機能安全とは｜IEC 61508とISO 26262の違いと開発で求められること

装置が異常を見つけたら燃料の供給を止め、故障を見つけたらモーターを止めて安全な状態に移す。こうした「安全を守る機能」を正しく働かせて、事故のリスクを許容できる水準まで下げる考え方が、機能安全です。

電子制御やソフトウェアを使う製品なら、プラント、産業機械、鉄道、自動車まで幅広く関わる考え方です。

部品メーカーでも、取引先から「ASILはいくつか」「機能安全の対応はできているか」と聞かれる場面が増えています。ASILは、自動車向けの規格ISO 26262で決める安全の厳しさのランクです。

この記事では、機能安全の意味から始め、規格の体系と、基本となるIEC 61508と自動車向けのISO 26262の中身と違いを解説します。そのうえで、開発の現場で実際に求められること、関連する新しい規格の動きという順で整理します。

機能安全とは

機能安全とは、安全を守るための「機能」を正しく働かせることで、リスクを許容できるレベルまで下げるという考え方です。

センサーで異常を検知して燃料の遮断弁を閉じる、故障を検出したらモーターを止めて安全な状態に移す、といった仕組みがこれにあたります。

IEC 61508では、機器とその制御系の安全のうち、ある部分を機能安全と定義しています。それは、電気・電子・プログラマブル電子（E/E/PE）の安全関連系などが正常に機能することに依存する部分です。

ISO 26262では、電気・電子システムの誤動作によるハザードが原因の「不合理なリスクがないこと」と表現されます。

ここでいう安全は「事故が絶対に起きない」ことではありません。規格の用語では、安全は許容できないリスクが存在しないこととされています。リスクはゼロにできない前提に立ち、残るリスクを受け入れられる水準まで下げていく発想です。

本質安全との違い

機能安全とよく対比されるのが本質安全です。本質安全は、危険の原因そのものを取り除くか小さくする方法です。鉄道の例でいえば、線路と道路を立体交差にすれば、列車と車がぶつかる可能性そのものがなくなります。

一方で踏切は、警報機や遮断機という機能によって安全を確保しています。すべての踏切を立体交差にするのは現実的ではないため、本質安全で取り除けないリスクを、機能で下げるという役割分担になります。

図1：本質安全と機能安全の違い

危険の元をなくすか、危険を機能で抑えるか。実際の製品では両方を組み合わせます。

本質安全

機能安全

考え方

危険の原因そのものを取り除く、または小さくする

安全を守る機能を働かせ、リスクを許容レベルまで下げる

鉄道の例

線路と道路を立体交差にする

踏切に警報機と遮断機を設ける

製品の例

低い電圧・小さい力で動かす、鋭い角をなくす

異常を検知して停止する、遮断弁を閉じる

前提

設計段階で危険源を消せる場合に使える

安全機能を担う部品やソフトの故障も想定する

弱点

コストや機能の制約から、すべてには適用できない

機能が働かないと防げないため、信頼性の裏付けが要る

※機能安全は本質安全の代わりではなく、本質安全で取り除けなかったリスクを下げるための手段として使います。

なぜ機能安全が必要になったのか

日本のものづくりでは長く、部品の信頼性を高めて故障をゼロに近づけることで安全を守ってきました。構成要素に故障やバグがあることを、そもそも前提にしない考え方です。

しかし設備が大型化・複雑化し、制御や安全の仕組みにPLC（プログラマブルコントローラ）などのマイコン系の電子機器が使われるようになりました。そうなると、ハードとソフトが絡み合った予期しない故障が起こり得ます。

構造を細かく決める従来の規格では、マイコンの中身までは規定できません。

そこで、故障は起きるものとして、それでも危険に至る確率を許容範囲に収めるという性能ベースの規格が必要になりました。1970年代以降の欧州のプラント大事故とその後の規制強化が、IEC 61508の制定につながったとされています。

機能安全が扱う2種類の故障

機能安全では、故障を性質の異なる2つに分けて考えます。部品の劣化などで時期を予測できずに起こる「ランダムハードウェア故障」と、仕様の誤りや設計ミス、ソフトのバグが原因の「決定論的原因故障（システマティック故障）」です。

前者は故障率のデータから確率で見積もれますが、後者は統計的に定量化できません。そのためランダム故障は数値目標と診断で、システマティック故障は開発プロセスで防ぐという二本立てで対策します。

