JP6937154B2 - コンテキストアウェアなネットワークのためのシステム及び方法 - Google Patents

Description

本開示は、概してサイバーセキュリティに関し、より具体的には、航空プラットフォーム及びインフラストラクチャに対するサイバーセキュリティ脅威を特定する際に使用される方法及びシステムに関する。

機内及び機外の両方の航空プラットフォーム及びインフラストラクチャの「e-Enabling」により、相互接続された物理的システム及びサプライチェーン・インフラストラクチャ（supply chain infrastructure）が実現したが、ネットワーク接続されたコンピューティングシステムに対するアクセスの増加によって、これらは今では、活発且つ増大するサイバーセキュリティ脅威の潜在的なターゲットとなっている。航空プラットフォーム及びインフラストラクチャは、多様な運航上の重要性、信頼性、及び可用性要件を備えた、階層的にネットワーク接続された組み込みシステム及びコントローラを含む複雑なシステムである。様々な例において、組み込みシステム及びコントローラは、汎用コンピューティングデバイスハードウェア、商用ソフトウェアオペレーティングシステム、及び、意図されたシステム機能を実行する特定のカスタムアプリケーション上で、ますますホストされるようになってきている。これらの機内組み込みシステム及びコントローラは、インターネット・プロトコル（ＩＰ）及びＩＥＥＥ（Institute of Electrical and Electronics Engineers）の有線及び無線通信ならびにネットワークプロトコルなどの、ＩＥＴＦ（Internet Engineering Task Force）及びＡＲＩＮＣ社（Aeronautical Radio, Inc.）基準に基づいたプロトコルを介して、ネットワーク接続することができる。また、機内システムは、ユーザ・データグラム・プロトコル（ＵＤＰ）及びトランスミッション・コントロール・プログラム（ＴＣＰ）などの標準的なＩＥＴＦ ＩＰベースのプロトコルを介して、機外のコンピューティングシステムとネットワーク接続することができる。

標準ベースのコンピューティング及び通信プロトコルの使用が増加すると、e-Enableされたアーキテクチャの全体的な統合が可能になるが、これによって、サイバーセキュリティ攻撃に対する脆弱性が高まる可能性もある。また、飛行機ネットワークデータフローの現在の定義は、機械理解可能な形式ではなく、ドメイン・ガード用に適したネットワークフィルタルールの作成には、手動解釈が必要である。これが、エラーや、有効範囲のギャップの発生につながる可能性がある。従って、e-Enableされた航空プラットフォーム上のシステムのコンテキストの変化に基づいて不正なネットワークフローを防止することができる、フィルター機能を高めるシステム及び方法が必要とされている。

本開示のいくつかの実施例の基本的な理解を与えるため、本開示の簡略化された概要を以下に提示する。この概要は、開示の包括的な概説ではなく、本開示のキーあるいは重要要素を特定するものでも、本開示の範囲を規定するものでもない。その唯一の目的は、後に提示されるより詳細な説明の前置きとして、本明細書に開示されるいくつかの概念を簡略化した形で提示することである。

概して、本開示のある種の実施例は、e-Enableされた航空プラットフォーム及びインフラストラクチャの機能ネットワークフローのコンテキストアウェアなメッセージ内容フィルタリングのための手法又は機構を提供する。様々な実施例によれば、航空機用の航空ネットワークにおけるネットワークメッセージを、その時点のシステムコンテキストに基づいて自動的にフィルタリングする方法が提供される。当該方法は、ネットワークメッセージを、コンピュータシステムのプロセッサによって受信することを含む。ネットワークメッセージは、航空ネットワーク内において、１つ又は複数のネットワークパケットによって送信元アビオニクス装置から宛先アビオニクス装置に向けて送信されたものである。当該方法は、前記航空ネットワーク内の１つ又は複数のアビオニクス装置を監視することによって、前記プロセッサによってその時点のシステムコンテキストを確定することを含む。いくつかの例において、前記システムコンテキストは、前記１つ又は複数のアビオニクス装置の統合的な状態を示すものである。いくつかの例において、前記その時点のシステムコンテキストは、以下のもの、すなわち、日付、時間、前記送信元アビオニクス装置の位置、前記宛先アビオニクス装置の位置、前記複数のアビオニクス装置の装置状態、及び、前記航空機の飛行フェーズ、のうちの１つ又は複数の組み合わせを含む。いくつかの例において、前記複数のアビオニクス装置の前記装置状態は、動作モード、メンテナンスモード、又は、データロードモードを含む。いくつかの例において、前記航空機の前記飛行フェーズは、以下の動作状態、すなわち、パワーオン、プリフライト、エンジンスタート、イン・ゲート、タクシー・アウト、離陸、初期上昇、上昇、巡航、降下、着陸進入、ロールアウト、タクシー・イン、ゴーアラウンド、及び、エンジンシャットダウン、のうちの１つ又は複数を含む。

当該方法は、前記ネットワークメッセージの容認性(acceptability)を、前記プロセッサによって分析することをさらに含む。前記ネットワークメッセージの容認性は、前記ネットワークメッセージに対応する複数の属性を特定することによって分析される。いくつかの例において、前記複数の属性は、前記ネットワークメッセージに対応する前記１つ又は複数のネットワークパケットのヘッダー及びデータフィールドに対応する。いくつかの例において、前記ネットワークメッセージに対応する複数の属性は、以下のもの、すなわち、宛先アドレス、送信元アドレス、前記ネットワークメッセージの飛行フェーズ、前記ネットワークメッセージの装置状態、ファンクション、サブファンクション、データフロー、及び、プロトコル、のうちの１つ又は複数を含む。

前記ネットワークメッセージの容認性は、特定のシステムコンテキスト内でどのような属性が許容されるかを示す１つ又は複数のフィルター・ルールに基づいて、前記システムコンテキスト内での前記ネットワークメッセージの容認性を判定することによってさらに分析される。いくつかの例において、前記１つ又は複数のフィルター・ルールは、前記航空ネットワークの試験フェーズ中に、前記航空ネットワーク内で送信された試験機能ネットワークフローに対応する１つ又は複数の試験ネットワークパケットを捕捉することによって、自動的に作成される。前記１つ又は複数の試験ネットワークパケットは、前記試験機能ネットワークフローに対応する１つ又は複数の試験ネットワークメッセージを抽出するために、解析される。次に、前記１つ又は複数の試験ネットワークメッセージのうちの上記試験ネットワークメッセージが、複数の試験属性を特定するために、調べられる。いくつかの例において、前記複数の試験属性は、前記試験ネットワークメッセージに対応する前記１つ又は複数の試験ネットワークパケットのヘッダー及びデータフィールドに対応している。次に、前記試験ネットワークメッセージの前記複数の試験属性が、分類される。前記１つ又は複数のフィルター・ルールは、前記１つ又は複数の試験ネットワークメッセージに対応する１つ又は複数のテーブルを自動的に作成することによって、さらに自動的に作成される。前記１つ又は複数のテーブルは、前記１つ又は複数のフィルター・ルールを含み、前記試験ネットワークメッセージの１つ又は複数の試験属性に基づいてチェーンされている。最後に、前記１つ又は複数のフィルター・ルールが有効化される。

いくつかの例において、前記１つ又は複数のフィルター・ルールは、前記１つ又は複数のネットワークパケットの１つ又は複数のペイロードを調べることによって、前記航空ネットワークにおける不正データフローを阻止する１つ又は複数のディープ・パケット・フィルタリング・ルールを含む。当該方法は、前記ネットワークメッセージが前記システムコンテキスト内で容認できると判定された場合に、前記プロセッサによって、前記ネットワークメッセージを前記宛先アビオニクス装置に送信することをさらに含む。

さらなる例において、１つ又は複数のプロセッサと、メモリと、前記メモリに格納された１つ又は複数のプログラムとを含むシステムが提供される。さらに別の例において、コンピュータシステムによって実行されるように構成された１つ又は複数のプログラムを含む非一時的なコンピュータ可読媒体が提供される。様々な例において、前記１つ又は複数のプログラムは、コンピュータシステムのプロセッサによってネットワークメッセージを受信するための命令を含む。前記ネットワークメッセージは、航空ネットワーク内において、１つ又は複数のネットワークパケットによって、送信元アビオニクス装置から宛先アビオニクス装置に向けて送信されたものである。前記１つ又は複数のプログラムは、前記航空ネットワーク内の１つ又は複数のアビオニクス装置を監視することによって、前記プロセッサによってその時点のシステムコンテキストを確定するための命令をさらに含む。いくつかの例において、前記システムコンテキストは、前記１つ又は複数のアビオニクス装置の統合的な状態を示すものである。前記１つ又は複数のプログラムは、前記ネットワークメッセージの容認性を前記プロセッサによって分析するための命令をさらに含む。前記ネットワークメッセージの容認性は、前記ネットワークメッセージに対応する複数の属性を特定することによって分析される。いくつかの例において、前記複数の属性は、前記ネットワークメッセージに対応する前記１つ又は複数のネットワークパケットのヘッダー及びデータフィールドに対応する。前記ネットワークメッセージの容認性は、１つ又は複数のフィルター・ルールに基づいて、前記システムコンテキスト内での前記ネットワークメッセージの容認性を判定することによって、さらに分析される。いくつかの例において、前記フィルター・ルールは、特定のシステムコンテキスト内でどのような属性が許容されるかを示すものである。前記１つ又は複数のプログラムは、前記ネットワークメッセージが前記システムコンテキスト内で容認できると判定された場合に、前記プロセッサによって、前記ネットワークメッセージを前記宛先アビオニクス装置に送信するための命令をさらに含む。

本開示は、以下の説明を添付図面と併せて参照することにより、最も理解されるであろう。なお、図面は、本開示の特定の実施例を示すものである。

１つ又は複数の実施例による、本開示の様々な方法を実施するための例示的なシステムの概略を示す図である。 １つ又は複数の実施例による、コンテキストアウェアなメッセージフィルタリングのための例示的なシステムを示す図である。 １つ又は複数の実施例による、e-Enableされた航空プラットフォームの一例を示す図である。 １つ又は複数の実施例による、コンテキストアウェアなネットワークフィルタリングの方法の一例を示す図である。 １つ又は複数の実施例による、オンボード・ネットワーク・システム（ＯＮＳ）を介して、セントラル・メンテナンス・コンピューター（ＣＭＣ）の無線データロートを行うための事象のシーケンスを示す図である。 １つ又は複数の実施例による、コンテキストアウェアなネットワークフィルタリングの方法の別の例を示す図である。 １つ又は複数の実施例による、コンテキストアウェアなネットワークフィルタリングの方法の別の例を示す図である。 １つ又は複数の実施例による、コンテキストアウェアなネットワークフィルタリングの方法の別の例を示す図である。 １つ又は複数の実施例による、コンテキストアウェアなネットワークフィルタリングの方法の別の例を示す図である。 本開示に記載の様々なプロセスを実施することができるシステムの一例を示すブロック図である。

本開示を実施するために発明者が想定したベストモードを含む、本開示のいくつかの特定の実施例について、詳細に説明する。これらの特定の実施例は、添付図面に図示されている。これらの特定の実施例に関連させて本開示を説明するが、本開示を記載の実施例に限定することを意図するものではない。むしろ、添付の特許請求の範囲によって規定される本開示の精神及び範囲に含まれうる代替例、変形例及び均等物を包含することを意図するものである。

例えば、本開示の手法を、特定のネットワークメッセージの特定のファンクション、サブファンクション及びデータフローに照らして説明するが、本開示の手法は、様々なファンクション、サブファンクション、及びデータフローを有するその他のネットワークフロー及び／又はプロトコルにも適用できる。別の例として、本開示の手法を、航空ネットワーク内の特定の装置及び／又は実体に関連させて説明する。本明細書において、「実体」及び「装置」という用語は、ネットワークパケット及び／又はネットワークメッセージを送受信する、航空ネットワーク内の１つ又は複数の様々なアビオニクス装置と同じ意味で用いられうる。ただし、本開示の手法は、他の様々なネットワークの装置及びネットワークの種類にも適用できる。以下の説明においては、本開示が十分に理解されるように、多くの具体的な詳細事項を提示している。本開示の特定の実施例は、これらの詳細事項のうちのいくつか又はすべてが無くとも実施されうる。他の例において、本開示が不必要に不明瞭にならないように、周知の処理動作については詳細には説明していない。

本開示の様々な手法及び機構を、明瞭にするためにしばしば単数の形態で記載している。ただし、いくつかの例は、別段の記載が無い限り、１つの手法の繰り返し、あるいは、機構を複数設けることを含む。例えば、様々なコンテキストにおいて、システムは、プロセッサを使用する。ただし、別段の記載が無い限り、本開示の範囲から逸脱することなく、システムが複数のプロセッサを用いることもありうる。また、本開示の手法及び機構において、２つの実体間の接続が示されることがある。２つの実体間の接続は、必ずしも、直接的な、他の介在のない接続を意味するものではなく、２つの実体間に様々な他の実体が存在していてもよい。例えば、プロセッサは、メモリに接続されうるが、プロセッサとメモリとの間に様々なブリッジ及びコントローラが存在しうる。このように、別段の記載が無い限り、接続とは、必ずしも、直接的な、他の介在のない接続を意味するものではない。
〈概要〉

