インターフェースの判断を理解する

正常な周期的ハートビートと、誤ったロジックまたは故障したアクチュエーターが共存することはあり得ます。電源喪失も、ウォッチドッグのタイムアウトとは異なる挙動を生じさせる場合があります。そのため、設計では監視対象を正確に特定し、ウォッチドッグをシステム安全性の完全な実証として扱わないようにするべきです。

制御性能は、信号の意味、タイミング、および承認済みの運転限界に依存します。通常の最適化と保護上の制約を分け、各判断をどの機能が担当するかを明確にしてください。実際の設定値は、選定した風車とコントローラーの文書で定義されていなければなりません。

レビュー記録に必要な情報を整理する

以下の情報をプロジェクト専用の確認表に記録してください。各項目について、文書、改訂番号、不確実な点を解決する責任者を示します。

• ウォッチドッグが監視するタスク、通信、または更新事象. 正確な構成と、その根拠となる文書を特定してください。
• タイムアウトの根拠および関連する実行条件またはネットワーク条件. 設計上の前提をプロジェクト記録で確認できるようにしてください。
• 検出された故障後の物理的な出力状態. 担当の確認者を明示し、不足情報を解決してください。
• 別の診断または保護対策を必要とするその他の故障. 受入れ時にこの項目をどう検証するかを定めてください。

受入れの範囲を定義する

検出できると主張する故障を発生させる試験によって、ウォッチドッグ機能を受け入れてください。ソフトウェアの表示に加えて、結果として生じるハードウェア挙動を検証してください。コントローラーの再起動が、必ず風車の意図した保護状態を成立させると仮定してはいけません。

記録には、どの故障を誘発し、どの機能が試験対象外だったかを明記するべきです。これにより、狭い診断結果をより広範な信頼性や安全性の主張へ拡大することなく、ウォッチドッグの証拠を利用できます。