JP2018079151A - 医用画像診断装置、その制御方法、及びプログラム - Google Patents

Abstract

【課題】 複数のゲストＯＳがホットスタンバイ方式で動作する医用画像診断装置において、当該医用画像診断装置が備える所定のハードウェアを複数のゲストＯＳにより同時に用いられないよう抑止する仕組みを提供すること。【解決手段】 複数のゲストＯＳがホットスタンバイ方式で動作する医用画像診断装置であって、前記医用画像診断装置が備える所定のハードウェアを用いた処理を実行し、当該処理の実行結果を出力する第一の処理手段と、前記ハードウェアを用いた処理を実行せずに、前記第一の処理手段の前記実行結果を出力する第二の処理手段と、本番系システムとして動作するゲストＯＳには前記第一の処理手段による処理を実行させ、待機系システムとして動作するゲストＯＳには前記第一の処理手段による処理を実行させずに、前記第二の処理手段による処理を実行させる制御手段とを備えることを特徴とする。【選択図】 図９

Description

本開示は、医用画像診断装置、その制御方法、及びプログラムに関する。

近年、医療分野において、医用画像のデジタル化が進んでおり、医師は患者の所定の部位を表すＸ線画像や光超音波画像等をコンピュータモニタに表示し、患者の症状を診察することが多い。なお、医用画像を用いた診断を読影と呼ぶ。

一方、デジタル化が進んだことにより、医用画像診断装置におけるソフトウェアが占める役割が大きくなり、ソフトウェア不具合によるエラーが問題になっている。例えば、Ｘ線撮影では、Ｘ線発生装置によって発せられたＸ線がＸ線照射部から被写体へ照射し、被写体を透過したＸ線をＸ線センサによって撮像することで画像データを取得する（撮影処理）。そして、取得した画像データに対して、ＧＰＵを使って階調処理やノイズ低減処理等の画像処理を行い、読影し易い状態にしてから画像データをＰＡＣＳ（医療用画像管理システム）等の外部機器に送信する（検像処理）。

この撮影処理や検像処理の最中に、何らかのソフトウェア等の不具合によりシステムが停止すると、取得した画像データがどの患者のものであるのか分からなくなってしまう可能性がある。つまり、一度目の照射が無駄になってしまう無効被ばく等となる可能性がある。

この課題を解決する方策として、特許文献１に、ソフトウェアを複数のゲストＯＳで動作させることで多重化し、一方のゲストＯＳでソフトウェア不具合によりエラーが発生した場合に、他方のゲストＯＳを使って処理を継続させる方法が開示されている。

特開２００７−３０４８４５号公報

特許文献１のような多重化方法を医用画像診断装置に適用する場合、ホットスタンバイ方式でシステムを多重化することが望まれている。患者を撮影し、本番系システムのゲストＯＳにエラーが発生した場合でも、待機系システムのゲストＯＳが途中から処理を引き継ぐことができるためである。これにより、医者や患者の待機時間を短縮することができる。

しかしながら、医用画像診断装置においてホットスタンバイ方式でシステムを多重化すると、画像処理時に複数のゲストＯＳが同時に同じＧＰＵを使うために画像処理が遅延し、検査効率が低下してしまう問題がある。

医用画像診断装置において複数のゲストＯＳを起動させ、各ゲストＯＳにおけるシステムをホットスタンバイ方式で稼働させると、画像処理を行う際には各ゲストＯＳが同時に医用画像診断装置のＧＰＵを使用しようとする。こうした場合、ＧＰＵは各ゲストＯＳから要求された画像処理を並列で実行するのではなく、１つずつ順次処理することになる。

つまり、本番系システムよりも先に待機系システムの処理要求が実行されてしまうと、待機系システムの画像処理が完了するまで、本番系システムは待機しなければならない。また、ＧＰＵに限らず、医用画像診断装置が備えるハードウェアが、各ゲストＯＳから要求された処理を並列処理できないような場合には、同様の問題が発生してしまう。

本開示の仕組みの目的は、複数のゲストＯＳがホットスタンバイ方式で動作する医用画像診断装置において、当該医用画像診断装置が備える所定のハードウェアを複数のゲストＯＳにより同時に用いられないよう抑止する仕組みを提供することである。

上記の目的を達成するために本開示の医用画像診断装置は、複数のゲストＯＳがホットスタンバイ方式で動作する医用画像診断装置であって、前記医用画像診断装置が備える所定のハードウェアを用いた処理を実行し、当該処理の実行結果を出力する第一の処理手段と、前記ハードウェアを用いた処理を実行せずに、前記第一の処理手段の前記実行結果を出力する第二の処理手段と、本番系システムとして動作するゲストＯＳには前記第一の処理手段による処理を実行させ、待機系システムとして動作するゲストＯＳには前記第一の処理手段による処理を実行させずに、前記第二の処理手段による処理を実行させる制御手段とを備えることを特徴とする。

本開示の仕組みによれば、複数のゲストＯＳがホットスタンバイ方式で動作する医用画像診断装置において、当該医用画像診断装置が備える所定のハードウェアを複数のゲストＯＳにより同時に用いられないよう抑止することが可能となる。

本実施形態に係る医用画像診断装置１００の機能構成の一例を示す図である。 本実施形態に係る医用画像診断装置１００の全体処理の流れの一例を示すフローチャートである。 本実施形態に係る本番系検査処理の動作の流れの一例を示すフローチャートである。 第一のゲストＯＳのウィンドウが第二のゲストＯＳのウィンドウよりも手前に表示された画面の一例を示す図である。 第二のゲストＯＳのウィンドウが第一のゲストＯＳのウィンドウよりも手前に表示された画面の一例を示す図である。 本実施形態に係る待機系検査処理の動作の流れの一例を示すフローチャートである。 本実施形態に係る動作ログの一例を示す図である。 別の実施形態に係る本番系検査処理の動作の流れの一例を示すフローチャートである。 本開示の仕組みの概要を説明するための図である。 本開示の仕組みの概要を説明するための図である。 本開示の仕組みの前提を説明するための図である。

以下、本開示の仕組みの実施形態について図面を用いて説明する。尚、かかる実施形態例が本発明の技術的範囲を限定するものではない。

まず、本開示の仕組みの概要について図９から図１１を用いて説明する。

従来、Ｘ線撮影装置や光音響画像生成装置、更にはＣＴ装置といった医用画像診断装置は、ＣＰＵ、ＧＰＵ、メモリ等のハードウェアリソースと、ハードウェアリソース上で動作可能なオペレーティングシステム（以下、ホストＯＳという。）とを含む。また、医用画像診断装置は、Ｘ線撮影装置であればＸ線センサを備えており、光音響画像生成装置であれば検査プローブを備えている。尚、医用画像診断装置は、例えばＰＣやタブレット端末や携帯端末等の情報処理装置であってもよい。また、光音響画像生成装置は、特開２０１０−６３６１７号公報や特開２０１１−５０４２号公報等に開示された装置である。

こうした医用画像診断装置においてソフトウェアの不具合等が発生してしまうと、医用画像診断装置内のシステムが停止してしまう。その結果、場合によっては患者をもう一度撮影しなおす必要があり、医者や患者の負担が大きい。特に、Ｘ線撮影装置では、再撮影により患者にもう一度Ｘ線を照射することになってしまう問題がある（つまり、一度目の撮影は無効被ばくとなる。）。

