🥇Ein wenig über Standards der Raumkommunikation

Meteor M1 Satellit
Quelle: vladtime.ru

Einführung

Der Betrieb von Raumfahrzeugen ist ohne Funkkommunikation unmöglich, und in diesem Artikel werde ich versuchen, die grundlegenden Ideen zu erklären, die das Fundament der Standards bilden, die vom Internationalen Beratenden Komitee für Datenübermittlung im Weltraum (Consultative Committee for Space Data Systems – CCSDS) entwickelt wurden. Diese Abkürzung wird im Folgenden verwendet.

Diese Veröffentlichung wird hauptsächlich dem Kanallniveau gewidmet sein, jedoch werden auch die grundlegenden Begriffe für andere Ebenen eingeführt. Der Artikel erhebt in keiner Weise den Anspruch auf eine vollständige und umfassende Beschreibung der Standards. Sie können sich über diese informieren auf Website CCSDS. Allerdings sind sie sehr komplex zu verstehen, und um sie zu durchdringen, haben wir viel Zeit investiert. Daher möchte ich hier grundlegende Informationen bereitstellen, die es viel einfacher machen, alles andere zu verstehen. Lassen Sie uns also beginnen.

Ehrwürdige Mission des CCSDS

Vielleicht stellt sich jemand die Frage: Warum sollten sich alle an Standards halten, wenn man auch sein eigenes proprietäres Protokoll-Stack für die Funkkommunikation entwickeln kann (oder seinen eigenen Standard, mit einem Blackjack und neuen Funktionen), um die Sicherheit des Systems zu erhöhen?

Erfahrungen haben gezeigt, dass es vorteilhafter ist, sich an die CCSDS-Standards zu halten, aus den folgenden Gründen:

Im Komitee, das für die Veröffentlichung der Standards verantwortlich ist, sind Vertreter aller großen Luft- und Raumfahrtagenturen der Welt vertreten, die ihre wertvollen Erfahrungen aus vielen Jahren der Planung und des Betriebs verschiedener Missionen einbringen. Es wäre sehr unklug, diese Erfahrungen zu ignorieren und immer wieder die gleichen Fehler zu machen.
Diese Standards werden von bereits auf dem Markt verfügbaren Anlagen für Bodenstationen unterstützt.
Wenn es während der Fehlersuche zu Problemen kommt, kann man sich immer an Kollegen aus anderen Agenturen wenden, die eine Verbindung zum Gerät von ihrer Bodenstation aus herstellen können. Wie Sie sehen, sind Standards äußerst nützlich, also lassen Sie uns die wichtigsten Punkte erörtern.

Architektur

Die Standards stellen eine Sammlung von Dokumenten dar, die das ganz gewöhnliche OSI-Modell (Open System Interconnection) widerspiegeln, mit der Ausnahme, dass auf der kanalen Ebene die Allgemeinheit auf die Trennung zwischen Telemetrie (Abwärtskanal – Raum – Erde) und Telecommands (Aufwärtskanal) beschränkt ist.

Betrachten wir einige Ebenen genauer, beginnend mit der physikalischen und aufwärts. Um mehr Anschaulichkeit zu bieten, betrachten wir die Architektur der empfangenden Seite. Die übertragende Seite ist deren Spiegelbild.

Physikalische Schicht

Auf 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üsselrolle – es geht darum, zulässige Modulationen (BPSK, QPSK, 8-QAM usw.) zu definieren und einige Empfehlungen zur Implementierung von Mechanismen zur symbolischen Synchronisation, Dopplerverschiebungskompensation usw. zu geben.

Ebene der Synchronisation und Kodierung

Formal ist sie ein Unterlevel der Datenlink-Ebene, wird jedoch häufig aufgrund ihrer Wichtigkeit innerhalb der CCSDS-Standards als separate Ebene betrachtet. Diese Ebene verwandelt den Bitstrom in sogenannte Rahmen (Telemetrie oder Telekommando), über die wir später sprechen werden. Im Gegensatz zur symbolischen Synchronisation auf der physikalischen Ebene, die einen korrekten Bitstrom ursprünglich ermöglicht, erfolgt hier die Rahmen-Synchronisation. Lassen Sie uns den Weg betrachten, den die Daten auf dieser Ebene zurücklegen (von unten nach oben):

