アジェンダ アシュアランスケースとは アシュアランスケースの必要性 論理の基礎 アシュアランスケースの表記法 GSN を例とした記法の説明 アシュアランスケースの利用 つながる世界での応用 3

アシュアランスケースの概要

ソフトウェアグループ・研究員 鈴木基史

独立行政法人 情報処理推進機構

技術本部 ソフトウェア高信頼化センター

2016年1月19日

ソフトウェアグループ・研究員 佐々木方規

アジェンダ

• アシュアランスケースとは

• アシュアランスケースの必要性

• 論理の基礎

• アシュアランスケースの表記法

• GSNを例とした記法の説明

• アシュアランスケースの利用

• つながる世界での応用

セーフティケースの歴史

1988年の北海油田Piper Alphaにおける爆発事故で167名死亡

【従来】

システムの安全性確認をチェックリスト項目を認証者が判定

【課題】

なぜチェックリスト項目を満たすとシステムが安全であるか、明示的な議論

が行われることが少なかった

【改善点】

チェックリスト項目の手順やテストだけでなく、なぜそれらの手順やテスト

で、システムの安全性が保たれるのか、

明示された議論

で

証拠

(エビデンス)

をもとにした議論が重要

導入により北海油田における事故が減少

欧米で規格認証の際に義務付けられるまでに普及

北海油田事故の調査報告書： Safety Case

(Cullen 卿)

アシュアランスケースとは

セーフティケースとは、テスト結果や検証結果をエビデンスと

してそれらを根拠にシステムの安全性を議論し、システム認証

者や利用者などに保証する、あるいは確信させる(assure)ため

のドキュメント

アシュアランス（Assurance:保証）+

ケース

（Case:論拠）

安全性

セーフティ

ケース

セキュリティ

セキュリティ

ケース

ディペンダビリティ

ディペンダビリティ

ケース

＊＊

＊＊

ケース

アシュアランスケース

総称

ISO/IEC 15026

Systems and software engineering Systems and software assurance

食品の異物混入事件

Goal: G_1

生産・販売される食

品は安全である。

Context: C_1

事故後の記者会見

（説明）

Undeveloped: U_1

Strategy: S_1 Goal: G_2 Goal: G_3

Evidence: E_1 Evidence: E_2

記者会見で、

事件後も通常通り生産・販売する

ことが説明された後、

記者から何故、工場を停止してチェックする必

要が無いのか問われたが、説明できなかった。

今後も異物混入は続くかもしれない。

絶対安全はありえない。

