ISO 26262(自動車機能安全)

1. 概要

A. 定義

ISO 26262は、自動車の電気・電子(E/E)システムの誤動作(malfunctioning behavior)による危険を許容可能な水準まで低減することを目標とする機能安全(Functional Safety)の国際規格である。汎用安全規格IEC 61508を自動車ドメインに特化して作られたもので、「安全は設計・開発・生産・運用の全ライフサイクルにおいて証拠(evidence)で立証されねばならない」という原則の上に立っている。

ISO 26262が登場した背景は、自動車の「コンピュータ化」にある。かつて機械・油圧で実現されていた制動・操舵・駆動が電子制御装置(ECU)とソフトウェアへ移行するにつれ、一つのセンサ誤り、一つのビット反転、一つのソフトウェア欠陥が、そのまま加速・制動失敗のような人命事故に発展しうるようになった。従来の品質管理が「故障率を下げること」に集中したとすれば、機能安全は一歩進んで「故障が起きてもシステムが危険な状態へ至らないよう(fail-safe / fail-operational)設計されているか」を問う。2011年の第1版が乗用車(総重量3.5t以下)を中心に制定された後、電動化・自動運転でE/E比率が急増したため、2018年の第2版でトラック・バス・二輪車まで適用範囲を広げ、半導体(第11部)・二輪車(第12部)の指針を新設した。

したがってISO 26262を理解する出発点は、「リスク(risk)= 重大度 × 曝露頻度 × 制御可能性」という視点である。すべての故障をゼロにはできないため、リスクの大きい機能にはより厳格な開発・検証を、リスクの小さい機能には通常の品質管理(QM)を適用するリスク比例(risk-proportionate)のアプローチが規格全体を貫く。この比例の尺度こそが、後述のASILである。

ISO 26262は全12部(part)で構成される。第1部(用語)・第2部(安全管理)を骨格とし、第3部(コンセプト段階)・第4部(システム)・第5部(ハードウェア)・第6部(ソフトウェア)が開発ライフサイクルを扱い、第7部(生産・運用)・第8部(支援プロセス)・第9部(ASIL指向分析)・第10部(指針)がこれを支える。2018年第2版で追加された第11部は半導体への適用指針を、第12部は二輪車への適応を扱う。このように規格が「管理−コンセプト−開発−運用−支援」を網羅する全方位の体系である点は、機能安全が特定の技術ではなく組織全体のプロセス・文化・ガバナンスを要求する経営課題であることを示唆する。

B. 機能安全と他の安全概念の区別

機能安全を正確に用いるには、隣接概念との境界を明確にせねばならない。ISO 26262が扱うのは、あくまでE/Eシステムの誤動作(systematic failure + random hardware failure)から生じる危害である。たとえばブレーキECUがソフトウェアのバグで制動命令を無視したり、メモリのビットが放射線で反転して誤ったトルクを出す状況が対象である。「機能安全(functional safety)」という名称自体がこの範囲を含意する——ある機能が「機能的に正しく動作できないとき」に生じる危険を、その機能を監視・補完する別の機能(安全メカニズム)で制御する、という意味である。

一方、システムが「設計どおり正常に動作」しているにもかかわらず、意図した機能自体の性能限界・誤認識のために危険が生じる場合はISO 26262の範囲外であり、これを扱うのが2022年に正式発行されたISO 21448(SOTIF, Safety Of The Intended Functionality)である。カメラが逆光で歩行者を認識できない自動運転の状況は「故障」ではなく「性能不足」であるため、SOTIFの領域である。また感電・発火のような非機能的危害は電気安全規格が、完成車全体の挙動安全はUL 4600(自動運転車の安全ケース)などが補完する。試験答案では「ISO 26262=故障への備え、SOTIF=性能限界への備え、両者は相互補完」という分担の構図を明確に述べることが核心である。

この区別が実務で重要な理由は、安全活動の「証明の仕方」が根本的に異なるからである。ISO 26262の故障は原因が特定可能で確率で定量化できるため、FTA・FMEAで故障経路を追跡し、ハードウェア指標で残存リスクを数値化できる。一方、SOTIFが扱う性能限界は「いつどの状況で誤認識するか」を完全に列挙できず、走行シナリオのカバレッジと統計的論証に依存する。すなわち前者が「決定論的証拠」であるなら、後者は「確率的・シナリオ的論証」に近い。情報管理技術士の観点では、両アプローチの検証哲学の違いを見抜くことが高得点の分岐点となる。

