特許 6504610 処理装置、方法及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6504610

(24)【登録日】2019年4月5日

(45)【発行日】2019年4月24日

(54)【発明の名称】処理装置、方法及びプログラム

(51)【国際特許分類】

   G06F 11/07 20060101AFI20190415BHJP

【ＦＩ】

   G06F11/07 175

   G06F11/07 157

【請求項の数】8

【全頁数】16

(21)【出願番号】特願2016-99624(P2016-99624)

(22)【出願日】2016年5月18日

(65)【公開番号】特開2017-207903(P2017-207903A)

(43)【公開日】2017年11月24日

【審査請求日】2017年9月8日

(73)【特許権者】

【識別番号】000227205

【氏名又は名称】ＮＥＣプラットフォームズ株式会社

(74)【代理人】

【識別番号】100103894

【弁理士】

【氏名又は名称】家入 健

(72)【発明者】

【氏名】鈴木 健吾

【審査官】 多胡 滋

(56)【参考文献】

【文献】 特開２００６−０２３９７０（ＪＰ，Ａ）

【文献】 特開２００７−１０９２３８（ＪＰ，Ａ）

【文献】 特開平０４−２６０９４２（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １１／０７

(57)【特許請求の範囲】

【請求項1】

主要な処理を行うメイン処理部と、
前記メイン処理部の外部に設けられ、前記メイン処理部の障害の発生を検出し、前記障害の発生に関係なく通知される前記メイン処理部の状態情報を取得する障害検出部と、
前記障害検出部が取得した状態情報から、前記障害の発生時に対応する状態情報を選択し、外部からアクセス可能な状態で保存する監視制御部と、
を備え、
前記メイン処理部は、前記障害検出部に対して前記障害の発生を検出するための検出用信号を送信し、
前記障害検出部は、所定期間、前記検出用信号が無い場合、前記障害の発生を検出したと判断し、
前記監視制御部は、前記障害の発生後の最初の検出用信号から２番目の検出用信号までの時間に基づいて前記メイン処理部の障害の度合いを判断する、
処理装置。

【請求項2】

主要な処理を行うメイン処理部と、
前記メイン処理部の外部に設けられ、前記メイン処理部の障害の発生を検出し、前記障害の発生に関係なく通知される前記メイン処理部の状態情報を取得する障害検出部と、
前記障害検出部が取得した状態情報から、前記障害の発生時に対応する状態情報を選択し、外部からアクセス可能な状態で保存する監視制御部と、
を備え、
前記メイン処理部は、前記障害検出部に対して前記障害の発生を検出するための検出用信号を送信し、
前記障害検出部は、所定期間、前記検出用信号が無い場合、前記障害の発生を検出したと判断し、
前記監視制御部は、前記障害の発生前の最後の検出用信号とさらに１つ前の検出用信号との間の時間に基づいて前記メイン処理部の障害の度合いを判断する、
処理装置。

【請求項3】

前記監視制御部は、前記障害の発生前の最後の検出用信号から前記障害の発生後の最初の検出用信号までの時間に基づいて前記メイン処理部の障害の度合いを判断する、
請求項１又は２に記載の処理装置。

【請求項4】

前記検出用信号は前記所定期間内に送信される
請求項１又は２に記載の処理装置。

【請求項5】

前記監視制御部は、前記障害検出部に対して障害確認要求を行い、前記障害の発生の有無を示す障害情報と前記状態情報とを前記障害検出部から取得する、
請求項１〜４のいずれか１つに記載の処理装置。

【請求項6】

前記状態情報と前記障害情報とを表示する表示部をさらに備えた請求項５に記載の処理装置。

【請求項7】

メイン処理部の障害を検出するステップと、
前記障害の発生に関係なく通知される前記メイン処理部の状態情報を取得するステップと、
前記取得した状態情報から、前記障害の発生時に対応する状態情報を選択するステップと、
外部からアクセス可能な状態で保存するステップと、
を備え、
前記障害を検出するステップは、前記障害の発生を検出するための検出用信号を送信することを含み、
前記状態情報を取得するステップは、所定期間、前記検出用信号が無い場合、前記障害の発生を検出したと判断することを含み、
前記状態情報を選択するステップは、前記障害の発生後の最初の検出用信号から２番目の検出用信号までの時間に基づいて前記メイン処理部の障害の度合いを判断することを含む、
方法。

【請求項8】

メイン処理部の障害を検出するステップと、
前記障害の発生に関係なく通知される前記メイン処理部の状態情報を取得するステップと、
前記取得した状態情報から、前記障害の発生時に対応する状態情報を選択するステップと、
外部からアクセス可能な状態で保存するステップと、
を備え、
前記障害を検出するステップは、前記障害の発生を検出するための検出用信号を送信することを含み、
前記状態情報を取得するステップは、所定期間、前記検出用信号が無い場合、前記障害の発生を検出したと判断することを含み、
前記状態情報を選択するステップは、前記障害の発生後の最初の検出用信号から２番目の検出用信号までの時間に基づいて前記メイン処理部の障害の度合いを判断することを含む、
をコンピュータに実現させるプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、処理装置、方法及びプログラムに関するものであり、特に、障害を解析するための情報を出力する監視制御部を含む処理装置、方法及びプログラムに関する。

【背景技術】

