{"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\/de\/blog\/administrirovanie\/nemnogo-o-standartah-kosmicheskoj-svyazi","title":{"rendered":"Einige Informationen zu Standards der Satellitenkommunikation.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Einige
\nMeteor M1 Satellit
\nQuelle: vladtime.ru<\/i><\/p>\n

Einf\u00fchrung<\/h2>\n

\nDer Betrieb von Raumfahrzeugen ist ohne Funkkommunikation unm\u00f6glich, und in diesem Artikel werde ich versuchen, die grundlegenden Ideen zu erkl\u00e4ren, die das Fundament der Standards bilden, die vom Internationalen Beratenden Komitee f\u00fcr Daten\u00fcbermittlung im Weltraum (Consultative Committee for Space Data Systems \u2013 CCSDS) entwickelt wurden. Diese Abk\u00fcrzung wird im Folgenden verwendet.<\/p>\n

Diese Ver\u00f6ffentlichung wird haupts\u00e4chlich dem Kanallniveau gewidmet sein, jedoch werden auch die grundlegenden Begriffe f\u00fcr andere Ebenen eingef\u00fchrt. Der Artikel erhebt in keiner Weise den Anspruch auf eine vollst\u00e4ndige und umfassende Beschreibung der Standards. Sie k\u00f6nnen sich \u00fcber diese informieren auf Website<\/a><\/noindex> CCSDS. Allerdings sind sie sehr komplex zu verstehen, und um sie zu durchdringen, haben wir viel Zeit investiert. Daher m\u00f6chte ich hier grundlegende Informationen bereitstellen, die es viel einfacher machen, alles andere zu verstehen. Lassen Sie uns also beginnen.
\n<\/a><\/noindex><\/p>\n

Ehrw\u00fcrdige Mission des CCSDS<\/h2>\n

\nVielleicht stellt sich jemand die Frage: Warum sollten sich alle an Standards halten, wenn man auch sein eigenes propriet\u00e4res Protokoll-Stack f\u00fcr die Funkkommunikation entwickeln kann (oder seinen eigenen Standard, mit einem Blackjack und neuen Funktionen), um die Sicherheit des Systems zu erh\u00f6hen?<\/p>\n

Erfahrungen haben gezeigt, dass es vorteilhafter ist, sich an die CCSDS-Standards zu halten, aus den folgenden Gr\u00fcnden:<\/p>\n

    \n
  1. Im Komitee, das f\u00fcr die Ver\u00f6ffentlichung der Standards verantwortlich ist, sind Vertreter aller gro\u00dfen Luft- und Raumfahrtagenturen der Welt vertreten, die ihre wertvollen Erfahrungen aus vielen Jahren der Planung und des Betriebs verschiedener Missionen einbringen. Es w\u00e4re sehr unklug, diese Erfahrungen zu ignorieren und immer wieder die gleichen Fehler zu machen.<\/li>\n
  2. Diese Standards werden von bereits auf dem Markt verf\u00fcgbaren Anlagen f\u00fcr Bodenstationen unterst\u00fctzt.<\/li>\n
  3. Wenn es w\u00e4hrend der Fehlersuche zu Problemen kommt, kann man sich immer an Kollegen aus anderen Agenturen wenden, die eine Verbindung zum Ger\u00e4t von ihrer Bodenstation aus herstellen k\u00f6nnen. Wie Sie sehen, sind Standards \u00e4u\u00dferst n\u00fctzlich, also lassen Sie uns die wichtigsten Punkte er\u00f6rtern.<\/li>\n<\/ol>\n

    <\/p>\n

    Architektur<\/h2>\n

    \nDie Standards stellen eine Sammlung von Dokumenten dar, die das ganz gew\u00f6hnliche OSI-Modell (Open System Interconnection) widerspiegeln, mit der Ausnahme, dass auf der kanalen Ebene die Allgemeinheit auf die Trennung zwischen Telemetrie (Abw\u00e4rtskanal \u2013 Raum \u2013 Erde) und Telecommands (Aufw\u00e4rtskanal) beschr\u00e4nkt ist.<\/p>\n

    \"Einige
    \n
    \nBetrachten wir einige Ebenen genauer, beginnend mit der physikalischen und aufw\u00e4rts. Um mehr Anschaulichkeit zu bieten, betrachten wir die Architektur der empfangenden Seite. Die \u00fcbertragende Seite ist deren Spiegelbild.<\/p>\n

    Physikalische Schicht<\/h2>\n

    \nAuf dieser Ebene findet die Umwandlung des modulierten Funksignals in einen Bitstrom statt. Die Standards hier sind im Wesentlichen empfehlender Natur, da es auf dieser Ebene schwierig ist, sich von der spezifischen Implementierung der Hardware zu abstrahieren. Hier spielt CCSDS eine Schl\u00fcsselrolle \u2013 es geht darum, zul\u00e4ssige Modulationen (BPSK, QPSK, 8-QAM usw.) zu definieren und einige Empfehlungen zur Implementierung von Mechanismen zur symbolischen Synchronisation, Dopplerverschiebungskompensation usw. zu geben.<\/p>\n

    Ebene der Synchronisation und Kodierung<\/h2>\n

    \nFormal ist sie ein Unterlevel der Datenlink-Ebene, wird jedoch h\u00e4ufig aufgrund ihrer Wichtigkeit innerhalb der CCSDS-Standards als separate Ebene betrachtet. Diese Ebene verwandelt den Bitstrom in sogenannte Rahmen (Telemetrie oder Telekommando), \u00fcber die wir sp\u00e4ter sprechen werden. Im Gegensatz zur symbolischen Synchronisation auf der physikalischen Ebene, die einen korrekten Bitstrom urspr\u00fcnglich erm\u00f6glicht, erfolgt hier die Rahmen-Synchronisation. Lassen Sie uns den Weg betrachten, den die Daten auf dieser Ebene zur\u00fccklegen (von unten nach oben):<\/p>\n

    \"Einige
    \n
    \nBevor wir dies tun, wollen wir ein paar Worte \u00fcber die Kodierung verlieren. Dieses Verfahren ist notwendig, um Bitfehler zu finden und\/oder zu korrigieren, die unvermeidlich bei der Daten\u00fcbertragung \u00fcber ein Funkkanal auftreten. Hier werden wir die Dekodierverfahren nicht betrachten, sondern nur die Informationen erhalten, die f\u00fcr das Verst\u00e4ndnis der weiteren Logik der Funktionalit\u00e4t der Ebene erforderlich sind. <\/p>\n

    Es gibt Block- und kontinuierliche Codes. Die Standards verlangen nicht die Verwendung eines bestimmten Kodierungstyps, jedoch sollte Kodierung in irgendeiner Form vorhanden sein. Zu den kontinuierlichen z\u00e4hlen faltenbasierte (convolutional) Codes. Diese dienen zur Kodierung eines kontinuierlichen Bitstroms. Im Gegensatz zu Blockcodes, bei denen die Daten in Codebl\u00f6cke unterteilt werden und nur innerhalb ganzer Bl\u00f6cke dekodiert werden k\u00f6nnen. Ein Codeblock besteht aus den \u00fcbertragbaren Daten und den angeh\u00e4ngten redundanten Informationen, die zur \u00dcberpr\u00fcfung der Korrektheit des Erhalts der Daten und zur Behebung m\u00f6glicher Fehler erforderlich sind. Zu den Blockcodes geh\u00f6ren die ber\u00fchmten Reed-Solomon-Codes.<\/p>\n

    Wenn die Faltungscodierung verwendet wird, gelangt der Bitstrom von Anfang an zum Dekoder. Das Ergebnis seiner Arbeit (alles passiert nat\u00fcrlich kontinuierlich) sind CADU-Datenbl\u00f6cke (channel access data unit). Diese Struktur ist f\u00fcr die Rahmen-Synchronisation notwendig. Am Ende jedes CADU ist ein Synchronisationsmarker (ASM \u2013 angeh\u00e4ngter Synchronisationsmarker) angef\u00fcgt. Dies sind bekannt vorausgesetzte 4 Byte, anhand derer der Synchronisierer den Anfang und das Ende von CADU findet. So wird die Rahmen-Synchronisation erreicht.<\/p>\n

    Der n\u00e4chste optionale Arbeitsschritt der Synchronisations- und Codierungsebene ist mit den Besonderheiten der physikalischen Ebene verbunden. Dies ist die Deraudomisierung. Der Grund daf\u00fcr ist, dass f\u00fcr die Erreichung der symbolischen Synchronisation h\u00e4ufige Umschaltungen zwischen den Symbolen erforderlich sind. Wenn wir beispielsweise ein Kilobyte an Daten \u00fcbertragen, das ausschlie\u00dflich aus Einsen besteht, wird die Synchronisation verloren gehen. Daher werden die Eingabedaten w\u00e4hrend der \u00dcbertragung mit einer periodischen pseudorandomisierten Sequenz vermischt, damit die Dichte von Nullen und Einsen gleichm\u00e4\u00dfig ist.<\/p>\n

    Anschlie\u00dfend erfolgt die Dekodierung der Blockcodes, und das, was \u00fcbrig bleibt, ist das Endprodukt der Synchronisations- und Codierungsebene \u2013 der Rahmen.<\/p>\n

    Kanalebene<\/h2>\n

    \nEinerseits erh\u00e4lt der Verarbeiter der Kanalebene Rahmen, andererseits gibt er Pakete aus. Da die Gr\u00f6\u00dfe der Pakete formal nicht begrenzt ist, m\u00fcssen sie f\u00fcr eine zuverl\u00e4ssige \u00dcbertragung in kleinere Strukturen \u2013 Rahmen \u2013 unterteilt werden. Hier betrachten wir zwei Unterabschnitte: einen f\u00fcr Telemetrie (TM) und einen f\u00fcr Telecommands (TC).<\/p>\n

    Telemetrie<\/h3>\n

    \nKurz gesagt, das sind die Daten, die die Bodenstation vom Satelliten erh\u00e4lt. Alle \u00fcbertragenen Informationen werden in kleine Fragmente fester L\u00e4nge \u2013 Rahmen \u2013 aufgeteilt, die die \u00fcbertragenen Daten und Steuerfelder enthalten. Lassen Sie uns die Struktur des Rahmens n\u00e4her betrachten:<\/p>\n

    \"Einige
    \n
    \nUnd beginnen wir mit dem Hauptheader des Telemetrierahmens. Ich werde mir in einigen Bereichen erlauben, die Standards einfach zu \u00fcbersetzen und dabei einige Erkl\u00e4rungen zu geben.<\/p>\n

    \"Einige
    \n
    \nDas Feld f\u00fcr die Identifikation des Hauptkanals (Master Channel ID) sollte die Versionsnummer des Rahmens und die Identifikation des Ger\u00e4ts enthalten.<\/p>\n

    Jeder KA sollte gem\u00e4\u00df den CCSDS-Standards eine eindeutige Kennung haben, anhand derer man, wenn man einen Frame hat, bestimmen kann, welchem Ger\u00e4t er geh\u00f6rt. Formell ist es notwendig, einen Antrag zur Registrierung des Ger\u00e4ts einzureichen, und dessen Name wird zusammen mit der Kennung in offenen Quellen ver\u00f6ffentlicht. Dennoch ignorieren oft russische Hersteller dieses Verfahren und vergeben zuf\u00e4llige Kennungen an das Ger\u00e4t. Die Versionsnummer des Frames hilft zu bestimmen, welche Version der Standards verwendet wird, um den Frame richtig zu lesen. Hier betrachten wir nur den konservativsten Standard mit der Version \u201e0\u201c.<\/i><\/p>\n

    Im Feld der Kennung des virtuellen Kanals (Virtual Channel ID) sollte die VCID des Kanals enthalten sein, von dem das Paket empfangen wurde. Es gibt keine Einschr\u00e4nkungen bei der Auswahl der VCID, insbesondere m\u00fcssen virtuelle Kan\u00e4le nicht unbedingt fortlaufend nummeriert werden.<\/p>\n

    Sehr h\u00e4ufig besteht die Notwendigkeit, die \u00fcbertragenen Daten zu multiplexen. Zu diesem Zweck gibt es einen Mechanismus virtueller Kan\u00e4le. Zum Beispiel \u00fcbertr\u00e4gt der Satellit Meteor-M2 ein Farbbild im sichtbaren Bereich, indem es es in drei Schwarz-Wei\u00df-Bilder aufteilt \u2013 jede Farbe wird in ihrem eigenen virtuellen Kanal als separates Paket \u00fcbertragen, obwohl die Struktur seiner Frames eine gewisse Abweichung von den Standards aufweist.<\/i><\/p>\n

    Das Feld des Flags f\u00fcr die operationale Kontrolle sollte ein Indikator f\u00fcr das Vorhandensein oder Fehlen des Feldes f\u00fcr die operationale Kontrolle im Telemetrie-Frame sein. Diese 4 Bytes am Ende des Frames dienen der Aufrechterhaltung der R\u00fcckmeldung bei der Kontrolle der Lieferung von Telecommands. Dar\u00fcber werden wir sp\u00e4ter sprechen.<\/p>\n

    Die Z\u00e4hler f\u00fcr die Frames des Haupt- und des virtuellen Kanals sind Felder, die bei der \u00dcbermittlung jedes Frames um eins erh\u00f6ht werden. Sie dienen als Indikator daf\u00fcr, dass kein Frame verloren gegangen ist.<\/i><\/p>\n

    Der Status der Telemetriedatenframe ist noch zwei Bytes Flags und Daten, von denen wir nur einige betrachten werden.<\/p>\n

    \"Einige
    \n
    \nDas Feld des Flags f\u00fcr den zus\u00e4tzlichen Header (Secondary Header) sollte ein Indikator f\u00fcr das Vorhandensein oder Fehlen eines zus\u00e4tzlichen Headers im Telemetrie-Frame sein.<\/p>\n

    Auf Wunsch kann zu jedem Frame ein zus\u00e4tzlicher Header hinzugef\u00fcgt werden, in dem alle Daten nach eigenem Ermessen platziert werden.<\/i><\/p>\n

    Das Feld f\u00fcr den Zeiger auf die erste Kopfzeile (First Header Pointer) muss, bei einem Synchronisierungsflag von \u201e1\u201c, die bin\u00e4re Darstellung der Position des ersten Oktets des ersten Pakets im Datenfeld (Data Field) des Telemetrie-Frames enthalten. Die Position wird ab 0 aufsteigend vom Beginn des Datenfeldes gez\u00e4hlt. Wenn es keinen Beginn des Pakets im Datenfeld des Telemetrie-Frames gibt, muss das Feld f\u00fcr den Zeiger auf die erste Kopfzeile den Wert in der bin\u00e4ren Darstellung \u201e11111111111\u201c haben (dies kann vorkommen, wenn ein langes Paket sich \u00fcber mehr als einen Frame erstreckt). <\/p>\n

    Wenn jedoch im Datenfeld ein leeres Paket (Idle Data) enthalten ist, muss der Zeiger auf die erste Kopfzeile den Wert in der bin\u00e4ren Darstellung \u201e11111111110\u201c haben. Das Empfangsger\u00e4t sollte anhand dieses Feldes den Datenstrom synchronisieren. Dieses Feld gew\u00e4hrleistet die Wiederherstellung der Synchronisation, selbst bei Frames, die ausgelassen wurden.<\/p>\n

    Das hei\u00dft, ein Paket kann zum Beispiel in der Mitte des vierten Frames beginnen und am Anfang des zwanzigsten Frames enden. Um seinen Beginn zu finden, dient genau dieses Feld. Pakete haben ebenfalls einen Kopf, in dem ihre L\u00e4nge festgelegt ist, daher muss der Verarbeiter des Link-Layers den Zeiger auf die erste Kopfzeile lesen, um festzustellen, wo das Paket endet.<\/i>
    \nWenn das Fehlerkontrollfeld vorhanden ist, muss es in jedem Telemetrie-Frame f\u00fcr einen bestimmten physikalischen Kanal w\u00e4hrend der gesamten Mission enthalten sein.<\/p>\n

    Dieses Feld wird unter Anwendung der CRC-Methode berechnet. Das Verfahren sollte n-16 Bit des Telemetrie-Frames aufnehmen und das Berechnungsergebnis in die letzten 16 Bit einf\u00fcgen.<\/p>\n

    Telemetrie-Befehle<\/h4>\n

    \nDer Frame der Telemetrie-Befehle weist einige wesentliche Unterschiede auf. Dazu geh\u00f6ren:<\/p>\n

      \n
    1. Eine andere Struktur der Kopfzeilen<\/li>\n
    2. Dynamische L\u00e4nge. Das bedeutet, dass die L\u00e4nge des Frames nicht festgelegt ist, wie es bei der Telemetrie der Fall ist, sondern je nach \u00fcbertragenen Paketen variieren kann.<\/li>\n
    3. Ein Mechanismus zur Gew\u00e4hrleistung der Zustellung von Paketen. Das hei\u00dft, das Raumfahrzeug muss den Erhalt der Frames best\u00e4tigen oder die erneute \u00dcbertragung vom Frame anfordern, der mit einem nicht korrigierbaren Fehler empfangen worden sein k\u00f6nnte.<\/li>\n<\/ol>\n

      \n\"Einige
      \n
      \n\"Einige
      \n
      \nViele Felder sind uns bereits aus dem Kopf des Telemetrie-Frames bekannt. Sie haben dieselbe Funktion, daher betrachten wir hier nur die neuen Felder.<\/p>\n

      Ein Bit des Flagge f\u00fcr die Umgehung sollte zur Kontrolle der \u00dcberpr\u00fcfung der Frames am Empf\u00e4nger verwendet werden. Der Wert \u201e0\u201c dieses Flags sollte anzeigen, dass dieses Frame vom Typ A ist und seine \u00dcberpr\u00fcfung gem\u00e4\u00df FARM erfolgen sollte. Der Wert \u201e1\u201c dieses Flags sollte dem Empf\u00e4nger anzeigen, dass dieses Frame vom Typ B ist und die \u00dcberpr\u00fcfung gem\u00e4\u00df FARM umgangen werden sollte.<\/p>\n

      Dieses Flag informiert den Empf\u00e4nger, ob der Mechanismus zur Best\u00e4tigung der Frame-Zustellung, bekannt als FARM \u2013 Frame Acceptance and Reporting Mechanism, verwendet werden soll.<\/i><\/p>\n

      Das Steuerungsflag sollte genutzt werden, um zu verstehen, ob das Datenfeld einen Befehl oder Daten transportiert. Wenn das Flag gleich \u201e0\u201c ist, sollte das Datenfeld Daten enthalten. Wenn das Flag gleich \u201e1\u201c ist, sollte das Datenfeld Kontrollinformationen f\u00fcr FARM enthalten.
      \nFARM ist ein endlicher Automat, dessen Parameter konfiguriert werden k\u00f6nnen.<\/i><\/p>\n

      RSVD. SPARE \u2013 reservierte Bits.<\/p>\n

      Es scheint, dass CCSDS in Zukunft Pl\u00e4ne daf\u00fcr hat, und zur R\u00fcckw\u00e4rtskompatibilit\u00e4t der Protokollversionen haben sie diese Bits bereits in den aktuellen Versionen des Standards reserviert.<\/i><\/p>\n

      Das Feld f\u00fcr die L\u00e4nge der Frames sollte eine Zahl im Bitformat enthalten, die der L\u00e4nge des Frames in Oktetten minus eins entspricht.<\/p>\n

      Das Datenfeld des Frames sollte unmittelbar nach dem Header ohne Unterbrechungen folgen und eine Ganzzahl an Oktetten enthalten, die maximal 1019 Oktetten lang sein kann. Dieses Feld sollte entweder einen Frame-Datenblock oder Informationen zu einem Steuerbefehl enthalten. Der Block mit den Frame-Daten sollte Folgendes enthalten:<\/p>\n