説明

診断ネットワークシステム

【課題】医用モダリティなどのモニタ・保守(点検)および修理を高信頼性をもって低コストで行なうことができ、トラブル発生時に問題解決策をユーザやサービスエンジニアに提供する。
【解決手段】診断ネットワークシステム10は、複数の分散形試験ユニット12と、マスタ分散形試験ユニット34と、通信媒体で相互に接続して情報の伝達を可能にしたネットワーク13と、複数の分散形試験ユニット12と通信を行うシステムモニタユニット16とを備える。システムモニタユニット16は、動作情報に関する情報を基に編集された編集情報データベースと、収集された情報を解析して複数のデバイスについて点検修理が必要か否かを常時、判定する手段と、ユーザインタフェース18との通信に応じて点検修理が必要なデバイスについてトラブルシューティングを行うのに必要なツール及び点検修理の処理手順を示す手段を有する診断ユニットと、を備えたものである。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、多数の異なったモジュール装置が互いに接続されて特定の機能を有するモダリティ(例えば血管X線イメージングシステム、MRI(磁気共鳴イメージング)システム、X線CTスキャナ、核医学診断装置、生体磁場計測装置など)などの対象システムのモニタ、保守(点検)、および修理を含む診断(試験、検査、管理)の手法に関する。
【背景技術】
【0002】
従来、この種のモジュール化システムの一例として、種々の医用モダリティが挙げられる。例えば、医用モダリティとしての血管X線イメージングシステムの場合、その典型的な構成として、患者テーブル、オペレータコンソール、コントロールパネル、および高電圧変圧器をモジュール装置として備え、これらのモジュール装置が電気的に接続されている。これにより、全体として、患者の血管イメージングを行うことができるようになっている。
【発明の概要】
【発明が解決しようとする課題】
【0003】
これらモダリティの各コンポーネントを点検修理するにはコストが掛かる。モジュール式に設計すれば、システムを顧客個々の要求に一致させて構築することができる。反面、修理や保守が複雑になる。つまり、それら修理や保守を個々のモジュールに合わせて行わなければならないので、修理や保守に要するコスト全体は高くなる。
【0004】
修理や保守を行うには、フィールド・サービス・エンジニアは、いつ生じるともしれない、あらゆるトラブルを調べるために、現場で直ちに使える技術マニュアルおよび修理手順書を持参していなければならない。しかし、ここでもシステムがモジュール式があるが故に、1つの問題を生じている。血管X線イメージングシステムはその典型的なものである。このシステムには、多様なモジュールが使用されるので、モジュールそれぞれに対して技術マニュアルおよび処理手順書がフィールド・サービス・エンジニアの手持ち品となってしまう。これはかなりの書類量になり、非常に不便で、移動性の良くないものであった。
【0005】
モダリティのシステムトラブル(問題)を診断する場合、診断結果に基づく問題解決法が的中の場合もあるが、外れてしまうこともあり、問題解決には試行錯誤的な要素を常に含んでいる。つまり、適宜な問題解決策に到達するまでには、多くの時間と手間が掛かる場合も非常に多かった。例えば、トラブルを診断するには、フィールド・サービス・エンジニアは問題解決のための処理手順を実行したり、頻繁に技術マニュアルを参照してそのような処理手順を実行する必要がある。最初の処理手順を実行してもトラブルが解決しないことも多く、その場合、追加の処理手順を実行する必要がある。これは著しく時間を浪費し、かつ診断コストも掛かる。また、処理手順を実行した結果、部品を交換する必要があることもある。しかも、その部品を交換しても、システムは依然として期待通りに作動しないという場合もある。
【0006】
トラブルの原因を見極めるのに2回以上の解決のための処理手順を実行する必要があることもある。一度、トラブルの原因が判定されると、かかる動作不良のコンポーネントをどのように修理するか又はどのように交換するかを決めるために、さらに多くの処理手順の実行が必要になる。経験豊かなフィールド・サービス・エンジニアであれば問題をより容易に識別し、それを解決するためのステップを知ることができるとしても、そのような経験のあるフィールド・サービス・エンジニアでさえも原因を誤診してしまうほど、めったに、しかも明瞭には発生しないトラブルもある。
【0007】
別のコスト上昇要因は保守、点検後に最適(optimum)性能を確保する手間にある。この最適性能はしばしばユーザが経験的に保有している。つまり、システムにより生成された画像を使用する医者一人ひとりが特有の性能パラメータ(performance parameters)を保有しており、これが個々の医者にとっての最適パラメータとなっている。このため、重要なことは、診断(試験、検査、管理)後に最適性能の状態を容易に再生することができ、システムを個々のユーザが好む性能特性を発揮できるセッティングに戻すことである。従来は、この最適性能の再生に多くの時間と手間が掛かっていた。
【0008】
また従来では、モダリティのシステム性能の状態をモニタする場合、モジュール化されているので、多くの手間を要していた。とくに、血管イメージングシステムの場合、その手間はしばしば複雑なものにもなっていた。それは、一般に多数のシステムコンポーネントが様々な部屋に置かれ、別々の電源からパワーを受けることがあるからである。概して、電気的安全、アース回りおよび距離の問題が生じる。
【0009】
本発明は、モジュール化システムにおける上述した従来のモニタ、保守、点検に関する種々の問題に鑑みてなされたもので、その主目的は、それらモニタ、保守、点検のコストを著しく低減させることができ、トラブル発生時に確実な問題解決策を提示できる、モジュール化システムに対する診断ネットワークシステムを提供することである。
【0010】
本発明の別の目的は、モジュール化システムを保守、点検するフィールド・サービス・エンジニアの手持ち品を少なくし、便利で、移動性を良くすることで、診断のコスト低減に寄与しようとするものである。
【0011】
本発明のさらに別の目的は、モジュール化システムのトラブル(問題)を診断する場合の試行錯誤的な要素を排除または減らし、能率良く問題解決策を提示して、診断のコスト低減に寄与しようとするものである。
【0012】
本発明のさらに別の目的は、経験豊かなフィールド・サービス・エンジニアであっても、解決困難な態様で発生するモジュール化システムのトラブルに対しても的確な解決策を提示できるようにすることである。
【0013】
本発明のさらに別の目的は、保守、点検やトラブル解決後に、モジュール化システムを以前のその最適性能の状態に容易に戻すことができ、これによっても、保守などのトータルの時間短縮および手間軽減を図ることができるようにする、ことである。
【0014】
本発明のさらに別の目的は、モジュール化システムの性能状態をオンラインで容易かつ確実にモニタでき、システム管理の信頼性を向上させることである。
【課題を解決するための手段】
【0015】
本発明に係る診断ネットワークシステムは、複数のデバイスと通信を行う診断ネットワークシステムにおいて、前記複数のデバイスの内の関連したそれぞれのデバイスと個別に通信を行って当該デバイスの動作状態に関する情報を常時、収集する複数の分散形試験ユニットと、マスタ分散形試験ユニットと、前記マスタ分散形試験ユニットおよび前記複数の分散形試験ユニットを通信媒体で相互に接続して情報の伝達を可能にしたネットワークと、前記マスタ分散形試験ユニットを経由して前記複数の分散形試験ユニットと通信を行うシステムモニタユニットと、前記システムモニタユニットと通信を行うとともにユーザに前記複数の分散形試験ユニットのそれぞれと通信を行わせるユーザインタフェースと、を備え、前記システムモニタユニットは、前記複数の分散形試験ユニットから前記動作状態に関する情報を収集するコントロールユニットと、前記複数の分散形試験ユニットから収集された前記動作情報に関する情報を基に編集された編集情報を格納するデータベースと、前記収集された情報を解析して前記複数のデバイスについて点検修理が必要か否かを常時、判定する手段と、前記ユーザインタフェースとの通信に応じて前記複数のデバイスの内の点検修理が必要なデバイスについてトラブルシューティングを行うのに必要なツール及び点検修理の処理手順を示す手段を有する診断ユニットと、を備えたものである。
【発明の効果】
【0016】
本発明の診断ネットワークシステムによれば、医用モダリティなどのモジュール化されたシステムに搭載された複数のデバイス(モジュール)のモニタ、保守および点検コストを低減させ、かつトラブル発生時に確実な問題解決策をユーザやサービスエンジニアに提供することができる。さらに、より簡単に、かつ、低コスト化・高信頼性をもってモニタし、保守(点検)および修理を行うことができる診断ネットワークシステムを提供することができる。また、この診断ネットワークシステムに好適に使用可能な分散形試験ユニットを提供することができる。
【図面の簡単な説明】
【0017】
【図1】本発明の診断ネットワークシステムの一例を示す図。
【図2】血管イメージングシステムに接続された場合の本発明の診断ネットワークシステムの一例の図。
【図3】本発明の診断ネットワークシステム係るオン・サイト部分(下側の円で表された)とTACにより提供されるオフ・サイトのサポート(上側の円で表された)の概念図。
【図4】本発明に係るスター配置構成の診断ネットワークシステムの図。
【図5】一般化されたDTUモジュールの断面透視図。
【図6】各DTUモジュールに共通のマイクロプロセッサモジュールの機能ブロック図。
【図7】各DTUモジュールに共通のパワーモジュールの機能ブロック図。
【図8】kV,mA DTU、PMT DTU、線量計DTU、およびマスタDTUに共通のサンプルコントロールモジュールの概要図。
【図9】DTUに使用されているマルチピンコネクタのマスタピン割り当てのテーブル。
【図10】RAMおよびEPROMメモリから成るDTUマイクロプロセッサ・メモリマップの図。
【図11】DTUマイクロプロセッサにより制御された場合のネットワークとサンプルコントロールモジュールとの間の通信データフローの図。
【図12】線量計DTUのブロック図。
【図13】オペレータコンソールに接続されたオペレータコンソールDTUのブロック図。
【図14】システムモニタにより実行される機能の概念図。
【図15】解像度処理手順のフロー図。
【図16】解像度処理手順に使用される問題分離アルゴリズムを示す図。
【図17】解像度処理手順に使用される問題分離アルゴリズムを示す図。
【図18】焦点試験処理手順を示すフロー図。
【図19】焦点試験処理手順を示すフロー図。
【図20】半値試験処理手順を示すフロー図。
【図21】迅速な管キャリブレーション・チェック処理手順を示すフロー図。
【図22】迅速な管キャリブレーション・チェック処理手順を示すフロー図。
【図23】チェックMAX ERR処理手順を示すフロー図。
【図24】間接撮影線量データ処理手順を示すフロー図。
【図25】間接撮影線量データ処理手順を示すフロー図。
【図26】間接撮影線量データ処理手順を示すフロー図。
【図27】本発明に係る2つのDTU間の通信に関係するセッション階層、データリンク階層、および物理メディア接続体を示す概念図。
【図28】図27のデータリンク階層パケットのコンポーネントを示す図。
【図29】図27のDTUネットワークプロトコルのデータリンクフレーム構成を示す図。
【図30】図27のセッション階層パケットの構成を示す図。
【図31】データ伝送の信頼性を上げる「スライディング技法」を表す図。
【図32】データ伝送の信頼性を上げる「スライディング技法」を表す図。
【図33】DTUに対する起動用シュードコードを表す図。
【図34】一般的なDTUに対する概略の起動シーケンスを示す図。
【図35】本発明に従うDTUネットワークの注釈セッションを表す図。
【図36】スマートブック(SmartBook)からの画面の例を示す図で、本システムにロギングしたときにフィールドエンジニアに提供されるグラフィカル・ユーザ・インタフェース・ソフトウエアを示す。
【図37】スマートブック(SmartBook)からの画面の例を示す図で、本システムにロギングしたときにフィールドエンジニアに提供されるグラフィカル・ユーザ・インタフェース・ソフトウエアを示す。
【図38】スマートブック(SmartBook)からの画面の例を示す図で、本システムにロギングしたときにフィールドエンジニアに提供されるグラフィカル・ユーザ・インタフェース・ソフトウエアを示す。
【図39】スマートブック(SmartBook)からの画面の例を示す図で、本システムにロギングしたときにフィールドエンジニアに提供されるグラフィカル・ユーザ・インタフェース・ソフトウエアを示す。
【図40】スマートブック(SmartBook)からの画面の例を示す図で、本システムにロギングしたときにフィールドエンジニアに提供されるグラフィカル・ユーザ・インタフェース・ソフトウエアを示す。
【図41】本発明の診断用ネットワークシステムにおいてフィールド・サービス・エンジニアが使用できるメニュー・オプションを説明するフローチャート図。
【図42】図41の「トラブルシュート」処理を表す動作シーケンス図。
【図43】図41の本発明に係る診断用ソフトウエアの「ユーティリティ」オプションについてのフロー図。
【図44】図41の本発明に係る診断用ソフトウエアの「ユーティリティ」オプションについてのフロー図。
【図45】図41の本発明に係る診断用ソフトウエアの「ユーティリティ」オプションについてのフロー図。
【図46】本発明の1つの展開例に係る診断ネットワークシステムの説明図。
【図47】本発明の別の1つの展開例に係る診断ネットワークシステムの説明図。
【発明を実施するための形態】
【0018】
本発明に係る診断ネットワークシステムの実施形態を添付図面を参照して説明する。
【0019】
この診断ネットワークシステム10は図1、2に示すように3つの主要なコンポーネントを備えている。すなわち、1)分散形試験ユニット(distributed test units:DTUs)12から成るハードウェアネットワーク13であって、血管イメージングシステム(vascular system)14(図2参照)を構成する種々のモジュール上の予め定めた試験位置(test points)に取り付けることができるコンポーネント、2)DTU12からデータを受領し取り扱うシステムモニタボックス16、および、3)フィールド・サービス・ノートブック18(従来のラップトップコンピュータ)であって、フィールド・サービス・エンジニアのシステムモニタボックス16に対するインタフェースとして機能するとともに、ユーザが本発明の診断ネットワークシステム10にアクセスできるようにするコンポーネントである。図3に概念的に示されているテクニカル・アシスタンス・センタ(TAC)19も本発明に係る別の構成要素を成す。
【0020】
[システムアーキテクチャ]
本発明の診断ネットワークシステム10に係る好適な実施形態の1つは、図1および2に示す如く、DTU12を直列につないだ最もシンプルな構成である。この構成により、血管イメージングシステム14の各デバイス(モジュール装置)の指定試験位置にて動作データを連続的に収集し、その情報を前記システムモニタボックス16に送り返すようになっている。図2に示すように、X線撮影のために使用される血管イメージングシステム14は、高電圧変圧器78、患者寝台17、C−アーム15、コントロールパネル32、およびコンソール30といったモジュール装置の集合体から成る。このDTUネットワーク13と前記システムモニタボックス16はオンサイトで配置されており、血管イメージングシステム14のモジュール装置に接続されている。DTU12の各々は互いに光ファイバネットワーク24により接続されている。好適な実施例によれば光ファイバネットワーク24として、「東芝アメリカ・エレクトロニック・コンポーネンツ(株)」から入手できるTOTX173/TORX173およびTOCP172の光ファイバーケーブルが使用される。各DTU12間の光ファイバーネットワーク24の最大長さは10メートルである。フィールド・サービス・ノートブック18はフィールド・サービス・エンジニアによってサイトまで持ち込まれ、イーサネット接続体20を使ってシステムモニタ16に接続される。このフィールド・サービス・ノートブック18にはグラフィカル・ユーザ・インタフェース(GUI)22が設けられており、これによりフィールド・サービス・エンジニアはDTUネットワーク13と直接に通信を行うことができる。
【0021】
図3に概念的に示すように、TAC19ではモデム・リンク26又はその他の適宜なデータラインを経由して、テクニカルサポート、機能統計、エキスパート・ノーレッジ(expert knowledge)、および外部データが追加的にオフサイトで得られる。このオフサイトのサポートはオンサイトのフィールド・サービス・エンジニアに与えられるので、本発明に係る診断ネットワークシステムを有効に機能させる上で助けとなる。
【0022】
図1および2で参照できるように、システムデータのサンプル能力は血管イメージングシステム14の予め定めた試験位置に配したDTU12により与えられる。例えば、DTU12は血管イメージングシステム14の線量計28、コンソール30、コントロールキャビネット32、および高電圧変圧器78などのコンポーネントに配してある。これらのコンポーネントの試験位置には各々、異なるDTUが備えられ、このDTUがその関連コンポーネントの特定のパラメータを監視するように設けられている。例えば線量計28は線量計DTU38を有し、X線の線量情報が集められる。DTUネットワーク13はマスタDTU34に接続されており、このマスタDTU34は、在来の25ピンケーブルの如くのマルチピン・ケーブル36によりシステムモニタボックス16に接続されている。
【0023】
複数のDTU12は直列に接続され、図1に示すように、マスタDTU34に始まりかつ終わるループの閉ループを形成している。図4に示すスター形の接続を行ってもよく、これにより直列接続で想定される欠点のいくつかを克服できる。
【0024】
図2のハードウェア構成の場合、マスタDTU34はパラレルポート40Aを有しており、これを通してマスタDTU34はシステムモニタボックス16のLPTポート40に接続される。このLPTポート40では4ビットがデータ入力用に、残りの4ビットが出力データ用に使われている。マスタDTU34は光学受信機/送信機54(図6参照)を有し、光ファイバネットワーク24との間の通信が可能になっている。このマスタDTU34は、システムモニタボックス16からデジタル信号を受信し、それをDTUネットワーク13用の光信号に変換する。マスターDTU34は、個々のDTU12から戻ったデータを受診すると、その信号を光信号の形態からデジタル信号の形態に変換し、その信号をシステムモニタボックス16に渡して解析させる。
【0025】
マスタDTU34の動作中においては、マスタDTU34が閉ループ中の第1番目のDTU12にデータを送り、その第1番目のDTU12がそのデータを第2番目のDTU12に再送信し、これを順次行って最後のDTU12がかかるデータをマスタDTU34に送り返し、ループを完成させる。DTU12がシリアルネットワークの場合、DTU12全部を接続してループを形成するのに1つの光ファイバネットワーク24のみで済むという点から、コスト的利点が一番である。
【0026】
このシリアル接続法の不利な点としては、a)1つのDTUの電源がダウンすると、ネットワークループ全体が動作不能になること、および、b)送信時に、光パルスの歪みが生じることがあり、この歪みが高速光通信の性能を低下させて低速モードになってしまうこと、である。これらの不利な点は図4に示すようにスター・ループ形それぞれのネットワーク構成を結合させたものを使って説明する。
【0027】
スター・ループ形ネットワークの一例を図4に示す。本実施例では4個以上の光入出力チャンネルを使い、本診断ネットワークシステムにとって不可欠な全てのDTU12を光ファイバケーブル・ネットワーク24の個々のリンクによってアクセスできるようにしている。第2に、DTU12はまたループ状に接続できる。主要なDTU12には直接アクセスができるので、1つのDTU12が故障していてもネットワーク全体が動作不能になるという事態が防止される。スター形構成の一つの不利な点は別々に接続するためには光ケーブルが付加的に必要になることである。しかし、各ループはそのループに割り当てられた専用のマスタDTU回路を持つことができ、そのマスタDTU回路は図2の閉ループの実施例に関連して説明したマスターDTU34と同類のものでよい。あるいはまた、マスターDTU回路一式がいくつかのループに共用されるという多重配置の構成を採用することもできる。
【0028】
[分散形試験ユニット]
さてDTU12を図5〜11を参照してさらに詳細に説明する。DTU12は可搬形のデータ収集ユニットであり、血管イメージングシステム14のコンポーネント(モジュール装置)上の所定試験位置に接続することができるように構成されており、そのイメージングシステムの通常動作又はそのイメージングシステムで作り出される画質に影響を及ぼすことなく、かかる接続が可能になっている。DTU12は本発明の診断ネットワークシステムの“感覚器”の機能を担い、データを収集してシステムモニタボックス16に送り出す。
【0029】
図5に示すように、3つの基本的モジュールが肩車状に設けられて1つのDTU12を成している。すなわち、1)マイクロプロセッサ・モジュール(MM)46、2)パワー・モジュール48(PM)、および3)サンプル・コントロール・モジュール(SCM)50である。これらのモジュールは図5に示すように、積層可能なマルチピン・コネクタ52により接続するのが好ましい。DTU12は、適宜なSCMモジュール50を選択し、マイクロプロセッサ・モジュール46およびパワー・モジュール48と一緒に積層することにより特定の試験位置に合わせることができる。マイクロプロセッサ・モジュール46およびパワー・モジュール48は各DTU12に対して不変であることが望ましい。DTU12にはLED104が搭載されており(図1に示す)、このLED104が状態情報を提供し、起動後にDTU12が動作しているか否かを表示する。
【0030】
マイクロプロセッサ・モジュール46は、バッテリパワーをオフ動作可能な東芝製68HC11AOのマイクロプロセッサ44を、ネットワーク内でのメモリおよび接続用光入出力能力と伴に有している。DTU12は、血管イメージングシステム14の例えば線量計といった1つのコンポーネントに少なくとも1対が光学である、接続するためのアナログ又はデジタルの入出力を有している。
【0031】
血管イメージングシステム14のDTU12を配置する試験位置の各々は様々の機能に供する。したがって、種々のタイプのSCM50が使われる。しかしながら、パワー・モジュール48とマイクロプロセッサ・モジュール46は各DTU12に共通である。全てのDTU12は全体的には似ているけれども、入力条件および動作レベル(電圧および値)は変わることがある。
【0032】
DTU12を取り付ける所定の試験位置は、最高の可能な限りの画質を得る上で最も重要と考えられる位置である。各DTU12はいくつかの機能を果たす。この機能には、1)光ファイバネットワーク24を通して受診したシステムモニタボックス16からのコマンドを監視しながら待つ、2)所定の試験位置への入力を監視する、および/または、3)所定値を保持するように試験位置を変更する、ことが含まれる。例えば、DTU12は正のフィードバック制御システムとして動作でき、そのシステムでは出力がある所定値に到達するまで入力としてフィードバックされる。このため、例えばユーザが線量計28の放射をある値まで上げたいと望むと、その線量計DTU38は指定出力値に達するまで放射を増分ずつ増加させる。
【0033】
マイクロプロセッサ・モジュール46はパワーモジュール48および試験位置特有のSCM50に一体化されている。マルチピンコネクタ52を介して、SCM50を制御するために必要な信号がマイクロプロセッサ44から与えられる。図6に示すマイクロプロセッサ・モジュール46の好適なアーキテクチャには、光学受信機および送信機54、東芝製モデル68HC11A1またはそれと同等のものなどのマイクロプロセッサ44、EPROM58、RAM 2000メモリ56Aのバンク、RAM 6000 メモリ56のバンク、RAM 8000メモリ56Cのバンク、およびフィールド・プログラマブル・ゲート・アレイ(FPGA)64が含まれる。マイクロプロセッサ44はマルチピンコネクタ52に接続されているデータ/アドレスバスを介して情報を伝送する。図9は、全部のDTU12の各々に対するマルチピンコネクタの信号割り当ての一例を示している。
【0034】
光学受信機および送信機54は光ファイバネットワーク24から受診した光パルスを電気的信号に変換し、この信号がマイクロプロセッサ44の通信ポートにより認識される。図6に示すごとく、拡張多重モードで動作しているマイクロプロセッサ44は、外部のRAM56A、56B、56CおよびEPROM58、ならびにI/Oにアクセスする。マイクロプロセッサ44のメモリマップの典型例を図10に示す。
【0035】
各DTU12はマイクロプロセッサ44内の直列接続の2つのマイクロプロセッサ68HC11A0を使ってデータを送受信するもので、そのシリアル・コミュニケーション・インターフェイス(SCIまたはRS232)60およびシリアル・ペリフェラル・インターフェイス(SPI)62は図11に示す通りである。クロスバースイッチ64を使い、システムモニタおよび試験位置の間で切り換えられる情報のフォーマットで指令されたように、光学リンク、および電気リンクを試験位置、すなわちRS232 60ポートまたはSPI 62ポートに接続する。クロスバースイッチ64Aは図11に示す如くFPGAの一部としてインプリメントされている。コード/デコード・ロジック65がMOSI/SCKフォーマットの信号をRx/Txフォーマットに、又はその反対に変換する。
【0036】
ネットワーク上の全てのトラフィックをマイクロプロセッサ44を通して行わせる代わりに、SPI62が光学受信機54から情報を受け、その信号を光学送信機54に再送信する。再送信された信号は再び変調されて光学パルス幅の歪みを補う。(PAL再送信スイッチ53を参照のこと。)このように、パルス幅の歪みを蓄積することなく、沢山のDTU12を直列に接続することができる。
【0037】
一般的なDTU12の場合、8個のアナログ信号(0〜2.5Vレンジ)をサンプルできる。マイクロプロセッサ44はその内部にA/D変換器66を備えている。試験位置から送られてきたアナログデータはマルチピン・コネクタ52を通って、このマルチピン・コネクタに直接結合しているマイクロプロセッサ44に到達する。
【0038】
アナログデータは次いで前記A/D変換器66を通ることでマイクロプロセッサ44内においてデジタルフォーマットに変換される。SCM50にはチップセレクトロジックとともにエクスターナルデータ/アドレスバスが使用されており、そのDTU12(アドレスレンジ0800−OFFF、図7)から別のDTUにインターフェースできる。初めの4つ(A0 − +5V、A1− BATT.1、A2 − BATT.2、A3 − +12V)の入力チャンネルはパワー・モジュール48(図5参照)をモニタするのに使用する。最初のチャンネルで+5Vの電源電圧をモニタする。第2および第3のチャンネルでDTU12内で利用されている2つのバッテリをモニタする。第4番目のチャンネルで内部のDC/DC変換器の電圧をモニタする。終りの4つのアナログチャンネルを使って、試験位置のいずれか1つからデータをサンプルすることができる。
【0039】
各DTU12は1時間までの間必要なデータを保持するためバッテリ68および24VDC入力70(図5)を有する自前のパワー・モジュール48を備えることが望ましい。このバッテリ68は内部のDC/DC変換器72からチャージされる。あるDTU12の「電源オン」の間、入力70に印加される24Vのパワーは、外部の電源又は血管イメージングシステム14の内側のDC電源ラインの一方から発生させることができる。DC/DC変換器72は24Vの入力電圧を、最高電流500mAの12V出力電圧に変換する。仮にこの機械から24V電源にアクセスできない場合、出力が24V DCである外部の壁面プラグ変圧器が使われる。前記変換器は500V 3000V入力/出力絶縁定格を有する。パワー・モジュール48の系統図(各DTUに共通)の一例を図7に示す。
【0040】
このパワー・モジュール48はリレースイッチ74を通してDC/DC変換器72に接続されている。高ノイズ耐性が必要なときは、パワー・モジュール48を物理的にDC/DC変換器72から切り離してX線曝射の期間のデータ収集に必要な短い時間の間は内部のバッテリ68から電源供給することができる。
【0041】
DTU12の各々は、それらが持っているSCM50に由来してDTU12の特別な特性を有している。SCM50の系統図は図8に示す如く、kV,mADTU76、マスタDTU、線量計DTU38、およびPMT DTU80に共通である。
【0042】
図12および13の例により示す如く、適宜なSCM50を選択しているので、一般的なDTU12が、血管イメージングシステム14のどこに配置するかに応じて、線量計DTU38またはコンソールDTU88といった別の特定DTU型として機能することができる。(図2参照のこと。)線量計28からといった、試験位置からのデータはSCM50上の試験位置接続体51を介してDTU12で受診される。ラインB4およびB5上のコマンドによってスイッチ200が制御され、リファレンス電圧と試験位置信号との間で切り換えがなされる。デバイダ59により、フルスケールおよび目盛られたレベルのその信号がスイッチ200から計測アンプ202に与えられる。
【0043】
計測アンプ202は次いでマルチピン・コネクタ52に通じているラインAIN6およびAIN7をドライブする。このためデータはマルチピン・コネクタ52のピンAIN6およびAIN7を通してマイクロプロセッサ・モジュール46に送られる。SCM50は、モニタ又はフィールド・サービス・エンジニアのラップトップ・コンピュ−タと交信をとるためRS232接続体55を備えている。MAX 232 RS232チップ57を設けてあり、これがかかるデータ信号RS232フォーマットから(およびこのフォーマットへ)SCM50で使用する±5Vのフォーマットに変換する。本発明の診断ネットワークシステムで使用するDTU12およびそれらの各SCM50の種類を以下に例示する。
【0044】
[kV,mA DT]
kV,mA DTU76のSCM50は、HVジェネレータタンク78(高電圧変圧器)上に配置されたTERMINAL−A PWBにまたはFEEDBACK PWBに接続することができる。(図2参照のこと。)kV,mA DTU76により試験位置51の電圧および/または電流が測定される。このSCM50は試験位置とDTU12の間のインタフェースとして機能する。一組の演算アンプがmA信号を、この電流レベルに比例する電圧レベルに変換する。同様の回路により+kV/−kV信号が見分けられ、絶対kV信号になる。このmAアンプは4〜1500mAの信号レンジ内で動作する必要がある(間接撮影/撮影モード)。したがって、様々なレンジを適応させるため、図8のプログラマブル・レジスタ・デバイダ59を介してプログラムされた増幅度が与えられる。
【0045】
[光電子倍増管DTU]
光電子倍増管(PMT)DTU80によりPMT80Aに加わる電圧が測定されるようになっている。簡単なOPアンプ回路を使えばそのPMT電圧を、マイクロプロセッサ・モジュール46(kV,mA SCMと同様)が測定するレベルに変換できる。
【0046】
[線量計DTU]
線量計DTU38(図12に示す)は典型的には線量計28に接続され、イメージング管に入射する放射線を測定する。この線量計DTU38はRS232リンクを使って35050Aまたは等価な線量計28を制御し、適切なレンジおよびモードを設定し、データを要求し、およびそのデータを光ファイバネットワーク24を通して前記システムモニタボックス16に伝送する。この線量計DTU38用のSCM50(図8に示す)は“Keithley”タイプ線量計用に設計されているが、別のタイプの線量計を使う場合は設計変更できる。このSCM50にはMAXIM MAX 232と同様のデバイスが使用されており、これによりマイクロプロセッサ44からの0〜5V RS232レベルが、線量計28に必要な9Vレベルに変換される。線量計28は内部のバッテリのみから電源供給を受け、遠隔からはターンオンさせることはできない。オペレータは「POWER ON/OFF」のボタンを押して起動させなければならない。しかしながら、この線量計は、ユーザにより選択された1〜255分の「無人運転」期間が経過すると、それ自身でターンオフする。
【0047】
[テクニック・セレクタ/コンソールDTU]
このテクニック・セレクタ(TS/コンソール)DTU88(図2に示す)はオペレータ・コンソール30に接続されており、オペレータのコンソール33に問いただし、このテクニック・セレクタがオペレータにより選択されたかどうかを判定する。さらに、このDTUはユーザが行った全ての動作をモニタし報告する。例えば、このDTUはkV,mA設定、焦点選択、X線管選択などのテクニックの選択をモニタし記録する。kV,mAの状態またはテクニックはオペレータを介在させることなく、TS DTU88から遠隔で選択し確認でき、多数の手順の完全自動化が可能になっている。後述するように、血管イメージングシステム14のキャリブレーション状態はDTU12の測定値をオペレータ・コンソール30の設定値と比較することで確認できる。
【0048】
このTS/コンソールDTU88はまたオペレータ・コンソール30の自動試験機能をドライブする。そこで本発明の血管イメージングシステムは、それぞれのDTU12が報告した試験位置の測定値を使って、これらの測定値を、テクニック・セレクタDTU88がオペレータ・コンソール30に記録した設定値と比較し、正確性を担保することができる。
【0049】
[マスタDTU]
このマスタDTU34は図2に示すようにループにおける初めでそして終りのDTUである。マスタDTU34はシステムモニタ16および光ファイバーネットワーク24間でプロトコル保存およびデータバッファリングの機能を果たすようになっている。マスタDTU34のSCM50を概略的に図8に示すが、このSCMは必要な信号を出力し、パラレルポート40Aを介してマスタDTU34をシステムモニタボックス16のLPTポート40にリンクさせる。この通信には「Standard Lap−LINK」又は「Interlink」のプロトコルが使われる。マスタDTU34間のSCM50には、マルチピンコネクタ52とシステムモニタ16のLPTポート40の間でデジタル信号用のバッファ204が利用されている。
【0050】
8本のデータラインと1本のストローブラインを使って、入力信号がシステムモニタボックスのLPT40からマスタDTU34のパラレルポート40Aに送られる。「SELECT」、「PAPER END」、「ACKNOWLEDGE」、「BUSY」、および「ERROR」の信号がシステムモニタボックス16のマスタDTU34からの出力信号として使われている。このマスタDTU34はRS232同様のプロトコルを使って、4ビット(+1ストローブ)のニブルを収集し、このニブルをネットワークプロトコルで受入れ可能なブロックにパックする。これにより、標準LPTポート40を使って、システムモニタ16および光ファイバネットワーク24間での通信を簡単化することができる。
【0051】
本発明の血管イメージングシステムはマスタDTU34が無くても構成することができ、その場合には、マスタDTU34を、システムモニタボックス16およびDTUネットワーク13間で高速の光通信を行うようにしたシステムモニタボックス内の回路に置き換える。
【0052】
[システムモニタボックス]
このシステムモニタボックス16(図1、2および14に示す)は、マスタDTU34を通して他の全てのDTU12を制御するもので、それらのDTU12に情報の問い合わせを行うとともに、それらのDTUが送り返してきたデータを処理する。システムモニタボックス16は全てのDTU12の何れとも個々に通信を行うことができる。システムモニタボックス16はリクエスト/コマンドを各DTU12に送ると、これに呼応してDTU12はそれらがあてがわれている装置から各々サンプルデータを収集する。システムモニタボックス16は各DTU12が提供したデータを解析して血管イメージングシステム14に発生した変化を判定することができる。システムモニタボックス16はまた、あるDTU12にコマンドを与えてそれ自身を別のタイプのDTU12に再構成することができる。
【0053】
システムモニタボックス16は図14に概念的に示す通り、コンピュータであり、このコンピュ−タは、マルチピン・ケーブルコネクタ36を介してマスタDTU3に接続するためのパラレルポート・インターフェース(LTP)ポート40、およびフィールド・サービスのノートブック・コンピュ−タ18に接続するためのイーサネット接続体20を有している。このシステムモニタボックス16はそのハードウェアとしてCD−ROM記憶装置94またはその同等物、マルチメディア能力、モデム96、イーサネット接続体20、スピーカを備えたサウンドボード98、グラフィックス能力、ハードウェアキー100、およびバーコードリーダ102を有する。システムモニタボックス16はまたCD−ROM94から立ち上げる(boot)こともできる。システムモニタ16は「マイクロソフト」社のウィンドウズ(Windows)・ベースのソフトウェア上で動作させることが望ましい。システムモニタ16はまた、ウィンドウズ´95(WINDOWS´95)またはユニックス(UNIX)といった次世代のソフトウェア・プラットフォーム上で動作させてもよい。
【0054】
図14に示す如く、このシステムモニタボックス16は診断システムの主要なシステム機能の全部を制御する。本発明に係る診断ネットワークシステム10を稼働させる上で必要な全ての情報および機能は、ソフトウェアによるグラフィカル・ユーザ・インターフェース(GUI)22を除いて、図36、37、38、39および40に示すように、システムモニタボックス16の内部に含まれている。このシステムの現在および過去の性能情報ファイルはオンサイト・データベース110に格納されている。システムモニタボックス16にはリモート・アクセス能力111が搭載されており、このリモート・アクセス能力により本サイトと交信し、TAC19によりモニタ可能になっている。CD−ROM94には書類(マニュアル及び手順)、装置仕様、及びサイトでの点検修理活動(serviceactivities)を実行する上で必要なビデオ・サポートのCDが含まれている。
【0055】
またリモート・アクセス機能111を使って遠隔のユーザがシステムモニタボックス16からファイル(例えばエラーログ、サイトの歴史情報)を転送し、システムモニタボックス16のデータベースにアクセスし、診断またはDTU12の制御といった遠隔機能を実行し、ソフトウェア訂正情報を受信し、DTU12の制御機能(すなわち、「サンプルDTU#2 10秒毎」といったシステムモニタボックス16に対するリモートコマンド)の実行予定を立て、そしてシステムの動作実行予定を立てることができる。システムモニタボックス16はまた自己診断、およびCD−ROMアクセス、DTU12のネットワーク、LPTポート40、シリアルポート108、およびイーサネット接続体20上の診断を実行する。
【0056】
フィールド・サービス・エンジニアがフィールド・サービス・ノートブック(コンピュータ)18をイーサネット接続体20を通してシステムモニタボックス16に接続すると、ネットワークデータにアクセスすることができる。システムモニタボックス16を通して診断情報が得られ、トラブルシューティングおよび各DTU12の保持を行うことができる。システムモニタボックス16はまた診断処理手順を使ってフィールド・サービス・エンジニアを補助することができる。フィールド・サービス・エンジニアおよびTAC19は共にモデム96を介して遠隔からシステムモニタボックス16にコンタクトし、DTU12のネットワークにアクセスするとともにシステムの動作をチェックすることができる。システムモニタボックス16はまたTAC19とのコンタクトを開始することもできる。TAC19は同様にシステムモニタボックス16に電子メールまたは技術報告の情報を送り、フィールド・サービス・エンジニアに読ませることが可能である。
【0057】
システムモニタボックス16は各DTU12から送られてきたデータを解析した後、その結果をモデム96を介してTAC19に自動的に送ることができる。もし何かの理由でTAC19のラインがふさがっている場合、システムモニタボックス16はその送りたいデータを後の伝送用にスプール(キューへの処理)する。またシステムモニタボックス16によってユーザはシステムモニタボックス16からTAC19へのデータのログやファイルの伝送予定を立てることができる。例えば、システムモニタボックスのエラーログや動作ログは8時間毎に伝送予定を立てることができる。
【0058】
このシステムモニタボックス16は各DTU12から送られてきた線量、信号振幅、解像度、およびフィールドの一様性などの試験位置データを解析する。インストールやキャリブレーション時には、フィールド・サービス・エンジニアがパラメータ(試験位置)の各々に対して受容可能な値を入力する。例えば、受容可能な線量値は0.08〜0.09と設定できる。これらの値は一度入力されると、システムモニタボックスのデータベース110に格納される。かかる事態が指令されると、システムモニタボックス16は線量計DTU38の如くの、該当するDTUから現在の値を読み込み、次いで読み込んだ値をシステムモニタボックス16に設けたエキスパート・システム(expert system)に渡す。このエキスパート・システム115は読み込んだ値を設定値と比較し、かかる読み込み値が受容可能な範囲内であるかどうかを判定する。エキスパート・システム115の判定により、血管イメージングシステム14の修理およびメインテナンスの間にユーザに促してとらすべきはどんな手続又は動作であるかが決定される。
【0059】
このシステムモニタボックス16は多数の診断処理手順を実行するので、システムの修理に伴う当て推量を減らすことができる。図15の例によって示す如く、フィールドサービスエンジニアは「解像度処理手順(Resolution Procedure)」により解析処理の中を案内され、画像の解像度が修正される。この結果、X線から細い大動脈の如くのビデオ像が画面上に表示され医師の観察に供せられる。医師にとっては殆ど又は全く価値の無いほど画質が劣化していることがある。そのような場合、画質の劣化はイメージ管(これを取り換えるにはおよそ40,000US$も掛かる)のまずさに因って生じているか、またはX線管(この取り換えはかなり安い)のまずさに因るかであろう。
【0060】
この解像度処理手順により問題の真の原因を求めるため一連の分離テクニックが行われる。この手続きによりフィールド・サービス・エンジニアのノートブック・コンピュ−タ上にインストラクションが表示される。フィールド・サービス・エンジニアはそこでX線画像化領域にファントム対象物を挿入する。このファントム対象物は鉛製のスクリーンで、所定の間隔と所定の厚さを有するワイヤを備えている。図16および17に示すCおよびC++言語で書かれたアルゴリズムを使って、解像度処理手順により画像の解像度はどの位置で測定できるかが判定される(ノーマルモード、拡大Iモード、又は拡大IIモード)。仮に解像度がこの3つのモードの何れかで測定できるならば、イメージ管は良好である。次いで解像度処理手順は「ディスプレイ・マスタ・オブジェクティブ・レンズ(Display Master Objective Lens)」といった他の処理手順を実行する。もしマスタ対象レンズ(master objective lens)が良好であるならば、次いで、図18および19に示す「チェック・フォーカル・スポット・サイズ(Check FocalSpot Size)」の処理手順が実行される。
【0061】
フィールド・サービス・エンジニアは今まで、この解像度の問題を解決しようとする中で、実際にはX線管のフィラメントに欠陥があった場合でも、イメージ管が原因であると考え、それを取り換えてきたかもしれない。本発明のシステム10によれば起こった問題に対する可能性のある全ての原因を予想し、不適切な解決策を自動的に排除/消去することで、そのような誤りを回避できる。
【0062】
前記エキスパート・システム(expert system)が実行する他の処理手順としては半値テスト(これは例えばX線ビームのハードネス(hardness)を決める)、クイック・チューブ・キャリブレーション・チェック(Quick Tube Calibration Check)、チェック・マックス・エントランス・エクスポージャ・レート(Check Max Exposure Rate)、およびフルオロ・ドーズ・データ(Flouro DoseData)の手続きなどがあり、それぞれ図20、21、22、23、24、25、および26に示されている。
【0063】
当業者ならば、これらの手順はシステムモニタボックス16に格納できかつエキスパートシステム115により実行できる多くの処理手順の単なる例であることを容易に認識できることであろう。これらの処理手順は、カリフォルニア州、パロアルト(Palo Alto)に所在する「Neuron Data Corp.」によりつくられた「NexPert」の名称で市販されているソフトウェアパッケージ上で実行される。
【0064】
このシステムモニタボックス16は安全機能も有している。遠隔のユーザ、例えばTAC19、およびフィールド・サービス・ノートブック18を介してシステムモニタボックス16に繋がっているユーザは、ユーザ・ログ・インおよびフィールド・サービス・ノートブック18のパラレルポート106に取り付けられたハードウェアキー100に関連したユーザ・パスワードを通して証明される。この証明情報はシステムモニタのデータベース110に保持される。一時的にハードウェア・キーを設けて本診断ネットワークシステム10のインストールおよび試験に使える。インストール時には、フィールド・サービス・エンジニアがTAC19に確認の電話を入れると、TAC19が今度はキーをサイト固有のものにする。
【0065】
エキスパート・システム115は同様にシステムモニタボックスのデータベース110に格納されている実行および歴史の情報を利用している。このシステムモニタボックスのデータベース110はエラーログ、アクティビティログ、問題解決ログ、結果ログ(システム評価テストの結果を提供)、ハードウェア・キー情報、およびシステムモニタのモジュール・バージョン情報(各プロセスおよびソフトウェア・リリースの版および改定情報を含む)を格納している。この情報が集合的に使われ、エキスパートシステムによる診断をサポートする。
【0066】
[フィールド・サービス・ノートブック]
このフィールド・サービス・ノートブック18により本発明にかかる診断ネットワークシステム10に備えられる。図1,2および14に示す如く、フィールド・サービス・エンジニアが現場に到着すると、このフィールド・サービス・ノートブック18がイーサネット接続体20を通してシステムモニタボックス16に接続される。
【0067】
次いで、グラフィカル・ユーザ・インタフェースのソフトウェア・ツール22を使って、ユーザはシステムモニタボックス16と交信を行い、各DTU12を含む、診断および保守の機能の全てにアクセスできる。フィールド・サービス・エンジニア・ノートブック18には「Intel 386」又は「486」又は同等のポータブル・コンピュ−タといったマイクロプロセッサ、グラフィックス能力、「ウィンドウズ」、およびウィンドウズ・ベースのグラフィック・ユーザ・インタフェース(GUI)が含まれる。本発明の好適な実施例によれば、GUIとして、カリフォルニア州、タスティンに在る東芝アメリカメディカルシステムズ社から出されている「スマートブック(SmartBook)」を使うことができる。
【0068】
[テクニカル・アシスタンス・センター]
テクニカル・アシスタンス・センター19(TAC)は本発明の診断ネットワークシステム10の中央情報源にあたる。図3参照のこと。TACのエンジニアにとってのツールは通常ユーザのインタフェースから得ることができ、このインタフェースによりTACエンジニアはオン・サイトのシステムモニタボックス16から画像をアップロードし且つ観察するのみならず、ログファイルをアップロードして、システムの性能状態を再検討することができる。TAC19では完全なサイト・ヒストリのみならず、オン・ラインのエキスパート・システムも同様に使用できる。TAC19で使用できるテクニカル・エキスパートは、迅速性が要求される診断ネットワークシステムの質問に関してフィールド・サービス・エンジニアの助けとなる。
【0069】
TAC19のハードウェアとしては、内部モデムを備えた従来形の複数のパーソナルコンピュ−タ(PCs)、複数のイーサネットカード、複数の200メガバイトまたはそれ以上の記憶容量のハードディスク、複数のCD−ROMドライブ(これらはファイルサーバに取り付けて共有可能な資源として使うことができる)、ワークステーション間を結ぶ複数のイーサネット接続網、1つのファイルサーバ、1つのバックアップシステム、1つの無停電電源装置(UPS)、および1つのレーザプリンタが含まれる。好適には、TAC19は市販されているNovellネットワーク、Oracleデータベース・サーバ、Neuronデータ・エキスパート・システム、および全てのPC上で動くWindows3.1のソフトウェアを使っている。TAC19のワークステーションはイーサネットを介して接続され、Novellネットワーク上で動作する。
【0070】
TACのユーザはサイトにつながると、1)“Get Images”、2)“DisplayImages”、3)“HW Key Information ”、4)“Error Log ”、および5)“Site History”の機能を使用できる。これら機能の全てはスクリーン上の(on-screen )ボタンまたはアイコンにより表示され、表示されたスクリーンからアクセスできる。可能な場合には、アクセラレータ・キーを設けて、それらの機能をアクセスのために使える。(ここで使用している用語「アクセラレータ・キー(Accelerator Keys)」は、プルダウン・メニュ・コマンドまたはクリックオン・ボタンの代わりに使うことができるキーストロークまたはキーストロークの組み合わせを意味している。
【0071】
“Get Images”の機能を使って、TACエンジニアはあるサイトにつながり、画像を検索することができる。それを検索する前には画像をアイコンとしてみるという選択肢が在るが、このアイコンはサイズが小さいためにオリジナルのものに比べて幾分詳細面で劣ると思われる。(画像サイズが小さいほど高速転送が可能になる。)このTACエンジニアはフル画像の代わりに画像ヘッダのみを検索することもできる。“Display Images”の機能により、TACエンジニアはサイトから検索した画像を表示することができる。一度表示されると、画像パラメータを調整する“windows level”のコントロールができるようになる。“HWKey Information”の機能により、TACエンジニアはあるサイトにつながって、そのサイトのキー目次のスクリーン上のスナップショットを呼び出すことができる。TACエンジニアは“Error Log”の機能を使うと、サイトのエラーログを通して走査することができる。“Site History”の機能により、サイト上に格納されているデータから、TACのデータベース112に格納されているサイト情報から、および、ASSISTデータベース114に格納されているサイト・ヒストリからサイト・ヒストリが提供される。
【0072】
サイト上に格納されている“Site History”には、プロセス・ヒストリ/ステータス、キー更新情報、キーステータス、エラーメッセージ、システム実行パラメータ、DTU記録などが含まれる。TACのデータベース112からのサイト・ヒストリには、遭遇した問題(トラブル)、それらの修理(fixes)などが含まれる。TACエンジニアがこのオプションを選択すると、表示領域は3つの情報源に応じて色またはフォントの何れかにより区別される。ユーザは必要ならば“Site His- tory”の状態から直接あるサイトにつないでファイルログを更新することができる。
【0073】
一連のデータベースのサーバー機能によって、TACのデータベース112は全てのサイトについて完全な情報を保持する。以下の機能の全てはユーザが多様なグラフ(パイ(pie)、ライン、バー)の基に表示情報をプロットできるグラフ能力を有している。データベースのサーバー機能によって、TACエンジニアは“Site History”のログを走査し、あるサイトから以前のサイトを介して結果(results )ログを走査し、あるサイトに対するハードウェア・キー更新の歴史を見て、およびフィールド・サービス・エンジニアが選んだあるサイトおよびインストールされているアップグレードなソフトウェア・バージョンを更新した状態を見る。
【0074】
[ネットワーク・プロトコルおよびコミュニケーション]
図27に示すように、DTU12のネットワーク・プロトコルは3つの論理階層、すなわちデータ・リンク階層116、セッション階層118、およびネットワーク・インタフェース階層119から成り、物理メディア階層である光ファイバネットワーク24を介して動作する。
【0075】
電源オン後、マイクロプロセッサ44のRS232ポート60(図11)は、9600、N、8、1のデータフォーマットにプログラムされ、オプティカルライン55はRS232RxDおよびTxDピンに接続される。このため、標準RS232プロトコルを使って、各DTU12は光ファイバネットワーク24によってアクセスできる。RS232およびSPI62のインタフェース・フォーマット間の切換えはソフトウェアにより制御することができる。DTU12間の通信は図28〜30に図示した如くのデータパケット120の状態で行われる。
【0076】
データパケット120が到着したDTU12には物理メディア(例えば光ファイバネットワーク24)を通してアドレスが指令され、ネットワーク・インタフェース階層119により初期的に操作される。その後、その受信状態にあるDTU12のデータリンク階層116はチェックサムをチェックし、正しいアドレスのチェックをし、そのパケットを受信する。この受信が完了すると、DTU12はパケットをそのセッション階層に送る。このデータパケットは、プリアンブル、フレーム・デリミタの開始、行先アドレス、ソースアドレス、データ長フィールド、データフィールド、フレーム・デリミタの終了、および図28および29に図示した如くの巡回冗長検査(CRC)のための2バイトから成る。前記パケット長はデータ長フィールドを調べることで判定される。次いでフレーム開始、フレーム終了およびCRCフィールドを調べることにより妥当性検査がなされる。このフレーム開始およびフレーム終了のデータは既知の値である。CRCの妥当性検査はCRCフィールドを除くフレーム上のCRCを計算すること、およびそれを埋め込まれたCRCと比較すること、から成る。データパケット120に使用するこのCRCアルゴリズムは、従来“CRC−CCITT”多項式(polynomial)(1021H)として知られている古典的なCRCハードウェア回路に基づいている。注目すべき重要なことは、データパケット120のCRCの計算は選択したネットワーク・インタフェースに依存してソフトウェア又はハードウェアになされるということである。RS232 SCI 60インタフェースおよびパラレルポート40のCRCはソフトウェアにより計算され、一方SPI62インタフェースのCRCはFPGA64のハードウェア回路により計算される。
【0077】
DTUネットワーク・プロトコルのデータリンク・フレ−ム(DNP)は、バイトオーダのネットワークとして大きなエンディアン(endian)を使っている。このため高次オーダのバイトが開始アドレスにくる。一例として、図29に、データ長およびCRCフィールドに使用するバイト・オーダを示す。注目すべき重要なことは、この階層がフレ−ムのデータ部分を使うだけでCRCを計算していることである。
【0078】
[データリンク階層]
このデータリンク階層116はプロトコルの論理的に最も低い階層である。この階層によりデータパケット120の実際の転送が行われる。このデータリンク階層116はセッション階層118からデータを受信し、カプセルに入れることにより作動する。図28に図示するように、この封じ込めには、セッション階層のデータにアドレスを付加すること、および、チェックサムを計算してこれをそのデータに付加することが含まれる。このデータリンク階層116は次いで図28に示すデータパケット120を次のDTU12に送る。
【0079】
このデータリンク階層116によれば、特定のアプリケーションのニーズに応じて、データ転送に関する3つの異なるオプションが与えられている。この3つのデータ転送法とは、積極的に受領通知を行う信頼性のある伝送、受領通知のない伝送、およびウィンドウをスライドする(sliding window)ようにした信頼性のある伝送、である。
【0080】
信頼性のある伝送は「再伝送による積極的な受領通知」という基本的な技法に基づいている。この技法には、受領側がソース側と交信する、すなわち、データを受け取ると受領通知メッセージを送り返すことが必要である。送り手側はデータパケット120を送る毎にその記録を保持し、次のデータパケット120を送る前に受領通知を待つ。送り手側はまたデータパケット120を送るとユーザ定義のタイマを作動させ、受領通知が到着する前にそのタイマが終了するならばそのデータパケット120を再転送する。再転送は3回まで試みられるようになっている。性能上の理由により、受信したメッセージが受領通知を送ることができかつ1つのメッセージで応答できるセッション階層118に届けられると、かかる作業を実行するのに必要な時間の半分を省くことができる。送り手側のデータリンク階層116は常に、受領通知(埋め込まれた応答)を別の処理のためにセッション階層118へ回す。このモードの場合、DTU12のノードでバッファリングしなくてもよい。受信メッセージのハンドルはアプリケーションに渡される。このメッセージの長さは“DNP Maximum Transfer Unit”の一定値を越えることはできない。この信頼性のある伝送サービス(Riliable TransmissionService)を使って、オープンネットワーク(Open Network)、クローズネットワーク(Close Network)、アノテート(Annotate)、インボークアドレス(Invoke Address)、インボークネーム(Invoke Name)、ダウンロード(Download)、アップロード(Upload)およびMemfillのモジュールがインプリメントされている。
【0081】
受領通知のない伝送の場合、アプリケ−ションによって受領通知を待つことなくメッセージを伝送することができる。メッセージの再伝送はなされない。このデータリンク階層116は受領通知を待つことなくメッセージを伝送する簡単な伝送サービスを提供できる。アプリケ−ションプログラムの責任としては、データパケット120が誤りなく行先に届いたことを確認するように設計することである。
【0082】
前記信頼性のある伝送/ウィンドウ・スライディングの技法は、前記他の転送法を使ってできる伝送よりも大形の伝送に使われる。ウィンドウ・スライディング(sliding window)の技法は積極的な受領通知および再伝送の一形態であり、多重データパケット120が受領通知を待つ前に伝送される。図31に示すように、各データパケット(パケット1〜4)120の各々の受信に受領通知を出す代わりに、受け手側サイトは4つのデータパケット120が受信されるまで待ち、各受領通知をスプールし、次いで送り手側サイトに1つの受領通知を送る。受領通知がなされないデータパケット120の数はどの所定時間においてもウィンドウサイズによって強制され、小さな固定数に限定される。送り手側が最初の4つのデータパケット120に対する受領通知を受け取ると、図32に示すように、ウィンドウはある時刻にて4つだけスライドし、次の一連のデータパケット120が送られる。
【0083】
失ったデータパケット120は再伝送され、そのウィンドウがスライドする前に受領通知がなされる。送り手側は、受領通知が返送されるべき状態を表す十分な情報をバータパケット120にエンコードする。送り手側が失ったデータパケット120を再伝送する場合、データパケット120毎に直ちに受領通知を送るように受け手側に要求する。
【0084】
積極的な受領通知を伴う信頼性のある伝送および受領通知のない伝送の両方法とは違って、このウィンドウ・スライディング法を用いる方法では、全ての受領通知はデータリンク階層116によってなされる。送り手側のデータリンク階層116はそのセッション階層118から多量のメッセージを受け入れ、また受け手側のデータリンク階層116は多量のメッセージをその受け手側のセッション階層118に渡す。もし要求があまりにも大きければ、データリンク階層116はそれらを個々のデータパケット120に分割する。
【0085】
[セッション階層]
このセッション階層(Session layer)118はDTUネットワーク13のプロトコル階層上の論理的に高い階層である。これはDTUネットワーク13で必要な2種類のサービスについてのプロトコルを提供するものである。すなわち、1)DTU12毎に対するDTUネットワーク13のプロトコルサービス標準、および2)例えばkV,mAまたは線量計など、DTU12の種類により決められた固有のサービス、である。
【0086】
セッション階層118がデータリンク階層116に送るデータは、データ長およびデータ(これはそのデータ自体に加えてヘッダも含む)の2つの部分から成る。セッション階層118ではデータパケット120のデータ部分のみが使われる。図30に示す如く、ヘッダの最初の2バイトに基づいて、このセッション階層118はDTU12によって、またはDTU12に要求されたサービスの種類を決めることができる。このサービスには、アノテーション、ネットワークチェック診断、プログラムおよびモジュールのダウンロード、モジュールの呼出し、メモリダンプ、およびDTU12の時間設定およびデバッグ・セッションが含まれる。
【0087】
[ネットワーク・インタフェース階層]
このネットワーク・インタフェイス階層119は、ネットワークの一番低いレベルでのデータ通信を担っており、データパケット120の送受信に必要なデバイス・ドライバおよびモジュールから成る。SCI 60(RS232)、SPI 62、パラレルポート・インターフェース40、およびパケットドライバといったこのレベルではCRC計算および確認が行われる。
【0088】
妥当なCRCを有し且つローカル・ノードに割り当てられたDNPアドレスとなる予定である全部のデータパケット120は受け入れられ、データリンク階層116に渡される。「同報通信(broadcast)」のデータパケット120も同様に受け入れられる。他の全てのデータパケット120はそれ以上の処理を必要とせず、除かれる(ドロップされる)。マスタDTU34は各別の例外扱いであり、マスタDTUのみならずシステムモニタボックス16に予定されたデータパケット120を受け入れる。システムモニタボックス16に予定された又はシステムモニタボックス16から予定されたデータパケット120は、システムモニタボックス16のパラレルポート・インタフェース40を越えて経由される。
【0089】
[DTUソフトウェア]
DTUソフトウェアは大別すると、DTU12のパワーがオンになったときに実行される「スタートアップ(Start Up)」ソフトウェアと、システムモニタボックス16がサービスを要求したときに実行される「点検修理(Services)」ソフトウェアに分類される。
【0090】
68HC11A0のマイクロプロセッサ44は、パワーオン/リセットの後、インストラクション(コード)の実行を開始する。(図10のマイクロプロセッサ・メモリ・マップ参照。)このソフトウェアコードは、カリフォルニア州、サンホセ(San Jose)に在るXILINX社によって製造されたモデルNo.XC3064といったFPGA64向けのコードを含むEPROM58のバンクを選択する、そのFPGAコードをFPGAチップ64にコピーする、および自己診断を実行する、ことである。自己診断はDTU12内の2つのRAMチップ56Aおよび56Bのメモリテストから始まる。この診断中にネットワークを不能にする欠陥が見つからないときには、かかるソフトウェアはシリアルポート54を初期化し、1つの速続ループを回りながら、そのシリアルポート54に現れるデータパケット120を待つ。このソフトウェアによりメモリ2000チップ56Aからバンク0が選択され、必要な通信バッファがセットアップされる。これらのバッファを使用してデータパケット120が受信される。スタートアップのシュードコードを図33に示す。
【0091】
FPGA64はパワーオン後、それにロードされているプログラムにしたがう論理機能を実行する。プログラムはシステムモニタボックス16からマイクロプロセッサ・モジュール44のRAMメモリバンク56A〜56Cにダウンロードできる。このFPGA64はアドレス0800からOFFF(16進法)までマップされたメモリである。68HC11A0のマイクロプロセッサ44のポートAは種々のFPGA64のコントロールピンに接続されている。FPGA64はRAM構成可能(RAM configurable)である、すなわちFPGA64の構成(configuration)はパワーオン後にダウンロードしなければならない。かかる構成プログラム(configuration program)はEPROM58内に在る。初期化プロセスはFPGA64をリセットし、次いでかかる構成をEPROM58からアドレス0800(16進法)にコピーする処理を伴う。
【0092】
FPGA64をリセットするには、FPGA64のRESET(ポートA、ビット6)およびPROGRAM DONE(ポートA、ビット5)の各ピンが6マイクロ秒の間、ロー(LOW)に設定し、そしてハイ(HIGH)に戻される。このリセットはINIT(ポートA、ビット0)のピン上でローからハイへの立上がりが検知されたときに完遂される。前記構成プログラムは、1バイトをアドレス0800に一度に書き込むことでダウンロードされる。FPGA64では1つのピンを使ってデータを受け入れる。かかるプログラムを適切にダウンロードするため、READY/BUSYピン(ポートA、ビット1)をチェックして、次のバイトをFPGA64に書き込む前にそれが“ready”であるかどうかを確認しなければならない。
【0093】
[DTU自己診断]
本発明では、装置又はネットワークのどの欠陥をも表示するエラーレポート機構を備えている。DTU12のリード/ライト・プロセッサにおいて矛盾が生じたときは、このシステムでは受け入れられないレベルの電圧が検出され、該当するDTU12上のLED104に信号が送られ、問題発生の状況が告知される。ローカルな診断のためには、フィールド・サービス・ノートブック18をDTU12のRS232ターミナル55に直接接続することもできる。
【0094】
FPGA64の初期化が終わったとき、DTU12の自己診断が行われる。最初に、DTU12にて、RAMチップ56A、56Bおよび56Cの各バンクに独特のあるパターンを書き込むことでRAMメモリテストが行われる。このパターンは読み戻され、比較される。このテストに使用するパターンはバンク番号である。全てのバンクは書き込まれ、次いで読み出されるから、バンクのスイッチングの特徴が同時にテストされる。この読出し/書込みのプロセスの中で矛盾が生じる場合、起動は停止され、エラーがLED104に報告される。
【0095】
次にバッテリ電圧レベルおよび電源レベルがチェックされる。もし受容できない電圧レベルであるならば、起動は停止し、エラーがLED104に報告される。電圧は低いが、仕様電圧の範囲で電気系をまだ機能させることが可能な受容できる場合には、システムモニタボックス16に報告されるが、起動を停止することはしない。
【0096】
SCIインタフェース60は以下の設定により初期化される。すなわち、ボー・レート:9600、パリティ:無し、ストップ・ビット:(1)、およびデータ・ビット:(8)、である。次にネットワーク・バッファが初期化される。データパケット120を受信し送信するには2つのバッファが必要になる。これらのバッファは「BANK 0 RAM2000」23Aから割り当てられている。
【0097】
[DTU動作]
「起動(Startup)」シーケンスは図34に示されており、全DTU12を初期化する処理である。各DTU12はマスタDTU34を通してシステムモニタボックス16により指令されると、自己診断および注釈(annotation)を実行する。「パワーオン」処理の部分がDTU12の注釈であり、その中で各DTU12はコマンド・パケット122をDTUネットワーク13を通して渡し、それをマスタDTU34に戻すように自分自身を確認する。
【0098】
この注釈コマンドによってDTUネットワーク13の機器構成が可能になる。起動時に、全てのDTU12にて自己の状態(status)および自己のSCM50の状態が判定される。注釈時間のときに、その状態および識別番号(identification numbers)がカプセルに入れられ、注釈パケット124の一部として送られる。DTU12およびSCM50に対するこの識別番号はEPROM58のプログラミング時間で割り当てられており、EPROM58に保存されている。両方の番号はソフトウェアにとって有用で、起動時に読み出される。この注釈パケット124にはDTU12に対するシーケンス番号も同様に付加される。
【0099】
図35に示す如く、この注釈パケット124はマスタDTU34からDTUネットワーク13を通って伝送され、その間に全DTU12の各々からの注釈情報がその注釈パケット124に加えられる。同様に、DTU12が注釈パケット124を調べるときには、DTU12のネットワークにおけるそれのシーケンス番号を判定し、そのシーケンス番号をそれのネットワーク番号としてくくる。
【0100】
この注釈セッションでは、光ファイバネットワーク24がオープンの構成であり、および、各DTU12はそれらが注釈情報を加えた後で注釈パケット124を再伝送しなければならないということを理解しているものと仮定されている。DTUメモリ・ダンプ・コマンドがDTU12のメモリのメモリ・ダンプを要求する能力を果たす。システムモニタボックス16はDTU12にバンクを示すメモリ・ダンプ要求を発すると、これにより、ダンプするため、アドレスとトータルのバイト数が開始される。DTU12はメモリの画像とともに応答する。
【0101】
システムモニタボックス16はモジュールを追加してDTU12にダウンロードすることができる。ダウンロード・コマンドがDTU12上のRAMチップの任意のバンクにもプログラム・モジュールをダウンロードする能力を果たす。バンク、開始アドレスおよびバイト数が指定される。モジュール呼出しコマンドは、システムモニタボックス16があるDTU12のRAMメモリにダウンロードされたモジュールを実行するように指令する方法である。このコマンドによりDTU12の時間をシステムモニタボックス16の時間に1970年以降、秒でセットされる。
【0102】
各DTU12は、そのDTUが内蔵しているSCM50に基づいて特定のサービスを実行し提供する。一般のネットワーク・サービス(チェック、オープン、クローズ、注釈、DTUメモリダンプ、ダウンロード、モジュール呼出しおよび時間設定コマンドなど)は各DTU12の特定の目的にもかかわらず、全てのDTU12で与えられる。これらの一般のサービスはDTU12のネットワークコマンドによって果たされる。ネットワークに配置できるDTU12の最大数は255であるが、12ケが好適な配置である。
【0103】
ネットワークのチェックはシステムモニタボックス16により開始される(マスタDTU34を介して)。光ファイバネットワーク24は平常時には閉じている(再伝送可能)ので、マスタDTU34から送られたどのデータパケット120もマスタDTUに戻って受信されなければならない。この種のデータパケット120は、このパケットが処理又は応答を必要としない「通過」データパケットであることを表すように設定される。この送信されたデータパケット120が戻ってきてマスタDTU34で受信されるならば、かかる光ファイバネットワーク24は動作可能である。
【0104】
ネットワーク・オープン・コマンドを使うと全部のDTU12に自動再送信の機能を使用禁止にするように指令できる。このため、DTU12は、そのDTUに向けてアドレスされていないどのデータパケット120をも再送信する。注釈パケット124は上述した如く例外である。ネットワーク・クローズ・コマンドは全部のDTU12に指令を与えて前記自動再送信の機能を使用可能に設定できる。
【0105】
ある特定のDTU12から要求されたサービスにより、システムモニタボックス16は、DTU12の機能を設定するネットワークの注釈の後で、そのDTU12に適宜なソフトウェア・モジュールを動的にダウンロードする。このため、別々の装置に取り付けられている各DTU12はその機能に合わせた、特定のソフトウェアパッケージ、実行モジュールを有する。
【0106】
例えば、kV,mA DTU76内の実行モジュールはシステムモニタボックス16からの要求を待ってkVまたはmAの何れかをサンプルする。この要求が受信されると、そのアナログポート(kVに対してピン0で、mAに対してピン1)がサンプルされ、その値が応答データパケット120にて返される。同様に、PMT DTU80の実行モジュールはシステムモニタボックス16からの要求を待ってPMT電圧をサンプルする。この要求が受信されると、そのアナログポート(ピン0)がサンプルされ、その値が応答データパケット120において返される。
【0107】
マスタDTU34のソフトウェアモジュールはパラレルポート40Aを有しており、このポートを通してマスタDTU34がシステムモニタボックス16と交信を行う。マスタDTU34はシステムモニタボックスのLPTポート40を通して受信される、システムモニタボックス16からのストローブ信号を待ち、そして8ビット(1バイト)を読み込む。読み込んだバイトが1フレームになると、このフレームは光ファイバネットワーク24に経由される。この逆転送も、1バイトの半分が一度に転送されることを除けば、同様である。
【0108】
[システム動作]
フィールド・サービス・ノートブック18とシステムモニタボックス16の間に介在するユーザ・インタフェースはGUI22により成し遂げられるもので、このGUIとしては、カリフォルニア州、タスティンに在る東芝アメリカメディカルシステムズ社から出されている、東芝社内のソフトウェア・プログラム「スマートブック(Smartbook)」が好ましい。このスマートブックは、ワシントン州のベルビュに所在するAsymetrix社により作られた“Multi Media Toolbook”(「ツールブック“Toolbook”」)として知られている市販のソフトウェアパッケージ上で開発されたものである。スマートブックを使う場合、フィールド・サービス・エンジニアは自分への許可が済むと、自分のフィールド・サービス・ノートブック18から本発明の診断ネットワークシステム10にアクセスできる。スマートブックにより得られるプルダウンのメニューオプションを通して(この例を図36〜40に示す)、フィールド・サービス・エンジニアは多数のオプションにアクセスできる。
【0109】
フィールド・サービス・エンジニアはフィールド・サービス・ノートブック18をシステムモニタボックス16に直ちに接続することができ、スマートブックのソフトウェアを使い、シリアルポート108を通してデータを収集し、システムモニタボックス16上のエキスパート・システム115を稼働させる。図41にはシーケンス上の記号、およびフィールド・サービス・エンジニアに用意されている以下のオプションを図示してある。最初に、フィールド・サービス・ノートブック18とシステムモニタボックス16との間でイーサネット接続が行われる(ステップ140)。
【0110】
スマートブックのツールを立ち上げるため、フィールド・サービス・エンジニアはカスタマイズされたハードウエア・キー100を自分のノートブックのパラレルポート106に差し込む(ステップ142)。このハードウエア・キー100により診断ネットワークシステム10へのユーザアクセスが許可され、その中に満了時間が組み込まれる。このキーが期限切れになっていない場合、スマートブックは、ユーザ名およびパスワードのプロンプトを表示したログイン画面(図示せず)を立ち上げる。
【0111】
接続され、そして安全なアクセスが確認されると、フィールド・サービス・エンジニアはシステムモニタボックス16に載せている本発明の診断ネットワークシステム10に診断開始を知らせる(ステップ144)。図36は、フィールド・サービス・エンジニアに最初に提供される典型的な画面イメージを図示するもので、グラフィカル・ユーザ・インタフェース・メイン・メニュ22およびステータス・バー134を含んでいる。このメインメニュ22はメニューバー上にいくつかのメニューオプションを提示するもので、このオプションには機器構成(configure)126、システム診断(System Diagnostics)128、ビュー(View)130、およびユーティリティ(Utilities)126が含まれる。
【0112】
各画面上のステータスバー(Status Bar)134(図36)はユーザがログインした前回以降、何か新しいメールをそのサイトが受けたかどうかを示し、システム・ステータス・エリア(System status area)136は血管イメージングシステムの現在の状態を表し、ウォーニングまたは緊急エラーエリア(Warning or Emergency Error area)138はユーザの注目を必要とするメッセージを示し、およびプロセス・エリア(Process area)140は現在実行中のプロセスを表示する。ユーザがログインされると、その後の全部の画面に伴ってステータス・バー134が表示される。これによりアクティビティのいかんにかかわらず、ユーザはキー情報にアクセスできる。同様にこれにより画面間の一貫性が与えられ、またユーザが精通するプロセスの容易化が図られる。
【0113】
次に、メインメニュ22の様々な他のオプションを更に詳細に説明する。図41を参照すると、機器構成(configure)オプション126によりユーザは初期の機器構成を行い、次いでその後の段階で必要な任意の再機器構成を行うことになる。インストールの間に、ユーザはサイト(site)146、X線システム148、およびDTUネットワーク13を機器構成しなければならない(ステップ150)。インストールの後ではDTUネットワーク13のみに再機器構成が必要となることがある(ステップ152参照)。この再機器構成はDTU12が別々の試験位置に移動される毎に必要となる。
【0114】
サイト機器構成(site Configuration)では(ステップ146)、ユーザはシステムモニタボックスのデータベース110およびTAC19に格納されているサイト特有の情報を入力する。X線機器構成(X-ray configuration)のオプション(ステップ148)により、ユーザは置換が必要な任意のシステムコンポーネントについての情報を入力可能である。X線機器構成のオプションを選ぶと、X線室のスチール写真をフィールド・サービス・ノートブックの画面上に表示させ、血管イメージングシステム14を構成している種々のコンポーネントを見せてくれる。X線システムの種々のコンポーネントのルーツバー表示も同様になされる。この表示を使って、ユーザはかかるサイトで血管イメージングシステム14を構成する特定のコンポーネントを選択することができる。それらの選択は、このサイトに特有のシステム機器構成を形成する、フィールド・サービス・ノートブック18の表示画面上の予め定めた場所の中に位置付けられる。この具体的な機器構成はシステムモニタのデータベース110にセーブされる。
【0115】
置換可能なコンポーネントは、選択(クリックオン)されたときにその絵、現在の部品番号、モデル番号およびそのコンポーネントのシリアル番号が表示されるホット(hot)な領域を有する。かかる特別のコンポーネントがシステムモニタボックスのデータベース110に無い場合、そのシリアル番号のフィールドはブランクであり、ユーザはインストールする新しいコンポーネントのシリアル番号をタイプ入力するよう促される。シリアル番号をスキャンするバー・コード・リーダ102(図14)を使って、エラーの可能性を減らすこともできる。このシリアル番号が一旦入力されると、シリアル番号、モデル番号、および部品番号(part number)が自動的にクロスチェックされ、その組み合わせがTACのデータベース112の中に在ることが保証される。何らかの不一致があると、それはTACがサイトに向けて発信する電子メール(e-mail)のメッセージを介してフィールド・サービス・エンジニアに伝達され、ステータスバー(Status Bar)の領域138に表示される。これ以後、フィールド・サービス・エンジニアがこのサイトにログインするときはいつでも、不一致(ミスマッチ)であることの表示がステータスバーの“working and e-mail”領域138になされる。コンポーネント部品の記述及びそれらの関連するモデル/シリアル番号は、システムモニタボックスのデータベース110及びTACのデータベース112で自動的に更新される。
【0116】
機器構成126のメニューバーから“VASPAC Configuration”のオプションを選択すると、別のサブメニューが立ち上がる(図41参照)。このメニューは特定のサイトに最も共通するポスト・インストールの機器構成をリストするもので、アクセサリ・ツールのメニューを供給する。機器構成の画面(Configurationscreen)がフィールド・サービス・ノートブック上に表示され、この画面により、試験位置がマークされたX線室の絵と各種のDTU12が表されたツールバーとが表示される。そこで、ユーザはDTU12をシステム上のDTUの配置に相当する表示絵上の様々な試験位置にドラッグおよびドロップする。もし適合しないDTUが試験位置にドラッグされると、エラーとして不一致のフラッグが立てられ、そのような相手は許されない。例えば、kV,mA DTU76は線量計DTU38の代わりに使えない。ユーザは、DTU12を顧客にあつらえ、追加し、さらにこのツールバーから消去して、そのソフトウエア構成を血管イメージングシステム14の実際の物理的な機器構成に適合させる能力を有している。
【0117】
“Accessories”を選択することで本診断ネットワークシステムに接続されたマルチメディアのアクセサリによって、ユーザは本診断ネットワークシステムに、血管イメージングシステム14に結合されたカメラ、音響ボード、またはビデオといった使用可能なハードウエアを連絡することができる。使用可能であると識別されていないハードウエアに依存する機能は停止される。血管イメージングシステムの動作上、重大なハードウエアは選択できないようになっている。すなわち、血管イメージングシステムがそれ無しでは作動しない場合、その機能が停止されることはない。
【0118】
メインメニュー(図41に示す)上の“Systems Diagnostics”のオプション128を選択することで、ユーザに血管イメージングシステム14に関連する、最も共通するトラブルシューティングのツールが提供される。この“SystemsDiagnostics”のオプション128によって、フィールド・サービス・エンジニアは、キャリブレーションを行い、予防保守を行い、トラブルシュートを実行し、システム固有のコンポーネント・リストを観察し、システム上の部品を交換し、または顧客が最高の画像を提供すると感じているセッティング状態に本診断ネットワークシステム10を戻すことができるように、最適な特性基準を発生させることができる。この“Systems Diagnostics”のオプション128を選択することで、図15および図18〜26に示した如くの処理手順を実行できる。「解像度“Resolution”」、「半値階層“Half Value Layer”」といった代表的な処理手順へのアクセスを示すスマートブック(SmartBook)からのサンプルメニュー画面は図39および図40に示してある。
【0119】
ユーザが“Systems Diagnostics”128を選択したときには、血管イメージングシステム14の絵が図38に示すように、フィールド・サービス・ノートブック18の画面上に表示される。かかる血管イメージングシステム14の選択可能なコンポーネントは全てボタンとして確認され、そしてアクション・ボタンはキャリブレート用のステータスバー134、予防保守156、トラブルシューティング158、コンポーネンツ160、スナップショット162、およびリプレイスメント164の下に置かれる。このため、ユーザがX線管をキャリブレートしたいと欲する場合、そのX線管ボタンとキャリブレートボタンが選択されることになる。次いで、テキスト、フローチャート、および/またはビデオ・チップから成るオン・スクリーンのインストラクションが画面上に表示され、ユーザがキャリブレーション処理を完遂する上でのアシストを果たす。
【0120】
例えば、フィールド・サービス・エンジニアが“trouble shoot”を選択すると、本発明の診断ネットワークシステム10はユーザを評価処理へと案内し、オンラインで表示、情報および示唆を、全体的には図42に示すように(図15および図18〜26も参照のこと)与える。
【0121】
“View”130のオプション(図41)を選択すると、フィールド・サービス・エンジニアは“Mail”166またはオンラインのX線“Manuals”168のいずれかにアクセス可能になる。“Mail”166を選択すると、フィールド・サービス・エンジニアはそのサイトに対して新しくセーブされたメッセージを見て、応答すること、または、TAC19の書類の最新情報を見ることができる。また“Manuals”168のオプションを選択したフィールド・サービス・エンジニアはCD−ROM記憶装置94に格納されたX線技術マニュアルにアクセスすることができる。これらのオン・スクリーンのマニュアルには、テキスト、フローチャート、およびその両方、さらにアニメ化したビデオ・チップのインストラクションが含まれる。フィールド・サービス・エンジニアはテクニカルデータの中を走査し、関連するビデオ・チップを見ることができ、これに加えて、サブ・コンポーネントのリストを得るため別の絵の中に見られるコンポーネント上にズーミングしていくこともでき、修理または保守の処理の中をステップ・バイ・ステップで案内される。テキスト、さらには画面のビデオ・セグメントも互いに関連付けられている。
【0122】
図41および図43、44および45に示す“Utilities”132のオプションによって、フィールド・サービス・エンジニアはサイト・ヒストリ170を見ることができ、このヒストリにより、過去および現在のサイトの結果、過去のシステムの問題(トラブル)とその問題をいかに修理したか、およびエラーログ178を考察することが可能になる。過去の結果の解析ログはシステムモニタのデータベース110に構成可能な(configurable)結果ログ(Results Log)の状態で格納されており、オーバフローする分はTACのデータベース112に自動的に送られる。フィールド・サービス・エンジニアが以前に生じた同様の問題に対する修理法を参照できるときは、この結果ログの情報を使って修理時間を短縮させることが可能になる。ログされたエラー、現在のアクティビティ、およびTAC19に送るべくスプールされたファイルといった現在のシステム状態も同様に見ることができる。
【0123】
修理ログ(Fixes Log)176には、そのサイトにて遭遇した全ての問題のヒストリ(歴史)およびその問題がどのように修理されたかの情報が含まれている。システムモニタボックスのデータベース110には全体ログも格納されており、そのログのコピーが同様にTACのデータベース112に格納されている。オンサイトのデータベースに対する最新情報はTACのデータベース112に自動的にかつ電気的に送られる。
【0124】
エラーログ(Error Log)178にはそのサイトでログされた、血管イメージングシステム14のエラーのリストが含まれている。このエラーログの大きさは構成可能であり、オーバーフローするエラーログ情報は自動的にTACのデータベース112に送られる。ユーザはエラーを表示することができる。すなわち、ある範囲の時間内に、あるレベルの、ある番号/ストリングで、そして特定の処理によってログされる。ユーザはまた、エラーログ178の全てまたはサブセットを表示させている間、特定のフィールドをターンオフ(turn OFF)させることができる。例えば、あるレベルに関連する全てのエラーが一旦引き出されると、そのフィールドはターンオフすることができ、1ライン当たりにより多くの情報が表示されるようにできる。エラーは、「オペレータ(Operator)」、「点検修理(Service)」および「デバッギング(Debugging)」の3つのレベルの内の一つであるとすることができる。このレベルは表示されることでユーザに伝わる。例えば、フィールド・サービス・エンジニアがエラーログ178を表示させたとき、デバッギング・レベルを除く、オペレータおよび点検修理のレベルの全てのエラーが表示される。しかし、上位のユーザがログインされると、全部のレベルのエラーが表示される。
【0125】
ユーザは、“Status”ユーティリティ172を介して、現在のセッションでログされたエラー180、現在のセッションで生じたアクティビティのログ182、TAC19に送られるべくスプールされた(キューされた)ファイル184、およびハードウエア・キー(Hardware Key)100の状態186が含まれている、本診断ネットワークシステム10の現在の動作状態を見ることができる。このステータス・エラー・ログ(Status Error Log)180は、エラー・サイト・ヒストリ・ログ(Error Site History Log)178と同様の「オペレータ」、「点検修理」、「デバッギング」のビューイング能力(viewing capabilities)を有している。アクティビティ・ログ(Activity Log)182は、日付および時間のスタンプ、ロギング処理名、およびメッセージ・ストリングを有している。ユーザはログを通して検索し、特定の処理によってログされたアクティビティを引き出すことができる。このアクティビティ・ログ182はその大きさを構成可能になっている。オーバーフロー分はTACのデータベース112に自動的に送られる。スプール184を選択することで、TACのデータベース112に送られるべくキューされたファイルを表示することができる。各エントリと伴に表示される情報には、ファイルをキューに入れた処理名、エントリがスプールされた日付および時間、エントリが送られる予定の日付および時間、行先(ファイルが送られる場所)、予想転送時間、エントリの現在の状態(アクティブまたはペンディング)、およびファイルのサイズが含まれる。ユーザはエントリを追加し又は消去することでスプール(キュー)を編集することができる。追加されたエントリはユーザが構成可能な“Send Immediately”オプション、または、“Schedule to be sent at <time>”オプションを有する。デフォルトによりその追加されたエントリが現在のリストの終りに予定される。
【0126】
フィールド・サービス・エンジニアはまた、スマートブックにより、以下の主要な機能をチェックするための各種の自己診断試験を実行するオプションを有している。すなわち、フィールド・サービス・ノートブック18とシステムモニタボックス16との間のイーサネット接続体20、システムモニタボックス16とマスタDTU34との接続体、光ファイバネットワーク24、およびシステムモニタボックス16に対する自己診断である。したがって、1つのツールが多様な点検および修理の機能を果たすことになる。
【0127】
[本発明の展開例]
図46および図47に、上述した診断ネットワークシステムをさらに発展的に展開した展開例のシステムブロックをそれぞれ示す。
【0128】
図46に示す診断ネットワークシステムは、ネットワーク901(例えばINDS)を介して複数のサイト902a,…,902cと1つのTAC903とを接続したものである。複数のサイト902a,…,902cのそれぞれには上述した実施形態と同様に、多数の種々のモジュール(本発明のデバイスまたはコンポーネントに相当する)が互いに接続されて1つの機能を果たす医用モダリティが設置されている。複数のサイト902a,…,902cの内、例えば、1つのサイト902aは磁気共鳴(MR)イメージングシステムのサイトであり、別のサイト902bはX線CTスキャナのサイトであり、残りのサイト902cは血管イメージングシステム(vascular system:アンギオグラフィ(ANGIO)システムとも呼ばれる)のサイトである。医用モダリティそれぞれの各モジュールにはDTUが設置され、このDTUは前述したものと同一または同様のネットワークに組み込まれる。TAC902にはワークステーション(WS)のほか、各サイトからの情報をハブ(HUB)経由でファイルサーバ(File Server)に送るときに使用されるFTP(File Transfer Protocol)サーバ、フィールドエンジニア・ノートブックが接続されてファイルサーバの情報にアクセスするときに使用されるアクセスサーバ(ACCESS)などが備えられる。
【0129】
これにより、複数のサイト902a,…,902cは共通のTAC902との間で個別に通信を行うことができ、前述したと同一または同様に動作させることができる。このように複数のサイトでTACを共通に使用するように構成すると、TACを構築、運営するためのコストを低減させることができる。また複数のサイトの多様な種類のモダリティに汎用的に対処可能な診断用ネットワークシステムを提供できる。
【0130】
なお、複数のサイトの数およびそのモダリティの種類は図46のものに限定されるものではない。例えば2つのサイトでもよいし、また4つ以上のサイトに接続するようにしてもよい。モダリティの種類も例えば、X線TV装置、核医学診断装置、SQUID素子を用いた生体磁場計測装置など、いかなる種類のものであってもよい。
【0131】
また図47に示す診断ネットワークシステムは、図46に示したシステムをさらに発展させたものである。すなわち、図46のシステムを2系統設置し、ネットワーク同士を互いに接続して双方向に又は1方向に通信可能にしたシステムである。同図において、符号901および911はネットワークを、符号902a,…,902fおよび912a,…,912cは医用モダリティが設置されているサイトを、さらに符号903および913a,913bはTACをそれぞれ示す。ネットワーク901、911の内、一方は例えばINDS回線、もう一方は例えばアナログ伝送回線で成り、相互に接続されている。とくに、一方のネットワーク911には複数(ここでは2つ)のTACが接続されている点に特徴がある。
【0132】
このようにネットワーク同士を接続する診断ネットワークシステムの場合、一方のネットワーク901のTAC902は相手のネットワーク911のTAC912a,912bに直接アクセス可能に構成でき、モダリティの試験に必要な情報を広範囲に得ることができる。その反対方向のアクセスも可能に構成できる。このため、一方のネットワークに直接接続された系を例えば国内地域(または国内の一地域)に構築し、もう一方のネットワークに直接接続された系を海外地域(または国内の他の地域)に構築するなど、広域的な診断ネットワークシステムを提供することができる。なお、別の実施形態として、このようにネットワーク同士を接続する場合、3つ以上のネットワークを互いに接続するようにしてもよい。
【0133】
なお、本診断ネットワークシステムの診断対象となり得るモジュール化システムは、上述のように必ずしも医用モダリティに限定されるものではなく、複数のモジュール装置が相互に接続されて特定の機能を発揮するシステムであれば、いかなるシステムであってよく、上述の実施形態と同様の作用効果を得ることができる。
【0134】
本発明によれば、血管イメージングシステムなどのモジュール化されたシステムを、より簡単に、かつ、低コスト化・高信頼性をもってモニタし、保守(点検)および修理を行うことができる診断ネットワークシステムを提供することができる。また、この診断ネットワークシステムに好適に使用可能な分散形試験ユニットを提供することができる。
【0135】
本発明の分散形試験ユニットでは、それらモニタ、保守、点検のコストを著しく低減させることができ、トラブル発生時に確実な問題解決策を提示できる。また、モジュール化システムを保守、点検するフィールド・サービス・エンジニアの手持ち品を少なくし、便利で、移動性を良くすることができる。さらに、モジュール化システムのトラブル(問題)を診断する場合の試行錯誤的な要素を排除または減らし、能率良く問題解決策を提示して、診断のコスト低減に寄与することが可能になる。さらに、経験豊かなフィールド・サービス・エンジニアであっても、解決困難な態様で発生するモジュール化システムのトラブルに対しても正確な解決策を提示できるようにできる。さらにまた、保守、点検やトラブル解決後に、モジュール化システムを以前のその最適性能の状態に容易に戻すことができ、これによっても、保守などのトータルの時間短縮および手間軽減を図ることができる。さらに、モジュール化システムの性能状態をオンラインで容易かつ確実にモニタでき、システム管理の信頼性を向上させる、ことなどである。
【0136】
さらに、本発明によれば、複数のデバイスを備えたシステムが血管イメージングシステムの場合、この血管イメージングシステムの選択されたデバイス(線量計、コントロール用コンソールなど)に接続されたDTUを有するネットワークを使うことで、そのDTUはデータを収集し、そのデータをシステムモニタに転送する。フィールド・サービス・エンジニアはフィールド・サービス・ノートブック(ラップトップ形コンピュータ)をシステムモニタに接続してDTUが収集したデータにアクセスする。この集めたデータを使い、容易にモニタし再生できるシステム性能の正確な尺度が作られ、予め設定した基準に基づいて最適な性能レベルが提供される。システムモニタの電子データベースの格納能力により、フィールド・サービス・エンジニアには、コンポーネントリスト、マニュアル、および現在のソフトウエアリリースを含む、サポートシステムおよびリファレンスマテリアルが与えられ、これにより、血管イメージングシステムの迅速で、煩わしさの少ない、より正確な修理が可能になる。
【0137】
本発明ではさらに自動化されたシステムを提供し、このシステムによりマニュアルでデータ転送を行っている間に生じる誤差の確率を減らし、ハードのコピーサポートやフィールド・サービス・エンジニアがサイトに運ばなければならないテクニカルデータの量を少なくし、そして、性能データの必要な解析をシステムモニタに高精度に実行させることができ、したがって、診断および修理における人為的なエラーを減らすことができる。
【0138】
このような診断ネットワークシステムはトラブルシューティングおよび修理の能率を上げ、ダウンタイムをより短く止めることに繋がり、このため、コストを低減させかつ顧客の満足度を向上させることができる。この試験用ネットワークシステムはまた試験対象システム(例えば血管イメージングシステム)にとって非侵襲で試験できることから、例えば試験対象システムが使用されている間に所定の試験位置からデータを収集できる。これにより、フィールド・サービス・エンジニアは、例えば血管イメージングシステムがダウンする前にシステム性能の低下を先行学習的に検出し、修正することができる。
【0139】
またオフ・サイトのテクニカル・アシスタンス・センタ(TAC)を使えば、遠隔よりシステムモニタにコンタクトでき、DTUネットワークにアクセスしてシステム動作状態をチェックし、そしてシステムモニタに格納されている情報を更新できる。
【0140】
本発明によればまた自動化によって評価時間を短縮できる。本発明の診断システムはエキスパートシステムを採用しており、このエキスパートシステムはシステムモニタプロセッサで処理されるソフトウエアを有し、このソフトウエア処理により、DTUから集められ格納されたデータが解析される。エキスパートシステムは過去の同様の問題状況をより迅速に参照し、解決策を呼び戻すことができる。このエキスパートシステムはしたがってフィールド・サービス・エンジニアに、かかるシステム上のどこをどのように解決すればよいかの示唆を与えることができる。このエキスパートシステムはまた、正しくない処理手順が実行された場合に先取りし、フィールド・サービス・エンジニアを代わりの正しい解決策に向けさせる。この結果、通常の修理プロセスに付きものであった、時間の掛かる当て推量、および試行錯誤が低減され、血管イメージングシステムのより早い修理または調整が可能になる。
【符号の説明】
【0141】
10 診断ネットワークシステム
12 DTU(分散形試験ユニット)
13 DTUネットワーク
14 血管X線イメージングシステム
15 C−アーム
16 システムモニタボックス
17 患者テーブル
18 フィールド・エンジニア・ノットブック
19 TAC(テクニカル・アシスタンス・センサ)
20 イーサネット接続体
24 光ファイバケーブル
28 線量計
30 コンソール
32 コントロールパネル
34 マスタDTU
36 マルチピン・ケーブル
38 線量計DTU
40A パラレルポート
40 LPTポート
46 MM(マイクロプロセッサ・モジュール)
48 PM(パワー・モジュール)
50 SCM(サンプル・コントロール・モジュール)
76 kV,mA DTU
78 高電圧変圧器
80 PMT DTU
88 コンソールDTU
104 LED