この区別を押さえると、規格の要求がなぜ「計算」と「手順」の両方に分かれているのかが見えてきます。

図2：機能安全が扱う2種類の故障

原因が違うので、対策の打ち方も変わります。

ランダムハードウェア故障部品の劣化など、いつ起こるか予測できない故障。故障率から確率で見積もれる。対策は冗長化、自己診断、故障率の低い部品の選定、目標値（PFH・PMHFなど）の計算

決定論的原因故障（システマティック故障）仕様の誤り、設計ミス、ソフトのバグ、手順の不備が原因。確率では表せない。対策は要求の明確化、レビュー、検証、コーディング規約、変更管理など開発プロセスの規律

※ソフトウェアの不具合は劣化しないため、すべてシステマティック故障として扱います。

機能安全規格の体系

機能安全の規格は、1つの親規格から分野ごとの規格が枝分かれする構造になっています。その親にあたるのがIEC 61508で、IECの規格体系の中で機能安全の基本安全規格（Basic safety publication）という位置づけです。

IEC 61508はあらゆる産業で使えるように要求事項を網羅しています。そのため、そのままでは「自社の製品にどの要求をどう当てはめるか」が専門家でないと分かりにくい面があります。

そこで、分野ごとに使いやすく具体化した分野規格や製品規格が作られてきました。

図3：機能安全規格の体系

IEC 61508を親に、分野ごとの規格と製品ごとの規格が作られています。

IEC 61508（JIS C 0508）全産業向けの基本安全規格。E/E/PE安全関連系の基本要求を定める

分野に合わせて具体化

ISO 26262自動車（道路車両）

IEC 61511プロセス産業の安全計装

IEC 62061産業機械の制御系

IEC 62278鉄道

IEC 61513原子力の計装制御

製品規格可変速ドライブ（IEC 61800-5-2）など

※分野規格や製品規格がない製品（プロセス用の温度伝送器など）は、IEC 61508を直接適用します。機械の安全制御ではISO 13849も広く使われます。

たとえば化学プラントでは、安全計装システムを設計・運用する側がIEC 61511を使います。そこに組み込むセンサーや遮断弁などの機器メーカーは、IEC 61508に沿って設計します。

同じ設備でも、立場によって参照する規格が変わる点は押さえておきたいところです。

工場の機械では、制御系の安全性能を定めるISO 13849やIEC 62061が中心になります。協働ロボットの導入で安全機能の性能が問われるのも、この流れの上にあります。

なお医療機器については、IEC 60601シリーズに適合する製品にはIEC 61508を基本安全規格として用いない整理になっています。

IEC 61508の概要

IEC 61508は、電気・電子・プログラマブル電子の安全関連系を対象にした国際規格です。日本では翻訳規格のJIS C 0508が2000年に発行されました。

現在のIEC 61508は2010年発行の第2版で、IECでは次の版の検討が進んでいます。

7部構成

規格は第1部から第7部までで構成されます。第1部から第4部が要求事項の本体で、それぞれ一般要求事項、ハードウェアの要求事項、ソフトウェアの要求事項、用語の定義を定めています。

第5部から第7部は、要求を満たすために使える設計手法や分析手法をまとめたガイドラインです。

実務では、システム全体の進め方は第1部、回路とハードは第2部、ソフトは第3部を中心に読むことになります。担当が分かれていても、第1部の考え方は全員が共有しておく必要があります。

SIL（安全度水準）

IEC 61508の中心にあるのがSIL（Safety Integrity Level、安全度水準）です。安全機能に求める信頼性を4段階で表し、SIL4が最も厳しく、SIL1が最も緩い水準です。

リスク分析の結果から、その安全機能がどれだけリスクを下げる必要があるかを見積もり、必要なSILを割り当てます。

SILには、安全機能が作動を求められる頻度に応じて2種類の数値目標があります。作動要求が年1回以下の「低頻度作動要求モード」では、いざというときに機能しない確率（PFDavg）で評価します。

それより頻繁な場合や常時働き続ける「高頻度作動要求・連続モード」では、1時間あたりの危険側故障の頻度（PFH）で評価します。

図4：SILと目標とする故障の確率・頻度

SILが1つ上がるごとに、許される値は1桁小さくなります。

SIL

低頻度作動要求モード
PFDavg（作動要求時に機能しない平均確率）

高頻度作動要求・連続モード
PFH（1時間あたりの危険側故障頻度）

