安全分析基礎とその説明手法の紹介

Embedded Technology WEST 2015 2015.06.10, グランフロント大阪

（株）デンソークリエイト 小林 展英

本発表の目的

•  安全分析の結果を第三者が納得して確認できる必要がある 安全分析における重要なポイント

安全分析 結果

基づく

確認記録 基づく

開発者

経験・考え方

第三者

経験・考え方

確認する 不一致

確認に用いる経験・考え方を揃えて説明できる必要がある

1 / 18

説明手法：D-Caseの紹介

•  相手と合意形成できている前提に基づき上位の主張を下位の主張に分解 •  最下位の主張の妥当性を証拠に基づいて説明することで主張全体が特性基準を

満足できていることを説明する

成果物が特性基準を 満足している

成果物の構成要素が 特性基準を満たしている

成果物の構成要素間の関係が 特性基準を満たしている

特性基準

成果物の 構成

成果物の構成に従って説明する

構成要素が 特性基準を 満たす証拠

構成要素間の 関係が特性基準を

満たす証拠

証拠

主張

前提 説明

2 / 18

説明手法：D-Caseの紹介

•  相手と合意形成できている前提に基づき上位の主張を下位の主張に分解 •  最下位の主張の妥当性を証拠に基づいて説明することで主張全体が特性基準を

満足できていることを説明する

成果物が特性基準を 満足している

成果物の構成要素が 特性基準を満たしている

成果物の構成要素間の関係が 特性基準を満たしている

特性基準

成果物の 構成

成果物の構成に従って説明する

構成要素が 特性基準を 満たす証拠

構成要素間の 関係が特性基準を

満たす証拠

証拠

主張

前提 説明

経験・考え方

安全分析結果

確認記録

3 / 18

【HAZOPの例】

分析手法：HAZOPの紹介

•  設計パラメータや操作にガイドワードを組み合わせることで 意図した正常な振舞いから「逸脱した状態」を抽出する

《設計パラメータ》

ライト光量

《ガイドワード》

無し

逆転

《逸脱した状態》

ライトが点灯しない

ライトの点灯が 逆転する

× ⇒

・・・

4 / 18

分析手法：FTAの紹介

•  「望ましくない状態」をシステムの構造等の明文化された前提に基づいて分解することで、その原因を明らかにする

•  発生確率も付与して分析できるが本発表では省略している

原因A

原因 A-1

原因B

原因 A-2

望ましくない状態

: ANDゲート

: ORゲート

: 事象

: 基本事象

凡例）

5 / 18

今回採用した安全分析プロセス

•  安全分析の概要理解を目的としている都合上、分析手順を一部で簡略化しています （故障モードの対策立案時における重要性分析など）

本プロセスの前提

6 / 18

手順1：ハザード分析 手順2：故障モード抽出

手順4：D-Caseで説明する

・システムが提供する機能の特性に 応じてHAZOPのガイドワードを決定・HAZOPを用いて機能の正常動作からの 逸脱をハザードとして抽出

・ハザードをFTAのトップゴールに設定・システム構成に基づいてハザードを分解・FTAの末端ノードはガイドワードを用いて 故障モードとして抽出

手順3：故障モードの対策定義・故障モードを装置単体で回避できる場合、 装置毎のスコープで対策を定義・複数の装置に跨がった対策が必要な場合、 装置間共通の方針を定めた上で対策を定義

xxxシステムは安全である

構造に関する文書

前提に従って説明する

構造の構成要素は安全である

・・・条件に関する文書

前提

前提

主張

戦略

安全分析プロセスの適用対象：システム設計情報

ID. 機能

1. ライトスイッチの点灯操作に応じてヘッドライトを点灯 2. ライトスイッチの消灯操作に応じてヘッドライトを消灯

システム構成

提供機能

ライトスイッチ

IGスイッチ ボデー制御ECU

ヘッドライト制御ECU

右ヘッドライト

左ヘッドライト

：ワイヤハーネス：CAN通信線

：センサ/アクチュエータ：ECU

HW_LS

HW_IG

HW_HLR

HW_HLLCAN

7 / 18

安全分析プロセスの適用対象：ECUソフトウェア設計情報

ECUソフトウェア構成

ヘッドライト制御ECU

Head Light Control SW-C

Application Framework

IO-StackCOM-Stack RTOS

CAN HW_LS HW_HLRHW_HLL

アプリケーション層

プラットフォーム層 アプリケーション

実行層

車載ソフト共通機能提供層

8 / 18

手順１：ハザード分析結果

ガイドワード採用方針

•  ヘッドライトの光量に着目して以下のガイドワードを採用 –  無し、異なる、過多、過少

ハザード分析結果

ID. ガイドワード ハザード

1. 無し ヘッドライトの完全な喪失 2. 異なる ヘッドライトの点灯、消灯が逆転 3. 過多 ヘッドライトの光量が多い 4. 過少 ヘッドライトの光量不足

手順1：ハザード分析 手順2：故障モード抽出

手順4：D-Caseで説明する

・システムが提供する機能の特性に 応じてHAZOPのガイドワードを決定・HAZOPを用いて機能の正常動作からの 逸脱をハザードとして抽出

・ハザードをFTAのトップゴールに設定・システム構成に基づいてハザードを分解・FTAの末端ノードはガイドワードを用いて 故障モードとして抽出

手順3：故障モードの対策定義・故障モードを装置単体で回避できる場合、 装置毎のスコープで対策を定義・複数の装置に跨がった対策が必要な場合、 装置間共通の方針を定めた上で対策を定義

