宇宙通信規格について少し

流星M1衛星
ソース: vladtime.ru

導入

宇宙技術の運用は無線通信なしでは不可能です。この記事では、宇宙データ システム国際諮問委員会 (CCSDS。以下、この略語を使用します) によって開発された標準の基礎となった主な考え方について説明します。 。

この投稿では主にデータ リンク層に焦点を当てますが、他の層の基本概念も紹介します。 この記事は、規格を徹底的かつ完全に説明することを目的としたものではありません。 で閲覧できます オンライン CCSDS。 ただし、これらは非常に理解するのが難しく、理解するのに多くの時間を費やしました。そのため、ここでは基本的な情報を提供したいと思います。これがあれば、他のすべてを理解するのがはるかに簡単になります。 それでは、始めましょう。

CCSDS の崇高な使命

おそらく誰かが疑問を持っているかもしれません。独自の無線プロトコル スタック (またはブラックジャックや新機能を備えた独自の標準) を開発して、システムのセキュリティを強化できるのに、なぜ誰もが標準に従う必要があるのでしょうか。

実践が示すように、次のような理由から、CCSDS 標準に準拠する方がより有益です。

1. 規格の発行を担当する委員会には、世界中の主要な航空宇宙機関の代表者が含まれており、長年にわたるさまざまなミッションの設計と運用で得られた貴重な経験が活かされています。 この経験を無視して再び熊手を踏むのは非常にばかげています。
2. これらの規格は、すでに市販されている地上局機器によってサポートされています。
3. 問題のトラブルシューティングを行うときは、いつでも他の機関の同僚に助けを求めて、地上局からデバイスとの通信セッションを実行できるようにすることができます。 ご覧のとおり、標準は非常に便利なものなので、その重要なポイントを見てみましょう。

アーキテクチャ

この標準は、最も一般的な OSI (オープン システム相互接続) モデルを反映した一連の文書です。ただし、データ リンク レベルでの共通性はテレメトリ (ダウンリンク - 宇宙 - 地球) とテレコマンド (アップリンク) への分割に限定されています。

物理的なレベルから始めて、レベルを上げて、いくつかのレベルを詳しく見てみましょう。 より明確にするために、受信側のアーキテクチャを考慮します。 透過するものはその鏡像です。

物理層

このレベルでは、変調された無線信号がビット ストリームに変換されます。 このレベルではハードウェアの特定の実装から抽象化することが難しいため、ここでの標準は主に勧告的な性質のものです。 ここで、CCSDS の重要な役割は、許容可能な変調 (BPSK、QPSK、8-QAM など) を定義し、シンボル同期メカニズム、ドップラー補償などの実装に関する推奨事項を提供することです。

同期とエンコードレベル

正式には、これはデータ リンク層のサブレイヤーですが、CCSDS 標準内での重要性のため、別のレイヤーに分離されることがよくあります。 この層は、ビット ストリームをいわゆるフレーム (テレメトリまたはテレコマンド) に変換します。これについては後で説明します。 正しいビット ストリームを取得できる物理層でのシンボル同期とは異なり、フレーム同期はここで実行されます。 このレベルでデータがたどるパス (下から上へ) を考えてみましょう。

ただし、その前に、コーディングについて少し触れておく価値があります。 この手順は、無線チャネルでデータを送信するときに必然的に発生するビット エラーを検出および/または修正するために必要です。 ここでは、デコード手順については考慮しませんが、レベルのさらなるロジックを理解するために必要な情報のみを取得します。

コードはブロックまたは連続することができます。 標準では、特定の種類のエンコーディングの使用を強制しませんが、そのように存在する必要があります。 連続符号には畳み込み符号が含まれます。 これらは連続ビット ストリームをエンコードするために使用されます。 これは、データがコードブロックに分割され、完全なブロック内でのみデコードできるブロック コードとは対照的です。 コード ブロックは、送信されたデータと、受信したデータの正確性を検証し、考えられるエラーを修正するために必要な付属の冗長情報を表します。 ブロック コードには、有名なリードソロモン コードが含まれます。

