JP2002351700A - コンピュータシステム、プログラム - Google Patents

Abstract

(57)【要約】 【課題】アプリの実行状態を加味してシステム全体の暴
走監視を行うことのできるコンピュータシステムを提供
する。 【解決手段】各アプリ毎の暴走監視タイマを設け、メイ
ン処理から呼び出したそれぞれのアプリにおいてアプリ
の処理が正常に行われた場合にそのアプリ用の暴走監視
タイマをクリアする。一方アプリの処理が異常の場合に
はクリアしない。全アプリの実行終了後、システム全体
の暴走監視処理において、全アプリの暴走監視タイマが
それぞれのアプリ毎に設けた所定の設定値未満であるか
を判定し、設定値未満であれば、システムのウォッチド
ッグタイマをクリアする。一方、暴走監視タイマの値が
設定値以上のものがある場合には、ウォッチドッグタイ
マをクリアしない。したがって、システムがリセットさ
れる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】コンピュータシステム等に関
する。

【０００２】

【従来の技術及び発明が解決しようとする課題】従来よ
り、コンピュータシステムにウォッチドッグタイマを備
え、所定の時間内にウォッチドッグタイマがクリアされ
ない場合にシステムが暴走状態であるとして、システム
リセット等の所定の処理を行う暴走監視システムがあ
る。

【０００３】例えば、図５に示すように、所定時間毎に
メイン処理が起動され、メイン処理においてアプリ処理
（ＡＰＬ０〜４）を順次呼び出して、各アプリ処理によ
って所定の機能を実現するコンピュータシステムにおい
て、メイン処理における各アプリの呼び出し時点をチェ
ックポイントとして、各アプリの呼び出しが正常に行わ
れたか否かを記録しておき、すべてのアプリの呼び出し
が正常に行われた場合にのみシステム全体の暴走監視処
理においてウォッチドッグタイマをクリアするシステム
がある。このシステムではいずれか１のアプリの呼び出
しが正常に行われなかった場合には、ウォッチドッグタ
イマはクリアされず、システムがリセットされる。な
お、ウォッチドッグタイマは、図５に記載の一連の処理
を実行する時間に設定されている。

【０００４】この方法では、アプリの呼び出しが正常に
行われた場合には、全体の処理が正常であると判定され
る。すなわち、アプリ内部での処理が正常に行われたか
否かは保証できず、アプリでの処理に異常があっても、
その異常を検出できない。そこで本発明は、アプリの実
行状態を加味してシステム全体の暴走監視を行うことの
できるコンピュータシステムを提供することを目的とす
る。

【０００５】

【課題を解決するための手段及び発明の効果】上述した
問題点を解決するためになされた請求項１に記載のコン
ピュータシステムによれば、いずれか１のアプリケーシ
ョンプログラムの実行時に異常がある場合、そのアプリ
ケーションプログラム用の暴走監視タイマがクリアされ
ないため、ウォッチドッグタイマがクリアされない。し
たがって、その後、監視時間に達した際にウォッチドッ
グタイマはコンピュータシステムが暴走状態であると判
定する。そしてウォッチドッグタイマは、例えばコンピ
ュータシステムのリセットを行う。

【０００６】すなわち、従来のように単に各アプリの呼
び出しが正常に行われたかだけでなく、各アプリの実行
内容やそれぞれのアプリ要件、処理が正常に終了したか
等の処理結果に基づいて、システム全体として正常か異
常かを判定することができる。

【０００７】なお、ウォッチドッグタイマの監視時間
は、例えば全てのアプリケーションプログラム及び実行
監視プログラムの実行時間を越える程度の時間にシステ
ムの初期化時に設定することで、いずれか１のアプリケ
ーションプログラム用の暴走監視タイマが前記所定値に
達した場合に、すぐにシステムにリセットがかかるよう
にすることができる。また、例えばウォッチドッグタイ
マの監視時間を全てのアプリケーションプログラム及び
実行監視プログラムの実行時間のｎ倍の時間にシステム
の初期化時に設定し、アプリケーションプログラムをｎ
回実行した上で、いずれか１のアプリケーションプログ
ラム用の暴走監視タイマが前記所定値に達している場合
には、システムの異常としてシステムにリセットをかけ
るなどのようにすることもできる。すなわち、ウォッチ
ドッグタイマの監視時間をシステム全体としての異常と
みなすべき時間に合わせて設定することで、適切な時間
でかつ適切なアプリケーションプログラムの実行回数
（再試行回数）でシステム全体として異常があると判定
させることができる。

