JP2005524174A - 制限付きアーキテクチャネットワーク内で構成およびダウンロードを行うための方法およびシステム - Google Patents

Abstract

機内娯楽システム（ＩＦＥＳ）などの制限付きアーキテクチャネットワーク内のライン交換ユニット（ＬＲＵ）コンピュータのソフトウェア構成（５０５５）を更新する方法とシステムを提示する。効率のよい並列方式で動作するＬＲＵのそれぞれが、現在のソフトウェアコンポーネントを識別する個別の構成ファイルを独立に作成する（５０１５）。各ＬＲＵは、起動後自動的に、または要求があったときに手動により、それぞれの構成ファイルを構成サーバに送信する。構成サーバは、システム構成データファイルを各ＬＲＵから受信された現在の構成ファイルで更新する。その後、ダウンロードサーバは、所望のソフトウェアコンポーネントのリストをＬＲＵに送信する（５０６５）。各ＬＲＵは、独立にかつ同時に、必要なソフトウェアをダウンロードサーバからダウンロードし、必要なコンポーネントをダウンロードするようダウンロードサーバに要求する（５０７５）。ファイル転送では、ＦＴＰなどの標準プロトコルを使用する。

Description

本発明は、一般に、コンピュータネットワークに関するものであり、より具体的には、航空機またはその他の乗り物のキャビン内で乗客に娯楽、通信、またはその他のサービスを提供するためのシステムなどにおいて制限付アーキテクチャネットワーク内の複数のコンピュータの一様なソフトウェア構成を維持する方法およびシステムに関する。

制限付きアーキテクチャネットワークは、例えば、航空機に搭乗している乗客に娯楽またはその他のサービスを提供するために使用され、一般に、機内娯楽システム（ＩＦＥＳ）と呼ばれる。ＩＦＥＳでは、複数のコンピュータ同士が接続され、さまざまな機能を提供する。これらのコンピュータとしては、例えば、オーディオ／ビデオヘッドエンド機器、エリア分配ボックス、乗客サービスシステム（ＰＳＳ）、および座席電子ボックスなどがある。制限付きアーキテクチャネットワークのモジュール環境では、これらのコンピュータはそれぞれライン交換ユニット（「ＬＲＵ」）と呼ばれる。これらのＬＲＵのうち少なくともいくつかは、個別にまたは座席グループ別に乗客席を割り当てるクライアントデバイスとして動作し、ビデオ娯楽または説明的なプレゼンテーションを行い、オーディオ／ビデオまたはＰＳＳの選択項目を選択するために入力を受け取り、電話または通信機能を提供し、対話型ゲームをプレーし、または他の類似の種類のサービスを提供する。

ＩＦＥＳなどの制限付きアーキテクチャネットワーク内で複数のコンピュータを稼働させる場合、それぞれのコンピュータ上のソフトウェア構成が正確な仕様に従って維持されるようにすることが絶対に必要である。はっきりした数の識別可能なソフトウェアコンポーネントを含む、ソフトウェア構成が、維持されなければならない、つまり、ソフトウェア構成の一部として指定されたソフトウェアコンポーネントはすべて、存在している必要があり、指定されていないソフトウェアコンポーネントは一切存在していてはならない。適切なＩＦＥＳの維持には、制限付きアーキテクチャネットワーク内のさまざまなＬＲＵのソフトウェア構成をチェックし、その後、ソフトウェアをＬＲＵにダウンロードして、利用可能な選択およびサービスを更新するかまたは問題を診断して修復する必要がある。

したがって、制限付きアーキテクチャネットワークは、構造および機能に重大な制約を課している。このようなネットワークでは、通常、ハードウェアおよびさまざまなハードウェアコンポーネント間の接続に利用可能な物理空間のサイズが限られている。利用可能な接続の能力または帯域幅の大きさも制限される場合がある。これらの制約の発生は、制限付きアーキテクチャネットワーク内のソフトウェア構成の絶対的整合性が必要であることともに、連邦航空局（ＦＡＡ）などの外部機関によりそのようなシステムに課されている要件から生じる。例えば、ＦＡＡは、完全にテストされたソフトウェア構成のみ、制限付きアーキテクチャネットワーク内で稼働させることが許されると要求している。ソフトウェア構成がわずかに異なるＬＲＵにより、ネットワーク全体の機能または飛行機のフライトコンピュータが無効にされるという危険性は大きすぎるため１回の食い違いも許されない。したがって、制限付きアーキテクチャネットワーク内でＬＲＵを構成する方法は完全に一貫性があり、再現可能でなければならないが、ほぼ完全な整合性を維持するには、多くの場合、費用のかかる労働集約的方法が必要である。

ＩＦＥＳハードウェアおよびソフトウェアメンテナンスを行うための利用可能時間も、飛行機が積み降ろしのためゲートで待機しているときの次のフライトまでの間の短いメンテナンス時間枠に限定される。限られたメンテナンス時間枠でＩＦＥＳシステム内のそれぞれのコンピュータのソフトウェア構成をセットアップしテストしなければならない。実際、ＩＦＥＳ構成およびダウンロード方法が他の手段によりスケジュールされたメンテナンス期間を超える場合、オペレータは、開始を回避するか、またはＩＦＥＳメンテナンスを中断することになる。そのため、ＩＦＥＳ内のコンピュータを構成し、ソフトウェアをダウンロードする方法の速度と効率を最適化することが望ましい。従来システムでは、ハードウェアの設置時に、例えば、座席電子ボックスの除去または追加時に、ソフトウェアを更新または構成できない、つまりソフトウェア構成を開始できるようにする前にハードウェア構成全体が整っていなければならない。したがって、必要なサービス時間は、ハードウェア構成時間とソフトウェア構成時間を足したものとなっている。航空機が地上にある間にこのようなサービスタスクを実施する機会の時間枠は非常に限られている。

メンテナンス要員は、航空会社にとって高価な間接費である。必要なＩＦＥＳメンテナンス要員数を最小限に抑えるため、また基本的なＩＦＥＳメンテナンス作業を実施するために必要な学習量およびスキルレベルが最小で済むように、再現可能でかつ信頼できるＩＦＥＳ構成およびダウンロード方法を実現するのが望ましい。

ＩＦＥＳ内の複数のコンピュータ上でソフトウェア構成を維持する従来の方法およびシステムは、通常、ネットワークでは実装されず、システム内の他のコンピュータにハード配線された「マスタ」コンピュータを使用することに基づいており、それぞれの「スレーブ」コンピュータをポーリングして、現在の構成を調べ、それぞれのコンピュータ上のソフトウェア構成のリストを作成し、必要なソフトウェアコンポーネントを特定のコンピュータにダウンロードしたり、特定のコンピュータから削除したりする。

ソフトウェアコンポーネントのダウンロード、削除、または上書きは、従来、ソフトウェアコンポーネント毎に順次実行されていた。それぞれのコンピュータは、コンピュータの中にない一連のソフトウェアコンポーネントのそれぞれが一度に１つずつダウンロードされるのを待たなければならない。例えば、従来の構成方法は、オペレータがシステム内の複数のコンピュータにダウンロードする特定のソフトウェアコンポーネントを選択した場合に開始される。従来、マスタコンピュータは、選択されたソフトウェアコンポーネントを順次、第１のスレーブコンピュータにダウンロードし、次に第２のスレーブコンピュータにダウンロードし、さらに第３のスレーブコンピュータにダウンロードし、というように続けて行く。さらに、ＩＦＥＳ構成およびダウンロード方法は、従来、ＩＦＥＳコンピュータ間で完全に逐次動作する、つまり、マスタコンピュータは一度に１つのスレーブコンピュータのみに接続し、そのスレーブコンピュータに一度にソフトウェアコンポーネントを１つだけダウンロードする。

従来の逐次的順次的ダウンロード手法では、コンピュータまたは構成可能なソフトウェアコンポーネントが追加される毎に必要なメンテナンス時間が長くなり、方法が複雑になり、その結果システムのエラーおよび障害が発生する確率が高まるため、ＩＦＥＳシステムの開発が進まなかった。現在、ＩＦＥＳは、一千台近くの個別の構成可能なコンピュータからなると思われ、それぞれソフトウェア構成を完全に維持しなければならない。制限付きアーキテクチャネットワーク内のＬＲＵの個数が倍増する場合このような作業を遂行するのはきわめて困難であるため、並列動作する構成チェックおよびソフトウェアダウンロード方法を実現することが望ましい。より具体的には、マスタコンピュータが一度に複数のスレーブコンピュータに接続するか、または一度に複数のソフトウェアコンポーネントをスレーブコンピュータにダウンロードするシステムおよび方法を実現するのが望ましい。

従来のＩＦＥＳは、ＩＦＥＳネットワーク内での信号伝送用の専用プロトコルを含む、カスタム専用ソフトウェアおよびハードウェア上で動作していた。このような専用システムは複雑で独自の性質を持つため、ＩＦＥＳの問題を診断し、解消することが困難であった。

そのため、制限付きアーキテクチャネットワーク内でマルチコンピュータシステムのソフトウェアを構成する改良された方法およびシステムが必要である。

制限付きアーキテクチャネットワーク内でソフトウェアの構成およびダウンロードに伴う前述の厄介な問題点および難しさは、実質的に本明細書で説明されているソフトウェアを構成しダウンロードするための方法およびシステムにより克服される。

本発明の一実施形態では、ソフトウェアの構成およびダウンロードは、伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）およびファイル転送プロトコル（ＦＴＰ）などの確立しているインターネット転送プロトコルの並列多重アクセス機能を使って実行される。一実施形態では、システム内のＬＲＵは、構成サーバとして動作するように選択され、またシステムを含むＬＲＵは、ダウンロードサーバとして動作するように選択されている。構成サーバとして動作するように選択されたＬＲＵは、ダウンロードサーバとしても動作することができるか、またはサーバとして動作するように選択されたＬＲＵは、２つの異なるＬＲＵであってもよい。本発明のシステムおよび方法では、システム内に存在する複数のＬＲＵが構成サーバ、ダウンロードサーバ、またはその両方として機能させることによりシステム内の自由度を高め、モジュール型とすることを規定している。本発明の他の実施形態では、複数の構成またはダウンロードサーバを実装し、システム内の冗長性、およびシステムの容量内での漸次アクセスに対応することができる。当業者であれば知っているように、本発明にとって、制限付きアーキテクチャネットワーク内の特定の１つのＬＲＵを構成またはダウンロードサーバのいずれかとして動作するように選択することは必要ない。

構成サーバは、システム内の複数のＬＲＵの構成をチェックするために用意される。ダウンロードサーバは、システム内の複数のＬＲＵにソフトウェアをダウンロードできるようにするため用意される。構成およびダウンロード活動は、したがって、構成およびダウンロードサーバが処理可能な同時ＦＴＰセッションの数によってのみ制限される。したがって、システムの完全な構成に要する時間は、主にネットワーク帯域幅および構成およびダウンロードサーバのパフォーマンスにより制限される。

構成およびダウンロードに関して本明細書で述べているステップは、複数の構成可能なＬＲＵを持つＩＦＥＳにおける問題を診断し、修復する方法として有用である。これらのステップはさらに、ＩＦＥＳを定期的に更新し、ＬＲＵの少なくとも１つのグループ間で望ましい一様な構成を維持したり、新しい機能および便利な設備を提供するのに役立つ。

一実施形態では、航空機に搭載されたＩＦＥＳにおける複数の構成可能なＬＲＵの構成をチェックする方法を提示する。ＩＦＥＳは、ＬＲＵとネットワーク経由で通信する少なくとも１つの構成サーバを備える。構成をチェックする方法は、（ａ）ＬＲＵに現在常駐しているソフトウェアコンポーネントを識別するリストを含むＬＲＵ構成ファイルをＬＲＵで生成するステップと、（ｂ）構成ファイルをＬＲＵから、作業ディレクトリ内にＬＲＵ構成ファイルを保持する構成サーバに送信するステップと、（ｃ）作業ディレクトリ内への構成ファイルの着信を検出するステップと、（ｄ）生成ステップにより生成されたＬＲＵ構成ファイルを反映するように現在のＳＣＤＦデータを設定し、構成チェック方法を前回実行したときにＬＲＵにより生成されたＬＲＵ構成ファイルを反映するように前のＳＣＤＦデータを設定することにより現在のＬＲＵ構成と前のＬＲＵ構成を表すデータを含むシステム構成データファイル（ＳＣＤＦ）を更新するステップと、（ｅ）作業ディレクトリからＬＲＵ構成ファイルを削除するステップとを含む。前記のステップは、並列に、チェック対象のそれぞれのＬＲＵについて独立に、実行することが可能である。さらに、一実施形態では、ＳＣＤＦの少なくとも一部は、構成サーバ上のデータベース、またはシステム内のＬＲＵ上のデータベースに格納される。構成ファイルを送信するステップは、ＦＴＰなどの標準ネットワークプロトコルにより実行されるのが好ましい。

