ISIT第9回カーエレクトロニクス研究会 2011/10/14 ISO 26262が規定する要求事項 （独）産業技術総合研究所 水口大知 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インターフェース ・仕様の検証 ・記法の選択 ・設計／実装 原則 ・設計／実装 検証 ⑥ソフトウェア開発 ・テスト計画 ・テスト手法の選択 ・テストケースの導出 ・要求カバレッジ ・構造カバレッジ ・テスト環境 ・ソフトウェア統合計画 ・テスト手法の選択 ・テストケースの導出 ・要求カバレッジ ・構造カバレッジ ・テスト環境 ・検証計画 ・テスト環境 ・検証結果の評価 ④システム開発 ・安全ゴールの妥当性確認 ・PMHFの評価 ・SMPM, LFMの評価 ・統合およびテスト計画 ・テストケースの導出 ・HW-SW・システム・車両レベルでのテスト ・技術安全要求が正しく 実装されていること ・安全メカニズムの性能、 タイミングのテスト ・外部／内部インターフェース ・安全メカニズムの診断カバレッジ ・ロバスト性 ・機能安全アセスメント の実施（アイテムが達成 する機能安全の評価） ・製品リリース基準 ⑦製造・運用 ・製造計画 ・事前品プロセスと製品プロセス のギャップ分析 ・製造プロセスアセスメント ・運用／サービス／廃棄計画 ・ユーザーへの情報（マニュア ルを含む） ・フィールドモニタリング ・変更管理 安全ライフサイクル Ⅱ．「安全ゴール指向」 • 安全ゴールとは、ハザード分析・リスクアセスメント の結果として得られる、トップレベルの安全要求 • 安全ゴールは、対応するハザーダスイベントのASIL を継承する 例（第10部第10節より） • アイテム定義 – アクチュエータを備えたシステム – ダッシュボードスイッチによる運転者からの要求によっ てトリガーされる – 車両が速度0km/hの場合には快適な機能を提供する – 15km/hを超える場合にアクティベートされた場合ハ ザードを引き起こす可能性がある • 初期アーキテクチャ Item Perimeter VS ECU Vehicle speed Driver's request Actuator control ECU Command to the actuator 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で開発することができる。 VS ECU Item Perimeter Vehicle speed Driver's request AC ECU Safety Switch Command to the actuator 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要素 – 要求事項 – アーギュメント – エビデンス Safety Requirements & Objectives Safety Argument Safety Evidence • ISO 26262が機能安全のための最低限の目的を 述べているとすれば、ISO 26262の要求事項およ び成果物は、安全ケースのための目的およびエビ デンスであるとみなすことができる （第10部5.3「安全ケースの理解」より） IEC 61508の考え方 機能安全 ＝ 安全機能 ＋ 安全度 安全のために何をするか Ex) • 制御対象の安全状態を達成／維持する 機能 • センサ、PEハードウェア、アクチュエータの 障害を検出／制御する機能 • ソフトウェア自身の障害を検出／制御す る機能 安全機能の失敗がどの程度許容さ れるか • 安全度水準（SIL 1～SIL 4）によって規定さ れる Ex) SIL 3 なら、目標機能失敗尺度は、 危険側故障率PFH[1/Hour] が10-8～10-7 ま たは 作動要求毎の機能失敗確率PFDavgが10-4～ 10-3 ハザード分析により 機能仕様を決定 リスクアセスメントにより 安全度目標を決定 安全度 = ハードウェア安全度＋ システマティック安全度 ランダムHW故障への対策の 度合い • 基本的に、ハードウェア設計における機能 失敗尺度の推定値が、目標値を下回ればよ い • ただし、安全側故障割合が低い場合は、 ハードウェアの冗長化が必要となる 信頼性の高い部品の使用、 系の多重化、 共通原因故障の排除、 診断テストによる故障診断率の向上、 システマティック故障への対策の度 合い • システマティック故障の回避および抑制によ る 安全ライフサイクルの規定、 各フェーズにける技法の推奨、 機能安全マネジメントの導入、 文書化、 42 機能安全アセスメント、 ISO 26262の考え方 機能安全 ＝ 適切な安全ゴールの 主張可能な達成 安全のためには、どうでなければ いけないか • ASILを含む ハザード分析・リスクアセスメント により要求導出 なぜ安全であるといえるのか • エビデンスに基づく合理的な説明・説得 安全ライフサイクルプロセスの 実施によりエビデンスを収集し、 安全ケースとしてコンパイル
© Copyright 2024 Paperzz