【0002】

サーバなどの処理装置では、信頼性の向上や可用性の向上を目的として、ＣＰＵ(Central Processing Unit)を有するメイン処理系の動作を、別のＣＰＵを有する監視制御系により監視するのが一般的である。すなわち、処理装置のメイン処理系で障害が発生した場合、処理装置の監視制御系で対応する。例えば、処理装置のメイン処理系においてデッドロックなどの障害が発生した場合、処理装置の監視制御系でこのデッドロックを検出して対処する。しかしながら、メイン処理系においてデッドロックが発生した場合、監視制御系はデッドロックが発生したことは認識できるが、メイン処理系の詳細な状態がわからずに、メイン処理系の障害の解析に支障をきたすという問題があった。

【0003】

処理装置の障害検出に関する技術は、種々提案されている。その一つが特許文献１に開示されている。特許文献１には、内部にウォッチドッグタイマーを備えた情報処理装置において障害が発生した場合、このウォッチドッグタイマーを使用して障害が発生したことを認識することが開示されている。すなわち、情報処理装置において発生した障害を、内部のウォッチドッグタイマーのタイムアウト信号を使用して検出することが開示されている。しかしながら、特許文献１には、処理装置の内部のウォッチドッグタイマーに障害が発生した場合については開示されていない。

【0004】

また、特許文献１には、情報処理装置において障害が発生した場合、情報処理装置が有するＢＭＣ(Baseboard Management Controller)ファームウェアが、ＢＩＯＳ(Basic Input Output System)のストールを検出し、ＳＭＩ(System Management Interrupt)を発生させてＢＩＯＳが採取するＣＰＵのログ情報を収集することが開示されている。しかしながら、特許文献１には、処理装置のＳＭＩに障害が発生した場合については開示されていない。

【0005】

特許文献２には、中央処理装置と、中央処理装置の処理プログラムを格納するメモリーとを有する監視制御装置であって、プログラムにおいて予め定められたチェックポイントを処理した際に、中央処理装置の動作情報を外部処理装置へ出力するポートと、ポートへ出力された中央処理装置の動作情報を格納する記憶手段とを含むことを特徴とする監視制御装置が開示されている。しかしながら、特許文献２には、処理装置に障害が発生した場合、メイン処理系の詳細な状態を監視制御系に伝えることについては開示されていない。

【先行技術文献】

【特許文献】

【0006】

【特許文献1】特開２０１５−１３００２３号公報

【特許文献2】特開２０００−２９３４０７号公報

【発明の概要】

【発明が解決しようとする課題】

【0007】

上述のように、処理装置のメイン処理系においてデッドロックが発生した場合、監視制御系はデッドロックが発生したことは認識できるが、メイン処理系の詳細な状態がわからずに、メイン処理系の障害の解析に支障をきたすという問題があった。

【0008】

本発明は、このような問題点を解決するためになされたものであり、メイン処理系に障害が発生した場合、メイン処理系の障害の解析を容易に行うことが可能な処理装置、方法及びプログラムを提供することを目的とする。

【課題を解決するための手段】

【0009】

本発明に係る処理装置は、主要な処理を行うメイン処理部と、前記メイン処理部の外部に設けられ、前記メイン処理部の障害の発生を検出し、前記障害の発生に関係なく通知される前記メイン処理部の状態情報を取得する障害検出部と、前記障害検出部が取得した状態情報から、前記障害の発生時に対応する状態情報を選択し、外部からアクセス可能な状態で保存する監視制御部と、を備える。

【0010】

本発明に係る方法は、メイン処理部の障害を検出するステップと、前記障害の発生に関係なく通知される前記メイン処理部の状態情報を取得するステップと、前記取得した状態情報から、前記障害の発生時に対応する状態情報を選択するステップと、外部からアクセス可能な状態で保存するステップと、を備える。

【0011】

本発明に係るプログラムは、メイン処理部の障害を検出するステップと、前記障害の発生に関係なく通知される前記メイン処理部の状態情報を取得するステップと、前記取得した状態情報から、前記障害の発生時に対応する状態情報を選択するステップと、外部からアクセス可能な状態で保存するステップと、をコンピュータに実現させる。

【発明の効果】

【0012】

本発明によれば、メイン処理系に障害が発生した場合、メイン処理系の障害の解析を容易に行うことが可能な処理装置、方法及びプログラムを提供することができる。

【図面の簡単な説明】

【0013】

【図1】実施の形態１に係る処理装置を例示するブロック図である。

【図2】実施の形態１に係る処理装置を例示するブロック図である。

【図3】実施の形態１に係る処理装置の動作を例示するシーケンス図である。

【図4】プラットフォームイベント生成部が生成するイベント情報を例示する図である。

【図5】実施の形態１の比較例１に係る処理装置を例示するブロック図である。

【図6】実施の形態１の比較例１に係る処理装置の動作を例示するシーケンス図である。

【図7】実施の形態２に係る処理装置を例示するブロック図である。

【図8】実施の形態３に係る処理装置を例示するブロック図である。

【図9】実施の形態３に係る処理装置の一部を例示するブロック図である。

【発明を実施するための形態】

【0014】

［実施の形態１］
以下、図面を参照して本発明の実施の形態について説明する。

【0015】

図１は、実施の形態１に係る処理装置を例示するブロック図である。

