設計の見える化（GSN）入門

Embedded Technology 2015

2015.11.19, パシフィコ横浜

（株）デンソークリエイト 宇都宮浩之

会社概要と私の経歴

• 会社概要– 所在地： 本社（名古屋市中区）、刈谷事業所（刈谷市）

– 設立： 1991.2.14

– 売上高： 40億800万円（2014年3月期）

– 従業員数： 235名（2014年4月時点）

– 業務内容：

• ITSソフト（ナビゲーションシステム、NaviCon等）

• 車載制御ソフト（メータ制御等）、車載プラットフォーム

• 開発環境支援ソフト（Simulinkベース開発環境等）

• 市販ソフト（工数管理・プロジェクト管理ツール：TimeTracker FX）

• 教育事業（技術ドキュメンテーション教育、書籍販売）

– 団体参加： DEOS, ASIF, TOPPERS等

• 私の経歴– GSNに関するトレーニング教材の開発

– 開発方法論・規格の現場導入（プロダクトライン, AUTOSARなど）

– その他、ナビゲーションシステム開発に従事

1 / 30

• ソフトウェア相互の信頼性確認のため• 企業の説明責任を果たすため• ステークホルダとの情報共有のため

• 全ての接続の検証が困難となる• 企業の責任の所在が曖昧になる

GSN活用の目的

• 多種多様な製品がつながる世界において、設計品質の見える化が重要となる

今後のシステム開発で重要になること

設計品質を見える化する表現方法としてGSNを活用する

2 / 30

つながる世界 つながる世界の課題

設計品質の見える化の必要性

出典：つながる世界のセーフティ＆セキュリティ 設計の見える化（IPA）

GSNとは？

• 相手と合意形成できている前提に基づき上位の主張を下位の主張に分解

• 最下位の主張の妥当性を証拠に基づいて説明することで主張全体が特性基準を満足できていることを説明する

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

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

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

特性基準

成果物の構成

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

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

構成要素間の関係が特性基準を満たす証拠

証拠

主張

前提 説明

3 / 30

GSN活用の目的との関係

• 相手と合意形成できている前提に基づき上位の主張を下位の主張に分解

• 最下位の主張の妥当性を証拠に基づいて説明することで主張全体が特性基準を満足できていることを説明する

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

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

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

特性基準

成果物の構成

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

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

構成要素間の関係が特性基準を満たす証拠

証拠

主張

前提 説明

経験・考え方

成果物

確認記録

4 / 30

参考：GSNで使用できる基本的なノード

ノード名 記号 説明

Goal 相手に説明したい「対象が達成すべき状態」を示す。S＋Vの形をした命題であるべき。例） 「システムは安全である」

Strategy 上位の主張を下位の主張に分解する仕方の説明を示す。例）「識別されたハザード毎に説明する」

Context 主張や説明が基づく相手と合意済みの情報を示す。例）「リスク分析の結果得られたハザードのリスト」、「ソフトウェアの構造」など

Solution 主張が達成できていることを示す証拠（証跡）を示す。証拠は明確に定義されたドキュメントです。例）「テスト報告書」、「運用記録」

Undeveloped まだ具体化できていない主張や説明であることを示す（未定義要素）。

前提

主張

証拠

説明

出典：アシュアランスケース入門, 名古屋大学

5 / 30

参考：ノード間の接続ルール

• リーフは「前提」、「証拠」、「未定義要素」のいずれかです。

• 矢印は2種類あります。「前提」は「主張」もしくは「説明」に付与されます。

証拠主張説明 説明

主張 主張説明

証拠 未定義要素

主張 主張主張前提

主張前提

前提

SupportedByInContextOf

出典：アシュアランスケース入門, 名古屋大学

6 / 30

参考：前提のスコープ

• 「前提」は紐付けられたノードとそれより下位のサブツリー全体にかかります

主張

説明

証拠

主張 主張

未定義要素

前提

赤い点線が「前提」の

スコープです。

出典：アシュアランスケース入門, 名古屋大学

7 / 30

参考：前提のスコープ（事例）

議論の詳細さに応じた前提の紐付けが重要

8 / 30

参考：GSNの位置づけ

《GSN》相手に対する説明範囲

前提境界

【議論境界】GSNの前提−主張・説明の関係

・前提：相手と合意済みであること・説明対象：成果物とその構成・証拠：構成要素とその関係が正しい理由

《作成時のポイント》適切な境界設定が

相手の納得を得られる説明の礎になります

9 / 30

安全分析プロセスにおける説明事例

GSN活用事例10 / 30

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

• 「GSNで説明する」を主眼とした発表の都合上、分析手順を一部で簡略化しています（故障モードの対策立案時における重要性分析など）

本プロセスの前提

11 / 30

【HAZOPの例】

分析手法：HAZOPの紹介

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

《設計パラメータ》

ライト光量

《ガイドワード》

無し

逆転

《逸脱した状態》

ライトが点灯しない

ライトの点灯が逆転する

× ⇒

・・・

12 / 30

分析手法：FTAの紹介

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

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

原因A

原因A-1

原因B

原因A-2

望ましくない状態

: ANDゲート

: ORゲート

: 事象

: 基本事象

凡例）

13 / 30

安全分析プロセスの適用対象（1/2）

ID. 機能

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

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

システム構成

提供機能

14 / 30

安全分析プロセスの適用対象（2/2）

ECUソフトウェア構成

15 / 30

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

ガイドワード採用方針

