|
23 |
EGASアーキテクチャ (3) |
挙げられたフォールトにはランダムハードウエアフォールトとシステマティックフォールトの2種類が混ざっています。ランダムハードウエアフォールトのみに関して、設計、検証上の注意点を教えてください。
ChatGPT:
ランダムハードウェアフォールト（Random Hardware Fault）は、シリコンや電子部品の経年劣化や物理的要因（放射線、温度、振動など）によって確率的に発生する故障であり、設計上・製造上のミス（いわゆるシステマティックフォールト）とは異なる性質を持ちます。ISO 26262の文脈でも、ランダムハードウェアフォールトに対してはハードウェアアーキテクチャメトリクス（Single Point Fault Metric, Latent Fault Metricなど）や、FMEDA (Failure Mode, Effects and Diagnostic Analysis) を用いて、想定される故障モードを分析し、必要な診断機能や冗長化を実装して要求レベル（ASIL）を満たすことが求められます。
以下では、ランダムハードウェアフォールトに着目したときの設計上・検証上の注意点を整理します。
1. 設計上の注意点
1-1. ハードウェアアーキテクチャメトリクスへの適合
ISO 26262 Part 5 では、Single Point Fault Metric (SPFM) や Latent Fault Metric (LFM)、さらにシステムレベルでは Probabilistic Metric for random Hardware Failures (PMHF) といった指標を達成する必要があります。
- SPFM: 単一点故障（検出されずに安全目標を侵害する恐れのある故障）の確率をいかに低く抑えるか。
- LFM: ある程度時間が経過しないと顕在化しない潜在故障をどれだけ検出できるか。
- PMHF: システムレベルで安全目標が侵害される確率を年間あたりいくつに抑えられるか。
これらを満たすため、以下のようなハードウェア診断・冗長化が設計段階で考慮されます。
- 冗長化設計
- 二重化(2エレメント)やモニタ系を持つことで故障検知と安全側制御を可能にする。
- 自己診断機能(オンチップBIST, RAMテスト, ECC/パリティ等)
- CPU/メモリ内部でのビット化け、回路の破損を検出する機構。
- アナログフロントエンドの診断
- センサ用ADCにリファレンス電圧監視、クロスチェックなどを用意して入力故障を検出する。
1-2. FMEDAによる故障モード・診断カバレッジの分析
部品レベルからECUレベルまで、FMEDA (Failure Mode, Effects and Diagnostic Analysis) を実施し、以下を明確にするのが一般的です。
- 故障モードの洗い出し
- 例: トランジスタ短絡、抵抗断線、コンデンサリーク、配線ショート、メモリビットフリップ等。
- 故障の影響(Effect)評価
- その故障が安全機能にどう影響を与えるか（単一点故障なのか、それともシステムは検出可能なのか）。
- 診断方法(Diagnostic Coverage)の見積もり
- どの診断機能を使ってどれくらいの確率で故障を検出できるのか。
- 故障率(λ)の妥当性評価
- 部品の信頼性データ（IEC TR 62380, SN29500, FIDESなどの信頼性規格）を参照し、ランダム故障率を定量化。
FMEDAの結果をもとに、冗長化や診断の追加を行いながら、要求されるハードウェアメトリクスを達成するかどうかを評価します。
1-3. 物理的・環境的要因への対策
ランダムハードウェアフォールトの発生率は、温度・振動・湿度などの使用環境によって大きく変化します。
- 温度上昇 → バイポーラトランジスタの熱暴走、電解コンデンサの寿命短縮など。
- 振動/衝撃 → はんだクラック、部品の破断など。
- 湿度/水分 → PCBへの腐食、漏電による誤作動。
設計段階で、ECUの筐体構造、防振設計、放熱設計、封止（ポッティング）などを吟味し、過酷な環境条件下でも故障率が過度に上がらないようにすることが必要です。
1-4. フェイルセーフコンセプト・安全機構の導入
ランダムフォールトが起きても、システム全体の安全を保つためのフェイルセーフコンセプトを策定します。
- デグレード制御
- 例: スロットルポジションがわからなくなったらリミット制御やアイドル固定。
- フェイルサイレント化
- 致命的な故障が発生した場合は、出力ドライバを強制的にOFFし、出力をカットする。
- エスケープパス
- 車両制御機能が部分的に失われても安全に停止できるようブレーキ・ステア系などの冗長設計を検討。
2. 検証上の注意点
2-1. ハードウェア診断機構のテスト
ランダムハードウェアフォールトを想定した診断機構（例: ECC、BIST、ウォッチドッグなど）が、実際に故障を想定した条件下で正しく検出・動作するかを検証します。
- フォールトインジェクションテスト
- シミュレーションやプロトタイプ基板上で、メモリビットフリップや回路短絡/断線を模擬して、診断が作動するかを確認する。
- ソフトウェア診断ルーチンのデバッグ
- ランタイムで実行するCPU自己診断、RAMテストなどが意図したタイミング・カバレッジで動作しているかを計測。
2-2. 信頼性試験・加速試験
- 環境試験(熱サイクル、振動、湿度、耐久試験)
- ランダムフォールトの発生メカニズムを早期に引き起こすための加速試験(例: HALT/HASSなど)で、実際にどの程度の故障が発生するかを評価。
- バーンイン試験
- 製造直後の初期故障(Infant Mortality)を除去するために、通電して高温環境下で一定時間運転し、不良素子を早期に検出。
2-3. FMEDA・FTAの整合性確認
- FMEDA結果で見積もった診断カバレッジや故障率をシステム全体のフォルトツリー解析(FTA) と照合し、
- 「単一故障が検出できずに安全目標を侵害する確率が、ASIL要件を満たす範囲内にあるか」
- 「複合故障の検出・制御がどの程度可能か」
をシミュレーションや実機試験で確認する。
2-4. 整合性レポートとコンフィギュレーション管理
- 機能安全の開発プロセスでは、文書化と追跡性(Traceability) が重視されます。
- ランダムハードウェアフォールト対策として導入した設計・診断機能が、どの安全要求(SR: Safety Requirement)に対して妥当性を持つのかを明確にレポート化し、ソフトウェアやシステム全体と整合性を取ります。
3. まとめ
ランダムハードウェアフォールトは、システマティックフォールト（設計不良やソフトウェアバグ等）とは異なり、確率的に避けられない側面があります。そのため、ISO 26262のハードウェア開発プロセスでは以下が特に重視されます。
- ハードウェアアーキテクチャメトリクス(SPFM/LFM/PMHF)の達成
- FMEDAを中心とした故障モード解析と診断カバレッジ設計
- 物理的・環境的要因を考慮した信頼性設計(温度、振動、防湿など)
- 診断機能(オンチップBISTやECC等)とフェイルセーフコンセプトの徹底
- フォールトインジェクションや加速試験等による検証
こうしたプロセスを通じて、ランダムハードウェアフォールトの発生率を可能な限り低減し、故障が発生しても安全要求を侵害しない(もしくは侵害の確率を必要十分に低く抑える)ようなシステムを実現することが重要となります。
ChatGPT の回答は必ずしも正しいとは限りません。重要な情報は確認するようにしてください。
前のブログ
Leave a Comment