畳み込みエンコーディングが使用される場合、ビットストリームは最初からデコーダに入力されます。 その作業の結果 (もちろん、これはすべて継続的に発生します)、CADU (チャネル アクセス データ ユニット) データ ブロックが生成されます。 この構造はフレーム同期に必要です。 各 CADU の最後には、同期メーカー (ASM) が接続されています。 これらは事前に知られている 4 バイトであり、シンクロナイザーはこれによって CADU の始まりと終わりを見つけます。 このようにしてフレーム同期が実現されます。

同期およびエンコード層の次のオプションの段階は、物理層の特性に関連付けられています。 これが非ランダム化です。 実際、シンボル同期を達成するには、シンボル間の頻繁な切り替えが必要です。 したがって、たとえば、すべて XNUMX で構成される XNUMX キロバイトのデータを送信すると、同期が失われます。 したがって、送信中に、入力データは、XNUMX と XNUMX の密度が均一になるように周期的な擬似ランダム シーケンスと混合されます。

次に、ブロック コードがデコードされ、残るのは同期とエンコード レベルの最終生成物であるフレームです。

データリンク層

一方では、リンク層プロセッサがフレームを受信し、もう一方ではパケットを発行します。 パケットのサイズは正式には制限されていないため、信頼性の高い送信を行うには、パケットをより小さな構造、つまりフレームに分割する必要があります。 ここでは、テレメトリ (TM) とテレコマンド (TC) の XNUMX つのサブセクションを個別に見ていきます。

テレメトリー

簡単に言えば、これは地上局が宇宙船から受信するデータです。 送信されるすべての情報は、固定長の小さなフラグメント、つまり送信データとサービス フィールドを含むフレームに分割されます。 フレーム構造を詳しく見てみましょう。

そして、テレメトリ フレームのメイン ヘッダーから検討を始めましょう。 さらに、途中でいくつかの説明を加えながら、いくつかの場所で規格を単純に翻訳することにします。

マスター チャネル ID フィールドには、フレームのバージョン番号とデバイス識別子が含まれている必要があります。

CCSDS 標準に従って、各宇宙船は独自の一意の識別子を持たなければなりません。これにより、フレームを持っているときに、それがどのデバイスに属しているかを判断できます。 正式には、デバイスを登録するには申請書を提出する必要があり、その名前と識別子はオープンソースで公開されます。 ただし、ロシアのメーカーはこの手順を無視して、デバイスに任意の識別子を割り当てることがよくあります。 フレームのバージョン番号は、フレームを正しく読み取るためにどのバージョンの標準が使用されているかを判断するのに役立ちます。 ここでは、バージョン「0」の最も保守的な標準のみを考慮します。

仮想チャネル ID フィールドには、パケットの送信元チャネルの VCID が含まれている必要があります。 VCID の選択に制限はありません。特に、仮想チャネルには必ずしも連続した番号が付けられる必要はありません。

多くの場合、送信データを多重化する必要があります。 この目的のために、仮想チャネルのメカニズムがあります。 たとえば、Meteor-M2 衛星は、可視範囲のカラー画像を XNUMX つの白黒画像に分割して送信します。各色は、別個のパケット内の独自の仮想チャネルで送信されますが、標準からは多少の逸脱があります。そのフレームの構造。

運用制御フラグ フィールドは、テレメトリ フレーム内の運用制御フィールドの有無を示すものとします。 フレームの末尾にあるこれらの 4 バイトは、テレコマンド フレームの配信を制御するときにフィードバックを提供するために機能します。 それらについては後ほど説明します。

メイン チャネル フレーム カウンタと仮想チャネル フレーム カウンタは、フレームが送信されるたびに XNUMX ずつ増加するフィールドです。 フレームが XNUMX つも失われていないことを示す指標として機能します。