【0016】

図１に示すように、実施の形態１に係る処理装置１０は、メイン処理部１１と監視制御部１２と障害検出部１３とを備える。メイン処理部１１は、外部に提供する情報の処理などの主要な処理を行う。障害検出部１３は、メイン処理部１１の外部に設けられ、メイン処理部１１の障害を検出する。また、障害検出部１３は、障害の発生に関係なくメイン処理部１１から通知されるメイン処理部１１の状態情報を取得する。監視制御部１２は、障害検出部１３が取得した状態情報から、障害の発生時に対応する状態情報を選択し、外部からアクセス可能な状態で保存する。

【0017】

実施の形態１に係る処理装置１０について詳細に説明する。
図２は、実施の形態１に係る処理装置を例示するブロック図である。

【0018】

処理装置１０は、表示部１１５をさらに備える。また、メイン処理部１１は、ＣＰＵ１１１と記憶部１１２〜１１４とを有する。

【0019】

処理装置１０は、例えば、ウェブサーバやファイルサーバなどの装置である。ＣＰＵ１１１は、ＣＰＵ(Central Processing Unit)、すなわち中央演算部を有し、処理装置１０の主たる機能を実現し、外部に対して出力し提供する情報を処理する。記憶部１１２は、例えば、ＲＯＭ(Read-Only Memory)であり、ＢＩＯＳ(Basic Input Output System)などのブートローダが格納される。記憶部１１３は、例えば、ＲＡＭ(Randum Access Memory)であり、処理装置１０の主記憶部である。記憶部１１４は、ＯＳ(Operating System)やファイルシステム・アプリケーションが格納される。

【0020】

なお、ＢＩＯＳとは、ファームウェアの一つで、コンピュータ等の処理装置に搭載されたプログラムのうち、ハードウェアとの間で、最も低レベルな入出力を行うためのプログラムである。ＢＩＯＳは、処理装置の電源投入時に実行される。ＢＩＯＳの機能には、処理装置のハードウェアの初期化や、記憶部からのブートローダの呼び出しがある。

【0021】

また、ブートとは、処理装置の起動を意味し、電源を投入時のＯＳ（Operating System）等、処理装置の動作環境を立ち上げるまでの処理がこれに該当する。また、ブートローダとは、ブート時に、処理装置の動作環境の立ち上げに必要なプログラムの読み込みを行うプログラムのことである。

【0022】

障害検出部１３は、ウォッチドッグタイマ（ＷＤＴ）制御部１３１とＣＰＵ状態保持部１３４とアラーム生成部１３２とアラーム付加情報生成部１３３とを有する。

【0023】

障害検出部１３は、処理装置１０の内部であってメイン処理部１１の外部に設けられる。障害検出部１３のＣＰＵ状態保持部１３４は、メイン処理部１１から、例えば、定期的に送信されるメイン処理部１１の状態情報を取得する。

【0024】

ここで、メイン処理部１１で発生する障害について説明する。メイン処理部１１で発生する障害の例としては、デッドロックが挙げられる。このデッドロックを検出する方法としては、ウォッチドッグタイマを使用した方法が挙げられる。ウォッチドッグタイマは、ＳｏＣ(System-on-a-chip)に含まれるものを使用する場合もあるし、外付けのウォッチドッグタイマを使用する場合もある。ＳｏＣが所有する資源や将来的なメンテナンスのし易さから、外付けのウォッチドッグタイマを使用してもよい。

【0025】

この例では、外付けのウォッチドッグタイマを使用する。処理装置１０は、障害検出部１３のウォッチドッグタイマ制御部１３１内にウォッチドッグタイマ１３１ａを有し、これを外付けのウォッチドッグタイマとして使用する。ウォッチドッグタイマ制御部１３１は、ウォッチドッグタイマ１３１ａを使用してメイン処理部１１のＣＰＵ１１１のデッドロックを検出する。すなわち、メイン処理部１１は、障害検出部１３に対してメイン処理部１１の障害の発生を検出するための検出用信号（リロード要求）を送信する。障害検出部１３のウォッチドッグタイマ制御部１３１は、例えば、所定期間αの間、ＣＰＵ１１１がウォッチドッグタイマ１３１ａに対して行う検出用信号が無い場合、ＣＰＵ１１１においてデッドロックなどの障害の発生を検出したと判断する。このようにして障害検出部１３は、タイムアウト情報などの障害情報を取得する。なお、検出用信号をリロード要求と呼ぶ。また、検出用信号は所定期間α内に送信される。また、検出用信号は、定期的に行われてもよい。

【0026】

ウォッチドッグタイマ制御部１３１は、障害が発生したと判断した場合、タイムアウト情報などの障害情報をアラーム付加情報生成部１３３とアラーム生成部１３２とに通知する。

【0027】

なお、デッドロックとは、複数のプロセスが互いに相手の占有している資源の解放を待ち、処理が停止してしまう障害のことである。また、ウォッチドッグタイマは、ウォッチドッグタイマ機能を意味する場合もある。

【0028】

ＣＰＵ状態保持部１３４は、処理装置１０の起動時のＢＩＯＳのステータス（ＰＯＳＴ（Ｐｏｗｅｒ Ｏｎ Ｓｅｌｆ Ｔｅｓｔ）ステータス）などのＣＰＵ１１１から通知されるＣＰＵ１１１の状態情報を保持する。また、ＣＰＵ状態保持部１３４は、ＣＰＵ１１１の状態情報を表示部１１５に表示する。

