JP5627414B2 - 動作ログ収集システム及びプログラム - Google Patents

Description

本発明は、動作ログ収集システム及びプログラムに関し、例えば、ＣＰＵリセット入力に結線されている回路において、ソフトウェア動作異常時に、ＣＰＵリセット起動前に、ソフトウェアの異常動作に関する情報を収集するシステム及びプログラムに適用し得るものである。

従来、中央処理装置（ＣＰＵ）によるソフトウェア動作に異常が生じ、ＣＰＵの暴走を監視するために、ウォッチドッグ監視回路が用いられている。

ウォッチドッグ監視回路は、タイマ機能を有している。システムが正常動作をしている場合、一定時間内に、ソフトウェア処理によるタイマリフレッシュを受け、ウォッチドッグ監視回路はタイマをリフレッシュする。

一方、ＣＰＵによるソフトウェア処理に異常が生じると、ソフトウェア処理によるウォッチドッグ監視回路のタイマリフレッシュがなされない。そのため、タイマの満了をもって、ウォッチドッグ監視回路は、直接結線されているＣＰＵのリセット入力に信号を出力する。これにより、ハードウェア自律のシステム再起動が行われ、システム動作の正常復帰が可能となる（特許文献１参照）。

一般的に、ウォッチドッグ監視回路の実装は、ソフトウェア処理暴走時のシステム再起動による自律正常復帰を目的とする。ソフトウェアによるウォッチドッグ監視回路のタイマリフレッシュは、実行レベルの低い周期処理により行われる。そして、ソフトウェア正常動作時は、ウォッチドッグ監視回路のタイマ時間内で周期的にリフレッシュ動作が行われるように実装する。その結果、ソフトウェア処理暴走時に、実行レベルの低い周期処理は待ち状態になり、ウォッチドッグ監視回路のタイマリフレッシュが行われず、タイマ満了でＣＰＵリセットが入力される。

特許文献３には、ハードウェア上の障害を監視する監視許容時間より短い周期で割り込み信号をコンピュータに送出するタイマ手段を備え、タイマ手段から割り込み信号を受け取ると、ハードウェア用ウォッチドッグのプログラムを、他のプログラムよりも最優先で起動する技術が記載されている。

また、特許文献２には、診断装置からシステム内の障害発生が中央処理装置に通知された時に、中央処理装置によって実行される障害情報を記録する技術が記載されている。

特開平５−２８２１８２号公報 特開平８−２８６９５６号公報 特開平４−１９０４３３号公報

ところで、ウォッチドッグ監視回路によるＣＰＵの再起動が発生するケースにおいて、その再起動直前のソフトウェア異常動作に関する情報を記憶しておくことが望まれる。これは、例えば、無限ループ処理等が生じた場合に、その原因を特定することができるかである。

しかし、上記のようなウォッチドッグ監視回路から直接ＣＰＵリセット入力に結線されているハードウェア構成の既存システムにおいては、ソフトウェアの介在なしにハードウェア論理でＣＰＵリセットが入るので、ソフトウェアの異常動作に関する情報を残すことができず、問題解析が困難であった。

そのため、ウォッチドッグ監視回路から直接ＣＰＵのリセット入力に結線されていているハードウェア構成のシステムにおいて、ソフトウェア異常動作に関する情報を、ＣＰＵの再起動前に収集することができる動作ログ収集システム及びプログラムが求められている。

かかる課題を解決するために、第１の本発明の動作ログ収集システムは、主制御装置と、タイマを有し、そのタイマ満了時に主制御装置に対してリセット信号を出力するウォッチドッグ監視手段とを備える動作ログ収集システムにおいて、（１）最優先レベルの周期割り込み動作により、ウォッチドッグ監視手段のタイマをリフレッシュし、所定周期のカウンタを有し、主制御装置による動作ログをカウンタのカウンタ値に対応付けて記憶手段に保存し、カウンタ値により主制御装置の再起動を行う動作ログ収集手段と、（２）動作ログ収集手段のカウンタを所定周期でリフレッシュする定周期処理手段とを備えることを特徴とする。

第２の本発明の動作ログ収集プログラムは、主制御装置と、タイマを有し、そのタイマ満了時に主制御装置に対してリセット信号を出力するウォッチドッグ監視手段とを備えるコンピュータを、（１）最優先レベルの周期割り込み動作により、ウォッチドッグ監視手段のタイマをリフレッシュし、所定周期のカウンタを有し、主制御装置による動作ログをカウンタのカウンタ値に対応付けて記憶手段に保存し、カウンタ値により主制御装置の再起動を行う動作ログ収集手段、（２）動作ログ収集手段のカウンタを所定周期でリフレッシュする定周期処理手段として機能させることを特徴とする。

