JP2019513445A - 撮像システム及び撮像システムの複数のノード間における通信のための通信プラットフォーム - Google Patents

Abstract

本発明は、撮像システム、及び、撮像システムの複数のノード間における通信のための通信プラットフォームを提案する。撮像システムのノードは、ネットワークを介してデータメッセージを受信するためのプロトコルモジュール５１０と、プロトコルモジュールからデータメッセージのデータフィールドを受信するためのネットワークモジュール５２０と、少なくとも１つのサービスモジュール５３０−１、…、５３０−ｎとを備え、データフィールドは、データメッセージの種類を示すためのメッセージ識別子（ＭｓｇＩＤ）と、ペイロードフィールドとを含み、各サービスモジュール５３０−１、…、５３０−ｎは、データメッセージのペイロードを取り扱う少なくとも１つのメッセージハンドラ５３２を備え、ネットワークモジュール５２０は、ディスパッチャ５２１と、複数のキュー５２３と、コールバックモジュール５２２と、メッセージ識別子と複数のキューとの間の第１のマッピング及びメッセージ識別子（ＭｓｇＩＤ）とコールバックハンドラとの間の第２のマッピングを記憶するためのメモリ５２４とを備え、ディスパッチャ５２１は、メッセージ識別子（ＭｓｇＩＤ）と第１のマッピングとに基づいて、複数のキュー５２３のうちの１つにデータメッセージをディスパッチするように構成され、コールバックモジュール５２２は、第２のマッピングに基づいて、複数のキューの各々にあるデータメッセージを処理するように構成され、各コールバックハンドラは、サービスモジュールにおけるメッセージハンドラに向けられる。

Description

本発明は、概して、医療撮像システムなどの撮像システムに関し、より具体的には、撮像システムにおける複数のノード間における通信のための通信プラットフォームに関し、コンピュータ断層撮影（ＣＴ：ｃｏｍｐｕｔｅｄ ｔｏｍｏｇｒａｐｈｙ）への特定の応用とともに説明されるが、以下の内容は、例えばＭＲＩ（磁気共鳴撮像、Ｍａｇｎｅｔｉｃ Ｒｅｓｏｎａｎｃｅ Ｉｍａｇｉｎｇ）、ＰＥＴ（陽電子放射断層撮影、Ｐｏｓｉｔｒｏｎ Ｅｍｉｓｓｉｏｎ Ｔｏｍｏｇｒａｐｈｙ）、ＰＥＴ−ＣＴなどの他の撮像システムにも適応する。

図１は、ＷＯ２０１２／０７３１６７において説明されるようなＣＴ撮像システム１００などの従来の撮像システムを示す。撮像システム１００は、固定ガントリー１０２と、固定ガントリー１０２により回転可能に支持された回転ガントリー１０４とを含む。回転ガントリー１０４は、長手軸又はｚ軸の周りで検査領域１０６の周囲を回転する。カウチなどの支持体１０８は、検査領域１０６内で対象者を支持し、走査前、走査中、及び／又は走査後にｘ、ｙ、及び／又はｚ軸に対して対象者を配置するために使用され得る。ｘ線管などの放射源１１０は、回転ガントリー１０４により支持され、検査領域１０６の周りを回転ガントリー１０４とともに回転し、及び、検査領域１０６を横断する放射線を照射する。ソースコリメータ１１２は、照射された放射線をコリメートして、検査領域１０６を横断する概ねファン、くさび、又は錐形の放射線ビームを生成する。検査領域１０６をまたいで放射源１１０の反対側に位置する放射線感受性ディテクターアレイ１１４は、検査領域１０６を横断する放射線を検出して放射線を示す投影データを生成する複数のディテクターピクセルを含む。再現器１１６は、投影データを再現して、検査領域１０６を表すボリュメトリック像データを生成する。イメージプロセッサ１１８は、ボリュメトリック像データを処理して、検出された放射線を表す１つ又は複数の像を生成する。ディスプレイ１２０は、１つ又は複数の像を提示するために使用される。汎用コンピューティングシステムは、オペレーターコンソール１２２として機能し、ディスプレイなどの出力デバイスと、例えばキーボード、マウス、及び／又はその他のものなどの入力デバイスとを含む。コンソール１２２に存在するソフトウェアは、臨床ワークフローを制御することを含め、システム１００の動作をオペレーターが制御することを可能にする。制御システムは、ガントリーホスト１２４として機能し、典型的には固定ガントリー１０２の内部に配備される。ガントリーホスト１２４は、支持体１０８の移動を制御すること、及び、例えば回転ガントリー１０４の回転などの走査フローを制御することを含む、様々なコンポーネントのための制御を提供する。

最近、様々なフラットパネルなどのより多くのコンポーネントが、撮像システムに導入されるように提案されている。図２は、ＣＴ撮像システムなどの撮像システム２００を示す。図１に示す撮像システム１００と比べて、撮像システム２００は、コンソール２１０及びガントリーホスト２２０に加えて、左パネル２１０、右パネル２２０、及びＣＴボックス２３０をさらに備える。それらのコンポーネント２１０〜２３０に存在するソフトウェアは、システム１００の動作をオペレーターが制御することを可能にする。各コンポーネントは、互いに異なってもよく、及び、コンソール２１０のＯＳ（例えばＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ）及びガントリーホスト２２０のＯＳ（例えばＬｉｎｕｘ（登録商標））と異なってもよい各自のオペレーティングシステム（ＯＳ：ｏｐｅｒａｔｉｏｎ ｓｙｓｔｅｍ）を含んでもよい。例えば、フラットパネルのＯＳは、ａｎｄｒｏｉｄ、ｉＯＳ、Ｌｉｎｕｘ（登録商標）、及びＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓなどであり得る。

ＵＳ２００５／０２３２２９１Ａ１は、メッセージがメッセージ検証プログラムを備える受け手プログラムに送信される前に、メッセージキューイングソフトウェア環境内でメッセージを検証する方法を開示する。

ＵＳ９０９２２８２Ｂ１は、キューマネージャー上で動作するチャンネルを監視する方法を開示する。チャンネルインスタンスの総数と、キューマネージャー上で動作する指定されたチャンネルの各々のインスタンスとの両方が経時的に監視される。

図２を参照すると、コンソール２１０、ガントリーホスト２２０、及び様々なノード２３０〜２５０などの撮像システム２００の複数のノード間における通信を可能にするために、通信ネットワークが、すべてのこれらのノードを相互接続するように配備される。複数のノードの各々が、他のノードと異なり得る各自のＯＳを含むので、想定される解決策は、例えば、ノードの各ペア間の通信を可能にするためにノードの各ペアに対して１つのソケット接続など、ネットワーク層でより多くのソケット接続を生成することであり得る。しかし、本発明の発明者らは、図９に示されるように、このような解決策が多くの欠点をもつことを認識している。

各ノードは、ネットワーク層にネットワークモジュール９２０を備え、ネットワーク層より上のサービス層に１つ又は複数のサービスモジュール９３０−１、９３０−２を備える。送信／受信キューは、ネットワークモジュール９２０におけるキュー９２３と、各サービスモジュール９３０−１、９３０−２におけるキュー９３３とを含め、ネットワーク層とサービス層との各々において実施されることとなる。通常、高パフォーマンスの又は異なる種類のサービスモジュールのために、２つ以上のスレッドが、異なる種類のメッセージを取り扱うために使用される。各サービスモジュール９３０−１、９３０−２はいくつかのメッセージハンドラを備え、異なるメッセージハンドラは、異なる種類のデータメッセージを取り扱う。サービスモジュールの種類は、異なるオペレーティングシステムに対して同じではない場合があるので、ソースコードは再使用され得ない。