【０００８】また、ウォッチドッグタイマ及びアプリケ
ーションプログラム毎の暴走監視タイマは、ハードウェ
アでもソフトウェアでも構成することができる。特にウ
ォッチドッグタイマはハードウェアで構成するとよい。
例えばコンピュータシステムとしてのマイコンに内蔵さ
れたハードリソースであるウォッチドッグタイマや、電
源ＩＣ等のその他の周辺装置に内蔵されたウォッチドッ
グタイマを用いるとよい。このようにすればソフトウェ
アが暴走してしまった場合等にも、確実にコンピュータ
システムのリセット（再起動）等を行うことができる。

【０００９】そしてこのようなコンピュータシステムの
実行するプログラムの構成はどのような構成でも構わな
い。例えばリアルタイムＯＳを用い、アプリケーション
プログラムをイベントドリブンあるいはタイムスライス
で実行する場合にも適用できる。また例えば、請求項２
に示すようにアプリケーションプログラムを順次実行
し、全てのアプリケーションプログラムの実行後にシス
テム全体の暴走監視処理を行う構成についても適用する
ことができる。

【００１０】さらに、請求項３に示すように、アプリケ
ーションプログラムに割込み処理プログラムを含み、そ
の割込み処理プログラムの処理結果を加味して、処理結
果が正常であるか否かを判定しそのアプリケーションプ
ログラム用の暴走監視タイマについての操作を行うよう
にするとよい。このようにすれば、アプリケーションプ
ログラム内の割込み処理の結果も加味して、システム全
体として動作が正常か否かを判定することができ、異常
の場合にはウォッチドッグタイマによってシステムの復
帰を行うことができる。

【００１１】なお、請求項２及び請求項３の構成は、リ
アルタイムＯＳを用いない比較的単純な構成の組込シス
テム等に特に有効である。そして、請求項４に示すよう
に、請求項１〜３のいずれかに記載の処理をコンピュー
タシステムに実現させる場合、例えば、コンピュータシ
ステム側で起動するプログラムとして備えることができ
る。このようなプログラムの場合、例えば、フロッピー
（登録商標）ディスク、光磁気ディスク、ＣＤ−ＲＯ
Ｍ、ハードディスク、ＲＯＭ、ＲＡＭ等のコンピュータ
読み取り可能な記録媒体に記録し、必要に応じてコンピ
ュータシステムにロードして起動することにより用いる
ことができ、また、ネットワークを介してロードして起
動することにより用いることもできる。

【００１２】

【発明の実施の形態】以下、本発明が適用された実施例
について図面を用いて説明する。なお、本発明の実施の
形態は、下記の実施例に何ら限定されることなく、本発
明の技術的範囲に属する限り種々の形態を採りうること
は言うまでもない。

【００１３】図１は、実施例のコンピュータシステムと
してのマイコン１の構成を示すブロック図である。マイ
コン１は、演算処理部１０、入出力部２０、ウォッチド
ッグタイマ３０を備える。演算処理部１０は、ＣＰＵ１
２、ＲＯＭ１４、ＲＡＭ１６を備え、ＣＰＵ１２はＲＯ
Ｍ１４に記憶されたプログラムを実行し、入出力部２０
を制御する。

【００１４】ウォッチドッグタイマ３０は、ＣＰＵ１２
によって指定されたカウント値になるまで、時間経過に
応じてカウントを行い、ＣＰＵ１２によって指定された
カウント値に達した場合にはリセット信号を演算処理部
１０へ出力して、演算処理部１０をリセットする。ＲＯ
Ｍ１４に記憶されたプログラムには、指定されたカウン
ト値に至る前にウォッチドッグタイマ３０へのクリア信
号をＣＰＵ１２に出力させるプログラムを含み、動作が
正常な間はこのプログラムを実行する。したがって、ウ
ォッチドッグタイマ３０のカウント値は指定されたカウ
ント値に達することなくリセットはされない。しかし処
理に異常が発生しこのプログラムが実行されず、クリア
信号がウォッチドッグタイマ３０へ出力されなかった場
合には、指定されたカウント値に達した時点で演算処理
部１０にリセットがかかり、異常な動作状態から復帰す
ることができる。ウォッチドッグタイマの設定時間（監
視時間に相当する）は、後述するメイン処理の実行開始
からシステム全体の暴走監視処理が終了するまでの時間
より長い時間に設定している。

【００１５】このようなマイコン１におけるＣＰＵ１２
の処理について図２〜図４を参照して説明する。図２
は、ＣＰＵ１２によって５ｍｓ毎に実行され、５ｍｓよ
り短い時間で完了する処理である。５ｍｓ毎に起動され
るメイン処理は、アプリケーションプログラム（以下、
ＡＰＬとも称する）を順次起動する。すなわち、ＡＰＬ
０を実行し、ＡＰＬ０の完了後に、ＡＰＬ１を実行し、
といった具合にＡＰＬ４まで同様に実行する。なお各Ａ
ＰＬは、所定の機能をマイコン１に実現させるためのプ
ログラムとして構成され、ＲＯＭ１４に格納されてお
り、例えば、このマイコン１が自動車のボデー系システ
ムの制御に適用されるのであれば、ＡＰＬ０がドアロッ
ク制御、ＡＰＬ１がライト制御、ＡＰＬ２がワイヤレス
制御、ＡＰＬ３がセキュリティ制御などに割り当てられ
る。