本開示は、e-Enableされた航空プラットフォーム及びインフラストラクチャの機能ネットワークフローに対して、コンテキストアウェアなメッセージ内容フィルタリングを行うためのシステム及び方法を提供する。ネットワーク接続された航空システム内の様々なアビオニクス装置間で送信されるネットワークパケットは、１つ又は複数のネットワークメッセージを含みうる。このようなアビオニクス装置は、例えば航空機又は管制センター内の様々な通信装置及び／又はコンピュータを含みうる。いくつかの例において、送信されたネットワークメッセージは、ファイアウォール・フィルターとして作用するコンピュータシステムによって受信される。当該コンピュータシステムは、ネットワーク接続された航空システム内の１つ又は複数のアビオニクス装置を監視して、これらのアビオニクス装置の位置、装置状態、及び／又は飛行フェーズなどの状態情報を得ることにより、ネットワーク接続された航空システムの、その時点のコンテキストを判定することができる。システムのその時点のコンテキストは、その時点の日付及び時間を含みうる。

このような、その時点のコンテキストに基づいて、コンピュータシステムは、ある特定のシステムのコンテキストにおいてどのような属性が許容されるかを示すフィルター・ルールに基づいて、受信したネットワークメッセージの容認性を判定することができる。コンピュータシステムは、ネットワークメッセージに対応するネットワークパケットの様々なヘッダー及びデータフィールドを、ディープ・パケット・アイデンティフィケーション(deep packet identification)によって調べることにより、そのネットワークメッセージの属性を特定する。コンピュータシステムは、受信したネットワークメッセージの属性が、ネットワーク接続された航空システムのその時点のコンテキスト内で容認可能であると判定されると、当該ネットワークメッセージを、宛先実体であるアビオニクス装置に送信する。このようにして、コンピュータシステムは、ネットワーク接続された航空システム内で送信されるネットワークメッセージに対して、コンテキストに基づいた制限を与えることができる。
〈例示的な実施形態〉

図１Ａは、１つ又は複数の実施例による、本開示の様々な方法を実施するための例示的なシステム１００の概略全体図である。具体的には、図１Ａは、ユーザーが、ウェブブラウザを備えるコンピュータ１０２を用いてネットワーク１０４にアクセスし、別のコンピュータ１０６と通信する状態を示している。いくつかの例において、コンピュータ１０６は、ユーザーの要求を満たすために必要なモジュールを含むサーバーとして構成される。いくつかの例において、コンピュータ１０２及び／１０６は、汎用のコンピュータである。他の例において、コンピュータ１０２及び／又は１０６は、特殊化されたアビオニクス装置であり、ネットワーク接続された航空システム、プラットフォーム、及び／又はアーキテクチャにおいて動作するための、適合性のある制御及びインターフェイスシステムを含むものである。他の例において、システム１００は、ネットワーク１０４を介してコンピュータ１０２及び１０６に接続された他の装置及び／又はコンピュータを含む。いくつかの例において、ネットワーク１０４は、イーサネット接続、及び／又は、ＩＰ及びＵＤＰを含む他の標準的なインターネット及びローカルエリアネットワーク（ＬＡＮ）技術である。他の例において、ネットワーク１０４は、任意の他の直接のネットワーク及び／又は無線ネットワークであってもよい。

図１Ｂは、本開示の１つ又は複数の実施例による、ネットワークパケットを捕捉するための例示的なシステムアーキテクチャ１０１を示す。２つのシステム、すなわちシステム１１０とシステム１１４とが、ネットワーク１０４のようなイーサネット接続によって接続されている。各システム（１１０又は１１４）は、コンピュータ１０２又は１０６を含むコンピュータシステム、又は、単一の列線交換ユニット（line replaceable unit:ＬＲＵ）もしくはＬＲＵの集合体のような航空システムでありうる。ＬＲＵは、その動作場所で迅速に交換できるように設計された、航空機、船舶、宇宙船（又は他の任意の製造済みアビオニクス装置）におけるモジュール式のコンポーネントでありうる。ＬＲＵは、ラジオ無線装置又は他の補助装置などの密閉されたユニットでありうる。例えば、システム１１０及び／又はシステム１１４は、航空機、衛星、管制塔、セルラータワー、航空機内ネットワークと通信する他の機外システム、及び／又はそれらのシミュレーションの通信コンポーネント及び／又はコンピュータである。図１Ｂは、ルーター１１６を介して互いに通信するフライト・マネジメント・コンピューター（ＦＭＣ）１２０とオンボード・ネットワーク・システム（ＯＮＳ）１２２とで構成されたシステム１１０を示している。また、システム１１４は、ルーター１２８を介して互いに通信するセントラル・メンテナンス・コンピュータ（ＣＭＣ）１２４、メンテナンス・ラップトップ（ＭＬ）１２６、及びプリンタ１３０を含む３つのＬＲＵによって構成されている。

本開示の目的の１つは、システム１１０とシステム１１４との間の情報のフローを制御するためのファイアウォール１１２のファイアウォール・フィルター・ルールを、自動的に作成する手段を提供することである。システム１１０とシステム１１４とのネットワーク１１４を介する接続は、矢印Ａで示している。様々な実施例において、システム１１０とシステム１１４との接続を監視することによって、システム１１０とシステム１１４との間で伝送されるデータを、矢印Ａに沿う任意の点で、ネットワークタップ１１８を介して捕捉することができる。様々な実施例において、当該データを、コンピュータ１０２及び／又は１０６などの、ネットワーク１０４に接続された別のコンピュータによって捕捉してもよい。ある種の実施例において、データは、様々な手法によって捕捉することができ、システム１１０とシステム１１４との間で送信されたデータパケットのすべてを記録するパケット・キャプチャー（「ＰＣＡＰ」）・ソフトウェアがその一例であるが、これに限定されない。データパケットは、１つ又は複数のネットワークメッセージを含む。データパケットが捕捉されると、以下に詳しく述べるように、システム１１０とシステム１１４との間の情報のフローを制御するためのファイアウォール１１２のフィルター・ルールを作成すべく、これらのデータパケットの解析、調査、分類、および機能ネットワークフローへのグループ化が行われる。なお、１つの機能ネットワークフローは、複数のネットワークメッセージからなる１つのグループに対応しうるものであり、例えばこのグループは、より高いレベルの飛行機のファンクション、サブファンクション、データフロー、及びプロトコルに対応している。

