JP2004526476A - 陽子線治療制御システム - Google Patents

Abstract

分散システム内のネットワークトラフィックを管理するための階層型通信アーキテクチャ。クライアントまたは制御コンピュータと複数のハードウェアデバイスとの間の通信は、エージェントおよびモニタデバイスによって指揮され、それらの活動は、開かれたチャネルまたはソケットの数を削減するように調整される。また、通信アーキテクチャは、ネットワークマッピング依存性を低減させることによって、分散システムの透過性およびスケーラビリティを改善する。アーキテクチャが陽子線治療システム内で実施されると、望ましいことに、患者の安全性を向上させてシステムの保守および開発を容易にする、フレキシブルなセキュリティポリシーが提供される。

Description

【技術分野】
【０００１】
（発明の背景）
（発明の分野）
本発明は、分散制御システムに関し、特に、陽子線治療デバイスのための分散環境でデータ通信を管理するための制御システムに関する。
【背景技術】
【０００２】
（関連技術の説明）
放射線粒子治療デバイスは、一般に、局所型の癌ならびに他の病気の処置に使用されている。これらのデバイスは、患者の特定の領域、例えば腫瘍を目標として設定し、精密に位置合わせされた原子の粒子流または電磁放射線を目標領域に誘導するために使用される。粒子流からのエネルギーが、局所的な細胞の損傷を引き起こし、腫瘍の成長および進行を効果的に途絶させる。
【０００３】
放射線治療法の特に有用な一形態は陽子線治療法であり、患者の目標領域に照射するのに、陽子が形成するエネルギー流が使用される。方向性を持ったビームによる他のタイプの放射線治療法と同様に、陽子線治療法では、陽子流が所望の目標領域だけに照射されるように、患者をビーム源に対して正確に位置決めする必要がある。そうしなければ、患者の身体内部の他の健康な細胞が陽子流によって損傷される可能性がある。
【０００４】
米国特許第４，９０５，２６７号に詳細に記載されているように、患者を特定の向きで位置決めするために支持装置が使用され、支持装置がさらに陽子処置設備のガントリ構造内の処置プラットフォーム上に位置決めされる。陽子治療設備は、多数の患者に対処する目的で、そのような処置装置を２つ以上さらに備えていることがある。処置設備の装置および構成要素の制御および監視は、各処置ステーションの活動を調整するコンピュータおよびハードウェアサブシステムによって指揮される。陽子線治療には、患者の位置決めに使用される機械式の装置に加えて、ビーム強度の制御、ビーム位置の修正、デジタル画像処理の実施、安全状態の監視、および他の機能に使用される他の多数のシステムおよびソフトウェア構成要素が必要である。これらのシステムが一体となって、ハードウェアおよびソフトウェア構成要素の複雑な分散型の集合体を形成する。さらに、２つ以上の処置装置を備える陽子処置設備では、システムの冗長性および各処置装置の選択的制御に関する追加的要求によって、システムの複雑さがさらに増大する。
【０００５】
放射線治療デバイスなどの分散システムの複雑なアーキテクチャは、単一アプリケーションによる整合制御に多数の障害をもたらし、さらにシステムの構成要素間のネットワーク化を困難にする。従来の分散システムの一つの特有の制限事項は、分散システムの様々な構成要素間のデータ通信の管理に関するものであり、これは、分散システムのサイズが増大するほどより困難になる。この問題は、特に放射線治療デバイスが２つ以上の処置装置を備えるように設計されているときに明らかである。その結果、１つには、維持しなければならない通信チャネルの数のために、集中制御および監視の解決策を提供することは厄介なタスクとなる。さらに、複雑な通信マッピングスキーマによって、すべてのデバイスが相互に通信できることを保証するのが困難になる。分散システムの一つの構成要素を修正またはアップグレードすると、必然的に、その修正された構成要素が接続されている他の多数の構成要素の構成を修正する必要が生じることが多い。これらの構成要素の構成の修正が適切でないと、システムが制御不能になる、システムの監視が不正確になる、デバイスが故障するなど、多数の問題を引き起こす可能性がある。
【０００６】
放射線治療デバイスでは、既存のマッピングスキーマを前述のように大幅に再構成することは、患者の安全性を保証するために解決しなければならない潜在的な制御の問題が生じるので、望ましくない。これらの問題が適切に解決されなければ、あるいは放射線治療デバイスの稼働時に１つまたは複数の構成要素が予期せず制御不能になれば、患者が負傷する可能性がある。したがって、修正および構成要素のアップグレードに対するシステムの許容度を高めるために、放射線治療デバイス内の構成要素間の透過性（transparency）のレベルを高めることが望ましい。
【０００７】
図１は、それぞれが選択された動作およびタスクを実行する複数のハードウェアデバイス５０を備える、従来の分散システム４０を示す。ハードウェアデバイス５０の制御および保守は、複数の通信チャネルまたはデータパス７０を介してハードウェアデバイス５０と通信する、１つまたは複数のホストアプリケーションまたはプロセス６０を用いて調整される。ホストアプリケーションまたはプロセス６０が通信するハードウェアデバイス５０のそれぞれに、通常、別個の通信チャネル７０が確立される。
【０００８】
放射線治療デバイスなどの複雑な分散システムの調整および管理機能が制限されるこの手法を用いると、いくつかの問題が生じる。特に、ホストアプリケーションまたはプロセス６０によって多数のハードウェアデバイス５０を管理または監視するときには、確立および維持しなければならない通信チャネル７０の必要数がさらに大きくなる。多くの場合、このことが、オペレーティングシステムまたはハードウェア構成要素によってサポートされる最大数を超えて増加する場合がある通信チャネル７０を、管理するのに必要なシステムオーバーヘッドを増加させることになる。したがって、対応できる通信チャネル７０の数に制約があるので、従来の分散システム４０のスケーラビリティが制限される。さらに、分散システム４０の複雑さが増大すると、有効なネットワーク監視および認証を実行し、安全なファイアウォールポリシーを維持して十分なシステムセキュリティを保証することがさらに困難になる。
【０００９】
複雑な分散システム４０では、既存のシステム４０のアーキテクチャで作業する個々人がチャネル７０の通信マッピングおよびシステム４０内のサービスを理解することを保証するのに、さらなる問題が生じる。このことは、新しいハードウェア構成要素または機能を追加するために、ハードウェアデバイス５０がどのように相互接続しているかを明確に知っていなければならない開発者には、特に重要である。従来の手法は、この問題に十分に対処しておらず、理解して発展させるのが困難な場合がある、難解なマッピングスキームに頼っている。
【００１０】
従来の分散環境は、通常、クライアント／サーバパラダイムに基づいている。クライアント／サーバ方式は、１つまたは複数のモノリシックホストアプリケーションを使用して、分散環境の個々のシステムをポーリングし、必要に応じて情報を１つにつなぎ合わせる。この情報の分配および調整方法は、前述した保守の難しさ、スケーラビリティの不足、データ検証および妥当性検査が複雑なことを含めて、多くの理由から、望ましくない。
【００１１】
さらに、陽子線治療システムでは、通常、動作すべき基盤ハードウェアデバイスおよびサブシステムの常時監視を必要とする、多数の安全機能が存在する。この監視要求に対する従来の手法は、制御プログラムまたはアプリケーションによって、ホストアプリケーションのレベルでハードウェアの監視を単独に実行することである。この手法を使用する潜在的な欠点の１つは、ホストアプリケーションまたは制御プログラムの故障が、潜在的に危険な状態またはハードウェアの破損状態をまねき得ることである。場合によっては、ホストアプリケーションと、監視されるハードウェアとの間の通信の消失を検出するために、「ウォッチドッグ」プログラムを採用することもあるが、ウォッチドッグプログラムを使用すると、システムに望ましくない影響を及ぼすことがある。
【００１２】
電源の場合、ウォッチドッグプログラムが電源を自動的に遮断して、システムセーフを起動することがある。この結果、電源が冷却され、その後患者の処置を再開できるまでのウォーミングアップ期間が長時間にわたることがある。さらに、陽子線治療システムの故障が処置直前まで隠れていることがあり、それが処置を遅らせて、患者の不快感を高めることになることも考えられる。
【００１３】
したがって、陽子線治療デバイスで使用されるような、複雑な疎結合型分散環境内の通信を管理する、改良型システムおよび方法が必要とされている。このシステムアーキテクチャは、陽子線治療システムの複雑さおよび帯域幅要求に対応できる一方で、スケーリング、保守、および発展を容易にするように、許容可能なレベルの単純性を維持すべきである。さらに、システムは、オフラインまたは誤動作しているデバイスの監視に関連する潜在的な問題を解決する、改良されたシステム監視機能を提供すべきである。
【発明の開示】
【課題を解決するための手段】
【００１４】
（発明の概要）
本発明は、陽子線治療システムのコマンド、管理、および監視のための階層型通信システムを含む。一態様では、前記陽子線治療システムのアーキテクチャは、患者の処置で使用されるハードウェアおよび／またはリソースに、エージェントモジュールを介して通信する、１つまたは複数のホストアプリケーションまたはプログラムを含む。前記エージェントは、透過性をもって（transparently）、通信トラフィックを管理し、前記陽子線治療システムの構成要素間のデータの経路指定を含むいくつかの管理機能を実行する。前記通信システムは、前記陽子線治療システムに関連する様々なハードウェアデバイスおよびリソースに、下層レベル（low level）の通信制御およびコマンド変換を提供するモニタモジュールを含む。
【００１５】
前記階層型通信システムを使用すると、通信の調整および管理の複雑さが大幅に軽減される。一態様では、通信システムアーキテクチャが、前記エージェントの経路指定／多重化機能を用いるマルチプロセスによって、チャネルまたはソケット使用率を低減させて、前記ハードウェアデバイス間のデータ交換を調整する際に直面する潜在的ボトルネックを解消する。前記通信システムはさらに、プロクタ（proctor）モジュールを使用して、組込みシステムに常時監視機能を与える。
【００１６】
集中型接続アーキテクチャは、前記陽子線治療システムを用いて処置される患者の安全性の維持において重要である接続セキュリティを向上させるという、さらなる利益を提供する。前記通信システムアーキテクチャは、さらに、ユーザインターフェースを単純化し、アプリケーションの開発および配置の複雑さを軽減する。例えば、ホストアプリケーションは、各デバイスと通信するのに必要な機能の実施または定義について明確に知らずに、組込みハードウェアデバイスを管理、監視および制御するように構成され得る。さらに、前記ホストアプリケーションは、デバイスまたはその制御システムの物理的な場所を知らずに、前記組込みハードウェアデバイスと通信するように構成され得る。一態様では、この性質の論理マッピングによって、システム構成を大幅に修正せずに、システム内にデバイスを柔軟に設置できるようになる。
【００１７】
一態様では、本発明は、陽子線治療デバイス内の通信を管理するための通信システムを含んでおり、このシステムが、処置ステーションと、１つまたは複数のホストアプリケーションと、１つまたは複数の機能構成要素と、エージェントとを含んでいる。前記処置ステーションは、較正および位置合わせされたビームを患者の処置中心（isocenter）に向けて誘導するために使用され、前記１つまたは複数のホストアプリケーションは、前記処置ステーションの動作に関連するハードウェアサブシステムを含む機能構成要素を介して、前記処置ステーションの動作を監視および制御するために使用される。前記エージェントは、各ホストアプリケーションに接続されており、ホストアプリケーションごとに単一のクライアントデータチャネルを使用する。前記エージェントはさらに、監視データチャネルによって各機能構成要素に接続されており、各ホストアプリケーションが前記単一のクライアントデータチャネルを使用して各機能構成要素と通信できるように、前記エージェントが各ホストアプリケーションと前記機能構成要素との間の経路指定動作を実行する。
【００１８】
他の態様では、本発明は、分散ネットワークを含む陽子線治療デバイスのための階層型通信アーキテクチャを含み、前記分散ネットワークが、少数のチャネルセットを用いて動作して、患者の処置に使用される放射線ビームの発生および位置合わせに関連する、１つまたは複数のホストアプリケーションと複数のハードウェアデバイスとの間の十分に透過な通信を提供する。前記アーキテクチャはさらに、複数の別個のデータチャネルによって各アプリケーションと各ハードウェアデバイスとに接続されたエージェントデバイスを含んでおり、該エージェントは、前記別個のデータチャネルを介して、１つまたは複数のホストアプリケーションと複数のハードウェアデバイスとの間の通信を経路指定する。前記アーキテクチャはさらに、各ハードウェアデバイスに結合するモニタ構成要素を含んでおり、該モニタ構成要素は、前記エージェントを介して経路指定されたホストアプリケーションからの命令を受け取り、後に前記ハードウェアデバイスで実行されるハードウェアが認識する形式に該命令を変換し、さらに、前記ハードウェアデバイスから情報応答を受信して、前記エージェントを介して前記情報応答を前記ホストアプリケーションに転送するために使用される。また、前記アーキテクチャでは、前記モニタ構成要素内にプロクタ構成要素が組み込まれており、これが、前記ハードウェアデバイスから得た前記情報応答を評価し、異常な（anomalous）ハードウェア挙動を識別し、さらに、異常なハードウェア挙動が検出された場合に１つまたは複数の安全策を発行する。
【００１９】
他の態様では、本発明は、分散ネットワーク内の通信を管理する階層型通信システムを含む。該システムはさらに、前記分散ネットワークに接続され、単一チャネルを介して複数のハードウェアデバイスに命令を送信するように構成されたクライアントを含む。さらに前記システムは、分散ネットワークを介して前記クライアントに接続され、且つ、各ハードウェアデバイスが単一チャネルによってエージェントに接続されるようにさらに複数のハードウェアデバイスに接続されたエージェントを含んでおり、該エージェントは、前記クライアントによって送信された命令を受信して、前記命令が向けられている目標ハードウェアデバイスを識別し、適切なチャネルを介して前記命令を前記目標ハードウェアデバイスまで経路指定する。前記システムは、前記目標ハードウェアデバイスに結合され、前記分散ネットワークに接続されたモニタをさらに含んでおり、該モニタが、前記エージェントによって経路指定された前記命令を受信し、前記命令に関連するハードウェアで認識可能なコマンドを識別し、その後、前記ハードウェアで認識可能なコマンドを、後に実行させるために前記目標ハードウェアデバイスに発行する。
【００２０】
他の態様では、本発明は、クライアントと複数のハードウェアデバイスとの間で情報交換するための方法を含み、前記クライアントが、前記複数のハードウェアデバイスを制御および監視する命令を発行する。前記方法はさらに、（１）前記クライアントと、前記クライアントと通信してそこから送信された命令を受信するように構成されたエージェントとの間に、第１の通信チャネルを確立するステップと、（２）前記エージェントと各ハードウェアデバイスとの間に複数の第２の通信チャネルを確立するステップと、（３）前記クライアントによって発行された前記命令を、前記命令が十分に透過な方式で適切なハードウェアデバイスに送られるように、前記エージェントを用いて経路指定するステップと、（４）ハードウェアデバイス上にあり、前記命令を、後に前記ハードウェアデバイスによって実行されるハードウェアで認識されるフォーマットに変換するモニタモジュールを使用して、前記命令を受信するステップとを含む。
【００２１】
また、他の態様では、本発明は、陽子線治療システム内で情報交換するための方法を含んでおり、ここで、望ましくは、複数の命令の送信を介し、少なくとも１つのホストアプリケーションを使用して複数のハードウェアデバイスを制御および監視するように、前記少なくとも１つのホストアプリケーションと前記複数のハードウェアデバイスとが相互接続されている。この方法はさらに、（１）各ホストアプリケーションと、該ホストアプリケーションと通信してそこから送信された命令を受信するように構成されたエージェントデバイスとの間に、第１の通信チャネルを確立するステップと、（２）各ハードウェアデバイスが単一の通信チャネルによって前記エージェントに接続されるように、前記エージェントデバイスと各々の前記ハードウェアデバイスとの間に、複数の第２の通信チャネルを確立するステップと、（３）前記エージェントデバイスを用いて、前記ホストアプリケーションによって発行された前記命令を、前記命令が、十分に透過な方式で適切なハードウェアデバイスに転送されるように、経路指定するステップと、（４）各々のハードウェアデバイス上にあり、前記命令を、後に前記ハードウェアデバイスによって実行されるハードウェアで認識されるフォーマットに変換するモニタモジュールを使用して、受信するステップとを含む。
【００２２】
さらに他の態様では、本発明は、ネットワークリソースの分散システムの通信および制御のための方法を含んでおり、クライアントデバイスとエージェントデバイスとの間に第１の通信チャネルを確立し、前記エージェントデバイスと少なくとも１つのハードウェアデバイスとの間に第２の通信チャネルを確立し、前記クライアントデバイスと前記エージェントデバイスとの間、さらには、前記エージェントデバイスと監視デバイスとの間で転送されるデータが、ハードウェアリソースの分散システムへのアクセスを要求するクライアントプロセスと、通信チャネルを管理し、クライアント処理要求について経路指定するエージェントプロセスと、該エージェントプロセスからの要求を受け入れ、該要求を実行し、結果を前記クライアントプロセスに返すモニタプロセスとにしたがって、処理される。
【００２３】
本発明のこれらおよび他の態様、利点、ならびに新規な特徴は、以下の詳細な説明を読み、添付の図面を参照すれば、明らかになろう。図面では、同じ要素は、同じ参照番号が付されている。
【発明を実施するための最良の形態】
【００２４】
（好ましい実施の形態の詳細な説明）
図２は、１つまたは複数のホストアプリケーション１０５に結合された、患者を処置するための陽子線治療システム（ＰＢＴＳ：proton beam therapy system）１００の一実施の形態を示す。一態様では、ホストアプリケーション１０５は、処置ステーション１１５と併せて使用される複数の機能構成要素１１０と通信する。機能構成要素１１０は、処置ステーション１１５の活動を誘導するモニタおよび管理構成要素を含む。各機能構成要素１１０は、処置ステーション１１５内に存在する１つまたは複数のハードウェアデバイスをさらに含み、これらは、望ましくは陽子線治療システム１００内で結合されて集合的に管理される。
【００２５】
処置プロセスの間、これらのハードウェアデバイスの動作は、精密に較正および位置合わせされた陽子線１４７を、患者１２０の特定の目標領域または処置中心（isocenter）１４８に向けて誘導するように調整されるのが望ましい。一実施の形態では、処置ステーション１１５は、注入器１３５によって加速器１３０に接続された陽子源１２５を備えている。加速器１３０は、陽子を所望のエネルギーレベルまで加速させ、ビーム輸送装置１４０を介して、処置ステーション１１５の固定位置で支持された患者１２０に陽子線を到達させる。ビーム輸送装置１４０は、粒子流を患者１２０の身体内の特定の目標処置中心に向けて誘導するノズル１５０をさらに備えている。患者１２０は、ガントリ１４５で支持されており、ガントリ１４５は、回転軸周りに回転可能であり、陽子線を適切に位置合わせするために使用される。陽子線治療システム１００のさらなる詳細については、本発明の譲受人に譲渡された米国特許第５，８６６，９１２号および米国特許第４，８７０，２８７号に開示されており、これらを参照によりここに援用する。
【００２６】
一態様では、陽子線治療システム１００は、複数の処置ステーション１１５を備えている。各処置ステーション１１５は、前述の陽子源１２５、加速器１３０、注入器１３５など、同一構成要素のうちの少なくとも一部を共有するように構成され得る。一態様では、処置ステーション１１５間で共有される構成要素は、共通の制御インターフェースを介して監視および制御される。多数の処置ステーションが組み込まれた陽子線治療システムのさらなる詳細は、米国特許第５，５８５，６４２号および米国特許第４，８７０，２８７号に記載されており、これらを参照によりここに援用する。
【００２７】
放射線治療の技術分野で理解されているように、陽子線または放射線流を目標処置中心に正確に到達させることが重要である。さらに、様々な異なる角度からビームを到達させることができるときには、陽子線または放射線流治療を強力なものにすることができる。したがって、一般に、患者１２０をビーム輸送装置１４０のノズル１５０に対して相対的に固定位置に設置し、ビームが様々な異なる角度から到達するように、ビーム輸送装置１４０のノズル１５０を、可動式ガントリ１４５を介して様々な位置に移動させることが望ましい。米国特許第４，９０５，２６７号および米国特許第５，１１７，８２９号は、それぞれ放射線処置のために患者１２０を位置合わせするシステムを開示しており、これらの各特許を参照によりここに援用する。さらに、米国特許第４，９１７，３４４号および米国特許第５，０３９，０５７号は、それぞれ、様々な角度の連続的な範囲にわたってビームを到達させるガントリシステムを開示しており、これらの各特許も参照によりここに援用する。他の様々な患者の処置を選択する方法、患者への粒子線または放射線ビームの到達を向上させる装置などについては、米国特許第５，０１７，７８９号、５，２４０，２１８号、５，８２５，８４５号、４，９０５，２６７号、５，１１７，８２９号、および５，２６０，５８１号に開示されており、これらも参照によりここに援用する。
【００２８】
機能構成要素１１０は、患者の安全性を保証するため、及び陽子線を構成して誘導するために使用されるハードウェアサブシステムの活動を監視および調整する。患者の安全性は、放射線処置の主たる関心事であり、ビームが常に適切な強度またはエネルギーレベルで導かれていることを保証するために、陽子線治療システム全体にわたって常時厳重な制御を維持しなければならない。一実施の形態では、ビーム治療システムは、ハードウェアデバイスおよびサブシステムが作動可能状態にあって、適切に構成されていることを確認できない限り、ビームが患者に接触しないように構成される。作動可能状態とは、ハードウェアデバイスおよびサブシステムが、許容範囲内であり、かつ患者の処置に適切なように決定された特定の範囲で機能していることを表す。通常、陽子線は、すべてのサブシステムがこの作動可能状態にあることを確認されるまで無効化される。以下においてさらに詳細に説明するように、機能構成要素１１０および階層型通信システムの構成は、いつ患者を処置するのが適切であるかを決定するために、陽子線治療デバイスの準備状態を監視するのに必要な整合機能を提供する。
【００２９】
一態様では、ホストアプリケーション１０５は、機能構成要素１１０と情報を交換し、放射線治療システムに主要なコマンドおよび監視機能を提供する。ホストアプリケーション１０５と機能構成要素１１０との通信は、通常は従来のネットワークトポロジーを用いて形成される複数のデータチャネル１５５を介して進められる。ホストアプリケーション１０５と機能構成要素１１０とは、階層型通信ネットワークによって連結されており、この階層型通信ネットワークは、陽子線治療システム１００を動作させるのに必要なデータ通信を実行するのに、従来のシステムよりも少数のデータチャネル１５５を使用する。
【００３０】
ホストアプリケーションは、ローカルホストアプリケーション１６０とリモートホストアプリケーション１６５の両方を備えていてもよい。ローカルホストアプリケーション１６０は、陽子線治療システム１００に直接関連するコンピュータまたは構成要素の上で実行されるアプリケーションを含む。例えば、ローカルホストアプリケーション１６０を、陽子線治療システム１００の１つまたは複数のハードウェアデバイスに結合されたコンピュータから直接実行することができる。あるいは、ローカルホストアプリケーション１６０を、放射線治療システム１００のハードウェアデバイスまたはサブシステムにネットワーク接続を介して連結された、１つまたは複数のスタンドアロンコンピュータから実行することもできる。ローカルホストアプリケーション１６０と、情報を送受信する対象の１つまたは複数の機能構成要素１１０との間のデータ交換は、前述の階層型通信ネットワークを介して進められる。
【００３１】
リモートホストアプリケーション１６５は、陽子線治療システム１００の外部でかつ／または陽子線治療システム１００から独立して、実行されるアプリケーションを含む。一態様では、リモートホストアプリケーション１６５は、リモートネットワーキングプロトコルの使用を介して陽子線治療システム１００にインターフェース接続するように構成されており、必ずしも陽子線治療システム１００に直接結合されたコンピュータまたは構成要素からローカルに実行される必要はない。ローカルホストアプリケーション１６０と同様に、リモートホストアプリケーション１６５は、階層型通信ネットワークを利用して必要または所望に応じて機能構成要素１１０とデータおよび情報を交換する。
【００３２】
機能構成要素１１０は、陽子線治療システム１００の動作に関連した多数のサブシステムを備えている。一態様では、これらのサブシステムは、相互の間およびホストアプリケーション１０５との間でデータおよび情報を交換する、コンピュータおよびハードウェアデバイスの分散ネットワークを形成する。図２には、説明のために、例示的な機能構成要素１１０を示す。これらの機能構成要素には、ビーム輸送システム１７０、安全システム１７５、電源システム１８０、およびロギングシステム１８５が含まれる。
【００３３】
放射線治療システムが、相互接続されたデバイスおよび構成要素の複合した集合体であり、これには上記で例示した機能構成要素１１０、ならびに他の多数の構成要素、システム、およびプロセスを含めることができることが理解できるであろう。これらのデバイスおよびサブシステムを１つにまとめて分散環境が形成され、これに本発明の階層型通信システムを実装して、チャネルの複雑さを軽減し、患者の安全性を向上することができる。
【００３４】
一態様では、陽子線治療システム１００の分散環境には、一度に２人以上の患者に対応するのに有用な、複数の処置ステーション１１５と、関連するハードウェアおよびソフトウェア構成要素とが含まれる。本発明は、分散環境の複雑度が、単一ステーション処置設備の場合よりもかなり増大するマルチステーション処置設備内の通信管理に適合するのに、特に適している。
【００３５】
階層型通信システムを、陽子線治療システム１００のコマンド、制御、および監視に関して開示しているが、本発明を他のタイプの分散システムとの使用に適合させて、通信効率を向上させ、チャネル数を削減できることが理解できるであろう。したがって、これらの代替的な分散システムアーキテクチャは、本発明の他の実施形態を、ここに記載するシステムおよび方法との使用に適合させたものとして表しているに過ぎないことが理解できる。
【００３６】
図３は、前述の陽子線治療システム１００などの分散環境における情報交換を管理する階層型通信アーキテクチャ２００に関する最上位編成のブロック図を示す。上記したように、分散システムは、特殊なコントローラ、コンピュータ、および他の構成要素を含めた複数のハードウェアデバイス２１０の中のいずれをも備えることができ、これらは、様々なデバイス２１０間の通信およびデータ交換を可能にするために、ネットワーク接続によって相互接続されていることが望ましい。階層型通信アーキテクチャ２００は、調整されたハードウェアおよびソフトウェアベースの手法を用いて実装され、ハードウェアデバイス２１０は、少数組のデータチャネル１５５を介してホストアプリケーション１０５に接続される。各ホストアプリケーション１０５は、複数の第１のデータ接続またはデータチャネル２２０がホストアプリケーション１０５とエージェントデバイス２１５との間で維持されるように、エージェントデバイス２１５と相互接続している。エージェントデバイス２１５はさらに、複数の第２のデータ接続またはデータチャネル２２５によって、分散システム１００の各ハードウェアデバイス２１０と相互接続している。
【００３７】
ホストアプリケーション１０５とエージェントデバイス２１５との間、ならびにエージェントデバイス２１５とハードウェアデバイス２１０との間の接続は、バークレーソケットベースの伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ：Transmission Control Protocol/Internet Protocol）またはユーザデータグラムプロトコル／インターネットプロトコル（ＵＤＰ／ＩＰ：User Datagram Protocol/Internet Protocol）などの、適切なプロトコルを使用するネットワーク接続を含んでいる。ソケットベースのプロトコルの広範囲のインターオペラビリティを階層型通信システム内で有利に使用して、各ハードウェアデバイス２１０が情報の送受信に使用できる、一般に認識されている通信プロトコルを提供することができる。さらに、ソケットベースのプロトコルは、（１）開発者がハードウェアインターフェースの作成に使用できる一般に良く理解されている仕様、（２）高信頼性の送受信特性、（３）マルチスレッド互換性、（４）複数同時接続の支援、ならびに（５）ブロッキングおよび非ブロッキング構成の支援を含めて、多くの有利な特性を有している。以下でさらに詳細に説明するように、これらの特性は、階層型通信アーキテクチャ２００の開発に関連する作業を単純化するのに有用で、ほとんどのホストアプリケーション１０５およびハードウェアデバイス２１０と併せて使用するために構成され得る。
【００３８】
階層型通信アーキテクチャ２００が、必ずしも前述のソケットベースのプロトコルとの使用だけに限定される必要はなく、むしろ例えばリモートメッセージパッシングプロトコルを含めた他の多数の通信プロトコルとの使用に適合され得ることが、当業者には理解されるであろう。したがって、階層型通信アーキテクチャ２００で他のプロトコルを実施することは、本発明の他の実施の形態を表すものと理解される。
【００３９】
図１に関して前述したように、従来の分散システム４０は、各ホストアプリケーション６０とその対応するハードウェアデバイス５０との間に複数のチャネル７０を維持しなければならない。したがって、従来の分散システムに必要なチャネル７０の総数が、急激に増大して性能を低下させ、またアーキテクチャの設計閾値を上回ることもある。階層型通信アーキテクチャ２００は、この制限事項を克服し、陽子線治療デバイス１００などの分散システム内の通信およびデータ交換に必要なチャネルの総数を大幅に減少させる。例えば、例示した従来の分散システム４０では、３つのホストアプリケーション６０が４つのハードウェアデバイス５０と通信するように構成されており、合計１２のチャネル７０を必要とする。それに比べ、図３に示すように、階層型通信アーキテクチャ２００を使用すると、同数のホストアプリケーションおよびハードウェアデバイスを接続するのに７つのチャネルだけでよい。
【００４０】
図示した分散システムは本発明の一実施の形態に過ぎず、分散システムの他のサイズ／構成も同様に、階層型通信アーキテクチャ２００を用いて実施すると、チャネル数が削減する利益をもたらすことが理解されるであろう。さらに、有利なことに階層型通信アーキテクチャ２００を既存の分散システムと併せて使用するように構成でき、その結果これらのシステムがこの新しい通信アーキテクチャを備えるように改造され、チャネル数が削減されて複雑さが軽減される利益がもたらされる。
【００４１】
前述の分散システム構成の他の利益は、各デバイス２１０、その制御システム、またはエージェント２１５の物理的な場所を知らずに、ホストアプリケーション１０５をハードウェアデバイス２１０と通信するように構成できることである。この性質の論理マッピングによって、システム構成を大幅に修正せずに、構成要素を分散システム内で柔軟に設置できるようになる。一態様では、本発明の分散システム構成を陽子線治療デバイスに適用して、システム構成要素間のマッピング依存性を大幅に低減させることによって、システムのスケーラビリティおよびフレキシビリティを増大させることができる。既存の構成要素を置き換えるとき、または新しい構成要素をシステムに追加するときに、大幅な再構成を必要とすることなく、システムが容易に維持され、アップグレードされることから、この特徴はマルチステーション処置設備を含む陽子線治療システムで特に有用である。
【００４２】
分散システム構成の重要な特徴は、システムに新しいホストアプリケーション１０５を追加する際の計算上の複雑さに関係する。図１に示すような従来のシステムは、ハードウェアデバイスに接続される各ホストアプリケーションについて、（Ｎ）の計算上の複雑さを有する（ここで、Ｎは、分散システム４０内のハードウェアデバイス５０の数である）。ハードウェアデバイス５０に適切に接続するには、ホストアプリケーション６０を追加するごとに、さらにＮ個のチャネル７０が必要になる。したがって、Ｍが分散システム内に存在するホストアプリケーションの数を表すとして、ホストアプリケーション６０を追加するごとに、チャネル７０の数が（Ｍ×Ｎ）の関数で増加する。
【００４３】
本発明では、ホストアプリケーションの追加に関する計算上の複雑さおよびコストが従来技術よりも大幅に削減される。例えば図３に示すように、第１のホストアプリケーションまたはクライアント１０５を複数のハードウェアデバイスに接続することに関する計算上の複雑さは、（Ｎ）の複雑さになる（Ｎは、分散システムに結合したハードウェアデバイス２１０の数である）。しかしその後、ホストアプリケーションまたはクライアント１０５を階層型通信アーキテクチャに続けて追加することに関する計算上の複雑さは、（１）、すなわち一定値である。したがって、第１番目のものより後にホストアプリケーションまたはクライアント１０５を追加するごとに、計算上の複雑さが大幅に軽減される。したがって、ホストアプリケーション１０５を追加して、ハードウェアデバイス２１０に適切に接続するように統合するには、合計Ｍ個だけのさらなるチャネル１５５を必要とする（ここで、Ｍは、分散システム内に存在するホストアプリケーションまたはクライアント１０５の総数に相当する）。したがって、本発明の分散システム内のチャネル１５５の数は、（Ｍ＋Ｎ）の関数で増大する。その結果、本発明の分散システム構成に必要なチャネル１５５の総数が増加する割合がかなり小さくなり、システムの複雑さが増大（すなわち、ホストアプリケーション１０５またはハードウェアデバイス２１０が増加）するときに計算上の複雑さが増大する割合は、従来の分散システムに比べて緩やかになる。階層型通信システムのこの特徴によって、以下でさらに詳細に説明するように、望ましいことにシステムのスケーラビリティが増大し、分散システムの管理が改善される。
【００４４】
図４は、さらに、陽子線治療デバイス１００との使用に適合された階層型通信アーキテクチャ２００を示す。前述のビーム輸送システム１７０、安全システム１７５、電源システム１８０、ロギングシステム１８５など、特定のサブシステムを形成するハードウェアデバイス２１０が、機能構成要素３０２に結合されていることが望ましい。機能構成要素３０２は、それぞれ物理レベルでも動作できる２つの論理層３０５に分けられる。第１論理層は、汎用層３１５を含み、これが、機能構成要素３０２の基盤ハードウェアデバイス２１０と、それよりも上位のアプリケーションまたはクライアント３２０との間に、通信インターフェースおよび経路指定機能を提供する。通常、クライアント３２０は、ほぼユーザ透過な（user-transparent）方式で汎用層３１５を介して情報要求およびコマンドを送る。続いてその送信が、組込み層３２５を含む第２論理層を介して、適切なハードウェアデバイス２１０に経路指定される。同様に、基盤ハードウェアデバイス２１０が、ユーザ透過な方式でクライアント３２０に情報を返信する。
【００４５】
一態様では、クライアント３２０は、制御構成要素３３５とユーザインターフェース３３０とを備えている。制御構成要素３３５は、機能構成要素３０２と相互作用し、基盤ハードウェアデバイス２１０と情報を交換して、指定された制御機能を実行する。各制御構成要素３３５はさらに、１つまたは複数のユーザインターフェース３３０に接続されていて、ユーザからの入力を受信し、必要に応じてユーザインターフェース３３０に情報を返すことができる。一態様では、１つまたは複数の制御構成要素３３５は、他の制御構成要素３３５にインターフェース接続して、所望の制御構成要素３３５間で直接通信するための手段を提供することができる。さらに、制御構成要素３３５は、複数の機能構成要素３０２間でコラボレーションするための手段を提供する。このコラボレーションは、ブレインコントローラ２２２と呼ばれる１つまたは複数の特殊コントローラ構成要素によって導かれる。他の制御構成要素２２０の様に、ブレインコントローラ２２２は、他のブレインコントローラ２２２に接続することによって、直接的または間接的に機能構成要素３０２のサービスを利用することができるのが望ましい。ブレインコントローラの構成および機能のさらなる詳細は、図８と併せてより詳細に説明する。
【００４６】
他の態様では、ユーザインターフェース３３０が、機能構成要素３０２と直接インターフェース接続することができ、制御構成要素３３５およびブレインコントローラ２２２を介してバイパス通信することができる。この通信モードを、例えば、ロギング動作、構成パラメータのフェッチ、およびデータストリームアプリケーションで使用して、機能構成要素３０２のハードウェアデバイス２１０とユーザインターフェース３３０との間で情報を直接送信することができる。
【００４７】
エージェント／汎用層
前述のエージェント２１５は、機能構成要素３０２の汎用層３１５内にある。各機能構成要素３０２は、クライアント３２０と基盤ハードウェアデバイス２１０との間のメッセージおよび情報のための経路指定デバイスとして働くエージェント２１５に結合させることができる。一態様では、クライアントによって送信される情報は、ハードウェアデバイス２１０を監視および制御するために望ましくはクライアント３２０によって発行される、コマンド、命令、要求などを含む。エージェント２１５は、この情報をクライアント３２０から受信し、機能構成要素３０２の基盤ハードウェアデバイス２１０に通信要求をサービスする、１つまたは複数のモニタ３４０に送信する。さらにエージェント２１５は、情報の性質に応じて、機能構成要素３０２内のすべてのモニタ３４０に所望の情報を同報するように構成することができる。
【００４８】
エージェント２１５はさらに、二重プロキシ（ｄｕａｌ−ｐｒｏｘｙ）機能を含み、モニタプロキシ機能２２６が、機能構成要素３０２に結合したモニタ３４０との通信を担い、クライアントプロキシ機能２２８が、クライアント３２０との通信を担う。さらに、エージェント２１５は、エラー検出やロギングなどの他のネットワーク通信機能も管理する。エージェント２１５には、さらにセキュリティ機能を組み込むことができ、それによってエージェントを、階層型通信アーキテクチャ２００の通信機構の使用にアクセス許可された「許可」クライアント３２０およびモニタ２４０を認識するように構成することができる。
【００４９】
階層型通信アーキテクチャ２００を使用する分散システムの通常（ルーチン）動作時に、システムが初期化され、エージェント２１５のモニタプロキシ２２６が、利用可能な各モニタ３４０とのハードウェアチャネル２２５を開く。モニタプロキシ２２６は、機能構成要素内の各モニタ３４０と通信し、モニタ３４０へのメッセージおよびモニタ３４０からのメッセージをキューに入れる機能を担うネットワークアプリケーションプログラミングインターフェース（ＡＰＩ：applications programming interface）を維持する通信プロキシである。
【００５０】
同様に、クライアントプロキシ２２８は、各クライアント３２０とのクライアントチャネル２２０を開くことによってクライアント３２０と通信するネットワークＡＰＩを維持する通信プロキシである。分散システム内の通信を可能にするのに多数の開かれたチャネルを必要とする従来のシステムとは異なり、本発明では、開かれた通信チャネル２２０、２２５の数とクライアント３２０およびハードウェアデバイス２１０の数とが１対１に対応している。
【００５１】
一実施の形態では、エージェント２１５は、メッセージポインタキューに対してポインタを利用しており、メッセージポインタが渡されて、実際のメッセージまたは情報が共有ヒープ内に格納される。第１キューは、クライアントプロキシへの着信メッセージに使用され、第２キューは、モニタプロキシからの発信メッセージ用であり、第３キューは、モニタプロキシへの着信メッセージであって、クライアントプロキシへの発信メッセージでもあるメッセージに使用される（例えば、クリーンパススルー）。クライアントプロキシの着信キューに到着するメッセージを検査し、且つ単一メッセージ（直線経路）または複数のメッセージ（ブロードキャスト）をモニタプロキシの発信キューに入れるスレッドを初期化するエージェント２１５によって情報が送信される。
【００５２】
クライアントプロキシは、クライアント３２０のアドレスをそれらのネットワークアドレス（すなわち、ソフトＩＰアドレス）にマッピングするルックアップテーブルを維持する。このテーブルは、メッセージが受信されるときに確立され、テーブルに追加されたエントリは、クライアント３２０に戻る、メッセージに対する返答の経路指定に使用される。さらに、エージェント２１５は、対応する宛先モニタ３４０にメッセージを経路指定するモニタプロキシ２２６によって使用される、モニタマッピング情報を含む構成データを維持することもできる。また、エージェント２１５がこの情報を使用して、特定の機能領域３０２内にどのモニタ３４０および関連ハードウェアデバイス２１０があるかを決定することもできる。その結果、単一のエージェント２１５を、複数の機能構成要素３０２および対応するハードウェアデバイス２１０のネットワーク通信を調整するように構成することができる。一実施の形態では、階層型通信アーキテクチャ２００は、分散システム全体についてネットワークトラフィックおよびメッセージングを調整する単一のエージェントを利用するように構成されるのが望ましい。単一エージェント構成を使用すると、新しい機能構成要素３０２およびハードウェアデバイス２１０の追加に関連したスケーリング動作が容易になり、分散システム全体にわたる整合性が保証される。
【００５３】
エージェントはさらに、分散システムへの無許可アクセスを防ぎ、あるいは特定の時間に情報送信の目的で認識されていないクライアント３２０を選択的にブロックする、様々なセキュリティ動作を実施することができる。エージェント２１５がこれらのセキュリティ動作を実行できる一つの方法は、開かれているクライアントチャネル２００を、その時点で認識または許可されているクライアント３２０だけに制限することである。患者の安全性およびシステムセキュリティを改善するために、これらのセキュリティ対策が、陽子線治療システム内で望ましく実施され得ることが理解されよう。
【００５４】
モニタプロクタ／組込み層
組込み層３２５を含む第２論理層は、基盤ハードウェアデバイス２１０との間の変換および通信を担うネットワークインターフェースまたはフックを提供する。各機能構成要素３０２の組込み層３２５は、望ましいことに、特定の機能構成要素３０２のハードウェアデバイス２１０が、クライアント３２０によって、分散システム内の場所またはアドレスについて明確に知らないままで、アクセスおよび監視され得るように、十分にユーザ透過性がある。
【００５５】
モニタ３４０は、各機能構成要素３０２の組込み層３１５にあり、汎用層３１５のエージェント２１５とのデータおよび情報の交換を担っている。以下においてさらに詳細に説明するように、モニタ３４０は、情報の受信、コマンドの解釈および変換、データ収集、データ提示、および情報の送信を含む機能の実行を担う複数の連携モジュールを含んでいる。
【００５６】
図５は、エージェント２１５とハードウェアデバイス２１０との間にあるモニタ３４０の連携モジュールを示す。モニタ２４０の機能構成要素には、プロキシ３５１、コマンドプロセッサ３５２、プロクタ３５３、ハードウェア抽出層３５４、およびドライバ３５５が含まれている。以下でさらに詳細に説明するように、これらの構成要素の活動は、エージェント２１５を介してクライアント３２０から受信した情報を処理し、この情報を認識可能な形式で基盤ハードウェアデバイス２１０に渡すことに関連したタスクを実行するように調整されるのが望ましい。
【００５７】
ドライバ３５５は、モニタ３４０の最下位論理レベルにあり、機能構成要素３０２とそれが相互作用するハードウェアデバイス２１０との間にハードウェアインターフェースを提供する。ハードウェアデバイス２１０は、いくつかの異なる計器、デバイス、装置などのいずれかを備えることができ、これらは、クライアント３２０によって制御および監視されることが望ましい。陽子線治療システムの典型的なハードウェアデバイス２１０は、磁石および線量計を備えることができる。ドライバ３５１は、クライアント３２０がハードウェアデバイス２１０の所望のサービスにアクセスすることができるように、ハードウェアデバイス２１０へのインターフェースの提供を担う。制御すべき各ハードウェアデバイス２１０には、ハードウェアデバイス２１０の一部分（すなわちコントローラカードなど）とインターフェースする少なくとも１つのドライバ３５１がある。
【００５８】
一般に、各ハードウェアデバイス２１０は、高度に専用化された限定的なコマンドセットを認識し、このコマンドは、特殊化されたビット／メモリアドレッシングまたはレジスタレベルコマンドを含んでいてもよい。これらのコマンド言語定義およびアドレッシングスキームは、通常は異なるクラスのハードウェアデバイス２１０（例えば、温度モニタと線量測定モニタ）間では共有されない。さらに、異なる製造業者製の類似のハードウェアデバイス２１０が、異なるコマンド構造を利用していることがある。さらに、データの出力およびフォーマットは、通常、ハードウェアデバイス２１０によって異なり、データ出力は、望ましくはクライアント３２０または他の機能構成要素３０２に渡すために変更されるべきであるフォーマットまたはユニット指定式であることがある。したがって、各ハードウェアデバイス２１０と通信するには、特殊化されたインタープリタを使用しなければならない。
【００５９】
ドライバ３５１は、特殊なインタープリタとして働き、上位の情報要求またはコマンドを、ハードウェアデバイス２１０によって認識されるネイティブ言語またはコードに変換する抽出機能を提供する。ハードウェアデバイス２１０のコマンド言語の制限を解消できるときには、階層型通信アーキテクチャ２００は、「汎用」コマンドおよび情報構造を利用することが望ましい。汎用言語は、階層型通信アーキテクチャ２００の様々な構成要素にわたり、共通認識される形式に情報をコード化する。特定のハードウェアデバイス２１０に向けた情報およびコマンドをドライバ３５１が受信し、汎用コードをハードウェアで認識可能なコードに変換するのに必要な動作を実行する。同様に、ドライバ３５１は、ハードウェアデバイス２１０から情報を受信し、この情報を分散システムの他の構成要素で認識される汎用形式に変換する。また、ドライバ３５１は、ユニット変換やフォーマット変換などの変換動作を実行してデータを修正してから、モニタ３４０の上位構成要素に分配することができる。
【００６０】
一態様では、前述のデータ変換動作をドライバ３５１のレベルで実行すことによって、望ましいことに、システムのスケーラビリティおよび開発フレキシビリティが向上する。例えば、既存のハードウェアデバイス２１０を異なるハードウェアデバイスに交換またはアップグレードする場合、階層型通信アーキテクチャ２００の上位構成要素に必要な修正が最小限に抑えられる。その代わりにドライバ３５１を構文またはコマンド構造の変更に対応するように容易に修正でき、それらを用いて、汎用言語コードが、新しくインストールされたハードウェアデバイスで認識されるコマンドまたは情報に変換される。同様に、ドライバ３５１は、分散システムの他の構成要素の大幅な修正の必要無く、新しいハードウェアデバイスによって生成されるデータのフォーマットまたは表示の変化を認識するように修正され得る。したがって、階層型通信アーキテクチャ２００をこのように構成することによって、ハードウェアデバイスの透過性が向上し、システムのアップグレードおよび保守に対応するのに必要な変更の数が限定される。
【００６１】
一態様では、ドライバ３５１は、基盤ハードウェアデバイス２１０にアクセスするために使用される、ラッパー（wrapper）アプリケーションプログラミングインターフェース（ＡＰＩ）を提供する。さらに、ドライバ３５１は、モニタ３４０の上位モジュールが要求する通りに実行するスレッドセーフ機能の集合体として実施することができる。ドライバ３５１は、通常、ハードウェアのレジスタへのメモリマップアクセスを使用して、結合されたハードウェアデバイス２１０とインターフェースしている。このようにインターフェースしているドライバは、ハードウェアデバイス２１０に含まれるプロセッサ、またはハードウェアデバイス２１０の制御に使用される周辺制御カードを利用することができる。この構成は、組込みクレイト（crate）とも呼ばれ、ここでクレイトは、ハードウェアデバイス２１０と、ドライバ３５１と、ドライバ３５１を実行するプロセッサと、ドライバ３５１によってハードウェアデバイス２１０の制御に使用されるコントローラカードとを備えている。
【００６２】
一実施の形態では、組込みクレイト内のドライバ開発および実施には、組込みコンピュータオペレーティングシステムおよび開発プラットフォームが使用される。組込み開発プラットフォームを使用することによって、ハードウェアレジスタを仮想化するようにドライバ３５１を設計でき、ハードウェアデバイス２１０によって要求される保護および他のサービスを提供できる。一態様では、ドライバ３５１は、ハードウェアデバイス２１０内の機能およびレジスタと、ソフトウェア開発者が使用する機能との間の論理マッピングを維持する、一連の機能呼び出しを与えるように構成され得る。また、機能構成要素３０２は、必要または要求に応じて作動するために、ドライバ３５１を使用して機能呼び出しを発行するようにも構成され得る。
【００６３】
ドライバ３５１は、ハードウェアデバイスの相互作用に集中して、特定のハードウェアデバイス２１０の「生の（raw）」サービスに対するインターフェースを提供でき、一方、ハードウェア抽出層（ＨＡＬ：hardware abstraction layer）３５４は、ドライバ３５１を使用して必要なハードウェア抽出を提供し、クライアント３２０による情報の提示とハードウェアデバイス２１０のそれとの間にブリッジを形成する。ＨＡＬ３５４はさらに、分散システムによって提供されるサービスと、ジョブを実行するハードウェアデバイス２１０との間の変換機構として働く。ＨＡＬ３５４のこの特徴によって、機能構成要素３０２に含まれる各ハードウェアデバイス２１０のその時点での実施およびコマンド構造を、分散システムの各部分に認識させ続けようとする問題および困難性が大幅に解消される。
【００６４】
例えば、ＨＡＬ３５４は、クライアント３２０からコマンドおよび命令を工学単位（例えば、アンペア（Amps）、ボルト（Volts）、ミリトール（mTorr）など）で受信し、それらを適切なドライバ表現、ならびに基盤ハードウェアデバイス２１０によって許容可能な入力として認識されるＡＰＩ呼び出しに変換する。同様に、ＨＡＬ３５４は、ハードウェアデバイス２１０から生のデータ出力および情報を受信し、生データをクライアント３２０に認識されるまたは望まれる形式に変換する１つまたは複数の動作を実行することができる。
【００６５】
ＨＡＬ３５４によって提供される望ましい特徴の１つは、分散システム内で使用される各ハードウェアデバイス２１０を、クライアント３２０のコマンド／制御機能から分離させておくことができることである。具体的には、ＨＡＬ３５４は、クライアント３２０によって要求されるサービスをハードウェア透過な形式に反映し、それらを処理するようにドライバ３５１に渡すように設計される。ハードウェアデバイス２１０が分散システム内で変更されるとき、あるいはクライアント３２０によって新しいまたは異なるサービスが要求される場合、望ましいことにＨＡＬは、その変化に対応するのに最小限の修正しか必要としない。さらに、分散システムに変更または追加がなされるときには、エージェント２１５やクライアント３２０などのＨＡＬ３５４の上位にある他の構成要素は、望ましいことに、修正をほとんどまたは全く必要としない。その代わりに、ドライバ３５１および基盤ハードウェアデバイス２１０にＨＡＬ３５４をインターフェースするコードの一部分を作り直すことによって、ＨＡＬ３５４は、必要に応じてシステム設計の変更に対応するように更新され得る。
【００６６】
また、ＨＡＬ３５４は、ドライバ３５５および関連するハードウェアデバイス２１０を単一のメタデバイス（meta-device）に統合するメカニズムを提供することもできる。メタデバイスは、クライアント３２０からは、論理上、ハードウェアの単一のユニットに見える。このようにハードウェアを統合すると、望ましいことに、システムの見かけの複雑さが軽減され、分散システムのハードウェア構成要素の監視および指揮が容易になる。例えば陽子線治療システムでは、ビーム散乱（scatterer）メタデバイスを、１つまたは複数の、分解器（resolver）、モータコントローラ、デジタル入力、およびシリアルポート通信を含めたハードウェアデバイス２１０を備えるものとして定義することができる。したがって、ビーム散乱メタデバイスに発行される単一のメタコマンドまたは命令を使用して、ビーム散乱体（scatterer）の様々なハードウェアデバイス２１０に望ましく発行される、複数のコマンドおよび／または命令の複合体を表すことができる。メタコマンドは、ＨＡＬ３５４によって認識され、対応するコマンドおよび／または命令が、ＨＡＬ３５４によってドライバ３５１を介して、適切なハードウェアデバイス２１０に発行される。同様に、ＨＡＬ３５４は、メタデバイス内に含まれる複数のハードウェアデバイス２１０からデータおよび情報を受信し、この情報を組み合わせて統合された形式でクライアント３２０に返信する１つまたは複数の動作を実行することができる。
【００６７】
ＨＡＬ３５４の他の特徴は、クライアント３２０がデバイス２１０への明確なアドレスまたは経路を知る必要がないように、各ハードウェアデバイス２１０のマッピングを機能構成要素３０２内で内部維持するために、ＨＡＬ３５４が使用され得ることである。その代わりに、クライアント３２０が、コマンドを単純にモニタ３４０に導くことができ、続いてこれを処理して、ＨＡＬ３５４によって決定されるように、適切なハードウェアデバイスに経路指定することができる。この特徴が、複雑な分散システム内のマッピングの複雑さを大幅に軽減し、デバイスの透過性を向上させることが理解されよう。デバイスの透過性は、分散システムの見かけ上の複雑さを軽減し、また開発者がハードウェアデバイス２１０の実際のレイアウトまたはトポロジーを認識しておく必要をなくすのに役立つことから、望ましい特性である。さらに、ＨＡＬ３５４は、クライアント３２０の大幅な再ネットワーク化を必要とせずに、基盤ハードウェアデバイス２１０を修正し、または機能構成要素３０２内のデバイスの構成を変更できるように、容易に再定義され得る。
【００６８】
モニタ３４０は、関連ハードウェアデバイス２１０の性能を監視する１つまたは複数のプロクタ３５３をさらに含み、機能構成要素３０２内の異常なまたは望ましくないデバイス挙動に関するハンドラーの働きをする。プロクタ３５３は、機能構成要素３０２のハードウェアデバイス２１０の要件および／または要求を評価する。プロクタ３５３によって実行される機能には、正しいシステム設定の監視および範囲外のパラメータの識別が含まれる。
【００６９】
一態様では、プロクタ３５３は、ハードウェアデバイス２１０から受信したデータおよび情報を解釈することによって、異常なデバイス挙動を識別する。プロクタ３５３は、機能構成要素３０２内のハードウェアデバイス２１０に関する所望の許容度および範囲の知識を維持しており、実際のハードウェア情報を指定された許容度および範囲と比較することによって、ハードウェアデバイス２１０が所望のパラメータ内で実行しているかどうかを判断する。一態様では、陽子線治療システム内の異常なデバイス挙動は、リングエネルギー、電源出力、磁界強度、および／または照射線量などの、１つまたは複数の重要な変数３５７を評価することによって識別され得る。重要な変数３５７の値が上限または許容範囲外にあることが観察されると、プロクタ３５３はこの事象を認識して報告することができる。他の態様では、重要な変数が所定の限度を超えて標準値から偏差しているときに、異常な挙動を識別することができる（例えば出力スパイク）。さらに、異常な挙動が悪化傾向として観察されることもあり、この場合、プロクタ３５３は、偏差の平均の変動がある時間内に許容範囲から外れることを予想する。
【００７０】
プロクタ３５３は、停止コマンドまたは命令の発行を通して１つまたは複数のハードウェアデバイス２１０の動作を停止させることによって、異常な挙動に対処することができる。その代わりに、プロクタ３５３は、ハードウェアデバイス２１０が動作を続けることを許可するが、クライアント３２０に異常状態の警告を発行することもできる。さらに、プロクタ３５３に、ステータスインジケータ３５８の送信など、構成可能な方式で、異常な挙動をクライアント３２０にロギングおよびレポートする機能を設けることもできる。
【００７１】
プロクタ３５３は、さらに、従来のシステムによって実行されることが多い、ホストアプリケーションレベルでシステムのオフラインまたは誤動作を監視するという欠点を軽減する。一態様では、プロクタの特徴は、クライアントとの実質的な相互作用なしに常時実行される、ローカライズ形式のハードウェアデバイス監視である。この実施の形態では、プロクタは、ハードウェアデバイス１１０がその範囲内で望ましく動作すべき１組の条件またはパラメータを認識している。プロクタ３５３は、さらに、ハードウェアデバイス機能を監視し、それがこれらのパラメータ内で動作していることを保証する。ハードウェアデバイス１１０が、認識されている条件から偏差している場合、プロクタ３５３は、モニタに、標準動作パラメータを復元する、ハードウェアによって認識される適切なコマンドを発行するように命令することができる。
【００７２】
例えば、陽子線治療デバイス１００用の電源をプロクタ３５３によって監視して、出力電力が要求されるまたは所望の電力に一致することを保証することができる。さらに、プロクタ３５３は、電源システムに内部故障がないことを保証することもできる。電源用のプロクタ３５３によって、故障が検出され、あるいは電源が標準パラメータ内で動作していないことが観察されると、プロクタがレポートを作成し、それが外部システムに送信されて、制御アプリケーションまたはクライアントが稼働していなくても、故障に関する事前警告を通知することができる。さらに、プロクタ３５３は、ハードウェアによって認識される、補正または復元機能を実行するコマンドの発行をモニタに命令することによって、電源を通常動作に復元させる補正処置を実施することができる。
【００７３】
一態様では、プロクタ３５３の使用によって、粒子線治療デバイスにおける患者の安全性が大きく向上する。重要なハードウェアデバイス２１０を自動的に連続監視することによって、プロクタ３５３が、その時点で発生している危険な異常状態を識別し、患者に危険を与えることのある将来的な異常状態を予測することができる。例えば、プロクタ３５３によってビーム強度が許容範囲でないことが観察されたら、システムを停止させて、患者を傷つける可能性を防ぐことができる。同様に、プロクタ３５３が、ビーム強度がその時点では容認可能な許容範囲内にあるが悪化傾向が生じていることを観察し、それを用いて、いつビーム強度が許容範囲を外れるか予測して、補正処置を実施すべきかどうかを決定することができる。陽子線治療システムの複雑さによって、プロクタ３５３を使用して実施される自動ハードウェア監視および制御手法が促進されることが理解されよう。
【００７４】
コマンドプロセッサ３５２は、論理上プロクタ３５３およびＨＡＬ３５４のすぐ上位にあり、その両方は独立にこの構成要素に接続されている。コマンドプロセッサ３５２の機能は、クライアント３２０から受信した着信命令を解釈して実行することである。さらに、コマンドプロセスによって、ハードウェアデバイス２１０から受信した要求データおよび情報の形式で返信メッセージが提供される。
【００７５】
コマンドプロセッサ３５２は、着信命令またはメッセージの構文を解析および検査することによって命令を解釈し、検証に基づいて、適切なハードウェアデバイス２１０で実行すべき命令を転送する。転送された命令はＨＡＬ３５４によって受信され、前述のように、ハードウェアデバイス２１０で実行するために、ＨＡＬ３５４が、ドライバ３５５への命令の準備および提示に関連した動作を実行する。さらに、コマンドプロセッサ３５２は、ハードウェアデバイスの監視およびエラー検出に関連した動作を実行するプロクタ３５３にも命令を転送する。コマンドプロセッサ３５２のもう１つの機能は、ＨＡＬ３５４およびプロクタ３５３によって与えられる、ハードウェアデバイス２１０からのデータおよび情報を受信して、この情報を適切なクライアント３２０に転送することである。
【００７６】
一態様では、コマンドプロセッサ３５２は、クライアント３２０からの着信命令の順序を維持する情報キューを含んでおり、これらを先入れ先出し（first in/first out）法で処理する。コマンドプロセッサ３５２は、命令をキューに直接コピーするのではなく、メッセージのサイズが大きいときには、システム性能に悪影響を及ぼすことのある、情報の不必要なコピーを避けるために、命令へのポインタを格納することができる。命令が処理されると、それに応じてキューが更新され、要求される情報をクライアント３２０に送り返す。
【００７７】
通信プロキシ３５１は、論理上、コマンドプロセッサ３５２の上位にあり、エージェント２１５に結合した１つまたは複数のチャネルから着信データおよび情報を受信し、この情報をコマンドプロセッサ３５２に直接転送する。通信プロキシ３５１は、通常、モニタ３４０の他の構成要素とは異なり、特殊なコマンドまたは命令インタープリタを持たず、情報の受信および配布のために使用される。さらに、通信プロキシ３５１は、コマンドプロセッサ３５２から要求される情報を含む発信メッセージを受け入れ、エージェント２１５を介して適切なクライアント３２０に発信メッセージを転送する。
【００７８】
一態様では、通信プロキシ３５１は、エージェント２１５からモニタ３４０への開かれたチャネルまたはソケット接続をそのそれぞれが反映する、複数のネットワークＡＰＩオブジェクトを維持することによって、クライアント３２０から受信した命令をハードウェアデバイスによって送られた対応するデータまたは応答に関連付ける。コマンドプロセッサ３５２から結果が受信されたときに、命令の結果を適切なクライアント３２０に転送することができるように、通信プロキシ３５１によって、ネットワークＡＰＩオブジェクトが使用されて、着信コマンドまたは命令の発信元が識別される。
【００７９】
図６は、前述のモニタ３４０を使用してコマンドまたは命令を実行するプロセスを示す。このプロセスは、エージェント２１５を介して転送された、クライアント３２０からの命令が受信される状態４１０から始まる。コマンドの受信は、エージェント２１５との開かれたチャネルを維持する、通信プロキシ３５１によって行われる。通信プロキシ３５１は、さらに、命令の発信源のアドレス、チャネル、またはＩＰ番号を識別することによって、着信命令の発信元を検証する。この情報は、どのクライアントが、準備ができたときに命令の結果を送られるべきかを識別するために、通信プロキシ３５１によって使用される。
【００８０】
状態４１５に進むと、検証のために、通信プロキシ３５１がコマンドプロセッサ３５２に命令を転送する。検証には、その命令が、認識されているフォーマットに一致しており、ＨＡＬ３５４およびプロクタ３５３に分配されるであろう必要パラメータおよび値を有していることを保証するために、命令の構文を検査することが含まれている。コマンド検証後、プロセス４００は、通信プロキシ２１５が承認検査を実施する状態４２０に進む。承認検査とは、特定のハードウェアデバイス２１０へのアクセスを要求している、またはハードウェアコマンドを発行しているクライアント３２０が、それを実際に許可されているか確認する検証手順である。一態様では、承認状態４２０が使用されて、機能構成要素３０２またはハードウェアデバイス２１０へのクライアントアクセスを制約することによって、分散システム内にあるレベルのセキュリティを実施することができる。クライアントアクセスは、クライアント３２０が、モニタ３４０内に格納されたリストによって指定される十分な許可を有するものと認識されるときにだけ許可される。さらに、承認状態４２０がブロッキング手順の中で使用されて、そのリソースが既に他のクライアント３２０によって使用されているとき、あるいは他の理由でブロックされているときには、クライアントデバイス３２０が特定のハードウェアデバイスまたはリソースにアクセスしないように保証することができる。
【００８１】
コマンド検証および認定後、プロセスは、コマンドルックアップ状態４２５に進み、そこで、コマンドプロセッサ３５２が、入力コマンドまたは命令に基づいて、起動すべき正しいハードウェアＡＰＩおよび関連ハードウェアデバイス２１０を決定する。次いで、コマンドプロセッサ３５２は、この情報を所望のハードウェアデバイス２１０に結合した適切なＨＡＬ３５４に送り、そこで命令は、ハードウェアデバイス２１０によって認識される適切な形式に変換され、状態４３０において実行される。
【００８２】
状態４３５において、ハードウェア起動の結果は、モニタ３４０の様々な構成要素を介して戻され、そこで、それらは図５に関して詳細に説明したように、処理されてパッケージ化される。その後、通信プロキシ３５１が、コマンドまたは命令の結果を、エージェント２１５を介して適切なクライアント３０２に送信する。
【００８３】
図７は、エージェント２１５を使用してクライアントデバイス３２０およびモニタ３４０と通信する情報交換プロセスを示す。そのプロセスは、状態５１０から始まり、そこで分散システムが始動して、エージェント２１５が、そのシステムの構成、および必要な機能構成要素３０２ごとに使用されるモニタ４３０の場所を識別する。一態様では、関連するクレイトまたはハードウェアデバイス２１０へのチャネルマッピングの特徴を含む中央構成ファイルまたはシステムにアクセスすることによって、システムの構成が決定される。さらに、エージェント２１５は、クライアントアクセスを提供するためにバインドされる専用ポートまたはチャネル１５５を決定するリスニングポートを識別する。中央構成ファイルまたはシステムからこの情報が得られた後は、状態５１５において、エージェント２１５がリスニングポートにバインドされ、その後、エージェント２１５がアクセスするように指定した各モニタ３４０への接続を確立する。
【００８４】
状態５２０において、エージェント２１５が、通常の情報処理ならびにクライアント３２０およびモニタ３４０との通信を開始する。エージェント２１５が、接続されたクライアント３２０から命令または情報要求を受信すると、エージェント２１５は、要求の発信元またはチャネル１５５を記録し、それによって命令の発信源であるクライアント３２０を識別する。その後、状態５２５において、エージェント２１５は、命令が送られるべき適切なモニタ３４０を決定する。一態様では、命令を受信するように指定されるモニタ３４０は、コマンドの発生源である着信チャネル番号を用いて識別される。さらに、要求しているクライアント２１５の発信元アドレスは、クライアント３２０とエージェント２１５との間のデータ送信において、エンコードされていてもよい。発信元アドレスは、クライアント３２０によって解析され、命令の結果を受信するべき適切なエージェント２１５が決定される。その後、エージェント２１５が命令を適切なモニタ３４０に転送し、そこで図６で説明したように命令が処理される。
【００８５】
状態５３０において、エージェント２１５がモニタ３４０から命令の結果を含む返信を受信すると、エージェント２１５が、リスニングポートおよび中央構成ファイルによって決定される適切なクライアント３２０に返信を転送する。したがって、エージェント２１５は、各クライアント３２０とハードウェアに結合したモニタ３４０との間の中継の働きをする。
【００８６】
図８は、分散システムで指揮および監視活動を調整するのに使用されるブレインコントローラ２２２の一実施の形態を示す。ブレインコントローラ２２２は、複数の機能構成要素３０２を１つに集約させて論理メタデバイス６３０を形成するのに有用な追加的な計算機能を提供する。一態様では、メタデバイス６３０は、所望のタイプのサービスを提供するために、複数の機能構成要素３０２間のコラボレーションを必要とする複合機能ドメインを表わしている。
【００８７】
ブレインコントローラ２２２は、さらに、ハインドブレイン（hind-brain）６１０とフォアブレイン（fore-brain）６２０とに分けることができる。ハインドブレイン６１０は、通常、大規模な意志決定または分析的比較の必要のない動作を実行する。例えば、ハインドブレイン６１０を使用して、複数のシステムまたは機能構成要素３０２に接続し、監視および／または動作機能などの動作を実行することができる。一態様では、ハインドブレイン６１０は、ユーザインターフェース３３０からの直接的なユーザ入力なしに自律的に機能し、ネットワーク接続またはチャネル１５５を介して１つまたは複数の機能構成要素３０２と直接相互作用する。ハインドブレイン６１０は、ユーザインターフェース３３０を介してユーザにその活動のステータスまたは結果を表示するように構成できるが、この機能は、必ずしもハインドブレイン動作に必要ではない。ハインドブレイン６１０は、さらに、今度は他のエージェント２１５にネットワーク接続されるメタデバイス６３０のためのエージェントの働きをすることができ、多くのシステムまたは機能構成要素３０２を１つに合わせて結合させるための手段を提供する。
【００８８】
例えば、陽子線治療システムは、分散システム全体にわたって広がる、それぞれがそれぞれのエージェント２１５を備える、複数の別個の機能構成要素３０２を、望ましく監視するビーム妨害メタデバイスを、実施することができる。ビーム妨害メタデバイスには、さらに、その時点での粒子線治療デバイスの処置モードについて知ることが必要なことがある。さらに、ビーム妨害メタデバイスには、陽子線を受け取るべき処置ステーション１１５について知ることが必要な場合がある。これらの各情報源から得られた情報を使用して、ハインドブレイン６１０が、いつ陽子線を関与させるのが安全か決定する。この処理が分散システム全体にわたって広がっている複数の機能構成要素３０２の調整を含んでいるので、単一のＨＡＬ３５４は、通常、この複雑な動作の実行には適しておらず、したがって同様の機能を達成するには、メタデバイスを使用することが望ましい。
【００８９】
フォアブレイン６２０は、ハインドブレイン６１０に比べて分析機能が高く、複雑な活動制御動作の実施を担っている。一態様では、フォアブレイン６２０は、特定の動作を実行するために、正しいステップが確実に実施されることを保証する動作状態マシンを形成する。例えば、フォアブレイン６２０は、患者の処置を管理するのに必要なステップの制御および監視を担うことができる。フォアブレインは、複数のエージェント２１５およびハインドブレイン６１０と通信し、コマンドを送信し、応答を受信し、これらを基盤ハードウェアデバイス２１０の活動を調整するために使用することによって、このタスクを遂行する。したがって、フォアブレイン６２０は、様々なサブシステムの活動を誘導して、分散システムのタスクを整合された方式で実行する。さらに、各フォアブレイン６２０は、通常、様々なシステム活動を誘導し、必要または要求に応じて応答またはステータス更新情報を受信するフォアブレイン６２０と相互作用するために使用されるユーザインターフェース３３０に接続されている。
【００９０】
上記した発明の説明によって、本発明の新規特徴を示し、記載し、指摘したが、当業者には、本発明の趣旨から逸脱することなく、図示した装置ならびにその使用の詳細な形態に、様々な省略、置換、および変更を実施できることが理解されよう。
【図面の簡単な説明】
【００９１】
【図１】従来の分散システムのブロック図である。
【図２】陽子線治療システムの一実施の形態を示す図である。
【図３】分散環境で使用される階層型通信システムに関する最上位層の編成の一実施の形態を示す図である。
【図４】陽子線治療デバイスとの使用に適合した階層型通信システムの一実施の形態を示す図である。
【図５】階層型通信システムと併せて使用されるモニタの一実施の形態を示す図である。
【図６】モニタによって使用されるコマンドまたは命令プロセスを示す図である。
【図７】階層型通信システム内でエージェントデバイスによって使用される情報交換プロセスを示す図である。
【図８】階層型通信システムと併せて使用されるブレインコントローラの一実施の形態を示す図である。