そこで、仮想化技術を用いて医用画像診断装置のホストＯＳ上に複数のゲストＯＳをインストールし、各ゲストＯＳでシステムを動作させる仕組みが考えられる。システムを多重化することにより、１つのシステムが停止した場合でも、他のシステムが処理を継続することができるので、エラー発生時の医者や患者の負担を軽減することが可能となる。

また、エラー発生時の処理の引き継ぎをなるべく早く行うために、ホットスタンバイ方式（ホットスペア方式ともいう。）の冗長化を採用することが望ましい。ホットスタンバイ方式とは、同じ構成のシステムを複数用意しておき、本番系システム（運用系システム、稼働系システムともいう。）と待機系システムを同期して常に同じ状態で稼働させ続けておくものである。また、ホットスタンバイ方式は、本番系システムに障害が発生し動作が停止すると即座に待機系システムに処理が切り替わり、途中だった処理も待機系システムに引き継いで続行されるものである。

このホットスタンバイ方式を採用した医用画像診断装置を図１１に示す。図１１の医用画像診断装置は、ハードウェアリソース上にホストＯＳ１３０がインストールされている。ホストＯＳ１３０は、例えばＸ線センサや検査プローブ１０１からデータを受信して、ホストＯＳ１３０上の複数のゲストＯＳに対してデータを渡す通信分配手段１３８を備えている。また、図１１の医用画像診断装置で動作する複数のゲストＯＳは、第一のゲストＯＳ１１０と第二のゲストＯＳ１２０であり、第一のゲストＯＳ１１０が本番系システムとして動作し、第二のゲストＯＳ１２０が待機系システムとして動作する。

各ゲストＯＳは、制御手段１１１、１２１と第一の画像処理手段１１６、１２６とを備える。制御手段は、通信分配手段１３８からデータを受け取り、第一の画像処理手段に画像処理の要求を行う。第一の画像処理手段はこの要求を受けると、医用画像診断装置のＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）を用いて画像処理を実行する。そしてその処理結果を制御手段に返す仕組みになっている。

しかしながら、ホットスタンバイ方式でシステムを多重化すると、画像処理を行う際には複数のゲストＯＳがＧＰＵを使用するべく動作する。ＧＰＵは画像処理の要求を順次処理するため、順番待ちが発生してしまう。つまり、待機系システムの画像処理が本番系システムの画像処理よりも先に実行されてしまうと、待機系システムの画像処理が完了するまで、本番系システムの画像処理が待機させられてしまう問題がある。

そこで、図９に示すように、各ゲストＯＳが第二の画像処理手段１１７、１２７を備えることで、この問題を解決する。第二の画像処理手段は、スタブ（スタブコード）である。つまり、実際にはＧＰＵを用いた画像処理を行わず、第一の画像処理手段による処理結果を返答するだけのモジュールである。すなわち、医用画像処理装置は、本番系システムのゲストＯＳには、第一の画像処理手段による処理を実行させ、待機系システムのゲストＯＳには、第一の画像処理手段による処理は実行させずに、第二の画像処理手段による処理を実行させる。こうすることで、ＧＰＵが複数のゲストＯＳに使用されないように抑止する。

また、本番系システムとして動作する第一のゲストＯＳ１１０においてエラーが発生した場合、図１０に示すように、医用画像診断装置は第二のゲストＯＳ１２０を待機系システムから本番系システムに切り替える。そして、医用画像診断装置は本番系システムである第二のゲストＯＳ１２０に第一の画像処理手段による処理を実行させる。一方、医用画像診断装置はエラーから復旧した第一のゲストＯＳ１１０を本番系システムから待機系システムに切り替える。そして、医用画像診断装置は待機系システムである第一のゲストＯＳ１１０に、第一の画像処理手段による処理は実行させずに、第二の画像処理手段による処理を実行させる。すなわち、本番系システムとして動作するゲストＯＳでエラーが発生した場合に、本番系システムとして動作するゲストＯＳには第一の処理手段による処理を実行させずに、第二の処理手段による処理を実行させる制御手段に相当する。また、待機系システムとして動作するゲストＯＳには第一の処理手段による処理を実行させる制御手段に相当する。このように、エラーが発生して本番系システムを担当するゲストＯＳが変更となった場合であっても、本番系システムにＧＰＵを使わせることが可能となる。

尚、複数のゲストＯＳがＧＰＵを同時に使用する場合について説明したが、これに限らない。複数のゲストＯＳがＣＰＵ、ＧＰＵ、ＨＤＤ、メモリ等の所定の（または特定の）ハードウェアを同時に使用する場合にも適用可能である。つまり、情報処理や記憶処理といった処理も含まれるため、本開示の仕組みは画像処理を行う場合に限らない。

以下、前述した本開示の仕組みの実施形態について説明を行う。

図１に、本開示の仕組みの実施形態に係る、複数のゲストＯＳがホットスタンバイ方式で動作する医用画像診断装置１００の機能構成を示す。

医用画像診断装置１００は、仮想化技術により複数のゲストＯＳを動作させる（多重化する）ことで、ソフトウェアの不具合によるシステム停止を抑止する。本実施形態では、通常時に稼働しているシステムを本番系システムと呼び、本番系システムと同期して常に本番系システムと同じ状態で稼働させておくシステムを待機系システムと呼ぶ。

医用画像診断装置１００では、多重化方式としてホットスタンバイ方式を採用する。ホットスタンバイ方式では、同じ構成のシステムを複数用意しておき、本番系システムと待機系システムとを同期して常に同じ状態で稼働させ続けておく。本番系システムに障害が発生し動作が停止すると即座に待機系システムに処理が切り替わり、途中だった処理も待機系システムに引き継いで続行される。

Ｘ線センサ／検査プローブ１０１は、Ｘ線検査の場合はＸ線センサを用い、光超音波検査の場合は検査プローブを用いる。Ｘ線センサは、被検体を透過したＸ線を検出し、画像データへ変換する。一方、検査プローブは、超音波を被検体に送信し、生体からの反射音を検出して画像データへ変換する。尚、医用画像診断装置１００は、ＣＴ装置やＭＲＩ装置といったモダリティであってもよい。そのため、医用画像診断装置１００は必ずしもＸ線センサ／検査プローブ１０１を備えている必要はない。モダリティに応じたセンサ等をＸ線センサ／検査プローブ１０１に代わりに備えていればよい。この場合、そのセンサ等から画像データ、テキストデータ、波形データ等が通信分配手段１３８に送信されればよい。

第一のゲストＯＳ１１０は、ホストＯＳ１３０上で動作する仮想マシンである。第一のゲストＯＳ１１０は、制御手段１１１、入力手段１１２、表示手段１１３、状態同期手段１１４、動作ログ１１５、第一の画像処理手段１１６、第二の画像処理手段１１７を含む。

制御手段１１１は医用画像診断装置１００のＣＰＵを用いて、入力手段１１２、表示手段１１３、状態同期手段１１４、第一の画像処理手段１１６、第二の画像処理手段１１７を統合的に制御する手段である。制御手段１１１は、第一のゲストＯＳ１１０が、本番系システムとして稼働している場合は第一の画像処理手段１１６を用いて画像処理を実施し、待機系システムとして稼働している場合は第二の画像処理手段１１７を用いて画像処理を実施する。すなわち、本番系システムとして動作するゲストＯＳには第一の処理手段による処理を実行させ、待機系システムとして動作するゲストＯＳには第一の処理手段による処理を実行させずに、第二の処理手段による処理を実行させる制御手段に相当する。