一実施形態では、ＬＲＵ構成ファイルを生成するステップは、それぞれのＬＲＵの起動時に自動的に実行される。別法として、ＬＲＵ構成ファイルを生成するステップは、手動で開始することもでき、その場合、この方法はさらに、構成サーバからＬＲＵに開始要求を送信する。

用途によっては、構成変更履歴を記録したイベントログを維持することが望ましい。したがって、一実施形態では、この方法は、さらに、現在のＬＲＵ構成ファイルとＬＲＵからの前の構成ファイルとを比較し、不整合を判別し、不整合をイベントログに記録する。

ＬＲＵの応答が遅い場合、システムではＬＲＵの報告を不定期間自動的に待つことはしないのが望ましい。アクティブなポーリングステップは、オプションにより、問題のある遅延を避けるために供給できる。より具体的には、一実施形態では、この方法はさらに、生成ステップを実行するために構成サーバからＬＲＵに初期命令を送信し、第１の所定の期間の間待機し、その後、第１の所定の期間の後作業ディレクトリをチェックして、ＬＲＵ構成ファイルが構成サーバによって受け取られるかどうかを判別することも行う。さらに、ＬＲＵ構成ファイルが届かなかった場合、この方法はさらに、構成ファイルからＬＲＵへの第２の命令を送信して生成ステップの実行、第２の所定の期間の待機、およびＬＲＵ構成ファイルが届いたかどうかを判別するため行われる作業ディレクトリの再チェックを作動させる。ＬＲＵ構成ファイルが第２の所定の期間の後に受信されていない場合、構成サーバは、ＬＲＵが報告に失敗したことを示す。

チェック方法は、構成ファイルを生成するステップの後、関連するＬＲＵの構成ファイルを格納するステップを含む。これは、必要なソフトウェアコンポーネントからターゲットのＬＲＵにダウンロードする状況に関して追加ステップを促進するのに有用である。

一実施形態では、さらに、ダウンロードサーバからソフトウェアを航空機に搭載されているＩＦＥＳの１つまたは複数の構成可能なＬＲＵコンピュータにダウンロードする方法を提示しており、ダウンロード方法は、１つまたは複数のターゲットＬＲＵにロードすることが望ましいソフトウェアを表す所望のソフトウェアコンポーネントのリストを選択するステップと、ダウンロードサーバからターゲットＬＲＵのそれぞれに所望のソフトウェアコンポーネントのリストを送信するステップと、各ＬＲＵの所望のソフトウェアコンポーネントのリストと各ＬＲＵの現在のソフトウェアコンポーネントのそれぞれのリストとを比較するステップと、所望のソフトウェアコンポーネントのリストおよび現在のソフトウェアコンポーネントのリストの不整合から必要とされるソフトウェアコンポーネントを決定するステップと、各ＬＲＵからダウンロードサーバに命令を送信し、それぞれのＬＲＵに必要なソフトウェアコンポーネントをダウンロードするステップと、必要なファイルをＬＲＵにダウンロードするステップと、ＬＲＵから不要なソフトウェアコンポーネントを削除するステップとを含む。ダウンロード方法では、ダウンロードサーバから各ＬＲＵに所望のソフトウェアコンポーネントのリストを送信するステップを含む、転送ステップのためＦＴＰなどの標準プロトコルを実行するのが好ましい。より具体的には、必要なソフトウェアコンポーネントをダウンロードする命令を各ＬＲＵから送信するステップは、必要なコンポーネントを識別するＦＴＰ「ｇｅｔ」コマンドを実行するステップを含む。

構成の方法およびダウンロードの方法は本発明のシステムとは無関係であるが、重なり合う箇所が２つある。１つは、ダウンロード方法の実行中に、ＬＲＵはダウンロードサーバからソフトウェアコンポーネントの所望のリストを受け取ることである。ソフトウェアコンポーネントの所望のリストは、ＬＲＵを構成する方法のステップで構成ファイルとともに生成される、ソフトウェアコンポーネントの現在のリストと比較される。もう１つは、ダウンロード方法の実行中に、ダウンロードサーバはその構成を報告したＬＲＵの名前または番号のリストを送ることができるということである。この番号は、構成方法のアクティブなポーリングステップにより本発明の実施形態で与えられる。

構成サーバおよびダウンロードサーバが独立していることは、本発明の利点である。一実施形態では、ＬＲＵのうちいくつかは、構成サーバ、ダウンロードサーバ、または両方として動作することが可能である。複数の構成サーバまたはダウンロードサーバを使用することにより、ネットワークトラフィックをより均等に分配し、ソフトウェアコンポーネントを構成する方法またはソフトウェアコンポーネントをダウンロードする方法が帯域幅に関連して低速であるという問題を緩和することができる。

本発明の他の態様は、制限付きアーキテクチャネットワーク内で使用する構成可能なシステムを実現することである。このシステムは、作業ディレクトリを保持するメモリ、データベースを保持する記憶デバイス、データパーサ、およびネットワーク通信デバイスを備える少なくとも１つのサーバを含む。さらに、このシステムは複数の構成可能なＬＲＵを備え、各ＬＲＵはそれぞれのＬＲＵで現在のソフトウェアコンポーネントを表す構成ファイルを生成するように動作可能な構成ファイルジェネレータ、および構成ファイルをサーバに送信するように動作可能なネットワーク通信デバイスを備える。このシステムはさらに、ＬＲＵとサーバとの間の並列通信を処理するためのネットワークバックボーンを含む。例えば、ネットワークバックボーンは、イーサネットネットワークとすることができる。サーバは、作業ディレクトリ内でそれぞれのＬＲＵから構成ファイルを受け取り、そこで、データパーサは、現在の構成を表すシステム構成データファイルのフィールドに構成ファイルを書き込み、現在のフィールドにすでに格納されているデータを前の構成を表すフィールドに移動することによりデータベースに格納されているＳＣＤＦを更新するように動作可能である。ＬＲＵは、ＦＴＰを使用して構成データファイルをサーバに送信するのが好ましい。

一実施形態では、システムは、ネットワークを介して所望のソフトウェアをダウンロードすることによりＬＲＵソフトウェアコンポーネントを更新する機能を備える。したがって、各ＬＲＵはさらに、構成ファイルを構成サーバから受け取った所望のコンポーネントのリストと比較して必要なコンポーネントを判別するコンパレータを備え、ＬＲＵのネットワーク通信デバイスはさらに、サーバから必要なコンポーネントをダウンロードするため構成ファイルを要求側に送信するように動作可能である。

一実施形態では、システムの手動起動をしやすくするため、システムは。ＬＲＵに構成ファイルを生成させるための開始要求を送信するように動作可能な管理端末を備える。別法として、ＬＲＵは、自動的に開始するように動作可能である。より具体的には、ＬＲＵの構成ファイルジェネレータは、ＬＲＵの起動後、構成ファイルを自動生成するように動作可能である。

本発明の具体的な利点として、ファイルの送信は、制限付きアーキテクチャネットワークの外部で確立され、テストされている、ＦＴＰなどの標準プロトコルで実行されるという点が挙げられる。標準プロトコルを使用することで、そのような環境において専有プロトコルを使用することに内在する厄介な問題および困難を回避できる。ＦＴＰクライアントソフトウェアおよびＦＴＰサーバソフトウェアなどの標準プロトコルソフトウェアは、一般的に、市販のオペレーティングシステムソフトウェアに付属しており、そうでないとしても、制限付きアーキテクチャネットワークで通常使用されるプラットフォームに合わせて作成、コンパイルすることは簡単である。有利には、本発明のシステムおよび方法では、ソフトウェア構成の維持に使用するために専用ソフトウェアプロトコルを作成または使用する必要がない。さらに、本発明では、すべてのコンピュータを構成するために個々のソフトウェアコンポーネントを組み合わせる必要もない。

本発明の著しい利点として、制限付きアーキテクチャネットワーク内のコンピュータのソフトウェア構成は、ハードウェア構成が完全でないとしても更新できるという点が挙げられる。複数のライン交換ユニット（ＬＲＵ）を備えるシステムでは、構成チェック方法またはダウンロード方法を１つまたは複数の選択されたＬＲＵまたはすべてのＬＲＵ上で実行することができる。さらに、一実施形態では、ソフトウェアのダウンロードを個別化して、それぞれのＬＲＵで必要なソフトウェアコンポーネントのみを備えるようにしている。したがって、１つのＬＲＵでソフトウェア構成を完了させるためにシステム全体を運転する必要はない。このため、メンテナンス時間は限定され、運用効率が高まる。

本発明の上記および他の目的、利点、および特徴は、以下の詳細な説明および付属の図面から明白であろう。
本発明はさまざまな修正形態および変更形態を許すが、いくつかの好ましい実施形態について、図面の例を使用して示し、本明細書で詳しく説明する。しかし、本明細書の説明は、説明されている特定の形態に本発明を制限することを意図しておらず、それどころか、この説明は、添付の請求項で定義されている本発明の精神と範囲内に入るすべての修正、代替え、および均等物を対象とすることを意図していることは理解されるであろう。

図１は、ＩＦＥＳなどの制限付きアーキテクチャネットワークに好適なネットワークまたはシステム１０００を例示している。図１のブロック図は、電子命令を実行し、ソフトウェアを実行またはデータを格納することができるコンピュータの一般的なハードウェアレイアウトを示している。本発明の一実施形態によれば、システム１０００は、全体として、管理端末１１００、少なくとも１つのサーバ１２００、および複数の構成可能なコンピュータまたは、システム１０００内のＬＲＵ １３００を表すものとして説明のため使用される特定のＬＲＵ １３００（「ＬＲＵｎ」とラベル付けされている）を含むＬＲＵ １３００を備える。管理端末１１００は、ユーザから入力データを受け取り、出力データをユーザに送るように動作可能である。例えば、管理端末１１００は、グラフィカルユーザーインターフェース（ＧＵＩ）を用意できるディスプレイを備えるのが好ましい。管理端末１１００は、アプリケーション特有のデバイスまたは、ラップトップコンピュータなどのＰＣとすることができる。さらに、管理端末１１００は、恒久的設置備品として、またはシステム１０００の開発、管理、またはトラブルシューティングのため必要に応じて設置される携帯型デバイスとして構築することができる。接続状態では、管理端末１１００は、構成サーバ１２００のそれぞれと通信する。

図１は、さらに、複数のＬＲＵ １３００が含まれている。構成可能なＬＲＵ １３００は、ソフトウェア構成の制御に信頼性および再現性があるコンピュータコンポーネントまたはデバイスを表す。制限付きアーキテクチャネットワークでは、一般に、構成可能なＬＲＵ １３００は、ソフトウェア問題が発生した場合に現場で診断し修復可能ででなければならないコンポーネントである。航空機、列車、バス、または船舶では、構成可能なＬＲＵ １３００は、例えば、乗客席環境と統合される乗客サービスまたは娯楽デバイスとすることができる。他の環境では、構成可能なＬＲＵ １３００は、データを測定し記録するためのデバイスとすることができる。本発明のシステムおよび方法は、全体として、複数のＬＲＵ １３００のあるシステム１０００で有用である。システムには千台を超えるＬＲＵ １３００があり得るが、図１では３つだけラベルが付いている。

システム１０００は、一般的に、１０ベース・テイー、１００ベース・テイー、またはギガビット イーサネットを含むイーサネットなどの適当なネットワーク規格、またはトークンリング規格もしくは無線規格などのイーサネット以外の規格に従って動作するＬＡＮである。そのような規格を使用することは、一般に、当業者には知られている。

図２−ａ〜２−ｃは、システム１０００を備えるハードウェア例（図２−ａ〜２−ｂ）および構成サーバ、ダウンロードサーバ、またはその両方のいずれかとして使用することも可能なデジタルサーバユニットの例（図２−ｃ）を詳細に示している。