本発明によれば、ウォッチドッグ監視手段から主制御装置のリセット入力に結線されていているハードウェア構成のシステムにおいて、ソフトウェア異常動作に関する動作ログを、主制御装置の再起動前に収集することができる。

実施形態の動作ログ収集システムの構成を示す構成図である。 実施形態の最優先周期処理ソフトウェアプロセスの処理を示すフローチャートである。 実施形態の定周期処理ソフトウェアプロセスの処理を示すフローチャートである。 実施形態のトレースログ収集エリアに格納される情報例を説明する説明図である。 実施形態のウォッチドッグ監視回路部における処理を示すフローチャートである。

（Ａ）実施形態
以下では、動作ログ収集システム及びプログラムの実施形態を、図面を参照しながら説明する。

（Ａ−１）実施形態の構成
図１は、実施形態に係る動作ログ収集システムの構成を示すブロック図である。図１において、この実施形態に係る動作ログ収集システム１０は、主制御部１、ウォッチドッグ監視回路部２、リセット回路部３、揮発性メモリ部４、不揮発性メモリ部５を少なくとも有して構成される。

主制御部１は、主制御部１を搭載する装置の動作を司るものである。主制御部１は、揮発性メモリ部４において最優先周期処理ソフトウェアプロセス４１及び定周期処理ソフトウェアプロセス４２を実行するものである。

最優先周期処理ソフトウェアプロセス４１及び定周期処理ソフトウェアプロセス４２は、揮発性メモリ部４内で動作するソフトウェアである。

最優先周期処理ソフトウェアプロセス４１は、ウォッチドッグ監視回路部２のタイマリフレッシュを、最優先レベルの周期的な割り込み処理として行うものである。最優先周期処理ソフトウェアプロセス４１は、ソフトウェア処理の実行レベルを最優先レベルとしているので、主制御部１によるソフトウェア処理の暴走時に最優先で実行され、主制御部１に対してリセット命令を出力することができる。

また、図１に示すように、最優先周期処理ソフトウェアプロセス４１により行われる主な機能として、タイマ部４１１、タイマリフレッシュ部４１２、トレースログ収集部４１３、再起動部４１４を少なくとも有する。

タイマ部４１１は、所定時間を計時するものである。タイマ部４１１は、例えば、「０」でない初期値（例えば「２５５」）から減算していく減算カウンタを適用することができる。なお、初期値は、特に限定されるものではない。なお、タイマ部４１１が計時する時間は、ウォッチドッグ監視回路部２のタイマ部２１のタイマ時間よりも短い。

また、この実施形態では、減算カウンタを適用する場合を例示するが、加算カウンタを適用するようにしてもよい。その場合、例えば初期値を「０」として加算していき所定値に達するか否かで、所定時間を計時することができる。この場合も、初期値は限定されるものではない。

タイマリフレッシュ部４１２は、最優先周期処理ソフトウェアプロセス４１が実行されると、ウォッチドッグ監視回路部２のタイマ部２１のタイマ値を初期値に戻し、タイマリフレッシュを行うものである。

トレースログ収集部４１３は、タイマ部４１１によるタイマが満了でない場合、タイマ部４１１のタイマ値をインデックスとして、対応するトレースログ情報を、不揮発性メモリ部５のトレースログ収集エリア５１に記録するものである。

トレースログ収集部４１３が、トレースログを収集するタイミングは、タイマ部４１１のタイマ値の変更時である。すなわち、減算カウンタがカウンタ値を減算したときに、トレースログ収集部４１３は、そのときのトレースログ情報をトレースログ収集エリア５１に記録する。

再起動部４１４は、タイマ部４１１によるタイマが満了した場合、主制御部１に対して直接リセット命令を出力するものである。ここで、再起動部４１４は、後述するウォッチドッグ監視回路部２及びリセット回路部３を用いずに、直接主制御部１に対してリセット命令を出力する。

定周期処理ソフトウェアプロセス４２は、所定周期毎に、最優先周期処理ソフトウェアプロセス４１のタイマ部４１１のタイマ値を初期値にリフレッシュするものである。定周期処理ソフトウェアプロセス４２の実行レベルは低い。また、定周期処理ソフトウェアプロセス４２の実行周期は、最優先周期処理ソフトウェアプロセス４１のタイマ部４１１の計時時間よりも短い。

例えば、特許文献３に記載の従来技術の場合、ウォッチドッグ監視回路のタイマリフレッシュを行うが、この実施形態の定周期処理ソフトウェアプロセス４２は、最優先周期処理ソフトウェアプロセス４１のタイマリフレッシュを行う点で異なる。

ウォッチドッグ監視回路部２は、主制御部１のソフトウェア実行処理に異常が生じた場合に、リセット回路部３にリセット命令を出力するものである。

