JP2011510374A - アプリケーションの実施方法、関係するキット及び航空機 - Google Patents

Abstract

本発明は、航空機等の車両（１）の乗員とのインターフェースの情報処理アプリケーション（210、210′）を実行する方法、及び、対応するシステム及び該システムを有する航空機に関する。
前記方法は、特に、車両の中に搭載された実行システムを備え、前記実行アプリケーションを有するリムーバブルメディア（200）を、リムーバブルメディア読取装置（128）を使って読取るステップ（306、308、604）（この読取装置は、車両に搭載された実行システム（110,120）を備える）と、前記実行システムに含まれ、前記リムーバブルメディア読取装置に接続する実行手段（111,121）により前記アプリケーションを実行するステップ（312,614）。
但し、前記アプリケーションの実行は、前記リムーバブルメディアの上でしか、その実行に必要なデータの永久記録を必要としない。
例として、ポータブルアプリケーションが使える、又は、リムーバブルメディア上にインストールされたオペレーティングシステムに基づいて実行システムが起動される。
【選択図】図１

Description

本発明は、車両の操縦機能及びメンテナンスのために、車両に組込まれたプラットフォームに関係する。具体的には、本発明は、このようなプラットフォームに対するアプリケーション実行のための方法とシステムに関する。

航空機又は自動車等種々の技術分野においては、多くの、操縦及び/又はメンテナンスを補助するアプリケーション（プログラム）が、車両メーカーにより設けられた車両搭載コンピュータシステムを使って、乗員に対して提案されている。しかし、このシステムは、メーカーが独占していた環境に制限を与える。 そこで、特に、航空に関する特定分野においては、それは「メーカーの分野（domaine constructeur）」、特に「航空機メーカー分野（domaine avionneur）」と呼ばれている。

一般的に、このシステム又はプラットフォームは、サーバーを介して車両部品と相互に関係している。また、表示装置、入力装置を介して、パイロット又はメンテナンスオペレータと相互に関係している。このプラットフォームから、車両のいくつかの重要な機能にアクセスできる。例えば、速度制御装置、自動車用ブレーキABS、自動操縦、及び、航空用のGPSに接続する種々の搭載電子装置である。

標準ARINC 763に準拠したネットワーク サーバー システム（NSS、即ち"Network Server System"）の名称で、パイロット及び航空機のメンテナンスオペレータ向けのコンピュータシステムは公知である。例えば、特許公報FR 2895793、FR 2892092、FR 2831871、又は、EP 1160160には、航空機用プラットフォームについて記載されている。

明らかに高レベルのセキュリティが、これらのプラットフォームの組み立て及び/又は変更には必要であることは認めざるを得ない。必要とされるセキュリティは、‘操縦及び/又はメンテナンスを目的とするプラットフォーム’と‘乗客用のコンピュータプラットフォーム（特に、機内エンターテインメント プラットフォームIFE(“In-Flight Entertainment”)’とでは異なる。

このような機内エンターテイメントは、WO 2007/093327又はEP 1367683等の刊行物に記載されている。

FR 2895793 FR 2892092 FR 2831871 EP 1160160 WO 2007/093327 EP 1367683

実際には、メーカー自身が、メーカーの分野を保証している。また、メーカーは、乗務員用のプラットフォームの新装置及び/又はプラットフォームのアプリケーション（applications informatiques）の検証と組立てを行っている。

従って、車両の持ち主が、このプラットフォームに、自由に新しいアプリケーションと機能を追加したいと希望する場合、問題がおきる。

このために、"ユーザー分野（domaine utilisateur ）"を、その車両の持ち主が自由に、アプリケーションの追加、変更できるような環境で定義するとよい。"ユーザー分野”と"メーカー分野"の区別は、後者が要求するセキュリティの必要性（例えば、費用のかかる認証手続きを設けること）により行うことができる。

自動車分野では、その持ち主は、リース会社、車両群の所有会社又は１の個人でありえる。

上記の問題のある別の産業分野として、次の説明の中心になるのは航空機分野である。航空機分野では、持ち主は、特に、乗客輸送のために航空機をチャータする航空会社でありえる。そこで、「会社分野（すなわち「エアライナー分野」）」について検討する。

また、パイロット及び／又はメンテナンスオペレータ向けの複数アプリケーションについて、予め必要なもの（pre-requis）が存在する。これにより、彼らが航空機の外で、これらアプリケーションを使うことができる。例えば、飛行準備（パフォーマンスの計算）、操作手続き（une procedure d'intervention）、飛行時に記録されたデータに基づく飛行後の報告書作成等である。

現在知られている解決法はポータブルパソコン（パソコン又はPC）の使用である。パソコンは、ラップトップ（stations d'accueil）を介して、飛行中に航空機のネットワークNSSに接続することができる。

これらパソコンは、これまで使用されていた重いパイロットの鞄に取って代わるもので、これらを使うと、パイロットは、移動しながら、飛行前にホテル又は搭乗準備室（salle de pre-embarquement）からミッションデータを運び、パフォーマンス計算を行うことができる。

旅行に広く使用されているアプリケーションには、パフォーマンス計算ツール、操作マニュアル（例えば、チェックリストを含む）、メンテナンスマニュアルがある。

これらパソコンは電子飛行バッグ（EFB, "Electronic Flight Bag"）として公知である。これは、Joint Aviation Authority JAAのTGL36 (Temporary Guidance Leaflet)標準になっており、Federal Aviation Administration FAAのAdvisory Circular AC、 ナンバー120-76A に掲載されている。

前記EFBバッグにはカテゴリーが３つある。
クラス１のEFBは、航空機のコンセントから電源を得て、棚（etagere）の上でオフラインで(autonome)使うことができるポータブルPCで構成されている。表示と制御手段(例えば、キーボードとマウス)は自立している(autonome)。

PC（航空会社）と搭載システムNSS（航空機メーカー）との間の独立性が提案されている。これによれば、航空会社は、このEFBクラス１に基づいて、所望のソフトウェアを自由にインストールすることができる。

しかし、このようなEFBクラス１は飛行の複数段階（例えば、離陸、着陸）では使用することができない。更に、プラットフォームNSSとのインターフェースがないと、航空機パラメータにアクセスすることはできない。

EFBクラスIIは、EFBクラスＩに似ている。EFBクラスIIでは、全飛行段階において使用することができるように、表示とコックピット手段の遠隔制御の可能性が提案されている。例えば、コックピットと一体となった表示装置、キーボード、トラックボールコックピットを使うことができる。パソコンは、ラップトップを介して遠隔のインターフェースに接続されている。ポータブルパソコンは航空機に付属していないので、パイロットは航空機の外で使うことができる。

