JP5005818B2 - リモート航空電子アプリケーション用ａｃａｒｓルータ - Google Patents

Description

本発明は、広くは、航空用遠隔通信に関し、より詳細には、ＡＣＡＲＳ（Aircraft Communication and Reporting System）ルーティングに関する。

航空分野では、ＡＣＡＲＳシステムを用いて、航空機と地上管制塔との間でデータの伝送を行う。特に、やりとりされるのは、航空会社オペレータとのＡＯＣ（Aeronautical Operational Control，航空運用管制）タイプの情報、又は、航空管制官とのＡＴＣ（Air Traffic Control，航空管制）タイプの情報である。

ＡＣＡＲＳシステムは、さまざま伝送媒体（当分野では、媒体とも称される）、より正確には、データ伝送のためのさまざまなタイプのサブネットワーク、すなわち、ＨＦ、ＶＨＦ、又はＳＡＴＣＯＭサブネットワークを使用する。ＶＨＦ遠隔通信サブネットワークは、ポイントツーポイントリンクによる地上の送信機／受信機との直接通信状態を可能にするが、通信範囲が比較的狭い。一方、人工衛星遠隔通信サブネットワークは、極地を除き、世界中をカバーするが、通信コストがかさむ。ＨＦサブネットワークは、極地をカバーする。通常、機上と地上との間のデータのリンクは、当分野では一般的な用語「データリンク」と称される。

通常、地上へのデータの伝送は、ＡＣＡＲＳルータを用いて行われる。このルータは、装置の通信管理部又はＣＭＵ（Communications Management Unit，通信管理ユニット）として機能し、いくつかのパラメータ、特に、媒体の可用性及びその使用コストに従って、最適な伝送媒体（ＶＨＦ、ＨＦ、ＳＡＴＣＯＭ）を自動的に選択する。

図１は、従来のＡＣＡＲＳルータ１００を使用する通信システムの構成を概略的に示す。そのようなルータは、地上とやりとりするデータをＡＣＡＲＳメッセージとして送受信する機能を有した１つ以上のアプリケーション１１０を内蔵する。これらのアプリケーションは、機器製造時に予め設定される。新たなアプリケーションを追加するためには、ルータの更新（又は、ルータ自体の交換）のほかに、新たな検証も必要となる。したがって、ルータへの新たなアプリケーションの導入は非常に手間の掛かる作業となる。また、ＡＣＡＲＳルータは、ＡＲＩＮＣ ６１９タイプの専用ポイントツーポイントリンクを用いてリモート航空電子アプリケーションに接続される。これらのリンクを介してＡＣＡＲＳメッセージを伝送するためのプロトコルは、ＡＲＩＮＣ ６１９規格で定義されている。

リモート航空電子アプリケーションは、複数のタイプのＬＲＵ（Line Replaceable Unit，回線可換ユニット）、例えば、航空機の状態に関する情報を航空会社に伝送するためのＡＣＭＳ（Aircraft Condition Monitoring System，航空機状態監視システム）モジュール、管制からの情報を受信するためのＡＴＣモジュール、整備データを交換するためのＣＭＳ（Centralised Maintenance System）モジュールなどに取り付けられる。これらのアプリケーションは、ルータの設計時に設けられた専用インタフェースを用いて、ルータとの対話を行う。換言すれば、ルータによって提供されるＡＣＡＲＳサービスを追加的なアプリケーションが使用することを想定していない。このことによって、新たなインタフェースの配置と、それに伴う新たな検証作業とが、少なくとも必要となるだろう。

以上の通り、従来のＡＣＡＲＳルータは、累進的なアーキテクチャではない。ＡＣＡＲＳサービスへの任意の新たな航空電子アプリケーションの導入は、ルータの新たな設定と、それに伴う新たな検証とを必要とする。

本発明の目的は、累進的な通信アーキテクチャを実現するＡＣＡＲＳルータを提案することにある。このようなルータは、さまざまな航空会社の要望に応じて、容易にカスタマイズできる。