テレメトリ フレーム データ ステータスは、さらに XNUMX バイトのフラグとデータであり、そのうちのいくつかについて説明します。

セカンダリ ヘッダー フラグ フィールドは、テレメトリ フレーム内のセカンダリ ヘッダーの有無を示すものでなければなりません。

必要に応じて、各フレームに追加のヘッダーを追加し、任意のデータをそこに配置できます。

同期フラグが「1」に設定されている場合、最初のヘッダー ポインタ フィールドには、テレメトリ フレームのデータ フィールド内の最初のパケットの最初のオクテットの位置のバイナリ表現が含まれます。 位置はデータフィールドの先頭から昇順に0からカウントされます。 テレメトリ フレームのデータ フィールドにパケットの開始がない場合、最初のヘッダー フィールドへのポインタはバイナリ表現「11111111111」の値を持つ必要があります (これは、XNUMX つの長いパケットが複数のフレームに分散されている場合に発生する可能性があります) ）。

データ フィールドに空のパケット (アイドル データ) が含まれている場合、最初のヘッダーへのポインタはバイナリ表現「11111111110」の値を持つ必要があります。 このフィールドを使用して、受信者はストリームを同期する必要があります。 このフィールドにより、フレームがドロップされた場合でも同期が確実に復元されます。

つまり、パケットは、たとえば 4 番目のフレームの中央で開始し、20 番目のフレームの最初で終了する可能性があります。 このフィールドは、その始まりを見つけるために使用されます。 パケットには長さを指定するヘッダーもあるため、最初のヘッダーへのポインターが見つかると、リンク層プロセッサーはそれを読み取る必要があり、それによってパケットがどこで終了するかを決定します。
エラー制御フィールドが存在する場合は、ミッション全体を通じて特定の物理チャネルのすべてのテレメトリ フレームに含める必要があります。

このフィールドは CRC メソッドを使用して計算されます。 この手順では、テレメトリ フレームの n-16 ビットを取得し、計算の結果を最後の 16 ビットに挿入する必要があります。

テレビチーム

TV コマンド フレームにはいくつかの大きな違いがあります。 その中で：

1. 異なる見出し構造
2. ダイナミックな長さ。 これは、フレーム長がテレメトリのように厳密に設定されるのではなく、送信されるパケットに応じて変化する可能性があることを意味します。
3. パケット配信保証メカニズム。 つまり、宇宙船はフレームを受信した後、フレーム受信の正しさを確認するか、訂正不能なエラーで受信された可能性があるフレームの転送を要求する必要があります。

多くのフィールドは、テレメトリ フレーム ヘッダーからすでによく知られています。 目的は同じなので、ここでは新しいフィールドのみを考慮します。

バイパス フラグの 0 ビットは、受信側でのフレーム チェックを制御するために使用する必要があります。 このフラグの値「1」は、フレームがタイプ A フレームであり、FARM に従って検証される必要があることを示します。 このフラグの値「XNUMX」は、フレームがタイプ B フレームであり、FARM チェックをバイパスする必要があることを受信機に示す必要があります。

このフラグは、FARM (フレーム受け入れおよび報告メカニズム) と呼ばれるフレーム配信確認メカニズムを使用するかどうかを受信者に通知します。

制御コマンド フラグは、データ フィールドがコマンドを転送するかデータを転送するかを理解するために使用する必要があります。 フラグが「0」の場合、データ フィールドにはデータが含まれている必要があります。 フラグが「1」の場合、データ フィールドには FARM の制御情報が含まれている必要があります。
FARM はパラメータを設定できる有限状態マシンです。

RSVD。 SPARE – 予約ビット。

CCSDS には将来の計画があるようで、プロトコル バージョンの下位互換性のために、標準の現在のバージョンでこれらのビットがすでに予約されています。

フレーム長フィールドには、オクテット単位のフレーム長から XNUMX を引いた値に等しいビット表現の数値が含まれている必要があります。