ディスパッチャも比較的単純である。すべてのタイプのメッセージを受信するために１つのスレッドが使用される。サービス層の異なるサービスモジュールにメッセージをディスパッチするためにネットワーク層に１つのスイッチ９２１が必要とされ、各サービスモジュールが対象のメッセージを逐次構文解析するために別のスイッチ９３２がさらに必要とされる。これは、それほどリアルタイムではなく、高パフォーマンスを達成することができない。さらに、サービス層は、メッセージデータキャッシュ／キュー、スレッドを生成及び管理する必要があり、対象のメッセージを処理するなどのそれ自体のタスクに注力することができない。新しい種類のデータメッセージが撮像システム２００に導入された場合、サービスモジュール９３０−１、９３０−２に対応したソースコードが各サービスモジュールに対して変更される必要がある。図２に示されるように、ノード２１０〜２５０などの２つ以上のノードが存在する場合、すべてのノード２１０〜２５０のすべてのサービスモジュールに対応したソースコードに対する変更が必要とされる。

従って、撮像システムにおける複数のノード間における通信のための改善された通信プラットフォーム又はアーキテクチャを提供することが有益である。

本発明の第１の態様の一実施形態によれば、撮像システムにおける複数のノードのうちのノードが提案される。撮像システムは、撮像システムにおける複数のノード間における通信のためのネットワークを備える。ノードは、ネットワークを介してデータメッセージを受信するためのプロトコルモジュールと、プロトコルモジュールからデータメッセージのデータフィールドを受信するためのネットワークモジュールと、少なくとも１つのサービスモジュールと、を備え、データフィールドは、データメッセージの種類を示すメッセージ識別子と、ペイロードフィールドとを備え、各サービスモジュールは、データメッセージのペイロードを取り扱う少なくとも１つのメッセージハンドラを備え、ネットワークモジュールは、ディスパッチャと、複数のキューと、コールバックモジュールと、メッセージ識別子と複数のキューとの間の第１のマッピング及びメッセージ識別子とコールバックハンドラとの間の第２のマッピングを記憶するためのメモリと、を備え、ディスパッチャは、メッセージ識別子と第１のマッピングとに基づいて複数のキューのうちの１つにデータメッセージをディスパッチするように構成され、コールバックモジュールは、第２のマッピングに基づいて複数のキューの各々にあるデータメッセージを処理するように構成され、各コールバックハンドラは、サービスモジュールにおけるメッセージハンドラに向けられる。

図９に示す前述の想定される解決策によると、それがメッセージを受信した後、ネットワークモジュールのディスパッチャが、メッセージの種類を確認するように構成され、ディスパッチャは、サービス層における１つ又は複数のサービスモジュール９３０−１、９３０−２の各サービスモジュールに対して、メッセージが対象となるか否かを判定し、メッセージがサービスモジュールに対して対象となる場合、サービスモジュールにメッセージをディスパッチする。典型的には、ネットワーク層において、各サービスモジュール９３０−１、９３０−２のためにキュー９２３−１、９２３−２が生成され、１つのサービスモジュールに対する対象のメッセージは、同じキューにプッシュされ、サービス層のサービスモジュールにより受信キュー９３３にプルされ、次に、サービス層の各サービスモジュール９３０−１、９３０−２において、ディスパッチャが、逐次受信キュー９３３内のメッセージを構文解析するように構成される。

提案される解決策では、メッセージは、ネットワーク層において完全に異なる手法でディスパッチされ、上述のキューもデータキャッシュもサービス層に必要とされない。ネットワーク層における複数のキューのうちの各キューは、特定のサービスモジュールに割り当てられるのではなく、各キューは、１つ又は複数の種類のデータメッセージに関係する。ネットワークモジュールのディスパッチャは、データメッセージの種類と複数のキューとの間のマッピングに基づいて、複数のキューのうちの１つにデータメッセージをディスパッチするように構成される。一実施形態において、すべての種類のデータメッセージは、それらのスケジューリング技法に応じて、異なるキューにディスパッチされ得る。例えば、逐次的に取り扱われる種類のデータメッセージは、１つのキューにディスパッチされ得、並列に取り扱われる種類のデータメッセージは、別のキューにディスパッチされ得る。別の一実施形態において、すべての種類のデータメッセージが、レイテンシ要求に応じて、異なるキューにディスパッチされ得る。例えば、ほとんど遅延を伴わないか、まったく遅延を伴わずに取り扱われるべき種類のデータメッセージは１つのキューにディスパッチされ得、より大きな遅延許容値を伴う種類のデータメッセージは、別のキューにディスパッチされ得る。

さらに、提案されるネットワークモジュールはサービス層にデータメッセージを単純に渡すのではなく、コールバックモジュールが、メッセージ識別子とコールバックハンドラとの間のマッピングに基づいて、各データメッセージに対して、サービス層におけるメッセージハンドラのエンターアドレスなどのコールバックハンドラを直接提供し得る。従って、サービス層ではデータメッセージをキューに入れる必要がなく、ネットワークモジュールは、サービス層における対応するメッセージハンドラにデータメッセージを直接送達することができる。

新しい種類のデータメッセージが撮像システム２００に導入された場合、以前はサービス層のスイッチャー９３２及びキュー９３３により行われていた作業が、ここではネットワーク層により行われるので、以前はすべてのノードのすべてのサービスモジュールのスイッチャー９３２及びキュー９３３のすべてに対して要求されていた大量のソースコード変更作業の必要がなくなる。新しい種類のデータメッセージのための関連するマッピングを追加することによる第１のマッピング及び第２のマッピングの非常に単純な構成変更を除いて、ネットワーク層におけるソースコードを変更する必要がない。従って、導入された新しいアプリケーション／サービス又は新しいノードに起因して新しい種類のデータメッセージが導入されたとき、撮像システム２００を簡単に拡張することができる。

第１のマッピング及び第２のマッピングは、事前構成され得るか、又は動的に構成され得る。

本発明の別の実施形態によると、ネットワークモジュールは、メッセージ識別子と、メッセージ識別子をもつデータメッセージがディスパッチされる先となる複数のキューのうちの１つを示すためのキューアイデンティティ値と、メッセージ識別子をもつデータメッセージを取り扱うためのサービスモジュールのメッセージハンドラに向けられたコールバックハンドラとをサービスモジュールから受信し、受信されたメッセージ識別子（ＭｓｇＩＤ）、受信されたキューアイデンティティ値、及び受信されたコールバックハンドラに基づいて、第１のマッピングと第２のマッピングとを更新するように構成されたレジスタをさらに備える。

このようにすると、サービスモジュールのすべてが他のノードへの接続を確立する、又はキューイングを取り扱うのではないものの、各種類のデータメッセージがどのキューに経路設定又はディスパッチされることになるかをネットワークモジュールに知らせることにより、その対象のメッセージをどのようにキューに入れるかを柔軟に設定又は構成することが依然として可能であり、コールバックハンドラを設定することにより、その対象のメッセージの各々に対してメッセージハンドラを柔軟に構成することもできる。その結果、すべての種類のサービスが、簡単にネットワークに配備され得る。クライアントは、対象のサーバへの接続を生成することを必要とせず、任意のデータメッセージの送信及び／又は受信を取り扱うことを必要とせず、クライアントは、対象のメッセージに対するそのコールバックをレジスタに入れること、及び、その対象のメッセージがどのようにキューに入れられることになるかを設定することしか必要としない。例えば、クライアントは、複数のキューのうちの１つ又は複数にその対象のメッセージを割り当てることにより、どの種類のメッセージが逐次的に取り扱われるか、どの種類のメッセージが並列に取り扱われるか、又は、どの種類のメッセージが専用の非共有キューにおいて取り扱われるかをカスタマイズし得る。

本発明の別の実施形態によると、サービスモジュールは、メッセージ識別子と、メッセージ識別子をもつデータメッセージがディスパッチされる先となる複数のキューのうちの１つを示すためのキューアイデンティティ値と、コンフィギュレーションデータに基づいて、メッセージ識別子をもつデータメッセージを取り扱うためのサービスモジュールのメッセージハンドラに向けられたコールバックハンドラとを生成するようにさらに構成される。

本発明の別の実施形態によると、ネットワークモジュールは、メッセージ識別子をサービスモジュール（５３０−１、…、５３０−ｎ）のために受信し、受信されたメッセージ識別子に対応したマッピングを除去することにより、受信されたメッセージ識別子に基づいて第１のマッピングと第２のマッピングとを更新するように構成されたアンレジスタをさらに備える。