本発明は、ＡＣＡＲＳメッセージ通信システムとして定義される。上記通信システムは、ＡＣＡＲＳメッセージの送信及び／又は受信を行うように構成されたアプリケーションを内蔵した少なくとも１つの機上機器と、複数のサブネットワーク（ＨＦ／ＶＨＦ／ＳＡＴＣＯＭ）への又は複数のサブネットワークからの上記メッセージのルーティングを行うように構成されたルータとを具備する。上記機器及び上記ルータは、ＡＦＤＸネットワークに接続される。上記アプリケーションは、上記ネットワークを介して、ルータで動的に登録されるように構成される。ルータは、上記アプリケーションが自身に実際に登録されている場合にのみ、上記メッセージのルーティングを行う。

典型的に、アプリケーションは、ルータに登録リクエストを送信し、返信として登録確認を受信することによって、ルータでの登録を行う。上記確認は、リクエストに含まれた情報がルータによって妥当であると判断された場合にのみ、ルータによって返送される。

この場合、有利には、登録リクエスト及び肯定的な登録確認は、ＡＰＯＴＡ／ＴＦＴＰ／ＵＤＰ／ＩＰプロトコルスタックを用いて伝送される。ここで、ＡＰＯＴＡは、機器側では、ＴＦＴＰ層とアプリケーションとの間のプロトコルアダプテーション層を意味し、かつ、ルータ側では、ＡＲＩＮＣ ６１８層とＴＦＴＰ層との間のプロトコルアダプテーション層を意味する。

第１変形実施態様によれば、ルータは、上記アプリケーションからの及び上記複数のサブネットワークのうちの１つへのＡＣＡＲＳメッセージのフロー制御を実行するように構成される。

ルータは、各メッセージのサイズを受信バッファの利用可能な容量と比較し、利用可能な容量が上記メッセージのサイズよりも小さかった場合に、拒否メッセージを上記アプリケーションに返送することによって、上記アプリケーションからのＡＣＡＲＳメッセージのフローを制御する。

第２変形実施態様によれば、ルータは、上記アプリケーションに対してテストメッセージを周期的に送信する。第１タイマは、送信のたびに所定の第１値（Ｔ_ｔｅｓｔ）でリロードされる。テストメッセージは、上記第１タイマがタイムアウトするたびに送信される。上記第１タイマのタイムアウトの前にルータがテストメッセージの受信確認を受信しなかった場合、上記アプリケーションの障害が検出される。

有利には、上記アプリケーションは、ルータに自身が登録されている間、かつテストメッセージの受信のたびに、上記第１値よりも大きい第２値（Ｔ_ｍｏｎ）で第２タイマをロードする。テストメッセージを受信するより前に上記第２タイマがタイムアウトした場合、ルータの障害が検出される。

代替実施態様に関係なく、ルータは、登録済みアプリケーションからのメッセージに影響するエラーを検出した場合に、登録済みアプリケーションのリストから、上記アプリケーションを特定するコードを削除することによって、当該アプリケーションの登録を抹消する。

同様に、上記アプリケーションは、ルータからのメッセージに影響するエラーを検出した場合に、当該ルータの登録を抹消する。上記アプリケーションのメッセージは、ルータでの伝送を保留されるが、上記複数のサブネットワークのうちの１つにルーティングされる。

また、本発明は、上記で定義された通信システムを具備した航空機に関する。

本発明のその他の特徴及び利点は、発明の好適な実施形態及び添付の図面から明らかとなる。

当分野では既知のＡＣＡＲＳルータを使用する機上通信システムの構成を概略的に示す。 本発明の一実施形態によるＡＣＡＲＳルータを使用する機上通信システムの構成を概略的に示す。 図２のシステムに適用されるプロトコルスタックを概略的に示す。 図３のＡＰＯＴＡプロトコル層の第１機能を概略的に示す。 本発明による通信システムにおいて、ルータでリモートアプリケーションを動的に登録するための方法を概略的に示す。

以降では、航空機がＡＦＤＸ（Avionics Full Duplex，航空電子機器全二重）ネットワークを備えていると仮定する。航空用に開発されたＡＦＤＸネットワークが交換イーサネット（登録商標）ネットワークに基づいていること、及び、それがＡＲＩＮＣ ６６４規格のパート７で規格化されていることに留意されたい。このネットワークの詳細な説明については、特に、以下のＵＲＬで入手可能な「AFDX protocol tutorial」と題された文書を参照されたい。
http://sierrasales.com/pdfs/AFDXTutorial.pdf