【特許請求の範囲】
【請求項1】
複数のデバイスと通信を行う診断ネットワークシステムにおいて、
前記複数のデバイスの内の関連したそれぞれのデバイスと個別に通信を行って当該デバイスの動作状態に関する情報を常時、収集する複数の分散形試験ユニットと、
マスタ分散形試験ユニットと、
前記マスタ分散形試験ユニットおよび前記複数の分散形試験ユニットを通信媒体で相互に接続して情報の伝達を可能にしたネットワークと、
前記マスタ分散形試験ユニットを経由して前記複数の分散形試験ユニットと通信を行うシステムモニタユニットと、
前記システムモニタユニットと通信を行うとともにユーザに前記複数の分散形試験ユニットのそれぞれと通信を行わせるユーザインタフェースと、を備え、
前記システムモニタユニットは、
前記複数の分散形試験ユニットから前記動作状態に関する情報を収集するコントロールユニットと、
前記複数の分散形試験ユニットから収集された前記動作情報に関する情報を基に編集された編集情報を格納するデータベースと、
前記収集された情報を解析して前記複数のデバイスについて点検修理が必要か否かを常時、判定する手段と、前記ユーザインタフェースとの通信に応じて前記複数のデバイスの内の点検修理が必要なデバイスについてトラブルシューティングを行うのに必要なツール及び点検修理の処理手順を示す手段を有する診断ユニットと、を備えたことを特徴とした診断ネットワークシステム。
【請求項2】
前記複数の分散形試験ユニット、前記マスタ分散形試験ユニット、前記ネットワーク、および前記システムモニタユニットを備えたシステムが複数の医用モダリティに個別に接続されている請求項1記載の診断ネットワークシステム。
【請求項3】
前記複数の医用モダリティは、血管X線イメージングシステム、X線CTスキャナ、および磁気共鳴イメージングシステムの内の少なくとも1種類の医用モダリティを含む請求項2記載の診断ネットワークシステム。
【請求項4】
前記複数の分散形試験ユニットは、前記複数のデバイスそれぞれの所望の試験位置に取り付けられ、且つ、その試験位置における当該デバイスの動作データを前記動作状態に関する情報として連続的に収集する構成を有する請求項1に記載の診断ネットワークシステム。
【請求項5】
前記複数のデバイスは、同一の医用モダリティを構成する複数のデバイスである請求項4に記載の診断ネットワークシステム。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate

