(57)【特許請求の範囲】
【請求項１】
航空機内で取得されたデータの取得および記録装置において、
−  複数の記録対象データストリームソースと、
−  少なくとも１つの日付つき記録パラメータ値ソースと、
−  少なくとも１つの不揮発性情報媒体上にデータストリームに由来するデータおよびパラメータ値を記録する手段と、
−  ソースに由来するデータを前記記録手段に向かってルーティングする手段と、を有し、
前記記録手段が、前記日付つき記録パラメータ値に関連づけされた異なるデータストリームのデータを別々のファイル内に記憶するように構成され、
前記記録手段が、前記データストリームの各データを、該各データを取得した取得世界時と関連づけて記録するように構成され、
前記記録手段が、前記ルーティング手段によって誘発された伝送待ち時間を補償するように構成された日付記入手段を有することを特徴とする装置。
【請求項２】
前記記録手段が、異なるデータソースに由来するデータを表わすファイルが記録されるにつれて生成される合成ファイルを生成する手段を有し、
前記合成ファイルにより前記異なるデータソースに由来するデータを表わすファイルを同期的に参照し再読取りすることが可能となり、
前記合成ファイルには、各々が前記データソースに由来するデータを表わすファイルを指し示す外部リファレンスが入っていることを特徴とする請求項１に記載の装置。
【請求項３】
前記記録手段が、少なくとも１つのファイル内に前記パラメータ値を動的に記録するように適合されていることを特徴とする請求項１または２のいずれか一項に記載の装置。
【請求項４】
前記記録手段が、パラメータの記述子ならびにテストに関するデータを汎用データ構造によって記録するように適合されていることを特徴とする請求項３に記載の装置。
【請求項５】
データストリームに由来する記録されたデータの少なくとも一回の配信のため合成ファイルを生成するように構成された読取り手段を有し、
前記合成ファイルにより配信すべきデータを含むファイルを同期的に参照し再読取りすることが可能となり、
前記合成ファイルには、各々が配信すべきデータを表わすファイルを指し示す外部レファレンスが入っていることを特徴とする請求項１〜４のいずれか一項に記載の装置。
【請求項６】
前記記録手段が、マテリアル交換フォーマット（ＭＸＦ）のファイルの形に前記データソースに由来するデータをフォーマットするように構成されていることを特徴とする請求項１〜５のいずれか一項に記載の装置。
【請求項７】
前記少なくとも１つのパラメータ値ソースが、世界時値からストリームデータソースに関連した時間コードへの変換器を有することを特徴とする請求項１〜６のいずれか一項に記載の装置。
【請求項８】
前記記録手段が、前記航空機のクロックに同期化された内部クロックを用いることによって取得時点で前記データストリームに日付記入するように構成されていることを特徴とする請求項１〜７のいずれか一項に記載の装置。
【請求項９】
前記記録手段が、航空機、飛行テストおよび前記データソースを識別する静的メタデータ、前記データストリームのデータおよび前記データの捕捉時点を表わす情報を含むファイルの中にデータストリームソースに由来する各データストリームをパッケージングする手段を有していることを特徴とする請求項１〜８のいずれか一項に記載の装置。
【請求項１０】
記録が実行されていない場合に前記データストリームを記憶し、予め定められた長さの時間中保存し、記録が開始された時点で前記一時記憶されたデータの少なくとも一部分を記録するバッファメモリーを含むことを特徴とする請求項１〜９のいずれか一項に記載の装置。
【請求項１１】
前記データストリームソースに由来するデータストリームが、一定の時間長の時間セグメントに分割され、前記記録手段が、各々の時間セグメントおよび各パラメータについて、該時間セグメント中に利用可能なパラメータの最新値を記録することを特徴とする請求項１〜１０のいずれか一項に記載の装置。
【請求項１２】
前記記録手段が、前記パラメータ値を取得した日付に応じて一定の時間長のセグメント中に分散したパラメータ値を含む記述的メタデータファイルを記録するように構成されており、１つのパラメータおよび１つのセグメントあたり唯一のパラメータ値が記録されることを特徴とする請求項１〜１１のいずれか一項に記載の装置。
【請求項１３】
前記記録手段が、中断無く連続しかつ構成が変わらない均一なシーケンスへと前記記録を分割するように構成されており、前記記録が再開または再構成される毎に各々の新たなシーケンスのための新しいファイルを含む新しいディレクトリが生成されることを特徴とする請求項１〜１２のいずれか一項に記載の装置。
【請求項１４】
前記記録手段が、同一のデータを異なる複数の圧縮率および圧縮アルゴリズムで記憶するように適合されていることを特徴とする請求項１〜１３のいずれか一項に記載の装置。
【請求項１５】
前記記録手段は、飛行テストに際して、少なくとも１つのデータストリームのデータと、該少なくとも１つのデータストリームのデータに続いて、該１つのデータストリームのデータを再読取りできるようにする１つの情報ブロックとを含む複数のパーティションに前記ファイルが分割される記録モードである「ストリーミング取得」モードで前記データを記憶するように構成されていることを特徴とする請求項１〜１４のいずれか一項に記載の装置。
【請求項１６】
前記記録手段が、地上で、前記記録されたデータを変換して、前記ファイルを複数のブロックに分割する「ファイル」モードで該変換されたデータを記録するように構成されており、前記ファイルのヘッダーおよび／またはフッターには前記ファイルの再読取りを可能にする情報が含まれ、ファイルのボディには前記データストリームに由来するデータが含まれていることを特徴とする請求項１〜１５のいずれか一項に記載の装置。
【請求項１７】
記録された異なる画像がどこにあるかを示すインデックステーブルを生成するように適合されたインデキシング手段を有することを特徴とする請求項１〜１６のいずれか一項に記載の装置。
【請求項１８】
前記記録手段が、少なくとも１つのデータストリームを圧縮せずにその未加工形態で保存するように構成されていることを特徴とする請求項１〜１７のいずれか一項に記載の装置。
【請求項１９】
前記記録手段が、「フレームワーク」の形で組織され、ユーザー向け情報で各ファイルを修飾することのできる記述メタデータを定義するように適合されていることを特徴とする請求項１〜１８のいずれか一項に記載の装置。
【請求項２０】
前記記録手段が、パラメータ値を記述するメタデータセットリストを含む静的記述メタデータファイルを記録するように適合されていることを特徴とする請求項１〜１９のいずれか一項に記載の装置。
【請求項２１】
前記記録手段が、１つ以上の同期化されたデータストリームのリプレイの形で、前記記録済みデータを供給するように構成されていることを特徴とする請求項１〜２０のいずれか一項に記載の装置。
【請求項２２】
複数の記録対象データストリームソースと、
少なくとも１つの日付つき記録パラメータ値ソースと、
少なくとも１つの不揮発性情報媒体上にデータストリームに由来するデータおよびパラメータ値を記録する手段と、
ソースに由来するデータを前記記録手段に向かってルーティングする手段と、を有する航空機内で捕捉されたデータの取得および記録方法において、前記記録手段が、
−  別々のファイル内に異なるデータストリームのデータを記憶するための記録ステップと、
−  各々のファイル内で、前記記録済みデータと前記日付つき記録パラメータ値を関連づけするステップと、
−  前記データストリームの各データを、該各データの取得世界時と共に記録するステップと、
−  前記ルーティング手段によって誘発された伝送待ち時間を補償する日付記入ステップと、を有することを特徴とする方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、航空機内で捕捉されたデータの取得および記録方法および装置に関する。本発明は、特に、映像、音声、グラフィックデータ、および、より一般的には、あらゆるタイプのデジタルデータを記録し視覚化できるようにする飛行テスト設備に関する。
【背景技術】
【０００２】
飛行テスト設備は、公知の通り、例えばシリアルデジタルインタフェース（Serial Digital Interface：ＳＤＩ）などの、特に、飛行機のシステムから出力されるテストカメラまたはビデオの映像ソースおよび関連する飛行機のパラメータを表わすいくつかのデータを記録する。これらの記録システムは、テスト機のニーズに適合させる必要のあるプロプライエタリシステム（systemes proprietaires）である。これらは磁気テープカセット上にデータを記憶する。その時代および当時市場で処理可能であった技術に応じて、異なるタイプの映像記録フォーマットおよび記録装置が利用されていた。
【０００３】
図１は、先行技術の映像測定コンポーネントの機能ブロックを概略的に示している。このシステムにおいては、飛行機のパラメータデータに日付を記入し、これらのデータを映像と関連づけする必要性、並びにできるだけ多くのチャネルを記録する必要性のため、一部の機能をできるだけ流用し質と量との間での妥協を行なうことで市販の専門的機材を適合させていた。
【０００４】
図１を見てわかるように、映像はセンサーカメラ１０５により得られ、その後処理手段１１５によって処理される。テストの推移を精確に知りかつ並行して得られたその他の全てのデータ、特に飛行機パラメータ１２０に対し、その映像をリンクさせる目的でＧＭＴ（グリニッジ標準時を表わす「Greenwich mean time」）１１０すなわち世界時に基づくタイムコード（horodatage）がこれに付加される。一部の飛行機については、飛行機のパラメータは、機上コンピュータ（図示せず）によって計算され、符号化される。対応するデータはパラメータ数および再書込み（rafrai^chissement（リフレッシュ））頻度が制限されている。処理手段１１５の出力端で、信号は例えばＳＤＩ規格「ＳＭＰＴＥ２５９」に準じて送信される。かかる接続のスループットは、２７０Ｍｂｐｓに固定される。
【０００５】
信号は、テスト中にスクリーン１２５上に視覚化される。ＳＤＩ映像信号の視覚化にはフォーマット変換器（図示せず）が必要であることに留意されたい。一方、映像およびメタデータすなわちパラメータ、飛行機、フライトおよび利用機材の識別子並びに時刻は、地上の手段１３５によるその調査、アーカイビングおよび／または記憶を目的としてカセット１３０上に記録される。使用される記録装置に応じて、使用される記録フォーマットが決定される。このフォーマットは、専らプロ向けである。その上、分類およびアーカイビングを容易にするために、飛行機のデータ（型式、番号…）がつけ加えられる。これらの情報はカセット上に補完される。かくして、各カセットのためのヘッダーが得られる。
【０００６】
地上では、得られたカセットを次に、作業領域（banc d'exploitaion）上で専門家が分析する。所望のシーケンスをサーチするためにカセット全体を読み通さなければならないことから、磁気テープの利用は線形的に行なわれる。その上、飛行機のパラメータは部分的に記録されていることから、作業領域とデータベースとの間の接続が必要である。
【０００７】
したがって、以上から分かるように、実映像ＩＥＶ（「Installation d’Essai en Vol（飛行テスト設備）の頭字語）の機上アーキテクチャは、使用される媒体すなわち磁気テープをその理由として比較的複雑なものである。実際、ストリーム（映像、音声および飛行機パラメータ）は、カセット上に記録される。
【０００８】
この技術的現状には、以下の通りの数多くの欠点がある。
−  ビデオテープレコーダでは、「ＳＤ」とも呼ばれる標準的精細度のビデオストリームしか記録できない。「ＨＤ」とも呼ばれる高精細度のビデオストリームを記録するためには、HD Camタイプのビデオテープレコーダを使用する必要があり、そのため追加費用が生じる。コックピットの計器に関する、航空シリアルビデオインタフェースのための航空シリアルビデオインタフェース（Avionics Serial Video Interface：ＡＳＶＩ）タイプ、または、グラフィックスビデオマトリクスのためのビデオグラフィックスアレイ（Video Graphics Array：ＶＧＡ）タイプのグラフィックページを記録するためには、これらの信号をＳＤまたはＨＤ映像信号に変換できるモジュールを付加しなければならない。
−  ビデオテープレコーダ上での画像の日付記入（タイムスタンプ）は、ＡＥＳ（専門的音声入力用デジタル信号構造を規定する標準化機構である音響技術学会を表わす「Audio Engineering Society（オーディオ技術者協会）」の頭字語）信号を介して提供される「タイムコード」と呼ばれる時間コードに基づいて行なわれる。したがって、特に飛行機時間に基づいて画像に日付記入できるように、飛行機時間をＡＥＳタイムコードに変換することのできるハードウェアモジュールを開発する必要がある。
−  ビデオテープレコーダ上には、動的パラメータを記録するためのシステムが全く具備されていない。したがって、飛行機パラメータを記録できるようにするため、音声トラック内に飛行機パラメータを符号化できるハードウェアモジュールを開発する必要がある。地上での利用に際してこれらのパラメータを読取るための別のハードウェアモジュールも開発しなければならない。
−  カセットは、線形媒体である。このことは、すなわち、取得の際に異なるストリーム（音声、映像およびパラメータ）を同期化しなければならないということを意味する。このために、異なるストリームの伝送時間が異なるので問題が生じる。
【発明の概要】
【発明が解決しようとする課題】
【０００９】
本発明は、これらの欠点の全てまたは一部を改善することを目的とする。特に、本発明は、以下に記した課題の全てまたは一部を解決することを目的とする。
【００１０】
最初の課題は、各ストリームのメタデータ、映像データ、音声データおよびタイムトラックを簡単にかつ無制限に関連付けし同期化させることにある。ビデオストリームは、情報を喪失することなく、すなわち本来の解像度および頻度で取得され、圧縮された形でまたは圧縮されずに記憶されなくてはならない。特に、これは、同じ媒体上に、実際には少なくとも１つのハードディスク上に、好ましくは異なるファイル内に異なるストリームを記録することであり、これには、取得時にストリームを同期化する必要がないという利点がある。
【００１１】
第２の課題は、これまで使用されてきた記録媒体、磁気テーブカセットおよび記録・再生機材の至近の陳腐化に関するものである。問題は、搭載機器の制約を満たすのみならず、地上で遭遇する制約、特に取得したデータの自動的アーカイビングおよび単純かつ迅速な処理に適合された交換フォーマットを見出すことにある。好ましくは、すでにハードディスクに記録された飛行機データ用および映像用のアーカイビング・インフラストラクチャを画一化することを目指す。
【００１２】
第３の課題は、あらゆるタイプのフォーマットで記録できるようにすることにある。実際、例えばＡＲＩＮＣ８１８（その標準８１８１がアビオニクスデジタルビデオ母線に関するものである、航空無線会社を表わす登録商標「Aeronautical Radio. Incorporated」の頭字語）、ＶＧＡ、関連づけられるテストを記述するデータ、プレトリガーすなわちプレオンセット機能およびリプレイ（再生）（英語の「play」または「replay」）機能など、コンピュータの出力端において、特に高精細度の新しいフォーマットが出現している。その上、新規の強力な圧縮アルゴリズムおよび高スループットを可能にするハードウェアも出現している。したがって、本発明は、映像に特定的でない機内システムアーキテクチャならびに、量的および質的な制限無く、異なるデータ、映像、音声、パラメータ、グラフィックストリームを取得し、圧縮し、同期化し、記憶し、かつリプレイし処理することを可能にするファイルフォーマットを決定することを目的とする。
【課題を解決するための手段】
【００１３】
本発明は特に、これらの課題の全てまたは一部を解決することを目的とする。このため、第１の態様によると、本発明は、航空機内で捕捉されたデータの取得および記録装置において、
−  複数の記録対象データストリームソースと、
−  少なくとも１つの日付つき記録パラメータ値ソースと、
−  少なくとも１つの不揮発性情報媒体上にデータストリーム由来のデータおよびパラメータ値を記録する手段と、を有し、
記録手段が、異なるデータストリームのデータを別々のファイル内に記憶するように構成されており、各ファイル内に記憶されたデータが前記パラメータ値と関連付けされることを特徴とする装置を目的とする。
【００１４】
かくして本発明は、映像に特定的でない機内システムアーキテクチャならびに、量的および質的な制限無く異なるデータ、映像、音声、パラメータ、グラフィックストリームを取得し、圧縮し、同期化し、記憶し、かつリプレイし処理することを可能にするファイルフォーマットを提供する。
【００１５】
その上、提案されているアーキテクチャはモジュール式アーキテクチャであり、異なるソースに由来する異なる音声／ビデオストリームは、記録されるチャネルの数に従ってサイズ（取得サーバーおよび記憶用ハードディスクの数）の決定を調整できるようにしかつ新しい機能の追加を容易にする複数の異なるプロセスによって取得される。
【００１６】
このような措置によって、取得の際にストリームを同期化することは不要となる。
【００１７】
異なる複数のファイル内にストリームを記録することには、以下のような利点がある。
−  機内では、ファイルは異なる複数のプロセスによって生成され、異なる複数のハードディスク上に記録され得る。
−  地上では、別々のファイル内に異なるストリームを記憶することにより、リクエストに応じて処理すべきデータの量およびファイルのサイズを制限することが可能となり、例えば「ニアライン」に戻す必要があるのは要求されたストリームを有するファイルのみになる。
【００１８】
本発明は、航空術の制約そしてより詳細には飛行テストの制約に適合したファイルフォーマットに関連づけされた１基の単純なサーバー（唯一であってよい）を中心として設計されたハードウェアアーキテクチャを提案する。
【００１９】
提案されたファイルフォーマットは、その同期化の能力を伴って全てのタイプのデータを記録すること、そして特に、絶対時間に基づくデータへのランダムアクセス、サーチを容易にするためのデータベースの自動情報提供およびデータセキュリティの確保によって処理を容易にすることを可能にする。
【００２０】
その上、提案されているアーキテクチャはモジュール式アーキテクチャであり、異なるソースに由来する異なるオーディオ／ビデオストリームは、記録されるチャネルの数に従ってサイズ（取得サーバーおよび記憶用ハードディスクの数）の決定を調整できるようにしかつ新しい機能の追加を容易にする複数の異なるプロセスによって取得される。
【００２１】
最終目的は、飛行テストの技術的制約を考慮に入れて（地上および機上で）最適化された「ワークフロー（workflow）」を得ることにある。ここで、「ワークフロー」というのは、例えば人々の間での文書の自動的伝送といったような、１つの組織内部の情報フローのことであるという点を喚起しておく。「ワークフロー」（文字通り、フランス語で「flux de travail」）というのは、達成すべきタスクと技術的プロセス（オペレーティングプロセスまたはビジネスプロシージャとも呼ばれる）の実現に関与する異なる動作主とのセットの情報処理によるモデル化および管理のことである。したがって「ワークフロー」という用語は、フランス語では「技術的プロセスの電子管理「gestion electronique des processus metier」と訳すことができると考えられる。より実際的には、「ワークフロー」は、検証回路、１つのプロセスの異なる動作主の間で達成すべきタスク、遅延、検証モードを記述し、各動作主に対してそのタスクの実現のために必要な情報を提供する。これは一般に追跡を可能にし、動作主を、その役割とそれを最良の形で達成する方法を明確にしながら識別する。「ワークフロー」エンジンは、「ワークフロー」の１つ以上の定義を実行できるようにするソフトウェアデバイスである。言葉の誤用で、このソフトウェアデバイスを単純に「ワークフロー」と呼ぶこともある。
【００２２】
カセットを用いないコンピュータ化された環境内のコンテンツ（データ、映像、音声、グラフィックアート）の管理によって以下のことが可能になる。
−  コストを制限すること。
−  処理を容易にすること（データアーカイビングの合理化、データへの容易かつ迅速なアクセス）。
【００２３】
この解決法は、中央サーバーを中心として単純であるばかりでなく入力フォーマットレベルでも圧縮率レベルでも適合性あるアーキテクチャによってもたらされる。
【００２４】
特定の特徴によると、記録手段は、異なるデータソースに由来するデータを表わすファイルが記録されるにつれて生成される合成ファイルの生成手段を有し、この合成ファイルによりこれらのファイルを同期的に参照し再読取りすることが可能となり、この合成ファイルにはデータソース由来のデータを表わすファイルを各々指し示す外部リファレンスが入っている。これらの合成ファイルは、複数のファイル内に含まれた日付つきの複数のストリームを関連づけすることによりファイルの同期的再読取りを可能にする。
【００２５】
特定の特徴によると、記録手段は、少なくとも１つのファイル内にパラメータ値を動的に記録するように構成されている。
【００２６】
特定の特徴によると、記録手段は、パラメータの記述子ならびにテストに関するデータを汎用データ構造を介して記録するように構成されている。
【００２７】
例えば、テストに関するデータはテストタイプ、テスト番号、飛行機の型式、飛行機の番号およびフライト番号である。
【００２８】
特定の特徴によると、記録手段は、データストリームの各データを、それを取得した世界時に関連づけて記録するように構成されている。
【００２９】
かくして、全てのタイプのデータを、それらを同期化する能力を伴って記録することが可能となり、特に世界時に基づくデータへのランダムアクセスにより処理が容易になる。
【００３０】
これらの各々の措置によって、データの記憶に必要なメモリー空間が制限される。
【００３１】
特定の特徴によると、以上で簡潔に報告された通りの本発明の目的である装置は、データストリームに由来する記録されたデータの少なくとも一回の配信のため合成ファイルを生成するように構成された読取り手段（２２０）を有し、この合成ファイルにより配信すべきデータを含むファイルを同期的に参照し再読取りすることが可能となり、この合成ファイルには、配信すべきデータを表わすファイルを各々指し示す外部レファレンスが入っている。
【００３２】
この合成ファイルは、どのストリームを配信すべきかを指示する。このメカニズムにより、異なるファイルでストリームを記録し処理できるようになる。
【００３３】
特定の特徴によると、以上で簡潔に報告された通りの本発明の目的である装置は、ソース由来のデータを記録手段に向かってルーティングする手段を有し、記録手段は、ルーティング手段によって誘発された伝送待ち時間を補償するように構成された日付記入手段を有する。
【００３４】
かくして日付記入は、きわめて精確である。
【００３５】
特定の特徴によると、記録手段は、ＭＸＦ（マテリアル交換フォーマットを表わす「Material eXchange Format」の頭字語）フォーマットのファイルの形にデータソース由来のデータをフォーマットするように構成されている。
【００３６】
その論理構造に関係するＭＸＦフォーマットの利点としては、その物理的構造から独立しているＭＸＦフォーマットのファイルの論理構造という利点を挙げることができる。したがって、異なるストリームおよびメタデータを、それらのタイプおよび場所の如何に関わらず、互いに組織し同期化することが可能である。
【００３７】
このフォーマットは、特に以下のようなＩＥＶの制約を満たすメカニズムを提供する。
−  ファイルモードおよび異なるストリーミングモードの管理。
−  外部リファレンスのサポ−ト。
−  異なるタイプの任意数のストリームの同期化。
−  ランダムアクセスのための包括的メカニズム。
−  きわめて進化したメタデータ管理。例えば、静的および動的メタデータの管理、メタデータの範囲の管理、幅広いニーズを網羅する規格化されたメタデータの「フレームワーク」の管理、プロプライエタリメタデータ「フレームワーク」を定義する能力。
【００３８】
特定の特徴によると、データストリームは、航空機のクロックに同期化された内部クロックを用いることによって取得時点で日付記入される。例えば、内部クロックの時刻合わせは、外部ＮＴＰサーバーまたは、ＡＥＳタイムコード入力に基づきＧＭＴ／ＡＥＳタイムコード変換器によって行なうことができる。このとき、インデックステーブルにより、このタイムコードに関連づけされた画像を見出すことができる。このメカニズムにより、同じ時間基準を用いない場合でも、記録されたデータストリームの同期的読取りを行うことができる。
【００３９】
特定の特徴によると、記録手段は、航空機、飛行テストおよび前記データソースを識別する静的メタデータ、データストリームのデータおよび前記データの捕捉時点を表わす情報を含むファイルの中にデータストリームソースに由来する各データストリームをパッケージングする手段を有している。
【００４０】
特定の特徴によると、以上で簡潔に報告されている通りの本発明の目的である装置は、記録が実行されていない場合にデータストリームを記憶し予め定められた長さの時間中保存し、記録が開始された時点で一時記憶されたデータの少なくとも一部分を記録するバッファメモリーを含む。
【００４１】
特定の特徴によると、データストリームソース由来のデータストリームは、一定の時間長の時間セグメントに分割され、記録手段は、各々の時間セグメントおよび各パラメータについて、この時間セグメントの間に処理可能なパラメータの最新値を記録する。
【００４２】
このように生成された時間セグメントは、飛行機およびテストならびに取得された異なるパラメータを記述する静的メタデータ、各時間セグメントについて採用されたパラメータの値および取得年月日を記録する動的メタデータを含むファイル内に、順次パッケージングされる。
【００４３】
かくして、パラメータを音声／ビデオストリームと同じ要領で記憶し処理できるような形で、これらのパラメータを時間に関して再組織することができる。
【００４４】
特定の特徴によると、記録手段は、取得した日付に関連して一定の時間長のセグメント中に分配されたパラメータ値を含む記述的メタデータファイルを記録するように構成されており、１つのパラメータおよび１つのセグメントあたり唯一のパラメータ値が記録される。
【００４５】
特定の特徴によると、記録手段は、中断無く連続しかつ構成が変わらない均一なシーケンスへと記録を分割するように構成されており、記録が再開または再構成される毎に各々の新たなシーケンスのための新しいファイルを含む新しいディレクトリが生成される。
【００４６】
特定の特徴によると、記録手段は、同一のデータを異なる複数の圧縮率および圧縮アルゴリズムで記憶するように構成されている。
【００４７】
特定の特徴によると、以上で簡潔に報告されている通りの本発明の目的である装置において、記録手段は、飛行テスト中、少なくとも１つのデータストリームのデータとそれに続いて１つのデータストリームのデータを再読取りできるようにする１つの情報ブロックとを含む複数のパーティションにファイルが分割される記録モードである「ストリーミング取得」モードでこれらのデータを記憶するように構成されている。
【００４８】
この記録モードは、ファイルが線形媒体（テープ）上で取得される場合、または取得が突然中断される危険性のある場合に用いられる。読取り可能な最後の情報ブロックの後にあるストリームのみが容易に復号することができない。かくして機内では、ファイルは、正しく閉じられなかった場合でも使用可能であるように「ストリーミング取得（streaming acquisition）」モードで取得される。これらのファイルは、予め定められた時間の長さに対応する複数のパーティションに分割される。したがってクラッシュの場合は、最後のパーティション内にあるストリームのみ復号が難しくなる。
【００４９】
特定の特徴によると、記録手段は、記録されたデータを変換して、ファイルを複数のブロックに分割する「ファイル」モードでそれらを記録するように、地上において、構成されており、このモードでは、ファイルは複数のブロックに分割され、ファイルのヘッダーおよび／またはフッターにはそのファイルの再読取りを可能にする情報が含まれ、ファイルのボディにはデータストリームに由来するデータが含まれている。
【００５０】
この記録モードは、ランダムアクセスを可能にする媒体（ハードディスクまたはコンパクトディスク）上に記録されるファイルに、より適合したものである。
【００５１】
特定の特徴によると、以上で簡潔に報告されている通りの本発明の目的である装置は、記録された異なる画像がどこにあるかを示すインデックステーブルを生成するように構成されたインデキシング手段（２３０）を有する。
【００５２】
したがってこのテーブルは、所与のストリームおよび瞬間についての画像にランダムにアクセスすることを可能にする。
【００５３】
特定の特徴によると、記録手段は、少なくとも１つのデータストリームを圧縮せずにその未加工形態で保存するように構成されている。
【００５４】
特定の特徴によると、記録手段は、「フレームワーク」の形で組織され、ユーザー向け情報で各ファイルを修飾することのできる記述メタデータを定義するように適合されている。
【００５５】
特定の特徴によると、記録手段は、パラメータ値を記述するメタデータセットリストを含む静的記述メタデータファイルを記録するように構成されている。
【００５６】
特定の特徴によると、記録手段は、１つ以上の同期化されたデータストリームのリプレイの形で、記録済みデータを供給するように構成されている。
【００５７】
第２の態様によると、本発明は、複数の記録対象データストリームソース、少なくとも１つの日付つき記録パラメータ値ソース、および少なくとも１つの不揮発性情報媒体上にデータストリームおよびパラメータ値由来のデータを記録する手段を有する航空機内で捕捉されたデータの取得および記録方法において、
−  別々のファイル内に異なるデータストリームのデータを記憶するための記録ステップと、
−  各々のファイル内の記録済みデータと前記パラメータ値を関連づけするステップと、
を含むことを特徴とする方法を目的としている。
【００５８】
本発明のその他の利点、目的および特徴は、添付図面と照らし合わせて全く限定的な意味なく説明を目的として以下に示す記述から、明らかになるものである。
【図面の簡単な説明】
【００５９】
【図１】先行技術のシステムを表わしている機能概略図である。
【図２】論理図の形で本発明の目的である装置の特定の１実施形態を表わしている。
【図３】本発明の目的である方法および装置の好ましい実施形態における、記録済みファイルの組織を概略的に表わしている。
【図４】異なる３つの記録モードにしたがって記録されたファイル構造を概略的に表わしている。
【図５】異なる３つの記録モードにしたがって記録されたファイル構造を概略的に表わしている。
【図６】異なる３つの記録モードにしたがって記録されたファイル構造を概略的に表わしている。
【図７】本発明の目的である方法および装置の特定の１実施形態において使用されるファイル構造を概略的に表わしている。
【図８】本発明の目的である方法および装置の特定の実施形態において使用される「フレームワーク」を概略的に表わしている。
【図９】本発明の目的である方法および装置の特定の実施形態において使用されるファイル構造を概略的に表わしている。
【図１０】本発明の目的である方法および装置の特定の実施形態において使用されるファイル構造を概略的に表わしている。
【図１１】本発明の目的である方法および装置の特定の実施形態において使用されるファイル構造を概略的に表わしている。
【図１２】本発明の目的である方法および装置の特定の実施形態において使用されるファイル構造を概略的に表わしている。
【図１３】本発明の目的である方法および装置の特定の実施形態において使用されるファイル構造を概略的に表わしている。
【図１４】本発明の目的である方法および装置の特定の実施形態において使用されるファイル構造を概略的に表わしている。
【図１５】本発明の目的である装置の特定の実施形態の変形形態を、論理図の形で表わしている。
【図１６】本発明の目的である装置の特定の実施形態の変形形態を、論理図の形で表わしている。
【発明を実施するための形態】
【００６０】
明細書全体において、「ディスク」という用語は、ハードディスクおよびコンパクトディスクの両方を含む。
【００６１】
図２に示されている通り、論理的観点から見て、中央サーバー２００をベースとする本発明の目的である装置の特定の１実施形態のアーキテクチャは、４つのレベルに分割される。図２の左側には、あらゆるタイプのソースからデータを取得する能力を提供するインタフェースソースが表わされている。図２は、技術的データ（donne'es me'tier）および飛行機時間２０１、カメラ２０２、グラフィックソース２０３、ＡＳＶＩソース２０４および音声ソース２０５の入力に関する。
【００６２】
次に、図２には、記録チャネル数の節約を可能にする画像モザイクを形成させるため、複数のＳＤソースを１つのＨＤ画像内に集めるのに役立つモザイク生成システムを場合によって含む切替えグリッド２０６を横断して、取得サーバーに向かってソースをルーティングできるシステムが示されている。図２の中央には、音声／ビデオストリームおよび飛行機パラメータの取得システムがある。これらのシステムは、異なるソースから送られた信号を回収し、これらをＭＸＦ（マテリアル交換フォーマットを表わす「Material eXchange Format」の頭字語）フォーマットのファイルの形に変換する役目を果たす。これら異なる取得システムは、互いに独立して機能し得る（これらを同期化する必要はない）。図２では、この部分は、マン・マシンインターフェース２１０以外に、映像取得モジュール２１１、音声取得モジュール２１２および、図中「ＭＴＤ」とも呼ばれているメタデータ（技術的データおよび飛行機時間データ）取得モジュールを含んでいる。
【００６３】
最後に、図２には、ＭＸＦフォーマットの異なるファイルを回収しそれらをディスク２２５上に記憶し、再読取りする役目を果たす合成、記憶および読取りシステムが示されている。異なるファイルは、（同期化の必要がない場合）互いに独立して書込むことができる。ファイルの同期的再読取りを可能にするため、合成ファイルが順次に生成され記録される。このために、記憶システム２２０は、合成ファイル生成モジュール２３５により合成ファイルに組込まれる外部リファレンスの生成モジュール２３０を有する。
【００６４】
好ましくは、本発明によると、ＭＸＦ規格のファイルフォーマットを使用し、ＩＥＶのニーズに適合されたこのフォーマットが提供する機能を選択する。ＭＸＦフォーマットは、公開され、進化しており（したがって数多くの異なる映像フォーマットおよびコーデックを管理できる）、採用数が増大しており、規格化され独立した（したがって永続的で相互運用可能な）フォーマットである。これは、制作後、インデキシングそしてアーカイビングを通って取得から配信までの全制作ラインにわたり交換フォーマットとして利用可能である。
【００６５】
ＭＸＦフォーマットは進化可能である。新たな諸問題に対処するため新しい規格および勧告が書込まれている。かくして、コンテナ「Ｊｐｅｇ２ｋ」を記述するために、近年、「４２２Ｍ」規格が追加された。「Ｈ．２６４」については、勧告「ＲＰ２００８」が「３８１Ｍ」規格を補完している。「ＶＣ−１」および「ＶＣ−３」については、規格を記述中である。
【００６６】
ＭＦＸフォーマットは、特に以下のようなＩＥＶの制約を満たすメカニズムを提供する。
−  ファイルモードおよび異なるストリーミングモードの管理。
−  外部リファレンスのサポート。
−  異なるタイプの任意数のストリームの同期化。
−  ランダムアクセスのための包括的メカニズム。
−  きわめて進化したメタデータ管理。すなわち、静的および動的メタデータ管理、メタデータの範囲すなわち幅広いニーズを網羅する規格化されたメタデータ「フレームワーク」の管理、プロプライエタリメタデータ「フレームワーク」を定義する能力。
【００６７】
実際、本発明の重要なポイントは、より一般的な利用のためＩＥＶおよび航空術のニーズに適合する、プロプライエタリメタデータの「フレームワーク」の利用および定義にある。
【００６８】
ここで、「フレームワーク」というのは、アプリケーションの迅速な開発を可能にするライブラリセットであるということを換起しておく。フレームワークは、完全なアプリケーションを生成できるのに充分なソフトウェアモジュールを提供する。これらのコンポーネントは、特に「アーバニゼーション（urbanisation）技術」と呼ばれる技術にしたがって互いに相互作用させて利用されるべく組織される。
【００６９】
この用語をフランス語化する試みがなされてきた。かくして、ケベックフランス語局により提案された「Cadre d’application（アプリケーションフレーム）」または「cadriciel（フレームワーク）」といった用語を目にすることがある。
【００７０】
「フレームワーク」は、ソフトウェアシステムの全体または一部の生成を容易にする機能セットを、ならびに、対象のドメインをモジュールに分割することによってアーキテクチャガイドを提供する。「フレームワーク」は通常、オブジェクト指向言語を用いて実現されるが、これが厳密に必要であるわけではない。すなわち、オブジェクト「フレームワーク」は、かくして、対象のドメインをクラスに分割し、各クラスの責任ならびにクラス間の協力を定義することによってアーキテクチャガイドを提供する。これらのクラスのサブセットは抽象型クラスであり得る。
【００７１】
ソフトウェアライブラリ（biblioteque logicielle）という用語の使用が、いわゆるライブラリ（librairie）に限定されるとしても、「フレームワーク」という用語を、この（階層組織の）ライブラリ（biblioteque）のために推奨されたソフトウェアアーキテクチャ、ひいては、たとえ異なる「フレームワーク」を管理できるにせよ、そのまわりに構築された開発環境をも含み入れるように拡張して用いることが可能である。
【００７２】
以下のような異なるタイプの「フレームワーク」がある。
−  システムインフラストラクチャ「フレームワーク」。オペレーティングシステム、グラフィックインタフェース、通信ツールを開発するためのもの。
−  ミドルウェア統合「フレームワーク」。不均一なアプリケーションを連合させるためのもの。異なる技術を唯一のインタフェースの形で利用可能にするためのもの。
−  企業「フレームワーク」。企業の活動部門に特定的なアプリケーションを開発するためのもの。
−  コンテンツ管理システム指向型「フレームワーク」。
【００７３】
これらの「フレームワーク」の主な利点は、それらのコードの再利用、ソフトウェアのライフサイクル（仕様、開発、メンテナンス、進化）の標準化にあり、これらによって、企業のニーズに適合したアーキテクチャをフォーマット化することが可能となる。これらのフレームワークは、以前の開発経験を利用する。これらの「フレームワーク」は、いわば、極めて柔軟でかつ進化するソフトウェアパッケージ（progiciels）である。
【００７４】
もう１つの重要な面は、次のような企図されているソースの多様性にある。
−  ＳＤソース。ＰＡＬおよびＮＴＳＣ解像度。
−  ＨＤソース。解像度１９２０×１０８０、毎秒５０画像、他。
−  ＡＳＶＩ（アビオニック・シリアルビデオインタフェースを表わす「Avionic serial video interface」の頭字語）または「Ａｒｉｎｃ８１８」ソース。解像度１０２４×７６８、６０ｐ、すなわち進行性モードで毎秒６０画像。
−  ＶＧＡ、ＳＶＧＡ（スーパービデオグラフィクスアレイを表わす「super video graphics array」の頭字語）およびＸＧＡ（拡張グラフィクスアレイを表わす「extended graphics array」の頭字語）ソース。解像度６４０×４８０〜１２８０×１０２４、６０ｐ。
−  アナログまたはデジタル音声ソース。
−  飛行機パラメータデータソース。約５０のパラメータ、例えば毎秒５件の取得といった頻度、あらゆるタイプのはるかに多くのデータを取得することも可能。
−  その他のタイプのソース。
【００７５】
異なるソースは同期していないという点に留意されたい。
【００７６】
オプションとして、切替えグリッドによって、同じ場所にブランチをグループ化し、記録したいカメラを選択すること（一般に利用可能な記録チャネルより多くのカメラが存在する）が可能となる。単一のＳＤ／ＨＤ−ＳＤＩグリッドしか必要でないという点に留意されたい。このグリッドは非同期ソースを管理し、例えば映像視覚化スクリーン上に表示されたメニューである制御用ＩＨＭにより駆動される。
【００７７】
モザイク発生器を使うと、モザイクを用いて同一の記録チャネル上に複数のカメラをグループ化することができる。例えば、品質を著しく損失することなく唯一のＨＤチャネル上に複数のＳＤカメラをグループ化することができる。
【００７８】
音声／ビデオストリームの取得は、以下の複数のステップからなる。
−  いわゆるストリームの取得。
−  これらのストリームの圧縮。
−  これらのストリームの日付記入。
−  圧縮され日付記入されたストリームの、ＭＸＦフォーマットのファイル内へのパッケージング。
【００７９】
圧縮は、採用されたコーデック（「符号器」および「復号器」という用語を短縮したもの）の１つに応じて行なわれる。高品質での最初の圧縮が、記憶モジュールに向かって転送されるストリームのスループットを制限するべく、取得サーバーによってリアルタイムで実施される。プロキシ品質での第２の圧縮は、可能であれば、地上でのプロキシの生成ステップを回避するべく同時に実施される。ソースおよび求める品質に応じて、同一サーバーの内部で複数のコーデックを利用することができる。
【００８０】
異なるストリームは時間的に精確に符号化される、つまり「タイムコード化」される。すなわち、およそ１つの画像の時間の長さのオーダーの精度で、それが取得された時点に応じて日付記入される。次のような複数の方法が考えられている。
−  ＧＭＴ／ＡＥＳタイムコード（Timecode ＡＥＳ）変換器が、記録手段の上流側に設置される。これらの記録手段には、ＡＥＳタイムコードに応じて取得された画像に日付を記入することのできるＡＥＳタイムコード入力が具備されている。ＡＥＳタイムコードに基づく日付記入は、市販の全ての映像取得サーバー上で利用可能であることから、この方法を直接適合させることができる。この方法は専らハードウェアに基礎をおき、したがってより精確である。反対に、これは、ハードウェアタイプのＧＭＴ／ＡＥＳタイムコード（Timecode ＡＥＳ）変換器の開発を必要とし、故障に弱い（変換器の故障またはＡＥＳ信号の伝送の問題の場合、日付記入は不可能になる）。
−  サーバーの内部クロックをベースとする方法。取得サーバーの内部クロックを、飛行機パラメータ取得ラック上と同じメカニズムを用いることによってかまたは機上コンピュータのＮＴＰ（ネットワーク上日付記入プロトコルを表わす「Network Time Protocol」の頭字語）サーバーを用いることにより、飛行機のクロックと同期化させることができる。例えば、内部クロックの時間合わせは、外部ＮＴＰサーバーによってかまたは、ＡＥＳタイムコード入力からＧＭＴ／ＡＥＳタイムコード（Timecode ＡＥＳ）変換器によって行なうことができる。
【００８１】
これらの時間データを使って、記録手段は、同期化された１つ以上のデータストリームのリプレイの形で、記録されたデータを提供するように構成される。
【００８２】
市販の取得ボード（carte（カード））は、取得された画像に日付を記入するためにその固有のクロックを利用する。したがって、取得ボードのクロックとサーバーの内部クロックの間で対応させかくしてサーバーの内部クロックに応じて映像に日付記入することができるように取得ソフトウェアのモジュールを開発しなくてはならない。したがって、この方法には、取得ソフトウェアのわずかな適合が必要であるが、反対に特定のハードウェアを必要としない。この方法は、より故障に強い（同期化が喪失した場合でも、サーバーの内部クロックは数日間にわたり充分精確に利用可能である）。
【００８３】
日付記入方法は、取得機器（カメラ、マイク他）と取得サーバーとの間のルーティングシステムによって誘発される伝送待ち時間を考慮に入れる。この待ち時間は実際には、直接的伝送の場合ゼロであるが、モザイク発生器を介して行なわれる場合、画像数個分のずれに達し得る。この待ち時間はわかっているため、公知の技術にしたがって、装置により補償される。
【００８４】
各ストリームは、原子ＭＸＦフォーマット（format MXF atomique）のファイル内に順次パッケージングされる。このファイルは、飛行機、テストおよびデータソースについて記述する静的メタデータ、取得されたストリームを含む音声または映像トラックおよび各画像の日付を含む動的な時間コードつまり「タイムコード」トラックを含んでいる。このトラックは、図７に照らして詳述されている機内ファイルのために選択された構造にしたがう。
【００８５】
変形形態として、サーバーに予備記録機能が組込まれていてよい。すなわち、記録が活動化されていない場合、圧縮され日付記入されたストリームは一時スペース内、好ましくはランダムアクセスメモリー内に記憶され、一定時間保存される。記録が開始された場合、これらのストリームは、生成されたＭＸＦフォーマットのファイルに統合される。
【００８６】
飛行機パラメータの取得では、次の複数のステップがグループ化されている。
−  データ送信システムへの接続の確立。
−  データ送信システムによって提供されたパラメータ（取得値および取得日付）の取得。
−  その取得日付に応じたこれらのパラメータのソート。
−  ＭＸＦフォーマットのファイル内へのパッケージング。
【００８７】
最初の２つのステップは、標準的データ発信システムにおける１クライアントの実行に対応する。これらのステップによって、パラメータリストに加入し、これらのパラメータ（名前、単位）についての一般的情報を回収し、次に規則的な時間的間隔で全ての工業値つまりこれらのパラメータについて測定された直接処理可能な値をそれらの取得日付と共に回収できる。
【００８８】
第３のステップは、映像ＩＥＶに特定的なものである。このステップにより、パラメータを時間的に再構成し、音声／ビデオストリームと同じ要領でそれらを記憶し処理できるようになる。音声／ビデオストリームは実際、一定の持続時間のセグメントに分割され、この持続時間は一般に、例えば２５画像／秒で１つの映像について４０ｍｓといったような、画像のフレームの周期または周波数つまり「フレームレート」に対応する。パラメータ取得ソフトウェアは、時間を（パラメータのために望まれる周波数に対応する）一定の時間長の時間セグメントに分割し、各セグメントおよび各パラメータについて、この時間セグメントの間に取得されたそのパラメータの最新の値（またはこの時間セグメント中に全く取得されなかった場合には、処理可能な最終値）を保存する。
【００８９】
このように生成された時間セグメントは、原子ＭＸＦフォーマットのファイル内に順次パッケージングされる。このファイルは、飛行機およびテストについて記述する静的メタデータならびに取得された異なるパラメータを含む。このファイルは同様に、各時間セグメントについて採用されたパラメータの値および取得日付が中に記録される一定の時間長のセグメントに分割された動的メタデータトラックをも含んでいる。このファイルは、図７に照らして詳述される構造である、機内ファイル用に採用された構造に従っている。
【００９０】
音声／ビデオストリームの場合と同様に、予備記録機能が、取得ソフトウェアに組込まれている。
【００９１】
シーケンスの記憶および管理に関しては、異なる取得に由来するＭＸＦフォーマットのファイルが、少なくとも１つの記憶用ディスク上に記録される。各ファイルは、生成されると順次、唯一のディスク上に記録される。
【００９２】
好ましくは、各ディスクは全てのファイルのコピーを記録する。しかしながら、異なるファイルの累積スループットが単一のディスクがサポートするスループットに比べて大きすぎる場合、必要なだけのディスクを使用して一部のファイルを１枚のディスクにそして一部のファイルを別のディスクに記録することにより、スループットを複数のディスク上に分配する。
【００９３】
次の表は、必要なファイルの容量とスループットの例を示す。
【表１】
0005580734.tif 000002
【００９４】
１つのソフトウェアが、異なる取得に由来するファイルを精査し、これらのファイルを同期的に参照し再読取りすることのできる合成ＭＸＦフォーマットのファイルを生成する。このファイルは、他で取得したファイルを各々指し示す外部リファレンスを含む。このファイルは、飛行機およびテストについて記述する静的メタデータ、ならびに各ファイルに特定的な静的メタデータ（カメラの識別子、パラメータの記述）のコピーを含む。このファイルは小さいもののきわめて重要であるため、規則的な時間的間隔で、好ましくは２枚の異なるディスク上の異なる場所で、完全に再書込みされる。かくして、第２の記憶システムが故障した場合でも、正しいファイルがつねに利用可能である。
【００９５】
地上への転送を容易にするため、好ましくは、同一のディレクトリ内（またはファイルが複数のディスク上に分配している場合には同じ名前をもつ複数のディレクトリ内）に、同時に取得したファイルを記録する。
【００９６】
飛行テスト中、記録を停止、再開または再構成することが可能である。好ましくは、処理を容易にするため、図３に例示されているように、記録を連続した、すなわち中断の無い、均一なすなわち構成が変わらないシーケンス３０５、３１０、３１５、３５５、３６０および３６５に再分割する。したがって、ここでは切替え３７０の後であるその理由（カメラの切替え、ディスク変更、クラッシュの後の再開）の如何を問わず、記録が中断３２０の後で再開されるかまたは再構成される毎に、各々の新しいシーケンスのための新しいファイルを伴う新しいディレクトリが作成される。
【００９７】
マン・マシンインタフェース（「ＩＨＭ」）に関しては、ユーザーはこのインタフェースを使って、記録したいソースを修正することができる。非同期であることによって妨げられることなくソース切替えを実施するために、次の２つの解決法が考えられる。
−  第１の変形形態においては、画像の喪失を回避するために全てのＳＤＩソースを同期化させる。この解決法には、同期化ハードウェアまたは「再クロッキング」機能を備えた切替えグリッドの設置が含まれる。
−  第２の変形形態においては、切替えの前に記録を停止させ、切替えの後に再開させる。これには、切替えられたチャネル上において複数の画像の喪失が関与するが、ハードウェアの適合は必要でない。記録の停止および再開は、ユーザーに見える形で、映像サーバーによって自動的に実施される。
【００９８】
「クラッシュ」および故障の影響を制限するために、次のことを想定する。
−  クラッシュ時のデータ喪失を制限することのできる「ストリーミング」モードすなわち連続モードでのＭＸＦフォーマットファイルの生成。
−  エラー時の再起動機能。エラーの場合自動的に取得が再スタートする。
−  テスト前の映像ＩＥＤの状態を確認する診断機能。
−  警報を発し、場合によっては関係するチャネルの取得を停止させる、テスト中の故障（信号喪失、画像の喪失または凍結（gel（フリーズ））、取得、日付記入または記憶システムの問題）の検出機能。
【００９９】
選択されたファイルフォーマットに関しては、映像ＩＥＶの枠内で利用されるファイルは、複数のタイプの映像および音声ストリーム、すなわちＳＤ映像（ＰＡＬおよびＮＴＳＣフォーマット）、ＨＤ映像（７２０ｐおよび１０８０ｉタイプのフォーマット）、コンピュータから来る映像（ＶＧＡタイプのフォーマット）、およびコックピットから来る映像、音声、将来のニーズ由来のその他のデータを記憶できるようにする。
【０１００】
これらのストリームは、その転送に必要なスループットおよびその記憶に必要な容量を制限するべく圧縮される。複数の異なるコーデックが、画像の数量とファイルのサイズとの間の良好な妥協を得る目的で使用される。この妥協は、ファイルの処理モードに応じて変わってもよく、複数の異なる圧縮率すなわち低圧縮（作業領域上での処理のための高品質映像）および／または高圧縮（個々のワークステーション上での処理向けのプロキシ）で同じ映像を記憶することが必要となることもある。
【０１０１】
ファイルは、これらの標準メタデータ（権利、題名、参加者、…）の音声／ビデオストリームの文書化を可能にする。ファイルは、同様に、全てのストリームに適用される（飛行機およびフライトの記述）または一部のストリームのみに適用される（カメラの記述等）技術的メタデータを記憶することをも可能にする。これらのメタデータはデータベース内で容易に修正されインデキシングされる。
【０１０２】
最後に、これらのファイルは同様に、動的メタデータの形で記憶されるパラメータストリーム（飛行機パラメータ）を記憶するためにも利用される。
【０１０３】
異なるソースから来る異なる音声／ビデオストリームは、複数の異なるプロセス（さらには複数の異なるマシン）により取得される。これらのプロセスを同期化し、取得された異なるストリームを単一のファイル内にグループ化させることは困難である。したがって、異なるストリームを非同期的に、別々のファイル内（１プロセスあたり少なくとも１つのファイル）で取得することが好ましい。この場合には、後で同期化できるようにするため、各ストリームに精確にタイムスタンプする。
【０１０４】
先に記した通り、機内アーキテクチャの中で使用されるディスクのスループットは時として異なるストリームの累積スループットをサポートするには不充分であることから、場合によって、スループットを複数のディスク上に分配する。
【０１０５】
取得プロセスは、多数の理由（給電中止、ディスク満杯、ハードウェアまたはソフトウェアの問題等）で突然停止させられる可能性がある。この場合、ファイルは、たとえ正しく閉じられていなくても、利用することができる。したがって、ファイルはストリーミングモードで、すなわち、ファイルの再読取りを可能にするきわめて重要な情報を規則的に書込むことによって取得される。
【０１０６】
最後に、ストリームの数およびソースを変更すること（映像ソースの変更）が可能である。これらの変更は、ファイル内でメタデータを介して「追跡（trace's）」される。ファイルは確認され、地上への転送に際して再度フォーマットすることができる。この目的で、ファイルの確認および操作機能を利用できる。
【０１０７】
先行技術においては存在しなかった本発明を使用することの重要な利点は、ネットワークを介して個別にストリームを処理できるという点にある。好ましくは、１ファイルあたりストリーム数を１として、ネットワークに負荷をかけ過ぎないようにする。
【０１０８】
先行技術の場合のように、ストリームを集合的に（作業領域上で）処理することもできる。選択されたファイルフォーマットによって、複数のファイル内に入った複数の日付つきファイルを関連づけし、参照し、かつ同期化して、これらの異なるストリームを完全に同期的に再読取りすることができる。
【０１０９】
その処理モードの如何に関わらず、ユーザーは、映像内を高速で移動し、記録上の正確な瞬間に迅速にアクセスできることを望む。採用されたファイルは、画像へのランダムアクセスを可能にする。
【０１１０】
その上、テストに由来する映像は、細心の注意が必要なデータを構成する。採用されたファイルフォーマットにより、データの機密性を確保することができる。ファイルフォーマットには、例えば、以下のものがある。
−  「ストリーミング」モードで処理され得る。すなわちこの場合、ファイルは、ネットワークによりユーザーまで配信されるが、ユーザーはそれをコピーできない。
−  読取りできなくなるように、暗号化され得る。
【０１１１】
ユーザーは同様に、許可の後、映像の一部分を抽出し、そこにデータをオーバレイし、それを外部用途のためにエキスポートすることを望む可能性がある。採用されたファイルのタイプは、「部分的回復」、所与の時間範囲内での一部のストリームの抽出、テキストオーバーレイ、解凍／再圧縮メカニズムをサポートする。
【０１１２】
コーデックに関しては、以上で記述したアーキテクチャは、例えば「Ｍｐｅｇ４ＡＶＣ（Ｈ．２６４）」、「ＶＣ−１」、「Ｊｐｅｇ２ｋ」、「Ｍｐｅｇ２」、コーデック「Ｄｉｒａｃ」および「Ｈ．２６５」などの異なるコーデックを同時に使用できるようにする。
【０１１３】
記録モードに関しては、ＭＸＦファイルフォーマットは、次のような複数の異なるモードでストリームを記憶できるようにする。
−  図４に例示されているように、ファイルが２つまたは３つのブロックに分割されている「ファイル」モード。ファイルのヘッダー４０５（英語で「header」）および／またはフッター４１０（英語で「footer」）は、そのファイルの再読取りを可能にする情報を含む。ファイルのボディ４１５は、ストリームを含む。このモードは、ファイルが、ランダムアクセスを可能にする媒体（ディスクまたはＣＤ）上に記憶されている場合に用いられる。
−  図５に例示されているように、ファイルが複数のパーティションに分割される「streaming acquisition（ストリーミング取得）」（フランス語ではacquisition continue（連続取得））モード。各パーティションは、取得されたストリーム５０５および５１５と、それらに続く、これらのストリームを再読取りできるようにする情報ブロック５１０および５２０とを含む。このモードは、ファイルが線形媒体（テープ）上で取得される場合、または取得が急激に中断される危険性がある場合に用いられる。読取り可能な最後の情報ブロックの後に位置するストリームのみが、容易に復号され得ない。
−  図６に例示されている通り、ファイルが複数のパーティションに分割される、「ストリーミングレクチャー（streaming lecture）」モード。各々のパーティションは、取得されたストリーム６１０および６２０と、それらに先行しこれらのストリームを読取ることができるようにする情報ブロック６０５および６１５とを含む。このモードは、ファイルを線形媒体（テープ）から再読取りしなければならない場合、またはケーブルもしくは電波によりネットワーク上でファイルを配信しなければならない場合に、用いられる。読取り可能な最初の情報ブロックに先行するストリームのみ容易な復号が不能になる。
【０１１４】
本発明の使用にあたっては、「ストリーミング取得」およびファイルモードがそれぞれ機内および地上で使用される。
【０１１５】
同期化メカニズムに関しては、ＭＸＦファイルフォーマットは、任意の数のストリームを、そのタイプおよびファイル（単複）内の分配の如何に関わらず、同期化できるようにする同期化メカニズムを提供する。
【０１１６】
外部リファレンスに関しては、ＭＸＦフォーマットによって、「原子」ファイルと呼ばれる異なるファイル内に音声／映像シーケンスを構成できる異なるストリームを記憶し、再読取りされるべきストリームを含むファイルを参照する「合成ファイル」と呼ばれるファイルを構築することができる。各ストリームは、別々のファイルの中に記憶される。合成ファイルは各々の配信について構築される。合成ファイルによって、どのストリームを配信すべきかが示される。このメカニズムにより、異なるファイル内でストリームを記録し処理できるようになる。
【０１１７】
メタデータの管理に関しては、ＭＸＦフォーマットによって、標準的メタデータ（題名、権利保持者）および「プロプライエタリ」と呼ばれるさらに特定的なメタデータ（飛行機およびテストの記述）を管理することができる。さらに、飛行テストに対する本発明の応用において用いられるファイルは、単一のストリーム（１つのソースの記述）にしか適用されないメタデータを含む。最後に、ＭＸＦフォーマットによって、飛行機パラメータを記憶するため、動的メタデータを定義することができる。
【０１１８】
物理的構造に関するＭＸＦフォーマットの利点としては、以下のことが挙げられる。
−  これは、異なるストリーム内に記録された異なる画像がどこにあるかを示すインデックステーブルの使用を可能にする。したがって、このインデックステーブルにより、所与のストリームおよび瞬間に対する画像にランダムにアクセスすることができる。
−  これは、未加工形態のストリーム、すなわち音声および／またはビデオストリーム、動的要素（不連続タイムコードおよび／または動的メタデータ）を含むエッセンスコンテナの使用を可能にする。これらのストリームは、一般に、１つの画像または１つのＧＯＰ（画像群を表わす「group of picture」の頭字語）の持続時間である一定の時間長に対応する断片にカットされ、この場合「フレームラッピング」と言う。同様に、（シーケンスの包括的持続時間に対応する）ブロックとしてストリームをパッケージングすることもでき、この場合、「クリップ−ラッピング」と言う。
【０１１９】
論理構造に関するＭＸＦフォーマットの利点については、その物理的構造から独立したＭＸＦフォーマットのファイルの論理構造の利点を挙げることができる。したがって、タイプおよび場所の如何に関わらず、異なるストリームとメタデータとを組織し同期化することが可能である。
【０１２０】
メタデータの管理に関しては、ＭＸＦフォーマットのファイルは、構造メタデータおよび記述メタデータを同時に定義できる唯一のメタデータモデルを利用する。構造メタデータは、ファイルの論理構造を記述できるきわめて重要な情報、ならびにその新規作成および修正の痕跡を保つことのできる一部の情報をグループ化している。これらのメタデータは必須で規格化されている。記述メタデータは、ユーザー向けの情報でファイルを修飾することができる。それらは任意である。それらは、「フレームワーク」の形で組織されている。
【０１２１】
３つのメタデータ「フレームワーク」がすでに、音声映像技術のニーズを満たすために「ＤＭＳ−１」の名前で規格化された。同様に、プロプライエタリメタデータ「フレームワーク」を定義し使用することもできる（この場合「ダークメタデータ（Dark Metadata）と言う）。ＭＸＦフォーマットを使用する一部のソフトウェアは、ＤＭＳ−１「フレームワーク」の中味の視覚化を可能にし、かつそれらをＸＭＬ（拡張可能マークアップ言語を表わす「extensible markup language」の頭字語）のファイルの形でインポートおよびエキスポートすることができる。反対に、これらのソフトウェアは、プロプライエタリ「フレームワーク」を無視するが、だからといってそれを削除するわけではない。
【０１２２】
日付記入および同期化のメカニズムに関しては、ＭＸＦフォーマットは、異なるストリームの日付記入および同期化を可能にする。各トラック（音声／ビデオストリームまたは動的メタデータ）はその固有の時間ベース（「フレームレート」）および起点を有する。ＭＸＦフォーマットのファイルの読取り装置は、以下のメカニズムにより絶対時間からのデータへのランダムアクセスを可能にする。すなわち、各トラックについて、トラックの時間ベースに応じて絶対時間がタイムコードに変換される。このとき、インデックステーブルによって、ＧＯＰ構造の中でさえこのタイムコードに関連づけされた画像を探し出すことができる。このメカニズムにより、トラックが同じ時間ベースを使用しない場合でさえ、トラックの同期的読取りを行なうことが可能である。
【０１２３】
ＭＸＦフォーマットのファイルは、特に以下のような一部のより特定的な機能性を管理できるようにする。
−  「Partial restore（部分的回復）」。これは、ＭＸＦフォーマットのファイルから、所与の時間範囲にわたりストリームおよびメタデータを抽出し、これらを未加工ファイルの形でまたは別のＭＸＦフォーマットファイル内に記録することのできるメカニズムである。
−  「Cryptage ＡＥＳ（ＡＥＳ暗号化）」：ＭＸＦフォーマットのファイル内のエッセンスを、ＡＥＳアルゴリズムを用いて暗号化することができる。
【０１２４】
相互運用性の問題を回避するため、好ましくは、例えば「Ｏｐ１ａ」タイプなどの単純かつ広く普及している構造を有し、規格を完全に遵守しているファイルが制作される（ＩＲＴ（登録商標「Institut fur Rundfunktechnik」の頭字語）の「アナライザ（analyserまたはanalyzer）」と呼ばれるＭＸＦフォーマットを使用するソフトウェアなどのツールにより、規格とファイルの非互換性を検出できる）。
【０１２５】
好ましくは、本発明を使用するために、異なる複数のファイル内にストリームを記録し、このことには以下のような利点がある。
−  機内では、ファイルは異なるプロセスにより生成され、異なる複数のディスク上に記録可能である。
−  地上では、別々のファイル内に異なるストリームを記憶することによって、リクエストに応じてファイルのサイズおよび処理すべきデータの量を制限することが可能であり、例えば要求されたストリームを含むファイルのみをニアラインで渡せばすむ。ここで、「ニアライン」というのは、ランダムアクセスデータ媒体上と同様、シーケンシャルアクセス媒体上にアーカイブされたデータを迅速に利用できるようにする高速アクセスシステムのことであるという点を喚起しておく。
【０１２６】
１実施形態においては、ストリームの原子化および図７に示されているファイル構造の利用が実施される。
【０１２７】
図７を見れば分かるように、以下の２つのタイプのファイルが用いられる。
−  各々が唯一つのストリーム（高品質映像、プロキシ映像、音声または動的メタデータ）、テストおよびストリームについての情報を与える静的メタデータ（飛行機およびフライトの識別子）および（カメラ、マイクまたはパラメータ記述の識別子）を含む原子ファイル７０５〜７３０。原子ファイル７０５〜７３０は、個別に利用され得る。
−  ストリームを含む異なるファイル７０５〜７３０を参照する合成ファイル７３５。合成ファイル７３５は、それだけで、飛行テストおよび異なるストリームについての全ての情報を得ることを可能にする。すなわち合成ファイル７３５は、テストについての情報を与える静的メタデータ（飛行機とフライトの識別子）および各ソースについての情報を与える静的メタデータ（カメラ、マイクの識別子またはパラメータ記述）を含む。合成ファイル７３５はまた、同期的にこれらの異なるストリームを処理することも可能にする。
【０１２８】
「メタデータフレームワーク」に関しては、ＭＸＦフォーマットの異なるファイルは、静的記述メタデータ（権利、飛行機の識別子…）そして時として飛行機のニーズすなわち飛行機上で行なわれるテストタイプに応じて速度または圧力といったような測定されたいくつかのパラメータを関連づけするニーズに応える動的記述メタデータ（飛行機パラメータ）を含む。
【０１２９】
極秘でない標準的な静的メタデータについては、規格化された「ＤＭＳ−１」フレームワークを利用できることが分かる。これらのメタデータは、実際、ＭＸＦフォーマットを使用する一部のソフトウェア中で参照できる。例えば、権利保持者およびその連絡先を表示するためには「フレームワーク制作（production framework）」が利用される。
【０１３０】
同様に、静的技術的メタデータ（飛行機、フライト、カメラおよびマイクの識別子、パラメータ記述）を記憶するために、間接的にＤＭＳ−１「フレームワーク」を利用することもできる。例えば、飛行機およびカメラを識別し、かくしてＭＸＦフォーマットを使用するソフトウェアの大部分の中でそれらを視覚化できるようにするために、「シーンフレームワーク（scene framework）」を利用することができる。
【０１３１】
好ましい実施形態においては、静的技術的メタデータに所望のタイプおよび名前をその通りに与え、かくしてこれらの視覚化、編集そしてインデキシングを可能にすることから、これらの静的技術的メタデータのためにプロプライエタリフレームワークが利用される。
【０１３２】
さらに、このプロプライエタリ「フレームワーク」は、これらのパラメータを記憶するのに必要なオクテット（バイト）数を著しく制限できる（間接的ＤＭＳ−１フレームワークの場合の数百オクテットに代わって、１パラメータあたり約１６オクテット）ことから、飛行機パラメータデータの記憶に適合している。
【０１３３】
プロプライエタリ「フレームワーク」を利用することによって、さらに或る種の機密性を確保することができる。実際、それが含むメタデータは、市販のＭＸＦフォーマットを使用するソフトウェアによって無視される。プロプライエタリフレームワークを記述するスキームを用いて修正または構成されたソフトウェアのみがこれらのメタデータを解釈できる。
【０１３４】
実施形態においては、図８にその構造が示されているフレームワークが使用される。かかる「フレームワーク」８０５は、次のような静的メタデータを記憶することを可能にする。
−  飛行機タイプおよび飛行機の識別子、ブロック８１０。
−  フライトタイプ（静的テスト、飛行テスト、営業フライト）およびフライト番号、ブロック８１５。
−  ソースの識別子、例えばタイプ、一意的に機器を識別するＰ／Ｎ（部品番号を表わす「Part Number」の頭字語）、機器の通し番号を識別するＳ／Ｎ（通し番号を表わす「Serial Number」の頭字語）、題名および専用スペース、ブロック８２０。
−  ソースに関する補足的注釈、ブロック８２５。
−  フライトについておよび各記録についてのＵＴＣで表わした時間範囲（協定世界時、ＵＴＣは「coordinated universal time」を表わす英語「ＣＵＴ」とフランス語「ＴＵＣ」の間の妥協案である）、ブロック８３０。
【０１３５】
この「フレームワーク」はさらに、例えばＥＶＳ（強化視覚システムを表わす「Enhanced Vision System」の頭字語）のために飛行機パラメータおよび各ソースに固有のパラメータ、例えば、地平線の計算上の位置、利得値、着氷除去、モード、ＧＰＳ（全地球測位システムを表わす「Global Positioning System」の頭字語）位置、を記憶できるようにする。
−  各パラメータの記述は静的に記憶され、ＵＬ（汎用ラベルを表わす「Universal Label」の頭字語）が関連付けられる、ブロック８３５。
−  パラメータサンプルは動的に記憶される、ブロック８４０。これらのサンプルは、必要なスペースを制限するため、各パラメータのＧＭＴ時間（取得日付）および値（無単位）しか含まない。これらのサンプルは、パラメータの名前および単位を検出できるようにＵＬを介してパラメータの記述子を参照する。
【０１３６】
このフレームワーク８０５は、以下で報告する通り、飛行テスト以外の航空技術アプリケーションを満足させるように設計されている。
【０１３７】
音声／映像ファイルの構造に関しては、各々の音声またはビデオストリームは、図９に示されている別ファイル９０５の中に記憶される。このファイルは、ＭＸＦフォーマットを使用する編集ソフトウェアまたは読取り装置の中で個別に利用可能である。
【０１３８】
したがって、これらのファイルは、音声またはビデオストリーム９１５および場合によっては不連続な（図示していない）１本のタイムコードトラックを含む単一の「ソースパッケージ（source package）」９１０、およびこのストリーム全体をリプレイできるようにする単一の「マテリアルパッケージ（material package）」９２０しか含まない。マテリアルパッケージ９２０は、出力端で要求される形態すなわち従来の映像読取り装置が読取る形態を有する。この構造の要素は所定の場所に置かれ、未加工データ「ソースパッケージ」に、「ファイルパッケージ」（フランス語ではfichier d’assemblage（アセンブリングファイル）と訳すことができる）」を介しリンクされる。この論理的表現は非常にコンパクトなものである。すなわち、１つの典型的「ファイルパッケージ」がおよそ１ｋｏ（１ｋＢ）に対応し、一方それが表わしているエッセンスは数メガオクテット、ギガオクテットさらにはテラオクテットであり得る。
【０１３９】
「Ｏｐ１ａ」構造は、単純でかつ広く普及しているために好適であり、優れた相互運用性を確保できる（ファイルは、ＭＸＦフォーマットを使用するほぼ全ての読取り装置および編集ソフトウェアにおいて利用可能である）。規格化中である「Ｏｐ０」構造は、記録中の読取り機能を最適化できることから、結局は有利であり得る。
【０１４０】
これらのファイルは、以下のような２つの異なる物理的構造を有し得る。
−  機内では、図１０で示されているように、ファイル１００５は、たとえ正しく閉じられていなかったとしても利用可能となるように、「ストリーミング取得」モードで取得される。これらのファイルは、選択された持続時間に対応する複数のパーティション１０１０、１０１５および１０２０に分割される。かくして、クラッシュ時に容易に復号できないのは、最後のパーティション１０２０内にあるストリームのみになる。各パーティションは、メタデータツリー１０２５とエッセンスコンテナ１０３０で構成されている。各々のメタデータツリー１０２５は、（ファイルの論理構造を与える）構造メタデータ、および静的記述メタデータ（権利、飛行機およびフライトの識別子、カメラまたはマイクの識別子）を含む。各エッセンスコンテナ１０３０は、ファイルを正しく伝送することができるようにするデータ（例えばパーティションのサイズ、ストリーム内のその位置についての情報）と共に、一定長の時間（１つの画像または１つのＧＯＰ）にわたり「フレームラッピング」モードでストリームをパッケージングする。地上では、図１１に示されている通り、ファイルは、「ファイル」モードに変換される。結果として得られたファイル１１０５は、もはやパーテイションヘッダー１１１０とパーテイションフッター１１０５しか含まない。これらのパーティションは、構造メタデータおよび静的記述メタデータを集めたメタデータツリー１１２０を含む。唯一のブロック１１３０で、（場合によって暗号化された）ストリームを「クリップラッピング」でパッケージングするために、唯一のエッセンスコンテナ１１２５が利用される。それ自体公知の技術にしたがって、各画像の高速アクセスを可能にするために、インデックステーブル１１３５が自動的に追加される。
【０１４１】
動的メタデータファイルに関しては、飛行機パラメータおよびその他の関連づけすべきデータを含むこのファイルは、音声／ビデオストリームを含むファイルと同じ論理および物理構造にしたがう。
【０１４２】
しかしながら、パッケージングされたメタデータとストリームに関してはいくつかの差異が存在する。この差異についてここで図１２に照らして説明する。第１の差異は、静的記述メタデータに関係する。音声／映像ソースを識別するメタデータセット（英語で「set」）は、パラメータを記述するメタデータセットのアセンブリまたはリスト１２０５〜１２２０により置き換えられる。各々のパラメータ記述子セットは、パラメータの名前、記述および単位、ならびに、ＵＬ（Universal Label）すなわち各パラメータに対する異なる識別子を記憶する。
【０１４３】
第２の差異は、エッセンスに関するものである。音声／ビデオストリームは、「タイムライン（timeline）」タイプの動的メタデータトラック１２２５により置換される。ここでタイムラインは、パラメータサンプルを含むデータの日付記入方法である。これらのパラメータサンプルはソートされ、（サーバーによる受領日付に応じてではなく）その取得日付に応じて、一定の持続時間（例えば５ｐｐｓ（「parametres par seconde（毎秒パラメータ数）」の頭字語）ならば２００ｍｓ）のセグメントに分配し、１つのパラメータおよび１つのセグメントあたり唯１つのサンプルのみを保持する。各サンプル１２３５は、パラメータの値およびその取得日付を記憶し、そのＵＬを介して対応するパラメータ記述子セットを参照するパラメータサンプルメタデータセット１２４０と関連づけして記憶される。
【０１４４】
その他の全てのファイルを同期的に再読取りできるようにするために参照する合成ファイルは、図１３に示されている通り、映像、音声またはパラメータストリームを含む１つのファイルに各々が参照を行う複数の「ソースパッケージ」１３０５、およびこれらのストリームすべてを同期的にリプレイできるようにする１つの「マテリアルパッケージ」１３１０で構成されている。「Ｏｐ１ｂ」タイプの構造が、この複雑性の管理を可能にする。したがってこのファイルはさほど容易に相互運用可能ではない。反面、このファイルの物理的構造は、図１４に示されている通り、より単純なものである。このファイル１４０５は、「パーテイションヘッダー」１４１０、「メタデータヘッダー」１４２０および「パーテイショフッター」１４１５しか含まない。ヘッダー１４１０およびフッター１４１５は、ファイルの論理構造を与える構造メタデータ、および静的グローバルメタデータ（飛行機およびフライトの識別子）を引き継ぐ静的メタデータ、および各々のストリームに関連づけされた静的メタデータ（ソース識別子、パラメータリスト）を含む。
【０１４５】
アーキテクチャの観点から見ると、例えば次のもののような複数の技術的選択が可能である。
−  圧縮ソフトウェアまたはハードウェアの選択。
−  視覚化の選択。
−  リプレイ機能用のモジュールの追加。
【０１４６】
その上、グローバルアーキテクチャのための変形形態が可能である。映像専用ネットワーク１５０５を使用する図１５に示されている第１の変形形態においては、センサーは、ファイルフォーマットのデータを直接スイッチ（英語で「switch」）１５１５に供給するが、このことは、センサーの或る一定レベルの複雑性を意味する。このアーキテクチャは、サーバー１５１０によって管理される視覚化レベルのリアルタイムの問題を提起する。サービスおよび画像の所望の品質は、ネットワーク１５０５の規模を決定するために考慮される。実際、センサーにより生み出されるスループットは非常に大きく、損失なく管理されなくてはならない。
【０１４７】
ａ）図１６に示されている第２の変形形態においては、映像専用でないグローバルネットワーク１６０５が使用され、このネットワークでは、映像センサー１６１０は、その他の全てのＩＥＶセンサー１６１５、１６２０または１６２５と同じレベルにある。この場合、センサーレベルでのデータの捕捉の後、これらのデータは、各アプリケーションに適合されたフォーマットでパッケージングされ、サーバー１６３０および１６３５およびスイッチ１６５０を介して、同じネットワーク上を通過する。このアーキテクチャもまた、視覚化サーバー１６４０によって使用される視覚化スクリーン１６４５上の視覚化レベルでのリアルタイムの問題を提起する。サービスおよび画像の所望の品質は、ネットワーク１６０５の規模を決定するために考慮される。実際、センサーにより生み出されるスループットは非常に大きく、損失なく管理されなくてはならない。
【０１４８】
第３の変形形態においては、前述の２つの変形形態が組み合わせられる。
【図１】
0005580734.tif 000003
【図２】
0005580734.tif 000004
【図３】
0005580734.tif 000005
【図４】
0005580734.tif 000006
【図５】
0005580734.tif 000007
【図６】
0005580734.tif 000008
【図７】
0005580734.tif 000009
【図８】
0005580734.tif 000010
【図９】
0005580734.tif 000011
【図１０】
0005580734.tif 000012
【図１１】
0005580734.tif 000013
【図１２】
0005580734.tif 000014
【図１３】
0005580734.tif 000015
【図１４】
0005580734.tif 000016
【図１５】
0005580734.tif 000017
【図１６】
0005580734.tif 000018