【0029】

アラーム付加情報生成部１３３は、ウォッチドッグタイマ制御部１３１から通知されたタイムアウト情報などの障害情報と、ＣＰＵ状態保持部１３４に保持されているＣＰＵ１１１の状態情報とを、ＢＭＣ１２２に通知するための形式に加工する。なお、加工された障害情報と状態情報とをアラーム付加情報と呼ぶ。アラーム付加情報生成部１３３は、アラーム付加情報を、ＢＭＣ１２２のアラーム付加情報取得部１２２ｂに出力する。

【0030】

アラーム生成部１３２は、ウォッチドッグタイマ制御部１３１から通知されたタイムアウト情報などの障害情報をＢＭＣ１２２のアラーム取得部１２２ｃに出力する。なお、アラーム生成部１３２から出力される情報をアラーム情報と呼ぶ。

【0031】

監視制御部１２は、ＢＭＣ１２２と記憶部１２１とを有する。ＢＭＣ１２２は、ＣＰＵ１１１が有するＣＰＵとは別のＣＰＵを有する。記憶部１２１は、例えば、ＥＥＰＲＯＭ(Electrically Erasable Programmable Read-Only Memory)である。

【0032】

ＢＭＣ１２２は、プラットフォームイベント（ＰｌａｔｆｏｒｍＥｖｅｎｔ）生成部１２２ａとアラーム付加情報取得部１２２ｂとアラーム取得部１２２ｃとを有する。プラットフォームイベント（ＰｌａｔｆｏｒｍＥｖｅｎｔ）生成部１２２ａは、アラーム情報とアラーム付加情報とを、後述するイベント情報に加工する。アラーム付加情報取得部１２２ｂは、アラーム付加情報生成部１３３から出力されたアラーム付加情報を取得し、取得した状態情報から、障害の発生時に対応する状態情報を選択して保存する。アラーム取得部１２２ｃは、アラーム生成部１３２から出力された障害情報を取得する。図２に示す経路Ｌ１１〜Ｌ１３を経由して状態情報（ステータス情報）がアラーム付加情報取得部１２２ｂに通知され、経路Ｌ２１〜経路Ｌ２３を経由してアラーム情報がアラーム取得部１２２ｃに通知される。

【0033】

プラットフォームイベント生成部１２２ａが加工したイベント情報は、外部からアクセス可能な状態で記憶部１２１に記憶される、又は、外部装置２０にイベント情報として出力される。なお、監視制御部１２から外部装置２０へのイベント情報の出力は、例えば、ＩＰＭＢ(Intelligent Platform Management Bus)３を介して出力される。

【0034】

表示部１１５は、例えば、７ｓｅｇＬＥＤ(７ segment Lazer Emitting Diode)などで構成され、処理装置１０の起動時のＢＩＯＳのステータスなどを表示する。また、表示部１１５は、ＣＰＵ１１１の状態情報とＣＰＵ１１１の障害情報とを表示する。

【0035】

実施の形態１においては、ＣＰＵ１１１の障害の発生を検出するためのウォッチドッグタイマ１３１ａを、ＣＰＵ１１１から独立させた障害検出部１３内に設けている。ウォッチドッグタイマによる障害の検出を障害検出部１３が自発的に行っている。これにより、ＣＰＵ１１１に障害が発生し異常動作している場合においても、ＣＰＵ１１１の障害を検出し、その障害情報を障害検出部１３経由でＢＭＣ１２２に通知することができる。

【0036】

また、ＣＰＵ１１１の状態情報を、ＣＰＵ１１１から独立させ障害検出部１３のＣＰＵ状態保持部１３４にステータス通知して保持している。そして、ＣＰＵ１１１の状態情報をＣＰＵ状態保持部１３４経由でＢＭＣ１２２に通知している。すなわち、ＣＰＵ１１１から障害検出部１３に対してステータスを通知し、状態情報（ステータス）をＢＭＣ１２２に通知している。これらの動作を、障害検出部１３とＢＭＣ１２２とが自発的に行っている。これにより、ＣＰＵ１１１に障害が発生し以上動作している場合においても、ＣＰＵ１１１の状態情報を障害検出部１３経由でＢＭＣ１２２に出力することができる。

【0037】

次に、実施の形態１に係る処理装置の動作について説明する。
図３は、実施の形態１に係る処理装置の動作を例示するシーケンス図である

【0038】

図３に示すように、メイン処理部１１のＣＰＵ１１１は、処理装置１０の起動時などにＢＩＯＳのＰＯＳＴステータスの進行具合に応じたＰＯＳＴステータスコードであるステータス情報（ＣＰＵ１１１の状態情報）を障害検出部１３のＣＰＵ状態保持部１３４に通知する（ステップＳ１０１）。

【0039】

ＣＰＵ１１１は、ステップＳ１０１と共にウォッチドッグタイマ制御部１３１に対してウォッチドッグタイマのリロード要求（検出用信号の送信）を行う（ステップＳ１０２）。

【0040】