さらに機能安全は、体系的故障(systematic failure)とランダム故障(random failure)を区別し、それぞれ異なる手段で扱う。体系的故障は要求・設計・実装の欠陥のように、条件さえ合えば必ず再現する故障であり、プロセスの厳格化(レビュー・静的解析・テストカバレッジ)で「予防」する。ランダム故障は半導体の経年劣化・放射線のように確率的に発生するハードウェア故障であり、安全メカニズムによる「検出・対応」と指標管理で制御する。この二分法が、規格全体の活動をどう配分するかを決める骨格である。

2. ASIL — リスク等級の決定と全体構造

ISO 26262のすべての活動は、ハザード分析およびリスクアセスメント(HARA, Hazard Analysis and Risk Assessment)から出発する。車両の各機能が誤動作したときに生じうる危険状況(hazardous event)を識別し、これを三つの軸で定量化する。第一に重大度(Severity, S0〜S3)——事故が起きたとき乗員・歩行者が被る傷害の程度。第二に曝露頻度(Exposure, E0〜E4)——その危険状況に車両が置かれる確率・頻度。第三に制御可能性(Controllability, C0〜C3)——運転者がその状況を回避・制御できる程度である。この三つの値の組合せでASIL(Automotive Safety Integrity Level)が決まる。

graph TD
  START["車両機能の定義"] --> HARA["HARA: 危険状況の識別"]
  HARA --> S["重大度 S0~S3"]
  HARA --> E["曝露頻度 E0~E4"]
  HARA --> C["制御可能性 C0~C3"]
  S --> COMB["リスク組合せ評価"]
  E --> COMB
  C --> COMB
  COMB --> ASIL["ASIL等級 QM/A/B/C/D"]
  ASIL --> SG["安全目標 Safety Goal 導出"]
  SG --> FSR["機能安全要求 FSR"]
  FSR --> TSR["技術安全要求 TSR"]

上の構造図が示すとおり、ASILはそれ自体が目的ではなく、「どれほど厳格に開発・検証するか」を決める入力である。ASILはQM(Quality Management、通常の品質管理で十分)とA・B・C・Dの五段階に分かれ、Dが最も厳格である。制動・操舵のように誤動作時に致命的な機能はおおむねASIL C/D、電動ミラー・室内灯のようにリスクの小さい機能はQM/Aに分類される。等級が上がるほど要求される分析・テスト・文書化・余裕設計の強度が非線形に大きくなるため、HARA段階でASILを過大・過小に見積もると、それぞれ過剰コストと安全不足に直結する。まさにこのため、HARAは少数の専門家の主観ではなく、多分野の合意と根拠記録によって実施されねばならない。

項目	内容	ASILとの関係
重大度(S)	S0(傷害なし)〜S3(生命の脅威・致命傷)	高いほどASIL ↑
曝露頻度(E)	E0(ほぼなし)〜E4(常時発生)	高いほどASIL ↑
制御可能性(C)	C0(制御容易)〜C3(制御不能)	高いほどASIL ↑
ASIL	QM < A < B < C < D	開発・検証の厳格度を決定

表は三要素の方向性を整理したものだが、実際の算定は単純な足し算ではなく、規格が提供するリスクマトリクス(risk matrix)に従う。たとえば高速走行中の意図しない全制動は重大度・曝露・制御不能がいずれも高いためASIL Dに、低速駐車中の後方カメラ消灯は相対的に低く評価される。三要素を積の形で扱うことには深い理由がある。どれほど重大な結果でも、ほとんど発生しなかったり(E低い)、運転者が容易に回避できる(C低い)なら、実際のリスクは下がるからである。たとえば「時速200kmでのみ発生する欠陥」は曝露頻度が低く等級が下がり、「運転者が即座に減速で対応可能な警告灯の誤り」は制御可能性が高く等級が下がる。このようにASILは結果の大きさだけでなく、その結果が現実化する条件まで総合した「実質リスク」の尺度であり、まさにこの点が単純な故障重大度分類と機能安全等級とを分ける核心である。答案でS・E・Cを並べるだけで「なぜ積で束ねるのか」を欠落させると、原理理解が不足していると評価される。