SIL4

10^-5以上 10^-4未満

10^-9以上 10^-8未満

SIL3

10^-4以上 10^-3未満

10^-8以上 10^-7未満

SIL2

10^-3以上 10^-2未満

10^-7以上 10^-6未満

SIL1

10^-2以上 10^-1未満

10^-6以上 10^-5未満

※出典：厚生労働省委託「機能安全活用テキスト」（中央労働災害防止協会）。数値はランダムハードウェア故障に対する目標で、システマティック故障はSILに応じた開発手法で対処します。

数値目標を満たすには、部品の故障率だけでなく、冗長化の構成、自己診断でどれだけの危険側故障を見つけられるか（診断カバー率）、定期点検の間隔なども効いてきます。

たとえば論理処理部を二重化すると、1台が故障しても安全機能を続けられる構成になります。

全安全ライフサイクル

IEC 61508のもう1つの柱が、構想から廃却までを16のフェーズに分けた「全安全ライフサイクル」です。

概念の検討、対象範囲の定義、潜在危険とリスクの解析から始まり、安全要求の決定と割り当て、安全関連系の実現と続きます。その後、設置と引き渡し、妥当性確認、運用・保全、改造、使用終了までが含まれます。

大切なのは、作って終わりではなく、運用中の保全や改造まで安全を維持する責任が続くという点です。プラントのように複数の企業が関わる場合は、自社がどのフェーズを担当するのかを最初に確認することが実務の第一歩になります。

ISO 26262の概要

ISO 26262は、IEC 61508を道路車両の電気・電子システム向けに適応させた分野規格です。初版は2011年に発行され、対象は量産される車両総重量3,500kgまでの乗用車でした。

2018年12月の第2版では、適用範囲がトラックやバスを含む量産の道路車両（モペッドを除く）に広がり、全10部から12部に増えました。新たに加わったのが、半導体への適用ガイドライン（Part 11）と二輪車向けの適応（Part 12）です。

12部の構成

12部は、管理の仕組み、開発の各段階、それを支える共通プロセス、ガイドラインに大きく分かれます。

開発の段階はシステム、ハードウェア、ソフトウェアと階層ごとに独立したパートになっており、担当者は自分の関わるパートを中心に読み込むことになります。

図5：ISO 26262（2018年版）の12部構成

管理・開発・支援・ガイドの4つの役割に分けると全体がつかみやすくなります。

Part 1 用語

共通規格全体で使う用語と略語の定義

Part 2 機能安全の管理

管理組織の安全文化、プロジェクトの安全計画、確認方策

Part 3 コンセプトフェーズ

開発アイテム定義、ハザード分析とリスクアセスメント、ASILと安全目標、機能安全コンセプト

Part 4 システムレベル

開発技術安全コンセプト、システム設計、統合と試験、安全の妥当性確認

Part 5 ハードウェアレベル

開発回路設計、ハードウェアアーキテクチャの指標、ランダム故障の評価

Part 6 ソフトウェアレベル

開発ソフトの要求、設計、実装、単体・統合テスト

Part 7 生産・運用・廃却

開発量産、運用、サービス、廃却の段階での安全

Part 8 支援プロセス

支援構成管理、変更管理、検証、文書化、ツールの信頼性、既存部品の流用など

Part 9 ASIL・安全指向の分析

支援ASILの分解、要素の共存、従属故障分析、安全分析

Part 10 ガイドライン

ガイド規格全体の考え方と適用例の解説（参考）

Part 11 半導体

ガイド半導体部品への適用ガイドライン。2018年版で追加

Part 12 二輪車

ガイド二輪車への適応。2018年版で追加

※Part 3〜7は、製品開発の各段階をVモデルで結んだ構成になっています。

ASILの決め方

ISO 26262では、SILの代わりにASIL（Automotive Safety Integrity Level、自動車用安全度水準）を使います。

ASILはAからDまでの4段階で、ASIL Dが最も厳しく、ASIL Aが最も緩い水準です。機能安全の要求を適用する必要がないと判断されたものはQM（品質管理）となり、通常の品質管理で対応します。

ASILは、車両の機能が誤動作したときに起こり得る危険な事象ごとに決めます。評価するのは、重大度（S）、遭遇する頻度（E）、ドライバーによる回避のしやすさ（C）の3つです。

たとえば「高速走行中にカーブで必要な操舵がされない」という事象なら、けがの程度、そうした走行状況の頻度、ドライバーが自分で立て直せるかを順に検討します。