図１に示すように、ウォッチドッグ監視回路部２の主な機能としては、タイマ部２１、リセット命令部２２が少なくともある。

タイマ部２１は、所定時間を計時するものである。タイマ部２１は、タイマ満了前に、最優先周期処理ソフトウェアプロセス４１からタイマのリフレッシュを受けると、タイマ値を初期値に戻す。なお、タイマ満了は、所定の閾値に達したときとすることができる。

リセット命令部２２は、タイマ部２１のタイマが満了になると、リセット回路部３に対してリセット命令を出力するものである。

リセット回路部３は、ウォッチドッグ監視回路部２からリセット命令を受け取ると、主制御部１に対してリセット信号を出力するものである。

揮発性メモリ部４は、最優先周期処理ソフトウェアプロセス４１、定周期処理ソフトウェアプロセス４２のワーキングエリアである。

不揮発性メモリ部５は、主制御部１のリセット入力によるシステム再起動前後で、データ内容が保証されるトレースログ情報エリア５１を保持するものである。

（Ａ−２）実施形態の動作
次に、この実施形態のソフトウェア動作ログ情報収集処理の動作を、図面を参照しながら説明する。

図２は、最優先周期処理ソフトウェアプロセス４１の処理を示すフローチャートである。また、図３は、定周期処理ソフトウェアプロセス４２の処理を示すフローチャートである。

まず、図２において、最優先周期処理ソフトウェアプロセス４１は、周期的な割り込み信号によりスタートする。その割り込みの周期は、特に限定されるものではないが、例えば１０ｍｓ間隔で割り込みスタートさせるようにしてもよい。

最優先周期処理ソフトウェアプロセス４１を実行すると、タイマリフレッシュ部４１２は、ウォッチドッグ監視回路部２のタイマ部２１のタイマ値を初期値に戻し、タイマフレッシュを行う（Ｓ１０１）。ウォッチドッグ監視回路部２のタイマフレッシュが行われると、事実上ハードウェアによるウォッチドッグ監視回路部２の機能が無効化することになる。

次に、最優先周期処理ソフトウェアプロセス４１のタイマ４１１のカウンタ値（この実施形態では減算カウンタのカウンタ値）が「０」であるか否かを判断する（Ｓ１０２）。ここで、最優先周期処理ソフトウェアプロセス４１のタイマ部４１１のカウンタ値の初期値は「２５５」であり、タイマ部４１１は、「２５５」〜「０」までカウントする。

図３に示すように、タイマ部４１１は、所定周期毎に、定周期処理ソフトウェアプロセス４２の処理により、カウンタ値が初期値に戻りリフレッシュされる（Ｓ２０１）。

カウンタ値が「０」の場合、再起動部４１４は、主制御部１に対してリセット命令を出力し、システムは再起動される（Ｓ１０３）。上記のように、最優先周期処理ソフトウェアプロセス４１が行われると、ウォッチドッグ監視回路部２のタイマリフレッシュがなされ、ウォッチドッグ監視回路部２は無効化しているので、最優先周期処理ソフトウェアプロセス４１が主制御部１に対して直接リセット命令を出力する。

一方、カウンタ値が「０」でない場合、タイマ部４１１は、カウンタ値を周期的に減算する（Ｓ１０４）。

ソフトウェア正常動作時には、タイマ部４１１のカウンタ値が「０」になる前に、定周期処理ソフトウェアプロセス４２によるリフレッシュ動作が実施されるので、タイマ部４１１は満了にならない。

トレースログ収集部４１３は、タイマ部４１１のカウンタ値が「０」でない場合、主制御部１により実行されているトレースログ情報を、タイマ部４１１のカウンタ値と対応付けて、トレースログ収集エリア５１に記録する（Ｓ１０５）。

ここで、図４は、トレースログ収集エリア５１に格納される情報例を説明する説明図である。

図４に示すように、トレースログ収集エリア５１には、カウンタ値が「０」以外の場合に、そのカウンタ値から減算したカウンタ値と、そのときのトレースログ情報とを対応付けた情報が記録される。

ここで、トレースログ情報は、例えば、ＣＰＵのプログラムカウンタ、ステータスレジスタ、メモリ／スタック等のソフトウェア動作情報である。また、トレースログ情報は、１個のカウンタ値に複数種類を対応付けることができる。図４では、３種類のトレースログ情報をカウンタ値に対応付ける場合を例示する。