入力手段１１２は、放射線技師や医師等のユーザからのマウスやキーボード等の入力装置からの操作を受け付ける手段である。ユーザは入力手段１１２を通して、医用画像診断装置１００に対して撮影指示や画像処理指示などを行う。

表示手段１１３は、Ｘ線センサ／検査プローブ１０１で撮影した画像データ１３１やボタン、フレーム、画像表示ウィンドウ等のＧＵＩ部品をコンピュータモニタ（表示装置）に表示する手段である。表示手段１１３は、第一のゲストＯＳ１１０が本番系システムとして稼働している場合は、第二のゲストＯＳ１２０の表示手段１２３より前面に画像データ１３１やＧＵＩ部品を表示する。

状態同期手段１１４は、第一のゲストＯＳ１１０と第二のゲストＯＳ１２０の状態を同期させる手段である。状態同期手段１１４は、第二のゲストＯＳ１２０の動作ログ１２５から第一のゲストＯＳ１１０で実行すべき処理を抽出し、制御手段１１１に実行させる。すなわち、本番系システムとして動作するゲストＯＳの動作ログを用いて、復旧したゲストＯＳの動作状態を本番系システムとして動作するゲストＯＳの動作状態と同期させる同期手段に相当する。なお、状態同期手段１１４は、第一のゲストＯＳ１１０が待機系システムとして稼働している場合のみ動作する。

動作ログ１１５は、制御手段１１１、入力手段１１２、表示手段１１３、第一の画像処理手段１１６の処理内容及び、処理結果を出力したログである。動作ログ１１５には、過去の動作ログも含まれる。また、動作ログ１２５は、医用画像診断装置１００のＨＤＤ等（記憶手段）に格納される。

第一の画像処理手段１１６は、Ｘ線センサ／検査プローブ１０１で撮影した画像データ１３１に対して、ＧＰＵを使って画像処理プログラムを実行することで階調処理、ノイズ低減処理等の画像処理を施す手段である。すなわち、医用画像診断装置が備える所定のハードウェアを用いた処理を実行し、当該処理の実行結果を出力する第一の処理手段に相当する。第一の画像処理手段１１６は、第一のゲストＯＳ１１０が本番系システムとして稼働している場合に用いられる。

第二の画像処理手段１１７は、画像処理プログラムを模擬したスタブプログラム（スタブコード）をＣＰＵで実行する手段である。スタブプログラムは、階調処理、ノイズ低減処理等の画像処理毎に準備する。また、スタブプログラムは、第二のゲストＯＳ１２０の動作ログ１２５から第二のゲストＯＳ１２０で施された当該画像処理の処理結果を取得し、制御手段１１１に通知する。すなわち、医用画像診断装置が備える所定のハードウェアを用いた処理を実行せずに、第一の処理手段の実行結果を出力する第二の処理手段に相当する。第二の画像処理手段１１７は、第一のゲストＯＳ１１０が待機系システムとして稼働している場合に用いられる。

第二のゲストＯＳ１２０は、第一のゲストＯＳ１１０と同様に、ホストＯＳ１３０上で動作する仮想マシンである。第二のゲストＯＳ１２０は、制御手段１２１、入力手段１２２、表示手段１２３、状態同期手段１２４、動作ログ１２５、第一の画像処理手段１２６、第二の画像処理手段１２７を含む。

制御手段１２１は、入力手段１２２、表示手段１２３、状態同期手段１２４、第一の画像処理手段１２６、第二の画像処理手段１２７を統合的に制御する手段である。制御手段１２１は、第二のゲストＯＳ１２０が、本番系システムとして稼働している場合は第一の画像処理手段１２６を用いて画像処理を実施し、待機系システムとして稼働している場合は第二の画像処理手段１２７を用いて画像処理を実施する。すなわち、本番系システムとして動作するゲストＯＳには第一の処理手段による処理を実行させ、待機系システムとして動作するゲストＯＳには第一の処理手段による処理を実行させずに、第二の処理手段による処理を実行させる制御手段に相当する。

入力手段１２２は、第一のゲストＯＳ１１０の入力手段１１２と同様なため説明を省略する。

表示手段１２３は、第一のゲストＯＳ１１０の表示手段１１３と同様に、Ｘ線センサ／検査プローブ１０１で撮影した画像データ１３１やボタン、フレーム、画像表示ウィンドウ等のＧＵＩ部品をコンピュータモニタ（表示装置）に表示する手段である。表示手段１２３は、第二のゲストＯＳ１２０が本番系システムとして稼働している場合は、第一のゲストＯＳ１１０の表示手段１１３より前面に画像データ１３１やＧＵＩ部品を表示する。

状態同期手段１２４は、第一のゲストＯＳ１１０の状態同期手段１１４と同様に、第一のゲストＯＳ１１０と第二のゲストＯＳ１２０の状態を同期させる手段である。状態同期手段１２４は、第一のゲストＯＳ１１０の動作ログ１１５から第二のゲストＯＳ１２０で実行すべき処理を抽出し、制御手段１２１に実行させる。すなわち、本番系システムとして動作するゲストＯＳの動作ログを用いて、復旧したゲストＯＳの動作状態を本番系システムとして動作するゲストＯＳの動作状態と同期させる同期手段に相当する。なお、状態同期手段１２４は、第二のゲストＯＳ１２０が待機系システムとして稼働している場合のみ動作する。

動作ログ１２５は、制御手段１２１、入力手段１２２、表示手段１２３、第一の画像処理手段１２６の処理内容及び、処理結果を出力したログである。動作ログ１２５には、過去の動作ログも含まれる。また、動作ログ１２５は、医用画像診断装置１００のＨＤＤ等（記憶手段）に格納される。

第一の画像処理手段１２６は、第一の画像処理手段１１６と同様に、Ｘ線センサ／検査プローブ１０１で撮影した画像データ１３１に対して、ＧＰＵを使って画像処理プログラムを実行することで階調処理、ノイズ低減処理等の画像処理を施す手段である。すなわち、医用画像診断装置が備える所定のハードウェアを用いた処理を実行し、当該処理の実行結果を出力する第一の処理手段に相当する。第一の画像処理手段１２６は、第二のゲストＯＳ１２０が本番系システムとして稼働している場合に用いられる。

第二の画像処理手段１２７は、第一のゲストＯＳ１１０の第二の画像処理手段１１７と同様に、画像処理プログラムを模擬したスタブプログラムをＣＰＵで実行する手段である。スタブプログラムは、階調処理、ノイズ低減処理等の画像処理毎に準備する。また、スタブプログラムは、第一のゲストＯＳ１１０の動作ログ１１５から第一のゲストＯＳ１１０で施された当該画像処理の処理結果を取得し、制御手段１２１に通知する。すなわち、医用画像診断装置が備える所定のハードウェアを用いた処理を実行せずに、第一の処理手段の実行結果を出力する第二の処理手段に相当する。第二の画像処理手段１２７は、第二のゲストＯＳ１２０が待機系システムとして稼働している場合に用いられる。

ホストＯＳ１３０は、仮想マシンを動作させる基盤となるＯＳである。ホストＯＳ１３０は、スナップショット取得ポイント設定手段１３２、スナップショット取得手段１３３、動作異常検知手段１３５、システム復旧手段１３６、処理切替手段１３７、通信分配手段１３８から構成される。また、画像データ１３１及び、スナップショットデータ１３４はホストＯＳ１３０が管理し、医用画像診断装置１００のＨＤＤ等（記憶手段）に格納される。