Bevor wir dies tun, wollen wir ein paar Worte über die Kodierung verlieren. Dieses Verfahren ist notwendig, um Bitfehler zu finden und/oder zu korrigieren, die unvermeidlich bei der Datenübertragung über ein Funkkanal auftreten. Hier werden wir die Dekodierverfahren nicht betrachten, sondern nur die Informationen erhalten, die für das Verständnis der weiteren Logik der Funktionalität der Ebene erforderlich sind.

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ählen faltenbasierte (convolutional) Codes. Diese dienen zur Kodierung eines kontinuierlichen Bitstroms. Im Gegensatz zu Blockcodes, bei denen die Daten in Codeblöcke unterteilt werden und nur innerhalb ganzer Blöcke dekodiert werden können. Ein Codeblock besteht aus den übertragbaren Daten und den angehängten redundanten Informationen, die zur Überprüfung der Korrektheit des Erhalts der Daten und zur Behebung möglicher Fehler erforderlich sind. Zu den Blockcodes gehören die berühmten Reed-Solomon-Codes.

Wenn die Faltungscodierung verwendet wird, gelangt der Bitstrom von Anfang an zum Dekoder. Das Ergebnis seiner Arbeit (alles passiert natürlich kontinuierlich) sind CADU-Datenblöcke (channel access data unit). Diese Struktur ist für die Rahmen-Synchronisation notwendig. Am Ende jedes CADU ist ein Synchronisationsmarker (ASM – angehängter Synchronisationsmarker) angefügt. Dies sind bekannt vorausgesetzte 4 Byte, anhand derer der Synchronisierer den Anfang und das Ende von CADU findet. So wird die Rahmen-Synchronisation erreicht.

Der nächste optionale Arbeitsschritt der Synchronisations- und Codierungsebene ist mit den Besonderheiten der physikalischen Ebene verbunden. Dies ist die Deraudomisierung. Der Grund dafür ist, dass für die Erreichung der symbolischen Synchronisation häufige Umschaltungen zwischen den Symbolen erforderlich sind. Wenn wir beispielsweise ein Kilobyte an Daten übertragen, das ausschließlich aus Einsen besteht, wird die Synchronisation verloren gehen. Daher werden die Eingabedaten während der Übertragung mit einer periodischen pseudorandomisierten Sequenz vermischt, damit die Dichte von Nullen und Einsen gleichmäßig ist.

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

Kanalebene

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

Telemetrie

Kurz gesagt, das sind die Daten, die die Bodenstation vom Satelliten erhält. Alle übertragenen Informationen werden in kleine Fragmente fester Länge – Rahmen – aufgeteilt, die die übertragenen Daten und Steuerfelder enthalten. Lassen Sie uns die Struktur des Rahmens näher betrachten:

Und beginnen wir mit dem Hauptheader des Telemetrierahmens. Ich werde mir in einigen Bereichen erlauben, die Standards einfach zu übersetzen und dabei einige Erklärungen zu geben.

Das Feld für die Identifikation des Hauptkanals (Master Channel ID) sollte die Versionsnummer des Rahmens und die Identifikation des Geräts enthalten.

Jeder KA sollte gemäß den CCSDS-Standards eine eindeutige Kennung haben, anhand derer man, wenn man einen Frame hat, bestimmen kann, welchem Gerät er gehört. Formell ist es notwendig, einen Antrag zur Registrierung des Geräts einzureichen, und dessen Name wird zusammen mit der Kennung in offenen Quellen veröffentlicht. Dennoch ignorieren oft russische Hersteller dieses Verfahren und vergeben zufällige Kennungen an das Gerät. 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 „0“.

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

