JP5896423B2 - 単一プロセッサ・クラス３電子航空バッグ - Google Patents

Description

関連出願への相互参照
本出願は、２０１０年２月２３日出願の米国暫定特許出願第６１／３０７，０１２号明細書の利益を主張し、参照のためその全体を本明細書に援用する。

本発明は、航空機における補助コンピュータ機能を提供する電子航空バッグ（ＥＦＢ：Ｅｌｅｃｔｒｏｎｉｃ Ｆｌｉｇｈｔ Ｂａｇ）に関し、特に、航空機内に恒久的に設置されタイプＡ、タイプＢ、タイプＣアプリケーションを同時にホストし実行するのに好適なクラス３ＥＦＢに関する。

ＥＦＢは、航空機搭乗員がより容易に、より効率的に、そしてより少ない紙で飛行管理タスクを行なえるよう設計されたコンピュータシステムである。ＥＦＢの通常の計算プラットフォームは、航空機搭乗員により航空機上に持ち込む必要が伝統的にあるパイロットの機内持ち込み航空バッグ内の航空機操作マニュアル、航空用海図、その他アイテム等の紙の参考資料を低減または置換することを目的としている。ＥＦＢ装置は、米国ではＡｄｖｉｓｏｒｙ Ｃｉｒｃｕｌａｒ（ＡＣ）１２０−７６Ａに従って連邦航空局（ＦＡＡ：Ｆｅｄｅｒａｌ Ａｖｉａｔｉｏｎ Ａｄｍｉｎｉｓｔｒａｔｉｏｎ）により、欧州では暫定ガイダンス冊子（ＴＧＬ：Ｔｅｍｐｏｒａｒｙ Ｇｕｉｄａｎｃｅ Ｌｅａｆｌｅｔ）３６に従って欧州航空安全局（ＥＡＳＡ：Ｅｕｒｏｐｅａｎ Ａｖｉａｔｉｏｎ Ｓａｆｅｔｙ Ａｇｅｎｃｙ）により、規制され、参照のためその全体を本明細書に援用する。

多くのケースでは、紙の参考文書を置換することを目的としたデータを供給しＥＦＢ上にそれを電子的に表示するように設計されたアプリケーションは、既製品（ＣＯＴＳ：Ｃｏｍｍｅｒｃｉａｌ−Ｏｆｆ−Ｔｈｅ−Ｓｈｅｌｆ）オペレーティングシステム（ＯＳ）とソフトウェア部品例えばＮＥＴ ｆｒａｍｅｗｏｒｋ部品を有するマイクロソフトＷｉｎｄｏｗｓ（登録商標）ＯＳと共に使用するために開発されている。これらのアプリケーションの例は、マニュアルと参考文書を表示するために使用されるドキュメントリーダー、端末チャートビュアー、電子ログブックアプリケーションである。

ＥＦＢは十分に成長し普及したので、操縦室内の表示装置を備えた追加コンピュータシステムの可用性は、主飛行表示システムと多機能表示装置とに伝統的に関連付けられた追加の機能性を提供するために利用された。これらは、位置、方位、飛行計画を含む航空機の現在状況に関連する航空電子データの表示装置を含む。従来のＥＦＢの機能に加えてこれらの追加機能は、３つのアプリケーションカテゴリ：タイプＡ、タイプＢ、タイプＣに分割される。タイプＡアプリケーションは、伝統的に紙形式で呈示される予め用意されたデータの固定表現（電子パイロットマニュアル、参考文書、機器リスト、保守マニュアル）を含む。タイプＢアプリケーションは、動的データと表現（端末チャート、性能計算、客室映像）を操作することができる対話型アプリケーションを含む。タイプＣアプリケーションは、主飛行表示装置に通常関連付けられ、飛行安全性と乗務員作業量に影響を及ぼす可能性があるアイテムを含む。タイプＣアプリケーションの例は、自身の航空機位置を表示する対話型ムービングマップ、あるいは洋上高度変更支援（Ｉｎ−Ｔｒａｉｌ Ｐｒｏｃｅｄｕｒｅｓ）またはマージング及び間隔保持（Ｍ＆Ｓ：Ｍｅｒｇｉｎｇ ａｎｄ Ｓｐａｃｉｎｇ ）のガイダンスを提供する放送型自動従属監視（ＡＤＳ−Ｂ：Ａｕｔｏｍａｔｉｃ Ｄｅｐｅｎｄｅｎｔ Ｓｕｒｖｅｉｌｌａｎｃｅ−Ｂｒｏａｄｃａｓｔ）処理装置と相互作用するアプリケーションであり、参照のためその全体を本明細書に援用する。

ＡＣ−１２０−７６Ａによると、タイプＣアプリケーションは、その故障が乗務員安全と作業量に与える影響により判断される厳しさを有する航空機認証サービス（ＡＩＲ：Ａｉｒｃｒａｆｔ Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ）設計承認を必要とする。航空無線技術委員会（ＲＴＣＡ：Ｒａｄｉｏ Ｔｅｃｈｎｉｃａｌ Ｃｏｍｍｉｓｓｉｏｎ ｆｏｒ Ａｅｒｏｎａｕｔｉｃｓ）は、航空電子装置で使用されるソフトウェアの設計承認を取得するためのＦＡＡ受諾ガイダンスＤＯ−１７８Ｂ「航空システムおよび航空機器認証に関わるソフトウェア安全関連の規格（Ｓｏｆｔｗａｒｅ Ｃｏｎｓｉｄｅｒａｔｉｏｎｓ ｉｎ Ａｉｒｂｏｒｎｅ Ｓｙｓｔｅｍｓ ａｎｄ Ｅｑｕｉｐｍｅｎｔ Ｃｅｒｔｉｆｉｃａｔｉｏｎ）」を発行する。ＲＴＣＡ社は、米国ワシントンＤ．Ｃ．を本拠とする営利法人ではない私的法人である。ＤＯ−１７８ＢはＦＡＡからの設計保証承認を得るための１つの手段であるが唯一の手段ではない。

ＡＣ１２０−７６Ａによると、物理的ＥＦＢハードウェアは設置と用途とに基づき３つのクラスの１つに類別される。そのクラスはクラス１、クラス２、クラス３である。クラス１ＥＦＢは通常、ポータブルであるが航空機に取り付けられないラップトップまたはタブレットＰＣ等のＣＯＴＳベースシステムである。クラス２ＥＦＢもまた通常、ＣＯＴＳベースのシステムであり、ポータブルであるが通常運転中航空機に接続される。クラス３ＥＦＢは、設置済み航空電子装置であり、クラス１ＥＦＢとクラス２ＥＦＢとは異なり、航空機上のその目的の機能に従う規定要件を満たす必要がある。ＲＴＣＡ社は、航空電子装置において使用されるハードウェアのＡＩＲ承認を取得するためのＦＡＡ承認受諾ガイダンスであるＤＯ−１６０Ｆ「搭載機器に適用する環境条件及び試験手順（Ｅｎｖｉｒｏｎｍｅｎｔａｌ Ｃｏｎｄｉｔｉｏｎｓ ａｎｄ Ｔｅｓｔ Ｐｒｏｃｅｄｕｒｅｓ）」を発行し、参照のためその全体を本明細書に援用する。