システム１０００は、一般に、ネットワークデータバックボーン１５００および娯楽放送またはＲＦバックボーン１６００を介して通信する複数のコンピュータコンポーネントを含むローカルエリアネットワーク（ＬＡＮ）である。ネットワークデータバックボーン１５００では、１００ベース・テイー イーサネットを使用するのが好ましく、放送ＲＦバックボーン１６００は、ビデオおよびオーディオ信号を含む高帯域ＲＦ伝送が可能であるのが好ましい。

一般に、システム１０００内のＬＲＵ １３００は、キャビン管理端末１１００、オーディオ／ビデオコントローラ２１２０、デジタルサーバユニット２５００、１つまたは複数のエリア分配ボックス２１５０、およびデータバックボーン１５００を介して通信する複数のタッピングユニット２１３０を備える。オーディオ／ビデオコントローラ２１２０、デジタルサーバユニット２５００、およびその他の補助デバイスは、ＲＦ放送バックボーン１６００を介してエリア分配ボックス２１５０またはタッピングユニット２１３０にオーディオおよびビデオ信号を供給することができる。エリア分配ボックス２１５０は、信号を関連するエリア内の１つまたは複数の座席電子ボックス（図２−ｂの２１６０）に受け渡す。別法として、タッピングユニット２１３０は、放送バックボーン１６００から娯楽信号を受信し、その信号を１つまたは複数の関連するオーバーヘッドディスプレイユニット２１４０に送信する。

「キャビン管理端末」
一実施形態では、図２−ａのキャビン管理端末１１００は、飛行機乗務員用のＩＦＥシステムへの中央ユーザインターフェースである。ユーザは、キャビン管理端末１１００を通じて、ＩＦＥシステム１０００内の他のハードウェアコンポーネントのソフトウェア構成を指定することができる。キャビン管理端末１１００を使用すると、さらに、ユーザはオーディオ／ビデオコンテンツまたは機内の旅客へのインターネットの利用を有効または無効にすることができる。一実施形態では、キャビン管理端末１１００は、１００ベース・テイー イーサネットデータネットワーク（これ以降「イーサネット」と呼ぶ）１５００に接続される。ローカルエリアネットワーク（ＬＡＮ）スイッチ２００では、イーサネットネットワークに接続されている各ＬＲＵノードを単一セグメントとして取り扱うことで、イーサネットネットワークを通じて高速データ転送を行うことができる。他の実施形態では、複数のＬＡＮスイッチ２００を使用することも可能である。本発明は、イーサネット １００ベース・テイー、１０ベース２、１０ベース５、１０００ベース・テイー、１０００ベースＸ、またはギガビットネットワークなどの適切なネットワーク通信規格に基づくように動作可能である。さらに他の実施形態では、ネットワークは、これらの代わりに、非同期転送モード（ＡＴＭ）、トークンリング、またはその他の形式のネットワークとすることも可能である。

本発明の一態様では、キャビン管理端末１１００は、図１および３に関して説明されているような構成チェック方法および図５〜９に関して説明されているダウンロード方法で使用することができる。

「エリア分配ボックス」
図２−ａを参照すると、エリア分配ボックス２１５０は、一般に、ローカルの座席レベルルーティングデバイスである。エリア分配ボックス２１５０は、ネットワークデータバックボーン１５００およびＲＦバックボーン１６００上の信号を座席電子ボックス２１６０（図２−ｂ）のグループへの分配を制御する。エリア分配ボックス２１５０は、座席電子ボックス２１６０およびオプションによりタッピングユニット２１３０の割り当てられたネットワークアドレスを保持する。エリア分配ボックス２１５０は、さらに、内蔵テスト機器（ＢＩＴＥ）機能も備えるのが好ましい。さらに、エリア分配ボックス２１５０は、例えば、頭上の読書灯および乗務員呼出灯を含む、対応するゾーン乗客サービスシステム２１５５を制御し、それと通信する。

オプションにより、エリア分配ボックス２１５０はさらに、オーディオ／ビデオコントローラ２１２０に関して以下で述べるのと同様にしてタッピングユニット２１３０を制御する動作をする。

一実施形態では、エリア分配ボックス２１５０は、構成サーバ、ダウンロードサーバ、またはその両方として動作することが可能である。したがって、エリア分配ボックス２１５０は、図１に示されているようにサーバ１２００とすることができ、図３および５に関してさらに詳しく説明されるように、構成チェックまたはソフトウェアダウンロード機能のいずれかを取り扱う。しかし、本発明のオペレーションの他の態様では、エリア分配ボックス２１５０は、他のデバイスから要求が送られた場合に構成チェックに応答することができることを理解されたい。そのような実施形態では、エリア分配ボックスは、図３の構成チェック方法に関して、または図５のダウンロード方法５０００に関して、後述のように、構成可能なターゲットＬＲＵ１３００として動作する。

エリア分配ボックス２１５０のハードウェアは、フラッシュメモリなどのメモリ、ネットワークインターフェースカード、ＲＳ４８５インターフェース、および無線周波数増幅器を備える１つまたは複数のマイクロプロセッサを含む。さらに、一実施形態では、エリア分配ボックス２１５０は、ＲＦ分配の利得制御用の適切な利得制御回路を備える。一実施形態では、エリア分配ボックス２１５０上で実行または格納されるソフトウェアは、オペレーティングシステム（例えば、Ｌｉｎｕｘ）、Ｗｅｂサーバ（例えば、Ａｐａｃｈｅ）、ＴＣＰ／ＩＰ、ＦＴＰクライアント、ＦＴＰサーバ、およびタッピングユニットおよびＣＳＳとインターフェースするためのポートまたはコネクタなどの複数のソフトウェアコンポーネントを備えることも可能である。適切なインターフェースとしては、ＲＳ４８５インターフェースなどのシリアルポートまたはＵＳＢがある。

「オーディオ・ビデオコントローラ」
オーディオ／ビデオコントローラ２１２０は、一般に、娯楽ヘッドエンドコントローラとして動作し、ＩＦＥシステム内のさまざまな機能を実行することができる。オーディオ／ビデオコントローラ２１２０は、カメラ、ビデオプレーヤ、オーディオプレーヤなどの複数の入力デバイスと通信する。オーディオ／ビデオコントローラ２１２０は、データバックボーン１５００および放送バックボーン１６００の両方と通信している。例えば、オーディオ／ビデオコントローラ２１２０の機能には、オーディオおよびビデオコンテンツの配信、タッピングユニット２１３０およびオーバーヘッドディスプレイユニット２１４０の制御、およびビデオテープ再生装置２０８０およびオーディオ再生装置２０９０などのさまざまな入力に対する周波数変調機能が含まれる。

さらに、一実施形態では、オーディオ／ビデオコントローラ２１２０はさらに、乗客サービスシステム２０６０（ＰＳＳ）のヘッドエンドコントローラとしても動作し、例えば、乗客に座席ベルトを締めるよう指示したりたばこを吸わないよう指示する放声装置システムおよび警告灯などが含まれる。したがって、オーディオ／ビデオコントローラ２１２０は、コックピットエリアマイク２０７０などのＰＳＳ関係入力に接続され、これにより、乗務員へのアナウンスのためＲＦバックボーン１６００を介して他の信号を中断することができる。ＰＳＳ制御機能をオーディオ／ビデオコントローラ２１２０に組み込むことにより、これらのＰＳＳ機能を制御するために別のＬＲＵ １３００を取り付ける必要がなくなる。

さらに、オーディオ／ビデオコントローラ２１２０により、乗客フライト情報システム（ＰＦＩＳ）２１００は、航空機識別、現在時刻、フライトモード、フライトナンバー、緯度、経度、および対気速度などの、非ＩＦＥシステム機器から取得されるデータを含む、システムデータのアクセスポイントとして動作する。一実施形態では、外部通信を行いやすくするため、オーディオ／ビデオコントローラ２１２０はさらに、１つまたは複数の衛星リンク２０２０を通じて地上または衛星通信局と通信することができるキャビン通信ユニット２０５０と通信する。

本発明の一態様では、オーディオ／ビデオコントローラ２１２０は、以下の図１および図３に関して説明されている構成可能なＬＲＵ １３００として動作することが可能である。オーディオ／ビデオコントローラ２１２０は、構成ファイルを生成し、ＦＴＰを介して構成ファイルを送信し、更新されたソフトウェアコンポーネントのダウンロードを受け取ることにより構成要求に応答することができる。他の実施形態では、オーディオ／ビデオコントローラ２１２０は、構成サーバ、ダウンロードサーバ、またはその両方として動作することが可能である。

オーディオ／ビデオコントローラ２１２０のハードウェアは、マイクロプロセッサ、イーサネットスイッチ、電話機インターフェースコンポーネント、Ａｅｒｏｎａｕｔｉｃａｌ Ｒａｄｉｏ，Ｉｎｃ．（ＡＲＩＮＣ）インターフェース、ＲＳ４８５インターフェース、および機内放送およびオーディオ／ビデオコンテンツ配信用のオーディオ変調装置を含む。オーディオ／ビデオコントローラ２１２０は、例えば、Ｌｉｎｕｘなどのオペレーティングシステム、ＡｐａｃｈｅなどのＷｅｂサーバ、ＴＣＰ／ＩＰ、ＦＴＰクライアント、ＦＴＰサーバ、タッピングユニットおよびＣＳＳとのＲＳ４８５インターフェース、およびＬＡＰＤ通信をはじめとするさまざまなソフトウェアコンポーネントを備える。

「デジタルサーバユニット」
デジタルサーバユニット２５００は、例えばハードディスクドライブに格納されているデジタルコンテンツから派生したアナログおよびビデオ出力を供給し、適切に定められた外部インターフェースを使用しモジュール方式で構成されている。ラックマウントは、ＡＲＩＮＣ ６００で規定している電気的および物理的インターフェースを備える。デジタルサーバユニット２５００は、このコネクタで、給電され、外部制御インターフェースに接続し、２つのステレオオーディオ出力が各ビデオ出力に関連付けられている６つのベースバンドビデオ出力、および１２個のステレオ出力、および３つのＲＦ入力を６つの変調ビデオ信号（１２個のステレオビデオ・オーディオを含む）と組み合わせた１つのＲＦ出力、および１２個のステレオ変調オーディオ出力を供給する。また、ＳＣＳＩ ＩＩインターフェースを介して記憶装置サブシステムの診断アクセスおよび拡張用に補助前面取付コネクタも用意されている。図２−ｃは、デジタルサーバユニット２５００の一実施形態のブロック図である。

デジタルサーバユニット２５００は、モジュール構造であり、ＡＲＩＮＣコネクタを持つＩ／Ｏアセンブリ２６０５およびモジュール回路カードにインターフェースするバックプレーンを備える。これらの回路カードは、制御およびインターフェース機能、オーディオまたはビデオ復号化、アナログ・バッファリング、ＲＦ変調、およびオーディオまたはビデオ信号を多重化して１つの組み合わせ信号を出力する機能を備える。シャシには、モジュール回路カード用の取付および冷却装備だけでなく、ディスクドライブ２５２０の取付手段も用意されている。ディスクドライブ２５２０の取付手段は、物理的動作パラメータ、例えば、航空機で使用するディスクドライブ２５２０の衝撃および振動パラメータを拡大適用するように設計されている。

図２−ｃに示されているコントローラ２５１０は、中央演算処理装置（ＣＰＵ）を含み、これは、好ましい実施形態では、８２６０ ＰｏｗｅｒＰＣである。ＣＰＵは、ディスクドライブ２５２０に格納されているデジタルコンテンツにアクセスし、１００ベース・テイー イーサネットインターフェースを介してコンテンツをビデオまたはオーディオクライアントにストリーミング出力するが、そこで、デジタルデータは復号化されて、アナログオーディオおよび／またはビデオ信号に変換され、さらにバッファリングされ、ネットワーク１０００内の他のＬＲＵ １３００用のＡＲＩＮＣコネクタから差分ベースバンドビデオおよびオーディオ出力として利用可能にされる。信号は、さらに、ＲＦ信号に変調され、３つのＲＦ入力信号と組み合わされて、放送ＲＦオーディオ／ビデオバックボーン１５００を介して配信される。