本発明の基本となる発想は、ＡＦＤＸネットワークに接続された機器の端末部（エンドシステム）に導入される任意のアプリケーションが、ＡＣＡＲＳ通信サービスを使用できるように、ルータで動的に登録されるようなプロトコルを提供することにある。実際には、関連するプロトコルは、あたかも、当該リモートアプリケーションがルータに内蔵されているかのように、又は、機上機器がルータを用いてＡＲＩＮＣ ４２９専用リンクを介してＡＲＩＮＣ ６１９プロトコルを使用しているかのように、ＡＣＡＲＳ通信サービスへのアクセスを予め登録された任意のリモートアプリケーションに拡張する。

図２は、本発明の一実施形態によるＡＣＡＲＳルータ２００を使用する機上通信システムを示す。ルータ２００と、符号ｃｌｉｅｎｔ ａｐｐｌ＿１、ｃｌｉｅｎｔ ａｐｐｌ＿２、…、ｃｌｉｅｎｔ ａｐｐｌ＿Ｎを付された複数のアプリケーションをそれぞれ内蔵した１つ以上の機器２１０とが、ＡＦＤＸ２２０に接続されている。機器２１０は、ＡＲＩＮＣ ６６４規格における端末（エンドシステム）である。ルータは、複数のサブネットワーク、特に、ＨＦ、ＶＨＦ、ＳＡＴＣＯＭサブネットワークや、ＷｉＭＡＸ又はＷｉ−Ｆｉサブネットワークを介して、ＡＣＡＲＳメッセージのルーティングを行うように構成される。当然ながら、サブネットワークは、列挙したものに限定されない。

各クライアントアプリケーションｃｌｉｅｎｔ ａｐｐｌ＿１，ｃｌｉｅｎｔ ａｐｐｌ＿２，…，ｃｌｉｅｎｔ ａｐｐｌ＿Ｎは、ＡＣＡＲＳサービスを使用する機能を有する。このためには、各クライアントアプリケーションは、以降に記載される手続きに従って、ルータに予め登録されていなければならない。ルータに新たなアプリケーションを追加した際、そのようなアプリケーションを再度検証しないで済ますためには、ルータのハードウェア構成又はソフトウェア構成に何らかの修正を必要とする。このようなアーキテクチャが、開発時に多大なモジュール化及び柔軟化を提供できるということに留意されたい。特に、同一のルータのままで、ＡＣＡＲＳ通信システムを容易にカスタマイズすることと、ルータに専用のアプリケーションを一体化することとが可能となる。

図３は、クライアントアプリケーション側とＡＣＡＲＳルータ側とにそれぞれ適用されるプロトコルスタック３１０，３００を概略的に示す。

各スタックの下位プロトコル層は、ＡＦＤＸネットワークのそれら、すなわち、イーサネットリンク層と、ＩＰネットワーク層と、ＵＤＰトランスポート層とから成る。

クライアントアプリケーション側において、図では「ＡＣＡＲＳデータリンクアプリケーション」と示されたアプリケーション層は、従来のＡＲＩＮＣ ６２０形式で、ルータにＡＣＡＲＳメッセージを伝送する。しかしながら、ＡＲＩＮＣ ６１９ファイル転送プロトコルを用いることによってＡＲＩＮＣ ４２９リンクを介してこれらのメッセージが伝送される従来技術とは異なり、本実施例では、ＡＣＡＲＳメッセージは、ＴＦＴＰ（Trivial File Transfer Protocol）セッションによる転送の前に、ＡＰＯＴＡ（ACARS Protocol Over TFTP and AFDX）と称されるプロトコルアダプテーション層によって伝送される。ＴＦＴＰプロトコルの詳細な説明については、ＩＥＴＦサイトで入手可能なＲＦＣ １３５０文書を参照されたい。本明細書中では、単純に、ＴＦＴＰプロトコルは、トランスポート層下でＵＤＰを使用してファイル転送を行うための非常にシンプルなプロトコルであると考える。

プロトコルスタック３１０におけるＡＰＯＴＡ層の役割は、リモート航空電子アプリケーションに（ＳＡＰ又はサービスアクセスポントとして）ＡＣＡＲＳサービスを提供すること、換言すれば、このアプリケーションのレベルで、ＡＣＡＲＳサービスをリモートで導入することにある。これを行うために、ＡＰＯＴＡプロトコル層は、ＡＣＡＲＳサービスプリミティブを用いてアプリケーション層の上位層と対話するとともに、ファイル転送プリミティブ（ＦＴサービスプリミティブ）を用いて下位層と対話する。また、プロトコルスタック３００の対となる部分と、ＡＰＯＴＡ−ＰＤＵ（Protocol Data unit）と称されるパケットを交換する。

