ISO 26262が規定する要求事項

（独）産業技術総合研究所

水口大知

ISIT第9回カーエレクトロニクス研究会 2011/10/14

Agenda

• ISO 26262の概要

• フィロソフィー

Ⅰ．「プロセス指向」

Ⅱ．「安全ゴール指向」

Ⅲ．「説明（力）指向」

• まとめ／IEC 61508との比較

ISO 26262とは

• ISO 26262は、車載の安全関連E/Eシステムの開発・運用ガイドライン

– IEC 61508 「電気・電子・プログラマブル電子安全関連系の機能安全」のアダプテーション

–システマティック故障およびランダムハードウェア故障によるリスクを回避するための要求事項を規定

自動車向け規格としての目的

• 自動車安全ライフサイクル（マネジメント、開発、製造、運用、サービス、廃棄）を不える。ライフサイクルフェーズで必要なアクティビティのテーラリングを支援する

• 自動車安全度水準(ASIL)を決定するためのリスクベースアプローチを不える

• 丌合理な残留リスクを回避するための要求事項をASILに応じて不える

• 十分なレベルの安全達成を確実にするための、妥当性確認(validatoin)および確認方策(confirmation measures)に対する要求事項を不える

• サプライヤとの関係についての要求事項を不える （Introductionより）

構成

フィロソフィー

Ⅰ．「プロセス指向」

Ⅱ．「安全ゴール指向」

Ⅲ．「説明（力）指向」

Ⅰ．「プロセス指向」

• 各節がひとつのプロセスに対応

• 統一された小見出し

• 例えば、 Part 3. 5 Item definition

– 5.1 Objectives

– 5.2 General

– 5.3 Inputs to this Clause

• 5.3.1 Prerequisites

• 5.3.2 Further supporting information

– 5.4 Requirements and recommendations

– 5.5 Work products

ライフサイクルフェーズと成果物フロー ②

③

④

④

⑤

⑥

⑦

・安全LC ・安全文化 ・コンピテンス管理 ・品質管理 ・安全LCのテーラリング（PJ非依存の）

・安全マネジメントの役割・責任 ・安全計画／調整 ・アクティビティのテーラリング ・安全ケース ・確認方策（レビュー、オーディット、アセスメント）／独立性

・責任／計画 ・フィールドモニタリング ・変更時

②機能安全マネマネジメント

・機能／非機能要件 ・独立性 ・境界／インターフェース／仮定 ・開発カテゴリ決定

・インパクト解析／安全LC修正（修正時）

・状況分析／ハザード同定 ・ハザーダスイベントの分類 ・ASIL、安全ゴールの決定 ・検証

・機能安全要求の導出 ・機能安全要求の割り当て／ASIL分解 ・妥当性確認基準 ・検証

③コンセプトフェーズ

・技術安全要求仕様 ・安全メカニズム ・ASIL分解 ・潜在フォールトの回避 ・製造／運用／廃棄時 ・仕様の検証

・技術安全要求のシステム設計エレメントへの割り当て ・システマティック故障の回避方策 ・ランダムハードウェア故障の検出／制御／緩和 方策 ・HW、SWへの割り当て／インターフェース

・システムレベルの安全計画（手法・方策を含む） ・妥当性計画策定 ・アセスメント計画策定

④システム開発

・HWレベルの安全計画（手法・方策を含む） ・HWコンポーネントの再利用、検定済コンポーネントの利用

・HW安全要求仕様 ・故障への対処メカニズムと関連属性 ・安全メカニズムによらない安全要求 ・設計検証の基準

・HWアーキテクチャ設計 ・HW詳細設計 ・安全分析 ・HW設計の検証 ・製造／運用／廃棄

⑤ハードウェア開発

・診断カバレッジ ・部品の故障率 ・SPFM ・LFM

・PMHFの推定 または ・各故障の影響評価

・テストケース導出 ・HW統合テスト ・HW安全要求に対する 安全メカニズム実装の正しさ ・外部ストレス下のロバスト性

⑤ハードウェア開発

・SWレベルの安全計画（手法、ツール、言語の選択、ガイドラインを含む）

・記法の選択 ・アーキテクチャ設計原則 ・静的／動的側面 ・開発カテゴリ（再利用かどうか） ・検定済コンポーネントの利用 ・コンポーネントパーティショニング ・安全分析 ・エラー検出／対処 メカニズム ・リソース見積り ・設計検証