図２−ｃに示されているＩ／Ｏアセンブリは、プライマリードメイン全二重１００ベース・テイー イーサネットポート、４つのセカンダリドメイン全二重１００ベース・テイー イーサネットポート、２つのＲＳ−２３２通信ポート、２つのマスタまたはスレーブ対応ＡＲＩＮＣ ４８５通信ポート、１２個のマスタ対応ＡＲＩＮＣ ４８５通信ポート、１つのＣＥＰＴ Ｅ−１デジタル電話中継回線、差動２０Ω、０ｄＢＭオーディオ出力および６００Ω、０ｄＢＭオーディオ入力を備える１つの４線モデム、１７個のＡＲＩＮＣ ７２０準拠キーライン入力、１１個のＡＲＩＮＣ ７２０準拠キーライン出力、１つのスタンバイ入力キーライン、１つの２０Ω、０ｄＢＭ補助オーディオ出力、１つの２０Ω、０ｄＢＭ ＰＲＡＭオーディオ出力、１つの２０Ω、０ｄＢＭ ＢＧＭオーディオ出力、ユニットアドレスおよびＲＦ周波数ブロックを識別する９個のディスクリート入力、６つの差動１００Ω、１Ｖｐｐビデオ出力、１２個の差動２０Ω、０ｄＢＭステレオオーディオ／ビデオ出力、１２個の差動２０Ω、０ｄＢＭステレオオーディオ出力、１つの組み合わせた受動結合ＲＦ入力、２つの能動的増幅および組み合わせＲＦ入力、３つのＲＦ入力とすべての内部ＲＦ変調オーディオ／ビデオ信号とを組み合わせた１つのＲＦ出力、および単相１１５ＶＡＣ、４００Ｈｚ電力入力を含む。

デジタルサーバユニット２５００の前面パネルは、さらに、１つのセカンダリドメイン全二重１００ベース・テイー イーサネットポート、１つのＲＳ−２３２通信ポート、ＤＣ電源電圧、１つの監視用プロセッサリセット、１つの監視用プロセッサアテンション入力、ＡＣ ＯＫ、ＤＣ ＯＫ、ＢＩＴＥ ＯＫ、ＳＣＳＩ活動用ＬＥＤステータスインジケータ、１つのＳＣＳＩ拡張ポート、１つのイーサネットスイッチステータスインターフェース、および１つのテストモードキーライン入力を含む。ネットワーク１０００内のデジタルサーバユニット２５００の接続はかなり異なる場合がある。図２−ａおよび２−ｂに一実施形態が示されている。

デジタルサーバユニット２５００は、ビデオテープ再生装置２０８０またはオーディオテープ再生装置２０９０と同様の仕方でビデオ娯楽機能を提供する。ビデオコンテンツは、ビデオテープの代わりに、Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔ Ｇｒｏｕｐ （ＭＰＥＧ）形式（ＭＰＥＧ−１またはＭＰＥＧ−２）に準拠する圧縮形式で格納される。ビデオデータは、ビデオを含む多重化形式で格納され、１から１６のオーディオトラックはＭＰＥＧ−２トランスポートストリーム形式で格納される。オーディオコンテンツは、オーディオテープを使わずに、ＭＰＥＧ−３（ＭＰ３）形式に準拠する圧縮形式でハードディスク２５２０に格納される。高性能ディスクドライブ２５２０は、コントローラ２５１０上のＣＰＵによりＷｉｄｅおよびＦａｓｔ ＳＣＳＩインターフェースを介してアクセスされる。その後、デジタルコンテンツはＴＣＰ／ＩＰを介して、デジタルサーバユニット２５００内の回路カード上のクライアントプラットフォーム２５５０、２５６０、２５７０、および２５８０にストリーム出力される。

ビデオクライアント（回路カード１つにつき２つ）およびオーディオクライアント（カード１つにつき４つ）の２種類のクライアントが実装される。それぞれのビデオクライアントは、ビデオと多重化されている最大１６個までの言語トラックから選択された２つの関連する同時ステレオ言語トラックとともに１つのビデオ出力を発生することができる。各オーディオクライアントは、３つもしくは４つのオーディオ出力を生成することができる。デジタルサーバユニット２５００は、全部で６つのビデオクライアントと６つの関連するデュアルステレオビデオおよびオーディオ／ビデオ出力に対し３つのビデオクライアントカードを備える。オーディオ出力のうち１２個は、その性質上汎用であるが、１３番目と１４番目の出力は、ＰＲＡＭおよびＢＧＭ機能を実装するために使用される。これら２つの航空機インターフェースは一般にモノラルなので、１３番目と１４番目のオーディオ出力のＭＰ３プログラミングは、モノラルＭＰ３として符号化されて格納され、ステレオデコーダの左チャネルのみ、適切な航空機放声システム入力に接続される。

ビデオクライアントは、デジタルＭＰＥＧオーディオ／ビデオデコーダだけでなく、汎用ＰＣ互換プラットフォームでもあり、放送バックボーン１６００を通じて放送ビデオチャネルとして表示されるカスタマイズされた機能を実装することができる。このような代表的なビデオクライアントの使用例は、乗客フライト情報システム（ＰＦＩＳ）２１００の実装である。

本発明の一実施形態では、コントローラ２５１０は、１６６ＭＨｚで動作するＰｏｗｅｒＰＣプロセッサ、４ＭＢ（メガバイト）のブート用フラッシュＲＯＭメモリ、６４ＭＢのアプリケーション用フラッシュＲＯＭメモリ、６４ＭＢのディスクオンチップフラッシュＲＯＭメモリ、２５６ＭＢのＲＡＭメモリ、２ｋＢの不揮発性スタティックＲＡＭ、スーパーキャパシタにより電力を供給されるクロックカレンダ、高性能ＳＣＳＩコントローラ、２つの９ポート１００ベース・テイー イーサネットスイッチ、ボイスオーバーＩＰ、エコーキャンセル、ＤＴＭＦトーン発生および復号化、および従来のモデムサポートを提供するために使用される３２０ｋＢの内部メモリおよびそれぞれ１ＭＢの外部フラッシュおよびＲＡＭメモリを備え３２０ＭＩＰＳで動作するデジタルシグナルプロセッサ（ＤＳＰ）サブシステム、および下位ウェッジロックおよびＣＰＵにさらに２つの感知点がある、上位ウェッジロックに配置されている１つの温度モニタを備える。

本発明の好ましい実施形態では、デジタルサーバユニット２５００は、構成サーバ、ダウンロードサーバ、またはその両方として動作することが可能である。デジタルサーバユニット２５００は、前述のように、本発明の構成方法とダウンロード方法の両方を実行するのに必要なコンピューティング資源を備える。本発明の一実施形態では、ネットワーク１０００内に複数のデジタルサーバユニット２５００がインストールされている可能性があり、大容量のデータをネットワーク１０００内の他のＬＲＵ １３００に通信することができる。

本発明の一態様では、図３および５について後述する方法に関して、デジタルサーバユニット２５００は、構成チェック要求に応答し、またソフトウェアダウンロードを受け取ることができる。そのような実施形態では、デジタルサーバユニット２５００は、図３に関して後述する構成チェック方法３０００、および図５に関して後述するダウンロード方法５０００におけるターゲットＬＲＵ １３００である。

「衛星リンク」
航空機の外部と通信するために、ＩＦＥシステム１０００は、オーディオ、ビデオ、音声、およびデータコンテンツの追加ソースをＩＦＥシステムに供給する、図２−ａのオプションの衛星リンク２０２０を含む。マルチチャネル受信器モジュール２０３０に関して、これは、複数のビデオチャネルをＩＦＥシステムに提供する。一実施形態では、マルチチャネル受信器モジュール２０３０は、ＩＦＥシステム内の他のＬＲＵ １３００に接続されるＲＦバックボーン１６００に接続される。衛星リンク２０２０では、ネットワーク記憶装置２０４０と組み合わせたインターネットアクセスも実現し、帯域幅を集中的に占有するグラフィックスや動画により衛星リンク帯域幅が消費されない場合、飛行機が地上にある間に、複数の人気のあるＷｅｂページをネットワーク記憶装置２０４０にダウンロードしておく。衛星リンク２０２０は、さらに、キャビン通信ユニット２０５０と連携して、Ｎｏｒｔｈ Ａｍｅｒｉｃａｎ Ｔｅｌｅｐｈｏｎｅ Ｓｙｓｔｅｍ（ＮＡＴＳ）などの地上電話網へのアクセスも提供することができる。

「タッピングユニット」
一般に、タッピングユニット２１３０は、放送信号をタップし、その信号の選択可能な部分または所定の部分を１つまたは複数のディスプレイユニットに配信するためのアドレス指定可能なデバイスである。したがって、タッピングユニット２１３０は、１人の乗客または乗客のグループが見られるように取り付けられている１つまたは複数のオーバーヘッドディスプレイユニット２１４０に直結される。オーバーヘッドディスプレイユニット２１４０は、例えば、頭上の隔壁または天井、視聴者の前の座席の背、調整可能な取付構造物、または適切な位置に取り付けることができる。一実施形態では、ＩＦＥシステム１０００は、複数のタッピングユニット２１３０を備える。タッピングユニットは、ディスプレイユニットのオン／オフを行う機能を持ち、またオーディオまたはビデオのチャネル選択のためチューナの同調も行う。一実施形態では、タッピングユニット２１３０は、オーディオ／ビデオＲＦバックボーン１６００で無線ＲＦ信号のステータスを報告するためにも使用される。

本発明の一態様では、図３および５について後述する方法に関して、タッピングユニット２１３０は、構成チェック要求に応答し、またソフトウェアダウンロードを受け取ることができる。図１のＬＲＵ １３００は、タッピングユニット２１３０であってよい。

「座席電子ボックス」
図２−ｂは、図２−ａのブロック図の続きであり、複数の座席電子ボックス２１６０がネットワークデータバックボーン１５００を通じてエリア分配ボックス２１５０に接続される。座席電子ボックス２１６０はそれぞれ、個々の乗客制御ユニット２２２０とのインターフェース、パーソナルデジタルゲートウェイ２２３０、ビデオディスプレイユニット２１７０、またはスマートビデオディスプレイユニット２１７５を備え、航空機内のそれぞれの乗客から利用できる。他の実施形態では（図２−ｂに示されていない）、複数のビデオディスプレイユニット２１７０または乗客制御ユニット２２２０はそれぞれの座席電子ボックス２１６０に接続されている。座席電子ボックス２１６０は、さらに、ビデオディスプレイユニット２１７０への電源、オーディオおよびビデオチャネル選択、および音量も制御する。１つまたは複数のユニバーサルシリアルバス２１８０またはオーディオジャック２２００も、座席電子ボックス２１６０に接続され、乗客はラップトップコンピュータ２１９０またはヘッドホン２２１０をネットワーク１０００に接続することができる。一実施形態では、座席電子ボックス２１６０上のハードウェアは、マイクロプロセッサ、ＲＦタップ、ＲＦ増幅器、ＲＦレベルへ検出、ＲＦ利得制御、およびＲＦスプリッタ、ＦＭチューナ、およびボイスオーバーＩＰ処理用のデジタルシグナルプロセッサ（ＤＳＰ）を備える。

ネットワーク１０００のハードウェアアーキテクチャの前記の説明を鑑みて、ＬＲＵ構成をチェックし、保守し、かつ修復または更新するのに使用される構成チェック方法およびダウンロード方法をシステム１０００で実行することができるステップについて説明することにする。

「構成チェック方法」
本発明の一実施形態による構成チェック方法３０００のステップは、図３−ａ〜ｄに例示されている。一般に、構成チェック方法３０００は、図２−ａ〜ｃのシステム１０００により実行され、各ＬＲＵ １３００のソフトウェア構成またはハードウェア構成を判別する。本明細書で参照する「ＬＲＵｎ」は、オーディオ／ビデオコントローラ２１２０、エリア分配ボックス２１５０、座席電子ボックス２１６０などのターゲットＬＲＵコンピュータ１３００のいずれか１つまたは本明細書で構成可能なＬＲＵ １３００であると述べられているコンポーネントのどれかとしてよい。構成チェック方法３０００を実行することにより特定の用途に対し必要に応じてさまざまな結果を出力することができるが、構成チェック方法３０００では、後述のように、システム構成データファイル（ＳＣＤＦ）を作成し、チェックされたそれぞれのＬＲＵ １３００の構成およびオプションにより、前のまたは所望の構成に関する各ＬＲＵ １３００の構成の不整合または変更を記述しているイベントログを表示する。