Sehr häufig besteht die Notwendigkeit, die übertragenen Daten zu multiplexen. Zu diesem Zweck gibt es einen Mechanismus virtueller Kanäle. Zum Beispiel überträgt der Satellit Meteor-M2 ein Farbbild im sichtbaren Bereich, indem es es in drei Schwarz-Weiß-Bilder aufteilt – jede Farbe wird in ihrem eigenen virtuellen Kanal als separates Paket übertragen, obwohl die Struktur seiner Frames eine gewisse Abweichung von den Standards aufweist.

Das Feld des Flags für die operationale Kontrolle sollte ein Indikator für das Vorhandensein oder Fehlen des Feldes für die operationale Kontrolle im Telemetrie-Frame sein. Diese 4 Bytes am Ende des Frames dienen der Aufrechterhaltung der Rückmeldung bei der Kontrolle der Lieferung von Telecommands. Darüber werden wir später sprechen.

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

Der Status der Telemetriedatenframe ist noch zwei Bytes Flags und Daten, von denen wir nur einige betrachten werden.

Das Feld des Flags für den zusätzlichen Header (Secondary Header) sollte ein Indikator für das Vorhandensein oder Fehlen eines zusätzlichen Headers im Telemetrie-Frame sein.

Auf Wunsch kann zu jedem Frame ein zusätzlicher Header hinzugefügt werden, in dem alle Daten nach eigenem Ermessen platziert werden.

Das Feld für den Zeiger auf die erste Kopfzeile (First Header Pointer) muss, bei einem Synchronisierungsflag von „1“, die binäre 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ählt. Wenn es keinen Beginn des Pakets im Datenfeld des Telemetrie-Frames gibt, muss das Feld für den Zeiger auf die erste Kopfzeile den Wert in der binären Darstellung „11111111111“ haben (dies kann vorkommen, wenn ein langes Paket sich über mehr als einen Frame erstreckt).

Wenn jedoch im Datenfeld ein leeres Paket (Idle Data) enthalten ist, muss der Zeiger auf die erste Kopfzeile den Wert in der binären Darstellung „11111111110“ haben. Das Empfangsgerät sollte anhand dieses Feldes den Datenstrom synchronisieren. Dieses Feld gewährleistet die Wiederherstellung der Synchronisation, selbst bei Frames, die ausgelassen wurden.

Das heißt, 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änge festgelegt ist, daher muss der Verarbeiter des Link-Layers den Zeiger auf die erste Kopfzeile lesen, um festzustellen, wo das Paket endet.
Wenn das Fehlerkontrollfeld vorhanden ist, muss es in jedem Telemetrie-Frame für einen bestimmten physikalischen Kanal während der gesamten Mission enthalten sein.

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

Telemetrie-Befehle

Der Frame der Telemetrie-Befehle weist einige wesentliche Unterschiede auf. Dazu gehören:

Eine andere Struktur der Kopfzeilen
Dynamische Länge. Das bedeutet, dass die Länge des Frames nicht festgelegt ist, wie es bei der Telemetrie der Fall ist, sondern je nach übertragenen Paketen variieren kann.
Ein Mechanismus zur Gewährleistung der Zustellung von Paketen. Das heißt, das Raumfahrzeug muss den Erhalt der Frames bestätigen oder die erneute Übertragung vom Frame anfordern, der mit einem nicht korrigierbaren Fehler empfangen worden sein könnte.

Viele Felder sind uns bereits aus dem Kopf des Telemetrie-Frames bekannt. Sie haben dieselbe Funktion, daher betrachten wir hier nur die neuen Felder.

Ein Bit des Flagge für die Umgehung sollte zur Kontrolle der Überprüfung der Frames am Empfänger verwendet werden. Der Wert „0“ dieses Flags sollte anzeigen, dass dieses Frame vom Typ A ist und seine Überprüfung gemäß FARM erfolgen sollte. Der Wert „1“ dieses Flags sollte dem Empfänger anzeigen, dass dieses Frame vom Typ B ist und die Überprüfung gemäß FARM umgangen werden sollte.