ある種類のメッセージがサービスモジュールにとってもはや対象とならない場合、サービスモジュールは、そのメッセージ識別子をネットワークモジュールのアンレジスタに送信することにより、この種類のメッセージをアンレジスタし得る。従って、サービスモジュールは、対象となるメッセージの種類を動的に構成し得る。

本発明の別の実施形態によると、複数のキューは、第１のキューと第２のキューとを備え、第１のキューに割り当てられるスレッドの数は、第２のキューに割り当てられるスレッドの数と異なる。例えば、第１のキューには、その中のメッセージの同期した取り扱いを可能にするために単一のスレッドが割り当てられ得る一方で、第２のキューには、より高いスループットを可能にするためにより多くのスレッドが割り当てられ得る。

いくつかの実施形態において、サービスモジュールは、複数のキューのうちのキューに割り当てられたスレッドの数を示すための値をネットワークモジュールに送信するようにさらに構成される。

このようにすると、データメッセージのキューイングが各サービスモジュール自体により行われないで場合であっても、サービスモジュールは、依然として、キュー内のデータメッセージの処理性能をカスタマイズするために、ネットワークモジュールにおけるキューのためにスレッドの数を構成することができる。例えば、サービスモジュールは、どの種類のデータメッセージがスレッドプールの単一のスレッドにより取り扱われるか、又は、何らかの他の種類のデータメッセージと共有されるスレッドにより取り扱われるかをカスタマイズし得る。

異なる種類のデータメッセージは、異なるスケジューリング技法で取り扱われる。例えば、位置フィードバックを伝達するいくつかの種類のデータメッセージに関しては、最新のメッセージのみが取り扱われることを必要とするのに対して以前のものはドロップされ得るが、ＥＣＧ信号などの生体信号を伝達するためのデータメッセージなどの何らかの他の種類のデータメッセージの場合、データメッセージはドロップされない。異なるスケジューリング技法を使用して第１のキューと第２のキューとを生成することにより、異なるスケジューリング技法を要求するデータメッセージが別々のキューで適切に取り扱われ得、互いに影響を与えない。

本発明の別の実施形態によると、１つ又は複数のメッセージ識別子が、複数のキューのうちの１つにマッピングされる。

このようにすると、データメッセージの種類ごとに１つのキューを生成する必要がなく、データメッセージの種類の選択されたセットが同じキューを共有し得る。

本発明の別の実施形態によると、ネットワークモジュールは、データフィールドとノード識別子とをプロトコルモジュールに送信するように構成され、ノード識別子は、データフィールドが送信される先の１つ又は複数のノードを示し、プロトコルモジュールは、データフィールドとノード識別子とに基づいて、データメッセージを生成するように構成される。

このようにして、ネットワーク層におけるデータメッセージの送信は、接続指向というよりはノード指向になるように設計される。従来、ネットワーク層におけるデータメッセージの送信は接続指向である。すなわち、サービスモジュールの各ペアの間に接続が確立され、ネットワーク層でノードの各ペアの間に複数の接続が確立される。その結果、多くのデータメッセージが不必要に同期される。提案される解決策では、ネットワーク層におけるデータメッセージの送信はノード指向である。従って、接続の複雑さは呼び出し元から隠される。

本発明の別の実施形態によると、複数のノードが、マスターノードと少なくとも１つのスレーブノードとを備え、ノードのプロトコルモジュールは、接続モジュールとメモリとを備え、マスターノードのメモリは、１つ又は複数のノードの接続情報を記憶するように構成され、ノードの接続情報は、ノードのノード識別子とノードアドレスと接続ステータスとを含み、マスターノードの接続モジュールは、接続制御メッセージをノードから受信するように構成され、接続制御メッセージは、ノードのノードアドレスであって、ネットワーク内で固有であり、動的に規定されるノードアドレスと、ノードのノード識別子であって、ネットワーク内で固有である、ノードのノード識別子とを含み、マスターノードの接続モジュールは、受信された接続制御メッセージに基づいて接続情報を更新するように、及び、接続情報に基づいて接続テーブルを送信するようにさらに構成され、接続テーブルは、ノード識別子とノードアドレスとの間のマッピングを示す。

いくつかの実施形態において、スレーブノードの接続モジュールは、接続制御メッセージを送信するように構成され、スレーブノードの接続モジュールは、接続テーブルをマスターノードから受信するように、及び、接続テーブルに基づいて１つ又は複数のノードの各々への接続を確立するようにさらに構成される。

このようにして、複数のノード間の接続は、各ノードのためのノード識別子及び／又はノードアドレスを事前固定することなく確立され得る。従って、個々のノードの追加及び／又は除去は柔軟であり得、ノードアドレスが動的に構成され得る。

一例において、マスターノードはガントリーホストである。ＣＴシステム又はＰＥＴ−ＣＴシステムなどの撮像システムでは、ガントリーホストが不可欠であり、従って、マスターノードとして機能することに適している。ガントリーホストがない又はガントリーホストがなくてもよい他の撮像システムでは、別のノードが、マスターノードとして機能するように選択され得る。例えば、ＭＲＩシステムでは、勾配増幅器及び／又はＲＦ増幅器のための制御装置が、マスターノードとして機能するように選択され得る。

本発明の別の実施形態によると、マスターノードのプロトコルモジュールは、接続解除イベントハンドリングモジュールをさらに備え、マスターノードの接続モジュールは、ノードの接続ステータスが記憶された接続情報に基づいて接続解除状態になったときに、接続解除イベントを生成し、接続解除イベントハンドリングモジュールに接続解除イベントを送信するようにさらに構成され、マスターノードのメモリは、接続解除イベントと少なくとも１つの動作との間の第３のマッピングを記憶するようにさらに構成され、接続解除イベントハンドリングモジュールは、接続解除イベントを受信し、第３のマッピングに基づいて、接続解除イベントに応答して少なくとも１つの動作を実施するように構成される。

このようにして、マスターノードは、すべての他のノードの接続ステータスを監視することができ、接続障害に対して必要なアクションをとり得る。例えば、例えば支持体を動かすための移動コマンドの実行中に接続障害が発生したとき、移動により発生するあらゆるリスク又は危険を避けるために、そのような移動がすぐに停止される。

本発明の別の実施形態によると、プロトコルモジュール（５１０−Ｍ、５１０−Ｓ）はクロスプラットフォームである。すなわち、プロトコルモジュールは、Ａｎｄｒｏｉｄ、ｉＯＳ、Ｌｉｎｕｘ（登録商標）、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓなどの様々なプラットフォームにわたって適用可能である。例えば、プロトコルモジュールは、Ｇｏｏｇｌｅにより提供されるＺｅｒｏＭＱ及びプロトコルバッファ（ＰＢ：Ｐｒｏｔｏｃｏｌ Ｂｕｆｆｅｒ）をベースとし得る。言い換えると、プロトコルモジュールは、異種混成ネットワークを介して通信を実施するように構成される。

本発明の第２の態様の一実施形態によれば、複数の前述のノードと、複数のノード間における通信のためのネットワークとを備える撮像システムが提案される。

本発明の第３の態様の一実施形態によれば、実行されたときに、ネットワークを通じて撮像システム内の複数のノード間における通信の方法を実施するコンピュータプログラム命令を備えるコンピュータ製品が提案される。本方法は、プロトコル層において、ネットワークを介してデータメッセージを受信するステップと、ネットワーク層において、プロトコルモジュール（５２０）からデータメッセージのデータフィールドを受信するステップであって、データフィールドが、メッセージの種類を示すためのメッセージ識別子（ＭｓｇＩＤ）とペイロードフィールドとを備える、ステップと、メッセージ識別子（ＭｓｇＩＤ）と、メッセージ識別子と複数のキューとの間の第１のマッピングとに基づいて、複数のキューのうちの１つにデータメッセージをディスパッチするステップと、メッセージ識別子（ＭｓｇＩＤ）とコールバックハンドラとの間の第２のマッピングに基づいて、複数のキューの各々にあるデータメッセージを処理するステップであって、各コールバックハンドラが、データメッセージのペイロードを取り扱うためにサービス層のメッセージハンドラに向けられる、ステップと、サービス層において、データメッセージのペイロードを取り扱うステップとを有する。

