Meteor-M1-Satellit
Quelle: vladtime.ru
Einführung
Der Betrieb der Weltraumtechnologie ist ohne Funkkommunikation unmöglich, und in diesem Artikel werde ich versuchen, die Hauptideen zu erläutern, die die Grundlage der vom International Advisory Committee for Space Data Systems (CCSDS) entwickelten Standards bildeten. Diese Abkürzung wird im Folgenden verwendet. .
Dieser Beitrag konzentriert sich hauptsächlich auf die Datenverbindungsschicht, es werden jedoch auch grundlegende Konzepte für andere Schichten vorgestellt. Dieser Artikel erhebt in keiner Weise den Anspruch, eine gründliche und vollständige Beschreibung der Standards zu sein. Sie können es unter einsehen CCSDS. Allerdings sind sie sehr schwer zu verstehen und wir haben viel Zeit damit verbracht, sie zu verstehen. Deshalb möchte ich hier grundlegende Informationen bereitstellen, mit denen es viel einfacher ist, alles andere zu verstehen. Also, fangen wir an.
Edle Mission von CCSDS
Vielleicht hat jemand eine Frage: Warum sollte sich jeder an Standards halten, wenn man seinen eigenen proprietären Funkprotokoll-Stack (oder seinen eigenen Standard mit Blackjack und neuen Funktionen) entwickeln und so die Sicherheit des Systems erhöhen kann?
Wie die Praxis zeigt, ist es aus folgenden Gründen rentabler, sich an CCSDS-Standards zu halten:
- Dem für die Veröffentlichung der Standards zuständigen Komitee gehören Vertreter aller großen Luft- und Raumfahrtbehörden der Welt an, die unschätzbare Erfahrungen aus vielen Jahren der Planung und Durchführung verschiedener Missionen mitbringen. Es wäre völlig absurd, diese Erfahrung zu ignorieren und erneut auf ihren Rechen zu treten.
- Diese Standards werden von bereits auf dem Markt erhältlichen Bodenstationsgeräten unterstützt.
- Bei der Behebung von Problemen können Sie sich jederzeit an Kollegen anderer Behörden wenden, damit diese von ihrer Bodenstation aus eine Kommunikationssitzung mit dem Gerät durchführen können. Wie Sie sehen, sind Standards eine äußerst nützliche Sache. Schauen wir uns also ihre wichtigsten Punkte an.
Architektur
Bei den Standards handelt es sich um eine Reihe von Dokumenten, die das gängigste OSI-Modell (Open System Interconnection) widerspiegeln, mit der Ausnahme, dass sich die Gemeinsamkeit auf Datenverbindungsebene auf die Unterteilung in Telemetrie (Downlink – Weltraum – Erde) und Telekommunikation (Uplink) beschränkt.
Schauen wir uns einige der Ebenen genauer an, beginnend mit der physischen Ebene und dann weiter nach oben. Zur besseren Übersicht betrachten wir die Architektur der Empfangsseite. Das Übertragende ist sein Spiegelbild.
Physikalische Schicht
Auf dieser Ebene wird das modulierte Funksignal in einen Bitstrom umgewandelt. Die Standards haben hier überwiegend beratenden Charakter, da es auf dieser Ebene schwierig ist, von der konkreten Implementierung der Hardware zu abstrahieren. Hier besteht die Schlüsselrolle von CCSDS darin, die akzeptablen Modulationen (BPSK, QPSK, 8-QAM usw.) zu definieren und einige Empfehlungen zur Implementierung von Symbolsynchronisationsmechanismen, Doppler-Kompensation usw. zu geben.
Synchronisierungs- und Codierungsebene
Formal handelt es sich um eine Unterschicht der Datenverbindungsschicht, wird jedoch aufgrund ihrer Bedeutung innerhalb der CCSDS-Standards häufig in eine separate Schicht aufgeteilt. Diese Schicht wandelt den Bitstrom in sogenannte Frames (Telemetrie oder Telecommands) um, über die wir später sprechen werden. Im Gegensatz zur Symbolsynchronisierung auf der physikalischen Ebene, die es Ihnen ermöglicht, den richtigen Bitstrom zu erhalten, wird hier die Rahmensynchronisierung durchgeführt. Betrachten Sie den Weg, den Daten auf dieser Ebene nehmen (von unten nach oben):
Zuvor lohnt es sich jedoch, ein paar Worte zum Codieren zu sagen. Dieses Verfahren ist notwendig, um Bitfehler zu finden und/oder zu korrigieren, die beim Senden von Daten über einen Funkkanal zwangsläufig auftreten. Hier werden wir nicht auf Dekodierungsverfahren eingehen, sondern nur die Informationen erhalten, die zum Verständnis der weiteren Logik des Levels erforderlich sind.
Codes können blockweise oder kontinuierlich sein. Die Standards erzwingen nicht die Verwendung einer bestimmten Art der Kodierung, sie muss jedoch als solche vorhanden sein. Kontinuierliche Codes umfassen Faltungscodes. Sie werden zur Codierung eines kontinuierlichen Bitstroms verwendet. Dies steht im Gegensatz zu Blockcodes, bei denen Daten in Codeblöcke unterteilt sind und nur innerhalb vollständiger Blöcke dekodiert werden können. Der Codeblock stellt die übertragenen Daten und die beigefügten redundanten Informationen dar, die erforderlich sind, um die Richtigkeit der empfangenen Daten zu überprüfen und mögliche Fehler zu korrigieren. Zu den Blockcodes gehören die berühmten Reed-Solomon-Codes.
Wenn Faltungskodierung verwendet wird, gelangt der Bitstrom von Anfang an in den Decoder. Das Ergebnis seiner Arbeit (das alles geschieht natürlich kontinuierlich) sind CADU-Datenblöcke (Channel Access Data Unit). Diese Struktur ist für die Frame-Synchronisation notwendig. Am Ende jedes CADU befindet sich ein angeschlossener Synch Maker (ASM). Dabei handelt es sich um 4 vorab bekannte Bytes, anhand derer der Synchronizer den Anfang und das Ende der CADU findet. Auf diese Weise wird die Frame-Synchronisation erreicht.
Die nächste optionale Stufe der Synchronisations- und Kodierungsschicht ist mit den Besonderheiten der physikalischen Schicht verbunden. Das ist Derandomisierung. Tatsache ist, dass zum Erreichen der Symbolsynchronisierung ein häufiger Wechsel zwischen Symbolen erforderlich ist. Wenn wir also beispielsweise ein Kilobyte an Daten übertragen, die ausschließlich aus Einsen bestehen, geht die Synchronisierung verloren. Daher werden die Eingabedaten während der Übertragung mit einer periodischen Pseudozufallsfolge gemischt, sodass die Dichte von Nullen und Einsen gleichmäßig ist.
Als nächstes werden die Blockcodes dekodiert, und was übrig bleibt, ist das Endprodukt der Synchronisations- und Kodierungsebene – ein Frame.
Datenübertragungsebene
Auf der einen Seite empfängt der Link-Layer-Prozessor Frames und auf der anderen Seite gibt er Pakete aus. Da die Größe von Paketen formal nicht begrenzt ist, ist es für ihre zuverlässige Übertragung notwendig, sie in kleinere Strukturen – Frames – aufzuteilen. Hier betrachten wir zwei Unterabschnitte: getrennt für Telemetrie (TM) und Telecommands (TC).
Telemetrie
Vereinfacht ausgedrückt handelt es sich hierbei um die Daten, die die Bodenstation vom Raumschiff empfängt. Alle übertragenen Informationen werden in kleine Fragmente fester Länge unterteilt – Frames, die übertragene Daten und Dienstfelder enthalten. Schauen wir uns den Rahmenaufbau genauer an:
Beginnen wir unsere Betrachtung mit dem Hauptheader des Telemetrierahmens. Darüber hinaus erlaube ich mir, die Standards an einigen Stellen einfach zu übersetzen und dabei einige Klarstellungen vorzunehmen.
Das Feld „Master Channel ID“ muss die Frame-Versionsnummer und die Gerätekennung enthalten.
Jedes Raumschiff muss gemäß den CCSDS-Standards über eine eigene eindeutige Kennung verfügen, anhand derer man anhand eines Rahmens bestimmen kann, zu welchem Gerät es gehört. Formal ist es notwendig, einen Antrag auf Registrierung des Geräts einzureichen, und sein Name wird zusammen mit seiner Kennung in offenen Quellen veröffentlicht. Russische Hersteller ignorieren dieses Verfahren jedoch häufig und weisen dem Gerät eine willkürliche Kennung zu. Anhand der Frame-Versionsnummer lässt sich ermitteln, welche Version der Standards zum korrekten Lesen des Frames verwendet wird. Hier betrachten wir nur den konservativsten Standard mit der Version „0“.
Das Feld „Virtuelle Kanal-ID“ muss die VCID des Kanals enthalten, von dem das Paket kam. Bei der Wahl der VCID gibt es keine Einschränkungen; insbesondere werden virtuelle Kanäle nicht unbedingt fortlaufend nummeriert.
Sehr oft besteht die Notwendigkeit, übertragene Daten zu multiplexen. Zu diesem Zweck gibt es einen Mechanismus virtueller Kanäle. Beispielsweise überträgt der Satellit Meteor-M2 ein Farbbild im sichtbaren Bereich und teilt es in drei Schwarz-Weiß-Bilder auf – jede Farbe wird in einem eigenen virtuellen Kanal in einem separaten Paket übertragen, obwohl es einige Abweichungen von den Standards gibt Struktur seiner Rahmen.
Das Feld „Operational Control Flag“ soll ein Indikator dafür sein, ob das Feld „Operational Control“ im Telemetrierahmen vorhanden ist oder nicht. Diese 4 Bytes am Ende des Frames dienen als Rückmeldung bei der Steuerung der Zustellung von Telecommand-Frames. Wir werden etwas später darüber sprechen.
Die Frame-Zähler des Hauptkanals und des virtuellen Kanals sind Felder, die bei jedem Senden eines Frames um eins erhöht werden. Dienen als Indikator dafür, dass kein einziger Frame verloren gegangen ist.
Der Datenstatus des Telemetrierahmens besteht aus zwei weiteren Bytes an Flags und Daten, von denen wir uns nur einige ansehen werden.
Das Flag-Feld „Sekundärer Header“ muss ein Indikator für das Vorhandensein oder Fehlen eines sekundären Headers im Telemetrierahmen sein.
Wenn Sie möchten, können Sie jedem Frame einen zusätzlichen Header hinzufügen und dort beliebige Daten nach Belieben platzieren.
Wenn das Synchronisierungsflag auf „1“ gesetzt ist, muss das Feld „First Header Pointer“ eine binäre Darstellung der Position des ersten Oktetts des ersten Pakets im Datenfeld des Telemetrierahmens enthalten. Die Position wird ab 0 in aufsteigender Reihenfolge vom Beginn des Datenfelds an gezählt. Wenn im Datenfeld des Telemetrierahmens kein Paketanfang vorhanden ist, muss der Zeiger auf das erste Headerfeld den Wert in binärer Darstellung „11111111111“ haben (dies kann passieren, wenn ein langes Paket über mehr als einen Rahmen verteilt ist). ).
Enthält das Datenfeld ein leeres Paket (Idle Data), dann sollte der Zeiger auf den ersten Header den Wert in binärer Darstellung „11111111110“ haben. Mit diesem Feld muss der Empfänger den Stream synchronisieren. Dieses Feld stellt sicher, dass die Synchronisierung auch dann wiederhergestellt wird, wenn Frames verloren gehen.
Das heißt, ein Paket kann beispielsweise in der Mitte des 4. Frames beginnen und am Anfang des 20. Frames enden. Dieses Feld wird verwendet, um seinen Anfang zu finden. Pakete haben auch einen Header, der ihre Länge angibt. Wenn also ein Zeiger auf den ersten Header gefunden wird, muss der Link-Layer-Prozessor diesen lesen und so bestimmen, wo das Paket endet.
Wenn ein Fehlerkontrollfeld vorhanden ist, muss es während der gesamten Mission in jedem Telemetrierahmen für einen bestimmten physischen Kanal enthalten sein.
Dieses Feld wird mit der CRC-Methode berechnet. Das Verfahren muss n-16 Bits des Telemetrierahmens nehmen und das Ergebnis der Berechnung in die letzten 16 Bits einfügen.
Fernsehteams
Der TV-Befehlsrahmen weist mehrere wesentliche Unterschiede auf. Unter ihnen:
- Unterschiedlicher Überschriftenaufbau
- Dynamische Länge. Dies bedeutet, dass die Rahmenlänge nicht wie bei der Telemetrie starr festgelegt ist, sondern je nach übertragenen Paketen variieren kann.
- Garantiemechanismus für die Paketzustellung. Das heißt, das Raumschiff muss nach dem Empfang die Richtigkeit des Frame-Empfangs bestätigen oder die Weiterleitung eines Frames anfordern, der möglicherweise mit einem nicht korrigierbaren Fehler empfangen wurde.
Viele Felder sind uns bereits aus dem Telemetrie-Frame-Header bekannt. Da sie denselben Zweck haben, betrachten wir hier nur die neuen Felder.
Ein Bit des Bypass-Flags muss zur Steuerung der Rahmenprüfung beim Empfänger verwendet werden. Ein Wert von „0“ für dieses Flag soll anzeigen, dass es sich bei dem Frame um einen Frame vom Typ A handelt und gemäß FARM überprüft werden muss. Ein Wert von „1“ für dieses Flag sollte dem Empfänger anzeigen, dass es sich bei diesem Frame um einen Frame vom Typ B handelt und die FARM-Prüfung umgehen sollte.
Dieses Flag informiert den Empfänger darüber, ob ein Rahmenzustellungsbestätigungsmechanismus namens FARM – Frame Acceptance and Reporting Mechanism – verwendet werden soll.
Das Steuerbefehlsflag muss verwendet werden, um zu verstehen, ob das Datenfeld einen Befehl oder Daten transportiert. Wenn das Flag „0“ ist, muss das Datenfeld Daten enthalten. Wenn das Flag „1“ ist, muss das Datenfeld Steuerinformationen für FARM enthalten.
FARM ist eine endliche Zustandsmaschine, deren Parameter konfiguriert werden können.
RSVD. SPARE – reservierte Bits.
Es scheint, dass CCSDS Pläne für die Zukunft hat, und aus Gründen der Abwärtskompatibilität der Protokollversionen haben sie diese Bits bereits in aktuellen Versionen des Standards reserviert.
Das Feld „Frame-Länge“ muss eine Zahl in Bit-Darstellung enthalten, die der Frame-Länge in Oktetten minus eins entspricht.
Das Frame-Datenfeld muss dem Header ohne Leerzeichen folgen und eine ganzzahlige Anzahl von Oktetten enthalten, die maximal 1019 Oktette lang sein darf. Dieses Feld muss entweder Rahmendatenblock- oder Steuerbefehlsinformationen enthalten. Der Frame-Datenblock muss enthalten:
- Ganzzahlige Anzahl von Benutzerdaten-Oktetten
- Segment-Header, gefolgt von einer ganzzahligen Anzahl von Benutzerdaten-Oktetten
Wenn ein Header vorhanden ist, muss der Datenblock ein Paket, eine Reihe von Paketen oder einen Teil eines Pakets enthalten. Ein Datenblock ohne Header kann keine Teile von Paketen enthalten, kann aber Datenblöcke im privaten Format enthalten. Daraus folgt, dass ein Header erforderlich ist, wenn der übertragene Datenblock nicht in einen Frame passt. Ein Datenblock mit einem Header wird als Segment bezeichnet
Das Zwei-Bit-Flags-Feld muss Folgendes enthalten:
- „01“ – wenn der erste Teil der Daten im Datenblock ist
- „00“ – wenn sich der mittlere Teil der Daten im Datenblock befindet
- „10“ – wenn sich das letzte Datenelement im Datenblock befindet
- „11“ – wenn keine Unterteilung erfolgt und ein oder mehrere Pakete vollständig in den Datenblock passen.
Das MAP-ID-Feld muss Nullen enthalten, wenn keine MAP-Kanäle verwendet werden.
Manchmal reichen 6 den virtuellen Kanälen zugewiesene Bits nicht aus. Und wenn es notwendig ist, Daten auf eine größere Anzahl von Kanälen zu multiplexen, werden weitere 6 Bits aus dem Segment-Header verwendet.
BAUERNHOF
Schauen wir uns den Funktionsmechanismus des Personalzustellungskontrollsystems genauer an. Dieses System sieht aufgrund ihrer Bedeutung nur die Arbeit mit Telebefehlsrahmen vor (Telemetrie kann jederzeit erneut angefordert werden, und das Raumschiff muss die Bodenstation deutlich hören und ihren Befehlen stets gehorchen). Angenommen, wir beschließen, unseren Satelliten neu zu flashen und eine Binärdatei mit einer Größe von 10 Kilobyte an ihn zu senden. Auf der Verbindungsebene wird die Datei in 10 Frames (0, 1, ..., 9) unterteilt, die nacheinander nach oben gesendet werden. Wenn die Übertragung abgeschlossen ist, muss der Satellit die Richtigkeit des Paketempfangs bestätigen oder melden, bei welchem Frame der Fehler aufgetreten ist. Diese Informationen werden im nächstgelegenen Telemetrierahmen an das Betriebskontrollfeld gesendet (oder das Raumschiff kann die Übertragung eines Leerlaufrahmens einleiten, wenn es nichts zu sagen hat). Anhand der empfangenen Telemetrie stellen wir entweder sicher, dass alles in Ordnung ist, oder wir senden die Nachricht erneut. Nehmen wir an, der Satellit hat Bild Nr. 7 nicht gehört. Das heißt, wir senden ihm die Frames 7, 8, 9. Erfolgt keine Antwort, wird das gesamte Paket erneut gesendet (und so weiter, mehrmals, bis wir feststellen, dass die Versuche vergeblich waren).
Nachfolgend finden Sie die Struktur des operativen Kontrollbereichs mit einer Beschreibung einiger Felder. Die in diesem Feld enthaltenen Daten werden CLCW (Communication Link Control Word) genannt.
Da man auf dem Bild den Zweck der Hauptfelder leicht erkennen kann und die anderen Felder langweilig anzusehen sind, verstecke ich die detaillierte Beschreibung unter einem Spoiler
Erläuterung der CLCW-FelderSteuerworttyp:
Für diesen Typ muss das Steuerwort 0 enthalten
Steuerwortversion (CLCW-Versionsnummer):
Bei diesem Typ muss das Steuerwort in der Bitdarstellung gleich „00“ sein.
Statusfeld:
Die Nutzung dieses Feldes wird für jede Mission separat festgelegt. Kann von verschiedenen Raumfahrtagenturen für lokale Verbesserungen verwendet werden.
Identifizierung des virtuellen Kanals:
Muss die Kennung des virtuellen Kanals enthalten, dem dieses Steuerwort zugeordnet ist.
Flag für den Zugriff auf den physischen Kanal:
Das Flag muss Auskunft über die Bereitschaft der physikalischen Schicht des Empfängers geben. Wenn die physikalische Schicht des Empfängers nicht bereit ist, Frames zu empfangen, muss das Feld „1“ enthalten, andernfalls „0“.
Flag für Synchronisierungsfehler:
Das Flag kann darauf hinweisen, dass die physikalische Schicht mit einem schlechten Signalpegel arbeitet und die Anzahl der abgelehnten Frames zu hoch ist. Die Verwendung dieses Feldes ist optional; wenn es verwendet wird, muss es „0“ enthalten, wenn eine Synchronisierung verfügbar ist, und „1“, wenn dies nicht der Fall ist.
Sperrflag:
Dieses Bit soll den FARM-Sperrstatus für jeden virtuellen Kanal enthalten. Ein Wert von „1“ in diesem Feld sollte anzeigen, dass FARM deaktiviert ist und Frames für jede virtuelle Ebene verworfen werden, andernfalls „0“.
Warteflag:
Dieses Bit soll verwendet werden, um anzuzeigen, dass der Empfänger keine Daten auf dem angegebenen virtuellen Kanal verarbeiten kann. Ein Wert von „1“ gibt an, dass alle Frames auf diesem virtuellen Kanal verworfen werden, andernfalls „0“.
Vorwärtsflagge:
Dieses Flag muss eine „1“ enthalten, wenn ein oder mehrere Typ-A-Frames verworfen wurden oder Lücken gefunden wurden, sodass ein erneutes Senden erforderlich ist. Das Flag „0“ zeigt an, dass keine Frames ausgelassen oder übersprungen wurden.
Antwortwert:
Rahmennummer, die nicht empfangen wurde. Wird durch den Zähler im Telecommand-Frame-Header bestimmt
Netzwerkschicht
Lassen Sie uns diese Ebene ein wenig berühren. Hier gibt es zwei Möglichkeiten: Entweder das Space-Packet-Protokoll verwenden oder ein beliebiges anderes Protokoll im CCSDS-Paket kapseln.
Ein Überblick über das Space-Packet-Protokoll ist ein Thema für einen separaten Artikel. Es soll es sogenannten Anwendungen ermöglichen, nahtlos Daten auszutauschen. Jede Anwendung verfügt über eine eigene Adresse und Grundfunktionen für den Datenaustausch mit anderen Anwendungen. Es gibt auch Dienste, die den Verkehr leiten, die Zustellung steuern usw.
Mit der Kapselung ist alles einfacher und übersichtlicher. Die Standards ermöglichen es, beliebige Protokolle durch Hinzufügen eines zusätzlichen Headers in CCSDS-Pakete zu kapseln.
Wobei der Header je nach Länge des gekapselten Protokolls unterschiedliche Bedeutungen hat:
Hier ist das Hauptfeld die Länge der Länge. Sie kann zwischen 0 und 4 Byte variieren. Außerdem müssen Sie in dieser Kopfzeile anhand der Tabelle den Typ des gekapselten Protokolls angeben .
Die IP-Kapselung verwendet ein weiteres Add-on, um den Pakettyp zu bestimmen.
Sie müssen einen weiteren Header hinzufügen, der ein Oktett lang ist:
Wobei PID eine weitere Protokollkennung ist
Abschluss
Auf den ersten Blick scheint es, dass die CCSDS-Header äußerst redundant sind und einige Felder verworfen werden könnten. Tatsächlich beträgt die Effizienz des resultierenden Kanals (bis zur Netzwerkebene) etwa 40 %. Sobald jedoch die Notwendigkeit entsteht, diese Standards umzusetzen, wird deutlich, dass jeder Bereich, jede Rubrik ihre eigene wichtige Aufgabe hat, deren Nichtbeachtung zu einer Reihe von Unklarheiten führt.
Wenn die Habrasociety Interesse an diesem Thema zeigt, werde ich gerne eine ganze Reihe von Artikeln veröffentlichen, die sich der Theorie und Praxis der Weltraumkommunikation widmen. Vielen Dank für Ihre Aufmerksamkeit!
Quellen
PS
Schlagen Sie nicht zu hart zu, wenn Sie Ungenauigkeiten feststellen. Melde sie und sie werden behoben :)
Source: habr.com