ルータ側では、ＡＲＩＮＣ ６１８プロトコル層は、地上とのＡＣＡＲＳ通信を管理する。上記と同様に、スタック３００のＡＰＯＴＡプロトコル層は、ＡＣＡＲＳサービスプリミティブを用いて上位層と対話するとともに、ファイル転送サービスプリミティブを用いて下位層と対話する。しかしながら、プロトコルスタック３１０とは異なり、ＡＰＯＴＡプロトコル層は、いかなるＡＣＡＲＳサービスも上位層へ提供しない。その主な機能は、ＴＦＴＰ層を介したファイル転送によるＡＣＡＲＳメッセージの伝送を提供することである。

具体的には、ＡＰＯＴＡプロトコル層は、以下の機能を提供する。
・リモートアプリケーションにおける、ルータのＡＣＡＲＳサービスのリモート導入
・ＡＣＡＲＳサービスのクライアントへのリモートアプリケーションの動的登録
・ダウンリンクのフロー制御
・クライアントアプリケーションの障害検出
・ＡＣＡＲＳサービスのロス検出
・エラー対処
当然ながら、機能はこれらに限定されない。

図４は、ダウンリンク、すなわち、空対地（Ａ／Ｇ）リンクに対するＡＣＡＲＳサービスのリモート導入メカニズムを概略的に示す。

ＡＰＯＴＡプロトコル層は、ステップ４１０で、ＡＣＡＲＳサービスプリミティブのほか、ファイル転送プリミティブを生成することによって、それらの利用可能なパラメータをエンコードする。転送しようとするファイルには、１つ以上のＡＰＯＴＡ−ＰＤＵパケットが含まれる。図中に「＃Ｆｉｌｅｎａｍｅ」と示されたファイルの名称は、通常、ソースアプリケーションを識別するコードと、アドレス（すなわち、ルータ）を識別するコードと、ファイルに含まれたメッセージのタイプを識別するコードとを含む。

ＡＰＯＴＡプロトコル層は、ステップ４２０で、ＴＦＴＰ層に命令し、ＦＴ−Ｗｒｉｔｅと示されたファイル転送プリミティブを用いて、ＡＰＯＴＡ ＰＤＵパケットを含んだファイルを転送する。次いで、ＴＦＴＰ層は、ＲＦＣ １３５０規格に従って、ＴＦＴＰ ＰＤＵパケットとして、ファイル＃Ｆｉｌｅｎａｍｅを転送する。これらの規格化されたパケットは、ファイル転送プロトコルＴＦＴＰを用いて、ＡＦＤＸネットワークを介してルータに転送される。スタッ３００のＡＰＯＴＡプロトコル層は、ＦＴ−Ｄａｔａ−Ｉｎｄプリミティブを用いて、ファイル＃Ｆｉｌｅｎａｍｅの受信を通知される。ＡＰＯＴＡプロトコル層がファイルを受け入れた場合、ファイルに含まれたＡＰＯＴＡ−ＰＤＵパケットが復元される。ステップ４４０において、ＡＰＯＴＡ−ＰＤＵパケットからＡＣＡＲＳメッセージが抽出され、ＡＲＩＮＣ ６１８プロトコル層に伝送される。アップリンクに対しては、スタック３００及びスタック３１０のＡＰＯＴＡプロトコル層は、対照的な方法で動作する。

本発明によれば、リモートアプリケーションによるＡＣＡＲＳメッセージの送信は、図５に示された手続きに従って、ルータに当該アプリケーションが予め登録されていることを前提とする。図中には、スタック３００及びスタック３１０の上位３つのプロトコル層だけが記載されているが、これが簡略化のためであることに留意されたい。

手続きは、アプリケーションをＡＣＡＲＳサービスプリミティブとして登録するためのリクエストによって開始される。リクエストは、図中では、Ａ−Ｒｅｇ−ｒｅｑと記され、ＡＰＯＴＡプロトコル層に送信される。このプリミティブによって、リモートアプリケーションが、ルータにおいて自身を新たなクライアントとして宣言するとともに、ＡＣＡＲＳラベル及びサブラベルを示すことが可能となる。ラベルは、アプリケーションが地上への送信と地上からの受信とのどちらを望むかを示す。