もう一つ重要な技法がASIL分解(ASIL decomposition)である。一つのASIL D要求を、互いに独立に動作する二つの経路(例: ASIL B + ASIL B(D))に分けて各構成要素の開発負担を下げる技法だが、ただし二つの経路が共通原因故障(CCF)で共に崩れないよう独立性(freedom from interference)を立証してはじめて成立する。独立性が崩れると(例: 二つの経路が同じ電源・クロック・メモリを共有)分解は無効となり、元のASIL D負担がそのまま戻るため、分解はコスト削減の手段である前に「独立性の証明」という別の分析課題を伴う点に留意せねばならない。

3. 安全ライフサイクルとVモデル — 構成要素と手順

ISO 26262の第二の軸は安全ライフサイクル(safety lifecycle)である。これはコンセプト段階 → 製品開発(システム・ハードウェア・ソフトウェア) → 生産・運用 → 廃棄まで安全活動を時系列で編んだもので、開発段階は典型的なVモデルで展開される。左の下降部で要求を上位から下位へ分解し(安全目標 → FSR → TSR → HW/SW設計)、右の上昇部で単体・統合・システム水準で検証し、各段階の成果物が上位要求を満たすことをトレーサビリティ(traceability)で立証する。

flowchart LR
  subgraph LEFT["設計(要求分解)"]
    direction TB
    L1["安全目標(Safety Goal)"] --> L2["機能安全要求(FSR)"]
    L2 --> L3["技術安全要求(TSR)"]
    L3 --> L4["HW/SW安全要求"]
    L4 --> IMPL["実装(設計・コーディング)"]
  end
  subgraph RIGHT["検証(統合・確認)"]
    direction TB
    R4["単体検証"] --> R3["HW/SW統合"]
    R3 --> R2["システム統合"]
    R2 --> R1["安全確認(Safety Validation)"]
  end
  IMPL --> R4
  L4 -. トレーサビリティ .-> R4
  L3 -. トレーサビリティ .-> R3
  L2 -. トレーサビリティ .-> R2
  L1 -. トレーサビリティ .-> R1

VモデルがISO 26262の事実上の標準開発モデルとなった理由は、「要求と検証の対称性」にある。左で上位安全要求を一段ずつ分解するたびに、右の対応段階でその要求が満たされたことを検証するよう、左右が鏡のように噛み合う。この対称構造は「すべての安全要求は必ず一つ以上の検証活動で閉じられねばならない」という閉ループ(closed-loop)原則を自然に強制し、トレーサビリティマトリクスでその閉ループを可視化する。要求が検証なしで残ったり、検証が要求なしで浮いていれば、トレーサビリティ点検で即座に露見するため、欠落した安全活動を早期に捕捉できる。

詳細な構成要素を段階別に見ると次のとおりである。コンセプト段階ではアイテム定義(item definition)で対象システムの境界を引き、HARAでASILと安全目標を定めた後、これを実装非依存の機能安全要求(FSR)へ具体化する。システム段階ではFSRをハードウェア・ソフトウェアへ割当可能な技術安全要求(TSR)へ細分し、安全アーキテクチャ(監視・冗長化・安全状態遷移)を設計する。ここで重要な概念が安全状態(safe state)と故障許容時間間隔(FTTI, Fault Tolerant Time Interval)である。故障が発生した瞬間から危険が現実化するまでの時間内に、システムが安全状態(例: トルク遮断、警告後の減速)へ遷移せねばならないという時間制約で、[[rtos]]の決定性・デッドラインの概念と直結する。FTTIはさらに「故障を検出する時間(fault detection time)」と「安全状態へ反応する時間(fault reaction time)」の和に分解され、この二つの時間の上限を保証するには診断周期と反応経路がリアルタイム性要求を満たさねばならない。ゆえに安全アーキテクチャ設計はリアルタイムスケジューリング設計と切り離せず、ウォッチドッグ・監視コアの周期をFTTIから逆算して定める作業が核心となる。

生産・運用段階も安全ライフサイクルの一部である。開発が終わったから安全が保証されるのではなく、生産工程で安全特性が再現されるか(工程管理)、運用中に故障を診断・報告しリコール・フィールド対応へフィードバックするかまでが規格の関心事である。すなわちISO 26262は「設計の安全」を越えて「ライフサイクル全体にわたる安全の維持」を要求し、これが一度きりの試験合格で終わる従来の認証と区別される点である。

ハードウェア段階では、ランダムハードウェア故障(random hardware failure)を定量的に評価する。核心指標は三つである。SPFM(単一点故障指標)は安全メカニズムが単一点故障をどれほど捕えるかを、LFM(潜在故障指標)は表に出ず潜む潜在故障をどれほど診断するかを、PMHF(ランダムハードウェア故障確率指標)は時間当たりの危険故障確率(FIT, 10億時間当たりの故障数)を表す。規格が提示する目標値はASILが上がるほど急峻になる。

