安全コンセプト - ISITカーエレクトロニクス研究会

安全コンセプト，アーキテクチャ設計の
理解とその最適表記法の提案
(20140714ISIT第15回カーエレクトロニクス研究会)
DNV・GL Principal Technical Expert
山下修平
DNV GL © 2014
SAFER, SMARTER, GREENER
0-0 はじめに
自動車の安全を語る時にその一側面として
機能安全の議論があります
ISO26262がこのガイドを提供しています
・2011/11に成立した国際規格
・自動車の電子制御システムの安全設計のガイドライン
0-1 はじめに
今日は ISO26262における
‘安全コンセプト’
あるいは
ISO26262的アーキテクチャ設計
の意味合いや
適切な扱い方（特に表記法）
を紐解きます
これは乗用車以外，メカトロ以外，
車両内クローズドシステム以外を扱う際にも
共通の重要概念です
目次
１．ISO26262の求める安全設計
1-1 安全コンセプトの現状
1-2 安全コンセプトの役割
1-3 規格の関連規定の再点検
２．表記法の刷新
2-1 ASIL操作ルールの確認
2-2 使いやすい表記法の導入
2-3 ツール化への期待
３．今後の展開について
目次
１．ISO26262の求める安全設計
1-1 安全コンセプトの現状
1-2 安全コンセプトの役割
1-3 規格の関連規定の再点検
２．表記法の刷新
2-1 ASIL操作ルールの確認
2-2 使いやすい表記法の導入
2-3 ツール化への期待
３．今後の展開について
1-1 安全コンセプトの現状 i
●業界で散見される事態，遭遇した事例：
・安全要求の仕様提示がサプライヤに通じない
・顧客から提示された安全設計仕様が理解できない
・安全設計仕様のレビューがうまく実施できない
・○○屋と××屋の間で安全設計議論がかみ合わない
・効果的なSEooC開発にならない
●これらの多くは
安全コンセプトがうまく作られていないことに起因していた
⇒‘安全コンセプトの受難’
SEooC : Safety Element Out Of Context
1-1 安全コンセプトの現状 ii
●なにが起こっているのか？ FSCがCR対象から外
れている
規格側要因
安全コンセ
プト受難
ユーザ側要因
TSCがシステム設計
とマージされている
HW/SWレベルのSC
に名前が無い
CR : Confirmation Review
SC : Safety Concept
FSC : Functional Safety Concept
TSC : Technical Safety Concept
HW : HardWare
SW : SoftWare
プロセス要件，定量
評価議論が先行
SC役割の認識不足
システム設計部署の
不在
作成手法，表記法の
議論不足
方法論の不備
サポートツールの
不在
1-2 安全コンセプトの役割 i
●安全コンセプトの役割
安全設計仕様の共有，共通理解，
合意，評価/検証の手段
仕様発信者
安全コンセプト
第三者
仕様受信者
透明化／
可視化の手段
1-2 安全コンセプトの役割 ii
●慶応大学の白坂先生は安全設計の説明性確保の考え方を下図を使って
‘設計仕様やシステム仕様を全部説明しようとするとうまくいかない。
安全関連部分のみを切り出して説明することが肝要’と指摘
『システムが安全である』
コンセプト
設計
2014/06/17 ITメディアセミナー
慶應大学専任准教授白坂成功先生講演
‘日本のモノづくりと機能安全
～その先にある“日本流”目指して～’より引用
システム
1-2 安全コンセプトの役割 iii
●安全コンセプトの役割は？
① 安全設計仕様の根拠を明示する
② 安全関連系を識別する
③ 識別した部分の開発の手厚さを示す
⇒
ISO26262はこれら一連のプロセスを
① 要求工学に基づく安全要求の導出・詳細化
② 上記に基づく安全関連系のラベリング（ASIL）
③ ASILの重み付けに基づく部品（エレメント）開発
として規定している
ASIL : Automotive Safety Integrity Level
1-2 安全コンセプトの役割 iv
●SLC中のASILの意味合いの変化を理解することが重要
SLC抜粋
パート２
マネジメント
ASILの意味合い
パート3.7 H&R
H&RにおけるASIL：リスクレベル
パート3.8 FSC
パート４システム開発
パート５
HW開発
SGのASIL：アイテム（車両レベルシステム）の
設計開発上の努力代の指標
パート６
SW開発
デコンポジション後のASIL：
対象エレメントの設計開発上の努力代の指標
パート８
支援プロセス
SLC : Safety LifeCycle
H&R : Hazard analysis & Risk assessment
SG : Safety Goal
1-2 安全コンセプトの役割 v
●デコンポジション後のASIL：対象エレメント設計・開発の努力代の
指標
・パート４，５，６中心に提供される手法選択表：合計４０以上
手法
ASILA
ASILB
ASILC
ASILD
1a
Method-1
o
+
+
++
1b
Method-2
+
+
++
++
2a
Method-3
+
++
++
++
2b
Method-4
++
++
++
+
・表以外にも多くのデコンポジション後ASILによる規定が規格の要件
を構成している
・このグラデーションが安全関連系の識別と切り離し（ASILの囲い込
み）の動機となる ⇒安全コンセプト作成要件
1-2 安全コンセプトの役割 vi
●安全コンセプト作成が求められるのは‘デコンポジション後のASIL’が現
れる箇所：
・機能安全コンセプト（FSC）
・技術安全コンセプト（TSC）
・ハードウエアアーキテクチャ設計（HWAD）
・ソフトウエアアーキテクチャ設計（SWAD）
作業の中身は共通，すなわち
HWAD : HardWare Architectural Design
SWAD : SoftWare Architectural Design
SM : Safety Mechanism
・安全要求仕様作成（SM検討，ASIL減免を含む）
・安全要求のエレメントへの配置
・ASILのアサインメント（ASILマッピング）
⇒これらを ‘安全コンセプト’または‘安全アーキテクチャ設計’の呼称で
束ねるとその役割，位置づけが理解しやすい
1-3 規格の関連規定の再点検 i
●なにが起こっているのか？ FSCがCR対象から外
れている
規格側要因
TSCがシステム設計
とマージされている
HW/SWレベルのSC
に名前が無い
安全コンセ
プト受難
ユーザ側要因
プロセス要件，定量
評価議論が先行
SC役割の認識不足
システム設計部署の
不在
作成手法，表記法の
議論不足
方法論の不備
サポートツールの
不在
1-3 規格の関連規定の再点検 ii
●安全コンセプト作成法の主な議論
安全コンセプト作成
手法，表記法の要件
コンセプト
作成ルール
記法の規定
安全分析法の指示
●FSC,TSC,HWAD,SWAD作成工程においては
・安全要求導出，安全要求配置とこれに基づくASILのマッピングを扱う
・この際、要求構造とエレメント構造の両方を扱う
・ASIL依存要件のグラデーションを動機としたASIL波及範囲の特定や囲い込みの努力が行われる
●安全分析がこれらの工程をサポート
・安全要求の導出・詳細化，ASIL波及範囲の特定
・上位安全要求の達成・侵害の切り口からの分析
1-3 規格の関連規定の再点検 iii
●仕様記述法の規定：
⇒パート8 表１が安全要求仕様の記述法を指定
安全要求仕様記述手法
ASILA
ASILB
ASILC
ASILD
1a
非形式記述
++
++
+
+
1b
準形式記述
+
+
++
++
1c
形式記述
+
+
+
+
●しかし正確でわかりやすい記述を必要とするのは実は安全コンセプト：
安全要求の属性の中には要求間インタラクション，要求のアロケーション先，
ASIL等の安全コンセプトの情報を含んでいるとみなせば間違いではないの
だが・・
誤解の一因になっているかもしれない
1-3 規格の関連規定の再点検 iv
●安全コンセプト作成法の主な議論
安全コンセプト作成
手法，表記法の要件
コンセプト
作成ルール
記法の規定
安全分析法の指示
●FSC,TSC,HWAD,SWADにおいて
・安全要求配置とこれに基づくASILのマッピングを扱う
・要求構造とエレメント構造を扱う
・ASIL依存要件のグラデーションを動機としたASIL波及範囲の特定，囲い込みの努力が行われる
●安全分析がこれらの工程をサポート
・安全要求の導出・詳細化，ASIL波及範囲の特定
・上位安全要求の達成・侵害の切り口からの分析
1-3 規格の関連規定の再点検 v
●要求/コンセプトスパイラル中の安全分析の役割
安全要求仕様
安全要求の導出・詳細化
安全要求の配置の検討
安全要求冗長化による
ASILの減免
安全方策の検討，
安全機構の追加
ASIL波及範囲の特定
安全分析
ASIL波及範囲の囲い込み
アーキテクチャ設計の更新
（上位）安全要求侵害
可能性の洗い出し
安全コンセプト
1-3 規格の関連規定の再点検 vi
●安全分析に関する規格要件
⇒パート4 表1やパート 5 表2では以下のように手法を指定
安全分析手法
ASILA
ASILB
ASILC
ASILD
1
トップダウン
o
+
++
++
2
ボトムアップ
++
++
++
++
1をFTA, 2をFMEAと直接読み替えてしまうと困難も多い
部品故障ベースの分析に陥りがち：規格の意図は安全要求侵害
⇒ 安全要求やコンセプトのわかりやすい記述が適切な安全分析をサポート
する可能性
目次
１．ISO26262の求める安全設計
1-1 安全コンセプトの現状
1-2 安全コンセプトの役割
1-3 規格の関連規定の再点検
２．表記法の刷新
2-1 ASIL操作ルールの確認
2-2 使いやすい表記法の導入
2-3 ツール化への期待
３．今後の展開について
2-1 ASIL操作ルールの確認 i
●安全コンセプト作成法の主な議論
安全コンセプト作成
手法，表記法の要件
コンセプト
作成ルール
記法の規定
安全分析法の指示
●FSC,TSC,HWAD,SWADにおいて
・安全要求配置とこれに基づくASILのマッピングを扱う
・要求構造とエレメント構造を扱う
・ASIL依存要件のグラデーションを動機としたASIL波及範囲の特定，囲い込みの努力が行われる
●安全分析がこれらの工程をサポート
・安全要求の導出・詳細化，ASIL波及範囲の特定
・上位安全要求の達成・侵害の切り口からの分析
2-1 ASIL操作ルールの確認 ii
●安全要求の配置とASIL割付操作の基本ルール：
・要求ツリー内のASIL不変則
・要求配置とエレメントへのASIL割付
・ASIL囲いこみとFFI
・デコンポジション
（凡例）
安全要求
ASIL継承
ASIL
SG001
エレメント
D
C
安全要求侵害
X
Element01
等は
B
A
安全要求侵害
の不在
QM
のいづれかを表す
2-1 ASIL操作ルールの確認 iii
●要求ツリー内のASIL不変原則
SRの導出・詳細化の過程でASILは不変
SR0101
SR01
X
X
SR0102
X
SR : Safety Requirement
2
3
2-1 ASIL操作ルールの確認 iv
●要求ツリー内のASIL不変原則
HW安全要求
ASIL D の例
HWSR001
安全目標
SG001
技術安全要求
機能安全要求
D
FSR001
FSR002
FSR003
D
TSR001
D
TSR002
D
TSR003
D
HWSR002
D
HWSR003
D
D
D
D
SWSR001
SWSR002
SWSR003
SW安全要求
2
4
D
D
D
2-1 ASIL操作ルールの確認 v
●エレメントへの要求配置とASIL割付
SRが配置されたエレメント（システム構成要素）には当該SRの
ASILが付与される
Element01
SR01
X
X
2
5
2-1 ASIL操作ルールの確認 vi
●エレメントへの要求配置とASIL割付（2）
ひとつのエレメントに複数のSRが配置された場合にはセレクト
ハイルールが適用される（図はASILＸ>ASILＹの場合）
Element01
SR01
X
X
セレクトハイ
Y
SR02
2
6
2-1 ASIL操作ルールの確認 vii
●エレメントへの要求配置とASIL割付（3）
前頁のケースでサブエレメントElement0102がSR01を侵害し
ない場合各々のサブエレメントには夫々に配置されたASILを割り
付けることができる
Element0101
SR01
X
X
安全要求侵害不在
Element0102
Y
Y
SR02
2
7
2-1 ASIL操作ルールの確認 viii
●エレメントへの要求配置とASIL割付（４）
前頁のケースでASILY=QMの場合
Element0101
SR01
X
X
安全要求侵害不在
Element0102
QM
2
8
2-1 ASIL操作ルールの確認 ix
●エレメントのASIL割付原理
SR配置によるエレメントへのASIL割付や FFIによるASIL波及範
囲の限定を説明するエレメントのASIL決定ロジックの原理
SR01
X
安全要求侵害
Element01
X
2
9
2-1 ASIL操作ルールの確認 x
●デコンポジション
SR冗長化に伴うASIL減免ルール：
SR01に対して‘冗長な’SR01’を追加することでASIL減免を与える
この時各々の配置先である２つのエレメント間に SR01/SR01’同時侵害
となるような従属故障が存在してはならない（＝独立要求）
Element01
SR01
SR01
A
X
要求冗長化
ASIL減免
Element02
X-1
SR01’
3
0
2-2 使いやすい表記法の導入 i
●安全アーキテクチャ，安全コンセプトは既存の記法：
UML，SysML, ADSL等でも十分表記できる
しかし
・ ISO26262の求める安全設計の思考作業を連続的にサポートする
には不足感ある
・特別な記法の知識がなくても、理解しやすく安全設計に着目したレ
ビューができると好ましい
・ルールを絵解きすると見えてくるISO26262オリエンテッドな記法
がほしい
2-2 使いやすい表記法の導入 ii
●安全アーキテクチャ記述用のメタモデルの要件：
- 要求層とエレメント層を明確に区別して扱える
- 要求間インタラクションを図示できる
- SMの役割をわかりやすく説明できる
- エレメントの開発努力代を指定するASILが安全要求の配置によっ
てもたらされることをあらわす
- ASIL囲い込み努力をエレメントの階層定義の中で考察できる
等,
ISO26262固有概念を合理的に扱える図式表現法のニーズは高い
2-2 使いやすい表記法の導入 iii
●規格趣旨に基づき以下のように表記タイプと遷移を定義
安全要求構造図(SRSD)
:各安全要求間のインタラクションとデコンポジシ
ョンをSG毎,SM毎,SS毎に説明する
要求ツリー図
安全要求配置図(SRAD)
:安全要求構造図をエレメント
図に重ねたもの
エレメント
ツリー図
要求層
エレメント層
ｘＮ(SG/SM/SS)
エレメント
構造図
(ELSD)
安全コンセプト図(SCD)
:ASILのエレメント上の最終
マッピングを示す
SS : System State
2-2 使いやすい表記法の導入 iv
●安全要求構造図(SRSD)
・安全要求間のインタラクションを明示
・要求（グループ）間の冗長関係と独立性要求を明示
NFSR003
FSR001
D
FSR002
D
FSR003
FSR0031
C(D)
D
FSR0032
A(D)
A(D)
3
4
2-2 使いやすい表記法の導入 v
●要求ツリー図
・ASIL不変則
・デコンポジションによる ASIL減免
・セカンダリSMのASIL
SG001
FSR001
D
FSR002
SG002
FSR003
HWSR001
技術安全要求
機能安全要求
安全目標
HW安全要求
D
TSR001
D
TSR002
D
TSR003
HWSR002
D
HWSR003
D
D
D
SWSR001
D
SWSR002
FSR0031
D
D
D
C(D)
SWSR003
D
FSR0032
NFSR003
A(D)
2
TSR0031
B
SW安全要求
D
3
5
D
2-2 使いやすい表記法の導入 vi
●エレメントツリー図
・エレメントとは作り込みの単位（通常は物理層の部品）
・エレメントのツリー構造＝入れ子構造
・ASILの囲い込み努力を促すエレメントの詳細化
SYSXX
Sub-sys01
ECU01
mC01
eSW01
SENS01
Others
Others
Others
Sub-sys02
Others
3
6
2-2 使いやすい表記法の導入 vii
●エレメント構造図(ELSD)
・エレメントの入れ子構造の直感的表現
・SR配置とASILの囲い込み努力を可視化
X
SYSXX
X
Sub-sys01
X
ECU01
X
X
X
mC01
eSW01
SENS01
Sub-sys02
X
3
7
2-2 使いやすい表記法の導入 viii
●安全要求配置図(SRAD)
・要求ツリーでは表現できない安全要求の側面：
・インタラクションと配置（＋結果としてのASIL割付け）
Sub-sys01
ECU01
NFSR003
SENS01
FSR001
D
mC01
D
FSR002
D
FSR003
FSR0031
C(D)
FSR0032
A(D)
A(D)
AS01
3
8
2-2 使いやすい表記法の導入 ix
●安全コンセプト図
・全安全要求配置後のエレメントに対するASILマッピング
Sub-sys01
ECU01
NFSR003
SENS01
FSR001
D
mC01
D
FSR002
D
FSR003
FSR0031
C(D)
FSR0032
A(D)
A(D)
AS01
3
9
2-3 ツール化への期待 i
●ツール（化）は表記法の統一や普及のしかけとして使いたい
・必要な‘しばり’はツールの形で提供するとうまくいきそう
・欧米発でないメタモデル＋ツール開発のチャンス
⇒今後の取り組み
・表記法とツール仕様をセットで提案
・賛同者を募り議論を進める
構想：
・複数の要求管理ツールのFEPとして提供
・UML他のメタモデルの活用と互換表記
2-3 ツール化への期待 ii
●ツール化で可能になること or 可能にしたいこと
・設計者がやりたいことをやりやすくする
：安全コンセプトメタモデルに対応した描画機能と使いやすいGUI
・必要な検討や作業をガイドする
：要求詳細化にまつわる安全分析サポート等
・煩雑な作業は自動化する
：要求配置に連動したエレメントのASIL算出等
・やってはいけないことはできないようにする
：要求配置に基づかないエレメントのASIL割付け等
・安全分析作業との連動
・要求管理ツールのFEP機能の提供
・他のメタモデルとの相互変換
目次
１．ISO26262の求める安全設計
1-1 安全コンセプトの現状
1-2 安全コンセプトの役割
1-3 規格の関連規定の再点検
２．表記法の刷新
2-1 ASIL操作ルールの確認
2-2 使いやすい表記法の導入
2-3 ツール化への期待
３．今後の展開について
3 今後の展開について
●安全コンセプト指向の規格適用活動の拡大：
・賛同者と協力して研究会やトレーニングを提供してゆく
・顧客要望に応じて実プロジェクトレベルの適用事例を積み上げる
●専用メタモデルの開発：
・実用的な表記法・文法の仕様ブラシアップの活動を展開する
●ツール化：
・志の高いベンダ様には積極的に協力してツール開発ビジネスを後
押しする
ご静聴ありがとうございました
Email address：
[email protected]
www.dnvgl.com
SAFER, SMARTER, GREENER

Download Report