このEFBクラスIIを使うと、読取りだけ、航空パラメータに対しアクセスすることができる。EFBとプラットフォームＮＳＳとの間の独立性は維持され、これにより航空会社は所望のソフトウェアを自由にインストールすることができる。

通常、EFBクラスＩとIIとは、航空会社により選択される。それらは頻繁に変更され、航空機の上で、連続的に操作する２人のパイロットの間でも相違してもよい。それらは、航空機のコックピットにおける複雑な組込みとインストールが必要であるという問題を提起する。例えば、市場で入手できる全てのポータブルパソコンを使用可能にするためのコネクター又はラップトップを用意することは困難であるからである。

航空機メーカーは、航空会社分野のコンピュータを管理していない。事実、これらコンピュータは、複数メーカーに適用されるセキュリティ基準に対応していないので、これらコンピュータを実行する時、セキュリティリスクが発生する。

クラスIII のEFBは、航空機に付属する装置である。例えば、エアバスＡ３４０（商品名）におけるＯＩＴ（Onboard Information Terminal：保守マニュアル等のフォルダーの電子版を参照するための対話型表示装置に対応する）。または、クラスIII のEFBは、メーカー番号（NSSシステムにおける識別番号）の一部を形成する装置である。例えば、エアバスＡ３８０（商品名）におけるＥＦＢである。ＥＦＢのタイプIII を使うと、システムへの組込みの理由で、読取り時に、アビオニクス（avionique）パラメータへアクセスすることができる。

しかし、クラスIII のEFBの場合、航空会社は、組立て者としてのメーカー抜きにしては、このEFBに基づくソフトウェアを自由に使うことはできない。

本発明の目的は、従来技術の欠点を解決することである。

このために、本発明は、特に車両（vehicule）の乗員とのインターフェースのアプリケーションの実行方法を目的とする。この方法は、以下のステップを有している。
−車両に搭載された実行システム（systeme d'execution）を備える(equipant）リムーバ ブルメディア読取手段を使って、実行アプリケーションを有するリムーバブルメディア を読み取るステップ：
−‘前記実行システムに含まれ、前記リムーバブルメディア読取装置に接続されている実 行手段’を使って前記アプリケーションを実行するステップ。
但し、前記アプリケーションの実行は、リムーバブルメディア上でしか、その実行に必要なデータの永久記録を必要としない。

ここで"永久"とは、アプリケーションの実行を超えるデータの格納、又は、記憶を意味する。即ち、アプリケーションは実行されないけれども、メモリにおいて永久化するデータである。一時記憶に対して、この永久記憶が対立している。一時記憶とは、一般的に、マイクロプロセッサーが、アプリケーションを効率的に実行することができるように、RAMタイプのメモリにデータを記憶させることである。

また、本発明は、特に車両の乗員とのインターフェースのアプリケーションの実行方法を対象とする。前記アプリケーションは自身の実行に必要な関係データを使うもので、前記方法は、
−車両に搭載される実行システムを備えるリムーバブルメディア読取手段を使って、リムーバブルメディアを読取る読取ステップ：リムーバブルメディアは前記実行すべきアプリケーションを有している。
−前記実行システムに含まれ、前記リムーバブルメディア読取装置に接続する実行手段により前記アプリケーションを実行するステップ。
前記アプリケーションの実行は、前記実行システムにおける、前記関係データの永久記録なしに実行される。

この永久記録は、オペレーティングシステムのレジスター、再書き込み可能なメモリ(EEPROM、Flash、…)又はハードディスク等、特に非揮発性メモリを対象としている。

アプリケーション実行に必要なデータと（例えば、オペレーティングシステムがこの実行を進めることができるための、レジスタの変更）、実行時に使用されるデータ（例えば、前記実行に必要な特性を持たないユーザファイル）とが区別される。

本発明によれば、搭載された実行システムにおいて、いかなるアプリケーションデータも、長期に記録されることはない。

アプリケーションに関係したデータで、その実行に必要なデータが、実行システムを汚染しないように、リムーバブルメディア以外の場所に、永久的に保存されないようにすることに留意すべきである。例として後で説明するように、これらアプリケーションがリムーバブルメディアに設けられているとき、アプリケーションを有するホルダーへの（即ち、リムーバブルメディアの上への）、実行に必要なデータの書込みを制限するポータブルアプリケーションが考えられる。
考えられる別の例として、リムーバブルメディア上にインストールされ、実行システムが起動（boote）されるオペレーティングシステムの存在である。該オペレーティングシステムにおいて実行されるアプリケーションは、オペレーティングシステム（即ち、リムーバブルメディア）のインストールにより制限されているレジスタ又は別の非揮発性メモリにおいてのみ、その実行に必要なデータの書込み行う。しかし、ミッションデータ（リムーバブルメディアに格納されることができる）、航空機関連データ（例えば、故障、修理の履歴）（航空機搭載メモリに保存されている）等の内容のデータを自由に操作する可能性は維持される。

