(57)【要約】【課題】アプリケーションの実行中にハードウェアの異常を検出できる情報処理装置を提供する。【解決手段】この情報処理装置（１）は、中央演算処理装置（１１）、メモリ（１６）及び表示装置（１７）を含むハードウェアと、ハードウェアのリソースを複数に分割した第１論理パーティション（２１）と第２論理パーティション（２２）とを含む複数の論理パーティションを管理する仮想化部（２４）と、第１論理パーティションで動作し、ユーザ・アプリケーションがゲストＯＳを介して稼動される仮想マシン（３３）と、第２論理パーティションで動作し、ハードウェアの診断を行う診断モジュール（４１３）とを備える。【選択図】図２
2018147277.tif 000002
【特許請求の範囲】
【請求項１】
中央演算処理装置、メモリ及び表示装置を含むハードウェアと、
前記ハードウェアのリソースを複数に分割した第１論理パーティションと第２論理パーティションとを含む複数の論理パーティションを管理する仮想化部と、
前記第１論理パーティションで動作し、ユーザ・アプリケーションがゲストＯＳを介して稼動される仮想マシンと、
前記第２論理パーティションで動作し、前記ハードウェアの診断を行う診断モジュールと、
を備えることを特徴とする情報処理装置。
【請求項２】
前記診断モジュールは、前記ハードウェアを用いて検査用の処理を実行し、前記検査用の処理の結果と、前記検査用の処理に要した時間とに基づいて、前記ハードウェアの診断を行うことを特徴とする請求項１記載の情報処理装置。
【請求項３】
前記診断モジュールは、前記第２論理パーティションへの前記リソースの割当率を示す情報と、前記検査用の処理に掛かった実時間とから、前記ハードウェアにより前記検査用の処理に費やされたプロセス時間を計算し、前記プロセス時間を前記検査用の処理に要した時間と見なして前記ハードウェアの診断を行うことを特徴とする請求項２記載の情報処理装置。
【請求項４】
前記割当率を示す情報には、前記第２論理パーティションに割り当てられた前記中央演算処理装置のコア数、時分割によって前記第２論理パーティションにより専有される前記中央演算処理装置の時間、及び前記中央演算処理装置の動作クロック周波数が含まれることを特徴とする請求項３記載の情報処理装置。
【請求項５】
前記第２論理パーティションで動作し、前記診断モジュールにより診断の結果が異常である場合に、前記ハードウェアを用いて異常を報知する報知モジュールを備えることを特徴とする請求項１から請求項４のいずれか一項に記載の情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、鉄道分野などの高い安全性が要求される分野で使用されるタブレット端末などの情報処理装置に関する。
【背景技術】
【０００２】
鉄道の分野では、例えば鉄道設備の保守作業において、タブレット端末を用いて係員へ様々な情報支援を行うことがある。このような場合、タブレット端末が異常動作し、係員が異常動作に気付かないと、作業の継続が困難になるばかりでなく、係員の安全、列車の安全又は列車の安定した運行に支障が生じる恐れがある。
特許文献１には、端末装置の情報処理に異常が生じたときに、この異常を速やかに発見できるようにした技術が提案されている。特許文献１の端末装置では、１台の端末装置の中で情報処理が二重に行われ、二重の処理結果の表示が時分割で交互に出力される。これにより、一方の情報処理に異常動作があれば、交互の表示出力に差異が生じ、使用者は、異常動作に速やかに気付くことができる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開平６−１６１７９１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
タブレット端末の異常動作は、ＯＳ（Operating System）のエラーに起因するもの、ＯＳ上で動作するアプリケーション・プログラム（以下「アプリケーション」と略す。）のエラーに起因するものに加え、ハードウェアのエラーに起因するものがある。
ハードウェアのエラーによりＯＳ又はアプリケーションが停止した場合、これにより表示画像に変化が生じれば、タブレット端末の異常動作の発見が容易となる。しかしながら、表示画像の変化が無いままアプリケーション等が停止すると、異常動作の発見が遅れる場合がある。
【０００５】
また、特許文献１の技術のように情報処理を二重に行うといったソフトウェア対策だけでは、二重の情報処理の一方がエラーとなるような限られた条件のハードウェアエラーにしか対処することができない。従って、例えば、ＯＳが停止するようなハードウェアエラーが生じた場合、特許文献１の技術では、異常動作の発見が遅れる場合がある。
【０００６】
本発明は、アプリケーションの実行中にハードウェアの異常を検出できる情報処理装置を提供することを目的とする。さらに、本発明は、ハードウェアの異常の予兆を検出でき、これにより、ハードウェアエラーに起因してアプリケーションが異常動作する前に、情報処理装置を交換するなどフェールセーフな対応をとることのできる情報処理装置を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明は、上記目的を達成するため、
中央演算処理装置、メモリ及び表示装置を含むハードウェアと、
前記ハードウェアのリソースを複数に分割した第１論理パーティションと第２論理パーティションとを含む複数の論理パーティションを管理する仮想化部と、
前記第１論理パーティションで動作し、ユーザ・アプリケーションがゲストＯＳを介して稼動される仮想マシンと、
前記第２論理パーティションで動作し、前記ハードウェアの診断を行う診断モジュールと、
を備えることを特徴とする情報処理装置とした。
【０００８】
この構成によれば、ユーザ・アプリケーションが稼動する第１論理パーティションと異なる第２論理パーティションにおいて診断モジュールがハードウェアの診断を行う。従って、ユーザ・アプリケーションの実行中でも、ユーザ・アプリケーションの実行を妨げずにハードウェアの診断を行い、ハードウェアの異常の予兆を検出することができる。
【０００９】
ここで、前記診断モジュールは、前記ハードウェアを用いて検査用の処理を実行し、前記検査用の処理の結果と、前記検査用の処理に要した時間とに基づいて、前記ハードウェアの診断を行う構成とするとよい。
この構成によれば、処理結果に異常は生じないものの、例えばハードウェア内部のエラー訂正等の影響により検査用の処理に要した時間が長くなるような異常の予兆を検出することができる。そして、予兆の段階で異常を検出することで、ハードウェアが異常動作してユーザ・アプリケーションが停止してしまうような状況を回避することができる。
【００１０】
さらに、前記診断モジュールは、前記第２論理パーティションへの前記リソースの割当率を示す情報と、前記検査用の処理に掛かった実時間とから、前記ハードウェアにより前記検査用の処理に費やされたプロセス時間を計算し、前記プロセス時間を前記検査用の処理に要した時間と見なして前記ハードウェアの診断を行う構成としてもよい。
【００１１】
例えば中央演算処理装置のリソースが分割されて第１論理パーティションと第２論理パーティションとに割り当てられている場合を想定する。この場合、第２論理パーティションのリソースを用いて検査用の処理を実行すると、検査用の処理に掛かった実時間は、第２論理パーティションへのリソースの割当率に応じて変化する。そこで、上記の構成によれば、ハードウェアが検査用の処理に費やしたプロセス時間に基づいてハードウェアの診断を行う。これにより、ユーザ・アプリケーションが動作している状態でも、検査用の処理に要した時間を適切に判定し、ハードウェアの診断を正確に行うことができる。
【００１２】
さらに、前記割当率を示す情報には、前記第２論理パーティションに割り当てられた前記中央演算処理装置のコア数、時分割によって前記第２論理パーティションにより専有される前記中央演算処理装置の時間、及び前記中央演算処理装置の動作クロック周波数が含まれる構成としてもよい。
このような構成により、複数のコアを含み、動作クロック周波数が可変な情報処理装置に対応して、ハードウェアの診断を正確に行うことができる。
【００１３】
さらに、本発明に係る情報処理装置は、前記第２論理パーティションで動作し、前記診断モジュールにより診断の結果が異常である場合に、前記ハードウェアを用いて異常を報知する報知モジュールを備えてもよい。
この構成によれば、ハードウェアエラーにより情報処理装置が異常動作する前に、ハードウェアの異常の予兆を使用者に報知することができる。これにより、ユーザは、情報処理装置の交換を行うなどのフェールセーフな対応をとることができる。
【発明の効果】
【００１４】
本発明によれば、アプリケーションの実行中にハードウェアの異常の予兆を検出でき、これにより、ハードウェアエラーに起因してアプリケーションが異常動作する前に、情報処理装置を交換するなどフェールセーフな対応をとることができる。
【図面の簡単な説明】
【００１５】
【図１】本発明の実施形態に係る情報処理装置を示す構成図である。
【図２】本発明の実施形態に係る情報処理装置の論理構造を示す構成図である。
【図３】ＣＰＵの診断処理の流れを示すシーケンス図である。
【図４】診断モジュールにより実行されるＣＰＵの診断処理の手順を示すフローチャートである。
【図５】メモリの診断処理の流れを示すシーケンス図である。
【図６】診断モジュールにより実行されるメモリの診断処理の手順を示すフローチャートである。
【発明を実施するための形態】
【００１６】
以下、本発明の実施の形態について図面を参照して詳細に説明する。
図１は、本発明の実施形態に係る情報処理装置を示す構成図である。図２は、本発明の実施形態に係る情報処理装置の論理構造を示す構成図である。
本発明の実施形態に係る情報処理装置１は、例えばタブレット端末であり、図１に示すように、ＣＰＵ（Central Processing Unit：中央演算処理装置）１１、不揮発性メモリ１２、メモリ１６、表示装置１７、タッチパネル１８及び通信装置１９を備える。表示装置１７は、例えば液晶ディスプレイなどの画像表示が可能な装置である。タッチパネル１８は表示装置１７上に設けられ、指又はデジタルペンなどを近接させることで近接した位置の情報を入力できる入力装置である。
【００１７】
不揮発性メモリ１２には、仮想化環境を構築する仮想化ＯＳプログラム１３が格納され、さらに、仮想マシン記憶部１４と、監視パーティション記憶部１５とが設けられる。仮想マシン記憶部１４には、ゲストＯＳプログラム３２ａとユーザ・アプリケーション３１とが格納される。監視パーティション記憶部１５には、監視ソフトウェア４１が格納される。
【００１８】
＜仮想化システムの構成＞
情報処理装置１の起動時、ＣＰＵ１１は、先ず、仮想化ＯＳプログラム１３を実行する。これにより、図２に示すように、仮想化部２４、仮想化部インタフェース５２、サービス・ソフトウェア５１、仮想マシン３３及び高信頼型アプリケーション・インタフェース４２が実現される。以下、アプリケーション・インタフェースを「ＡＰＩ」と記す。
【００１９】
仮想化部２４は、ハードウェア・リソース２５を時分割或いは複数の領域に分割した複数の論理パーティションを構築し、これらの管理を行う。複数の論理パーティションには、ゲストパーティション（第１論理パーティションに相当）２１、監視パーティション２２（第２論理パーティションに相当）及びシステムパーティション２３が含まれる。また、仮想化部２４は、各パーティション間のデータの送受信を行う。ゲストパーティション２１と監視パーティション２２とは、仮想化部２４を介してデータの送受信が可能である他、互いに独立している。従って、ゲストパーティション２１で情報処理上の異常が発生しても、この異常が監視パーティション２２の情報処理へ容易に波及することはない。
【００２０】
仮想化部インタフェース５２は、サービス・ソフトウェア５１と仮想化部２４又はハードウェア・リソース２５とを結ぶためのＡＰＩを有するサブシステムである。サービス・ソフトウェア５１は、仮想化環境の管理のために仮想化部２４が利用する各種のサービスを提供する。
【００２１】
仮想マシン３３は、ゲストパーティション２１上で動作し、ハードウェア・リソース２５を模擬して、ゲストＯＳ３２とハードウェア・リソース２５とを結ぶソフトウェアである。仮想マシン３３は、１つの情報処理装置のように振る舞うことで、ゲストＯＳ３２は仮想マシン３３上で稼動する。仮想マシン３３は、ゲストパーティション２１に割り当てられたハードウェア・リソース２５に加え、仮想化部２４と通信を行うための機能モジュールを備える。ゲストＯＳ３２は、この機能モジュールを駆動するためのドライバがインストールされることで、機能モジュールを介して仮想化部２４と通信を行うことが可能となる。
【００２２】
高信頼型ＡＰＩ４２は、監視パーティション２２上のソフトウェアと仮想化部２４又はハードウェア・リソース２５とを結ぶための高信頼型のＡＰＩを有するサブシステムである。高信頼型のＡＰＩとしては、例えばＰＯＳＩＸ（Portable operating system interface）などを採用できる。
【００２３】
＜ゲストパーティション＞
ゲストパーティション２１においては、ＣＰＵ１１の分割されたリソースが、仮想マシン記憶部１４のゲストＯＳプログラム３２ａを実行する。これにより、図２に示すように、仮想マシン３３上でゲストＯＳ３２が動作する。さらに、ＣＰＵ１１の分割されたリソースは、ゲストＯＳ３２において仮想マシン記憶部１４のユーザ・アプリケーション３１を実行する。これにより、ゲストＯＳ３２上でユーザ・アプリケーション３１が動作する。図２においてユーザ・アプリケーション３１は、メモリ１６に展開されてＣＰＵ１１によって実行されているプロセスの状態を表わしている。
【００２４】
ゲストＯＳ３２は、例えば一般的なタブレット端末用のＯＳである。ゲストＯＳ３２は、仮想マシン３３を１つの物理マシンのように認識し、１つの物理マシン上で動作するときと同様に動作する。さらに、ゲストＯＳ３２には、仮想化部２４とデータの送受信を行うための機能モジュールのドライバが組み込まれ、これにより、ゲストＯＳ３２と仮想化部２４との間でデータの送受信が可能となる。
ユーザ・アプリケーション３１は、例えば、鉄道設備の保守作業を支援する支援ソフトウェアである。ユーザ・アプリケーション３１は、１つの物理マシン上で動作する場合と同様に、仮想マシン３３上で動作する。
【００２５】
＜監視パーティション＞
監視パーティション２２においては、ＣＰＵ１１の分割されたリソースが、監視パーティション記憶部１５の監視ソフトウェア４１を実行する。これにより、高信頼型ＡＰＩ４２上で監視ソフトウェア４１が動作する。図２において監視ソフトウェア４１は、メモリ１６に展開されてＣＰＵ１１によって実行されているプロセスの状態を表わしている。
監視ソフトウェア４１は、主にユーザ・アプリケーション３１の動作の監視と異常報知とを行う。監視ソフトウェア４１は、図２に示すように、キープ・アライブ・モジュール４１１、報知モジュール４１２、診断モジュール４１３、ロギングモジュール４１４、演算照合モジュール４１５及び状態監視（health monitor）モジュール４１６を備える。
【００２６】
キープ・アライブ・モジュール４１１は、ゲストパーティション２１上のアプリケーションと繰り返し通信を行って、アプリケーションの動作確認を行う。
診断モジュール４１３は、情報処理装置１の起動時と動作中とにハードウェアの診断処理を行う。
ロギングモジュール４１４は、仮想マシン３３上のゲストＯＳ３２と通信を行って、ユーザ・アプリケーションによる通信等のアクセスログ及び操作ログの収集および保存を行う。
【００２７】
報知モジュール４１２は、例えば表示装置１７の出力によって使用者に報知を行う。監視パーティション２２には、ゲストパーティション２１よりも高い優先度で表示装置１７のリソースが割り当てられている。これにより、仮にゲストパーティション２１から表示装置１７に画像出力が行われているときであっても、報知モジュール４１２はこの画像に上書きするように表示装置１７に画像を出力することができる。情報処理装置１が振動装置又は表示ランプなどの報知デバイスを有する場合には、報知モジュール４１２はこれらの報知デバイスを動作させて報知を行ってもよい。
【００２８】
演算照合モジュール４１５は、ユーザ・アプリケーション３１から照合要求がなされた処理について自ら同様の処理を行って処理結果を照合する。演算照合モジュール４１５は、この照合の処理によりユーザ・アプリケーション３１の異常動作を検出する。
状態監視モジュール４１６は、監視パーティション２２内で生じた例外又はタイムアウトに応じた所定の処理を実行する。
【００２９】
＜ＣＰＵ診断処理＞
続いて、診断モジュール４１３によるＣＰＵ１１の診断処理について、フローチャートとシーケンス図とを参照しながら説明する。
図３は、ＣＰＵの診断処理の流れを示すシーケンス図である。図４は、診断モジュールにより実行されるＣＰＵの診断処理の手順を示すフローチャートである。
【００３０】
診断モジュール４１３は、図３に示すように、ユーザ・アプリケーション３１が実行されている間、ＣＰＵ１１の診断処理Ｊ１、Ｊ１ａを定期的に繰り返し実行する。診断処理Ｊ１、Ｊ１ａが開始されると、先ず、診断モジュール４１３は検査処理Ｊ２を実行する。検査処理Ｊ２において診断モジュール４１３は、実時間の計測を開始し（図４のステップＳ１１）、所定の演算処理を実行し（ステップＳ１２）、実時間Ｔ１の計測を終了する（ステップＳ１３）。
【００３１】
検査処理Ｊ２が終了すると、診断モジュール４１３は、演算結果が正常か否かを判別する（ステップＳ１４）。その結果、診断モジュール４１３は、正常な演算結果が得られなければ異常と判定する。一方、演算結果が正常である場合、続いて、診断モジュール４１３は、検査処理Ｊ２に要した時間からＣＰＵ１１に異常の予兆が無いか判定する。
【００３２】
一般に、ＣＰＵ１１及びメモリ１６には、内部に記憶されたデータの一部が反転されるようなエラーが生じても、デバイス内でこれを検出しかつ訂正を行うエラー訂正機能が備わる。そして、エラーがある場合と無い場合とで処理に費やす時間が変化する。また、メモリ１６には、不良となったブロックを管理対象から外し、以後に使用されないようにする機能が備わるものがあり、不良ブロックが検出された際には、これに対処するための処理により時間が費やされる。さらに、不揮発性の領域を有するメモリ１６の場合では、セルの劣化によって不揮発性の領域の書込時間が長くなることがある。このような機能及び作用があるため、劣化によりハードウェアエラーが生じるような場合には、その前段でハードウェア内部のエラー訂正の動作等により、処理に要する時間が長くなる。
【００３３】
そこで、診断モジュール４１３は、ＣＰＵ１１がステップＳ１２の演算処理に要した時間に基づいてＣＰＵ１１に異常の予兆が無いか判定する。しかし、ＣＰＵ１１は、ステップＳ１２の演算処理を、ユーザ・アプリケーション３１の処理と並列して実行している。従って、ステップＳ１２の演算処理の開始から終了までに掛かった実時間には、ＣＰＵ１１がユーザ・アプリケーション３１の処理に費やした時間が含まれる。すなわち、ＣＰＵ１１が内部でエラー訂正等が行われずに、正常にステップＳ１２の演算処理を実行したとしても、監視パーティション２２へのＣＰＵ１１のリソースの割当率に基づいて、処理に掛かった実時間が変化する。
【００３４】
そこで、診断モジュール４１３は、先ず、監視パーティション２２のＣＰＵ１１のリソースの割当率μを仮想化部２４から読み出す（ステップＳ１５）。割当率の情報には、監視パーティション２２に割り当てられたＣＰＵ１１のコア数、時分割により割り当てられたＣＰＵ時間、演算処理中の動作クロック周波数が含まれる。ＣＰＵ時間とは、時分割により監視パーティション２２の処理が専有するＣＰＵ１１の時間を意味する。監視パーティション２２に割り当てられたＣＰＵ１１のリソースの割当率μは、例えば、コア数、ＣＰＵ時間、ＣＰＵ１１の動作クロック周波数の各要素の割当率を乗算して数値化することができる。ここで、コア数の割当率は、最大のコア数に対する、割り当てられたコア数の割合により表わせばよい。また、ＣＰＵ時間の割当率は、割り当てられた時分割の割合により表わせばよい。動作クロックの周波数の割当率は、最速となる周波数に対する演算処理中の周波数の割合により表わせばよい。
【００３５】
次に、診断モジュール４１３は、ステップＳ１３で計測された実時間Ｔ１と割当率μとからステップＳ１２の演算処理に費やされたＣＰＵ１１のプロセス時間Ｔｐを計算する（ステップＳ１６）。プロセス時間Ｔｐは、例えば実時間Ｔ１と割当率μとを乗算して得られる。プロセス時間Ｔｐを計算したら、診断モジュール４１３は、プロセス時間ＴｐがＣＰＵ１１の異常の予兆と判断できる閾値Ｔｔｈ１と比較する（ステップＳ１７）。ここで、プロセス時間Ｔｐが閾値Ｔｔｈ１以下であれば判定結果は正常となり、閾値Ｔｔｈ１より長ければ判定結果は異常となる。
【００３６】
ステップＳ１７の結果がＹＥＳであれば、診断モジュール４１３は、正常の判定により１回の診断処理Ｊ１を終了する。ステップＳ１７の結果がＮＯであれば、診断モジュール４１３は、異常の判定により、仮想化部２４へゲストパーティション２１の停止要求を行い（ステップＳ１８）、報知モジュール４１２へＣＰＵ１１の異常を報知する表示要求を行う（ステップＳ１９）。そして、診断処理Ｊ１ａが終了される。
【００３７】
図３の異常の予兆が検出された診断処理Ｊ１ａのシーケンスに示すように、仮想化部２４へゲストパーティション停止要求が発行されると、仮想化部２４は、ゲストパーティション２１へのハードウェア・リソース２５の割当を停止する。これにより、仮想マシン３３、ゲストＯＳ３２、ユーザ・アプリケーション３１が停止する。さらに、異常判定Ｊ３がなされて報知モジュール４１２へ異常を報知する表示要求がなされると、報知モジュール４１２が表示装置１７へ例えば「ＣＰＵ異常」などの異常を報知する画像出力を行う。このとき、たとえ表示装置１７にユーザ・アプリケーション３１の画像出力が行われていても、報知モジュール４１２はこの画像に上書きするように異常を報知する画像出力を行うことができる。なお、情報処理装置１が振動装置又は表示ランプなどの報知デバイスを有する場合には、報知モジュール４１２はこれらの報知デバイスを動作させて報知を行ってもよい。
【００３８】
＜メモリ診断処理＞
続いて、診断モジュール４１３によるメモリ１６の診断処理について、フローチャートとシーケンス図とを参照しながら説明する。
図５は、メモリの診断処理の流れを示すシーケンス図である。図６は、診断モジュールにより実行されるメモリの診断処理の手順を示すフローチャートである。
【００３９】
診断モジュール４１３は、図５に示すように、ユーザ・アプリケーション３１が実行されている間、メモリ１６の診断処理Ｊ５、Ｊ５ａを定期的に繰り返し実行する。診断処理Ｊ５、Ｊ５ａが開始されると、先ず、診断モジュール４１３は検査処理Ｊ６を実行する。メモリ１６の検査処理Ｊ６において診断モジュール４１３は、実時間の計測を開始し（図６のステップＳ２１）、メモリ１６に所定のリード・ライト処理を実行し（ステップＳ２２）、実時間Ｔ１の計測を終了する（ステップＳ２３）。リード・ライト処理において診断モジュール４１３は、監視パーティション２２に割り当てられたメモリ１６の領域に、所定のビットパターンのデータを書き込み、その後、このデータを読み出す。
【００４０】
検査処理Ｊ６が終了すると、診断モジュール４１３は、処理結果が正常か否かを判別する（ステップＳ２４）。すなわち、診断モジュール４１３は、読み出したデータのビットパターンが書き込んだものと同一か否かを判別する。同一であれば正常を示し、異なれば異常を示す。判別の結果、診断モジュール４１３は、正常な処理結果が得られなければ異常と判定する。一方、処理結果が正常である場合、診断モジュール４１３は、検査処理Ｊ６に要したプロセス時間Ｔｐからメモリ１６に異常の予兆が生じていないか判定する。
【００４１】
上述したように、メモリ１６にハードウェアエラーが生じるような場合には、その前段でメモリ１６の内部のエラー訂正の動作、或いは、不揮発性の領域への書込み時間の増大により、メモリ１６へのリード・ライト処理に要する時間が長くなる。また、リード・ライト処理に掛かる実時間は、監視パーティション２２に割り当てられるハードウェア・リソースの割当率、具体的にはＣＰＵ１１のリソースの割当率に基づいて変化する。
【００４２】
従って、診断モジュール４１３は、ＣＰＵ１１がステップＳ２２のリード・ライト処理に要したプロセス時間Ｔｐに基づいてメモリ１６の異常の予兆の有無を判定する。検査処理Ｊ６を実行したら、診断モジュール４１３は、監視パーティション２２のＣＰＵ１１のリソースの割当率μを仮想化部２４から読み出す（ステップＳ２５）。割当率μは、図４で示したものと同一である。
【００４３】
次に、診断モジュール４１３は、ステップＳ２３で計測された実時間Ｔ１と割当率μとからステップＳ２２のリード・ライト処理に費やされたＣＰＵ１１のプロセス時間Ｔｐを計算する（ステップＳ２６）。プロセス時間Ｔｐは、例えば実時間Ｔ１と割当率μとを乗算して得ることができる。続いて、診断モジュール４１３は、プロセス時間Ｔｐがメモリ１６の異常の予兆と判断できる閾値Ｔｔｈ２と比較する（ステップＳ２７）。ここで、プロセス時間Ｔｐが閾値Ｔｔｈ２以下であれば判定結果は正常となり、閾値Ｔｔｈ２より長ければ判定結果は異常となる。
【００４４】
ステップＳ２７の結果がＹＥＳであれば、診断モジュール４１３は、正常の判定により１回の診断処理Ｊ５を終了する。ステップＳ２７の結果がＮＯであれば、診断モジュール４１３は、異常の判定により、仮想化部２４へゲストパーティション２１の停止要求を行い（ステップＳ２８）、報知モジュール４１２へメモリ１６の異常を報知する表示要求を行う（ステップＳ２９）。そして、診断処理Ｊ５ａが終了される。
【００４５】
図５の異常の予兆が検出された診断処理Ｊ５ａのシーケンスに示すように、仮想化部２４へゲストパーティション停止要求が発行されると、仮想化部２４は、ゲストパーティション２１へのハードウェア・リソース２５の割当を停止する。これにより、仮想マシン３３、ゲストＯＳ３２、ユーザ・アプリケーション３１が停止する。さらに、異常判定Ｊ７がなされて報知モジュール４１２へ異常を報知する表示要求がなされると、報知モジュール４１２が表示装置１７へ例えば「メモリ異常」などの異常を報知する画像出力を行う。このとき、たとえ表示装置１７にユーザ・アプリケーション３１の画像出力が行われていても、報知モジュール４１２はこの画像に上書きするように異常を報知する画像出力を行うことができる。なお、情報処理装置１が振動装置又は表示ランプなどの報知デバイスを有する場合には、報知モジュール４１２はこれらの報知デバイスを動作させて報知を行ってもよい。
【００４６】
以上のように、本実施形態の情報処理装置１によれば、ユーザ・アプリケーション３１が稼動するゲストパーティション２１と異なる監視パーティション２２において、診断モジュール４１３がハードウェアの診断を行う。従って、ユーザ・アプリケーション３１の実行中でも、この実行を妨げることなくハードウェアの診断を行って、ハードウェアの異常の予兆を検出することができる。
また、本実施形態の情報処理装置１によれば、診断モジュール４１３は、検査処理Ｊ２、Ｊ６の処理結果だけでなく、検査処理Ｊ２、Ｊ６に要した時間に基づいてハードウェアの診断を行う。したがって、処理結果に異常が生じないものの、ハードウェア内部のエラー訂正等の影響により処理時間が長くなるようなハードウェアの異常の予兆を検出することができる。これにより、ハードウェアが異常動作してユーザ・アプリケーション３１が停止してしまうような状況を事前に回避できる。例えば、使用者は、ユーザ・アプリケーション３１に異常が生じる前に、異常の予兆により情報処理装置１を再起動したり、情報処理装置１を交換したりするなどフェールセーフな対応をとることができる。
【００４７】
さらに、本実施形態の情報処理装置１によれば、診断モジュール４１３は、監視パーティション２２に割り当てられているハードウェアの割当率、具体的にはＣＰＵ１１のリソースの割当率μを取得する。そして、診断モジュール４１３は、検査処理Ｊ２に掛かった実時間Ｔ１と割当率μとから、検査処理Ｊ２に要したプロセス時間Ｔｐを計算し、プロセス時間Ｔｐに基づいてハードウェアの診断を行う。このような処理により、ユーザ・アプリケーション３１の実行に要する時間を除いて検査処理Ｊ２に要した時間を求めることができ、ハードウェアの診断を正確に行うことができる。
【００４８】
以上、本発明の各実施の形態について説明したが、本発明は上記の実施の形態に限られるものではない。例えば、上記実施形態では、ハードウェアの診断処理として診断モジュール４１３がＣＰＵ１１とメモリ１６との診断処理を行う例を示した。しかし、診断対象は、ＣＰＵ１１又はメモリ１６に限られず、通信装置１９又は不揮発性メモリ１２など様々なハードウェアについても同様に診断対象とすることができる。また、上記実施形態では、監視ソフトウェア４１は、ハードウェアの異常と判定した場合に、報知モジュール４１２によって使用者に異常を報知する構成を例にとって説明した。しかし、監視ソフトウェア４１に、使用者に報知する以外のフェールセーフを実現するための処理を行う機能モジュールが設けられる場合、監視ソフトウェア４１は、動作異常が確認された場合に、上記の機能モジュールを駆動する構成を採用してもよい。
【００４９】
また、上記実施形態では、ハードウェア・リソースの割当率を示す情報として、ＣＰＵ１１のコア数、ＣＰＵ時間、ＣＰＵ１１の動作クロックの周波数を例に挙げた。しかし、論理パーティションへのコアの割当ができないＣＰＵ、或いは、動作クロックの周波数が一定のＣＰＵを用いている場合には、割当率を示す情報からコア数又は動作クロックの周波数の情報が省かれてもよい。また、ＣＰＵ１１のコア数、ＣＰＵ時間、動作クロックの周波数の他に、割当率によって検査用の処理の時間に影響が生じるハードウェア・リソースがあれば、このリソースの割当率が考慮されてプロセス時間Ｔｐが計算されてもよい。また、仮想化部は、ハイパーバイザー型であっても、ホストＯＳ型であってもよい。その他、実施の形態で示した細部は、発明の趣旨を逸脱しない範囲で適宜変更可能である。
【符号の説明】
【００５０】
１  情報処理装置
１１  ＣＰＵ
１２  不揮発性メモリ
１３  仮想化ＯＳプログラム
１４  仮想マシン記憶部
１５  監視パーティション記憶部
１６  メモリ
１７  表示装置
１８  タッチパネル
１９  通信装置
２１  ゲストパーティション（第１論理パーティション）
２２  監視パーティション（第２論理パーティション）
２３  システムパーティション
２５  ハードウェア・リソース
３１  ユーザ・アプリケーション
３２  ゲストＯＳ
３３  仮想マシン
３２ａ  ゲストＯＳプログラム
４１  監視ソフトウェア
４２  高信頼型アプリケーション・インタフェース
５１  サービス・ソフトウェア
５２  仮想化部インタフェース
４１１  キープ・アライブ・モジュール
４１２  報知モジュール
４１３  診断モジュール
４１４  ロギングモジュール
４１５  演算照合モジュール
４１６  状態監視モジュール
【図１】
2018147277.tif 000003
【図２】
2018147277.tif 000004
【図３】
2018147277.tif 000005
【図４】
2018147277.tif 000006
【図５】
2018147277.tif 000007
【図６】
2018147277.tif 000008