Claims (90)

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. 前記プロクタ構成要素が、異常なハードウェア挙動を、前記ハードウェアデバイスに関する所望の許容範囲または動作範囲からの偏差として識別する、請求項２５に記載の階層型通信アーキテクチャ。
29. 前記異常なハードウェア挙動が、前記情報応答内に含まれる重要な変数を評価することによって識別される、請求項２５に記載の階層型通信アーキテクチャ。
30. 前記重要な変数が最大許容範囲または閾値で与えられる正常値を超えるときに、前記異常なハードウェア挙動が識別される、請求項２９に記載の階層型通信アーキテクチャ。
31. 前記異常なハードウェア挙動が、前記重要な変数の偏差の変動する平均がある時間内に正常値を超える悪化傾向として識別される、請求項２９に記載の階層型通信アーキテクチャ。
32. 前記重要な変数がリングエネルギー変数を含む、請求項２９に記載の階層型通信アーキテクチャ。
33. 前記重要な変数が電源出力変数を含む、請求項２９に記載の階層型通信アーキテクチャ。
34. 前記重要な変数が磁界強度変数を含む、請求項２９に記載の階層型通信アーキテクチャ。
35. 前記重要な変数が照射線量変数を含む、請求項２９に記載の階層型通信アーキテクチャ。
36. 前記プロクタによって発行される前記安全策が、放射線ビームの発生に関係する前記複数のハードウェアデバイスの１つまたは複数の動作を停止させることを含む、請求項２５に記載の階層型通信アーキテクチャ。
37. 前記プロクタによって発行される前記安全策が、前記ホストアプリケーションへの警告の転送を含む、請求項２５に記載の階層型通信アーキテクチャ。
38. 前記プロクタによって発行される前記安全策が、前記ホストアプリケーションへの異常な挙動のロギングまたはレポートを含む、請求項２５に記載の階層型通信アーキテクチャ。
39. 前記陽子線治療デバイスに追加クライアントが統合されるときに、前記少数のチャネルセットが一定の複雑さで増加する、請求項２５に記載の階層型通信システム。
40. 前記増加の複雑さが、前記陽子線治療デバイスのスケーラビリティを改善する、請求項３９に記載の通信システム。
41. 分散ネットワーク内の通信を管理するための階層型通信システムであって、
    前記分散ネットワークに接続され、単一チャネルを介して複数のハードウェアデバイスに命令を送信するように構成されたクライアントと、
    前記分散ネットワークを介して前記クライアントに接続され、さらに、各々のハードウェアデバイスが単一チャネルによって接続されるように前記複数のハードウェアデバイスに接続され、前記クライアントによって送信された命令を受信し、前記命令が向けられている目標のハードウェアデバイスを識別し、適切なチャネルを介して前記命令を前記目標のハードウェアデバイスに経路指定するエージェントと、
    前記目標のハードウェアデバイスに関連付けられ、さらに前記分散ネットワークに接続され、前記エージェントによって経路指定された前記命令を受信し、前記命令に関連するハードウェア認識可能なコマンドを識別し、その後、前記ハードウェア認識可能なコマンドを、後で実行させるために前記目標のハードウェアデバイスに発行するモニタとを含むシステム。