乗務員(equipage）は、乗客に対立するものを意味する。つまり、車両の機能パラメータを使って、介入し、作用する権限を有する従業員である。特に、乗務員は、１人又は複数のパイロット、搭乗する乗務員及びメンテナンスオペレータを総称したものである。

本発明によれば、会社が、上記従業員の役に立つアプリケーション アセンブリを有するリムーバブルメディアを使えば、ポータブルコンピュータを使用しなくてよい。複数のインターフェースの存在を考えると、ポータブルコンピュータの組込みとインストールに関係する問題は回避される。実際に、リムーバブルメディアは一般的な接続標準に従っている。

更に、利害関係者を有するポータブルコンピュータの使用と比較すると、リムーバブルメディアを使用することは、経済的利益がある。従来、リムーバブルメディアは受動的で自身の実行手段を欠く装置（独立電源がなく）として考えられてきた。実際に、一般的に記憶手段として使っていた。

パイロットは、専用のメディア読取装置を持つポータブルパソコンを使って、自分のホテルから、このリムーバブルメディアを簡単に使うことができる。

搭載された実行システムとリムーバブルメディアとを接続すると（メディア読取装置を介して）、例えば、コックピットに備えられている表示装置、入力装置のインターフェースを介して、飛行の全段階でリムーバブルメディアを使うことができる。

実行システムは、車両に組込まれた情報処理システムの形をとることができる、又は航空機に取り付けられたEFBクラスIII タイプの装置の形をとることができる。

リムーバブルメディアからのアプリケーションのロードは、搭載システムに対し行われるが、実施時の前記アプリケーションは搭載プラットフォーム上に跡を残さない、というメカニズムの働きのおかげで、後に問題を発生させることは無い。このように従業員EFBとプラットフォームとの間に強い独立性があるので、リムーバブルメディアを介して、航空会社は、自由に、搭載システムのセキュリティに影響を与えることなく、自分が望む複数アプリケーションを実行することができる。
この意味では、自分の実行のためのアプリケーションに関係するデータは、例えば、ドライバー、ライブラリー、ソースコード、実行ファイル、コンフィギュレーションファイル、レジスターファイルであることができる。これら後者のものはリムーバブルメディアに格納され、従って、実行システムに向けての格納のために展開されることはない。

この独立性があるので、前記プラットフォームは、特定メディア環境用にならないようにできる。それゆえ、種々のカスタマイズされたリムーバブルメディアを介して、例えば、パイロットに関係する飛行環境、メンテナンス操作員に関係するテスト、シミュレーション環境等種々の実行環境を受け入れることができる。

また、非常駐アプリケーションに特有なデータにより汚染されることがないから、搭載システムは安全である。

前記のとおり、実際に、コックピット又は専用アビオニクス開口部（baie avionique）は、ＣＰＵカード（une carte d'unite centrale de traitement (CPU)）を提供する。該ボードは、情報処理システム用の表示装置、入力手段（キーボード及び/又はマウス）又は情報処理システム用ポインティングデバイス、メディア読取装置（コックピットからアクセス可能であり、パイロット、又はオペレータが所望のアプリケーションを含むメディアを、これに接続する）に接続されている。

搭乗準備室では、例えば、パイロットは、自分のメディアを、PC端子に、又はポータブルパソコンに設けられている専用の読取装置に接続することができ、航空機の外部から、所望のアプリケーション及びミッションデータにアクセスすることができる。

本発明の一つの実施例において、前記アプリケーションは、ポータブルアプリケーションである。

周知の通り、「ポータブルアプリケーション」は、独自のデータを格納するファイルにおいてオフラインで機能するソフトウェアである。ホストコンピュータのハードディスクに予めインストールすることはない。該ホストコンピュータ上にトレース（跡；traces 又は empreintes）を残さずに、該アプリケーションと関係個人データを自由に使用することが可能である。

従って、コンピュータに影響を与えるようなトレースを残す複数アプリケーションの同居の必要性に関連する誤動作、又は、追加的開発を回避することができる。ポータブルアプリケーションの特性から見て、実行システムへのアプリケーションの組込みは航空機メーカーには必要ではない。後者は余分な開発を避けることができるし、他方、航空会社はこれらアプリケーションを自由に、ゆっくり、追加、変更することができる。

例えば、最新技術のシステムにおいて、これらトレースとは、レジスタへの入力（des entrees en base de registre）、環境変数の変更、共有ライブラリのインストール又はアップデート、一時ファイルの生成、アプリケーションのバイナリー（binaires applicatifs）及びホストプラットフォームのハードディスク上のコンフィギュレーションファイルのコピーである。

特に、実行システムは、前記読取装置に接続されたメディアに格納されているポータブルアプリケーションを検出するように構成されたアプリケーションランチャーを有している。前記ポータブルアプリケーションはアプリケーションランチャーから起動される。

"plug and play″用メカニズムを使うと、読取装置にリムーバブルメディアを接続をすると、パイロット又はオペレータは、リムーバブルメディアにあるアプリケーションに、自動的に高速にアクセスすることができる。

アプリケーション ランチャーは、例えば、複数ファイルＵ３、Framakey（ポータブル アプリケーションの開発の基準）又は等価なフォーマットを検出し、対応するアプリケーション(複数)を表示することができる。これにより、ユーザは選択することができる。

一つの実施例において、前記リムーバブルメディアは、一つのオペレーティングシステムを有している。前記方法は、前記アプリケーション実行の前に、前記オペレーティングシステムの上の実行システムの起動段階（boot）を含んでいる。
前記アプリケーションは、リムーバブルメディアのオペレーティングシステムの環境において実行される。

読取装置に挿入されるリムーバブルメディアの上で、遠隔で起動（boot）するメカニズムを使うと、‘起動されたオペレーティングシステム’と‘オペレーティングシステムにおいて実行される複数アプリケーション’とによる、ホストプラットフォームの汚染を回避することができる。

前記実施例のおかげで、パイロット又はオペレータが使う前記オペレーティングシステムは車両に関係しておらず、リムーバブルメディアに関係している。この解決法により、オペレーティングシステムの利用に関係する法的な規定（dispositions legales）から解放される。

例えば、オペレーティングシステムに適用されるライセンスが存在し、しかも、そのオペレーティングシステムの実行が領土に依存するようなことがある。そのようなオペレーティングシステムが、車両の製造業者により直接導入されない場合に、バイヤー（acquereurs）は、前記オペレーティングシステム環境において開発されたアプリケーションを使うことができないということが起こる。
しかし、前記実施例のおかげで、航空会社は、独自のオペレーティングシステムを選択することができる。

特に、前記実行システムは、前記読取装置に接続されるリムーバブルメディアに格納されているオペレーティングシステムに基づいて前記実行システムを起動（booter）するように構成されたBIOSシステムを有している。BIOSの直接（directe）構成を使うと、搭載プラットフォームの実行システムの簡単な再起動により、実行システム及び‘リムーバブルメディアに含まれているアプリケーション’の起動を自動化することができる。

一実施例において、前記実行システムは、起動で実行される１のバーチャルマシンを含む。前記オペレーティングシステムは前記バーチャルマシンにおいて実行される。

これら条件のおかげで、ホストプラットフォームのハードウェア制約から解放される。従って、リムーバブルメディアが使用されるホストプラットフォームの全ハードウェア構成を満足させねばならない一般的ドライバー（リムーバブルメディアに格納される）を使用しなくてすむ。

その代わりに、実行システム上に設けられるバーチャルマシン用ドライバーが使用される。特に、製造された車両／航空機の全部、又は、部分の上に、同一のバーチャルマシンを設けることができる。これら特定ドライバーを使って、複数の機能がアクセスされる。結果、パフォーマンスが改善され、複数サービスがオペレーティングシステムにより提供される。

特に、前記実行システムは、前記バーチャルマシンにおいて実行されるオペレーティングシステムを含むことができる。

(複数)表示装置のおかげで、少なくとも２つのバーチャルコンピュータが、１つのハードウェア実行システム（CPU）に基づいてインスタンス化される。その結果、例えば、１つは航空機メーカーに関係する、他の１つは航空会社に関係するというように、２つの異なる環境を提供することができる。こうして、２つのＣＰＵを使用しなければならない(この場合、コスト、物理的スペース、熱的消費が重要になる）という制約から解放される。

１実施例において、前記実行手段は、前記実行システムのリムーバブルモジュールの部分を形成している。特に、リムーバブルＣＰＵカードがそうである。

この構成によれば、車両の寿命の間（１の航空機の寿命は数十年である）、処理／実行手段の処理能力の進化を効率的に管理することが可能である。

本発明の特徴によれば、前記リムーバブルメディアは、ＵＳＢメモリ、フラッシュメモリ、メモリカード（ＳＤカード、コンパクトフラッシュ（登録商標）、…）コンパクトディスク、ＤＶＤディスクを含む群の内の１つである。

これら実施例によれば、リムーバブルメディア、特に、格納用リムーバブルメディアは、実行手段、特にＣＰＵを備えていない装置であるが分かる。特に、格納のリムーバブルメディアがそうである。

また、スペースを最小にするために、リムーバブルメディアは独立電源（バッテリータイプの）を備えていない。

本発明は、車両の乗員とのインターフェースのアプリケーションの実行方法であって、
―車両に搭載された実行システムを備えるリムーバブルメディア読取装置を使って、ポータブルアプリケーションを有するリムーバブルメディアを読取るステップ、
−`前記実行システムに含まれ、前記リムーバブルメディア読取装置に接続する実行手段 ′を使って、前記ポータブルアプリケーションを実行するステップ。

また、本発明は、車両の乗員とのインターフェースのアプリケーションの実行方法を対象とする。この方法は、以下を含む。
−車両に搭載された実行システムを備えるリムーバブルメディア読取手段を使って、オペ レーティングシステム及び実行アプリケーションを有するリムーバブルメディアを読取 るステップ：
−`前記実行システムに含まれ、前記リムーバブルメディア読取装置に接続された実行手 段′を使って、リムーバブルメディアの前記オペレーティングシステム上に載った(emb arque)実行システムを起動するステップ：
−前記オペレーティングシステムにおいて前記アプリケーションを実行するステップ。

本発明は、車両の乗員とのインターフェースのアプリケーションを実行するための１つのキットを扱う。このキットは、次のものを有している。
−前記実行アプリケーションを有するリムーバブルメディア、
−前記リムーバブルメディアを受入れ、読取るリムーバブルメディア読取装置、及び、前 記読取手段に接続された前記アプリケーションを実行するように構成された実行手段を 、有する車両に搭載された実行システム。
但し、前記リムーバブルメディアは、“前記アプリケーションの実行は、前記リムーバブルメディアの上でしか、その実行に必要なデータの永久記録を必要としないように構成されている。

同様に、本発明は、車両の乗員とのインターフェースのアプリケーションを実行するための１つのキットを対象とする。前記アプリケーションは自分のアプリケーションに必要な関係データを処理するものであって、このキットは、次のものを有している。
−前記実行アプリケーションを有するリムーバブルメディア、
−前記リムーバブルメディアを受入れ、読取るように構成された、リムーバブルメディア 読取装置、及び、前記読取手段に接続された前記アプリケーションを実行するように構 成された実行手段を有する車両に搭載された実行システム。
但し、前記リムーバブルメディアは、“前記アプリケーションの実行は、前記実行システムにおいて、関係データの永久記録を必要としない”ように構成されている。

必要に応じて、複数キットの内の１は、上記方法の特徴に関係する手段を有することができる。

特に、前記アプリケーションはポータブルアプリケーションであることができる。具体的には、実行システムは、メディアが読取装置に接続されたときに、例えば、plug and play手段を使って、前記メディアに記憶されている複数アプリケーションを検出するように構成されたアプリケーションランチャーを含む。

代替として又はポータブルアプリケーションとの組合せで、オペレーティングは、前記リムーバブルメディアに設けることができる。実行システムは、例えば、適当な方法で実行システムのBIOSをパラメータ化して、このオペレーティングシステムで起動（booter）するように構成される。

特別の特徴によれば、実行システムは前記実行システムのリムーバブルモジュールの部分を形成している。

同様に、本発明は、車両の乗員とのインターフェースのアプリケーションを実行するための１つのキットを対象とする。前記キットは、次のものを有している。
−ポータブルアプリケーションを有する、１のリムーバブルメディア、
−車両に搭載された１の実行システム：これは、`前記リムーバブルメディアを受け入れ 、読取るリムーバブルメディア読取装置′及び`前記読取装置に接続され、前記リムー バブルメディアの前記ポータブルアプリケーションを実行するように構成された実行手 段′を有している。

同様に、本発明は、車両の乗員とのインターフェースのアプリケーションを実行するための１つのキットを対象とする。前記キットは、次のものを有している。
−オペレーティングシステムと前記実行すべきアプリケーションを有する、１のリムーバ ブルメディア、
−車両に搭載された、１の実行システム：これは、`前記リムーバブルメディアを受け入 れ、読取るリムーバブルメディア読取装置′及び`前記読取装置に接続され、リムーバ ブルメディアの前記オペレーティングシステム上で、前記搭載実行システムを起動する ように、又、前記オペレーティングシステムにおいて前記アプリケーションを実行する ように構成された実行手段′を有する。

同様に、本発明は前記キットを有する航空機を対象とする。

該キット及び該航空機の有利な点、目的、特徴は、前記した本発明の方法と同様であるので、繰り返さない。

本発明の特徴と利点は図面を使って好ましい実施例を読むと明確になる。

本発明を実施するために、航空機に搭載されたシステムの一例である。 例えば、図１のシステムにおける、本発明の第１実施例の概略を示す図である。 本発明による方法の第１実施例のフローチャートである。 本発明の第１実施例と関係する(複数)アプリケーションのノマド的利用の１例である。 例えば、図１のシステムにおける、本発明の第２実施例の概略を示す図である。 本発明による方法の第２実施例のフローチャートである。 例えば、図１のシステムにおける、本発明の第３実施例の概略を示す図である。 図１のシステムにおける、本発明の第４実施例の概略を示す図である。

本発明は、１の車両（ここでは、航空機１）の乗員用のアプリケーションの実行に関係する。そのアプリケーションにおいて、実行アプリケーションを記憶するリムーバブルメディアを読取るために、車両１に搭載された実行システムを備えるリムーバブルメディア読取装置に接続する。後者の実行システムは実行手段を有するものである。

図１を参照すると、航空機１はコックピット10を備えている。パイロット又はメンテナンスオペレータが、コックピットから、NSS（Network Server System）タイプの搭載システムに対しアクセスすることが可能になっている。該システムは、ツール及びパイロット支援及び航空機１の機能のアプリケーションを提供する。

NSSシステム100は、サブシステム110（必要があればセキュリティ化されている）を持っている。前記メーカー分野、即ち、航空機メーカー分野は、処理ユニットCPU111、揮発性メモリRAM112、ハードディスク113、周辺機器114、コックピットからアクセス可能な視覚化周辺装置及び入力装置、例えば、表示装置115及びキーボード/マウス116を提供している。これら装置はデータバス117により接続されている。

前記サブシステム110は、航空機１のセキュリティに関する重要なアプリケーションを有する場合がある（第２ケース）。従って、航空機メーカーは、前記サブシステムが、第３者が資格なしに介入できるような他のサブシステム（第１ケース）から分離されることを望む。実施例において、重要なアプリケーションは、他のサブシステムに設け、高度にセキュリティ化し、サブシステム110から一方向ネットワークダイオード（diode reseau unidirectionnelle）により分離することができる。この場合の特徴としては、サブシステム110は、航空機メーカーにより組み立てられることである。上記２つのケースの内、第２ケースにおいて、ハードウェアとアプリケーション(ソフトウェア)の認証（certification）は、主として、高度なセキュリティ化されるサブシステムのために、これら（ハードウェアとアプリケーション）を対象としていることを、ここで指摘する。

プロセッサー111を使うと、ハードディスク113に格納されたアプリケーションを実行することができる。これらアプリケーションは、航空機メーカーにより認証されて、サブシステム110に組み込まれる。

NSSシステム100は、サブシステム110よりセキュリティが低い第２サブシステム120を有している。つまり、認証（certification）と組立ての条件がより低いものである。

メーカー分野であれ、航空会社分野であれ、このサブシステム120は、データバスにより接続されており、アプリケーションを実行するための処理装置CPU121、揮発性メモリRAM122、ハードディスク123、周辺装置124及び、コックピットからアクセスできる表示装置、入力装置（例えばキーボード／マウス126）を有している。

スペースを節約するために、表示装置とキーボード／マウス115,116,125,126は同一装置に分散配置することができる。コマンドを使って１つのサブシステムから他のサブシステムに伝達することができる。

２つのサブシステム110と120は、ゲートウェイ（passerelle）130を介して相互に接続されている。これにより、プロセッサ121上で実行されるアプリケーションは、セキュリティ化されたサブシステム110が生成するアビオニクスパラメータ、データを取込むことができる。この取込みは、例えば、ハードディスク113に格納されている又は周辺装置114から送信されるデータファイル及び/又はパラメータの読取りにより行われる。

特に、ゲートウェイ130は、サブシステム120で実行されるアプリケーション（特に、以下に導入されるリムーバブルメディアのアプリケーション）について、サブシステム110のデータにアクセスする権利を制限し、サブシステム110を保護することにより、システムのセキュリティに貢献している。

サブシステム120は、更にリムーバブルメディア128読取装置を有している。ここでは、ＵＳＢ（Universal Serial Bus）メモリの読取りである。前記読取装置はリムーバブルメディアとシステムとの間の接続を可能にし、前者（リムーバブルメディア）の読取りを可能にするインターフェースとして考えることができる。一般的に、このインターフェースに関係するプログラム（例えば、ドライバー等）は、この読取機能を保証している。複数の読取装置128が設けることができる。これにより、ＵＳＢ,ファイアウォール（登録商標）等の種々のインターフェースのフォーマットを提供するリムーバブルディアの接続が可能になる。

パイロットは、この読取装置128に、コックピット10からアクセスすることができる。他の複数読取装置128は、例えば、メンテナンス要員（agents de maintenance）が前記サブシステム120と通信できるようにコックピットの外部に、サブシステム120に備えることができる。

パイロット又は他の要員との対話のない処理装置（複数）、特にCPU111,121,RAM112,122、ハードディスク113,123、周辺装置114,124は、専用スペース（例えば、コックピットの外側にあるアビオニクス情報処理部11）に組み込まれる。

補助的表示装置及び入力装置は、コックピット10の外側に、乗客キャビンを移動する従業員用に設けられる。

同様に、前記表示装置115及び入力装置116に代えて、表示装置及び/又は入力装置を接続するためのインターフェースを、必要に応じコックピットの外側に、追加して設けることができる。これにより、メンテナンス要員はコックピット10の外からNSSシステム100に操作することができる。

図２には、本発明の第１の実施例が示されている。これは、サブシステム120を単純化したものである。これに、パイロットのＵＳＢメモリ200が接続されている。

パイロットのＵＳＢメモリ200は、１又は複数のアプリケーション210、210′等を含むメモリである。これはパイロットの航空会社が開発したもので、補助ツール（例えば、認証リスト（checklists）等の飛行計画、手続き計画）として提案された。これらアプリケーションは航空機クルー（特に、パイロット）とのインターフェースアプリケーションである。

複数アプリケーション210、210′は、U3（Sandisk基準、登録商標）又はFramakey（自由ソフトウェアフォーマット）等のポータブルアプリケーションフォーマットにおいて開発されている。これらポータブルアプリケーションは、ＵＳＢメモリ200上で使用できる特性を有している。つまり、その使用は、主装置の上で、特にアプリケーションが実行されるハードディスク上で、ここでは、システム100の上で、個人情報が放置されないようにセキュリティ化されている。

これらアプリケーションは、実行のために、オペレーティングシステムを変更するものではない。オペレーティングシステムにおいて、アプリケーションが実行され、ライブラリーも十分である。つまり、前記アプリケーションはオペレーションシステムに内在するライブラリーで足りており、新規なライブラリーを設ける必要はない。これはホストマシーン上のトレースを構成することとなる。

これらアプリケーションを実行するには、アプリケーションに関係するデータを含むフォルダーのコピーが必要である。つまりアプリケーションファイル（フォーマットＵ３又はFramakey等）、ライブラリー、configurationのファイル、そのデータ等である。従って、アプリケーションの実行は、このフォルダー（この場合、フォルダーが記憶されているリムーバブルメディア）から直接に実行される。

ＵＳＢメモリ200は、ＵＳＢ読取装置128に接続され、ＣＰＵ121を使ってアプリケーション210を実行することができる。ＵＳＢメモリ200を読取ることができ、必要があれば、メモリにデータを書込むことができる。

サブシステム120のハードディスク123は、オペレーティングシステムＯＳ（Windows（登録商標）のOperating System等）123-1（これはサブシステム120の始動時に動く）、(複数)アプリケーション123-2（航空機メーカーにより既に組み込まれている）、ランチャーアプリケーション123-3を含んでいる。

このランチャーアプリケーション123-3は、読取装置128にＵＳＢメモリ200を挿入するときに、plug and playメカニズムにより起動する。該ランチャーアプリケーション123-3は、接続されたＵＳＢメモリにおいて、ポータブルアプリケーションの基準(特にU3 et Framakey)に基づいて作成されたアプリケーションを検出するように構成されている。

該アプリケーションは、検出されたポータブルアプリケーションを、パイロット又は他の従業員の表示装置125に表示する。パイロット又は他の従業員は、アプリケーションを実行するために、アプリケーションを選択する。

詳述すると、図３に示されているように、パイロットは航空機１を担当し、飛行するときに、ステップ300で、搭載システム及びその部品の電源を入れる。

ステップ302で、サブシステム120はオペレーティングシステム123-1の実行を開始する。

この段階で、パイロットは、従来のやり方で、航空機会社により既に組み込まれているアプリケーション123-2を使うことができる（ステップ304）。

ステップ306において、パイロットはＵＳＢ読取装置128に、ＵＳＢメモリ200を挿入する。ＵＳＢメモリには、全ミッションデータ、特に認証リスト、飛行計画が記憶されている。これらデータは予めパイロットにより、例えばホテルで作成されている。これらデータには、航空会社により開発されたポータブルアプリケーションを介して、全パイロットがアクセスできる。

ステップ308において、サブシステム120は、メモリ200が読取装置128に挿入されたことをplug and playメカニズムにより検出し、ランチャーアプリケーション123-3を起動する。このアプリケーション123-3はＵＳＢメモリのメモリをスキャンし、ポータブルアプリケーションの標準に対応しているアプリケーションファイル(Ｕ3標準のためのextension u3pを提供するファイル)の存在を判断する。

大容量メディアに対し検出時間を短縮するために、ルートフォルダー又は特定フォルダーにおける、ＵＳＢメモリのスキャンを限定するように設計することができる。

ステップ308において、ランチャーアプリケーション123-3は、ＵＳＢメモリ200に存在するポータブルアプリケーションのリストを作成する。

ステップ310において、ランチャーアプリケーション123-3は、パイロットの表示装置125に検出されたポータブルアプリケーション210のリストを表示する。

ステップ312において、パイロットはマウス126で、望むアプリケーション210を選択し、クリック等で実行を要求する。

アプリケーション210は、RAM122を使って、プロセッサ121により実行される。しかし、ハードディスク123上では、如何なるファイル又はconfigurationのコピーも行われない。

こうして、パイロットは、飛行用データを使うことができる。パイロットは、例えば、飛行後に使用するために、ＵＳＢメモリ200のメモリに直接登録された情報を入手することもできる。

例として、実行中のアプリケーション210は、オペレーティングシステム123-1を使って、例えばサブシステム120の周辺装置124にプリントすることができる。実際に、ポータブルアプリケーション210により、既に接続されているプリンタ、及び、選択されたデフォールトプリンタを印刷制御するための共通対話ボックスが現れる。

オペレーティングシステムはマルチタスクであることが好ましい。パイロットは複数のアプリケーション123-2,123-3に同時にアクセスすることができる。

アプリケーション210の最後に、パイロットはアプリケーションを閉じる（ステップ314）。ポータブルアプリケーション210,210′の特性により、実行されるアプリケーションに関係するどのようなデータも、サブシステム120のハードディスク上に常駐することはない。

本発明によれば、航空会社は自分用複数アプリケーションを開発でき、認証も、メーカーによる事前組込みもなく、航空機においてそれらを使用することができる。

パイロットが自分のＵＳＢメモリをＵＳＢ読取装置に接続できるように設計できることに注意すべきである。

その結果、本発明の技術思想を離れることなくサブシステム110を設計することができる。

また、本発明は、ランチャーアプリケーション123-3が無くて、パイロットがファイルシステム（FileSystem）を使ってポータブルアプリケーションファイル210にアクセスし、実行を要求しなければならないようなケースにも適用できることに留意すべきである。

図４は、ＵＳＢメモリ200の利用を説明するものである。前記のとおり、車両１のユーザ（ここでは、パイロット、メンテナンス要員）は、予め関係するデータ（donnees d'intervention：ミッションデータ、飛行計画、メンテナンス手続き等）を作成し、及び/又は、操作時（intervention）に、登録されているデータを使い、飛行報告等、後で活用することができる。

航空機のパイロットについて説明すると、パイロットは、ポータブルパソコン400を使うことができる。このツールを使うと、パイロットは、どこにおいても、特に、ホテルにおいても、搭乗準備室においても、飛行の前後の処理を実行することができる。

代替案として、パイロットは、搭乗準備室においてパソコンをＰＣ端子（図示しない）に自由に接続することができる、又はホテルのコンピュータを使うこともできる。

このパソコン400は、従来型のもので、表示装置402、キーボード404、アプリケーションを実行するプロセッサーＣＰＵ406、アプリケーション及びオペレーティングシステムを格納しているハードディスク408、ＲＡＭ及び読取手段に関係するＵＳＢポートを有している。コンピュータ400に搭載されるオペレーティングシステムは、特に航空機メーカーにより航空機１に組込まれたアプリケーション123-1と同一ファミリーである。すなわち、バイナリーコンパチブルである。

パイロットは自分のＵＳＢメモリ200をコンピュータ400のポート410に接続する。コンピュータ上に備えられているランチャーアプリケーションを使って（前記したやり方と同じやり方で）、又はコンピュータ400に搭載されたファイルシステムを介して直接的に、パイロットはＵＳＢメモリ200に格納されているポータブルアプリケーション210にアクセスする。

このようにして、ポータブルアプリケーション210が実行される。パイロットは望まれる処理を実行する。例えば、データを修正し、読取り、追加する等。

使用後、アプリケーション210は終了される。ポータブルアプリケーションであるから、コンピュータ４００の上には如何なるトレースを残さない。

次に、図５を使って、本発明の第２実施例を説明する。

この第２実施例において、アプリケーション210の実行のためのオペレーティングシステムは、サブシステム110又は120に搭載されず、ＵＳＢメモリ200に格納される。該メモリの上で、サブシステム120が起動する（booter）。図１乃至４に関係する上記の他の特徴は、この実施例においても同様である。

詳細には、図５は、本発明の第２実施例を示す。パイロットのＵＳＢメモリ200が接続されているサブシステム120を単純化して示している。

図５において、ハードディスク123には特定のデータは格納されていない。しかしながら、オペレーティングシステム、アプリケーション、関係データはハードディスクに格納されるように設計し、ＵＳＢメモリ200が無いときでもシステム100を起動することができる。

プロセッサー121（及び、広義のサブシステム120のマザーボード）は、ファームウェアＢＩＯＳ（Basic Input Output System)121-1をＲＯＭに記憶している。これは、オペレーティングシステムを起動するため必要とする、周辺装置のリストと順序を規定している。当業者にとって、これはＢＩＯＳの起動順序に関する重要なものである。

本発明のＢＩＯＳ121-1は、ＵＳＢ読取装置128上で、最初にbooterすることを規定する。そうでなければ、ハードディスク１２３上で起動することを規定する。もちろん、システムはリムーバブルメディア128の読取装置を複数有しており、対応するＢＩＯＳは、ハードディスク123に尋ねる前に、予め決められた順序でこれら読取装置をそれぞれ指定している。

ＵＳＢメモリ200は、必要ならば（ポータブルである必要なないが）、アプリケーション210と210′に加えて、１つのオペレーティングシステム212と複数のドライバー214を有している。

オペレーティングシステム212はインストールされていない、即ち、その構成は特定のハードウェア層に関係していない。

ドライバー214は、航空機メーカーにより予め保証されており、この航空機メーカーの航空機を使う航空会社に提供されている。これらドライバー214を使って、オペレーティングシステム212が、サブシステム120であれ、航空機１であれ、全てのハードウェア（パイロットのUSBメモリ200と関係して使用される）を識別することを可能にするという意味で、ドライバー214は一般的（generiques）であることが好ましい。そうすれば、USBメモリ200を別のコンピュータ上で使用することができる。

実際に、航空機メーカーはいくつかの主要なオペレーティングシステムに対し、又、航空機メーカーが提供するネットワークでアクセスできるサービス（印刷サーバー、アビオニクスパラメータに対するアクセスサービス、KCCUユニット（Keyboard Cursor Control Unit))に対し、複数ドライバーを提供している。航空会社は、パイロットがそれにアクセスできるように、USBメモリ200上にこれら機能を、自由に組込むことができる。