画像データ１３１は、Ｘ線センサ／検査プローブ１０１で撮影した画像データである。また、画像データ１３１は、第一の画像処理手段１１６または第一の画像処理手段１２６によって画像処理がなされた結果である。

スナップショット取得ポイント設定手段１３２は、ゲストＯＳのスナップショットを取得するタイミングを設定する手段である。本実施形態では、スナップショット取得ポイント設定手段１３２は、本番系システムとして動作するゲストＯＳのスナップショットを取得するタイミングを設定する。スナップショットとは、ある時点のシステムの状態（例えば、メモリ、ＣＰＵ、レジスタ、ディスク等）をデータとして保存することをいう。このデータをスナップショットデータと称する。スナップショットデータを用いることで、ゲストＯＳをスナップショット取得時の状態に復元することができる。

スナップショット取得手段１３３は、ゲストＯＳのスナップショットを取得する手段である。スナップショット取得手段１３３は、本番系システムとして稼働しているゲストＯＳの動作ログを監視し、スナップショットを取得すべきポイントに処理が到達した際に、スナップショットを取得する。

スナップショットデータ１３４は、本番系システムで稼働しているゲストＯＳのスナップショットデータである。

動作異常検知手段１３５は、本番系システムの動作ログ及び、本番系システムで稼働しているゲストＯＳの状態を監視し、動作異常（エラー）の発生を検知する手段である。

システム復旧手段１３６は、ゲストＯＳが動作異常になった際に、スナップショットデータ１３４を用いて、ゲストＯＳをエラー発生前の状態に復旧する手段である。すなわち、本番系システムとして動作するゲストＯＳまたは待機系システムとして動作するゲストＯＳでエラーが発生した場合に、スナップショットを用いて復旧する復旧手段に相当する。

処理切替手段１３７は、本番系システムと待機系システムを切り替える手段である。動作異常検知手段１３５が本番系システムの動作異常を検知した場合、処理切替手段１３７は、待機系システムに本番系システムに移行するよう通知する。

通信分配手段１３８は、Ｘ線センサ／検査プローブ１０１からデータを受信し、複数のゲストＯＳに分配する手段である。また、通信分配手段１３８は、制御手段１１１及び制御手段１２１から指示された画像データをＰＡＣＳ１４０（Ｐｉｃｔｕｒｅ Ａｒｃｈｉｖｉｎｇ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ）に送信する。このとき、通信分配手段１３８は、本番系システムとして動作するゲストＯＳから指示された画像データをＰＡＣＳ１４０に送信する。各ゲストＯＳはホットスタンバイ方式で動作しているため、本番系システムと待機系システムから画像データの送信が指示される。これをすべて実行してしまうと、同じ画像データを複数回送信することになるので、本番系システムから指示された画像データのみを送信する。または、本番系システムと待機系システムのいずれかから指示された画像データのみを送信する形態であってもよい。通信分配手段１３８がＰＡＣＳに送信する際には、ＷＡＮまたはＬＡＮ等のネットワークを介して有線または無線で送信する。また、送信する画像データは、ＤＩＣＯＭ（Ｄｉｇｉｔａｌ Ｉｍａｇｉｎｇ ａｎｄ ＣＯｍｍｕｎｉｃａｔｉｏｎ ｉｎ Ｍｅｄｉｃｉｎｅ）規格のＤＩＣＯＭ画像（ＤＩＣＯＭデータ）である。

尚、本実施形態では医用画像診断装置１００で２つのゲストＯＳが動作する例について説明を行うが、ゲストＯＳの数は複数であればよく、２つに限らない。ゲストＯＳが３つ以上動作する場合には、医用画像診断装置１００は、１つのゲストＯＳを本番系システムとして動作させ、それ以外のゲストＯＳを待機系システムのゲストＯＳとして動作させる。

次に、図２から図７を用いて、本開示の仕組みの実施形態に係る処理の流れを示す。

まず、図２を用いて医用画像診断装置１００の全体処理の流れを説明する。以下説明するＳ２０１乃至Ｓ２０６の各ステップは、医用画像診断装置１００のＣＰＵが各機能部を動作することにより実行される処理である。

ステップＳ２０１では、ホストＯＳ１３０のスナップショット取得ポイント設定手段１３２は、スナップショットデータを取得するポイント（以下、スナップショット取得ポイントという。）を設定する。ここでいうポイントとは、タイミングのことである。スナップショット取得ポイントは、ユーザからの入力を受け付けたポイントか、本番系システムの過去の動作ログから自動的に抽出したポイントとする。

ここで、動作ログについて説明する。動作ログは、例えば、図７のように、処理が行われた年月日時分秒を示すタイムスタンプ７０１、処理順に発行されるＩＤである識別子７０２、処理種別７０３、処理内容７０４、処理結果７０５等が含まれていればよく、フォーマット及び、保持方法は問わない。なお、ここでは、処理種別７０３は、入力手段１１２で指定されたユーザ操作処理を“ＵＳＥＲ＿ＯＰＥ”とし、その他の内部処理を“ＩＮＴＥＲＮＡＬ”としている。また、処理内容７０４は、処理開始を“ｓｔａｒｔ”、処理終了を“ｆｉｎｉｓｈ”としている。また、処理結果７０５は、成功を“ｓｕｃｃｅｓｓ”、エラーを“ｅｒｒｏｒ”、画像解析値を“数値”、その他を“ｎｏｎｅ”としている。

ステップＳ２０１の説明に戻る。スナップショット取得ポイントの自動抽出について説明する。エラーが発生しやすいパターンは、ユーザ操作に伴う処理を行った場合である。コンピュータは並列処理を行うことが可能ではあるものの、予期せぬユーザ操作が発生し、エラーとなってしまうことが多い。よって、ユーザ操作のタイミングをスナップショット取得ポイントとすることが望ましい。つまり、第一のゲストＯＳ１１０が本番系システムとして稼働している場合は、過去の動作ログ１１５を解析し、スナップショット取得ポイントとしてエラーが発生した直前のユーザ操作処理の処理内容７０４を抽出すればよい。

例えば、過去の動作ログ１１５が図７の場合だと、識別子７０２＝“１００１１”、処理内容７０４＝“ｆｉｎｉｓｈＩｐＤｙｎａｍｉｃＲａｎｇｅ”のレコードで、エラー（処理結果７０５＝“ｅｒｒｏｒ”）が発生しているのがわかる。従って、過去の動作ログ１１５から抽出するスナップショット取得ポイントは、当該レコードより前のレコードのうち、直近のユーザ操作処理（処理種別７０３＝“ＵＳＥＲ＿ＯＰＥ”）のレコード（識別子７０２＝“１００１０”）である。すなわち、処理内容７０４＝“ｓｔａｒｔＩｐＤｙｎａｍｉｃＲａｎｇｅ”である。つまり、この処理内容が実行されるタイミングをスナップショット取得ポイントとして設定する。

また、スナップショット取得ポイントとして、撮影処理終了のタイミング（処理内容７０４＝“ｆｉｎｉｓｈＣａｐｔｕｒｅ”）を予め設定しておいてもよい。本番系システムとして動作しているゲストＯＳで、撮影処理後にソフトウェア不具合によって画像データ１３１への参照が切れる等のエラーが発生した際に、エラー発生前の状態に復旧することが可能になるためである。