タイプＡおよび／またはＢ（以降、タイプＡ／Ｂ）アプリケーションは任意のクラスのＥＦＢ上でホストされ、設計承認を必要としない。しかしながらタイプＣアプリケーションは実際に設計承認を必要とし、クラス３ＥＦＢ上においてだけホストされることができる。但し、アプリケーションが技術基準（ＴＳＯ：Ｔｅｃｈｎｉｃａｌ Ｓｔａｎｄａｒｄ Ｏｒｄｅｒ）を有し、かつクラス１ＥＦＢまたはクラス２ＥＦＢ上の他の被ホストアプリケーションが軽微な安全影響を及ぼすあるいは安全影響を全く及ぼさず、ＴＳＯを有するタイプＣアプリケーションを妨害しない状況を除く。

単一のクラス３ＥＦＢ上でタイプＡ／ＢアプリケーションとタイプＣアプリケーションをホストする場合、設計承認されたタイプＣアプリケーションと航空機インターフェースを、ＥＦＢに接続されたあるいはＥＦＢ上でホストされた航空機上のいかなる安全重要部品またはソフトウェアに対してもタイプＡ／Ｂアプリケーションからの悪影響も妨害も無いように、タイプＡ／Ｂアプリケーションから分離することが重要である。設計承認されたソフトウェアを分離し、ＥＦＢに接続された航空機部品を保護する現在の方法は、単一のＥＦＢ内に２つの別個のプロセッサ、すなわち、専用ＬｉｎｕｘベースのオペレーティングシステムとタイプＣアプリケーション等の設計承認されたオペレーティングシステムをホストするものと、米国ワシントン州マイクロソフト株式会社により製造されたＷｉｎｄｏｗｓ（登録商標）オペレーティングシステム等のＣＯＴＳオペレーティングシステムをホストするものと、を使用することである。２つのプロセッサを接続する回路は、ＥＦＢに接続された航空機インターフェースを保護するためにその動作を制御し、監視し、制限できるようにする設計承認されたオペレーティングシステムによりＣＯＴＳオペレーティングシステム上のハードウェア制御を提供する。２つの別個のプロセッサにより与えられる物理的分離は、タイプＣアプリケーションのタイプＡ／Ｂアプリケーションからの十分な分離を与える。

本発明は、単一プロセッサ上でタイプＡ／ＢとタイプＣアプリケーションの両方を実行し、これにより重量、消費電力、コストの大幅な節約を可能にするクラス３ＥＦＢ（電子航空バッグ）を提供する。タイプＡ／ＢアプリケーションがタイプＣアプリケーションの実行を妨害し得る一組のメカニズムを特定することにより、本発明者は、メモリ、処理および表示資源へのアクセスを制限するオペレーティングシステムの変更によりハードウェア分離という効果を達成した。これらの変更は、マルチプロセッサシステムに等価な分離を有する単一プロセッサアーキテクチャを可能にする。

具体的には、本発明は、少なくとも１つのコアを有する単一プロセッサと、プロセッサと通信しオペレーティングシステムを保持する電子メモリシステムと、を有するクラス３電子航空バッグを提供する。電子航空バッグは、ナビゲーションシステムと、プロセッサと通信する表示装置と、を含む他の機上設備に接続するために航空機データネットワークと通信するネットワークインターフェースを提供する。電子メモリシステム内のタイプＡ／Ｂアプリケーションの電子メモリ、表示装置、およびプロセッサへのアクセスは、タイプＡ／Ｂアプリケーションの実行によるタイプＣアプリケーションの実行への潜在的妨害を阻止するために、オペレーティングシステムにより適用される所定の規則に従って制限される。

したがって、単一プロセッサ上で実行する重要アプリケーションと非重要アプリケーションとを別々のプロセッサの必要性無しに分離することが本発明の少なくとも１つの実施形態の特徴である。

オペレーティングシステムは、例えば、ソケットバッファの全体サイズをソケット当たりの所定最大データ割り振りに制限してソケットの合計数をソケットの所定最大数に制限することにより、通信用に使用されるソケットバッファの全体サイズを制限してもよい。当該技術において通常理解されるように、ソケットバッファはコンピュータにより実行される処理間の通信用に使用されるコンピュータメモリ内の記憶領域である。

したがってタイプＡ／Ｂアプリケーションによる過剰なソケットバッファ（通常はオペレーティングシステムのメモリ空間に存在する）割り振りがオペレーティングシステム動作を妨害するのを防止することが本発明の少なくとも１つの実施形態の特徴である。

オペレーティングシステムはネットワーク同報メッセージを禁止してもよい。

したがって、スプーフィングを防止するために監視されてもよいメッセージが明確な規定エンドポイント間に存在することを保証することが本発明の少なくとも１つの実施形態の特徴である。

電子メモリシステムは不揮発性データ記憶装置を含んでもよく、各アプリケーションは書き込み権限ではなく読み取りおよび実行権限を有する区画に割り当てられもよい。

したがってタイプＡ／Ｂアプリケーションがディスク上書きを介しタイプＣアプリケーションにより使用されるデータを変更するのを防止することが本発明の少なくとも１つの実施形態の特徴である。

揮発性データ記憶装置の予約は、アプリケーション当たり所定最大記憶量に制限されてもよい。各タイプＡ／Ｂアプリケーションは、すべてのタイプＣアプリケーションが揮発性データ記憶装置を予約した後にだけ揮発性データ記憶装置を予約してもよい。

タイプＣアプリケーションに揮発性メモリを与えないことにより、タイプＡ／Ｂアプリケーションにより使用される過剰な揮発性メモリがタイプＣアプリケーションを妨害するのを防止することが本発明の少なくとも１つの実施形態の別の特徴である。

揮発性データ記憶装置の予約はすべてのアプリケーションの所定合計最大記憶量に制限されてもよい。

したがって揮発性メモリの割り振りから生じるシステム不安定性を防止することが本発明の少なくとも１つの実施形態の特徴である。

オペレーティングシステムは、揮発性データ記憶装置へのアクセスを制御するメモリ管理ユニットのレジスタにロードすることにより、所定全体最大量とアプリケーション当たりの所定最大量とを適用してもよい。

したがって、タイプＡ／Ｂアプリケーションの動作による破壊に耐性のあるメモリ分割を実施するためにメモリ管理ユニットを採用することが本発明の少なくとも１つの実施形態の特徴である。メモリ管理ユニット設定へのアクセスはオペレーティングシステムに制限されることができる。

オペレーティングシステムは、アプリケーションプログラムの様々な処理の実行のために単一プロセッサのスケジューリングを制御し、各アプリケーションプログラムの最大スケジューリング率を制限してもよい。

したがって実行タイプＡ／Ｂアプリケーションにより完全に奪われることに耐性のある処理スケジューリングアルゴリズムを採用することが本発明の少なくとも１つの実施形態の特徴である。

異なるアプリケーションの処理は、タイプＣアプリケーションの処理が待ち行列において優先度を与えられるように単一プロセッサの待ち行列に入れられてもよい。

したがって混合アプリケーションの環境においてタイプＣアプリケーションの動作を保証することが本発明の少なくとも１つの実施形態の特徴である。

処理は、全スケジューリング率（ｆｕｌｌ ｓｃｈｅｄｕｌｅｄ ｐｅｒｃｅｎｔａｇｅ）を歴史的に使用しない場合と比較して全スケジューリング率を歴史的に使用する場合は待ち行列の低順位に置かれてもよい。