42. 前記分散ネットワーク内の通信が十分に透過な方式で経路指定されるように、前記エージェントが、１つまたは複数のモニタとの通信を仲介するために使用されるモニタプロキシと、１つまたは複数のクライアントとの通信を仲介するために使用されるクライアントプロキシとを含む二重プロキシ機能を有する、請求項４１に記載の階層型通信システム。
43. 前記エージェントモジュールに、１つまたは複数の許可されたクライアントを識別し、前記クライアントがそれを実施する適切な許可を有するものと識別されるときにだけ、命令を前記目標のハードウェアデバイスに経路指定する安全機能が、さらに組み込まれている、請求項４１に記載の階層型通信システム。
44. 前記モニタモジュールが、
    前記エージェントによって経路指定された前記命令を受信する通信プロキシと、
    前記命令の構文を解析および検査することによって、受信した前記命令を解釈するコマンドプロセッサと、
    前記目標のハードウェアデバイスの性能および動作パラメータを監視するプロクタと、
    前記命令を、前記目標のハードウェアデバイスによって受信されて後に実行されるハードウェア認識コマンドに変換するために使用されるハードウェア抽出層とをさらに含む請求項４１に記載の階層型通信システム。
45. 前記目標のハードウェアデバイスが、
    前記ハードウェア認識コマンドを前記モニタの前記ハードウェア抽出層から受信し、
    前記コマンドを実行し、且つ、
    前記プロクタによる処理及び前記エージェントを介しての前記クライアントへの転送のために、実行された前記コマンドに対応する動作情報を前記モニタに返す、請求項４４に記載の階層型通信システム。
