組み込みシステムのウォッチドッグタイマー（WDT）の活用、ハードウェアとソフトウェアWDTの違い
組み込みシステムのハングアップは、製品の信頼性を大きく損ねる深刻な問題です。ユーザー体験を著しく低下させ、最悪の場合、製品に対する信頼を失墜させることにもつながります。システムが応答しなくなり、電源を入れ直すまで動かないといった状況は、開発者にとって頭の痛い課題でしょう。
このような事態を防ぎ、システムの安定稼働を確保するために不可欠なのが、ウォッチドッグタイマー（WDT）です。WDTは、システムがフリーズしたり、予期せぬループに陥ったりした際に、自動的にシステムを再起動させる番犬のような役割を果たします。適切に活用することで、製品の信頼性を飛躍的に高められます。
ウォッチドッグタイマー（WDT）の基本的な仕組み
ウォッチドッグタイマーは、組み込みシステムが正常に動作しているかを監視するための仕組みです。タイマーが一定時間内にリセットされない場合、システムに異常が発生したと判断し、強制的にリセットをかけます。これにより、システムが完全に停止したままになることを防ぎ、自己復旧を促します。
WDTの動作はシンプルです。システム内のプログラムが定期的にWDTをクリア（またはキック）することで、タイマーがタイムアウトしないようにします。もしプログラムが何らかの理由でWDTをクリアできなくなると、タイマーは設定された時間を経過し、システムの再起動が実行されます。
ハードウェアWDTとソフトウェアWDTの違い
ウォッチドッグタイマーには、大きく分けてハードウェアWDTとソフトウェアWDTの2種類があります。それぞれの特性を理解し、適切に使い分けることが重要です。
ハードウェアWDT：システムの最終防衛ライン
ハードウェアWDTは、マイコン内部に独立した回路として実装されているか、外部に専用のICとして配置されます。その最大の特長は、CPUが完全にフリーズしたり、ソフトウェアが暴走したりしても、独立して動作し続ける点です。CPUがどんな状態に陥っても、ハードウェアWDTはタイマーをカウントし続け、タイムアウトすればシステムをリセットします。
メリットとしては、ソフトウェアのバグやOSのクラッシュなど、あらゆる状況からの復旧が期待できることです。システムの健全性を監視する最終防衛ラインとして機能します。しかし、監視できるのは「CPUがWDTをキックできる状態にあるか」という大まかな状態のみで、特定のタスクが停止しているかといった詳細な挙動までは把握できません。
ソフトウェアWDT：きめ細かいタスク監視
ソフトウェアWDTは、アプリケーションコードの一部として実装されるタイマーです。例えば、特定のタスクが予定通りに処理を完了しているかを監視したり、特定のイベントが一定時間内に発生したかをチェックしたりするのに用いられます。
メリットは、監視対象を細かく設定できることです。システム内の個々のモジュールやタスクの健全性を確認できます。しかし、ソフトウェアWDT自体もソフトウェアとして動作するため、CPUが完全に停止したり、OSがクラッシュしたりすると、ソフトウェアWDTも動作を停止してしまい、システムをリセットできない可能性があります。
| 項目 | ハードウェアWDT | ソフトウェアWDT |
|---|---|---|
| 実装方法 | マイコン内蔵回路、または外部IC | アプリケーションコード内 |
| 独立性 | CPUやソフトウェアから独立 | ソフトウェアの一部として動作 |
| 監視対象 | CPU全体の動作（WDTキックの有無） | 特定のタスク、モジュール、イベント |
| 復旧能力 | システム全体のハングアップからの復旧 | 特定機能の停止からの復旧（CPU停止時は不可） |
| 活用シーン | 最終的なシステム全体の安全確保 | 個別の機能やタスクの応答性監視 |
実用上は、ハードウェアWDTをシステム全体の最終的な監視役とし、その上でソフトウェアWDTを導入して個々の機能やタスクの健全性を監視するという、両者を組み合わせた多層的なアプローチが推奨されます。
FreeRTOSにおける全タスク監視設計
リアルタイムOS（RTOS）を使用する組み込みシステムでは、複数のタスクが並行して動作します。この環境でウォッチドッグタイマーを効果的に活用するには、全ての重要なタスクが正常に動作していることを確認する仕組みが必要です。
単に各タスクがそれぞれ勝手にハードウェアWDTをキックするだけでは、一部のタスクが停止していても他のタスクがWDTをキックし続けるため、システム全体のフリーズを見逃す可能性があります。そこで、FreeRTOSのようなRTOS環境では、以下のような設計が一般的です。
- 監視フラグの導入: 各重要なタスクに、自身の生存を示すフラグ（例: `xTaskHeartbeat[TASK_ID]`）を用意します。
- タスクからのフラグ更新: 各タスクは、自身の処理が正常に実行されていることを示すために、定期的にこのフラグを更新（例: カウンタをインクリメント）します。
- WDT監視タスクの設置: 専用のWDT監視タスクを設け、このタスクが定期的に全てのタスクの生存フラグをチェックします。
- WDTのキック: WDT監視タスクは、全ての生存フラグが一定時間内に更新されていることを確認できた場合にのみ、ハードウェアWDTをキックします。
もし、いずれかのタスクの生存フラグが設定された期間内に更新されていなければ、WDT監視タスクはハードウェアWDTをキックしません。これにより、ハードウェアWDTがタイムアウトし、システムがリセットされることで、異常な状態から復旧できます。この方式では、WDT監視タスク自体の優先度を高く設定し、確実に動作するようにすることが重要です。
WDTリセット後のログ保存と原因解析
WDTによるリセットは、システムが異常状態に陥ったことを示します。単に再起動するだけでなく、なぜリセットされたのかを解析することが、根本原因を取り除き、製品の信頼性を高める上で非常に重要です。
リセット後の情報収集
WDTリセットが発生した際に、その直前のシステムの状態を記録する仕組みを導入します。これは、不揮発メモリ（EEPROM、フラッシュメモリなど）にログを保存することで実現します。保存すべき情報としては、以下のようなものが考えられます。
- リセットカウンタ（WDTリセットが発生した回数）
- リセット発生時の時刻（RTCがあれば）
- 直前に実行されていたタスクのID
- プログラムカウンタ（PC）の値
- スタックポインタ（SP）の値
- 主要なレジスタの値
- エラーコードや状態フラグ
これらの情報は、システム起動時に読み出し、開発者が解析できるようにします。特に現場で発生した問題をデバッグする際に、このログが唯一の手がかりとなることも少なくありません。
原因解析の進め方
ログ情報をもとに、リセットの原因を特定します。
まず、リセットカウンタが増加しているか確認し、WDTリセットが頻繁に発生していないかを把握します。
次に、ログに記録されたタスクIDやプログラムカウンタの値から、どのタスクのどのあたりで処理が停止したのか、あるいは無限ループに陥ったのかを推測します。
具体的な解析ステップとしては、以下が挙げられます。
- コードレビュー: ログ情報が指し示すコード箇所を重点的にレビューし、潜在的なバグ（無限ループ、デッドロック、リソース枯渇など）がないか確認します。
- 再現性の確認: 可能な限り開発環境で問題を再現させ、デバッガを使って詳細な動作を追跡します。
- リソース監視: メモリ使用量、スタック使用量、CPU負荷などを監視し、リソース不足が原因でないかを確認します。
- 割り込み処理の確認: 割り込み処理がWDTキックを妨げていないか、あるいは割り込み処理内で問題が発生していないかを確認します。
これらの解析を通じて、システムの脆弱性を特定し、修正することで、WDTリセットの発生頻度を減らし、より堅牢な製品へと改善できます。
製品の信頼性を高めるWDTの導入と製品化支援
ウォッチドッグタイマーは、組み込みシステム開発において、製品の信頼性を担保するための非常に重要な要素です。開発の初期段階からWDTの活用を念頭に置いた設計を行い、テストとデバッグを繰り返すことで、市場投入後に発生しうる重大な問題を未然に防ぐことができます。
当社、サイコス・ジャパン株式会社は、1990年の創業以来35年にわたり、製品開発を一貫して手掛けてきました。機構設計から電子回路、基板、組み込みソフト、クラウド、そして量産まで、製品づくりの全工程を自社で取りまとめてきた実績があります。特に組み込みソフトウェア開発においては、WDTをはじめとする信頼性設計のノウハウを豊富に持っています。
もし、試作機は動くものの、いざ製品化を考えたときにシステムの安定性や信頼性に不安を感じている方がいらっしゃいましたら、ぜひご相談ください。お客様の製品が市場で長く愛されるよう、信頼性の高い製品づくりをサポートいたします。初回相談は無料です。