図6：ASILを決める3つの評価軸

危険な事象ごとに S・E・C を評価し、組み合わせでASILが決まります。

S / Severity重大度（S0〜S3）起こり得るけがの程度。S0はけがなし、S3は生命に関わる重傷または致命傷

E / Exposure遭遇頻度（E0〜E4）その危険が生じる走行状況にどれだけ置かれるか。E0はほぼあり得ない、E4は高い

C / Controllability制御可能性（C0〜C3）ドライバーなどが危害を回避できるか。C0は一般に制御可能、C3は制御困難または不可能

S3・E4・C3 の組み合わせで最も厳しい ASIL D。S0・E0・C0 のいずれかが含まれると QM（機能安全の要求は不要）

※ASILはアイテム（車両レベルの機能）の危険事象に対して決め、そこから導いた安全要求が各部品に引き継がれます。

解説資料では、エアバッグや電動パワーステアリングがASIL Dの例、エアコンやインフォテインメントがQMの例としてよく挙げられます。

ただし実際のASILは車種の使われ方や機能の設計によって変わるため、部品名だけで決まるものではない点に注意が必要です。

このハザード分析とリスクアセスメント（HARA）は、工場で行うリスクアセスメントと「危険を洗い出し、重さと起こりやすさで評価する」骨格は共通しています。

違うのは、評価の対象が作業者ではなく道路上の人全体で、回避のしやすさという自動車固有の軸が加わる点です。

IEC 61508とISO 26262の違い

ISO 26262はIEC 61508を土台にしています。そのため、故障を2種類に分ける考え方、ライフサイクル全体で安全を管理する姿勢、独立した立場による確認などは共通です。

一方で、自動車の量産とサプライチェーンに合わせて、いくつかの点が大きく変わっています。

図7：IEC 61508とISO 26262の比較

親規格と分野規格の関係ですが、レベルの決め方や対象の範囲が異なります。

IEC 61508

ISO 26262

位置づけ

全産業向けの基本安全規格

IEC 61508を道路車両向けに適応した分野規格

対象

E/E/PE安全関連系（プラント、機械、機器など）

量産の道路車両に搭載されるE/Eシステム（モペッド除く）

現行版

第2版（2010年）、全7部

第2版（2018年）、全12部

安全度のレベル

SIL1〜SIL4（SIL4が最も厳しい）

ASIL A〜D（Dが最も厳しい）、対象外はQM

レベルの決め方

必要なリスク低減量から決める。PFDavg・PFHの数値範囲と対応

危険事象ごとに重大度・遭遇頻度・制御可能性の3軸で決める

ハードの定量指標

PFDavg・PFH、安全側故障割合（SFF）、ハードウェアフォールトトレランス

SPFM・LFM（アーキテクチャ指標）、PMHF（ランダム故障の確率）

想定する生産

個別設計の設備・システムも多い

大量生産と、完成車メーカー・サプライヤー間の分業

ライフサイクル

構想から廃却まで16フェーズ

管理・コンセプト・製品開発・生産・運用を12部で規定

※SILとASILは決め方が異なるため、単純に数字を読み替えることはできません。

SILとASILは読み替えられない

よくある誤解が「ASIL DはSIL3に相当する」といった単純な読み替えです。SILは必要なリスク低減量から決まり、確率の数値範囲と直接結びついています。

ASILは危険事象の重大度、頻度、制御可能性の組み合わせで決まり、そのうえでASILごとに求める手法や目標値が定められています。

産業機器のメーカーが車載分野に参入する場合も、その逆の場合も、「SIL認証品だから車載でも使える」とは限らないことを前提にします。そのうえで、相手の規格で要求を確認し直す必要があります。

サプライヤーとの分担が規格に組み込まれている

自動車は、完成車メーカーを頂点にTier1、Tier2と多くの部品メーカーが分業して作られます。

ISO 26262は顧客とサプライヤーの関係についての要求を含みます。開発を分担する際には、どちらがどの安全活動と成果物に責任を持つかを開発インタフェース合意書（DIA）で取り決めるのが一般的です。

自動車業界のサプライチェーンと商流の中で、部品メーカーは「安全要求を受け取り、根拠となる証拠を返す」立場になります。

受注の段階で機能安全の対応範囲を確認しておかないと、開発の途中で想定外の分析や文書の作成が発生し、工数が膨らむことがあります。