・以下の3点をD-Caseで見える化する - 故障モードの抽出結果 - 故障モードに対する対策 - システムに対する対策の組込み状況

次の手順ではID.1のハザードを対象として故障モードを抽出していきます。

9 / 18

手順２：故障モード分析結果

装置種別

装置

H/W本体＋入出力

起こり得る故障

手順1：ハザード分析 手順2：故障モード抽出

手順4：D-Caseで説明する

・システムが提供する機能の特性に 応じてHAZOPのガイドワードを決定・HAZOPを用いて機能の正常動作からの 逸脱をハザードとして抽出

・ハザードをFTAのトップゴールに設定・システム構成に基づいてハザードを分解・FTAの末端ノードはガイドワードを用いて 故障モードとして抽出

手順3：故障モードの対策定義・故障モードを装置単体で回避できる場合、 装置毎のスコープで対策を定義・複数の装置に跨がった対策が必要な場合、 装置間共通の方針を定めた上で対策を定義

・以下の3点をD-Caseで見える化する - 故障モードの抽出結果 - 故障モードに対する対策 - システムに対する対策の組込み状況

次の手順では抽出した故障モードに対する対策を決定します

10 / 18

手順３：故障モードの対策定義結果

安全対策方針

（方針１）走行中における突然のヘッドライト喪失を回避するため、ヘッドライト制御に関する故障検出時には点灯する側で制御する。

（方針２）通信に関する途絶・誤り検出時には受信側で方針１に基づいて制御する。

安全対策定義

ID. 構成要素 故障モード 対策

1. ボデー制御ECU

IGスイッチ値のワイヤハーネス断線 H/W回路で断線時のIGスイッチ値をオンとする

2. ノイズ印加によるIGスイッチ値の逆転 IO-StackでIGスイッチ値のチャタリングを防止する

3. CAN通信線断線 ヘッドライト制御ECU側で対応する

4. CAN送信メッセージの値化け COM-Stackで誤り検出符号を付与する

： ： ：

7. ヘッドライト制御ECU

CAN通信線断線 COM-Stackで通信途絶時のIGスイッチ値をオンとする

8. CAN受信メッセージの値化け COM-Stackで誤り検出時のIGスイッチ値をオンとする

： ： ：

： ： ： ：

手順1：ハザード分析 手順2：故障モード抽出

手順4：D-Caseで説明する

・システムが提供する機能の特性に 応じてHAZOPのガイドワードを決定・HAZOPを用いて機能の正常動作からの 逸脱をハザードとして抽出

・ハザードをFTAのトップゴールに設定・システム構成に基づいてハザードを分解・FTAの末端ノードはガイドワードを用いて 故障モードとして抽出

手順3：故障モードの対策定義・故障モードを装置単体で回避できる場合、 装置毎のスコープで対策を定義・複数の装置に跨がった対策が必要な場合、 装置間共通の方針を定めた上で対策を定義

・以下の3点をD-Caseで見える化する - 故障モードの抽出結果 - 故障モードに対する対策 - システムに対する対策の組込み状況

11 / 18

手順４：D-Caseを用いた説明

第三者の納得には数多くの情報を適切に構造化して説明できる必要がある

手順1：ハザード分析 手順2：故障モード抽出

手順4：D-Caseで説明する

・システムが提供する機能の特性に 応じてHAZOPのガイドワードを決定・HAZOPを用いて機能の正常動作からの 逸脱をハザードとして抽出

・ハザードをFTAのトップゴールに設定・システム構成に基づいてハザードを分解・FTAの末端ノードはガイドワードを用いて 故障モードとして抽出

手順3：故障モードの対策定義・故障モードを装置単体で回避できる場合、 装置毎のスコープで対策を定義・複数の装置に跨がった対策が必要な場合、 装置間共通の方針を定めた上で対策を定義

・以下の3点をD-Caseで見える化する - 故障モードの抽出結果 - 故障モードに対する対策 - システムに対する対策の組込み状況

12 / 18

第三者が納得するために必要なこと

以下の2点は納得する上で知っておきたい必要条件となるはず •  どのような過程で、どのような判断基準に基づき分析されたか？ •  要求を満足する対策は最終成果に漏れなく組込まれているのか？

分析工程の構成要素

13 / 18

工程n要求 中間成果

最終成果工程n+1

基準A 基準B

組込み状況

【D-Caseの有効性】 安全分析の全体俯瞰

まだ具体化できて いないことを示す記号

説明内容を モジュール化

14 / 18

【D-Caseの有効性】 安全分析の全体俯瞰（M2 ECU群） 15 / 18

【D-Caseの有効性】 判断基準の見える化

ここまで書くのは ちょっと過剰かも…

ハザード網羅 の判断基準

16 / 18

【D-Caseの有効性】 対策の組込み状況の確認

組込み状況 の確認記録

導出した対策

17 / 18

まとめ

HAZOP FTA

トレーサビリティ, テスト報告書等

D-Case

外部 内部

分析

確認 ：仕事の流れ ：結果の総括

凡例

（今回の発表で解決に取り組んできた問題）

安全分析の結果を第三者が納得できるよう説明したい

•  HAZOP, FTAを組み合わせることでシステムの外部・内部の視点を整理して安全分析を進めることができる

•  D-Caseを用いることで第三者の納得を助ける説明文書を提供できる –  安全分析結果の全体俯瞰、判断基準 –  安全分析結果対策の組込み状況

18 / 18