ウォッチドッグタイマーとしての外部ログ──疲れた判断を迂回する組込み設計の原則
いや、これがですね。最近ちょっと気づいたことがあって。
組込み設計でウォッチドッグタイマー（WDT）を実装するとき、「システムが自分で自分を監視できなくなったとき、外部から叩き起こす」という発想があるじゃないですか？
陸、これをログ設計にそのまま当てはめてみたんすよ。
—
疲れた判断、っていうのが問題なんだよね
長時間稼働するファームウェアで、一番こわいのは静かに壊れていくことなんすよ。クラッシュしてくれれば追いやすい。でも、ちょっとずつズレていく誤動作は、内部の状態機械だけじゃ検出できないことが多い。
人間も同じで──深夜のデバッグ作業中に「まあ、これでいいか」って判断するのは、WDTがタイムアウトしかけてる状態に近い。
—
外部ログを「外部WDT」として使う設計原則
具体的には、こういう三段構えで組んでいる。
- 周期ログをキックとして扱う
内部処理が正常に回っていれば、一定周期でステータスをログに吐き出す。ログが途切れたらアウト。WDTのハートビートと同じ考え方。
- 異常は「検出」より「予兆」で拾う
エラーが出てからじゃ遅い。電圧のドリフトや応答時間の微妙な増加を、外部ログで時系列に残しておく。あとから「あー、なるほど、そういうことか」ってなる。
- 判断をログに委ねる
疲れた自分がリアルタイムで判断するより、ログが「何かおかしい」と教えてくれる設計にする。人間をループの外に出す、というやつ。
—
実装でハマったこと
フラッシュへの書き込み頻度を上げすぎてメモリが早期劣化した経験があって、それ以来リングバッファ＋外部SRAMへの逃がしを基本にしてる。ログ自体がシステムの足を引っ張ったら本末転倒なんで、ここは慎重に設計するんすよ。
—
「疲れた判断を迂回する」という言い方、少し大げさかもしれないけど──原理としては正直そういうことか、と思ってる。WDTが教えてくれるのは、「お前はもう自分で判断できないから、俺がリセットしてやる」という事実だけ。それと同じ謙虚さを、ログ設計にも持ち込みたいんですよね。
→ プロフィール / 他チャネルを見る
コメント