図６は第２実施例のフローチャートである。パイロットはシステム100、従って、そのサブシステム110と120の電源を入れる（ステップ600）。プロセッサ121はBIOS121-1にアクセスして、実行させる（ステップ602）。

BIOSの最初のコマンドで、システムはＵＳＢポート128上に、アクセス可能なオペレーティングシステムが存在するかどうかを判断する（ステップ604）。つまり、オペレーティングシステムを有しているＵＳＢメモリ200が接続されているか否かを判断する。

「ｎｏ」である場合（ステップ606）、サブシステム120は、ＢＩＯＳのリストの周辺装置上で、例えば、ハードディスク123のオペレーティングシステム上で起動する。

「ｙｅｓ」の場合（ステップ608）、サブシステム120はオペレーティングシステム212をメモリＲＡＭにロードし、プロセッサ121により実行する。

サブシステム120のハードウェア層にオペレーティングシステム212を適合させるために、オペレーティングシステム212の初期化には、ＵＳＢメモリ200に存在する一般的ドライバー214のロードが含まれている（ステップ610）。周辺装置と組込まれるハードウェア部品に対応する複数ドライバー214だけが、plug and playメカニズムによりロードされる。

従って、実行サブシステム１２０における各再起動において、オペレーティングシステム212は、ＢＩＯＳ、チップセット、ＣＰＵ，ビデオカード、サブシステム120のその他の周辺装置を検出し、再度、これら種々の部品に使われるドライバーをロードする。