本発明の他の目的及び利点が、添付図面に関連付けて記載された説明を参照することでより明らかとなり、簡単に理解され得る。

以下、本発明が実施形態とともに図面を参照しながら、さらに詳細に言及及び説明される。

ＣＴ撮像システムなどの従来の撮像システムを示す図である。 本発明の一実施形態に従ったＣＴ撮像システムなどの例示的な撮像システムを示す図である。 本発明の一実施形態に従った撮像システムの複数のノード間における通信のための例示的なソフトウェアアーキテクチャを示す図である。 本発明の一実施形態に従ったプロトコル層の接続を確立する例示的なフローを示す図である。 本発明の一実施形態に従ったノードのプロトコルモジュールとネットワークモジュールとサービスモジュールとを示す図である。 本発明の一実施形態に従ったマスターノードの例示的なプロトコルモジュールと、スレーブノードの例示的なプロトコルモジュールとを示す図である。 本発明の一実施形態に従った例示的なネットワークモジュールと例示的なプロトコルモジュールとのアーキテクチャを示す図である。 本発明の一実施形態に従った少なくとも１つのサービスモジュールを備える例示的なサービス層のアーキテクチャを示す図である。 別の想定される解決策に従ったノードのプロトコル層とネットワーク層とサービス層とを示す図である。 本発明の一実施形態に従ったガントリーホスト又はコンソールなどのサービスを提供するための例示的なノードのアーキテクチャを示す図である。

図中の同じ参照符号は、同様の又は対応する特徴及び／又は機能を示す。

特定の実施形態に関連して、及び特定の図面を参照しながら本発明が説明されるが、本発明はそれに限定されず、特許請求の範囲のみにより限定される。説明される図面は、概略図にすぎず非限定的である。図面において、要素のうちのいくつかの寸法は、例示を目的として誇張される場合があり、一定の縮尺で描かれない場合がある。

図３は、本発明の一実施形態に従った撮像システムの複数のノード間における通信のための例示的なアーキテクチャを示す。図３を参照すると、アーキテクチャは、複数のノード間における通信の基盤として機能する通信基盤３１０を備える。通信基盤は、ノードを接続すること、並びに、メッセージを送信、受信、及びディスパッチすることを担う。通信基盤３１０は、有線又は無線ネットワークを備え得る。通信基盤３１０は、異種混成ネットワーク３１１を備え得る。異種混成ネットワークは、異なるオペレーティングシステム、異なるプロトコル、及び／又は異なるアクセス技術を使用してコンピュータ又は他のデバイスを接続するネットワークとして規定される。本アーキテクチャは、様々なノードに存在するアプリケーションのためのサービスを提供することを担う複数のサービスプロバイダー３２０を備える。例えば、複数のサービスプロバイダー３２０は、セッションマネージャー３２１、移動のためのＩＭｏｖｅｍｅｎｔ３２２、ビーム制限のためのＩＢＬ３２３、ワークフローのためのＩＷｏｒｋｆｌｏｗ３２４、仮想コンポーネント３２５、ハードウェア更新３２６、他の接続点３２７などのうちの１つ又は複数を備え得る。アーキテクチャは、複数のアプリケーション３３０をさらに備え、各アプリケーション３３０は、サービスを提供するために、及び／又はサービスにアクセスするためのユーザーインターフェースとして機能するために、特定のノードにおいて動作する。複数のアプリケーション３３０は、コンソール３３１、ガントリーホスト３３２、及び、左パネル３３３、右パネル３３４、及びＣＴボックス３３５などの様々なパネルのうちの１つ又は複数を備え得る。例えば、コンソール３３１は、ＩＷｏｒｋｆｌｏｗ３２４などのサービスを提供し得、ガントリーホスト３３２は、ＩＭｏｖｅｍｅｎｔ３２３及びＩＢＬ３２５などの移動サービスを提供し得、左パネル３３１及び右パネル３３２は、オペレーターがコンソール３３１及びガントリーホスト３３２により提供されるサービスなどのサービスにアクセスすることを可能にする。複数のアプリケーション３３０は、ａｎｄｒｏｉｄ、ｉＯＳ、Ｌｉｎｕｘ（登録商標）、及びＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓなどの異なるオペレーティングシステムに基づき得る。ＣＴシステムなどのいくつかの撮像システムでは、ガントリーホスト３３２が不可欠であるのに対して、左パネル３３３、右パネル３３４などの他のアプリケーション３３０は任意選択的である。

図５は、本発明の一実施形態に従ったノード５００のプロトコルモジュール５１０−Ｍ、５１０−Ｓ、ネットワークモジュール５２０、及び少なくとも１つのサービスモジュール５３０−１、…、５３０−ｎを示す。図４は、本発明の一実施形態に従ったプロトコル層の接続を確立する例示的なフローを示す。図６は、本発明の一実施形態に従った、スレーブノード６１０のプロトコルモジュール６１２及びネットワークモジュール６１４、並びに、マスターノード６２０との対話を示す。

図５を参照すると、各ノード５００は、それがマスターノードであるか否かに応じてプロトコルモジュール５１０−Ｍ又は５１０−Ｓを備え、さらに、ネットワークモジュール５２０、及び１つ又は複数のサービスモジュール５３０−１から５３０−ｎを備える。

マスターノードのプロトコルモジュール５１０−Ｍは、接続モジュール５１２−Ｍとメモリ５１６−Ｍとを備える。スレーブノードのプロトコルモジュール５１０−Ｓは、接続モジュール５１２−Ｓとメモリ５１６−Ｓとを備える。

マスターノードのメモリ５１６−Ｍは、１つ又は複数のノードの接続情報を記憶するように構成される。ノードの接続情報は、ノードのノード識別子とノードアドレスと接続ステータスとを含む。ノード識別子は、ノードを一意に識別するためのノードの名前又は任意の値であり得る。ノードアドレスは、通信ネットワークからノードにアクセスできる任意のアドレスであり得る。一実施形態において、ノードの接続情報を記憶するためのデータ構造体「ＮｏｄｅＩｎｆｏ」は、次に示すように、ＩＰアドレス「ｉｐＡｄｄｒｅｓｓ」、任意選択的なＭＡＣアドレス「ＭＡＣ」、ノード識別子「ｒｏｌｅＴｙｐｅ」、接続ステータス「ｉｓＯｎｌｉｎｅ」、及び、ノードから最新の接続制御メッセージを受信した時点を示すための任意選択的なタイムスタンプ「ｌａｓｔＴｉｍｅ」を含み得る。

マスターノードの接続モジュール５１２−Ｍは、接続制御メッセージをノードから受信するように構成される。接続制御メッセージは、ノードのノードアドレスとノード識別子とを含む。マスターノードの接続モジュール５１２−Ｍは、受信された接続制御メッセージに基づいて、接続情報を更新するように構成される。マスターノードの接続モジュール５１２−Ｍは、接続情報に基づいて、接続テーブルを生成するように、及び、好ましくは事前に規定された時間間隔で、例えば３秒ごとに、すべてのノードに接続テーブルをパブリッシュするようにさらに構成される。一例において、接続テーブルは、すべてのオンラインノードのノード識別子とノードアドレスとの間のマッピングを示す。別の一例において、接続テーブルは、すべてのノードのノード識別子とノードアドレスとオンラインステータスとの間のマッピングを示す。各スレーブノードがマスターノードから接続テーブルを受信した後、各スレーブノードは、接続テーブル中のノードアドレスを使用することにより、そのスレーブノード自体と接続テーブル内のノードとの間における接続を確立することができる。さらに、スレーブノードは、ノードのオンラインステータスを確認するように、及び、ノードがオフラインになった場合に１つ又は複数の所定のアクションをとるようにさらに構成され得る。一実施形態によると、スレーブノードの接続モジュール５１２−Ｓは、接続制御メッセージを送信するように構成される。接続制御メッセージは、スレーブノードのノードアドレスの変化などのスレーブノードのステータスを適時マスターノードに知らせるために、定期的に、例えば１秒ごとに、スレーブノードにより送信され得る。スレーブノードの接続モジュール５１２−Ｓは、接続テーブルをマスターノードから受信するように、及び、接続テーブルに基づいて、１つ又は複数のノードの各々への接続を確立するようにさらに構成される。スレーブノードのメモリ５１６−Ｓは、それ自体のノード識別子、それ自体のノードアドレス、及び確立された接続を記憶するように構成され得る。

