Meteor M1-satelliet
Bron: vladtime.ru
Introductie
De werking van ruimtetechnologie is onmogelijk zonder radiocommunicatie, en in dit artikel zal ik proberen de belangrijkste ideeën uit te leggen die de basis vormden van de normen ontwikkeld door het International Advisory Committee for Space Data Systems (CCSDS. Deze afkorting zal hieronder worden gebruikt) .
Dit bericht zal zich primair richten op de datalinklaag, maar er zullen ook basisconcepten voor andere lagen worden geïntroduceerd. Dit artikel heeft geenszins de pretentie een grondige en volledige beschrijving van de normen te geven. Je kunt het bekijken op CCSDS. Ze zijn echter erg moeilijk te begrijpen, en we hebben veel tijd besteed aan het proberen ze te begrijpen, dus hier wil ik basisinformatie geven, waardoor het veel gemakkelijker zal zijn om al het andere te begrijpen. Dus laten we beginnen.
Edele missie van CCSDS
Misschien heeft iemand een vraag: waarom zou iedereen zich aan standaarden moeten houden als je je eigen propriëtaire radioprotocolstack (of je eigen standaard, met blackjack en nieuwe functies) kunt ontwikkelen, waardoor de veiligheid van het systeem toeneemt?
Zoals de praktijk laat zien, is het om de volgende redenen winstgevender om aan de CCSDS-normen te voldoen:
- De commissie die verantwoordelijk is voor het publiceren van de normen bestaat uit vertegenwoordigers van alle grote lucht- en ruimtevaartagentschappen ter wereld. Zij brengen onschatbare ervaring mee die is opgedaan tijdens vele jaren van ontwerp en uitvoering van verschillende missies. Het zou heel absurd zijn om deze ervaring te negeren en opnieuw op hun hark te stappen.
- Deze normen worden ondersteund door grondstationapparatuur die al op de markt is.
- Bij het oplossen van eventuele problemen kunt u altijd de hulp inroepen van collega's van andere instanties, zodat zij vanaf hun grondstation een communicatiesessie met het apparaat kunnen voeren. Zoals u kunt zien, zijn normen uiterst nuttig, dus laten we eens kijken naar de belangrijkste punten ervan.
Architectuur
De standaarden zijn een reeks documenten die het meest gebruikelijke OSI-model (Open System Interconnection) weerspiegelen, behalve dat op datalinkniveau de gemeenschappelijkheid beperkt is tot de verdeling in telemetrie (downlink - ruimte - aarde) en telecommands (uplink).
Laten we enkele niveaus in meer detail bekijken, te beginnen met het fysieke en hogerop. Voor meer duidelijkheid zullen we de architectuur van de ontvangende kant bekijken. De zendende is zijn spiegelbeeld.
Fysieke laag
Op dit niveau wordt het gemoduleerde radiosignaal omgezet in een bitstroom. De standaarden zijn hier vooral adviserend van aard, omdat het op dit niveau lastig is om te abstraheren van de specifieke implementatie van de hardware. Hier is de sleutelrol van CCSDS het definiëren van aanvaardbare modulaties (BPSK, QPSK, 8-QAM, enz.) en het geven van enkele aanbevelingen over de implementatie van symboolsynchronisatiemechanismen, Doppler-compensatie, enz.
Synchronisatie- en coderingsniveau
Formeel is het een sublaag van de datalinklaag, maar vanwege het belang ervan binnen de CCSDS-standaarden wordt het vaak gescheiden in een aparte laag. Deze laag zet de bitstroom om in zogenaamde frames (telemetrie of telecommands), waar we het later over zullen hebben. In tegenstelling tot symboolsynchronisatie op de fysieke laag, waardoor u de juiste bitstroom kunt verkrijgen, wordt hier framesynchronisatie uitgevoerd. Beschouw het pad dat gegevens op dit niveau volgen (van onder naar boven):
Maar daarvoor is het de moeite waard om een paar woorden over codering te zeggen. Deze procedure is nodig om bitfouten te vinden en/of te corrigeren die onvermijdelijk optreden bij het verzenden van gegevens via een radiokanaal. Hier zullen we geen decoderingsprocedures overwegen, maar zullen we alleen de informatie verkrijgen die nodig is om de verdere logica van het niveau te begrijpen.
Codes kunnen blokvormig of doorlopend zijn. De standaarden dwingen niet het gebruik van een specifiek type codering af, maar deze moet wel als zodanig aanwezig zijn. Continue codes omvatten convolutionele codes. Ze worden gebruikt om een continue bitstroom te coderen. Dit in tegenstelling tot blokcodes, waarbij gegevens worden opgedeeld in codeblokken en alleen binnen volledige blokken kunnen worden gedecodeerd. Het codeblok vertegenwoordigt de verzonden gegevens en de bijgevoegde redundante informatie die nodig is om de juistheid van de ontvangen gegevens te verifiëren en mogelijke fouten te corrigeren. Blokcodes omvatten de beroemde Reed-Solomon-codes.
Als convolutionele codering wordt gebruikt, komt de bitstroom vanaf het begin de decoder binnen. Het resultaat van zijn werk (dit alles gebeurt uiteraard continu) zijn CADU-datablokken (channel access data unit). Deze structuur is nodig voor framesynchronisatie. Aan het einde van elke CADU bevindt zich een aangesloten synchronisatiemaker (ASM). Dit zijn 4 vooraf bekende bytes, waarmee de synchronisator het begin en einde van de CADU vindt. Dit is hoe framesynchronisatie wordt bereikt.
De volgende optionele fase van de synchronisatie- en coderingslaag houdt verband met de eigenaardigheden van de fysieke laag. Dit is derandomisatie. Feit is dat om symboolsynchronisatie te bereiken veelvuldig schakelen tussen symbolen noodzakelijk is. Dus als we bijvoorbeeld een kilobyte aan gegevens verzenden die geheel uit enen bestaan, gaat de synchronisatie verloren. Daarom worden de invoergegevens tijdens de verzending gemengd met een periodieke pseudo-willekeurige reeks, zodat de dichtheid van nullen en enen uniform is.
Vervolgens worden de blokcodes gedecodeerd en wat overblijft is het eindproduct van het synchronisatie- en coderingsniveau: een frame.
Datalinklaag
Aan de ene kant ontvangt de linklaagprocessor frames en aan de andere kant geeft hij pakketten uit. Omdat de grootte van pakketten niet formeel beperkt is, is het voor hun betrouwbare transmissie noodzakelijk om ze op te splitsen in kleinere structuren: frames. Hier zullen we naar twee subsecties kijken: afzonderlijk voor telemetrie (TM) en telecommands (TC).
Telemetrie
Simpel gezegd zijn dit de gegevens die het grondstation van het ruimtevaartuig ontvangt. Alle verzonden informatie wordt verdeeld in kleine fragmenten van een vaste lengte: frames die verzonden gegevens en servicevelden bevatten. Laten we de framestructuur eens nader bekijken:
En laten we onze overweging beginnen met de hoofdkop van het telemetrieframe. Verder zal ik mezelf toestaan de normen op sommige plaatsen eenvoudigweg te vertalen, waarbij ik gaandeweg enkele verduidelijkingen zal geven.
Het veld Master Channel ID moet het frameversienummer en de apparaat-ID bevatten.
Elk ruimtevaartuig moet volgens CCSDS-normen zijn eigen unieke identificatie hebben, waarmee men, met een frame, kan bepalen tot welk apparaat het behoort. Formeel is het noodzakelijk om een aanvraag in te dienen om het apparaat te registreren, en de naam ervan, samen met de identificatie, zal in open bronnen worden gepubliceerd. Russische fabrikanten negeren deze procedure echter vaak en wijzen een willekeurige identificatie aan het apparaat toe. Het frameversienummer helpt bepalen welke versie van de standaarden wordt gebruikt om het frame correct te kunnen lezen. Hier beschouwen we alleen de meest conservatieve standaard met versie “0”.
Het veld Virtuele Kanaal-ID moet de VCID bevatten van het kanaal waarvan het pakket afkomstig is. Er zijn geen beperkingen op de keuze van VCID; met name virtuele kanalen zijn niet noodzakelijkerwijs opeenvolgend genummerd.
Heel vaak is er behoefte aan het multiplexen van verzonden gegevens. Voor dit doel is er een mechanisme van virtuele kanalen. De Meteor-M2-satelliet zendt bijvoorbeeld een kleurenbeeld uit in het zichtbare bereik en verdeelt dit in drie zwart-witte beelden - elke kleur wordt verzonden in zijn eigen virtuele kanaal in een afzonderlijk pakket, hoewel er enige afwijking is van de standaarden in de structuur van zijn frames.
Het Operationele Controle-vlagveld zal een indicator zijn van de aanwezigheid of afwezigheid van het Operationele Controle-veld in het telemetrieframe. Deze 4 bytes aan het einde van het frame dienen om feedback te geven bij het regelen van de levering van telecommandframes. We zullen er later over praten.
De frametellers van het hoofdkanaal en het virtuele kanaal zijn velden die elke keer dat een frame wordt verzonden met één worden verhoogd. Dienen als een indicator dat er geen enkel frame verloren is gegaan.
De gegevensstatus van het telemetrieframe bestaat uit nog twee bytes aan vlaggen en gegevens, waarvan we er slechts een paar zullen bekijken.
Het secundaire header-vlagveld moet een indicator zijn van de aan- of afwezigheid van een secundaire header in het telemetrieframe.
Als u wilt, kunt u aan elk frame een extra header toevoegen en daar naar eigen goeddunken gegevens plaatsen.
Het First Header Pointer-veld zal, wanneer de synchronisatievlag is ingesteld op "1", een binaire weergave bevatten van de positie van het eerste octet van het eerste pakket in het gegevensveld van het telemetrieframe. De positie wordt geteld vanaf 0 in oplopende volgorde vanaf het begin van het gegevensveld. Als er geen start van het pakket in het dataveld van het telemetrieframe is, moet de verwijzing naar het eerste headerveld de waarde hebben in de binaire weergave "11111111111" (dit kan gebeuren als een lang pakket over meer dan één frame wordt verspreid ).
Als het dataveld een leeg pakket bevat (Idle Data), dan moet de pointer naar de eerste header de waarde hebben in de binaire representatie “11111111110”. Met dit veld moet de ontvanger de stream synchroniseren. Dit veld zorgt ervoor dat de synchronisatie wordt hersteld, zelfs als er frames worden verwijderd.
Dat wil zeggen dat een pakket bijvoorbeeld in het midden van het vierde frame kan beginnen en aan het begin van het twintigste frame kan eindigen. Dit veld wordt gebruikt om het begin ervan te vinden. Pakketten hebben ook een header die de lengte ervan specificeert, dus wanneer een pointer naar de eerste header wordt gevonden, moet de link-layer-processor deze lezen, en daarbij bepalen waar het pakket zal eindigen.
Als er een foutcontroleveld aanwezig is, moet dit gedurende de hele missie in elk telemetrieframe voor een bepaald fysiek kanaal aanwezig zijn.
Dit veld wordt berekend met behulp van de CRC-methode. De procedure moet n-16 bits van het telemetrieframe gebruiken en het resultaat van de berekening in de laatste 16 bits invoegen.
TV-teams
Het tv-opdrachtframe kent een aantal belangrijke verschillen. Onder hen:
- Andere kopstructuur
- Dynamische lengte. Dit betekent dat de framelengte niet rigide wordt ingesteld, zoals bij telemetrie, maar kan variëren afhankelijk van de verzonden pakketten.
- Garantiemechanisme voor pakketbezorging. Dat wil zeggen dat het ruimtevaartuig, na ontvangst ervan, de juistheid van de frameontvangst moet bevestigen, of moet verzoeken om doorzending vanaf een frame dat ontvangen had kunnen worden met een onherstelbare fout.
Veel velden zijn ons al bekend uit de telemetrieframeheader. Ze hebben hetzelfde doel, dus hier zullen we alleen de nieuwe velden beschouwen.
Eén bit van de bypass-vlag moet worden gebruikt om de framecontrole bij de ontvanger te regelen. Een waarde van "0" voor deze vlag geeft aan dat het frame een type A-frame is en moet worden geverifieerd volgens FARM. Een waarde van "1" voor deze vlag zou aan de ontvanger moeten aangeven dat dit frame een Type B-frame is en de FARM-controle moet omzeilen.
Deze vlag informeert de ontvanger of hij een bevestigingsmechanisme voor frameaflevering moet gebruiken, genaamd FARM - Frame Acceptance and Reporting Mechanism.
De besturingsopdrachtvlag 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 besturingsinformatie voor FARM bevatten.
FARM is een eindige toestandsmachine waarvan de parameters kunnen worden geconfigureerd.
RSVD. SPARE – gereserveerde bits.
Het lijkt erop dat CCSDS plannen voor hen heeft in de toekomst, en voor achterwaartse compatibiliteit van protocolversies hebben ze deze bits al gereserveerd in de huidige versies van de standaard.
Het framelengteveld moet een getal in bitweergave bevatten dat gelijk is aan de framelengte in octetten min één.
Het framegegevensveld moet de header zonder spaties volgen en een geheel aantal bytes bevatten, dat maximaal 1019 bytes lang kan zijn. Dit veld moet framegegevensblok- of besturingsopdrachtinformatie bevatten. Het framegegevensblok moet het volgende bevatten:
- geheel getal aantal gebruikersgegevensoctetten
- segmentkop gevolgd door een geheel aantal gebruikersgegevensoctetten
Als er een header aanwezig is, moet het datablok een pakket, een set pakketten of een deel van een pakket bevatten. Een datablok zonder header kan geen delen van pakketten bevatten, maar kan wel datablokken in privéformaat bevatten. Hieruit volgt dat een header nodig is wanneer het verzonden datablok niet in één frame past. Een gegevensblok met een header wordt een segment genoemd
Het twee-bits vlaggenveld moet het volgende bevatten:
- "01" - als het eerste deel van de gegevens zich in het datablok bevindt
- “00” - als het middelste deel van de gegevens zich in het datablok bevindt
- "10" - als het laatste stukje data zich in het datablok bevindt
- “11” - als er geen verdeling is en een of meer pakketten volledig in het datablok passen.
Het veld MAP ID moet nullen bevatten als er geen MAP-kanalen worden gebruikt.
Soms zijn 6 bits toegewezen aan virtuele kanalen niet voldoende. En als het nodig is om gegevens naar een groter aantal kanalen te multiplexen, worden nog eens 6 bits uit de segmentheader gebruikt.
BOERDERIJ
Laten we het werkingsmechanisme van het controlesysteem voor personeelslevering eens nader bekijken. Dit systeem voorziet alleen in het werken met frames van telecommanders vanwege hun belang (telemetrie kan altijd opnieuw worden aangevraagd en het ruimtevaartuig moet het grondstation duidelijk horen en altijd zijn commando's gehoorzamen). Stel dat we besluiten onze satelliet te reflashen en er een binair bestand van 10 kilobytes naar toe te sturen. Op linkniveau wordt het bestand opgedeeld in 10 frames (0, 1, ..., 9), die één voor één naar boven worden gestuurd. Wanneer de verzending is voltooid, moet de satelliet de juistheid van de pakketontvangst bevestigen, of rapporteren op welk frame de fout is opgetreden. Deze informatie wordt naar het operationele controleveld in het dichtstbijzijnde telemetrieframe gestuurd (of het ruimtevaartuig kan de verzending van een inactief frame initiëren als het niets te zeggen heeft). Op basis van de ontvangen telemetrie zorgen we ervoor dat alles in orde is, of gaan we verder met het opnieuw verzenden van het bericht. Laten we aannemen dat de satelliet frame #7 niet heeft gehoord. Dit betekent dat we hem frames 7, 8, 9 sturen. Als er geen antwoord is, wordt het hele pakket opnieuw verzonden (enzo meerdere keren totdat we beseffen dat de pogingen tevergeefs zijn).
Hieronder vindt u de structuur van het operationele besturingsveld met een beschrijving van enkele velden. De gegevens in dit veld worden CLCW - Communication Link Control Word genoemd.
Omdat je op de foto gemakkelijk het doel van de hoofdvelden kunt raden, en de andere saai zijn om naar te kijken, verberg ik de gedetailleerde beschrijving onder een spoiler
Uitleg van CLCW-veldenType controlewoord:
Bij dit type moet het stuurwoord 0 bevatten
Controlewoordversie (CLCW-versienummer):
Voor dit type moet het stuurwoord in de bitrepresentatie gelijk zijn aan "00".
Statusveld:
Het gebruik van dit veld wordt voor elke missie afzonderlijk bepaald. Kan worden gebruikt voor lokale verbeteringen door verschillende ruimtevaartorganisaties.
Virtuele kanaalidentificatie:
Moet de identificatie bevatten van het virtuele kanaal waaraan dit stuurwoord is gekoppeld.
Vlag voor fysieke kanaaltoegang:
De vlag moet informatie geven over de gereedheid van de fysieke laag van de ontvanger. Als de fysieke laag van de ontvanger niet klaar is om frames te ontvangen, moet het veld “1” bevatten, anders “0”.
Vlag voor synchronisatiefout:
De vlag kan erop wijzen dat de fysieke laag op een slecht signaalniveau werkt en dat het aantal afgewezen frames te hoog is. Het gebruik van dit veld is optioneel; indien gebruikt, moet het “0” bevatten als synchronisatie beschikbaar is, en “1” als dat niet het geval is.
Blokkerende vlag:
Deze bit bevat de FARM-vergrendelingsstatus voor elk virtueel kanaal. Een waarde van "1" in dit veld zou moeten aangeven dat FARM is uitgeschakeld en dat frames voor elke virtuele laag zullen worden weggegooid, anders "0".
Wachtvlag:
Deze bit wordt gebruikt om aan te geven dat de ontvanger geen gegevens op het opgegeven virtuele kanaal kan verwerken. Een waarde van "1" geeft aan dat alle frames op dit virtuele kanaal worden verwijderd, anders "0".
Voorwaartse vlag:
Deze vlag zal een "1" bevatten als een of meer type A-frames zijn weggegooid of er gaten zijn gevonden, dus opnieuw verzenden is noodzakelijk. De vlag "0" geeft aan dat er geen verloren frames of overgeslagen beelden zijn geweest.
Reactiewaarde:
Framenummer dat niet is ontvangen. Bepaald door de teller in de header van het telecommandframe
netwerklaag
Laten we dit niveau eens nader bekijken. Er zijn hier twee opties: gebruik het space packet-protocol, of sluit een ander protocol in het CCSDS-pakket in.
Een overzicht van het space packet-protocol is een onderwerp voor een apart artikel. Het is ontworpen om zogenaamde applicaties naadloos gegevens uit te laten wisselen. Elke applicatie heeft een eigen adres en basisfunctionaliteit voor het uitwisselen van gegevens met andere applicaties. Er zijn ook diensten die het verkeer routeren, de levering controleren, enz.
Met inkapseling is alles eenvoudiger en duidelijker. De standaarden maken het mogelijk om alle protocollen in CCSDS-pakketten in te kapselen door een extra header toe te voegen.
Waar de header verschillende betekenissen heeft, afhankelijk van de lengte van het protocol dat wordt ingekapseld:
Hier is het hoofdveld de lengte van de lengte. Dit kan variëren van 0 tot 4 bytes. Ook in deze header moet u het type ingekapseld protocol aangeven met behulp van de tabel .
IP-inkapseling maakt gebruik van een andere add-on om het type pakket te bepalen.
Je moet nog een header toevoegen, één octet lang:
Waar PID een andere protocol-ID is die wordt gebruikt
Conclusie
Op het eerste gezicht lijkt het misschien dat de CCSDS-headers extreem redundant zijn en dat sommige velden kunnen worden weggegooid. De efficiëntie van het resulterende kanaal (tot op netwerkniveau) is inderdaad ongeveer 40%. Zodra echter de noodzaak ontstaat om deze normen te implementeren, wordt het duidelijk dat elk gebied, elke rubriek zijn eigen belangrijke missie heeft, en het negeren hiervan leidt tot een aantal dubbelzinnigheden.
Als de habrasociety interesse toont in dit onderwerp, zal ik met plezier een hele reeks artikelen publiceren gewijd aan de theorie en praktijk van ruimtecommunicatie. Bedankt voor uw aandacht!
bronnen
PS
Sla niet te hard als u onjuistheden ontdekt. Rapporteer ze en ze worden opgelost :)
Bron: www.habr.com