ステップＳ２０２では、ホストＯＳ１３０のスナップショット取得手段１３３は、ステップＳ２０１で設定したスナップショット取得ポイントの一覧を取得する。すなわち、どのタイミングでスナップショットデータを取得すべきかを示す情報の一覧を取得するということである。

ステップＳ２０３では、ホストＯＳ１３０の動作異常検知手段１３５は、本番系システムとして動作しているゲストＯＳの監視を開始する。例えば、第一のゲストＯＳ１１０が本番系システムとして動作している場合は、動作ログ１１５及び、第一のゲストＯＳ１１０の状態を監視することで、動作異常を検知する。

ステップＳ２０４では、ホストＯＳ１３０は、本番系システムのゲストＯＳに本番系検査処理を実行させ、待機系システムのゲストＯＳに待機系検査処理を実行させる。本番系検査処理の詳細は図３に示し、待機系検査処理の詳細は図６に示す。各検査処理の詳細は後述する。尚、各検査処理には、撮影処理及び検像処理が含まれる。

ステップＳ２０５では、ホストＯＳ１３０の動作異常検知手段１３５は、本番系システムとして稼働しているゲストＯＳの状態監視を終了する。

ステップＳ２０６では、ホストＯＳ１３０のスナップショット取得手段１３３は、ステップＳ３０７で取得したスナップショットデータ１３４を医用画像診断装置１００のＨＤＤから削除する。

次に、図３を用いて本番系検査処理の動作の流れを説明する。以下、第一のゲストＯＳ１１０が本番系システムとして稼働している場合を例に取り説明する。第二のゲストＯＳ１２０が本番系システムとして稼働している場合には、以下説明する第一のゲストＯＳ１１０の各手段が実行する各種処理を、第二のゲストＯＳ１２０の各手段が実行することになる。

ステップＳ３０１では、第一のゲストＯＳ１１０の入力手段１１２は、ユーザからの操作を受け付ける。ユーザは入力手段１１２を通して、医用画像診断装置１００に対して、撮影指示や画像処理指示などを行うことができる。

ステップＳ３０２では、第一のゲストＯＳ１１０の制御手段１１１は、これから実行する処理が画像データ１３１に対する画像処理か否かを判定する。すなわち、ＧＰＵを用いて画像処理を行うか否かを判定するということである。画像処理以外の処理を実行する場合はステップＳ３０３に進み、画像処理を実行する場合はステップＳ３０４に進む。

ステップＳ３０３では、第一のゲストＯＳ１１０の制御手段１１１は、画像処理以外の処理を実行する。例えば、ステップＳ３０１でユーザが撮影処理を指示した場合、制御手段１１１は、Ｘ線センサ／検査プローブ１０１から画像データ１３１を受信し、ホストＯＳ１３０に格納する。そして、表示手段１１３を使って画像データ１３１及び、ボタン、フレーム、画像表示ウィンドウ等のＧＵＩ部品を医用画像診断装置１００のコンピュータモニタに表示する。尚、既に、画像データ１３１がホストＯＳ１３０の所定の場所に格納されている場合は、他のゲストＯＳで受信完了したと判断し、受信した画像データ１３１を破棄する。また、その他の画像処理以外の処理としては、患者情報を登録する、画像診断を効率化するために画像データ１３１に注目領域情報を付加する処理も含まれる。更には、ＨＩＳ（Ｈｏｓｐｉｔａｌ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｙｓｔｅｍｓ）／ＲＩＳ（Ｒａｄｉｏｌｏｇｙ Ｉｎｆｏｒａｍｔｉｏｎ Ｓｙｓｔｅｍｓ）及び、ＰＡＣＳなどの外部装置とやり取りする等の処理も画像処理以外の処理に含まれる。これらの処理が完了した後、制御手段１１１は、タイムスタンプ７０１、識別子７０２、処理種別７０３、処理内容７０４、処理結果７０５等の情報を動作ログ１１５に出力する。

ステップＳ３０４では、第一のゲストＯＳ１１０の第一の画像処理手段１１６は、ＧＰＵで画像処理プログラムを実行することで、画像データ１３１に対して、階調処理、ノイズ低減処理等の画像処理を施す。尚、画像処理を実行するケースとしては、主に、ステップＳ３０１でユーザが明示的に指示した場合、及び撮影処理時にシステムが自動的に実施する場合がある。撮影処理時にシステムが自動的に実施する画像処理としては、例えば、ノイズ低減処理や画像歪み補正処理等がある。

ステップＳ３０４を具体的に説明する。制御手段１１１は、制御手段１１１が含まれる第一のゲストＯＳ１１０が本番系システムであるのか、または待機系システムであるのかを示す情報を記憶している。よって、制御手段１１１は、この情報に基づいて第一のゲストＯＳ１１０が本番系システムとして動作するゲストＯＳであると判断すると、第一の画像処理手段１１６による画像処理を実行させる。一方、制御手段が含まれるゲストＯＳが待機系システムであると判断する場合については、ステップＳ６０３で後述する。

画像処理が終了すると第一の画像処理手段１１６は処理結果（画像処理が成功したか否かを示す情報）を制御手段１１１に通知する。この通知を受けると、制御手段１１１は、ステップＳ３０３と同様に、タイムスタンプ７０１、識別子７０２、処理種別７０３、処理内容７０４、処理結果７０５等の情報を動作ログ１１５に出力する。

ステップＳ３０５では、ホストＯＳ１３０の動作異常検知手段１３５は、本番系システムで稼働しているゲストＯＳの動作異常を検知したか否かを判定する。動作異常を検知しなかった場合はステップＳ３０６に進み、検知した場合はステップＳ３１０に進む。尚、ゲストＯＳの状態監視の方法としては、ゲストＯＳが出力する動作ログの確認や、ゲストＯＳに対して一定時間ごとにハートビートを発信して応答が無くなった場合に異常状態になっていると判断する等の方法を取ればよい。

ステップＳ３０６では、ホストＯＳ１３０のスナップショット取得手段１３３は、本番系システムの処理がステップＳ２０２で取得したスナップショット取得ポイントに到達しているか否かを判定する。すなわち、スナップショット取得ポイントが示す処理と本番系システムで実施した処理とが同じであるか否かを判定する。スナップショット取得ポイントに到達している場合はステップＳ３０７に進み、スナップショット取得ポイントに到達していない場合はステップＳ３０８に進む。尚、スナップショット取得ポイントに到達しているか否かの判定には動作ログ１１５を用いるか、もしくは、スナップショット取得ポイントに到達した際に制御手段１１１がスナップショット取得手段１３３に通知する構成でも良い。

ステップＳ３０７では、ホストＯＳ１３０のスナップショット取得手段１３３は、第一のゲストＯＳ１１０のスナップショットデータ１３４を取得し、ホストＯＳ１３０が管理する医用画像診断装置１００のＨＤＤ等に保存する。尚、スナップショットデータの取得は、第一のゲストＯＳ１１０の動作を停止することなく取得することができる。

ステップＳ３０８では、第一のゲストＯＳ１１０の制御手段１１１は、ステップＳ３０１で受け付けたユーザ操作に伴う処理が全て完了したか否かを判定する。全て完了した場合はステップＳ３０９に進み、完了していない処理が存在する場合はステップＳ３０２に進み、処理が完了するまでステップＳ３０２乃至ステップＳ３０８を繰り返し実行する。