飛行管理、印刷、データローダ、又はセントラル・メンテナンスなどの主要な飛行機機能の機能フローは、複数のサブファンクションを包含しうるものであり、これらサブファンクションは、互いに異なるデータフローとしても表すことができる。いくつかの例において、データフローは、テンポラル交換又はプロトコル交換である。本開示のプロセスを説明するために用いられる機能フローの例は、以下を含む。
１．データロード（プロトコル）
ａ．ＩＥＥＥ８０２．１ｘ 認証／接続
ｂ．ＡＲＩＮＣ ６１５Ａセッションの確立
ｃ．ＴＦＴＰ（Trivial File Transfer Protocol）プロトコルを用いたデータロード動作の実行
ｄ．ＡＲＩＮＣ ６１５Ａセッションのクローズ
２．プリンタジョブ（プロトコル）
３．ＣＭＣＦ(central maintenance control function）
ａ．セッションを確立しない、連続するＢＩＴＥ（Build In Test Equipment）報告（テンポラル）
ｂ．ＣＭＣＦからのＬＲＵコンフィギュレーション報告の照会（プロトコル）

図２は、１つ又は複数の実施例による、本開示の手法及び機構に関連して実施されうるe-Enableされた航空プラットフォーム２００の一例を示している。航空プラットフォーム及びインフラストラクチャは、ネットワーク接続することによる操作及び作業の効率性という利点を享受するために、e-Enableされたアーキテクチャ及びテクノロジーを、急速に採用しつつある。プラットフォーム２００の様々な例において、e-Enableされた航空機２０２は、航空機から航空機への（Ａ２Ａ）ネットワーク２３４及び／又は航空機から地上への（Ａ２Ｉ）ネットワーク２３６を介して、様々な実体に接続することができる。いくつかの例において、航空機２０２は、全地球的測位システム（ＧＰＳ）２０６、組み込みシステム２０８、無線周波数識別（ＲＦＩＤ）タグ２１０、無線センサネットワーク２１２、８０２．１１アクセスポイント２１４、及び、乗客装置２１６を含め、対応する通信無線を備えた様々な航空機内ネットワークシステムを含んでいる。いくつかの例において、航空機２０２は、さらに、飛行機２０２と地上システムとの間で複数のデータソースを統合するアプリケーション２０４をさらに含む。いくつかの例において、これらのデータソースは、ロード可能なソフトウェアに対応する情報（例えば、ナビゲーション・データベース、電子フライトバッグ、気象予報）や、ヘルスデータ（例えば、無線センサー及びタグデータ等の診断データ）、及び、交通管制データ（例えば交通ビーコン）を格納するものである。いくつかの例において、航空機ネットワークシステムは、システム１１０及び１１４であり、コンピュータ１０２及び１０６などのコンピュータ及び／又はサーバーを含む。いくつかの例において、アプリケーション２０４は、コンピュータ１０２、１０６などのコンピュータ、及び、システム１１０、システム１１４などのシステムに格納される。いくつかの例において、航空機内ネットワークシステムは、ファイアウォール・フィルター１１２などのファイアウォールによってセキュリティ保護された、安全なデータネットワークを含む。

いくつかの例において、e-enableされた飛行機２０２は、用途に応じて複数の実体と通信し、このような実体には、電子商取引業者、飛行機製造会社、機内装置供給業者、航空会社、航空用及びその他のネットワークサービスプロバイダー、サービサー（保守用）、航空交通管制（ＡＴＣ）センター、規制機関（例えば、連邦航空局）、及び、飛行機２２０及び無人航空機２２２のような他の飛行機が含まれうる。例えば、航空機内ネットワークシステムは、Ａ２Ａネットワーク２３４を介して、別の飛行機２２０及び／又は無人航空機システム２２２に対する情報の送受信を行う。このような情報には、１０９０ＭＨｚ拡張スキッタリンク(Squitter link)に基づくＡＤＳ−Ｂ（Automatic Dependent Surveillance-Broadcast）、又は、航空機の識別及び追跡のための他のビーコンが含まれうる。例えば、各航空機２０２、２２０、２２２は、ＡＤＳ−Ｂデータリンクを用いて、当該航空機の正確な位置、速度（垂直方向及び水平方向の両方）、ならびに、高度その他の情報を、管制官(controllers)及び近くの他の航空機に自動的に送信することができる。

同様に、航空機内ネットワークシステムは、Ａ２Ｉネットワーク２３６を介して、衛星２２４、空港アクセスポイント２２６、航空交通管制（ＡＴＣ）地上局２２８、及び／又はセルラー基地局２３０と通信することにより、航空会社インフラストラクチャ実体に対する情報の送受信を行う。いくつかの例において、航空会社インフラストラクチャ実体とのＡ２Ｉリンクは、飛行機が空中にある際には、ブロードバンド衛星を介し（ＳＡＴＣＯＭを介し）、地上にある際には８０２．１１リンクを介する。いくつかの例において、ＡＴＣセンターは、航空交通管制地上局２２８を介して、ビーコン、交通情報、及び／又は、他の航行情報を送信する。いくつかの例において、ＡＴＣ地上局との通信は、衛星又は地上無線リンクを通じて、航空プロトコルを介して行われる。ＡＤＳ−Ｂは、ＡＴＣセンターとの追加のＭｏｄｅ Ｓ無線リンクを提供することができる。いくつかの例において、第三者プロバイダが、セルラー基地局２３０を介して、インターネット、ブロードバンド、および他のサービスを提供しうる。

機内及び機外の両方の航空プラットフォーム及びインフラストラクチャの「e-Enabling」により、相互接続された物理的システム及びサプライチェーン・インフラストラクチャ（supply chain infrastructure）が実現したが、ネットワーク接続されたコンピューティングシステムに対するアクセスの増加によって、これらは今では、活発且つ増大するサイバーセキュリティ脅威の潜在的なターゲットとなっている。航空プラットフォーム及びインフラストラクチャは、多様な運航上の重要性、信頼性、及び可用性要件を備えた、階層的にネットワーク接続された組み込みシステム及びコントローラを含む複雑なシステムである。さらに、組み込みシステム及びコントローラは、汎用コンピューティングデバイスハードウェア、商用ソフトウェアオペレーティングシステム、及び、意図されたシステム機能を実行する特定のカスタムアプリケーション上で、ますますホストされるようになってきている。これらの機内組み込みシステム及びコントローラは、ＩＰ及びＩＥＥＥの有線及び無線通信ならびにネットワークプロトコルなどの、ＩＥＴＦ及びＡＲＩＮＣ基準に基づいたプロトコルを介して、ネットワーク接続することができる。また、機内システムは、ＵＤＰ及びＴＣＰなどの標準的なＩＥＴＦ ＩＰベースのプロトコルを介して、機外のコンピューティングシステムとネットワーク接続することができる。標準ベースのコンピューティング及び通信プロトコルの使用が増加すると、e-Enableされたアーキテクチャの全体的な統合が可能になるが、これによって、サイバーセキュリティ攻撃に対する脆弱性が増加する可能性もある。

様々な例において、e-Enableされた航空プラットフォーム２００内で接続される実体には、信頼できるものもあれば、信頼できないものもある。従って、このようなe-Enableされた航空プラットフォーム２００における不正データフローを阻止するとともに、飛行フェーズ、航空機の位置、時間、及び位置を含むシステムのコンテキストに基づいて、情報及び／又は通信をフィルタリングすることが重要である。

図３Ａは、１つ又は複数の実施例による、コンテキストアウェアなネットワークフィルタリングの方法の一例３００を示している。ステップ３０１において、ネットワークメッセージが受信される。いくつかの例において、ネットワークメッセージは、システム１００及び／又はシステム１０１などのシステム内の装置間で、ネットワークフロー内の１つ又は複数のネットワークパケットによって送信される。いくつかの例において、機能ネットワークフローは、送信元から宛先への一連のパケットであり、宛先は、例えば、ホスト、マルチキャストグループ、またはブロードキャストドメインである。いくつかの例において、機能ネットワークフローは、特定の期間内の以下のパラメータ、すなわち、送信元及び宛先ＩＰアドレス、送信元及び宛先ポート、及び、レイヤー４プロトコルによって、一意的に識別される。様々な例において、機能ネットワークフローは、システム１１０及び／又はシステム１１４などの様々な送信元から送られる。

ステップ３０３において、その時点のシステムのコンテキストが判定される。いくつかの例において、その時点のシステムのコンテキストは、特定の飛行フェーズに対応する。いくつかの例において、当該システムのコンテキストは、捕捉されたネットワークメッセージ、すなわち特定の飛行フェーズを示す飛行フェーズメッセージに基づいて特定される。他の例において、その時点のシステムのコンテキストは、他の測定値に基づくものであり、様々なシステム及び装置から受信した他の情報に基づいて特定される。様々な例において、システムのコンテキストは、以下のもの、すなわち、位置、日付、時間、装置状態、及び、飛行フェーズのうちの１つ又は複数を含む。システム１００及び／又は１０１などのシステムの位置は、全地球的測位システム（ＧＰＳ）、又は、無線周波数（ＲＦ）位置特定手法を含む他のジオロケーション手段、例えば、ＴＤＯＡ（Time Difference Of Arrival）、セルラータワーによる三角測量、もしくは、ＩＰアドレス、ＭＡＣアドレスＲＦＩＤなどとの関連付けによるインターネット及びコンピュータによるジオロケーションなどによって、求めることができる。様々な例において、システムの装置状態は、動作モード、メンテナンスモード、及び／又はデータロードモードを含む。さらに、様々な例において、システムは、特定の飛行フェーズにありうる。例えば、飛行フェーズとして、以下の動作状態が挙げられる。すなわち、パワーオン、プリフライト、エンジンスタート、イン・ゲート（in-gate）、タクシー・アウト、離陸、初期上昇（initial climb）、上昇（climb）、巡航（enroute cruise）、降下、着陸進入（approach land）、ロールアウト、タクシー・イン、ゴーアラウンド、及び、エンジンシャットダウンなどである。例えば、航空機が、ゲートを離れている及び／又は空中にある飛行フェーズ中は、システム又は航空機は、動作モードにある。また、航空機が地上にある場合、その時点のシステムは、メンテナンスモードでありうる。いくつかの例において、航空機がターミナルゲートに到着する時間と次のフライトに出発する時間との間の１つ又は複数の飛行フェーズ中は、航空機は地上にあると考えられる。そのような飛行フェーズには、限定するものではないが、イン・ゲート、エンジンシャットダウン、プリフライト、及び、エンジンスタートが含まれうる。他の例において、タクシー・イン及びタクシー・アウトなどの他の飛行フェーズ中にも、航空機が地上にあると考えられる。いくつかの例において、システムがメンテナンスモードにある際には、ショップ・フォールト・データ（shop fault data）のダウンロード、コンフィギュレーション情報の照会、及び、新たな動作又はコンフィギュレーションデータの列線交換ユニット（ＬＲＵ）へのデータロードなどの、通常のメンテナンス作業のみが許可される。

様々な例において、飛行フェーズに応じて、様々なネットワークメッセージ及び／又はフローが、e-Enableされたプラットフォーム上で許可及び／又はブロックされる。例えば、プリフライトフェーズは、航空機の出発準備に伴う任意の作業を含みうる。この間、乗務員は、航空機の耐空性(airworthiness)を判定し、出発前に未解決の問題に対処しなければならない。いくつかの例において、航空機は、広範囲に及ぶ自動飛行機能を有しており、当該機能は、航行及びパフォーマンスの最適化タスクのうちの多くを、所望に応じて自動処理できるようにするものである。自動飛行の初期設定及び飛行管理システム（ＦＭＳ）のプログラミングが、プリフライトフェーズ中に行われうる。様々な例において、プリフライトフェーズ中に、必要な飛行パラメータが、システム内で選択又はプログラムされる。いくつかの航空会社は、自動飛行システムを初期化するのに必要な情報を、ＡＣＡＲＳ（Aircraft Communication and Reporting System）データリンクユニットを介して自動的にアップロードすることを可能にする情報システムを有している。ＡＣＡＲＳは、通常、ＶＨＦデータリンク及び英数字インターフェイスを用いて、航空機と中央航空会社オペレーションセンター（ＡＯＣ）との間の会社固有の通信を実現している。

出発前飛行フェーズでは、出発予定時刻が近づくと、機長、ゲート案内係、及び地上クルーチーフが連携して、すべての出発前の要件が満たされているかどうかを確認する。例えば、パイロットは、空港ターミナル情報サービス（ＡＴＩＳ）を通じて気象条件及び滑走路の使用率に関する最新情報を入手することにより、ＦＭＳ及び自動飛行のパラメータを最終決定する。さらに、乗務員は、ＡＴＣから飛行経路の確認を受けなければならない。出発予定時刻より前（通常少なくとも数時間前）に、航空会社のディスパッチャーは、飛行計画最適化に基づいた要請経路を、ＡＴＣに提出する。出発の約２０分前に、好ましくはＡＣＡＲＳのＰＤＣ（Pre-Departure Clearance）機能によって、ＡＴＣ経路許可（クリアランス）が要求される。乗務員が受信するＡＴＣ経路許可は、提出された経路とは異なる場合があり、このような変更に対する対処（燃料／パフォーマンス／ディスパッチ検討）及び再プログラムを行わなければならない。

経路変更に加えて、ＡＴＣが、その時点の空域状況のために、予定された出発時間を調整することもありうる。ＡＴＣの許可（クリアランス）には、渋滞、経路の干渉、又は悪天候条件に起因する、「ゲートホールド」又は予想「ホイールアップ」時間が含まれうる。航空機の移動に備えて、地上クルーは、遅延荷物を含む荷物及び貨物積み込みを完了し、貨物ドアを閉じる。通常、機長は、牽引車ドライバー（又はその他の地上クルー）と、「インターホン」リンクを通して通信し、副操縦士は、ＶＨＦ無線によって、ランプコントロール及び／又はＡＴＣと通信する。

例えばタクシー・アウト・フェーズなどにおいて地上動作を開始する場合はいつでも、管制機関から許可を受けなければならない。ランプエリアを離れる前のどこかの時点で、副操縦士が地上管制と連絡を取り、使用滑走路へのタキシング許可を得る。離陸重量が大きいなどの動作上の考慮事項によっては、特別な滑走路の使用が要求される場合があり、この場合は、修正された一連の作業をＡＴＣが行うため、タキシング及び／又は離陸の遅延が起こりうる。タキシング中に、ＡＣＡＲＳ又はＶＨＦ無線によって、ロードクローズアウト（load closeout）が受信される。多くの先行する出発便が離陸のために順につかえているためにタキシングの時間が長くなりそうな場合は、機長が、乗客及び客室乗務員に、遅延長さの最善の予測時間を知らせる機内アナウンスを行うこともある。遅延が大幅な場合は、会社は、ＡＣＡＲＳ又はＶＨＦ無線を用いて、新たなＥＴＯ（estimated time "OFF"）を反映する更新を行わなければならない場合もある。航空機が滑走路の出発末端に近づくと、離陸が迫っていること及び自身の席に着くべきことを客室乗務員に知らせるために、機長が出発時機内アナウンスを行うこともある。乗客用説明（ビデオ）が表示される場合もある。

様々な例において、離陸フェーズ中のネットワークメッセージは、管制塔から航空機への様々な通信を含む。例えば、滑走路を最も効率的に使用するために、ローカルコントロールの管制官は、最終の離陸許可の準備段階として、「滑走路上で待機（position and hold)」許可を出すことがあり、これは、航空機が、所定位置までタキシングし、他の交通や滑走路制限が終わるまで、あるいはＡＴＣ（航空交通管制）指示の離陸時間まで、離陸滑走路上で待機することを許可するためのものである。あるいは、このような待機時間が必要でない場合や、離陸を早める必要がある場合は、管制塔は、所定位置での待機なしでの離陸をフライトに許可する。別の例として、フライトが大型の航空機の離陸に続くものである場合、離陸滑走を開始する前に、許容可能な時間が経過したかを確認することによって、ウェーク回避のための十分な時間間隔要件を保証しなければならない。

順調な離陸の後に、通常は、上昇フェーズが行われる。正常な初期上昇（climb-out）は、任意のノイズ及び／又は障害物の要件に合わせながら航空機を「クリーンアップ」（ギア上昇、フラップ／スラット格納）することを含む。ＡＴＣの指令の受け入れを含む、フライト環境の状況によって、乗務員が、最良の飛行プロファイルを実現するために、継続して航空機のパフォーマンスを監視する必要が生じる。上昇中のどこかの時点で、コックピット・クルーは、ＦＭＳ及び／又はパフォーマンス・チャートをチェックし、最適且つ最大の巡航高度を、計画データ及び所望の巡航マッハと比較する。この情報を用いて、最適な巡航高度をＡＴＣと共に調整する。他の因子には、ウィンド・データ及びライド（乱気流）状況、対流性気象、運用許容基準（ＭＥＬ：Minimum Equipment List)偶発事、トラフィックに起因する速度制限、及び、燃料消費問題が含まれる。上昇中における乗客関連アクティビティーには、食事及び／又は飲み物サービス、何らかの商業用の機内アナウンス、及び、何らかの娯楽システムの起動が含まれる。加えて、機長は、通常、巡航時間、気象状況、主な通過ポイント、予定到着時刻、及び、到着地天候を知らせる機内アナウンス、そして、場合によっては、増員された乗務員の存在及び／又は安全情報に関する何らかの情報を知らせる機内アナウンスを行う。

いくつかの例において、巡航フェーズ中に巡航高度に達すると、出力設定及び／又はマッハターゲットが確定され、乗務員はＡＴＣに高度を報告する。乗務員は、何らかの出発遅延ＡＣＡＲＳコードのダウンリンクや、エンジンモニターログ（自動化されていない場合）の記録を含め、様々な管理上の義務も行う。航空機は、通常、少なくとも２つのＶＨＦトランシーバを備えており、水上認証されている場合は、ＨＦ無線を備えている。ＶＨＦ無線管理では、通常、一方のチューナーをその時点のＡＴＣ周波数に設定する必要があり、もう一方は、社内通信に使用するか、汎用の緊急チャンネル（１２１．５ＭＨｚ）での受信監視を維持する必要がある。衛星通信（ＳＡＴＣＯＭ）は、ＡＴＣと社内通信の両方に利用可能な場合に使用されうる。ＳＡＴＣＯＭシステムには、信号劣化、時刻によるばらつき、及び、ＨＦに関連するその他の欠点の無い、全世界に及ぶ通信カバレッジという利点をもたらす。さらに、地上施設とのＶＨＦによる接触が行えない場合、乗務員は、通常、空対空周波数の１２３．４５ＭＨｚに受信監視を維持する。このチャンネルは、ライドレポート（ride report）及び巡航気象などの操作上の情報を航空機間で直接やりとりするのに用いられる。

他の例において、巡航高度決定に利用可能な情報源には、他のフライトからのパイロットレポート（ＰＩＲＥＰ）、ＡＴＣ、乗務員自身の経験、ディスパッチ、及び、フライトプランが含まれる。国際線では、他の国家主権の管轄下にある空域境界を越えて飛行するには、地域の規制に対応するための追加の手続きが必要な場合がある。このようなＦＩＲ（飛行情報区）の境界は、通常、飛行計画プロセス（提出フライトプラン）による事前通知、及び、フライトが境界に近づく際の航空機による予備連絡を必要とする。一般的に、洋上空域への進入を含め、各境界交差地点で別個のＡＴＣ許可が発行されなければならない。

