🥇Einige Informationen zu Standards der Raumkommunikation

Meteor M1 Satellit
Quelle: vladtime.ru

Einführung

Der Betrieb von Weltraumtechnik ist ohne Funkkommunikation nicht möglich. In diesem Artikel möchte ich die grundlegenden Ideen erläutern, die den Standards zugrunde liegen, die vom Internationalen Beratenden Komitee für Raumdatenübertragungssysteme (Consultative Committee for Space Data Systems – CCSDS) entwickelt wurden. In der Folge wird diese Abkürzung verwendet.

Diese Veröffentlichung wird sich hauptsächlich mit der Kanalschicht befassen, jedoch werden auch grundlegende Konzepte für andere Ebenen eingeführt. Der Artikel erhebt in keiner Weise den Anspruch, eine vollständige und umfassende Beschreibung der Standards zu liefern. Diese können Sie auf Webseite CCSDS finden. Sie sind jedoch sehr schwer verständlich, und um sie zu begreifen, haben wir viel Zeit investiert. Daher möchte ich hier grundlegende Informationen präsentieren, die es einfacher machen, die restlichen Konzepte zu verstehen. Lassen Sie uns also beginnen.

Die edle Mission von CCSDS

Vielleicht fragt sich jemand: Warum sollten wir uns an Standards halten, wenn wir ein eigenes proprietäres Protokoll-Stack für die Funkkommunikation entwickeln könnten (oder unseren eigenen Standard, mit Blackjack und neuen Features), um die Sicherheit des Systems zu erhöhen?

Die Praxis zeigt, dass es aus mehreren Gründen vorteilhafter ist, sich an die CCSDS-Standards zu halten:

In das Komitee zur Veröffentlichung der Standards sind Vertreter aller großen Raumfahrtorganisationen weltweit berufen worden, die ihren unschätzbaren Erfahrungsschatz aus vielen Jahren der Planung und Durchführung verschiedenster Missionen einbringen. Es wäre äußerst unklug, diese Erfahrung zu ignorieren und dieselben Fehler erneut zu machen.
Diese Standards werden von bereits auf dem Markt vorhandenen Ausrüstungen der Bodenstationen unterstützt.
Bei der Behebung von Problemen kann jederzeit Hilfe von Kollegen in anderen Agenturen angefordert werden, die eine Verbindung mit dem Gerät von ihrer Bodenstation aus herstellen. Wie Sie sehen, sind Standards äußerst nützlich, also schauen wir uns ihre Schlüsselpunkte genauer an.

Architektur von

Die 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 „Downlink“ – Raum zu Erde) und Telecommands (der „Uplink“) beschränkt ist.

Lassen 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.

Physikalische Ebene

Auf dieser Ebene erfolgt die Umwandlung des modulierten Funksignals in einen Bitstrom. Die Standards sind hier überwiegend empfehlender Natur, da es auf dieser Ebene schwierig ist, sich von der spezifischen Implementierung der Hardware zu abstrahieren. Hier kommt dem CCSDS eine Schlüsselrolle zu – die zulässigen Modulationen (BPSK, QPSK, 8-QAM usw.) zu definieren und einige Empfehlungen für die Implementierung von Mechanismen zur symbolischen Synchronisierung, der Kompensation des Doppler-Effekts usw. zu geben.

Synchronisations- und Codierungsebene

Formell betrachtet ist es eine Unterebene der Kanalschicht, wird jedoch aufgrund seiner Bedeutung innerhalb der CCSDS-Standards häufig als eigenständige Ebene hervorgehoben. Diese Ebene wandelt den Bitstrom in sogenannte Frames (Telemetrie oder Telecommands) um, über die wir später sprechen werden. Im Gegensatz zur symbolischen Synchronisation auf der physikalischen Ebene, die einen korrekten Bitstrom gewährleistet, wird hier eine Frame-Synchronisation durchgeführt. Lassen Sie uns den Weg betrachten, den die Daten auf dieser Ebene (von unten nach oben) durchlaufen:

Bevor wir jedoch dazu kommen, ist es wichtig, ein paar Worte über die Kodierung zu verlieren. Diese Prozedur ist notwendig, um Bitfehler zu erkennen und/oder zu korrigieren, die unvermeidlich beim Übertragen von Daten über den Funkkanal auftreten. Hier werden wir die Dekodierungsverfahren nicht betrachten, sondern uns nur mit den Informationen beschäftigen, die erforderlich sind, um die weitere Logik der Funktionalität dieser Ebene zu verstehen.

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ören Faltungscodes (convolutional codes). Diese kodieren einen stetigen Bitstrom. Im Gegensatz zu blockbasierten Codes, bei denen Daten in Codeblöcke (codeblock) unterteilt werden und nur in Form vollständiger Blöcke dekodiert werden können. Ein Codeblock besteht aus den zu übertragenden Daten und den zusätzlichen Informationen, die zur Überprüfung der korrekten Datenempfang und zur Behebung möglicher Fehler erforderlich sind. Zu den blockbasierten Codes zählen die bekannten Reed-Solomon-Codes.

Wenn Faltungscodierung verwendet wird, wird der Bitstrom zu Beginn an den Dekoder weitergeleitet. Das Ergebnis seiner Arbeit (dies geschieht selbstverständlich kontinuierlich) sind CADU-Datenblöcke (channel access data unit). Diese Struktur ist erforderlich für die Rahmensynchronisation. Am Ende jeder CADU ist ein Synchronisationsmarker (ASM – attached synch marker) angehängt. Dies sind vier vordefinierte Bytes, mit denen der Synchronisator den Anfang und das Ende der CADU findet. So wird die Rahmensynchronisation erreicht.

Der nächste optionale Schritt in der Synchronisations- und Kodierungsstufe bezieht sich auf die Besonderheiten der physikalischen Ebene. Dies ist die Dérandomisierung. Um symbolische Synchronisation zu erreichen, sind häufige Wechsel zwischen den Symbolen erforderlich. Wenn wir beispielsweise ein Kilobyte an Daten übertragen, das ausschließlich aus Einsen besteht, wird die Synchronisation verloren gehen. Daher werden bei der Übertragung die Eingabedaten mit einer periodischen pseudo-zufälligen Sequenz gemischt, um eine gleichmäßige Verteilung von Nullen und Einsen zu gewährleisten.

Anschließend erfolgt die Dekodierung der Blockcodes, und das, was übrig bleibt, ist das Endprodukt der Synchronisations- und Kodierungsstufe – ein Frame.

Kanalebene

Einerseits erhält der Kanalverarbeiter die Frames, andererseits gibt er Pakete aus. Da die formale Größe der Pakete nicht begrenzt ist, müssen sie für eine zuverlässige Übertragung in kleinere Strukturen – Frames – unterteilt werden. Hier betrachten wir zwei Unterabschnitte: einen für Telemetrie (TM) und einen für Telekommandos (TC).

Telemetrie

Einfach ausgedrückt sind das die Daten, die die Bodenkontrollstation vom Raumfahrzeug erhält. Alle übermittelten Informationen werden in kleine, feste Längen zerlegt – in Frames, die die übertragenen Daten und Steuerfelder enthalten. Lassen Sie uns die Struktur eines Frames näher betrachten:

Wir beginnen mit dem Haupt-Header des Telemetrie-Frames. An dieser Stelle erlaube ich mir, die Standards teilweise direkt zu übersetzen und gleichzeitig einige Erklärungen zu geben.

Das Feld für die Hauptkanal-ID (Master Channel ID) muss die Versionsnummer des Frames und die Identifikationsnummer des Gerätes enthalten.

Jeder Knoten, gemäß den CCSDS-Standards, muss eine eindeutige Kennung haben, anhand derer festgestellt werden kann, zu welchem Gerät er gehört. Formell muss ein Antrag auf Registrierung des Geräts eingereicht werden, und dessen Name sowie die Kennung werden in öffentlichen Quellen veröffentlicht. Oft ignorieren jedoch russische Hersteller dieses Verfahren und weisen dem Gerät willkürlich 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 „0“.

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änkungen bei der Auswahl der VCID; insbesondere müssen virtuelle Kanäle nicht zwingend fortlaufend nummeriert werden.

Sehr oft besteht die Notwendigkeit, die übertragenen Daten zu multiplexen. Dafür gibt es einen Mechanismus für virtuelle Kanäle. Zum Beispiel überträgt der Satellit Meteor-M2 ein farbiges Bild im sichtbaren Bereich, indem es in drei schwarz-weiße Bilder aufgeteilt wird – jede Farbe wird in ihrem eigenen virtuellen Kanal als separates Paket übertragen, obwohl es in der Struktur seiner Frames einige Abweichungen von den Standards gibt.