ステップＳ３０９では、第一のゲストＯＳ１１０の制御手段１１１は、検査処理が終了したか否かを判定する。検査処理が終了した場合は本番系システムの動作が終了し、検査処理が終了していない場合はステップＳ３０１に進む。

ステップＳ３０５で動作異常を検知したと判定されると、ステップＳ３１０では、ホストＯＳ１３０の処理切替手段１３７は、第二のゲストＯＳ１２０の制御手段１２１に本番系システムに移行するよう通知する。制御手段１２１は通知を受けると、状態同期手段１２４を停止し、第一の画像処理手段１２６を使って画像処理を実行するよう処理を切り替える。次に、表示手段１２３が第一のゲストＯＳ１１０の表示手段１１３より前面に画像データ１３１やＧＵＩ部品等を表示する。

図４及び図５を用いて表示手段の動作について詳細に説明する。図４は、医用画像診断装置１００のモニタの様子を示す画面４００である。すなわち、ホストＯＳ１３０の画面４００である。動作異常を検知する前は、図４に示すように、本番系システムである第一のゲストＯＳ１１０の各種情報を示す画面４０１が、待機系システムである第二のゲストＯＳ１２０の各種情報を示す画面４０２よりも前面に表示される。これは、本番系システムの処理結果をユーザに閲覧させるためである。つまり、処理切替手段１３７により本番系システムと待機系システムとが入れ替わると、図５に示すように、本番系システムである第二のゲストＯＳ１２０の画面４０２が、待機系システムである第一のゲストＯＳ１１０の画面４０１よりも前面に表示される。このように、本番系システムの画面（ウィンドウ）を自動的に前面に表示することで、本番系システムの画面をユーザが前面に表示するよう指示する手間を軽減できる。尚、本実施形態では画面４０１と画面４０２とをウィンドウ形式で表示させる一例を提示したが、フルスクリーン形式でも構わない。この場合、本番系システムのゲストＯＳの画面をフルスクリーンで表示するようにすればよい。

そして、動作異常検知手段１３５は、状態監視先を第二のゲストＯＳ１２０の動作ログ１２５、及び第二のゲストＯＳ１２０に切り替え、スナップショット取得手段１３３は、スナップショット取得先を第二のゲストＯＳ１２０に切り替える。尚、本番系システムと待機系システムを切り替える際に、処理切替手段１３７はその旨をユーザに通知する構成にしてもよい。

ステップＳ３１１では、ホストＯＳ１３０のシステム復旧手段１３６は、ステップＳ３０７で取得したスナップショットデータ１３４を用いて、第一のゲストＯＳ１１０をエラー発生前の状態に復旧する。

ステップＳ３１２では、第一のゲストＯＳ１１０の状態同期手段１１４は、第一のゲストＯＳ１１０と第二のゲストＯＳ１２０の状態を一致させる。具体的には、本番系システムとして稼働している第二のゲストＯＳ１２０の動作ログ１２５から、第一のゲストＯＳ１１０で実行すべき処理内容７０４を抽出する。そして、制御手段１１１を用いて、取得した処理内容７０４を実行する。尚、実行すべき処理内容７０４は、エラーが発生した処理及び、ステップＳ３１１で第一のゲストＯＳ１１０を復旧している間に第二のゲストＯＳ１２０で実行された処理になる。これらは、識別子７０２をキーに、第一のゲストＯＳ１１０の動作ログ１１５と第二のゲストＯＳ１２０の動作ログ１２５を比較することで抽出できる。なお、処理内容７０４の抽出方法は、動作ログ１２５を参照せずに制御手段１２１に問い合わせてもよい。

ステップＳ３１３では、ホストＯＳ１３０は、第一のゲストＯＳ１１０が復旧した後、第一のゲストＯＳ１１０を待機系システムとして稼働させる。そして、待機系検査処理を実行させる。待機系検査処理の詳細は、図６を用いて後述する。

次に、図６を用いて待機系検査処理の動作の流れを説明する。以下、第二のゲストＯＳ１２０が待機系システムとして動作している場合を例に取り説明する。第一のゲストＯＳ１１０が本番系システムとして稼働している場合には、以下説明する第二のゲストＯＳ１２０の各手段が実行する各種処理を、第一のゲストＯＳ１１０の各手段が実行することになる。

ステップＳ６０１では、第二のゲストＯＳ１２０の状態同期手段１２４は、本番系システムとして動作している第一のゲストＯＳ１１０の動作ログ１１５から第二のゲストＯＳ１２０で実行すべき処理内容７０４を抽出する。実行すべき処理内容７０４は、ステップＳ３０３、もしくは、ステップＳ３０４で第一のゲストＯＳ１１０で実行されたユーザ操作処理の中で、第二のゲストＯＳ１２０で未だ実行されていない処理になる。これは、識別子７０２をキーに、第一のゲストＯＳ１１０の動作ログ１１５と第二のゲストＯＳ１２０の動作ログ１２５を比較し、第二のゲストＯＳ１２０で未だ処理していない処理内容７０４を取得する。次に、取得した処理内容７０４の中から、処理種別７０３＝“ＵＳＥＲ＿ＯＰＥ”の処理を抽出すればよい。尚、処理内容７０４の抽出方法は、動作ログ１１５を参照せずに制御手段１１１に問い合わせてもよい。

ステップＳ６０２では、第二のゲストＯＳ１２０の制御手段１２１は、ステップＳ６０１で抽出した処理内容７０４が、画像処理か否かを判定する。画像処理の場合はステップＳ６０３に進み、画像処理以外の場合はステップＳ６０６に進む。

ステップＳ６０３では、第二のゲストＯＳ１２０の制御手段１２１は、第二の画像処理手段１２７で画像処理を実行する。但し、第二の画像処理手段１２７は、ＧＰＵで画像処理プログラムを実行せずに、ＣＰＵを使って該当画像処理プログラムを模擬したスタブプログラム（スタブコード）を実行する。スタブプログラムでは、第一のゲストＯＳ１１０で施された画像処理の処理結果７０５を識別子７０２及び、処理内容７０４をキーにして、動作ログ１１５から取得する。尚、処理結果７０５の抽出方法は、動作ログ１１５を参照せずに制御手段１１１に問い合わせてもよい。

また、ホットスタンバイ方式の場合、本番系システムと待機系システムは同じ処理をほぼ同じタイミングで実行するため、本番系システムの第一の画像処理手段が画像処理を完了するまで待機系システムの第二の画像処理手段は処理結果を取得することができない。そのため、第二の画像処理手段は、本番系システムの動作ログから画像処理の処理結果を取得できるまで定期的にスタブプログラムを実行し、動作ログを参照する。第二の画像処理手段がスタブプログラムを実行する間隔は、本番系システムと待機系システムの同期処理に影響を及ぼさない程度の間隔であればよい。第二の画像処理手段が本番系システムの制御手段に処理結果を問い合わせる場合も同様である。

ステップＳ６０４では、第二のゲストＯＳ１２０の制御手段１２１は、画像処理以外の処理を実行する。ステップＳ６０４の処理は、前述したステップＳ３０３と同様であるため、詳細な説明は省略する。但し、前述したように、本番系システムの表示内容を前面に表示するため、待機系システムの表示内容は本番系システムの表示内容よりも背面に表示されるか、コンピュータモニタには表示されない。尚、既に、画像データ１３１がホストＯＳ１３０の所定の場所に格納されている場合は、他のゲストＯＳで受信完了したと判断し、受信した画像データ１３１を破棄する。もしくは、バックアップとして残しておいてもよい。