指標	ASIL B	ASIL C	ASIL D
SPFM	≥ 90%	≥ 97%	≥ 99%
LFM	≥ 60%	≥ 80%	≥ 90%
PMHF	< 100 FIT	< 100 FIT	< 10 FIT

この数値が意味するところを散文で解けばこうである。ASIL DのSPFM 99%は「単一点故障の99%を安全メカニズムが検出・対応せねばならない」という意味であり、PMHF 10 FITは「危険なランダム故障が10億時間(約11.4万年の連続走行)当たり10回未満でなければならない」という極めて低い確率を要求する。これを達成するにはECCメモリ、ロックステップ(lockstep)デュアルコア、ウォッチドッグ、周期的自己診断(BIST)のような安全メカニズムをアーキテクチャに織り込まねばならない。

ここで核心は「診断カバレッジ(diagnostic coverage)」という概念である。どれほど故障率の低い部品でも、故障を検出できなければ安全指標にそのままリスクとして計上され、逆に故障率がやや高くても安全メカニズムが故障を高い割合で検出し安全状態へ遷移させれば残存リスクは下がる。すなわちハードウェア安全設計の本質は「故障をなくすこと」ではなく「故障を適時に検出・隔離すること」である。このためASIL Dシステムは演算結果を二経路で比較するロックステップ、メモリ誤りを訂正するECC、周期的に論理を検査するBISTを重ね、単一故障が検出なしに出力へ伝播する経路を構造的に遮断する。

ソフトウェア段階ではMISRA Cのようなコーディング規則、静的解析、要求ベーステスト、構造的カバレッジ(ASIL DはMC/DCを要求)を適用し、これは[[embedded-software-test]]・[[software-safety-analysis]]のFMEA・FTA技法と噛み合って体系的故障を除去する。ソフトウェアはランダムに「摩耗」しないため、故障率の数値ではなく開発プロセスの厳格性そのものが安全証拠となる点がハードウェアと決定的に異なる。ゆえに規格はASILが高いほど、より強い設計原則(モジュール化・強結合の禁止・決定的実行)、より厳格な検証技法(境界値・同値分割・故障注入)、より高いカバレッジ目標を「推奨(highly recommended)」水準で差をつけて要求する。また要求・設計・コード・テストの間の双方向トレーサビリティを保ち、どの安全要求がどのコードで実装されどのテストで検証されたかを漏れなく証拠として残さねばならない。

4. 比較 — 機能安全規格間の関係と適用事例

ISO 26262は単独で存在せず、安全規格の階層の中に置かれる。母体であるIEC 61508は全産業向けの汎用機能安全規格で、安全度水準をSIL 1〜4に分けるが、ISO 26262のASILはこれを自動車ドメインに合わせて再解釈したものである。差が生じる理由は適用の文脈にある。工場設備(IEC 61508)は故障時に「停止(fail-safe)」がおおむね安全だが、高速走行する車両は急な全停止がかえって危険になりうるため、fail-operational(一部機能の維持)設計が要求される。この実務的含意の差が、二つの規格のアーキテクチャ選択を分ける。

規格	対象	等級体系	核心的関心事
IEC 61508	全産業(汎用)	SIL 1〜4	汎用機能安全の母体
ISO 26262	道路車両E/E	ASIL A〜D(+QM)	E/E故障への備え
ISO 21448(SOTIF)	意図機能の性能限界	等級なし	誤認識・性能不足
DO-178C	航空SW	DAL A〜E	航空ソフトウェア

また航空ソフトウェア規格DO-178C(DAL A〜E)と比較すると、等級化・Vモデル・トレーサビリティという共通の骨格が浮かび上がる。両規格とも「安全完全性が高いほどより厳格な検証」を要求するが、航空は認証機関(FAA/EASA)の審査が前提である一方、自動車は相対的に製造者の自己宣言・監査の比重が大きく、プロセス証拠の自己立証責任が大きい。このように同じ機能安全でも産業ごとの認証エコシステムが異なれば実務の運用方式が変わる点を答案で押さえると、比較の深みが増す。