46. 前記プロクタが、前記目標のハードウェアデバイスから前記動作情報を受信して、その時点の動作を評価する、請求項４５に記載の階層型通信システム。
47. 前記目標のハードウェアデバイスのその時点の動作が異常と判断されるときに、前記プロクタが、１つまたは複数の安全策を実行する、請求項４５に記載の階層型通信システム。
48. 前記安全策が、前記目標のハードウェアデバイスを無効にすることを含む、請求項４７に記載の階層型通信システム。
49. 前記安全策が、前記クライアントにステータスインジケータを転送することを含む、請求項４７に記載の階層型通信システム。
50. 前記目標のハードウェアデバイスが正常動作パラメータから外れて動作しているときに、前記目標のハードウェアデバイスの前記その時点の動作が異常と判断される、請求項４７に記載の階層型通信システム。
51. 前記目標のハードウェアデバイスが誤動作しているとき、または動作していないときに、前記目標ハードウェアデバイスの前記その時点の動作が異常と判断される、請求項４７に記載の階層型通信システム。
52. 前記目標のハードウェアデバイスの前記その時点の動作の傾向が、前記目標のハードウェアデバイスが将来の時点で正常動作パラメータから外れて動作することを示しているとき、前記目標のハードウェアデバイスの前記その時点の動作が異常と判断される、請求項４７に記載の階層型通信システム。
53. 前記エージェントが、前記複数のハードウェアデバイスの少なくとも１つの動作を監視するために使用される制御構成要素またはアプリケーションを含む、請求項４４に記載の階層型通信システム。
54. 前記クライアントがユーザインターフェースを含み、
    該ユーザインターフェースを介して、ユーザが、前記複数のハードウェアデバイスの１つまたはそれ以上を制御または監視する命令を入力し、さらに、前記ユーザインターフェースが、前記複数のハードウェアデバイスの１つまたはそれ以上から、その動作ステータスを示す情報を受信する、請求項４４に記載の階層型通信システム。
