小説で学ぶ自動車ソフトウェア開発 (その5) ISO26262とASIL
前回までのA-SPICE編では、自動車ソフトウェア開発における「プロセス」の重要性を見てきた。要求を決め、設計し、実装し、検証し、そのすべてを後から追跡できるようにする。A-SPICEは、そうした開発の進め方そのものを評価するための、車載開発の"OS"だった。
今回からは、Part 2として 機能安全――ISO 26262とASILの世界 に入る。
A-SPICEが「良いプロセスで品質を作り込む」ための考え方だとすれば、ISO 26262は「たとえ故障しても、人を傷つけない」ための考え方である。車のECUは壊れる。センサーは誤る。メモリは化ける。だからこそ、自動車のソフトウェアは、故障しないことを祈るのではなく、故障する前提で設計されなければならない。
主人公の成田剛志は、安全認証担当の中月さんとの対話を通じて、HARA、ASIL、フェイルセーフ、フォールトトレランス、FMEA、FTAといった、機能安全の中核に触れていく。ここから先は、「正しく動くソフトウェア」だけでなく、「壊れたときにも人を守るソフトウェア」の物語である。
Part 2 機能安全 ―― ISO 26262とASILの世界
「故障で人が死ぬ」──
この恐怖を数式と設計で克服しようとした人たちの、 真剣な技術の物語。
第19章 「故障は、する前提で設計しろ」
FSAFE.001：機能安全とは何か ― ISO 26262の基本
アセスメントが終わって二週間後、僕は初めて中月さんの机の前に呼ばれた。
中月 薫さん。59歳。安全認証担当のシニアエンジニア。机の上には分厚い英語の規格書が積まれていて、灰色のカーディガンにはコーヒーの染みがあって、話し方は無駄がなく、声は低くて静かだった。A-SPICEの藤谷さんが「プロセス番長」なら、中月さんは「安全番長」という感じの人だった。
「成田くん、カイトのSWE担当だな」
「はい」
「SWE.3から5だったか。自動運転ドメインECUのソフトウェア、一部だな」
「はい。センサーフュージョンの周辺と、コンポーネント統合テストを担当しています」
中月さんは頷いた。それから、机の上の一冊の本を取り出した。赤い表紙に「ISO 26262-1:2018」と書かれている。
「今日から機能安全の話に入る。まず聞く。機能安全って何か知ってるか？」
「え、えっと......」僕は少し考えた。「安全に動くための機能、ですか？」
「逆だ」
「逆？」
「機能安全は、"機能の安全" じゃない。"機能の誤動作による危険の排除" だ。定義は、"E/Eシステムの誤動作に起因する不合理なリスクの不在"。つまり、電気・電子システムが壊れたり誤った動作をしたりしても、その結果として人が死なないようにする、ということだ」
「"正しく動いている" 状態の話じゃなくて、"壊れたとき" の話？」
「そう。車のECUは必ず壊れる。部品の寿命がある。電磁ノイズを受ける。高温にさらされる。メモリが化ける。そういうことが、10年、20年の使用期間中に必ず起きる。だから機能安全の鉄則はこうだ」
中月さんはホワイトボードに太いマーカーで書いた。
「故障は、する前提で設計しろ」
「故障したとき、車がどう振る舞うかを、設計の段階から決めておく。それが機能安全の出発点だ」
「ISO 26262は2011年初版、2018年改訂の国際規格。2011年の初版は乗用車（車両総重量3.5t以下）のE/Eシステムが対象だった。2018年の第2版で適用範囲が拡張されて、トラック・バス・モーターサイクル（Part 12）などにも届くようになった」
「全部で12のPartに分かれてる」と中月さんは続けた。
Part 1：語彙定義
Part 2：機能安全マネジメント
Part 3：コンセプトフェーズ
Part 4：システムレベル
Part 5：ハードウェアレベル
Part 6：ソフトウェアレベル
Part 7：生産と運用
Part 8：支援プロセス
Part 9：ASIL指向と安全指向分析
Part 10：ガイドライン
Part 11：半導体向けガイドライン
Part 12：オートバイ向け適応
「このうち、成田くんが主に関わるのはPart 3（コンセプトフェーズ）、Part 4（システム）、Part 6（ソフトウェア）、Part 8（支援プロセス）だ。Part 4とPart 6は、A-SPICEのSYS群とSWE群にほぼ対応する」
「つまり、A-SPICEとISO 26262は同じV字の上で動くんですね」
「そうだ。A-SPICEが"全体のプロセス"を定義し、ISO 26262がその中の"安全関連部分"を強化する。重なるところは多い。A-SPICEのSWE.1相当のことをPart 6の安全要求導出でもやる。A-SPICEのSWE.4相当のことをPart 6のソフトウェア単体テストでもやる。違いは、安全に関連する活動に追加の制約と証拠が要求されること」
用語
機能安全（Functional Safety）：E/Eシステムの誤動作（ランダムハードウェア故障・系統的故障）によって引き起こされる不合理なリスクの不在。ISO 26262が定義する概念。「壊れたとき人が死なない」ための工学体系。「壊れていないのに危険」はSOTIF（ISO 21448）が扱う。
「もう一個、大事な区別を言う。"ランダムハードウェア故障"と"系統的故障"の違いだ」
「ランダム故障は、部品の確率的な劣化。どのトランジスタが何時間後に壊れるかは確率でしか言えない。これに対しては、設計で冗長化し、確率を計算で保証する」
「系統的故障は、設計ミスやプロセスエラーから来る故障。コードのバグ、要求の誤解、試験の抜け漏れ。これは確率では扱えない。だから、"体系的なプロセス"で減らす。A-SPICEがここに効いてくる」
「つまり、A-SPICEは系統的故障を減らすための手段でもあるんですね」
「その通りだ。機能安全とA-SPICEが兄弟規格と呼ばれる理由の一つがこれだ」
その日のノート。
剛志のノート（19）
・機能安全＝E/Eシステムの誤動作による不合理なリスクの不在。壊れたとき人が死なないための工学。
・鉄則：「故障は、する前提で設計しろ」
・ISO 26262は2018年改訂。12 Partで構成。SWEエンジニアが関わるのはPart 3/4/6/8。
・ランダム故障（確率的、冗長化で対処）vs 系統的故障（設計ミス、A-SPICEで対処）。
・A-SPICEは系統的故障を減らす手段でもある。だから"兄弟規格"。
第20章 ハザードを洗い出す ―― HARAの一日
FSAFE.002：ハザード分析とリスクアセスメント（HARA）
翌日の朝、中月さんが「今日はHARAをやる」と言った。「ハラ」と読む。Hazard Analysis and Risk Assessment、ハザード分析とリスクアセスメント。
会議室には中月さんと僕のほか、カイトの安全チームのメンバーが5人集まっていた。A3の大きな紙がテーブルに広げられていて、いくつかの列が引かれていた。太田さんも来ていた。「俺、組込みはわかるんですけど、安全分析は初めてで」と小声で言った。「俺も」と僕は返した。
そして、中月さんの隣に、もう一人いた。渡会 良吉さん（44歳）だ。無口で、会議室に入るなりホワイトボードの前に立ち、無言で何かを書き始めていた。HARA・FMEA・FTAの実務エキスパートで、中月さんの右腕----そう後で聞いた。
「渡会さん、成田くんに軽く説明してもらえますか」と中月さんが言った。
渡会さんは振り向かなかった。ただ、ホワイトボードのマーカーを動かす速度がわずかに上がった。数十秒後、彼は振り返って、ボードを指差した。そこにはすでに、HARAの骨格が表になって描かれていた。
「......これが、今日やること、ですか？」と僕は恐る恐る聞いた。
渡会さんは小さく頷いた。それだけだった。
----この人、喋らないんだ。でも、図で全部言っている。
「アイテム」「機能」「ハザード」「動作状況」「S」「E」「C」「ASIL」「安全目標」
「成田くん、HARAは機能安全の一丁目一番地だ。開発の最初の段階で、"どんな危険が起きうるか"を全部洗い出して、その危険がどれくらい深刻かをアセスメントする。その結果として、ASILが決まる」
「ASILは次の章で詳しくやるが、今日は流れを見てほしい」
中月さんは例として、カイトのブレーキ制御システムを取り上げた。
「まず、アイテムを決める。今日は"前方衝突被害軽減ブレーキシステム（AEBS）"。これがカイトの主要な安全機能の一つだ」
「次に、このシステムの機能を列挙する」
機能①：前方車両を検知して衝突リスクを判定する
機能②：衝突リスクがあれば警報を出す
機能③：衝突リスクが高ければ自動的にブレーキをかける
「次に、各機能のハザードを考える。ハザードとは、"この機能が誤動作したら何が起きるか"だ。誤動作には二種類ある。"動くべきときに動かない（機能喪失）"と、"動くべきでないときに動く（不意動作）"」
「機能③のブレーキ自動介入なら――」
ハザードA：衝突リスクがあるのに自動ブレーキが効かない（機能喪失）
ハザードB：衝突リスクがないのに自動ブレーキが作動する（不意動作）
「どちらも危ない。Aは前の車に追突する。Bは後続車に追突される」
「次に、この二つのハザードを、S・E・Cの三つの指標で評価する」
中月さんはホワイトボードに三列の表を書いた。
S（Severity）：危害の深刻度
S0：ケガなし
S1：軽傷（入院不要）
S2：重傷（生命の危機ではない）
S3：生命の危機、または死亡
E（Exposure）：危険状況への暴露頻度
E0：ほぼ発生しない（ASIL算定では考慮しない扱い）
E1：非常にまれ（年1回未満レベル）
E2：まれ（年に数回程度）
E3：中程度の頻度（月に数回程度）
E4：高頻度（ほぼ毎日／日常的に遭遇する状況）
C（Controllability）：ドライバーが危険を回避できる程度
C0：誰でも制御可能
C1：大半のドライバーが制御可能
C2：一部のドライバーが制御可能
C3：制御困難（ほぼ制御不能）
「では、ハザードAを評価しよう。高速道路を走行中に前方で急停車があり、自動ブレーキが効かなかった場合を想定して」
「Sは？ 前の車に100km/hで追突したら」
「S3ですね。死ぬかもしれない」と僕は言った。
「そう。S3。Eは？ 高速道路で前方の急停車に遭遇する頻度は？」
「年に何回かはありますね。E2かE3？」
「今回はE3にしておこう。Cは？ 前方で急停車が起きたとき、ドライバーは自分でブレーキをかけられるか？」
「状況によりますが......高速だと反応時間が短い。C3、難しいケースも多い」
「その通り。C3。S3、E3、C3。これをASIL決定表に当てはめると――」
中月さんはASIL決定表を見せた。S・E・Cの組み合わせに対して、QM/A/B/C/Dが対応していた。
「S3、E3、C3で、ASILは――？」
「Dですね」と僕は指で表をたどった。
「ASIL Dだ。最高レベル。これが、"前方衝突被害軽減ブレーキが効かなかった"という機能喪失に対する安全度要求になる」
「ASIL Dって、どれくらい厳しいんですか？」
「極端に言えば、MCUのPMHF（Probabilistic Metric for Hardware Failure：ランダム故障の確率的尺度）が10の-8乗per時間以下、つまり一億時間に1回未満の故障率を要求する。それに対応するソフトウェア開発は、MC/DCカバレッジ、独立検証、形式証明に近い手法まで使う場合がある」
「すごいですね......」
「HARAが終わると、その結果として"安全目標（Safety Goal）"が定義される。今回の例では――」
「安全目標 SG-01：AEBSは、衝突リスクがある状況において、前方衝突を回避・軽減するためのブレーキ介入を意図なく喪失してはならない」
ASIL D、継続的な機能の喪失
「これが最上位の安全要求。ここからすべての安全設計が始まる」
その日のノート。
剛志のノート（20）
・HARA：ハザードを洗い出し、S（深刻度）×E（暴露頻度）×C（回避可能性）でASILを決める。
・S0-3：ケガなし〜生命の危機。E0-4：ほぼ発生なし〜毎日。C0-3：誰でも制御〜ほぼ不能。
・S3+E3+C3 → ASIL D（最高レベル）。
・機能喪失（動くべきときに動かない）と不意動作（動くべきでないときに動く）の両方をHARAする。
・HARAの最終成果物＝安全目標（Safety Goal）。ここから安全設計が始まる。
HARA会議が終わった後、渡会さんはまだホワイトボードの前に立っていた。中月さんが先に部屋を出ていった後も、渡会さんは一言も喋らないまま、次々と図を描き続けた。HARA表、ASIL決定マトリクス、安全目標のツリー構造----すべてが静寂の中で生まれていった。
「渡会さん、今日の分、まとめてくれてるんですか」と僕は聞いた。
渡会さんはちらっとこちらを見て、また黙ってホワイトボードに向き直った。答えは、図そのものだった。
第21章 ASILという名の格付け
FSAFE.003：ASIL A/B/C/D ― 安全度水準の4段階とその意味
「ASILを詳しく見よう」と翌日、中月さんは言った。
「ASIL（Automotive Safety Integrity Level）はAからDの4段階。Dが最も厳しく、Aが最も緩い。さらに"QM"（Quality Management）というレベルがあって、これはASIL不要、通常の品質管理で十分という意味だ」
「つまり全部で5段階？」と僕は聞いた。
「そう考えていい。QM、A、B、C、Dの5段階。HARAで決まったASILに応じて、設計・実装・テストの要求レベルが変わる」
中月さんはホワイトボードに表を書いた。
QM：安全分析不要。通常の品質管理で十分
ASIL A：低レベルの安全対策。基本的な冗長化と検証
ASIL B：中低レベル。より厳密なテスト、部分的冗長化
ASIL C：中高レベル。独立した安全機構、詳細な安全分析
ASIL D：最高レベル。完全冗長化、独立検証、PMHF ≦ 10⁻⁸/h
「ソフトウェアで言えば、ASIL Dではコードカバレッジの要求が最も厳しい。MC/DC（Modified Condition/Decision Coverage）カバレッジが必須で、すべての分岐条件の組み合わせを網羅する。これは実用的には、テストケースが数百〜数千になることを意味する」
「ASIL Dの機能をそのままソフトウェアに実装するのが大変すぎる場合、どうするんですか？」と僕は聞いた。
「いい質問だ。そのときは"ASIL分解"という手法を使う」
ASIL分解 ―― 一人に背負わせない
「ASIL分解とは、高ASILの要求を複数のサブシステムに分割して、それぞれが低いASILで実装できるようにする手法だ」
「たとえば、ASIL D要求の機能を二つの独立したサブシステムAとBに分解する。AがASIL B、BもASIL Bとする。二つが独立して動作し、両方が同時に故障しないと危険状態に至らない設計にすれば、全体としてASIL Dを達成できる。ただし――ここが本質的なポイントで――"独立性（Sufficient Independence）" が証明できることが大前提だ。独立性が示せなければ、そもそも分解は許されない」
「表記はASIL B(D)とASIL B(D)のように書く。括弧の中の(D)が元々の要求レベルを表す。ISO 26262では、代表的な分解パターンとして次のような組み合わせが認められている――」
・ASIL D = ASIL C(D) + ASIL A(D)
・ASIL D = ASIL B(D) + ASIL B(D)
・ASIL D = ASIL D(D) + QM(D)
「いずれも、両系統の独立性が論証できて初めて成立する。逆に言えば、独立性が証明できないケースでは分解そのものができない、と覚えておけばいい」
「カイトのAEBSでは、メインの自動ブレーキECU（ASIL C相当の実装）と、独立した安全モニタリング機構（ASIL D相当の監視）を組み合わせることで、全体のASIL D要求を満たす設計にしている」
「でも」と僕は言った。「二つのシステムが本当に独立してるって、どうやって証明するんですか？ 同じソフトウェアプラットフォームで動いてたら、共通の原因で両方やられませんか？」
中月さんは少し微笑んだ。
「鋭いな。それが"共通原因故障（CCF：Common Cause Failure）"の問題だ。ASIL分解が有効なのは、二つのサブシステムが独立していることが証明できるとき。同じハードウェア、同じOS、同じ開発チームが作ったら、"共通原因" で両方故障する可能性がある。だからASIL D分解では、ハードウェアを物理的に分離したり、ソフトウェアを異なる言語・ツールで開発したりする"多様化"を要求することがある」
用語
ASIL分解：ASIL D等の高いASIL要求を、複数の独立したサブシステムに分割して、それぞれが低ASILで実装できるようにする手法。ASIL D → ASIL B(D) + ASIL B(D)のように表記する。二つのサブシステムの独立性（CCF対策）が条件。
PMHF（Probabilistic Metric for Hardware Failures）：ランダムハードウェア故障の確率的尺度。ASIL Dではシステム全体のPMHFが10⁻⁸/時間以下を目標とする。
その日のノート。
剛志のノート（21）
・ASIL：QM / A / B / C / Dの5段階。DはPMHF ≦ 10⁻⁸/h、MC/DCカバレッジ必須。
・ASIL Dほど、設計・実装・テストの要求が厳しい。ドキュメントも膨大になる。
・ASIL分解：高ASILを複数の低ASILサブシステムに分割。ASIL D = ASIL B(D) + ASIL B(D)。
・分解の条件：二つのサブシステムが独立（CCF対策：ハード分離、多様化）。
・カイトのAEBSはメインECU＋独立モニタリングでASIL D達成。
第22章 安全要求を作る ―― 「なぜ」から「何を」へ
FSAFE.004：機能安全要求とTSR ― 安全目標から実装までの橋渡し
「HARAで安全目標ができた。ASILも決まった。次のステップは"安全要求の派生"だ」と中月さんは翌朝、言った。
「ISO 26262の正規の階層は、Safety Goal → FSR → TSR → HSR・SSR の4階層だ。整理するとこうなる」
0. 安全目標（Safety Goal） ── HARAで決まる、ASIL付きの最上位目標
① 機能安全要求（FSR：Functional Safety Requirement） ── 機能として何を達成するか
② 技術安全要求（TSR：Technical Safety Requirement） ── アーキテクチャ上どう実現するか
③ ハードウェア安全要求（HSR）・ソフトウェア安全要求（SSR） ── HW/SWに落ちた具体要求
「本書では分かりやすさのため、Safety GoalからFSR/TSR/HSR・SSRの流れを"三段階"とまとめて説明することがあるが、正式にはSafety Goalを含めた4階層だ、と覚えておいてほしい」
「安全目標SG-01（"AEBSは衝突リスクある状況でブレーキ喪失してはならない"）から、まずFSRを作る。FSRは"機能として何を達成するか"。実装の方法は書かない」
「たとえば――」
FSR-01：AEBSは、衝突リスク判定後300ms以内にブレーキ介入を開始しなければならない [ASIL D]
FSR-02：AEBSは、自システムの故障を50ms以内に検出し、安全状態へ移行しなければならない [ASIL D]
FSR-03：AEBSの誤警報率は1000時間運行あたり1件未満でなければならない [ASIL B]
「次にFSRから、TSRを派生させる。TSRは"技術として何をどう実現するか"。ここで初めてシステムアーキテクチャとの対応が出てくる」
TSR-01（FSR-01に対応）：ADCのセンサーフュージョンSW-Cは、衝突リスク判定から50ms以内に車両制御コマンド生成SW-Cに出力しなければならない
TSR-02（FSR-02に対応）：ADC内の自己診断ロジックは、10ms周期でフォールト検出ルーティンを実行しなければならない
「TSRが決まると、それを実現するためのハードウェア要求（HSR）とソフトウェア要求（SSR）が派生する。これらは直接、A-SPICEのSYS.2とSWE.1の要求書に取り込まれる」
「あ、A-SPICEの要求書と、機能安全の安全要求が、同じ文書に混ざるんですか？」と僕は聞いた。
「そうだ。DOORSで管理するとき、要求ごとに属性として"ASIL"を付ける。ASIL Dのタグが付いた要求は、追加のレビュー・検証義務が発生する。A-SPICEの観点からも、ISO 26262の観点からも、その要求はより厳しく扱われる」
「つまり、同じリクワイヤメントが、A-SPICEとISO 26262の両方で管理される」
「その通り。これが"兄弟規格が一つの要求書を共有する"形だ。だから、DOORSで安全要求を変更するとき、A-SPICEのSUP.10（変更管理）とISO 26262の変更管理を両方通す必要がある」
その日のノート。
剛志のノート（22）
・安全要求の三段階：FSR（機能として何を）→TSR（技術として何をどう）→HSR/SSR（HW/SWで何を）。
・FSRはASIL付きで定義。TSRからA-SPICEのSYS.2・SWE.1要求書に取り込まれる。
・DOORSで要求にASILタグを付けて管理。ASIL Dの要求は追加検証義務。
・要求変更はA-SPICEのSUP.10と26262の変更管理を両方通す。
・A-SPICEと26262は同じ要求書を共有する兄弟関係。
第23章 車が壊れるとき ―― フェイルセーフとフォールトトレランス
FSAFE.005：フェイルセーフと冗長化 ― 安全アーキテクチャの設計思想
「車のソフトウェアが壊れたとき、何が起きるべきか？」と中月さんは問うた。ある午後の技術ミーティングで、泉谷さんも加わっていた。
「大きく二つの考え方がある。"フェイルセーフ"と"フォールトトレランス"だ」
「フェイルセーフは、故障が起きたとき、システムを"安全な状態"に移行させる。つまり、機能を止めてでも安全を確保する。たとえばエレベーターが異常を検知したら最寄り階で停止してドアを開ける、みたいな発想」
「フォールトトレランスは、故障が起きても機能を継続させる。一つが壊れても、冗長系が引き継いで走り続ける。複数エンジンを積んだ旅客機が、片発を失っても残りのエンジンで飛び続けられるように設計されている、あの"複数系統での冗長化"の発想だ」
「どちらが正解？」と僕は聞いた。
「機能による。緊急ブレーキ（AEBS）は、壊れたら即フェイルセーフ（停止・警告）でいい。でも、高速道路をL3自動運転で走行中に、突然"私は壊れました、さようなら"と制御を放棄されたら危ない。この場合はフォールトトレランスで、最低限の制御を一定時間維持してドライバーに引き継がせる"最小リスク機動"が必要になる」
安全状態の設計
「フェイルセーフで移行する先、"安全状態（Safe State）"は、事前に定義しておかなければならない」
「カイトで定義した安全状態の例を見せる」
・AEBSの安全状態：警報を継続し、自動ブレーキ介入を停止してドライバーに引き継ぐ
・L3自動運転の安全状態：最大20秒間、車線を維持して速度を落とし、ドライバーに引き継ぐ要求を出す
・パワートレインECUの安全状態：エンジン/モーター出力をゼロに落とし、惰行させる
「安全状態は、それ自体が新たな危険源にならないように設計する。たとえば"高速道路の追い越し車線で急停止"は安全状態として最悪だ。後続車に追突される」
冗長化と多様化
「冗長化は、同じ機能を複数のハードウェア・ソフトウェアで実装することだ。主系と副系。主系が壊れたら副系が引き継ぐ。これを"空間的冗長性"と呼ぶ」
「多様化は、冗長化のバリエーション。同じ機能を、異なる技術・実装で持つ。たとえばカメラ系とLiDAR系の両方で物体検知する。一方の誤検知が、他方で弾かれる。共通原因故障を防ぐためだ」
「泉谷さん、カイトの冗長化って具体的にどうなってますか？」と僕は聞いた。
「ADCは主系と安全モニタリング系の二系統だ。主系がメインの自動運転処理をする。安全モニタリング系は主系の出力を独立して監視して、異常なコマンドをゲートする。物理的には別のチップ、別のメモリ空間で動く」
「これはASIL分解と組み合わさってるわけですね」
「そうだ。主系はASIL C相当の実装、安全モニタリング系はASIL Dの厳格さで実装。両方合わせてASIL D全体要求を満たす」
その日のノート。
剛志のノート（23）
・フェイルセーフ：故障したら安全状態に移行（機能停止も選択肢）。
・フォールトトレランス：故障しても機能継続（冗長系が引き継ぐ）。
・安全状態は事前設計必須。新たな危険源にならない状態を選ぶ。
・冗長化：同じ機能を複数のHW/SWで実装（空間的冗長性）。
・多様化：異なる技術・実装で同じ機能（共通原因故障対策）。
・カイトのADC：主系（ASIL C）＋安全モニタリング系（ASIL D）。
第24章 壊れ方を想像する ―― FMEAとFTA
FSAFE.006：安全分析 ― ボトムアップとトップダウン、二つの目
「安全設計が決まったら、"それで本当に安全か"を分析で確かめる。主要な手法が二つある。FMEAとFTAだ」と中月さんは言った。
FMEA ―― 下から上へ
「FMEA（Failure Mode and Effects Analysis）は、ボトムアップの分析。部品一個一個の"故障モード"を列挙して、それが上位システムにどんな影響を与えるかを追う」
「センサーフュージョンSW-Cの一つのモジュールを例にとると――」
コンポーネント：前方カメラ映像取得モジュール
故障モード①：映像信号が途絶える → 影響：センサーフュージョンへの入力喪失 → ASIL B相当の故障検出で対処
故障モード②：映像が遅延する（50ms超） → 影響：古いデータで判定、衝突回避が遅れる → ASIL D相当のタイムスタンプチェックが必要
故障モード③：映像が歪む（画像処理バグ） → 影響：誤検知率上昇 → 系統的故障として設計レビューで対処
「FMEAはこれを、システム内の全コンポーネント・全モジュールに対してやる。カイトのADCだけで数百〜数千エントリになる。非常に手間がかかるが、細かい故障モードを拾える」
「FMEAにDiagnostic Coverage（診断カバレッジ）の概念を加えたのがFMEDAだ。どの故障が安全機構で検出されるか（DC）を計算して、PMHF（ランダム故障率）を定量的に導出する。ASIL Dの定量目標を達成しているかを証明するのに使う」
FTA ―― 上から下へ
「FTA（Fault Tree Analysis）は逆方向。"この事故が起きる条件は何か"というトップ事象を置いて、下へ下へと原因をたどる木構造（フォールトツリー）を描く」
「トップ事象：衝突回避ブレーキが作動しない」
「その原因は？ OR条件でつながる――」
A：センサーが衝突リスクを検出しない
B：判定ロジックがブレーキ指令を出さない
C：ブレーキアクチュエータが指令を受け付けない
「Aをさらに展開すると――」
A1：カメラが前方映像を取得しない（AND条件：カメラ故障 AND LiDAR故障 AND レーダー故障）
A2：センサーフュージョンが誤判定する
「AND条件になっているのはなぜか？ 複数センサーで冗長化しているから。カメラ単独が壊れても、LiDARとレーダーで補える設計になっている。つまり、全部同時に壊れないと事故にならない」
「FMEAは"詳細"に強く、FTAは"構造"に強い。両方やることで、安全設計の穴を違う方向から探す。どちらか一方では足りない」
用語
FMEA（Failure Mode and Effects Analysis）：故障モードと影響解析。部品の故障モードを列挙し上位システムへの影響を分析するボトムアップ手法。FMEDAはFMEAに診断カバレッジを加えた定量版。
FTA（Fault Tree Analysis）：フォールトツリー解析。トップ事象（事故）から原因をAND/OR論理でたどるトップダウン手法。論理ゲートで構成。
その日のノート。
剛志のノート（24）
・FMEA：ボトムアップ。部品→故障モード→上位影響の列挙。詳細に強い。
・FMEDA：FMEAに診断カバレッジを加えた定量版。PMHFを計算する。
・FTA：トップダウン。事故→原因をAND/OR論理で展開。構造に強い。
・両方やることで安全設計の穴を違う角度から探す。
・カイトのADCは三センサー（カメラ＋LiDAR＋レーダー）冗長化でFTA上のAND条件が深い。
第25章 機能安全のライフサイクル ―― 始まりから終わりまで
FSAFE.007：ISO 26262の全体像 ― コンセプトフェーズから廃棄まで
「最後に、ISO 26262の全体的なライフサイクルを俯瞰しよう」と中月さんは言った。「個々の手法を学んだが、それがどの順番でつながるか、見渡せると全体が見える」
中月さんはホワイトボードにV字と、その下に続く矢印を描いた。
機能安全ライフサイクルの流れ
Phase 1【コンセプトフェーズ（Part 3）】
→ アイテム定義・HARA・安全目標・FSC（機能安全コンセプト）
Phase 2【システム開発（Part 4）】
→ TSR・技術安全コンセプト・システムアーキテクチャ・HSRとSSRへの割り付け
Phase 3【ハードウェア開発（Part 5）】
→ HW設計・PMHF計算・HW統合テスト
Phase 4【ソフトウェア開発（Part 6）】
→ SSR・SWアーキテクチャ・詳細設計・SW単体テスト・SW統合テスト・SW検証
Phase 5【統合と検証（Part 4/6）】
→ SW/HW統合・システム検証・機能安全検証
Phase 6【生産（Part 7）】
→ 機能安全要求の生産プロセスへの継承
Phase 7【運用とサービス（Part 7）】
→ フィールドモニタリング・OTA更新時の安全継続確認
Phase 8【廃棄（Part 7）】
→ 安全機能の廃棄手順
「A-SPICEのV字と、ISO 26262のライフサイクルが、どう重なるかわかるか？」
「Phase 1がSYS.1〜2に対応して、Phase 2がSYS.3、Phase 4がSWE.1〜6......ですね」と僕は言った。
「そうだ。V字の各段に、安全分析と安全要求の活動が"追加"される。重なるが、追加の証拠が要る。これが、A-SPICEを満たすだけでは機能安全認証が取れない理由だ」
DIA（Development Interface Agreement）
「もう一個重要な概念を話す。DIA、Development Interface Agreement。開発インタフェース合意書だ」
「カイトでは、OEMから弊社への安全責任の分担を書いた文書がある。これがDIA。"AEBSの機能安全コンセプトはOEMが定義する、TSR以下はアイソーが責任を持つ"みたいな内容が書いてある」
「一つの車の中で、安全責任が分割されてる。OEM、Tier1、Tier2で、それぞれが担う安全責任の範囲がDIAで定義される。これがないと、誰がどの安全機能の責任者かが不明になる」
「これで機能安全（ISO 26262）の基本を一通りやった」と中月さんは言った。「感想は？」
「正直、思ってたより"人間的"な活動だと感じました」と僕は言った。
「人間的？」
「はい。"故障は起きる前提で考える"って、すごく正直な思想だと思って。"壊れない"と言い張るんじゃなくて、"壊れたときどうするか"を最初から設計する。そこに潔さを感じました」
中月さんは、珍しく少し表情を崩した。
「それだ。それが機能安全の本質。"完璧なものは作れない"という前提から出発する誠実さ。その誠実さを、HARAと安全要求とFMEAとFTAで、数式と文書の形に落とす。それが私の仕事だ」
その日の最後のノート。
剛志のノート（25・機能安全まとめ）
① 機能安全＝E/Eシステムの誤動作による不合理なリスクの不在。「故障は起きる前提で設計」。
② HARA：S×E×C → ASIL決定 → 安全目標定義。
③ ASIL A〜D（+QM）：Dが最高。MC/DCカバレッジ、PMHF ≦ 10⁻⁸/h。
④ ASIL分解：高ASILを独立した低ASIL複数系統に分割（CCF対策が必要）。
⑤ 安全要求：FSR → TSR → HSR/SSR の三段階。DOORSでASILタグ管理。
⑥ フェイルセーフ（停止→安全状態）+ フォールトトレランス（継続）を機能別に選択。
⑦ FMEA/FMEDA（ボトムアップ）+ FTA（トップダウン）で安全設計を多角的に検証。
⑧ ライフサイクル全体：コンセプト→システム→HW→SW→統合→生産→運用→廃棄。
⑨ DIA：OEM-Tier1-Tier2間で安全責任の分担を文書化。
⑩ A-SPICEとISO 26262は同じV字を共有。機能安全は"追加の厳格さ"として重なる。