具体的な適用事例を見ると理解が深まる。電動パワーステアリング(EPS)は操舵補助力の喪失が致命的であるため通常ASIL Dで開発され、モータ制御器にロックステップコアと多重センサを置きFTTI内の安全状態遷移を保証する。バッテリマネジメントシステム(BMS)は過充電・熱暴走を防がねばならないため、セル電圧・温度監視と接触器遮断をASIL C/Dで設計する。逆にインフォテインメントのディスプレイはおおむねQMである。もう一つ実務で重要な概念がSEooC(Safety Element out of Context)で、特定の車両を前提とせず汎用の仮定のもとで開発した半導体・ソフトウェア部品(例: 車載MCU)を、完成車統合時にその仮定の成立可否だけを確認して再利用する方式である。半導体企業がASIL等級を「事前確保」して供給するエコシステムがこうして作られる。

このエコシステムの実際の働きを見ると、車載MCU供給企業はチップにロックステップコア・ECC・BISTのような安全メカニズムを内蔵し、安全マニュアル(safety manual)に「完成車が守るべき仮定と使用条件」を明記して共に提供する。完成車・部品(Tier-1)企業はその仮定が自社システムで成立するかだけを確認すればよいため、半導体水準の膨大な安全分析を繰り返さずにASIL要求を満たせる。このようにISO 26262は単一組織の開発規範を越え、サプライチェーン全体が安全証拠を分業・引継ぎするDIA(Development Interface Agreement)ベースの協業モデルを制度化した点に意義が大きい。

5. 深化 — 自動運転時代の機能安全の拡張と最新動向

近年、機能安全の地形は自動運転とソフトウェア定義車両(SDV, Software-Defined Vehicle)へ急速に移動している。最大の変化は、ISO 26262(故障安全)だけでは自動運転を扱えないという認識である。自動運転事故の相当数は、部品が「故障」したためではなく、認識・判断アルゴリズムが「設計された限界の中で正常に動作」したにもかかわらず例外状況を誤判断して発生する。これを埋めるためISO 21448(SOTIF)が2022年に正式規格として発行され、既知/未知の危険・安全領域を四象限に分け、未知の危険領域を検証・走行データで縮小するアプローチを提示する。さらにAIベース自動運転の全体安全ケース(safety case)を扱うUL 4600、そして2024年に発行されたISO/PAS 8800(自動車AI安全)まで登場し、規格体系が多層化している。

SOTIFの四象限アプローチは特に味わう価値がある。安全/危険と既知/未知の二軸で領域を分けると、開発の目標は「既知の危険(Area 2)」を設計で除去し、「未知の危険(Area 3)」をシナリオ発掘・走行蓄積で「既知」の領域へ引き込んで再び除去することになる。問題はArea 3を完全に空にできないことにあり、「どれほど検証すれば十分安全と宣言するか(validation target)」という統計的判断が介入する。このため自動運転の安全は数億kmの実走行・シミュレーションデータを要求し、故障中心のISO 26262とは根本的に異なる証明負担を生む。

第二の動向はセキュリティと安全の融合である。コネクテッドカーではサイバー攻撃がそのまま安全脅威になるため、サイバーセキュリティ規格ISO/SAE 21434と機能安全が共に設計されねばならない。たとえばOTA(無線更新)で制御ソフトウェアを更新する際、改ざんされたファームウェアがASIL D機能を損なわないよう、セキュリティと安全の要求が相互検証される。従来、安全は「偶発的故障(random/systematic)」を、セキュリティは「悪意ある攻撃(malicious)」を想定し、互いに異なる脅威モデルを用いたが、コネクテッド・自動運転環境では攻撃が安全目標を直接狙うため、二つの脅威モデルを一つの分析へ統合せねばならない。国連規則UNECE WP.29 R155/R156がサイバーセキュリティ管理体系(CSMS)とソフトウェア更新管理体系(SUMS)を型式認可要件として義務化したことで、この融合は選択ではなく規制遵守事項となった。第三は中央集中型E/Eアーキテクチャへの転換である。数十個のECUに分散していた機能が少数の高性能ドメイン・ゾーン(zonal)コントローラへ統合されるにつれ、一つのハードウェア上でASIL D機能とQM機能が共存するようになった。このときハイパーバイザ・パーティショニングで混合クリティカリティ(mixed-criticality)間の干渉のなさを保証する設計が核心課題として浮上したが、これは[[rtos]]の空間・時間分割の概念と直結する。