悪天候のために所望の軌道から逸れる必要が生じる可能性は、常に存在する。対流性気象や雷雨の場合、計画経路から逸れる必要があるが、これは、ＶＨＦ／レーダー環境におけるＡＴＣとの連携によって容易になる。飛行における他のフェーズ中と同様に、不測の事態によって航空機を進路変更させて代替の空港まで飛行する必要が生じる可能性に、乗務員は、常に備えていなければならない。目的地空港の（天候、停電、又は他の現場状況による）閉鎖に加えて、進路変更の要因には、医療的な緊急事態（病気の乗客／乗務員）、航空機の設備の問題、機内でのテロ行為、容認不可能な待機時間、風又は交通遅延による燃料消費が含まれる。

降下フェーズ中は、フライト時間が約３０〜４０分残っている状態で初期降下が行われ、この間に、乗務員は進入（アプローチ）及び着陸の準備を開始する。ＡＣＡＲＳ又はＶＨＦ無線によって、到着地のステーションに「In Range」メッセージがしばしば送信される。このメッセージは、最新の着陸予定時刻、特別な乗客リクエスト（車いす／コネクション）を含み、まだ送信されていなければ、メンテナンスの不具合を含む。一方、ステーションは、到着ゲート割り当て、地上電源ユニットのステータス、及び、割り当てられたゲートの「トウイン（tow-in）のみ」要件などの、任意の他の関連するステータスメッセージを送信又はアップリンクする。降下中に、ＡＴＣは、ＳＴＡＲ（Standard Terminal Arrival Route）又はトラフィックシーケンス要求に対する応答のような、通達されている標準的な到着手続きの一部でありうる高度制限を発令しうる。制限は、ＣＤＵ及び計算されたプロファイルを介して直接プログラムすることができるので、ＦＭＳは降下計画のために乗務員が利用できる主要なリソースである。

目的地の天候及び予測される進入（アプローチ）／滑走路方式は、到着を計画する際の主要な考慮事項である。この情報の主な情報源は、ＡＴＩＳ（Airport Terminal Information System）である。ただし、ホールディング（待機）遅延、気象条件、滑走路の運行状況は、ＡＴＣ及び／又はディスパッチによって伝達されうる。ＡＴＩＳは、現在の天気、採用されている計器進入操作手順、使用中の滑走路、並びに、滑走路及び誘導路の閉鎖に関する詳細、ウィンドシアー報告、個々の滑走路の正確な視程値、制動能力、鳥の活動、一時的な障害物（例えば工事）、ＬＡＨＳＯ（land and hold short operations）の使用、及び、任意の他の関連する安全関連情報を提供する。

ほとんどの航空会社によって使用される航空機は、通常、進入フェーズのための様々な進入方式のナビゲーション要件を満たすように装備されている。精密進入には、前述したように、全地球的測位システム（ＧＰＳ）自動着陸、ＧＰＳ ＬＮＡＶ／ＶＮＡＶ、及び、カテゴリー（ＣＡＴ）Ｉ、ＩＩ、ＩＩＩのＩＬＳ進入がある。大きな空港の多くの滑走路は、計器着陸システム（ＩＬＳ: Instrument Landing System）を用いて、其々ローカライザー及びグライドスコープと呼ばれる横方向要素及び垂直要素で構成された明確な経路に沿う誘導を、計器飛行中にパイロットに与える。非精密進入は、ローカルの航法支援（ナブエイド：Navaid）又は衛星によって横方向の軌道情報は提供されるが、垂直方向の誘導は、特定の滑走路に直接関連しない気圧による基準又は他の手段によって行われる方式である。予測されるように、精密進入は、上昇限界及び視界がはるかに低い条件下での操作のためのものである。

進入及び着陸を完了するための要件が満たされない場合は、ゴーアラウンド・フェーズが実行され、これに続いて、標準化された「進入複行手順」及び／又はＡＴＣ指示が行われなければならない。進入複行に続いて取ることができる選択肢には、着陸中止の原因となっている、容認できない状況が解消されるのを待つべくホールディングに入る、代替の空港への進路変更、又は、最も一般的なものとして、別の進入を開始するためのＡＴＣによる誘導を受け入れること、がある。多くの着陸中止が、滑走路の交通が原因で、ＡＴＣ又はコックピット・クルーによって提案される。ほとんどの場合、先行する到着機が適時に滑走路をクリアできなかったことが原因で着陸中止となるが、滑走路端部位置についている航空機による離陸の遅延が原因の場合もある。

滑走路に着陸すると、着陸及び／又はロールアウトフェーズにおいて、パイロットは、逆推力、グラウンドスポイラー、及び、車輪制動を利用して、タクシング速度まで減速し、滑走路から離れる。滑走路を出た後、副操縦士は、タクシー・インの指示を求めて地上管制と連絡を取り、着陸後タクシーチェックリストを完了し、到着ゲートの割り当て及び占有状況を確認するために、ローカルのランプコントロールを呼び出す。タクシー・イン・フェーズの間、パイロットは、ＡＴＣによって与えられたタクシー許可の実行を手助けするための、到着地空港の誘導路チャートを利用することができる。到着ゲートに空きが無い場合、航空機は、離れた位置で、遅延状態の解消を待つ必要があるかもしれない。ゲートに空きが無い状態は、その時点でゲートに位置している航空機の離陸の遅延やその他の運航上の問題によってしばしば起こり、予測される遅延時間がＡＴＣ及び乗客に伝達されることになる。ステーションの中には、自動パーキングシステムを用いているものもあり、これは、機長がリードインライン及び停止位置のガイドとして用い得るライト及び／又はサインを配置したものを含んでいる。

ステップ３０５において、ネットワークメッセージの送信元装置が特定され、ステップ３０７において、宛先装置が特定される。いくつかの例において、送信元／宛先装置は、例えば図１Ｂに示した装置のような、航空ネットワーク内の１つ又は複数の様々なアビオニクス装置である。別の例において、送信元及び／又は宛先装置は、プロセス、アプリケーション、デバイス、及び／又はオペレーティングシステム（ＯＳ）である。前述したように、機能ネットワークフロー及びそれに含まれるネットワークメッセージは、特定の期間内の以下のパラメータ、すなわち、送信元及び宛先ＩＰアドレス、送信元及び宛先ポート、及び、レイヤー４プロトコルによって、一意的に識別される。いくつかの例において、ファイアウォール１１２のようなファイアウォールが、送信されたネットワークパケットを検査し、パケットの送信元及び宛先アドレス、プロトコル、ＰＣＴ及びＵＤＰトラフィックの場合はポート番号、の組み合わせなどの、パケットに含まれる情報に基づいて、ファイアウォールの一組のフィルタリングルールにパケットが合致しているかどうかを判定する。

いくつかの例において、ファイアウォールは、ネットワーク層ファイアウォール、パケットフィルター、アプリケーション層ファイアウォール、及び／又はそれらの任意の組み合わせである。いくつかの例において、ファイアウォールは、パケットが既存のトラフィックのストリームの一部であるかどうかを判定することなく（例えば接続「状態（ステート）」についての情報を記憶せずに）パケットそのものに含まれている情報のみに基づいて各パケットのフィルタリングを行うステートレス(stateless)ファイアウォールである。他の例において、ファイアウォールは、ステートフル(stateful)ファイアウォールであり、これは、アクティブなセッションについてのコンテキストを維持し、その「状態情報」を用いてパケット処理を高速化することができるものである。例えば、図１Ｂに矢印Ａで示したような既存のネットワーク接続は、送信元及び宛先のＩＰアドレス、ＵＤＰ又はＴＣＰのポート、及び、接続の期間におけるその時点の段階（セッション開始、ハンドシェーキング、データ伝送、又は接続完了を含む）を含むいくつかのプロパティによって表すことができる。ネットワークパケットが既存の接続に合致しない場合、当該パケットは、新たな接続のルールセットに従って評価される。パケットが、ファイアウォールの状態テーブル(state table)との比較に基づいて、既存の接続に合致した場合、さらなる処理を行うことなく、通過が許可される。

ステップ３０９において、送信元装置から宛先装置へと送られているネットワークメッセージが、システムがその時点のコンテキストにある際に容認可能かどうかを判定するために、ネットワークメッセージのデータフィールドの内容を特定する。さらなる例において、ファイアウォールは、受信するネットワークパケットのディープ・パケット・インスペクション（deep packet inspection：DPI）を実行するためのディープ・パケット・フィルタリングルールを組み込んでいる。いくつかの例において、ディープ・パケット・インスペクション機能を有効にしたこのようなファイアウォールは、ＯＳＩモデルにおけるレイヤー２及びレイヤー３以上を調べる能力を有する。いくつかのケースにおいて、ＤＰＩを実行することによって、ネットワークメッセージのヘッダー、データプロトコル構造、ならびにペイロードを含め、ＯＳＩモデルのレイヤー２〜７を調べることができる。ＤＰＩ機能は、装置が、ＯＳＩモデルのレイヤー３以上の情報に基づいて、見るあるいは他のアクションを取る際に実行される。いくつかの例において、ＤＰＩは、パケットのデータ部分から抽出された情報を含むシグネチャデータベースに基づいて、トラフィックの特定及び分類を行うことができ、これにより、ヘッダー情報のみに基づく分類よりも、精緻な管理が可能となる。いくつかの例において、ネットワークメッセージを、ファイアウォールによって、例えばディープ・パケット・インスペクションを通じて、さらに調べることによって、受信したネットワークメッセージの追加の属性を特定及び／又は判定することができる。様々な例において、このような属性には、例えば、装置状態、飛行フェーズ、ファンクション、サブファンクション、データフロー、及び／又はプロトコルがある。いくつかの例において、このような属性は、ネットワークパケットのヘッダー及びデータフィールドに対応し、ネットワークメッセージによって開始されるアクションの種類を示す。

いくつかの例において、ネットワークメッセージによって開始されるアクションは、開く、印刷する、コピーする、スタートする、書く、及び／又は、通信する、などの様々なアプリケーションベースのアクションである。他の例において、ネットワークメッセージによって他のアクションが開始される。いくつかの例において、ネットワークメッセージのこのようなアクションは、装置状態及び／又は対応する飛行フェーズと関連付けられている。前述したように、このような飛行フェーズには、限定するものではないが、プリフライト、エンジンスタート、イン・ゲート、タクシー・アウト、離陸、初期上昇、上昇、巡航、降下（ディセント）、着陸進入、ロールアウト、タクシー・イン、ゴーアラウンド、及び、エンジンシャットダウンがある。いくつかの例において、このような飛行フェーズのうちの１つ又は複数は、動作モード、メンテナンスモード、又はデータロードモードなどの装置状態に対応する。

いくつかの例において、ネットワークメッセージのファンクション、サブファンクション、及びデータフローは、ネットワークメッセージによって搬送されるメッセージ、及び／又は、ネットワークメッセージによって開始されるアクションを分類するものである。例えば、ネットワークメッセージのファンクションには、無線データロード、ＣＭＣＦ（central maintenance and computing functions）、印刷ジョブなどがある。さらに、主要な航空機ファンクションの他のファンクション・フローには、例えば、飛行管理、推力管理、及び／又は、航空機状態監視（aircraft condition monitoring）がある。このような機能フローは、サブファンクションを含みうる。サブファンクションも、様々なデータフローとして表すことができる。様々な例において、ネットワークメッセージのサブファンクションは、ネットワークメッセージのファンクションの特定の実施態様である。例えば、無線データロードファンクションは、ＩＥＥＥ８０２．１ｘ、６１５Ａ、コンフィギュレーション報告、印刷リクエストなどのサブファンクションを含みうる。

いくつかの例において、ネットワークメッセージのデータフローは、ネットワークメッセージによって開始される特定のアクションを表す。いくつかの例において、データフローは、テンポラル交換又はプロトコル交換である。例えば、無線データロード及び印刷ジョブを含むファンクション・フローは、プロトコル交換である。８０２．１ｘ認証は、プロトコルデータフロー交換の別の例である。対気速度及び／又は高度データフローは、テンポラルデータフローの一例である。ＣＭＣＦ（central maintenance computing functions）は、テンポラルとプロトコルの両方のデータフローを含みうる。例えば、セッションを確立しない、連続する「ＢＩＴＥ」（build in test equipment）報告は、テンポラルデータフローである。同様に、確立されたメンバーシステムリストから投稿された機能ステータスは、テンポラルデータフローである。別のテンポラルデータフローとしては、確立されたメンバーシステムリストからのデータのために待ち行列に入っているファンクションがある。ただし、ＣＭＣＦからの列線交換ユニット（「ＬＲＵ」）の照会は、プロトコルデータフローである。

例えば、ネットワークメッセージは、下記の表１のネットワークメッセージ４のように、アビオニクス装置にソフトウェアをアップロードするためのアクションでありうる。このようなネットワークメッセージは、例えば航空機がイン・ゲート飛行フェーズにある際などの、システムがデータロードモードにある際にのみ許可されうる。このようなネットワークメッセージは、「無線データロード」ファンクション、「６１５Ａ」サブファンクション、「データ伝送」データフロー、及び、ＴＦＴＰプロトコルをさらに含みうる。考えられるネットワークメッセージのさらなる例を、下記の表１に示している。