【００１６】そして、各ＡＰＬの中には、割込みが発生
した際に処理を行うプログラム（割込み処理プログラ
ム）を含むものがある。例えば、ＡＰＬ１は、割込み１
〜ｎまでを受け付け、各割込みに応じた処理を行うプロ
グラムを含んでいる。ＡＰＬ１がライト制御の機能を実
現するためのプログラムであれば、この割込み処理に
は、照度センサからの情報を読み取る割込み処理や、ユ
ーザが操作したスイッチの情報を読み取る割込み処理な
どがある。この割込み処理の結果は、ＲＡＭ１６に記憶
され（実行履歴の記憶）、メイン処理から呼び出された
ＡＰＬ１の処理の中で、このＲＡＭ１６に記憶された情
報に基づいてライトの制御内容を確定してライトの点灯
または消灯を行うなどの制御をする。

【００１７】各ＡＰＬは、図３に示すように、メイン処
理からの呼び出しがあると、そのＡＰＬの機能を実現さ
せるための処理（Ｓ１００）を実行した後、そのＡＰＬ
の処理結果に異常があるか否かを判定する（Ｓ１１
０）。Ｓ１００の処理として、例えばドアロック制御の
ＡＰＬ内では、セキュリティ状態のロック／アンロック
を管理する状態とドアロック／アンロックの要求に対し
応答を待つ状態のパラレルで動作する２つの状態に基づ
いて制御を行う処理がある。この場合パラレルで動作す
る２つの状態を記憶しておく。そしてＳ１１０でその記
憶した状態の正常／異常を判定する。このようにＡＰＬ
の機能によって、またＡＰＬの要求仕様に基づいて異常
であるか正常であるか判定する。なお、ＡＰＬが割込み
処理プログラムを含むＡＰＬの場合には、Ｓ１１０にお
いて、割込み処理の結果についても異常があるか否かを
判定する。すなわち、Ｓ１１０の判定は例えばＳ１００
のＡＰＬの通常処理中で記憶した実行履歴、及び、割込
み処理のあるＡＰＬの場合にはその割込み処理中で記憶
した実行履歴に基づいて判定する。なお、この異常は、
決められた時間で応答がない場合（タイムアウト）や、
ハードウェアの異常検出、仕様で定義されている異常状
態の発生などを含む。

【００１８】これら処理結果に異常がない場合には（Ｓ
１１０：ＹＥＳ）、Ｓ１２０へ移行し、異常がある場合
には（Ｓ１１０：ＮＯ）、ＡＰＬ処理を終了して、メイ
ン処理に戻る。Ｓ１２０では、そのＡＰＬの暴走監視タ
イマをクリアする。このタイマは各ＡＰＬ毎に設けられ
たタイマ変数であり、このタイマ変数の値は、後述する
図４のＳ２２０の処理でカウントアップされている。

【００１９】このように各ＡＰＬの処理において、ＡＰ
Ｌ処理の処理結果が正常のときのみ各ＡＰＬ毎の暴走監
視タイマをクリアする。したがって、処理結果に異常が
ある場合には、そのＡＰＬの暴走監視タイマはクリアさ
れずそのＡＰＬ処理が終了する。

【００２０】そしてすべてのＡＰＬ（図２ではＡＰＬ０
〜ＡＰＬ４）の処理が終了すると、メイン処理はシステ
ム全体の暴走監視プログラムによるシステム全体の暴走
監視処理を呼び出す。このシステム全体の暴走監視処理
のフローを図４に示して説明する。

【００２１】Ｓ２１０〜Ｓ２５０は、全ＡＰＬについ
て、各アプリ毎の暴走監視タイマのカウントアップと、
各ＡＰＬ毎の暴走監視タイマが設定値以上か否かを判定
する暴走監視結果確認処理であり、Ｓ２１０では、全Ａ
ＰＬについて暴走監視結果確認処理を実施したか否かを
判定する。全アプリについて暴走監視結果確認処理を行
った場合（Ｓ２１０：ＹＥＳ）にはＳ２６０へ移行す
る。一方、まだ確認していないＡＰＬがある場合には
（Ｓ２１０：ＮＯ）そのＡＰＬを確認対象のＡＰＬとし
てＳ２２０へ移行する。