• ヘッドライトの光量に着目して以下のガイドワードを採用

– 無し、異なる、過多、過少

ハザード分析結果

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

1. 無し ヘッドライトの完全な喪失

2. 異なる ヘッドライトの点灯、消灯が逆転

3. 過多 ヘッドライトの光量が多い

4. 過少 ヘッドライトの光量不足

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

16 / 30

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

装置種別

装置

H/W本体＋入出力

起こり得る故障

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

17 / 30

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

安全対策方針

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

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

安全対策定義

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スイッチ値をオンとする

： ： ：

： ： ： ：

18 / 30

手順４：GSNを用いた説明

ハザード分析結果

故障モード分析結果

故障モードの対策定義結果

対策がシステムに組み込まれていることを確認した記録

19 / 30

GSNを用いた説明：ハザード分析結果20 / 30

GSNを用いた説明：ハザード分析結果

前提ノード（C1）がハザードの網羅性に関する理解を助けてくれる

21 / 30

GSNを用いた説明：故障モード分析結果22 / 30

GSNを用いた説明：故障モード分析結果23 / 30

GSNを用いた説明：故障モードの対策定義結果

前提ノード（C7）で末端ゴール（G11）の合格条件を可視化するのがポイント

24 / 30

GSNを用いた説明：対策の組み込み状況の確認

前提ノード（C7）と証拠ノード（Sn1）の関係で組み込み状況が一目瞭然です

25 / 30

現場導入に向けた見通し

• 手戻りに要した工数はFTA, GSNの表現構造の見直しが大半であった

• 今回定めた表現構造を再利用することで手戻り工数の削減が期待できる

ID. 工数分類 工数内訳 時間

1. 準備工数 HAZOPの習得 5.0h 21.0h

2. FTAの習得 8.0h

3. GSNの習得 8.0h

4. 安全分析工数（初版作成）

対象システムの理解 0.5h 7.5h

5. ハザード分析 0.5h

6. 故障モード分析 2.0h

7. 安全対策定義 1.5h

8. 対策結果の確認 3.0h

9. レビュー工数 初版、第二版、第三版に対して各１回実施 3.0h 3.0h

10. 手戻り工数 第二版（ハザード分析の構造から見直し） 7.0h 11.0h

11. 第三版（対策結果の確認構造のみ見直し） 4.0h

12. 合計 42.5h

26 / 30

本事例に関するまとめ

HAZOP FTA

トレーサビリティ,

テスト報告書等GSN

外部 内部

分析

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

凡例

（本事例で取り組んだ問題）

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

• GSNを用いることで第三者の納得を助ける説明文書を提供できた

– 安全分析結果の全体俯瞰

– 判断に用いる根拠・基準、対策の組み込み状況の可視化

GSNの位置付け

27 / 30

GSNを導入してみたいと思ってくれた方へ

• 弊社における導入の進め方

① GSNの基本的な知識の教育（記法や注意点等）

② 事例ベースで実際にGSNを用いて演習

③ 使い勝手の良いツールを導入（astah GSN）

④ 活用できる場の提供（設計成果のレビューに採用）

⑤ 期待するGSNの構造の共有（レビュー時に指導）

• スムーズな導入のためのポイント

– GSNの良し悪しを判断できる人が”一人”居ると良いです⇒何をどう描いたら役に立つか自信が持てなくなるので…

– はじめの”一人”の育成は、 DEOS協会、D-Case部会に協力を仰ぐと良いかと思います。

28 / 30

D-Caseに関するトレーニング

No. 科目名称 概要

1. 導入 ①D-Caseの必要性、②D-Caseの基本概念、③活用事例の共有

2. 議論モデル境界 ①議論範囲の決定、②議論範囲の妥当性評価

3. 議論モデル作成 ①主張の設定、②主張を分解する説明の設定、③主張・説明に対する前提の設定、④主張を支える証拠の設定、⑤議論モデルの作成手順

4. 議論モデル妥当性確認

①用語の評価基準、②主張の評価基準、③説明の評価基準、④前提の評価基準、⑤証拠の評価基準

5. 議論モデル合意形成 ①合意形成の基礎、②合意形成の手順

6. 議論モデル管理 ①議論モデルの変更要因、②変更に対する影響範囲分析、③変更に対する追跡性の版管理、④変更管理の手順

7. ツール支援 ①ツール要求、②ツール評価、③ツール導入手順

導入

議論モデル境界

議論モデル作成

議論モデル管理

議論モデル妥当性評価

議論モデル合意形成 ツール支援

科目一覧

弊社からD-Caseトレーニング構造編を提供可能（DEOS認定取得済）

※赤枠：トレーニング提供可能範囲

29 / 30

D-Case関連の参考情報

• D-Case推進団体– DEOS協会（ディペンダビリティ技術推進協会）

• http://deos.or.jp/index-j.html

– D-Case研究会

• http://www.dcase.jp

• D-Case関連の公開記事– Youtube：モデリングしてますか？ - GSN/D-Case/安全コンセプト

• https://www.youtube.com/playlist?list=PLcb1q4H_P-

HTyrGX_y47XIQzXORGD3D2g

• D-Caseに関するツール– astah GSN

• http://astah.change-vision.com/ja/product/astah-gsn.html

– D-Case Editor

• http://www.dcase.jp/p/jeditor.htmlお問い合わせ先：・株式会社デンソークリエイト 宇都宮浩之・E-mail: hiroyuki@dcinc.co.jp

30 / 30