機能安全の開発で求められること

ここからは、ISO 26262を例に、開発の現場で実際に何が変わるのかを見ていきます。IEC 61508でも名前や細部は違いますが、考え方の骨格は同じです。

図8：ISO 26262に沿った開発の流れ

車両レベルの安全目標を、システム・ハード・ソフトの要求へ順に落とし込み、逆の順で確かめます。

コンセプト（Part 3）

01アイテム定義対象とする車両機能と、その境界・前提条件を決める

02HARA危険事象を洗い出し、S・E・CからASILと安全目標を決める

03機能安全コンセプト安全目標を守るための機能安全要求を導き、構成要素に割り当てる

製品開発（Part 4〜6）

04技術安全コンセプト検出・診断・安全状態への移行など、技術的な仕組みに具体化

05ハード・ソフト開発要求に沿って設計し、安全分析と指標の評価を行う

06統合・検証ソフト→ハード→システム→車両と組み上げながら試験する

仕上げと量産以降（Part 4・7）

07安全の妥当性確認車両レベルで安全目標が達成されていることを確かめる

08機能安全アセスメント独立した立場から、達成された機能安全を評価する

09生産・運用・廃却量産工程や市場での保守でも安全を維持する

※Part 2の安全管理と、Part 8の構成管理・変更管理・文書化は、全段階を通して並行して行います。

要求を上から下までつなぐ

機能安全の開発では、車両レベルの安全目標から、機能安全要求、技術安全要求、ハードとソフトの要求へと段階的に具体化していきます。そしてVモデルの右側で、それぞれの要求が満たされたことを試験で確かめます。

このとき求められるのが、どの要求がどの設計に反映され、どの試験で確認されたかを追える状態（トレーサビリティ）です。組込みソフトの開発の流れ自体は大きく変わりませんが、要求とテストの対応を記録として残す作業が格段に増えます。

安全分析で弱点を先に見つける

設計の各段階では、故障したときに安全目標がどう破られるかを分析します。下から積み上げる帰納的な手法としてFMEA、上から原因をたどる演繹的な手法としてFTAがよく使われ、両方を組み合わせて抜け漏れを防ぐのが一般的です。

手法そのものは品質管理で使うFMEAの進め方と共通する部分が多くあります。ただし機能安全では、「その故障は安全機構で検出できるか」「検出して安全状態に移るまでの時間は足りるか」まで踏み込みます。

さらに、1つの原因で冗長化した2系統が同時に壊れる共通原因故障がないかも確認します。

ハードウェアは数値で示す

ハードウェアでは、ランダム故障に対する設計の強さを次の3つの指標で示します。

• SPFM（単一点故障メトリック）：安全機構で守られずに直接危険につながる故障の少なさ
• LFM（潜在故障メトリック）：潜在故障への備え
• PMHF：ランダムハードウェア故障で安全目標が破られる確率

ISO 26262-5（ハードウェアレベル）では、これらの目標値の目安がASILごとに示されています。

ASIL Dでは、SPFMが99%以上、LFMが90%以上、PMHFが10FIT（1FITは10億時間に1回の故障）未満です。ASIL B・Cでは緩く、ASIL Aには定量的な目標値がありません。

ASILが上がるほど自己診断の網羅性と部品の故障率データの精度が問われます。

ソフトウェアはプロセスで守る

ソフトウェアの不具合はシステマティック故障なので、確率では評価しません。代わりに、ASILに応じて推奨される手法を開発の各段階で使います。例えば次のような手法です。

• コーディング規約の順守
• 設計の静的解析
• 要求に基づくテスト
• 構造的なカバレッジの測定

開発に使うツールの信頼性も対象になります。コンパイラやテストツールの誤りが不具合を見逃す原因になり得るため、ツールをどう使い、どう確かめたかも説明できるようにしておきます。

独立した確認と文書で説明できるようにする

機能安全では、作った本人以外が確認する仕組みが規格で定められています。

ISO 26262では、成果物の確認レビュー、プロセスの監査、機能安全アセスメントといった確認方策があります。ASILが高いほど、設計に関与していない人・部門・組織による確認が求められます。

最終的には、分析結果、試験結果、レビュー記録などの証拠を束ね、「なぜこの製品は十分に安全と言えるのか」を論理立てて示すセーフティケースにまとめます。文書を作ること自体が目的ではなく、第三者が読んで安全の根拠をたどれることが目的です。