ステップＳ１０１により、障害検出部１３は、メイン処理部１１から障害の発生に関係なく通知されるメイン処理部１１の状態情報を取得する。ステップＳ１０１とステップＳ１０２とは定期的に行われてもよい。ステップＳ１０１の通知を略してステータス通知と呼ぶ。

【0041】

ＣＰＵ状態保持部１３４は、ステップＳ１０１のステータス通知の内容を表示部１１５に表示させる。なお、ウォッチドッグタイマ制御部１３１は、ステップＳ１０１のステータス通知の前に、ＣＰＵ１１１用のウォッチドッグタイマを予め開始しておく（ステップＳ１０３）。

【0042】

ステップＳ１０２において、定期的にウォッチドッグタイマのリロード要求が行われていれば、メイン処理部１１は正常に動作しているとする。

【0043】

メイン処理部１１においてデッドロックが発生した場合（ステップＳ１０５）、ウォッチドッグタイマのリロード要求は滞る。リロード要求が滞り、所定期間αの間、リロード要求が無い場合、障害検出部１３のウォッチドッグタイマ制御部１３１は、ＣＰＵ１１１に障害が発生したと判断し、ウォッチドッグタイマをタイムアウトする（ステップＳ１０６）。ステップＳ１０６により、障害検出部１３は、メイン処理部１１の障害を検出し、このタイムアウトなどの障害情報を取得する。そして、ウォッチドッグタイマ制御部１３１は、このタイムアウトに関するタイムアウト情報をアラーム付加情報生成部１３３とアラーム生成部１３２とに通知する（ステップＳ１０７ａ、ステップＳ１０７ｃ）。タイムアウト情報の通知を略してタイムアウト通知と呼ぶ。

【0044】

ステップＳ１０７ａのタイムアウト通知を受信したアラーム付加情報生成部１３３は、ＣＰＵ状態保持部１３４に、ＣＰＵ１１１の現在のステータス情報（ＣＰＵ１１１の状態情報）の問い合わせを行い、ＣＰＵ状態保持部１３４から現在のステータス情報を取込む（ステップＳ１０７ｂ）。また、アラーム付加情報生成部１３３は、ステータス情報とタイムアウト情報とをＢＭＣ１２２に通知する形式に加工してアラーム付加情報を生成する（ステップＳ１０８ａ）。

【0045】

タイムアウト情報を受信したアラーム生成部１３２は、ウォッチドッグタイマアラームが発生した旨のウォッチドッグタイマアラームフラグを起立する（ステップＳ１０８ｂ）。ウォッチドッグタイマアラームフラグを起立するとは、例えば、ウォッチドッグタイマのアラームビットを設け、アラームビットをオンにすることである。アラームビットのオン又はオフの情報をアラーム情報と呼ぶ。アラーム生成部１３２は、メイン処理部１１のＣＰＵ１１１のタイムアウト情報（障害情報）に基づいてアラーム情報を生成する。

【0046】

監視制御部１２のＢＭＣ１２２は、ウォッチドッグタイマアラームフラグを監視する（ステップＳ１０４ａ）と共にアラーム付加情報が生成されているか否かを監視する（ステップＳ１０４ｂ）。ステップＳ１０４ａにおいて、ＢＭＣ１２２は、アラーム生成部１３２に対して、例えば、ポーリングを行うことによりウォッチドッグタイマアラームフラグが起立しているか否かを監視する。また、ステップＳ１０４ｂにおいて、ＢＭＣ１２２は、アラーム付加情報生成部１３３に対して、ポーリングを行うことによりアラーム付加情報が生成されているか否かを監視する。すなわち、監視制御部１２は、障害検出部１３のアラーム付加情報生成部１３３に対して障害確認要求を行い、ＣＰＵ１１１の状態情報をアラーム付加情報生成部１３３から取得する。また、監視制御部１２は、障害検出部１３のアラーム生成部１３２に対して障害確認要求を行い、障害情報をアラーム生成部１３２から取得する。ステップＳ１０４ａとステップＳ１０４ｂとにおける障害確認要求は、定期的に行われる。

【0047】

ウォッチドッグタイマアラームフラグが起立し、ウォッチドッグタイマアラームが発生していることを認識した場合（ステップＳ１０９ａ）、ＢＭＣ１２２は、プラットフォームイベント生成部１２２ａにて情報を整形し、記憶部１２１などにウォッチドッグタイマアラームの情報（ＳＥＬ（Ｓｙｓｔｅｍ Ｅｖｅｎｔ Ｌｏｇ））を記憶し登録する（ステップＳ１１０ａ）。

【0048】

また、ウォッチドッグタイマアラームが発生していることを認識した場合（ステップＳ１０９ａ）、ＢＭＣ１２２は、外部装置２０に対してＩＰＭＢ３を介してイベント通知を行う（ステップＳ１１１ａ）。

【0049】

アラーム付加情報が生成されていることを認識した場合（ステップＳ１０９ｂ）、ＢＭＣ１２２は、プラットフォームイベント生成部１２２ａにて情報を整形し、記憶部１２１などにアラーム付加情報（ＳＥＬ（Ｓｙｓｔｅｍ Ｅｖｅｎｔ Ｌｏｇ））を記憶し登録する（ステップＳ１１０ｂ）。ステップＳ１１０ｂにおいて、ＢＭＣ１２２は、アラーム付加情報生成部１３３から取得したＣＰＵ１１１の状態情報から、障害の発生時に対応する状態情報を選択し、これを外部からアクセス可能な状態で記憶部１２１に保存する。