したがって特定アプリケーションによる単一プロセッサの独占を防止することが本発明の少なくとも１つの実施形態の特徴である。

電子航空バッグはさらに、構成レジスタを有する周辺装置を含んでもよく、第１のオペレーティングシステムはこれらのレジスタへのアクセスをタイプＡ／Ｂアプリケーションに対し阻止してもよい。

したがってタイプＡ／Ｂアプリケーションによる周辺装置動作の破損を防止することが本発明の少なくとも１つの実施形態の特徴である。

電子航空バッグはさらに、表示装置にデータを供給するために単一プロセッサとの通信を提供する表示システムを含んでもよい。オペレーティングシステムは、タイプＡ／ＢアプリケーションがタイプＣのバッファのデータを上書きできないように、少なくとも１つのタイプＣと１つのタイプＡ／Ｂアプリケーションのそれぞれの別個のバッファを管理し、オペレーティングシステム制御によりバッファ間で選択する。

したがって、単一のバッファが使用される場合に起こり得るように、タイプＡ／Ｂアプリケーションが出力上書きにより、タイプＣアプリケーションから出力される重要な図形を不可逆的に破壊するのを防止することが、本発明の少なくとも１つの実施形態の特徴である。

別個のバッファは、異なるアプリケーションにより一意的に書き込み可能な記憶場所内にあってもよい。

したがって、ビデオバッファオーバーランがタイプＣアプリケーションによるグラフィックデータの出力を妨げるのを防止することが本発明の少なくとも１つの実施形態の特徴である。

オペレーティングシステムはさらに、表示装置にデータを供給するように単一プロセッサ上で実行されてもよい。このとき、オペレーティングシステムは、アプリケーションから標準表示データを受信するアプリケーションのビデオバッフとタイプＣアプリケーションから高優先度表示データを受信するオーバーレイビデオバッファとを管理してもよく、表示されたときにアプリケーションバッファがオーバーレイバッファからのデータを閉塞できないようにバッファの内容を合成してもよい。

したがって、タイプＡ／Ｂアプリケーション（またはタイプＣアプリケーション）により重要なグラフィックデータが閉塞されないことを保証してどうにか焦点を維持することが本発明の少なくとも１つの実施形態の特徴である。

バッファは機能領域に分割されてもよく、表示システムは、表示装置の示された方位に依存して、異なる機能領域の表示装置上のバッファ位置と空間的位置との関係を違ったやり方で再配列してもよい。

したがって、２つの異なる表示フォーマットを別々にプログラムする必要無く、表示装置の方位に依存して表示装置の洗練された再フォーマットを行うことが本発明の少なくとも１つの実施形態の特徴である。

電子メモリシステムはまた第２のオペレーティングシステムを保持してもよく、タイプＡ／Ｂアプリケーションは、第１のオペレーティングシステムにより実施される仮想化による第２のオペレーティングシステムにより実行されてもよい。第１のオペレーティングシステムは例えば、保証されたオープンソースオペレーティングシステムであってよく、第２のオペレーティングシステムはＷｉｎｄｏｗｓ（登録商標）等の著作権付きオペレーティングシステムであってよい。

したがって、設計承認されたアプリケーションに使用される電子航空バッグの能力を危険に晒すこと無く、設計承認することができない著作権付きオペレーティングシステム上においてだけ実行可能なタイプＡ／Ｂアプリケーションの使用を可能にすることが本発明の少なくとも１つの実施形態の特徴である。オペレーティングシステムの分離と仮想化は、誤った振る舞いが抑制されるように著作権付きオペレーティングシステムをコンパートメント化する。

これらの特定の目的と利点は、特許請求の範囲に入るいくつか実施形態にだけ適用されてよく、したがって本発明の範囲を規定しない。

図１は、アプリケーション同士を分離するために別個のプロセッサを使用する従来技術のＥＦＢのハードウェアブロック図である。 図２は、本発明に基づく単一プロセッサを使用したＥＦＢを示す図１のものと同様なハードウェアブロック図である。 図３は、メモリシステムと単一プロセッサ間の通信を示す図２のＥＦＢの機能ブロック図である。 図４は、図２と図３のＥＦＢのローディングと立ち上げを示すフローチャートである。 図５は、ローディングと立ち上げに使用する図２と図３のＥＦＢ上で実行可能なアプリケーションプログラムの構成ファイルと構成表の表示である。 図６は、様々なデータ構造とファイルの割り振りを示す図２のメモリの詳細な表示である。 図７は、電子航空バッグを表示するためにグラフィック合成器により合成される異なる実行アプリケーションにより使用される複数のビデオバッファの表示である。 図８は、単一の２進アプリケーションにより２つの表示方位を支援するアプリケーションテンプレートの表示である。 図９は、アプリケーション処理を待ち行列に入れる本発明において使用されるプロセッサスケジューリングシステムの簡略図である。 図１０は、不揮発性磁気ディスク装置の表示であり、その区画表を示す。 図１１は、本発明により実施されてもよい仮想化の図である。

さて図１を参照すると、航空機１２において用いる従来技術のＥＦＢ１０は、第１と第２のメモリ１５と１７とそれぞれ通信する第１のプロセッサ１４と第２のプロセッサ１６とを含んでもよい。第１のプロセッサ１４は、例えばタイプＣソフトウェアアプリケーションであってよい第１のメモリ１５内に保持された第１のソフトウェアアプリケーション１８をホストするために使用されてもよい。第２のプロセッサ１６は、例えばタイプＡ／Ｂソフトウェアアプリケーションであってよい第２のメモリ１７内に保持された第２のソフトウェアアプリケーション２０をホストするために使用されてもよい。メモリ１５と１７は、固定磁気ディスク駆動ユニットと、いくつかの形式の不揮発性メモリを提供するためにフラッシュメモリと、を含んでもよい。

プロセッサ１４と１６は、単一の液晶表示（ＬＣＤ）装置２６を有する共通表示ユニット２２を共有してもよい。各プロセッサ１４と１６は自身のビデオコントローラ２４と２５と通信してもよい。第１のプロセッサ１４は主ビデオコントローラ２４と通信してもよく、第２のプロセッサ１６は第２のビデオコントローラ２５と通信してもよい。２つのビデオコントローラ２４と２５は、映像切り替えシステム３０として機能するフィールドプログラマブルゲートアレイ（ＦＰＧＡ）のシステムを介しＬＣＤ装置２６と通信してもよい。ＦＰＧＡ切り替えシステム３０は単一プロセッサの制御下であってよい。例えば、第１のプロセッサ１４は、ビデオインタフェース３１上で送信する際にプロセッサ１４または１６のどちらが存在するかを制御することができるように、自身を切り替えシステム３０に接続する主装置バス３５を有してもよい。このような状況は、表示ユニット２２が、第２のプロセッサ１６上で実行する第２のソフトウェアアプリケーション２０により供給されるあまり重要でない情報を表示するために使用されている間に、重要な飛行または航空機関連情報を表示する必要が生じた場合に生じてよい。切り替えシステム３０は、ＬＣＤ表示装置２６の回路２７を駆動する信号を操縦者に供給しボタンまたはＬＣＤタッチスクリーン４２からの信号を受信する表示装置インターフェース３１を介しＬＣＤ２６と通信してもよい。外部キーボード３６は表示装置インターフェース３１に接続されてもよい。プロセッサ１４と１６はまた、当該技術において理解されるように、航空機カメラ等の他の装置と通信するための標準イーサネットネットワーク（図示せず）と通信してもよい。