表１は、ネットワーク接続された航空プラットフォーム内のシステム１１０、システム１１４、及び／又は、他のコンピュータシステム、ＬＲＵ、及び／又は装置間で伝送されうる、考えられるネットワークメッセージを含む。表１に示すように、メッセージ３〜１２は、プリフライト飛行フェーズ中のデータロード動作に関連しており、データロードファンクションとして特定されている。このようなデータロード動作は、メンテナンス・ラップトップ（Maintenance Laptop）１２６などの無線メンテナンス・ラップトップによって行われる、機内ネットワークシステム（ＯＮＳ）によるＣＭＣ（Central Maintenance Computer）ＬＲＵのデータロードに対応する。前述したように、データロードファンクションは、イン・ゲート飛行フェーズ中及び／又はタクシー・アウト飛行フェーズ中などの、航空機が地上にある際のメンテナンスモードにおいてのみ許可される、メンテナンス動作でありうる。いくつかの例において、無線データロードファンクションは、ロード可能なターゲット間でデータファイルを交換する作業を含む。このような作業は、ネットワーク上の利用できるロード可能ターゲットを発見し、ロード可能ターゲットのその時点のコンフィギュレーションを照会し、新たな又は更新されたソフトウェア及びコンフィギュレーションファイルをロード可能ターゲットにロードし、ロード可能ターゲットからデータファイルをダウンロードすることなどを含む。

メッセージ３〜５のデータロード動作のサブファンクションは、ＩＥＥＥ８０２．１ｘとして特定されている。ポートベースのネットワークアクセス制御（ＰＮＡＣ）のためのＩＥＥＥ８０２．１ｘ規格は、ＥＡＰＯＬ（EAP over LAN）としても知られている、ＩＥＥＥ８０２による拡張認証プロトコル（ＥＡＰ）のカプセル化を定義するものである。例えば、機能ネットワークフロー３、４、５は、ＩＥＥＥ８０２．１ｘサブファンクションを含む。表１にさらに示すように、メッセージ３のデータフローは、メンテナンス・ラップトップ（ＭＬ）１２６に対応するソースアドレス４から、オンボード・ネットワーク・システム（ＯＮＳ）１２２に対応する宛先アドレス２へのＭＬ認証要求として特定されている。ネットワークメッセージ４のデータフローは、無線データロードを開始するための、ＯＮＳ１２２からＭＬ１２６へのＭＬ認証許可として分類されている。ネットワークメッセージ５のデータフローは、ＭＬ１２６からＯＮＳ１２２へ、そしてＯＮＳ１２２の追加のポートＢへの、ＯＮＳによるＣＭＣデータロードのＭＬによる要求として特定されている。

他の例において、無線データロードファンクションのためのネットワークメッセージのサブファンクションは、ＡＲＩＮＣ ６１５Ａ規格であり、これは、イーサネット、ＣＡＮ（Controller Area Network）、及び／又は、ＡＲＩＮＣ６６４などの様々な種類のネットワークを介して航空機へのデータロード作業を行うために用いられる。いくつかの例において、６１５Ａ規格を用いるソフトウェアが、１つ又は複数のターゲットについてのアップロード、バッチ・アップロード、ダウンロード、サーチ、情報データロードの作業を行う。例えば、表１のネットワークメッセージ６〜１２は、データロードファンクションのための６１５Ａサブファンクションを含むものとして特定されている。機能ネットワークフロー６は、「セッション確立要求」データフローをさらに含み、これは、ある種の例において、システム１１０と１１４との間などの、装置間のインタラクティブな情報交換を開始するものである。「セッション確立要求」は、ＯＮＳ１２２に対応する送信元アドレス２から、ＣＭＣ１２４に対応する宛先アドレス３に送信される。ネットワークメッセージ７は、ＣＭＣ１２４からＯＮＳ１２２に送信される、「セッション確立許可」データフローを含む。ネットワークメッセージ８は、「データ伝送」データフローをさらに含み、これは、ＯＮＳ１２２とＣＭＣ１２４との間のデータのダウンロード及び／又はアップロードを開始しうるものである。いくつかの例において、このようなダウンロード及び／又はアップロードは、ＴＦＴＰ（Trivial File Transfer Protocol）を含み、ネットワークメッセージ８のプロトコルは、このプロトコルとして確認されている。ネットワークメッセージ９、１０、１１も、同様に、ＯＮＳ１２２とＯＭＣ１２４との間でのＴＦＴＰプロトコルを用いた「データ伝送」データフローを含む。別の例において、無線データロード作業において、他のプロトコルを実施することもある。最後に、ネットワークメッセージ１２は、「セッションクローズ」要求を含み、これは、ある種の例において、ＯＮＳ１２２とＯＭＣ１２４との間でデータが完全にダウンロード及び／又はアップロードされた後に、これらの装置間でのインタラクティブな情報交換を終了しうるものである。

メッセージ１３及び１４も、プリフライト飛行フェーズに対応するものとして特定されており、プリンタ動作に関連するものである。表１に示すように、メッセージ１３及び１４は、印刷ファンクションとして特定されている。ネットワークメッセージ１３及び１４は、「印刷要求」として特定されたサブファンクションをさらに含み、これは、ある種の例において、機能ネットワークフロー６〜１２によって確立されたデータロードのプリントアウト要求に対応する。ネットワークメッセージ１３は、「セッション確立」データフローを含み、これは、ＯＮＳ１２２とプリンタ１３０との間などの、装置間のインタラクティブな情報交換を開始するものである。機能ネットワークフロー１３は、データフロー００２のための「印刷」データフロー分類を含み、これは、プリンタ１３０での報告の印刷を開始しうるものである。

別の例として、メッセージのファンクションが、ＣＭＣＦ（central maintenance control function）の場合もありうる。表１に示すように、ネットワークメッセージ１５〜１８は、ＣＭＣＦファンクションとして特定されており、これは、メンテナンス報告要求を示しうるものである。ある種の例において、ＣＭＣＦは、誤りを除外するとともに、中央集中化された誤り報告を通じて適切なメンテナンス動作をガイドするために、航空機の機内メンテナンスシステムとの通信を開始及び／又は受信しうる。いくつかの例において、ＣＭＣＦは、誤り報告の統合、メッセージの関連付け、及び、ＦＤＥ（flight deck effect）相関を許可する。

メッセージ１５及び１６は、ＣＭＣコンフィギュレーション報告に関連している。表１に示すように、ネットワークメッセージ１５及び１６は、コンフィギュレーション報告サブファンクションとして特定されている。ネットワークメッセージ１５は、コンフィギュレーション報告を要求する、ＣＭＣ１２４からＦＭＣ１２０への「報告要求」データフローを含む。続いて、ネットワークメッセージ１６は、ＦＭＣ１２０からＣＭＣ１２４への「報告送信」データフローを含む。

メッセージ１７及び１８は、ＣＭＣ ＢＩＴＥ報告に関連している。表１に示すように、ネットワークメッセージ１７及び１８は、ＢＩＴＥ報告サブファンクションとして特定されている。ＢＩＴＥ（Built-In Test Equipment：内蔵試験装置)は、概ね、メインテナンスプロセスをサポートするために機内システムに組み込まれた、受動的な誤り管理及び診断装置と言える。内蔵試験装置は、試験可能とするとともに診断を行うためにシステムの一部として設けられたマルチメーター、オシロスコープ、放電検出プローブ、周波数発生器のことを指し得る。ネットワークメッセージ１７は、ＣＭＣ１２４からフライト・マネジメント・コンピューター１１２への「報告要求」データフローを含み、これは、ＦＭＣ１２０の診断の要求に対応しうる。次に、ネットワークメッセージ１８は、ＣＭＣ１２４に診断報告を提供する、ＯＮＳ１２２からＣＭＣ１２４への「報告送信」データフローを含む。

残りのネットワークメッセージ１、２、及び、１９〜３８は、ＦＭＣ大気データファンクションとして特定されている。図１Ｂに示すフライト・マネジメント・コンピューター１２０のようなＦＭＣは、様々な飛行中のタスクを自動化し、運航乗務員の作業負荷を軽減する、特殊なコンピュータシステムである。ＦＭＣの第一の機能は、飛行計画の飛行中管理である。ＦＭＳは、ＧＰＳや慣性航法装置（INS: inertial navigation system）などの様々なセンサーを用い、時には無線通信ナビゲーションによるサポートも受けて、航空機の位置を判別し、飛行プランに沿って航空機を誘導する。これらのネットワークメッセージは、さらに、「高度」データフロー及び「対気速度」データフローを含み、これらは、それぞれ、航空機の高度及び対気速度を表しうるものである。このようなデータフローが、フライト・マネジメント・コンピューター（ＦＭＣ）１２０に対応する送信元アドレス１から、ＣＭＣ１２４に対応する宛先ソース３に送信される。

ステップ３１０において、システムは、送信元装置から宛先装置に向けて送られているメッセージが、システムがその時点のコンテキストにある場合に容認可能であるかどうかを判定する。システムは、ディープ・パケット・インスペクション機能を用いて、ネットワークメッセージのデータを特定するとともに、フィルター・ルールを参照することにより、その特定のコンテキスト（位置、時間、装置状態、飛行フェーズなど）中に、ある実体（送信元装置）が別の実体（宛先装置）に特定のアクション（ネットワークメッセージデータ及び属性）を取ってよいかどうかを判定する。前述したように、実体とは、図１Ａ及び図１Ｂに示したような、航空ネットワーク内の１つ又は複数のアビオニクス装置のことを指し得る。いくつかの例において、実体は、１つ又は複数のそのようなアビオニクス装置の集合体である。このコンテキストアウェアなプロセスの出力は、多くの数の質問を含みうる。例えば、誰が権限を有するか（どの（送信元）実体、役割制約）、何をすることを許可されているか（アクション制約）、どこからそれを行うことができるか（位置制約）、いつそれを行うことができるか（時間制約）、どのようにしてそれを行うことができるか（プロトコル／ＡＰＩ制約）及び、誰（どの（宛先）実体）に対してそれを行うことができるか、などである。このような制約は、コンテキストベースの制御を利用して実施することができ、その結果は、コンテキストアウェアな認証と考えることができる。現在のファイアウォールのルールが、第１の装置がある種のプロトコルを用いて第２の装置と通信して良いかどうかを判定しているのと同等であるのに対して、コンテキストアウェアなフィルタリングは、特定のコンテキストにおいて、第１の実体が第２の実体に特定のアクションを取ることができるかどうかを判定していると言える。コンテキストアウェア・ベースのプロトコルは、２つの実体間の通信を制限する、はるかに充実した一組の制御を提供する。

送信元装置から宛先装置に向けて送られているネットワークメッセージが、システムがその時点のコンテキストにある場合に容認可能であると判定されると、ステップ３１１において、当該ネットワークメッセージが宛先装置に送信される。ネットワークメッセージが容認できない場合は、当該ネットワークメッセージは、宛先装置に送信されない。ステップ３１２において、システムは、当該ネットワークメッセージが最終のネットワークメッセージであるかどうかを判断する。当該ネットワークメッセージが、システム内で送信された最終のネットワークメッセージでない場合、ステップ３０１において別のメッセージが受信される。当該ネットワークメッセージが、システム内で送信された最終のネットワークメッセージである場合、ステップ３１３において、当該方法が終了する。

図３Ｂは、１つ又は複数の実施例による、オンボード・ネットワーク・システム（ＯＮＳ）を介してセントラル・メンテナンス・コンピュータ（ＣＭＣ）の無線データロードを行うための事象のシーケンス３５０を示している。図３Ｂは、無線メンテナンス・ラップトップ（ＭＬ）１２６を用いて、ＯＮＳ１２２を介したＣＭＣ１２４のデータロードを行うための、コンテキスト及びプロトコルのステップを表している。これらのステップは、表１におけるネットワークメッセージ３〜１２に相当する。サブジェクトマターエキスパート（subject matter expert）が、各コンテキストのキー・アクティビティーを決定することにより、コンテキストアウェアなフィルターを作成する。図３Ｂに示した例では、航空機は、プリフライト飛行フェーズにある。他の例において、このようなステップは、コンピュータ１０２及び／又はサーバー１０６などのコンピュータシステムによって行われうる。

まず、ステップ３５２〜３５６において、ＭＬ１２６が認証される。ステップ３５２は、ＭＬ１２６からＯＮＳ１２２へのＭＬ認証要求であるネットワークメッセージ３に対応している。ステップ３５４は、ＯＮＳ１２２からＭＬ１２６へのＭＬ認証許可であるネットワークメッセージ４に対応している。次に、ステップ３５６において、ＭＬ１２６は、図３Ａに示したように、ＯＮＳによるＣＭＣデータロードＭＬ要求に対応するメッセージ５を送信する。

