ARINC 664 メッセージ構造

アビオニクス・サブシステムの設計者は、アビオニクス・アプリケーションに最も適合するメッセージ構造を選択することから合理的に解放されます。メッセージは、UDPパケットのペイロードに含められます。一般に、メッセージの解釈は、アビオニクス・アプリケーション間の合意により決定されます。

ARINC 664, Part 7は、明示と暗示の2つのタイプのメッセージ構造を識別します。明示メッセージ構造は、受信機がデータを正確に解釈することを可能にするフォーマット情報を含みます。暗示メッセージ構造は、データの解釈において受信機を助けるための記述情報を含んでいません。従って、ネットワークの帯域幅をより有効に使用します。

本節は、ARINC 664暗示メッセージ構造フォーマットについて説明します。暗示メッセージ構造に含まれる明示フォーマット情報が存在しないので、アビオニクス・アプリケーションは、受信データのメッセージ・フォーマットを識別する方法を必要とします。これは、暗示メッセージ構造をAFDX受信ポートと関連付けることにより達成されます。アプリケーションは、メッセージが受信されるUDPポート番号に基づいて、メッセージ構造を関連付けます。

インターネットで、特定のよく知られたUDPポート番号は、特定のアプリケーションに対応しています。ポート69は、簡易ファイル転送プロトコル（TFTP）により使用されます。ポート80は、ハイパーテキスト転送プロトコル（HTTP）により使用される等。Internet Assigned Number Authority（IANA）は、UDPポート番号の空間を管理しています。UDPポート番号は、3グループに分かれます。

割当ポート番号（ウェルノウン・ポート）：0～1023
登録ポート番号：1024～4951
動的／プライベート・ポート番号：49152～65535

AFDX/ARINC 664は、閉鎖ネットワークですが、UDPポート番号は、動的／プライベートの番号範囲から選択されるべきです。この理由は、ゲートウェイがAFDXネットワークとインターネット間を通信するために使用されるとき、標準のポート番号割当と競合の可能性があるからです。

暗示メッセージ構造

ARINC 664, Part 7は、暗示メッセージ構造のフォーマットのより完全な説明を示します。以下のものを含めて、限定数のデータ型が定義されています。

Signed_32 Integer
Signed_64 Integer
Float_32
Float_64
Boolean
String
Opaque Data

標準はまた、プリミティブ・データ型が、自然な範囲で配列されている必要があります。例えば、Float_64は、64 Bit境界で配列する必要があります。アドレス0は、UDPペイロードの先頭とみなされます。全配列は、アドレス0と相対的です。

メッセージ構造の最初の4バイトは、予約されています。この後、基本メッセージ構造は、機能ステータス・セットと呼ばれる4バイト・ワードから構成され、最大4つのデータ・セットが続きます。基本メッセージ構造は、メッセージ構造を形成するために、任意の回数、反復することができます。図23は、2つのメッセージ構造を示しています。左側のものは、2つのデータ・セット、データ・セット1とデータ・セット2から構成されています。機能ステータス・セットは、各々データ・セット1と2に一致する2つの機能ステータス・バイト、FS1とFS2を持っています。

図23 2つのメッセージ構造

各データ・セットの機能ステータスは、通信機能ステータス・バイトでエンコードされます。データなし、正常動作、機能試験、および計算データなしの4つの状態があります。明らかに、データは、機能ステータスがデータ・セットの全データに適用されるように、データ・セットにグループ化されなければなりません。

上記の右で描写したメッセージ構造は、2つの基本メッセージ構造と、総計5つのデータ・セット、および5つの通信機能ステータスから構成されています。

ARINC 429ラベル

図24は、ARINC 664メッセージ構造を使用して、ARINC 429データをいかに適応できるかを示しています。不明瞭でプリミティブ・データ型は、データの解釈がアプリケーションに任されるように使用されます（普通）。

図24 ARINC 664メッセージ構造

AFDXプロトコル・スタック

プロトコル層は、AFDX通信サービス、UDPトランスポート層、およびリンク・レベル（バーチャル・リンク）サービスに分けられます。

送信

Txプロトコルは、AFDXポートに送られるメッセージで始まります。UDPトランスポート層は、適切な送信元、および宛先UDPポート番号を含むUDPヘッダの追加を担当します。これらの番号は、ほとんどの場合、システム設定により決定され、各AFDX通信ポートに対して固定されます。 SAPポートの場合、アプリケーションは、IP、およびUDP宛先アドレスを動的に示します。

IPネットワーク層は、UDPパケットを受け取り、断片化される必要があるかを決定します。IPネットワーク層は、断片化が必要であるかを決定するために、適切なバーチャル・リンクのLmaxを使用します。 IPヘッダが追加され、IPチェックサムは、各フラグメントに対して計算されます。IP層は、イーサネット・ヘッダを追加し、適切なサブVLキュー内のイーサネット・フレームをエンキューします。（バーチャル）リンク層は、シーケンス番号（VLベース毎に）を追加し、フレームが複製され（必要な場合）、イーサネット送信元アドレスが、フレームが送信される物理ポートIDで更新される冗長性管理ユニットにフレームをパスすることにより、送信用イーサネット・フレームのスケジューリングを担当します。

図25 AFDX Txプロトコル・スタック

受信

受信は、送信の逆です。プロセスは、フレーム・チェック・シーケンス（FCS）を使用して正確さがチェックされるイーサネット・フレームの受信で始まります。エラーがない場合、FCSが外され、AFDXフレームは、完全性チェックと冗長性管理を介してパスされます。これらのステップは、（バーチャル）リンク・レベルで行われます。結果として、IPパケットは、IPネットワーク・レベル上にパスされます。

ネットワーク・レベルは、必要な場合、IPチェックサム・フィールドのチェックとUDPパケット分解を担当します。 UDPパケットは、適切なUDPポートにAFDXメッセージを配送（DEMUX）するために、UDPトランスポート層にパスされます。

図26 AFDX Rxプロトコル・スタック