各プロセッサ１４と１６はまた、ボタンとＬＣＤタッチスクリーン４２または外部キーボード３６からの信号を受信するそれ自身のインターフェース２９と通信してもよい。

図１を再び参照すると、各プロセッサ１４と１６は、安全関連の懸念のために航空機１２の他の航空電子装置への航空電子インターフェース４３のアクセスと可視性を制限するために必要かもしれない。Ｉ／Ｏカード３４は、ＥＦＢ１０が航空機１２上に設置された他の装置と相互作用できるように航空電子インターフェース４３へのアクセスを提供する。Ｉ／Ｏカード３４は、埋め込みソフトウェアと、支援回路と、当該技術において知られたタイプの航空電子インターフェース４３に接続するように設計された回路と、を含むマイクロコントローラからなってもよい。第１のプロセッサ１４がＩ／Ｏカード３４を初期化して構成できるようにすることで、第２のプロセッサ１６から航空電子インターフェース４３へのアクセスを第１のプロセッサ１４が制限できるようにする。この能力は、ＥＦＢ１０が必要安全基準を満たせるようにする。

ある環境下では、第２のプロセッサ１６の誤動作あるいはソフトウェア２０のソフトウェア故障のいずれかのために、第１のプロセッサ１４が第２のプロセッサ１６を無効化またはリセットする必要があるかもしれない。第１のプロセッサ１４が第２のプロセッサ１６を無効化またはリセットできるようにする第１のプロセッサ１４から第２のプロセッサ１６へのリセット信号３３があってもよい。これは、第２のプロセッサ１６だけでなく第１のプロセッサ１４が表示ユニット２２上の完全な制御（切り替えシステム３０を介した）を有することを保証する。これにより、民間航空機１２内のクラス３ＥＦＢ上でのソフトウェアアプリケーションの使用を規定する厳格なＦＡＡ基準を満たす第２のアプリケーションの高価な認可の必要性をなくす。したがって、第２のソフトウェアアプリケーション２０は市販のソフトウェアアプリケーションを表してもよい。第２のソフトウェアアプリケーション２０が専用ソフトウェアアプリケーションとして提供されたとしても、タイプＣアプリケーションに必要な高価で厳格な認証が無くなるので大きな利点が依然としてある。これは、第１のプロセッサ１４が、重要情報を表示するためにあるいは即時オペレータ応答を要求するために必要となることがある表示ユニット２２と第２のプロセッサ１６の制御を完全に支配する能力を備えているからである。

次に図２を参照すると、本発明は、２つのプロセッサシステムの複雑性と、一方のプロセッサの他方に対する優勢を与えるために使用されるハードウェアスイッチと、が単一プロセッサ５０のおかげで回避されるＥＦＢ１０’を提供する。この単一プロセッサ５０は、以下に説明するように、特別に変更されたオペレーティングシステム５４を使用することにより、メモリ１５内に保持された複数のアプリケーションプログラム５２（タイプＡ、ＢまたはＣアプリケーション）を実行する。特別に変更されたオペレーティングシステム５４は、ＥＦＢ１０’上でホストされる他のすべてのソフトウェアの実行を制御する。ＥＦＢ１０の固有動作に関係する主メニュープログラム５３もまたメモリ１５内に保持されプロセッサ５０により実行されてもよい。説明の明確化のために、本明細書で使用される用語「オペレーティングシステム」は、通常は複数のアプリケーションにより使用されアプリケーションプログラムの実行に必要な追加のルートサービス、ドライバ、他のソフトウェアと組み合わせたオペレーティングシステムカーネルをカバーすると考えられる。

本アーキテクチャでは、プロセッサ５０は切り替えシステムの必要無しにインターフェース３４と通信してもよく、インターフェース３４は前述のものと同様なデバイスバス３５を介し様々な入力装置３６、４２と接続してもよい。インターフェース３４はまた、航空電子インターフェース４３を介しナビゲーションユニットを含む航空電子システムに接続してもよい。プロセッサ５０はまた、できるだけ小さい単一グラフィックプロセッサを有するビデオコントローラ２４と通信し、インターフェース３４を介し表示ユニット２２にデータを伝達してもよい。プロセッサ５０はまた、再びインターフェース３４を介しボタンとタッチスクリーン４２と外部キーボード３６からの信号を受信する入力インターフェース２９と通信してもよい。

次に図３を参照すると、プロセッサ５０は例えば、それぞれが例えばＬ１キャッシュ５８を有し、Ｌ２キャッシュ６０を共有する複数のコア５６を有するプロセッサであってよい。Ｌ２キャッシュ６０は１つまたは複数の内部バスを介しメモリシステム６２の両方の部分であるランダムアクセス揮発性メモリ６４と不揮発性メモリ６６と接続してもよい。後者は例えば論理的には、例えばフラッシュメモリにより実現される「ディスク」ドライブである。揮発性メモリ６４へのアクセスはメモリ管理ユニット６８を介してもよく、不揮発性メモリ６６へのアクセスは当該技術において周知のタイプのディスクコントローラ７０を介してもよい。

次に図４を参照すると、プロセッサ５０は、航空機内におけるＥＦＢ１０’の使用の前に、およびＥＦＢ１０’の使用過程における様々な時刻に、ロードルーチン７６を実行してもよい。ロードルーチン７６は、所望のアプリケーションプログラムをインストールして構成するために使用される。処理ブロック８０により示される第１の工程では、ロードルーチン７６はローダープログラムを開始する。処理ブロック８２によると、ローダープログラムは、電子航空バッグ１０’上で使用される識別されたアプリケーションプログラム５２とそれに関連した構成ファイル８４（マニフェストファイルの一部として）とを精査する。このようなアプリケーションはディスク区画内のそれらの配置に影響を与えるので、アプリケーションプログラム５２が識別される。

図３と図５をしばらく参照すると、構成ファイル８４は各アプリケーションプログラム５２のエントリ８６を有してもよく、エントリ８６は当該アプリケーションのアプリケーション実行ファイル８８にリンクされる。各構成ファイル８４のエントリ８６は通常、アプリケーション実行ファイル８８とその処理を識別する（例えば、グループ識別子により）アプリケーション識別子９０と、アプリケーションタイプ９２（例えば、タイプＡ、タイプＢまたはタイプＣ）と、を提供し、アプリケーション９６用に予約されるメモリの量を示すであろう。構成ファイル８４からの情報は、オペレーティングシステム５４の立ち上げ時に、当該アプリケーションプログラム５２用に作成された構成表９４に加えられるであろう。構成表９４は、パーミッショングループを定義するメモリ管理ユニットメモリ割り振り情報９８と、以下に検討される各アプリケーションプログラム５２に関連したビデオバッファ情報１０２と、を含む以下に説明する追加情報を加えるであろう。