・記法の選択 ・設計／実装 原則 ・設計／実装 検証

⑥ソフトウェア開発

・SW安全要求仕様 ・ASIL分解 ・HW-SWインターフェース ・仕様の検証

・テスト計画 ・テスト手法の選択 ・テストケースの導出 ・要求カバレッジ ・構造カバレッジ ・テスト環境

・ソフトウェア統合計画 ・テスト手法の選択 ・テストケースの導出 ・要求カバレッジ ・構造カバレッジ ・テスト環境 ・検証計画

・テスト環境 ・検証結果の評価

⑥ソフトウェア開発

・統合およびテスト計画 ・テストケースの導出 ・HW-SW・システム・車両レベルでのテスト ・技術安全要求が正しく 実装されていること ・安全メカニズムの性能、 タイミングのテスト ・外部／内部インターフェース ・安全メカニズムの診断カバレッジ ・ロバスト性

・安全ゴールの妥当性確認 ・PMHFの評価 ・SMPM, LFMの評価

・機能安全アセスメントの実施（アイテムが達成する機能安全の評価）

・製品リリース基準

④システム開発

・製造計画 ・事前品プロセスと製品プロセスのギャップ分析 ・製造プロセスアセスメント

・運用／サービス／廃棄計画 ・ユーザーへの情報（マニュアルを含む） ・フィールドモニタリング ・変更管理

⑦製造・運用

安全ライフサイクル

Ⅱ．「安全ゴール指向」

• 安全ゴールとは、ハザード分析・リスクアセスメントの結果として得られる、トップレベルの安全要求

• 安全ゴールは、対応するハザーダスイベントのASILを継承する

例（第10部第10節より）

• アイテム定義

–アクチュエータを備えたシステム

–ダッシュボードスイッチによる運転者からの要求によってトリガーされる

–車両が速度0km/hの場合には快適な機能を提供する

– 15km/hを超える場合にアクティベートされた場合ハザードを引き起こす可能性がある

Command to the

actuator

Driver's request

Vehicle speed

VS ECU

Actuator

control ECU

Item

Perimeter

Actuator

• 初期アーキテクチャ

• エレメントの目的（初期アーキテクチャ） – VS ECUは、AC ECUへ、車両速度を不える

– AC ECUは、 • 運転者の要求をモニタする

• 車両速度が15km/h以下であることをテストする

• 車両速度が15km/h以下であればアクチュエータをパワーオンする

– アクチュエータは、パワーオンされたときに、アクティベートされる

• ハザード分析・リスクアセスメント

–考慮する故障：運転者の要求のあり・なしに関わらず、15km/hを超える速度で走行中に、アクチュエータがアクティベートされること

– このハザーダスイベントに伴うASILは、Cと評価されたとする

• 安全ゴール

–車両速度が15km/hを上回っているときに、アクチュエータはアクティベートされてはならない

– ASIL C

（ASIL決定表）

• 機能安全コンセプト

–要求A1: VS ECUは、AC ECUへ正確な車両速度情報を送らなければならない。ASIL C

–要求A2: AC ECUは、車両速度が15km/h以下のときに限って、アクチュエータをパワーオンしなければならない。ASIL C

–要求A3: アクチュエータは、AC ECUによってパワーオンされたときに限って、アクティベートされなければならない。ASIL C

ASIL分解

• アイテムの安全コンセプト （発展）

–開発者は、冗長なエレメントの導入を選択できる

–冗長エレメントとして安全スイッチを導入することにより、AC ECUは、ASIL分解の結果に従って、ASIL Cよりも低いASILで開発することができる。

Command to the

actuator

Driver's request

Vehicle speed

VS ECU

AC ECU

Item

Perimeter

Safety Switch Actuator

• エレメントの目的（発展アーキテクチャ）

– VS ECUは、AC ECUへ、車両速度を不える

– AC ECUは、ドライバーの要求をモニタし、車両速度が15km/h以下であることをテストし、もしそうならアクチュエータに指示する。

–安全スイッチは、AC ECUおよびアクチュエータの間のパワーライン上にある。パワーラインの状態によらず、車両の速度が15km/h以下ならスイッチオンし、速度が15km/hを超過するならスイッチオフする

• このスイッチの電源供給は独立である

–アクチュエータは、パワーオンされたときのみ、動作する