オペレーティングシステムの実行にはＲＡＭ122、プロセッサ121、必要な周辺装置124が使われる。ハードディスク１２３上にはデータは書き込まれない。従って、オペレーティングシステムの実行を終了するときには、如何なるデータも残っていない。これにより、機能間の問題もなく、新規なＵＳＢメモリ200を受け入れることができる。

一旦オペレーティングシステム212が実行されると、自動的に実行される専用アプリケーションは、ＵＳＢメモリ200に存在する複数アプリケーション210,210′のリストを作成し、それらをパイロットに提示する（ステップ612）。パイロット自身は、ファイルシステムを介して、アプリケーション210,210′にアクセスする（ステップ612）。

ステップ614において、パイロットは望むアプリケーション（例えば、認証リストアプリケーション）の実行を選択し、開始する。

ここで、オペレーティングシステム212はＵＳＢメモリ200の上に存在するから、アプリケーション210,210′に関係するパラメータ又はデータも、ＵＳＢメモリ200上に存在していることに注意すべきである。従って、これらアプリケーションが実行されても、ハードディスク123の汚染はない。もちろん、上記したようにポータブルアプリケーションを使用できる。これにより如何なるデータも別のファイルにコピーされることはない。

アプリケーション210を使用することにより、パイロットはメモリ200の中のデータにアクセスできる（読出し及び/又は書込み）。