ステップＳ６０５では、第二のゲストＯＳ１２０の制御手段１２１は、本番系システムに移行するか否かを判定する。ステップＳ３１０で発行された処理切替手段１３７からの本番系システムへの移行通知が届いている場合はステップＳ６０７に進み、届いていない場合はステップＳ６０６に進む。

ステップＳ６０６では、第二のゲストＯＳ１２０の制御手段１２１は、検査処理が終了したか否かを判定する。すなわち、ステップＳ６０１で抽出すべき未処理の処理内容が存在するか否かを判定する。検査処理が終了した場合は待機系システムの動作が終了し、検査処理が終了していない場合はステップＳ６０１に進む。

ステップＳ６０７では、第二のゲストＯＳ１２０の第二の画像処理手段１２７は、ステップＳ６０３で取得した第一のゲストＯＳ１１０で施された画像処理の処理結果７０５に基づき、ステップＳ３０４で実施された画像処理が成功したか否かを判定する。成功している場合は処理結果７０５を制御手段１２１に通知してからステップＳ６０９に進み、エラーの場合（すなわち、失敗している場合）は、ステップＳ６０８に進む。

ステップＳ６０８では、第二のゲストＯＳ１２０の制御手段１２１は、第一の画像処理手段１２６を用いて、画像データ１３１に画像処理を施す。第一の画像処理手段１２６は、ステップＳ３０４と同様に、ＧＰＵで画像処理プログラムを実行することで階調処理、ノイズ低減処理等の画像処理を施す。

画像処理が終了すると第一の画像処理手段１２６は処理結果（画像処理が成功したか否かを示す情報）を制御手段１２１に通知する。この通知を受けると、制御手段１２１は、タイムスタンプ７０１、識別子７０２、処理種別７０３、処理内容７０４、処理結果７０５等の情報を動作ログ１２５に出力する。ステップＳ６０７で制御手段１２１が第二の画像処理手段１２７から処理結果７０５の通知を受けた場合も同様である。

ステップＳ６０９では、ホストＯＳ１３０は、第二のゲストＯＳ１２０を本番系システムとして稼働させる。そして、本番系検査処理を実行させる。本番系検査処理の詳細は、図３を用いて前述した通りである。

このように、本番系システム（第一のゲストＯＳ１１０）の画像処理が失敗した場合に、待機系システム（第二のゲストＯＳ１２０）で第一の画像処理手段１２６を用いた画像処理を行うことで、ホットスタンバイ方式を実現する。また、ステップＳ６０３で、画像処理にスタブプログラムを用いることで、本番系システムの処理を妨害することなく、本番系システム（第一のゲストＯＳ１１０）と待機系システム（第二のゲストＯＳ１２０）の状態を同期させることができる。

図８は、図３の本番系検査処理の別の実施形態を示す。前述した実施形態では、スナップショット取得ポイントを手動または自動で決定しておき、スナップショット取得ポイントの一覧に基づき、ステップＳ３０６において、スナップショット取得ポイントに到達したか否かを判定した。一方、無効被ばくを抑止するにはＸ線センサ等から送信された画像データの受信が完了したタイミングでスナップショットを取得することが望ましい。これにより、画像データに対する画像処理でエラーが発生した場合であっても、画像データの受信が完了した後の処理から再開することができるため、無効被ばくを抑止できる。図８に示す別の実施形態は、これを実現するための処理の流れを示す。

図８を用いて本番系検査処理の別の実施形態の動作の流れを説明する。尚、図８の破線で示すステップＳ８０１及びステップＳ８０２以外の処理や医用画像診断装置の機能構成、データ構成、画面構成等は、前述した実施形態と同様であるので説明を省略する。

ステップＳ８０１では、ホストＯＳ１３０のスナップショット取得手段１３３は、本番系システムが、Ｘ線センサ／検査プローブ１０１から送信された画像データの受信を完了したか否かを判定する。画像データの受信を完了した場合はステップＳ８０２に進み、画像データの受信を完了していない場合はステップＳ３０８に進む。尚、画像データの受信を完了したか否かの判定には動作ログ１１５を用いるか、もしくは、画像データの受信を完了した際に制御手段１１１がスナップショット取得手段１３３に通知する構成でも良い。

ステップＳ８０２では、ホストＯＳ１３０のスナップショット取得手段１３３は、第一のゲストＯＳ１１０のスナップショットデータ１３４を取得し、ホストＯＳ１３０が管理する医用画像診断装置１００のＨＤＤ等に保存する。すなわち、第一の処理手段で処理を行うためのデータを受信した場合に、当該データを受信したゲストＯＳのスナップショットを取得するスナップショット取得手段に相当する。換言すれば、第一の処理手段で処理を行うためのデータを受信した場合に、第一の処理手段で処理を実行するゲストＯＳのスナップショットを取得するスナップショット取得手段に相当する。尚、スナップショットデータの取得は、第一のゲストＯＳ１１０の動作を停止することなく取得することができる。

このように、Ｘ線センサ等から送信された画像データの受信が完了したタイミングでスナップショットを取得することにより、画像処理が失敗した場合でも無効被ばくを抑止することが可能となる。

以上説明したように、本開示の仕組みによれば、複数のゲストＯＳがホットスタンバイ方式で動作する医用画像診断装置において、当該医用画像診断装置が備える所定のハードウェアを複数のゲストＯＳにより同時に用いられないよう抑止することが可能となる。

（第一の変形例）
本実施形態では、医用画像診断装置１００が様々な構成を備えていたが、複数のゲストＯＳがホットスタンバイ方式で動作する医用画像診断装置１００が第一の処理手段と第二の処理手段と制御手段とを備える装置であってもよい。これにより、複数のゲストＯＳがホットスタンバイ方式で動作する医用画像診断装置において、当該医用画像診断装置が備える所定のハードウェアを複数のゲストＯＳにより同時に用いられないよう抑止することが可能となる。

（第二の変形例）
また、複数のゲストＯＳがホットスタンバイ方式で動作する医用画像診断装置１００が第一の処理手段と第二の処理手段と制御手段と、更にスナップショット取得手段を備える装置であってもよい。これにより、医用画像診断装置１００のゲストＯＳでエラーが発生した場合に備えて、データを受信したときの状態に戻すためのスナップショットを取得することが可能となる。

（第三の変形例）
また、複数のゲストＯＳがホットスタンバイ方式で動作する医用画像診断装置１００が第一の処理手段と第二の処理手段と制御手段とスナップショット取得手段と、更に復旧手段を備える装置であってもよい。これにより、医用画像診断装置１００にエラーが発生したとしても、ゲストＯＳを、データを受信したときの状態に復元することが可能となる。

（第四の変形例）
また、複数のゲストＯＳがホットスタンバイ方式で動作する医用画像診断装置１００が第一の処理手段と第二の処理手段と制御手段とスナップショット取得手段と復旧手段と、更に同期手段を備える装置であってもよい。これにより、復旧したゲストＯＳの動作状態を本番系システムとして動作するゲストＯＳの動作状態と同期させることが可能となる。

（その他の実施例）
尚、本開示の仕組みは、複数の機器から構成されるシステムの１部として適用しても、１つの機器からなる装置の１部に適用してもよい。