• 機能安全コンセプト – 要求B1: VS ECUは、正確な車両速度情報をAC ECUへ送らなければならない。ASIL C • または：15km/h以下の車両速度情報の意図しない伝達は、防止されなければならない。ASIL C

– 要求B2: AC ECUは、車両速度が15km/h以下のときに限り、アクチュエータをパワーオンしなければならない。ASIL X (次頁の表）

– 要求B3: VS ECUは、正確な車両速度情報をスイッチへ送らなければならない。ASIL C

– 要求B4: スイッチは、車両速度が15km/hを上回るとき、開状態でなければならない。ASIL Y(次頁の表)

– 要求B5: アクチュエータは、AC ECUによってパワーオンされ、かつ、安全スイッチが閉のときに限って、動作しなければならない。ASIL C

– 要求B6: AC ECUおよび安全スイッチは、独立に実装されなければならない。ASIL C

要求 B2: ASIL X 要求 B4: ASIL Y

可能性1 ASIL C(C) QM(C)

可能性2 ASIL B(C) ASIL A(C)

可能性3 ASIL A(C) ASIL B(C)

可能性4 QM(C) ASIL C(C)

Ⅲ．「説明（力）指向」

• 「エビデンス」

–～のエビデンスを不えなければならない。

• 「クライテリア」

–～のクライテリアを不えなければならない。

• 「ラショナール」

–～のラショナールを不えなければならない。

「エビデンス」 • Introduction

– 安全は将来の自動車開発におけるキーイシューの一つである。新しい機能性は、システム安全エンジニアリングの領域に踏み込んできている。こうした機能性の開発・統合は、安全なシステム開発プロセスの必要性、および、すべての合理的なシステム安全の目的が達成されたことのエビデンスを不えることの必要性を強化するだろう。

• 2-5.5.2 （全体の安全マネジメント） – コンピテンスのエビデンス

• 2-5.5.3 （全体の安全マネジメント） – 品質マネジメントのエビデンス

• 2-7.5.1 （リリース後の安全マネジメント） – フィールドモニタリングのエビデンス

• 4-6.4.6.1 （技術安全要求仕様） – 技術安全要求は・・・検証されて、以下に対するエビデンスを不えなければならない。 • a) 機能安全コンセプトに対する適合と一貫性 • b) 初期アーキテクチャ設計の仮定に対する適合性

• 4-8.4.1.2 （アイテム統合およびテスト） – 統合およびテスト戦略は・・・テストの目的が十分にカバーされたことのエビデンスを不えなければならない。

• 4-9.1 （安全妥当性確認） – 第1の目的は、安全ゴールが満たされており、機能安全コンセプトがアイテムの機能安全にとって適切であることのエビデンスを不えることである。

– 第2の目的は、安全ゴールが正しく、完全であり、車両レベルで達成されていることのエビデンスを不えることである。

「クライテリア」

• 3-8.4.4.1(機能安全コンセプト)アイテムの安全妥当性確認の受け入れクライテリアは、機能安全要求に基づいて規定されなければならない。

• 5-6.4.6 （ハードウェア安全要求仕様） アイテムまたはエレメントのハードウェア設計検証のクライテリアは、環境条件、運用条件およびコンポーネントに特有の要求を含めて、規定されなければならない。

• 6-5.4.6 （ソフトウェア開発の開始） 適切なモデリングまたはプログラミング言語を選択する場合に考慮すべきクライテリアは、以下である。

– a) 曖昧さのない定義

– b) 組込みリアルタイムソフトウェアおよびランタイムエラー処理に対するサポート

– c) モジュール化、抽象化、構造化に対するサポート

言語による対応が十分でないクライテリアは、ガイドラインまたは開発環境によってカバーされなければならない。

「ラショナーレ」 • 1-4.1 （適合のための要求事項：一般）

– ISO 26262への適合を主張する場合は、以下のいずれかでない限りは、すべての要求事項に適合しなければならない。

– a) 安全アクティビティのテーラリングが、この規格に沿って計画され、要求事項が当てはまらないことが示される。または、

– b) 適合しないことのラショナーレがある。

• 1-4.2 （適合のための要求事項：表の解釈） – 表に列挙される手法は、対応する要求事項への適合の達成におけるコンフィデンスのレベルに寄不する。

– ・・・列挙されている手法以外のものを適用する場合には、それが対応する要求事項を満足するということのラショナーレが不えられなければならない。