一旦アプリケーション210の動作が完了すると、前記アプリケーション210の実行が終了する（ステップ616）。この実行のトレースは、サブシステム120に、特にハードディスク213の上に残ることはない。

パイロットのＵＳＢメモリ200の使用に関して、コンピュータ400は、ＢＩＯＳにおいて、図５，６と関連して上記したサブシステム120と同じように、構成される。即ち、ＵＳＢポート410で起動する。こうして、パイロットは、どのようなＰＣ（ポータブルであろうとも）の上でも、オペレーティングシステム212を起動することができる。

従って、パイロットは航空機外であろうとも、航空機内であろうとも同じ作業環境で作業を行うことができる。航空会社は企業のポータルサイトとサービスにアクセスするためにポータブルパソコンＰＣ400を提供する。このポータブルパソコンは、USBメモリ200の挿入時の再起動（redemarrage）の後で、ＵＳＢメモリに基づいて使用できる。従って、企業のオフィス環境を含むハードディスク408は、使用されない。ＵＳＢメモリ200に基づいて航空機作業環境を使用するときには、それについてのトレースは全く残らない。

このように、ポータブルパソコンＰＣ400は、２つの作業環境（それぞれ独立しており、それらの間には交換がない）を提供することに留意すべきである。即ち、１つは、企業におけるオフィスにおける使用環境、他の１つは航空機における使用環境（Flight Ops-飛行のオペレーティングシステムと呼ばれている）である。

