ウォッチドッグタイマ（WDT）の安全設計について。

質問

組み込み系（車載系）の質問です。
マイコンのプログラムにて、ウォッチドッグタイマ
の仕様検討をしています。

通常ウォッチドッグはマイコン暴走時の検知として、
Resetを発生させるような作りになっていると思うのですが、

なぜ暴走したかわからないまま、単純にResetを
かけて、何もなかったように再び起動してよいものか？
と疑問に感じております。
（例えば、すでにハード的に異常が発生しており、マイコンの
　Resetをかけてもある事象が発生すると必ず暴走してしまい。
　それが原因で恐ろしい事態へとつながる・・等）

このような状態を防ぐためにも、何か定石的な考え方は
ありませんでしょうか？例でも結構ですので、ご教示
頂きたく思っております。

■例（自分なりに検討してみました）
　例えばウォッチドッグタイマ割り込みを使用して、
　割り込みルーチン内でソフトウェアリセットを掛ける。
　その時同時に E2PROM等にウォッチドッグタイマ割り込み発生
　回数を記憶しておき、Resetスタート後この発生回数を確認し、
　ある回数を超えた時点で、エラーモードへ遷移する。

回答No.4

ralf124c · ベストアンサー

かなり昔の話で間違いも多くて恐縮なのですが、交換器などの顧客の利用状況のデータが最重要なシステムではシステムのリセットにグレードを設けております。
かなりうろおぼえなのですが、どのようなグレードかと申しますと
　0.5：現状発生しているイベントを保障する(新規のイベントは棄てる)
　1.0：現状のイベントで重要度の高いもののみ保障する
　1.5：課金情報のみを保障する
　2.0：メモリのダンプを取って一部の装置をリセットする
　2.5：メモリの全ダンプを取って全リセットする→再起動を数回失敗するとOFFの状態に
のような感じだったかと・・・(正確でなくてごめんなさい)。
一応、多重構成になっているのでWDTがオーバーフロー(数百ミリ秒単位)するとまず系が切り替わり、その繰り返し回数が一定量を超えると上記のような試みが複数回ずつ実行されて遷移してゆきます。
このようなクリティカルなイベントをフェーズ番号という番号(0.5,1,1.5,2,2.5)で表していた記憶があります。
ご参考になりますかどうか・・・。

お礼

なるほど。。
大変参考になりました。
「エラーの頻度によってフェーズを切り替え、最終的にはシステムダウンさせる。」
使えそうです！有り難うございます。

回答No.3

noname#242220

この様な時に『フェイルセーフ』と言う考え方が有ります。
自動車はエンジンが故障した場合、エンジンの回転を制御できないような故障ではなく、回転が停止するような故障であれば車自体が止まることになり安全である。このため、回転を止めるような故障モードに自動的に（自然に）落とし込むような設計思想がフェイルセーフとなる。
＊　ウィキペディアより
と言う事ですのでウォッチドッグタイマ割り込みで転移する動作モードが
上記の様に成っていれば問題は無いでしょうね。

お礼

ご回答ありがとうございます。
ウォッチドッグタイマ割り込みが発生した要因で、

＞エンジンの回転を制御できないような故障ではなく、
＞回転が停止するような故障

の判定ができれば良いのですが、デバッグをしない限り、
ウォッチドッグの要因を判定するのは難しいですよねぇ？

回答No.2

zwi

>その時同時に E2PROM等にウォッチドッグタイマ割り込み発生回数を記憶しておき、Resetスタート後この発生回数を確認し、ある回数を超えた時点で、エラーモードへ遷移する。

E2PROM等に記録される発生回数はずっとカウントアップでしょうか？
気になるのは、稀にハードに起因するとかで発生する問題の積み重ねで１年後とか２年後とかエラー遷移した場合で、その場合は原因がわからないんじゃないでしょうか？
それにエラーモードに遷移されても困る状況って無いのか気になります。車が走らないとかなって、それが多発したらリコールが怖そうです^^;

って事でＷＤＴが発生する時間間隔についても知らべないとまずいと思います。

補足

アドバイスありがとうございます。
そうですね。時間測定の機能を使用出来れば、
時間間隔に関しても考慮することで詳細な
エラー判定ができそうですね！

一言でエラーモードと言っても”何のエラーで？”といった所を
考慮する必要がありそうですね。。難しそうですが・・

＞それにエラーモードに遷移されても困る状況って無いのか気になりま＞す。車が走らないとかなって、それが多発したらリコールが怖そうで＞す^^;
⇒
　信頼をとるか安全をとるかですね。。

回答No.1

Tasuke22

なるほど、ですね。

昔、汎用機をやっていたころはウォッチドックタイマ割込みは
即メモリダンプを取って原因を1件ずつ追求していましたが、
車載用は、無限ループ解除、に使っているのですね。

確かに、解除、リセットでは現象を回避するだけで根本問題の
解決にはならないですね。

回数を記録するだけでも、進歩と思います。欲を言えば動いて
た場所なども記録して、原因追及の足がかりも作りたいですが、
欲が大きいでしょうか。

お礼

車載に限らず、民生品等に関しても無限LOOPや暴走等の検知で
リセットをかけるような仕組みになっています。

民生品であれば即リセットでも特に問題ないと思うのですが、
（当然ユーザーはびっくりしますが、命にかかわることは
　ないと思います。）
しかし車となる話は別になるのかなと・・

デバッグ時であれば、オンチップデバッグ等のトレース機能を
用いて、ある程度原因追究できそうですけどね！