Dowway Vehicle の CEO である Johnny Liu 著
- 作者: Dowway Vehicle の CEO である Johnny Liu
- 公開: 2026 年 6 月 15 日
- カテゴリ: 自動車工学 / 機能安全 (FUSA)
簡単なお持ち帰り
ハザード分析とリスク評価 (HARA) は、ISO 26262-3 コンセプト フェーズの出発点です。 システム障害によって引き起こされる危険を発見し、次の 3 つのメトリックを使用してリスクを評価します。 重大度 (S)、 露出 (E)、および 制御性 (C). これらのスコアが組み合わさって、 自動車の安全性レベル (ASIL) QM から ASIL D まで。 電動パワーステアリング (EPS) 完全な監査対応のハラ ワークフローを表示するシステム。
Table of Contents
1. ハラの紹介 & ISO 26262 V モデルにおけるその戦略的位置
ステア バイ ワイヤやドライブ バイ ワイヤ プラットフォームなどの安全性が重要な車載システムを構築する場合、 ハラ (ハザード分析とリスク評価) あなたの最初の真のエンジニアリング ステップです。 これは、パート 3 (コンセプト フェーズ) の下で ISO 26262 V モデルの最上部に位置しています。 ハラは、単純でリスクの高い質問に答えます。
「システムの部品が故障した場合、車内外の人々にとってどれほど危険ですか?」
ハラは、製品の基本的なセットアップ間の技術的なブリッジとして機能します (アイテムの定義) と高度なエンジニアリング目標 (安全目標. はっきりとした原がなければ、下流のすべてが推測の仕事です。 どのような危険を止めようとしているのかわからない場合、適切な機能安全コンセプト (FSC) を構築したり、技術的安全要件 (TSR) を作成したりすることはできません。
ハラの主な出力は です ASIL (自動安全性レベル). ASIL A と ASIL D を単なる規制上の評価として扱わないでください。 これらの違いにより、開発ワークロード、タイムライン、予算が 10 倍に変わります。
- アシル A: 少し余分な事務処理を伴う標準的なエンジニアリング品質のセットアップが必要です。
- アシル D: ソフトウェア テストでは 100% MC/DC (修正条件/決定範囲)、ハードウェア レベルの障害トレランス (PMHF) を計算するための深度の定量的 FMEDA、およびハードウェア レベルのフォールト トレランス (ロックステップ プロセッサまたはデュアル パワー パスなど) が必要です。
ASIL を過小評価すると、車に危険なギャップが残ります。 それを過大評価すると、過剰なエンジニアリングに数百万ドルを浪費してしまいます。
2. ハラが機能的安全性において最も困難なステップである理由
ルールは紙の上では明確に見えますが、Hara は正しく理解するのが難しいことで知られています。 これは通常、3 つの特定のエンジニアリング フリクション ポイントで故障します。
I. ドライビング シナリオ トラップ: 多すぎるか少なすぎる
ISO 26262 では、運転状況の現実的なリスト全体で障害を確認する必要があると述べています。 しかし、現実世界には無限の道があります。 速度、ロード グリップ、天気、ドライバーの入力を永遠に混在させることができます。 チームは通常、次の 2 つの方向のいずれかで失敗します。
- スプレッドシートが爆発します。 エンジニアは何千もの小さなシナリオのバリエーションを記録し、大量の読み取り不可能なドキュメントを作成します。
- 盲点: エンジニアは、完璧な条件 (「晴れた日に乾いた高速道路をまっすぐ運転する」など) のみを書き留め、危険なエッジ ケースを見逃しています。
- これを解決する方法： 構造化された を使用します OEDR (動作環境と運転ルーチン) シナリオをグループ化し、シナリオを論理的に制限するためのチェックリスト。
II。 S/E/C 評価の人間の偏見
重大度 (S) は、実際の医療傷害尺度にリンクしていますが、 露出 (E) そして 制御性 (C) 非常に主観的です。 制御性 — 通常のドライバーが障害をどの程度うまく処理できるか – は、最も多くの議論を引き起こします。 同じチームの 2 人のエンジニアが同じ失敗を見て、C1 (扱いやすい) と C3 (非常に扱いにくい) の間で議論するのが一般的です。 これらのスコアは推測ではなく、数で接地する必要があります。
III. ゴースト欠陥ループ
ハラの間違いは沈黙している。 ハザードの段階でハザードを逃した場合、その安全目標は書きません。 安全目標がないため、テスト エンジニアはテスト ケースを作成しません。 お客様のシステムは、実験室で空飛ぶ色ですべての検証テストに合格しますが、顧客がそれを運転し始めると、それでも致命的な安全上の欠陥があります。
3. 段階的な ISO 26262 HARA ワークフロー (EPS ケーススタディあり)
標準的なハラの 6 つのステップを使用して説明しましょう。 電動パワーステアリング (EPS) 物理的な参照としてのシステム。
ステップ 1: アイテムの定義 (ベースラインの確立)
フリーズしたバージョン トラッキングなしでは、Hara を開始できません アイテムの定義. このドキュメントは、システムの境界を設定します。 システムの機能、物理的な制限、インターフェイス、速度範囲、および問題が発生した場合の動作を正確にリストする必要があります。
表 1: 項目定義 キー要素 & ハラ影響 (EPS の例)
| 次元 | EPS の特定のコンテンツ | 原への直接の影響 |
|---|---|---|
| 機能境界 | ステアリング トルク アシスタンス、アクティブ リターン、アクティブ ダンピング、レーンキーピング アシスト (LKA) インターフェイス。 | 検討中の障害モードの範囲を決定します。 |
| システムの境界と インターフェイス | 車速 (ABS/ESC から CAN-FD)、ステアリング ホイール角度 (SAS から)、電源 (12V/48V)。 | EPS に伝播する可能性のある外部信号障害を識別します。 |
| 操作条件 | 高速、低速、パーキング アシスト、リバース ギア、ヒル アシスト。 | シナリオ マトリックスの基本的な次元を確立します。 |
| 環境条件 | 動作温度 ($-40^\circ\text{c}$ から $+85^\circ\text{c}$)、湿度、振動プロファイル、EMC 制限。 | 外部環境ストレッサーのエクスポージャー (e) 評価に影響を与えます。 |
| 機能上の制限 | 最大アシスト トルク (例: $80\text{ nm}$)、LKA 介入の最大車両速度。 | 意図しないシステム動作の物理的な境界制限を設定します。 |
ステップ 2: 運用シナリオの識別 (OEDR マトリックス)
アイテム定義の操作条件と環境条件を使用して、シナリオのマトリックスを構築します。 使用 OEDR (動作環境と運転ルーチン) このステップを構成する方法。
表 2: 運用シナリオのディメンション マトリックス
| 次元 | 分類値 | 典型的なエンジニアリング シナリオ |
|---|---|---|
| 車速 | 非常に低い ($<5\text{ km/h}$)、低い ($5-30\text{ km/h}$)、ミッド ($30-80\text{ km/h}$)、高い ($>80\text{ km/h}$)。 | 駐車場、都会的なストップ アンド ゴー、田舎の運転、高速道路のクルージング。 |
| 道路の摩擦 ($\mu$) | 高摩擦 ($\MU \約 1.0$)、中低 (ウェット/アイス、$\MU \LE 0.3$)、非アスファルト。 | 乾いたコンクリート、大雨、黒い氷、砂利道。 |
| 運転操作 | 直線運転、車線変更、カーブ/ターン、緊急回避。 | ハイウェイ クルージング、高速道路出口ランプ、都市交差点のターン。 |
| 道路カテゴリ | 高速道路、都市幹線道路、田舎道、駐車場。 | 制御アクセス高速道路、交差点、単車橋。 |
ステップ 3: ハザード イベントの識別 (失敗モードとシナリオ)
次に、E/E システムのコア障害モードをシナリオ マトリックスにマッピングします。 評価する標準的な障害モードは次のとおりです。
- 機能の喪失 (システムが完全に動作しなくなります)
- 部分関数 (システムのパフォーマンスが低下します)
- 意図しないアクティベーション （システムがオフのときにオンになります）
- 不正確/逆関数 (システムはドライバーの意図とは反対に機能します)
- スタック/ロック機能 (システム出力がフリーズする)
私たちの EPS にとって、これらの失敗は特定の危険に変わります。 この構造を使用して、すべてのハザード ステートメントを記述します。 「いつ[Scenario]、原因[Failure Mode]、[Hazardous Event]が発生し、につながります[Vehicle-Level Harm]」
表 3: EPS 代表のハザード イベント
| id | システム障害モード | 運転シナリオ | 車両レベルのハザード &; 害 |
|---|---|---|---|
| H-01 | ステアリング アシスタンスの完全な損失。 | 高速 ($>80\text{ km/h}$) 高速道路のカーブ。 | ドライバーの努力が急激に急上昇。 車両はカーブを維持できません。 車線の出発/衝突。 |
| H-02 | 意図しない逆アシスト トルク。 | 高速 ($>80\text{ km/h}$) まっすぐなクルージング。 | 左/右への突然の予想外の引っ張り。 車両は対向車線に入ります。 ロールオーバー/正面衝突。 |
| H-03 | 意図しないセルフステアリングのアクティベーション。 | 低速 ($<5\text{ km/h}$) パーキング アシスト。 | EPS はステアリング ラックを最大ロックするように命令します。 近くの歩行者/車両との衝突。 |
| H-04 | ステアリング ラック/カラム ロック (スタック)。 | 中速 ($30-80\text{km/h}$) 車線変更。 | ハンドルを回すことはできません。 横方向にロックされた車両。 側面衝突衝突。 |
ステップ 4: S/E/C 評価 & 定量的ガイドライン
コア リスク評価は、重大度 ($S$)、エクスポージャー ($E$)、および制御可能性 ($C$) の 3 つのパラメーターの評価で構成されています。
I. 重大度 ($S$)
これは、危険の最悪の場合に人がどれほどひどく傷ついているかを評価します。 それは医療にマッピングされます AIS (短縮傷害尺度)。
- S0 (怪我なし): 身体に害はありません。
- S1 (ライト/中程度): 単純な切り傷、擦り傷、または軽度のあざ。
- S2 (重度/生命を脅かす): 深い傷、骨折。 生存率は非常に高いです。
- S3 (致命的/重大): 生命を脅かす怪我、器官の重大な損傷。 生存は不確かです。
II。 エクスポージャー ($e$)
これは、ドライバーが特定の運転シナリオで費やす時間を評価します。
- E1 (非常に低い): まれな状況 (異常気象や非常に特殊なオフロード トラックなど)。
- E2 (低): 年に数回しか発生しません。
- E3 (中): 毎週または毎月発生します (高速道路の追い越しなど)。
- E4 (高): ほぼすべてのドライブの一部 (標準の道路速度や通常のターンなど)。
III. 制御性 ($c$)
これは、通常のドライバーが事故を回避するために行動を起こすことができるかどうかを評価します。
- C0 (制御可能): 扱いやすい。 危険を引き起こしません。
- C1 (簡単に制御できます): ドライバーの 99% 以上が簡単に車を安全に保つことができます。
- C2 (通常制御可能): ドライバーの 90% から 99% は、通常の入力で障害を処理できます。
- C3 (制御が難しい): ドライバーの 90% 未満で事故を防ぐことができます。
? 制御性のための実際のエンジニアリング ルール: 監査に合格するには、C レーティングを推測しないでください。 でそれらを接地します ドライバーの反応時間. 調査によると、警告されていないドライバーは take を示しています 0.6 秒から 0.8 秒 予期しないステアリングの変更に対応するため。
- EPS の故障 ($H-02$、意図しないリバース トルクなど) が原因で、車が車線から出る原因となります。 0.5 秒未満、ドライバーには修正するための物理的な時間がありません。 これは明確です C3。
- パスの偏差がかかる場合 2.0 秒以上、通常のドライバーには、カウンターステアまたはブレーキをかけるのに十分な時間があります。 を正当化できます C1 又は C2 ここで評価します。
表 4: S/E/C 評価基準の定義 & キャリブレーション データ
| 次元 | クラス | 定義 | 定量的/経験的キャリブレーション アンカー |
|---|---|---|---|
| S | S3 | 致命的/重大な怪我 | AIS 5-6 (生存確率 $<90\%$、重度の脊椎/頭部外傷) |
| S2 | 重度/生命を脅かす | AIS 3-4 (重度の骨折、臓器の裂傷、生存率が高い) | |
| S1 | 軽い/中程度 | AIS 1-2 (むち打ち症、軽度の骨折、短期入院) | |
| s0 | 怪我はありません | AIS 0 (生理学的損傷なし、標準の小さな隆起) | |
| え | E4 | 高い確率 | $>10\%$ の平均運転運転時間で遭遇したシーン |
| E3 | 中程度の確率 | $1\% – 10\%$ で発生したシーンが運転運転時間の | |
| E2 | 低確率 | $0.1\% – 1\%$ で発生したシーンが運転運転時間 | |
| E1 | 非常に低い確率 | 運転時間の $<0.1\%$ で遭遇したシーン | |
| C | C3 | 制御が難しい | リアクション ウィンドウ $<0.6\text{ 秒}$; 非常に熟練したレースドライバー操作が必要です |
| C2 | 通常は制御可能です | リアクション ウィンドウ $0.6 – 1.2\text{ 秒}$; 標準的なカウンター ステアリングまたはブレーキングにより、衝突を回避できます | |
| C1 | 簡単に制御できます | リアクション ウィンドウ $>1.2\text{ 秒}$; スロットルの簡単な解放または軽度のブレーキングにより、危険を回避できます | |
| C0 | 完全に制御可能 | 標準の自動シャーシ制御 (パッシブ メカニカル リンクなど) を介して安全に処理 |
ステップ 5: ASIL の決定
ここで、標準の ISO 26262 マトリックスを使用して、S、E、および C スコアに基づいて ASIL レベルを見つけます。
表 5: ISO 26262 ASIL 決定マトリックス
| 重大度 (S) | 露出 (E) | 制御性 C1 | 制御性 C2 | 制御性 C3 |
|---|---|---|---|---|
| S1 | E1 | QM | QM | QM |
| E2 | QM | QM | QM | |
| E3 | QM | QM | QM | |
| E4 | QM | QM | asil a | |
| S2 | E1 | QM | QM | QM |
| E2 | QM | QM | asil a | |
| E3 | QM | asil a | アシル B | |
| E4 | asil a | アシル B | アシル C | |
| S3 | E1 | QM | QM | asil a |
| E2 | QM | asil a | アシル B | |
| E3 | asil a | アシル B | アシル C | |
| E4 | アシル B | アシル C | アシル D |
ステップ 6: 安全目標の策定
ハラの最終出力は、 安全目標 (SGS). ASIL 評価 (ASIL A から D) のすべてのハザードには、少なくとも 1 つの安全目標が必要です。
役に立つためには、安全目標が 4 つのルールを満たしている必要があります。
- 検証可能である必要があります。 彼らのために明確な合格/不合格テストを書くことができます。
- 明確な制限がある必要があります。 それらが適用される特定の速度、力、または時間を述べます。
- ASIL レベルを表示する必要があります。 危険から直接受け継いだ。
- FTTI を定義する必要があります。 を指定します フォールト トレラントの時間間隔。
フォールト トレラント時間間隔 (FTTI) は? FTTI は、電気障害が発生してからシステムが正常に入力されるまでの最大時間です。 安全な状態. システムが FTTI よりも障害を特定するのに時間がかかると、車両は制御不能な状態になります。
表 6: EPS の安全目標と FTTI の割り当て (ハラに由来)
| 参照 | 安全目標 (SG) | 継承された ASIL | 定義された安全状態 | フットティ |
|---|---|---|---|---|
| SG-01 | EPS は、車速 $V > 30\text{km/h}$。 | アシル D | フェイルセーフへの移行: すぐにステアリング パワー ステージを無効にします。 モーター アシストをカットします。 純粋なメカニカル ステアリングに戻ります。 | $< 100\text{ ms}$ |
| SG-02 | EPS は、ドライバーのステアリング入力なしで、意図しないステアリングの自己作動を防止するものとします。 | アシル D | ステアリング パワー ステージを無効にします。 物理安全リレーを開きます。 インストルメント クラスターを介してドライバーに通知します。 | $< 200\text{ ms}$ |
| SG-03 | EPS は、車両の衝突を防ぐために、パーキング アシスト モード ($v < 10\text{ km/h}$) 中の最大セルフステア トルクを制限するものとします。 | asil a | モーター相電流をキャップに制限して、機械トルク出力を $< に制限します。 5\text{ nm}$. | $< 500\text{ ms}$ |
4. EPS ケース スタディ: ASIL ダイバージェンス分析
機能安全における最も重要な概念の 1 つは、 ASIL はシステムの所有物ではありません。 これは、特定の危険シナリオの特性です. まったく同じ EPS ハードウェアを含む 2 つの異なる状況を見てみましょう。
ケース A: EPS 高速コーナリング中のアシストの完全な損失 ($H-01$)
- シナリオ: $>80\text{ km/h}$ の鋭いハイウェイ ランプで運転します。
- 失敗: EPS モーター コントローラが燃え尽き、ステアリング アシストはすぐにゼロになります。
- リスク評価:
- 重大度 ($S3$)): 高速での急なターン中にアシストが低下した場合、ドライバーは突然大きな力を加えて車を車線に保つ必要があります。 失敗すると、車は道路から出ます。 これは、致命的な事故 ($S3$) に簡単につながる可能性があります。
- 露出（$E4$)): スロープでの運転は、高速道路のドライバーが毎日行うことです ($E4$)。
- 制御性 ($C3$)): ドライバーが積極的に回転していると、アシストが即座に低下するため、反応ウィンドウは小さくなります。 通常のドライバーは、車線 ($C3$) にとどまるのに十分な速さで高い修正力を加えることはできません。
- ASIL 結果: $$\text{s3} + \text{e4} + \text{c3} \longrightarrow \mathbf{asil\ d}$$
ケース B: 低速駐車時の EPS 意図しないセルフステアリング ($H-03$)
- シナリオ: $<5\text{km/h}$ を駐車場で運転しています。
- 失敗: EPS コントローラーにはメモリ エラーがあり、左に全速力で操舵トルクを命令します。
- リスク評価:
- 重大度 ($S2$)): 歩行速度では、柱や別の車に衝突すると構造的な損傷が生じる可能性がありますが、誰かを殺す可能性はほとんどありません ($S2$)。
- 露出（$E3$)): ドライバーは毎日車を駐車しますが、アクティブなシステム エラーが発生している間に駐車する場合は、時間比 ($e3$) で適度に低くなります。
- 制御性 ($C1$)): 低速では、車はほとんど勢いがありません。 不意にホイールが回転しても、ドライバーは簡単にブレーキ ペダルを踏んで車を止めることができます。 反応ウィンドウが広い ($c1$)。
- ASIL 結果: $$\text{s2} + \text{e3} + \text{c1} \longrightarrow \mathbf{asil\ a}$$
表 7: EPS ハザード イベントの比較分析と ASIL 出力
| id | ハザード イベント | の評価 | e 評価 | C評価 | 最後の ASIL | ASIL 評価の支配的な原動力 |
|---|---|---|---|---|---|---|
| H-01 | 高速アシストの突然の損失 | S3 | E4 | C3 | アシル D | 極端な速度、ゼロの反応ウィンドウ、横加速度。 |
| H-02 | 高速の意図しないリバース アシスト | S3 | E4 | C3 | アシル D | 速度での直接アクティブなパスの偏差は、本質的に致命的です。 |
| H-03 | 低速の意図しないステアリング | S2 | E3 | C1 | asil a | 運動エネルギーが低い。 ドライバー ブレーキは、ステアリング パスを簡単に上書きします。 |
| H-04 | 中速車線変更ロックアップ | S3 | E3 | C2 | アシル C | 中間露出; ドライバーはブレーキをかけてパスを制御できますが、パスはロックされています。 |
5. Hara の 5 つの一般的なエンジニアリングの落とし穴 (およびそれらを防ぐ方法)
ダウウェイ ビークルでのシャシー エンジニアリングを何年にもわたってリードしてきましたが、ハラスを書くときにエンジニアリング チームが陥る 5 つのよくある罠を私は見てきました。
落とし穴 1: 悪天候と厳しい道路状況を除外する
多くのチームは、完璧な状態のシナリオを作成します。乾いた、晴れた、通常は積載された車です。 彼らは、悪天候では失敗が異なる振る舞いをすることを忘れています。
- リスク: 凍結道路でのステアリング ロックアップ ($\MU \LE 0.15$) を評価しないと、タイヤが牽引力を失うとステアリングの制御性が完全に変化するという事実を見逃してしまいます。
- 修正: OEDR テンプレートに悪天候チェックを追加します。 チームに、ウェット、アイス、オーバーロードの条件下ですべてのハザードを評価するよう強制します。
落とし穴 2: 制御性 ($c$) に「ガット フィール」を使用する
エンジニアは、最終的な ASIL 評価を $QM$ または $ASIL\ A$ に下げるために、ハザードに $C1$ または $C2$ を与えることがよくあります。 これにより、後で開発作業が保存されます。 彼らは次のような怠惰な正当化を書いています。
- リスク: プロの安全監査人は、これをサポートされていない仮定として直ちにフラグを立て、あなたの認証を拒否します。
- 修正: 重大な障害に対する $C1$ または $C2$ の評価は、データに裏打ちされている必要があるというルールを作成します。 ドライビング シミュレータ レポート、追跡テスト、または公開されたドライバーの反応調査を使用します。 難しい数字がない場合は、$C3$ として書き留める必要があります。
落とし穴 3: 漠然とした安全目標を書きます
「ステアリング システムは常に安全である必要があります」などの空のステートメントを書くことは役に立ちません。
- リスク: テスト エンジニアは、「安全であること」のため、物理的な合格テストを構築することはできません。
- 修正: すべての安全目標には、明確で測定可能な制限が必要です。 安全と見なされるためには、システムが満たされている必要がある正確な力、速度、または時間を述べてください。
落とし穴 4: ASIL 分解後のトレーサビリティの破損
ISO 26262 では、高レベルの安全要件を 2 つの低レベルの冗長要件 (たとえば、ASIL D 目標を 2 つの ASIL B(D) パスに分割する) に分割できます。 多くの場合、チームは紙の上でこれを行いますが、要件追跡ツール (JAMA やドアなど) のリンクを更新するのを忘れています。
- リスク: 後の設計更新中に、エンジニアは、ASIL D の全体的な安全性の前提を破っていることに気付かずに、冗長パスの 1 つを変更する可能性があります。
- 修正: 必要な管理ソフトウェアを使用して、ハザードからソフトウェア テスト ケースに至るまで、厳密で途切れのないリンクを強制します。
落とし穴 5: 「メールによるレビュー」トラップ
ハラはプロジェクトの早い段階で発生するため、安全管理者はオフィスでスプレッドシート全体を作成し、200 行のファイルを電子メールでハードウェア、ソフトウェア、およびテスト リードに電子メールで送信して、簡単なデジタル署名を得ることがよくあります。
- リスク: $100\text{ ms}$ ftti の制限に達することができないことに気付かないうちに、ソフトウェア リードはそれに署名します。 テスト リードは、故障をシミュレートするラボ機器がないことに気付かずに署名します。
- 修正: ライブの対面的なハラ レビュー ワークショップを義務付けます。 ハードウェア、ソフトウェア、システム、およびテスト リードがすべての行を一緒に処理するまで、Hara ベースラインをロックすることはできません。
表 8: ハザード & 緩和行列
| 落とし穴 | 核となる脅威 | コンクリート エンジニアリング ソリューション |
|---|---|---|
| #1 | シナリオ省略 | 低摩擦、高負荷、夜間シナリオを含む OEDR チェックリストを義務付けます。 |
| #2 | 主観的な C 評価 | すべての C1 および C2 クレームについて、経験的なドライバー反応統計が必要です。 |
| #3 | あいまいな安全目標 | 「検証可能性ルール」の適用: SGS は、バイナリ パス/失敗基準によってテストできる必要があります。 |
| #4 | 分解されたトレーサビリティ | ASIL タグの検証を使用して、JAMA/DOORS にエンドツーエンドのデジタル スレッドを実装します。 |
| #5 | メール サインオフ サイロ | ログに記録されたエンジニアリング アクション アイテムを使用して、機能横断的なインタラクティブなハラ ワークショップを実施します。 |
6. 監査の準備: TüV/SGS 評価を生き残る
サードパーティの安全監査人があなたのハラをチェックすると、最終的なスコアだけでなく、エンジニアリング ロジックも調べます。 彼らが尋ねる5つの質問は次のとおりです。
Q1: 「ハラがアイテム定義の正確な現在のバージョンにマッピングされていることをどのように保証しますか?」
- 直接の答え: トラッキング システムで、まったく同じリリース ID で両方のファイルをロックします。
- 詳細な説明: これにより、開発者が設計変更を行うときに、HARA が実際の車両アーキテクチャから離れるのを防ぎます。 当社の構成管理プロセスでは、アイテム定義を変更すると、自動的にレビューのために Hara にフラグが設定されるようにする必要があります。
Q2: 「どのような経験的データを使用して、[Hazard X]C3 ではなく C1/C2 として?」
- 直接の答え: 50 個のアラートされていないテスト ドライバーを含む、ドライバー内シミュレータ テスト ログを使用しました。
- 詳細な説明: C2 の評価を証明するために、テスト グループの $96\%$ がターン中に故障したときに車両を車線に維持し、平均 $0.85\text{}$ 以内に反応したことをテストしました。 主観的な「エキスパート ドライバー」の意見が評価を設定することは許可されていません。
Q3: 「あなたの Hara レビューに参加したのは誰で、アクション アイテムの解決ログはどこにありますか?」
- 直接の答え: ハードウェア、ソフトウェア、システム、テスト、および安全性からリードする物理的なワークショップを開催しました。
- 詳細な説明: すべての会議メモ、サインオフ、および未解決の問題は、プロジェクト追跡ツールに保存されます。 「メールによるレビュー」は許可されていません。 すべてのアクション アイテムの歴史と、安全目標を承認する前にどのように解決されたかをお見せできます。
Q4: 「運転のシナリオが完全で、重要な問題のケースを省略していないことを確認するために、どのような方法論を使用しましたか?」
- 直接の答え: ISO 26262-3 Annex B のシナリオ リストに基づいて構築された構造化された OEDR フレームワークを使用しました。
- 詳細な説明: 車速、路面グリップ、ドライバー操作、道路タイプのすべての組み合わせを体系的にチェックしました。 これにより、便利で解決しやすい運転状況を選択しただけではありません。
Q5: 「フィールドに戻された問題とその後の設計変更は、このハラを更新するためにどのようにマッピングされますか?」
- 直接の答え: すべてのデザインの更新またはフィールドの問題は、最初に正式な安全性への影響分析を行う必要があります。
- 詳細な説明: 変更がシステムの境界、パフォーマンスの制限、または障害の動作に影響を与える場合、変更管理ツールは自動的にタスクを開き、ハラを更新して再検証します。
表 9: TÜV/SGS HARA アセスメント チェックリスト & 証拠マップ
| 監査人の挑戦のテーマ | コンプライアンスの根底にある意図 | 必要な工学的証拠資料 |
|---|---|---|
| ベースラインを入力します | 入力の整合性と検証 一貫性。 | ドキュメント ID リンク、ロックされたアイテム定義ベースライン、一致する変更履歴の日付。 |
| 客観性の評価 | 不当な「ASIL ダウングレード」を探しています。 | ヒューマン ファクター テスト レポート、ドライビング シミュレーター トライアル ログ、公開された学術的安全性統計 |
| チームの能力 | 機能横断的な表現の確認。 | 会議の議事録、記録されたアクション アイテム、エンジニア トレーニング & 能力記録。 |
| 完全 | 重大なシナリオの省略を確実にします。 | 完成した OEDR チェックリスト、HAZOP テーブル、FMEA 境界図。 |
| ライフサイクル統合 | 継続的な安全管理を確認します。 | 変更要求フォーム、ハラ改訂履歴ログ、影響分析レポート。 |
7. 世界クラスの機能安全チームのプロフィール
安全な車両を製造するには、誠実さと技術的な深さを重視するエンジニアリング文化が必要です。 最高の安全チームは、いくつかのコア特性を共有しています。
- 最初にアイテム定義をフリーズします。 彼らはハラに突入しません。 1 つのハザード行を作成する前に、インターフェイス、信号、および物理的な制限をマッピングするために必要な数週間を費やします。
- 彼らは技術的な議論を奨励しています。 彼らは簡単な合意を求めていません。 開発者がシステム エンジニアに挑戦し、安全管理者に質問するテスト リードを歓迎します。 外出先での安全リコールよりも、会議室で厳しい議論をする方がはるかに良いでしょう。
- オフライン シートではなく、統合データベースを使用します。 スプレッドシートは使いやすいですが、トップ チームは、接続された ALM ツールで安全データを管理します。 これにより、ハザードが変更されると、リンクされたすべての要件とテスト ケースが自動的に更新されます。
- これらは、失敗操作の動作のためにビルドします。 ステア バイ ワイヤのような重要なシステムの場合、障害が発生したときにシャットダウンするだけではありません。 それらは冗長な電力、通信、および制御経路を設計するため、主要なコンポーネントが故障した後でも車両が安全に操縦できるようになります。
8. 締めくくりの考え: ハラは資産であり、プロセスの負担ではありません
ハラを監査人を満足させるための行政演習として扱わないでください。 正しく行われた場合、Hara は強力なシステム エンジニアリング ツールです。 これにより、設計上の欠陥を早期に発見し、開発費を抑え、車を運転する人の命を保護します。
物理的なドライバーの反応データに S/E/C 評価を固定し、構造化されたシナリオ テンプレートを使用して現実世界をカバーし、要件を完全にリンクしたままにすることで、最初の試行で監査に合格する安全で信頼性の高いシステムを構築できます。