組み込みシステムの障害モデリング

マイクロコントローラーと2.4 GHzトランシーバーモジュールを備えたワイヤレスセンサー回路、I²Cインターフェイスを備えた一部の統合センサー、UARTポート、および必要なディスクリートコンポーネントがあります。

このボードは、LiPoバッテリーとシャント充電器を備えた、ソーラー（PV）パネルからの電力を清掃するように設計されています。これにより、センサーは自己給電され、無期限に動作し、メンテナンスを最小限に抑えることができます。

このようなシステムで発生する可能性のある障害を調査したいと思います。これは、経年劣化、環境仕様（温度、湿度など）の違反、または誤ったメンテナンス（設計の問題/バグではない）が原因である可能性があります。動作寿命を最大化するため。

センサーノードが動作する環境は、天井または壁に貼り付けられた建物です。したがって、極端な温度や雨は考慮されません。

私が思いついたのは、要約しようとするいくつかの欠点です：

• コンポーネントが壊れています->オープン\短絡
• センサーの故障->誤った出力値（しかし、どのように間違っていますか？）
• ほこり\水による分離の欠陥->漏れの増加
• 温度が範囲外-> ???

センサーノードがどのように失敗するかをどのように推定できますか、そしてその理由は？

起こりうる障害を「すべて」理解するには、自由度が多すぎます。ただし、設計サイクルの早い段階（つまり、広範囲にリリースする前）で障害を特定して軽減するための手法があります。

設計時の活動（プレハードウェア）

ピアレビューは、常にバグを見つけるための優れた方法です。他の人に設計を分析してもらい、質問に対する防御の準備をしてもらいます（または、バグを発見したことを認めて修正します！）精査に代わるものはなく、疲れたものに見落とされているものは新鮮な目でよく見られます。これはハードウェアとソフトウェアの両方で機能します-回路図はソースコードと同じくらい簡単にレビューできます。

ハードウェアについては、他の人が言ったように、DFMEA（Design Failure Mode and Effects Analysis）がお勧めです。各コンポーネントについて、「これが短絡した場合どうなるか」と「これが断線した場合どうなるか」を自問し、分析の記録を作成してください。ICの場合、隣接するピンが互いに短絡した場合にどうなるかを想像してください（はんだブリッジなど）。

ファームウェアの場合、静的コード分析ツール（MISRA、lintなど）を使用して、コード内の隠れたバグを明らかにできます。フローティングポインターや比較の代わりの等価性（= vs ==）などは、これらのツールが見逃すことのない一般的な「大失敗」です。

動作の書面による理論も、ハードウェアとソフトウェアの両方にとって非常に役立ちます。動作理論では、システムの動作、保護の動作、シーケンスなどについてかなり高いレベルで説明する必要があります。ロジックの流れ方を簡単に説明すると、多くの場合、一部のケースが見落とされている可能性があることに気づきます（「ワイタセック、この状態はどうですか？」）

プロトタイプレベルのテスト

ハードウェアを入手したら、次は「仕事」に取り掛かります。

理論的な分析がすべて完了したら、デバイスが仕様内でどのように動作するかを正確に特徴付けることが重要です。これは、一般に検証テストまたは認定と呼ばれます。許容されるすべての極値をテストする必要があります。

もう1つの重要な認定アクティビティは、コンポーネントの応力分析です。すべての部品は、定義された動作条件で、最大電圧/電流/温度に対して評価されます。堅牢性を確保するには、適切なディレーティングガイドラインを適用する必要があります（電圧の80％、電力の70％を超えないようにしてください）。

正常な状態にあることを知ってはじめて、外部の異常、または説明しているような複数の異常について推測を始めることができます。この場合も、DFMEAモデル（Xが発生するとどうなるか）は良いアプローチです。ユーザーがユニットに対して行うことができるあらゆることを考えてください-出力を短くし、信号を結合し、ユニットに水をこぼします-それらを試して、何が起こるかを確認します。

HALTテスト（高度に加速された寿命テスト）は、これらのタイプのシステムにも役立ちます。ユニットは環境チャンバーに入れられ、最低温度から最高温度まで、最低および最高の入力および出力を振動させて実行されます。これにより、電気的および機械的なあらゆる種類の問題が見つかります。

これは、いくつかの組み込みファズテストを実行するのにも良いタイミングです。すべての入力を期待される範囲をはるかに超えて実行し、UART / I2Cなどを通じて意味不明なものを送信して、ロジックの穴を見つけます。（例えば、ビットバンギングI2Cルーチンは、バスをロックすることで悪名高いです。）

ストライフテストは、堅牢性を実証する良い方法です。過熱、過負荷などの保護機能を無効にし、何かが壊れるまでストレスを加えます。ユニットは、何か障害が発生するか、異常な動作が発生するまで、できるだけ高温にしてください。パワートレインが故障するまでユニットに過負荷をかけます。いくつかのパラメーターが最悪の条件をわずかに超えて失敗した場合、それは限界性の指標であり、設計上の考慮事項を再検討する必要があるかもしれません。

次のレベルのアプローチを採用して、DFMEAの結論のいくつかを物理的にテストすることもできます。実際には、ショートとオープン、ピンショートを行い、何が爆発するかを確認します。

参考文献

私の経歴は電力変換です。私たちはIPC-9592Aと呼ばれる業界標準を持っています。これは、どのようなテストとその実行方法に関して、製品の認定方法を標準化する取り組みです。このドキュメントで言及されている種類のテストや方法論の多くは、他の電気分野でも簡単に使用できます。

I2Cインターフェースに複数のデバイスがあると、1つのデバイスが失敗し、I2Cを占有し、他のすべてのI2C送信を強制終了する「バブバブ」問題の可能性があります。

浸漬テストと環境テストを組み合わせると、異なる形式の障害分析が提供されます。限界コンポーネント、最大/最小/変動する温度、異なる湿度、汚れた電源、ノイズの多いRF環境などを一定期間使用すると、通常の使用よりもはるかに長い期間をシミュレートします。システムには実際の故障があり、故障率を計算できます。

最も可能性の高い障害はファームウェアのバグです。私がやったことはすべていくつかありました。

ウォッチドッグタイマーが有効になっていることを確認し、「犬をかわいがる」前にすべての重要な繰り返し機能を実行する必要があります。タイマー割り込みにフラグを設定し、それを使用してメインループのウォッチドッグをクリアします。

リセットサイクルでファームウェアの回復もテストします。

起動は多くの障害が発生したときなので、リレーを介して電源を入れ、電源を入れ直すための簡単なスクリプトを作成し、無線がウェイクアップを示すのを待って、繰り返します。次に、これを10000サイクルほど実行します。

いくつかの明らかなもの：

• バッテリーの故障。おそらく電解液の損失により、電子機器の汚染につながります
• 太陽光発電システムからの過電圧
• 機械の近くにありますか？その後、衝撃/振動
• 外部環境（雨/雪が信号を吸収するなど）による通信の損失。

FMEAを実行している場合、何が障害を構成するかを決定する前に、システムがどれほど重要であるかを最初に検討する必要があります。

加速寿命試験および高度加速寿命試験について誰も言及しなかったことに驚いています。

自由に使える重要なツールの1つは、摂氏10度の温度上昇ごとに、平均信頼性が50％低下することです。非常に高い温度でテストすることにより、製品の寿命をある程度知ることができます。これを利用するために、定格温度を超えてコンポーネントをテストする必要はありません。