いくつかの実施形態において、マスターノードのプロトコルモジュール５１０−Ｍは、接続解除イベントハンドリングモジュール５１４−Ｍをさらに備える。マスターノードの接続モジュール５１２−Ｍは、ノードの接続ステータスが記憶された接続情報に基づいて接続解除状態になったときに、接続解除イベントを生成するように、及び、接続解除イベントハンドリングモジュール５１４−Ｍに接続解除イベントを送信するようにさらに構成される。マスターノードのメモリ５１６−Ｍは、接続解除イベントと少なくとも１つの動作との間の第３のマッピングを記憶するようにさらに構成される。接続解除イベントハンドリングモジュール５１４−Ｍは、接続解除イベントを受信するように、及び、第３のマッピングに基づいて、接続解除イベントに応答して少なくとも１つの動作を実施するように構成される。

次に、図４を参照して、一実施形態に従ったマスターノード４１０のプロトコルモジュールと、スレーブノード４２０のプロトコルモジュールと、その間における相互接続とが説明される。

ステップ４２２において、スレーブノード４２０は、マスターノード４１０に接続制御メッセージ４３２を送信する。スレーブノード４２０から接続制御メッセージ４３２を受信した後、マスターノード４１０は、ステップ４１２において、記憶された接続情報４４０を更新する。接続情報４４０は、ハッシュマップに記憶され得る。特に、ステップ４１２０において、マスターノード４１０は、記憶された接続情報にノード４２０が存在するか否かを確認する。マスターノード４１０に以前に知られていない新しいノードなど、記憶された接続情報４４０にノード４２０が存在しない場合、マスターノード４１０は、ステップ４１２２において、ノード識別子と、接続制御メッセージ４３２からのノードのノードアドレスと、任意選択的に接続制御メッセージ４３２の受信時点とを記憶することを含め、受信された接続制御メッセージに基づいて、記憶されたハッシュマップ４４０にスレーブノード４２０のための新しいエントリーを生成し得る。ノード４２０がハッシュマップ４４０などの記憶された接続情報に既に存在する場合、マスターノード４１０は、ステップ４１２４において、変化が存在する場合にノードアドレスを更新すること、及び、接続制御メッセージ４３２の受信時点を記録することなど、接続制御メッセージに基づいてノード４２０のためのエントリーを更新することを行い得る。スレーブノードから接続制御メッセージを受信した後、マスターノード４１０は、ｉｓＯｎｌｉｎｅをｔｒｕｅに設定するなど、スレーブノードのステータスをオンラインに設定する。

マスターノード４１０は、接続テーブル４３４をパブリッシュするように構成され得る。接続テーブル４３４は、すべてのオンラインノードのためのノード識別子とノードアドレスとの第３のマッピングを含み得る。接続テーブル４３４を受信した後、スレーブノード４２０は、ステップ４２４において、接続テーブルに基づいて１つ又は複数の接続を確立又は再確立し得る。特に、ステップ４２４０において、スレーブノード４２０は、スレーブノード４２０自体とオンラインノードとの間における接続が既に確立されたか否かを確認し得る。まだ確立されていない場合、スレーブノード４２０は、例えばメソッド「ｎｏｄｅＥｎｔｅｒ（ＮｏｄｅＩｎｆｏ ｎｏｄｅ）」を呼び出すために、そのオンラインノードのノード識別子とノードアドレスとに基づいて、スレーブノード４２０自体とオンラインノードとの間における接続を確立し得る。スレーブノードのプロトコルモジュールは、メソッド「ｎｏｄｅＥｎｔｅｒ（ＮｏｄｅＩｎｆｏ ｎｏｄｅ）」が呼び出されたときに、ポート及びサービス構成により接続を確立するように構成され得る。

図４を参照すると、マスターノード４１０は、ステップ４１４において、各ノードの接続ステータスを監視するようにさらに構成され得る。一実施形態において、マスターノード４１０が所定の期間にわたってスレーブノードから接続制御メッセージを一切受信しなかった場合、マスターノード４１０は、例えば設定ｉｓ Ｏｎｌｉｎｅがｆａｌｓｅに設定されるなど、スレーブノードのステータスをオフラインに設定する。ノードの接続ステータスがオフラインとなったことがステップ４１４０において検出された後、マスターノード４１０は、接続解除イベントを生成し、ステップ４１４２において、接続解除イベントに応答して、少なくとも１つの動作を実施する。例えば、スレーブがオフラインであるときには、支持体の移動は危険であり、できる限り迅速に停止されなければならない。

さらに、接続解除イベントは、他の手段により、例えば、物理的なリンクのステータスを監視することにより生成され得る。例えば、ＺｅｒｏＭＱネットワークモニターは、アイドル状態のネットワークを十分に使用するために、ステップ４１４４において、ソケット接続を確認して、確立された接続の接続解除を検出したときに接続解除イベントを送信するために使用され得る。

ノードのプロトコルモジュール５１０−Ｍ、５１０−Ｓは、ネットワークを介してデータメッセージを送信及び受信するようにさらに構成される。いくつかの実施形態において、ノードのプロトコルモジュール５１０−Ｍ、５１０−Ｓは、次の２つのメソッド、すなわち「ｉｒｅｑ （）」と「ｉｐｕｂ （）」とのうちの１つによりデータメッセージを送信するように構成され得る。メソッド「ｉｒｅｑ （）」は、応答を要求するメッセージを送信するために使用され、メソッド「ｉｐｕｂ （）」は、１つ又は複数のノードにメッセージを送信するために使用され、応答は要求されない。データメッセージが受信された後、プロトコル層は、受信されたデータメッセージのデータフィールドをネットワークモジュール５２０に、及び、いくつかの実施形態において、ネットワークモジュール５２０のディスパッチャ５２１に送達する。

本発明の一実施形態によると、プロトコルモジュール５１０のインターフェースは、次のように規定される。

図５を再度参照すると、ネットワークモジュール５２０は、ディスパッチャ５２１と複数のキュー５２３とコールバックモジュール５２２とメモリ５２４とを備える。メモリ５２４は、メッセージ識別子と複数のキューとの間の第１のマッピングと、メッセージ識別子ＭｓｇＩＤとコールバックハンドラとの間の第２のマッピングとを記憶する。ディスパッチャ５２１は、メッセージ識別子ＭｓｇＩＤと第１のマッピングとに基づいて、複数のキュー５２３のうちの１つにデータメッセージをディスパッチするように構成され、コールバックモジュール５２２は、第２のマッピングに基づいて、複数のキューの各々にあるデータメッセージを処理するように構成される。各コールバックハンドラは、サービスモジュールにおけるメッセージハンドラに向けられる。複数のキュー５２３が、初期化中に生成され得、及び／又は、動的に生成され得る。いくつかの実施形態によれば、キューとメッセージ識別子との間のマッピングは、１対１の又は１対多であり得、コールバックハンドラとメッセージ識別子との間のマッピングは、１対１である。

本発明の一実施形態によれば、ディスパッチャ５２１の疑似コードは、次のように説明され得る。

いくつかの実施形態に従って、１つ又は複数のメッセージ識別子は、複数のキューのうちの１つにマッピングされる。言い換えると、１つ又は複数の種類のデータメッセージがメッセージグループにグループ化され、同じメッセージグループのデータメッセージが同じキューにディスパッチされる。表１は、例示的な第１のマッピングを示す。５つのメッセージグループが表１に示されるが、他の実施形態においては必要に応じてより多くの又はより少ないメッセージグループが規定され得る。