図４と図１０を再び参照すると、処理ブロック８２で得られた情報を使用することにより、処理ブロック１０６では、アプリケーションプログラム５２は不揮発性メモリ６６にインストールされ、前もって用意された区画９９にインストールされる。分割処理は、アプリケーションプログラムの（そしてまた、この区画内に含まれるファイルの書き込みアクセスではなく読み取りアクセスと実行だけを提供するオペレーティングシステムの）実行ファイルを保持する第１のディスク区画９９ａを含む別個のディスク区画９９ａ〜９９ｄを割り振る。第２の区画９９ｂは、実行ではなく読み取り／書き込みアクセスを提供し、一時ファイルおよびログ用のアプリケーションプログラムにより使用される。第３の区画９９ｃは、この区画に含まれるファイルの実行ではなく読み取り専用アクセスを提供し、アプリケーション間で共有されるデータベース用に使用されてもよい。第４の区画９９ｄは、利用可能であるが未だインストールされていないプログラムを保持し、実行可能ではなく、そしてオペレーティングシステムのためだけの読み取りと書き込みがなされる。第１のディスク区画９９内にアプリケーションを配置することにより、いかなる誤ったアプリケーションも他のアプリケーションのディスクファイルを上書きできない。各区画９９は区画表１１０内の行により概して示されるように区画表１１０内に記述される。当該技術において理解されるように、区画９９は、それ自身のファイルシステム１１２（論理アドレスをディスク上の物理アドレスへマッピングする）と、オペレーティングシステムとディスク媒体内の情報の符号化により適用される所定の限定物理アドレス範囲１１６へマッピングするそれ自身の記憶領域１１４と、を含む。区画表１１０は、区画毎の論理的識別子（ここではａ、ｂ、ｃ、ｄとして示す）と、ファイルシステム１１２の物理アドレス情報１２０と、特定区画に対し読み取るまたは書き込む権限を有するアプリケーションプログラム５２を示すデータアクセス権限１２２と、を提供してもよい。アクセス権限の実施のための他の分割方法もまた本発明によって考えられる。

通常、各アプリケーションプログラム５２は、区画９９ａ内のそれ自身の一意的フォルダにロードされ、ファイルシステム１１２の他のディレクトリに関連する部分を見るのを防止する「ルートジェイル（ｒｏｏｔ ｊａｉｌ）」を備える。当該技術において知られるタイプの「ループバック装置」は、所与のアプリケーションプログラムが区画９９ｂと９９ｃの適切な部分だけにアクセスできるようにするために使用される。ディスクコントローラハードウェア構成レジスタに対するアクセスを制限することにより、および／またはアプリケーションプログラムに利用可能なオペレーティングシステム呼び出しを制限することにより、ディスクコントローラハードウェアは、可能性のある誤ったアプリケーション振る舞い（１つのアプリケーションが第２のアプリケーションを上書きするあるいはそのデータを書き込む）を防止する頑強な区画化を実施することができる。

図４を再び参照すると、ロードルーチン７６の少なくとも１回の完了後、プロセッサ５０は処理ブロック１３２で始まる立ち上げルーチン１２６を実行してもよい。この立ち上げルーチン１２６はオペレーティングシステム５４により実施され、実行のために揮発性メモリ６４内に様々なアプリケーションプログラム５２を移動させる。この立ち上げ処理は、構成表９４により、特にはタイプＡ、ＢまたはＣに関する各アプリケーションプログラムの識別により、再び制御される。好ましい実施形態では、立ち上げ処理は、タイプＣアプリケーションで始まり、タイプＣアプリケーションのすべてが処理ブロック１３４と１３６を境とするループ毎に立ち上げられた後に、タイプＡおよびタイプＢアプリケーションを立ち上げる。

図６をまた参照すると、この立ち上げ処理の第１番目の工程では、オペレーティングシステム５４と様々なアプリケーションプログラム５２との実行可能ファイルを保持するための揮発性メモリ６４はオペレーティングシステム５４により予約される。この予約は、（各アプリケーションプログラムの処理に割り当てられたグループに従って）各アプリケーションプログラム５２により使用されるランダムアクセスメモリ６４の各アドレス範囲へのアクセスを制御するために、オペレーティングシステムと共に、揮発性メモリ６４の物理アドレスへの論理アドレスのマッピングを制御するためにメモリ管理ユニット６８の制御レジスタにデータをロードすることにより、メモリ管理ユニット６８（図１に示さす）により、実行されてもよい。制御レジスタはレジスタメモリ空間６５内にマッピングされた論理アドレスメモリを有してもよく、これによりメモリ管理ユニット６８の制御レジスタへのアクセスはメモリ管理ユニット６８自身により、オペレーティングシステム５４に限定されてもよい。

立ち上げルーチン１２６の第１番目の工程の前に、第１のアドレス範囲１３８は、オペレーティングシステム実行ファイルと、そのデータメモリ１４０と、ソケットバッファ１４２に予約されたメモリと、を保持するために、オペレーティングシステム５４に割り振られる。データのこの第１のアドレス範囲１３８の書き込み権限は、オペレーティングシステムにより設定されるように、オペレーティングシステム５４にだけ与えられる。

既に述べたように、アプリケーションプログラム５２のそれぞれのアドレス範囲もまた処理ブロック１４８において予約される。本発明は、構成ファイルから判断される各アプリケーションプログラム５２に所定の固定アドレス範囲１５２だけを予約する。この予約処理は構成表９４から識別されるタイプＣアプリケーションから始める。各予約アドレス範囲１５２はアプリケーションプログラム５２自身のオブジェクトファィル１５４を保持（実行のための命令を保持）しなければならない。予約アドレス範囲１５２内のデータ空間は以下に説明されるようにアプリケーションにより必要に応じ割り振られる。アプリケーションの予約アドレス範囲１５２の権限は既に述べたように、アプリケーションプログラム５２が、それらの実行ファイル８８を保持する一意的なアドレス範囲１５２外に書き込むことができないように設定され、アプリケーション間の妨害（例えばタイプＣアプリケーションのアプリケーションデータのタイプＡ／Ｂアプリケーションによる有害な上書き）を防止する。すべてのタイプＣアプリケーションが構成ファイル８４当たりの最大予約メモリ量を与えられることを保証するためにはメモリが不十分な場合、その後、より多くのメモリの予約を必要とするタイプＡ／Ｂアプリケーションプログラム５２は立ち上げられなく、エラーが告知されログ記録される。

タイプＡ／ＢアプリケーションがタイプＣアプリケーションの適切な動作に必要なメモリを後で割り当てることができないことを保証するために、タイプＣアプリケーションのすべての制限が評価され、タイプＣアプリケーションが最初に立ち上げられる。残りのメモリはタイプＡ／Ｂアプリケーションに利用可能となる。タイプＡ／Ｂアプリケーションの構成限界が、すべてのタイプＣアプリケーションが評価された後に利用可能なものを越えると、アプリケーションは立ち上げられなくなる。この評価は、タイプＣアプリケーションにより使用中のメモリの現在量ではなく設計承認された構成ファイル内に規定された最大限度を使用して実行される。

当該技術において理解されるように、ソケットバッファ１４２は実際のネットワーク（例えば、ネットワーク４５）上またはアプリケーション処理間のネットワーク状通信を提供するために使用されてもよい。ここでは、ソケットバッファ１４２は様々なプログラムまたは装置によりアクセスされるネットワーク点またはアプリケーション間で送信されるデータの記憶を行う。ソケットバッファ１４２はオペレーティングシステム５４の第１のアドレス範囲１３８内に保持されるので、ソケットメモリの誤用（例えば、あまりにも多くのソケットが開かれるか、ソケットが大きすぎる場合）はシステムの動作を妨害する可能性がある。