55. 前記クライアントがユーザインターフェースを含み、
    該ユーザインターフェースを介して、ユーザが、前記複数のハードウェアデバイスの１つまたはそれ以上を制御または監視する命令を入力し、さらに、前記ユーザインターフェースが、前記複数のハードウェアデバイスの１つまたはそれ以上から、前記命令の結果を示す情報を受信する、請求項４４に記載の階層型通信システム。
56. 前記クライアントが、１つまたは複数の前記ハードウェアデバイスの活動を調整するために使用されるブレインコントローラを含む、請求項４４に記載の階層型通信システム。
57. 前記ブレインコントローラが、前記分散システム内の１つまたは複数のハードウェアデバイスを監視するハインドブレイン構成要素を含む、請求項５６に記載の階層型通信システム。
58. 前記ブレインコントローラが、前記分散システム内の１つまたは複数のハードウェアデバイスを制御するフォアブレイン構成要素を含む、請求項５６に記載の階層型通信システム。
59. 前記ブレインコントローラが、前記複数のハードウェアデバイスを、整合されたハードウェア機能ドメインを表すメタデバイスに集約するために使用される、請求項５６に記載の階層型通信システム。
60. 前記ブレインコントローラが、実質的なユーザ入力を要求せずに、自律的に動作する、請求項５６に記載の階層型通信システム。
61. 複数のハードウェアデバイスと、これらの複数のハードウェアデバイスを制御および監視する命令を発行するクライアントとの間で情報を交換するための方法であって、
    前記クライアントと、前記クライアントと通信し、そこから送信された命令を受け取るように構成されたエージェントとの間に第１の通信チャネルを確立するステップと、
    前記エージェントと各々のハードウェアデバイスとの間に複数の第２の通信チャネルを確立するステップと、
    前記命令が十分に透過な方式で適切なハードウェアデバイスに転送されるように、前記エージェントを用いて、前記クライアントによって発行された前記命令を経路指定するステップと、
    前記命令を、後で前記ハードウェアデバイスによって実行される、ハードウェアで認識されるフォーマットに変換する、前記ハードウェアデバイス上にあるモニタモジュールを使用して、前記命令を受信するステップとを含む方法。