Das Feld für das Flagge Operational Control sollte einen Indikator für das Vorhandensein oder Fehlen des Feldes Operational Control im Telemetrie-Frame darstellen. Diese 4 Bytes am Ende des Frames dienen der Unterstützung des Feedbacks bei der Kontrolle der Lieferung von Telemetrie-Frames. Darüber werden wir später sprechen.

Die Zähler für den Haupt- und den virtuellen Kanal sind Felder, die bei der Übertragung jedes Frames um eins erhöht werden. Sie dienen als Indikator dafür, dass kein Frame verloren gegangen ist.

Der Status der Daten im Telemetrie-Frame besteht aus zwei weiteren Bytes für Flags und Daten, wobei wir nur einige davon betrachten werden.

Das Feld für das Flag des zusätzlichen Headers (Secondary Header) sollte einen Indikator für das Vorhandensein oder Fehlen eines zusätzlichen Headers (Secondary Header) im Telemetrie-Frame darstellen.

Optional can be added to each frame, an additional header, where you can place any data at your discretion.

Das Feld für den Zeiger auf den ersten Header (First Header Pointer) muss, wenn das Synchronisierungsflag auf "1" gesetzt ist, die binäre 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ählt. Wenn im Datenfeld des Telemetrie-Frames kein Paketbeginn vorhanden ist, sollte das Feld für den Zeiger auf den ersten Header den binären Wert „11111111111“ haben (das kann vorkommen, wenn ein langes Paket sich über mehrere Frames erstreckt).

Wenn das Datenfeld jedoch ein leeres Paket (Idle Data) enthält, sollte der Zeiger auf den ersten Header den binären Wert „11111111110“ aufweisen. Anhand dieses Feldes sollte der Empfänger die Synchronisierung des Streams durchführen. Dieses Feld gewährleistet die Wiederherstellung der Synchronisierung, selbst wenn Frames übersprungen werden.

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änge vermerkt ist. Daher muss der Kanal-Handler beim Finden des Zeigers auf den ersten Header diesen lesen, um festzustellen, wo das Paket endet.
Wenn das Fehlerkontrollfeld vorhanden ist, muss es in jedem Frame der Telemetrie für einen bestimmten physikalischen Kanal während der gesamten Mission enthalten sein.

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ügen.

Telekommandos

Der Frame der Telekommandos weist mehrere wesentliche Unterschiede auf. Dazu gehören:

Eine andere Struktur der Header
Dynamische Länge. Das bedeutet, dass die Länge des Frames nicht starr festgelegt ist, wie es in der Telemetrie der Fall ist, sondern je nach übertragenen Paketen variieren kann.
Der Mechanismus zur Paketliefergarantie. Das heißt, der KAM muss nach dem Erhalt die Korrektheit des Empfangs der Frames bestätigen oder die Übermittlung vom Frame anfordern, der möglicherweise mit einem nicht korrigierbaren Fehler angenommen wurde.

Viele 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.

Ein Bit des Umgehungsflags sollte verwendet werden, um die Überprüfung der Frames am Empfänger zu steuern. Der Wert „0“ dieses Flags sollte darauf hinweisen, dass dieser Frame ein Typ-A-Frame ist und seine Überprüfung gemäß FARM durchgeführt werden sollte. Der Wert „1“ dieses Flags sollte dem Empfänger signalisieren, dass dieser Frame ein Typ-B-Frame ist und die Überprüfung gemäß FARM umgangen werden sollte.

Dieses Flag informiert den Empfänger darüber, ob der Mechanismus zur Bestätigung der Frame-Lieferung verwendet werden muss, der als FARM — Frame Acceptance and Reporting Mechanism — bezeichnet wird.

Das Steuerbefehlsflag dient dazu zu verstehen, ob das Datenfeld einen Befehl oder Daten transportiert. Wenn das Flag den Wert „0“ hat, sollte das Datenfeld Daten enthalten. Wenn das Flag den Wert „1“ hat, sollte das Datenfeld Steuerinformationen für FARM enthalten.
FARM ist ein konfigurierbarer Automat mit anpassbaren Parametern.

RSVD. SPARE – reservierte Bits.

Es scheint, dass CCSDS in Zukunft Pläne dafür hat und zur Rückwärtskompatibilität der Protokollversionen diese Bits bereits in der aktuellen Version des Standards reserviert hat.

