JP2000122900A - マイクロコントローラの暴走監視方法 - Google Patents
マイクロコントローラの暴走監視方法Info
- Publication number
- JP2000122900A JP2000122900A JP10297916A JP29791698A JP2000122900A JP 2000122900 A JP2000122900 A JP 2000122900A JP 10297916 A JP10297916 A JP 10297916A JP 29791698 A JP29791698 A JP 29791698A JP 2000122900 A JP2000122900 A JP 2000122900A
- Authority
- JP
- Japan
- Prior art keywords
- task
- monitoring
- level
- microcontroller
- runaway
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Landscapes
- Debugging And Monitoring (AREA)
Abstract
(57)【要約】
【課題】 プログラム構成上の最上位レベルから最下位
レベルまでのいずれのレベルのタスクに起因する暴走で
あっても、確実にそれを検知できるマイクロコントロー
ラの暴走監視方法を提供する。 【解決手段】 複数のタスク１〜４を時分割で実行する
マルチプログラミングを採用したマイクロコントローラ
における暴走監視方法であって、プログラム構成上の最
下位レベルに、プログラム構成上の最上位レベルのＯＳ
１によって管理されず、かつそのＯＳ１が正常に動作し
ているか否かを監視する監視タスク４を配置し、ＯＳ１
によって監視タスク４が正常に動作しているか否かを監
視する。
レベルまでのいずれのレベルのタスクに起因する暴走で
あっても、確実にそれを検知できるマイクロコントロー
ラの暴走監視方法を提供する。 【解決手段】 複数のタスク１〜４を時分割で実行する
マルチプログラミングを採用したマイクロコントローラ
における暴走監視方法であって、プログラム構成上の最
下位レベルに、プログラム構成上の最上位レベルのＯＳ
１によって管理されず、かつそのＯＳ１が正常に動作し
ているか否かを監視する監視タスク４を配置し、ＯＳ１
によって監視タスク４が正常に動作しているか否かを監
視する。
Description
【０００１】
【発明の属する技術分野】本発明は、複数のタスクを時
分割で実行するマルチプログラミングを採用したマイク
ロコントローラにおける暴走監視方法に関する。
分割で実行するマルチプログラミングを採用したマイク
ロコントローラにおける暴走監視方法に関する。
【０００２】
【従来の技術】従来、マイクロコントローラにおいて
は、ウオッチドッグタイマを備え、ＯＳ（operating sy
stem）によってウオッチドッグタイマを定期的にクリア
させていた。そして、暴走によりＯＳがウオッチドッグ
タイマをクリアできない状態に陥ると、ウオッチドッグ
タイマがタイムアップし、ハードウェアによってマイク
ロコントローラがリセットされるようになされていた。
したがって、ＯＳによって直接管理されているタスクに
起因する暴走は、ウオッチドッグタイマがクリアされな
いことによって検知できるものの、ＯＳによって直接管
理されていないタスクに起因する暴走は、ウオッチドッ
グタイマがクリアされてしまうことから、検知できなか
った。
は、ウオッチドッグタイマを備え、ＯＳ（operating sy
stem）によってウオッチドッグタイマを定期的にクリア
させていた。そして、暴走によりＯＳがウオッチドッグ
タイマをクリアできない状態に陥ると、ウオッチドッグ
タイマがタイムアップし、ハードウェアによってマイク
ロコントローラがリセットされるようになされていた。
したがって、ＯＳによって直接管理されているタスクに
起因する暴走は、ウオッチドッグタイマがクリアされな
いことによって検知できるものの、ＯＳによって直接管
理されていないタスクに起因する暴走は、ウオッチドッ
グタイマがクリアされてしまうことから、検知できなか
った。
【０００３】一般的に、マルチプログラミングを採用し
たマイクロコントローラにおけるＯＳ以外のタスクは、
図４に示すように、ＯＳ５１によって直接管理されてい
る子タスク５２と、ＯＳ５１によって直接管理されてい
ないフラグ待ち子タスク５３とに分かれており、高速に
かつ定期的に実行すべきタスクを子タスク５２とし、そ
れ以外の比較的低速にあるいは非定期的に実行してもよ
いタスクをフラグ待ち子タスク５３として、フラグ待ち
子タスク５３はＣＰＵ（central processing unit ）の
空き時間に実行している。ところが、ＣＲＴ（cathode-
ray tube）を備えたディスプレイ装置を制御するマイク
ロコントローラでは、ＣＲＴの高電圧に起因してノイズ
が発生しやすく、このようなノイズによりいずれかのフ
ラグ待ち子タスク５３の実行が停止しても、ＯＳ５１は
フラグ待ち子タスク５３を直接管理していないので、正
常動作を継続し、ウオッチドッグタイマがクリアされて
しまうことから、リセットがかからず、当該フラグ待ち
子タスク５３の実行が停止したままになってしまう。し
たがって、他のフラグ待ち子タスク５３の実行が行えな
い状態が継続することになる。
たマイクロコントローラにおけるＯＳ以外のタスクは、
図４に示すように、ＯＳ５１によって直接管理されてい
る子タスク５２と、ＯＳ５１によって直接管理されてい
ないフラグ待ち子タスク５３とに分かれており、高速に
かつ定期的に実行すべきタスクを子タスク５２とし、そ
れ以外の比較的低速にあるいは非定期的に実行してもよ
いタスクをフラグ待ち子タスク５３として、フラグ待ち
子タスク５３はＣＰＵ（central processing unit ）の
空き時間に実行している。ところが、ＣＲＴ（cathode-
ray tube）を備えたディスプレイ装置を制御するマイク
ロコントローラでは、ＣＲＴの高電圧に起因してノイズ
が発生しやすく、このようなノイズによりいずれかのフ
ラグ待ち子タスク５３の実行が停止しても、ＯＳ５１は
フラグ待ち子タスク５３を直接管理していないので、正
常動作を継続し、ウオッチドッグタイマがクリアされて
しまうことから、リセットがかからず、当該フラグ待ち
子タスク５３の実行が停止したままになってしまう。し
たがって、他のフラグ待ち子タスク５３の実行が行えな
い状態が継続することになる。
【０００４】
【発明の開示】本発明は、上記した事情のもとで考え出
されたものであって、プログラム構成上の最上位レベル
から最下位レベルまでのいずれのレベルのタスクに起因
する暴走であっても、確実にそれを検知できるマイクロ
コントローラの暴走監視方法を提供することを、その課
題とする。
されたものであって、プログラム構成上の最上位レベル
から最下位レベルまでのいずれのレベルのタスクに起因
する暴走であっても、確実にそれを検知できるマイクロ
コントローラの暴走監視方法を提供することを、その課
題とする。
【０００５】上記の課題を解決するため、本発明では、
次の技術的手段を講じている。
次の技術的手段を講じている。
【０００６】本発明の第１の側面によれば、複数のタス
クを時分割で実行するマルチプログラミングを採用した
マイクロコントローラにおける暴走監視方法であって、
プログラム構成上の最下位レベルに、プログラム構成上
の最上位レベルのタスクによって管理されず、かつその
最上位レベルのタスクが正常に動作しているか否かを監
視する監視タスクを配置し、最上位レベルのタスクによ
って監視タスクが正常に動作しているか否かを監視する
ことを特徴とする、マイクロコントローラの暴走監視方
法が提供される。
クを時分割で実行するマルチプログラミングを採用した
マイクロコントローラにおける暴走監視方法であって、
プログラム構成上の最下位レベルに、プログラム構成上
の最上位レベルのタスクによって管理されず、かつその
最上位レベルのタスクが正常に動作しているか否かを監
視する監視タスクを配置し、最上位レベルのタスクによ
って監視タスクが正常に動作しているか否かを監視する
ことを特徴とする、マイクロコントローラの暴走監視方
法が提供される。
【０００７】好ましい実施の形態によれば、最上位レベ
ルのタスクは、監視タスクの起動毎にインクリメントさ
れる監視タスク起動回数カウンタのカウント値に基づい
て監視タスクが正常に動作しているか否かを監視し、監
視タスクは、最上位レベルのタスクの起動毎にインクリ
メントされる最上位タスク起動回数カウンタのカウント
値に基づいて最上位レベルのタスクが正常に動作してい
るか否かを監視する。
ルのタスクは、監視タスクの起動毎にインクリメントさ
れる監視タスク起動回数カウンタのカウント値に基づい
て監視タスクが正常に動作しているか否かを監視し、監
視タスクは、最上位レベルのタスクの起動毎にインクリ
メントされる最上位タスク起動回数カウンタのカウント
値に基づいて最上位レベルのタスクが正常に動作してい
るか否かを監視する。
【０００８】他の好ましい実施の形態によれば、最上位
レベルのタスクは、監視タスクが正常に動作していない
ことを検知したときに、ウオッチドッグタイマをクリア
しないことによりマイクロコントローラをリセットさ
せ、監視タスクは、最上位レベルのタスクが正常に動作
していないことを検知したときに、ウオッチドッグタイ
マをクリアしないことによりマイクロコントローラをリ
セットさせる。
レベルのタスクは、監視タスクが正常に動作していない
ことを検知したときに、ウオッチドッグタイマをクリア
しないことによりマイクロコントローラをリセットさ
せ、監視タスクは、最上位レベルのタスクが正常に動作
していないことを検知したときに、ウオッチドッグタイ
マをクリアしないことによりマイクロコントローラをリ
セットさせる。
【０００９】他の好ましい実施の形態によれば、最上位
レベルのタスクは、監視タスクが正常に動作していない
ことを検知したときに、リセット命令を発行することに
よりマイクロコントローラをリセットさせ、監視タスク
は、最上位レベルのタスクが正常に動作していないこと
を検知したときに、リセット命令を発行することにより
マイクロコントローラをリセットさせる。
レベルのタスクは、監視タスクが正常に動作していない
ことを検知したときに、リセット命令を発行することに
よりマイクロコントローラをリセットさせ、監視タスク
は、最上位レベルのタスクが正常に動作していないこと
を検知したときに、リセット命令を発行することにより
マイクロコントローラをリセットさせる。
【００１０】本発明によれば、最上位レベルのタスクと
最下位レベルのタスクすなわち監視タスクとで、互いの
動作を相互監視するので、プログラム構成上の最上位レ
ベルから最下位レベルまでのいずれのレベルのタスクに
起因する暴走であっても、確実にそれを検知できる。
最下位レベルのタスクすなわち監視タスクとで、互いの
動作を相互監視するので、プログラム構成上の最上位レ
ベルから最下位レベルまでのいずれのレベルのタスクに
起因する暴走であっても、確実にそれを検知できる。
【００１１】すなわち、最上位レベルのタスクに直接管
理されているタスクに起因する暴走が発生した場合、最
上位レベルのタスクの実行が停止するので、監視タスク
が最上位レベルのタスクを監視することにより、暴走の
発生を確実に検知できる。また、最上位レベルのタスク
に直接管理されていないタスクに起因する暴走が発生し
た場合、最下位レベルのタスクである監視タスクの実行
が停止するので、最上位レベルのタスクが監視タスクを
監視することにより、暴走の発生を確実に検知できる。
理されているタスクに起因する暴走が発生した場合、最
上位レベルのタスクの実行が停止するので、監視タスク
が最上位レベルのタスクを監視することにより、暴走の
発生を確実に検知できる。また、最上位レベルのタスク
に直接管理されていないタスクに起因する暴走が発生し
た場合、最下位レベルのタスクである監視タスクの実行
が停止するので、最上位レベルのタスクが監視タスクを
監視することにより、暴走の発生を確実に検知できる。
【００１２】また、最上位レベルのタスクと監視タスク
とが、互いに相手の起動回数をカウントするカウンタの
カウント値に基づいて相手が正常に動作しているか否か
を監視するようにすれば、相手の動作の監視を容易に行
える。
とが、互いに相手の起動回数をカウントするカウンタの
カウント値に基づいて相手が正常に動作しているか否か
を監視するようにすれば、相手の動作の監視を容易に行
える。
【００１３】また、最上位レベルのタスクと監視タスク
とが、ウオッチドッグタイマをクリアしないことにより
マイクロコントローラをリセットさせるようにすれば、
最上位レベルのタスクと監視タスクとの双方の実行が同
時に停止した場合にも、ウオッチドッグタイマがタイム
アップしてマイクロコントローラをリセットできる。
とが、ウオッチドッグタイマをクリアしないことにより
マイクロコントローラをリセットさせるようにすれば、
最上位レベルのタスクと監視タスクとの双方の実行が同
時に停止した場合にも、ウオッチドッグタイマがタイム
アップしてマイクロコントローラをリセットできる。
【００１４】また、最上位レベルのタスクと監視タスク
とが、リセット命令を発行することによりマイクロコン
トローラをリセットさせるようにすれば、ウオッチドッ
グタイマを設けることなくマイクロコントローラをリセ
ットできる。
とが、リセット命令を発行することによりマイクロコン
トローラをリセットさせるようにすれば、ウオッチドッ
グタイマを設けることなくマイクロコントローラをリセ
ットできる。
【００１５】本発明のその他の特徴および利点は、添付
図面を参照して以下に行う詳細な説明によって、より明
らかとなろう。
図面を参照して以下に行う詳細な説明によって、より明
らかとなろう。
【００１６】以下、本発明の好ましい実施の形態を、図
面を参照して具体的に説明する。
面を参照して具体的に説明する。
【００１７】図１は、本発明に係るマイクロコントロー
ラの暴走監視方法を採用したプログラム構造の説明図で
あって、マイクロコントローラを動作させるためのプロ
グラムは、プログラム構成上の最上位レベルに位置する
ＯＳ１と、プログラム構成上の中間レベルに位置する子
タスク２と、プログラム構成上の最下位レベルに位置す
るフラグ待ち子タスク３および監視タスク４とにより構
成されている。本実施形態においては、ＣＲＴを備えた
ディスプレイ装置を制御するマイクロコントローラに本
発明を適用した例について説明する。
ラの暴走監視方法を採用したプログラム構造の説明図で
あって、マイクロコントローラを動作させるためのプロ
グラムは、プログラム構成上の最上位レベルに位置する
ＯＳ１と、プログラム構成上の中間レベルに位置する子
タスク２と、プログラム構成上の最下位レベルに位置す
るフラグ待ち子タスク３および監視タスク４とにより構
成されている。本実施形態においては、ＣＲＴを備えた
ディスプレイ装置を制御するマイクロコントローラに本
発明を適用した例について説明する。
【００１８】すなわち、ＯＳ１は優先順位が最も高く、
フラグ待ち子タスク３および監視タスク４は優先順位が
最も低い。子タスク２はそれらの中間の優先順位であ
る。また、子タスク２およびフラグ待ち子タスク３の配
置数はそれぞれ任意であり、子タスク２同士あるいはフ
ラグ待ち子タスク３同士で優先順位を設けてもよいし、
設けなくてもよい。フラグ待ち子タスク３同士で優先順
位を設ける場合、監視タスク４の順位は、最下位のフラ
グ待ち子タスク３以下の順位に設定する。
フラグ待ち子タスク３および監視タスク４は優先順位が
最も低い。子タスク２はそれらの中間の優先順位であ
る。また、子タスク２およびフラグ待ち子タスク３の配
置数はそれぞれ任意であり、子タスク２同士あるいはフ
ラグ待ち子タスク３同士で優先順位を設けてもよいし、
設けなくてもよい。フラグ待ち子タスク３同士で優先順
位を設ける場合、監視タスク４の順位は、最下位のフラ
グ待ち子タスク３以下の順位に設定する。
【００１９】ＯＳ１は、優先順位が最上位のタイマ割込
により、たとえば２ｍｓｅｃ毎に起動され、子タスク２
を直接管理し、また監視タスク４を監視する。
により、たとえば２ｍｓｅｃ毎に起動され、子タスク２
を直接管理し、また監視タスク４を監視する。
【００２０】子タスク２は、ＯＳ１により直接管理さ
れ、たとえば操作キーの押下を検出するなどのように、
高速にかつ定期的に実行すべき処理を担当する。
れ、たとえば操作キーの押下を検出するなどのように、
高速にかつ定期的に実行すべき処理を担当する。
【００２１】フラグ待ち子タスク３は、たとえばＥＥＰ
ＲＯＭ（electrically erasable and programmable rea
d only memory ）へのアクセス、あるいはＣＲＴの画面
調整のための文字や図形の表示などのように、比較的低
速にあるいは非定期的に実行してもよい処理を担当す
る。このフラグ待ち子タスク３は、ＯＳ１により直接管
理されておらず、すべての子タスク２の実行が終了した
時点で、いずれかの子タスク２によりフラグがオンされ
ていれば、実行される。実行の終了により、フラグ待ち
子タスク３はフラグをオフする。
ＲＯＭ（electrically erasable and programmable rea
d only memory ）へのアクセス、あるいはＣＲＴの画面
調整のための文字や図形の表示などのように、比較的低
速にあるいは非定期的に実行してもよい処理を担当す
る。このフラグ待ち子タスク３は、ＯＳ１により直接管
理されておらず、すべての子タスク２の実行が終了した
時点で、いずれかの子タスク２によりフラグがオンされ
ていれば、実行される。実行の終了により、フラグ待ち
子タスク３はフラグをオフする。
【００２２】監視タスク４は、ＯＳ１により直接管理さ
れておらず、フラグがオンされたフラグ待ち子タスク３
の実行が終了した時点で実行され、タイマ割込によりＯ
Ｓ１が起動されるまで、ＯＳ１の監視動作を継続する。
れておらず、フラグがオンされたフラグ待ち子タスク３
の実行が終了した時点で実行され、タイマ割込によりＯ
Ｓ１が起動されるまで、ＯＳ１の監視動作を継続する。
【００２３】なお、暴走状態でないときには、子タスク
２の実行は必ず２ｍｓｅｃ以内に終了し、フラグ待ち子
タスク３あるいは監視タスク４が実行されるようになさ
れている。
２の実行は必ず２ｍｓｅｃ以内に終了し、フラグ待ち子
タスク３あるいは監視タスク４が実行されるようになさ
れている。
【００２４】次に動作を説明する。電源投入時あるいは
リセット直後には、最下位レベルの監視タスク４が実行
されている。そして、タイマ割込によりＯＳ１が起動
し、子タスク２を順次実行させる。子タスク２の実行に
より１以上のフラグがオンされた場合、全ての子タスク
２の実行が終了した時点で、オンされているフラグに対
応するフラグ待ち子タスク３が順次実行される。もちろ
ん、１つの子タスク２が複数のフラグをオンさせてもよ
い。フラグ待ち子タスク３の実行中にタイマ割込によっ
てＯＳ１が起動した場合、上記の子タスク２の実行以下
の動作が繰り返されることになる。
リセット直後には、最下位レベルの監視タスク４が実行
されている。そして、タイマ割込によりＯＳ１が起動
し、子タスク２を順次実行させる。子タスク２の実行に
より１以上のフラグがオンされた場合、全ての子タスク
２の実行が終了した時点で、オンされているフラグに対
応するフラグ待ち子タスク３が順次実行される。もちろ
ん、１つの子タスク２が複数のフラグをオンさせてもよ
い。フラグ待ち子タスク３の実行中にタイマ割込によっ
てＯＳ１が起動した場合、上記の子タスク２の実行以下
の動作が繰り返されることになる。
【００２５】フラグ待ち子タスク３の実行中にタイマ割
込によってＯＳ１が起動されない場合、フラグ待ち子タ
スク３の実行が終了すると、監視タスク４が実行され
る。また、子タスク２の実行によっていずれのフラグ待
ち子タスク３のフラグもオンされなかった場合、全ての
子タスク２の実行が終了した時点で、監視タスク４が実
行される。監視タスク４の実行は、タイマ割込によって
ＯＳ１が起動されるまで継続される。
込によってＯＳ１が起動されない場合、フラグ待ち子タ
スク３の実行が終了すると、監視タスク４が実行され
る。また、子タスク２の実行によっていずれのフラグ待
ち子タスク３のフラグもオンされなかった場合、全ての
子タスク２の実行が終了した時点で、監視タスク４が実
行される。監視タスク４の実行は、タイマ割込によって
ＯＳ１が起動されるまで継続される。
【００２６】いま、子タスク２の実行中に外来ノイズが
侵入し、暴走が発生したとすると、子タスク２の実行が
終了しないことから、ＯＳ１が停止状態になる。この場
合、ＯＳ１がウオッチドッグタイマをクリアしない状態
が継続するので、ウオッチドッグタイマがタイムアップ
し、ハード的にマイクロコントローラがリセットされ
る。このとき、監視タスク４が実行されることはないの
で、監視タスク４がウオッチドッグタイマをクリアする
ことはない。
侵入し、暴走が発生したとすると、子タスク２の実行が
終了しないことから、ＯＳ１が停止状態になる。この場
合、ＯＳ１がウオッチドッグタイマをクリアしない状態
が継続するので、ウオッチドッグタイマがタイムアップ
し、ハード的にマイクロコントローラがリセットされ
る。このとき、監視タスク４が実行されることはないの
で、監視タスク４がウオッチドッグタイマをクリアする
ことはない。
【００２７】また、フラグ待ち子タスク３の実行中に外
来ノイズが侵入し、暴走が発生したとすると、フラグ待
ち子タスク３の実行が終了しないことから、監視タスク
４が停止状態になる。この場合、ＯＳ１が監視タスク４
の動作が異常であることを検知し、ウオッチドッグタイ
マをクリアしない状態になる。これにより、ウオッチド
ッグタイマがタイムアップし、ハード的にマイクロコン
トローラがリセットされる。このとき、監視タスク４は
停止しているので、監視タスク４がウオッチドッグタイ
マをクリアすることはない。
来ノイズが侵入し、暴走が発生したとすると、フラグ待
ち子タスク３の実行が終了しないことから、監視タスク
４が停止状態になる。この場合、ＯＳ１が監視タスク４
の動作が異常であることを検知し、ウオッチドッグタイ
マをクリアしない状態になる。これにより、ウオッチド
ッグタイマがタイムアップし、ハード的にマイクロコン
トローラがリセットされる。このとき、監視タスク４は
停止しているので、監視タスク４がウオッチドッグタイ
マをクリアすることはない。
【００２８】また、ＯＳ１自体が暴走して事実上機能を
停止し、監視タスク４のみが実行される事態に陥ると、
監視タスク４がＯＳ１の動作が異常であることを検知
し、ウオッチドッグタイマをクリアしない状態になる。
これにより、ウオッチドッグタイマがタイムアップし、
ハード的にマイクロコントローラがリセットされる。こ
のとき、ＯＳ１は事実上停止しているので、ＯＳ１がウ
オッチドッグタイマをクリアすることはない。
停止し、監視タスク４のみが実行される事態に陥ると、
監視タスク４がＯＳ１の動作が異常であることを検知
し、ウオッチドッグタイマをクリアしない状態になる。
これにより、ウオッチドッグタイマがタイムアップし、
ハード的にマイクロコントローラがリセットされる。こ
のとき、ＯＳ１は事実上停止しているので、ＯＳ１がウ
オッチドッグタイマをクリアすることはない。
【００２９】また、ＯＳ１と監視タスク４との双方が暴
走により事実上機能を停止した場合、ＯＳ１と監視タス
ク４との双方がウオッチドッグタイマをクリアしない状
態が継続するので、ウオッチドッグタイマがタイムアッ
プし、ハード的にマイクロコントローラがリセットされ
る。
走により事実上機能を停止した場合、ＯＳ１と監視タス
ク４との双方がウオッチドッグタイマをクリアしない状
態が継続するので、ウオッチドッグタイマがタイムアッ
プし、ハード的にマイクロコントローラがリセットされ
る。
【００３０】したがって、最上位レベルのＯＳ１から最
下位レベルの監視タスク４までのいずれのレベルのタス
クに起因する暴走が発生しても、確実にそれを検知し、
マイクロコントローラをリセットして暴走を停止させる
ことができる。
下位レベルの監視タスク４までのいずれのレベルのタス
クに起因する暴走が発生しても、確実にそれを検知し、
マイクロコントローラをリセットして暴走を停止させる
ことができる。
【００３１】上記ＯＳ１の動作について、図２に示すフ
ローチャートを参照しながらさらに詳細に説明する。２
ｍｓｅｃ毎のタイマ割込によりＯＳ１が起動されると、
先ずＯＳ起動回数カウンタの内容が１だけインクリメン
トされる（Ｓ１）。このＯＳ起動回数カウンタは、ＯＳ
１の起動回数をカウントするカウンタであって、具体的
にはＲＡＭの所定番地の内容をＣＰＵが１ずつ加算して
いくことによって実現される。
ローチャートを参照しながらさらに詳細に説明する。２
ｍｓｅｃ毎のタイマ割込によりＯＳ１が起動されると、
先ずＯＳ起動回数カウンタの内容が１だけインクリメン
トされる（Ｓ１）。このＯＳ起動回数カウンタは、ＯＳ
１の起動回数をカウントするカウンタであって、具体的
にはＲＡＭの所定番地の内容をＣＰＵが１ずつ加算して
いくことによって実現される。
【００３２】次に、監視タスク起動回数カウンタに変化
があったか否かが判断される（Ｓ２）。この監視タスク
起動回数カウンタは、監視タスク４の起動回数をカウン
トするカウンタであって、具体的にはＲＡＭの所定番地
の内容をＣＰＵが１ずつ加算していくことによって実現
される。この監視タスク起動回数カウンタは、監視タス
ク４自体によってインクリメントされる。このステップ
Ｓ２における判断は、詳細な手順を示していないが、一
度だけの判断で監視タスク起動回数カウンタに変化があ
ったか否かを判定するのではなく、フローがステップＳ
２に至る毎に監視タスク起動回数カウンタに変化があっ
たか否かを判断して、監視タスク起動回数カウンタに変
化がない状態が所定回数繰り返されたときに、初めて監
視タスク起動回数カウンタに変化がないと判定し、それ
以外の場合には監視タスク起動回数カウンタに変化があ
ると判定するのである。
があったか否かが判断される（Ｓ２）。この監視タスク
起動回数カウンタは、監視タスク４の起動回数をカウン
トするカウンタであって、具体的にはＲＡＭの所定番地
の内容をＣＰＵが１ずつ加算していくことによって実現
される。この監視タスク起動回数カウンタは、監視タス
ク４自体によってインクリメントされる。このステップ
Ｓ２における判断は、詳細な手順を示していないが、一
度だけの判断で監視タスク起動回数カウンタに変化があ
ったか否かを判定するのではなく、フローがステップＳ
２に至る毎に監視タスク起動回数カウンタに変化があっ
たか否かを判断して、監視タスク起動回数カウンタに変
化がない状態が所定回数繰り返されたときに、初めて監
視タスク起動回数カウンタに変化がないと判定し、それ
以外の場合には監視タスク起動回数カウンタに変化があ
ると判定するのである。
【００３３】ステップＳ２において監視タスク起動回数
カウンタに変化があると判定された場合（Ｓ２：ＹＥ
Ｓ）、ウオッチドッグタイマがクリアされる（Ｓ３）。
すなわち、監視タスク４が正常に動作していると判断で
きるので、ウオッチドッグタイマをクリアしてマイクロ
コントローラがリセットされないようにするのである。
カウンタに変化があると判定された場合（Ｓ２：ＹＥ
Ｓ）、ウオッチドッグタイマがクリアされる（Ｓ３）。
すなわち、監視タスク４が正常に動作していると判断で
きるので、ウオッチドッグタイマをクリアしてマイクロ
コントローラがリセットされないようにするのである。
【００３４】次に、子タスク２が順次実行され（Ｓ
４）、すべての子タスク２が実行されると、ＯＳレベル
の処理が終了する。
４）、すべての子タスク２が実行されると、ＯＳレベル
の処理が終了する。
【００３５】ステップＳ２において監視タスク起動回数
カウンタに変化がないと判定された場合（Ｓ２：Ｎ
Ｏ）、データの退避などのシステム停止準備動作が実行
され（Ｓ５）、ＯＳレベルの処理が終了する。すなわ
ち、監視タスク４が正常に動作していないと判断できる
ので、ウオッチドッグタイマをクリアしないことにより
マイクロコントローラをリセットさせるのである。
カウンタに変化がないと判定された場合（Ｓ２：Ｎ
Ｏ）、データの退避などのシステム停止準備動作が実行
され（Ｓ５）、ＯＳレベルの処理が終了する。すなわ
ち、監視タスク４が正常に動作していないと判断できる
ので、ウオッチドッグタイマをクリアしないことにより
マイクロコントローラをリセットさせるのである。
【００３６】上記監視タスク４の動作について、図３に
示すフローチャートを参照しながらさらに詳細に説明す
る。マイクロコントローラの電源投入時あるいはリセッ
ト時に、先ず各種機能が初期化される（Ｓ１１）。
示すフローチャートを参照しながらさらに詳細に説明す
る。マイクロコントローラの電源投入時あるいはリセッ
ト時に、先ず各種機能が初期化される（Ｓ１１）。
【００３７】次に、ＯＳ１の動作を許可する（Ｓ１
２）。すなわち、タイマ割込があったときにＯＳ１に制
御を移せる状態にする。
２）。すなわち、タイマ割込があったときにＯＳ１に制
御を移せる状態にする。
【００３８】次に、監視タスク起動回数カウンタの内容
が１だけインクリメントされる（Ｓ１３）。
が１だけインクリメントされる（Ｓ１３）。
【００３９】次に、ＯＳ起動回数カウンタに変化があっ
たか否かが判断される（Ｓ１４）。このステップＳ１４
における判断は、詳細な手順を示していないが、一度だ
けの判断でＯＳ起動回数カウンタに変化があったか否か
を判定するのではなく、フローがステップＳ１４に至る
毎にＯＳ起動回数カウンタに変化があったか否かを判断
して、ＯＳ起動回数カウンタに変化がない状態が所定回
数繰り返されたときに、初めてＯＳ起動回数カウンタに
変化がないと判定し、それ以外の場合にはＯＳ起動回数
カウンタに変化があると判定するのである。
たか否かが判断される（Ｓ１４）。このステップＳ１４
における判断は、詳細な手順を示していないが、一度だ
けの判断でＯＳ起動回数カウンタに変化があったか否か
を判定するのではなく、フローがステップＳ１４に至る
毎にＯＳ起動回数カウンタに変化があったか否かを判断
して、ＯＳ起動回数カウンタに変化がない状態が所定回
数繰り返されたときに、初めてＯＳ起動回数カウンタに
変化がないと判定し、それ以外の場合にはＯＳ起動回数
カウンタに変化があると判定するのである。
【００４０】ステップＳ１４においてＯＳ起動回数カウ
ンタに変化があると判定された場合（Ｓ１４：ＹＥ
Ｓ）、ウオッチドッグタイマがクリアされる（Ｓ１
５）。すなわち、ＯＳ１が正常に動作していると判断で
きるので、ウオッチドッグタイマをクリアしてマイクロ
コントローラがリセットされないようにするのである。
ンタに変化があると判定された場合（Ｓ１４：ＹＥ
Ｓ）、ウオッチドッグタイマがクリアされる（Ｓ１
５）。すなわち、ＯＳ１が正常に動作していると判断で
きるので、ウオッチドッグタイマをクリアしてマイクロ
コントローラがリセットされないようにするのである。
【００４１】次に、フラグ待ち子タスク３が順次実行さ
れ（Ｓ１６）、フラグがオンになっているすべてのフラ
グ待ち子タスク３が実行されると、ステップＳ１３に戻
る。フラグがオンになっているフラグ待ち子タスク３が
存在しない場合、もちろんフラグ待ち子タスク３が実行
されることなくステップＳ１３に戻る。
れ（Ｓ１６）、フラグがオンになっているすべてのフラ
グ待ち子タスク３が実行されると、ステップＳ１３に戻
る。フラグがオンになっているフラグ待ち子タスク３が
存在しない場合、もちろんフラグ待ち子タスク３が実行
されることなくステップＳ１３に戻る。
【００４２】ステップＳ１４においてＯＳ起動回数カウ
ンタに変化がないと判定された場合（Ｓ１４：ＮＯ）、
データの退避などのシステム停止準備動作が実行され
（Ｓ１７）、Ｓ１６に進む。すなわち、ＯＳ１が正常に
動作していないと判断できるので、ウオッチドッグタイ
マをクリアしないことによりマイクロコントローラをリ
セットさせるのである。
ンタに変化がないと判定された場合（Ｓ１４：ＮＯ）、
データの退避などのシステム停止準備動作が実行され
（Ｓ１７）、Ｓ１６に進む。すなわち、ＯＳ１が正常に
動作していないと判断できるので、ウオッチドッグタイ
マをクリアしないことによりマイクロコントローラをリ
セットさせるのである。
【００４３】以上の監視タスク４の動作は、タイマ割込
によりＯＳ１が起動される度に中断され、その後ＯＳ１
の動作が終了することにより、中断箇所以降が引き続い
て実行される。
によりＯＳ１が起動される度に中断され、その後ＯＳ１
の動作が終了することにより、中断箇所以降が引き続い
て実行される。
【００４４】なお、上記実施形態においては、ＯＳ１が
監視タスク４の異常を検知したとき、および監視タスク
４がＯＳ１の異常を検知したときに、ウオッチドッグタ
イマをクリアしないことによりマイクロコントローラを
リセットさせたが、マイクロコントローラの命令中にリ
セット命令が存在する場合、ＯＳ１が監視タスク４の異
常を検知したときにＯＳ１がリセット命令を発行し、ま
た監視タスク４がＯＳ１の異常を検知したときに監視タ
スク４がリセット命令を発行するように構成してもよ
い。
監視タスク４の異常を検知したとき、および監視タスク
４がＯＳ１の異常を検知したときに、ウオッチドッグタ
イマをクリアしないことによりマイクロコントローラを
リセットさせたが、マイクロコントローラの命令中にリ
セット命令が存在する場合、ＯＳ１が監視タスク４の異
常を検知したときにＯＳ１がリセット命令を発行し、ま
た監視タスク４がＯＳ１の異常を検知したときに監視タ
スク４がリセット命令を発行するように構成してもよ
い。
【００４５】
【発明の効果】以上説明したように、本発明によれば、
最上位レベルのタスクと最下位レベルのタスクすなわち
監視タスクとで、互いの動作を相互監視するので、プロ
グラム構成上の最上位レベルから最下位レベルまでのい
ずれのレベルのタスクに起因する暴走であっても、確実
にそれを検知できる。
最上位レベルのタスクと最下位レベルのタスクすなわち
監視タスクとで、互いの動作を相互監視するので、プロ
グラム構成上の最上位レベルから最下位レベルまでのい
ずれのレベルのタスクに起因する暴走であっても、確実
にそれを検知できる。
【図１】本発明に係るマイクロコントローラの暴走監視
方法を採用したプログラム構造の説明図である。
方法を採用したプログラム構造の説明図である。
【図２】ＯＳの動作を説明するフローチャートである。
【図３】監視タスクの動作を説明するフローチャートで
ある。
ある。
【図４】従来のマイクロコントローラの暴走監視方法を
採用したプログラム構造の説明図である。
採用したプログラム構造の説明図である。
１ ＯＳ ２ 子タスク ３ フラグ待ち子タスク ４ 監視タスク
Claims (4)
- 【請求項１】 複数のタスクを時分割で実行するマルチ
プログラミングを採用したマイクロコントローラにおけ
る暴走監視方法であって、 プログラム構成上の最下位レベルに、プログラム構成上
の最上位レベルのタスクによって管理されず、かつその
最上位レベルのタスクが正常に動作しているか否かを監
視する監視タスクを配置し、 前記最上位レベルのタスクによって前記監視タスクが正
常に動作しているか否かを監視することを特徴とする、
マイクロコントローラの暴走監視方法。 - 【請求項２】 前記最上位レベルのタスクは、前記監視
タスクの起動毎にインクリメントされる監視タスク起動
回数カウンタのカウント値に基づいて前記監視タスクが
正常に動作しているか否かを監視し、 前記監視タスクは、前記最上位レベルのタスクの起動毎
にインクリメントされる最上位タスク起動回数カウンタ
のカウント値に基づいて前記最上位レベルのタスクが正
常に動作しているか否かを監視する、請求項１に記載の
マイクロコントローラの暴走監視方法。 - 【請求項３】 前記最上位レベルのタスクは、前記監視
タスクが正常に動作していないことを検知したときに、
ウオッチドッグタイマをクリアしないことによりマイク
ロコントローラをリセットさせ、 前記監視タスクは、前記最上位レベルのタスクが正常に
動作していないことを検知したときに、前記ウオッチド
ッグタイマをクリアしないことによりマイクロコントロ
ーラをリセットさせる、請求項１または２に記載のマイ
クロコントローラの暴走監視方法。 - 【請求項４】 前記最上位レベルのタスクは、前記監視
タスクが正常に動作していないことを検知したときに、
リセット命令を発行することによりマイクロコントロー
ラをリセットさせ、 前記監視タスクは、前記最上位レベルのタスクが正常に
動作していないことを検知したときに、リセット命令を
発行することによりマイクロコントローラをリセットさ
せる、請求項１または２に記載のマイクロコントローラ
の暴走監視方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP10297916A JP2000122900A (ja) | 1998-10-20 | 1998-10-20 | マイクロコントローラの暴走監視方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP10297916A JP2000122900A (ja) | 1998-10-20 | 1998-10-20 | マイクロコントローラの暴走監視方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2000122900A true JP2000122900A (ja) | 2000-04-28 |
Family
ID=17852760
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP10297916A Pending JP2000122900A (ja) | 1998-10-20 | 1998-10-20 | マイクロコントローラの暴走監視方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2000122900A (ja) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2010267091A (ja) * | 2009-05-14 | 2010-11-25 | Canon Inc | 情報処理装置、その制御方法、及びコンピュータプログラム |
| US7996732B2 (en) | 2006-06-14 | 2011-08-09 | Denso Corporation | Program-execution monitoring method, system, and program |
| JP2012089073A (ja) * | 2010-10-22 | 2012-05-10 | Denso Corp | 電子制御装置、及び、これを用いた電動パワーステアリング装置 |
-
1998
- 1998-10-20 JP JP10297916A patent/JP2000122900A/ja active Pending
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7996732B2 (en) | 2006-06-14 | 2011-08-09 | Denso Corporation | Program-execution monitoring method, system, and program |
| JP2010267091A (ja) * | 2009-05-14 | 2010-11-25 | Canon Inc | 情報処理装置、その制御方法、及びコンピュータプログラム |
| JP2012089073A (ja) * | 2010-10-22 | 2012-05-10 | Denso Corp | 電子制御装置、及び、これを用いた電動パワーステアリング装置 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JPS60263235A (ja) | マイクロコンピユ−タシステム | |
| US7721083B2 (en) | CPU runaway determination circuit and CPU runaway determination method | |
| JP2001056772A (ja) | 障害監視システム | |
| JP2000122900A (ja) | マイクロコントローラの暴走監視方法 | |
| US6321289B1 (en) | Apparatus for automatically notifying operating system level applications of the occurrence of system management events | |
| JP2965075B2 (ja) | プログラム実行状態監視方法 | |
| JP2000187521A (ja) | Ｖｄｔ作業監視装置、及び監視方法 | |
| CN106227615B (zh) | 程序启动过程中预防进程卡死的方法及系统 | |
| CN107145402B (zh) | 一种检测软件宕机的方法和电子设备 | |
| JPS63163932A (ja) | 制御用計算機のシステム監視方式 | |
| JP3859564B2 (ja) | イベント通知タスク制御処理方式及び方法並びにプログラム | |
| JP4675567B2 (ja) | 大画面表示システム | |
| JP2004213122A (ja) | クライアント／サーバによる制御システムの安定稼働方法及びそのプログラム | |
| JPH11282725A (ja) | 計算機 | |
| JP2000076081A (ja) | タスクマネージャー及びプログラム記録媒体 | |
| JPS6389941A (ja) | マイクロプロセツサ応用機器の監視制御装置 | |
| JPH0334037A (ja) | システム異常の検出処理方式 | |
| JPH07271561A (ja) | 情報処理装置 | |
| JP2002229807A (ja) | 応答制御装置およびコンピュータ・プログラム | |
| JPH05324416A (ja) | システムエラーヒストリー退避方式 | |
| JPH05257748A (ja) | マイクロプロセッサ装置 | |
| JP2000066926A (ja) | Ｏｓを使用したプログラミング時の暴走検出方法 | |
| JP2814988B2 (ja) | 障害処理方式 | |
| JPH04252315A (ja) | 処理装置のリセット方法 | |
| JPH1139032A (ja) | マルチｃｐｕ型集中監視装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040818 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070806 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070828 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20080115 |