次いで、ＡＰＯＴＡプロトコル層は、ファイル名＃Ｆｉｌｅｎａｍｅ（ＲｅｇＲｅｑ）と、図ではＲｅｇＲｅｑ ＰＤＵと示されたＡＰＯＴＡ ＰＤＵパケットと、ＴＦＴＰポート番号（図示せず）とをパラメータとして有したファイル転送サービスプリミティブ（ＦＴ−Ｗｒｉｔｅ）を生成する。ファイル名には、送信されたメッセージのタイプのほかに、ソースアプリケーションを識別するコードが含まれる。この場合、メッセージのタイプは、登録リクエストである。

ルータによる受信時、ＴＦＴＰ層は、受信したファイル名＃Ｆｉｌｅｎａｍｅ（ＲｅｇＲｅｑ）と、ＲｅｇＲｅｑ ＰＤＵパケットとを伝送する。ＲｅｇＲｅｑパケットには、特に、アプリケーションが予約を望むＡＣＡＲＳラベル及びサブラベルのリストが含まれる。

ルータのＡＰＯＴＡ層は、ファイル名及び／又は伝送されたＲｅｑＲｅｑ ＰＤＵパケットに含まれた情報に基づいて、登録リクエストが妥当であるか否かをチェックする。妥当である場合、ルータは、登録確認メッセージを返す前に、関連するアプリケーションのコードをローカルで登録する。逆に、登録リクエストが失敗した場合、ルータは、登録失敗メッセージを送り返す。登録確認又は登録失敗メッセージの送信は、すでに説明した通り、ファイル転送サービスプリミティブ（ＦＴ−Ｗｒｉｔｅ）を用いて実行される。本実施例では、登録が確認されると、ＡＰＯＴＡ層は、ファイル名＃Ｆｉｌｅｎａｍｅ（ＲｅｇＲｅｑ）及びＲｅｇＣｏｎｆ ＰＤＵパケットをパラメータとして用いて、上記プリミティブを生成する。

端末による受信時、確認メッセージは、ＡＰＯＴＡ層によって処理され、確認メッセージが、Ａ−Ｒｅｇ−ｃｏｎｆと示されたＡＣＡＲＳサービスプリミティブを用いて、クライアントアプリケーションに伝送される。

また、ＡＰＯＴＡプロトコル層は、ダウンリンクのフローを制御する機能を有する。有利には、このフロー制御は、ＡＦＤＸネットワーク（１００Ｍｂ／ｓ）とＶＨＦ／ＨＦ／ＳＡＴＣＯＭサブネットワーク（３１ｋｂ／ｓ未満）との間のスループットの不均衡性に起因した、ルータの高い輻輳リスクに対して提供される。一方、アップリンクではフロー制御が必要とされないことに留意されたい。

ルータにおいて登録が処理された後、リモートアプリケーションは、ＡＣＡＲＳメッセージを送信する。これを行うために、ファイル転送サービスプリミティブ（ＦＴ−Ｗｒｉｔｅ）が、リモートアプリケーションのＡＰＯＴＡ層によって、ルータのＡＰＯＴＡ層に転送される。このプリミティブは、特にリモートアプリケーションのコードを含んだファイル名と、メッセージのタイプ（アップリンクか、ダウンリンクか）と、メッセージのサイズとを、パラメータとして有する。

ルータのＡＰＯＴＡ層がこのリクエストを受信したとき、ＡＰＯＴＡ層は、最初に、リモートアプリケーションが登録済みのものであるか否かをチェックする。未登録の場合、リクエストは拒否され、ファイル転送は中断される。次いで、フロー制御の実行が必要か否かを判断するために、メッセージのタイプがチェックされる。必要な場合（ダウンリンクの場合）、メッセージのサイズが受信バッファの利用可能な領域よりも小さいか否かがチェックされる。容量が充分にある場合、ＴＦＴＰ転送がルータによって受理される。容量が不足した場合、リクエストは拒否され、ルータのＡＰＯＴＡ層は、この拒否を示すサービスプリミティブを用いて、リモートアプリケーションのＡＰＯＴＡ層にこのことを通知する。そして、リモートアプリケーションのＡＰＯＴＡ層は、新たなリクエストの送信を停止する。

