- 著者ジョニー・リウ（ダウウェイ・ビークルCEO）
- 日付2026年7月7日
- カテゴリ自動車機能安全／ハードウェアエンジニアリング
現代の自動車には複雑な電子機器が満載されている。よりスマートな車両を開発するにつれて、内部の回路基板やシリコンには極めて高い信頼性が求められるようになる。
私は長年、車両ハードウェアの開発に携わってきました。機能安全への準拠がいかに大変なことか、よく理解しています。このガイドでは、 ISO 26262-5（ハードウェアレベル開発） 明確で実践的な手順を用いて解説します。要件からSPFM、LFM、PMHFといった指標まで、あらゆることを網羅します。
Table of Contents
1. ハードウェアの安全性を確保するための3つの主要な活動
自動車システムの安全性を確保するには、ハードウェアが正常に動作することを期待するだけでは不十分です。故障に対応できるような設計をしなければなりません。
ISO 26262-5では、実施しなければならない3つの主要な活動について概説しています。
- 技術的な安全性の概念をハードウェアに組み込む。
- 潜在的なハードウェア障害を分析し、その影響を解明する。
- ソフトウェアチームと密接に連携を取る。
第8条および第9条の背後にある論理
この規格では、ハードウェアの安全性を測定するために、2つの異なる条項を使用しています。
- 第8条（ハードウェアアーキテクチャの指標）この条項では、単一障害指標（SPFM）と潜在障害指標（LFM）という2つのパーセンテージを使用して、ハードウェア設計と安全機構がランダムな物理的故障にどれだけ適切に対応できるかを測定します。
- 第9条（ランダムなハードウェア障害の評価）この条項は、全体的なリスクを評価します。数学的な確率計算（PMHF）またはカットセット分析を用いて、安全目標に違反するリスクが十分に低いかどうかを確認します。
2. ハードウェア安全要件（HSR）の設定
あなたの ハードウェア安全要件（HSR） システムレベルの技術安全要件（TSR）から直接導き出される必要があります。また、詳細な ハードウェア・ソフトウェア・インターフェース（HSI） 物理的な部品とコードがどのように相互作用するかを示す仕様書。
HSRは、以下の5つの主要分野を網羅する必要があります。
1) 内部障害制御
要件には、ハードウェアユニット内部の障害をどのように処理するかを明記する必要があります。これには、ウォッチドッグタイマーやタイマーなどのツールを使用して一時的な不具合（過渡的な障害）を検出する方法も含まれます。
2) 外部障害に対する耐性
ハードウェアは、基板外部で発生する障害にも耐えられる必要があります。例えば、外部の電子制御ユニット（ECU）が故障した場合、ECUの入力部は、断線や電源ライン（KL30）の短絡といった問題に対応できなければなりません。
3) ユニット間マッチング
安全要件が車内の隣接するハードウェアユニットの安全要件と一致し、適切に機能することを確認してください。
4) 故障検出と信号伝達
設計では、不具合を迅速に検知して報告する必要があります。一般的な物理的故障を検出するための要件を記述する必要があります。これには以下が含まれます。
- ピンを開く
- 接地短絡
- 電源への短絡
5) 設計検証ルール
HSRは、特定の安全機構に縛り付けるものであってはなりません。むしろ、後で設計を検証するために使用するルールを定義する必要があります。これらのルールには以下が含まれます。
- 環境的限界温度、振動、電磁干渉（EMI）。
- 運転条件電源電圧範囲と想定される耐用年数（ミッションプロファイル）。
- コンポーネント固有のルール特定のマイクロチップまたは電源ドライバに関する要件。
3. ハードウェア設計：アーキテクチャから回路図まで
ハードウェア設計は、全体像となるアーキテクチャから実際の回路図へと段階的に進んでいく。
全体像を捉えた建築
アーキテクチャ図には、すべてのハードウェアユニットとその接続方法が示されています。
- ASILの継承すべてのハードウェアユニットは、割り当てられた最高レベルの自動車安全完全性レベル（ASIL）の安全要件を満たさなければなりません。
- トレーサビリティは極めて重要である要件は、上位レベルのHSRから基板上の最小の機能回路ブロックまで追跡可能でなければなりません。この双方向のトレーサビリティは、ISO 26262とASPICEの両方における基本原則です。
- シンプルに設計上のミスを避けるためには、レイアウトをモジュール化し、ブロックのサイズを適切なものに保ち、不必要な複雑さを避けるようにしてください。
- 環境ストレス熱、振動、湿度、粉塵、車両の他の部品からの電気ノイズ（EMI）など、現実世界の要因を考慮する必要があります。これらの考慮事項は、設計検証計画（DVP）テスト（EMC、電気特性、ライフサイクル環境テスト）に含める必要があります。
詳細な回路図
回路図に線を描き始める際は、以下のルールに従ってください。
- 過去から学ぶ: 会社の安全文化に従い、過去のプロジェクトから得られた教訓を活用してください（ISO 26262-2:2018、5.4.7項を参照）。
- 身体への過度のストレスを防ぐ電気ノイズ、熱、湿気に耐えられるように回路を設計してください。
- 制限を守るすべての部品が規定された環境限界内で動作することを確認してください。
- 堅牢な手法を用いる信頼性の高い品質管理（QM）設計手法を採用する。これには、保守的な部品選定、部品の定格低下（部品を最大許容値以下で動作させること）、および最悪ケース回路解析（WCCA）が含まれる。
4. ハードウェアの安全性分析：障害の分類
ハードウェアが故障する可能性のある箇所を特定するには、安全性分析を実施する必要があります。この分析は、 ISO 26262-9:2011 条項 8。
この分析は、設計を早期に洗練させ、後で作業を検証するのに役立ちます。これは、 ASIL（B）、C、またはD。
安全分析では、以下の3種類の故障を検討する必要があります。
- 安全上の障害安全目標に直接違反しない不具合。
- 単点断層（SPF）／残留断層（RF）。
- 多点断層（MPF） （認識された欠陥、検出された欠陥、潜在的な欠陥を含む）。
ほとんどの実際のプロジェクトでは、マルチポイント分析を以下のように制限できます。 二点断層 （2つの独立した故障が同時に発生する場合）。2つの部品が故障する可能性のあるすべての組み合わせを分析する必要はありません。代わりに、一方の故障がコアハードウェア部品に影響を与え、もう一方の故障がその部品を保護するための安全機構を破壊するような組み合わせに焦点を当ててください。
単一点断層（SPF）
SPFとは、単一のハードウェアコンポーネントにおける物理的な故障であり、いかなる安全機構によっても検知されず、システムが安全目標に直接違反する原因となるものである。
ASIL（B）、C、またはDシステムに対して緩和されたSPFが存在することを証明するには、以下を示す必要があります。
- A) 信頼性の高い安全機構システムを安全な状態に保つ、または安全な状態に切り替えられる安全機構が備わっています。これはシステム内部で行われる必要があります。 フォールトトレラント時間間隔 (FTTI)。
- B) 高い診断カバレッジ診断ツールで検出できる残留故障の数を計算する必要があります。
SPF（特殊用途向け防爆構造）の主要設計ルール：
- FTTIルール診断テストの実行に時間がかかりすぎる場合、または安全機構の応答に時間がかかりすぎる場合、合計時間がFTTIよりも長くなると、その機構は無効になります。
- パワーアップチェック故障が起動時にしか検出できない場合は、運転を開始する前に、車両の電源が入った直後に自己診断テストを実行する必要があります。
- 分析ツール計算結果の妥当性を検証するために、故障モード影響解析（FMEA）またはフォールトツリー解析（FTA）を使用してください。
- 評価レベル使用する部品によっては、チップ全体を分析することも、個々のピンの故障モードを詳細に調べることもできます。
潜在的欠陥
潜在的故障とは、安全機構では検知されず、運転者も気づかないような、複数の箇所で発生する故障のことです。こうした隠れた故障は時間とともに蓄積され、別の箇所が故障した際に突然システム障害を引き起こす可能性があります。
潜在的な欠陥から保護したことを証明するには、以下を示す必要があります。
- A) ドライバーへの通知システムは最初の故障を検知し、2回目の故障が発生する前に許容可能な時間枠内でドライバーに警告を発することができる。
- B) 測定されたカバレッジ: これらの隠れた故障に対する診断範囲を評価し、計算する必要があります。
潜在的欠陥に対する主要な設計ルール：
- 診断テストの間隔と応答時間の合計が、マルチポイント故障検出のために定義された時間枠よりも長い場合、その故障は検出されていない（潜在的な）故障とみなされます。
- 定量的なFMEAまたはFTAを使用して、数理モデルを構築してください。
検証：3a/3bと1a/1bの関係
設計検証中は、標準的な方法 3aと3b これらは、環境および堅牢な設計原則に対する具体的なチェックとして機能します。これらを使用して、基本的な検証方法を補完および強化してください。 1aと1b。
5. ハードウェアアーキテクチャの指標と故障率
外部監査機関に対して設計の安全性を証明するには、そのアーキテクチャ指標を算出する必要があります。
故障率（FIT）データの入手先
故障率を捏造することはできません。故障発生時間（FIT）データは、以下の3つの情報源のいずれかから入手する必要があります。
出典1：業界標準
これは、部品の故障率を調べる最も一般的な方法です。以下の方法を使用できます。
- SN 29500 （シーメンス規格。自動車業界で広く使用されている。）
- IEC/TR 62380 または IEC 61709。
- MIL HDBK 217 F 通知 2 または RIAC HDBK 217。
- UTE C80-811。
- NPRD95。
- EN 50129:2003 附属書C または IEC 62061:2005 附属書D。
- RIAC FMD97 または MIL HDBK 338。
ソース2：現場からの返却データ
路上を走行する車両から得られる実際のデータを使用することもできますが、そのデータは高い信頼性レベルを備えている必要があります。
出典3：構造化された専門家の判断
データが存在しない場合は、工学専門家による体系的な評価を利用できます。その際、評価の根拠となった理由と基準を正確に記録する必要があります。
ASILレベルの指標目標
監査に合格するには、設計が以下の最低基準を満たしている必要があります。
| メトリック | アシルB | アシルC | アシルD |
|---|---|---|---|
| 単一点故障指標（SPFM） | $\ge 90\%$ | $\ge 97\%$ | $\ge 99\%$ |
| 潜在故障指標（LFM） | $\ge 60\%$ | $\ge 80\%$ | $\ge 90\%$ |
| ランダムハードウェア故障確率（PMHF） | $< 10^{-7} \text{ h}^{-1}$ (100 FIT) | $< 10^{-7} \text{ h}^{-1}$ (100 FIT) | $< 10^{-8} \text{ h}^{-1}$ (10 FIT) |
6. ループを閉じる：ハードウェアの安全性テスト
書類や計算だけに頼ってはいけません。残っている設計上の欠陥を見つけるには、実際にハードウェアをテストする必要があります。
安全機構を検証するために、以下の3つのテスト方法に基づいてテストケースを作成してください。
A. 機能テスト
このテストは、基板が通常の条件下で想定どおりに動作することを確認するものです。通常の入力を与え、出力が仕様と一致するかどうかを確認します。何か異常が見られた場合は、その原因を分析する必要があります。
B. 故障注入テスト
このテストは、問題が発生した際に安全機構が実際に機能することを証明します。基板に物理的な損傷を与えたり、故障をシミュレートしたり（例えば、ピンをグランドに短絡させるなど）、システムの反応を観察します。これは、安全装置の反応時間を検証する最良の方法です。
C. 電気試験
このテストでは、設計が動作電圧範囲全体にわたって検証されることを確認します。高電圧、低電圧、および急激な電圧スパイク条件下で基板を動作させ、安定性が維持されることを確認します。
環境ストレス試験
ハードウェアが外部からの物理的ストレスにどれだけ耐えられるかもテストする必要があります。これには、高振動テスト、温度サイクルテスト（極低温から高温まで）、および高電磁ノイズ（EMC）テスト中のボードの動作が含まれます。
最後に
機能安全は反復的なプロセスです。まず要件を定め、回路を設計し、FMEAと計算を用いて解析し、最後に物理的なテストで全てを検証します。テストで弱点が見つかった場合は、設計を修正し、再度テストを行います。このサイクルを繰り返すことで、真に安全で堅牢な車両を開発できるのです。
よくある質問
Q1：診断テストと安全対応に、耐障害時間間隔（FTTI）よりも長い時間がかかった場合はどうなりますか？
簡潔な回答安全機構は、システムを時間内に保護できないため、無効です。
詳細障害が発生し、診断に時間がかかりすぎると、安全機構が作動する前にシステムがクラッシュしたり、危険な動作をしたりする可能性があります。物理的な障害が発生した瞬間からシステムが安全な状態に達するまでの反応時間は、常にFTTI（故障検出時間）よりも短くなければなりません。
Q2：ISO 26262-5における3a/3b検証方法と1a/1b検証方法の関係は何ですか？
簡潔な回答方法3aと3bは、基本的な設計チェック1aと1bをサポートおよび強化するために使用する、具体的で的を絞ったチェックです。
詳細方法1a（環境限界の確認）と方法1b（定格低減やWCCAなどの設計ルールの使用）は、基本的な設計手法です。方法3aと方法3bは、検証の第2段階として機能します。これらは、特定の物理的故障箇所と環境条件に焦点を当て、初期設計で見落としがなかったことを確認します。
Q3：SN 29500規格がハードウェアの故障率を計算する際に広く用いられているのはなぜですか？
簡潔な回答自動車サプライチェーンにおいて、最も信頼され、広く受け入れられている故障率データベースです。
詳細MIL-HDBK-217FやIEC/TR 62380といった規格も有用ですが、シーメンスが開発したSN 29500は、最新のシリコンチップや受動部品の故障率を非常に現実的かつ最新の状態で提供します。これを使用することで、自動車メーカーやティア1サプライヤーが機能安全監査で期待する内容と計算結果の整合性を確保できます。