【0050】

また、アラーム付加情報が生成されていることを認識した場合（ステップＳ１０９ｂ）、ＢＭＣ１２２は、外部装置２０に対してＩＰＭＢ３を介してイベント通知を行う（ステップＳ１１１ｂ）。すなわち、ＢＭＣ１２２は、状態情報と障害情報とを関連付けて外部に出力する。

【0051】

次に、プラットフォームイベント生成部１２２ａが生成するイベント情報について説明する。
図４は、プラットフォームイベント生成部が生成するイベント情報を例示する図である。
図４は、障害検出部１３のアラーム付加情報生成部１３３と、ＢＭＣ１２２のアラーム付加情報取得部１２２ｂと、の間でやり取りする情報を示す。

【0052】

図４に示す情報Ｄ４０１（アラーム付加情報）は、アラーム付加情報生成部１３３とアラーム付加情報取得部１２２ｂとがやり取りする情報である。情報Ｄ４０１は、アラーム付加情報生成部１３３が生成し、アラーム付加情報取得部１２２ｂに対して出力するアラーム付加情報である。情報Ｄ４０１は、ステータス発行元とステータスコードとステータスコード（拡張）とを含む。ステータス発行元とステータスコード（拡張）は将来の拡張用である。ステータスコードは、メイン処理部１１におけるデッドロック発生時（障害発生時）のＣＰＵ１１１のステータス情報（状態情報）を示す。

【0053】

図４に示す情報Ｄ４０２は、ＢＭＣ１２２のプラットフォームイベント（ＰｌａｔｆｏｒｍＥｖｅｎｔ）生成部１２２ａが生成するイベント情報である。プラットフォームイベント生成部１２２ａは、アラーム付加情報取得部１２２ｂがアラーム付加情報生成部１３３から取得した情報Ｄ４０１（アラーム付加情報）を、一般的にＩＰＭＩ(Intelligent Platform Management Interface)で定義されているＰｌａｔｆｏｒｍＥｖｅｎｔの形式に加工する。プラットフォームイベント生成部１２２ａが生成したイベント情報は、記憶部１２１や外部装置２０に格納される。

【0054】

このようにして、メイン処理部１１のＣＰＵ１１１のデッドロック（障害情報）だけでなく、メイン処理部１１のステータス情報（状態情報）も、イベント情報として外部装置２０などに伝えることができる。

【0055】

実施の形態１に係る処理装置の特徴は、ＣＰＵ１１１の異常を外付けのウォッチドッグタイマ１３１ａにより検出し、例えば、ウォッチドッグタイマアラームなどの障害発生時のＣＰＵ１１１の状態情報をイベント情報情報として外部装置２０などに通知する点である。

【0056】

実施の形態１の効果について説明する。
実施の形態１においては、メイン処理部１１のＣＰＵ１１１から障害検出部１３に対して随時ステータス情報を通知し、ウォッチドックタイマアラームの検出を自発的に行い、ＢＭＣ１２２への報告を自発的に行っている。そして、ＣＰＵ１１１が有するウォッチドックタイマを使用せずに、外部のウォッチドックタイマを使用してＣＰＵ１１１の障害を検出している。これにより、ＣＰＵ１１１に障害が発生している場合でも、ＣＰＵ１１１の障害を検出してＣＰＵ１１１の障害状況をＢＭＣ１２２に通知することができる。

【0057】

また、実施の形態１においては、ＣＰＵ１１１が有するＳＭＩ(System Management Interrupt)機能を使用せずに、ＣＰＵ１１１の外部に存在する障害検出部１３から、ＣＰＵ１１１のステータス情報とウォッチドックタイマアラーム情報とを監視制御部１２に通知している。これにより、ＣＰＵ１１１に障害が発生している場合でも、ＣＰＵ１１１のステータスをＢＭＣ１２２に通知することができる。

【0058】

また、実施の形態１に係る処理装置１０は、メイン処理部１１がデッドロックした際に、その原因解析に必要となるＣＰＵ１１１のステータス情報とアラーム情報とを外部装置２０などに伝えることができる。これにより、処理装置１０の障害の解析を容易に行うことができる。その結果、メイン処理部に障害が発生した場合、メイン処理部の障害の解析を容易に行うことが可能な処理装置、方法及びプログラムを提供することができる。

【0059】

なお、この実施例においては、ＢＩＯＳのステータスコードを例にして説明したが、ＯＳ(Operating System)やアプリケーションのプロセス番号に当てはめて応用してもよい。

【0060】

また、この実施例においては、外付けのウォッチドッグタイマを例にして説明したが、この外付けのウォッチドッグタイマを、監視制御のＳｏＣ(System-on-a-Chip)に含めて１チップの構成で実現してもよい。

【0061】

［実施の形態１の比較例１］
図５は、実施の形態１の比較例１に係る処理装置を例示するブロック図である。

【0062】

図５に示すように、比較例１に係る処理装置１０ａは、メイン処理部１１ａと監視制御部１２ａと障害検出部１３ａとを有する。

【0063】