(例）

異物混入があっても、すぐに原因を特定して

問題を取り除くプロセスがあることを主張

生産・販売される食品の安全性説明が必要

第三者が分かる説明が必要（論理と証拠が必要）

日本メーカ製自動車の「意図しない急加速（UA）」

 2009～2010年

日本メーカ製自動車の「意図しない急加速」に関するクレームが急増

 米国議会や米運輸省道路交通安全局(NHTSA)から報告を求められるもメー

カ側は説明に苦慮

 NHTSAは米国航空宇宙局(NASA)に脆弱性の有無の調査を要請

上記の結果ＮＡＳＡ が実施したこと



調査範囲

電子スロットル制御

(Electronic Throttle Control)

システムの設計及び/もしくは実装に実際に意図しな

い加速

(Unintended Acceleration)

を引き起こすことが予期できる脆弱性があるかないかを決定する。



UAを引き起こす可能性はあるか



通常の使用で実際に起こりうるか



実施した解析

（いずれもツールを最大限活用）



実装コードの解析



ロジックの解析



モデルベースのテスト



実時間性の解析



結果

NASAの解析とテストでは、消費者が報告したような、大きなUAを引き起こすETCの不具合の

証拠は見つからなかった。

客観的・合理的な説明の必要性



これまでの日本企業は、利用者の要望に個々に答えることで

高品質というブランド力を築いてきた



実際、日本製のソフトウェアの品質は海外に比べて1桁以上高いとの調

査報告もある



しかしながら、グローバル市場においては客観的・合理的な

説明が求められる

客観的・合理的な説明が必要



製品自体の品質を事実に基づいて論理的に説明できなくてはならない



国際標準（ISO/IEC）等、世界的に合意されている基準類を用いた説明、

または、それに準じた説明（規格適合、規格認証 等）



専門性のある第三者による説明（第三者確認、第三者証明 等）

議論とは



Discuss:

ある問題をあらゆる角度から論じる



Argue:

自分の考えを主張し相手の説を論駁(ろんばく)するために理由・

証拠をあげて議論する



Debate:

は公の問題を賛成・反対に分かれて公開の席上で公式に討論する



Dispute:

(一時的に感情的になって）論争する



Controvert:

(意見の相違の大きい問題などの長期にわたる、特に書きも

のなどによる

）論争

Discuss /

Argue

/ Debate /Dispute/Controvert

安全工学

セーフティケース

哲学

辞書から

議論学

Argumentation theory

人工知能

論理の基礎： スティーヴン・トゥールミン

http://en.wikipedia.org/wiki/Stephen_Toulmin

イギリス生まれの哲学者。

専門は、科学哲学。ロンドン生まれ。

1942年、ロンドン大学キングス・カレッジ卒業後、ケン

ブリッジ大学で博士号取得。

オックスフォード大学講師、リーズ大学教授、

1965年に渡米（69年帰化）、南カリフォルニア大学教授。

スティーヴン・トゥールミン

(Stephen Edelston Toulmin,

1922年3月25日 - 2009年12月4日)

【特筆すべき観念】

The Toulmin Model（トゥールミンモデル）

The Toulmin method （トゥールミン法）

Good reasons approach

トゥールミン・ロジックの基礎

主張

： Claim

基礎

： Data

根拠

： Warrant

論理の基本

主張（C論理）

論理として構築されるひとつの主張

基礎（D論理）

論理の根拠となる、状態、事実など

最初に呈示される説明情報

根拠（W論理）

クレームの根拠としてデータが利用

可能であることを正当化する情報

ディベートで超論理思考を手に入れる

ISBN 978-4-904209-13-4

著者： 苫米地英人 脳機能学者/カーネギーメロン大学博士

トゥールミンの三角ロジック（１）

主張： Claim

基礎： Data

根拠： Warrant

窓を開けた方がいい

室温が30度だ

窓を開ければ室温が下がり、

快適になる

http://kogolearn.wordpress.com/

早稲田大学人間科学学術院 向後千春

トゥールミンの三角ロジック

トゥールミンの三角ロジック（２）

主張： Claim

基礎： Data

根拠： Warrant

窓を開けた方がいい

室温が30度だ

窓を開ければ室温が下がり、

快適になる

反駁： Rebuttal

↑ 温度計が狂っている

←（主張は反駁できない）

反駁(はんばく）: Rebuttal

http://kogolearn.wordpress.com/

早稲田大学人間科学学術院 向後千春

トゥールミンの三角ロジック

↑ 外の方が気温が高ければ、

温度は下がらない

_{反駁： Rebuttal}

トゥールミンの三角ロジックが成り立っている場合

トゥールミンの三角ロジック（３）

主張： Claim

基礎： Data

根拠： Warrant

窓を開けた方がいい

室温が30度だ

窓を開ければ室温が下がり、

快適になる

質疑： Question

↑ なぜ30度だとわかるのか？

←（主張は反駁できない）

質疑: Question

http://kogolearn.wordpress.com/

早稲田大学人間科学学術院 向後千春

トゥールミンの三角ロジック

↑ なぜ窓を開けると

室温が下がるのか？

_{質疑： Question}

トゥールミンの三角ロジックが成り立っている場合

トゥールミンの三角ロジック（４）

主張： Claim

基礎： Data

根拠： Warrant

窓を閉めた方がいい

室温が30度だ

クーラを入れれば、

室温が下がり、快適になる

反論: Counter argument

http://kogolearn.wordpress.com/

早稲田大学人間科学学術院 向後千春

トゥールミンの三角ロジック

新たな三角ロジックを立てる

トゥールミン・モデル

クレーム

：Claim

データ

：Data

ワラント

：Warrant

論理を支える構造

クレーム（C論理）

論理として構築されるひとつの主張

データ（D論理）

論理の根拠となる、状態、事実など

最初に呈示される説明情報

ワラント（W論理）

クレームの根拠としてデータが利用

可能であることを正当化する情報

バッキング（B論理）

ワラントが正しいことを支持する証

拠、証言、統計、価値判断、信憑性

などの情報

クゥオリフィアー（Ｑ論理）

クレームの相対的強度の定性的な表

現。また、可能であれば90％などの

定量的な表現

リザベーション（Ｒ論理）

クレームに対する例外を主張する論

理

ディベートで超論理思考を手に入れる ISBN 978-4-904209-13-4 著者： 苫米地英人 脳機能学者/カーネギーメロン大学博士

バッキング

：Backing

リザベーション

：Reservation

クゥオリフィアー

：Qualifier

表記法

アシュアランスケースは通常、自然言語で記述



トゥールミン（Toulmin）モデル

Stephen Edelston Toulmin, 1922年3月25日 - 2009年12月4日

イギリス生まれの哲学者(専門は科学哲学)



GSN（Goal Structuring Notation）

イギリス ヨーク大学、イギリス国防省



D-CASE

日本 DEOS

（Dependable Embedded Operating Systems for Practical Use）プロジェクト

（科学技術振興機構（JST）の戦略的創造研究推進事業CRESTの研究領域のひとつとして作られた）



CAE (Claim Argument Evidence)

イギリス Adelard社、City University London

ゴール（Goal）

保証したいこと、命題（例：システムは安全である）

_{ゴールはさらに詳細なゴール（サブゴール）に分解される}

前提（Context)

システムの状態、環境などゴールを議論するときの前提等

_{（例：リスク分析の結果得られたハザードのリスト）}

戦略（Strategy）

ゴールをサブゴールに分けるときの考え方

_{（例：個別の障害ごとに議論する）}

ソリューション

（Solution）

ゴールが成り立つことを最終的の保証するもの

（例：テスト結果、運用事例など）

未展開記号

（Undeveloped entity）

ゴールを保障するための十分な議論又はエビデンスがない

（これはゴールやストラテジーにつけることができる）

ＧSＮ（Goal Structuring Notation）

 保証のための構造化された議論の記述法

(T.Kellyらにより開発）

- GSN Community Standard Ver.1.0

GSNの記述例

G1

システムは安全である

S1 ハザードがすべて回避されているこ とを保証する議論

G2

ハザード１

が回避されている

G3

ハザード２

が回避されている

Sn1

ハザード1

の回

避方法

Sn2

ハザード2

の回

避方法

C2

同定されたハザード

ハザード1

ハザード2

C1

システム仕様書

ゴール（Goal） 前提（Context) 戦略（Strategy） サブゴール（Sub Goal） 根拠（Solution）

D-Case

名称

ノード

解説

ゴール

対象システムに対して、議論すべき命題

戦略

ゴールが満たされることを、サブゴールに分

_{割して詳細化するときの議論の仕方}

前提

ゴールや戦略を議論するとき、その前提とな

_る情報

エビデンス

詳細化されたゴールを最終的に保障するもの

未達成

ゴールを保障するための十分な議論もしくは

_{エビデンスがない}

モニタ

運転中のシステムより取得可能なエビデンス

外部接続

他のシステムのD-Caseへのリンク

システムは ディペンダブル である ハザードごと に議論する ハザード リスト テスト 結果 システム ログ

D-CaseはGSNを使って表記します。

主に右表のノードにより構成されます。

このうち、モニタと外部接続はD-CaseのGSN からの拡張です。

DEOSプロジェクト研究成果集 P41, 図4-5: D-Caseの例 http://www.jst.go.jp/crest/crest-os/osddeos/data/DEOS-FY2013-SS-01J.pdf

CAE (Claims, Arguments and Evidence)

クレーム

(Claim)

議論

(Argument)

サブクレーム

(Subclaim)

サブクレーム

(Subclaim)

証拠

(Evidence)

サポート

クレーム

正しい又は誤りであ

ると評価することが

できる議論の中での

主張

それぞれのクレームは、いくつかの

サブクレーム、議論、又は証拠でサ

ポートされる。

サブクレームは付加的な文脈に関係

する資料、例えば使用される用語や

範囲の説明、を含んでいるかもしれ

ない。

議論

クレームを支持して

提示する議論アプ

ローチの記述

この要素はオプションであるが、多

くの場合、親クレームを満足するた

めのアプローチの説明を含めると良

い。

もしクレームをサポートするアプ

ローチが、対象とする読者によって

良く理解されているか、単純であれ

ば、単にサポートするクレームから

直接リンクすることが許容される。

証拠

クレーム又は議論を

支持して提示される

証拠への参照

通常、証拠ノードは要約され、そし

て証拠を含む関連する外部レポート

へリンクします。

http://www.adelard.com/asce/choosing-asce/cae.html

アシュアランスケースの国際標準化



国際標準化の活動の中心： OMG

(Object Management Group)

System Assurance Platform Task Force (SysA PTF)

ARM (Argumentation Metamodel)

FTF beta

SAEM (Software Assurance

Evidence Metamodel) FTF beta

SACM (Structured Assurance

Case Metamodel)

← UML, CORBA

統合

(2012年6月)

GSNとCAEを統合したメタモデル

http://www.omg.org/spec/SACM/1.1/PDF/

GSNの規格

GSNの仕様は、GSNワーキング グループの以下のWebサイトから入手可能

Goal Structuring Notation

The GSN Working Group Online

http://www.goalstructuringnotation.info/documents/GSN_Standard.pdf

GSN COMMUNITY STANDARD VERSION1

November 2011

TIM KELLY’S HOME PAGES

TIM KELLY氏：

イギリス ヨーク大学

コンピュータ・サイエンス学部

高信頼性システム 教授

高信頼性システム

エンジニアリング研究グループ

ジョイントリーダ

D-Case Editor



D-Case Editorは型チェック機能などを持つ、アシュアランスケースのエディター



Eclipseのプラグインで、Eclipse GMFを使って実装。

http://www.jst.go.jp/crest/crest-os/tech/D-CaseEditor/index.html



主な機能



アシュアランスケースの表記法であるGSN ( Goal Structuring Notation ) をサポート



GSNパターンライブラリ、基礎的な変数型チェック機能



D-Caseの整合性検査



対象システムのモニタリング機能

Eclipse (統合開発環境)



Eclipse

（「イクリプス」または「エクリプス」）

は、IBMによって開発された

統合開発環境 (IDE) の一つ。



高機能ながらオープンソース

であり、Javaをはじめとする

いくつかの言語に対応する。



Eclipse自体はJavaで記述され

ている。

http://ja.wikipedia.org/wiki/Eclipse_(%E7%B5%B1%E5%90%88%E9%96%8B%E7%99%BA%E7%92%B0%E5%A2%83)

D-Case Editorのインストール

1. パッケージ版にはEclipseにすでにD-Case Editorのプラグインが組み込み済み、またサンプルのWorkspaceも入っているので、

それを指定すればすぐに利用可能

1. Java VMをダウンロードしてインストール

https://java.com/ja/download/

2. D-Case Editorパッケージ版ダウンロード

*1

http://www.jst.go.jp/crest/crest-os/tech/D-CaseEditor/Download_files/eclipseWin32.zip

3. eclipseWin32.zipを解凍

4. 解凍済みフォルダーにあるeclipse.exeを起動

5. 起動時ウインドウ「Workspace Launcher」の「Workspace: 」に解凍

フォルダーの下にある[workspace」を指定する

*

より簡単にGSNを書いてみたい人へ

http://www.jst.go.jp/crest/crest-os/tech/D-CaseStencil/index.html



「D-Case Stencil - PowerPoint Add-in for D-Case」がお勧め



簡単にインストールして、PowerPointが使える人なら誰でも使える



作ったデータもDcase Editorに取り込みができる

インストールマニュアルはここ

ダウンロードはここから

操作マニュアルもあります

D-Case Stencil - PowerPoint Add-in for D-Case



インストール後、D-Caseタブを選択

インストールするとD-CASE タブが追加される

追加されるメニュー

D-CASE Editorへの取り込みも サポートされている

ノード

GSNノード（ゴール）

保証したいこと、主張

（例：システムは安全である）

ゴールはさらに詳細なゴール

（サブゴール）

に分解される

Goal: G_1

システムは安全である

主張

ID, ツールにより自動で設定される

GSNノード（ソリューション）

ゴールが成り立つことを最終的の保証するもの

（例：テスト結果、運用事例など）

Evidence: E_1

ハザード １の

回避方法

D-Caseではエビデンス

（根拠）

GSN CS V1はソリューション(ID: Sn1, Sn2…)

証跡（アイテム）

*1：危害要因のこと

リスクの原因とその属性のことを意味する

*1

GSNノードのつなげ方１（支援リンク）

Goal: G_1 ハザード１が回避さ れている Evidence: E_1 ハザード１の回避 方法

支援リンク(SupportedBy)

黒矢印

矢印の方向に注意

この構造はソリューションで

示される証跡がゴールに記載

される主張が正しいことを示

している

GSNノード（戦略）

ゴール(G_1)をサブゴール(G_2, G_3)に分けると

きの考え方

（例：ハザード がすべて回避されていることを保証する議論）

Goal: G_1 システムは安全である Strategy: S_1 ハザードがすべて回 避されていることを 保証する議論 Goal: G_2 ハザード１が回避 されている Goal: G_3 ハザード２が回避され ている

この戦略に従い、トップのゴールが下の２

つのサブゴールに分解される。

ここでは、ハザード分析をした結果を用い

て、各ハザード毎にその安全性を保証する

議論を構築する戦略である。

Evidence: E_1 ハザード１の回避 方法

GSNノード（前提）

戦略での使われ方

• 説明に関連する付加情報の宣言

• 使用される言葉の定義や説明

ゴールでの使われ方

• 主張の範囲の定義、制約

• 主張と関連した補足説明

（ゴールとコンテキスト間に矛盾がないように注意） Goal: G_1 システムは安全である Strategy: S_1 ハザードがすべて回 避されていることを 保証する議論 Goal: G_2 ハザード１が回避 されている Goal: G_3 ハザード２が回避され ている Evidence: E_1 ハザード１の回避 方法

Context: C_1

同定されたハザード

ハザード1

ハザード2

システムの状態、環境などゴールを議論するとき

の前提等

（例：リスク分析の結果得られたハザードのリスト）

GSNノードのつなげ方２（前提リンク）

前提リンクは，白矢印で表し，文脈的関係性を説明

Goal: G_1 システムは安全である Strategy: S_1 ハザードがすべて回 避されていることを 保証する議論 Goal: G_2 ハザード１が回避 されている Goal: G_3 ハザード２が回避され ている Evidence: E_1 ハザード１の回避 方法 *２

同定（どうてい）とは、ある対象について、そのものにかかわ

る既存の分類のなかからそれの帰属先をさがす行為。

リスクの性質等を考慮しながら絞り込んでいくことを意味する。

＊２：

GSNでは白矢印

前提リンク(InContextOf)

Context: C_1

同定されたハザード

ハザード1

ハザード2

未展開記号

Goal: G_1 システムは安全である Strategy: S_1 ハザードがすべて回 避されていることを 保証する議論 Goal: G_2 ハザード１が回避 されている Goal: G_3 ハザード２が回避され ている Evidence: E_1 ハザード１の回避 方法 *２

Context: C_1

同定されたハザード

ハザード1

ハザード2

Undeveloped: U_1

ゴールを保障するための十分な議論又はエビデンスがない

（これはゴールやストラテジーにつけることができる）

ゴールをサブゴールに分解する

Goal: G_1 ゴール Strategy: S_1 戦略 Goal: G_2 サブゴール Goal: G_3 サブゴール

GSNは、保証したいこと（ゴール）を複数のサブゴールに分割することによ

り詳細化し、詳細化されたサブゴール毎にそのサブゴールが成り立つことを

示す根拠により保証することにより、最初のゴールを保証するものである。

つまり、ゴールをどのようにサブゴールに分

割するかが非常に重要である。

ゴールをどのようにサブゴールに分割するか

を示すのが戦略であり、ここに

議論

が存在

ゴール分解に「議論分解パターン」を利用

議論分解パターン

項番

分解パターン

説明

１

アーキテクチャ分解 (architecture)

システム構成に従って分解

２

機能分解 (functional)

主張を機能構成に従って分解

３

属性分解 (set of attributes)

特性を複数の属性に分解

４

帰納分解(infinite set)

帰納法による分解

（N=1の時主張が成立、N=Kの時出張が成立ならＮ＝Ｋ＋１でも主張が成立）

５

完全分解 (complete)

説明対象のすべての要素による分解

６

単調分解 (monotonic)

新システムによる旧システムの改善点による分解

７

修正分解 (concretion)

曖昧性の明確化による分解

８

プロセス分解

プロセスの入力、処理、出力に対して主張を分解

９

プロセス関係分解

プロセス先行後続関係に基づいて主張を分解

１０

階層分解

対象の階層構成に基づいて、主張を分解

１１

ＤＦＤ分解

ＤＦＤの階層構成に基づいて、主張を分解

１２

ビュウ分解

UMLのビュウ構成に基づいて、主張を分解

１３

ユースケース分解

ユースケースに基づいて、主張を分解

１４

要求記述分解

要求の記述項目に対して、主張を分解

１５

状態遷移分解

状態遷移に対して、主張を分解

１６

運用要求記述分解

運用要求定義票に基づき、主張を分解

１７

シーケンス分解

シーケンス図に基づいて、出張を分解

１８

ビジネスプロセス分解

ビジネスプロセスモデル記法に基づき主張を分解

Safety and Assurance Cases: Past, Present and Possible Future – an Adelard Perspective, Robin Bloomfield and Peter Bishop

http://www.scsc.org.uk/pubs/2010%20Bloomfield.pdf ( )はBloomfieldのMain types

議論分解パターン例（属性分解）

Goal: G_1 システムは ディペンダブルである Context: C_1 ディペンダブル属性 可用性 安全性 信頼性 保守性 一貫性 Strategy: S_1 属性ごとに議論 Goal: G_2 システムは可用性 を持つ Goal: G_3 システムは安全性 を持つ Goal: G_4 システムは信頼性 を持つ Goal: G_5 システムは保守性 を持つ Goal: G_5 システムは一貫性 を持つ 「実践D-Case ディペンダビリティケースを活用しよう！」 P67

GSNの実際の記述例

「 既製システムをISO26262に適合させる場合のセーフティケースの利用とその評価 実施報告書」

2013年2月 IPA

http://www.ipa.go.jp/files/000026856.pdf

実験のためのモデルシステム

対象： 自動車用ドアロックシステム

（構造や制御の仕組みが比較的シンプルであり自動車に対する専門知識が無くても理解し易い）

ライフサイクル： 概要設計～システム設計

正統派と非正統派

アシュアランスケース利用には、正統派と非正統派がある



正統派

認証規格に利用



非正統派

認証規格の利用以外の広い応用範囲への利用

アシュアランスケースと認証規格



Safety Caseの作成、提出を義務付けている規格



Yellow Book: 鉄道システムの改変時の安全管理



EUROCONTROL: 安全で機能的な航空管制管理



ISO26262: 自動車の電気、電子システムの機能安全規格



Def-Stan 00-56: 英国防衛省策定の防衛システムの安全管理



US. Food and Drug Administration (FDA)

Infusion Pump Improvement Initiative:

点滴ポンプなどの医療器具の病院導入時

http://hceme.blog84.fc2.com/blog-entry-2234.html



今後はセーフティだけでなく、セキュリティ等

にも広がる可能性大

CC-Case:

file:///E:/Download/IPSJCSS2013066.pdf

http://lab.iisec.ac.jp/degrees/d/theses/iisec_d24_thesis.pdf

どのような利用があるのか

① 説明責任をはたすため

② ステークスフォルダーとの情報共有のため

③ 設計の再利用のため

④ ソフトウェアの相互の信頼性確認のため

何か設計・実装されているか容易に分かる

欧米では説明責任をはたすために、規格として求められるケースもある

マネージャレベルでも、アシュアランスケースから何が設計されているか、理解が可能

つながる世界において、ソフトウェアの相互の信頼性確認のための基礎

• ETロボコンへの応用例： 富士ゼロックス（株） 伊東敦

http://www.jst.go.jp/crest/crest-os/osddeos/event/201211/ET2012C805.pdf

• 計画立案時の事例： （株）デンソークリエイト 小林 展英

http://www.jst.go.jp/crest/crest-os/osddeos/event/201402/DEOS_13.pdf

• シミュレーションへの適用例： 三菱電機（株） 森 素子

http://deos.or.jp/event/files/ET2014presentation_mitsubishielectric.pdf

より詳しく学習するために

【書籍教材】

• D-Case入門 ～ディペンダビリティ・ケースを書いてみよう！～

松野裕、高井利憲、山本修一郎

発行所 株式会社ダイテックホールディング

http://www.dimensions-japan.org/dcase/pdf/DCaseIntro.pdf

• 実践D-Case ディペンダビリティケースを活用しよう！

松野裕、山本修一郎

2013年3月25日発行

ISBN 978-4-86293-091-0

http://www.dimensions-japan.org/dcase/pdf/JissenDCase.pdf

【ビデオ教材】

• GSN解説(1) - GSN (Goal Structuring Notation)とは何か？

名古屋大学 山本修一郎教授 (2:58)

https://www.youtube.com/watch?v=cV8oJ4mcMwM

• GSN解説(2) - GSNの基礎とその構成要素 名古屋大学 山本修一郎教授 (2:32)

https://www.youtube.com/watch?v=0OOxmxrnZS0

• アシュランス・セイフティーケース概論 ～歴史的背景と制度～

産総研 田口研治 招聘研究員(4:54)

https://www.youtube.com/watch?v=VedmkvMcBEg

• GSN記法チュートリアル～書き方のコツ～ 産総研 相馬 研究員(2:40)

https://www.youtube.com/watch?v=S32kLHBT96c

基礎編 ５．アシュアランスケース概論 ６．D-Case作法 応用編 ７．D-Case演習 ８．議論分解パターン ９．D-Case Editorの使い方 ３．D-Case/GSNの基礎 ４．D-Case作成法 ５．議論分解パターン

より詳しく学習するために

【セミナー報告書】

SEC高信頼化技術適用事例セミナー

D-Caseの適用事例に学ぶ、合意形成と説明責任

・D-Caseで高信頼性をどのように保証するか？ ～D-Case活用の基本パターン～

IPA/SEC 連携委員 国立大学法人名古屋大学 情報連携統括本部 情報戦略室

教授 山本 修一郎 氏

http://sec.ipa.go.jp/users/seminar/seminar_tokyo_20150717-01.pdf

・D-Caseを用いたゴール共有による開発プロセスの適用 ～ETロボコンでの試行と成果～

富士ゼロックス株式会社 コントローラ開発本部 コントローラプラットフォーム第二開発部

マネージャー 土樋 祐希 氏

http://sec.ipa.go.jp/users/seminar/seminar_tokyo_20150717-02.pdf

・D-Caseで開発成果の品質をどのように説明するか？

～ソフトウェア開発現場におけるD-Case活用事例～

株式会社デンソークリエイト プロジェクトセンター シニアデスク

小林 展英 氏

http://sec.ipa.go.jp/users/seminar/seminar_tokyo_20150717-03.pdf

http://sec.ipa.go.jp/seminar/20150717.html

より詳しく学習するために

【セミナー報告書】

SEC高信頼化技術適用事例セミナー

D-Caseの適用事例に学ぶ、合意形成と説明責任

・第三者検証における保証の見える化

～独立検証及び妥当性確認（IV&V）における事例紹介～

国立研究開発法人宇宙航空研究開発機構

研究開発部門 第三研究ユニット 研究員

神戸 大輔 氏

http://sec.ipa.go.jp/users/seminar/seminar_tokyo_20150717-04.pdf

・D-Case実用化へ向けた活動の動向について ～日本の安全・安心を世界で共有するために～

一般社団法人ディペンダビリティ技術推進協会（DEOS）

DEOSプロジェクト

http://deos.or.jp/consortium-guidance/index-j.html

D-Caseの実用化へ向けた標準化・認証制度

https://www.ipa.go.jp/sec/info/21050617.html

D-Case部会主査

日本大学理工学部

応用情報工学科 准教授

松野 裕 氏

http://sec.ipa.go.jp/users/seminar/seminar_tokyo_20150717-05.pdf

http://sec.ipa.go.jp/seminar/20150717.html

「つながる世界」での安心・安全の仕組み環境の整備に向けて

課題

リスクのある連携動作に

警告発生

異なる品質基準の製品間の

制御可否

判断

目指す

世界

【

】

セーフティ＆セキュリティ設計

の見える化

環境の整備に向けた活動

H26年度

ソフトウェア相互の

信頼性確認の仕組み

トラスト環境の整備

• 品質基準が異なる製品を接続する際、その全体品質が一番低い部分の品質に依存する課題

• 利用者が製品やサービスを組み合わせて利用する際、すべての接続品質の検証が困難という課題

（安全性、セキュリティ等）

設計品質の見える化の推進

セーフティ＆セキュリティ設計

の品質の見える化

セーフティ＆セキュリティ設計

の普及・促進

2015年 品質向上のためのセーフティ＆ セキュリティ設計の勧め

ガイドブック作成

プロモーション

H26年度

H27年度以降

セミナー、雑誌

ソフトウェア相互の信頼性確認の仕組み

警告発生・制御可否

設計品質の見える化

見える化（アシュアランスケース）

セーフティ・セキュリティ設計

WOCS

2

₁₃

th

_{(3日目） 1/21 15:40～16:30}

招待講演 つながる世界（

IoT時代

）の天使と悪魔

中尾 昌善 氏

（独立行政法人情報処理推進機構 ソフトウェア高信頼化センター）

Check！

Catch！

Search！