Dieses Flag informiert den Empfänger, ob der Mechanismus zur Bestätigung der Frame-Zustellung, bekannt als FARM – Frame Acceptance and Reporting Mechanism, verwendet werden soll.

Das Steuerungsflag sollte genutzt werden, um zu verstehen, ob das Datenfeld einen Befehl oder Daten transportiert. Wenn das Flag gleich „0“ ist, sollte das Datenfeld Daten enthalten. Wenn das Flag gleich „1“ ist, sollte das Datenfeld Kontrollinformationen für FARM enthalten.
FARM ist ein endlicher Automat, dessen Parameter konfiguriert werden können.

RSVD. SPARE – reservierte Bits.

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

Das Feld für die Länge der Frames sollte eine Zahl im Bitformat enthalten, die der Länge des Frames in Oktetten minus eins entspricht.

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:

eine Ganzzahl an Benutzerdaten-Oktetten
den Segmentheader und darauf folgend eine Ganzzahl an Benutzerdaten-Oktetten

Wenn der Header vorhanden ist, sollte der Datenblock ein Paket, eine Menge von Paketen oder einen Teil davon enthalten. Ein Datenblock ohne Header kann keine Teile von Paketen enthalten, kann jedoch Datenblöcke eines privaten Formats enthalten. Daraus folgt, dass ein Header erforderlich ist, wenn der übertragene Datenblock nicht in ein Frame passt. Ein Datenblock mit einem Header wird als Segment bezeichnet.

Das Feld für die Flags mit einer Größe von zwei Bits sollte Folgendes enthalten:

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

Das MAP-Identifierfeld muss Nullen enthalten, wenn die MAP-Kanäle nicht verwendet werden.
Manchmal sind 6 Bit, die für virtuelle Kanäle reserviert sind, nicht ausreichend. Und wenn es notwendig ist, Daten auf eine größere Anzahl von Kanälen zu multiplexen, kommen weitere 6 Bit aus dem Segment-Header zum Einsatz.

FARM

Betrachten wir eingehender den Mechanismus der Funktionsweise des Systems zur Überwachung der Bildübertragung. Dieses System sieht ausschließlich die Arbeit mit den Rahmen der Telekommando aufgrund ihrer Wichtigkeit vor (Telemetrie kann immer wieder angefordert werden, aber der Satellit muss die Bodenstation klar hören und immer ihren Kommandos gehorchen). Angenommen, wir haben uns entschieden, unseren Satelliten neu zu flashen, und senden eine Binärdatei mit einer Größe von 10 Kilobyte an Bord. Auf der Ebene des Datenkanals wird die Datei in 10 Frames (0, 1, …, 9) unterteilt, die nacheinander nach oben gesendet werden. Wenn die Übertragung abgeschlossen ist, muss der Satellit den Empfang des Pakets bestätigen oder melden, bei welchem Frame ein Fehler aufgetreten ist. Diese Informationen werden im Feld der operativen Kontrolle im nächsten Frame der Telemetrie gesendet (oder der Satellit kann die Übertragung eines leeren Frames (idle frame) initiieren, wenn er nichts zu sagen hat). Anhand der erhaltenen Telemetrie stellen wir fest, ob alles in Ordnung ist oder ob wir mit dem erneuten Senden der Nachricht beginnen. Angenommen, der Satellit hat Frame Nr. 7 nicht gehört. Dann senden wir ihm die Frames 7, 8, 9. Falls keine Antwort erfolgt, wird das Paket nochmal vollständig gesendet (und so weiter, bis wir verstehen, dass die Versuche vergeblich sind).

Im Folgenden finden Sie die Struktur des operativen Kontrollfelds mit einer Beschreibung einiger Felder. Die in diesem Feld enthaltenen Daten werden CLCW – Communication Link Control Word – genannt.

Da man anhand des Bildes gut auf die Funktion der Hauptfelder schließen kann und das Betrachten der anderen langweilig ist, verstecke ich die detaillierte Beschreibung unter einem Spoiler.