【図10】
image rotate

【図11】
image rotate

【図12】
image rotate

【図13】
image rotate

【図14】
image rotate

【図15】
image rotate

【図16】
image rotate

【図17】
image rotate

【図18】
image rotate

【図19】
image rotate

【図20】
image rotate

【図21】
image rotate

【図22】
image rotate

【図23】
image rotate

【図24】
image rotate

【図25】
image rotate

【図26】
image rotate

【図27】
image rotate

【図28】
image rotate

【図29】
image rotate

【図30】
image rotate

【図31】
image rotate

【図32】
image rotate

【図33】
image rotate

【図34】
image rotate

【図35】
image rotate

【図36】
image rotate

【図41】
image rotate

【図42】
image rotate

【図43】
image rotate

【図44】
image rotate

【図45】
image rotate

【図46】
image rotate

【図47】
image rotate

【図37】
image rotate

【図38】
image rotate

【図39】
image rotate

【図40】
image rotate


【公開番号】特開2010−17563(P2010−17563A)
【公開日】平成22年1月28日(2010.1.28)
【国際特許分類】
【出願番号】特願2009−201847(P2009−201847)
【出願日】平成21年9月1日(2009.9.1)
【分割の表示】特願2006−196211(P2006−196211)の分割
【原出願日】平成9年6月6日(1997.6.6)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.イーサネット
2.UNIX
【出願人】(000003078)株式会社東芝 (54,554)
【Fターム(参考)】