{"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":"Ein wenig \u00fcber Standards der Raumkommunikation","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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

Einf\u00fchrung<\/h2>\n

\nDer Betrieb von Weltraumtechnik ist ohne Funkkommunikation nicht m\u00f6glich. In diesem Artikel m\u00f6chte ich die grundlegenden Ideen erl\u00e4utern, die den Standards zugrunde liegen, die vom Internationalen Beratenden Komitee f\u00fcr Raumdaten\u00fcbertragungssysteme (Consultative Committee for Space Data Systems \u2013 CCSDS) entwickelt wurden. In der Folge wird diese Abk\u00fcrzung verwendet.<\/p>\n

Diese Ver\u00f6ffentlichung wird sich haupts\u00e4chlich mit der Kanalschicht befassen, jedoch werden auch grundlegende Konzepte f\u00fcr andere Ebenen eingef\u00fchrt. Der Artikel erhebt in keiner Weise den Anspruch, eine vollst\u00e4ndige und umfassende Beschreibung der Standards zu liefern. Diese k\u00f6nnen Sie auf Webseite<\/a><\/noindex> CCSDS finden. Sie sind jedoch sehr schwer verst\u00e4ndlich, und um sie zu begreifen, haben wir viel Zeit investiert. Daher m\u00f6chte ich hier grundlegende Informationen pr\u00e4sentieren, die es einfacher machen, die restlichen Konzepte zu verstehen. Lassen Sie uns also beginnen.
\n<\/a><\/noindex><\/p>\n

Die edle Mission von CCSDS<\/h2>\n

\nVielleicht fragt sich jemand: Warum sollten wir uns an Standards halten, wenn wir ein eigenes propriet\u00e4res Protokoll-Stack f\u00fcr die Funkkommunikation entwickeln k\u00f6nnten (oder unseren eigenen Standard, mit Blackjack und neuen Features), um die Sicherheit des Systems zu erh\u00f6hen?<\/p>\n

Die Praxis zeigt, dass es aus mehreren Gr\u00fcnden vorteilhafter ist, sich an die CCSDS-Standards zu halten:<\/p>\n

    \n
  1. In das Komitee zur Ver\u00f6ffentlichung der Standards sind Vertreter aller gro\u00dfen Raumfahrtorganisationen weltweit berufen worden, die ihren unsch\u00e4tzbaren Erfahrungsschatz aus vielen Jahren der Planung und Durchf\u00fchrung verschiedenster Missionen einbringen. Es w\u00e4re \u00e4u\u00dferst unklug, diese Erfahrung zu ignorieren und dieselben Fehler erneut zu machen.<\/li>\n
  2. Diese Standards werden von bereits auf dem Markt vorhandenen Ausr\u00fcstungen der Bodenstationen unterst\u00fctzt.<\/li>\n
  3. Bei der Behebung von Problemen kann jederzeit Hilfe von Kollegen in anderen Agenturen angefordert werden, die eine Verbindung mit dem Ger\u00e4t von ihrer Bodenstation aus herstellen. Wie Sie sehen, sind Standards \u00e4u\u00dferst n\u00fctzlich, also schauen wir uns ihre Schl\u00fcsselpunkte genauer an.<\/li>\n<\/ol>\n

    <\/p>\n

    Architektur von<\/h2>\n

    \nDie Standards sind eine Sammlung von Dokumenten, die das allgemeine Modell der OSI (Open System Interconnection) widerspiegeln, mit der Ausnahme, dass auf der Datenverbindungsschicht die Interaktion auf die Aufteilung in Telemetrie (der \u201eDownlink\u201c \u2013 Raum zu Erde) und Telecommands (der \u201eUplink\u201c) beschr\u00e4nkt ist.<\/p>\n

    \"Ein
    \n
    \nLassen Sie uns einige Ebenen im Detail betrachten, beginnend mit der physischen und sich nach oben bewegend. Zur besseren Veranschaulichung betrachten wir die Architektur der empfangenden Seite. Die sendende Seite stellt ihr Spiegelbild dar.<\/p>\n

    Physikalische Ebene<\/h2>\n

    \nAuf dieser Ebene erfolgt die Umwandlung des modulierten Funksignals in einen Bitstrom. Die Standards sind hier \u00fcberwiegend empfehlender Natur, da es auf dieser Ebene schwierig ist, sich von der spezifischen Implementierung der Hardware zu abstrahieren. Hier kommt dem CCSDS eine Schl\u00fcsselrolle zu \u2013 die zul\u00e4ssigen Modulationen (BPSK, QPSK, 8-QAM usw.) zu definieren und einige Empfehlungen f\u00fcr die Implementierung von Mechanismen zur symbolischen Synchronisierung, der Kompensation des Doppler-Effekts usw. zu geben.<\/p>\n

    Synchronisations- und Codierungsebene<\/h2>\n

    \nFormell betrachtet ist es eine Unterebene der Kanalschicht, wird jedoch aufgrund seiner Bedeutung innerhalb der CCSDS-Standards h\u00e4ufig als eigenst\u00e4ndige Ebene hervorgehoben. Diese Ebene wandelt den Bitstrom in sogenannte Frames (Telemetrie oder Telecommands) um, \u00fcber die wir sp\u00e4ter sprechen werden. Im Gegensatz zur symbolischen Synchronisation auf der physikalischen Ebene, die einen korrekten Bitstrom gew\u00e4hrleistet, wird hier eine Frame-Synchronisation durchgef\u00fchrt. Lassen Sie uns den Weg betrachten, den die Daten auf dieser Ebene (von unten nach oben) durchlaufen:<\/p>\n

    \"Ein
    \n
    \nBevor wir jedoch dazu kommen, ist es wichtig, ein paar Worte \u00fcber die Kodierung zu verlieren. Diese Prozedur ist notwendig, um Bitfehler zu erkennen und\/oder zu korrigieren, die unvermeidlich beim \u00dcbertragen von Daten \u00fcber den Funkkanal auftreten. Hier werden wir die Dekodierungsverfahren nicht betrachten, sondern uns nur mit den Informationen besch\u00e4ftigen, die erforderlich sind, um die weitere Logik der Funktionalit\u00e4t dieser Ebene zu verstehen. <\/p>\n

    Es gibt blockbasierte und kontinuierliche Codes. Die Standards schreiben keinen spezifischen Kodierungstyp vor, jedoch muss ein solches Verfahren vorhanden sein. Zu den kontinuierlichen Codes geh\u00f6ren Faltungscodes (convolutional codes). Diese kodieren einen stetigen Bitstrom. Im Gegensatz zu blockbasierten Codes, bei denen Daten in Codebl\u00f6cke (codeblock) unterteilt werden und nur in Form vollst\u00e4ndiger Bl\u00f6cke dekodiert werden k\u00f6nnen. Ein Codeblock besteht aus den zu \u00fcbertragenden Daten und den zus\u00e4tzlichen Informationen, die zur \u00dcberpr\u00fcfung der korrekten Datenempfang und zur Behebung m\u00f6glicher Fehler erforderlich sind. Zu den blockbasierten Codes z\u00e4hlen die bekannten Reed-Solomon-Codes.<\/p>\n

    Wenn Faltungscodierung verwendet wird, wird der Bitstrom zu Beginn an den Dekoder weitergeleitet. Das Ergebnis seiner Arbeit (dies geschieht selbstverst\u00e4ndlich kontinuierlich) sind CADU-Datenbl\u00f6cke (channel access data unit). Diese Struktur ist erforderlich f\u00fcr die Rahmensynchronisation. Am Ende jeder CADU ist ein Synchronisationsmarker (ASM \u2013 attached synch marker) angeh\u00e4ngt. Dies sind vier vordefinierte Bytes, mit denen der Synchronisator den Anfang und das Ende der CADU findet. So wird die Rahmensynchronisation erreicht.<\/p>\n

    Der n\u00e4chste optionale Schritt in der Synchronisations- und Kodierungsstufe bezieht sich auf die Besonderheiten der physikalischen Ebene. Dies ist die D\u00e9randomisierung. Um symbolische Synchronisation zu erreichen, sind h\u00e4ufige Wechsel zwischen den Symbolen erforderlich. Wenn wir beispielsweise ein Kilobyte an Daten \u00fcbertragen, das ausschlie\u00dflich aus Einsen besteht, wird die Synchronisation verloren gehen. Daher werden bei der \u00dcbertragung die Eingabedaten mit einer periodischen pseudo-zuf\u00e4lligen Sequenz gemischt, um eine gleichm\u00e4\u00dfige Verteilung von Nullen und Einsen zu gew\u00e4hrleisten.<\/p>\n

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

    Kanalebene<\/h2>\n

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

    Telemetrie<\/h3>\n

    \nEinfach ausgedr\u00fcckt sind das die Daten, die die Bodenkontrollstation vom Raumfahrzeug erh\u00e4lt. Alle \u00fcbermittelten Informationen werden in kleine, feste L\u00e4ngen zerlegt \u2013 in Frames, die die \u00fcbertragenen Daten und Steuerfelder enthalten. Lassen Sie uns die Struktur eines Frames n\u00e4her betrachten:<\/p>\n

    \"Ein
    \n
    \nWir beginnen mit dem Haupt-Header des Telemetrie-Frames. An dieser Stelle erlaube ich mir, die Standards teilweise direkt zu \u00fcbersetzen und gleichzeitig einige Erkl\u00e4rungen zu geben.<\/p>\n

    \"Ein
    \n
    \nDas Feld f\u00fcr die Hauptkanal-ID (Master Channel ID) muss die Versionsnummer des Frames und die Identifikationsnummer des Ger\u00e4tes enthalten.<\/p>\n

    Jeder Knoten, gem\u00e4\u00df den CCSDS-Standards, muss eine eindeutige Kennung haben, anhand derer festgestellt werden kann, zu welchem Ger\u00e4t er geh\u00f6rt. Formell muss ein Antrag auf Registrierung des Ger\u00e4ts eingereicht werden, und dessen Name sowie die Kennung werden in \u00f6ffentlichen Quellen ver\u00f6ffentlicht. Oft ignorieren jedoch russische Hersteller dieses Verfahren und weisen dem Ger\u00e4t willk\u00fcrlich eine Kennung zu. Die Versionsnummer des Frames hilft dabei zu bestimmen, welche Version der Standards verwendet wird, um den Frame korrekt zu lesen. Hier betrachten wir nur den konservativsten Standard mit der Version \u201e0\u201c.<\/i><\/p>\n

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

    Sehr oft besteht die Notwendigkeit, die \u00fcbertragenen Daten zu multiplexen. Daf\u00fcr gibt es einen Mechanismus f\u00fcr virtuelle Kan\u00e4le. Zum Beispiel \u00fcbertr\u00e4gt der Satellit Meteor-M2 ein farbiges Bild im sichtbaren Bereich, indem es in drei schwarz-wei\u00dfe Bilder aufgeteilt wird \u2013 jede Farbe wird in ihrem eigenen virtuellen Kanal als separates Paket \u00fcbertragen, obwohl es in der Struktur seiner Frames einige Abweichungen von den Standards gibt.<\/i><\/p>\n

    Das Feld f\u00fcr das Flagge Operational Control sollte einen Indikator f\u00fcr das Vorhandensein oder Fehlen des Feldes Operational Control im Telemetrie-Frame darstellen. Diese 4 Bytes am Ende des Frames dienen der Unterst\u00fctzung des Feedbacks bei der Kontrolle der Lieferung von Telemetrie-Frames. Dar\u00fcber werden wir sp\u00e4ter sprechen.<\/p>\n

    Die Z\u00e4hler f\u00fcr den Haupt- und den virtuellen Kanal sind Felder, die bei der \u00dcbertragung 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 Daten im Telemetrie-Frame besteht aus zwei weiteren Bytes f\u00fcr Flags und Daten, wobei wir nur einige davon betrachten werden.<\/p>\n

    \"Ein
    \n
    \nDas Feld f\u00fcr das Flag des zus\u00e4tzlichen Headers (Secondary Header) sollte einen Indikator f\u00fcr das Vorhandensein oder Fehlen eines zus\u00e4tzlichen Headers (Secondary Header) im Telemetrie-Frame darstellen.<\/p>\n

    Optional can be added to each frame, an additional header, where you can place any data at your discretion.<\/i><\/p>\n

    Das Feld f\u00fcr den Zeiger auf den ersten Header (First Header Pointer) muss, wenn das Synchronisierungsflag auf \"1\" gesetzt ist, die bin\u00e4re Darstellung der Position des ersten Oktetts des ersten Pakets im Datenfeld (Data Field) des Telemetrie-Frames enthalten. Die Position wird ab 0 in aufsteigender Reihenfolge vom Beginn des Datenfeldes gez\u00e4hlt. Wenn im Datenfeld des Telemetrie-Frames kein Paketbeginn vorhanden ist, sollte das Feld f\u00fcr den Zeiger auf den ersten Header den bin\u00e4ren Wert \u201e11111111111\u201c haben (das kann vorkommen, wenn ein langes Paket sich \u00fcber mehrere Frames erstreckt). <\/p>\n

    Wenn das Datenfeld jedoch ein leeres Paket (Idle Data) enth\u00e4lt, sollte der Zeiger auf den ersten Header den bin\u00e4ren Wert \u201e11111111110\u201c aufweisen. Anhand dieses Feldes sollte der Empf\u00e4nger die Synchronisierung des Streams durchf\u00fchren. Dieses Feld gew\u00e4hrleistet die Wiederherstellung der Synchronisierung, selbst wenn Frames \u00fcbersprungen werden.<\/p>\n

    Das bedeutet, dass das Paket zum Beispiel in der Mitte des 4. Frames beginnen und am Anfang des 20. enden kann. Um den Beginn zu finden, dient genau dieses Feld. Pakete haben ebenfalls einen Header, in dem die L\u00e4nge vermerkt ist. Daher muss der Kanal-Handler beim Finden des Zeigers auf den ersten Header diesen lesen, um festzustellen, wo das Paket endet.<\/i>
    \nWenn das Fehlerkontrollfeld vorhanden ist, muss es in jedem Frame der Telemetrie f\u00fcr einen bestimmten physikalischen Kanal w\u00e4hrend der gesamten Mission enthalten sein.<\/p>\n

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

    Telekommandos<\/h4>\n

    \nDer Frame der Telekommandos weist mehrere wesentliche Unterschiede auf. Dazu geh\u00f6ren:<\/p>\n

      \n
    1. Eine andere Struktur der Header<\/li>\n
    2. Dynamische L\u00e4nge. Das bedeutet, dass die L\u00e4nge des Frames nicht starr festgelegt ist, wie es in der Telemetrie der Fall ist, sondern je nach \u00fcbertragenen Paketen variieren kann.<\/li>\n
    3. Der Mechanismus zur Paketliefergarantie. Das hei\u00dft, der KAM muss nach dem Erhalt die Korrektheit des Empfangs der Frames best\u00e4tigen oder die \u00dcbermittlung vom Frame anfordern, der m\u00f6glicherweise mit einem nicht korrigierbaren Fehler angenommen wurde.<\/li>\n<\/ol>\n

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

      Ein Bit des Umgehungsflags sollte verwendet werden, um die \u00dcberpr\u00fcfung der Frames am Empf\u00e4nger zu steuern. Der Wert \u201e0\u201c dieses Flags sollte darauf hinweisen, dass dieser Frame ein Typ-A-Frame ist und seine \u00dcberpr\u00fcfung gem\u00e4\u00df FARM durchgef\u00fchrt werden sollte. Der Wert \u201e1\u201c dieses Flags sollte dem Empf\u00e4nger signalisieren, dass dieser Frame ein Typ-B-Frame ist und die \u00dcberpr\u00fcfung gem\u00e4\u00df FARM umgangen werden sollte.<\/p>\n

      Dieses Flag informiert den Empf\u00e4nger dar\u00fcber, ob der Mechanismus zur Best\u00e4tigung der Frame-Lieferung verwendet werden muss, der als FARM \u2014 Frame Acceptance and Reporting Mechanism \u2014 bezeichnet wird.<\/i><\/p>\n

      Das Steuerbefehlsflag dient dazu zu verstehen, ob das Datenfeld einen Befehl oder Daten transportiert. Wenn das Flag den Wert \u201e0\u201c hat, sollte das Datenfeld Daten enthalten. Wenn das Flag den Wert \u201e1\u201c hat, sollte das Datenfeld Steuerinformationen f\u00fcr FARM enthalten.
      \nFARM ist ein konfigurierbarer Automat mit anpassbaren Parametern.<\/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 diese Bits bereits in der aktuellen Version des Standards reserviert hat.<\/i><\/p>\n

      Das Rahmenl\u00e4ngenfeld sollte eine Zahl im Bitformat enthalten, die der L\u00e4nge des Rahmens in Oktetten minus eins entspricht.<\/p>\n

      Das Datenfeld des Rahmens sollte unmittelbar nach dem Header ohne L\u00fccken folgen und eine ganze Anzahl von Oktetten enthalten, die maximal 1019 Oktetten lang sein kann. Dieses Feld sollte entweder einen Rahmen-Datenblock oder Steuerinformationen enthalten. Der Rahmen-Datenblock sollte Folgendes enthalten:<\/p>\n