また図４を参照すると、処理ブロック１５６では、各アプリケーションプログラム５２により必要とされるソケットバッファ１４２は第１のアドレス範囲１３８内に予約される。ソケットバッファ１４２によるアドレス範囲１３８の可能な過剰割り振り（例えば、オペレーティングシステム５４またはそのアプリケーションプログラム５２の動作に影響を与える可能性がある）を防止するために、本発明は、ソケットバッファ１４２の合計数とそれらの最大サイズの両方を構成データ８４から得られる所定値に制限する。このようにして、アドレス範囲１３８が所定最大サイズのソケットのこの所定合計数を保持することができることを保証することにより、ソケットバッファ１４２が利用可能メモリ空間を越えないことを保証することができる。実際には、オペレーティングシステムメモリに格納された各アプリケーション５２に関連した構造はアプリケーション処理がソケット接続を要求するときにチェックされる。この要求がソケットメモリに境界を越えるように強要すれば、要求はオペレーティングシステム５４により拒絶されるだろう。

処理ブロック１６０では、上述のビデオバッファ１５８のそれぞれは、表示システム２６へのアクセスを必要とするアプリケーションのオペレーティングシステム１３８に割り当てられたメモリ範囲内で予約される。

各アプリケーションプログラム５２が立ち上げられ、必要な揮発性メモリ６４が予約されると、オペレーティングシステム５４は、処理ブロック１６２に基づき、アプリケーションプログラム５２のそれぞれの処理（例えば、以下に説明するようにオペレーティングシステムスケジューラによりスケジューリングされてよい処理）をスケジューリングしてもよい。

図９を参照すると、オペレーティングシステムスケジューラ１６１は、アプリケーションプログラム５２により生じる処理の処理識別子１６６を保持するスケジュール待ち行列１６４を提供してもよい。これらの処理は、例えば各処理が次の処理が実行される前に所定の最大量以下のプロセッサ時間を持つことができるタイムスライスシステムに従ってプロセッサ５０により実行される。十分に実行されなかった処理は保留中の処理をすべて保持する工程表１６８に戻される。工程表１６８はまた他の処理により生じた処理を保持する。

論理的に描写すると、工程表１６８は、待ち行列順のプロセッサ５０による実行のための待ち行列１６４に配置するために、スケジューラエンジン１７０によりスケジューリングされる処理をそれぞれが表す一組の行を提供する。各行は、処理識別番号１６６と、内在アプリケーション１７２のタイプ（例えば、タイプＣ）と、処理１７４の最近の実行履歴と、を含む。スケジューラエンジン１７０は、タイプＡ／Ｂアプリケーションの前に表１６８内のいかなるタイプＣアプリケーションもスケジューリングするように動作し、さらに、処理１７４の履歴により示されるように、以前のスケジュール機会にそれらの全タイムスライスを使用しなかった処理に高い優先度を与えるように動作する。

したがって、スケジューラエンジン１７０は、ＣＰＵを以前に独り占め（ｈｏｇ）したアプリケーション５２を「罰する」ために、それらをタスク待ち行列のさらに後方に押しやってＣＰＵへのアクセスを得るために長く待たせるペナルティシステムを使用する。ＣＰＵ上の最大割り当て時間を常に使用するアプリケーションを罰することにより、カーネルは、それらをタスク待ち行列の終わりに押しやりすべての処理がＣＰＵにアクセスすることを保証する。そして構成ファイル内の最大値許容ＣＰＵ時間を適切に設定することにより、適切なアプリケーション優先順を制御することができる。

次に図６と図７を参照すると、オブジェクトファィル１５４により表される各アプリケーションプログラム５２は、オペレーティングシステム５４により別個のローカルグラフィックバッファ１５８を備える。このグラフィックバッファ１５８は、状態情報と共通グローバル構造（テキスチャ、フォント等）を格納するために使用されるメモリと、表示スクリーン２６の領域上に可視映像を完全に記述するのに十分な表示スクリーン２６へ出力するためのレンダリングを保持してもよいフレームバッファと、を含む。１つまたは複数の従来のグラフィックプロセッサ１８０は、表示スクリーン２６に１対１ベースでマッピングするピクセル値を供給するグラフィックバッファ１５８のフレームバッファ部内に別個の十分にレンダリングされたスクリーンマップを生成するために、オペレーティングシステム５４へのグラフィック呼出しを処理してもよい。このとき、これらのスクリーンマップは、表示スクリーン２６上にグラフィックバッファ１５８の１つのデータを表示するためにグラフィックバッファ１５８のデータ間で選択する（オペレーティングシステム５４により提供される焦点情報に従って）合成処理により、スクリーンバッファ内にグラフィックプロセッサ１８０により合成されてもよい。この処理は、誤ったタイプＡ／Ｂアプリケーションが、オペレーティングシステム５４により逆にすることができないやり方でタイプＣアプリケーションのデータを破壊できないように、各アプリケーション１５４の内在グラフィックデータが焦点と重要性の変更に応じて失われないように、それらを保存する。

オペレーティングシステム５４は、合成処理中にグラフィックバッファ１５８からのグラフィック情報の「前に」常に配置されるオーバーレイグラフィックバッファ１５８’を作成する。オーバーレイグラフィックバッファ１５８’内のこのデータは、常に一番前である、および／または透明度パラメータ（ｔｒａｎｓｐａｒｅｎｃｙ ｐａｒａｍｅｔｅｒ）を利用してもよい。このオーバーレイは、タッチスクリーンキーボード、テンキーまたはナビゲーションボタン等のグローバルシステムインタフェースを提供するだけでなく、例えばタイプＣアプリケーションにより生成され得る高優先度システム情報（警告、通知等）を告知するために使用されることができる。

また図８を参照すると、各グラフィックバッファ１５８は様々な機能領域１９０に分割されてもよい（ここでは画像を保持するものとして描写されるが、可能性としてより高レベルのグラフィック命令を保持する）。機能領域１９０は、例えば表示スクリーン２６上に単独で配置され得るデータを分離する。グラフィック合成器１８６は、表示スクリーン２６ａにより描写されるポートレートモードあるいは表示スクリーン２６ｂにより描写されるランドスケープモードのいずれかにおいて表示スクリーンの当該方位を示すスクリーン位置命令１９６を受け取ってもよい。後者は水平方向に長い次元で前者は垂直方向に長い次元で配置される。例えば構成表９４内の設定から与えられるこのスクリーン位置命令１９６に基づき、グラフィック合成器１８６は最良の表示配置を提供するために機能領域１９０の空間的位置を変更する。したがって、例えば機能領域１９０は、タッチスクリーンボタンを記述する機能領域１９０ａとグラフィック出力画像を記述する機能領域１９０ｂとを含んでもよい。ランドスケープ表示装置スクリーン２６ｂに関しては、機能領域１９０ａに由来するボタンの画像は機能領域１９０ｂに由来するグラフィック出力画像の側面に配置されてもよく、一方、ポートレート表示スクリーン２６ａに関しては、機能領域１９０ａに由来するボタンの画像は機能領域１９０ｂに由来するグラフィック出力画像の下に配置されてもよい。このようにして、別個のスクリーンレイアウトはグラフィックバッファ１５８内にハードコード化される必要はない。