Das Rahmenlängenfeld sollte eine Zahl im Bitformat enthalten, die der Länge des Rahmens in Oktetten minus eins entspricht.

Das Datenfeld des Rahmens sollte unmittelbar nach dem Header ohne Lücken 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:

eine ganze Anzahl von Oktetten an Nutzdaten
den Segmentheader und anschließend eine ganze Anzahl von Oktetten an Nutzdaten

Wenn ein Header vorhanden ist, muss der Datenblock ein Paket, mehrere Pakete oder einen Teil davon enthalten. Ein Datenblock ohne Header kann keine Teile von Paketen enthalten, wohl aber Datenblöcke eines privaten Formats. Dies bedeutet, dass ein Header erforderlich ist, wenn der übertragene Datenblock nicht in ein einziges Paket passt. Ein Datenblock mit Header wird als Segment bezeichnet.

Das 2-Bit-Flagsfeld muss Folgendes enthalten:

„01“ – wenn der erste Teil der Daten im Datenblock enthalten ist
„00“ – wenn der mittlere Teil der Daten im Datenblock enthalten ist
„10“ – wenn der letzte Teil der Daten im Datenblock enthalten ist
„11“ – wenn keine Aufteilung erfolgt und ein oder mehrere Pakete vollständig im Datenblock enthalten sind.

Das MAP-Identifikationsfeld sollte Nullen enthalten, wenn die MAP-Kanäle nicht verwendet werden.
Manchmal sind die 6 Bits, die für virtuelle Kanäle vorgesehen sind, nicht ausreichend. Und wenn die Daten auf eine größere Anzahl von Kanälen multiplexiert werden müssen, werden weitere 6 Bits aus dem Segment-Header verwendet.

FARM

Lassen Sie uns detaillierter auf die Funktionsweise des Systems zur Kontrolle der Datenübertragung eingehen. Dieses System ist ausschließlich für den Umgang mit Kommunikationsrahmen konzipiert, da deren Wichtigkeit stark ist (Telemetriedaten können jederzeit erneut angefordert werden, während das Raumfahrzeug die Bodenstation klar hören und stets deren Befehlen gehorchen muss). Angenommen, wir haben beschlossen, unseren Satelliten neu zu programmieren, und senden eine Binärdatei von 10 Kilobyte an Bord. Auf der Netzwerkebene wird die Datei in 10 Rahmen (0, 1, …, 9) aufgeteilt, die nacheinander nach oben gesendet werden. Wenn die Übertragung abgeschlossen ist, muss das Raumfahrzeug den Empfang des Pakets bestätigen oder angeben, bei welchem Rahmen ein Fehler aufgetreten ist. Diese Informationen werden im nächsten Rahmen der Telemetriedaten im operativen Kontrollfeld gesendet (oder das Raumfahrzeug kann die Übertragung eines leeren Rahmens einleiten, wenn es nichts zu sagen hat). Anhand der erhaltenen Telemetrie stellen wir entweder fest, dass alles in Ordnung ist, oder wir beginnen mit der erneuten Übertragung der Nachricht. Angenommen, der Satellit hat Rahmen Nr. 7 nicht empfangen. Dann senden wir ihm die Rahmen 7, 8, 9. Sollte keine Antwort eintreffen, wird das gesamte Paket erneut gesendet (und so weiter, bis wir feststellen, dass unsere Versuche vergeblich sind).

Nachfolgend finden Sie den Struktur eines operativen Kontrollfeldes mit einer Beschreibung einiger Felder. Die in diesem Feld enthaltenen Daten werden als CLCW – Communication Link Control Word bezeichnet.

Da man aus dem Bild ziemlich gut auf die Funktion der Hauptfelder schließen kann und die anderen etwas langweilig sind, verstecke ich die detaillierte Beschreibung unter einem Spoiler.

Dekodierung der CLCW-FelderTyp des Kontrollworts (Control Word Type):
Für diesen Typ des Kontrollworts sollte der Wert 0 enthalten sein.

Version des Kontrollworts (CLCW Version Number):
Für diesen Typ des Kontrollworts muss der Wert "00" in der Bitdarstellung betragen.

Statusfeld (Status Field):
Die Verwendung dieses Feldes wird für jede Mission separat festgelegt. Es kann von verschiedenen Raumfahrtbehörden für lokale Verbesserungen genutzt werden.