メンテナンス・ラップトップ（ＭＬ）１２６が無線８０２．１ｘの認証を受けると、ステップ３５８及び３６０によって、６１５Ａセッションが確立される。ステップ３５８は、ＯＮＳ１２２からＣＭＣ１２４へのセッション確立要求であるメッセージ６に対応している。ステップ３６０は、ＣＭＣ１２４からＯＮＳ１２２へのセッション確立許可であるメッセージ７に対応している。ステップ３６２は、メッセージ８、９、及び１０に対応しており、ここで、ＴＦＴＰプロトコルを用いてＯＮＳ１２２からＣＭＣ１２４にメッセージが伝送される。各メッセージについて、フィルターは、上記の条件が満たされているかどうかをチェックし、図３Ａのステップ３１０のように、システム間でのメッセージの通過を許可することが可能である。

飛行フェーズは、システムのコンテキストを判定するために用いることができる１つのパラメータに過ぎない。これに代えて、システムは一連の作業を行っているので、それぞれの先行するステップをコンテキストとして用いて、メッセージが次のステップの要件を満たしているかどうかを判定することもできる。対気速度及び高度のメッセージ（ネットワークメッセージ１、２、及び１９〜３８）については、どの飛行フェーズでメッセージを通過させることができるかについての制限は無いため、このようなメッセージについてのフィルター・ルールは、送信元アドレス、宛先アドレス、ポート、及びプロトコルに基づいた標準的なＩＰテーブルのようなルールに似たものとなる。

図４Ａ、図４Ｂ、図４Ｃ、及び、図４Ｄは、１つ又は複数の実施例による、航空機用の航空ネットワーク内のネットワークメッセージを、その時点のシステムコンテキストに基づいて、自動的にフィルタリングするための追加的な方法４００を示している。ステップ４０１において、ステップ３０１と同様に、以下に詳述するプロセッサ５０１などのコンピュータシステムのプロセッサによって、ネットワークメッセージ４１５が受信される。ネットワークメッセージ４１５は、航空ネットワーク内の１つ又は複数のネットワークパケットによって送信される。ネットワークメッセージ４１５は、送信元アビオニクス装置から宛先アビオニクス装置に送信される。いくつかの例において、送信元アビオニクス装置及び／又は宛先アビオニクス装置は、コンピュータ１０２及び１０６などの様々な異なるアビオニクス装置、あるいはシステム１１０及び／又はシステム１１４内の様々なＬＲＵである。

ステップ４０３において、ステップ３０３と同様に、航空ネットワーク内の１つ又は複数のアビオニクス装置を監視することによって、その時点のシステムコンテキスト４１９がプロセッサによって確定される。いくつかの例において、システムコンテキスト４１９は、１つ又は複数のアビオニクス装置の総合的な状態４１７を表す。いくつかの例において、その時点のシステムコンテキスト４１９は、日付、時間、送信元アビオニクス装置の位置、宛先アビオニクス装置の位置、複数のアビオニクス装置の装置状態４２１、及び、航空機の飛行フェーズ４３２のうちの１つ又は複数の組み合わせである。いくつかの例において、複数のアビオニクス装置の装置状態４２１は、動作モード、メンテナンスモード、又はデータロードモードを含む。いくつかの例において、航空機の飛行フェーズ４２３は、以下の動作状態、すなわち、パワーオン、プリフライト、エンジンスタート、イン・ゲート、タクシー・アウト、離陸、初期上昇、上昇、巡航、降下、着陸進入、ロールアウト、タクシー・イン、ゴーアラウンド、及び、エンジンシャットダウンのうちの１つ又は複数を含む。例えば、その時点のシステムコンテキスト４１９は、１３００時間状態の２０１５年２月２８日における、航空機が地上の航空交通管制（ＡＴＣ）と通信しつつ上昇飛行フェーズにおける初期上昇を行っている動作モード中であるかもしれない。図３Ａ〜３Ｂに関連させて前述したように、様々な飛行フェーズ４１９中に、様々なネットワークメッセージ４１５が許可及び／又は阻止される。

ステップ４０５において、ステップ３０５、３０７、３０９、３１０と同様に、プロセッサによって、ネットワークメッセージ４１５の容認性が分析される。ネットワークメッセージ４１５の容認性は、ネットワークメッセージ４１５に対応する複数の属性４２５を特定する（４０９）ことによって分析される。いくつかの例において、ネットワークメッセージ４１５に対応する複数の属性４２５は、宛先アドレス、送信元アドレス、ネットワークメッセージの飛行フェーズ、ネットワークメッセージの装置状態、ファンクション、サブファンクション、データフロー、及びプロトコルのうちの１つ又は複数を含む。いくつかの例において、複数の属性４２５は、ネットワークメッセージ４１５に対応する１つ又は複数のネットワークパケットのヘッダー及びデータフィールド４２７に対応する。ステップ３０９において前述したように、ファイアウォール１１２のような、コンピュータシステム実行ファイアウォールプログラムが、ディープ・パケット調査又はステートフル・フィルタリングを行うことによって、属性を特定しうる。

ネットワークメッセージ４１５の容認性は、１つ又は複数のフィルター・ルール４２９に基づいて、システムコンテキスト４１９内でのネットワークメッセージの容認性を判定することによって、さらに分析される（４１１）。１つ又は複数のフィルター・ルール４２９は、特定のシステムコンテキスト内でどのような属性４２５が許容されるかを示すものである。様々な実施例において、フィルター・ルール４２９は、その時点のシステムコンテキスト４１９を含む、様々なシステムコンテキストについての許容可能な属性４２５を指定する。日付、時間、送信元アビオニクス装置の位置、宛先アビオニクス装置の位置、複数のアビオニクス装置の装置状態（４２１）、航空機の飛行フェーズ（４２３）及び／又は航空ネットワーク内の任意の他の動作が変化するのに応じて、他の様々なシステムコンテキストが、代わる代わる、その時点のシステムコンテキスト４１９になりうる。一例において、ある特定のシステムコンテキストが、その時点のシステムコンテキスト４１９である。いくつかの例において、１つ又は複数のフィルター・ルール４２９は、図３Ａ〜図３Ｂで説明したように、１つ又は複数のネットワーク接続パケットの１つ又は複数のペイロードを調べることによって、航空ネットワークにおける不正データフローを阻止する、１つ又は複数のディープ・パケット・フィルタリング・ルール４３１を含む。ステップ３１１と同様に、ネットワークメッセージ４１５が、システムコンテキスト４１９において容認可能であると判定されると、ステップ４０７において、ネットワークメッセージ４１５がプロセッサによって宛先アビオニクス装置に送信される。

いくつかの例において、１つ又は複数のフィルター・ルール４２９は、航空ネットワークの試験フェーズ中に、自動的に作成される（４３３）。様々な実施例によれば、１つ又は複数のフィルター・ルール４２９は、航空ネットワーク内で送信された試験機能ネットワークフローに対応する１つ又は複数の試験ネットワークパケットを捕捉すること（４５１）によって、自動的に作成される（４３３）。次に、試験機能ネットワークフローに対応する１つ又は複数の試験ネットワークメッセージを抽出するために、１つ又は複数の試験ネットワークパケットが解析される（４５３）。次に、複数の試験属性４５６を特定するために、１つ又は複数のネットワークメッセージのうちの１つの試験ネットワークメッセージが調べられる（４５５）。いくつかの例において、複数の試験属性４５６は、試験ネットワークメッセージに対応する１つ又は複数の試験ネットワークパケットのヘッダー及びデータフィールドに対応する。いくつかの例において、試験ネットワークメッセージが、ネットワークメッセージ４１５であり、試験ネットワークメッセージの属性が、属性４２５である。

次に、試験ネットワークメッセージ複数の試験属性が、分類される（４５７）。いくつかの例において、複数の試験属性を分類すること（４５７）は、１つ又は複数のソース内を探索して、所定のネットワークフローに対応する、以前に分類された属性を抽出することを含む。いくつかの例において、１つ又は複数のソースは、ローカルストレージ又はグローバルネットワークを介してアクセスされるグローバルデータベースを含む。いくつかの例において、所定の機能ネットワークフローは、一人又は複数のユーザーによって、以前に分類されたものである。いくつかの例において、所定の分類は、１つ又は複数の分類ファイルに含まれる。他の例において、複数の試験属性を分類すること（４５７）は、追加的又は代替的に、１つ又は複数の特定された試験属性についての分類を入力するよう、ユーザーに促すことを含む。いくつかの例において、ユーザーに促すことは、最も関連性のある選択肢のリストから１つ又は複数の分類を選択するよう、ユーザーに促すことを含む。いくつかの例において、関連性のある選択肢は、試験ネットワークフロー及び／又は試験属性に対するネットワークフロー及び／又は属性の類似性に基づいて、ランク付けされる（４５６）。分類されたネットワークフローの例は、表１に示したとおりである。

いくつかの例において、１つ又は複数のフィルター・ルール４２９は、１つ又は複数の試験ネットワークメッセージに対応する１つ又は複数のテーブル４６１を自動的に作成すること（４５９）によって、自動的に作成される（４３３）。いくつかの例において、１つ又は複数のテーブル４６１は、１つ又は複数のフィルター・ルール４２９を含む。他の例において、１つ又は複数のテーブル４６１は、試験ネットワークメッセージの１つ又は複数の試験属性に基づいて、チェーンされる（４６３）。いくつかの例において、テーブル４６１は、試験ネットワークメッセージの飛行フェーズによって、整理される。いくつかの例において、次に、１つ又は複数フィルター・ルール４２９が、有効化される（４６５）。いくつかの例において、１つ又は複数フィルター・ルール４２９は、既存の分類ファイル又は他の知識ベースと比較することにより、自動的に有効化される。

いくつかの例において、各試験ネットワークメッセージが分類される（４５７）につれて、分類された各試験ネットワークメッセージについて、フィルター・ルール４２９が作成される。いくつかの例において、作成されるフィルター・ルール４２９は、任意アクセス制御（ＤＡＣ: discretionary access control）ルールである。いくつかの例において、各ＤＡＣルールは、分類された試験ネットワークフローに基づく。いくつかの例において、ＤＡＣルールは、リナックス（Linux）テーブルに用いられるIPtablesルールである。IPtablesとは、Linuxカーネルファイアウォール（様々なNetfilterモジュールとして実施される）によって提供されるテーブル及びそれが格納しているチェーンならびにルールを、システム管理者が設定することを可能にする、ユーザスペースアプリケーションプログラムのことを指しうる。現在のところ、様々なプロトコルに、様々なカーネルモジュール及びプログラムが使用されている。すなわち、iptablesはＩＰｖ４に、ip6tablesはＩＰｖ６に、arptablesはＡＲＰに、ebtablesはイーサネットフレームに適用される。いくつかの例において、分類されたネットワークフローに基づいて、ip6tables、arptables、及び、ebtablesなどの他のタイプのフィルター・ルールが生成される。

いくつかの例において、各機能データフローは、モードごとに、アウトバウンド・フィルターとインバウンド・フィルターの両方のＩＰフィルター・ルール４２９を作成する。これは、システムコンテキストを示す飛行フェーズに依存する、データロードメッセージ（表１のネットワークメッセージ３〜１２）、又は、ＣＭＣ報告メッセージ（表１０のネットワークメッセージ１５〜１８）のためのフィルター・ルールのような特定のルールに関連している。高度メッセージ及び対気速度メッセージ（表１におけるネットワークメッセージ１、２及び１９〜３８）などの他のメッセージは、飛行フェーズに無関係である。いくつかの例において、これらのフィルターは、十分に豊富であることにより、各機能／データフローに個別に対応できる。いくつかの例において、このようなＩＰフィルター・ルール４２９は、単純なIPtablesルール又はステートレスなフィルター・ルールをチェーンすることによって、ステートフルな挙動を捕捉するように拡張することができる。例えば、シーケンスプロトコルダイアグラムを、802.1xトランザクションのようなサブファンクションレベルで作成することができる。様々な例において、ステートフルなＩＰフィルター・ルール４２９は、例えばパケットの長さ、グロスレベルのＩＰ宛先／送信元（ＤＡ／ＳＡ）アドレススペース、ポートＤＡ／ＳＡなどのある範囲の動作値を有するルールについて、最小境界及び最大境界を確定することができる。いくつかの例において、シンプルなＩＰルールをチェーンした場合、このようなルール４２９は、ステートフルな挙動が考慮されると、よりターゲットを絞った境界まで拡張することができる。ファイアウォール１１２のようなファイアウォールは、ステートフルなＩＰフィルター・ルール４２９を用いて、自身を横断するネットワーク接続の動作状態及び特性を追跡し、各接続の重大な属性をメモリに保存することができる。このような属性は、まとめて、接続の状態として知られているものであり、接続に使用されるＩＰアドレス及びポート、並びに、接続を通過するパケットのシーケンス番号のような詳細を含みうる。いくつかの例において、ファイアウォールによるステートフルなインスペクションは、経時的に、入ってくるパケット及び出て行くパケット、並びに、接続の状態を監視し、ダイナミック・ステート・テーブルにデータを保存する。いくつかの例において、このような累積データを評価することによって、管理者が設定したルールのみに基づくのではなく、以前の接続により構築されたコンテキスト、並びに、同じ接続に属する以前のパケットにも基づいて、フィルタリングの決定が行われるようにする。