方法３０００は、手動または自動のいずれかで起動できる。例えば、ステップ３０１０では、方法３０００は、ユーザが管理端末１１００（図１、２−ａ）から、または別法として、システム１０００内のラップトップ２１９０などの他のデバイスから、開始コマンドを入力したときに、手動で開始される。方法３０００は、さらに、ステップ３０４０に示されているように、ＬＲＵｎ １３００の起動後、例えば、ＬＲＵｎのスイッチで作動させた後、ＬＲＵｎを電源に接続した後、ＬＲＵｎをネットワークに接続した後、またはＬＲＵｎあるいはシステム１０００の他のコンポーネントを再起動した後に、自動的に開始するようにもできる。いずれの場合も、構成サーバは、構成チェックを開始するＵＲＬのホストとなる。図２−ａを参照すると、構成サーバは、適切なソフトウェアを備え、データバックボーン１５００と通信するコンポーネントであればどのようなものでもよい。構成サーバは、デジタルサーバユニット２５００またはエリア分配ボックス２１５０であるのが好ましい。

さらに、図１に示されているサーバ１２００は、構成サーバまたはダウンロードサーバのいずれでもよい。図１に示されているように、システムのレイアウトは、システム１０００内のＬＲＵ １３００上でソフトウェアコンポーネントを構成する方法およびソフトウェアコンポーネントをダウンロードする方法の両方に適用される。したがって、サーバ１２００は、構成サーバまたはダウンロードサーバのいずれかを表すものと理解すべきであり、サーバ１２００は、構成およびダウンロードの方法に関して本明細書で説明しているように、逐次または並列のいずれかで両方の機能を実行することができる。本発明の他の実施形態では（図１には示されていない）、複数のサーバ１２００があり得る。このような実施形態では、システム内のＬＲＵ １３００は、ネットワーク１５００を通じて複数のサーバ１２００と通信することができるであろう。

ユーザが手動で方法３０００を開始するような場合、ユーザは前の構成チェックの結果を検討したがる可能性があり、したがって、ステップ３０１５で前の構成条件を検討することを選択する機会を得られる。前の結果を検討する場合、ステップ３０２０で、前の構成チェックの結果であったＳＣＤＦを取得し、ステップ３０２５でその結果を表示する。ステップ３０２０で前の結果を構成サーバが取得できない場合、ステップ３０２５で適切なエラーメッセージが表示されるはずである。

ＳＣＤＦが構成サーバに格納される一実施形態においてＳＣＤＦを取得して表示するステップ３０２０では、管理端末１１００において、構成サーバとのＦＴＰセッションを開き、ＦＴＰ「ｇｅｔ」コマンドを実行する。応答として、構成サーバの記憶装置からＳＣＤＦが読み出され、管理端末１１００に送り返され、モニタを通じて表示されるか、またはプリンタなどの周辺デバイスを通じてステップ３０２５で出力される。ＳＣＤＦが管理端末に格納される一実施形態では、ＳＣＤＦは管理端末の記憶デバイスから読み出すことも可能である。

ステップ３０２０および３０２５は、過去の構成情報に素早くアクセスするのに使用される。過去の構成情報は、ＬＲＵ １３００構成が頻繁に変更されないシステムで有用と思われる。ユーザが、冗長な情報を返す可能性のあるチェック方法を実行する前、または実行する代わりに、旧い構成データを参照できるようにすることで、時間が節約される。

ユーザがステップ３０１０でチェック方法３０００をリアルタイムで開始した場合、いくつかのトラブルシューティングまたは更新アプリケーションは、ＬＲＵ １３００の全部ではなく一部の現在の構成をチェックすることが望ましい状況を示すことができる。したがって、ステップ３０３０では、チェックする１つまたは複数のＬＲＵ １３００をユーザ側で選択する機会を得られる。本発明の一実施形態では、管理端末に、例えば、システム内の個別ユニット、ユニットのグループ、構成可能なユニットのすべてをはじめとする、さまざまなＬＲＵ選択項目のメニューが表示される。そこで、ステップ３０３５で構成サーバは構成要求それぞれの選択されたＬＲＵｎ １３００に送信する。説明のため、システム１０００のユーザはステップ３０３０でＬＲＵｎ １３００のみを選択したと仮定する。

本発明の一実施形態では、ステップ３０３５で選択されたＬＲＵに送信される構成要求は、選択されたＬＲＵ １３００の宛先のそれぞれに適切にアドレス指定されているＴＣＰまたはＵＤＰなどの標準プロトコルを使用する、イーサネットブロードキャスト（例えば、単一ターゲットＬＲＵである場合）またはマルチキャスト（例えば、複数のターゲットＬＲＵがある場合）の形式であるのが好ましい。本発明の好ましい実施形態では、システム１０００内で送信されるメッセージは短いためＵＤＰが使用され、エラーが検出された場合に再送することができる。ＴＣＰとともに使用した場合に使用可能な誤り訂正はこのような理由から必要でない。構成サーバは、存在するＬＲＵ １３００、対応するＩＰアドレス、および割り当てられた座席番号を識別する構成マップを保持する。構成要求はそれぞれ、一般的に、構成ファイルＣＦｎを生成するＬＲＵｎ １３００の命令であり、表１に関して以下で詳述する。

ステップ３０１０〜３０３５を実行するように動作可能なコンピュータ実行可能コードは、一実施形態では、管理端末１１００で実行される。ステップ３０１０〜３０３５に関連する機能を実行するために必要なソフトウェアは、管理端末にも格納することができる。別法として、ステップ３０１０〜３０３５は、構成サーバ１２００で実行することが可能である。一実施形態では、ステップ３０４５〜３０５２の群は、図３−ａに示されているように、ＬＲＵｎ １３００にロードされたソフトウェアによりひとまとめで実行される。

構成ファイルの要求を選択されたＬＲＵ １３００に送信した後、ＬＲＵ １３００のアクティブなポーリングを行うステップ群がオプションとして用意される。これらのアクティブなポーリングステップは、図３−ｄに示されており、アクティブなポーリングのステップは図３−ａのステップ３０３５の後に開始し、図３−ｄのステップ３２３０で制御が戻された後、図３−ａのステップ３０４５に続く。

一実施形態では、図３−ｄのアクティブなポーリング方法は、ＬＲＵｎ １３００（またはＬＲＵ １３００のどれか）のＷｅｂページ内で実行するＪａｖａアプレットにより実行される。アプレットがＬＲＵｎ上で実行されると、構成サーバは、図３−ｄに示されている方法を実行するために命令を実行することができる。構成サーバは、特定のソケットで接続を監視し、新しい構成ファイルが受信される毎にインクリメントする。進捗バーが、報告したＬＲＵ １３００の数を示す。本発明の一実施形態では、図３−ａ〜ｄの方法全体に要する時間は数分未満、つまり制限付きアーキテクチャネットワーク内でソフトウェアを構成するすでに知られている方法よりもかなり高速であると思われる。

アクティブなポーリングの第１のステップであるステップ３２１０で、構成サーバはＬＲＵｎなどのステップ３０３０で選択されたＬＲＵ １３００に、生成ステップを実行する初期命令を送信する。構成サーバは、次に、図３−ｄの矢印３２１５で示されている、第１の所定の期間待機する。ステップ３２２０で、ＬＲＵｎの構成ファイル（ＣＦｎ）が第１の所定の期間に構成サーバにより受信されたかどうかのチェックを行う。受信されていれば、構成方法は、ステップ３２３０で、図３−ａに示されている次ステップ群に戻り、ステップ３０４５から始まる。受信されていなければ、ステップ３２４０で第２の命令が構成サーバからＬＲＵｎに送信され、生成ステップが実行される。ステップ３２４０は、要求を構成サーバから直接、ステップ３２２０の前に報告していなかった特定ＬＲＵｎに送信することにより実行される（ステップ３０３０で選択されたすべてのＬＲＵ １３００へのブロードキャストの代わりに）。図３−ｄでラベル３２４５の矢印で示されている第２の所定の期間待機した後、アクティブなポーリング方法は、再びステップ３２５０でＬＲＵ構成ファイルが受信されたかどうかをチェックすることにより続行する。選択されたＬＲＵがステップ３２５０の後にそれでも報告しなかった場合、ステップ３２６０で「Ｎｏ Ｒｅｓｐｏｎｓｅ」レポートが生成され、方法はステップ３２３０で図３−ａに示されている次ステップ群に戻り、ステップ３０４５から始まる。ステップ３２００〜３２６０はともに、本発明のシステム１０００内のＬＲＵ １３００を構成する方法の一部として実行されるアクティブなポーリングの方法を含む。

図３−ａに戻ると、流れ図から、方法３０００が手動で開始したか（ステップ３０１０〜３０３５）、または自動で開始したか（ステップ３０４０）に関係なく、選択されたまたは所定の各ＬＲＵ １３００は、ステップ３０４５で関連する現在の構成ファイルＣＦｎをそれぞれ生成することは明らかである。構成ファイルＣＦｎは、特定のＬＲＵｎに関する現在のソフトウェアまたはハードウェア構成情報、例えば、ユニット識別、ハードウェア部品番号、シリアル番号、媒体アクセス制御（ＭＡＣ）アドレス、ＩＰアドレス、およびソフトウェアコンポーネント部品番号、または追跡するのが望ましいＬＲＵｎに関する他の情報を含む。ＬＲＵｎの構成ファイルＣＦｎが生成されると、オプションにより、図２のステップ３０５０で指示されているようにＬＲＵｎの記憶デバイスに格納することができる。

ＬＲＵｎの構成ファイルＣＦｎ例を以下の表１に示す。

構成チェック方法３０００がステップ３０４０で自動的に起動された場合、ＬＲＵｎは構成ファイルＣＦｎを自動的に生成する。当業者には明らかなように、これは、ＬＲＵ １３００でオペレーティングシステムの起動オペレーションにプログラムされ書き込まれている適切な命令を使用するなど、さまざまな方法で実行することができる。

各ＬＲＵは、その後、ステップ３０５０で構成ファイルを構成サーバに送信する。構成チェック方法３０００では、制限付きアーキテクチャネットワークを介してファイルを送信するためＦＴＰなどの標準プロトコルを使用する。ＦＴＰは、一般的にＴＣＰ／ＩＰ（インターネットプロトコルスイートともいう）にバンドルされているよく知られているアプリケーションである。したがって、構成ファイルを送信するために、ＬＲＵｎは構成サーバとのＦＴＰセッションを開き、ステップ３０５２で示されているように、ＦＴＰ「ｐｕｔ」コマンドを実行して、構成ファイルＣＦｎをＬＲＵｎから構成サーバに送信する。

それぞれ関連する構成ファイルＣＦｎを生成し（ステップ３０４５）、ファイルを構成サーバに送信する（ステップ３０５０）ＬＲＵオペレーションは、システム１０００内の複数のＬＲＵ １３００の中で並列実行することができる。この並列構成チェック方法は、効率の面で有利である。図３−ａは、図３−ｂに、両方の図に示されているラベル「Ａ」の円３０５４でつながっている。構成サーバがステップ３０５５で構成ファイルＣＦｎを受信すると、構成サーバは、ステップ３０５８で作業ディレクトリ内に構成ファイルＣＦｎを保持することができる。当業者には知られているように、構成ファイルは作業ディレクトリ内に保持する必要はなく、保持されている情報を構成ファイルに格納せずオンザフライで構成方法を実行することも可能であるが、情報は、ステップ３０５８で作業ディレクトリ内に保持されていれば、再利用できて有利である。

図４−ａは、座席２３ ＡＢおよびＣ、座席１７ ＨＪおよびＫ、および座席７ＡおよびＣをそれぞれ受け持つＬＲＵからの構成ファイルの送信の概略を例示している。ＬＲＵは、ＦＴＰ「ｐｕｔ」を独立に生成し実行して、対応する構成ファイルＣＦ２３ＡＢＣ、ＣＦ１７ＨＪＫ、およびＣＦ７ＡＣを構成サーバに送信し、そこで、構成ファイルは作業ディレクトリ内に置かれる。

構成サーバは、新しい構成ファイルが入っていないか作業ディレクトリ内を連続的または定期的にチェックする。図３−ａに例示されているような方法３０００に戻ると、構成サーバがステップ３０５９で新しい構成ファイルＣＦｎが着信したことを検出すると、構成サーバは、構成ファイルＣＦｎのデータとともにＳＣＤＦの一部をステップ３０６０で更新する。ステップ３０６０は、一般に、ステップ３０６５および３０７０でＣＦｎの一部を抽出しＳＣＤＦに供給する解析オペレーションを含む。より具体的には、特定のＬＲＵｎに関連する構成ファイルＣＦｎは生成されると（ステップ３０６５）、要素ＳＣＤＦｎとして示されている本明細書で「レコード」と呼ぶＳＣＤＦの一部に入る。レコードＳＣＤＦｎがすでに存在している場合、レコードは、ステップ３０７０でＣＦｎから解析された情報で更新される。