メイン処理部１１ａは、例えば、７セグメントＬＥＤ(Lazer Emitting Diode)などの簡素な表示部１１５を有し、処理装置１０ａの起動時のＢＩＯＳステータス（ＰＯＳＴ（Ｐｏｗｅｒ Ｏｎ Ｓｅｌｆ Ｔｅｓｔ）ステータス）を表示部１１５に表示させる。

【0064】

監視制御部１２ａは、実施の形態１の監視制御部１２と比べてアラーム付加情報取得部１２２ｂが設けられていない。

【0065】

障害検出部１３ａは、実施の形態１の障害検出部１３と比べてＣＰＵ状態保持部１３４とアラーム付加情報生成部１３３が設けられていない。

【0066】

図６は、実施の形態１の比較例１に係る処理装置の動作を例示するシーケンス図である。

【0067】

図６に示すように、メイン処理部１１ａのＣＰＵ１１１は、処理装置１０ａの起動時などにＢＩＯＳのＰＯＳＴステータスの進行具合に応じたＰＯＳＴステータスコードを表示部１１５に伝える（ステップＳ１０１）と共にウォッチドッグタイマ制御部１３１に対して、定期的にウォッチドッグタイマのリロード要求を行う（ステップＳ１０２）。

【0068】

メイン処理部１１ａにデッドロックが発生し（ステップＳ１０５）、ウォッチドッグタイマのリロード指示が滞ると、ウォッチドッグタイマ制御部１３１はタイムアウトし（ステップＳ１０６）、その旨をアラーム生成部１３２に伝える（ステップＳ１０７）。

【0069】

アラーム生成部１３２は、ウォッチドッグタイマアラームが発生した旨のフラグを起立する（ステップＳ１０８）。

【0070】

一方、監視制御部１２ａのＢＭＣ１２２は、ウォッチドッグタイマアラームフラグを定期的に監視し（ステップＳ１０４）、アラームを認識すると（ステップＳ１０９）、記憶部１２１などにアラーム情報（ＳＥＬ（Ｓｙｓｔｅｍ Ｅｖｅｎｔ Ｌｏｇ））を記憶し登録し（ステップＳ１１０）、外部装置２０にＩＰＭＢ３を通してイベント通知を行う（ステップＳ１１１）。

【0071】

しかしながら、実施の形態１の比較例１においては、メイン処理部１１ａにおいてデッドロックが発生した際、故障が発生したというアラーム情報しか認識することができない。ＣＰＵ１１１の状態情報を認識することができない。従って、処理装置１０の障害の解析をすることは難しい。

【0072】

［実施の形態１の比較例２］
実施の形態１の比較例２においては、実施の形態１と比較して、ＣＰＵ１１１が有するウォッチドッグタイマ機能を使用してＣＰＵ１１１の障害を検出する点が異なる。本比較例２においては、ウォッチドッグタイマ機能に障害が発生しＣＰＵ１１１が異常動作している場合、ＣＰＵ１１１の障害を検出することが難しい。

【0073】

［実施の形態１の比較例３］
実施の形態１の比較例３においては、実施の形態１と比較して、ＣＰＵ１１１が有するＳＭＩ(System Management Interrupt)機能を使用してＣＰＵの障害発生の通知を行う点が異なる。本比較例３においては、ＳＭＩ機能に障害が発生しＣＰＵ１１１が異常動作している場合、ＣＰＵ１１１の障害を通知することが難しい。

【0074】

［実施の形態２］
次に、実施の形態２について説明する。
図７は、実施の形態２に係る処理装置を例示するブロック図である。

【0075】

図７に示すように、実施の形態２は、前述の実施の形態１と比べて、障害検出部１３に付加情報制御部１３５を有する点が異なる。付加情報制御部１３５は、デッドロックが発生後にステータスコードを複数回取得し、取得したステータスコードを一定時間毎に何回、アラーム付加情報取得部１２２ｂに対して出力するかを制御する。なお、一定時間の時間間隔及び一定時間毎に出力するステータスコードの回数は、付加情報制御部１３５により所望の値が設定される。

【0076】

実施の形態２においては、付加情報制御部１３５が一定時間の時間間隔と一定時間毎に出力するステータスコードの回数とを設定する。これにより、ウォッチドッグタイマのリロード間隔の長さにより、ＣＰＵ１１１において、例えば、ソフトウェアの暴走などの障害が発生しているのか否か、又はソフトウェアはある程度適正に動いているのか否かの判断を行うことができる。

【0077】

例えば、監視制御部１２は、障害の発生前の最後の検出用信号から障害の発生後の最初の検出用信号までの時間に基づいてメイン処理部１１の障害の度合いを判断することができる。

【0078】

また、監視制御部１２は、障害の発生後の最初の検出用信号から２番目の検出用信号までの時間に基づいてメイン処理部１１の障害の度合いを判断してもよい。

【0079】

また、監視制御部１２は、障害の発生前の最後の検出用信号とさらに１つ前の検出用信号との間の時間に基づいてメイン処理部１１の障害の度合いを判断してもよい。

【0080】

［実施の形態３］
次に、実施の形態３について説明する。
図８は、実施の形態３に係る処理装置を例示するブロック図である。
図９は、実施の形態３に係る処理装置の一部を例示するブロック図である。

【0081】