フレーム データ フィールドはヘッダーの後にスペースを入れずに続き、整数のオクテットを含める必要があります。長さは最大 1019 オクテットです。 このフィールドには、フレーム データ ブロックまたは制御コマンド情報が含まれている必要があります。 フレーム データ ブロックには次のものが含まれている必要があります。

• ユーザーデータオクテットの整数
• セグメントヘッダーの後に整数のユーザーデータオクテットが続きます

ヘッダーが存在する場合、データ ブロックにはパケット、パケットのセット、またはパケットの一部が含まれている必要があります。 ヘッダーのないデータ ブロックにはパケットの一部を含めることはできませんが、プライベート形式のデータ ブロックを含めることはできます。 このことから、送信されるデータ ブロックが XNUMX つのフレームに収まらない場合にはヘッダーが必要であることがわかります。 ヘッダーを持つデータのブロックはセグメントと呼ばれます

XNUMX ビットのフラグ フィールドには以下を含める必要があります。

• "01" - データの最初の部分がデータ ブロック内にある場合
• 「00」 - データの中間部分がデータ ブロック内にある場合
• 「10」 - 最後のデータがデータ ブロック内にある場合
• 「11」 - 分割がなく、XNUMX つ以上のパケットがデータ ブロックに完全に収まる場合。

MAP チャネルが使用されない場合、MAP ID フィールドにはゼロを含める必要があります。
仮想チャネルに割り当てられた 6 ビットでは不十分な場合があります。 さらに、より多くのチャネルにデータを多重化する必要がある場合は、セグメント ヘッダーのさらに 6 ビットが使用されます。

ファーム

人材配置管理システムが機能する仕組みを詳しく見てみましょう。 このシステムは、その重要性のため、テレコマンドのフレームの操作のみを提供します (テレメトリはいつでも再度要求でき、宇宙船は地上局の声をはっきりと聞き、常にそのコマンドに従わなければなりません)。 そこで、衛星を再フラッシュし、サイズ 10 キロバイトのバイナリ ファイルを衛星に送信することにしたとします。 リンク レベルでは、ファイルは 10 個のフレーム (0、1、...、9) に分割され、7 つずつ上向きに送信されます。 送信が完了すると、衛星はパケット受信の正しさを確認するか、どのフレームでエラーが発生したかを報告する必要があります。 この情報は、最も近いテレメトリ フレームの運用制御フィールドに送信されます (または、何も言うことがなければ、宇宙船はアイドル フレームの送信を開始できます)。 受信したテレメトリに基づいて、すべてが正常であることを確認するか、メッセージの再送信に進みます。 衛星がフレーム #7 を受信しなかったと仮定しましょう。 これは、フレーム 8、9、XNUMX を送信することを意味します。応答がない場合は、パケット全体が再送信されます (試行が無駄であることが分かるまで、これを数回繰り返します)。

以下に、操作制御フィールドの構造といくつかのフィールドの説明を示します。 このフィールドに含まれるデータは、CLCW (Communication Link Control Word) と呼ばれます。

メインフィールドの目的は絵から容易に推測できますが、その他のフィールドは見ているだけで退屈なので、詳細な説明はネタバレとして隠します

CLCWフィールドの説明コントロールワードタイプ:
このタイプの場合、制御ワードには 0 が含まれている必要があります。

コントロール ワード バージョン (CLCW バージョン番号):
このタイプの場合、制御ワードはビット表現で「00」に等しくなければなりません。

ステータスフィールド:
このフィールドの使用はミッションごとに個別に決定されます。 さまざまな宇宙機関による局所的な改善に使用できます。

仮想チャネルの識別:
この制御ワードが関連付けられている仮想チャネルの識別子を含める必要があります。

物理チャネルアクセスフラグ:
フラグは、受信側の物理層の準備状況に関する情報を提供する必要があります。 受信機の物理層がフレームを受信する準備ができていない場合、フィールドには「1」が含まれている必要があり、それ以外の場合は「0」が含まれます。