62. 前記モニタモジュールが、さらに、前記ハードウェアデバイスから、後に前記エージェントを介して前記クライアントに転送されるステータス情報を受信する、請求項６１に記載の情報交換方法。
63. 前記モニタモジュールが、前記ハードウェアデバイスの動作を監視し、前記ハードウェアデバイスが所望の許容範囲内で動作しているか否かを判断するプロクタをさらに含む、請求項６１に記載の情報交換方法。
64. 前記ハードウェアデバイスが前記所望の許容範囲から外れて動作していると判断されたときに、前記プロクタが、１つまたは複数の安全策を実行する、請求項６３に記載の情報交換方法。
65. 前記プロクタによって実行される前記安全策が、前記ハードウェアデバイスのその時点の動作機能を示すステータスインジケータを、前記クライアントに発行することを含む、請求項６４に記載の情報交換方法。
66. 前記プロクタによって実行される前記安全策が、前記ハードウェアデバイスの解除を含む、請求項６４に記載の情報交換方法。
67. 前記プロクタによって実行される前記安全策が、前記ハードウェアデバイスの動作を前記所望の許容範囲内に戻すために、前記ハードウェアデバイスによって実行される、ハードウェアで認識される１つまたは複数のコマンドを発行することを含む、請求項６４に記載の情報交換方法。
68. 前記クライアントおよび前記複数のハードウェアデバイスが、陽子線治療システムを構成し、前記情報の交換が前記システムのスケーラビリティを改善する、請求項６４に記載の情報交換方法。
69. 前記クライアントおよび前記複数のハードウェアデバイスが、陽子線治療システムを構成し、前記システムの計算上の複雑さが一定の関数で増大する、請求項６４に記載の情報交換方法。
70. 前記モニタが、前記クライアントからの命令を受信することなく、自律的に動作する、請求項６４に記載の情報交換方法。
71. 自律的な前記モニタの動作が、オフラインデバイスを監視するために使用される、請求項７０に記載の情報交換方法。
72. 自律的な前記モニタの動作が、誤動作しているハードウェアデバイスを検出するために使用され、前記モニタが、前記誤動作しているハードウェアデバイスを正常動作に戻す補正処置を自動的に実施する、請求項７０に記載の情報交換方法。
73. 自律的な前記モニタの動作が、異常なハードウェアデバイス挙動を検出するために使用され、前記モニタが、前記誤動作しているハードウェアデバイスを正常動作に戻す補正処置を自動的に実施する、請求項７０に記載の情報交換方法。
74. 自律的な前記モニタの動作が、異常なハードウェアデバイス挙動を検出するために使用され、前記モニタが、前記異常な挙動を、後で前記クライアントに送信するために自動的にロギングする、請求項７０に記載の情報交換方法。
75. １つまたは複数のホストアプリケーションと複数のハードウェアデバイスとを含み、望ましくは前記ホストアプリケーションが複数の命令の送信を介して前記複数のハードウェアデバイスを制御および監視するために使用される、陽子線治療システム内で情報を交換するための方法であって、
    各ホストアプリケーションとエージェントデバイスとの間に、前記ホストアプリケーションと通信し、送信された命令を受信するように構成された第１の通信チャネルを確立するステップと、
    各ハードウェアデバイスが単一通信チャネルによってエージェントに接続されるように、前記エージェントデバイスと各ハードウェアデバイスとの間に複数の第２の通信チャネルを確立するステップと、
    前記ホストアプリケーションによって発行された命令を、該命令が十分に透過な方式で、適切な前記ハードウェアデバイスに転送されるように、前記エージェントデバイスを用いて経路指定するステップと、
    前記命令を、後にハードウェアデバイスによって実行されるハードウェアデバイスで認識されるフォーマットに変換する、各々の前記ハードウェアデバイス上にあるモニタモジュールを使用して、前記命令を受信するステップとを含む方法。