個々のレコードＳＣＤＦｎはそれぞれ、例えば、「ＣＵＲＲＥＮＴ」、「ＰＲＥＶＩＯＵＳ」、および「ＤＥＳＩＲＥＤ」というデータセットを含む比較データを含む。レコードＳＣＤＦｎが与えられると、「ＣＵＲＲＥＮＴ」、「ＰＲＥＶＩＯＵＳ」、および「ＤＥＳＩＲＥＤ」セットはそれぞれ、上述のように、ＬＲＵｎに対する構成ファイルに含まれるカテゴリを表すデータを含む。ＳＣＤＦｎレコードの例を以下の表２に示す。

表２のＳＣＤＦｎの例では、ＣＵＲＲＥＮＴ構成から、例えば、ＤＥＳＩＲＥＤ構成と一致する部品番号、シリアル番号、およびソフトウェアコンポーネント番号を持つ新しいコンピュータのあることがわかる。「ＤＥＳＩＲＥＤ」というラベルの付いている欄は、一実施形態では、ユーザが特定のＬＲＵｎに対して所望の構成として指定した構成を反映している。ＤＥＳＩＲＥＤ欄のデータは、図５に関して以下で詳述するように、ダウンロード方法についてソフトウェアインベントリからユーザが所望のソフトウェアコンポーネントを選択した後更新される。「ＤＥＳＩＲＥＤ」というラベルの付いている欄は、システム全体を通してシステムのユーザが一様を保ちたいハードウェアまたはソフトウェアに応じて、「ＣＵＲＲＥＮＴ」または「ＰＲＥＶＩＯＵＳ」というラベルの付いている欄に表示される構成情報のすべてを含むか、一部を含むか、全く含まないのいずれかである。構成チェック方法３０００で、ＰＲＥＶＩＯＵＳデータは古いＣＵＲＲＥＮＴデータで置き換えられ、ＳＣＤＦｎレコードのＣＵＲＲＥＮＴ欄（表２）は、解析されたＣＦｎデータ（表１）でＣＵＲＲＥＮＴを上書きすることにより更新される。

レコードＳＣＤＦｎはそれぞれ、ＬＲＵ １３００のすべてに対するレコードを含むＳＣＤＦの一部である。ＳＣＤＦは、システム１０００の所望のソフトウェアまたはハードウェア構成情報の完全な表現を含み、したがって、ＳＣＤＦは、システム１０００の複数の構成可能なＬＲＵｎ １３００にそれぞれ対応する複数のレコードＳＣＤＦｎを含む。ＳＣＤＦは、新しいレコードＳＣＤＦｎで更新され、構成サーバの記憶デバイス（例えば、ディスクドライブ、ＮＶＲＡＭなど）に更新されたＳＣＤＦが書き込まれる。ＳＣＤＦは、起動後に構成サーバのＲＡＭに復元されるのが好ましい。一実施形態では、ＳＣＤＦのすべてまたは一部をシステム内のＬＲＵ １３００のいずれかに格納できる。当業者には知られているように、ＳＣＤＦが特定のＬＲＵ １３００上に格納するために必要なすべてが利用可能なメモリ上にある。この実施形態の冗長性により加えられたデータ完全性は有利である。オプションにより、ＣＦｎは、ＳＣＤＦが更新された後に、ステップ３０７５で構成サーバ上の作業ディレクトリから削除することができる。ＬＲＵｎが報告した後、またＳＣＤＦｎがＳＣＤＦ内で更新されている場合、構成サーバは、ステップ３０８０で管理端末１１００にメッセージを送信し、ＬＲＵｎがその確認を報告したことを確認する。

図４−ｂに概略が示されているように、構成ファイル例ＣＦ２３ＡＢＣ、ＣＦ１７ＨＪＫ、およびＣＦ７ＡＣが生成されて、対応するレコードＳＣＤＦ２３ＡＢＣ、ＳＣＤＦ１７ＨＪＫ、およびＳＣＤＦ７ＡＣに入り、格納され、構成データベース内のＳＣＤＦを更新する。

ラベル「Ｂ」が付いている円３１００は、図３−ｂに示されているステップのシーケンスを図３−ｃの次のセット群に接続する。図３−ｂを参照すると、そこで比較ステップ３０８５が実行され、ＬＲＵのそれぞれの構成で生じた変更が判別される。特に、比較ステップでは、ＣＵＲＲＥＮＴコンポーネントとＰＲＥＶＩＯＵＳコンポーネントとを比較し、一致していないものを判別する。ステップ３０９０で、ＣＵＲＲＥＮＴ構成とＰＲＥＶＩＯＵＳ構成との相違は、オプションにより、システム１０００内のソフトウェアまたはハードウェアの構成に対する変更の履歴を含むイベントログに書き込まれる。イベントログは、構成サーバの記憶デバイスまたは管理端末１１００などのシステム内の他のコンピュータに格納される。

本発明の一態様では、さまざまなＬＲＵ １３００に関係する構成情報は、複数のＬＲＵユニットの構成データが各スレーブコンピュータの根気のいるテストを行ってから利用可能であったいくつかの従来システムと比較して、主として共有され、アクセス可能である。

解析ステップ３０６０が完了し、ステップ３０６５および３０７０でレコードＳＣＤＦｎ（例えば、表２）のそれぞれでＳＣＤＦが更新された後、図４−ｂに概略が示されているように、ステップ３０７５で構成サーバの作業ディレクトリから構成ファイルを削除することができる。さらに、歩調をあわせて構成サーバは特定のＬＲＵｎについての構成チェックが完了したことを管理端末１１００に通知する。一実施形態では、管理端末１１００はすべてのＤＥＳＩＲＥＤ ＬＲＵ １３００がチェックされるまで待ち、チェックされたら、管理端末に新しい構成情報を表示する。

有利には、システム１０００の効率および安定性は、個々のＬＲＵ毎に、またはＬＲＵグループ別に、ＬＲＵ １３００構成のチェックを行いやすくすることにより促進される。システム１０００に生じた問題をトラブルシューティングする際に、メンテナンス要員は、例えば、（ａ）システム内のすべてのＬＲＵの構成をチェックすること、および（ｂ）問題が明らかになった場合に、ＬＲＵ構成を個別にまたはグループ別にチェックすることにより、問題の「零点規正」を行うことができる。ＬＲＵ １３００すべてがＤＥＳＩＲＥＤ構成を持つＬＲＵグループであれば、チェックが早い。そこで相違が示されているＬＲＵグループについて、一度に１ユニットずつ解析することができる。トラブルシューティングに対するこのようなアプローチを促進することにより、システムメンテナンスは時間的効率のよい論理的でシステマティックな方法により実施することができる。方法３０００では、一度にＬＲＵ １３００、１つずつ、システム全体を順次チェックしていく必要がないため、従来のシステムを苦しめていたエラーおよび反復手順を回避できる。

「ダウンロードの方法」
構成チェック方法を実施して、古くなった、問題のある、あるいは他の何らかの点で望ましくないソフトウェアコンポーネントを識別した後、ソフトウェアコンポーネントまたは設定を必要に応じてピンポイントでＬＲＵ １３００ユニットにダウンロードすることによりＬＲＵ １３００構成を更新できることが望ましい。したがって、本発明の他の態様では、ＬＲＵ １３００のそれぞれのソフトウェアコンポーネントまたは設定を更新するダウンロード方法が提示されている。ダウンロード方法５０００の例が図５に示されている。ダウンロード方法は、通常、ＬＲＵ １３００を効率のよい方法で更新されたソフトウェアにより構成するために構成チェック方法とともに使用される。

このダウンロード方法は、それぞれのＬＲＵがＳＣＤＦｎで指定されたＤＥＳＩＲＥＤ構成と一致するＣＵＲＲＥＮＴ構成ファイルを持つようにＬＲＵ １３００ソフトウェアコンポーネントを修正する場合に効果がある。このダウンロード方法は、構成チェック方法３０００の後に各ＬＲＵｎのソフトウェアコンポーネントを更新し、各ＬＲＵｎユニットの構成データのそれぞれのＣＵＲＲＥＮＴおよびＤＥＳＩＲＥＤセットの食い違いを解消するために使用することができる。構成チェック方法３０００がダウンロード方法の直後に繰り返された場合、ＬＲＵ構成を変えた何らかの介在イベントがなければ、構成情報のそれぞれのＣＵＲＲＥＮＴおよびＤＥＳＩＲＥＤセットは、各個別ＬＲＵについて一致する。

図１を参照すると、ダウンロード方法は、一般に、管理端末１１００のソフトウェアコンポーネントインベントリから、またはサーバ１２００（ダウンロード方法の場合はダウンロードサーバ）からソフトウェアコンポーネントをＬＲＵｎなどの１つのＬＲＵ、いくつかのＬＲＵ、またはすべてのＬＲＵに送信する動作をする。ダウンロードは、ネットワーク資源の無駄な消費を避けるためＦＴＰを介して特定のＬＲＵアドレスを宛先とするのが好ましい。

より具体的に述べると、再び図５において、ソフトウェアダウンロード方法５０００は、ＩＦＥＳメンテナンス要員などのユーザがダウンロード方法を開始する命令を入力すると、開始ステップ５００５から始まる。一実施形態では、開始ステップ５００５は、管理端末１１００から、またはシステム１０００のイーサネットデータバックボーン１５００（図２−ａ）とインターフェースするように適合されているラップトップ２１９０などの補助メンテナンスコンピュータから実行される。

ダウンロードサーバがＬＲＵ １３００で必要なソフトウェアコンポーネントを配信できるためには、それらのソフトウェアコンポーネントをまず最初に、ダウンロードサーバからアクセス可能な記憶デバイスに常駐するソフトウェアインベントリに入れなければならない。本明細書の例の場合、このインベントリには、表２に関して上で説明したように、ＬＲＵに格納する必要があるＤＥＳＩＲＥＤソフトウェアコンポーネントが含まれる。したがって、図５に例示されているように、ユーザはステップ５０１０で、構成サーバインベントリを更新するよう求められる。そのように選択した場合、ＤＥＳＩＲＥＤソフトウェアコンポーネント（ソフトウェア「インベントリ」を構成する）のリストをステップ５０２０で指定することができる。オプションにより、一番最近のＳＣＤＦが利用可能な場合、ステップ５０２０の前のステップ５０１５で表示することができる。本発明の一実施形態では、メニューは、管理端末１１００または補助メンテナンスラップトップ上で実行されているＨＴＭＬブラウザに表示されるＨＴＭＬページとすることができる。ＨＴＭＬは、システム１０００（図２−ｂに示されている）に接続されている乗客制御ユニット２２２０またはパーソナルデジタルゲートウェイ２２３０の１つに表示することすら可能である。

ステップ５０２０で、ユーザは、ＤＥＳＩＲＥＤインベントリの一部となる新しいソフトウェアを選択することができる。新しいソフトウェアコンポーネントを利用するには、ステップ５０２５で、システム１０００（図１および２）の少なくとも１つのコンポーネントにより読み取ることができる記憶媒体からロードする。例えば、図２−ａに例示されているように、利用可能な新しいソフトウェアコンポーネントは、最初にＣＤ−ＲＯＭ、ＤＶＤ、または管理端末１１００、ダウンロードサーバ、またはデータバックボーン１５００上の任意のデバイスから読み出すことができるディスケットまたはハードドライブなどの記録可能媒体に収録しておくことができる。新しいソフトウェアコンポーネントは、例えば、デジタル記録動画、音楽などの娯楽ファイル、またはプログラムオブジェクトまたはグラフィックスなどシステム運用ファイルがある。図５の方法５０００を参照すると、ステップ５０２５で、選択された新しいコンポーネントは記憶デバイスから読み込まれる。初期格納場所からダウンロードサーバに選択されたコンポーネントを送信するには、ＦＴＰ「ｐｕｔ」コマンドを使用するのが好ましい。別法として、選択されたコンポーネントを利用可能な状態に置き、ダウンロードサーバからアクセス可能なドライブから読み込めるようにすることもできる。

ダウンロードサーバは、オプションにより、ステップ５０３５で、ＤＥＳＩＲＥＤコンポーネントのインベントリ内に新しいソフトウェアコンポーネントをローカルで格納することも可能である。このステップでは、ダウンロードの方法の第２のステップ群（５０５５〜５０８５）でソフトウェアコンポーネントをより柔軟に配信することができる。第１のステップ群の最終ステップでは、ステップ５０４０で表示が更新され、インベントリは新しいＤＥＳＩＲＥＤコンポーネントを含むように更新されたものとして反映される。