図５は、本開示において説明した様々なプロセスを実施することができるシステム５００の一例を示すブロック図である。いくつかの例において、システム５００は、コンピュータ１０２及び／又はコンピュータ１０６のようなクライアント装置であり、１つ又は複数の例は、１つ又は複数のプログラムを格納する非一時的なコンピュータ可読媒体の形態で実施される。特定の例によれば、本開示の特定の例を実施するのに適したシステム５００は、プロセッサ５０１、メモリ５０３、インターフェイス５１１、及びバス５１５（例えばＰＣＩバス又は他の相互接続ファブリック）を含み、ストリーミングサーバーとして動作する。いくつかの例において、適当なソフトウェア又はファームウェアの制御下で動作する場合、プロセッサ５０１は、（ステップ４０１におけるような）ネットワーク接続された航空システム内で送信されたネットワークメッセージの受信、（ステップ４０３におけるような）その時点のシステムコンテキストの判定、（ステップ４０５におけるような）ネットワークメッセージの容認性の分析、及び／又は、（ステップ４０７におけるような）容認可能なネットワークメッセージの送信を請け負う。他の例において、プロセッサ５０１は、ユーザー入力の受信及びフィルター・ルールの作成（４３３）を請け負う。プロセッサ５０１に代えて、又はプロセッサ５０１に加えて、特別な構成とされた様々な装置を用いることができる。他の例において、システム５００は、以下の要素、すなわち、ポンプ、タイミング要素、加熱要素、サーモスタット、及び、濃度検出器のうちの１つ又は複数を含みうる。

インターフェイス５１１は、典型的には、ネットワーク１０４のようなネットワークを介して、データパケット又はデータセグメントを送受信するように構成されている。インターフェイスサポートの具体例には、イーサネットインターフェイス、フレームリレーインターフェイス、ケーブルインターフェイス、ＤＳＬインターフェイス、トークンリングインターフェイスなどがある。さらに、ファーストイーサネットインタフェース、ギガビットイーサネットインタフェース、ＡＴＭインターフェイス、ＨＳＳＩインターフェイス、ＰＯＳインターフェイス、ＦＤＤＩインターフェイスなどの、様々な超高速インターフェイスが提供されうる。一般に、これらのインターフェイスは、適当な媒体との通信に適したポートを含みうる。いくつかのケースにおいて、これらは、独立プロセッサも含み、場合によっては、揮発性ＲＡＭを含む。独立プロセッサは、パケット交換、媒体の制御及び管理のような通信集中タスク(communications intensive tasks)を制御しうる。

特定の例によれば、システム５００は、メモリ５０３を用いて、（ステップ４０１におけるような）ネットワーク接続された航空システム内で送信されるネットワークメッセージの受信、（ステップ４０３におけるような）その時点のシステムコンテキストの判定、（ステップ４０５におけるような）ネットワークメッセージの容認性の分析、及び／又は、（ステップ４０７におけるような）容認可能なネットワークメッセージの送信を含む動作のためのデータ及びプログラム命令を保存する。他の例において、メモリ５０３は、ユーザー入力の受信及びフィルター・ルールの作成（４３３）を含む動作のためのデータ及びプログラム命令を保存する。プログラム命令は、例えば、オペレーティングシステム及び／又は１つ又は複数のアプリケーションの動作を制御する。メモリは、受信メタデータ及びバッチ要求メタデータを記憶するようにも構成されうる。

さらに、本開示は、以下の付記による実施例を含む。

付記１． 航空機用の航空ネットワークにおけるネットワークメッセージを、その時点のシステムコンテキストに基づいて自動的にフィルタリングする方法であって、前記航空ネットワーク内において１つ又は複数のネットワークパケットによって送信されたネットワークメッセージを、コンピュータシステムのプロセッサによって受信し、前記ネットワークメッセージは、送信元アビオニクス装置から宛先アビオニクス装置に向けて送信されたものであり、前記航空ネットワーク内の１つ又は複数のアビオニクス装置を監視することによって、前記プロセッサによってその時点のシステムコンテキストを確定し、前記システムコンテキストは、前記１つ又は複数のアビオニクス装置の統合的な状態を示すものであり、前記ネットワークメッセージの容認性を、前記プロセッサによって分析し、前記分析は、前記ネットワークメッセージに対応する複数の属性であって、前記ネットワークメッセージに対応する前記１つ又は複数のネットワークパケットのヘッダー及びデータフィールドに対応する属性を特定することと、特定のシステムコンテキスト内でどのような属性が許容されるかを示す１つ又は複数のフィルター・ルールに基づいて、前記システムコンテキスト内での前記ネットワークメッセージの容認性を判定することと、によって行われ、前記ネットワークメッセージが前記システムコンテキスト内で容認できると判定された場合に、前記プロセッサによって、前記ネットワークメッセージを前記宛先アビオニクス装置に送信する、方法。

付記２． 前記その時点のシステムコンテキストは、以下のもの、すなわち、日付、時間、前記送信元アビオニクス装置の位置、前記宛先アビオニクス装置の位置、前記複数のアビオニクス装置の装置状態、及び、前記航空機の飛行フェーズ、のうちの１つ又は複数の組み合わせを含む、付記１に記載の方法。

付記３． 前記複数のアビオニクス装置の前記装置状態は、動作モード、メンテナンスモード、又は、データロードモードを含む、付記２に記載の方法。

付記４． 前記航空機の前記飛行フェーズは、以下の動作状態、すなわち、パワーオン、プリフライト、エンジンスタート、イン・ゲート、タクシー・アウト、離陸、初期上昇、上昇、巡航、降下、着陸進入、ロールアウト、タクシー・イン、ゴーアラウンド、及び、エンジンシャットダウン、のうちの１つを含む、付記２に記載の方法。

付記５． 前記ネットワークメッセージに対応する前記複数の属性は、以下のもの、すなわち、宛先アドレス、送信元アドレス、前記ネットワークメッセージの飛行フェーズ、前記ネットワークメッセージの装置状態、ファンクション、サブファンクション、データフロー、及び、プロトコル、のうちの１つ又は複数を含む、付記１に記載の方法。

付記６． 前記１つ又は複数のフィルター・ルールは、前記航空ネットワークの試験フェーズ中に以下のようにして自動的に作成される、すなわち、前記航空ネットワーク内で送信された試験機能ネットワークフローに対応する１つ又は複数の試験ネットワークパケットを捕捉し、前記試験機能ネットワークフローに対応する１つ又は複数の試験ネットワークメッセージを抽出するために、前記１つ又は複数の試験ネットワークパケットを解析し、複数の試験属性を特定するために、前記１つ又は複数の試験ネットワークメッセージのうちの１つの試験ネットワークメッセージを調べ、前記複数の試験属性は、前記試験ネットワークメッセージに対応する前記１つ又は複数の試験ネットワークパケットのヘッダー及びデータフィールドに対応しており、前記試験ネットワークメッセージの前記複数の試験属性を分類し、前記１つ又は複数の試験ネットワークメッセージに対応する１つ又は複数のテーブルを自動的に作成し、前記１つ又は複数のテーブルは、前記１つ又は複数のフィルター・ルールを含み、前記１つ又は複数のテーブルは、前記試験ネットワークメッセージの１つ又は複数の試験属性に基づいてチェーンされており、前記１つ又は複数のフィルター・ルールを有効化する、付記１に記載の方法。

付記７． 前記１つ又は複数のフィルター・ルールは、１つ又は複数のディープ・パケット・フィルタリング・ルールを含み、前記１つ又は複数のディープ・パケット・フィルタリング・ルールは、前記１つ又は複数のネットワークパケットの１つ又は複数のペイロードを調べることによって、前記航空ネットワークにおける不正データフローを阻止する、付記１に記載の方法。

付記８． 航空機用の航空ネットワークにおけるネットワークメッセージを自動的にフィルタリングするためのシステムであって、前記システムは、１つ又は複数のプロセッサと、メモリと、前記メモリに格納された１つ又は複数のプログラムとを含み、前記１つ又は複数のプログラムは、以下のための命令を含む、すなわち、前記航空ネットワーク内において１つ又は複数のネットワークパケットによって送信されたネットワークメッセージを、前記１つ又は複数のプロセッサによって受信し、前記ネットワークメッセージは、送信元アビオニクス装置から宛先アビオニクス装置に向けて送信されたものであり、前記航空ネットワーク内の１つ又は複数のアビオニクス装置を監視することによって、前記１つ又は複数のプロセッサによってその時点のシステムコンテキストを確定し、前記システムコンテキストは、前記１つ又は複数のアビオニクス装置の統合的な状態を示すものであり、前記ネットワークメッセージの容認性を、前記１つ又は複数のプロセッサによって分析し、前記分析は、前記ネットワークメッセージに対応する複数の属性であって、前記ネットワークメッセージに対応する前記１つ又は複数のネットワークパケットのヘッダー及びデータフィールドに対応する属性を特定することと、特定のシステムコンテキスト内でどのような属性が許容されるかを示す１つ又は複数のフィルター・ルールに基づいて、前記システムコンテキスト内での前記ネットワークメッセージの容認性を判定することと、によって行われ、前記ネットワークメッセージが前記システムコンテキスト内で容認できると判定された場合に、前記１つ又は複数のプロセッサによって、前記ネットワークメッセージを前記宛先アビオニクス装置に送信する、システム。

付記９． 前記システムコンテキストは、以下のもの、すなわち、日付、時間、前記送信元アビオニクス装置の位置、前記宛先アビオニクス装置の位置、前記複数のアビオニクス装置の装置状態、及び、前記航空機の飛行フェーズ、のうちの１つ又は複数の組み合わせを含む、付記８に記載のシステム。

付記１０． 前記複数のアビオニクス装置の前記装置状態は、動作モード、メンテナンスモード、又は、データロードモードを含む、付記９に記載のシステム。

付記１１． 前記航空機の前記飛行フェーズは、以下の動作状態、すなわち、パワーオン、プリフライト、エンジンスタート、イン・ゲート、タクシー・アウト、離陸、初期上昇、上昇、巡航、降下、着陸進入、ロールアウト、タクシー・イン、ゴーアラウンド、及び、エンジンシャットダウン、のうちの１つを含む、付記９に記載のシステム。

付記１２． 前記ネットワークメッセージに対応する前記複数の属性は、以下のもの、すなわち、宛先アドレス、送信元アドレス、前記ネットワークメッセージの飛行フェーズ、前記ネットワークメッセージの装置状態、ファンクション、サブファンクション、データフロー、及び、プロトコル、のうちの１つ又は複数を含む、付記８に記載のシステム。

付記１３． 前記１つ又は複数のフィルター・ルールは、前記航空ネットワークの試験フェーズ中に以下のようにして自動的に作成される、すなわち、前記航空ネットワーク内で送信された試験機能ネットワークフローに対応する１つ又は複数の試験ネットワークパケットを捕捉し、前記試験機能ネットワークフローに対応する１つ又は複数の試験ネットワークメッセージを抽出するために、前記１つ又は複数の試験ネットワークパケットを解析し、複数の試験属性を特定するために、前記１つ又は複数の試験ネットワークメッセージのうちの１つの試験ネットワークメッセージを調べ、前記複数の試験属性は、前記試験ネットワークメッセージに対応する前記１つ又は複数の試験ネットワークパケットのヘッダー及びデータフィールドに対応しており、前記試験ネットワークメッセージの前記複数の試験属性を分類し、前記１つ又は複数の試験ネットワークメッセージに対応する１つ又は複数のテーブルを自動的に作成し、前記１つ又は複数のテーブルは、前記１つ又は複数のフィルター・ルールを含み、前記１つ又は複数のテーブルは前記試験ネットワークメッセージの１つ又は複数の試験属性に基づいてチェーンされており、前記１つ又は複数のフィルター・ルールを有効化する、付記８に記載のシステム。

付記１４． 前記１つ又は複数のフィルター・ルールは、１つ又は複数のディープ・パケット・フィルタリング・ルールを含み、前記１つ又は複数のディープ・パケット・フィルタリング・ルールは、前記１つ又は複数のネットワークパケットの１つ又は複数のペイロードを調べることによって、前記航空ネットワークにおける不正データフローを阻止する、付記８に記載のシステム。

