(57)【要約】統合モジュラ・アビオニクス（ＩＭＡ）システム内でのアプリケーション間通信とＩ／Ｏデバイスの処理のための技術により、アプリケーション・ソフトウェア・モジュール間または区分アプリケーション（Ｐ１、Ｐ２）間で厳しい空間的時間的区分を維持しながら、多くのアプリケーション（Ｂ）の統合が可能となる。デバイス・アクセスと同様の方式で所望のアプリケーション相互作用を要約することにより、アプリケーション・モジュールの統合が簡単になる。このような要約により、以前に開発されたアプリケーションと新しいアプリケーションの統合が容易になる。本発明は、オペレーティング・システムから最小限のサポートしか必要とせず、アプリケーション特性に対する統合環境の従属性を最小限に押さえる。【選択図】図１
2004514959.tif 000002
【特許請求の範囲】
【請求項１】
統合モジュラ・アビオニクス（ＩＭＡ）システムにおいて同じＣＰＵとともに動作する複数の区分アプリケーション間における破損されていない区分間アプリケーション通信のための方法であって、
最上位優先度およびＣＰＵの全制御でシステム・エグゼクティブ・モジュールを実行するステップと、
複数のアプリケーションを区分して、それぞれが保護メモリ空間を使用し、下位優先モードで動作する区分アプリケーションを作成して、時間間隔をとってＣＰＵにアクセスするステップと、
複数の区分アプリケーションのそれぞれから生成された出力メッセージを、システム・エグゼクティブにより複数の区分アプリケーションのそれぞれに対して割当てられた共用メモリ場所内の巡回出力メッセージ待ち行列内へ割当てるステップと、複数の区分アプリケーションのそれぞれは、その割当てられた共用メモリ場所内に、生成する出力メッセージを格納し、
中央チャネル・レジストリ・テーブルが共用メモリ場所内の出力メッセージ・アドレス空間場所を決め、複数の区分アプリケーションのどれが、それぞれの出力メッセージを読み取るよう許可されているかをリストし、システム・エグゼクティブ・アプリケーションによって維持される中央チャネル・レジストリ・テーブル内に巡回出力メッセージ待ち行列をレジスターするステップと、
さらに、複数の区分アプリケーションのそれぞれの中のライブラリ・ルーチン内で、出力メッセージが、複数の区分アプリケーションに正しくアドレス付けされており、完全なメッセージであり、破損されたり、もはや存在しない区分アプリケーションにアドレス付けされていないことを検査するステップと、
共用メモリ場所内の巡回出力メッセージ待ち行列内に格納された出力メッセージの直接読取りを可能にするステップとを含み、複数の区分アプリケーションの許可区分アプリケーションのみに、読取り専用アクセスで共用メモリから読み取ることが認可されている方法。
【請求項２】
実行時間は、複数の区分アプリケーションのそれぞれに対してシステム・エグゼクティブによって割当てられている時、複数の区分アプリケーションのそれぞれに対して上記のステップを繰り返すことを含む、請求項１に記載の方法。
【請求項３】
複数の区分アプリケーションのそれぞれに対して読み取った出力メッセージのメッセージ読取り索引を作成するステップと、
複数の区分アプリケーションによってメッセージ読取り索引を読み取るステップと、どのメッセージが読み取られたのか、およびどのメッセージが巡回出力メッセージ待ち行列から削除できるのかを判断するステップとをさらに含む、請求項１に記載の方法。
【請求項４】
出力巡回メッセージ待ち行列のオーバフローを検出するステップと、
巡回メッセージ待ち行列のオーバフローを軽減するために読み取られた出力メッセージを削除するステップとをさらに含む、請求項３に記載の方法。
【請求項５】
追加の新しいメッセージは、出力巡回メッセージ待ち行列内に挿入される、請求項１に記載の方法。
【請求項６】
前記巡回出力メッセージ待ち行列をレジスターするステップは、出力メッセージ待ち行列を、複数の区分アプリケーションによって読み取られた時に、デバイス・ドライバ・コマンド・メッセージのように見えるように通信プリミティブ・フォーマットに要約するステップを含む、請求項１に記載の方法。
【請求項７】
少なくとも１つの出力メッセージを要約する前記ステップを行った後、要約された出力メッセージが、レガシ・アプリケーション内のデバイス・ドライバのための通信チャネルを介して読み取られ、デバイス・ドライバ・ポートを介してのみアクセスできるレガシ・アプリケーションが、レガシ・アプリケーションにアドレス付けされている出力メッセージを読み取ることを可能にする、請求項６に記載の方法。
【請求項８】
前記巡回メッセージ待ち行列はストリーム・バッファとして配置され、出力メッセージがストリーム・フォーマットであり、したがって、複数の区分アプリケーションのうちの２個以上の区分アプリケーションによって読取り可能である、請求項１に記載の方法。
【請求項９】
前記システム・エグゼクティブは、システム・エグゼクティブでのみ書込み可能であるが、すべてのアプリケーション区分によって読取り可能な複数の区分アプリケーションのそれぞれの安全状況履歴を維持する、請求項１に記載の方法。
【請求項１０】
デバイスが、複数の区分アプリケーションの少なくとも１つ内に含まれ、前記方法は、デバイス・デーモンを介して出力メッセージ内のコマンドを使用してデバイスを制御するステップをさらに含む、請求項１に記載の方法。
【請求項１１】
前記検査するステップ中に、二重状況フィールドが作成され、それぞれの出力メッセージに付加されて、それぞれの出力メッセージが、巡回出力メッセージ待ち行列内に完全に格納されることを確実にする、請求項１に記載の方法。
【請求項１２】
前記ストリーム・バッファは、データを検査するため、追加のチェック・コードを含む、請求項８に記載の方法。
【請求項１３】
データ・バスに接続されたＣＰＵボードを制御するシステム・エグゼクティブ・モジュールと、
タイム・スケジュールに従ってＣＰＵボードに割当てられた保護メモリ空間内で動作し、出力メッセージを作成するシステム・エグゼクティブによって区分された複数の区分アビオニクス・アプリケーションと、
ＣＰＵボードに割当てられた区分共用メモリ空間内に位置する複数の巡回メッセージ待ち行列と、を有し、
前記巡回メッセージ待ち行列は、複数の区分準拠アビオニクス・アプリケーションの関連する１つでのみ書込み可能であり、該巡回メッセージ待ち行列は、関連する受信側区分アビオニクス・アプリケーションによって直接に読取り可能である、航空機アビオニクス・システム。
【請求項１４】
前記巡回メッセージ待ち行列は、ストリーム・バッファ・フォーマットである、請求項１３に記載のシステム。
【請求項１５】
前記メッセージは、デバイス・ドライバ・コマンドまたはデータ・フォーマットに要約される、請求項１３に記載のシステム。
【請求項１６】
要約された前記メッセージは、レガシ・アプリケーションによって読み取られる、請求項１５に記載のシステム。
【請求項１７】
データ・バスに接続されたＣＰＵボードを制御し、複数の区分アビオニクス・アプリケーションを区分するシステム・エグゼクティブ・アプリケーションを有する航空機アビオニクス・システムのための方法であって、
出力メッセージを作成するためタイム・スケジュールに従って保護メモリ空間内で複数の区分アビオニクス・アプリケーションを実行するステップと、
区分共用メモリ空間内に位置する複数の巡回メッセージ待ち行列内に出力メッセージを入れるステップとを含み、前記巡回メッセージ待ち行列は、複数の区分準拠アビオニクス・アプリケーションから送信側アプリケーションによってのみ書込み可能であり、
さらに、前記巡回メッセージ待ち行列内で前記出力メッセージを読み取るステップを含み、前記巡回メッセージ待ち行列は、関連する受信側区分アビオニクス・アプリケーションによって直接に読取り可能である、航空機アビオニクス・システムのための方法。
【請求項１８】
前記巡回メッセージ待ち行列は、ストリーム・バッファ・フォーマットである、請求項１７に記載の方法。
【請求項１９】
前記メッセージをデバイス・ドライバ・コマンドまたはデータ・フォーマットに要約するステップをさらに含む、請求項１７に記載の方法。
【発明の詳細な説明】
【０００１】
関連出願
本出願は、２０００年８月２０日に出願された、Ｍ．Ｓ．ＡｂｏｕｔａｂｌとＭ．Ｙｏｕｎｉｓによる出願第０９／６４８，９８５号、「インテリジェント・モジューラ・アビオニクスにおける分割および再利用の「ためのアプローチ（Ａｎ　Ａｐｐｒｏａｃｈ　ｆｏｒ　Ｓｕｐｐｏｒｔｉｎｇ　Ｐａｒｔｉｔｉｏｎｉｎｇ　ａｎｄ　Ｒｅｕｓｅ　ｉｎ　Ｉｎｔｅｌｌｉｇｅｎｔ　Ｍｏｄｕｌａｒ　Ａｖｉｏｎｉｃｓ）」に関連する。
発明の分野
本発明は、アビオニクス機器のためのソフトウェア・アプリケーション間の通信および入出力（Ｉ／Ｏ）デバイスの処理に関する。
発明の背景
最近のコンピュータ・テクノロジの発達により、アビオニクス産業は、最新のハードウェアの処理能力および通信能力が向上したのを利用し、複数の連合アビオニクス・アプリケーションを共用プラットフォームに組み合わせることができるようになってきた。多くのソフトウェア構成要素を、これら従来の別々の構成要素の計算需用を満たすのに十分な能力を有する単一の共用計算環境に統合するため、統合モジュラ・アビオニクス（ＩＭＡ）と呼ばれる新しいコンセプトが開発されてきた。このような統合により、ハードウェアのコストが下がり、航空機の運航オペレータが保有していなければならない予備ユニットの数が減少した。航空機のアビオニクス機器の軽量化および消費電力の低減化が、この統合法によって実現する。
【０００２】
ＩＭＡ法により、また新しい問題点も生じる。その中の重要な問題点として、アプリケーション間の望ましくない従属性を回避しなければならないという問題がある。１つのアプリケーション内の問題または故障が他のどのアプリケーションにも悪影響を及ぼさないということを、非常に高い保証レベルで、示すことができなければならない。非常に高いレベルの保証がないと、航空機認証機関（たとえば、ＦＡＡ）は、このようなシステムの航空機への据付けを容易に認証しようとはしない。したがって、ＩＭＡベースのアプリケーションが、空間的にも時間的にも厳しく区分されていることが求められる。
【０００３】
概念上、厳しいまたは頑強な区分とは、アプリケーション間の境界が明確に規定され保護され、その結果、あるアプリケーション・モジュールのオペレーションが、たとえ他のアプリケーションが誤ったまたは不正な方式で動作している場合でも、別のアプリケーションの挙動によって妨害され破損されることのないようにされているということである。障害のある構成要素により、他の構成要素が故障したり、トータル・システム故障を発生させる危険性がないということを保証するため、統合環境にとって、障害の影響を閉じ込めることは極めて重大である。たとえば、理想的なＩＭＡベースのアビオニクス・システムでは、キャビンの温度制御システム内の故障が、航空機の安全なオペレーションに必要な臨界飛行制御システムに、悪影響を及ぼすことがあってはならない。
【０００４】
連合アビオニクス・システムでは、アプリケーションがプロセッサや通信ハードウェアを互いに共用せず、自然に区分がなされるが、計算リソースを排他的に使用するのでコストが高くなる。ＩＭＡ環境では、あるアプリケーションが他のアプリケーションとしばしばリソースを共用し、したがって、正しいオペレーションをするには、リソースを正しく共用する必要がある。多くのアビオニクス・ソフトウェア・アプリケーションが同じコンピュータに共存する場合、アプリケーションが、メモリにアクセスし、ＣＰＵ処理サイクルを消費し、入出力デバイスとインターフェイスをとることに関して、区分が特に問題となる。通常、アプリケーションは異なるメモリ領域に割当てられ、ＣＰＵやＩ／Ｏデバイスなどの共用リソースの使用については、タイム・スケジュールに基づいて、それらの間で調整される。メモリの区分およびタイム・スケジュールは、通常、システムが航空機で使用される前に、システム内へのアプリケーションの統合の一部として決定される。
【０００５】
メモリおよびリソース・キャパシティをいくつかのアプリケーション間に分割することにより、境界が形成され統合が容易になるが、障害が存在するような状況下で、これらの境界が破られないという保証はない。したがって、ＩＭＡ環境では、統合アプリケーション間で空間的にも時間的にも厳しい区分がなされることを確実にする必要がある。それぞれのアプリケーションのアドレス空間は、他のアプリケーションによる無許可アクセスに対して保護されていなければならない。さらに、１つのアプリケーションを、割当てられたＣＰＵ使用時間より長く操作して、他の統合アプリケーションの進捗を遅らせてはならない。
【０００６】
区分が厳しいまたは頑強であるとは、障害のあるアプリケーション区分の誤った挙動が、他の安全なアプリケーションに決して影響を及ぼさないということである。アプリケーションの誤った挙動は、そのアプリケーションによって排他的に使用されているハードウェア・デバイス内のソフトウェア障害または故障の結果である可能性がある。障害は、その性質としては、一般的なもの、偶発的なもの、故意によるものがあり、また持続期間としては、永久的なもの、過渡的なもの、断続的なものがある。通信されたデータの妥当性を検査して、アプリケーション・ソフトウェア内のセマンティックに関連する一般的な障害によるエラーを検出する、アプリケーションに特化したセマンティック・チェックを実施することが有益である。通常、システムは、ビザンチン（Ｂｙｚａｎｔｉｎｅ ｆａｕｌｔ）の障害に陥る可能性は少なく、すなわち、すべての障害はそれ自体、エラーとなって現れて、その他すべての安全なモジュールと同じ方式で検出される。さらに、障害は、通常、一度に１つずつ起き、同時性はない。
【０００７】
障害のある構成要素が他の安全なシステム構成要素を破損しようとすると、エラーとして検出される。その障害のあるアプリケーション区分と通信しているアプリケーションのみが、そのエラーを認識して、そのアプリケーションの性質に従って回復動作を行う必要がある。他方、障害のあるアプリケーションと通信していない安全なアプリケーションのオペレーションは、影響を受けない。
発明の概要
本発明は、ＩＭＡシステム内でアプリケーションの統合を容易にする、アプリケーション間通信とＩ／Ｏデバイスの処理のための新規な技術を開示する。これらの技術により、多くのアプリケーションの統合が可能になり、アプリケーション・モジュール間の厳しい空間的な区分を維持することができるようになる。デバイス・アクセス・トランザクションとしてアプリケーション間の所望の相互作用を要約することにより、アプリケーション・モジュールの統合が簡単になる。このような要約により、ＩＭＡ環境内で以前に開発されたアプリケーションの統合が容易になる。この方法は、他の方法と比べて、オペレーティング・システムからのサポートが少なくて済み、統合環境のアプリケーションの詳細に対する従属性を最小限にする。したがって、本発明は、統合アプリケーション間での、空間的な区分を確実にし、通信およびデバイスの共用を可能にすることに焦点を当てる。
【０００８】
本発明は、エアインク（ＡＲＩＮＣ）規格６５３に準拠するＩＭＡシステム内のアプリケーションの統合を容易にする、アプリケーション間通信とＩ／Ｏデバイスの処理のための方法および装置を有する。本発明により、多くのアプリケーションの統合が可能になり、アプリケーション間の厳しい空間的時間的区分を維持することができるようになる。本発明は、デバイス・ドライバとして区分アプリケーション内のアプリケーション・タスクに要約できる、区分間メッセージ型サービスを使用するデバイス・アクセス・トランザクションとしてアプリケーション間での相互作用を要約することにより、これらのアプリケーション・モジュールの統合を簡単にする。
詳細な説明
図１は、２０００年８月２０日に出願されたＡｂｏｕｔａｂｌ　Ｙｏｕｎｉｓ出願番号第６４８，９８５号に記述され、本発明に使用できる、リアルタイム安全臨界アビオニクス・アプリケーションを統合するためのアーキテクチャを示す図である。アーキテクチャは、図１に示すように、基本的に、ＡＲＩＮＣ規格６５３およびアビオニクス・コンピュータ・リソースのための最小動作性能標準に準拠できる、２層オペレーティング環境である。しかし、本発明は、レガシ・ソフトウェア・モジュールと、すべてが共用ＣＰＵ上で実行される、リアルタイム・オペレーティング・システムとの統合を可能にすることにより、さらにそれ以上のものとなる。アプリケーション間通信のための本方法について記述する場合は、このアーキテクチャについての記述であるが、この技術はまた、他のＩＭＡシステムにも適用可能である。
【０００９】
システム・エグゼクティブ（ＳＥ）１０と称される、アーキテクチャの低層が、それぞれのアプリケーション・モジュール１３に、その中でアプリケーションが実行できる、仮想機械、すなわち、保護区分を供給する。この方式で、アプリケーションが、空間定義域内で他のアプリケーションから隔離される。本願では、空間的な区分を強化するため、大部分のモデム・プロセッサとともに使用可能なメモリ管理ユニット（図示せず）などのハードウェア手段に依拠する。時間定義域の隔離は、事前計算されたスタティックな時間割に基づいて、アプリケーション間でＣＰＵボード１９と他のリソースを共用することにより得られる。システム１０エグゼクティブは、リアルタイム・クロック１１を維持し、その中で、それぞれのアプリケーションに明確に定義されたタイム・スライスが指定されている時間割を厳格に実施する。空間的および時間的区分を確実にすることに加えて、ＳＥ１０は、コンテクスト・スイッチングを取り扱い、アプリケーション区分１３を初期設定／監視／終了する。ＳＥ１０のみが、最上位特権ＣＰＵモードで実行する能力を有する。その他すべての区分は、それより下位の特権ＣＰＵモードで実行し、したがって、アプリケーションが、メモリ保護セットアップを破損したり、または他のアプリケーションのＣＰＵ１９を使用する権利を破る可能性が排除される。それぞれのＣＰＵ１９はまた、飛行機１７に置かれたキーボードやコンピュータなどの外部デバイスと通信するデバイス・ドライバ１２と、相互接続データ・バス１８との通信を供給するバス・ドライバ２１とを含む。
【００１０】
多くのタスクから構成され得る、区分アプリケーション１３のそれぞれが、保護メモリ区分、たとえば、図２のＰ１に指定され、したがって、１つのアプリケーション区分内の障害が他のアプリケーションに伝搬するのを防ぐことができる。この特徴を得るために、それぞれのアプリケーション１３が、システム・エグゼクティブ（ＳＥ）１０に対して、自体のアプリケーション・エグゼクティブ（ＡＥ）１５とインターフェイス・ライブラリ（ＩＬ）１６を伴う。ＡＥ１５は、アプリケーション内通信と同期を取り扱う。ＡＥ１５はまた、アプリケーションのオウン・メモリ区分の境界内でアプリケーションのダイナミック・メモリ要件を管理する。ＡＥ１５はまた、アプリケーションのタスクをスケジュールするためのそのオウン・ストラテジを実施できる。アプリケーション間およびプロセッサ間通信に関連する、すべてのアプリケーション・エグゼクティブ（ＡＥ）１５機能は、インターフェイス・ライブラリ１６を介してＳＥ１０に手渡される。
【００１１】
一般に、オペレーティング・システムが、ハードウェアへの特権アクセスを有するため、システム・エグゼクティブ１０は、特権オペレーションを取り扱うことを可能にするアプリケーション・エグゼクティブ１５にサービスを供給する必要がある。これらのサービスには、例外処理、割込みイネーブルおよびディセーブル、そして、たとえば、スレッド・コンテクスト・スイッチング中の、プロセッサ内部状態へのアクセスが含まれる。インターフェイス・ライブラリ（ＩＬ）１６は、これらのサービスをカプセル化する。ＩＬは、アプリケーション・エグゼクティブ１５とコンピュータのハードウェア・サービスの間のゲートウェイとして働く。
【００１２】
２層アーキテクチャの主要設計目標は、ＳＥ１０を単純に、かつ統合アプリケーションの数や種類から独立して保有することである。ＳＥ１０の設計を単純なものにすると、認証が容易になる。統合アプリケーション１３からの独立性により、ＳＥ１０が、アプリケーションの変更による影響を余り受けなくなり、したがって、アプリケーションの変更やアップグレードの度に再認証する回数が少なくて済む。アプリケーション間通信パラダイムは、ＳＥ１０と個々のアプリケーション区分間の結合の程度を判断する１つの主要な態様である。したがって、アプリケーション間通信のためのメカニズムは、ＳＥ１０とアプリケーションとの結合を可能な限り最大限回避しなければならない。以下に、統合アプリケーション間で厳しい区分を維持し、通信を可能にし、ＳＥを関与させない、アプリケーション間通信のための本方法について記述する。この記述全体を通じて、区分およびアプリケーションの用語は、互いに交換可能に使用される。ここに提示する方法は、本明細書で記述したものだけでなく、どの２層ＩＭＡソフトウェア・アーキテクチャにも適合することに留意されたい。
【００１３】
さまざまな区分間でデータを共用するために、通信プリミティブが必要となる。一般に、メッセージ引渡しおよび共用メモリが、マルチタスク・セットアップ内のタスク間通信に使用される。同じ技術が、区分間通信に適用可能である。しかし、本方法は、メッセージ引渡しの使用を、ＩＭＡ環境内の区分間通信（ＩＰＣ）のための手段としてサポートするだけである。共用メモリＩＰＣのためのサポートは、メモリ管理を複雑なものにする。システム・エグゼクティブは、ＳＥ１０アドレス空間内またはグローバル・アクセス可能メモリ・エリア内のいずれかに、メモリ・エリアを割当て、ホストとして共用データを処理する必要がある。これらの共用データへのアクセスは、ＳＥ１０サービスを介してでなければならない。ＳＥ１０は、共用メモリを管理して、データの整合性を維持する必要あり、また区分間のコンテクスト・スイッチングも必要となる。共用メモリは可能であるが、ＳＥ１０を複雑にする原因にもなる。さらに、共用メモリは、通常、データを検査するために最小のチェックしか行わないため、エラーを伝搬しやすい。他方、メッセージ引渡しは、区分間に頑強な通信手段を提供できる。厳密なメッセージ・フォーマット・チェッキングを課して、偽のトラフィックに対する防御をすることができる。さらに、ＩＭＡ環境内のアプリケーション・エグゼクティブ・インターフェイス（ＡＰＥＸ）のためのＡＲＩＮＣ６５３標準とアビオニクス・コンピュータ・リソース（ＡＣＲ）のためのＲＴＣＡ最小動作性能標準はまた、ＩＰＣのためのメッセージ引渡しを使用しなければならない。区分内のアプリケーション・タスクは、アプリケーション開発者の選択したメカニズムを介して互いに通信することに留意されたい。１つの区分から別の区分への通信アクティビティのみが、メッセージ引渡しを介して必要となる。
【００１４】
本発明によれば、アプリケーション１３が、アプリケーション区分Ｐ１とＰ２の間で分割され、これらが、図２に示すように、データおよびサービスを共用するよう通信する。区分Ｐ１が他の区分Ｐ２からデータを必要とする場合、Ｐ１は、明示的要求をＰ２に送信してデータを取得するか、またはＰ２が連続的にデータをＰ１にアクセス可能にすることを期待する。サービスの共用は、しばしば、要求側（クライアント）とサービス・プロバイダ（サーバ）の間の要求および応答メッセージの交換を必要とする。本方法では、本願は、メッセージを、通信セマンティクスに従って、要求／応答（クライアント／サーバ）メッセージと状況メッセージに分類する。クライアント／サーバＩＰＣでは、本願は、１つのサーバだけが、おらくは複数のクライアントからの要求を受信できるようにする。メッセージを記入し、それらを指定区分で読込可能にすることにより、状況メッセージの実施が簡単なものになる。以下に、区分間でクライアント／サーバおよび状況メッセージがどのようにサポートされるかについて説明する。
【００１５】
本環境内でクライアント／サーバ・メッセージ引渡しＩＰＣをサポートするための、可能な１つの方法が、通信している区分間で共用可能になるようメッセージ待ち行列を割当てることである。この方法はメッセージ引渡しの頑強性という利点を維持するものの、暗黙的に、待ち行列からのメッセージを書き込み、読み取るための手段として、共用メモリＩＰＣをサポートする必要があり、したがって、上述したように、ＳＥの設計が複雑となる。
【００１６】
しかし、本発明によれば、図２に示すように、送信側区分２２が、送信側メッセージ２３について、そのオウン・メモリ空間２０内にメッセージ待ち行列２４を割当てる必要がある方法である異なる方法がとられる。送信側区分は、待ち行列２４を受信側区分２５で読取り可能にするか、またはＳＥ１０が、送信側のアドレス空間（図示せず）から受信側のアドレス空間内のメッセージ待ち行列（図示せず）へメッセージをコピーするのに依拠する。
【００１７】
送信側２２から受信側区分２５へメッセージをコピーするには、包括的メッセージ・ハンドラがＳＥの中に含まれていなければならない。メッセージ・ハンドラが送信側区分から、メッセージを受信側待ち行列に挿入するよう要求を得ると、ハンドラは、この通信の信憑性を検査した後、このメッセージを宛先待ち行列に物理的にコピーする。システム・エグゼクティブをアプリケーション間メッセージの処理に関与させることにより、アプリケーションとＳＥの結合が強まり、したがって、統合が複雑となる。さらに、ＳＥにサポートされた、メッセージ処理ライブラリにより、ＳＥの設計の複雑さが一層増すが、特に、区分間のコンテクスト・スイッチング、割込み、メッセージ処理中にトリガされた潜在的な例外に対処している場合はなおさらである。
【００１８】
あるいは、本発明の他の態様によれば、割当てには、図４に示すように、出力メッセージのために送信側区分２２内で巡回待ち行列４０を使用することが含まれる。図３に示すように、巡回待ち行列は、チャネル・レジストリ・テーブル３０を使用するＳＥ１０により、読取り専用アクセスのための許可受信側区分２５のアドレス空間に、マップされる。送信側区分２２は、巡回待ち行列４０に書込みアクセスする唯一のものである。図５に示すように、送信側区分は、巡回待ち行列４０のための読取りポインタ５０と書込みポインタ５１を維持する。書込みポインタ５１は、新しいメッセージを挿入するために使用される。読取りポインタ５０は、オーバフロー状態を検出するために使用される。これについては以下で説明する。図２に示すように、受信側区分２５は、待ち行列のためのオウン読取りポインタ５２を維持し、それを送信側区分で読取り可能にする。
【００１９】
受信側は、その送信側読取りポインタ５０を使用して、巡回待ち行列２４からのメッセージにアクセスする。図５に示すように、送信側区分２２は、メッセージ挿入中のオーバフローを検出すると、受信側が既に消費したメッセージがあれば、それらを除去する。送信側は、読取りポインタ５０のそのバージョンの値を受信側の読取りポインタ５２の値と比較することにより、消費されたメッセージを識別する。送信側が、その読取りポインタ５０の更新後も、まだオーバフロー状態である場合は、エラーが宣言され、アプリケーションに特化したアクションがとられる。受信側区分２５の読取り受信側ポインタ５２を、必要であれば、受信通知用に使用することもできる。送信側区分２２は、受信側読取りポインタ５２の読取りポインタの値をチェックして、メッセージ（たとえば、クライアントの要求）がサーバ、受信側区分２５によって受信されていることを確認することができる。
【００２０】
新しい区分間メッセージ・サービスを、デバイス・ドライバとして区分内のアプリケーション・タスクに要約することができる。この要約は、概して区分間の通信プリミティブについて記述している、ＡＲＩＮＣ６５３標準の規格と整合性を有する。区分間メッセージを構成要素タスクにルーティングすることは、この標準では対処していない。デバイス・ドライバの要約を使用することにより、外部デバイスを介して通信する手段を既に有するため、レガシ連合アプリケーションの統合が容易になる。メッセージ待ち行列がＳＥ１０に特化しているため、新しいアプリケーションを統合する場合に変更する必要がない。さらに、統合用には、連合アプリケーションによって使用される通信チャネルのためのデバイス・ドライバだけを置き換えれば良い。
【００２１】
ＳＥ１０が、空間的区分を確実にするためＣＰＵ１９メモリ（図示せず）を管理するよう認可された唯一の構成要素であるため、送信側区分２２は、ＳＥ１０とともに待ち行列アドレス２７をレジスターする必要がある。さらに、受信側区分は、その待ち行列のために、その受信側読取りポインタ５２の場所を登録しなければならない。登録は、システムの初期設定中、またはリンク時のいずれかに、行うことができる。どちらの場合も、ＳＥ１０は、すべてのＩＰＣ関連データ構造のアドレスのリストを維持する。システムの初期設定中にアドレスをレジスターするためには、ＳＥの１０アドレス空間にアクセスするためＳＥの１０ライブラリ・ルーチンの呼出しが必要である。登録後、送信側区分２２と受信側区分２５は、それぞれ、受信側読取りポインタと待ち行列のアドレス用のリストを照会しなければならない。
【００２２】
受信側区分Ｐ２にメッセージを送信する、送信側区分Ｐ１が、ホストとしてこれらのメッセージを処理するため、そのオウン・アドレス空間内に待ち行列をスタティックに定義する必要がある。送信側区分Ｐ１は、ＳＥ１０内の区分間通信（ＩＰＣ）サービス２８に、この待ち行列からメッセージを受信するよう許可された、待ち行列アドレスと受信側区分Ｐ２とを認識させる待ち行列区分をレジスターすることが必要となる。図３に示すように、ＳＥ１０は、すべてのオープンＩＰＣチャネル３１のためＩＰＣチャネル・レジストリ・テーブル３０を維持する。レジストリ・テーブルは、システム・エグゼクティブ１０によって維持され、読取り専用で区分によるアクセスが可能である。
【００２３】
ＩＰＣ待ち行列の処理を統一するためには、定義済み巡回メッセージ待ち行列４０構造（ＩＰＣ＿ｑｕｅｕｅ）を使用しなければならない。ＩＰＣ＿ｑｕｅｕｅタイプは、ＳＥのＩＰＣチャネル・レジストリ・テーブル３０との不整合の原因になりかねない誤った変更を防ぐために、コンパイル時に定義すべき、一意的な事前区分待ち行列名を要求する。図４に示すように、待ち行列は、２つの別個の読取り／書込みポインタ、すなわち、受信側読取りポインタ５２と送信側書込みポインタ５１を使用して、アクセス可能である。送信側読取りポインタ５０は、次のメッセージを検索するため、受信側区分によって使用され修正される。送信側書込みポインタは、メッセージを挿入するため送信側区分によってのみ使用される。
【００２４】
書込みオペレーションは、送信側区分２２に対して完全にローカルである。空のエントリを追跡するため、送信側２２は、そのエントリを再使用できるようにするため、消費したメッセージを除去する必要がある。送信側区分２２は、そのオウン送信側読取りポインタ５０を維持して、読み取られなかったメッセージの上書きを防ぐ。送信側２２と受信側２５区分内の２つの読取りポインタの値を同期させるため、送信側区分２２は、送信側が待ち行列オーバフローを検出すると、そのオウン送信側読取りポインタ５０を、受信側２５によって維持される値に更新する。受信側の読取りポインタ５２の値を使用した後にも、まだオーバフロー状況が続いている場合は、送信側は、エラー（データを消費していない区分を受信する）を宣言する。受信側の読取りポインタ５２は、メッセージが偶発的に上書きされてしまうことを防ぐために、読取りオペレーションの最後の段階に進む。このような場合は、受信側がメッセージを完全に検索する以前に強制排除され、送信側が待ち行列内の空のメッセージ・エントリ上で不足する場合に起こる。図２に示すように、受信側の読取りポインタ５２のアドレスは、チャネル・レジストリ・テーブル３０（「Ｍｓｇ　Ａｃｋ」フィールド）内に含まれ、２つの読取りポインタの値が同期している時、送信側によって参照することができる。送信および受信アルゴリズムを、図５、６、７に示す。送信側区分２２の強制排除により、受信側区分２５が不完全なメッセージを読み取るのを防ぐために、二重状態状況フィールドが、メッセージ・エントリが使用されている（有効）か使用されていない（空）かを表示する、それぞれのメッセージに付加されている。待ち行列から読み取られる次のエントリが空メッセージを含む場合は、読取り側区分は、待ち行列内にメッセージがないとの結論を下す。メッセージ状況は、それが完全に待ち行列の中に挿入された後に始めて、有効となる。データ・タイプやライブラリ・ルーチンの詳細については、付属文書Ａに記載する。
【００２５】
上述したメッセージ引渡しプロトコルは、区分間通信のクライアント／サーバ・モデルに適合する。しかし、このプロトコルは、１ストリームのデータを１つまたは複数の区分に同報する場合、送信側がメッセージを多くの待ち行列、それぞれの受信者に対して１つずつ挿入しなければならないため、非効率的となる。
【００２６】
あるいは、図８に示すように、メッセージのストリーム・バッファが、そのオウン・メモリ空間内の送信側区分によって作成することができ、多くの受信者に読取り可能となる。送信側は、ストリーム・バッファ８０への書込み認可を有する唯一の区分となる。システム・エグゼクティブは、このストリーム・バッファが送信側によってのみ書き込みでき、ストリーム・バッファ８０を、読取り専用エリアとして１人または複数の受信者のメモリ空間にマップすることを確実にする。
【００２７】
図８に示すように、ストリーム・バッファ８０は、送信側に維持されている１つの書込みポインタ５１とそれぞれの受信者のための受信側読取りポインタ５２とを備える巡回ストリーム・バッファである。それぞれの受信側区分２５は、そのオウン読取りポインタを維持する役割を有する。図８に示すように、多くの受信側２５が、巡回ストリーム・バッファ内の異なる場所から読み取る可能性がある。送信側とすべての受信者によって使用されるストリーム・バッファがただ１つしかないので、平行読取り／書込み要求を正しく取り扱うには、厳格な制御が必要となる。実際、送信側区分２２と受信側区分２５は、区分が強制排除されている場合の整合性を確実にするために、メッセージを書き込んだり読み取ったりする以前に、ストリーム・バッファ内のメッセージ場所を排他的にロックしなければならない。ロックすると、オペレーションの速度がかなり落ちるだけでなく、送信側区分と受信者区分にブロック状態を導入するおそれも生じる。
【００２８】
あるいは、本発明の他の態様によれば、本願は、付属文書Ｂにリストしたように、制御コマンドのための並行性には、より自由な形式を使用している。ストリーム・バッファ「ＩＰＣ＿ｓｔｒｅａｍ」は、４つの属性を有する。
【００２９】
メッセージ本体が格納される「メッセージ」フィールド
メッセージが有効であるので、受信者が先へ進みそれを検索することができることを表示する「状況」フィールド
古いメッセージと最近のメッセージとを区別するために使用されるメッセージ識別子。識別子は、ストリーム当たりのメッセージ・シーケンス・カウンタの現在値である。
【００３０】
不完全に更新されたメッセージを読み取ることを防御するための「ＣＲＣ」チェック・サム・コード
送信側区分２２は、まず最初に、現在メッセージを無効化し、次いで、メッセージ本体を正しいチェック・サムとともに更新し、メッセージ識別子を現在メッセージ・シーケンス・カウンタに設定し、有効なフラグを設定し、最後に、メッセージ・シーケンス・カウンタを増加させる。受信者が、最初に、現在メッセージが有効であることを確認する。次に、メッセージ本体を検索し、チェック・サム・コードを点検する。受信者が、メッセージを検索している間に強制排除され、送信側が、新しいチェック・サムとともに新しいメッセージを同じ場所に挿入した場合、受信者は、「ＣＲＣ」が、たった今検索したばかりのメッセージ本体と一致しないことを検出し、そのメッセージを再読取りすることができる。
【００３１】
メッセージ・シーケンス・カウンタは、メッセージ書込み順序を追跡する。ストリームが多くのリーダと単一のライタとを備えるため、ライタと１つまたは複数のリーダとの間には速度と頻度に大きなばらつきが出る可能性がある。したがって、ライタは、リーダに指されたメッセージを上書きする可能性がある。リーダが実行を再開した後に２つのメッセージを検索すると、第１のメッセージはストリーム内で最も最近に挿入されたものであり、第２のメッセージは最も古いメッセージであるため、リーダは、順番誤りメッセージとなって終了する。メッセージ・シーケンス・カウンタを使用してメッセージ順序を識別することにより、リーダ区分は、このようなことが起きたのを検出でき、適切なアクションをとることができる。
【００３２】
ＩＰＣ待ち行列と同様の方式で、ストリーム・バッファ８０を、送信側のアドレス空間内にスタティックに作成する必要がある。送信側区分は、ＳＥ１０とともにストリーム・バッファ８０を登録して、その結果、ＳＥ１０が、読取り専用アクセス認可とともに、許可された受信区分のメモリ・マップ内にストリームのアドレスを含むようにしなければならない。ＳＥ１０は、「ＩＰＣ＿ｃｈａｎｎｅｌ＿ｒｅｇｉｓｔｒｙ＿ｔａｂｌｅ」３０（図３参照）と同様のレジストリ・テーブル（図示せず）（「ＩＰＣ＿ｓｔｒｅａｍ＿ｒｅｇｉｓｔｒｙ＿ｔａｂｌｅ」）内にアドレスを記録して、ストリーム・バッファ・アドレスの解を可能にする。「ＩＰＣ＿ｃｈａｎｎｅｌ＿ｒｅｇｉｓｔｒｙ＿ｔａｂｌｅ」３０はまた、ＩＰＣストリーム・バッファをレジスターするのに使用できるが、ＩＰＣの性能を向上させるためには別個のテーブルを使用する方が良い。
【００３３】
ストリーム・レジストリ・テーブル（図示せず）は、ＳＥによって維持され、アプリケーションに対する読取り専用アクセスとしてアクセス可能である。登録後、受信側区分は、ストリーム・データ構造のアドレス用テーブルに照会しなければならない。登録は、システム初期設定時、リンク時、ロード時のいずれかで行うことができる。システムの初期設定中にアドレスをレジスターするには、ＳＥのアドレス空間にアクセスするため、ＳＥのライブラリ・ルーチンを呼び出す必要がある。データ・タイプとライブラリ・ルーチンの詳細については、付属文書Ｂに記載する。
【００３４】
アプリケーション区分が、他の区分と通信している場合、その、他の区分の故障について知っていることは極めて重要である。通信の故障に反応して、必要な回復手順を行うことは、アプリケーション区分の責任範囲であるが、少なくとも、読取りポインタをリセットする必要がある。読取りポインタは、受信側区分によってのみ更新可能なため、通信している区分にトランスペアレントな送信側区分の障害を回復するための導出法を使用することはできない。
【００３５】
送信側区分内の故障を受信側に知らせるための可能な１つの方法に、いくつかの異常なＩＰＣ状況をトリガして、受信側区分が送信側の故障を検出できるようにする方法がある。システム・エグゼクティブは、区分ＩＰＣエリアを無効化するか、または一次的に他の区分へのアクセスができないようにすることができる。したがって、他のアプリケーションは、障害のある区分と通信している時、エラーを検出することができる。しかし、この方法は、その使用を限定する基本的な問題点がある。すべての受信側区分が障害のある区分とともにＩＰＣアクティビティを行っていて、エラー状況にある前に、障害のある区分の回復および再初期設定が終了された場合に、この問題点が表面化する。この場合、いくつかの受信側区分は、送信側の故障を認識せず、読取りポインタをリセットしない。したがって、この方法は、実行可能な方法ではない。
【００３６】
本発明の他の態様による、第２の方法として、システム・エグゼクティブ１０によってすべての区分の安全状況履歴を維持する方法がある。システム・エグゼクティブ１０は、システム・エグゼクティブ１０によってのみ書込み可能なすべての区分で読取り可能な、共用メモリ・エリア内に区分の安全状況を保存する。受信側区分２５が送信側区分２２の故障を検出するためには、受信側区分２５は、それぞれのＩＰＣアクティビティの前に、送信側区分２２の状況をチェックする必要がある。
【００３７】
区分の故障履歴は、２つの整数値によって入手することができる。第１の値は、送信側区分の故障の繰返し数を表示し、第２の値は、その区分の現在状況を反映する。それぞれの受信側区分２５は、送信側区分２２が故障した回数のための値のオウン・コピーを維持する必要がある。このプライベート値は、この特定の送信側のため、システム・エグゼクティブ（ＳＥ）１０によって維持されている値と比較される。この２つの値が一致すれば、送信側は安全である。システム・エグゼクティブ（ＳＥ）１０が、より大きな繰返し値を提示すると、受信側区分２５は、送信側の中で起きた故障が、回復手順をトリガできると結論付ける。回復アクションには、アプリケーションに特化した手順、更新、システム・エグゼクティブによって提示された値に対する送信側の故障繰返しのオウン値、読取りポインタのリセットが含まれる。第２の値は、区分の状況（準備完了、終了した、または初期設定された）を反映する。この方式で、受信側は、送信側とともにＩＰＣアクティビティを再開（または継続）する以前に、その送信側が安全であることを知ることができる。
【００３８】
この方法は、実施が容易であり、ＩＰＣアクティビティの詳細で高価なデータ移動の部分にＳＥ１０を関与させる必要がない。ＳＥ１０がエラーをログ記録し、区分状況を監視するため、送信側の状況を提供することは、受信側区分２５での読取りを可能にすることと同様簡単である。
【００３９】
一般に、入出力（Ｉ／Ｏ）の処理は、ハードウェアに依存する。通常、オペレーティング・システムが、ソフトウェア・ドライバによってＩ／Ｏデバイスを要約し、これが、入力または出力オペレーションを行いながら、デバイス・ハードウェアを管理する。デバイス・ドライバは、デバイスへのアクセスが必要なアプリケーション・タスクのための高レベルなインターフェイスを提供する。Ｉ／Ｏデバイスは共用可能であるため、本環境下の区分間での障害伝搬のための間接的な手段となり得る。たとえば、入力デバイスを誤ってリセットし続けている区分が、他の安全な区分に対する、そのデバイスの可用性を妨げ、したがって、それらのオペレーションを妨害する可能性がある。さらに、図１のＩＭＡ２層アーキテクチャは、どのようにアプリケーションがデバイスにアクセスするのかに関する、多くの問題を提起する。
【００４０】
通常、Ｉ／Ｏデバイスは、２つのタイプ、すなわち、ポーリング・ベースのデバイスと割込駆動型デバイスに分類できる。ポーリング・ベースのＩ／Ｏでは、デバイスは、オンデマンドでアクセス可能となり、アプリケーションにデータの可用性を通知しない。割込駆動型デバイスは、デバイスが以前に開始したオペレーションを完了した時、割込みを生成する。生成された割込みは、ＣＰＵまたは専用デバイス・コントローラのいずれかによって取り扱うことができる。両タイプのデバイスは、メモリ・マップ形でも、またはＩＯマップ形でも良い。メモリ・マップ形Ｉ／Ｏでは、正規メモリ読取り／書込み命令を使用して、デバイスにアクセスする。ＩＯマップ形デバイスのアクセスには、特別のＩ／Ｏ命令を使用する。
【００４１】
本発明による本環境下において、本願は、ＣＰＵがＩ／Ｏデバイスからどの割込みも受信しないことを想定する。Ｉ／Ｏデバイスは、ポーリングされるか、デバイス・コントローラによってサポートされるかであり、デバイスに特化したハードウェア内に含まれて、デバイスとハンドシェークし、データをバッファする。アビオニクスなどの安全臨界リアルタイム・アプリケーションでは、ＣＰＵに対しＩ／Ｏデバイスによって生成される割込みが頻繁に起きると、システムの予測精度が低下し、システムの妥当性検査および認証を著しく複雑なものにする。さらに、ＣＰＵをオフロードし、性能を向上させるために、モデム・コンピュータ・アーキテクチャ上で、デバイス・コントローラまたはＩ／Ｏコプロセッサを使用することは、極めて普通のことである。
【００４２】
ＣＰＵは、メモリ・マップ形Ｉ／Ｏをサポートするか、またはＩＯマップ形デバイスのための区分レベルのアクセス保護を可能にするメカニズムを提供する。すべての場合において、Ｉ／Ｏデバイスへのアクセスに、特権命令を使用するべきではない。近年、メモリ・マップ形Ｉ／Ｏデバイスのサポートが、マイクロプロセッサでほぼ標準となってきている。たとえば、モトローラ（Ｍｏｔｏｒｏｌａ）（登録商標）パワーＰＣ（ＰｏｗｅｒＰＣ）プロセッサは、メモリ・マップ形デバイスのみをサポートしている。メモリ管理ユニットを使用すると、メモリ・マップ形デバイスへのアクセスが、区分のアドレス空間を制限することにより、制御できる。デバイス・アドレスがそのアドレス空間内にある場合は、区分が、正規メモリ・アクセス命令を使用して、デバイスにアクセスできる。他方、インテル・ペンティアム（登録商標）（Ｉｎｔｅｌ　Ｐｅｎｔｉｕｍ（登録商標））プロセッサは、メモリ・マップ形デバイスとＩ／Ｏマップ形デバイスの両方をサポートしている。しかし、ペンティアム（登録商標）・プロセッサのＩ／Ｏ命令は、特権的である。したがって、ペンティアム（登録商標）・プロセッサが本環境下で使用されている場合は、メモリ・マップ形デバイスのみが使用可能である。
【００４３】
本方法におけるデバイス処理は、ＳＥ１０でもＡＥ１５でも行うことができる。ＳＥ１０内でＩ／Ｏデバイスを処理するには、同期メカニズムを実施して、アプリケーション間のオペレーションで正しい順序を維持する必要があり、したがって、ＳＥ１０の設計が複雑なものとなる。ＳＥ１０を簡単なものにしておくことは、ＳＥ１０認証を容易にするための設計目標である。さらに、ＳＥ１０内にデバイス・ハンドラを含めると、ＳＥ１０が、デバイスの変更による影響を受けやすくなる。このような従属性があると、新しくデバイスを追加したり除去したりする度ごとに、ＳＥ１０の再認証が必要となりかねない。他方、アプリケーション・エグゼクティブ（ＡＥ）は、デバイス間調整をせずに、共用Ｉ／Ｏデバイスを取り扱うことができない。
【００４４】
図９を参照すると、本発明の一態様に従って、ＡＥ１５は、そのアプリケーション（区分）によって排他的に使用されるＩ／Ｏデバイスを取り扱う。ＡＥ１５同期プリミティブを使用して、区分内でタスクによって作られるデバイスへのアクセスを管理する。ＳＥ１０は、システム内のすべてのデバイスが１つおよびただ１つの区分にマップされる。バックプレーン・データ・バスなどの区分間の共用デバイスをサポートするために、デバイス・デーモン９４（ハンドラ）が、専用区分内で作成される。次いで、デバイス・デーモン９４は、アクセス要求を、他のアプリケーション区分（Ｐ１、Ｐ２）によって作られるデバイス・ドライバ９３に「供する」。共用デバイス・マネージャ区分Ｐ３はまだ、そのデバイスに対する排他的なアクセスを有する。共用デバイスへの読取りまたは書込みアクセスを必要とするアプリケーション区分が、ＩＰＣプリミティブを介してデバイス・デーモンと通信する。読取り／書取り（たとえば、バックプレーン・バス）、ランダム読取り（たとえば、ディスク）または書込み専用（たとえば、アクチュエータ）タイプのアクセスが可能なデバイスには、デバイス・デーモン９４とアプリケーション区分（Ｐ１、Ｐ２）の間の通信のためのクライアント・サーバＩＰＣプロトコルを使用する必要がある。この場合、デバイス・デーモン９４は、異なる区分からの要求を直列化して、予測可能で同期化されたデバイス・アクセス・パターンを維持する。センサなどのストリーム入力デバイスについては、デバイス・デーモン９４によってＩＰＣストリーム（状態バッファ）が使用され、入力データが他の区分でも使用可能にすることができる。
【００４５】
共用デバイス９３を管理する区分Ｐ３は、デバイス処理のみを行うか、またはデバイス・アクセス要求の処理に加え、ホストとしてアプリケーションを処理することができる。言い換えれば、デバイスを制御する区分Ｐ３は、そのオウン内部タスク間のデバイスへのアクセスを管理し、他の区分からのアクセス要求にも供することができる。使用頻度の高い共用デバイスについては、専用デバイス区分は、通常、応答性を確実にするため、デバイス・デーモンのみを含む。
【００４６】
ホストとして他のアプリケーション・タスクを処理する区分Ｐ３によって共用デバイス９３を管理することには、デバイス・アクセスを必要とする区分と、ホストとしてそのデバイスのためのデーモンを処理するアプリケーション区分との間に従属性が生じるため、ある程度の危険性が伴う。アプリケーション・タスクの故障により、区分全体がクラッシュすると、共用デバイス９３は、もはや他の区分（Ｐ１、Ｐ２）にアクセスできなくなる。この構成では、システムの区分が危険となるため、デバイスへのアクセスがなくなってもそれにより、他の区分が故障するようなことがない場合を除いて、使用してはならない。
【００４７】
ＩＰＣプリミティブを介してデバイス・アクセスを要約すると、同じプロセッサに割当てられている場合でも異なるプロセッサに割当てられている場合でも、アプリケーション間のメッセージのトランスペアレントなルーティング・メッセージを介して、アプリケーションの統合が簡単になる。開発者は、ＩＰＣチャネルを使用して常にアプリケーションを参照する。上述したように、ＩＰＣチャネルが、デバイスまたは他のアプリケーション区分との通信を要約することができる。さらに、一般に、ＩＰＣ通信モデルを使用するのに過度な適応を必要としないため、本方法によれば、もともと連合システムのために設計されたレガシ・アプリケーションの統合が容易になる。
【００４８】
より詳細には、デバイス処理のための本発明による方法の一例が、図９に示してある。２つの区分Ｐ１およびＰ２が、システム内で統合される。第１の区分（Ｐ１）は、出力デバイスＤ１、９０およびＤ３、９３への頻繁なアクセス、そして出力デバイスＤ２、９２への時折のアクセスを必要とする。区分Ｐ２は、デバイスＤ２、９２およびＤ３、９３への大量のアクセスを必要とする。統合環境下では、専用区分Ｐ３が含まれて、共用デバイスＤ３、９３を管理し、Ｐ１およびＰ２による要求に供する。区分Ｐ３が、Ｄ３への排他的アクセスを有し、Ｄ３のためのデバイス・デーモン９４タスクとデバイス・ドライバ９３とを含む。デバイス・ドライバは、デバイス・ハードウェアを要約し、デーモンの一部または別個のライブラリとなり得る。通常、ドライバは、デバイス製造業者により供給される。デーモン・タスクは、読取り可能共用メモリ・エリア内に割当てられた専用要求待ち行列（ＩＰＣ＿ｑｕｅｕｅ）から読み取ることにより、他の区分からの入りアクセス要求を受信する。区分Ｐ１およびＰ２が、共用デバイス区分Ｐ３と通信するため、上述したＩＰＣクライアント・サーバ・メッセージ引渡しプロトコルを使用する。
【００４９】
区分Ｐ１が、Ｄ１への排他的アクセスを有し、他の区分と供給しない。Ｄ２がＰ１とＰ２の間で共用されているため、デバイス・デーモンが必要である。Ｄ２を管理するため、専用区分が含まれている場合がある。あるいは、Ｐ１のＤ２へのアクセスが、Ｐ２のアクセスと比べて、極めてまれであるため、Ｄ２がＰ２に割当てられている。Ｐ２内でのＰ１からおよびタスクからのＤ２に対するアクセス要求を、Ｄ２デバイス・デーモンによるサービスを受けるため待ち行列に入れなければならない。図９に示すように、区分Ｐ２内のタスク、Ｐ２−Ａ、Ｐ２−Ｂが、別個の待ち行列Ｑ２を使用して、デバイスＤ２デーモンに要求を送信し、他の待ち行列Ｑ１が、区分Ｐ１からの要求用に指定される。２つの別個の待ち行列を使用すると、区分、Ｐ１とＰ２の間の従属性が減少する。
【００５０】
その例では、区分毎にただ１つのタスクが、他の区分により管理される共用デバイスへのアクセスを必要とする、たとえば、タスクＰ１−Ｂだけが、デバイスＤ２にアクセスすると想定される。区分毎に多くのタスクが、区分間の共用デバイスへのアクセスを必要とする場合、ＡＥ１５は、区分内で要求のアクセス順序と優先度を管理する必要がある。話を簡単にするため、図には、ただ１つのデバイス書込みシナリオしか示していない。共用デバイス９３からデータを読み取るためには、共用デバイス区分（たとえば、Ｐ３）で、ストリーム・バッファまたは追加の待ち行列が必要である。
【００５１】
本発明によるデバイス処理では、アプリケーション・タスクのスケジューリングと共用デバイスの間の結合を減少することにより、共用デバイスへのアクセス要求をスケジューリングする際のかなりの程度の柔軟性が得られ、したがって、スケジューリングの可能性の分析を単純化することができる。さらに、専用区分に割当てられたデバイス・デーモンを有することにより、区分間の障害の閉込めを確実にし、デバイス・ドライバ内のエラーからアプリケーション区分を保護し、デバッギングを容易にする。繰り返すが、本方法を通じて、ＳＥは、Ｉ／Ｏ処理にほとんど関係せず、所定の単純性を保つ。
【００５２】
共用デバイス・デーモン方法を使用すると、システム積分器は、アプリケーション区分の不可欠な部分としてデーモン区分をスケジュールし、それをスケジューリングの可能性の分析で考慮して、最悪のシナリオでの適時性を確実にする必要がある。デバイス・アクセス要求が増えると、適時なアクセスを確実にするため、高い頻度で、そのデバイスのためのデーモン区分を呼び出す必要が生じる。デバイス・デーモンのために専用区分を使用すると、区分間のメッセージ・トラフィックが増加する可能性が生じるが、共用デバイスのスケジューリングが簡単になり、デバイス状況のグローバルな整合性が確実になる。たとえば、デバイスへのアクセス中にデーモン区分が強制排除される場合である。
【００５３】
本発明は、本明細書に記述した好ましい実施形態による範囲内に限定されるものと考えられるべきではない。本発明の明細書および手法を考慮することにより、当業者が容易に考えられる、その他の利点および修正形態も、以下の特許請求の範囲および趣旨内に含まれるものとする。
付属文書Ａ
クライアント・サーバＩＰＣのためのライブラリ・ルーチン
データ・タイプ
【００５４】
【表１】
2004514959.tif 000003
【００５５】
ＩＰＣ待ち行列が、コンパイル時にアプリケーションによってスタティックに割当てられる。”ＩＰＣ＿ｃｈａｎｎｅｌ＿ｒｅｇｉｓｔｒｙ＿＿ｔａｂｌｅ”は、ＳＥエクゼクティブとのリンク前またはアプリケーション初期設定段階中に構築できる。チャネル・レジストリ・テーブルが初期設定中に構築されると、ＳＥは、特権実行モードで動作している２つのライブラリ・ルーチンをエクスポートしなければならない。アプリケーションが、これらの２つのルーチンを使用して、受信側読取りポインタのＩＰＣ待ち行列とアドレスのためのレジストリ・エントリを挿入する。リンクする前にレジストリ・テーブルを構築するためには、これらの登録手順は必要ではない。レジストリ・テーブルはアプリケーションで読取り可能になるため、ＩＰＣライブラリの残りの部分には、特権実行モードは必要ではない。ＩＰＣライブラリ・ルーチンについて、以下に、その概要を述べる。一般に、ルーチンには、パラメータの広範囲な妥当性検査を行って、厳しい区分が破られる原因となる可能性のある誤ったパラメータ値の検出を確実にする必要がある。
初期設定
送信側も受信側も、それらのオウン・データ構造を初期設定する。その方法を以下に記述する。
ライブラリ・ルーチン
【００５６】
【表２】
2004514959.tif 000004
【００５７】
いったん区分が待ち行列を作成して、メッセージを他の区分に送信すると、その区分は、ＩＰＣデバイス・レジスタ・ライブラリ・ルーチンを使用して、その待ち行列をレジスターするよう要求される。登録により、ＳＥ内のＩＰＣサービスが、送信側のアドレス空間内の待ち行列のアドレス、およびその待ち行列からメッセージを受信するため許可された区分を認識する。このルーチンは、スーパバイザ・モードで動作し、以下のことを行う。
１．　時間ベース・スケジューリング・テーブルに従って、”ｓｅｎｄｅｒ　ＩＤ”パラメータが、現在動作している区分の識別に一致することを検査する。
２．　”ａｕｔｈｏｒｉｚｅｄ ｒｅｃｅｉｖｅｒ”内のエントリが、システム内の既存区分を反映することを確実にする。
３．　待ち行列名およびｓｅｎｄｅｒ＿ＩＤのための”ＩＰＣ＿ｃｈａｎｎｅｌ＿ｒｅｇｉｓｔｒｙ＿ｔａｂｌｅ”を探索する。
４．　”ＩＰＣ＿ｃｈａｎｎｅｌ＿ｒｅｇｉｓｔｒｙ＿ｔａｂｌｅ”内にエントリがある場合は、エントリ内の未定義フィールドを更新する。
５．　既存エントリがない場合は、ＳＥは、”ＩＰＣ＿ｃｈａｎｎｅｌ＿＿ｒｅｇｉｓｔｒｙ＿ｔａｂｌｅ”内の使用可能な空間をチェックして、その待ち行列のためにレジストリ・テーブル内にエントリを挿入することによって待ち行列をレジスターする。
６．　正しく完了した場合にはゼロを返し、正しく完了しなかった場合には、ゼロ以外のエラー・コードを返す。
【００５８】
【表３】
2004514959.tif 000005
【００５９】
いったん受信側区分が、送信側区分内のＩＰＣのための、次に読み込むメッセージのオウン索引を作成し初期設定すると、受信側は、ＩＰＣ＿ｄｅｖｉｃｅ＿ａｃｋ＿ｒｅｇｉｓｔｅｒライブラリ・ルーチンを使用して、この索引のアドレスをレジスターするよう要求される。その後、送信側区分は、”ＩＰＣ＿ｃｈａｎｎｅｌ−ｒｅｇｉｓｔｒｙ ｔａｂｌｅ”を照会し、受信側の読取り索引のアドレスを得、消費されたメッセージによって占有されている空間のメッセージ受信通知と再利用のために、それを使用する。このルーチンは、スーパバイザ・モードで動作し、以下のことを行う。
１．　待ち行列名およびｓｅｎｄｅｒ＿ＩＤのための”ＥＰＣ＿ｃｈａｎｎｅｌ＿ｒｅｇｉｓｔｒｙ＿ｔａｂｌｅ”を探索する。
２．　”ＩＰＣ＿ｃｈａｎｎｅｌ＿ｒｅｇｉｓｔｒｙ＿ｔａｂｌｅ”内にエントリがある場合は、現在動作中の区分が許可受信側であることを確認し、受信側の読取り索引のアドレスを更新する。
３．　既存エントリがない場合は、ＳＥは、”ＩＰＣ＿ｃｈａｎｎｅｌ＿ｒｅｇｉｓｔｒｙ＿ｔａｂｌｅ”内の使用可能な空間をチェックして、その待ち行列のためのレジストリ・テーブル内にエントリを挿入することによって待ち行列をレジスターする。
４．　正しく完了した場合にはゼロを返し、正しく完了しなかった場合には、ゼロ以外のエラー・コードを返す。
【００６０】
【表４】
2004514959.tif 000006
【００６１】
受信側区分は、このルーチンを使用して、送信側が指定したメッセージ待ち行列のアドレスを得る。このルーチンは、ユーザ・モードで動作し、以下のことを行う。
１．　待ち行列名およびｓｅｎｄｅｒ＿ＩＤのための”ＩＰＣ＿ｃｈａｎｎｅｌ＿ｒｅｇｉｓｔｒｙ＿ｔａｂｌｅ”を探索する。
２．　待ち行列アドレスを返す。
３．ノットファウンド・エラーの場合、−１を返す。
【００６２】
【表５】
2004514959.tif 000007
【００６３】
送信側区分は、このルーチンを使用して、受信側の読取り索引のアドレスを得る。このルーチンは、ユーザ・モードで動作し、以下のことを行う。
１．　（現在動作中の区分である）待ち行列名およびｓｅｎｄｅｒ＿ＩＤのための”ＩＰＣ＿ｃｈａｎｎｅｌ＿ｒｅｇｉｓｔｒｙ＿ｔａｂｌｅ”を探索する。
２．受信側の読取り索引のアドレスを返す。
３．ノットファウンド・エラーの場合、−１を返す。
ｉｎｔＩＰＣ＿ｄｅｖｉｃｅ＿ｗｒｉｔｅ（ＩＰＣ＿ｑｕｅｕｅ＊ ｑｕｅｕｅ， ｃｈａｒ＊ ｍｅｓｓａｇｅ
送信側区分は、ライブラリ機能”ＩＰＣ＿ｄｅｖｉｃｅ＿ｗｒｉｔｅ”を呼び出して、特定の待ち行列内に新しいメッセージを入れる。この待ち行列は、巡回データ構造であり、したがって、書込み索引ｗｔは、待ち行列の最後に到着した後、０にリセットされる。さらに、安全のため、空メッセージ・スロットが、最新挿入メッセージと、受信側が次に読み取るメッセージとの間の分離記号として、常に保有される。これは、速い受信側が古いメッセージを読み取るのを防ぐための巡回待ち行列内の安全策である。空メッセージは、このような速い読取り側を停止する。送信オペレーションの要約は、メッセージ待ち行列に対応するＩＰＣデバイスへの書込みである。このルーチンは、ユーザ・モードで動作し、以下のアクションを行う。
１．　待ち行列オーバフローをチェックする。待ち行列が一杯である場合は、クリーンアップ・ステップ２、３、４、５、６を行い、それ以外の場合は、ステップ７に進む。
２．　受信側の読取り索引のアドレスが分からない場合は、ＩＰＣ＿ｄｅｖｉｃｅ＿ｇｅｔＡｃｋＡｄｄｒｅｓｓを使用して、それを得るよう試みる。
３．　受信側の読取り索引のアドレスがまだ分からない場合は、エラーを返す。
４．　（ｗｔ ｉｎｄｅｘの値が、送信側の読取り索引の直後にあり）そして（送信側と受信側の両方の中の読取り側索引が同じ）場合は、オーバフローのためのエラーを返す。
５．　送信側の読取り索引に対応する場所から、受信側の読取り索引の場所を含まず、受信側の読取り索引の場所まで、メッセージを無効化する。
６．　送信側の読取り索引を受信側の読取り索引の現在値に設定する。
７．　ｗｔ ｉｎｄｅｘによって示されている場所で、メッセージを送信側待ち行列にコピーする。
８．　メッセージの状況をＶＡＬＩＤとマーク付けする。
９．　”ｗｔ”の値を次の場所に進める。
１０．　正しく完了した場合にはゼロを返し、正しく完了しなかった場合には、ゼロ以外のエラー・コードを返す。
オーバフロー状態とは、”ｗｒｉｔｅ＿ｐｏｉｎｔｅｒ”に対応する待ち行列内の場所が、一杯（ＩＰＣ＿ｑｕｅｕｅ．ｑｕｅｕｅ＿ｍｓｇ［ｗｒｉｔｅ＿ｐｏｉｎｔｅｒ］．ｓｔａｔｕｓ ＝＝ ＶＡＬＩＤ
ｉｎｔＩＰＣ＿ｄｅｖｉｃｅ＿ｒｅａｄ（ＩＰＣ＿ｑｕｅｕｅ＊ ｑｕｅｕｅ，ｉｎｔ＊ｒｃｖＲｄ，ｃｈａｒ ＊ｍｓｇ） の時である。
【００６４】
受信側区分は、ライブラリ機能”ＩＰＣ＿ｄｅｖｉｃｅ＿ｒｅａｄ”を呼び出して、送信側待ち行列からメッセージを得る。受信側オペレーションの要約は、送信側待ち行列に対応するＩＰＣデバイスからの読取りである。このルーチンは、次に有効なメッセージを検索して、受信側の読取り索引を進めるだけである。このルーチンは、タイム・スライス中に受信側区分のアドレス空間内でユーザ・モードで動作し、以下のアクションを行う。
１．　待ち行列アンダフロー（ＩＰＣ＿ｑｕｅｕｅ．ｂｕｆｆｅｒ［ｒｃｖＲｄ］．ｓｔａｔｕｓ ＝＝ ＥＭＰＴＹ）をチェックする。待ち行列が空の場合は、ゼロ以外のエラー・コードを返す。
２．　受信側の読取り索引を使用して、待ち行列から次のメッセージを得る。
３．　受信側の読取り索引の値を次の場所に進める。
４．　正しく完了した場合にはゼロを返し、正しく完了しなかった場合には、ゼロ以外のエラー・コードを返す。
付属文書Ｂ
ストリームＩＰＣのためのライブラリ・ルーチン
データ・タイプ
【００６５】
【表６】
2004514959.tif 000008
【００６６】
ＩＰＣストリームが、コンパイル時にアプリケーションによってスタティックに割当てられる。”ＩＰＣ＿ｓｔｒｅａｍ＿ｒｅｇｉｓｔｒｙ＿ｔａｂｌｅ”は、ＳＥエクゼクティブとのリンク前またはアプリケーション初期設定段階中に構築できる。ストリーム・レジストリ・テーブルが初期設定中に構築されると、ＳＥは、特権実行モードで動作しているライブラリ・ルーチンをエクスポートしなければならない。アプリケーションが、そのルーチンを使用して、そのＩＰＣストリームのためのレジストリ・エントリを挿入する。リンクする前にレジストリ・テーブルを構築すると、このような登録手順を必要としない。登録テーブルはアプリケーションで読取り可能にできるため、ＩＰＣライブラリの残りの部分は、特権実行モードを必要としない。ＩＰＣライブラリ・ルーチンについて、以下に、その概要を記述する。一般に、ルーチンには、パラメータの広範囲な妥当性検査を行って、厳しい区分が破られる原因となる可能性のある、誤ったパラメータ値を検出することを確実にする必要がある。
ライブラリ・ルーチン
【００６７】
【表７】
2004514959.tif 000009
【００６８】
いったん区分が状況メッセージのためのストリーム・バッファを作成すると、その区分は、ＩＰＣ＿ｓｔｒｅａｍ＿ｒｅｇｉｓｔｅｒライブラリ・ルーチンを使用して、そのストリームをレジスターするよう要求される。登録により、ＳＥ内のＩＰＣサービスが、このストリームからメッセージを検索するため許可されたストリームと区分のアドレスを認識する。このルーチンは、スーパバイザ・モードで動作し、以下のアクションを行う。
１．　時間ベース・スケジューリング・テーブルに従って、”ｓｅｎｄｅｒ＿ＩＤ”パラメータが、現在動作している区分の識別に一致することを検査する。
２．　”ａｕｔｈｏｒｉｚｅｄ＿ｒｅｃｅｉｖｅｒｓ”テーブル内のエントリが、システム内の実際の既存区分を反映することを確実にする。
３．　パラメータ内にエラーや不整合がない場合は、ＳＥは、”ＩＰＣ＿ｓｔｒｅａｍ＿ｒｅｇｉｓｔｒｙ＿ｔａｂｌｅ”内にそのストリームのためのエントリを挿入することにより、ストリームをレジスターする。さらに、ＳＥは、読取り専用アクセスのためのストリームを、許可受信側のアドレス空間にマップする。
４．　正しく完了した場合にはゼロを返し、正しく完了しなかった場合には、ゼロ以外のエラー・コードを返す。
【００６９】
【表８】
2004514959.tif 000010
【００７０】
ストリーム・バッファからデータ・メッセージを検索するため、受信側区分は、このルーチンを使用して、送信側区分のアドレス空間内のストリーム・バッファのアドレスを見つけ出す必要がある。このルーチンは、ユーザ・モードで動作し、以下のことを行う。
１．　ストリーム名および送信側ＩＤのための”ＩＰＣｓｔｒｅａｍ＿ｒｅｇｉｓｔｒｙ＿ｔａｂｌｅ”を探索する。
２．　このストリームを使用して、現在動作している区分が、送信側区分からメッセージを受信するよう許可されていることをチェックする。
３．　ストリームが登録されている場合は、ストリーム・バッファのアドレスを返す。
４．ノットファウンド・エラーの場合、−１を返す。
ｉｎｔＩＰＣ＿ｓｔｒｅａｍ＿ｗｒｉｔｅ（ＩＰＣ＿ｓｔｒｅａｍ＊ ｓｔｒｅａｍ，ｃｈａｒ＊ ｍｅｓｓａｇｅ）
送信側区分は、ライブラリ機能”ＩＰＣ＿ｓｔｒｅａｍ＿ｗｒｉｔｅ”を呼び出して、ストリームにメッセージを書き込む必要がある。このルーチンは、アプリケーション実行スタックを使用して、ユーザ・モードで実行する。ストリームは巡回であり、したがって、ストリームの最後に到着した後、第１のメッセージの場所に書込みポインタをリセットする。送信オペレーションの要約は、ストリームに対応するＩＰＣストリームへの書込みである。”ＩＰＣ＿ｓｔｒｅａｍ＿ｗｒｉｔｅ”ルーチンは、以下のアクションを行う。
１．　”ｗｒｉｔｅ＿ｉｎｄｅｘ”に対応する場所のメッセージ状況を、ＩＮＶＡＬＩＤに設定する。
２．　”ｗｒｉｔｅ＿ｉｎｄｅｘ”を使用して、受信側待ち行列にメッセージをコピーする。
３．　メッセージのためのチェック・サムを生成し、それをＣＲＣフィールドに格納する。
４．　”Ｍｓｇ＿ＩＤ”をメッセージ・シーケンス・カウンタの値に設定する。
５．メッセージ状況を、ＶＡＬＩＤに設定する。
６．　”ｗｒｉｔｅ＿ｉｎｄｅｘ”の値を次の場所に進める。
７．　メッセージ・シーケンス・カウンタの値を増加させる。
８．　正しく完了した場合にはゼロを返し、正しく完了しなかった場合には、ゼロ以外のエラー・コードを返す。
【００７１】
チェックすべきオーバフロー状況がないことに留意されたい。単に、送信側は、最新状況メッセージでストリーム内に次のエントリを上書きするだけである。メッセージ状況フィールドは、メッセージを書き込む前に無効化され、その結果、送信側が完了前に強制排除されている場合、受信側は、破損されたメッセージの読取りを停止される。
ｉｎｔＩＰＣ＿ｓｔｒｅａｍ＿ｒｅａｄ（ＩＰＣ＿ｓｔｒｅａｍ＊ ｓｔｒｅａｍ， ｉｎｔ＊ ｒｅａｄ−ｉｎｄｅｘ，
ｃｈａｒ＊＊ ｍｅｓｓａｇｅ
受信側区分は、ＳＥライブラリ機能”ＩＰＣ＿ｄｅｖｉｃｅ＿ｒｅａｄ”を呼び出して、ストリームからメッセージを得る必要がある。それぞれの受信側が、そのオウン読取り索引を保有し、これが、ストリームから読み取るための次のメッセージを識別する。異なる受信側が、ストリーム内で異なる場所から読み取っている可能性がある。このルーチンは、アプリケーション実行スタックを使用して、ユーザ・モードで実行する。受信オペレーションの要約は、送信側ストリームに対応するＩＰＣストリームからの読取りである。”ＩＰＣ＿ｓｔｒｅａｍ＿ｒｅａｄ”ルーチンは、以下のアクションを行う。
１．　ストリーム・アンダフロー（ｓｔｒｅａｍ．ｓｔｒｅａｍ＿ｍｓｇ［ｒｅａｄ ｉｎｄｅｘ］．ｓｔａｔｕｓ ＩＮＶＡＬＩＤ）をチェックする。ストリームが空の場合は、ゼロ以外のエラー・コードを返す。
２．　ストリームが空でない場合は、”ｒｅａｄ＿ｐｏｉｎｔｅｒ”を使用して、ストリームから次のメッセージを得る。
３．　ＣＲＣをチェックする。ＣＲＣが正しい場合は、ステップ６に進む。
４．　ＣＲＣが正しくない場合は、アンダフローをチェックする。
５．　ストリームが空の場合は、ゼロ以外のエラー・コードのアンダフロー表示（ＩＬ）を返す。ストリームが空でない場合は、送信側区分内の故障を表示するエラー・コードを返す。
６．”ｒｅａｄ−ｉｎｄｅｘ”の値を次の場所に進める。
７．正しく完了した場合にはゼロを返し、正しく完了しなかった場合には、ゼロ以外のエラー・コードを返す。
【００７２】
ＣＲＣが正しくない場合は、受信側がメッセージを完全に読み取る前に強制排除され、送信側がそれを上書きした可能性がある。したがって、再試行を行う。再試行しても、なおＣＲＣが正しくならない場合は、エラーの原因が、ハードウェア内の送信側区分内の故障であることを表示する。しかし、再試行して、ストリームが空であることが表示された場合は、ルーチンは、送信側がメッセージを完全に上書きする前に強制排除され、読取り索引によって参照した場所が、準備完了データを含んでいないと結論付ける。
【図面の簡単な説明】
【図１】
本発明に用いることのできる２層オペレーティング環境を示す図である。
【図２】
本発明によるクライアント・サーバ区分間メッセージ引渡しプロトコルを示す図である。
【図３】
区分間通信（ＩＰＣ）チャネルのレジストリ・テーブルを示す図である。
【図４】
本発明に従って開発されたＩＰＣ待ち行列へのアクセスを示す図である。
【図５】
本発明に従って開発された巡回待ち行列を示す図である。
【図６】
本発明に従って開発された本発明の送信アルゴリズムのためのコマンドを示すテーブルである。
【図７】
本発明に従って開発された受信アルゴリズムのためのコマンドを示すテーブルである。
【図８】
本発明に従って開発された本発明での同報ストリーム・バッファを示す図である。
【図９】
本発明に従って開発された出力デバイスの処理を示す図である。
【図１】
2004514959.tif 000011
【図２】
2004514959.tif 000012
【図３】
2004514959.tif 000013
【図４】
2004514959.tif 000014
【図５】
2004514959.tif 000015
【図６】
2004514959.tif 000016
【図７】
2004514959.tif 000017
【図８】
2004514959.tif 000018
【図９】
2004514959.tif 000019
【国際公開パンフレット】
2004514959.tif 000020
2004514959.tif 000021
2004514959.tif 000022
2004514959.tif 000023
2004514959.tif 000024
2004514959.tif 000025
2004514959.tif 000026
2004514959.tif 000027
2004514959.tif 000028
2004514959.tif 000029
2004514959.tif 000030
2004514959.tif 000031
2004514959.tif 000032
2004514959.tif 000033
2004514959.tif 000034
2004514959.tif 000035
2004514959.tif 000036
2004514959.tif 000037
2004514959.tif 000038
2004514959.tif 000039
2004514959.tif 000040
2004514959.tif 000041
2004514959.tif 000042
2004514959.tif 000043
2004514959.tif 000044
2004514959.tif 000045
2004514959.tif 000046
2004514959.tif 000047
2004514959.tif 000048
2004514959.tif 000049
2004514959.tif 000050
2004514959.tif 000051
2004514959.tif 000052
2004514959.tif 000053
2004514959.tif 000054
2004514959.tif 000055
2004514959.tif 000056
2004514959.tif 000057
2004514959.tif 000058
2004514959.tif 000059
2004514959.tif 000060
2004514959.tif 000061
2004514959.tif 000062
2004514959.tif 000063
2004514959.tif 000064