図５のダウンロード方法５０００の第２のステップ群では、ステップ５０１５〜４０でインベントリが更新された後、ステップ５０５０では、第１のステップ群５０１５〜５０４０でシステム１０００にロードされたインベントリからソフトウェアコンポーネントでターゲットＬＲＵを更新する機会を設ける。更新する１つまたは複数のＬＲＵ １３００がステップ５０５５で選択される。一実施形態では、ＬＲＵ １３００またはシステム１０００内のＬＲＵ １３００の所定のグループのすべてを選択する機能があってよい。その後、ステップ５０５５で利用可能なインベントリ内からさまざまなソフトウェアコンポーネントを選択することにより、ＤＥＳＩＲＥＤソフトウェアコンポーネントのリストを作成する。

ステップ５０６５で、ＤＥＳＩＲＥＤコンポーネントのリストは、選択されたＬＲＵに送り出される。図６−ａは、システム１０００内のさまざまなＬＲＵ １３００に「望ましいソフトウェアリスト」（つまり、ＤＥＳＩＲＥＤソフトウェアコンポーネントのリスト）を送信するダウンロードサーバの概略を例示している。ダウンロードサーバは、ＦＴＰ「ｐｕｔ」コマンドを実行して、ＤＥＳＩＲＥＤコンポーネントのリストを送信するのが好ましい。

図５の方法のステップ５０７０を参照すると、ＬＲＵ １３００のそれぞれが独立に、ＤＥＳＩＲＥＤソフトウェアコンポーネントのリストを現在の構成ファイルと比較して、ＬＲＵ １３００がＤＥＳＩＲＥＤソフトウェアコンポーネントを必要としているかどうかを判別する。図６ｂでは、ＬＲＵ １３００により実行することが可能な比較例を例示しており、そこでは、現在のＬＲＵ １３００ソフトウェアコンポーネントのうちの２つが「ｄｅｓｉｒｅｄ ｓｏｆｔｗａｒｅ ｌｉｓｔ」のＤＥＳＩＲＥＤソフトウェアコンポーネントと一致しており、またソフトウェアコンポーネント１５５４３はＤＥＳＩＲＥＤソフトウェアコンポーネント２３４５６とは一致していない。ＬＲＵ １３００は、独立に、必要とするソフトウェアコンポーネントのみを取得しようとする。再び図５を参照すると、方法５０００のステップ５０７５で、各ＬＲＵはＦＴＰ「ｇｅｔ」コマンドを実行して、図６−ｃに概略が示されているように、構成サーバから欠損している、または必要とされるコンポーネントを取り出す。さらに、ソフトウェアコンポーネントがＣＵＲＲＥＮＴソフトウェアコンポーネントのリスト内に存在するが、ＤＥＳＩＲＥＤソフトウェアコンポーネントのリスト内には存在していない場合、そのソフトウェアコンポーネントはステップ５０７５を実行しているシステム１０００内のＬＲＵ １３００のそれぞれにより独立して削除される。

ソフトウェアコンポーネントの選択および選択解除は、図７に例示されているシステム構成ＧＵＩ例７０００から実行することも可能である。システム構成例ＧＵＩ７０００は、３つのラベル「ＬＲＵ」、「ＳＯＦＴＷＡＲＥ」、および「ＰＡＲＴ ＮＵＭＢＥＲ」の項目の表を示している。ＬＲＵ欄には、システム内の構成可能なＬＲＵの一覧、例えば、「ＬＲＵ１Ａ」、「ＬＲＵ１Ｂ」、「ＬＲＵ２Ａ」などが表示されている。「Ｓｙｓｔｅｍｓ」というラベルの付いている行は、構成サーバ１２００（図１）として動作するように指定されているコンピュータコンポーネントに対応する。（図２−ａに例示されているようなシステム１０００のさまざまなコンポーネントが、構成可能なサーバとして機能することができる）。図７のシステム構成ＧＵＩをそのまま参照すると、ＳＯＦＴＷＡＲＥ欄およびＰＡＲＴ ＮＵＭＢＥＲ欄は、それぞれ、ソフトウェアコンポーネント名および対応する部品番号の一覧が表示される。各ＬＲＵのそれぞれのコンポーネントの一覧は別に表示される。図６の左側にあるチェックボックスにより、ユーザは特定のＬＲＵにどのソフトウェアコンポーネントをインストールするかを指示することができる（チェックボックスは各ＬＲＵの名前を含む行の隣に表示されないことに留意されたい）。図７からわかるように、複数のチェックボックスを同時に選択することができる。一実施形態では（図７に示されていない）、システム構成ＧＵＩ ７０００はさらに、すべてのチェックボックスの選択または選択解除を行う手段を備えることも可能である。

図７の下段に、「ＪＡＺ」、「ＤＥＬＥＴＥ」などのラベルの付いたメニューボタンが表示されている。ＤＥＬＥＴＥボタンは、各ＬＲＵについて示されているリストからソフトウェアコンポーネントを削除する場合に使用される。表示されているリストからソフトウェアコンポーネントを削除するには、ユーザ側で、そのコンポーネントの隣りにあるボックスにチェックマークを入れ、その後ＤＥＬＥＴＥを押す（マウスまたはタッチパネルであれば自分の指を使って）。その後、表示が更新され、削除されたソフトウェアコンポーネントがない状態で新しいシステム構成が表示されるのが好ましい。（このステップは、図５の方法５０００のステップ５０４０により示される）。ＰＲＩＮＴボタンは、システムに接続されている印刷デバイスを通じてシステム構成表示の印刷コピーを生成する場合に使用する。ＤＯＮＥボタンを使用すると、システムのユーザは、すでに述べた前の「Ｕｐｄａｔｅ Ｓｙｓｔｅｍ， Ｕｐｄａｔｅ ＬＲＵｓ， ｏｒ Ｄｏｎｅ？」メニューに戻る。

「ＪＡＺ」、「ＣＤ ＲＯＭ」、および「ＦＬＯＰＰＹ」というラベルが付いている、下段の表示のメニューボタンは、図７のシステム構成表示にまだ示されていないソフトウェアコンポーネントをシステムにロードする場合に使用する。システムのユーザがこれらのボタンのうちの１つ、例えば、ＣＤ ＲＯＭボタンを押すと、その媒体からロードされているソフトウェアコンポーネントの他の表示が現れる。

本発明の一実施形態による例として、ＣＤ ＲＯＭの媒体ロード表示に対するＧＵＩ ８０００を図８に示した。図７のシステム構成表示に表示されないある欄、ＳＴＡＴＵＳ欄が、媒体表示には表示されることに留意されたい。ＳＴＡＴＵＳ欄は、媒体に記録されているソフトウェアコンポーネントがダウンロードサーバに正常にロードされたかどうかを示す。図８のＧＵＩ ８０００では、「ＬＲＵ２Ａ」というラベルが付いている行のＳＴＡＴＵＳ欄に、メッセージ「ＦＡＩＬＥＤ」が示されており、このようなメッセージは、例えば、ダウンロードサーバがメモリ限界に達してしまい、したがって、ＬＲＵ２Ａのために所望のソフトウェアコンポーネントを格納できないことを示すことが考えられる。システムのユーザ、例えば、メンテナンス要員は、追加ソフトウェアコンポーネントをロードできる空き領域を作るためにダウンロードサーバからいくつかのファイルを削除する（か、または新しいダウンロードサーバを追加する）ことが必要になる場合がある。ユーザは、ＣＤ ＲＯＭからソフトウェアコンポーネントを選択する作業を終了したら、ＧＵＩの下部を見て、ＵＰＤＡＴＥボタンを押して媒体ロード表示を更新するか、またはＤＯＮＥボタンを押してシステム構成表示に戻ることができる。他の実施形態では、媒体ロード表示に、ＤＥＬＥＴＥボタンまたはＰＲＩＮＴボタン（図示せず）などの追加機能用の他のボタンを、必要に応じて、含めることも可能である。

インベントリ構成サーバから利用可能なソフトウェアでＬＲＵを更新する前に、図３に関して上で説明した構成チェック方法３０００を実行することが望ましい。特に、構成情報のリアルタイムの「手動開始」処理は、一番最近の構成情報から操作するのが望ましいので、サーバ１２００からターゲットＬＲＵ １３００に「ＤＥＳＩＲＥＤ」リストを送信するステップの間際に実行するのが好ましい。

ＬＲＵがそれぞれの現在構成ファイルを報告したときに、例えば、図９に例示されているように、ＬＲＵ Ｌｏａｄｉｎｇ ＧＵＩ ９０００を使用して表示することができる。ＧＵＩ ９０００は、さらに、セクションチェックボックスボタンを備えており、ユーザはそれで、更新するＬＲＵの特定のグループを選択することができる。ＡＬＬボタンは、ＬＲＵグループ内のすべてのＬＲＵを更新しなければならない場合に選択することができる。一実施形態は、ＬＲＵグループに対する１つまたは複数のチェックボックスがオンになっている間にＳＩＮＧＬＥボタンを押すと、更新の選択対象のＬＲＵグループ内の個々のＬＲＵの一覧がメニューに表示される。ＧＵＩ ７０００、８０００、９０００からの最後の選択は、図５の方法のステップ５０６５で、図６−ａに例示されているように、各ＬＲＵに送信されたＤＥＳＩＲＥＤ構成リストを定義することでもある。

図９のＧＵＩ ９０００では、例えばシステムソフトウェアコンポーネントの隣に表示されているようにチェックボックスは無効にすることができる。これは、システムが初期ダウンロード前に一定であるようにするため、またはオフラインになっているまたは利用できないことが判明しているＬＲＵを停止するために実行できる。しかし、これらのチェックボックスは、第１の構成およびダウンロードの後に有効にし選択可にできる。特定のＩＦＥＳのソフトウェア構成は、通常、顧客によって異なり、システム設計者の仕様書と整合を取るようにしなければならないことに留意されたい。

図５のダウンロード方法５０００のステップ５０６５に関して述べたように、ＡＬＬまたはＳＩＮＧＬＥボタンのいずれかでＬＲＵグループまたは個別ＬＲＵを選択した後、ダウンロードサーバは、それぞれの選択されたＬＲＵにＤＥＳＩＲＥＤ構成のリストを送る。本発明の一実施形態では、ＵＤＰ（ＴＣＰではなく）を使用するイーサネットブロードキャストまたはマルチキャストによりこのリストが送信される。各ＬＲＵは、部品リストを受信した後、現在の構成との比較を実行し、現在の構成に欠けているソフトウェアコンポーネントのリストを編集し、ＬＲＵ １３００はその後、ダウンロードサーバに対し、必要なそれぞれのコンポーネントのダウンロードを要求する。一実施形態では、ＬＲＵ要求は、ダウンロードサーバとのＦＴＰセッションを開き、必要な各ソフトウェアコンポーネントに対しＦＴＰ「ｇｅｔ」コマンドを実行することにより行う。複数のＦＴＰセッションおよびダウンロードが、ダウンロードサーバのシステムおよび処理能力の帯域幅の制限に従って、並列実行することが可能である。もちろん、システムは、すべてのＬＲＵからのＦＴＰ「ｇｅｔ」要求を同時に処理できるのが最も好ましい。制限付きアーキテクチャネットワーク１０００では、実質的に並列実行によりソフトウェアをダウンロードできるのが有利であり、そのため、ソフトウェアを構成し、複数のＬＲＵ １３００にダウンロードする際にかなり時間を短縮できる。

一実施形態では、ＬＲＵ １３００が要求した新しいソフトウェアコンポーネントすべてを受け取った後、ＬＲＵはファイル転送が完了したことを知らせるメッセージを構成サーバ１２００に送信する。構成サーバは、ＬＲＵが「アンパック」を必要としているというマークを付け、ＬＲＵがその構成に必要なソフトウェアコンポーネントをすべて受信した場合、ＬＲＵは図５のダウンロード方法のステップ５０８０に示されているように再起動する。一実施形態では、アンパックするステップ５０８５は、ｔａｒ、ｒａｒ、またはｚｉｐファイル形式などの圧縮ファイル形式の圧縮解除を行うことにより実行される。５０８５の完全性チェックは、ファイル転送で生じた可能性のあるエラーを調べるためファイルをチェックする適当な方法でよく、例えば、エラーは、ＴＣＰプロトコルではなくＵＤＰプロトコルを使用してファイルを転送する場合にありえ、適当な方法には、チェックサム計算、巡回冗長検査（ＣＲＣ）、または他の何らかの完全性チェックアルゴリズムを含めることも可能である。