１つのメッセージグループ「移動コマンド」は、例えば、ガントリーの目標傾倒角度を伝達するための種類のメッセージ、対象者支持体の目標水平位置及び／又は目標垂直位置を伝達するための種類のメッセージなどを含む、移動コマンドを伝達する種類のメッセージのためのものである。このグループ内のすべてのメッセージが、キュー「ｍｏｖｅｍｅｎｔ＿ｃｍｄ」にディスパッチされる。１つのメッセージグループ「位置フィードバック」は、例えば、現在の傾倒角度などのガントリー１０４の現在位置を伝達するための種類のメッセージ、対象者支持体１０８の現在位置を伝達するための種類のメッセージなどを含む、位置フィードバックを伝達する種類のメッセージのためのものである。このグループ内のすべてのメッセージは、キュー「ｍｏｖｅｍｅｎｔ＿ｐｆ」にディスパッチされる。１つのメッセージグループ「ＥＣＧデータ」は、ＥＣＧデータを伝達する種類のメッセージである。このグループ内のすべてのメッセージは、キュー「ｍｏｖｅｍｅｎｔ＿ｅｃｇ」にディスパッチされる。１つのメッセージグループ「ワークフローコマンド」は、例えば、患者登録簿のための種類のメッセージ、配向選択のための種類のメッセージ、検査カード選択のための種類のメッセージなどを含む、ワークフローコマンドを伝達する種類のメッセージである。このグループ内のすべてのメッセージは、キュー「ｗｏｒｋｆｌｏｗ＿ｗｆ」にディスパッチされる。１つのメッセージグループ「患者リスト」は、患者リストを伝達する種類のメッセージのためのものである。このグループ内のすべてのメッセージは、キュー「ｗｏｒｋｆｌｏｗ＿ｐａｔｉｅｎｔ ｌｉｓｔ」にディスパッチされる。

異なるキューは、異なるスケジューリング技法、異なるキューイング／デキューイングポリシー、及び／又は異なる数のスレッドを使用してもよい。一実施形態において、キュー「ｍｏｖｅｍｅｎｔ＿ｐｆ」の場合、キュー内のメッセージは、リアルタイムで取り扱われる。すなわち、コールバックモジュール５２２は、対応するコールバックハンドラを呼び出して、リアルタイムでメッセージを取り扱う。しかし、最新のメッセージが最も新しく更新された位置フィードバックを伝達するので、最新のメッセージのみが取り扱われることを必要とするのに対して、以前のものはドロップされ得る。一実施形態において、キュー「ｍｏｖｅｍｅｎｔ＿ｅｃｇ」の場合、キュー内のメッセージは、リアルタイムで逐次取り扱われ、ＥＣＧデータの完全な集合が要求されるので、どのメッセージもドロップされない。一例において、ドロップされるメッセージは、ネットワークモジュールによりドロップされ、代替的には、ドロップされるメッセージは、サービス層又はアプリケーション層に渡されて、次にそこでドロップされ得る。一実施形態において、キュー「ｍｏｖｅｍｅｎｔ＿ｍｓ」及びキュー「ｗｏｒｋｆｌｏｗ＿ｗｆ」の各々の場合、メッセージは、メッセージ間のコンフリクトを避けるために、単一のスレッドにより同期された手法で取り扱われることを必要とする。例えば、対象者支持体を水平に動かすことなどの移動コマンドが、同じ種類の移動コマンドが実行されているときに来た場合、後のコマンドは、以前のコマンドが完了となるまで実行されない。一実施形態において、キュー「ｗｏｒｋｆｌｏｗ＿ｐａｔｉｅｎｔ ｌｉｓｔ」の場合、データの量が大きく、メッセージが取り扱いに比較的長い時間を必要とするので、メッセージは他の種類のメッセージと共有されずに別々のタスクキュー内で取り扱われる。

ネットワークモジュール５２０は、レジスタ５２５をさらに備え得る。レジスタ５２５は、メッセージ識別子ＭｓｇＩＤと、メッセージ識別子をもつデータメッセージが経路設定される先となる複数のキューのうちの１つを示すためのキューアイデンティティ値と、メッセージ識別子をもつデータメッセージを取り扱うためのメッセージハンドラに向けられたコールバックハンドラとをサービスモジュールから受信するように、及び、受信されたメッセージ識別子とキューアイデンティティ値とコールバックハンドラとに基づいて、第１のマッピングと第２のマッピングとを更新するように構成される。特に、メッセージ識別子とキューアイデンティティ値との間のマッピングを生成するために、第１のマッピング内に新しいエントリーが生成され得、メッセージ識別子とコールバックハンドラとの間のマッピングを生成するために、第２のマッピング内に新しいエントリーが生成され得る。複数のキュー５２３が動的に生成され得るいくつかの実施形態において、レジスタユニット５２５は、受信されたキュー名をもつキューが存在するか否かを確認し、存在しない場合は、受信されたキュー名をもつキューを生成するようにさらに構成され得る。

本発明の一実施形態によると、レジスタ５２５の疑似コードは、次のように説明され得る。

いくつかの実施形態において、レジスタ５２５は、キューのためのスレッドプールの数を設定するようにさらに構成される。一例において、キュー内のデータメッセージが同期して取り扱える場合、キューのためのスレッドプールの数は１に設定され得る。別の一例において、キュー内のデータメッセージが非同期で取り扱える場合、キューのためのスレッドプールの数は２以上に設定され得る。この場合、レジスタ５２５は、例えば、次のメソッドにより、キューに割り当てられたスレッドプールの数を示すための値をサービスモジュール５３０から受信するようにさらに構成される。
ｖｏｉｄ ｒｅｇｉｓｔｅｒ（ｉｎｔ ｍｓｇＩＤ， Ｓｔｒｉｎｇ ｑｕｅｕｅＮａｍｅ， ｉｎｔ ｔｈｒｅａｄＮｕｍｂｅｒ， ＩＮｅｔＢａｓｉｓＣａｌｌｂａｃｋ ｃａｌｌｂａｃｋ）；

ネットワークモジュール５２０は、アンレジスタ５２６をさらに備え得る。アンレジスタ５２６は、メッセージ識別子ＭｓｇＩＤをサービスモジュールから受信するように、及び、受信されたメッセージ識別子に基づいて、第１のマッピングと第２のマッピングとを更新するように構成される。特に、受信されたメッセージ識別子に関係するマッピングは、第１マッピングと第２のマッピングとから除去される。レジスタ５２５を呼び出すことにより、サービスモジュールは、対象のメッセージを追加し得、アンレジスタ５２６を呼び出すことにより、サービスモジュールは、もはや対象とならないメッセージを除去し得る。従って、サービスモジュールは、いずれのソースコードも変化させる必要なく、その対象のメッセージを動的に変更することができる。

本発明の一実施形態に従った、アンレジスタ５２６の疑似コードは、次のように説明され得る。

図７は、本発明の一実施形態に従った例示的なネットワークモジュール７２０及び例示的なプロトコルモジュール７１０のアーキテクチャを示す。図７を参照すると、下から上に向かう方向において、ネットワークモジュール７２０が下層すなわちプロトコル層７１０からメッセージを受信し、受信されたメッセージをディスパッチし、次に、受信されたメッセージを、コールバックハンドラを介してより高い層すなわちサービス層により取り扱われるように渡す。上から下に向かう方向において、ネットワークモジュール７２０がより高い層からメッセージを、すなわちサービス層から、他のノードに送信される様々な種類のメッセージを受信し、プロトコル層７１０にこれらのメッセージを送信する。サービス層から受信されたメッセージは、ｉＳｅｓｓｉｏｎ、ｉＮｅｔｗｏｒｋ、ＰＢ（ビーム位置決め、ｐｏｓｉｔｉｏｎ ｂｅａｍ）、ＢＬ（ビーム制限、ｂｅａｍ ｌｉｍｉｔａｔｉｏｎ）などの、様々なサービスのためのメッセージを含む。

本発明の一実施形態によると、ネットワークモジュールのインターフェースは、次のように規定され得る。