あるいは、機能的に同一の結果は、アプリケーションにより必要とされるグラフィック要素の位置を自動的に調整するためにスクリーンの方位に関する知識を使用するグラフィックライブラリを採用することにより提供されてもよいことが理解されるだろう。

図１１を参照すると、様々な認証レベルを有する複数のアプリケーションプログラム５２を実行するために単一プロセッサ５０を使用する能力は、単一プロセッサ５０とオペレーティングシステム５４が仮想化により第２のオペレーティングシステム２１２を実行できるようにするように拡大されてもよい。この仮想化は、アプリケーションプログラム５２のいくつかを、設計承認されたオペレーティングシステム５４とは異なるオペレーティングシステム２１２上で実行できるようにする。したがって例えば上述の変更は設計承認されたＬｉｎｕｘベースのアプリケーションに関してであってよいが、タイプＡ／Ｂアプリケーションのいくつかは、Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステム２１２をＬｉｎｕｘオペレーティングシステム５４による有効なアプリケーションとして実行することにより、Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステム２１２に固有のものとさせることができる。

この実施形態では、オペレーティングシステム５４の設計承認されたＬｉｎｕｘベースのカーネル２００は、ゲストオペレーティングシステム２１２（典型的にはＷｉｎｄｏｗｓ（登録商標）オペレーティングシステム等のＣＯＴＳオペレーティングシステム）の実行を可能にするハイパーバイザ２１０等のバーチャライザ（ｖｉｒｔｕａｌｉｚｅｒ）を組み込んでもよい。ハイパーバイザ２１０は、ゲストオペレーティングシステム２１２に仮想ハードウェアプラットフォームを提供し、後者がＷｉｎｄｏｗｓ（登録商標）オペレーティングシステムを対象としたタイプＡおよびタイプＢアプリケーションプログラム５２を実行できるようにする。Ｌｉｎｕｘカーネル２００はタイプＣアプリケーションプログラム５２を直接実行してもよい。

当該技術において理解されるように、ハイパーバイザ２１０は、実際の物理的マシン（すなわち、プロセッサ、メモリ、ハードウェア）のＣＯＴＳオペレーティングシステム２１２の様相を作成するために、ＣＯＴＳオペレーティングシステム上にインストールされた仮想装置ドライバ２１４と仮想化層２１６とを介し実際のハードウェアへのインターフェースを提供する。さらに仮想マシンの動作は、ＣＯＴＳオペレーティングシステム２１２と、プロセッサ５０とメモリシステム６２の実際の物理資源のアプリケーションプログラム５２と、による使用を制約し、かつ設計承認されたオペレーティングシステム５４に従属するように、上述のように変更されたハイパーバイザ２１０とオペレーティングシステム５４により制御される。仮想マシン（ＣＯＴＳオペレーティングシステムとそこでホストされるドライバとアプリケーションとの集合）は、それ自身でタイプＡ／Ｂアプリケーションかのように扱われる。Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステム２１２は、不揮発性メモリ６６と揮発性メモリ６４内の任意の他のアプリケーションプログラム５２と同様にそれ自身の区画を与えられ、従来のアプリケーションに関する上述の他の制約条件を受けてもよい。

この環境では、タイプＣアプリケーションプログラム５２は、設計承認されたオペレーティングシステム５４上で直接実行され、したがってプロセッサ時間と表示空間を含む資源という意味で優先度を与えられてもよい。

仮想化は、特に、少なくとも部分的にはソフトウェアで実施されてもよいあるいは仮想化環境に広範に変換されてもよいグラフィックス処理に関して、性能の損失を与える可能性がある。このため、本発明は、オペレーティングシステム５４の仮想装置ドライバからハードウェアドライバ２３２へのトンネリング２２０を考える。このトンネリング２２０は、仮想装置ドライバ２１４と仮想化層２１６を回避し、かつカーネル２００を介し命令を実際のハードウェアドライバ２３２へ直接与えるようにＣＯＴＳオペレーティングシステム２１２を変更することにより実施されてもよい。このようにして、グラフィック命令がビデオコントローラ２４のハードウェアにより直接実施されるのではなくむしろ仮想化を介しソフトウェアで実施されるときに発生し得る遅延だけでなく、仮想化層２１６とハイパーバイザ２１０を介した作業の遅延も削除される。

タイプＡ／Ｂアプリケーション上のタイプＣアプリケーションの優先度を混乱させるトンネリングの危険性は、オペレーティングシステム５４がトンネリング２２０をオン・オフ切り替えできるようにすることにより、例えば、ドライバ２３２を異なる命令バッファ（仮想装置ドライバ２１４とトンネリング２２０により使用されるものと、設計承認されたオペレーティングシステム５４上でホストされるアプリケーションプログラム５２により使用されるもの）間に向けることにより、制御される。

さらなる性能向上は、例えば電子航空バッグ１０’内に実装されないハードウェア部品の支援を削除する著しく単純化されたＣＯＴＳオペレーティングシステムを使用することにより得られる。

さらなる性能向上は、複数の異なるＣＯＴＳオペレーティングシステム２１２（図示せず）により様々な組のアプリケーションプログラム５２を実行することにより得られるかもしれない。様々な仮想マシンの使用は、異なるオペレーティングシステム２１２により表される各仮想マシンに割り振られた資源を変更することにより実行するアプリケーションプログラム５２のタイプに各仮想マシンを「調節」できるようにする。例えば、メモリ集中型アプリケーションプログラム（ｍｅｍｏｒｙ ｉｎｔｅｎｓｉｖｅ ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍ）５２はそれに比例したメモリを与えられた仮想マシン上で実行されてもよく、コンピュータ集中型アプリケーション（ｃｏｍｐｕｔａｔｉｏｎａｌｌｙ ｉｎｔｅｎｓｉｖｅ ａｐｐｌｉｃａｔｉｏｎ）はより大きなプロセッサ資源を与えられた仮想マシン６４ａ上で実行されてもよい。同様に、ネットワークアクセス等のハードウェア資源はそのように調整されることができる。このようにして、資源は、仮想化による性能損失を低減することでより好適に割り振られてもよい。例えば、追加メモリは処理速度を不釣り合いに改善することができ、メモリが与えられれば仮想マシンは、仮想マシン間のメモリの単純な均等分割を上回る効率向上を達成することができる。この種の調整は、電子航空バッグ１０’の閉じたハードウェア環境のために、可能である。

本発明は本明細書に含まれる実施形態と例示とに限定されないように特に意図されている。特許請求の範囲は、本実施形態の部分と以下の請求項の範囲内で生じる異なる実施形態の要素の組み合わせとを含む実施形態の変更形式を含むものと理解すべきである。本明細書に記載の特許文献と非特許文献を含む参照文献のすべてを参照により本明細書に援用する。

Claims (21)