Ｓ１０３で説明したように、再起動部４１４は、カウンタ値が「０」の場合に、主制御部１にリセット命令を行う。図４に示すように、カウンタ値が「０」になるまでのトレースログ情報、すなわち、カウント値が「２５５」から「１」まで経過する時点のトレースログ情報は、トレースログ収集エリア５１に記録されている。従って、再起動部４１４がリセット命令を出力する直前までのトレースログ情報が、トレースログ収集エリア５１に記録される。また、主制御部１は、再起動部４１４からのリセット命令により再起動し、システムを正常復帰させる。

図５は、ウォッチドッグ監視回路部２における処理を示すフローチャートである。

ウォッチドッグ監視回路部２は、周期的にタイマ部２１のタイマ値をカウントダウンし（Ｓ３０１）、タイマ満了である場合（Ｓ３０２）、リセット回路部３にリセット命令を行う（Ｓ３０３）。これを受けて、リセット回路部３は主制御部１にリセット信号を出力する。なお、タイマ満了でない場合、Ｓ３０１に移行し、タイマ満了になるまでタイマ値のカウントダウンを行う。

また、上述したように、最優先周期処理ソフトウェアプロセス４１が、ウォッチドッグ監視回路部２のタイマリフレッシュを行っている。

ここで、ソフトウェア異常動作時に、例えばメモリ破壊等、最優先周期処理ソフトウェアプロセス４１までも動作不能になった場合は、ウォッチドッグ監視回路部２による主制御部１へのリセットが動作するため、システムは正常復帰する。

この場合でも、最優先周期処理ソフトウェアプロセス４１のトレースログ収集部４１３が、ソフトウェア異常動作時のカウンタ値にトレースログ情報を対応付けて記録しているので、その時点までのトレース動作ログ情報がトレースログ収集エリア５１に保存されている。

（Ａ−３）実施形態の効果
以上のように、実施形態によれば、ウォッチドッグ再起動直前のソフトウェア動作トレース情報を収集することにより、ウォッチドッグ再起動発生原因の解析時間短縮が期待できる。

例えば、無限ループ処理に陥り、ウォッチドッグ再起動が発生したケースにおいて、再起動前のソフトウェア動作情報（例えば、ＣＰＵのプログラムカウンタ、ステータスレジスタ、メモリ／スタックなど）がトレース収集されていれば、少なくとも無限ループに陥っていた箇所は特定可能であり、収集情報によっては、無限ループに陥った原因（スタック破壊、メモリ破壊ｅｔｃ）も特定可能である。

（Ｂ）他の実施形態
上述した実施形態は、本発明の実施形態の一例である。例えば、上述した実施形態では、最優先周期処理ソフトウェアプロセスという１つのソフトウェアの機能として説明したが、最優先周期処理ソフトウェアプロセスが備える各機能をソフトウェアとし、複数のソフトウェアとして設けるようにしてもよい。

また、実施形態では、最優先周期処理ソフトウェアプロセスの再起動部のリセット命令を出力タイミングがカウンタ値「０」の場合として説明したが、これに限定されるものではなく、例えば、閾値に達した時点としてもよい。この場合も、その閾値に対するまでのカウンタ値に対応付けた動作ログが、時系列にトレースログとして保存することができる。

１…主制御部、２…ウォッチドッグ監視回路部、２１…タイマ部、２２…リセット命令部、３…リセット回路部、４…揮発性メモリ部、４１…最優先周期処理ソフトウェアプロセス、４２…定周期処理ソフトウェアプロセス、５…不揮発性メモリ部、５１…トレースログ収集エリア。

Claims (2)

1. 主制御装置と、タイマを有し、そのタイマ満了時に上記主制御装置に対してリセット信号を出力するウォッチドッグ監視手段とを備える動作ログ収集システムにおいて、
   最優先レベルの周期割り込み動作により、上記ウォッチドッグ監視手段の上記タイマをリフレッシュし、所定周期のカウンタを有し、上記主制御装置による動作ログを上記カウンタのカウンタ値に対応付けて記憶手段に保存し、上記カウンタ値により上記主制御装置の再起動を行う動作ログ収集手段と、
   上記動作ログ収集手段の上記カウンタを所定周期でリフレッシュする定周期処理手段と を備えることを特徴とする動作ログ収集システム。
2. 主制御装置と、タイマを有し、そのタイマ満了時に上記主制御装置に対してリセット信号を出力するウォッチドッグ監視手段とを備えるコンピュータを、
   最優先レベルの周期割り込み動作により、上記ウォッチドッグ監視手段の上記タイマをリフレッシュし、所定周期のカウンタを有し、上記主制御装置による動作ログを上記カウンタのカウンタ値に対応付けて記憶手段に保存し、上記カウンタ値により上記主制御装置の再起動を行う動作ログ収集手段と、
   上記動作ログ収集手段の上記カウンタを所定周期でリフレッシュする定周期処理手段
   として機能させることを特徴とする動作ログ収集プログラム。

Images