76. 前記ホストアプリケーションと前記ハードウェアデバイスとの間の前記通信が、患者の処置に関連する１つまたは複数の重要な変数を監視するために使用される、請求項７５に記載の陽子線治療システムにおける情報交換方法。
77. 前記重要な変数が、異常なハードウェア挙動を識別するために監視される、請求項７６に記載の陽子線治療システムにおける情報交換方法。
78. 前記異常なハードウェア挙動が、前記重要な変数が最大許容範囲または閾値で与えられる正常値を超えるときに識別される、請求項７７に記載の陽子線治療システムにおける情報交換方法。
79. 前記異常なハードウェア挙動が、前記重要な変数の偏差の変動する平均がある時間内に正常値を超える悪化傾向として識別される、請求項７７に記載の陽子線治療システムにおける情報交換方法。
80. 前記重要な変数がリングエネルギー変数を含む、請求項７６に記載の陽子線治療システムにおける情報交換方法。
81. 前記重要な変数が電源出力変数を含む、請求項７６に記載の陽子線治療システムにおける情報交換方法。
82. 前記重要な変数が磁界強度変数を含む、請求項７６に記載の陽子線治療システムにおける情報交換方法。
83. 前記重要な変数が照射線量変数を含む、請求項７６に記載の陽子線治療システムにおける情報交換方法。
84. プロクタがさらに、前記異常なハードウェア挙動の検出に応答して、前記複数のハードウェアデバイスの１つまたは複数の動作を停止する、請求項７７に記載の陽子線治療システムにおける情報交換方法。
85. 前記プロクタが、前記異常なハードウェア挙動の検出に応答して、前記ホストアプリケーションに警告を転送する、請求項７７に記載の陽子線治療システムにおける情報交換方法。
86. 前記プロクタが、前記異常な挙動を前記ホストアプリケーションにロギングまたはレポートする、請求項７７に記載の陽子線治療システムにおける情報交換方法。
87. ネットワークリソースの分散システムの通信および制御方法であって、
    クライアントデバイスとエージェントデバイスとの間に第１の通信チャネルを確立するステップと、
    前記エージェントデバイスと少なくとも１つのハードウェアデバイスとの間に第２の通信チャネルを確立するステップと、
    前記クライアントデバイスと前記エージェントデバイスとの間、及び前記エージェントデバイスとモニタデバイスとの間で転送されるデータを、ハードウェアリソースの前記分散システムにアクセス要求するクライアントプロセス、通信チャネルを管理してクライアントプロセス要求を経路指定するエージェントプロセス、並びに、前記エージェントプロセスからの要求を受信し、該要求を実行し、及び、結果を前記クライアントプロセスに返信するモニタプロセスに従って、処理するステップとを含む方法。
88. ユーザインターフェースを介してユーザから前記要求を受信するステップと、
    クライアントデバイスから前記エージェントデバイスに前記要求を転送するステップとをさらに含む請求項８７に記載のクライアントプロセス。
89. 前記クライアントデバイスから前記要求を受信するステップと、
    前記エージェントデバイスがどのハードウェアデバイスに前記要求を転送すべきかを決定するステップと、
    前記決定されたハードウェアデバイスに前記要求を送信するステップとをさらに含む請求項８７に記載のエージェントプロセス。
90. 前記エージェントデバイスから前記要求を受信するステップと、
    前記要求を、前記ハードウェアデバイスで実行される、ハードウェアで認識される命令に変換するステップと、
    異常なハードウェア挙動を識別するために、前記ハードウェアデバイスのステータスを監視するステップと、
    異常なハードウェア挙動が検出されたときに、１つまたは複数の補正処置を実施するステップとをさらに含む請求項８７に記載のモニタプロセス。

Images