Identifikator des virtuellen Kanals (Virtual Channel Identification):
Sollte den Identifikator des virtuellen Kanals enthalten, mit dem dieses Kontrollwort verbunden ist.

Zugriffsflagge auf den physischen Kanal:
Das Flag sollte Informationen über die Bereitschaft der physikalischen Empfangsebene bereitstellen. Wenn die physikalische Empfangsebene nicht bereit ist, Frames zu empfangen, sollte das Feld "1" enthalten, andernfalls "0".

Synchronisationsfehler-Flag:
Dieses Flag kann darauf hinweisen, dass die physische Ebene bei schlechtem Signalpegel arbeitet und die Anzahl der verworfenen Frames zu hoch ist. Die Verwendung dieses Feldes ist optional; wenn es verwendet wird, sollte es '0' bei bestehender Synchronisation und '1' bei fehlender Synchronisation enthalten.

Blockierungsflag:
Dieses Bit sollte den Status der FARM-Sperrung für jeden virtuellen Kanal enthalten. Ein Wert von '1' in diesem Feld sollte anzeigen, dass die FARM gesperrt ist und Frames für jede virtuelle Ebene verworfen werden, andernfalls '0'.

Warteflag:
Dieses Bit sollte genutzt werden, um anzuzeigen, dass der Empfänger den angegebenen virtuellen Kanal nicht verarbeiten kann. Ein Wert von '1' zeigt an, dass alle Frames auf diesem virtuellen Kanal verworfen werden, andernfalls '0'.

Weiterleitungsflag:
Dieses Flag sollte '1' enthalten, wenn ein oder mehrere Frames vom Typ A verworfen wurden oder Lücken gefunden wurden, die eine Weiterleitung erforderlich machen. Das Flag '0' zeigt an, dass keine Frames verworfen und keine Lücken vorhanden waren.

Antwortwert:
Die Frame-Nummer, die nicht akzeptiert wurde. Bestimmt anhand des Zählers im Header des Telekommando-Frames.

Netzwerkschicht

Lassen Sie uns auch diese Ebene kurz ansprechen. Hier gibt es zwei Möglichkeiten: Entweder das Raumprotokoll verwenden oder ein beliebiges anderes Protokoll in ein CCSDS-Paket kapseln.

Eine Übersicht über das Raumprotokoll ist ein Thema für einen eigenen Artikel. Es wurde entwickelt, damit sogenannte Anwendungen nahtlos Daten austauschen können. Jede Anwendung hat ihre eigene Adresse und eine grundlegende Funktionalität für den Datenaustausch mit anderen Anwendungen. Zudem gibt es Dienste, die den Datenverkehr routieren, die Lieferung überwachen usw.

Die Kapselung ist simpler und verständlicher. Die Standards ermöglichen die Kapselung beliebiger Protokolle in CCSDS-Pakete, indem ein zusätzlicher Header hinzugefügt wird.

Der Header hat verschiedene Bedeutungen, abhängig von der Länge des kapselnden Protokolls:

Hier ist das Hauptfeld – die Länge. Sie kann von 0 bis 4 Byte variieren. In diesem Header muss zudem der Typ des kapselten Protokolls angegeben werden, mithilfe einer Tabelle. hier herunter.

Bei der IP-Einkapselung wird eine weitere Schicht verwendet, um den Pakettyp zu bestimmen.
Es muss ein weiterer Header mit einer Länge von mindestens einem Oktett hinzugefügt werden:

Dabei steht PID für einen weiteren Protokollbezeichner, der entnommen wurde hier herunter

Fazit

Auf den ersten Blick mag es scheinen, dass die CCSDS-Header äußerst redundant sind und einige Felder weggelassen werden könnten. Tatsächlich beträgt die Effizienz des resultierenden Kanals (bis zur Netzwerkschicht) etwa 40%. Sobald jedoch die Notwendigkeit besteht, diese Standards umzusetzen, wird deutlich, dass jedes Feld, jeder Header seine eigene wichtige Aufgabe hat, deren Ignorierung zu einer Vielzahl von Mehrdeutigkeiten führt.

Wenn die Habr-Community Interesse an diesem Thema zeigt, würde ich mich freuen, eine Reihe weiterer Artikel zu veröffentlichen, die sich mit der Theorie und Praxis der Raumkommunikation befassen. Vielen Dank für Ihre Aufmerksamkeit!