組織の仕組みと安全文化

Part 2では、個別のプロジェクトより前に、組織として機能安全を管理する仕組みを求めています。主な内容は次のとおりです。

• 安全に関する問題を隠さず報告できる安全文化
• 担当者の力量の確保
• 品質マネジメントシステムの整備
• プロジェクトごとの安全計画の作成

そのため機能安全の導入は、設計部門だけでは完結しません。品質保証、生産技術、調達も含めた全社の取り組みとして、機能安全の責任者を決め、既存の開発プロセスとの差分を洗い出すところから進めることになります。

SOTIF・サイバーセキュリティと今後の改訂

ISO 26262が扱うのは、あくまで電気・電子システムの「故障」に起因するリスクです。ところが自動運転や運転支援では、何も故障していないのに、センサーが逆光で歩行者を見落とす、想定外の道路状況で判断を誤るといった危険が起こり得ます。

こうした機能の仕様や性能の不足によるリスクを扱うのが、2022年6月に発行されたISO 21448（SOTIF：意図した機能の安全性）です。

また、外部からの攻撃に備える車両のサイバーセキュリティについては、2021年8月にISO/SAE 21434が発行されました。

故障（ISO 26262）、性能の限界（ISO 21448）、攻撃（ISO/SAE 21434）という3つの視点があります。これらを組み合わせて安全を考えるのが、今の車載開発の姿です。

規格自体も改訂に向けて動いています。ISOのサイトでは、ISO 26262の各部が改訂予定とされ、次の版の原案が作成段階にあります。

認証機関の解説では、機械学習を使ったソフトウェアへの適用、故障しても機能を続けるフェールオペレーショナルな構成、SOTIFとの整合などが論点に挙げられています。

IEC 61508も次の版の作成が進んでいます。現行版で仕組みを作りつつ、改訂の動向を追っておくことが求められます。

まとめ

機能安全は、特別な部署だけの仕事ではなく、要求を決める人から試験をする人、量産を支える人までが同じ考え方を共有して初めて成り立ちます。

関連する職種としては組込みエンジニアに求められるスキルとキャリアや電気・電子設計の仕事内容、組織的な仕組みづくりでは品質保証の役割とも深く関わります。

自社の製品がどの規格の対象になり、どのレベルが求められるのかを確認するところから、まずは全体像をつかんでいきましょう。

出典

出典・参考資料（15件）を開く出典・参考資料を閉じる

• 機能安全の定義・規格の体系・IEC 61508の構成と全安全ライフサイクル：日本電気計測器工業会（JEMIMA）「機能安全規格の技術解説」（2013年11月）
• SILとPFDavg・PFHの対応：厚生労働省委託 中央労働災害防止協会「機能安全活用テキスト」（平成29年2月）
• IEC 61508-1の版と発行日：IEC Webstore「IEC 61508-1:2010」
• ISO 26262の適用範囲・IEC 61508との関係・ASILの定義・第2版の主な変更点（半導体ガイダンス、二輪車要求の追加）：ISO 26262-1:2018 プレビュー（iTeh Standards）
• ISO 26262第2版の発行時期と改訂予定・次版の作成状況：ISO「ISO 26262-10:2018」
• 第2版の発行時期と適用範囲の拡大：Jama Software「ISO 26262 Second Edition Introduces Updates」
• S・E・Cの区分とASILの例：Jama Software「What Is ASIL?」
• コンセプトフェーズの手順とハザードの例：日本自動車研究所「自動運転システム安全設計 第3報」JARI Research Journal（2016年10月）
• 踏切と立体交差の例：日本品質保証機構（JQA）「ISO NETWORK Vol.22」
• ハードウェア指標（SPFM・LFM・PMHF）の目標値：Chalmers University of Technology 修士論文「Implementing ISO 26262-5」（2023年）
• PMHFの目標値：G. Schildbach「On the Application of ISO 26262 in Control Design for Automated Vehicles」EPTCS 269（2018年）
• ISO 21448の発行時期と定義：ISO「ISO 21448:2022」
• ISO/SAE 21434の発行時期：ISO「ISO/SAE 21434:2021」
• ISO 26262次版の論点：UL Solutions「What to Expect with Version 3 of ISO 26262」（2024年1月）
• IEC 61508次版（第3版）の原案：oSIST prEN IEC 61508-3:2025 プレビュー（iTeh Standards）