(57)【要約】【課題】サーバクライアントシステムで、集中管理/分散管理にかかわらず、ソフトコード不変でタスク管理するタスク管理制御方法を得る。【解決手段】サーバのタスクＡ  ５０１からクライアントのタスクＢ  ５０３を起動するとき、サーバのＯＳ５０４からタスクＢの起動要求ＶＡＲ＿Ｄａｔ  １１０を仮想リソースアクセス管理５０５の仮想リソースアクセス１０２に転送し、仮想リソースアクセス１０２はＶＲ＿ＬＯＣ＿Ｔａｂｌ  １０１からタスクＢの所在を探索してＣ−ＣＰＵ４０１へアクセス要求を行う。仮想リソースアクセス１０２は、ＶＡＲ＿Ｄａｔ１１０をＭＥＭ２  ４０３に転送後、割り込みルーチン１０６を起動する。仮想リソースアクセス管理６０２の割り込みルーチン１０６はＶＡＲ＿Ｄａｔ  １１０をデコードし、ＯＳ６０１内のタスク管理６０１１経由で、タスクレディキュー１０７にタスクＢのＩＤを登録後、ディスパッチャ１０８を起動する。【選択図】図１
2011238168.tif 000002
【特許請求の範囲】
【請求項１】
互いに結合されるプロセッサをそれぞれ有するサーバとクライアントの連携システムにおけるタスク制御方法であって、
前記サーバは、前記プロセッサで動作する第１のＯＳと、前記第１のＯＳと前記第１のプロセッサの間に位置する第１の仮想リソースアクセス管理とを備え、
前記クライアントは、前記プロセッサで動作する第２のＯＳと、第２のＯＳと前記プロセッサの間に位置する第２の仮想リソースアクセス管理を備え、
前記第１のＯＳから前記第１の仮想リソースアクセス管理に、仮想リソースアクセス用データを転送し、
前記第１の仮想リソースアクセス管理は、前記仮想リソースアクセス用データに対応するタスクが、前記クライアントにある場合、前記仮想リソースアクセス用データと割り込み制御信号を前記クライアントに送出し、
前記第２の仮想リソースアクセス管理は、前記割り込み制御信号に応答し、割り込みルーチンを起動し、
前記割り込みルーチンは、前記仮想リソースアクセス用データに基づき、前記タスクをタスクレディキューに登録し、前記第２のＯＳのディスパッチャを起動する、
ことを特徴とするタスク制御方法。
【請求項２】
請求項１記載のタスク制御方法であって、
前記仮想リソースアクセス用データは、
前記タスクの起動のサービスコールを発行したタスクのＩＤと、
アクセス先の仮想リソースの種類とＩＤと、
前記仮想リソースに対するアクションの種類と、
前記サービスコールのＩＤと、
前記仮想リソースのＩＤ以外の前記サービスコールの引数のタイプと先頭アドレスとからなる、
ことを特徴とするタスク管理方法。
【請求項３】
請求項２記載のタスク制御方法であって、
前記仮想リソースの種類とはタスクかデータであり、
前記アクションの種類はタスク管理かデータアクセスである、
ことを特徴とするタスク管理方法。
【請求項４】
請求項１記載のタスク制御方法であって、
前記第１の仮想リソースアクセス管理は、仮想リソースロケーションテーブルを管理し、
前記仮想リソースロケーションテーブルで、前記サーバと前記クライアント上の全ての仮想リソースの各タスクについて、
前記仮想リソースの種類、前記仮想リソースのＩＤ、および前記仮想リソースのロケーションを登録する、
ことを特徴とするタスク制御方法。
【請求項５】
請求項１記載のタスク制御方法であって、
前記第１の仮想リソースアクセス管理は、仮想リソースロケーションテーブルを管理し、
前記仮想リソースロケーションテーブルで、前記サーバと前記クライアント上の全ての仮想リソースの各データについて、
前記仮想リソースの種類、前記仮想リソースのＩＤ、前記仮想リソースのロケーション、および前記データの先頭アドレスを登録する、
ことを特徴とするタスク制御方法。
【請求項６】
請求項１記載のタスク制御方法であって、
前記第１の仮想リソースアクセス管理は、仮想リソースロケーションテーブルを管理し、
前記仮想リソースロケーションテーブルに、前記サーバと前記クライアント上の全ての仮想リソースについて、前記仮想リソースの種類、前記仮想リソースのＩＤ、および前記仮想リソースのロケーションを登録し、
前記第１の仮想リソースアクセス管理は、登録された前記仮想リソースの前記ロケーションを用いて、前記タスクが前記サーバと前記クライアントのどちらにあるかを判定する、
ことを特徴とするタスク制御方法。
【請求項７】
請求項１記載のタスク制御方法であって、
前記タスクが前記サーバ内にある場合、
前記第１のＯＳのタスク管理ルーチンを起動して、前記タスクの起動を実行する、
ことを特徴とするタスク制御方法。
【請求項８】
互いに結合されるサーバとクライアントが連携してタスク制御を行うサーバクライアント連携システムであって、
前記サーバは、第１のメモリと、第１のプロセッサと、前記第１のメモリに記憶され、第１のプロセッサで動作する第１のＯＳと前記第１のＯＳと前記第１のプロセッサの間に位置する第１の仮想リソースアクセス管理とを備え、
前記クライアントは、第２のメモリと、第２のプロセッサと、前記第２のプロセッサの割込みコントローラと、前記第２のメモリに記憶され、前記第２のプロセッサで動作する第２のＯＳと前記第２のＯＳと前記第２のプロセッサの間に位置する第２の仮想リソースアクセス管理を備え、
前記サーバの前記第１のＯＳは前記第１の仮想リソースアクセス管理に、仮想リソースアクセス用データを転送し、
前記第１の仮想リソースアクセス管理は、前記仮想リソースアクセス用データに対応するタスクが、前記サーバと前記クライアントのどちらにあるか決定し、
前記タスクが前記クライアントにある場合、前記仮想リソースアクセス用データと割り込み制御信号を前記クライアントに送出し、
前記クライアントの前記第２の仮想リソースアクセス管理は、前記割り込み制御信号に応答し、割り込みルーチンを起動し、
前記割り込みルーチンは、前記仮想リソースアクセス用データに基づき、前記タスクをタスクレディキューに登録し、前記第２のＯＳのディスパッチャを起動する、
ことを特徴とするサーバクライアント連携システム。
【請求項９】
請求項８記載のサーバクライアント連携システムであって、
前記仮想リソースアクセス用データは、
前記タスクの起動のサービスコールを発行したタスクのＩＤと、
アクセス先の仮想リソースの種類とＩＤと、
前記仮想リソースに対するアクションの種類と、
前記サービスコールのＩＤと、
前記仮想リソースのＩＤ以外の前記サービスコールの引数のタイプと先頭アドレスとからなる、
ことを特徴とするサーバクライアント連携システム。
【請求項１０】
請求項９記載のサーバクライアント連携システムであって、
前記仮想リソースの種類とはタスクかデータであり、
前記アクションの種類はタスク管理かデータアクセスである、
ことを特徴とするサーバクライアント連携システム。
【請求項１１】
請求項８記載のサーバクライアント連携システムであって、
前記第１の仮想リソースアクセス管理は、
前記第１のメモリ上に仮想リソースロケーションテーブルを管理し、
前記仮想リソースロケーションテーブルで、前記サーバと前記クライアント上の全ての仮想リソースについて、
前記仮想リソースの種類、前記仮想リソースのＩＤ、および前記仮想リソースのロケーションを登録し、
前記第１の仮想リソースアクセス管理は、前記仮想リソースロケーションテーブルに登録された前記仮想リソースの前記ロケーションを用いて、前記タスクが前記サーバと前記クライアントのどちらにあるかを判定する、
ことを特徴とするサーバクライアント連携システム。
【請求項１２】
請求項８記載のサーバクライアント連携システムであって、
前記第２の仮想リソースアクセス管理の前記割り込みルーチンは、前記仮想リソースアクセス用データをデコードし、前記タスクのＩＤを抽出する、
ことを特徴とするサーバクライアント連携システム。
【請求項１３】
請求項１２記載のサーバクライアント連携システムであって、
前記第２の仮想リソースアクセス管理の前記割り込みルーチンは、前記第２のＯＳのタスク管理処理ルーチン経由で、前記第２のメモリに記憶された前記タスクレディキューに前記タスクのＩＤを登録する、
ことを特徴とするサーバクライアント連携システム。
【請求項１４】
請求項８記載のサーバクライアント連携システムであって、
前記第１の仮想リソースアクセス管理は、前記タスクが前記サーバ内にあると判定した場合、
前記第１のＯＳのタスク管理ルーチンを起動して、前記タスクの起動を実行する、
ことを特徴とするサーバクライアント連携システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバクライアント連携システムに係り、特に、分散管理システム、集中管理システムの切り替え時に、タスク管理やタスク間の通信を不変化するタスク制御技術に関する。
【背景技術】
【０００２】
組み込みシステムで複数モジュールからなる機械を制御する方法として、集中制御と分散制御がある。前者は一箇所でコンピュータ処理を全て行う方法で、後者はモジュールごとの制御を分散させる方法である。
【０００３】
２つの方法には利害得失があり、場合によりいずれかが選択される。前者は、コンピュータ処理を一箇所に集めるため、低コストで、かつモジュール間の同期が容易となる。後者は、コスト高でソフトが複雑化するが、制御コンピュータと機械との間の通信ネックが解消でき高速化に効果がある。
【０００４】
このため、ユーザニーズにより、両者のどちらを選ぶかが変わってくる。両方のユーザニーズを満たすためには、両者が簡単に切り替えられる仕掛けが要求される。
【０００５】
集中制御と分散制御の切り替え方法を提示する技術として、特許文献１や特許文献２に係る発明がある。これらはどちらも、仮想マシンの下位に、例えば仮想環境制御部を設け、他の仮想マシンとのデータ通信を可能とする。具体的には、実マシンａ上の仮想マシンＡから仮想マシンＢへのデータ送信時に、仮想マシンＢが実マシンａ上にあるか、他の実マシンｂ上にあるかを判定する。そして、他の実マシンｂ上にある時は、ネットワーク経由で仮想マシンＡから仮想マシンＢへデータ転送することとなる。すなわち、仮想環境制御部によって、「仮想マシンＡと仮想マシンＢが共に実マシンａ上にある場合（集中制御）」と、「仮想マシンＡが実マシンａ上にあって、仮想マシンＢが実マシンｂ上にある場合（分散制御）」の違いを吸収することが可能になる。その結果、仮想マシンＡ自身は、集中制御と分散制御の違いを意識することなく、データ転送を行うことが可能となる。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００８−２７８４７８号公報
【特許文献２】特開２００３−１８６７０７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、上述の特許文献１及び２に係る発明では、集中制御と分散制御の切り替えを容易に行うという目的に対しては不十分である。両者の切り替えを容易に行うためには、複雑で変更が多いソフトの切り替えをほぼ不要にすることが望ましいが、特許文献１及び２に係る発明は、データ転送についてしか考慮されておらず、複数の実マシン間でのタスク間通信の問題を考慮していないためである。
【０００８】
本発明は、上記の課題を解決するため、タスク間のデータ通信だけでなく、タスク管理もアプリケーションコードを不変にするサーバクライアント連携システム、及びタスク制御方法を提供することを目的とする。
【課題を解決するための手段】
【０００９】
上記の目的を達成するため、本発明においては、互いに結合されるプロセッサをそれぞれ有するサーバとクライアントの連携システムにおけるタスク制御方法であって、サーバは、プロセッサで動作する第１のＯＳと、第１のＯＳとプロセッサの間に位置する第１の仮想リソースアクセス管理とを備え、クライアントは、プロセッサで動作する第２のＯＳと、第２のＯＳとプロセッサの間に位置する第２の仮想リソースアクセス管理を備え、第１のＯＳから第１の仮想リソースアクセス管理に仮想リソースアクセス用データを転送し、第１の仮想リソースアクセス管理は、仮想リソースアクセス用データに対応するタスクが、クライアントにある場合、仮想リソースアクセス用データと割り込み制御信号をクライアントに送出し、第２の仮想リソースアクセス管理は、割り込み制御信号に応答し、割り込みルーチンを起動し、割り込みルーチンは、仮想リソースアクセス用データに基づき、タスクをタスクレディキューに登録し、第２のＯＳのディスパッチャを起動するタスク制御方法を提供する。
【００１０】
また、上記の目的を達成するため、本発明においては、互いに結合されるサーバとクライアントが連携してタスク制御を行うサーバクライアント連携システムであって、サーバは、第１のメモリと、第１のプロセッサと、第１のメモリに記憶され、第１のプロセッサで動作する第１のＯＳと第１のＯＳと第１のプロセッサの間に位置する第１の仮想リソースアクセス管理とを備え、クライアントは、第２のメモリと、第２のプロセッサと、第２のプロセッサの割込みコントローラと、第２のメモリに記憶され、第２のプロセッサで動作する第２のＯＳと第２のＯＳと第２のプロセッサの間に位置する第２の仮想リソースアクセス管理を備え、サーバの第１のＯＳは第１の仮想リソースアクセス管理に、仮想リソースアクセス用データを転送し、第１の仮想リソースアクセス管理は、仮想リソースアクセス用データに対応するタスクが、サーバとクライアントのどちらにあるか決定し、タスクがクライアントにある場合、仮想リソースアクセス用データと割り込み制御信号をクライアントに送出し、クライアントの第２の仮想リソースアクセス管理は、割り込み制御信号に応答して割り込みルーチンを起動し、割り込みルーチンは、仮想リソースアクセス用データに基づき、タスクをタスクレディキューに登録し、第２のＯＳのディスパッチャを起動する構成のサーバクライアント連携システムを提供する。
【００１１】
さらに、本発明のうち代表的な実施態様の概要を簡単に説明すれば以下の通りである。
仮想リソースがバスやネットワーク越しの別システム上にあるときに、ＯＳとハードウェアの間に、仮想リソースへのアクセスを管理する層である仮想リソースアクセス管理をもうける。
サーバ側では、クライアントにある仮想リソースに対して、ＯＳからアクセス要求があれば、仮想リソースアクセス用のコードを作成して、クライアントに対してアクセスする。
このアクセス要求がタスク管理であれば、管理対象のタスクの名称やサービスコールのＩＤをバスやネットワーク経由で転送し、その後、クライアント上のプロセッサへ割込みをかける。
上記の割込みによりクライアントの割込みルーチンは、ＯＳ上のデータキューにタスクを登録し、ディスパッチャを起動することにより実施する。具体的にはタスク起動の場合には、タスクレディキューに起動対象のタスクを登録し、その後ディスパッチャを起動する。
【発明の効果】
【００１２】
本発明により、集中制御と分散制御の切り替えを容易に行うことができるため、ユーザの多様な要求に対応可能となる。
【図面の簡単な説明】
【００１３】
【図１】本発明の第１の実施例の分散制御におけるタスク起動の全体構成図である。
【図２】第１の実施例の一適用形態である、血液自動分析装置の全体構成図である。
【図３】第１の実施例に係る、集中制御での制御系の全体構成図である。
【図４】第１の実施例に係る、分散制御での制御系の全体構成図である。
【図５】第１の実施例に係る、集中制御でのソフトウェア構成図である。
【図６】第１の実施例に係る、分散制御でのソフトウェア構成図である。
【図７】第１の実施例に係る、タスク制御のコード例を示す図である。
【図８】第１の実施例に係る、仮想リソースアクセス用データのフォーマット例を示す図である。
【図９】第１の実施例に係る、仮想リソースアクセス用データテーブルのフォーマット例を示す図である。
【図１０】第１の実施例に係る、仮想リソースアクセスのフローチャート図である。
【図１１】第１の実施例に係る、クライアントシステム上のタスク起動の動作を示すガントチャート図である。
【図１２】第１の実施例に係る、クライアント上のタスク起動時のクライアント側の割込みハンドラのフローチャート図である。
【図１３】第１の実施例に係る、ＯＳ内のタスク管理のフローチャート図である。
【発明を実施するための形態】
【００１４】
以下、本発明による代表的な実施例を図面に従って詳細に説明する。なお、以下においては、同じ参照番号、記号は同じものもしくは類似のものを表わすものとする。なお、以下の説明において、複数のプロセッサがバスやネットワークを介して接続されたマルチプロプロセッサシステムで、スケジューラタスクが動作するプロセッササイドをサーバあるいはホストと呼び、それ以外の制御タスクが実行されるプロセッササイドをクライアントと呼ぶ。サーバとクライアントのハード構成は同一であって良く、スケジューラタスクが動作するプロセッササイドがサーバ、ホストとなる。
【実施例１】
【００１５】
第１の実施例は、複数モジュールからなる機械システムに、サーバクライアント連携システムのタスク制御方法を適用した実施例である。
【００１６】
１．機械システムの例
まず、図２に従い、本実施例の複数モジュールからなる機械システムの一適用例である血液自動分析装置を説明する。なお、複数モジュールからなる機械システムの他の例としては、自動車やファクトリーオートメーション等が存在する。
【００１７】
図２は、血液を自動分析する装置構成の概念図を示す。血液自動分析装置は、機械系部分２０１と制御系部分２０２からなる。
【００１８】
機械系部分２０１はディスク上の血液サンプルを運搬するセル群２０１１を中心に、セルに血液サンプルを分注するサンプル分注機構２０１２、血液サンプルを分注されたセルに試薬を分注する薬分注機構２０１３、セル内のサンプルと試薬を攪拌する攪拌機構２０１４、およびセルに光を当てサンプルを分析する測光機構２０１５が、主な構成要素となる。
【００１９】
制御系部分２０２は、制御ライン２０２０を経由して機械系部分２０１の機械を制御する部分で、モータをドライブする電子部品が搭載されている複数のＭＤ（Ｍｏｔｏｒ  Ｄｒｉｖｅ）ボード２０２１と、制御全体の計画を立てＭＤボード２０２１にドライブの指示をする処理部であるＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｇ  Ｕｎｉｔ）ボード２０２２から構成する。複数のＭＤボード２０２１と、ＣＰＵボード２０２２はバス２０２３で接続されている。ここでは、ＣＰＵボード２０２２がサーバ或いはホスト、ＭＤボード２０２１がクライアントとなる。
【００２０】
２．制御系部分のハード構成
制御系部分２０２の制御方法として、ＣＰＵボード２０２２のみでＭＤへの指示を全て行う集中制御と、ＣＰＵボード２０２２以外に一部の制御はＭＤボード２０２１で分散して行う分散制御があり、これらの各々のハード構成を、図３と図４に従い、以下に述べる。
【００２１】
図３は集中制御におけるハード構成の一例を示す図である。ＣＰＵボード２０２２は、ホスト用Ｈ−ＣＰＵ３０１を中心に、ソフトを格納しておくＲＯＭ１  ３０２，主記憶ＭＥＭ１  ３０３，およびバスコントローラＢＵＳ  ＣＮＴ３０４から構成される。さらに、ＭＤボード２０２１と共通にアクセスする共有メモリとしてＣＭＥＭ３０７も搭載する。なお、記憶部を構成するＲＯＭ１  ３０２と主記憶ＭＥＭ１  ３０３を総称して、第１のメモリと呼ぶことがある。
【００２２】
ＭＤボード２０２１は、モータドライブ部品ＭＤｒｉｖｅ３０５、ドライブ部品の電気特性を制御するＤｒｉｖｅ  ＣＮＴ３０６，およびＢＵＳ  ＣＮＴ３０８から構成する。集中制御にあっては、プロセッサは必要ないので図示を省略してある。なお、ここでバスはマルチマスターを取れる仕様とし、ホスト側ＣＰＵボード２０２２もクライアント側ＭＤボード２０２１も、バスマスタにもスレーブにもなりえ、したがってＢＵＳ  ＣＮＴ３０４、３０８はマスタ側制御もスレーブ側制御も含む構成をとっている。
【００２３】
図４は分散制御でのハード構成の一例を示す図である。ＣＰＵボード２０２２の構成は図３と同一である。ＭＤボード２０２１は、ＭＤｒｉｖｅ３０５、Ｄｒｉｖｅ  ＣＮＴ３０６、およびＢＵＳ  ＣＮＴ３０８は同一であるが、制御ソフトの一部をＣＰＵボード２０２２から移すため、クライアント用Ｃ−ＣＰＵ４０１を中心に、ソフトを格納するＲＯＭ２  ４０２と主記憶ＭＥＭ２  ４０３が加わった構成となる。さらに、他システムからの割込みを受け付けるために、割込みコントローラＩＮＴＣ４０４が追加された構成となっている。なお、記憶部を構成するＲＯＭ２  ４０２と主記憶ＭＥＭ２  ４０３を総称して、第２のメモリと呼ぶことがある。
【００２４】
３．制御系のソフト構成
次に本実施例の集中制御と分散制御の各々のソフト構成の一例を、図５と図６に従い述べる。なおこのソフト構成は、上述したＣＰＵ上で動作する各種のプログラムで実現されることは言うまでもない。これらのプログラムはサーバ、クライアントの各メモリであるＲＯＭに記憶される。
【００２５】
図５は集中制御でのソフト構成の一例を模式的に示す図である。図５に示すハード構成部分は、先に説明した図３のハード構成から集中制御ソフトの実行に関連する部分だけを抜き出している。
【００２６】
本実施例におけるアプリケーションソフトは、スケジュールタスクＡ  ５０１と複数の機械制御タスク群５０２からなる。機械制御タスクＢ  ５０３は機械制御タスク群５０２の中の一つを代表している。スケジューラタスクＡ  ５０１は、図２のサンプル分注機構２０１２から測光機構２０１５の機械をどのタイミングで動作させるか、即ち複数のＭＤをどのタイミングで起動するかをスケジューリングする。ここではマクロなタイミングを決める。機械制御タスク群５０２は、スケジューラタスクＡ  ５０１が決めるマクロなタイミングを受けて、複数のＭＤをどのミクロタイミングで実行するかを決める。なお、機械制御タスク群５０２の一つの機械制御タスクがＭＤボード２０２１の一つの制御を担当する。
【００２７】
オペレーティングシステムＯＳ  ５０４は、そのタスク管理ルーチンを用いて、マルチタスクからなる制御アプリケーションの実行制御をする。
【００２８】
仮想リソースアクセス管理５０５は、ＯＳ  ５０４のタスク管理ルーチンを起動することにより、仮想リソースに対するアクセスを管理する。ここで、仮想リソースとは、タスクやイベントやメッセージなど、ＯＳ５０４のサービスコールがアクションを行う対象となる要素である。ＯＳ  ５０４から仮想リソースに対するアクションの指示を受けて、物理的なリソースに対してアクセスしたり、ＯＳ５０４内のタスク管理機構であるタスク管理ルーチンを用いて、仮想リソースに対してアクションを行う。
【００２９】
図６は分散制御でのソフト構成の一例を模式的に示す図である。図６のハード構成部分は、図３の構成から分散制御ソフトの実行に関連する部分だけを抜き出している。
【００３０】
アプリケーションソフトのうち、Ｈ−ＣＰＵ３０１で動作するソフトはスケジュールタスクＡ  ５０１のみで、スケジュールタスクＡ  ５０１以外の機械制御タスク群  ５０２は，クライアント側のＭＤボード２０２１上のＣ−ＣＰＵ４０１で動作する。図６では機械制御タスクＢ  ５０３を代表して示している。
【００３１】
Ｃ−ＣＰＵ４０１上のソフト構成は、Ｈ−ＣＰＵ３０１上と同様で、機械制御タスクＢ  ５０３はＯＳ  ６０１上で動作し、仮想リソースアクセス管理６０２は、ＯＳ  ６０１とＣ−ＣＰＵ４０１上の間で仮想リソースのアクセスを管理する。
【００３２】
図６の分散制御ソフトで用いるデータの格納領域について述べる。ＯＳ５０４上のタスクしかアクセスしないデータはＭＥＭ１  ３０３に格納し、ＯＳ６０１上のタスクしかアクセスしないデータはＭＥＭ２  ４０３に格納する。双方のタスクからアクセスするデータは共有メモリＣＭＥＭ３０７に格納する。
【００３３】
４．分散制御でのタスクＡからタスクＢの起動の動作
続いて、上述した仮想リソースアクセス管理を用いて、集中制御と同じサービスコールで、分散制御でもタスクＡからタスクＢを起動する仕組みを説明する。本実施例においては、サーバのタスクＡからクライアントのタスクＢを起動するとき、サーバのＯＳ５０４からタスクＢの起動要求を仮想リソースアクセス管理５０５に転送し、仮想リソースアクセス管理５０５はタスクＢの所在を探索し、該当するＣ−ＣＰＵ４０１へアクセス要求を行う。仮想リソースアクセス管理５０５は、仮想リソースアクセス用データをクライアントに転送すると共に、割り込みルーチンを起動する。仮想リソースアクセス管理６０２の割り込みルーチンは仮想リソースアクセス用データをデコードしてタスクＢのＩＤを取得し、ＯＳ６０１内のタスク管理経由で、タスクレディキューにタスクＢのＩＤを登録後、ディスパッチャを起動することによりタスクＢを実行する。
【００３４】
まず、図１に従い、全体の動作概要を述べる。次に、タスクＡとタスクＢの関係を図７に従い述べ、続いて、図８と図９に従い、図１で用いるインタフェースの構造を述べる。最後に、図１０〜図１３に従い、タスクＡからタスクＢを起動する手順を詳細に述べる。
【００３５】
＜全体の動作概観＞
図１は、ハード構成とソフト構成を一体化して、各種の信号の流れを模式的に示した図である。ホストであるＣＰＵボード２０２２と、クライアントとなるＭＤボード２０２１のハード構成、仮想リソースアクセス管理５０５、６０２より上位のソフト構成は、図４、図６に示した構成と同一である。なお、図示の都合上、ＭＤボード２０２１中の、ＲＯＭ３０２、４０２、ＭＤｒｉｖｅ３０５、Ｄｒｉｖｅ  ＣＮＴ３０６は省略してある。仮想リソースアクセス管理５０５は、ロケーションテーブルＶＲ＿ＬＯＣ＿ＴＡＢＬ  １０１と仮想リソースアクセス１０２とから構成され、仮想リソースアクセス管理６０２は、割り込みルーチンＩｔａｓｋ＿Ｍａｎ１０６で構成される。
【００３６】
図１において、スケジューラタスクＡ  ５０１は、サービスコールによりクライアント上の機械制御タスクＢ５０３に起動をかける。タスクＢへ起動をかけるというアクションを示す情報は、ＯＳ  ５０４により仮想リソースアクセス用データＶＲＡ＿Ｄａｔ１１０として、仮想リソースアクセス管理５０５に送信する。
【００３７】
これを受けて、仮想リソースアクセス管理５０５では、ＭＥＭ１  ３０３上の仮想リソースのロケーションテーブルＶＲ＿ＬＯＣ＿ＴＡＢＬ  １０１を参照して、タスクＢ５０３が別システム、即ちクライアントのＣ−ＣＰＵ４０１上のＯＳ  ６０１上に搭載されていることを認識して、バス２０２３とＢＵＳ＿ＣＮＴ３０４、３０８を介して、アクセス情報ＶＲＡ＿Ｄａｔ１１０を実線矢印１０３で転送し、割込み制御を点線矢印１０５で実施する。
【００３８】
ＶＲＡ＿Ｄａｔ１１０はＢＵＳ＿ＣＮＴ３０８内のＦＩＦＯ１０４を介して主記憶ＭＥＭ２  ４０３に転送される。割込み制御信号１０５は割込みコントローラＩＮＴＣ  ４０４に転送され、コントローラＩＮＴＣ  ４０４はＣ−ＣＰＵ４０１に対して、仮想リソースアクセス管理６０２の割込みルーチンＩｔａｓｋ＿Ｍａｎ１０６の起動を要求する。
【００３９】
Ｉｔａｓｋ＿Ｍａｎ１０６は、ＭＥＭ２  ４０３に格納されたアクセス用データＶＲＡ＿ＤＡＴ１１０をデコードし（１０６１）、タスク管理起動１０６２でＯＳ６０１内のタスク管理ルーチン６０１１を起動（１０６２）することにより、タスクＡが発行したサービスコールに応じた処理を実施する。
【００４０】
本実施例では、スケジューラタスクＡ  ５０１が機械制御タスクＢ  ５０３に起動をかけるため、割込みルーチンＩｔａｓｋ＿Ｍａｎ１０６が、ＯＳ６０１の中のタスクＢのＩＤをタスクレディキュー１０７に登録し、その後ディスパッチャ１０８を起動する。これにより、タスクＢ  ５０３はその時点のシステム状態によっては起動がかかる。図１の場合は、全てのタスクが休止状態１０９であるため、タスクＢ  ５０３が起動されることとなる。
【００４１】
＜タスクＡとタスクＢの関係＞
ホスト側のタスクＡとクライアント側のタスクＢの関係を、図７に従い述べる。
【００４２】
本実施例では、タスクＡが act_tsk を用いてタスクＢを起動する。その後タスクＢは ext_tsk でタスクを終了する。なお、図７の例はμITRON(Micro Industrial TRON)の文法に従っているが、基本的な機能なので、他のＲＴＯＳ（Real-time operating system）でも同様な機能はある。
【００４３】
＜インタフェースの構造＞  
ここでは、本実施例のシステムで用いるインタフェースの構造の一例を、図８と図９に従い説明する。その後、本実施例のタスクＡからタスクＢを起動する場合のデータ表現について述べる。まず、図８に従い、仮想リソースアクセス用データＶＲＡ＿ＤＡＴ  １１０の一例について述べる。
【００４４】
ＶＲＡ＿ＤＡＴ  １１０はホストのＯＳ  ５０４のサービスコールを表現する。仮想リソースとしては、上述したようにタスクとメッセージなどのデータを想定している。ＳｏｒｃｅＴｓｋ８０１はサービスコールを発行したタスクのＩＤを格納する。ＤｅｓｔＫ８０２はアクセス対象の仮想リソースの種類を示す。タスクとデータのリソースがある。データにはメッセージやミューテックスなど種々の種類があり、この種別もここで表現する。ＤｅｓｔＩＤ８０３は仮想リソースのＩＤを示す。タスクのＩＤ、メッセージのＩＤなどである。
【００４５】
ＡｃｔＫ８０４はアクセスする仮想リソースに対するアクションの種類をあらわす。タスク管理かデータ通信かを示す。ＡｃｔＳＣ８０５はアクションをあらわすサービスコールのＩＤを示す。
【００４６】
ＡｔｒＩＤ８０６はサービスコールにＤｅｓｔＩＤ８０３以外の引数があるときに、その引数のデータタイプを示す。ＡｔｒＰｏｉｎｔｅｒ８０７は、サービスコールにＤｅｓｔＩＤ８０３以外の引数のアドレスを格納する。その引数がホストとクライアント間で共通のデータ領域であるときには、ＣＭＥＭ３０７に格納しておく。引数は本実施例では一個としているが、ＡｔｒＩＤ８０６とＡｔｒＰｏｉｎｔｅｒ８０７を複数持つことにより複数個の引数への拡張は容易である。
【００４７】
次に、図９に従い、仮想リソースのロケーションテーブルＶＲ＿ＬＯＣ＿ＴＡＢＬ  １０１の構造の一例を述べる。
【００４８】
ＶＲ＿ＬＯＣ＿ＴＡＢＬ  １０１はタスクかデータがどのシステム上にあるかを示す。Ｈ＿ＣＰＵ３０１上のＯＳ５０４上か、クライアントのＣ＿ＣＰＵ３０１のＯＳ６０１上か、ＣＭＥＭ３０７上かを示す。また、クライアントは複数あるため、どのクライアントのＣ＿ＣＰＵ上にあるかも示す。
【００４９】
タスクとデータは複数あるため、タスクの数をＴＳＫ＿ＮＵＭ９０１で表し、データの数をＤａｔａ＿ＮＵＭ９０２で表す。
【００５０】
タスクのセット９０６は、仮想リソースの種類、即ちタスクかデータかを表現するＶＲ＿Ｋ９０３，仮想リソースのＩＤを示すＶＲ＿ＩＤ９０４、および仮想リソースのシステムロケーションを示すＶＲ＿ＬＯＣ９０５の３個のデータをセットとして、そのロケーションを表現する。９０６はこのセットがタスクの数ＴＳＫ＿ＮＵＭ９０１だけ、設定されている。
【００５１】
データのセット９０８もタスクのセット９０６と同様であるが、ロケーションは、ホスト上のメモリＭＥＭ１  ３０３，クライアント上のＭＥＭ２  ４０３、および共有メモリＣＭＥＭ３０７の３箇所となる。さらに、メモリのアドレス領域をＶＲＰｏｉｎｔｅｒ９０７が加わる。９０８はこのセットがデータの数Ｄａｔａ＿ＮＵＭ９０２だけ、設定されている。
【００５２】
続いて、本実施例で、タスクＡ  ５０１から、クライアントＣ−ＣＰＵ４０１上のタスクＢ  ５０３を起動する場合のデータの具体的内容を述べる。
【００５３】
まず、図８のＶＲＡ＿ＤＡＴ  １１０の具体例を示す。ＳｏｒｃｅＴｓｋ８０１は、タスクＡ  ５０１のタスクＩＤとなる。ＤｅｓｔＫ８０２はタスクを表す仮想リソースのＩＤとなる。ＤｅｓｔＩＤ８０３はタスクＢ  ５０３のタスクＩＤとなる。ＡｃｔＫ８０４は、タスク管理のアクションを示すＩＤとなる。ＡｃｔＳＣ８０５は、タスク起動のサービスコールact_tsｋを示すＩＤとなる。このサービスコールには、ＤｅｓｔＩＤ８０３以外に引数がないため、ＡｔｒＩＤ８０６とＡｔｒＰｏｉｎｔｅｒ８０７は不要となり、０とＮＵＬＬを格納する。
【００５４】
次に、図９のＶＲ＿ＬＯＣ＿ＴＡＢＬ  １０１の具体例を示す。本実施例のシステムに出現する仮想リソースは、タスクＡ  ５０１とタスクＢ  ５０３であるため、この二つについて示す。ＴＳＫ＿ＮＵＭ９０１はこの二つしかタスクがないとすると２となる。
【００５５】
タスクＡ  ５０１のデータを述べる。ＶＲ＿Ｋ９０３はタスクを表す仮想リソースのＩＤとなる。ＶＲ＿ＩＤ９０４はタスクＡ  ５０１のタスクＩＤとなる。ＶＲ＿ＬＯＣ  ９０５はＨ＿ＣＰＵ３０１上のＯＳ５０４のシステムを示すＩＤとなる。
【００５６】
タスクＢ  ５０３のデータを述べる。ＶＲ＿Ｋ９０３はタスクを表す仮想リソースのＩＤとなる。ＶＲ＿ＩＤ９０４はタスクＢ  ５０３のタスクＩＤとなる。ＶＲ＿ＬＯＣ  ９０５はＣ＿ＣＰＵ４０１上のＯＳ６０１のシステムを示すＩＤとなる。
【００５７】
＜動作の詳細手順＞
続いて、図１０から図１３に従い、本実施例の分散制御における、タスクＡからタスクＢを起動する手順を詳細に述べる。
【００５８】
まず、図１０に従い、図１の仮想リソースアクセス１０２の処理手順を述べる。
【００５９】
ステップ１００１：ＶＲ＿ＬＯＣ＿ＴＡＢＬ  １０１からＶＲＡ＿ＤＡＴ  １１０のアクセス先と同じ仮想リソースを探す。即ち(VRA_DatのDestK==  VR_K)、かつ (VRA_DatのDestID == VR_ID)の 要素を取り出す。
【００６０】
ステップ１００２：仮想リソースの種類がタスクかデータかを判定。即ちVRA_Datの DestK  ==  TSKか否かを判定する。
【００６１】
ステップ１００３：仮想リソースの種類が、タスクの場合には、ＶＲＡ＿ＤＡＴ  １１０とＶＲ＿ＬＯＣ  ９０５を引数としてタスクアクセス関数TSK_Accessを呼び出す。ロケーションが自分のシステムの場合には、通常のＯＳの動作に従いタスク管理を実施する。詳細は一般のＯＳの書籍に記載がある。例えば、鹿取祐二著、「SuperHで学ぶμITRON仕様OS」、電波新聞社（２００６年１月発行）、などである。なお、ロケーションが別システムの場合の本関数以降の動作手順は、図１１から図１３に従い、後ほど詳細に述べる。
【００６２】
ステップ１００４：仮想リソースの種類が、データの場合には、ＶＲＡ＿ＤＡＴ  １１０と      ＶＲＰｏｉｎｔｅｒ９０７を引数としてデータアクセス関数Data_Accessを呼び出す。データは自システムしかアクセスしない場合には、自システムのメモリＭＥＭ１  ３０３に事前に登録し、別システムもアクセスする場合には共有メモリＣＭＥＭ３０７に事前に登録しておく。いずれにしろ、自システムのアドレスを用いたメモリアクセスであり、通常のＯＳの動作に従う。詳細は一般のＯＳの書籍に記載がある。例えば、ステップ１００３で述べた書籍である。
【００６３】
次に、図１０のステップ１００３において、アクセス対象のタスクＢが別システムの場合の動作手順を述べる。即ち、図１に示すように、タスクＢ  ５０３がＣ＿ＣＰＵ４０１上のＯＳ６０１に搭載されているときの手順である。
【００６４】
図１１は、割込みルーチンＩＴＳＫ＿Ｍａｎ１０６を起動するまでの手順を示すガントチャートの一例である。ガントチャートの時間の前半は、ＶＲＡ＿Ｄａｔ１１０を転送する図１の実線矢印１０３の動作である。
【００６５】
ＴＳＫ＿Ａｃｃｅｓｓ  １００３が、ＶＲＡ＿Ｄａｔ１１０をＢＵＳ２００３のデータラインＤ＿Ｌｉｎｅ（ＢＵＳ２０２３の一部）にバスプロトコルに従って転送する（図１１の１１０１）。Ｄ＿Ｌｉｎｅに転送されたＶＲＡ＿Ｄａｔ１１０は、ＢＵＳ＿ＣＮＴ３０８内のＦＩＦＯ(ＦｉｒｓｔＩＮ  ＦｉｒｓｔＯｕｔ)レジスタ１０４に転送する（１１０２）。Ｃ−ＣＰＵ４０１がＦＩＦＯ１０４上のデータを、メモリＭＥＭ２  ４０３に格納する（１１０３）。
【００６６】
ガントチャートの時間の後半は、タスクＢ  ５０３を起動するための割込みルーチンＩＴＳＫ＿Ｍａｎ１０６の起動までの、図１の点線矢印１０５の動作である。
【００６７】
割込み信号Ｉｎｔ＿Ｓｉｇ  １１０４を割込みラインＩｎｔ＿Ｌｉｎｅ（ＢＵＳ２０２３の一部）に転送する（図１１の１１０５）。Ｉｎｔ＿Ｌｉｎｅに転送された割込み信号Ｉｎｔ＿Ｓｉｇ  １１０４で、割込みコントローラＩｎｔＣ４０４を制御し（１１０６）、ＩｎｔＣ４０４がＣ＿ＣＰＵ４０１経由でＩＴＳＫ＿Ｍａｎ１０６を起動する。このとき、ＩＴＳＫ＿Ｍａｎ１０６はＯＳ６０１が管理する割込みハンドラよりも優先順位が高く起動され、即座に実行される。
【００６８】
図１２は、割込みルーチンＩＴＳＫ＿Ｍａｎ１０６の処理フローの一例である。
【００６９】
ステップ１０６１：図１１でＭＥＭ２  ４０３に格納されたＶＲＡ＿Ｄａｔ  １１０を読み出し、デコードする。これにより、どのタスクに対して、どういう管理をするかを認識できる。
【００７０】
ステップ１０６２：ステップ１０６１に従い、ＶＲＡ＿Ｄａｔ  １１０により指定されたタスクに対して、指定された管理を行うため、これらの情報を引数として、ＯＳ６０１内のタスク管理６０１１のサービスルーチンを起動する。
【００７１】
図１３は、タスク管理６０１１の処理フローの一例を示す。
【００７２】
ステップ１３０１：タスク管理のユーティリティである、タスクやシステム全体の状態、レディキューなどを変更する。
【００７３】
本実施例では、タスク起動のタスク管理を実施するため、ステップ１３０１１において、タスクレディキュー１０７にＤｅｓｔＩＤ８０３，即ちタスクＢ  ５０３のＩＤを登録し、タスクＢを実行可能状態に移す。
【００７４】
タスクの実行状態が関連する他の例としては、タスクを停止するケースが考えうる。このときにはレディキューの変更はなく、ステップ１３０３で停止対象のタスクを引数としてディスパッチャ１０８を起動することになる。
【００７５】
ステップ１３０２：ディスパッチャ１０８の起動が必要かどうかを判断する。
【００７６】
ステップ１３０３：ディスパッチャ１０８を起動する。ディスパッチャの詳細は、一般のＯＳの書籍に記載がある。例えば、鹿取祐二著、「SuperHで学ぶμITRON仕様OS」、電波新聞社（２００６年１月発行）などに詳述されている。
【００７７】
ディスパッチャ１０８は実行状態のタスクを切り替える処理を行う。具体的には、これまで実行状態にあったコンテクストを保存したり、次に実行すべきタスクのコンテクストを復帰する。本実施例では、現在は全てのタスクが休止状態にある（図１の１０９）。タスクＢ  ５０３がステップ１３０１でレディキューに登録されたため、次に実行すべきタスクはタスクＢとなり、コンテクストを復帰する。このコンテクスト復帰の直前に、システム状態の変更も行う。タスクＢが実行状態にあることを示すように変更する。
【産業上の利用可能性】
【００７８】
本発明は、サーバクライアント連携システム、特に分散管理と集中管理のシステム構成の切り替え時に、タスク管理やタスク間の通信を不変化するタスク制御技術として有用である。
【符号の説明】
【００７９】
２０１…血液を自動分析する装置の機械系部分
２０２…制御系部分
２０１１…ディスク上の血液サンプルを運搬するセル群
２０１２…サンプル分注機構
２０１３…薬分注機構
２０１４…攪拌機構
２０１５…測光機構
２０２１…複数のＭＤ（Ｍｏｔｏｒ  Ｄｒｉｖｅ）ボード
２０２２…ＣＰＵボード
バス…２０２３
３０１…ホスト用Ｈ−ＣＰＵ
３０２…ＲＯＭ１、
３０３…主記憶ＭＥＭ１
３０４…バスコントローラＢＵＳ  ＣＮＴ
３０５…モータドライブ部品ＭＤｒｉｖｅ
３０６…Ｄｒｉｖｅ  ＣＮＴ
４０１…クライアント用Ｃ−ＣＰＵ
４０２…ＲＯＭ２
４０３…主記憶ＭＥＭ２
５０１…スケジュールタスクＡ
５０２…複数の機械制御タスク群
５０３…機械制御タスクＢ
５０４…オペレーティングシステムＯＳ
５０５、６０２…仮想リソースアクセス管理
６０１…ＯＳ
１０１…ＶＲ＿ＬＯＣ＿ＴＡＢＬ：仮想リソースのロケーションテーブル
１０４…ＦＩＦＯ（ＦｉｒｓｔＩｎ  ＦｉｒｓｔＯｕｔ）レジスタ
１０６…Ｉｔａｓｋ＿Ｍａｎ：タスク管理割込みルーチン
１０７…タスクレディキュー
１０８…ディスパッチャ
８０１…ＳｏｒｃｅＴｓｋ：サービスコールを発行したタスクのＩＤ
８０２…ＤｅｓｔＫ：アクセス対象の仮想リソースの種類
８０３…ＤｅｓｔＩＤ：仮想リソースのＩＤ
８０４…ＡｃｔＫ：仮想リソースに対するアクションの種類
８０５…ＡｃｔＳＣ：サービスコールのＩＤ
８０６…ＡｔｒＩＤ：サービスコールのＤｅｓｔＩＤ８０３以外の引数のデータタイプ
８０７…ＡｔｒＰｏｉｎｔｅｒ：８０６で示す引数のアドレス
９０１…ＴＳＫ＿ＮＵＭ：ＶＲ＿ＬＯＣ＿ＴＡＢＬ１０１内のタスクの数
９０２…Ｄａｔａ＿ＮＵＭ：ＶＲ＿ＬＯＣ＿ＴＡＢＬ１０１内のデータの数
９０３…ＶＲ＿Ｋ：ＶＲ＿ＬＯＣ＿ＴＡＢＬ１０１内の仮想リソースの種類
９０４…ＶＲ＿ＩＤ：９０３の仮想リソースのＩＤ
９０５…ＶＲ＿ＬＯＣ：９０３の仮想リソースのシステムロケーション
９０７…ＶＲＰｏｉｎｔｅｒ：ＶＲ＿ＬＯＣ＿ＴＡＢＬ１０１内のデータタイプの仮想リソースに対するメモリのアドレス。
【図１】
2011238168.tif 000003
【図２】
2011238168.tif 000004
【図３】
2011238168.tif 000005
【図４】
2011238168.tif 000006
【図５】
2011238168.tif 000007
【図６】
2011238168.tif 000008
【図７】
2011238168.tif 000009
【図８】
2011238168.tif 000010
【図９】
2011238168.tif 000011
【図１０】
2011238168.tif 000012
【図１１】
2011238168.tif 000013
【図１２】
2011238168.tif 000014
【図１３】
2011238168.tif 000015