Dekodierung der Felder CLCWTyp des Kontrollworts (Control Word Type):
Für diesen Typ des Kontrollworts muss 0 enthalten sein.

Version des Kontrollworts (CLCW Version Number):
Für diesen Typ des Kontrollworts muss „00“ im bitweisen Format lauten.

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

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

Zugriffssignal für den physischen Kanal:
Das Signal sollte Informationen über die Einsatzbereitschaft der physischen Ebene des Empfängers bereitstellen. Wenn die physische Ebene des Empfängers nicht bereit ist, Bilder zu empfangen, sollte das Feld '1' enthalten, andernfalls '0'.

Synchronisationsfehler-Signal:
Das Signal kann anzeigen, dass die physische Ebene bei schlechtem Signalpegel arbeitet und die Anzahl der abgelehnten Bilder zu hoch ist. Die Verwendung dieses Feldes ist optional; wenn es verwendet wird, sollte es '0' bei vorhandener Synchronisation und '1' bei nicht vorhandener Synchronisation enthalten.

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

Warte-Signal:
Dieses Bit sollte verwendet werden, um anzuzeigen, dass der Empfänger das aktuelle Bild auf dem angegebenen virtuellen Kanal nicht verarbeiten kann. Der Wert '1' zeigt an, dass alle Bilder auf diesem virtuellen Kanal verworfen werden, andernfalls '0'.

Weiterleitungsflag:
Dieses Flag sollte '1' enthalten, wenn ein oder mehrere Bilder vom Typ A verworfen oder Lücken festgestellt wurden, daher ist eine Weiterleitung erforderlich. Das Flag '0' zeigt an, dass keine Bilder verworfen wurden und keine Lücken vorhanden sind.

Antwortwert:
Nummer des nicht akzeptierten Bildes. Bestimmt durch den Zähler im Header des Telecommands.

Netzwerkschicht

Lass uns auch diese Ebene kurz ansprechen. Hier gibt es zwei Möglichkeiten: entweder das Protokoll des Raumdatenpakets zu verwenden oder ein anderes Protokoll in ein CCSDS-Paket zu kapseln.

Ein Überblick über das Protokoll des Raumdatenpakets ist ein Thema für einen separaten Artikel. Es wurde geschaffen, damit sogenannte Anwendungen nahtlos Daten austauschen können. Jede Anwendung hat ihre eigene Adresse und grundlegende Funktionalitäten zum Austausch von Daten mit anderen Anwendungen. Es gibt auch Dienste, die den Datenverkehr routieren und die Zustellung überwachen.

Die Kapselung ist einfacher und klarer. Die Standards ermöglichen die Kapselung beliebiger Protokolle in CCSDS-Paketen durch Hinzufügen eines zusätzlichen Headers.

Wo der Header je nach Länge des gekapselten Protokolls unterschiedliche Bedeutungen hat:

Hier ist das Hauptfeld die Längenlänge. Sie kann zwischen 0 und 4 Byte variieren. Außerdem muss in diesem Header der Typ des gekapselten Protokolls angegeben werden, mithilfe der Tabelle von hier.

Bei der Kapselung von IP wird eine weitere Schicht verwendet, um den Typ des Pakets zu bestimmen.
Es ist notwendig, einen weiteren Header hinzuzufügen, der von einem Oktett lang ist:

Wo PID – eine weitere Protokollkennung ist, die entnommen wird von hier

Fazit

Auf den ersten Blick mag es scheinen, dass die CCSDS-Header äußerst überladen sind und einige Felder weggelassen werden könnten. Tatsächlich liegt die Effizienz des resultierenden Kanals (bis zur Netzebene) bei etwa 40 %. Sobald jedoch der Bedarf besteht, diese Standards umzusetzen, wird klar, dass jedes Feld, jeder Header seine wichtige Aufgabe hat, deren Ignorierung zu einer Reihe von Mehrdeutigkeiten führt.

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