図５を再度参照すると、ノード５００は、少なくとも１つのサービスモジュール５３０−１、…、５３０−ｎを備える。各サービスモジュールは、データメッセージのペイロードを取り扱うための少なくとも１つのメッセージハンドラ５３２を備える。各メッセージハンドラ５３２は、メッセージハンドラ５３２のエンターアドレスに向けられた対応するコールバックハンドラによりネットワークモジュールにより呼び出され得る。

図８は、本発明の一実施形態に従った少なくとも１つのサービスモジュールを備える例示的なサービス層８００のアーキテクチャを示す。２つのサービスモジュール、すなわちワークフローサービスのための１つのサービスモジュール８１０と、移動サービスのための他方のサービスモジュール８２０とが図８に示されるが、より多くの又はより少ないサービスモジュールが構成に使用され得る。一実施形態によると、サービスモジュールは、Ａｎｄｒｏｉｄにおける遠隔サービスコンポーネント、或いは、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ又は任意の他の適切なオペレーティングシステムにおけるＣＯＭコンポーネントを介して実施され得る。

いくつかの実施形態において、サービスモジュールは、単一のサービスのメッセージを取り扱うように、又は複数のサービスのメッセージを取り扱うように構成され得る。例えば、ビーム位置を制御するためのサービス、及びビーム制限のためのサービスは両方とも同じノード、すなわちガントリーホストにより提供され、したがって、これらの２つのサービスのためのメッセージは、１つのサービスモジュールにおいて取り扱われるように設計され得る。

いくつかの実施形態において、サービスは、１つのノードにより提供又は実行されるが、２つ以上のノードによりアクセスされ得る。例えば、走査フローを制御するためのサービスは、コンソールにより提供されるが、左パネル、右パネル、及び操作ボックスなどの異なるノードによりアクセスされ得る。同じサービスにアクセスするための異なるノードのサービスモジュールは、同じであり得るか、又は異なり得る。一実施形態において、同じサービスにアクセスするための異なるノードのサービスモジュール間において、メッセージＩＤテーブルは同じであり得、日付型は同じであり得るが、同じ種類のメッセージを取り扱うためのメッセージハンドラは異なり得る。

サービスモジュールのメッセージハンドラは、メッセージを処理することと、アプリケーション層などの上層にメッセージを渡すこととを担う。いくつかの実施形態において、メッセージハンドラは、１つのメッセージをアプリケーション層における２つ以上のアプリケーションに渡すように構成され得る。

図１０は、本発明の一実施形態に従ったガントリーホスト又はコンソールなどの、サービスを提供するための例示的なノードのソフトウェアアーキテクチャを示す。示されるアーキテクチャは、プロトコル、ネットワーク、並びにサービス層１０１０及びアプリケーション層１０２０を備える。アプリケーション層１０２０は、サービスを提供するためのビジネスプラットフォーム１０２４と、他のノードがその提供されるサービスにアクセスすることを可能にするプラグイン１０２２とを備える。

いくつかの実施形態において、複数のノードのうちのいくつかは、コンソール及びガントリーホストなどのサービスを提供するように構成される（以下、ビジネスノードと呼ばれる）。ビジネスノードは主に、応答サーバ及びパブリッシュサーバとして機能する。図１０を参照すると、ビジネスノードの場合、ビジネスノードは、主にインターフェース「ｒｅｓ （）」を介してメッセージを受信し、インターフェース「ｐｕｂ （）」を介してメッセージを送信する。応答サーバは、マルチワーカーモードにより実施されなければならず、サービスプロバイダーは、対象のコマンドを記録し、対象のコマンドを並列に取り扱う。

図１０を参照すると、プラグイン１０２２は、コマンドハンドラ、状態機械、いくつかのステータステーブル、ステータスモニター、及びデータパブリッシャを備え得る。

異なるノードのためのステータステーブルは異なり得る。例えば、移動制御サービスを提供するガントリーホストにおいて、ステータステーブルは、移動軸のためのステータス値、接続のためのステータス値、及び／又は、位置フィードバックのためのステータス値を含み得る。例えば、ワークフローサービスを提供するコンソールでは、ステータステーブルは、走査フローのためのステータス値を含み得る。

モニターは、タイマーを始動させて、３秒ごとなどの所定の時間間隔にわたってそのスレーブノードに対するすべてのステータステーブルを更新するスレッドである。ガントリーホストにおいて、モニターは、物理的な接続のオンラインステータスを確認するように、及び、特定の接続がオフラインになった場合、進行中の移動を停止するようにさらに構成され得る。コンソールにおいて、モニターは、プロシージャデータが適時にパブリッシュされることを確実にし得る。

本明細書において説明される技術的な処理は、様々な手段により実施される。例えば、これらの技術は、ハードウェア、ソフトウェア、又はハードウェアとソフトウェアとの組み合わせにおいて実施される。ハードウェアにより実施する場合、処理ユニットは、１つ又は複数の特定用途向け集積回路（ＡＳＩＣ：ａｐｐｌｉｃａｔｉｏｎ ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ）、デジタル信号プロセッサ（ＤＳＰ：ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ）、デジタル信号処理デバイス（ＤＳＰＤ：ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｉｎｇ ｄｅｖｉｃｅ）、プログラム可能論理デバイス（ＰＬＤ：ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｄｅｖｉｃｅ）、フィールドプログラム可能ゲートアレイ（ＦＰＧＡ：ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）、プロセッサ、制御装置、マイクロ制御装置、マイクロプロセッサ、本明細書において説明される機能を実施するように設計された他の電子ユニット、又はそれらの組み合わせにおいて実施される。ソフトウェアを使用する場合、実施は本明細書において説明される機能を実施するモジュール（例えば、プロシージャ、関数など）を通して行われ得る。ソフトウェアコードは、メモリユニットに記憶され、プロセッサにより実行される。

さらに、請求項に記載された主題の態様は、請求項に記載された主題の様々な態様を実施するためのコンピュータ又はコンピューティングコンポーネントを制御するためのソフトウェア、ファームウェア、ハードウェア、又はそれらの任意の組み合わせを製造するための標準的なプログラミング及び／又はエンジニアリング技術を使用した方法、装置、システム、又は製品として実装される。本明細書において使用される「製品」という用語は、任意のコンピュータ可読デバイス、キャリア、又は媒体からアクセス可能なコンピュータプログラムを包含するように意図される。例えば、コンピュータ可読媒体は、限定されないが、磁気記憶デバイス（例えば、ハードディスク、フロッピーディスク、磁気ストリップ…）、光ディスク（例えば、コンパクトディスク（ＣＤ：ｃｏｍｐａｃｔ ｄｉｓｋ）、デジタル多用途ディスク（ＤＶＤ：ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｓｋ）…）、スマートカード、及びフラッシュメモリデバイス（例えば、カード、スタック、キードライブ…）を含み得る。もちろん、当業者は、本明細書において説明される範囲又は趣旨から逸脱することなく、この構成に多くの変形がなされることを認識する。

本出願において使用される場合、プロトコルモジュール、ネットワークモジュール、サービスモジュール、コールバックモジュール、接続モジュール、接続解除イベントハンドリングモジュールなどの「モジュール」、「ディスパッチャ」、「キュー」、「レジスタ」、「アンレジスタ」、「剪断波ディテクター」などの「推定器」、「性質推定器」及び「撮像符号化器」という用語は、プロセッサ又はコンピュータに関係するエンティティ、ハードウェア、ハードウェアとソフトウェアとの組み合わせ、ソフトウェア、又は実行中のソフトウェアを表すことが意図されるが、特に、それらの用語は、ソフトウェア、又は実行中のソフトウェアを表す。例えば、コンポーネントは、限定されないが、プロセッサ上で動作するプロセス、プロセッサ、オブジェクト、エグゼキュータブル、実行のスレッド、プログラム、及び／又はコンピュータである。例示として、サーバ上で動作するアプリケーションとサーバとの両方が、コンポーネントであり得る。１つ又は複数のコンポーネントは、実行のプロセス及び／又はスレッド内に存在し、コンポーネントは、１つのコンピュータに局在するか、及び／又は、２つ以上のコンピュータ間に分散される。

