概要
ISO26262とは、自動車の電子システムの機能安全についての国際規格です。機能安全とは、安全対策によって、許容できないリスクから免れるための技術の総称です。
ISO26262は、IEC61508で国際規格化されていた機能安全の考え方を自動車産業に導入するために2011年に作成されました。3.5トン以下の乗用車が対象となりますが、2018年の第２版では二輪車が適用範囲に含まれるようになりました。
国際規格
安全に関する国際規格の体系は以下になります。
| ［Ａ規格］ 基本安全規格 |
広範囲の製品、プロセス及びサービスに適用する一般的な安全に関する基本概念、原則及び要求事項 | ISO12100：機械類の安全性 ISO14121：リスクアセスメントの原則 |
| ［Ｂ規格］ グループ安全規格 |
いくつかの類似の製品、プロセス及びサービスに適用する安全を含む規格 | IEC61508：プログラマブル電子制御システムの安全性、他 |
| ［Ｃ規格］ 製品安全規格 |
特定の製品、プロセスまたはサービスの安全を含む規格 | ISO26262：自動車、 IEC62278：鉄道、他 |
国際規格での安全とは、一般的な感覚でのリスクが存在しないということではなく、対象となるリスクが安心して受け入れられる程度に抑制された状態を指します。安全規格の目的は、安心して受け入れられる程度にまでリスクを抑制することです。
安全の考え方
受容可能と許容可能
受容可能なリスクとは、誰がどのような状況でも受け入れることができるリスクで、受容不可能なリスクとは、どのような状況であっても受け入れることができないリスクです。受容可能なリスクと受容不可能なリスクの中間のリスクは、「受容不可能でないリスク」と呼ばれます。
一方、許容可能なリスクとは、特定の条件下で受け入れることができるリスクで、許容不可能なリスクとは、特定の条件下で受け入れることができないリスクです。これらは、「受容不可能でないリスク」の領域に存在します。
| 危険側 ↑ ↓ 安全側 |
受容不可能なリスク | |
| 受容不可能でないリスク | 許容不可能なリスク | |
| 許容可能なリスク | ||
| 受容可能なリスク | ||
許容可能なリスクは、社会における現時点での評価に基づいた状況下で受け入れられるリスクです。同じ程度のリスクでも、その対象の利便性や費用対効果、その時代や地域における安全に対する価値観などのバランスにより異なることがあります。
ALARP
ALARP（As Low As Reasonably Practicable）とは、合理的に実施可能な限りリスクを下げるという考え方です。これは、安全のためにいくらでもコストを掛けるという意味ではなく、適切な価格を維持できる現実的な範囲での最大限の努力により、製品の安全性を確保するという意味になります。
また、ISO26262では「State of the Art」という言葉があり、これはその社会での法令や規格などに基づき、安全の責任を果たすために必要な最低ラインという意味で捉える必要があります。
リスクの低減
リスクの低減の方法には以下の３つがあります。
- 本質的安全設計
危険源のリスクを直接的に低減するもので、リスク低減の中で最も優先して取り組むものです。道路の横断歩道を例を取ると、道路を高架にして横断歩道を無くする対策が相当します。 - 付加的保護方策
本質的安全設計を行った後、または、本質的安全設計が適用できないリスクに対する対策で、安全機能によって危険源を回避するという考え方です。道路の横断歩道を例を取ると、横断歩道に信号機を付ける対策が相当します。 - 使用上の情報
本質的安全設計と付加的保護方策を行っても残ったリスクに対しては、製品の使用者に適切に周知する必要があります。道路の横断歩道を例を取ると、横断歩道付近の注意書きや子供への教育などの対策が相当します。
ASIL
SIL（Safety Integrity Level）とは、機能安全で要求される安全レベルで、ASIL（Automotive SIL）とは自動車版のSILです。
ASILは、重大度（Severity）、暴露可能性（Exposure）、回避可能性（Controllability）よりＡからＤの４段階が決定され、Ｄが最も厳しくなります。これらの他に安全に関する要求が存在しないQM（Quality Management）があり、この場合は品質管理に基づいた対応が求められます。
- 重大度（S）
S0 S1 S2 S3 負傷なし 軽傷か中程度の負傷 重症であるが
命に別状はない致命的な重症 - 暴露可能性（E）
E0 E1 E2 E3 E4 可能性がない 可能性が非常に低い 可能性が低い 可能性が中程度 可能性が高い - 回避可能性（C）
C0 C1 C2 C3 一般的に回避可能 容易に回避可能 通常は回避可能 回避困難または
回避不能
ASILは以下のように決定されます。
| ASILの決定 | C1 | C2 | C3 | |
| S1 | E1、E2 | QM | QM | QM |
| E3 | QM | QM | ASIL A | |
| E4 | QM | ASIL A | ASIL B | |
| S2 | E1 | QM | QM | QM |
| E2 | QM | QM | ASIL A | |
| E3 | QM | ASIL A | ASIL B | |
| E4 | ASIL A | ASIL B | ASIL C | |
| S4 | E1 | QM | QM | ASIL A |
| E2 | QM | ASIL A | ASIL B | |
| E3 | ASIL A | ASIL B | ASIL C | |
| E4 | ASIL B | ASIL C | ASIL D | |
尚、異なるASILのエレメントが共存する場合、全体としては厳しい方のASILが適用されます。
章構成
ISO26262は、コンセプトフェーズ、システムレベルの製品開発、ソフトウェアレベルの製品開発、支援プロセスなど11の章から構成されます。
機能安全の管理
機能安全で要求される概念を以下に挙げます。
- 安全ライフサイクル
製品のコンセプトから開発、生産、運用、廃棄に至る製品のライフサイクル全体を通じて行う安全管理のサイクルです。 - 安全文化
組織の掲げた安全の方針や目的に向かって順守しなければならない安全活動が、共通の理解や活動として組織に定着することです。 - テーラリング
機能安全規格で定められている活動を、対象となる組織やプロジェクトに合わせて仕立て直す（テーラリング）ことを指します。 - セーフティケース
安全を主張するためのエビデンス（根拠となる成果物）の総称です。対象アイテムのASILに対して、１つ以上のセーフティゴールが含まれるセーフティケースが必要になります。 - コンファメーションメジャー
安全ライフサイクルを通じて安全を保証するための活動で以下が含まれます。
– コンファメーションメレビュー（成果物の評価）
– 機能安全監査（プロセスの評価）
– 機能安全アセスメント（機能安全への適合性の評価）
コンセプトフェーズ
コンセプトフェーズでは、アイテム（開発対象）に想定されるハザードを分析し、達成すべきセーフティゴールとASILを定め、機能安全コンセプトを設定します。コンセプトフェーズの流れは以下になります。
- アイテムの定義
- ハザード分析（HA：Hazard Analysis）
- リスクアセスメント（RA：Risk Assessment）
- 機能安全コンセプトの設定
リスクアセスメントとリスク低減は開発サイクルの中で反復的に行われる必要があります。
アイテムの定義
アイテム（安全対策の対象）の範囲と制約を決定し、使用状況や使用方法を分析します。全てのリスクを想定しての対策は難しいため、対象製品に対して安全上の制約を設け、現実的な対策を行う必要があります。
ハザード分析
ハザード分析には、FMEA（Failure Mode and Effects Analysis）やHAZOP（Hazard and Operability Studies）などが利用されます。ハザードとは、人に害を及ぼす可能性のある故障や誤動作です。
リスクアセスメント
抽出されたハザードについてリスクアセスメントを実施します。リスクの大きさとは、危害の重大度と発生可能性の組み合わせとして定義されます。ハザードを危害の重大度、暴露可能性（発生頻度）、回避可能性の３つの観点から評価し、ASILを決定します。
併せて、ハザードイベントに対するセキュリティゴール（Safety Goal）を設定します。セキュリティゴールは車両レベルで検討されます。
機能安全コンセプトの設定
機能安全コンセプトでは、セーフティゴールに基づいて、安全方策を含めたセーフティメカニズムを定義します。そして、安全方策（Safety Measures）とセーフティメカニズムを実現するための機能安全要求（Functional Safety Requirements）を設定します。
システムレベルの製品開発
システムレベルの製品開発の流れは以下になります。
- 技術的安全要求の設定
コンセプトフェーズでの機能安全要求をシステムレベルの技術的安全要求（Technical Safety Requirements）に詳細化する。 - システム設計
技術的安全要件を含めたシステム要求仕様に基づきシステム設計を行う。 - アイテムの統合とテスト
システム設計が安全要件を網羅していることを確認する。 - 安全妥当性確認
安全方策（Safety Measures）の妥当性を確認する。
技術的安全要件を検討する上でポイントは以下になります。
- セーフティメカニズム（Safety Mechanism）
- ASILデコンポジション
セーフティメカニズム
セーフティメカニズムとは、ハードウェアやソフトウェアなどの仕組みにより、障害を検出し、故障を制御し、警告を発してリスクを回避する技術的解決策です。セーフティメカニズムを検討する上でのポイントは以下になります。
- 診断テスト期間（Diagnostic Test Interval）：障害発生から障害検出までの時間
- 障害応答時間（Fault Response Time）：障害検出から安全状態までの時間
- 障害耐性間隔（Fault Tolerance Interval）：障害発生からハザードイベントまでの時間
機能安全としては、障害が発生してハザードイベントに至るまでに、障害を検出して安全状態に復旧させる必要があります。従って以下の関係があります。
| 診断テスト期間 ＋ 障害応答時間 ＜ 障害耐性間隔 |
併せて、以下の観点について検討する必要があります。
- 安全状態への移行方法
- 安全状態を維持する方法
ASILデコンポジション
ASILデコンポジションとは、開発対象を構成するエレメントの独立性に基づいて、ASILの減免を行う手法です。基本的に異なるASILのエレメントが共存する場合は、全体としては厳しい方のASILが適用されますが、条件によりASILの減免が可能になります。
ハードウェアレベルの製品開発
ハードウェアレベルの製品開発の流れは以下になります。
- ハードウェア安全要求仕様
システムレベルの技術的安全要求（Technical Safety Requirements）とシステム設計仕様に基づきハードウェアとしての安全要求仕様を作成する。 - ハードウェア設計
システム設計仕様とハードウェア安全要求仕様に基づきハードウェアを設計する。 - ハードウェアアーキテクチャメトリックの評価
セーフティゴールの逸脱につながるハードウェアの偶発的故障を評価する。 - セーフティゴール逸脱の評価
ハードウェアの偶発的故障によるセーフティゴール逸脱の残存リスクが十分に低いことの理論的根拠となる基準の設定する。
尚、障害と故障の言葉の定義は以下になります。
- 障害（Fault）
本来の機能や状態から逸脱させることにつながる異常な状態（原因） - 故障（Failure）
本来の機能や性能を逸脱した状態（結果）
ハードウェアアーキテクチャメトリックの評価
ハードウェアアーキテクチャメトリックとは、ハードウェアの偶発的故障に対するハードウェアアーキテクチャの堅牢性（ロバスト性）を評価するための指標です。ハードウェア障害には以下の種類があります。
| シングルポイント障害 （Single Point Fault） |
$S$ | 単一でセーフティゴールを逸脱する障害 |
| マルチポイント障害 （Multi Point Fault） |
$M$ | 複数の障害の組み合わせでセーフティゴールを逸脱する障害（$M=M_D+M_P+M_L$） |
| 検出可能なマルチポイント障害 （Detected Multi Point Fault） |
$M_D$ | セーフティメカニズムで検出可能なマルチポイント障害 |
| 検知可能なマルチポイント障害 （Perceived Multi Point Fault） |
$M_P$ | ドライバにより検知可能なマルチポイント障害 |
| 潜在的マルチポイント障害 （Latent Multi Point Fault） |
$M_L$ | セーフティメカニズムやドライバにより検出・検知できないマルチポイント障害 |
| 安全障害 | $A$ | セーフティゴールの逸脱に至らない障害 |
| 全体の障害率 | $F$ | （$F=S+M+A$） |
ハードウェアアーキテクチャメトリックは、以下の定義に基づいて計算されます。
- シングルポイント障害メトリクス（SPFM、Single Point Fault Metrics）
シングルポイント障害に対する堅牢性を示す指標$$\mathrm{SPFM}=1-\frac{S}{F}=\frac{M+A}{F}$$ASIL A B C D SPFM － 90％以上 97％以上 99％以上 - 潜在障害メトリクス（LF、Latent Failure Metrics）
潜在障害に対する堅牢性を示す指標$$\mathrm{LF}=1-\frac{M_L}{F-S}=\frac{M_D+M_P+A}{F-S}$$ASIL A B C D LF － 60％以上 80％以上 90％以上
セーフティゴール逸脱の評価
ハードウェアの偶発的故障によるセーフティゴール逸脱の可能性対する定量的目標値は以下になります。目標値は、対象の運転時間当たりの故障の平均確率で表されます。
| ASIL | A | B | C | D |
| 故障率 | － | $10^{-7}/h$ 以下 | $10^{-7}/h$ 以下 | $10^{-8}/h$ 以下 |
尚、シングルポイント障害については、ハードウェア部品のレベルで評価する必要があります。シングルポイント障害が受容可能であることを示すため、以下の故障率クラスを満たす必要があります。
| ASIL | A | B | C | D |
| 故障率クラス | － | 故障率クラス１ ＋安全対策 |
故障率クラス２ ＋安全対策、または 故障率クラス１ |
故障率クラス２ ＋安全対策、または 故障率クラス１ |
ここで、故障率クラスの目標故障率は以下で定義されます。
| 故障率クラス１ | 故障率クラス２ | 故障率クラス３ | 故障率クラス４ | 故障率クラス５ |
| $10^{-10}/h$ 未満 | $10^{-9}/h$ 以下 | $10^{-8}/h$ 以下 | $10^{-7}/h$ 以下 | $10^{-6}/h$ 以下 |
ソフトウェアレベルの製品開発
ソフトウェアレベルの製品開発の流れは以下になります。
- ソフトウェア安全要求仕様
システムレベルの技術的安全要求（Technical Safety Requirements）とシステム設計仕様に基づきソフトウェアとしての安全要求仕様を作成する。 - ソフトウェアアーキテクチャ設計
システム設計仕様とソフトウェア安全要求仕様に基づきソフトウェアアーキテクチャを設計する。 - ソフトウェアユニット設計と実装
ソフトウェア安全要求仕様とソフトウェアアーキテクチャ設計に基づきソフトウェアユニットの設計を行う。 - ソフトウェアユニットテスト
ソフトウェアユニット設計が正しく実装されていることを確認する。 - ソフトウェア統合とテスト
ソフトウェアアーキテクチャ設計が正しく実装されていることを確認する。 - ソフトウェア安全要件の検証
ソフトウェア安全要求仕様が正しく実装されていることを確認する。