【００２２】Ｓ２２０では、確認対象のＡＰＬの暴走監
視タイマをカウントアップする（例えば＋１）。続くＳ
２３０では、そのＡＰＬの暴走監視タイマが予め記憶さ
れた設定値以上であるか否かを判定する。設定値より小
さい場合には（Ｓ２３０：ＮＯ）、Ｓ２４０へ移行し
て、確認対象のＡＰＬが正常であることを記憶して（Ｓ
２４０）、Ｓ２１０へ移行する。一方、設定値以上の場
合には（Ｓ２４０：ＹＥＳ）、確認対象のＡＰＬが異常
であることを図示しない不揮発メモリに記憶して（Ｓ２
５０）、Ｓ２１０へ移行する。なお、設定値は各ＡＰＬ
毎に処理異常と見なすべき時間に設定している。

【００２３】そしてＳ２６０では、Ｓ２５０で異常と記
憶されたＡＰＬがあるか否かを判定し、異常と記憶され
たＡＰＬがない場合には（Ｓ２６０：ＮＯ）、ウォッチ
ドッグタイマ３０へクリア信号を出力して、ウォッチド
ッグタイマ３０のカウンタをクリアする（Ｓ２７０）。
一方、異常と記憶されたＡＰＬがある場合には（Ｓ２６
０：ＹＥＳ）、この処理を終了し、メイン処理に戻る。

【００２４】このようにして、実行結果に異常のあるＡ
ＰＬが存在する場合にはウォッチドッグタイマ３０のカ
ウンタのクリアを行わない。したがって、ウォッチドッ
グタイマは設定時間に達し、演算処理部１０がリセット
される。よって、各ＡＰＬの処理に異常がある場合に、
即再起動することができる。また異常の内容は不揮発メ
モリに記憶されるのでこれを解析することで異常の発生
したＡＰＬを知ることができる。

【００２５】なお、上記実施例においてウォッチドッグ
タイマの設定時間は、メイン処理の実行開始からシステ
ム全体の暴走監視処理が終了するまでの時間より長い時
間に設定することとしたが、例えば図２の一連の処理が
１回実行される時間に設定してもよいし、数回実行され
る時間に設定してもよい。この設定時間は、例えば仕様
に従ってシステムが異常とみなすべき時間に設定すれば
よい。

【図面の簡単な説明】

【図１】実施例のコンピュータシステムの構成を示すブ
ロック図である。

【図２】実施例のコンピュータシステムで実行する処理
を説明する図である。

【図３】アプリケーション毎の暴走監視処理のフローチ
ャートである。

【図４】システム全体の暴走監視監視処理のフローチャ
ートである。

【図５】従来のコンピュータシステムにおける暴走監視
処理を説明する図である。

【符号の説明】

１…マイコン １０…演算処理部 １２…ＣＰＵ １４…ＲＯＭ １６…ＲＡＭ ２０…入出力部 ３０…ウォッチドッグタイマ

Claims (4)

【特許請求の範囲】
1. 【請求項１】ウォッチドッグタイマを備え、 複数のアプリケーションプログラムと、 前記ウォッチドッグタイマの監視時間より短い間隔で実
   行され、処理に異常がない場合に前記ウォッチドックタ
   イマのクリアを行うためのシステム全体の暴走監視プロ
   グラムとを実行するコンピュータシステムにおいて、 前記アプリケーションプログラム毎の暴走監視タイマを
   備え、 前記アプリケーションプログラムにおける処理におい
   て、当該アプリケーションプログラムによる処理結果が
   正常であるか否かを判定し、正常の場合には当該アプリ
   ケーションプログラム用の暴走監視タイマのクリアを行
   い、異常がある場合には当該アプリケーションプログラ
   ム用の暴走監視タイマをクリアを行わず、 前記システム全体の暴走監視プログラムによる処理にお
   いて、全てのアプリケーションプログラム用の暴走監視
   タイマが所定値に達しない場合には、前記ウォッチドッ
   グタイマのクリアを行い、いずれか１の前記アプリケー
   ションプログラム用の暴走監視タイマが前記所定値に達
   した場合には、前記ウォッチドッグタイマのクリアを行
   わないことを特徴とするコンピュータシステム。
2. 【請求項２】請求項１に記載のコンピュータシステムに
   おいて、 全てのアプリケーションプログラムは順次実行し、 前記システム全体の暴走監視プログラムの実行は、前記
   全てのアプリケーションプログラムの実行後に行うこと
   を特徴とするコンピュータシステム。
3. 【請求項３】請求項１または２に記載のコンピュータシ
   ステムにおいて、 前記複数のアプリケーションプログラムのうち少なくと
   もいずれか１のアプリケーションプログラムには、割込
   み処理プログラムが含まれており、 前記アプリケーションプログラムによる処理結果が正常
   であるか否かの判定は、前記割込み処理の処理結果を加
   味して行うことを特徴とするコンピュータシステム。
4. 【請求項４】請求項１〜３のいずれかに記載のコンピュ
   ータシステムに、当該請求項に記載の処理を実行させる
   ためのプログラム。