バッファに格納されたメッセージの地上への送信が完了したこと、又はルータがメッセージパージ命令を受信したことによって、ＡＣＡＲＳルータの受信バッファが空になったとき、このことが、それぞれ、地上への送信の確認及びメッセージのパージを示すサービスプリミティブを用いて、リモートアプリケーションのＡＰＯＴＡ層に通知される。これらのプリミティブのうちのいずれかを受信したとき、リモートアプリケーションのＡＰＯＴＡ層は、新たなリクエストの送信が可能となる。

有利には、また、ファイル転送サービスプリミティブ（ＦＴ−Ｗｒｉｔｅ）の引数としてのファイル名には、優先度の指示子及び／又はルーティング方式の指示子が含まれる。これらの指示子によって、ルータは、一方においては、個々のフローを階層的に順序付けることと、他方においては、それら個々の可用性レベルに応じて、最適なＨＦ／ＶＨＦ／ＳＡＴＣＯＭ媒体を個々のメッセージ毎に選択することとが可能となる。

また、ＡＰＯＴＡプロトコル層は、障害の発生しているクライアントアプリケーションを検出できる。アップリンクを介して送信されたメッセージをリモートアプリケーションが処理できない場合、そのようなリモートアプリケーションには障害が発生している。

そのような障害を検出するために、ルータのＡＰＯＴＡプロトコル層は、登録済みアプリケーションのそれぞれにテストメッセージ（明細書中では「Ｔｅｓｔｌｉｎｋ」と称する）を定期的に送信する。送信のたびに、タイマが所定の値（Ｔ_ｔｅｓｔ）でリロードされ、タイマがタイムアウトしたとき、新たなテストメッセージが送信される。メッセージ転送が複数のアプリケーションのうちの１つに対して失敗した場合、すなわち、上記タイマがタイムアウトするより前に、ルータがこのアプリケーションから受信確認を受信しなかった場合、当該アプリケーションには障害が発生していると見なされる。この検出メカニズムによって、ルータは、リモートアプリケーションがもはや利用不可能であることを出来るだけ早く見つけ出し、以後、当該リモートアプリケーションへの地上からのメッセージを拒否することができる。

同様に、リモートアプリケーションは、ＡＣＡＲＳサービスのロス、例えば、ＡＦＤＸネットワークに問題が発生したことを検出できる。これを実行するために、リモートアプリケーションは、ルータに登録されている間、所定の値Ｔ_ｍｏｎ＞Ｔ_ｔｅｓｔでタイマをロードする。そして、タイマは、テストメッセージ（Ｔｅｓｔｌｉｎｋ）の受信のたびに、所定の値Ｔ_ｍｏｎでリロードされる。タイマがタイムアウトした場合、アプリケーションは、テストメッセージが届かず、ＡＣＡＲＳサービスが失われたという結論に達する。

ＡＰＯＴＡプロトコル層によれば、ＡＣＡＲＳサービスに生じたエラーに適切に対処することが可能となる。具体的には、例えば、ファイル転送が失敗したこと、受信したメッセージが適切な形式でなかったこと、転送リクエストの引数としてのファイル名が誤っていたこと、又は、さらなるメッセージがプロトコル層の現在の状態では許可されなかったことなどを理由にエラーが検出された場合、このエラーは、以下の方法で処理される。

リモートアプリケーションからのメッセージに影響するエラーがルータによって検出されたとき、アプリケーションは、ＡＣＡＲＳサービスから、単純に「登録抹消」される。具体的には、登録済みアプリケーションのリストから当該アプリケーションのコードを削除することによって、アプリケーションの登録が抹消される。アプリケーションには、メッセージによってこのことが通知され、ＡＣＡＲＳサービスに再びアクセス可能となるためには、再度の登録を要する。

同様に、ルータのメッセージに影響するエラーが検出された場合、アプリケーションは、ＡＣＡＲＳサービスから「登録抹消」され、メッセージによってこのことが通知される。しかしながら、先の場合とは異なり、当該アプリケーションのコードは、ルータで扱われるアプリケーションのリストからは削除されない。当該アプリケーションのステータスは、単に、「登録済み」から「登録抹消」に切り換わる。それによって、ルータは、転送のためにバッファに留め置かれたこのアプリケーションからのメッセージを地上に引き続き送信できる。