図７，８には、本発明の第３実施例が記載されている。

第３実施例では、サブシステム120がバーチャル化層を提供し、これが、特に、ドライバー214に対して、オペレーティングシステム212をハードウェアの束縛から解放しているが、この点を別とすれば、この第３実施例は、上記の第２実施例に似ている。

図１乃至６との関係で上記した特徴についても、この実施例は同様に有している。

図７は本発明の第３実施例であり、パイロットのＵＳＢメモリが接続されているサブシステム120の概略を示している。

図７において、ハードディスク123は、第１ホストオペレーティングシステム123-4を格納している。例えば、リナックス（登録商標）カーネル（noyau linux）又はリナックス（登録商標）ディストリビューション（distribution linux）、１つのバーチャルマシン123-5（この第１オペレーティングシステム１２３−４において実行されるように構成された）、第２オペレーティングシステム123-1（例えば、図２と関連して前記した）、及び、第２オペレーティングシステムにおいて実行されるアプリケーション123-2。これら種々のソフトウェア部品は航空機メーカーにより組込まれる。

バーチャルマシンは、VMWare, QEmu 又は XEN等に準拠している。

図８に示されているように、サブシステム120の起動において、第１オペレーティングシステム123-4は、航空機用ハードウェア層800の上で、適合したドライバーを使って直接実行される。次に、バーチャルマシーン123-5が、自動的に起動され、「従来の」オペレーティングシステム123-1がこれに続き、種々のアプリケーション123-2をパイロットに提示する。