ここまでに説明されていることは、１つ又は複数の実施形態の例を含む、もちろん、前述の実施形態を説明することを目的としてコンポーネント又は方法の考えられるすべての組み合わせを説明することは不可能であるが、当業者は様々な実施形態の多くのさらなる組み合わせ及び順列が可能であることを認識する。従って、説明される実施形態は、添付の請求項の趣旨及び範囲内に入るすべてのこのような代替例、変更例、及び変形例を包含することが意図される。さらに、「含む」という用語が詳細な説明又は特許請求の範囲において使用される限りにおいて、「含む」という用語は、請求項において移行句として使用されるときに「備える」が解釈されるのと同様に、「備える」という用語と同様の手法で非排他的であることが意図される。

Claims (15)

1. 撮像システムにおける複数のノードのうちのノードであって、前記撮像システムは、前記撮像システムにおける前記複数のノード間における通信のためのネットワークを備え、前記ノードは、
   前記ネットワークを介してデータメッセージを受信するためのプロトコルモジュールと、
   前記プロトコルモジュールから前記データメッセージのデータフィールドを受信するためのネットワークモジュールと、
   少なくとも１つのサービスモジュールと、を備え、
   前記データフィールドは、前記データメッセージの種類を示すメッセージ識別子と、ペイロードフィールドとを備え、
   各サービスモジュールは、前記データメッセージのペイロードを取り扱う少なくとも１つのメッセージハンドラを備え、
   前記ネットワークモジュールは、ディスパッチャと、複数のキューと、コールバックモジュールと、前記メッセージ識別子と前記複数のキューとの間の第１のマッピング及び前記メッセージ識別子とコールバックハンドラとの間の第２のマッピングを記憶するためのメモリと、を備え、
   前記ディスパッチャは、前記メッセージ識別子と前記第１のマッピングとに基づいて前記複数のキューのうちの１つに前記データメッセージをディスパッチし、
   前記コールバックモジュールは、前記第２のマッピングに基づいて前記複数のキューの各々にある前記データメッセージを処理し、前記各コールバックハンドラは、前記サービスモジュールにおける前記メッセージハンドラに向けられる、
   ノード。
2. 前記ネットワークモジュールは、
   前記メッセージ識別子と、前記メッセージ識別子をもつ前記データメッセージがディスパッチされる先となる前記複数のキューのうちの１つを示すためのキューアイデンティティ値と、前記メッセージ識別子をもつ前記データメッセージを取り扱うための前記サービスモジュールの前記メッセージハンドラに向けられた前記コールバックハンドラとを前記サービスモジュールから受信し、
   受信された前記メッセージ識別子、受信された前記キューアイデンティティ値、及び受信された前記コールバックハンドラに基づいて、前記第１のマッピングと前記第２のマッピングとを更新する、
   レジスタをさらに備える、請求項１に記載のノード。
3. 前記サービスモジュールは、さらに、前記メッセージ識別子と、前記メッセージ識別子をもつ前記データメッセージがディスパッチされる先となる前記複数のキューのうちの１つを示すための前記キューアイデンティティ値と、コンフィギュレーションデータに基づいて、前記メッセージ識別子をもつ前記データメッセージを取り扱うための前記サービスモジュールの前記メッセージハンドラに向けられた前記コールバックハンドラとを生成する、請求項２に記載のノード。
4. 前記ネットワークモジュールは、さらに、
   前記メッセージ識別子を前記サービスモジュールのために受信し、
   前記受信されたメッセージ識別子に対応した前記マッピングを除去することにより、前記受信されたメッセージ識別子に基づいて前記第１のマッピングと前記第２のマッピングとを更新する、
   アンレジスタを備える、請求項２に記載のノード。
5. 前記複数のキューは、第１のキューと第２のキューとを備え、前記第１のキューに割り当てられるスレッドの数は、前記第２のキューに割り当てられるスレッドの数と異なる、請求項１に記載のノード。
6. 前記サービスモジュールは、さらに、前記複数のキューのうちのキューに割り当てられたスレッドの数を示すための値を前記ネットワークモジュールに送信する、請求項５に記載のノード。
7. 前記１つ又は複数のメッセージ識別子が、前記複数のキューのうちの１つにマッピングされる、請求項１に記載のノード。
8. 前記ネットワークモジュールは、前記データフィールドとノード識別子とを前記プロトコルモジュールに送信し、前記ノード識別子は、前記データフィールドが送信される先の１つ又は複数のノードを示し、
   前記プロトコルモジュールは、前記データフィールドと前記ノード識別子とに基づいて、前記データメッセージを生成する、
   請求項１に記載のノード。
9. 前記複数のノードが、マスターノードと少なくとも１つのスレーブノードとを備え、
   前記ノードの前記プロトコルモジュールは、接続モジュールとメモリとを備え、
   前記マスターノードの前記メモリは、前記１つ又は複数のノードの接続情報を記憶し、前記ノードの前記接続情報は、前記ノードのノード識別子とノードアドレスと接続ステータスとを含み、
   前記マスターノードの前記接続モジュールは、接続制御メッセージを前記ノードから受信し、前記接続制御メッセージは、
   前記ノードの前記ノードアドレスであって、ネットワーク内で固有であり、動的に規定される前記ノードアドレスと、
   前記ノードの前記ノード識別子であって、前記ネットワーク内で固有である、前記ノードの前記ノード識別子とを含み、
   前記マスターノードの前記接続モジュールは、前記受信された接続制御メッセージに基づいて前記接続情報を更新するように、及び、前記接続情報に基づいて接続テーブルをさらに送信し、前記接続テーブルは、前記ノード識別子と前記ノードアドレスとの間のマッピングを示す、
   請求項１に記載のノード。
10. 前記マスターノードはガントリーホストである、請求項９に記載のノード。
11. 前記マスターノードの前記プロトコルモジュールは、接続解除イベントハンドリングモジュールをさらに備え、
    前記マスターノードの前記接続モジュールは、さらに、前記ノードの前記接続ステータスが記憶された前記接続情報に基づいて接続解除状態になったときに、接続解除イベントを生成し、前記接続解除イベントハンドリングモジュールに前記接続解除イベントを送信し、
    前記マスターノードの前記メモリは、前記接続解除イベントと少なくとも１つの動作との間の第３のマッピングをさらに記憶し、
    前記接続解除イベントハンドリングモジュールは、前記接続解除イベントを受信し、前記第３のマッピングに基づいて、前記接続解除イベントに応答して少なくとも１つの動作を実施する、
    請求項９に記載のノード。
12. 前記スレーブノードの前記接続モジュールは、接続制御メッセージを送信し、
    前記スレーブノードの前記接続モジュールは、前記接続テーブルを前記マスターノードから受信し、前記接続テーブルに基づいて前記１つ又は複数のノードの各々への接続をさらに確立する、
    請求項９に記載のノード。
13. 前記プロトコルモジュールはクロスプラットフォームである、請求項１に記載のノード。
14. 請求項１に記載の複数のノードと、
    前記複数のノード間における通信のためのネットワークとを備える、
    撮像システム。
15. 実行されたときに、ネットワークを通じて撮像システム内の複数のノード間における通信の方法を実施するコンピュータプログラム命令を備えるコンピュータ製品であって、前記方法は、
    プロトコル層において、
    前記ネットワークを介してデータメッセージを受信するステップと、
    ネットワーク層において、
    前記データメッセージのデータフィールドを受信するステップであって、前記データフィールドが、メッセージの種類を示すためのメッセージ識別子とペイロードフィールドとを備える、ステップと、
    前記メッセージ識別子と、前記メッセージ識別子と前記複数のキューとの間の第１のマッピングとに基づいて、複数のキューのうちの１つに前記データメッセージをディスパッチするステップと、
    前記メッセージ識別子とコールバックハンドラとの間の第２のマッピングに基づいて、前記複数のキューの各々にある前記データメッセージを処理するステップであって、前記各コールバックハンドラが、前記データメッセージのペイロードを取り扱うためにサービス層のメッセージハンドラに向けられる、ステップと、
    前記サービス層において、
    前記データメッセージの前記ペイロードを取り扱うステップとを有する、
    コンピュータ製品。
    

Images