講演資料

ＣＢＣＳ安全要求の適用性向上に
向けた可視化の取り組み
奈良先端科学技術大学院大学
柿本和希
川口真司高井利憲石濱直樹飯田元片平真史
13th WOCS2
1/20/2016
Copyright © 2016 奈良先端科学技術大学院大学 All Rights Reserved.
1
Outline
• 背景
–
–
CBCS安全要求
一般安全要求とその問題点
• 研究概要
–
–
目的とアプローチ
関連研究
• GSNを用いたCBCS安全要求の可視化
–
–
可視化コンセプト
構築例
• 評価
–
–
評価実験
分析と考察
• まとめ
13th WOCS2
1/20/2016
Copyright © 2016 奈良先端科学技術大学院大学 All Rights Reserved.
2
Computer-Based Control System(CBCS)
安全要求
•
国際宇宙ステーション(ISS) の建造にあたって，
NASAが定めた安全要求
– ISS に関連する全てのコンピュータシステムに対して適用される
一般安全要求
– CBCS 安全要求の適用されるシステムは，NASA に対する安全審査を通過す
る必要がある
•
一般安全要求: 特定分野のシステムに汎用的に適用される安全要求
13th WOCS2
1/20/2016
Copyright © 2016 奈良先端科学技術大学院大学 All Rights Reserved.
3
一般安全要求適用の流れ
1. 解釈
–
一般安全要求において，実際にはどのようなことが求められるかを
理解する
2. 開発
–
解釈をもとに，安全要求に従ってシステムの開発を行う
3. 審査
–
システム
システムが一般安全要求を満たすことを
ステークホルダーに説明し，審査を受ける
開発
安全
要求
13th WOCS2
1/20/2016
解釈
開発者
審査
Copyright © 2016 奈良先端科学技術大学院大学 All Rights Reserved.
審査者
4
一般安全要求適用時の問題点
• 暗黙的な記述が存在しており，その解釈に幅がある
• 条文の意図から外れた解釈
– 危険性が残留したシステム開発
– 安全審査における危険性の見落とし
システム
開発
安全
要求
13th WOCS2
1/20/2016
解釈
開発者
審査
Copyright © 2016 奈良先端科学技術大学院大学 All Rights Reserved.
審査者
5
CBCS安全要求における暗黙的な記述例
実際の条文
条文: 3.1.1.1
『CBCSは既知の安全な状態で起動する』
読み取ることが難しい情報
暗黙知
起動時だけではなく，起動中も安全化が
必要
システムに依存する記述
『既知の安全な状態』がどのような状態
を指すか明確ではなく，定義がシステム
やシステムの状態に依存してしまう
例外事項
異常起動を起こす可能性がある場合でも
安全化されていればよい
実際に考慮する必要のある暗黙的な情報
13th WOCS2
1/20/2016
Copyright © 2016 奈良先端科学技術大学院大学 All Rights Reserved.
6
Outline
• 背景
–
–
CBCS安全要求
一般安全要求とその問題点
• 研究概要
–
–
目的とアプローチ
関連研究
• GSNを用いたCBCS安全要求の可視化
–
–
可視化コンセプト
構築例
• 評価
–
–
評価実験
分析と考察
• まとめ
13th WOCS2
1/20/2016
Copyright © 2016 奈良先端科学技術大学院大学 All Rights Reserved.
7
目的とアプローチ
• 目的: 暗黙的に記述された一般安全要求の条文の明確化
1.
2.
一般安全要求に対する正しい理解・解釈の支援
一般安全要求を用いた設計・審査の効率化の支援
• アプローチ: Goal Structuring Notation (GSN) を用いて条文の
解釈に必要な情報を可視化することにより明確化する
– Goal Structuring Notation
• 議論を可視化するための記法
• 安全性に関する議論を記述する目的でも用いられる
13th WOCS2
1/20/2016
Copyright © 2016 奈良先端科学技術大学院大学 All Rights Reserved.
8
Goal-Structuring Notation
ゴール1
• Goal
– 保証されるべき主張
ゴール1を分
割する戦略
• Strategy
– Goal を保証するための戦略
– Goal を複数のサブゴールに分割する
• Solution
– Goalが満たされる証拠
13th WOCS2
1/20/2016
ゴール１の
サブゴール
サブゴール
が満たされ
る証拠
Copyright © 2016 奈良先端科学技術大学院大学 All Rights Reserved.
ゴール１の
サブゴール
サブゴール
が満たされ
る証拠
9
今回のアプローチによる条文の可視化
自然言語による記述例
条文:CBCSは既知の
安全な状態で起動する
単純な変換によるGSNに
よる記述例
今回のアプローチによる
GSNによる記述例
CBCSは既知の安全
な状態で起動する
3.1.1.1 [G1]
3.1.1.1[C4]
The CBCS shall safety initialize
to a known, safe state.
CBCSは既知の安全な状
態で起動する
3.1.1.1[C3]
3.1.1.1 [S1]
前提となる合意事項を分けて
議論する
3.1.1.1 [G2] <agreement>
3.1.1.1 [G3]
安全な状態の定義について
合意がなされている
CBCSは合意された既知の
安全な状態で起動する
安全な状態が具体的にど
のような状態なのか，元
の条文では明確でないた
め，前提として定義する
必要がある
3.1.1.1[C2]
3.1.1.1 [S2]
検証
結果
設計と検証、安全な状態に関
する合意に分けて議論する
安全な起動状態に対する
同意事項，設計において
暗黙的に求められる事
項，設計に対する検証が
求められる
3.1.1.1 [G5]
CBCSは合意された既知
の安全な状態で起動する
設計となっている
3.1.1.1 [G4] <agreement>
安全な起動状態について
合意している
3.1.1.1 [S4]
3.1.1.1 [S3]
オフノミナルな状態と、起
動過程の状態に分けて議論
する
起動する状況と、それに対
する状態に分けて議論する
3.1.1.1 [G7]
システムが起動する可能性
のある状況がすべて識別さ
れている
3.1.1.1 [G8] <agreement>
システムが起動する可能性のあ
る全ての状況に対して起動時の
状態が定義され、それらが安全
であることに合意している
3.1.1.1 [C1]
3.1.1.1 [G9]
G49によって合意した安
全な状態の定義に基づい
た状態が定義されている
必要がある
（異常起動を起こす可能
性がある場合）異常起動
を起こしても安全な状態
である
3.1.1.1 [G10]
3.1.1.1 [G11]
Power ON から初期状態
に至るまでの過程におい
ても安全な状態である。
定義された安全な状態
以外ではCBCSは起動
しない
3.1.1.1 [S6]
ハザードごとに議論する
13th WOCS2
1/20/2016
Copyright © 2016 奈良先端科学技術大学院大学 All Rights Reserved.
3.1.1.1 [G15]
ある起動時のハザードAが
発生した場合において
も、CBCSは安全な状態
10
関連研究
• アシュアランスケース（GSN）による保証と一般安全要求に
よる保証を比較した研究[1]
– 簡単なシステムの保証を行い，定性的に比較を行った
– 一般安全要求による保証
• 規格に従うことで，エビデンスを揃えやすい
• 条文をどのように適用するべきかがわかりづらい
• どのように安全性が確保されるのかが暗黙的
– GSNによる保証
• GSNを用いた保証は，どのように安全性が確保されているのかを明確に
することができる
• 自由度が高く，どのようなエビデンスを揃えればいいかがわからない
– それぞれ完全ではなく，相補的に用いるべきであると主張
[1] HawkiRichard ns el al. (2013): “Assurance cases and prescriptive software safety certification: A comparative study” Safety Science
13th WOCS2
1/20/2016
Copyright © 2016 奈良先端科学技術大学院大学 All Rights Reserved.
11
関連研究
• DO-178C（航空機システムにかかわる安全要求）に含まれる
暗黙的な記述のGSNを用いた視覚化の研究[2]
– 背景:
• 既存の安全規格には多くの暗黙的な記述が含まれている
• 何故その検証や文書が必要かは述べられていない
– アプローチ:
• DO-178Cの各安全度レベルにおいて必要な検証や文書の視覚化
• 設計にまで踏み込んだ視覚化は行っていない
• 評価が行われていない
[2] C. Michael Holloway (Feb. 2015): “Explicate ‘78: 78 Discovering the Implicit Assurance Case in
Do-178C”, 23rd Safety-critical Systems Symposium, 2-5 Bristol, UK.
13th WOCS2
1/20/2016
Copyright © 2016 奈良先端科学技術大学院大学 All Rights Reserved.
12
Outline
• 背景
–
–
CBCS安全要求
一般安全要求とその問題点
• 研究概要
–
–
目的とアプローチ
関連研究
• GSNを用いたCBCS安全要求の可視化
–
–
可視化コンセプト
構築例
• 評価
–
–
評価実験
分析と考察
• まとめ
13th WOCS2
1/20/2016
Copyright © 2016 奈良先端科学技術大学院大学 All Rights Reserved.
13
CBCS安全要求のGSN化
1. 読み取ることが難しい情報の明確化
– 安全審査を通過した，過去の解釈を元にすることで意図から外れた
解釈をしてしまうことを防いだ
– 読み取ることが難しい情報を記述するため過去の解釈を参考にした
– JAXAエンジニア2名以上によるレビューを行った
2. システムに依存する記述の明確化
– 対象システムにおける解釈について，ステークホルダ間で合意するこ
とをゴールとした
3. 検証に対する要求の明確化
– 設計に対する要求と検証に対する要求をGSNの議論構造上で分けて
記述することで，どちらに対する要求なのかをわかりやすく記述した
13th WOCS2
1/20/2016
Copyright © 2016 奈良先端科学技術大学院大学 All Rights Reserved.
14
構築例
CBCSは既知の安全
な状態で起動する
（実際の条文）
2. システムに依存
する記述の明確化
3.1.1.1 [G1]
3.1.1.1[C4]
The CBCS shall safety initialize
to a known, safe state.
CBCSは既知の安全な状
態で起動する
3.1.1.1[C3]
3.1.1.1 [S1]
前提となる合意事項を分けて
議論する
3.1.1.1 [G2] <agreement>
3.1.1.1 [G3]
安全な状態の定義について
合意がなされている
CBCSは合意された既知の
安全な状態で起動する
安全な状態が具体的にど
のような状態なのか，元
の条文では明確でないた
め，前提として定義する
必要がある
3.1.1.1[C2]
3.1.1.1 [S2]
設計と検証、安全な状態に関
する合意に分けて議論する
安全な起動状態に対する
同意事項，設計において
暗黙的に求められる事
項，設計に対する検証が
求められる
3. 検証に対する
要求の明確化
3.1.1.1 [G5]
3.1.1.1 [G6]
CBCSは合意された既知
の安全な状態で起動する
設計となっている
3.1.1.1 [G4] <agreement>
安全な起動状態について
合意している
1. 読み取ることが難
しい情報の明確化
3.1.1.1 [S5]
3.1.1.1 [S4]
3.1.1.1 [S3]
3.1.1.1 [G7]
システムが起動する可能性
のある状況がすべて識別さ
れている
13th WOCS2
1/20/2016
4.3.1.1.1 に従って検証する
オフノミナルな状態と、起
動過程の状態に分けて議論
する
起動する状況と、それに対
する状態に分けて議論する
3.1.1.1 [G8] <agreement>
システムが起動する可能性のあ
る全ての状況に対して起動時の
状態が定義され、それらが安全
であることに合意している
3.1.1.1 [C1]
G49によって合意した安
全な状態の定義に基づい
た状態が定義されている
必要がある
3.1.1.1 [G9]
（異常起動を起こす可能
性がある場合）異常起動
を起こしても安全な状態
である
3.1.1.1 [G10]
3.1.1.1 [G11]
Power ON から初期状態
に至るまでの過程におい
ても安全な状態である。
定義された安全な状態
以外ではCBCSは起動
しない
Copyright © 2016 奈良先端科学技術大学院大学
All Rights Reserved.
3.1.1.1 [S6]
ハザードごとに議論する
CBCSは合意された既知
の安全な状態で起動する
ことが検証されている
3.1.1.1 [G12]
3.1.1.1 [G13]
既知の安全な状態で起動
する
想定外のハザーダス
ンドを送出しない
15
1. 読み取ることが難しい情報の明確化
3.1.1.1 [G1]
3.1.1.1[C4]
The CBCS shall safety initialize
to a known, safe state.
CBCSは既知の安全な状
態で起動する
3.1.1.1[C3]
3.1.1.1 [S1]
前提となる合意事項を分けて
議論する
3.1.1.1 [G2] <agreement>
3.1.1.1 [G3]
安全な状態の定義について
合意がなされている
CBCSは合意された既知の
安全な状態で起動する
安全な状態が具体的にど
のような状態なのか，元
の条文では明確でないた
め，前提として定義する
必要がある
3.1.1.1[C2]
3.1.1.1 [S2]
設計と検証、安全な状態に関
する合意に分けて議論する
3.1.1.1 [G4] <agreement>
安全な起動状態について
合意している
安全な起動状態に対する
同意事項，設計において
暗黙的に求められる事
項，設計に対する検証が
求められる
3.1.1.1 [G5]
3.1.1.1 [G6]
CBCSは合意された既知
の安全な状態で起動する
設計となっている
CBCSは合意された既知
の安全な状態で起動する
ことが検証されている
3.1.1.1 [S5]
3.1.1.1 [S4]
3.1.1.1 [S3]
3.1.1.1 [G7]
システムが起動する可能性
のある状況がすべて識別さ
れている
13th WOCS2
1/20/2016
4.3.1.1.1 に従って検証する
オフノミナルな状態と、起
動過程の状態に分けて議論
する
起動する状況と、それに対
する状態に分けて議論する
3.1.1.1 [G8] <agreement>
システムが起動する可能性のあ
る全ての状況に対して起動時の
状態が定義され、それらが安全
であることに合意している
3.1.1.1 [C1]
G49によって合意した安
全な状態の定義に基づい
た状態が定義されている
必要がある
3.1.1.1 [G9]
（異常起動を起こす可能
性がある場合）異常起動
を起こしても安全な状態
である
3.1.1.1 [G10]
3.1.1.1 [G11]
Power ON から初期状態
に至るまでの過程におい
ても安全な状態である。
定義された安全な状態
以外ではCBCSは起動
しない
Copyright © 2016 奈良先端科学技術大学院大学
All Rights Reserved.
3.1.1.1 [S6]
ハザードごとに議論する
3.1.1.1 [G12]
3.1.1.1 [G13]
既知の安全な状態で起動
する
想定外のハザーダス
ンドを送出しない
16
設計と検証、安全な状態に関
する合意に分けて議論する
項，設計に対する検証が
求められる
1. 読み取ることが難しい情報の明確化
3.1.1.1 [G5]
CBCSは合意された既知
の安全な状態で起動する
設計となっている
3.1.1.1 [S4]
オフノミナルな状態と、起
動過程の状態に分けて議論
する
3.1.1.1 [G12
既知の安全な
する
3.1.1.1 [G9]
た安
基づい
ている
（異常起動を起こす可能
性がある場合）異常起動
を起こしても安全な状態
である
13th WOCS2
3.1.1.1 [S6]
1/20/2016
3.1.1.1 [G10]
3.1.1.1 [G11]
Power ON から初期状態
に至るまでの過程におい
ても安全な状態である。
定義された安全な状態
以外ではCBCSは起動
しない
Copyright © 2016 奈良先端科学技術大学院大学 All Rights Reserved.
17
2. システムに依存する記述の明確化
3.1.1.1 [G1]
3.1.1.1[C4]
The CBCS shall safety initialize
to a known, safe state.
CBCSは既知の安全な状
態で起動する
3.1.1.1[C3]
3.1.1.1 [S1]
前提となる合意事項を分けて
議論する
3.1.1.1 [G2] <agreement>
3.1.1.1 [G3]
安全な状態の定義について
合意がなされている
CBCSは合意された既知の
安全な状態で起動する
安全な状態が具体的にど
のような状態なのか，元
の条文では明確でないた
め，前提として定義する
必要がある
3.1.1.1[C2]
3.1.1.1 [S2]
設計と検証、安全な状態に関
する合意に分けて議論する
3.1.1.1 [G4] <agreement>
安全な起動状態について
合意している
安全な起動状態に対する
同意事項，設計において
暗黙的に求められる事
項，設計に対する検証が
求められる
3.1.1.1 [G5]
3.1.1.1 [G6]
CBCSは合意された既知
の安全な状態で起動する
設計となっている
CBCSは合意された既知
の安全な状態で起動する
ことが検証されている
3.1.1.1 [S5]
3.1.1.1 [S4]
3.1.1.1 [S3]
3.1.1.1 [G7]
システムが起動する可能性
のある状況がすべて識別さ
れている
13th WOCS2
1/20/2016
4.3.1.1.1 に従って検証する
オフノミナルな状態と、起
動過程の状態に分けて議論
する
起動する状況と、それに対
する状態に分けて議論する
3.1.1.1 [G8] <agreement>
システムが起動する可能性のあ
る全ての状況に対して起動時の
状態が定義され、それらが安全
であることに合意している
3.1.1.1 [C1]
G49によって合意した安
全な状態の定義に基づい
た状態が定義されている
必要がある
3.1.1.1 [G9]
（異常起動を起こす可能
性がある場合）異常起動
を起こしても安全な状態
である
3.1.1.1 [G10]
3.1.1.1 [G11]
Power ON から初期状態
に至るまでの過程におい
ても安全な状態である。
定義された安全な状態
以外ではCBCSは起動
しない
Copyright © 2016 奈良先端科学技術大学院大学
All Rights Reserved.
3.1.1.1 [S6]
ハザードごとに議論する
3.1.1.1 [G12]
3.1.1.1 [G13]
既知の安全な状態で起動
する
想定外のハザーダス
ンドを送出しない
18
2. システムに依存する記述の明確化
3.1.1.1 [G4] <agreement>
安全な起動状態について
合意している
3.1.1.1 [S3]
起動する状況と、それに対
する状態に分けて議論する
3.1.1.1 [G7]
システムが起動する可能性
のある状況がすべて識別さ
れている
13th WOCS2
1/20/2016
3.1.1.1 [G8] <agreement>
システムが起動する可能性のあ
る全ての状況に対して起動時の
状態が定義され、それらが安全
であることに合意している
Copyright © 2016 奈良先端科学技術大学院大学 All Rights Reserved.
3.1.1.
G49に
全な状
た状態
19
必要が
3. 検証に対する要求の明確化
3.1.1.1 [G1]
3.1.1.1[C4]
The CBCS shall safety initialize
to a known, safe state.
CBCSは既知の安全な状
態で起動する
3.1.1.1[C3]
3.1.1.1 [S1]
前提となる合意事項を分けて
議論する
3.1.1.1 [G2] <agreement>
3.1.1.1 [G3]
安全な状態の定義について
合意がなされている
CBCSは合意された既知の
安全な状態で起動する
安全な状態が具体的にど
のような状態なのか，元
の条文では明確でないた
め，前提として定義する
必要がある
3.1.1.1[C2]
3.1.1.1 [S2]
設計と検証、安全な状態に関
する合意に分けて議論する
3.1.1.1 [G4] <agreement>
安全な起動状態について
合意している
安全な起動状態に対する
同意事項，設計において
暗黙的に求められる事
項，設計に対する検証が
求められる
3.1.1.1 [G5]
3.1.1.1 [G6]
CBCSは合意された既知
の安全な状態で起動する
設計となっている
CBCSは合意された既知
の安全な状態で起動する
ことが検証されている
3.1.1.1 [S5]
3.1.1.1 [S4]
3.1.1.1 [S3]
3.1.1.1 [G7]
システムが起動する可能性
のある状況がすべて識別さ
れている
13th WOCS2
1/20/2016
4.3.1.1.1 に従って検証する
オフノミナルな状態と、起
動過程の状態に分けて議論
する
起動する状況と、それに対
する状態に分けて議論する
3.1.1.1 [G8] <agreement>
システムが起動する可能性のあ
る全ての状況に対して起動時の
状態が定義され、それらが安全
であることに合意している
3.1.1.1 [C1]
G49によって合意した安
全な状態の定義に基づい
た状態が定義されている
必要がある
3.1.1.1 [G9]
（異常起動を起こす可能
性がある場合）異常起動
を起こしても安全な状態
である
3.1.1.1 [G10]
3.1.1.1 [G11]
Power ON から初期状態
に至るまでの過程におい
ても安全な状態である。
定義された安全な状態
以外ではCBCSは起動
しない
Copyright © 2016 奈良先端科学技術大学院大学
All Rights Reserved.
3.1.1.1 [S6]
ハザードごとに議論する
3.1.1.1 [G12]
3.1.1.1 [G13]
既知の安全な状態で起動
する
想定外のハザーダス
ンドを送出しない
20
3. 検証に対する要求の明確化
3.1.1.1 [G6]
CBCSは合意された既知
の安全な状態で起動する
ことが検証されている
3.1.1.1 [S5]
4.3.1.1.1 に従って検証する
3.1.1.1 [G12]
3.1.1.1 [G13]
3.1.1.1 [G14]
既知の安全な状態で起動
する
想定外のハザーダスコマ
ンドを送出しない
異常起動に対しても既知
の安全な状態を保持する
13th WOCS2
1/20/2016
Copyright © 2016 奈良先端科学技術大学院大学 All Rights Reserved.
21
構築結果
• GSN化済みの条文: 12/38
ゴール数
合意ゴール数ストラテジ数
総計
168
14
66
平均
14
1.16
5.5
最大数
（１条文あたり）
25
3
12
最小数
（１条文あたり）
3
0
1
13th WOCS2
1/20/2016
Copyright © 2016 奈良先端科学技術大学院大学 All Rights Reserved.
22
Outline
• 背景
–
–
CBCS安全要求
一般安全要求とその問題点
• 研究概要
–
–
目的とアプローチ
関連研究
• GSNを用いたCBCS安全要求の可視化
–
–
可視化コンセプト
構築例
• 評価
–
–
評価実験
分析と考察
• まとめ
13th WOCS2
1/20/2016
Copyright © 2016 奈良先端科学技術大学院大学 All Rights Reserved.
23
評価実験概要
• 安全審査における，提案手法の有効性を評価する
• HTVを想定した，誤りを含む架空の仕様に対して安全審査を
行う
– 定量的調査
• 誤りに対する対策の記述数
• 誤りの発見数
– アンケートによる自己評価
• 対策の記述に対する達成度
• 誤りに発見に対する達成度
従来版
CBCS
審査
GSN版
CBCS
想定
HTV
仕様
JAXAエンジニア各チーム10名
13th WOCS2
1/20/2016
Copyright © 2016 奈良先端科学技術大学院大学 All Rights Reserved.
24
評価実験環境
• JAXAエンジニア 20名
– GSNによって記述されたCBCS安全要求を用いるグループ10名
– 従来のCBCS安全要求を用いるグループ10名
• 以下の知識に対して調査し，偏りのないようにチーム分けを
行った
– HTVに関する知識
– GSNに関する知識
• 問題数: 全4問
• 実験時間: 1時間
– 事前説明: 10分
– 安全審査: 40分
– アンケート記入 :10分
13th WOCS2
1/20/2016
Copyright © 2016 奈良先端科学技術大学院大学 All Rights Reserved.
25
問題例
逸脱
意図しないメモリの変更がおこなわれる
原因
SEUによるビットの反転
対応条文
3.1.1.7
逸脱への
対策
・ビット反転を検出し復帰する
13th WOCS2
1/20/2016
・1ビットの反転に対して誤り訂正ができる
Copyright © 2016 奈良先端科学技術大学院大学 All Rights Reserved.
26
問題例
逸脱
意図しないメモリの変更がおこなわれる
原因
SEUによるビットの反転
対応条文
3.1.1.7→3.1.1.6
逸脱への
対策
・ビット反転を検出し復帰する
13th WOCS2
1/20/2016
・1ビットの反転に対して誤り訂正ができる
・2ビット以上の誤りには多重化で対応する
Copyright © 2016 奈良先端科学技術大学院大学 All Rights Reserved.
27
評価実験結果: 正答数と回答時間
• 平均得点（4点満点中）
– GSN: 2.78点
– 従来: 1.90点
4
3.5
3
– 1Q-(IQR*1.5)〜3Q+(IQR*1.5)外は外れ値とした
• 平均回答時間
– GSN: 38.4分
– 従来: 34.7分
• 得点に対する有意差検定
– スチューデントのt検定
– 危険率p = 0.026… < 0.05
2.5
2
1.5
1
0.5
0
GSN
13th WOCS2
1/20/2016
Copyright © 2016 奈良先端科学技術大学院大学 All Rights Reserved.
従来
28
評価実験自己評価: アンケート
GSNによって記述されたCBCS安全要求を用いたグループ
従来のCBCS安全要求を用いたグループ
13th WOCS2
1/20/2016
Copyright © 2016 奈良先端科学技術大学院大学 All Rights Reserved.
29
実験結果のまとめと考察
• GSNで記述した安全要求を用いた場合
– 実際の得点は高かったが，被験者の自己評価は従来の
安全要求よりも低かった
• 従来の安全要求を用いた場合
– 実際の得点が悪いにもかかわらず，被験者の自己評価
が高かった
13th WOCS2
1/20/2016
Copyright © 2016 奈良先端科学技術大学院大学 All Rights Reserved.
30
実験結果から得られた仮説と検証方針
1. GSN版CBCS安全要求を用いた場合，実際には適用出来ていても
低い自己評価を行ってしまう
– 過剰設計の原因となる可能性がある
2. 従来の安全要求を用いた場合，実際には適用出来ていなくても
適用出来ていると思い込んでしまう
– 安全審査における見落としの原因となる可能性がある
• 仮説の検証のため，それぞれのグループにおいて課題の点数と
アンケート結果の関係について以下の分析を行った
1. 実際の結果が良い被験者が低い自己評価を行っていないか
2. 実際の結果が悪い被験者が高い自己評価を行っていないか
3. 自己評価と実際の点数に相関があるか
13th WOCS2
1/20/2016
Copyright © 2016 奈良先端科学技術大学院大学 All Rights Reserved.
31
仮説に対する分析
GSNによって記述されたCBCS安全要求を用いたグループ
全体
ポジティブ
ネガティブ
相関係数
対策の記述
2.78
3.5（2人）
2.5（7人）
0.658…
誤りの発見
2.78
3.33(3人)
2.25（5人）
0.549…
従来のCBCS安全要求を用いたグループ
全体
ポジティブ
ネガティブ
相関係数
対策の記述
1.90
1.67（3人）
2.25（4人）
- 0.251…
誤りの発見
1.90
1.80（5人）
1.67（3人）
0.146…
– グループ分けは以下のように行った
• ポジティブ群『とてもよくできた』，『できた』
• ネガティブ群『できなかった』，『あまりできなかった』
– アンケートにおける５段階の回答（できなかった〜よくできた）をそれぞれ
1～5点として得点とのピアソンの積率相関係数を求めた
13th WOCS2
1/20/2016
Copyright © 2016 奈良先端科学技術大学院大学 All Rights Reserved.
32
分析に対する考察
• GSNによって記述されたCBCS安全要求を用いた場合
– 自己評価と実際の結果に正の相関がある
• 従来のCBCS安全要求
– 自己評価と実際の結果に相関がない
• 安全審査において従来のCBCS安全要求を用いた場合，
審査者が十分に適用したと感じた場合においても危険性
が見過ごされている恐れがある
• 見過ごされた危険性は後の工程や運用時に顕在化し，
コストの増大や重大な事故の原因となりうる
13th WOCS2
1/20/2016
Copyright © 2016 奈良先端科学技術大学院大学 All Rights Reserved.
33
評価実験から期待される貢献
• 開発者への貢献
– 条文の解釈に対する支援
– 設計・開発時における条文の適用性の向上
• 審査者への貢献
– 条文に合わない仕様・設計の発見率の向上
• 双方への利益
– 審査時，条文適用時の実感と実際の結果の一致
– 安全性の向上
13th WOCS2
1/20/2016
Copyright © 2016 奈良先端科学技術大学院大学 All Rights Reserved.
34
今後の課題
• CBCS安全要求全体に対する理解の支援
– 条文ごとのGSNではなく，条文間の関係の理解も含めた支援を行う
• 合意ゴールの有効性確認
– 合意を目的としたゴールを設定することによる開発への効果を検証
する
– 合意内容をGSNによって記述することによる安全審査への効果を
検証する
13th WOCS2
1/20/2016
Copyright © 2016 奈良先端科学技術大学院大学 All Rights Reserved.
35
まとめ
• 問題: 一般安全要求は自然言語によってあいまいに記述さ
れており，その解釈は開発者の知識や能力によって変わっ
てしまう
• 提案: GSNを応用する
• 貢献:
– 一般安全要求の暗黙的な記述を可視化により明確化できた
– 評価実験を通して有効性を確認した
• 評価結果:
– 誤りの発見と対策の記述において良い影響を与える
– 開発者の思い込みによる誤りの見逃しを防ぐ効果がある
13th WOCS2
1/20/2016
Copyright © 2016 奈良先端科学技術大学院大学 All Rights Reserved.
36

Download Report