ウォッチドッグの正しい設計手法
ウォッチドッグタイマー（以下WDT）を有効にして周期的にカウンタのクリアをおこなっていても、実機のフリーズを検知できないことがあり、組み込みの現場では珍しくない失敗です。この原因の多くは、WDTを設定で足りる機能と捉える思い込みにあります。ウォッチドッグは設定で済ませられるものではなく、計画を立てて設計する対象です。
本記事では、WDTの必要性から正しい蹴り方(WDTのクリアの仕方）、誤検知を防ぐ設計方法、ログ設計、レビュー観点までを解説します。
ウォッチドッグが必要な理由
WDTは、システムの異常を検知する監視機構です。ただ有効にして実行するだけでは、肝心の異常を見逃します。まずはWDTの概要、実装品質の重要性、内蔵WDTと外部WDTの使い分けを確認しましょう。
ウォッチドッグの概要
WDTは、プログラムの暴走やフリーズを監視するタイマーです。タイマーは自動的にカウントアップするため、内部カウンタがオーバーフローすると、システムの停止やリセットが発生します。プログラムの暴走やフリーズが起こると、このような状況に陥りがちです。
オーバーフローによるトラブルを防ぐには、プログラムにカウンタを定期的にクリアし続けるコードを記述します。このクリア操作を、いわゆる「蹴る」と呼びます。
実装品質が重要な理由
WDTが頼りになるかどうかは、蹴り方の実装品質で決まります。蹴り方を誤れば、異常が起きてもWDTはリセットをかけられないのです。例えば、ある技術資料によれば、一定周期で機械的に蹴る方式の危うさを指摘しています。WDTはハードウェアの保険ではなく、ソフトウェア設計そのものといえるでしょう。
内蔵WDTと外部WDTの使い分け
多くのマイコンはWDTを内蔵しており、追加コストなく使えるのが利点です。一方で、内臓WDTはマイコン誤動作時に正しく機能しない可能性が存在します。そういった懸念に対処するために、外部WDTをつけることで信頼性を向上させることもできます。外部WDTはマイコンから独立して動くため、システムの暴走やフリーズが発生した場合でも監視を続けられるという利点があります。また信頼性の高さが求められる機器では、内蔵WDTと外部WDTの組み合わせも有効な選択肢です。
「正しい蹴り方」のための設計
正しい蹴り方とは、タスクの正常な動作を確かめてから蹴る方式を指します。ここからは危険なキック実装、動作確認、RTOS環境の設計を順に見ていきます。
危険なWDTのキック実装
最も避けたいのは、タイマー割り込みの中だけでWDTを蹴る実装です。割り込みはメイン処理の停止中も動き続け、暴走中でもカウンタがクリアされてしまいます。では固定された一カ所で蹴る方式なら安全かというと、そうではありません。一部のタスクが停止しても、その箇所さえ通れば監視は成立してしまうのです。
正常に動作することを確認してから蹴る設計
推奨されるのは、各タスクが正常かどうかを確かめてから蹴る設計です。タスクごとに生存フラグを用意し、各タスクが周期内に自分のフラグを立てます。監視役は全フラグがそろったときだけWDTを蹴り、直後にフラグを戻すのです。一つでも欠ければ蹴らないため、部分的なタスク停止も見逃しません。
RTOS環境におけるWDT設計
リアルタイムOS（RTOS）を使う場合は、WDT設計にいっそう踏み込んだ配慮が必要です。監視タスクがスケジュール状況を確かめてから蹴るべきだと説いている資料もあります。これらを安定して実現するために、ゲートキーパータスクやミューテックスを活用して、優先度の逆転を抑えましょう。またアイドルタスクの監視だけでは、高優先度タスクの暴走を見逃すことにも注意が必要です。
誤検知を防ぐ設計のポイント
WDTには、正常な処理を異常と誤判定しない設計も求められます。誤検知による不要なリセットは、それ自体が一つの障害です。ここからは起動直後や高負荷による誤検知への対策、Window WDTの活用、タイムアウト時間の決め方を扱います。
起動直後や高負荷時における誤検知対策
誤検知が起きやすいのは、処理が長く止まる場面です。起動直後の初期化やFlashメモリへの書き込み中は、通常より長い停止が生じます。一時的な高負荷も、処理時間を押し上げる要因です。対策は、こうした長い停止を見込み、処理が最も長引く場合でもタイムアウトしない設計にすることです。
Window WDTの活用
通常のWDTは、蹴るのが遅すぎる異常しか検知できません。Window WDTは、蹴ってよい時間帯に下限と上限を設けます。早すぎる蹴りは、一定周期で空転する暴走ループの兆候です。ある資料では、ウィンドウが開く前の蹴りを異常として検出できると説明しています。また、一部のマイコンメーカーの資料には、ウィンドウ開始位置を75％に置く設定例が示されています。
タイムアウト時間の決め方
タイムアウト時間は、最悪実行時間（WCET）を基準に決めます。短すぎれば誤検知を招き、長すぎれば異常の発見が遅れます。実測した処理時間をベースに、余裕を加えて設定するのが基本です。一部のマイコンメーカーの資料では、60MHzのクロックを8192分周して16384カウントで約2.23秒になる例を示しています。
WDTリセット発生時のログ設計とダンプ取得
もしWDTによるリセットが発生した場合は放置せず、原因を究明する必要があります。そのためにはログやダンプなど、調査に必要な情報の確保が重要です。ここでは原因究明の重要性、異常時のログ設計、ダンプ取得と安全な復帰を取り上げます。
再起動後における原因究明の重要性
原因不明のまま再起動が続けば、現場は深刻な事態に陥るでしょう。手がかりがなければ、再現困難なバグの調査に多くの時間を奪われます。この事態を防ぐためには、ログなどの情報を確保した上で原因究明をおこなうことが重要です。IPAの設計ガイドでも、異常の検知とログによる記録をあわせて設計するよう促しています。
異常時のログ設計
異常時のログで最初に押さえたいのは、リセットの要因です。多くのマイコンはリセット要因レジスタを備え、WDTか電源かを起動時に判別できます。１つの方法として、専用レジスタのビットから種別を読み取る手法があります。タスクの状態やスタック情報も記録し、不揮発メモリへ退避させます。
ダンプの取得と解析、安全な復帰
クラッシュ解析の鍵は、ダンプの取得方針をあらかじめ決めておくことです。RAM全体の保存が難しければ、プログラムカウンタなど最小限の情報に絞ります。ダンプから原因を特定する解析ツールも、整ってきました。復帰設計にも慎重さが要り、リセット後はフェイルセーフ状態を経て通常動作へ戻します。
WDT設計におけるレビュー観点
WDTの品質は、実装した後の検証で決まります。コードを書き終えた時点では、異常時に機能するかはまだわかりません。最後に見落とされやすいレビュー観点、テスト観点の作り方、品質保証との関係を整理します。
見落とされやすいレビュー観点
レビューでありがちなのは、「カウンタのクリアがおこなわれている」事実だけを見て満足する姿勢です。本当に見るべきは、異常時に検知できるかどうかという一点にあります。割り込みを禁止した区間で監視が止まっていないかも、あわせて確かめてください。異常な経路でWDTが無効化されないか、コードを追って調べる姿勢も欠かせません。
テスト観点の作成方法
テストの要点は、異常を意図的に起こして復帰動作を確かめることです。タスクを故意に無限ループへ陥らせる試験を、観点に組み込みます。CPUへの高負荷や通信の遮断、デッドロックも意図的に再現するのです。こうした試験は、機能安全規格IEC 61508が診断カバレッジの検証手段として求めるアプローチでもあります。
品質保証とWDT設計の関係
WDT設計は、システム全体の品質保証に直結します。機能安全規格のIEC 61508やISO 26262は、メインとなるシステムが動作しなくてもWDTは動作できるよう、WDTに独立性を求めています。異常の検知、フェイルセーフ状態への移行、安全な復帰までを一連の流れとして設計してこそ、品質は保たれます。