本発明の利点は、ターゲットＬＲＵが再起動のためシステム内の他のターゲットＬＲＵの構成およびソフトウェアのダウンロードが完了するまで待たなくてよいという点である。本発明の一実施形態では、システム内のＬＲＵ １３００の一部または大半は、他のＬＲＵ １３００が構成中であり、ソフトウェアダウンロードを受信中の場合、切断されるか、または動作していない可能性がある。このため、制限付きアーキテクチャネットワーク内で接続されている複数のコンピュータの設計、テスト、およびトラブルシューティングの実行中にかなり時間を短縮できる。

ステップ５０８０で再起動した後、メモリ内の所定の場所でダウンロード済みファイルを見つけたＬＲＵ １３００は、完全性チェックを開始し、チェックに合格した場合、図５のステップ５０８５で示されているように、それらのファイルをアンパックする。完全性チェックは、一実施形態では使用する転送プロトコルに誤り訂正機能がないため（ＴＣＰにはあるがＵＤＰにはない）必要であり、アンパックは、一実施形態ではソフトウェアコンポーネントは送信速度を上げられる圧縮または「パック」状態で送信される場合があるため必要である。

最後に、ＬＲＵは、構成ファイルをサーバ１２００（一実施形態では、構成サーバ）に送信する。新しいシステム構成情報が、メンテナンス要員によりシステムに接続されているラップトップ、または管理端末１１００に表示される。

本明細書で説明されている好ましい実施形態に対するさまざまな変更形態および修正形態は当業者には明らかなことであると理解すべきである。このような変更形態および修正形態は、本発明の精神および範囲を逸脱せず、また結果として伴う利点を損なうこともない。

本発明の一実施形態による制限付きアーキテクチャネットワーク内のコンピュータの構成をチェックし、ソフトウェアをコンピュータにダウンロードするマルチコンピュータシステムのブロック図である。 本発明の教示による機能を備える機内娯楽システムのヘッドエンドコンポーネントを含む制限付きアーキテクチャネットワークの第１の部分の概略図である。 シートレベルコンポーネントを含む制限付きアーキテクチャネットワークの第２の部分の概略図である。 本発明の一実施形態によるデジタルサーバユニットのハードウェアレイアウトのブロック図である。 本発明の教示による制限付きアーキテクチャネットワーク内のコンピュータの構成をチェックする方法の流れ図の第１の部分である。 本発明の教示による制限付きアーキテクチャネットワーク内のコンピュータの構成をチェックする方法の流れ図の第２の部分である。 本発明の教示による制限付きアーキテクチャネットワーク内のコンピュータの構成をチェックする方法の流れ図の第３の部分である。 本発明の教示による方法のアクティブなポーリングステップを示す、制限付きアーキテクチャネットワーク内のコンピュータの構成をチェックする方法の流れ図の第４の部分である。 ターゲットＬＲＵが構成ファイルを構成サーバに送信する状況を示す概略図である。 構成データベース内のＳＣＤＦに構成ファイルを格納する構成サーバの概略図である。 本発明の教示によるターゲットＬＲＵにソフトウェアをダウンロードする方法の流れ図である。 所望のソフトウェアコンポーネントのリストをターゲットＬＲＵに送信するダウンロードサーバの概略図である。 所望のソフトウェアリストと比較された構成ファイルデータスタックの概略図である。 ＦＴＰ「ｇｅｔ」コマンドを使用して、ダウンロードサーバから必要なソフトウェアコンポーネントを取得するＬＲＵの概略図である。 本発明の方法により使用することができるシステム構成ＧＵＩ例の図である。 本発明の方法により使用することができる媒体選択ＧＵＩ例の図である。 本発明の方法により使用することができるＬＲＵ選択ＧＵＩ例の図である。

Claims (28)

1. ＬＲＵと通信する少なくとも１つの構成サーバを備える制限付きアーキテクチャネットワーク内で複数の構成可能な前記ＬＲＵの構成をチェックする方法であって、更新するＬＲＵ毎に、
   前記ＬＲＵでＬＲＵ構成ファイルを生成するステップであって、前記ＬＲＵ構成ファイルは前記ＬＲＵに現在常駐しているソフトウェアコンポーネントを識別するリストを含むステップと、
   前記ＬＲＵ構成ファイルを前記ＬＲＵから前記構成サーバに送信するステップと、
   前記ＬＲＵ構成ファイルの前記着信を検出するステップと、
   現在および前のＬＲＵ構成を表すデータを含むシステム構成データファイル（ＳＣＤＦ）を、前記現在のＳＣＤＦデータを前記生成ステップにより生成された前記ＬＲＵ構成ファイルを反映するように設定することにより、また、前記前のＳＣＤＦデータを前記構成チェック方法の前回実行中に前記ＬＲＵにより生成されたＬＲＵ構成ファイルを反映するように設定することにより更新するステップとを含む方法。
2. 前記ＬＲＵ構成ファイルを前記ＬＲＵから前記構成サーバに送信する前記ステップは、さらに、作業ディレクトリ内に前記ＬＲＵ構成ファイルを保持するステップを含む請求項１に記載の方法。
3. さらに、前記作業ディレクトリから前記ＬＲＵ構成ファイルを削除するステップを含む請求項２に記載の方法。
4. さらに、前記ＳＣＤＦの少なくと一部を前記制限付きアーキテクチャネットワーク内の少なくとも１つのＬＲＵに格納するステップを含む請求項１に記載の方法。
5. 前記ＬＲＵ構成ファイルを生成する前記ステップは、前記それぞれのＬＲＵの起動時に自動的に実行される請求項１に記載の方法。
6. さらに、前記ＬＲＵでＦＴＰ「ｐｕｔ」コマンドを実行して前記ＬＲＵ構成ファイルを送信する前記ステップを含む請求項５に記載の方法。
7. 前記ＬＲＵ構成ファイルを生成する前記ステップは、手動で開始され、前記方法はさらに、前記構成サーバから前記ＬＲＵに開始要求を送信する前記ステップを含む請求項１に記載の方法。
8. 前記開始要求は、イーサネットマルチキャストを介して少なくとも１つのＬＲＵに送信される請求項７に記載の方法。
9. 前記開始要求は、イーサネットブロードキャストを介して複数のＬＲＵに送信される請求項７に記載の方法。
10. 前記送信ステップはＦＴＰを介して実行される請求項１に記載の方法。
11. さらに、前記ＬＲＵ構成ファイルデータと前記ＬＲＵからの前の構成ファイルのデータとを比較し、不整合を判別し、前記不整合をイベントログに書き込む前記ステップを含む請求項１に記載の方法。
12. さらに、
    前記構成サーバから前記ＬＲＵに初期命令を送信して前記生成ステップを実行するステップと、
    第１の所定の期間待機するステップと、
    前記第１の所定の期間の後前記作業ディレクトリをチェックして、前記ＬＲＵ構成ファイルが前記構成サーバにより受信されたかどうかを判別するステップと、
    前記ＬＲＵ構成ファイルが受信されなかった場合に、前記構成ファイルから前記ＬＲＵに第２の命令を送信して、前記生成ステップを実行するステップと、
    第２の所定の期間待機し、その後再び、前記作業ディレクトリをチェックして、前記ＬＲＵ構成ファイルが受信されたかどうかを判別するステップとを含む請求項１に記載の方法。
13. さらに、前記第２の所定の期間の後前記ＬＲＵ構成ファイルが受信されなかった場合にＬＲＵは失敗報告を送らなければならないことを指示するステップを含む請求項１２に記載の方法。
14. 前記ステップは、複数のＬＲＵについて独立にかつ並列に実行される請求項１に記載の方法。
15. さらに、前記構成ファイルを生成する前記ステップの後、前記関連するＬＲＵの前記構成ファイルを格納する前記ステップを含む請求項１に記載の方法。
16. 制限付きアーキテクチャネットワーク内で少なくとも１つの構成可能なＬＲＵコンピュータによりダウンロードサーバからソフトウェアをダウンロードする方法であって、
    １つまたは複数のターゲットＬＲＵにロードされることが望ましいソフトウェアを表す所望のソフトウェアコンポーネントのリストを選択するステップと、
    前記ダウンロードサーバに接続されている記憶媒体から新しいソフトウェアコンポーネントをロードするステップと、
    前記ダウンロードサーバから前記ターゲットＬＲＵのそれぞれに所望のソフトウェアコンポーネントの前記リストを送信するステップと、
    各ＬＲＵの所望のソフトウェアコンポーネントの前記リストと前記ＬＲＵのそれぞれの現在のソフトウェアコンポーネントのリストとを比較するステップと、
    所望のソフトウェアコンポーネントの前記リストと現在のソフトウェアコンポーネントの前記リストとを比較することにより必要なソフトウェアコンポーネントを決定するステップと、
    前記ＬＲＵにより前記ダウンロードサーバから前記必要なソフトウェアコンポーネントをダウンロードするステップと、
    所望のソフトウェアコンポーネントの前記リストにない前記ＬＲＵに含まれているソフトウェアコンポーネントを削除するステップとを含むダウンロード方法。
17. さらに、前記ＬＲＵのそれぞれの現在のソフトウェアコンポーネントの前記リストを表示する前記ステップを含む請求項１６に記載の方法。
18. さらに、前記新しいソフトウェアコンポーネントを前記ダウンロードサーバに格納する前記ステップを含む請求項１６に記載の方法。
19. さらに、ダウンロードの前記ステップの後に前記ＬＲＵを再起動する前記ステップを含む請求項１６に記載の方法。
20. さらに、ダウンロードの前記ステップの後に行う前記必要なソフトウェアコンポーネントの整合性チェックおよびアンパックの前記ステップを含む請求項１６に記載の方法。
21. 前記ダウンロードサーバから前記ＬＲＵのそれぞれに所望のソフトウェアコンポーネントの前記リストを送信する前記ステップは、ＦＴＰを使用して実行される請求項１６に記載の方法。
22. 必要なソフトウェアコンポーネントをダウンロードする命令を前記ＬＲＵのそれぞれから送信する前記ステップは、前記必要なコンポーネントを識別するＦＴＰ「ｇｅｔ」コマンドを実行するステップを含む請求項２１に記載の方法。
23. 制限付きアーキテクチャネットワーク内で使用するための構成可能なシステムであって、
    作業ディレクトリを保持するメモリ、データベースを保持する記憶デバイス、データパーサ、およびネットワーク通信デバイスを備える少なくとも１つのサーバと、
    複数の構成可能なＬＲＵであって、前記ＬＲＵのそれぞれは、前記それぞれのＬＲＵの現在のソフトウェアコンポーネントを表す構成ファイルを生成するように動作可能な構成ファイルジェネレータ、および前記構成ファイルを前記サーバに送信するように動作可能なネットワーク通信デバイスを備えるＬＲＵと、
    前記ＬＲＵと前記サーバとの間の並列通信を処理するためのネットワークバックボーンとを備え、
    前記サーバは、前記作業ディレクトリ内で前記それぞれのＬＲＵから前記構成ファイルを受信し、前記データパーサは、前記データベースに格納されているシステム構成データファイルを、現在の構成を表す前記システム構成データファイルのフィールドに前記構成ファイルを書き込み、前記現在のフィールドにすでに格納されているデータを前記前の構成を表すフィールドに移動することにより更新するように動作可能である構成可能なシステム。
24. 前記サーバはデジタルサーバユニットである請求項２３に記載のシステム。
25. 前記ＬＲＵは、ＦＴＰを介して前記構成データファイルを前記サーバに送信する請求項２３に記載のシステム。
26. 前記ＬＲＵはさらに、前記構成ファイルを前記サーバから受け取った所望のソフトウェアコンポーネントのリストと比較して必要なコンポーネントを判別するコンパレータを備え、前記ＬＲＵの前記ネットワーク通信デバイスはさらに、前記サーバから前記必要なソフトウェアコンポーネントをダウンロードするため前記構成ファイルを前記要求側に送信するように動作可能である請求項２３に記載のシステム。
27. さらに、開始要求を送信し、前記ＬＲＵに前記構成ファイルを生成させるように動作可能な管理端末を備える請求項２３に記載のシステム。
28. 前記ＬＲＵの前記構成ファイルジェネレータは、前記ＬＲＵの起動後、前記構成ファイルを自動生成するように動作可能である請求項２３に記載のシステム。

Images