セキュアなファイル転送手段
本発明は、搭載用遠隔通信システムに関する。本システムは、セキュアエリアと非セキュアエリアとに区分けされ、セキュアエリアの第１遠隔通信機器ユニットと、非セキュアエリアの第２遠隔通信機器ユニットと、第１機器ユニットから第２機器ユニットへの第１片方向リンクとを少なくとも具備する。上記第１機器ユニットは、第１プロトコルに従って上記第１リンクでデータを送信するように構成される。本システムは、第２機器ユニットから第１機器ユニットへの、第２プロトコルに従う第２リンクをさらに具備する。上記第２プロトコルの上位２つのレイヤは、第１プロトコルの上位２つのレイヤとは異なる。上記第２機器は、第２プロトコルに従ってフレーム内にカプセル化された第１プロトコルに従うメッセージとして、第２リンクでデータの送信を行うように構成される。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、搭載用（on-board）遠隔通信システム、具体的には、航空機に搭載される遠隔通信システムの分野に関する。
【背景技術】
【０００２】
近年、いくつかの航空会社では、乗客に対して、フライト中の遠隔通信サービス、具体的には、衛星リンクを介したインターネットアクセス及び電子メールの送受信を可能にするサービスを提供している。このために、航空機の客室は、乗客が普段通りに接続可能なイーサネット（登録商標）タイプの有線ネットワーク又は無線ＬＡＮネットワーク（ＩＥＥＥ ８０２．１１ ｂ／ｇ）を備えている。このような通信システムについては、例えば、特許文献１を参照されたい。
【０００３】
また、パイロット、整備員、及び航空機乗務員は、機上ネットワークにリンクされている制御端末を持つ。機上ネットワークは、明白なセキュリティ上の理由で非セキュアエリアとセキュアエリアとに区分けされ、乗客が前者にはアクセスできるが後者にはアクセスできないようになっている必要がある。セキュアエリアは、航空機の情報及び制御システムを特に含み、コックピット及び空港に位置する。セキュアエリアは、従来の物理的アクセスコントロール手段によって保護されている。
【０００４】
機上ネットワークのセキュアエリアへのアクセスを禁止する容易かつ既知の１つの方法が、セキュアエリアと非セキュアエリアとの間のリンクを片方向リンクで提供することである。
【０００５】
図１は、セキュアエリアＡと非セキュアエリアＢとに区分けされた機上ネットワーク１００の概略図である。リンク１１０は、ＡからＢへの片方向リンクであり、例えば、ＡからＢへの通信方向に対応するシングルツイストペアケーブルを用いたイーサネット（登録商標）リンクである。しかしながら、このようなシステムは、効率よくエリアＡのセキュリティを保証するが、一方で、２つの重大な欠点を有する。まず、このシステムは、エリアＢからエリアＡへのいかなる通信も例外なく禁止してしまう。また、エリアＡからエリアＢへのデータ転送に対して、送信先機器は、データを送信した機器へ受信通知を返すことができない。これでは、最新の通信プロトコルとの互換性が取れず、その上、送信元機器から正しい転送手続に関するあらゆる種類の保証を奪ってしまう。
【０００６】
本発明の目的は、セキュアエリアと非セキュアエリアに区分けされた搭載用遠隔通信システムであって、セキュアエリアのプロテクトを大幅に低下させることなく、２つのエリア間で双方向通信を行う機会を提供するシステムを提案することである。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】国際公開第００／１４９８７号パンフレット
【非特許文献】
【０００８】
【非特許文献１】"CES White Paper on AFDX"，http://www.ces.ch
【非特許文献２】"The TFTP Protocol"，http://www.ietf.org/rfc/rfc783.txt
【非特許文献３】"ARINC Protocol Tutorial"，http://www.condoreng.com
【発明の概要】
【課題を解決するための手段】
【０００９】
本発明は、セキュアエリアと非セキュアエリアとに区分けされ、セキュアエリアの第１遠隔通信機器ユニットと、非セキュアエリアの第２遠隔通信機器ユニットと、第１機器ユニットから第２機器ユニットへの第１片方向リンクとを少なくとも具備する搭載用遠隔通信システムによって定義される。上記第１機器ユニットは、第１プロトコルに従って上記第１リンクでデータを送信するように構成される本システムは、第２プロトコルに従う第２機器ユニットから第１機器ユニットへの第２リンクを具備する。上記第２プロトコルの上位２つのレイヤは、第１プロトコルの上位２つのレイヤとは異なる。上記第２機器ユニットは、第２プロトコルに従ってフレーム内にカプセル化された第１プロトコルに従うメッセージとして、第２リンクでデータの送信を行うように構成される。
【００１０】
有利には、第１プロトコルの上位２つのレイヤは、イーサネット（登録商標）レイヤである。換言すれば、第１プロトコルのスタックは、ＴＦＴＰ／ＵＤＰ／ＩＰ／Ｅｔｈｅｒｎｅｔ（登録商標）である。
【００１１】
第１実施態様に従い、第２プロトコルの上位２つのレイヤは、ＡＲＩＮＣ ４２９レイヤである。
【００１２】
第２実施態様に従い、第２プロトコルの上位２つのレイヤは、ＣＡＮレイヤである。
【図面の簡単な説明】
【００１３】
【図１】最新の技術では既知である搭載用ネットワークの概略図である。
【図２】本発明の第１実施形態による搭載用遠隔通信システムの概略図である。
【図３】セキュアエリアの機器ユニットと非セキュアエリアの機器ユニットとの間の通信プロトコルを示す図である。
【図４】本発明の第２実施形態による搭載用遠隔通信システムの概略図である。
【図５】本発明の第３実施形態による搭載用遠隔通信システムの概略図である。
【図６】ＡＲＩＮＣ ４２９プロトコルに準拠したリンクで使用されるフレームを示す図である。
【発明を実施するための形態】
【００１４】
本発明のその他の特徴及び利点が、添付された図面を参照して、発明の好適な実施形態から明らかとなる。
【００１５】
本発明の第１の基本構想は、あるプロトコル（以後、第２プロトコルと称する）に準拠した、非セキュエリアからセキュアエリアへのリターンリンクを提供することにある。第２プロトコルの上位２つのレイヤは、セキュアエリアから非セキュアエリアへの通信に用いられるプロトコル（以後、第１プロトコルと称する）のそれらとは異なる。
【００１６】
本発明の第２の基本構想は、データ送信のために、セキュアエリアからのすべての制御メッセージと共に、シンプルかつ強固なファイル転送プロトコルを使用することにある。
【００１７】
図２は、本発明に従う搭載用遠隔通信システムの概略図である。
【００１８】
ＬＲＵ１及びＬＲＵ２は、それぞれ、セキュアエリアＡ及び非セキュアエリアＢに属する遠隔通信機器を示す。エリアＡ及びエリアＢに対応するサブネットワークは、イーサネット（登録商標）ネットワークを切り替えて、及び／又は、共有して使用する。例えば、エリアＡのサブネットワークは、ＡＦＤＸ（Avionics Full Duplex Switched Ethernet（登録商標））ネットワークであってよい。ＡＦＤＸネットワークの説明については、サイトwww.ces.chで入手可能な文献"CES White Paper on AFDX"を参照されたい。リンク２４０及びリンク２４１のようなエリアＡ及びエリアＢのイーサネット（登録商標）リンクは、全二重タイプであってよい。一方で、リンク２１０のようなエリアＡからエリアＢへ向かう各イーサネット（登録商標）リンクは、単信タイプである必要がある。
【００１９】
本発明に従って、リンク２２０のようなエリアＢからエリアＡへ向かう各リンクは、リンク２１０のプロトコルとは異なるプロトコル、例えば、航空分野で一般に使用されるＡＲＩＮＣ ４２９プロトコルに準拠している。ＡＲＩＮＣ ４２９プロトコルは、リンクレイヤと同様に、物理レイヤを規格化する。ＡＲＩＮＣ ４２９プロトコルは、一対のツイストケーブルを使用し、ＢからＡへの選択された片方向送信を行う。
【００２０】
あるいは、エリアＢからエリアＡへ向かうリンクは、自動車の分野で普及しているＣＡＮ（Control Area Network）プロトコルに従ってもよい。ＣＡＮプロトコルのリンクレイヤ及び物理レイヤの一部は、ＩＳＯ １１８９８−１規格で規格化される。このプロトコルは、シンプルケーブル対上での半二重タイプの送信を提供する。実際には、本発明においては、エリアＢからエリアＡへの送信のみが使用される。
【００２１】
図３は、本発明の一実施形態に従う遠隔通信システムに実装されるプロトコルスタックを示す。機器ＬＲＵ１は、片方向イーサネット（登録商標）リンク３１０での送信のための第１プロトコルスタック３３０と、リターンリンクでのデータ受信のための第２プロトコルスタック３５０とを使用する。リンク３２０は、ＡＲＩＮＣ ４２９プロトコルに準拠する。対称的に、機器ＬＲＵ２は、イーサネット（登録商標）リンク３１０でのデータ受信のための第１プロトコルスタック３４０と、リンク３２０でのデータ送信のための第２プロトコルスタック３６０とを使用する。
【００２２】
有利には、第１プロトコルスタック３３０，３４０は、ＴＦＴＰ／ＵＤＰ／ＩＰ／Ｅｔｈｅｒｎｅｔ（登録商標）から成る。ＴＦＴＰ（Trivial File Transfer Protocol）がＩＥＴＦによって規格化されたファイル転送プロトコルであることに留意されたい。包括的な説明は、www.ietf.org/rfc/rfc783.txt中のＲＦＣ １３５０を参照されたい。
【００２３】
機器ＬＲＵ１がデータファイルをＬＲＵ２へ送信しようとするとき、ＴＦＴＰレイヤは、ライトリクエスト（ＷＲＱ）によって一時セッションをオープンするとともに、ファイルを５１２バイトのブロックに分割する。ブロックは、ＴＦＴＰヘッダとの連結後に、ＵＤＰトランスポートレイヤへ送信される。ＵＤＰレイヤは、当業者には既知のように、接続確立やエラー時の再送を行うことなく、メッセージレベルサービスを提供する。そして、メッセージのＩＰデータグラムは、従来通りイーサネット（登録商標）フレームで送信される。受信時には、データは、プロトコルスタック３４０とは逆の方向に向かう。受信したＴＦＴＰメッセージ毎に、機器ＬＲＵ２は、ＲＦＣ １３５０規格に従って、受信通知メッセージを送信する。このメッセージは、３６０で示され、かつ以下に記載されるように、ＡＲＩＮＣ ４２９フレームにカプセル化される。ＡＲＩＮＣフレームは、従来通りリンク３２０で送信され、かつメッセージは、３５１でデカプセル化される。故に、スタック３３０及びスタック３４０のＴＦＴＰレイヤに対して、あたかもトランスポートが全二重リンクによってＩＰネットワーク上で行われるかのように動作する。
【００２４】
機器ＬＲＵ２がデータファイルをＬＲＵ１へ送信しなければならないとき、一時セッションは、リードリクエスト（ＲＲＱ）によって、ＬＲＵ１主導でオープンされる。送信されるファイルは、スタック３４０のＴＦＴＰレイヤによって、５１２バイトのブロックに分割される。ブロックは、対応するＴＦＴＰヘッダと連結される。このようにして得られたＴＦＴＰメッセージは、３６１に示され、かつ以下で詳細に記載されるように、ＡＲＩＮＣフレームにカプセル化される。ＡＲＩＮＣフレームは、従来通りリンク３２０で送信されるとともに、３５１でデカプセル化される。ついで、機器ＬＲＵ１は、スタック３３０、すなわち、イーサネット（登録商標）単信リンク３１０を介して、受信通知メッセージを送信する。受信通知メッセージは、プロトコルスタック３４０を介して、逆方向へ届けられる。ここで再び、スタック３３０，３４０のＴＦＴＰレイヤに対して、あたかもトランスポートが全二重リンクによってＩＰネットワーク上で行われるかのように動作する。
【００２５】
ＡＲＩＮＣリンク３２０と、第１プロトコルのメッセージを第２プロトコルのフレームにカプセル化するメカニズムとは、セキュアエリアとは隔てられたアクセスを形成する。
【００２６】
非セキュアエリアの機器ＬＲＵ２は、例えば、乗客の端末が接続可能なプロキシサーバとして、航空機に常設される。この場合、ＴＦＴＰメッセージカプセル化を実現するコンバージョンゲートウェイは、上記サーバに位置する。
【００２７】
図４は、本発明の第２実施形態に従う搭載用遠隔通信システムの概略図である。第１実施形態とは異なり、セキュアエリアのいくつかの機器ユニットＬＲＵ１，ＬＲＵ３，ＬＲＵ５は、非セキュアエリアの機器ユニットＬＲＵ２と通信できる。このために、マルチキャストタイプのＡＲＩＮＣリンク４２０は、関係する機器へのリターンパスとして機能する。ＡＲＩＮＣリンクは、送信源（emitter）には接続できないが、最大２０台の受信機に対応できるということに留意されたい。
【００２８】
図５は、本発明の第３実施形態に従う搭載用遠隔通信システムの概略図である。第１及び第２実施形態とは異なり、ＬＲＵ１などのセキュアエリアの機器ユニットは、非セキュアエリアの複数の機器ユニットＬＲＵ２，ＬＲＵ４，ＬＲＵ６と通信できる。このために、機器ＬＲＵ１は、複数のＡＲＩＮＣ ４２９インタフェースを備える。機器ユニットＬＲＵ２，ＬＲＵ４，ＬＲＵ６を上記インタフェースにそれぞれ接続する複数の下りＡＲＩＮＣリンク５２１，５２２，５２３は、リターンパスとして機能する。この実施形態では、ＣＡＮバスが、複数の送信源にリンクできるＣＡＮバスとして、ＡＲＩＮＣリンクの代わりに有利に使用できる。
【００２９】
セキュアエリアの複数の機器ユニットが非セキュアエリアの複数の機器ユニットと通信できるようにするために、第２及び第３実施形態が第４実施形態へと有利に組み合わせできることが当業者には明白である。この場合、いくつかのマルチキャストタイプのＡＲＩＮＣリンクは、セキュアエリアの機器ユニットへのリターンパスとして機能する。変形例に従って、ＣＡＮバスは、非セキュアエリアの機器ユニットとセキュアエリアの機器ユニットとの間のリターン機能を確保する。
【００３０】
上記の実施形態は、ＴＦＴＰメッセージを第２プロトコル、例えば、ＡＲＩＮＣ ４２９プロトコルのフレームにカプセル化するメカニズムを使用する。ＡＲＩＮＣ ４２９プロトコルの詳細な説明は、サイトwww.condoreng.comで入手可能な"ARINC Protocol Tutorial"と題された文献を参照されたい。
【００３１】
図６は、ＡＲＩＮＣフレームの概略図である。ＡＲＩＮＣフレームは、５つのフィールドから成る３２ビットのワードで構成されている。ビットＰは、パリティビットである。フィールドＳＳＭは、機器の動作状態を示す。１９ビットのフィールドＰＡＹＬＯＡＤは、ペイロードを含み、必要であれば、パディングビット（ＰＡＤ）が付加される。フィールドＳＤＩは、マルチキャスト送信の場合に、フレームの送信先の指示を可能にする。最後に、フィールドＬＡＢＥＬは、ペイロードに対応する航空電子工学パラメータと、それを構成するデータのフォーマットとを示す。
【００３２】
以後、ＴＦＴＰメッセージは、リターンパスでのカプセル化の後に送信できるもの、すなわち、ＡＣＫ、ＤＡＴＡ、ＥＲＲＯＲと見なされる。
【００３３】
図３を参照すると、機器ＬＲＵ１がデータファイルを機器ＬＲＵ２へ送信しようとするとき、機器ＬＲＵ１は、ライトリクエストメッセージ（ＷＲＱ）を機器ＬＲＵ２へ送信する。ＬＲＵ２は、ファイルを受信できる状態にあるならば、確認メッセージをＬＲＵ１へ返す。ついで、ファイルのデータブロックを含む受信したメッセージ毎に、機器ＬＲＵ２は、受信したブロックの数を示す確認メッセージをＬＲＵ１へ返す。ファイルの終端は、５１２バイト未満のブロックを受信したときに、スタック３４０のＴＦＴＰレイヤによって検出される。ライトリクエストを確認するための第１メッセージは、通常、ブロックナンバー０で示される。機器ＬＲＵ１がデータブロックを送信する際に、スタック３３０のＴＦＴＰレイヤは、タイマを設定する。タイマがアップする前に確認メッセージが受信されなければ、データブロックは、ＴＦＴＰメッセージによって再送信される。
【００３４】
ＴＦＴＰプロトコルの確認メッセージＡＣＫは、メッセージのタイプを識別する２バイトの第１オペレーションコードフィールド（Ｏｐｃｏｄｅ＝４）と、確認されたブロック受信数を与える２バイトの第２フィールドとを含む。カプセル化モジュール３６１は、第２オペレーションコードバイト（第１バイトは、確認メッセージのために常にゼロとなる）と、その次の、ブロック数の２バイトとを、第２プロトコルのフレームに格納する。カプセル化モジュール３６１は、データ転送に使用される送信元機器（ＬＲＵ１）及び送信先機器（ＬＲＵ２）のＵＤＰポート番号を、このメッセージに付加する。１バイトで符号化されたＵＤＰポート番号毎に、確認メッセージのために７バイトが送信されなければならず、３つのＡＲＩＮＣフレーム又は１つのＣＡＮフレームを要する。
【００３５】
機器ＬＲＵ１が機器ＬＲＵ２からデータファイルを受信しようとするとき、機器ＬＲＵ１は、リードリクエストＲＲＱを機器ＬＲＵ２へ送信する。機器ＬＲＵ２は、送信可能な状態にあるならば、関係するファイルの５１２バイトの第１ブロックを、確認通知として機器ＬＲＵ１へ直接送信する。機器ＬＲＵ１は、応答として、第１ブロックの確認メッセージＡＣＫを送信する。その過程は、上記の通り、ファイルの最終ブロックが送信されるまで続く。ブロックの送信後、スタック３４０のＴＦＴＰレイヤが所与の時間内に確認通知を受信しない場合、送信が繰り返される。
【００３６】
ＴＦＴＰプロトコルのデータメッセージＤＡＴＡは、メッセージのタイプを識別する２バイトの第１オペレーションコードフィールド（Ｏｐｃｏｄｅ＝３）と、送信したブロック数を与える２バイトの第２フィールドと、データブロックが格納された０≦ｎ≦５１２であるｎバイトのフィールドとを含む。
【００３７】
カプセル化モジュール３６１は、第２オペレーションコードバイト（第１バイトは、データメッセージのために常にゼロである）と、その次の、送信されたブロック数の２バイトと、最後の、関係するブロックのｎバイトとを、第２プロトコルのフレームに格納する。モジュール３６１は、データ転送に使用される送信元機器ＬＲＵ１及び送信先機器ＬＲＵ２のＵＤＰポート番号を、このメッセージに付加する。故に、ｎデータバイトのブロックの送信のためには、ｎ＋７バイトが送信されなければならず、Ｅ［（ｎ＋７）．８／１９］＋１のＡＲＩＮＣフレームと、ｎ＋７のＣＡＮフレームとを必要とする。ここで、Ｅ［ｘ］は、ｘの整数部を与える。
【００３８】
ＬＲＵ１によって送信されたライトリクエスト（ＷＲＱ）又はリードリクエスト（ＲＲＱ）がＬＲＵ２によって承諾できない場合、又はデータ転送中にエラーが発生した場合、スタック３４０のＴＦＴＰレイヤによって、エラーメッセージが送信される。
【００３９】
ＴＦＴＰプロトコルのエラーメッセージＥＲＲＯＲは、メッセージのタイプを識別する２バイトの第１オペレーションコードフィールド（Ｏｐｃｏｄｅ＝５）と、診断されたエラーのコードを含む２バイトの第２フィールドと、場合によっては、エラーを説明するＡＳＣＩＩ記号を含む第３フィールドとを含み、その後にゼロバイトが続く。この第３フィールドは、ここでは使用されない。
【００４０】
カプセル化モジュール３６１は、第２オペレーションコードバイト（第１バイトは、エラーメッセージのために常にゼロである）と、その次の、エラーコードの２バイトとを、第２プロトコルのフレームに格納する。最後に、モジュール３６１は、データ転送に使用される送信元機器（ＬＲＵ１）及び送信先機器（ＬＲＵ２）のＵＤＰポート番号を、このメッセージに付加する。故に、エラーメッセージの送信のためには、５バイトが送信されなければならず、３つのＡＲＩＮＣフレーム又は５つのＣＡＮフレームを必要とする。
【００４１】
第２実施形態のように、機器ＬＲＵ２がセキュアエリアの複数の機器ユニットにリンクされている場合、カプセル化モジュール３６１は、ＴＦＴＰメッセージの送信先に応じて、ＡＲＩＮＣフレームのＳＩＤフィールドの値を決定する。
【００４２】
しかしながら、ＴＦＴＰメッセージの送信先を区別できない第２プロトコルをシステムが使用する場合、モジュール３６１は、送信先機器のＩＰアドレスを、カプセル化されたメッセージに有利に付加する。
【００４３】
また、第３実施形態のように、非セキュアエリアの複数の機器ユニットがセキュアエリアの機器ユニットにリンクされる場合と、ＴＦＴＰメッセージの送信先機器ユニットによるＴＦＴＰメッセージを送信した送信元機器の判断ができない第２プロトコルをシステムが使用する場合、各モジュール３６１は、送信元機器のＩＰアドレスを、カプセル化されたメッセージに有利に付加する。
【００４４】
一般に、第４実施形態の場合には、各モジュール３６１は、ＴＦＴＰメッセージの送信元及び送信先機器それぞれのＩＰアドレスを、カプセル化されたメッセージに付加する。
【符号の説明】
【００４５】
３１０ 片方向イーサネット（登録商標）リンク
３２０ ＡＲＩＮＣリンク
３３０，３４０ 第１プロトコルスタック
３５０，３６０ 第２プロトコルスタック
３５１ デカプセル化モジュール
３６１ カプセル化モジュール
【技術分野】
【０００１】
この発明は、搭載用（on-board）遠隔通信システム、具体的には、航空機に搭載される遠隔通信システムの分野に関する。
【背景技術】
【０００２】
近年、いくつかの航空会社では、乗客に対して、フライト中の遠隔通信サービス、具体的には、衛星リンクを介したインターネットアクセス及び電子メールの送受信を可能にするサービスを提供している。このために、航空機の客室は、乗客が普段通りに接続可能なイーサネット（登録商標）タイプの有線ネットワーク又は無線ＬＡＮネットワーク（ＩＥＥＥ ８０２．１１ ｂ／ｇ）を備えている。このような通信システムについては、例えば、特許文献１を参照されたい。
【０００３】
また、パイロット、整備員、及び航空機乗務員は、機上ネットワークにリンクされている制御端末を持つ。機上ネットワークは、明白なセキュリティ上の理由で非セキュアエリアとセキュアエリアとに区分けされ、乗客が前者にはアクセスできるが後者にはアクセスできないようになっている必要がある。セキュアエリアは、航空機の情報及び制御システムを特に含み、コックピット及び空港に位置する。セキュアエリアは、従来の物理的アクセスコントロール手段によって保護されている。
【０００４】
機上ネットワークのセキュアエリアへのアクセスを禁止する容易かつ既知の１つの方法が、セキュアエリアと非セキュアエリアとの間のリンクを片方向リンクで提供することである。
【０００５】
図１は、セキュアエリアＡと非セキュアエリアＢとに区分けされた機上ネットワーク１００の概略図である。リンク１１０は、ＡからＢへの片方向リンクであり、例えば、ＡからＢへの通信方向に対応するシングルツイストペアケーブルを用いたイーサネット（登録商標）リンクである。しかしながら、このようなシステムは、効率よくエリアＡのセキュリティを保証するが、一方で、２つの重大な欠点を有する。まず、このシステムは、エリアＢからエリアＡへのいかなる通信も例外なく禁止してしまう。また、エリアＡからエリアＢへのデータ転送に対して、送信先機器は、データを送信した機器へ受信通知を返すことができない。これでは、最新の通信プロトコルとの互換性が取れず、その上、送信元機器から正しい転送手続に関するあらゆる種類の保証を奪ってしまう。
【０００６】
本発明の目的は、セキュアエリアと非セキュアエリアに区分けされた搭載用遠隔通信システムであって、セキュアエリアのプロテクトを大幅に低下させることなく、２つのエリア間で双方向通信を行う機会を提供するシステムを提案することである。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】国際公開第００／１４９８７号パンフレット
【非特許文献】
【０００８】
【非特許文献１】"CES White Paper on AFDX"，http://www.ces.ch
【非特許文献２】"The TFTP Protocol"，http://www.ietf.org/rfc/rfc783.txt
【非特許文献３】"ARINC Protocol Tutorial"，http://www.condoreng.com
【発明の概要】
【課題を解決するための手段】
【０００９】
本発明は、セキュアエリアと非セキュアエリアとに区分けされ、セキュアエリアの第１遠隔通信機器ユニットと、非セキュアエリアの第２遠隔通信機器ユニットと、第１機器ユニットから第２機器ユニットへの第１片方向リンクとを少なくとも具備する搭載用遠隔通信システムによって定義される。上記第１機器ユニットは、第１プロトコルに従って上記第１リンクでデータを送信するように構成される本システムは、第２プロトコルに従う第２機器ユニットから第１機器ユニットへの第２リンクを具備する。上記第２プロトコルの上位２つのレイヤは、第１プロトコルの上位２つのレイヤとは異なる。上記第２機器ユニットは、第２プロトコルに従ってフレーム内にカプセル化された第１プロトコルに従うメッセージとして、第２リンクでデータの送信を行うように構成される。
【００１０】
有利には、第１プロトコルの上位２つのレイヤは、イーサネット（登録商標）レイヤである。換言すれば、第１プロトコルのスタックは、ＴＦＴＰ／ＵＤＰ／ＩＰ／Ｅｔｈｅｒｎｅｔ（登録商標）である。
【００１１】
第１実施態様に従い、第２プロトコルの上位２つのレイヤは、ＡＲＩＮＣ ４２９レイヤである。
【００１２】
第２実施態様に従い、第２プロトコルの上位２つのレイヤは、ＣＡＮレイヤである。
【図面の簡単な説明】
【００１３】
【図１】最新の技術では既知である搭載用ネットワークの概略図である。
【図２】本発明の第１実施形態による搭載用遠隔通信システムの概略図である。
【図３】セキュアエリアの機器ユニットと非セキュアエリアの機器ユニットとの間の通信プロトコルを示す図である。
【図４】本発明の第２実施形態による搭載用遠隔通信システムの概略図である。
【図５】本発明の第３実施形態による搭載用遠隔通信システムの概略図である。
【図６】ＡＲＩＮＣ ４２９プロトコルに準拠したリンクで使用されるフレームを示す図である。
【発明を実施するための形態】
【００１４】
本発明のその他の特徴及び利点が、添付された図面を参照して、発明の好適な実施形態から明らかとなる。
【００１５】
本発明の第１の基本構想は、あるプロトコル（以後、第２プロトコルと称する）に準拠した、非セキュエリアからセキュアエリアへのリターンリンクを提供することにある。第２プロトコルの上位２つのレイヤは、セキュアエリアから非セキュアエリアへの通信に用いられるプロトコル（以後、第１プロトコルと称する）のそれらとは異なる。
【００１６】
本発明の第２の基本構想は、データ送信のために、セキュアエリアからのすべての制御メッセージと共に、シンプルかつ強固なファイル転送プロトコルを使用することにある。
【００１７】
図２は、本発明に従う搭載用遠隔通信システムの概略図である。
【００１８】
ＬＲＵ１及びＬＲＵ２は、それぞれ、セキュアエリアＡ及び非セキュアエリアＢに属する遠隔通信機器を示す。エリアＡ及びエリアＢに対応するサブネットワークは、イーサネット（登録商標）ネットワークを切り替えて、及び／又は、共有して使用する。例えば、エリアＡのサブネットワークは、ＡＦＤＸ（Avionics Full Duplex Switched Ethernet（登録商標））ネットワークであってよい。ＡＦＤＸネットワークの説明については、サイトwww.ces.chで入手可能な文献"CES White Paper on AFDX"を参照されたい。リンク２４０及びリンク２４１のようなエリアＡ及びエリアＢのイーサネット（登録商標）リンクは、全二重タイプであってよい。一方で、リンク２１０のようなエリアＡからエリアＢへ向かう各イーサネット（登録商標）リンクは、単信タイプである必要がある。
【００１９】
本発明に従って、リンク２２０のようなエリアＢからエリアＡへ向かう各リンクは、リンク２１０のプロトコルとは異なるプロトコル、例えば、航空分野で一般に使用されるＡＲＩＮＣ ４２９プロトコルに準拠している。ＡＲＩＮＣ ４２９プロトコルは、リンクレイヤと同様に、物理レイヤを規格化する。ＡＲＩＮＣ ４２９プロトコルは、一対のツイストケーブルを使用し、ＢからＡへの選択された片方向送信を行う。
【００２０】
あるいは、エリアＢからエリアＡへ向かうリンクは、自動車の分野で普及しているＣＡＮ（Control Area Network）プロトコルに従ってもよい。ＣＡＮプロトコルのリンクレイヤ及び物理レイヤの一部は、ＩＳＯ １１８９８−１規格で規格化される。このプロトコルは、シンプルケーブル対上での半二重タイプの送信を提供する。実際には、本発明においては、エリアＢからエリアＡへの送信のみが使用される。
【００２１】
図３は、本発明の一実施形態に従う遠隔通信システムに実装されるプロトコルスタックを示す。機器ＬＲＵ１は、片方向イーサネット（登録商標）リンク３１０での送信のための第１プロトコルスタック３３０と、リターンリンクでのデータ受信のための第２プロトコルスタック３５０とを使用する。リンク３２０は、ＡＲＩＮＣ ４２９プロトコルに準拠する。対称的に、機器ＬＲＵ２は、イーサネット（登録商標）リンク３１０でのデータ受信のための第１プロトコルスタック３４０と、リンク３２０でのデータ送信のための第２プロトコルスタック３６０とを使用する。
【００２２】
有利には、第１プロトコルスタック３３０，３４０は、ＴＦＴＰ／ＵＤＰ／ＩＰ／Ｅｔｈｅｒｎｅｔ（登録商標）から成る。ＴＦＴＰ（Trivial File Transfer Protocol）がＩＥＴＦによって規格化されたファイル転送プロトコルであることに留意されたい。包括的な説明は、www.ietf.org/rfc/rfc783.txt中のＲＦＣ １３５０を参照されたい。
【００２３】
機器ＬＲＵ１がデータファイルをＬＲＵ２へ送信しようとするとき、ＴＦＴＰレイヤは、ライトリクエスト（ＷＲＱ）によって一時セッションをオープンするとともに、ファイルを５１２バイトのブロックに分割する。ブロックは、ＴＦＴＰヘッダとの連結後に、ＵＤＰトランスポートレイヤへ送信される。ＵＤＰレイヤは、当業者には既知のように、接続確立やエラー時の再送を行うことなく、メッセージレベルサービスを提供する。そして、メッセージのＩＰデータグラムは、従来通りイーサネット（登録商標）フレームで送信される。受信時には、データは、プロトコルスタック３４０とは逆の方向に向かう。受信したＴＦＴＰメッセージ毎に、機器ＬＲＵ２は、ＲＦＣ １３５０規格に従って、受信通知メッセージを送信する。このメッセージは、３６０で示され、かつ以下に記載されるように、ＡＲＩＮＣ ４２９フレームにカプセル化される。ＡＲＩＮＣフレームは、従来通りリンク３２０で送信され、かつメッセージは、３５１でデカプセル化される。故に、スタック３３０及びスタック３４０のＴＦＴＰレイヤに対して、あたかもトランスポートが全二重リンクによってＩＰネットワーク上で行われるかのように動作する。
【００２４】
機器ＬＲＵ２がデータファイルをＬＲＵ１へ送信しなければならないとき、一時セッションは、リードリクエスト（ＲＲＱ）によって、ＬＲＵ１主導でオープンされる。送信されるファイルは、スタック３４０のＴＦＴＰレイヤによって、５１２バイトのブロックに分割される。ブロックは、対応するＴＦＴＰヘッダと連結される。このようにして得られたＴＦＴＰメッセージは、３６１に示され、かつ以下で詳細に記載されるように、ＡＲＩＮＣフレームにカプセル化される。ＡＲＩＮＣフレームは、従来通りリンク３２０で送信されるとともに、３５１でデカプセル化される。ついで、機器ＬＲＵ１は、スタック３３０、すなわち、イーサネット（登録商標）単信リンク３１０を介して、受信通知メッセージを送信する。受信通知メッセージは、プロトコルスタック３４０を介して、逆方向へ届けられる。ここで再び、スタック３３０，３４０のＴＦＴＰレイヤに対して、あたかもトランスポートが全二重リンクによってＩＰネットワーク上で行われるかのように動作する。
【００２５】
ＡＲＩＮＣリンク３２０と、第１プロトコルのメッセージを第２プロトコルのフレームにカプセル化するメカニズムとは、セキュアエリアとは隔てられたアクセスを形成する。
【００２６】
非セキュアエリアの機器ＬＲＵ２は、例えば、乗客の端末が接続可能なプロキシサーバとして、航空機に常設される。この場合、ＴＦＴＰメッセージカプセル化を実現するコンバージョンゲートウェイは、上記サーバに位置する。
【００２７】
図４は、本発明の第２実施形態に従う搭載用遠隔通信システムの概略図である。第１実施形態とは異なり、セキュアエリアのいくつかの機器ユニットＬＲＵ１，ＬＲＵ３，ＬＲＵ５は、非セキュアエリアの機器ユニットＬＲＵ２と通信できる。このために、マルチキャストタイプのＡＲＩＮＣリンク４２０は、関係する機器へのリターンパスとして機能する。ＡＲＩＮＣリンクは、送信源（emitter）には接続できないが、最大２０台の受信機に対応できるということに留意されたい。
【００２８】
図５は、本発明の第３実施形態に従う搭載用遠隔通信システムの概略図である。第１及び第２実施形態とは異なり、ＬＲＵ１などのセキュアエリアの機器ユニットは、非セキュアエリアの複数の機器ユニットＬＲＵ２，ＬＲＵ４，ＬＲＵ６と通信できる。このために、機器ＬＲＵ１は、複数のＡＲＩＮＣ ４２９インタフェースを備える。機器ユニットＬＲＵ２，ＬＲＵ４，ＬＲＵ６を上記インタフェースにそれぞれ接続する複数の下りＡＲＩＮＣリンク５２１，５２２，５２３は、リターンパスとして機能する。この実施形態では、ＣＡＮバスが、複数の送信源にリンクできるＣＡＮバスとして、ＡＲＩＮＣリンクの代わりに有利に使用できる。
【００２９】
セキュアエリアの複数の機器ユニットが非セキュアエリアの複数の機器ユニットと通信できるようにするために、第２及び第３実施形態が第４実施形態へと有利に組み合わせできることが当業者には明白である。この場合、いくつかのマルチキャストタイプのＡＲＩＮＣリンクは、セキュアエリアの機器ユニットへのリターンパスとして機能する。変形例に従って、ＣＡＮバスは、非セキュアエリアの機器ユニットとセキュアエリアの機器ユニットとの間のリターン機能を確保する。
【００３０】
上記の実施形態は、ＴＦＴＰメッセージを第２プロトコル、例えば、ＡＲＩＮＣ ４２９プロトコルのフレームにカプセル化するメカニズムを使用する。ＡＲＩＮＣ ４２９プロトコルの詳細な説明は、サイトwww.condoreng.comで入手可能な"ARINC Protocol Tutorial"と題された文献を参照されたい。
【００３１】
図６は、ＡＲＩＮＣフレームの概略図である。ＡＲＩＮＣフレームは、５つのフィールドから成る３２ビットのワードで構成されている。ビットＰは、パリティビットである。フィールドＳＳＭは、機器の動作状態を示す。１９ビットのフィールドＰＡＹＬＯＡＤは、ペイロードを含み、必要であれば、パディングビット（ＰＡＤ）が付加される。フィールドＳＤＩは、マルチキャスト送信の場合に、フレームの送信先の指示を可能にする。最後に、フィールドＬＡＢＥＬは、ペイロードに対応する航空電子工学パラメータと、それを構成するデータのフォーマットとを示す。
【００３２】
以後、ＴＦＴＰメッセージは、リターンパスでのカプセル化の後に送信できるもの、すなわち、ＡＣＫ、ＤＡＴＡ、ＥＲＲＯＲと見なされる。
【００３３】
図３を参照すると、機器ＬＲＵ１がデータファイルを機器ＬＲＵ２へ送信しようとするとき、機器ＬＲＵ１は、ライトリクエストメッセージ（ＷＲＱ）を機器ＬＲＵ２へ送信する。ＬＲＵ２は、ファイルを受信できる状態にあるならば、確認メッセージをＬＲＵ１へ返す。ついで、ファイルのデータブロックを含む受信したメッセージ毎に、機器ＬＲＵ２は、受信したブロックの数を示す確認メッセージをＬＲＵ１へ返す。ファイルの終端は、５１２バイト未満のブロックを受信したときに、スタック３４０のＴＦＴＰレイヤによって検出される。ライトリクエストを確認するための第１メッセージは、通常、ブロックナンバー０で示される。機器ＬＲＵ１がデータブロックを送信する際に、スタック３３０のＴＦＴＰレイヤは、タイマを設定する。タイマがアップする前に確認メッセージが受信されなければ、データブロックは、ＴＦＴＰメッセージによって再送信される。
【００３４】
ＴＦＴＰプロトコルの確認メッセージＡＣＫは、メッセージのタイプを識別する２バイトの第１オペレーションコードフィールド（Ｏｐｃｏｄｅ＝４）と、確認されたブロック受信数を与える２バイトの第２フィールドとを含む。カプセル化モジュール３６１は、第２オペレーションコードバイト（第１バイトは、確認メッセージのために常にゼロとなる）と、その次の、ブロック数の２バイトとを、第２プロトコルのフレームに格納する。カプセル化モジュール３６１は、データ転送に使用される送信元機器（ＬＲＵ１）及び送信先機器（ＬＲＵ２）のＵＤＰポート番号を、このメッセージに付加する。１バイトで符号化されたＵＤＰポート番号毎に、確認メッセージのために７バイトが送信されなければならず、３つのＡＲＩＮＣフレーム又は１つのＣＡＮフレームを要する。
【００３５】
機器ＬＲＵ１が機器ＬＲＵ２からデータファイルを受信しようとするとき、機器ＬＲＵ１は、リードリクエストＲＲＱを機器ＬＲＵ２へ送信する。機器ＬＲＵ２は、送信可能な状態にあるならば、関係するファイルの５１２バイトの第１ブロックを、確認通知として機器ＬＲＵ１へ直接送信する。機器ＬＲＵ１は、応答として、第１ブロックの確認メッセージＡＣＫを送信する。その過程は、上記の通り、ファイルの最終ブロックが送信されるまで続く。ブロックの送信後、スタック３４０のＴＦＴＰレイヤが所与の時間内に確認通知を受信しない場合、送信が繰り返される。
【００３６】
ＴＦＴＰプロトコルのデータメッセージＤＡＴＡは、メッセージのタイプを識別する２バイトの第１オペレーションコードフィールド（Ｏｐｃｏｄｅ＝３）と、送信したブロック数を与える２バイトの第２フィールドと、データブロックが格納された０≦ｎ≦５１２であるｎバイトのフィールドとを含む。
【００３７】
カプセル化モジュール３６１は、第２オペレーションコードバイト（第１バイトは、データメッセージのために常にゼロである）と、その次の、送信されたブロック数の２バイトと、最後の、関係するブロックのｎバイトとを、第２プロトコルのフレームに格納する。モジュール３６１は、データ転送に使用される送信元機器ＬＲＵ１及び送信先機器ＬＲＵ２のＵＤＰポート番号を、このメッセージに付加する。故に、ｎデータバイトのブロックの送信のためには、ｎ＋７バイトが送信されなければならず、Ｅ［（ｎ＋７）．８／１９］＋１のＡＲＩＮＣフレームと、ｎ＋７のＣＡＮフレームとを必要とする。ここで、Ｅ［ｘ］は、ｘの整数部を与える。
【００３８】
ＬＲＵ１によって送信されたライトリクエスト（ＷＲＱ）又はリードリクエスト（ＲＲＱ）がＬＲＵ２によって承諾できない場合、又はデータ転送中にエラーが発生した場合、スタック３４０のＴＦＴＰレイヤによって、エラーメッセージが送信される。
【００３９】
ＴＦＴＰプロトコルのエラーメッセージＥＲＲＯＲは、メッセージのタイプを識別する２バイトの第１オペレーションコードフィールド（Ｏｐｃｏｄｅ＝５）と、診断されたエラーのコードを含む２バイトの第２フィールドと、場合によっては、エラーを説明するＡＳＣＩＩ記号を含む第３フィールドとを含み、その後にゼロバイトが続く。この第３フィールドは、ここでは使用されない。
【００４０】
カプセル化モジュール３６１は、第２オペレーションコードバイト（第１バイトは、エラーメッセージのために常にゼロである）と、その次の、エラーコードの２バイトとを、第２プロトコルのフレームに格納する。最後に、モジュール３６１は、データ転送に使用される送信元機器（ＬＲＵ１）及び送信先機器（ＬＲＵ２）のＵＤＰポート番号を、このメッセージに付加する。故に、エラーメッセージの送信のためには、５バイトが送信されなければならず、３つのＡＲＩＮＣフレーム又は５つのＣＡＮフレームを必要とする。
【００４１】
第２実施形態のように、機器ＬＲＵ２がセキュアエリアの複数の機器ユニットにリンクされている場合、カプセル化モジュール３６１は、ＴＦＴＰメッセージの送信先に応じて、ＡＲＩＮＣフレームのＳＩＤフィールドの値を決定する。
【００４２】
しかしながら、ＴＦＴＰメッセージの送信先を区別できない第２プロトコルをシステムが使用する場合、モジュール３６１は、送信先機器のＩＰアドレスを、カプセル化されたメッセージに有利に付加する。
【００４３】
また、第３実施形態のように、非セキュアエリアの複数の機器ユニットがセキュアエリアの機器ユニットにリンクされる場合と、ＴＦＴＰメッセージの送信先機器ユニットによるＴＦＴＰメッセージを送信した送信元機器の判断ができない第２プロトコルをシステムが使用する場合、各モジュール３６１は、送信元機器のＩＰアドレスを、カプセル化されたメッセージに有利に付加する。
【００４４】
一般に、第４実施形態の場合には、各モジュール３６１は、ＴＦＴＰメッセージの送信元及び送信先機器それぞれのＩＰアドレスを、カプセル化されたメッセージに付加する。
【符号の説明】
【００４５】
３１０ 片方向イーサネット（登録商標）リンク
３２０ ＡＲＩＮＣリンク
３３０，３４０ 第１プロトコルスタック
３５０，３６０ 第２プロトコルスタック
３５１ デカプセル化モジュール
３６１ カプセル化モジュール
【特許請求の範囲】
【請求項１】
セキュアエリアと非セキュアエリアとに区分けされ、
セキュアエリアの第１遠隔通信機器ユニットと、
非セキュアエリアの第２遠隔通信機器ユニットと、
第１機器ユニットから第２機器ユニットへの第１片方向リンクと
を少なくとも具備し、
前記第１機器ユニットが第１プロトコルに従って前記第１リンクでデータの送信を行うように構成された、搭載用遠隔通信システムであって、
第２機器ユニットから第１機器ユニットへの、第２プロトコルに従う第２リンクを具備し、
第２プロトコルの上位２つのレイヤは、第１プロトコルの上位２つのレイヤとは異なっており、
前記第２機器ユニットは、第２プロトコルに従ってフレーム内にカプセル化された第１プロトコルに従うメッセージとして、第２リンクでデータの送信を行うように構成されることを特徴とする搭載用遠隔通信システム。
【請求項２】
第１プロトコルの上位２つのレイヤが、イーサネット（登録商標）レイヤであることを特徴とする請求項１に記載の搭載用遠隔通信システム。
【請求項３】
第１プロトコルのスタックが、ＴＦＴＰ／ＵＤＰ／ＩＰ／Ｅｔｈｅｒｎｅｔ（登録商標）であることを特徴とする請求項２に記載の搭載用遠隔通信システム。
【請求項４】
第２プロトコルの上位２つのレイヤが、ＡＲＩＮＣ ４２９レイヤであることを特徴とする請求項１ないし３のいずれか１項に記載の搭載用遠隔通信システム。
【請求項５】
第２プロトコルの上位２つのレイヤが、ＣＡＮレイヤであることを特徴とする請求項１ないし３のいずれか１項に記載の搭載用遠隔通信システム。
【請求項６】
第２機器ユニットが、カプセル化モジュールを具備し、
前記カプセル化モジュールは、ＴＦＴＰプロトコルのメッセージ、すなわち、ＡＣＫ、ＥＲＲＯＲ、ＤＡＴＡを、ＡＲＩＮＣ ４２９フレームにカプセル化するように構成されることを特徴とする請求項３又は４に記載の搭載用遠隔通信システム。
【請求項７】
前記カプセル化モジュールが、第１機器と第２機器との間でデータを送信するために使用されるＵＤＰポート番号を、前記ＴＦＴＰメッセージに付加するように構成されることを特徴とする請求項６に記載の搭載用遠隔通信システム。
【請求項８】
前記カプセル化モジュールが、前記ＴＦＴＰメッセージの送信先機器のＩＰアドレス、及び／又は、前記ＴＦＴＰメッセージの送信元機器のＩＰアドレスを、前記ＴＦＴＰメッセージに付加するように構成されることを特徴とする請求項６又は７に記載の搭載用遠隔通信システム。
【請求項９】
請求項１ないし８のいずれか１項に記載の搭載用遠隔通信システムを具備することを特徴とする航空機。
【請求項１】
セキュアエリアと非セキュアエリアとに区分けされ、
セキュアエリアの第１遠隔通信機器ユニットと、
非セキュアエリアの第２遠隔通信機器ユニットと、
第１機器ユニットから第２機器ユニットへの第１片方向リンクと
を少なくとも具備し、
前記第１機器ユニットが第１プロトコルに従って前記第１リンクでデータの送信を行うように構成された、搭載用遠隔通信システムであって、
第２機器ユニットから第１機器ユニットへの、第２プロトコルに従う第２リンクを具備し、
第２プロトコルの上位２つのレイヤは、第１プロトコルの上位２つのレイヤとは異なっており、
前記第２機器ユニットは、第２プロトコルに従ってフレーム内にカプセル化された第１プロトコルに従うメッセージとして、第２リンクでデータの送信を行うように構成されることを特徴とする搭載用遠隔通信システム。
【請求項２】
第１プロトコルの上位２つのレイヤが、イーサネット（登録商標）レイヤであることを特徴とする請求項１に記載の搭載用遠隔通信システム。
【請求項３】
第１プロトコルのスタックが、ＴＦＴＰ／ＵＤＰ／ＩＰ／Ｅｔｈｅｒｎｅｔ（登録商標）であることを特徴とする請求項２に記載の搭載用遠隔通信システム。
【請求項４】
第２プロトコルの上位２つのレイヤが、ＡＲＩＮＣ ４２９レイヤであることを特徴とする請求項１ないし３のいずれか１項に記載の搭載用遠隔通信システム。
【請求項５】
第２プロトコルの上位２つのレイヤが、ＣＡＮレイヤであることを特徴とする請求項１ないし３のいずれか１項に記載の搭載用遠隔通信システム。
【請求項６】
第２機器ユニットが、カプセル化モジュールを具備し、
前記カプセル化モジュールは、ＴＦＴＰプロトコルのメッセージ、すなわち、ＡＣＫ、ＥＲＲＯＲ、ＤＡＴＡを、ＡＲＩＮＣ ４２９フレームにカプセル化するように構成されることを特徴とする請求項３又は４に記載の搭載用遠隔通信システム。
【請求項７】
前記カプセル化モジュールが、第１機器と第２機器との間でデータを送信するために使用されるＵＤＰポート番号を、前記ＴＦＴＰメッセージに付加するように構成されることを特徴とする請求項６に記載の搭載用遠隔通信システム。
【請求項８】
前記カプセル化モジュールが、前記ＴＦＴＰメッセージの送信先機器のＩＰアドレス、及び／又は、前記ＴＦＴＰメッセージの送信元機器のＩＰアドレスを、前記ＴＦＴＰメッセージに付加するように構成されることを特徴とする請求項６又は７に記載の搭載用遠隔通信システム。
【請求項９】
請求項１ないし８のいずれか１項に記載の搭載用遠隔通信システムを具備することを特徴とする航空機。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公表番号】特表２００９−５３８０１６（Ｐ２００９−５３８０１６Ａ）
【公表日】平成２１年１０月２９日（２００９．１０．２９）
【国際特許分類】
【出願番号】特願２００９−５１０５０５（Ｐ２００９−５１０５０５）
【出願日】平成１９年４月２７日（２００７．４．２７）
【国際出願番号】ＰＣＴ／ＦＲ２００７／０５１１８６
【国際公開番号】ＷＯ２００７／１３２１０７
【国際公開日】平成１９年１１月２２日（２００７．１１．２２）
【出願人】（５０１４４６２２８）エアバス・フランス (93)
【Ｆターム（参考）】
【公表日】平成２１年１０月２９日（２００９．１０．２９）
【国際特許分類】
【出願日】平成１９年４月２７日（２００７．４．２７）
【国際出願番号】ＰＣＴ／ＦＲ２００７／０５１１８６
【国際公開番号】ＷＯ２００７／１３２１０７
【国際公開日】平成１９年１１月２２日（２００７．１１．２２）
【出願人】（５０１４４６２２８）エアバス・フランス (93)
【Ｆターム（参考）】
[ Back to top ]