図８に示すように、実施の形態３に係る障害検出部１３は、前述の実施の形態１と比べて、異常検出部１３６と記憶部１３７とをさらに有する点が異なる。異常検出部１３６は、ウォッチドッグタイマ制御部１３１と同様な機能、仕組みであって、ＣＰＵ１１１とは別の部位の障害を検出するための機能を有する。異常検出部１３６は、複数の部位の障害をそれぞれ検出するために、検出機能Ｆａ、検出機能Ｆｂ、検出機能Ｆｃなどの複数の検出機能を有する。

【0082】

障害検出部１３が、例えば、ＦＰＧＡ(Field-Programmable Gate Array)で構成されている場合、ＦＰＧＡをコンフィグするためのコンフィグ用ファイルは、フラッシュＲＯＭ(Read Only Memory)などにより構成された記憶部１３７に格納される。

【0083】

ＦＰＧＡをコンフィグする場合、コンフィグ用ファイルが格納された記憶部１３７にアクセスする。このとき、異常検出部１３６は、記憶部１３７へのアクセス異常などを検出し、これをアラーム付加情報としてＢＭＣ１２２に通知する。アラーム付加情報としては、例えば、図４に示す情報Ｄ４０１であるステータス発行元、ステータスコード及びステータスコード（拡張）を使用して情報の判別をする。このようにして、異常検出部１３６は、障害を検出する。

【0084】

また、異常検出部１３６は、記憶部１３７へのアクセス異常の他にも、別の部位の異常を、検出機能Ｆａ、検出機能Ｆｂ及検出機能びＦｃなどを使用して行う。

【0085】

異常検出部１３６及びウォッチドッグタイマ制御部１３１が、複数の部位の異常を同時に検出し、それらの異常が発生した旨をアラーム付加情報生成部１３３に通知する場合、通知する情報間で競合が起こり、通知する情報が消失する可能性がある。このような情報の消失を避けるため、例えば、図９に示すように、障害検出部１３内にＦＩＦＯ(First In First Out)を設ける。

【0086】

次に、実施の形態３に係るアラーム付加情報生成部１３３の動作について説明する。

【0087】

図９に示すように、アラーム付加情報生成部１３３は、ウォッチドッグタイマ制御部１３１及び異常検出部１３６からアラームの書き込み要求があると、ＦＩＦＯに次々と情報を書き込む。

【0088】

アラーム付加情報生成部１３３は、ＦＩＦＯに情報が書き込まれている場合、アラーム付加情報の有無を示すレジスタＲ４０１を確認する。レジスタＲ４０１のフラグが立っている場合、ＦＩＦＯに情報が書き込まれている状態を示す。また、レジスタＲ４０１のフラグが立っていない場合、ＦＩＦＯに情報が書き込まれていない状態を示す。

【0089】

アラーム付加情報生成部１３３は、レジスタＲ４０１のフラグが立っている場合、何もしない。また、アラーム付加情報生成部１３３は、レジスタＲ４０１のフラグが立っていない場合、ＦＩＦＯから情報を取り出し、レジスタＲ４０２に取り出した情報を反映すると共にレジスタＲ４０１のフラグを立てる。

【0090】

一方、ＢＭＣ１２２は、レジスタＲ４０１を監視し、レジスタＲ４０１のフラグが立っていない場合、何もしない。また、ＢＭＣ１２２は、レジスタＲ４０１のフラグが立っている場合、レジスタＲ４０２の内容を読み出すと共にレジスタＲ４０１のフラグを落とす。

【0091】

なお、レジスタＲ４０２は、ステータス発行元、ステータスコード及びステータスコード（拡張）を示すレジスタである。

【0092】

また、上記の実施の形態では、本発明を主にハードウェアの構成として説明したが、本発明はこれに限定されるものではない。本発明は、各構成要素の処理を、ＣＰＵ（Central Processing Unit）にコンピュータプログラムを実行させることにより実現することも可能である。

【0093】

上記の例において、プログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実態のある記録媒体(trangible storage medium)を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ−ＲＯＭ（Read Only Memory）、ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Programable ROM）、ＥＰＲＯＭ(Erasable PROM)）、フラッシュＲＯＭ、ＲＡＭ(Random Access Memory)を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

【0094】

なお、本発明は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。

【符号の説明】

【0095】

１０、１０ａ…処理装置 １１、１１ａ…メイン処理部 １２、１２ａ…監視制御部 １３、１３ａ…障害検出部 １１１…ＣＰＵ １１２２〜１１４…記憶部 １１５…表示部 １２１…記憶部 １２２…ＢＭＣ １２２ａ…プラットフォームイベント生成部 １２２ｂ…アラーム付加情報取得部 １２２ｃ…アラーム取得部 １３１…ウォッチドッグタイマ制御部 １３１ａ…ウォッチドッグタイマ １３２…アラーム生成部 １３３…アラーム付加情報生成部 １３４…ＣＰＵ状態保持部 １３５…付加情報制御部 １３６…異常検出部 １３７…記憶部 Ｄ４０１、Ｄ４０２…情報 Ｒ４０１、Ｒ４０２…レジスタ Ｆａ、Ｆｂ、Ｆｃ…検出機能 Ｌ１１、Ｌ１２、Ｌ１３、Ｌ２１、Ｌ２２、Ｌ２３…経路 α…所定期間

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】