統合がもたらす利点は明確である。配線・コネクタが減り重量・コストが下がり、ソフトウェア定義車両としてOTAで機能を継続改善できる。しかし安全の観点では「隔離の証明」という新たな難題を投げかける。低クリティカリティのアプリケーションの暴走が高クリティカリティ制御のCPU・メモリ・ネットワーク帯域を侵食しないよう資源を時間・空間的に分割し、その隔離が欠陥状況でも崩れないことを立証せねばならない。このためAUTOSAR Adaptiveプラットフォーム、安全認証済みハイパーバイザ、決定的イーサネット(TSN)のような基盤技術が機能安全アーキテクチャの必須要素として浮上している。予想される出題の方向としては、「ISO 26262とSOTIF・21434の統合安全プロセスを自動運転の事例で説明せよ」という融合型論題、あるいは「中央集中E/Eアーキテクチャで混合クリティカリティ隔離を保証する設計方策を論ぜよ」というアーキテクチャ型論題が有力である。

6. 考慮事項および示唆点

適用戦略 — ASIL指向設計(ASIL-oriented design): プロジェクト初期にHARAで機能別ASILを確定し、その等級に比例してアーキテクチャ・プロセス・検証の強度を配分せねばならない。特にASIL分解で高等級要求を低等級の多重経路へ分散する際は、独立性(freedom from interference)と共通原因故障の排除を必ず証拠として残してはじめて分解が有効となる。等級を後から調整すると再設計コストが急増するため、コンセプト段階の正確なASIL算定が全体コストを左右する。
トレードオフ — 安全対コスト・性能・日程: ASIL D要求はロックステップ・冗長化・広範なカバレッジテストを伴い、BOMコストと開発期間を大きく増やす。逆にSEooC・部品再利用・ASIL分解はコストを下げるが、仮定の妥当性立証の負担を残す。技術士の観点では「安全は妥協不可」という原則のもと、過剰設計と過小設計の間でリスク比例的な最適点を見いだす均衡感覚が要求される。
展望 — データ駆動・連続的安全保証: 自動運転とSDVの時代には、出荷時点の一度きりの認証ではなく、走行データ・OTA・現場モニタリングを通じた運用中の連続安全保証(continuous safety assurance)へパラダイムが移動する。SOTIFの未知リスク縮小、デジタルツイン・シミュレーションベースの検証、安全ケース(safety case)の継続更新が規格実務の中心となるだろう。
連携技術 — セキュリティ・AI・リアルタイム性の統合: 機能安全はもはや独立した活動ではなく、ISO/SAE 21434(サイバーセキュリティ)、ISO/PAS 8800(AI安全)、[[rtos]]のリアルタイム性、[[software-safety-analysis]]のFMEA・FTAと有機的に結合されねばならない。特に中央集中アーキテクチャでは混合クリティカリティ隔離とセキュリティ・安全の共同設計が核心能力となり、組織次元の安全文化(safety culture)とガバナンスがこれを支えねばならない。
組織・ガバナンス — 安全文化の制度化: ISO 26262は技術要件に先立ち「安全を最優先とする組織能力」を要求する。独立した安全評価(confirmation measure)、役割・責任の明確化、サプライチェーン間のDIA締結、成果物の構成・変更管理が支えられなければ、どれほど優れた設計も「証拠で立証されない安全」にとどまる。したがって技術士は機能安全を単一プロジェクトの品質活動ではなく、全社のプロセス・人材・文化にわたる継続投資として設計・運用するガバナンスの観点を備えねばならない。

参考資料

ISO, "ISO 26262:2018 Road vehicles — Functional safety": https://www.iso.org/standard/68383.html
ISO, "ISO 21448:2022 Road vehicles — Safety of the intended functionality (SOTIF)": https://www.iso.org/standard/77490.html
Semiconductor Engineering, "ISO 26262 Knowledge Center": https://semiengineering.com/knowledge_centers/automotive/automotive-standards/iso-26262/
ISO26262 Academy, "Hardware Metrics: PMHF, SPFM and LFM Explained": https://iso26262.academy/blog/hardware-metrics-explained-pmhf-spfm-lfm
ISO/SAE, "ISO/SAE 21434:2021 Road vehicles — Cybersecurity engineering": https://www.iso.org/standard/70918.html

一言まとめ: ISO 26262は自動車E/Eシステムの誤動作リスクをHARA→ASIL(A〜D)で等級化し、安全ライフサイクル・VモデルとSPFM・LFM・PMHFのハードウェア指標で全ライフサイクルにわたり安全を証拠で立証する機能安全規格であり、SOTIF・21434・AI安全規格と結合して自動運転時代へ拡張している。