２００ ＡＣＡＲＳルータ
２１０ クライアントアプリケーション内蔵機器
２２０ ＡＦＤＸネットワーク
３００ ＡＣＡＲＳルータ側のプロトコルスタック
３１０ クライアントアプリケーション側のプロトコルスタック

Claims (9)

1. ＡＣＡＲＳメッセージの送信及び／又は受信を行うように構成されたアプリケーションを内蔵した少なくとも１つの機上機器と、複数のサブネットワーク（ＨＦ／ＶＨＦ／ＳＡＴＣＯＭ）への又は複数のサブネットワーク（ＨＦ／ＶＨＦ／ＳＡＴＣＯＭ）からの前記メッセージのルーティングを行うように構成されたルータとを具備したＡＣＡＲＳメッセージ通信システムであって、
   前記機器及び前記ルータは、ＡＦＤＸネットワークに接続され、
   前記アプリケーションは、前記ネットワークを介して、ルータで動的に登録されるように構成され、
   ルータは、前記アプリケーションが自身に実際に登録されている場合にのみ、前記メッセージのルーティングを行い、
   前記アプリケーションは、ルータに登録リクエストを送信し、返信として登録確認を受信することによって、ルータでの登録を行い、
   登録リクエスト及び登録確認は、ＡＰＯＴＡ／ＴＦＴＰ／ＵＤＰ／ＩＰプロトコルスタックを用いて送信され、
   ＡＰＯＴＡは、機器側では、ＴＦＴＰ層とアプリケーションとの間のプロトコルアダプテーション層を意味し、かつ、ルータ側では、ＡＲＩＮＣ ６１８層とＴＦＴＰ層との間のプロトコルアダプテーション層を意味することを特徴とする通信システム。
2. 前記アプリケーションは、リクエストに含まれた情報がルータによって妥当であると判断された場合にのみ、登録確認を受信することを特徴とする請求項１に記載の通信システム。
3. ルータが、前記アプリケーションからの及び前記複数のサブネットワークのうちの１つへのＡＣＡＲＳメッセージのフロー制御を実行するように構成されることを特徴とする請求項１に記載の通信システム。
4. ルータは、各メッセージのサイズを受信バッファの利用可能な容量と比較し、利用可能な容量が前記メッセージのサイズよりも小さかった場合に、拒否メッセージを前記アプリケーションに返送することによって、前記アプリケーションからのＡＣＡＲＳメッセージのフローを制御することを特徴とする請求項３に記載の通信システム。
5. ルータが、前記アプリケーションに対してテストメッセージを周期的に送信し、
   第１タイマは、送信のたびに所定の第１値（Ｔ_ｔｅｓｔ）でリロードされ、
   テストメッセージは、前記第１タイマがタイムアウトするたびに送信され、
   前記第１タイマのタイムアウトの前にルータがテストメッセージの受信確認を受信しなかった場合、前記アプリケーションの障害が検出されることを特徴とする請求項１ないし４のいずれか１項に記載の通信システム。
6. 前記アプリケーションが、ルータに自身が登録されている間かつテストメッセージの受信のたびに、前記第１値よりも大きい第２値（Ｔ_ｍｏｎ）で第２タイマをロードし、
   テストメッセージを受信するより前に前記第２タイマがタイムアウトした場合、ルータの障害が検出されることを特徴とする請求項５に記載の通信システム。
7. ルータは、登録済みアプリケーションからのメッセージに影響するエラーを検出した場合に、登録済みアプリケーションのリストから、前記アプリケーションを特定するコードを削除することによって、当該アプリケーションの登録を抹消することを特徴とする請求項１ないし６のいずれか１項に記載の通信システム。
8. 前記アプリケーションは、ルータからのメッセージに影響するエラーを検出した場合に、自身のステータスを「登録済み」から「登録抹消」に切り換えることによって、当該ルータとの間の通信を一旦中止するとともに、当該ルータで伝送中の前記アプリケーションのメッセージは前記複数のサブネットワークのうちの１つにルーティングされるようにすることを特徴とする請求項１ないし７のいずれか１項に記載の通信システム。
9. 請求項１ないし８のいずれか１項に記載の通信システムを具備することを特徴とする航空機。

Images