付記１５． コンピュータシステムによって実行されるように構成された１つ又は複数のプログラムを含む非一時的なコンピュータ可読媒体であって、前記１つ又は複数のプログラムは、以下のための命令を含む、すなわち、航空機用の航空ネットワーク内において１つ又は複数のネットワークパケットによって送信されたネットワークメッセージを、コンピュータシステムのプロセッサによって受信し、前記ネットワークメッセージは、送信元アビオニクス装置から宛先アビオニクス装置に向けて送信されたものであり、前記航空ネットワーク内の１つ又は複数のアビオニクス装置を監視することによって、前記プロセッサによってその時点のシステムコンテキストを確定し、前記システムコンテキストは、前記１つ又は複数のアビオニクス装置の統合的な状態を示すものであり、前記ネットワークメッセージの容認性を、前記プロセッサによって分析し、前記分析は、前記ネットワークメッセージに対応する複数の属性であって、前記ネットワークメッセージに対応する前記１つ又は複数のネットワークパケットのヘッダー及びデータフィールドに対応する属性を特定することと、特定のシステムコンテキスト内でどのような属性が許容されるかを示す１つ又は複数のフィルター・ルールに基づいて、前記システムコンテキスト内での前記ネットワークメッセージの容認性を判定することと、によって行われ、前記ネットワークメッセージが前記システムコンテキスト内で容認できると判定された場合に、前記プロセッサによって、前記ネットワークメッセージを前記宛先アビオニクス装置に送信する、非一時的なコンピュータ可読媒体。

付記１６． 前記その時点のシステムコンテキストは、日付、時間、前記送信元アビオニクス装置の位置、前記宛先アビオニクス装置の位置、前記複数の装置の装置状態、及び、前記航空機の飛行フェーズのうちの１つ又は複数の組み合わせを含む、付記１５に記載の非一時的なコンピュータ可読媒体。

付記１７． 前記複数のアビオニクス装置の前記装置状態は、動作モード、メンテナンスモード、又は、データロードモードを含む、付記１６に記載の非一時的なコンピュータ可読媒体。

付記１８． 前記航空機の前記飛行フェーズは、以下の動作状態、すなわち、パワーオン、プリフライト、エンジンスタート、イン・ゲート、タクシー・アウト、離陸、初期上昇、上昇、巡航、降下、着陸進入、ロールアウト、タクシー・イン、ゴーアラウンド、及び、エンジンシャットダウン、のうちの１つを含む、付記１６に記載の非一時的なコンピュータ可読媒体。

付記１９． 前記ネットワークメッセージに対応する前記複数の属性は、宛先アドレス、送信元アドレス、前記ネットワークメッセージの飛行フェーズ、前記ネットワークメッセージの装置状態、ファンクション、サブファンクション、データフロー、及び、プロトコルのうちの１つ又は複数を含む、付記１５に記載の非一時的なコンピュータ可読媒体。

付記２０． 前記１つ又は複数のフィルター・ルールは、１つ又は複数のディープ・パケット・フィルタリング・ルールを含み、前記１つ又は複数のディープ・パケット・フィルタリング・ルールは、前記１つ又は複数のネットワークパケットの前記ペイロードを調べることによって、前記ネットワーク接続された航空システムにおける不正データフローを阻止する、付記１５に記載の非一時的なコンピュータ可読媒体。

このような情報及びプログラム命令を、本明細書に記載のシステム／方法を実施するために用いることができるため、本開示は、本明細書に記載の様々な動作を行うためのプログラム命令、状態情報などを含む、有形もしくは非一時的な機械可読媒体に関連している。機械可読媒体の例としては、ハードディスク、フロッピーディスク、磁気テープ、ＣＤ‐ＲＯＭディスク及びＤＶＤのような光媒体、光ディスクのような光磁気媒体、読み出し専用メモリデバイス（ＲＯＭ）及びプログラム可能な読み出し専用メモリ装置（ＰＲＯＭｓ）のような、プログラム命令を格納及び実行するように特別に構成されたハードウェア装置、を含む。プログラム命令の例は、コンパイラーによって作成されたような機械コード、及び、インタープリターを用いてコンピュータによって実行されうるハイレベルコードを含むファイルの両方を含む。

本開示を、具体的な実施例に言及して具体的に図示及び説明したが、本開示の精神又は範囲から逸脱することなく、開示の実施例の形態及び詳細についての変更が行えることは、当業者に明らかであろう。従って、本開示は、本開示の真の精神及び範囲に含まれるすべての変形例及び均等例を含むものと解釈されることを意図している。利便性のためにコンポーネント及びプロセスの多くを単数形で記載しているが、本開示の手法を行うために、複数のコンポーネント及び複数回のプロセスを採用しうることは、当業者には明らかであろう。

Claims (12)

1. 航空機用の航空ネットワークにおけるネットワークメッセージを、現時点のシステムコンテキストに基づいて自動的にフィルタリングする方法であって、
   前記航空ネットワーク内において、送信元アビオニクス装置から宛先アビオニクス装置に向けて１つ又は複数のネットワークパケットによって送信されたネットワークメッセージを、コンピュータシステムのプロセッサによって受信し、
   前記航空ネットワーク内の１つ又は複数のアビオニクス装置を監視することによって、前記１つ又は複数のアビオニクス装置の統合的な状態を示す、現時点のシステムコンテキストを前記プロセッサによって確定し、
   前記ネットワークメッセージの容認性を、以下の工程を以って前記プロセッサによって分析し、
   ・前記ネットワークメッセージに対応する複数の属性であって、前記ネットワークメッセージに対応する前記１つ又は複数のネットワークパケットのヘッダー及びデータフィールドに対応する属性を特定すること；および
   ・特定のシステムコンテキスト内でどのような属性が許容されるかを示す１つ又は複数のフィルター・ルールに基づいて、前記システムコンテキスト内での前記ネットワークメッセージの容認性を判定すること；
   前記ネットワークメッセージが前記システムコンテキスト内で容認できると判定された場合に、前記プロセッサによって、前記ネットワークメッセージを前記宛先アビオニクス装置に送信する、方法であって、
   前記１つ又は複数のフィルター・ルールは、以下の工程、すなわち、
   前記航空ネットワーク内で送信された試験機能ネットワークフローに対応する１つ又は複数の試験ネットワークパケットを捕捉し、
   前記試験機能ネットワークフローに対応する１つ又は複数の試験ネットワークメッセージを抽出するために、前記１つ又は複数の試験ネットワークパケットを解析し、
   前記１つ又は複数の試験ネットワークメッセージのうちの１つの試験ネットワークメッセージを調べることにより、前記試験ネットワークメッセージに対応する前記１つ又は複数の試験ネットワークパケットにおけるヘッダー及びデータフィールドに対応する複数の試験属性を特定し、
   前記試験ネットワークメッセージの前記複数の試験属性を分類し、
   前記１つ又は複数の試験ネットワークメッセージに対応し且つ以下の特徴を有する１つ又は複数のテーブルを自動的に作成し、
   ・前記１つ又は複数のテーブルは、前記１つ又は複数のフィルター・ルールを含む；および
   ・前記１つ又は複数のテーブルは、前記試験ネットワークメッセージの１つ又は複数の試験属性に基づいてチェーンされている；
   前記１つ又は複数のフィルター・ルールを有効化する、工程により、前記航空ネットワークの試験フェーズ中に自動的に作成される、方法。
2. 前記現時点のシステムコンテキストは、以下のもの、すなわち、
   日付、時間、前記送信元アビオニクス装置の位置、前記宛先アビオニクス装置の位置、前記複数のアビオニクス装置の装置状態、及び、前記航空機の飛行フェーズ、のうちの１つ又は複数の組み合わせを含む、請求項１に記載の方法。
3. 前記複数のアビオニクス装置の前記装置状態は、動作モード、メンテナンスモード、又は、データロードモードを含む、請求項２に記載の方法。
4. 前記航空機の前記飛行フェーズは、以下の動作状態、すなわち、
   パワーオン、プリフライト、エンジンスタート、イン・ゲート、タクシー・アウト、離陸、初期上昇、上昇、巡航、降下、着陸進入、ロールアウト、タクシー・イン、ゴーアラウンド、及び、エンジンシャットダウン、のうちの１つを含む、請求項２又は３に記載の方法。
5. 前記ネットワークメッセージに対応する前記複数の属性は、以下のもの、すなわち、
   宛先アドレス、送信元アドレス、前記ネットワークメッセージの飛行フェーズ、前記ネットワークメッセージの装置状態、ファンクション、サブファンクション、データフロー、及び、プロトコル、のうちの１つ又は複数を含む、請求項１〜４のいずれかに記載の方法。
6. 前記１つ又は複数のフィルター・ルールは、１つ又は複数のディープ・パケット・フィルタリング・ルールを含み、前記１つ又は複数のディープ・パケット・フィルタリング・ルールは、前記１つ又は複数のネットワークパケットの１つ又は複数のペイロードを調べることによって、前記航空ネットワークにおける不正データフローを阻止する、請求項１〜５のいずれかに記載の方法。
7. 航空機用の航空ネットワークにおけるネットワークメッセージを自動的にフィルタリングするためのシステムであって、前記システムは、
   １つ又は複数のプロセッサと、
   メモリと、
   前記メモリに格納された１つ又は複数のプログラムとを含み、
   前記１つ又は複数のプログラムは、以下のための命令、すなわち、
   前記航空ネットワーク内において、送信元アビオニクス装置から宛先アビオニクス装置に向けて１つ又は複数のネットワークパケットによって送信されたネットワークメッセージを、前記１つ又は複数のプロセッサによって受信する；
   前記航空ネットワーク内の１つ又は複数のアビオニクス装置を監視することによって、前記１つ又は複数のアビオニクス装置の統合的な状態を示す、現時点のシステムコンテキストを前記１つ又は複数のプロセッサによって確定する；
   前記ネットワークメッセージの容認性を、以下の工程を以って前記１つ又は複数のプロセッサによって分析する；
   ・前記ネットワークメッセージに対応する複数の属性であって、前記ネットワークメッセージに対応する前記１つ又は複数のネットワークパケットのヘッダー及びデータフィールドに対応する属性を特定すること；および
   ・特定のシステムコンテキスト内でどのような属性が許容されるかを示す１つ又は複数のフィルター・ルールに基づいて、前記システムコンテキスト内での前記ネットワークメッセージの容認性を判定すること；
   前記ネットワークメッセージが前記システムコンテキスト内で容認できると判定された場合に、前記１つ又は複数のプロセッサによって、前記ネットワークメッセージを前記宛先アビオニクス装置に送信する、ための命令を含み、
   前記１つ又は複数のフィルター・ルールは、以下の工程、すなわち、
   前記航空ネットワーク内で送信された試験機能ネットワークフローに対応する１つ又は複数の試験ネットワークパケットを捕捉し、
   前記試験機能ネットワークフローに対応する１つ又は複数の試験ネットワークメッセージを抽出するために、前記１つ又は複数の試験ネットワークパケットを解析し、
   前記１つ又は複数の試験ネットワークメッセージのうちの１つの試験ネットワークメッセージを調べることにより、前記試験ネットワークメッセージに対応する前記１つ又は複数の試験ネットワークパケットにおけるヘッダー及びデータフィールドに対応する複数の試験属性を特定し、
   前記試験ネットワークメッセージの前記複数の試験属性を分類し、
   前記１つ又は複数の試験ネットワークメッセージに対応し且つ以下の特徴を有する１つ又は複数のテーブルを自動的に作成し、
   ・前記１つ又は複数のテーブルは、前記１つ又は複数のフィルター・ルールを含む；および
   ・前記１つ又は複数のテーブルは、前記試験ネットワークメッセージの１つ又は複数の試験属性に基づいてチェーンされている；
   前記１つ又は複数のフィルター・ルールを有効化する、工程により、前記航空ネットワークの試験フェーズ中に自動的に作成される、システム。
8. 前記システムコンテキストは、以下のもの、すなわち、
   日付、時間、前記送信元アビオニクス装置の位置、前記宛先アビオニクス装置の位置、前記複数のアビオニクス装置の装置状態、及び、前記航空機の飛行フェーズ、のうちの１つ又は複数の組み合わせを含む、請求項７に記載のシステム。
9. 前記複数のアビオニクス装置の前記装置状態は、動作モード、メンテナンスモード、又は、データロードモードを含む、請求項８に記載のシステム。
10. 前記航空機の前記飛行フェーズは、以下の動作状態、すなわち、
    パワーオン、プリフライト、エンジンスタート、イン・ゲート、タクシー・アウト、離陸、初期上昇、上昇、巡航、降下、着陸進入、ロールアウト、タクシー・イン、ゴーアラウンド、及び、エンジンシャットダウン、のうちの１つを含む、請求項８又は９に記載のシステム。
11. 前記ネットワークメッセージに対応する前記複数の属性は、以下のもの、すなわち、
    宛先アドレス、送信元アドレス、前記ネットワークメッセージの飛行フェーズ、前記ネットワークメッセージの装置状態、ファンクション、サブファンクション、データフロー、及び、プロトコルのうちの１つ又は複数を含む、請求項７〜１０のいずれかに記載のシステム。
12. 前記１つ又は複数のフィルター・ルールは、１つ又は複数のディープ・パケット・フィルタリング・ルールを含み、前記１つ又は複数のディープ・パケット・フィルタリング・ルールは、前記１つ又は複数のネットワークパケットの１つ又は複数のペイロードを調べることによって、前記航空ネットワークにおける不正データフローを阻止する、請求項７〜１１のいずれかに記載のシステム。

Images