(57)【要約】      （修正有）【課題】管理対象システムにおけるエラー停止要因を検知することで管理対象システムの保守時に容易にシステムデバッグができるように制御する。【解決手段】システム管理装置１は、管理対象システム２からの初期化情報が入力されればカウント値を初期値に設定し、入力されなかったときは所定の周期でカウントするタイマーを有し、カウント値が閾値になった場合に閾値到達情報を出力し、システムリセットを指示するウォッチドッグ部１１と、閾値到達情報が出力された場合に、閾値到達情報が出力されてからリセット指示情報が出力されるまでの期間中に、管理対象システム２へ生存フラグの出力を要求する生存フラグ要求送信部１２と、管理対象システム２から出力された生存フラグを受信する生存フラグ受信部１３と、前記生存フラグを受信したか否かを示す生存フラグ情報を保持する生存フラグ保持部１４とを備える。【選択図】図１
2016184384.tif 000002
【特許請求の範囲】
【請求項１】
管理対象システムから初期化情報が入力された場合はカウント値を初期値に設定し、初期化情報が入力されなかった場合は、所定の周期で前記カウント値をカウントするタイマーを有し、前記カウント値が閾値になった場合に閾値到達情報を出力し、前記閾値到達情報が出力してから所定の期間後に前記管理対象システムへシステムリセットを指示するリセット指示情報を出力するウォッチドッグ部と、
前記閾値到達情報が出力された場合に、前記閾値到達情報が出力されてから前記リセット指示情報が出力されるまでの期間中に、前記管理対象システムへ生存フラグの出力を要求する生存フラグ要求送信部と、
前記管理対象システムから出力された前記生存フラグを受信する生存フラグ受信部と、
前記生存フラグ受信部が前記生存フラグを受信したか否かを示す生存フラグ情報を保持する生存フラグ保持部と
を備えることを特徴とするシステム管理装置。
【請求項２】
前記リセット指示情報と前記生存フラグ情報とに基づく前記管理対象システムの状態を示す表示を行なう表示部をさらに備える
ことを特徴とする請求項１に記載のシステム管理装置。
【請求項３】
前記表示部は、前記リセット指示情報が出力されるまでに前記生存フラグを受信しなかった場合に、前記管理対象システムの状態が前記管理対象システムにおけるオペレーティングシステムに関するプログラムに起因したエラーを起こした状態であったことを表示する
ことを特徴とする請求項２に記載のシステム管理装置。
【請求項４】
前記表示部は、前記リセット指示情報が出力されるまでに前記生存フラグを受信した場合に、前記管理対象システムの状態が前記管理対象システムにおけるアプリケーションプログラムに起因したエラーを起こした状態であったことを表示する
ことを特徴とする請求項２または請求項３に記載のシステム管理装置。
【請求項５】
前記管理対象システムの状態を記憶する生存フラグ情報記憶部をさらに備える
ことを特徴とする請求項１から４のいずれか１項に記載のシステム管理装置。
【請求項６】
時刻情報を取得する時刻情報取得部をさらに備え、
前記生存フラグ情報記憶部は、前記生存フラグ情報と前記生存フラグ情報を保持した時の前記時刻情報とを記憶する
ことを特徴とする請求項５に記載のシステム管理装置。
【請求項７】
前記生存フラグ情報記憶部は、前記生存フラグを受信した回数を記憶しておく
ことを特徴とする請求項５または請求項６に記載のシステム管理装置。
【請求項８】
前記生存フラグ情報記憶部は、前記リセット指示情報を出力した回数を記憶しておく
ことを特徴とする請求項５から７のいずれか１項に記載のシステム管理装置。
【請求項９】
前記生存フラグ情報記憶部は、前記生存フラグを受信した回数と前記リセット指示情報を出力した回数との差分を記憶しておく
ことを特徴とする請求項８に記載のシステム管理装置。
【請求項１０】
前記表示部は、前記生存フラグ情報記憶部が記憶した情報を表示する
ことを特徴とする請求項６から請求項９のいずれか１項に記載のシステム管理装置。
【請求項１１】
前記管理対象システムは、入力データを処理する処理部と、入力される選択制御信号に基づいて前記入力データの供給先を前記処理部から前記システム管理装置へ切り替えるセレクタとを備えるものであって、
前記ウォッチドッグ部は、前記リセット指示情報が出力されるまでに前記生存フラグを受信しなかった場合に、前記管理対象システムをリセットする第１のリセット信号を出力するものであって、
前記入力データに対して代替処理を行なうリカバリー処理実行部と、
前記初期化情報と前記リセット指示情報と前記生存フラグ情報とに基づいて前記選択制御信号を出力するリカバリー制御部とをさらに備え、
前記選択制御信号は、通常期間は前記入力データの供給先を前記処理部とし、前記第１のリセット信号を出力してから前記管理対象システムから前記初期化情報が入力されるまでの期間は、前記入力データの供給先を前記リカバリー処理実行部とする情報を含むことを特徴とする請求項１から請求項１０のいずれか１項に記載のシステム管理装置。
【請求項１２】
管理対象システムから初期化情報が入力された場合はカウント値を初期値に設定し、初期化情報が入力されなかった場合は所定の周期で前記カウント値をカウントし、前記カウント値が閾値になったときに閾値到達情報を出力して所定の期間後に前記管理対象システムへシステムリセットを指示するリセット指示情報を出力するウォッチドッグステップと、
前記閾値到達情報が出力された後、前記所定の期間内に前記管理対象システムへ生存フラグの出力を要求する生存フラグ要求情報を送信する生存フラグ要求送信ステップと、
前記管理対象システムから出力された前記生存フラグを受信したか否かを示す生存フラグ情報を保持する生存フラグ保持ステップと
を備えることを特徴とするシステム管理方法。
【請求項１３】
前記リセット指示情報と前記生存フラグ情報とに基づく前記管理対象システムの状態を示す表示を行なう表示ステップをさらに備える
ことを特徴とする請求項１２に記載のシステム管理方法。
【請求項１４】
前記表示ステップは、前記リセット指示情報が出力されるまでに前記生存フラグを受信しなかった場合に、前記管理対象システムの状態が前記管理対象システムにおけるオペレーティングシステムに関するプログラムに起因したエラーを起こした状態であったことを表示する
ことを特徴とする請求項１３に記載のシステム管理方法。
【請求項１５】
前記表示ステップは、前記リセット指示情報が出力されるまでに前記生存フラグを受信した場合に、前記管理対象システムの状態が前記管理対象システムにおけるアプリケーションプログラムに起因したエラーを起こした状態であったことを表示する
ことを特徴とする請求項１３または請求項１４に記載のシステム管理方法。
【請求項１６】
前記管理対象システムの状態を記憶する生存フラグ情報記憶ステップをさらに備える
ことを特徴とする請求項１２から１５のいずれか１項に記載のシステム管理方法。
【請求項１７】
時刻情報を取得する時刻情報取得ステップをさらに備え、
前記生存フラグ情報記憶ステップは、前記生存フラグ情報と前記生存フラグ情報を保持した時の前記時刻情報とを記憶する
ことを特徴とする請求項１６に記載のシステム管理方法。
【請求項１８】
前記生存フラグ情報記憶ステップは、前記生存フラグを受信した回数を記憶しておく
ことを特徴とする請求項１６または請求項１７に記載のシステム管理方法。
【請求項１９】
前記生存フラグ情報記憶ステップは、前記リセット指示情報を出力した回数を記憶しておく
ことを特徴とする請求項１６から１８のいずれか１項に記載のシステム管理方法。
【請求項２０】
前記生存フラグ情報記憶ステップは、前記生存フラグを受信した回数と前記リセット指示情報を出力した回数との差分を記憶しておく
ことを特徴とする請求項１９に記載のシステム管理方法。
【請求項２１】
前記表示ステップは、前記生存フラグ情報記憶ステップが記憶した情報を表示する
ことを特徴とする請求項１７から請求項２０のいずれか１項に記載のシステム管理方法。
【請求項２２】
前記管理対象システムは、入力データを処理する処理ステップと、入力される選択制御信号に基づいて前記入力データの供給先を前記処理部から前記システム管理装置へ切り替えるセレクタステップとを備えるものであって、
前記リセット指示情報が出力されるまでに前記生存フラグを受信しなかった場合に、前記管理対象システムをリセットする第１のリセット信号を出力するシステムリセットステップと、
前記入力データに対して代替処理を行なうリカバリー処理実行ステップと、
前記初期化情報と前記リセット指示情報と前記生存フラグ情報とに基づいて前記選択制御信号を出力するリカバリー制御ステップとをさらに備え、
前記選択制御信号は、通常期間は前記入力データの供給先を前記処理ステップとし、前記第１のリセット信号を出力してから前記管理対象システムから前記初期化情報が入力されるまでの期間は、前記入力データの供給先を前記リカバリー処理実行ステップとする情報を含む
ことを特徴とする請求項１２から請求項２１のいずれか１項に記載のシステム管理方法。
【請求項２３】
請求項１１に記載のシステム管理装置と、
入力データをカメラからの映像データとし、設定された映像フォーマットに変換してメモリ部に記録処理を行なう処理部、及び入力される選択制御信号に基づいて前記映像データの供給先を前記処理部から前記システム管理装置へ切り替えるセレクタを有する管理対象システムと
を備える監視カメラシステム。
【請求項２４】
前記処理部は、前記第１のリセット信号が入力されてから前記選択制御信号が前記入力データの供給先を前記処理部とする情報に変わった後に、前記リカバリー処理実行部が代替処理を行なった処理結果について前記フォーマットに変換してメモリ部に記録処理を行なう
ことを特徴とする請求項２３に記載の監視カメラシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、管理対象のシステムの状態を監視して、システムが停止したときにシステム再起動を制御するシステム管理装置及びシステム管理方法に関する。
【背景技術】
【０００２】
監視カメラと記録装置とを備え、犯罪や事故などの状況を残す貴重な映像を記録する監視システムなどは、監視映像を確実に記録することが求められるシステムであり、システムが停止したままになると所期の目的を果たせなくなるシステムがある。このようなシステム対して、システムの状態を監視しシステムが停止したときにはシステムの再起動をさせるシステム管理装置を備えることで、自動的に所期の目的を果たせる状態に復帰させることができる。
【０００３】
このようなシステムに対して、システムが停止したときにシステムの再起動をさせるシステム管理装置を備えていても、システム停止の要因を特定することができない。そこで、システム上のオペレーティングシステム（以下、ＯＳ：Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍともいう）やＯＳ配下のドライバが正常に動作している場合にプログラムエラー停止検出ができるシステム管理装置として、システム上のＯＳやＯＳ配下のドライバのエラー停止した場合はシステムからのウォッチドッグリセットでシステムリセットし、ＯＳよりも上位のアプリケーションプログラム（以下、アプリともいう）がエラー停止した場合はＯＳを動作させたままシステム上のアプリだけをリセットし、ＯＳ配下のドライバによって、エラー停止しているアプリのタスク詳細情報とエラー停止回数を不揮発性メモリのカーネルログエリアに記録し、被疑要因タスクの特定を容易にする装置が記載されている（例えば、例えば、特許文献１参照）。ここで、ウォッチドッグリセットとは、管理対象となるシステム側からカウントクリア情報が入力された場合はカウント値を初期値に設定し、カウントクリア情報が入力されなかった場合は、所定の周期でカウント値をカウントするタイマーを用いて、カウント値が閾値になった場合にシステムをシステムリセットするように指示を与えるものである。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００９−１５１４４０号公報（第６−１２頁、第６図）
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、特許文献１はアプリがエラー停止した場合はアプリのタスク詳細情報とエラー停止回数を不揮発性メモリに記録することが可能であるが、ＯＳやＯＳ配下のドライバがエラー停止した場合は、ＯＳやＯＳ配下のドライバについてのエラー停止情報やエラー停止回数を不揮発性メモリに記録することができず、保守の際にシステムの停止要因が分からないという問題があった。
【０００６】
この発明は、上述のような課題を解決するためになされたもので、管理対象システムにおけるエラー停止要因を検知することで管理対象システムの保守時に容易にシステムデバッグができるように管理対象システムを制御するシステム管理装置、システム管理方法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
この発明に係るシステム管理装置においては、管理対象システムから初期化情報が入力された場合はカウント値を初期値に設定し、初期化情報が入力されなかった場合は、所定の周期で前記カウント値をカウントするタイマーを有し、前記カウント値が閾値になった場合に閾値到達情報を出力し、前記閾値到達情報が出力してから所定の期間後に前記管理対象システムへシステムリセットを指示するリセット指示情報を出力するウォッチドッグ部と、前記閾値到達情報が出力された場合に、前記閾値到達情報が出力されてから前記リセット指示情報が出力されるまでの期間中に、前記管理対象システムへ生存フラグの出力を要求する生存フラグ要求送信部と、前記管理対象システムから出力された前記生存フラグを受信する生存フラグ受信部と、前記生存フラグ受信部が前記生存フラグを受信したか否かを示す生存フラグ情報を保持する生存フラグ保持部とを備えることを特徴とするものである。
【発明の効果】
【０００８】
この発明は、ウォッチドッグ部においてカウント値が閾値に到達するまでに管理対象システムから初期化情報が入力されなかった場合に、管理対象システムへシステムリセットを指示するリセット指示情報を出力する前に管理対象システムへ生存フラグの出力を要求し、管理対象システムが生存フラグ出力の要求に対応した生存フラグが受信できたか否かを示す生存フラグ情報を保持することで、生存フラグが受信できた場合は管理対象システムのＯＳは動作可能であるがウォッチドッグ部へ初期化情報を出力するアプリケーションプログラムが動作できない状態であった、生存フラグが受信できなかった場合は管理対象システムのＯＳから動作できない状態であったと判別することができる。
【図面の簡単な説明】
【０００９】
【図１】実施の形態１にかかるシステム管理装置１の構成ブロック図である。
【図２】実施の形態１にかかるウォッチドッグ部の構成ブロック図。
【図３】実施の形態１にかかるウォッチドッグ部１１の動作タイミング図である。
【図４】実施の形態１にかかる生存フラグ受信部１３の構成ブロック図である。
【図５】管理対象システム２の構成ブロック図である。
【図６】プログラム処理を実行するときのソフトウェア構成図である。
【図７】実施の形態１にかかるシステム管理装置１の動作フローチャートである。
【図８】生存フラグ情報記憶部１９にて記憶される記録フォーマット図である。
【図９】実施の形態２にかかるシステム管理装置１の構成ブロック図である。
【図１０】リカバリー処理実行部４１の構成を示す図である。
【図１１】実施の形態２にかかるシステム管理装置１の動作フローチャートである。
【発明を実施するための形態】
【００１０】
実施の形態１．
図１は、実施の形態１にかかるシステム管理装置１の構成を概略的に示すブロック図である。システム管理装置１は、管理対象システム２と通信可能に接続されている。図１では、内部バスインターフェース（ＩＦともいう）２０を介して内部バス３で接続されている。ここで、管理対象システム２は、プロセッサを備え、ＯＳを起動してＯＳ上のアプリを実行するものである。
【００１１】
次にシステム管理装置１について説明する。システム管理装置１は、ウォッチドッグ部１１と、生存フラグ要求送信部１２と、生存フラグ受信部１３と、生存フラグ保持部１４とを備える。また、図１では、さらに表示部１８、時刻情報取得部１５、生存フラグ情報記憶部１９、リセットカウンタ１７、生存カウンタ１９、そして内部バスインターフェース２０を備えた構成を示す。
【００１２】
内部バスインターフェース２０は、管理対象システム２とシステム管理装置１とを内部バス３を介して接続するインターフェースであり、管理対象システム２がマスターとなってウォッチドッグ部１１もしくは生存フラグ受信部１３とのデータのリード・ライトをするためのパラレルバスインターフェースである。なお、内部バス３はシリアルバスインターフェースでもよい。
【００１３】
ウォッチドッグ部１１は、所定の周期でカウント値をカウントするウォッチドッグタイマー１１１を有し、管理対象システム２から入力された初期化情報であるクリア信号ｓｉｇＣが入力された場合は、ウォッチドッグタイマー１１１のカウント値を初期値に設定する。また、ウォッチドッグ部１１は、ウォッチドッグタイマー１１１のカウント値が閾値になった場合に閾値到達情報を出力する。ここで、管理対象システム２は、正常に動作している場合は、ウォッチドッグタイマー１１１の初期値から閾値になるよりも短い期間にシステム管理装置１のウォッチドッグ部１１へクリア信号ｓｉｇＣを出力する。従って、ウォッチドッグ部１１は、管理対象システム２が正常に動作している間はカウント値が閾値にならないように初期値及び閾値が設定されている。
【００１４】
図２は、実施の形態１にかかるウォッチドッグ部の構成を概略的に示すブロック図である。ウォッチドッグ部１１は、ウォッチドッグタイマー１１１、タイマーリセット部１１２、比較部１１３、閾値保持部１１４、リセット出力部１１５、割り込み出力通知部１１６を備える。タイマーリセット部１１２は、クリア信号ｓｉｇＣが入力された場合に、ウォッチドッグタイマー１１１のカウント値を初期値に設定する。ここで初期値は、本実施の形態でのウォッチドッグタイマー１１１のカウントの始まりを示すタイマーリセット値であって、ゼロである必要はなく、設定されたロード値であっても構わない。
【００１５】
ウォッチドッグタイマー１１１は、所定の周期でカウント値をカウントする。所定の周期は、例えばシステム管理装置１のシステムクロックなどに基づく周期である。例えば、システム管理装置１のシステムクロックそのものを用いて、システムクロックの１周期ごとにカウント値を１ずつデクリメントする。
【００１６】
閾値保持部１１４は、生存フラグ要求送信部１２に対して割り込み通知信号を出力するウォッチドッグタイマー１１１のカウント値を保持している。この閾値については予め設定した固定値であっても構わないし、変更可能な値に設定できるようにしてもよい。例えば、内部バス３を介して管理対象システム２のプロセッサから設定可能にする方法などがある。
【００１７】
比較部１１３は、ウォッチドッグタイマー１１１のカウント値と閾値保持部１１４で設定された閾値との比較を行ない、ウォッチドッグタイマー１１１のカウント値と閾値との比較結果を示す情報を出力する。例えば加算器で構成し、閾値の負の値とウォッチドッグタイマー１１１のカウント値とを加算することでウォッチドッグタイマー１１１のカウント値と閾値との差分結果を求めることができる。
【００１８】
リセット出力部１１５は、比較部１１３からの情報と、生存フラグ受信部１３からの情報から管理対象システム２へのリセット指示情報を出力する。リセット指示情報は管理対象システム２全体をリセットする第１のリセット信号ｓｉｇＲ１と、管理対象システム２内のアプリをリセットする第２のリセット信号ｓｉｇＲ２とを有する。システムリセットは第１のリセット信号ｓｉｇＲ１に基づいて行われる。
【００１９】
割り込み出力通知部１１６は、比較部１１３の結果に基づいてウォッチドッグタイマー１１１のカウント値が閾値に到達したことを示す閾値到達情報を生存フラグ要求送信部１２へ出力する。例えば、ウォッチドッグタイマー１１１がカウント値をデクリメントするタイマーである場合は、ウォッチドッグタイマー１１１のカウント値から閾値を引いた差分値が負の値になったときに閾値到達情報を出力する。
【００２０】
生存フラグ要求送信部１２は、ウォッチドッグタイマー１１１が閾値到達情報を出力したときに、管理対象システム２へ生存フラグ要求割り込み信号ｓｉｇＲＱを出力する。生存フラグ要求割り込み信号ｓｉｇＲＱは、管理対象システム２に対してシステム管理装置１へ生存フラグを送信することを要求する割り込み信号である。管理対象システム２が正常動作している場合は、管理対象システム２は生存フラグ要求割り込み信号ｓｉｇＲＱが入力されればシステム管理装置１へ生存フラグを送信する。
【００２１】
生存フラグ受信部１３は、閾値到達情報が出力されてから所定の期間内に管理対象システム２から生存フラグｓｉｇＦが入力されたか否かを示す情報を、ウォッチドッグタイマー１１１のリセット出力部１１５に出力する。生存フラグ受信部１３の詳細については後述する。
【００２２】
図３は、ウォッチドッグ部１１の動作タイミングを示す図である。縦軸はウォッチドッグタイマー１１１のカウント値を示し、横軸は時間経緯を示す。ここでは、ウォッチドッグタイマー１１１は所定の周期でカウント値をデクリメントするタイマーとして示している。
【００２３】
管理対象システム２が通常に動作している間は、ウォッチドッグタイマー１１１のカウント値が初期値から閾値になるまでの間よりも短い間隔でクリア信号ｓｉｇＣが入力されるので、管理対象システム２からクリア信号ｓｉｇＣが入力されれば、タイマーリセット部１１２によってカウント値は初期値に戻る。
【００２４】
図３では２回初期値に戻った後に管理対象システム２に何らかのトラブルが生じてクリア信号ｓｉｇＣが来なくなった状態を示す。このとき、ウォッチドッグタイマー１１１のカウント値は閾値以下となり閾値到達情報が出力され、生存フラグ要求送信部１２は、管理対象システム２へ生存フラグ要求割り込み信号ｓｉｇＲＱを出力する。
【００２５】
その後、生存フラグ受信部１３から生存フラグ受信完了信号が出力されたときに、リセット出力部１１５は、比較部１１３からの情報と、生存フラグ受信部１３からの情報から管理対象システム２へのリセット指示情報を出力する。
【００２６】
リセット出力部１１５は、閾値到達情報が出力され、生存フラグｓｉｇＦが入力されたことを示す情報が入力された場合は、管理対象システム２は、ウォッチドッグタイマーをクリアするアプリは異常のある状態であるが、生存フラグ要求割り込み信号ｓｉｇＲＱに対する生存フラグｓｉｇＦを返すことが可能な状態であると判断する。つまり、この場合は管理対象システム２のＯＳは正常に動作している状態でアプリ自体が異常をきたしていると判断できる。この場合は、管理対象システム２内のアプリをリセットする第２のリセット信号ｓｉｇＲ２を管理対象システム２へ出力する。これにより、管理対象システム２は、管理対象システム２全体をリセットすることなく、管理対象システム２内のアプリをリセットすることになるので、管理対象システム２全体をリセットするよりも管理対象システム２のアプリ動作を早く復旧することができる。
【００２７】
一方、閾値到達情報が出力され、生存フラグｓｉｇＦが入力されなかったことを示す情報が入力された場合は、管理対象システム２は、ウォッチドッグタイマーをクリアするアプリが異常のある状態であり、生存フラグ要求割り込み信号ｓｉｇＲＱに対する生存フラグｓｉｇＦを返すことも不可能な状態であると判断する。つまり、この場合は管理対象システム２のＯＳが正常に動作していない状態であると判断できる。この場合は、管理対象システム２全体をリセットする第１のリセット信号ｓｉｇＲ１を管理対象システム２へ出力する。これにより、管理対象システム２は、管理対象システム２全体をリセットする。
【００２８】
図４は、生存フラグ受信部１３の構成ブロック図の一例を示す。生存フラグ受信タイマー部１３１は、生存フラグ要求送信部１２が生存フラグ要求割り込み信号ｓｉｇＲＱを出力した情報を入力し、生存フラグ要求割り込み信号ｓｉｇＲＱが出力されてから所定の期間（タイムアウト時間）をカウントし、所定の期間が到達したときにラッチ部１３２に所定の期間が到達したことを示す生存フラグ受信完了信号を出力する。生存フラグ受信タイマー部１３１がカウントするカウント量はこの閾値については予め設定した固定値であっても構わないし、変更可能な値に設定できるようにしてもよい。例えば、内部バス３を介して管理対象システム２のプロセッサから設定可能にする方法などがある。
【００２９】
ラッチ部１３２は、生存フラグｓｉｇＦの状態を保持し、後段の生存フラグ保持部１４と生存フラグカウンタ１６に結果を出力する。例えば、生存フラグｓｉｇＦが通常はＬｏｗレベル電位であって、管理対象システム２が生存フラグ要求割り込み信号ｓｉｇＲＱに対する生存フラグｓｉｇＦを返したときにＨｉｇｈレベル電位を示すＨｉアクティブのデジタル信号とすれば、ラッチ部１３２は、生存フラグｓｉｇＦの立ち上がりエッジを検出してラッチする。これにより、ラッチ結果がＨｉｇｈレベルであれば、管理対象システム２が生存フラグ要求割り込み信号ｓｉｇＲＱに対する生存フラグｓｉｇＦを返したことが判定できる。一方、ラッチ結果がＬｏｗレベルであれば管理対象システム２が生存フラグｓｉｇＦを出力していないことが判定できる。つまり、ラッチ結果は、生存フラグｓｉｇＦを受信したか否かを示す生存フラグ情報を表す。以降においても、生存フラグｓｉｇＦが通常はＬｏｗレベル電位であって、管理対象システム２が生存フラグ要求割り込み信号ｓｉｇＲＱに対する生存フラグｓｉｇＦを返したときにＨｉｇｈレベル電位を示すＨｉアクティブのデジタル信号として説明するが、信号極性の設定についてはこれに限るものではないことは明らかである。
【００３０】
生存フラグ保持部１４は、生存フラグ受信部１３にて生存フラグｓｉｇＦを受信したか否かを示す生存フラグ情報を保持する。これにより、生存フラグが受信できた場合は、管理対象システム２のＯＳは動作可能であるがウォッチドッグ部１１へ初期化情報を出力するアプリケーションプログラムが動作できない状態であったと判断できる。一方、生存フラグが受信できなかった場合は、管理対象システムのＯＳから動作できない状態であったと判別することができる。
【００３１】
図１に戻って説明する。時刻情報取得部１５は、生存フラグ受信完了信号が入力された時刻情報を取得する。例えば、生存フラグ受信タイマー部１３１からの生存フラグ受信完了信号をトリガーとしてリアルタイムクロックと通信を行ない、生存フラグ受信完了信号を受信した時刻情報を取得する。
【００３２】
生存フラグカウンタ１６は、生存フラグ要求送信部１２が出力した生存フラグ要求割り込みｓｉｇＲＱに対して、管理対象システム２から生存フラグｓｉｇＦが返ってきた回数をカウントするカウンタである。カウント回数は、ある一定期間でリセットされてもよいし、ある一定回数カウントするとリセットされてもよいし、管理対象システム２からリセットされるように構成されていてもよい。
【００３３】
リセットカウンタ１７は、ウォッチドッグ部１１によって管理対象システム２へリセットをかけた回数をカウントするカウンタである。カウント回数は、ある一定期間でリセットされてもよいし、ある一定回数カウントするとリセットされてもよいし、管理対象システム２からリセットされるように構成されていてもよい。ただし、生存フラグカウンタ１６のカウント回数のリセットタイミングと同じにしておくことが望ましい。
【００３４】
表示部１８は、管理対象システム２を管理しているシステム管理者に対して、生存フラグ保持部１４で保持されている管理対象システム２から生存フラグが返ってきたかを示すフラグ情報を入力し、管理対象システム２にエラー停止があった旨や、エラー停止要因および、生存フラグカウンタ１６やリセットカウンタ１７のカウント値を用いてエラー停止した回数などの情報を表示するように構成されている。また、表示部１８はシステム管理装置１の一部ではなく、外部の液晶モニターなどの表示装置に表示できる映像コネクタを備えた構成となっていてもよい。
【００３５】
生存フラグ情報記憶部１９は、不揮発性メモリなどの半導体メモリで構成されており、システムメンテナンス時のログとしてシステム管理装置１で受信した生存フラグ情報をメモリに記録しておく。具体的には、生存フラグ保持部１４で保持されている管理対象システム２から生存フラグが返ってきたかを示す生存フラグ情報を入力し、その生存フラグ情報と共に時刻情報取得部１５で取得している時刻を記録する。さらに、生存フラグカウンタ１６のカウント数およびリセットカウンタ１７のカウント数およびリセットカウンタ１７のカウント数と生存フラグカウンタ１６のカウント数との差分を記録してもよい。また、生存フラグ情報記憶部１９は、システム管理装置１に内部バス３のマスター機能を持たせることで、システム管理装置１の一部ではなく内部バス３に接続された不揮発性メモリに記録されてもよいし、図１には図示していない内部バス３に接続された記憶媒体に記録されてもよい。
【００３６】
図５は、管理対象システム２の構成例および管理対象システム２を含めたシステム全体の構成要素を示すブロック図である。図５に示されるように、管理対象システム２は、プロセッサ２１、メモリ２３、ワークメモリ２２、通信部２４、外部インターフェース２５を備えており、プロセッサ２１とメモリ２３、およびシステム管理装置１は内部バス３で接続されている。さらに、プロセッサ２１へはシステム管理装置１から割り込み信号ｓｉｇＲＱが接続されている。
【００３７】
プロセッサ２１は、メモリ２３に記憶されているプログラムを実行する。具体的には、プロセッサ２１は、メモリ２３に記憶されているプログラムやその他のデータのうち必要となるものをワークメモリ５に読み出し、ワークメモリ２２にアクセスし、ワークメモリ５に読みだされたプログラムに記述されている処理を実行する。プログラムやその他のデータは、例えば、メモリ２３においてブロックごとに記憶され、ブロックごとに読み出される。
【００３８】
不揮発性メモリ２３は、各種のデータを記憶する読み書き可能なメモリであり、例えばフラッシュメモリのような不揮発性メモリである。メモリ２３は、ＯＳやＯＳ配下のドライバ、およびアプリケーションで使用されるプログラムデータを記憶する。
【００３９】
ワークメモリ２２は、プロセッサ２１の作業領域として使用されるメモリであり、例えば（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）である。ワークメモリ２２は、不揮発性メモリ２３から読み出されたデータを記憶する。
【００４０】
通信部２４は、プロセッサ２１が管理対象システム２に接続された外部の機器と外部インターフェース２５を介して通信を行う際に、相受信データを外部接続機器との通信プロトコルに従って変換する。
【００４１】
外部インターフェース２５は、管理対象システムと外部接続機器とを接続するインターフェースであり、例えばＵＳＢ（Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ）インターフェースである。また、外部インターフェース２５には、ＵＳＢ以外にも、例えばＡＴＡインターフェースを持ったＨＤＤや、管理対象システム２の制御を行うためのコマンド入力部としてのユーザー操作のためのＲＳ２３２Ｃのシリアルインターフェースなど様々なインターフェースを持った外部機器が接続される。
【００４２】
内部バス３は、プロセッサ２１が制御する読み書き可能なデータバスであり、不揮発性メモリ４やシステム管理装置１とのデータのやりとりを行うものである。プロセッサ２１は、内部バス３を経由してシステム管理装置１内部にあるレジスタ空間や不揮発性メモリに記憶されているデータへのアクセスが可能でなる。
【００４３】
図６は、プロセッサ２１においてプログラム処理を実行するときのソフトウェア構成図である。プロセッサ２１上で動作するソフトウェアはソフトウェア層ごとにデバイスドライバ２１１、カーネル２１２、アプリケーション２１３で構成されており、それらが相互に動作することで所望の動作を実現している。
【００４４】
デバイスドライバ２１１は、プロセッサ２１に対してワークメモリ２２や内部バス３などの機器内部で接続されているデバイスや、通信部２４および外部インターフェース２５を介して外部に接続されたデバイスを制御・操作するためのソフトウェアであり、カーネル２１２がこれらのデバイスを制御するために、デバイスドライバ２１１は上記の接続されているデバイスが持っているレジスタ空間などにアクセスしてデータの送受信や通信およびデバイスの設定などを行う。
【００４５】
カーネル２１２はＯＳを構成するプログラムであり、アプリケーション２１３からのシステムコールに対して、適切なデバイスドライバ２１１を制御することでデバイスドライバ２１１に接続しているデバイスからのデータを受信し、アプリケーション２１３に受信したデータを用いた処理結果を提供する。また、カーネル２１２は、システム管理装置１からの割り込みである割り込み信号ｓｉｇＲＱを受信し、割り込み信号ｓｉｇＲＱに対応する例外処理を行うためにデバイスドライバ２１１を制御し、例外処理を実行するように動作する。
【００４６】
つまり、割り込み信号ｓｉｇＲＱはカーネル２１２で受信し、カーネル２１２がデバイスドライバ２１１を制御することで割り込み信号ｓｉｇＲＱに対応する例外処理が実行されるため、アプリケーション２１３が停止していた場合でも割り込み信号ｓｉｇＲＱに対応する例外処理は実行可能である。しかし、カーネル２１２もしくはデバイスドライバ２１１が停止している状態では割り込み信号ｓｉｇＲＱを受信できないため、割り込み信号ｓｉｇＲＱに対応する例外処理は実行されないことになる。
【００４７】
アプリケーション２１３は、上位のアプリケーションプログラムであり、管理対象システム２が持つ機能を実現させるための特定の処理を行うソフトウェアであり、ソフトウェア上でカーネル２１２を呼びだし、所望のデータを得ることで管理対象システム２が持つ機能を実現させる。
【００４８】
次に、システム管理装置１の動作の流れについて説明する。図７は、本実施の形態１におけるシステム管理装置１の動作を示すフローチャートである。図７においてＳから始まる符号はそれぞれの処理ステップについて付けた符号を示す。
【００４９】
システム管理装置１、および管理対象システム２に電源が入り、システムリセットが解除されると、プロセッサ２１はメモリ２３内のデバイスドライバ２１１およびカーネル２１２のプログラムが記憶されている所定のアドレスにアクセスし、ワークメモリ２２へそれらのプログラムを転送する。そしてプロセッサ２１は、カーネル２１２のプログラムを順次実行することでデバイスドライバ２１１およびカーネル２１２を起動する。デバイスドライバ２１１およびカーネル２１２の起動が完了するとカーネル２１２にて指定されたアプリケーション２１３のプログラムを同様にワークメモリ２２へ転送し、順次プログラム処理を実行することでアプリケーション２１３を起動する。
【００５０】
デバイスドライバ２１１、カーネル２１２、アプリケーション２１３の起動が完了するとウォッチドッグタイマー１１１のカウントをスタートさせ、ウォッチドッグ部１１に供給されるシステムクロックに同期してウォッチドッグタイマー１１１のカウント値をデクリメントする（Ｓ１）。なお、ウォッチドッグタイマー１１１の初期値は予め設定されたタイマーリセット値である。タイマーリセット値はプロセッサ２１により内部バス３経由で設定してもよいし、ウォッチドッグタイマー１１１のカウント値の全ビットを１とした値としてもよい。
【００５１】
管理対象システム２では、アプリケーション２１３として、定期的にシステム管理装置１に対してウォッチドッグ部１１へクリア信号を出力するタスクがプログラムされており、アプリケーション２１３からカーネル２１２を介してクリア信号が出力される。そのため、管理対象システム２が正常に動作している場合は定期的にウォッチドッグ部１１へクリア信号が出力されるようになっている。このように、管理対象システム２からウォッチドッグ部１１へクリア信号が出力されると（Ｓ２：ＹＥＳ）、タイマーリセット部１１２でクリア信号を受信し、ウォッチドッグタイマー１１１に対してタイマーリセットをかける（Ｓ３）。タイマーリセットがかかるとウォッチドッグタイマー１１１は継続してシステムクロックに同期してカウント値をデクリメントする。
【００５２】
一方で、アプリケーション２１３のバグなどにより、あるタスクで無限ループに入ってしまった場合、ウォッチドッグ部１１へクリア信号を出力するタスクに移行できないため、管理対象システム２からクリア信号が出力されないことになる。また、カーネル２１２がデバイスドライバ２１１を介して、例えば外部インターフェース２５に接続された外部機器との間で通信エラーなどが発生し、カーネル２１２が停止してしまった場合も、内部バス３の制御、およびクリア信号を出力するカーネル２１２が停止してしまっているため、クリア信号を出力できない。
【００５３】
管理対象システム２が上述したような状態に陥り、クリア信号がシステム管理装置１に入力されない場合（Ｓ２：ＮＯ）、ウォッチドッグタイマー１１１のカウント値が閾値保持部１１４で保持されている閾値よりも大きいかどうかを比較部１１３にて判定する（Ｓ４）。ウォッチドッグタイマー１１１のカウント値が閾値保持部１１４で保持されている閾値よりも大きい場合（Ｓ４：ＮＯ）、継続してウォッチドッグタイマー１１１を動作させるため、Ｓ１に戻りウォッチドッグタイマー１１１をデクリメントする。
【００５４】
一方で、ウォッチドッグタイマー１１１のカウント値が閾値保持部１１４で保持されている閾値以下の場合（Ｓ４：ＹＥＳ）、割り込み出力通知部１１６から割り込み通知信号が生存フラグ要求送信部１２に出力され、生存フラグ要求送信部１２から管理対象システム２に対して割り込み信号ｓｉｇＲＱとして生存フラグ要求割り込みが出力される（Ｓ５）。
【００５５】
生存フラグ要求割り込みが出力されると管理対象システム２からの生存フラグの受信待ちのため、生存フラグ受信部１３を構成している生存フラグ受信タイマー部１３１のタイマー計測を開始する（Ｓ６）。生存フラグ受信タイマー部１３１はタイムアウト時間が設定されており、設定されたタイムアウト時間となるまでカウントを継続する。
【００５６】
ここで、管理対象システム２が生存フラグ要求割り込みを受信したときの管理対象システム２の動作について説明する。管理対象システム２に生存フラグ要求送信部１２からの割り込み信号ｓｉｇＲＱである生存フラグ要求割り込みが入力されると、管理対象システム２では、カーネル２１２が割り込み受信を検知し、生存フラグ要求割り込み受信時の例外処理を実行する。カーネル２１２は、生存フラグ要求割り込み受信時の例外処理として、デバイスドライバ２１１を制御し、内部バス３を介して生存フラグをシステム管理装置１に出力するよう動作する。そのため、アプリケーション２１３が無限ループに入ってしまいハングアップしてしまっている場合、カーネル２１２は動作しているため、デバイスドライバ２１１を制御して生存フラグをシステム管理装置１に返すことが可能である。次に、カーネル２１２がハングアップした場合、生存フラグ要求割り込みが入力されても割り込み受信の検知ができず、生存フラグ要求割り込み受信時の例外処理を実行できないため、生存フラグをシステム管理装置１に返すことができない。
【００５７】
システム管理装置１では、管理対象システム２から生存フラグが返ってきた場合、生存フラグ受信部１３を構成するラッチ部１３２にて生存フラグの立ち上がりエッジを検出し、「１」をラッチする（Ｓ７）。一方、生存フラグが返って来ない場合、立ち上がりエッジを検出できないためラッチ部１３２は「０」となる。
【００５８】
生存フラグ受信タイマー部１３１がタイムアウトになっていない間（Ｓ８：ＮＯ）は、ラッチ部１３２にて生存フラグの受信待ち状態を継続する。一方で、生存フラグ受信タイマー部１３１がタイムアウトとなった場合（Ｓ８：ＹＥＳ）、タイムアウト時に生存フラグ受信タイマー部１３１は生存フラグ受信完了信号を出力し（Ｓ９）、タイムアウト時にラッチ部１３２でラッチしている値を生存フラグ情報として生存フラグ保持部１４と生存フラグカウンタ１６に出力する（Ｓ１０）。
【００５９】
ここで、生存フラグ情報が「１」の場合は、管理対象システム２から生存フラグが返ってきたことを示し、「０」の場合は、管理対象システム２から生存フラグが返ってこなかったことを示している。上述した通り、管理対象システム２において、デバイスドライバ２１１、およびカーネル２１２が動作している場合は生存フラグを返すことが可能であり、デバイスドライバ２１１、およびカーネル２１２が動作していない場合は生存フラグを返すことができない。つまり、生存フラグ情報は、デバイスドライバ２１１およびカーネル２１２が動作しているかどうかを示す情報であり、「１」の場合はデバイスドライバ２１１およびカーネル２１２が動作している、「０」の場合はデバイスドライバ２１１およびカーネル２１２が停止していることを表している。そのため、生存フラグ情報から停止している箇所がデバイスドライバ２１１およびカーネル２１２なのか、アプリケーション２１３なのかを判別することが可能となる。
【００６０】
生存フラグ保持部１４では、生存フラグ受信部１３より入力した生存フラグ情報をレジスタで保持する（Ｓ１１）。保持するレジスタは生存フラグ保持部１４の内部でもよいし、内部バス３を介してプロセッサ２１がアクセス可能なレジスタに保持しておいてもよい。また、保持している生存フラグ情報は生存フラグ要求送信部１２より生存フラグ要求割り込みが出力されるたびにクリアされる。
【００６１】
時刻情報取得１５は、生存フラグ受信部１３を構成する生存フラグ受信タイマー部１３１からの生存フラグ受信完了信号をトリガーとしてリアルタイムクロックと通信を行い、生存フラグ受信完了信号を受信した時刻情報を取得する（Ｓ１２）。
【００６２】
また、生存フラグ受信部１３から生存フラグ情報が出力されると、生存フラグカウンタ１６にて、生存フラグ情報が「１」の場合（Ｓ１３：ＹＥＳ）は、生存フラグカウンタ１６をインクリメントし（Ｓ１４）、生存フラグ情報が「０」の場合（Ｓ１３：ＮＯ）は、生存フラグカウンタ１６をインクリメントしない。なお、生存フラグカウンタ１６のリセットは、あらかじめ決められた期間でリセットを行ってもよいし、あらかじめ決められた回数に達するとリセットを行ってもよいし、内部バス３を介してプロセッサ２１からリセットをかけるようにしてもよい。
【００６３】
生存フラグ受信完了信号が出力され、かつ、ウォッチドッグ部１１のウォッチドッグタイマー１１１のカウント値が閾値保持部１１４で保持している閾値以下である場合に、リセット出力部１１５は管理対象システム２のリセットを行うリセット信号を出力し、管理対象システム２の再起動を行う。ここで、リセット信号は、管理対象システム２のアプリケーション２１３のみのリセットを行うアプリリセット信号と管理対象システム２のシステム全体のリセットを行うシステムリセット信号に分かれており、生存フラグ情報の値を参照して出力するリセット信号を切り替えてもよい。つまり、生存フラグ情報が「１」の場合は、上述の通り、デバイスドライバ２１１およびカーネル２１２は動作している状態であるため、アプリケーション２１３のみをリセットすればよいため、アプリリセット信号を出力する。一方で、生存フラグ情報が「０」の場合は、デバイスドライバ２１１およびカーネル２１２が動作していない状態であるため、システム全体をリセットする必要があり、システムリセット信号を出力する。このようにすることでデバイスドライバ２１１およびカーネル２１２が動作している場合はアプリケーション２１３のみを再起動することができるため、再起動時間を短縮できると共に、デバイスドライバ２１１およびカーネル２１２が保持している他の情報をクリアすることなくシステムの動作を継続することが可能となる。
【００６４】
ウォッチドッグ部１１よりリセット信号が出力されるとリセットカウンタ１７をインクリメントする（Ｓ１６）。なお、リセットカウンタ１７のリセットは、あらかじめ決められた期間でリセットを行ってもよいし、あらかじめ決められた回数に達するとリセットを行ってもよいし、内部バス３を介してプロセッサ２１からリセットをかけるようにしてもよい。
【００６５】
生存フラグ情報記憶部１９にて、生存フラグ情報、時刻情報、リセットカウンタ値、生存フラグカウンタ値を入力し、それらをメモリへ記録する（Ｓ１７）。メモリへの記録は、生存フラグ受信完了信号を受けて、生存フラグ情報、時刻情報、リセットカウンタ値、生存フラグカウンタ値の更新が終了するたびに実施される。
【００６６】
図８は、生存フラグ情報記憶部１９にて記憶される情報の記録フォーマットを示す図である。生存フラグ受信部１３から出力された生存フラグ情報に対して、生存フラグ情報が出力された時刻情報とそのときのリセットカウンタ値と生存フラグカウンタ値、およびリセットカウンタ値と生存フラグカウンタ値の差分が一列で参照できるように記憶される。このように記録することで管理対象システム２のメンテナンス時などに管理対象システム２が停止した原因や時刻、回数を一覧表示することができ、システムメンテナンスによるデバッグ作業を容易にすることができる。ここで、リセットカウンタ値と生存フラグカウンタ値との差分はデバイスドライバ２１１およびカーネル２１２がエラー要因となった回数を表している。
【００６７】
さらに、表示部１８にて、生存フラグ情報、リセットカウンタ値、生存フラグカウンタ値を参照して管理対象システム２の状態を液晶モニターなどの表示機に表示する。表示内容としては、エラー停止要因として、生存フラグ情報が「１」の場合は、アプリケーションエラーと表示し、生存フラグ情報が「０」の場合は、カーネルエラーと表示する。また、リセットカウンタ値を停止回数として表示し、生存フラグカウンタ値をアプリケーションエラー回数として表示し、さらに、リセットカウンタ値と生存フラグカウンタ値との差分をカーネルエラー回数として表示する。このように表示することで管理対象システム２のシステム管理者は、管理対象システム２が停止したことに加えて、停止要因と停止回数などを容易に知ることができる。
【００６８】
ここで、本実施の形態１では、システム管理装置１と管理対象システム２とのデータのやり取りを内部バス３にて行うように構成したが、専用の通信線を使用してもよいし、汎用的なシリアルインターフェースもしくはパラレルインターフェースを用いてもよいし、イーサネット（Ｅｔｈｅｒｎｅｔ（登録商標））などのネットワークを使用してもよく、これに限られるものではない。
【００６９】
以上に説明したように、実施の形態１に係るシステム管理装置１およびシステム管理方法によれば、管理対象システム２がウォッチドッグタイマー１１１によるタイムオーバーとなった場合、ウォッチドッグ部１１から管理対象システム２のリセットをかける前に、管理対象システム２に対して生存フラグ要求割り込みを出力し、生存フラグが返ってきたか否かを示す生存フラグ情報を取得することで、アプリケーション２１３に起因しているのか、デバイスドライバ２１１およびカーネル２１２が停止していることに起因しているのかを判別することができる。
【００７０】
また、実施の形態１に係るシステム管理装置１およびシステム管理方法によれば、生存フラグ情報から判別したエラー要因に加えて、リセットカウンタ１７のカウンタ値によるシステムリセット回数と生存フラグカウンタ１６のカウンタ値によるアプリケーションエラー回数およびリセットカウンタ値と生存フラグカウンタ値との差分であるカーネルエラー回数を表示する表示機を備えることで、管理対象システム２のシステム管理者に対して、管理対象システム２が停止したことを表示機に表示することで知らせることができるとともに、管理対象システム２の停止要因と停止回数などを知らせることができ、システムメンテナンスによる保守時に容易にシステムデバッグを行うことができる。
【００７１】
また、実施の形態１に係るシステム管理装置１およびシステム管理方法によれば、生存フラグ情報から判別したエラー要因に加えて、生存フラグ情報の更新した時刻情報とそのときのリセットカウンタ値と生存フラグカウンタ値、およびリセットカウンタ値と生存フラグカウンタ値との差分を生存フラグ情報記憶部１９にログ情報として記録することで、保守時にそれらの情報を参照することができ、容易にシステムデバッグを行うことができる。
【００７２】
また、実施の形態１に係るシステム管理装置１およびシステム管理方法によれば、ウォッチドッグ部１１に生存フラグ要求送信部１２と生存フラグ受信部１３を追加することで生存フラグ情報を得ることができ、管理対象システム２のエラー要因の判別が可能となり、システム管理装置１を複雑な構成にすることなく、容易に構成することができ、さらにシステム管理装置１の回路規模を増大させることなくコストを抑えることができる。
【００７３】
実施の形態２．
実施の形態１にかかるシステム管理装置１では、ウォッチドッグタイマーがタイムオーバーとなった場合に、管理対象システム２に対してリセットをかける前に、管理対象システム２に対して生存フラグ要求割り込みを出力し、管理対象システム２から生存フラグが返ってきたか否かを示す生存フラグ情報を取得する装置について説明した。実施の形態２では、さらに管理対象システム２がリセットを入力してからシステムの正常動作が行えるまでの復帰期間を、システム管理装置１が管理対象システム２に備えられた処理部の動作について代替処理を行なうリカバリー処理実行部を備える。
【００７４】
図９は、実施の形態２にかかるシステム管理装置１の構成を概略的に示すブロック図である。システム管理装置１は、管理対象システム２と通信可能に接続されている。図９では、内部バスＩＦ２０を介して内部バス３で接続されている。
【００７５】
ここで、管理対象システム２は、プロセッサを備え、ＯＳを起動してＯＳ上のアプリを実行するものである。
【００７６】
まずは、本実施の形態にかかる管理対象システム２について説明する。図２では、本実施の形態にかかる管理対象システム２を、監視カメラシステムとして説明する。この場合、管理対象システム２は、カメラ２６と監視記録部２８とメモリ部２９を備える。監視カメラシステムは、カメラからの撮像画像を常時または定期的に記録するので、動作不良で記録できない期間やシステムリセットからの復帰期間が短い方が望ましい。また、監視記録部２８は、実施の形態１に示すプロセッサ２１及びメモリ２３によって構成される。
【００７７】
カメラ２６は、撮像した画像を映像データに変換する。カメラ２６は、例えば壁や天井などに取り付けられ、通行する人や物を撮影するために設置されている。
【００７８】
監視記録部７２は、カメラ２６から入力された映像データを映像フォーマットに変換してメモリ部２９に記録を行なう記録処理を行なう。ここで、映像フォーマットは、例えば映像であればＭＰＥＧ（Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ）−２や、Ｈ．２６４（ＭＰＥＧ−４  ＡＶＣ）など映像圧縮方式に基づいたフォーマットを示すものである。
【００７９】
また、メモリ部２９への記録アドレスと記録した映像が撮影された日時とを対応するような検索テーブルを作成し、そのテーブルに記録した情報を追加しながら記録を行うことで、メモリ部２９に記録された映像の検索性を高めることができる。
【００８０】
メモリ部２９は、入力された映像データを記憶する記憶媒体であり、指定されたアドレスにデータを記憶する。なお、メモリ部２９は、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）のような磁気記憶装置であってもよいし、フラッシュメモリ（Ｆｌａｓｈ  Ｍｅｍｏｒｙ）を用いたメモリーカードや光ディスクを使用した記憶媒体であってもよく、データを保存することが可能な記憶媒体であればよい。図２ではメモリ部２９をＨＤＤ２９と示している。
【００８１】
本実施の形態にかかる管理対象システム２である監視カメラシステムでは、カメラ２６と監視記録部２８との間にセレクタ２７１を備えている。セレクタ２７１は、入力をカメラ２６とし出力を監視記録部２８及びシステム管理装置１が備えるリカバリー処理実行部４１として接続されており、システム管理装置１が備えるリカバリー制御部４２からの選択制御信号によって出力を監視記録部２８及びリカバリー処理実行部４１のいずれかに出力する。
【００８２】
同様に、監視記録部２８とメモリ部２９との間にセレクタ２７２を備えている。セレクタ２７２は、入力を監視記録部２８及びシステム管理装置１が備えるリカバリー処理実行部４１とし出力をメモリ部２９として接続されており、システム管理装置１が備えるリカバリー制御部４２からの選択制御信号によって入力を監視記録部２８及びリカバリー処理実行部４１のいずれかを選択して選択した側から入力されたデータをメモリ部２９に出力する。
【００８３】
次に、本実施の形態にかかるシステム管理装置１について説明する。本実施の形態にかかるシステム管理装置１は、実施の形態１にかかるシステム管理装置１と同様にウォッチドッグ部１１、生存フラグ要求送信部１２、生存フラグ受信部１３、及び内部バスＩＦ２０を備える。ウォッチドッグ部１１、生存フラグ要求送信部１２、生存フラグ受信部１３、及び内部バスＩＦ２０の動作については上述の実施の形態１と同じである。
【００８４】
また、図２には生存フラグ保持部１４、時刻情報保持部１５、生存フラグカウンタ１６、リセットカウンタ１７、表示部１８、及び生存フラグ情報記憶部１９を示していないが本実施の形態にかかるシステム管理装置１においても備える構成であってもよい。この場合の生存フラグ保持部１４、時刻情報保持部１５、生存フラグカウンタ１６、リセットカウンタ１７、表示部１８、及び生存フラグ情報記憶部１９の動作についても上述の実施の形態１と同じである。
【００８５】
図１０は、リカバリー処理実行部４１の構成を示す図である。リカバリー処理実行部４１は、映像受信部４１１と記録処理部４１２と記録データ送信部４１３とを備える。
【００８６】
映像受信部４１１は、管理対象システム２が備えるセレクタ２７１を介してカメラ２６からの映像データを受信し、図示していない内部バッファに受信した映像データを貯め、記録処理部４１２からのデータ転送要求に応じて内部バッファに貯まっている映像データを記録処理部４１２に出力する。
【００８７】
記録処理部４１２は、映像受信部４１１から入力された映像データに対して、メモリ部２９へ記録を行うために記録アドレスを指定し、入力された映像データを記録データ送信部４１３へ出力する。記録処理部４１２は、上述した監視記録部２８で行っているような映像フォーマットの変換および検索用テーブルの作成などの複雑な記録処理は行わず、入力された映像データをそのままアドレスを指定し、記録データ送信部４１３へ出力するように構成されている。このように記録処理部４１２の処理を必要最低限な処理のみを行うように簡易なものとすることで処理開始までにかかる時間を短くすることができるため、すぐにリカバリー処理を実行することが可能となる。さらに、高性能なハードウェアやＣＰＵが不要となりコストを抑制することができる。
【００８８】
記録データ送信部４１３は、記録処理部４１２から入力される映像データを図示していない内部バッファに貯め、メモリ部２９からのデータ転送要求に応じて内部バッファに貯まっている映像データについてセレクタ２７２を介してメモリ部２９に出力する。
【００８９】
映像受信部４１１と記録処理部４１２と記録データ送信部４１３とは、リカバリー制御部４０から処理を実行する指示を示す信号を受信した場合にのみ処理を行なうものとしてもよく、これによりリカバリー処理が必要のない期間は実行を止めることができるため常時動作する場合よりも消費電力の低減に効果を奏する。
【００９０】
リカバリー制御部４２は、ウォッチドッグ部１１におけるエラー要因の判定結果に基づいて管理対象システム２のセレクタ２７１及びセレクタ２７２と、リカバリー処理実行部４１を制御する。エラー要因の判定方法については実施の形態１で説明したので本実施の形態では説明を省略する。
【００９１】
具体的には、エラー要因の判定結果がカーネルエラーとなった場合は、セレクタ２７１の入力であるカメラ２６からの映像信号をリカバリー処理実行部４１へ出力するようにセレクタ２７１に対して選択制御信号を供給し、セレクタ２７２のリカバリー処理実行部４１からの入力を記録処理部４１２へ出力するようにセレクタ２７２に対して選択制御信号を供給する。一方、エラー要因の判定結果がアプリケーションエラーとなった場合は、セレクタ２７１の入力であるカメラ２６からの映像信号を監視記録部２８へ出力するようにセレクタ２７１に対して選択制御信号を供給し、セレクタ２７２の監視記録部２８からの入力を記録処理部４１２へ出力するようにセレクタ２７２に対して選択制御信号を供給する。
【００９２】
また、エラー要因の判定結果がカーネルエラーとなった場合は、リカバリー処理実行部４１に対してリカバリー処理の実行を行なうように例えばイネーブル信号を供給する。一方、エラー要因の判定結果がアプリケーションエラーとなった場合は、リカバリー処理実行部４１はリカバリー処理の実行を行なう必要がないため、例えばディスエーブル信号を供給することでリカバリー処理実行部４１の実行を止めることで常時動作する場合よりも消費電力の低減に効果を奏する。
【００９３】
なお、メモリ部２９の中で、監視記録部２８からきたデータを記録する記録領域を第１の記録領域とし、リカバリー処理実行部４１からきたデータを記録する記録領域を第２の記録領域（リカバリー記録領域ともいう）として、予め別途設けておいても構わない。この場合、通常動作時は監視記録部２８からきたデータを第１の記録領域に記録し、リカバリー処理動作時はリカバリー処理実行部４１からきたデータを第２の記録領域に記録する。
【００９４】
このとき、リカバリー処理が終了し、通常動作に戻った場合に、監視記録部２８がメモリ部２９から第２の記録領域に記録されている映像データを読み出し、正規となる記録処理を行なって第１の記録領域に記録し直すことで、通常動作時と同様の映像フォーマットにて記録しなおすことが可能となる。
【００９５】
次に、本実施の形態におけるシステム管理装置１の動作の流れについて説明する。図１１は、実施の形態２におけるシステム管理装置１の動作を示すフローチャートである。ここで、図１１における処理ステップの符号が図７及び実施の形態１に示した処理ステップの符号と同一であるものは、実施の形態１と同じ動作であるため、本実施の形態では説明を省略する。なお、図１１のスタートから処理ステップＳ１０の間にあるＳ１−Ｓ９と示した処理ステップは、図７及び実施の形態１に示した処理ステップＳ１から処理ステップＳ９までの処理ステップをまとめたものとして示している。
【００９６】
なお、通常動作時は、セレクタ２７１の入力であるカメラ２６からの映像信号を監視記録部２８へ出力するようにセレクタ２７１に対して選択制御信号を供給し、セレクタ２７２の監視記録部２８からの入力を記録処理部４１２へ出力するようにセレクタ２７２に対して選択制御信号を供給する。さらに、リカバリー処理実行部４１は動作する必要がないため、リカバリー処理実行部４１の実行を止めても構わない。
【００９７】
本実施の形態では、処理ステップＳ１３以降の動作について説明する。
【００９８】
生存フラグ受信部１３からのエラー停止要因を示す生存フラグ情報が「１」の場合（Ｓ１３：ＹＥＳ）は、アプリケーションエラーであると判定し、リセット出力部１１５から、管理対象システム２のプロセッサ２１上で動作しているアプリケーションをリセットする第２のリセット信号ｓｉｇＲ２を出力する（Ｓ２１）。
【００９９】
処理ステップＳ２１の第２のリセット信号ｓｉｇＲ２を出力した後はシステム管理装置１の作業は一旦終了する。具体的には管理対象システム２内のアプリがリセットから復旧されるまで待ち、処理ステップＳ１を開始することになる。
【０１００】
また、エラー要因の判定結果がアプリケーションエラーとなった場合は、通常動作と同じとして、セレクタ２７１の入力であるカメラ２６からの映像信号を監視記録部２８へ出力するようにセレクタ２７１に対して選択制御信号を供給し、セレクタ２７２の監視記録部２８からの入力を記録処理部４１２へ出力するようにセレクタ２７２に対して選択制御信号を供給する。さらに、リカバリー処理実行部４１は動作する必要がないため、リカバリー処理実行部４１の実行を止めても構わない。
【０１０１】
生存フラグ受信部１３からのエラー停止要因を示す生存フラグ情報が「０」の場合（Ｓ１３：ＮＯ）は、カーネルエラーであると判定し、リセット出力部１１５から、管理対象システム２全体をリセットする第１のリセット信号ｓｉｇＲ１を出力する（Ｓ３１）。
【０１０２】
処理ステップＳ３１の第１のリセット信号ｓｉｇＲ１を出力した後は、リカバリー制御部４２は、セレクタ２７１の入力であるカメラ２６からの映像信号をリカバリー処理実行部４１へ出力するようにセレクタ２７１に対して選択制御信号を供給し、セレクタ２７２のリカバリー処理実行部４１からの入力を記録処理部４１２へ出力するようにセレクタ２７２に対して選択制御信号を供給する（Ｓ３２）。
【０１０３】
また、リカバリー処理実行部４１に対してリカバリー処理の実行を行なうように例えばイネーブル信号を供給する（Ｓ３３）。リカバリー処理を開始するためのトリガー信号であっても構わない。
【０１０４】
次に、処理ステップＳ３１にて出力された第１のリセット信号ｓｉｇＲ１によって、管理対象システム２の再起動が完了し、動作が開始するとウォッチドッグ部１１に対してウォッチドッグのクリア信号が出力される。これにより、管理対象システム２が正常に再起動できたと判断することができる。そのため、クリア信号が入力されない場合（Ｓ３４：ＮＯ）は、継続してリカバリー処理実行部４１にてリカバリー処理を実行する。一方で、クリア信号が入力されると（Ｓ３４：ＹＥＳ）、リカバリー制御部４２は、リカバリー処理実行部４１でのリカバリー処理を停止する（Ｓ３５）。
【０１０５】
続いて、セレクタ２７１の入力であるカメラ２６からの映像信号を監視記録部２８へ出力するようにセレクタ２７１に対して選択制御信号を供給し、セレクタ２７２の監視記録部２８からの入力を記録処理部４１２へ出力するようにセレクタ２７２に対して選択制御信号を供給する（Ｓ３６）。これにより、監視記録部２８での記録処理後の映像データがメモリ部２９に記録されるようになり、通常の動作に切り替わる。
【０１０６】
その後、上述したようにリカバリー処理中にメモリ部２９のリカバリー記録領域に記録した映像データを監視記録部２８が読み出し、監視記録部２８にて通常の記録処理を行い、メモリ部２９の通常記録領域に記録する映像データに変換された映像データをメモリ部２９に記録する（Ｓ３７）。この際、リカバリー処理実行部４１にてリカバリー処理を開始した時刻をシステム管理装置１内部にあるレジスタに記憶しておき、管理対象システム２の監視記録部２８にて、その時刻を内部バス３経由で読み出すことで、撮影された映像の日時情報が取得でき、上述したように、メモリ部２９の記録アドレスと撮影された映像の日時が対応する検索テーブルを作成し、リカバリー処理にて記録した映像についても通常の監視記録部２８にて行われる記録処理と同様に検索性を高めるための検索テーブルを作成することが可能となる。
【０１０７】
以上に説明したように、実施の形態２に係るシステム管理装置１およびシステム管理方法によれば、管理対象システム２がウォッチドッグタイマー１１１によるタイムオーバーとなった場合、ウォッチドッグ部１１から管理対象システム２のリセットをかける前に、管理対象システム２に対して生存フラグ要求割り込みを出力し、生存フラグが返ってきたか否かを示す生存フラグ情報を取得することで、アプリケーション２１３に起因しているのか、デバイスドライバ２１１およびカーネル２１２が停止していることに起因しているのかを判別することができる。
【０１０８】
また、実施の形態２に係るシステム管理装置１およびシステム管理方法によれば、管理対象システム２へのシステムリセットをかけ、管理対象システム２が再起動中にリカバリー処理を行うことで管理対象システム２の処理を補うことができるため、再起動中に重要なデータの記録を行うことができ、管理対象システム２の信頼性を高めることができる。さらに、生存フラグ情報からアプリケーションに起因するエラーと判別されることにより、アプリケーションのみをリセットすることができるため、管理対象システム２全体をリセットした場合に比べ、管理対象システムの復旧時間を短縮することができる。
【０１０９】
また、実施の形態２に係るシステム管理装置１およびシステム管理方法によれば、ウォッチドッグ部１１に生存フラグ要求送信部１２と生存フラグ受信部１３を追加することで生存フラグ情報を得ることができ、管理対象システム２のエラー要因の判別が可能となり、システム管理装置１を複雑な構成にすることなく、容易に構成することができ、さらにシステム管理装置１の回路規模を増大させることなくコストを抑えることができる。
【符号の説明】
【０１１０】
１      システム管理装置
２      管理対象システム
３      内部バス
１１    ウォッチドッグ部
１１１  ウォッチドッグタイマー
１２    生存フラグ要求送信部
１３    生存フラグ受信部
１４    生存フラグ保持部
１５    時刻情報取得部
１６    生存フラグカウンタ
１７    リセットカウンタ
１８    表示部
１９    生存フラグ情報記録部
２０    内部バスインターフェース
２１１  デバイスドライバ
２１２  カーネル
２１３  アプリケーション
【図１】
2016184384.tif 000003
【図２】
2016184384.tif 000004
【図３】
2016184384.tif 000005
【図４】
2016184384.tif 000006
【図５】
2016184384.tif 000007
【図６】
2016184384.tif 000008
【図７】
2016184384.tif 000009
【図８】
2016184384.tif 000010
【図９】
2016184384.tif 000011
【図１０】
2016184384.tif 000012
【図１１】
2016184384.tif 000013