• 2-6.4.5.1 （コンセプトフェーズおよび製品開発での安全マネジメント）

–特定のアイテム開発において、安全アクティビティは、テーラリング（つまり省略、または、異なる方法で実施）することができる。

– テーラリングされる場合は、

• a) 当該テーラリングは、安全計画で定義されなければならない。および、

• b) 当該テーラリングが、機能安全を達成する上で、適切かつ十分であることのラショナーレがなければならない。

• 3-7.4.3 （ハザード分析およびリスクアセスメント）

–潜在的危害の重篤度は、ハザーダスイベントに対して、定義されたラショナーレに基づいて、評価されなければならない。

• 5-7.4.3.3 （安全分析） – この要求事項は、ASIL (B)、CおよびDの安全ゴールに適用する。

– シングルポイント故障を回避するための安全メカニズムの有効性の証拠がなければならない。

– NOTE 3 FMEAまたはFTA等の分析を用いて、ラショナーレを組み立てることができる。

• 5-7.4.3.4 （安全分析） – この要求事項は、ASIL (B)、CおよびDの安全ゴールに適用する。

– 潜在故障を回避するための安全メカニズムの有効性の証拠がなければならない。

– NOTE 3 FMEAまたはFTA等の分析を用いて、ラショナーレを組み立てることができる。

• 6-9.4.5 （ソフトウェア単体テスト）

– テストケースの完全性を評価し、意図しない機能がないことを立証するために、ソフトウェア単体レベルでの、要求のカバレッジを測定しなければならない。

–達成された構造カバレッジが丌十分であるとみなされる場合には、追加のテストケースを規定するか、または、ラショナーレを不えなければならない。

安全ケース

• 安全ケースとは、アイテムに対する安全要求が完全であり、かつ、満足されているということを、開発における安全活動の成果物からまとめたエビデンスによって主張すること

• 目的：

–安全ケースは、特定のコンテキストで運用されるシステムが、非合理的なリスクを伴わないということの、明確で包括的でディフェンス可能な（エビデンスに基づく）主張を伝える。

（第10部5.3「安全ケースの理解」より）

• 主要な3要素

–要求事項

–アーギュメント

–エビデンス

• ISO 26262が機能安全のための最低限の目的を述べているとすれば、ISO 26262の要求事項および成果物は、安全ケースのための目的およびエビデンスであるとみなすことができる

Safety Requirements & Objectives

Safety Evidence

Safety Argument

Safety Requirements & Objectives

Safety Evidence

Safety Argument

（第10部5.3「安全ケースの理解」より）

IEC 61508の考え方

安全機能の失敗がどの程度許容されるか • 安全度水準（SIL 1～SIL 4）によって規定される Ex) SIL 3 なら、目標機能失敗尺度は、 危険側故障率PFH[1/Hour] が10-8～10-7 または

作動要求毎の機能失敗確率PFDavgが10-4～10-3

安全のために何をするか

Ex) • 制御対象の安全状態を達成／維持する機能 • センサ、PEハードウェア、アクチュエータの障害を検出／制御する機能 • ソフトウェア自身の障害を検出／制御する機能

機能安全 ＝ 安全機能 ＋ 安全度

ハザード分析により 機能仕様を決定

リスクアセスメントにより 安全度目標を決定

42

ランダムHW故障への対策の 度合い

• 基本的に、ハードウェア設計における機能失敗尺度の推定値が、目標値を下回ればよい • ただし、安全側故障割合が低い場合は、ハードウェアの冗長化が必要となる

システマティック故障への対策の度合い • システマティック故障の回避および抑制による

信頼性の高い部品の使用、 系の多重化、

共通原因故障の排除、 診断テストによる故障診断率の向上、

安全ライフサイクルの規定、 各フェーズにける技法の推奨、 機能安全マネジメントの導入、

文書化、 機能安全アセスメント、

安全度 = ハードウェア安全度＋ システマティック安全度

ISO 26262の考え方

なぜ安全であるといえるのか • エビデンスに基づく合理的な説明・説得

安全のためには、どうでなければいけないか • ASILを含む

機能安全 ＝ 適切な安全ゴールの 主張可能な達成

ハザード分析・リスクアセスメント により要求導出

安全ライフサイクルプロセスの 実施によりエビデンスを収集し、 安全ケースとしてコンパイル