安全設計アプローチの可視化 - scdl lab....2016/10/19 ·...

© 2016 CALSONIC KANSEI CORPORATION. All Rights Reserved.

2016年 7月 28日

カルソニックカンセイ株式会社電子事業本部電子戦略推進グループ

ISO26262推進

佐々木喜好

安全設計アプローチの可視化

～車載電子機器開発へのSCDL適用事例～

Safety Concept Notation Open Conference 2016


本日ご紹介したいこと

2

• 「SCDL」＝「お絵かき作法」ではなかった

• 可視化って素晴らしい

• カルソニックカンセイ？

学問的な難しい所は専門家の方々へお任せするとして


会社紹介


会社概要

会社名カルソニックカンセイ株式会社

埼玉県さいたま市北区日進町2-1917

１９３８年８月２５日

森谷弘史（CEO)

４１５億円

20,904名（連結） 3,622名（単独）

※’15年3月31日時点

※’15年3月31日時点

4

本社所在地

設立

代表取締役社長

資本金

従業員


何をしている会社なの

６製品群の自動車製品を生産・供給する総合部品メーカー

5


電子・電装製品

6


Agenda

7

１．安全コンセプト設計を始めました

２．SCDLが登場しました

３．スッキリしました


ISO26262(自動車機能安全国際規格）対応

9

2011年11月 ISO26262初版発行車載電子機器が対象 ASIL-A, B, C, Dと全てのリスクレベルが対象とな

る製品群を開発

プロセス

電子・電装製品

ISO2

62

62準拠技術


ISO26262対応による新たな取り組み

10

従来の安全設計フロー（弊社）

製品構想

システム設計

ハードウエア設計ソフトウエア設計

新たな安全設計の導入

実験

顧客要求

安全コンセプト設計

機能安全コンセプト

技術安全コンセプト

生産

SCDL適用範囲


要求とアーキテクチャー構成要素に基づいて、車載電子機器の入力から出力まで全体の

安全なアーキテクチャーを検討

安全であることの説明

安全コンセプト設計の役割

11

XX機能 ASIL D

ZZ機能 QM

機能要求

安全要求

機能要求

安全要求

安全アーキテクチャー

安全

なぜならば・・・

エレメントエレメント

故障

安全関連の機能

車載電子機器


安全アーキテクチャー検証

安全コンセプト設計の流れ

12

トップダウンアプローチにて設計機能安全/技術安全コンセプト共に共通のアプローチ

機能要求の検討

安全分析

安全要求の検討


機能要求

FMEA / FTA

安全要求

安全要求

機能要求安全アーキテクチャー図

FMEA / FTA


安全コンセプト設計の実現手段

13

機能要求

安全要求

安全アーキテクチャーはドキュメントで構成し、入力から出力までの要求をまとめた仕様

安全分析安全措置

安全アーキテクチャー図

FMEA / FTA

アーキテクチャー全体を俯瞰

安全アーキテクチャー仕様


安全コンセプト設計と成果物

安全アーキテクチャー仕様は安全コンセプト設計の成果物同時に要求間のトレーサビリティーも確保

機能要求

機能要求

制約条件

安全要求

機能要求１：運転者の操作意図を取得する

安全要求１：運転者の操作意図を取得する

安全要求２：取得した運転者の操作意図を比較する

機能要求１と安全要求１、２は独立した構造とする

ヘッドランプ信号を取得する

安全分析前の機能要求

安全分析後の機能安全要求

技術安全要求


気付きがありました

15

安全コンセプト設計を導入して見えてきた課題



安全分析


安全アーキテクチャー ②作り手によりバラツキが出る

①設計根拠が説明し難い

③複雑で解り難い



16

図はあくまで全体を俯瞰するための補足手段

安全アーキテクチャー仕様は設計の結果であり、その設計過程は見え難い

どの安全要求がこの機能要求を助けるの？

この要求は何のためにあるの

安全アーキテクチャー仕様安全分析

制約条件はどこ？

安全アーキテクチャー図

結果でまとまっている


②作り手によりバラツキが出る

17

あるプロジェクトの安全アーキテクチャー図。設計者は解るが・・・

要求がエレメント（部品）を跨いでいる意図は？

複数出力を持つ機能の意図は？

ブロックの色違い意味がある？

入り乱れている出力の関係性は？

中間線（赤線）は何を表す？


③複雑で解り難い -1

18

要求間の依存関係が理解出来ない言葉の繋がりで要求の繋がりを読み解く＝誤解を招く


スイッチ１とスイッチ２を別々に取り込む

取り込んだ入力を比較する

スイッチ１を平均化をする

スイッチ２と平均化後のスイッチ１を判断し出力を許可する

取得平均化判断

比較取得

出力スイッチ１

スイッチ２こういうアーキテクチャーを想定していたが・・・



19


スイッチ１とスイッチ２は独立（共倒れ故障の影響を与えない）

機能機能

安全安全

出力スイッチ１

スイッチ２

制約条件の正確な理解が出来ない

出力

安全安全スイッチ２出力

機能スイッチ１出力

どちらでも間違ってはいないが



20

そもそも、理解に時間が掛かる言葉の繋がり、行間、言語表現などを読み解き、安全アーキテクチャーを正確に捉える事は難しい

弊社製品の安全アーキテクチャー仕様


何が足りない

21

文章による仕様表現の限界ではないか

設計過程の有り方が不十分ではないか

言葉以外の表現＝可視化

共通会話出来るような仕組み＝標準化

設計過程の見える化＝残す

欠けているものは何か？


SCDL仕様 version 1.0 が、2016年4月にリリース

※SCDL=Safety Concept Description Language

希望の光となりました


思い出してみると

24

ISO26262では要求仕様の手法について規定がある

要求仕様の手法 ASIL A ASIL B ASIL C ASIL D

1a 非形式記述強く推奨強く推奨推奨推奨

1b 準形式記述推奨推奨強く推奨強く推奨

1c 形式記述推奨推奨推奨推奨

引用元：ISO26262-8:2011 表1

準形式記述構文形式などのルールを持つ図/表を用いた表記法


設計の有り方を考えてみました

25

「設計を伝える」から「設計を見せる」ことが必要

安全アーキテクチャー図を補足するのが、安全アーキテクチャー仕様

安全アーキテクチャー仕様を、安全アーキテクチャー図が助けるのではなく




安全分析



アプローチの見直し

26

機能要求

FMEA / FTA

安全要求

安全要求

機能要求

FMEA / FTA

安全アーキテクチャー図SCDL


各検討フェーズでSCDLを活用まずは図を書く・使う・確認する設計手法を導入





機能要求の検討フェーズでは

27

安全アーキテクチャーの機能要求を明確にし、要求の役割や依存関係を図に基づいて論じる

FR1運転者の操作意図を取得する

FR2操作意図を判定する

FR3判定結果に基づき点灯要求を送信する

運転者の操作(スイッチ)

エレメント：BCM B

ライト点灯要求(ライト)

ID 要求内容配置先

FR1 運転者の操作意図を取得する BCM

FR2 操作意図を判定する BCM

FR3 判定結果に基づき点灯要求を送信する BCM


安全アーキテクチャー図（SCDL）

FR 機能要求※BCM: Body Control Module


安全分析フェーズでは

28

安全アーキテクチャー図を補足的に用いて、機能要求の安全分析を実施し安全への影響を見極める

安全分析（FMEAのケース） FR2, FR3についても同様に行う


FR2操作意図を判定する

FR3判定結果に基づき点灯要求を送信する



故障


安全要求の検討フェーズでは

29

機能要求に対する安全要求を図表記を用いて論じる制約条件の可視化が重要

安全アーキテクチャー図(SCDL)



操作意図を判定する

判定結果に基づき点灯要求を送信する



FR2 FR3

SM1-1運転者の操作意図を取得する

SM1-2

入力比較を実施する

FR

SM

機能要求

安全要求

B

B

B

制約条件共倒れの影響を与えない

機能要求


分類 ID 内容 ASIL 配置先

FR1

Functional Requirement FR1 運転者の操作意図を取得する B BCM

Non Functional SafetyRequirement

NFSR1 FR1とSM1-1.SM1-2は独立共倒れ故障の影響を与えない

B -

Safety Mechanism SM1-1 運転者の操作意図取得する B BCM

Safety Mechanism SM1-2 入力比較を実施する B BCM

B

NFSR1運転者の操作(スイッチ)


安全アーキテクチャーフェーズでは

機能要求毎に検討した結果を一つにまとめ、安全コンセプトを完成させる

30

統合

安全アーキテクチャー図(SCDL) 安全アーキテクチャー仕様

FR2FR3

FR1

等しい

FR1FR2

FR3


安全アーキテクチャー検証フェーズでは

統合後の安全アーキテクチャーの成立性を再検証する

31

矛盾はないか

過剰設計となっていないか

最適化されているか

制約条件は成立しているか

安全アーキテクチャー仕様安全アーキテクチャー図


ここまで色々お話して来ましたが

33



安全分析


安全アーキテクチャー ②作り手によりバラツキが出る


③複雑で解り難い


①設計根拠が説明し難い →スッキリ

34

アプローチ自体が安全のエビデンスとなっている

安全分析結果


機能要求

安全要求


②作り手によりバラツキが出る →スッキリ

35

SCDL仕様に準拠したスタイルガイドラインに従う設計

SCDL仕様

スタイルガイドライン


③複雑で解り難い →スッキリ

36

図表記により直感的な理解が可能となった

設計者以外も正確且つ容易な理解が可能

要求間の依存関係が理解出来ない制約条件の正確な理解が出来ないそもそも、理解に時間が掛かる

文章による言語表現だけでは上手く理解出来ない


まとめ


まとめ

38

SCDLを活用し、安全コンセプト設計の各フェーズを検討することが、エビデンスを作り上げることに繋がる

SCDLを取り入れることにより、より正確でスピード感ある理解が可能。

設計品質、レビュー品質向上にも貢献している

可視化の実現にはSCDLに準拠した開発ツールを活用するのが良い（重要）


ご清聴ありがとうございました

安全設計アプローチの可視化 - scdl lab....2016/10/19 ·...

Documents