また、本発明は上記実施形態を実現するための装置及び方法のみに限定されるものではない。

例えば、上記システム又は装置内のコンピュータ（ＣＰＵ或いはＭＰＵ）に、上記実施形態を実現（実行可能と）するためのソフトウェアのプログラムコードを供給するものも本開示の仕組みの範疇に含まれる。また、このプログラムコードに従って上記システム或いは装置のコンピュータが上記各種デバイスを動作させることにより上記実施例を実現する場合も本開示の仕組みの範疇に含まれる。

この場合、前記ソフトウェアのプログラムコード自体が上記実施形態の機能を実現することになる。即ち、そのプログラムコード自体、及びそのプログラムコードをコンピュータに供給するための手段、具体的には上記プログラムコードを格納した記憶媒体も本開示の仕組みの範疇に含まれる。

この様なプログラムコードを格納する記憶媒体としては、例えばフレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＤＶＤ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。

また、本開示の仕組みは上記プログラムコードのみに従って各種デバイスを制御することにより、上記実施形態の機能が実現される場合に限らない。例えば、上記プログラムコードがコンピュータ上で稼働しているＯＳ（オペレーティングシステム）、或いは他のアプリケーションソフト等と共同して上記実施形態が実現される場合も本開示の仕組みの範疇に含まれる。

更に、コンピュータの機能拡張ボードに備わるメモリに格納された上記プログラムコードの指示に基づいて、その機能拡張ボードに備わるＣＰＵ等が実際の処理の一部または全部を行う場合なども本開示の仕組みの範疇に含まれる。

なお、前述した実施形態は、本開示の仕組みを実施するにあたっての具体化の例を示したものに過ぎず、これらによって本開示の仕組みの技術的範囲が限定的に解釈されてはならないものである。即ち、本開示の仕組みはその技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。

１００ 医用画像診断装置
１１０ 第一のゲストＯＳ
１１１ 制御手段
１１４ 状態同期手段
１１６ 第一の画像処理手段
１１７ 第二の画像処理手段
１２０ 第二のゲストＯＳ
１２１ 制御手段
１２４ 状態同期手段
１２６ 第一の画像処理手段
１２７ 第二の画像処理手段
１３０ ホストＯＳ
１３３ スナップショット取得手段
１３６ システム復旧手段

Claims (13)

1. 複数のゲストＯＳがホットスタンバイ方式で動作する医用画像診断装置であって、
   前記医用画像診断装置が備える所定のハードウェアを用いた処理を実行し、当該処理の実行結果を出力する第一の処理手段と、
   前記ハードウェアを用いた処理を実行せずに、前記第一の処理手段の前記実行結果を出力する第二の処理手段と、
   本番系システムとして動作するゲストＯＳには前記第一の処理手段による処理を実行させ、待機系システムとして動作するゲストＯＳには前記第一の処理手段による処理を実行させずに、前記第二の処理手段による処理を実行させる制御手段と
   を備えることを特徴とする医用画像診断装置。
2. 前記制御手段は、前記本番系システムとして動作するゲストＯＳでエラーが発生した場合に、前記本番系システムとして動作するゲストＯＳには前記第一の処理手段による処理を実行させずに、前記第二の処理手段による処理を実行させ、前記待機系システムとして動作するゲストＯＳには前記第一の処理手段による処理を実行させることを特徴とする請求項１に記載の医用画像診断装置。
3. 前記第一の処理手段で前記処理を行うためのデータを受信した場合に、当該データを受信したゲストＯＳのスナップショットを取得するスナップショット取得手段
   を更に備えることを特徴とする請求項１または２に記載の医用画像診断装置。
4. 前記本番系システムとして動作するゲストＯＳまたは前記待機系システムとして動作するゲストＯＳでエラーが発生した場合に、前記スナップショットを用いて復旧する復旧手段
   を更に備えることを特徴とする請求項３に記載の医用画像診断装置。
5. 前記本番系システムとして動作するゲストＯＳの動作ログを用いて、前記復旧したゲストＯＳの動作状態を前記本番系システムとして動作するゲストＯＳの動作状態と同期させる同期手段
   を更に備えることを特徴とする請求項４に記載の医用画像診断装置。
6. 前記第二の処理手段はスタブコードであることを特徴とする請求項１乃至５のいずれか１項に記載の医用画像診断装置。
7. 前記ハードウェアはＧＰＵであることを特徴とする請求項１乃至６のいずれか１項に記載の医用画像診断装置。
8. 複数のゲストＯＳがホットスタンバイ方式で動作する医用画像診断装置の制御方法であって、
   前記医用画像診断装置の第一の処理手段が、前記医用画像診断装置が備える所定のハードウェアを用いた処理を実行し、当該処理の実行結果を出力する第一の処理ステップと、
   前記医用画像診断装置の第二の処理手段が、前記ハードウェアを用いた処理を実行せずに、前記第一の処理ステップの前記実行結果を出力する第二の処理ステップと、
   前記医用画像診断装置の制御手段が、本番系システムとして動作するゲストＯＳには前記第一の処理ステップによる処理を実行させ、待機系システムとして動作するゲストＯＳには前記第一の処理ステップによる処理を実行させずに、前記第二の処理ステップによる処理を実行させる制御ステップと
   を備えることを特徴とする医用画像診断装置の制御方法。
9. 前記制御ステップは、前記本番系システムとして動作するゲストＯＳでエラーが発生した場合に、前記本番系システムとして動作するゲストＯＳには前記第一の処理ステップによる処理を実行させずに、前記第二の処理ステップによる処理を実行させ、前記待機系システムとして動作するゲストＯＳには前記第一の処理ステップによる処理を実行させることを特徴とする請求項８に記載の医用画像診断装置の制御方法。
10. 前記医用画像診断装置のスナップショット取得手段が、前記第一の処理ステップで前記処理を行うためのデータを受信した場合に、当該データを受信したゲストＯＳのスナップショットを取得するスナップショット取得ステップ
    を更に備えることを特徴とする請求項８または９に記載の医用画像診断装置の制御方法。
11. 複数のゲストＯＳがホットスタンバイ方式で動作する医用画像診断装置の制御方法を実行可能なプログラムであって、
    前記医用画像診断装置を、
    前記医用画像診断装置が備える所定のハードウェアを用いた処理を実行し、当該処理の実行結果を出力する第一の処理手段と、
    前記ハードウェアを用いた処理を実行せずに、前記第一の処理手段の前記実行結果を出力する第二の処理手段と、
    本番系システムとして動作するゲストＯＳには前記第一の処理手段による処理を実行させ、待機系システムとして動作するゲストＯＳには前記第一の処理手段による処理を実行させずに、前記第二の処理手段による処理を実行させる制御手段
    として機能させることを特徴とするプログラム。
12. 前記制御手段は、前記本番系システムとして動作するゲストＯＳでエラーが発生した場合に、前記本番系システムとして動作するゲストＯＳには前記第一の処理手段による処理を実行させずに、前記第二の処理手段による処理を実行させ、前記待機系システムとして動作するゲストＯＳには前記第一の処理手段による処理を実行させることを特徴とする請求項１１に記載のプログラム。
13. 前記医用画像診断装置を、
    前記第一の処理手段で前記処理を行うためのデータを受信した場合に、当該データを受信したゲストＯＳのスナップショットを取得するスナップショット取得手段
    として更に機能させることを特徴とする請求項１１または１２に記載のプログラム。

Images