また、 バーチャル化層123-5があるために、ドライバー214′は最大のハードウェア層800をみたすような一般的でなものでなく、バーチャル化層又はバーチャルマシーン123-5に特有であるが、この点を除いて、 ＵＳＢメモリ200は、前記した図５と関連するものと類似している。

実際には、バーチャル化層に関してシミュレートされたＢＩＯＳにおいて、起動順序が規定されている。オペレーティングシステムを使うメディア（CD-ROM等）が提供されるポート、必要に応じてデフォールトで別のポートが表示される。ここでは、オペレーティングシステム212上で起動するための起動の主要ポートして、ＵＳＢポートを指定することができる。

第３実施例は、バーチャルマシン上で並列に実行されるオペレーティングシステムの数を限定していないが、このことに注意すべきである。特に、いかなるオペレーティングシステムもハードディスク123に設けられていない。更に、複数のオペレーティングシステムを起動させるために、複数の読取装置128を使うことができる。

最後に、バーチャル層123-5があるので、航空機メーカー分野、航空会社分野に対し、同一プロセッサを同時に使うことができる。これら２つの分野の間の分離は、バーチャルマシンにおいて、対応する各オペレーティングシステムのインスタンス化（instanciation）により実行される。このように、航空機においてプロセッサを１つにすることができる。

ＵＳＢメモリ200のノマド的（nomade）使い方（図４を参照）を考えることができる。その場合、コンピュータ400は、第３実施例と関係したサブシステム120と同じリナックス（登録商標）カーネル（noyau linux）及びバーチャルマシン手段を使うことになる。

次に、前記の実施例の変形例を説明する。好ましくは、サブシステム120にアプリオリにソフトウェアをインストールしないようにした第２実施例について説明する。

この変形例では、プロセッサー121のリムーバブルモジュールに基づいている。これを使うと、航空会社はＣＰＵカード121の廃棄を管理することができる。

従って、航空機メーカーは、航空会社が、ＣＰＵカード（la carte CPU）121を自由に配置するスペースを提供する。航空会社は自分が必要とするＣＰＵの処理能力を選択することができる。従って、航空会社は、廃棄するに当たり、代わりのものを決めることができる。

このように、本発明の方法により得られるソフトウェアの自由度の外に、航空会社は、搭載システム100、110,120のハードウェアの部分的自由度を享受できる。

ＣＰＵカード121は、搭載システム100のセキュリティを高める特性に基づいて機能と安全性を保証するために、アビオニクス標準（例えば、電気的及び/又は熱的カバーを対象とする）に準拠していなければならない。このために、STC（Supplemental Type Certification）保証を行うことができる。

本発明によれば、保証と組立てのための航空機メーカーの関与を必要とせず、航空会社は、自分が望み、航空機で使うアプリケーションを自由に開発することができる。

本発明は、前記の実施例に限定されるものではない。

特に、前記した自動車界との関係において、ナビゲーションアプリケーションGPSを含むリムーバブルメディアが考えられる。

運転者は、自宅のパソコンに、自分の運転コースと別の通過点とを準備する。

自動車において、この運転者は自分のメモリを車載コンピュータ（車載システム）に接続する。これにより、前記した航空機に関する実行モードの内の１つに基づいて、ナビゲーション アプリケーションの実行が可能になる。

本発明によれば、このアプリケーションの実行は車載システムのセキュリティを変更しない。また、そのアプリケーションを持つリブーバブルメディアは、複数の自動車で使用することができる。

Claims (10)

1. 車両の乗員とのインターフェースのアプリケーション（210、210′）を実行する方法であって、次のステップを有する方法。
   ―車両に搭載された実行システム（110,120）を備えるリムーバブルメディア読取装置（128）を使って、実行アプリケーションを有するリムーバブルメディア（200）を読み取るステップ（306、308、604）；
   −前記実行システムにより提供され、前記リムーバブルメディア読取装置に接続される実行手段（111,121）を使って前記アプリケーションを実行するステップ（312,614）。
   但し、前記アプリケーションの実行は、前記リムーバブルメディアの上でしか、その実行に必要なデータの永久記録を必要としない。
2. 前記アプリケーションはポータブルアプリケーションである請求項１に記載された方法。
3. 前記実行システムは、前記読取装置に接続されたメディアに記憶されたポータブルアプリケーションを検出するように構成されたアプリケーション ランチャー（123-3）を有する、請求項２に記載された方法。
   但し、前記ポータブルアプリケーションはアプリケーション ランチャーから出力される。
4. 前記リムーバブルメディアはオペレーティングシステム（212）を有する請求項１乃至３のいずれか１項に記載の方法であって、
   アプリケーションの前記実行に先立って、前記オペレーティングシステムに対する実行システムの起動ステップ（608）を含む方法。
   但し、前記アプリケーションはリムーバブルメディアのオペレーティングシステムの環境において実行される。
5. 前記実行システムは、前記読取装置に接続されるリムーバブルメディアに格納されたオペレーティングシステムに基づいて前記実行を起動するように構成されたＢＩＯＳシステム（121-1）を有する請求項４に記載の方法。
6. 前記実行システムは、起動時に実行されるバーチャルマシン（123-5）を有する請求項４又は５に記載の方法。
   但し、前記オペレーティングシステム（212）は前記バーチャルマシンにおいて実行される。
7. 前記実行システムは、前記バーチャルマシン（123-5）において実行されるように構成されたオペレーティングシステム（123-1）を有する請求項６に記載の方法。
8. 前記実行手段は前記実行手段のリムーバブルモジュールの部分を形成する請求項1乃至７のいずれか１項に記載の方法。
9. 車両（1）の乗員とのインターフェースの情報処理アプリケーションを実行するためのキットであって、次のものを有するキット。
   −前記実行アプリケーション(210,210′)を有するリムーバブルメディア（200）、
   −前記リムーバブルメディア（200）を受入れ、読取るように構成された、リムーバブルメディア読取装置（128）、及び、前記読取手段に接続された、前記リムーバブルメディアに含まれる前記アプリケーションを実行するように構成された実行手段（111、121）を有する車両に搭載された実行システム（110,120）。
   但し、前記リムーバブルメディアは、“前記アプリケーションの実行が、前記リムーバブルメディアの上でしか、その実行に必要なデータの永久記録を必要としない”ように構成されている。
10. 請求項９に記載のキットを有する航空機１。

Images