1. 少なくとも１つのコアを有する単一プロセッサと、
   前記プロセッサと通信し、オペレーティングシステムを保持する電子メモリシステムと、
   ナビゲーションシステムを含む他の機上設備に接続するために航空機データネットワークと通信するネットワークインターフェースと、
   前記プロセッサと通信する表示装置と、
   を含むクラス３電子航空バッグにおいて、
   前記オペレーティングシステムは、前記電子メモリシステム内のタイプＡ／Ｂアプリケーションの前記電子メモリシステム、前記表示装置、および前記プロセッサへのアクセスを、前記タイプＡ／Ｂアプリケーションの実行によるタイプＣアプリケーションの実行の潜在的妨害を阻止するために前記オペレーティングシステムにより適用される所定の規則に従って制限するように実行し、
   前記タイプＣアプリケーションは前記航空機データネットワークと相互作用するように構成されており、前記タイプＡ／Ｂアプリケーションは前記航空機データネットワークと相互作用するように構成されておらず、
   前記オペレーティングシステムは、前記表示装置にデータを供給するように前記単一プロセッサ上で実行され、
   前記オペレーティングシステムは、アプリケーションから標準表示データを受信するアプリケーションバッファと、タイプＣアプリケーションから高優先度表示データを受信するオーバーレイバッファと、を管理し、
   前記オペレーティングシステムは、表示されたときに前記アプリケーションバッファが前記オーバーレイバッファからのデータを遮らないように、前記バッファの内容を合成することを特徴とするクラス３電子航空バッグ。
2. 請求項１に記載のクラス３電子航空バッグにおいて、前記オペレーティングシステムは通信用に使用されるソケットバッファの全体のサイズを制限することを特徴とするクラス３電子航空バッグ。
3. 請求項２に記載のクラス３電子航空バッグにおいて、前記ソケットバッファの前記全体のサイズはソケット当たりの所定最大データ割り振りと所定最大数のソケットとにより制限されることを特徴とするクラス３電子航空バッグ。
4. 請求項１に記載のクラス３電子航空バッグにおいて、ネットワーク同報メッセージが禁止されることを特徴とするクラス３電子航空バッグ。
5. 請求項１に記載のクラス３電子航空バッグにおいて、
   前記電子メモリシステムは不揮発性データ記憶装置を含み、
   各アプリケーションは書き込み権限ではなく読み取りおよび実行権限を有する区画に割り当てられることを特徴とするクラス３電子航空バッグ。
6. 請求項１に記載のクラス３電子航空バッグにおいて、
   前記電子メモリシステムは揮発性データ記憶装置を含み、
   各タイプＡ／Ｂアプリケーションは、すべてのタイプＣアプリケーションが揮発性データ記憶装置に予約された後にだけ揮発性データ記憶装置に予約される、ことを特徴とするクラス３電子航空バッグ。
7. 請求項６に記載のクラス３電子航空バッグにおいて、揮発性データ記憶装置の予約はアプリケーション当たりの所定最大記憶量に制限されることを特徴とするクラス３電子航空バッグ。
8. 請求項７に記載のクラス３電子航空バッグにおいて、前記揮発性データ記憶装置の予約はすべてのアプリケーションの所定の合計最大記憶量に制限されることを特徴とするクラス３電子航空バッグ。
9. 請求項７に記載のクラス３電子航空バッグにおいて、前記オペレーティングシステムは、前記揮発性データ記憶装置へのアクセスを制御するメモリ管理ユニット内のレジスタをロードすることにより前記所定の合計最大記憶量とアプリケーション当たりの所定最大量を適用することを特徴とするクラス３電子航空バッグ。
10. 請求項１に記載のクラス３電子航空バッグにおいて、前記オペレーティングシステムは、前記アプリケーションの様々な処理の実行のための前記単一プロセッサのスケジューリングを制御し、各アプリケーションの制限された最大スケジューリング率を与えることを特徴とするクラス３電子航空バッグ。
11. 請求項１０に記載のクラス３電子航空バッグにおいて、前記アプリケーションの前記様々な処理は、タイプＣアプリケーションの処理が待ち行列における優先度を与えられるように前記単一プロセッサの待ち行列に入れられることを特徴とするクラス３電子航空バッグ。
12. 請求項１１に記載のクラス３電子航空バッグにおいて、前記処理は、全スケジューリング率を歴史的に使用しない場合と比較して全スケジューリング率を歴史的に使用する場合は前記待ち行列の低順位に置かれることを特徴とするクラス３電子航空バッグ。
13. 請求項１に記載のクラス３電子航空バッグにおいて、
    前記電子航空バッグはさらに、構成レジスタを有する周辺装置を含み、
    前記オペレーティングシステムは、これらのレジスタへのアクセスをタイプＡ／Ｂアプリケーションに対して阻止することを特徴とするクラス３電子航空バッグ。
14. 請求項１に記載のクラス３電子航空バッグにおいて、
    前記オペレーティングシステムは、前記表示装置にデータを供給するために前記単一プロセッサ上で実行され、
    前記オペレーティングシステムは、前記タイプＡ／Ｂアプリケーションが前記タイプＣの前記バッファのデータを上書きできないように、少なくとも１つのタイプＣと１つのタイプＡ／Ｂアプリケーションのそれぞれの別個のバッファを管理し、オペレーティングシステム制御により前記バッファ間で選択することを特徴とするクラス３電子航空バッグ。
15. 請求項１４に記載のクラス３電子航空バッグにおいて、別個のバッファは異なるアプリケーションにより一意的に書き込み可能な記憶場所内に存在することを特徴とするクラス３電子航空バッグ。
16. 請求項１４に記載のクラス３電子航空バッグにおいて、
    前記バッファは機能領域に分割され、
    前記表示システムは、前記表示装置の示された方位に依存して異なる機能領域の前記表示装置上のバッファ位置と空間的位置との関係を再配列することを特徴とするクラス３電子航空バッグ。
17. 請求項１に記載のクラス３電子航空バッグにおいて、
    前記電子メモリシステムはまた、第２のオペレーティングシステムを保持し、
    前記タイプＡ／Ｂアプリケーションは前記オペレーティングシステムにより実施される仮想化により前記第２のオペレーティングシステムにより実行される、ことを特徴とするクラス３電子航空バッグ。
18. 請求項１７に記載のクラス３電子航空バッグにおいて、
    前記オペレーティングシステムはあたかも前記第２のオペレーティングシステムがタイプＡ／Ｂアプリケーションであるかのように前記第２のオペレーティングシステムを実行することを特徴とするクラス３電子航空バッグ。
19. 請求項１７に記載のクラス３電子航空バッグにおいて、
    前記オペレーティングシステムは、前記第２のオペレーティングシステムの実行による前記タイプＣアプリケーションの実行の潜在的妨害を阻止するために、前記オペレーティングシステムにより適用された所定の規則に従って前記第２のオペレーティングシステムの前記電子メモリ、前記表示装置、および前記プロセッサへのアクセスを制限することを特徴とするクラス３電子航空バッグ。
20. 請求項１７に記載のクラス３電子航空バッグにおいて、前記オペレーティングシステムは設計承認を必要とするオペレーティングシステムであり、前記第２のオペレーティングシステムは設計承認を必要としないオペレーティングシステムであることを特徴とするクラス３電子航空バッグ。
21. 請求項１９に記載のクラス３電子航空バッグにおいて、前記第２のオペレーティングシステムはＷｉｎｄｏｗｓ（登録商標）であることを特徴とするクラス３電子航空バッグ。

Images