同期失敗フラグ:
このフラグは、物理層が低い信号レベルで動作していて、拒否されたフレームの数が多すぎることを示している可能性があります。 このフィールドの使用はオプションです。使用する場合、同期が利用可能な場合は「0」を、利用できない場合は「1」を含める必要があります。

ブロックフラグ:
このビットには、各仮想チャネルの FARM ロック ステータスが含まれます。 このフィールドの値が「1」の場合は、FARM が無効であり、仮想レイヤごとにフレームが破棄されることを示します。それ以外の場合は、「0」です。

待機フラグ:
このビットは、受信機が指定された仮想チャネル上のデータを処理できないことを示すために使用されます。 値「1」は、この仮想チャネル上ですべてのフレームが破棄されることを示し、それ以外の場合は「0」です。

前進フラグ:
1 つ以上のタイプ A フレームが破棄されたか、ギャップが見つかったために再送信が必要な場合、このフラグには「0」が含まれます。 「XNUMX」フラグは、フレームのドロップやスキップがなかったことを示します。

応答値:
受信されなかったフレーム番号。 テレコマンド フレーム ヘッダーのカウンタによって決定されます

ネットワーク層

このレベルについて少し触れてみましょう。 ここには XNUMX つのオプションがあります。スペース パケット プロトコルを使用するか、CCSDS パケット内の他のプロトコルをカプセル化するかのいずれかです。

スペース パケット プロトコルの概要については、別の記事で説明します。 いわゆるアプリケーションがシームレスにデータを交換できるように設計されています。 各アプリケーションには、他のアプリケーションとデータを交換するための独自のアドレスと基本機能があります。 トラフィックのルーティング、配信の制御などを行うサービスもあります。

カプセル化を使用すると、すべてがよりシンプルかつ明確になります。 この規格では、追加のヘッダーを追加することで、あらゆるプロトコルを CCSDS パケットにカプセル化することができます。

ヘッダーの意味は、カプセル化されるプロトコルの長さに応じて異なります。

ここで、メインフィールドは長さです。 0 ～ 4 バイトの範囲で変化します。 また、このヘッダーでは、テーブルを使用してカプセル化されたプロトコルのタイプを指定する必要があります。 故に.

IP カプセル化では、別のアドオンを使用してパケットのタイプを決定します。
XNUMX オクテット長のヘッダーをもう XNUMX つ追加する必要があります。

ここで、PID は取得される別のプロトコル識別子です 故に

まとめ

一見すると、CCSDS ヘッダーは非常に冗長であり、一部のフィールドは破棄される可能性があるように見えるかもしれません。 実際、結果として得られるチャネルの効率 (ネットワーク レベルまで) は約 40% です。 しかし、これらの標準を実装する必要が生じるとすぐに、各分野、各見出しに独自の重要な使命があることが明らかになり、これを無視すると多くのあいまいさが生じます。

ハブラソサエティーがこのテーマに興味を示してくれれば、宇宙通信の理論と実践に特化した一連の記事を喜んで出版します。 ご清聴ありがとうございました！

ソース

CCSDS 130.0-G-3 — 宇宙通信プロトコルの概要
CCSDS 131.0-B-2 – TM 同期とチャネルコーディング
CCSDS 132.0-B-2 - TM スペース データ リンク プロトコル
CCSDS 133.0-B-1 - 宇宙パケット プロトコル
CCSDS 133.1-B-2 - カプセル化サービス
CCSDS 231.0-B-3 - TC 同期とチャネルコーディング
CCSDS 232.1-B-2 通信操作手順-1
CCSDS 401.0-B-28 無線周波数および変調システム - パート 1 (地球局および宇宙船)
CCSDS 702.1-B-1 - CCSDS スペース リンク上の IP

PS
不正確な点を見つけた場合は、あまり強く叩かないでください。 報告すれば修正されます:)

出所： habr.com