設計の見える化 (GSN) 入門 Embedded Technology 2015 2015.11.19, パシフィコ横浜 ( 株 ) デンソークリエイト宇都宮浩之
会社概要と私の経歴 1 / 30 会社概要 所在地 : 本社 ( 名古屋市中区 ) 刈谷事業所( 刈谷市 ) 設立 : 1991.2.14 売上高 : 40 億 800 万円 (2014 年 3 月期 ) 従業員数 : 235 名 (2014 年 4 月時点 ) 業務内容 : ITSソフト ( ナビゲーションシステム NaviCon 等 ) 車載制御ソフト ( メータ制御等 ) 車載プラットフォーム 開発環境支援ソフト (Simulinkベース開発環境等) 市販ソフト ( 工数管理 プロジェクト管理ツール :TimeTracker FX) 教育事業 ( 技術ドキュメンテーション教育 書籍販売 ) 団体参加 : DEOS, ASIF, TOPPERS 等 私の経歴 GSNに関するトレーニング教材の開発 開発方法論 規格の現場導入 ( プロダクトライン, AUTOSARなど ) その他 ナビゲーションシステム開発に従事
GSN 活用の目的 2 / 30 今後のシステム開発で重要になること 多種多様な製品がつながる世界において 設計品質の見える化が重要となる つながる世界 つながる世界の課題 全ての接続の検証が困難となる 企業の責任の所在が曖昧になる 設計品質の見える化の必要性 ソフトウェア相互の信頼性確認のため 企業の説明責任を果たすため ステークホルダとの情報共有のため 出典 : つながる世界のセーフティ & セキュリティ設計の見える化 (IPA) 設計品質を見える化する表現方法として GSN を活用する
GSN とは? 3 / 30 相手と合意形成できている前提に基づき上位の主張を下位の主張に分解 最下位の主張の妥当性を証拠に基づいて説明することで主張全体が特性基準を満足できていることを説明する 特性基準 成果物が特性基準を満足している 主張 前提 成果物の構成 成果物の構成に従って説明する 説明 成果物の構成要素が特性基準を満たしている 成果物の構成要素間の関係が特性基準を満たしている 証拠 構成要素が特性基準を満たす証拠 構成要素間の関係が特性基準を満たす証拠
GSN 活用の目的との関係 4 / 30 相手と合意形成できている前提に基づき上位の主張を下位の主張に分解 最下位の主張の妥当性を証拠に基づいて説明することで主張全体が特性基準を満足できていることを説明する 特性基準 成果物が特性基準を満足している 主張 確認記録 前提 成果物の構成 成果物の構成に従って説明する 説明 経験 考え方 成果物の構成要素が特性基準を満たしている 成果物の構成要素間の関係が特性基準を満たしている 証拠 構成要素が特性基準を満たす証拠 成果物 構成要素間の関係が特性基準を満たす証拠
参考 :GSN で使用できる基本的なノード 5 / 30 ノード名記号説明 Goal Strategy 主張 説明 相手に説明したい 対象が達成すべき状態 を示す S+V の形をした命題であるべき 例 ) システムは安全である 上位の主張を下位の主張に分解する仕方の説明を示す 例 ) 識別されたハザード毎に説明する Context Solution Undeveloped 前提 証拠 主張や説明が基づく相手と合意済みの情報を示す 例 ) リスク分析の結果得られたハザードのリスト ソフトウェアの構造 など 主張が達成できていることを示す証拠 ( 証跡 ) を示す 証拠は明確に定義されたドキュメントです 例 ) テスト報告書 運用記録 まだ具体化できていない主張や説明であることを示す ( 未定義要素 ) 出典 : アシュアランスケース入門, 名古屋大学
参考 : ノード間の接続ルール 6 / 30 リーフは 前提 証拠 未定義要素 のいずれかです 前提 主張 主張 主張 証拠 未定義要素 矢印は 2 種類あります 前提 は 主張 もしくは 説明 に付与されます 前提 主張 主張 説明 主張 前提 説明 説明 主張 証拠 InContextOf SupportedBy 出典 : アシュアランスケース入門, 名古屋大学
参考 : 前提のスコープ 7 / 30 前提 は紐付けられたノードとそれより下位のサブツリー全体にかかります 主張 前提 説明 主張 証拠 主張 未定義要素 赤い点線が 前提 のスコープです 出典 : アシュアランスケース入門, 名古屋大学
参考 : 前提のスコープ ( 事例 ) 8 / 30 議論の詳細さに応じた前提の紐付けが重要
参考 :GSN の位置づけ 作成時のポイント 適切な境界設定が相手の納得を得られる説明の礎になります 議論境界 GSN の前提 主張 説明の関係 GSN 相手に対する説明範囲 9 / 30 前提境界 前提 : 相手と合意済みであること 説明対象 : 成果物とその構成 証拠 : 構成要素とその関係が正しい理由
GSN 活用事例 10 / 30 安全分析プロセスにおける説明事例
今回採用した安全分析プロセス 11 / 30 本プロセスの前提 GSN で説明する を主眼とした発表の都合上 分析手順を一部で簡略化しています ( 故障モードの対策立案時における重要性分析など )
分析手法 :HAZOP の紹介 12 / 30 設計パラメータや操作にガイドワードを組み合わせることで意図した正常な振舞いから 逸脱した状態 を抽出する HAZOP の例 設計パラメータ ガイドワード 逸脱した状態 ライト光量 無し 逆転 ライトが点灯しない ライトの点灯が逆転する
分析手法 :FTA の紹介 13 / 30 望ましくない状態 をシステムの構造等の明文化された前提に基づいて分解することで その原因を明らかにする 発生確率も付与して分析できるが本発表では省略している 望ましくない状態 原因 A 原因 B 原因 A-1 原因 A-2 凡例 ) : 事象 : 基本事象 : AND ゲート : OR ゲート
安全分析プロセスの適用対象 (1/2) 14 / 30 提供機能 ID. 機能 1. ライトスイッチの点灯操作に応じてヘッドライトを点灯 2. ライトスイッチの消灯操作に応じてヘッドライトを消灯 システム構成
安全分析プロセスの適用対象 (2/2) 15 / 30 ECU ソフトウェア構成
手順 1: ハザード分析結果 16 / 30 ガイドワード採用方針 ヘッドライトの光量に着目して以下のガイドワードを採用 無し 異なる 過多 過少 ハザード分析結果 ID. ガイドワード ハザード 1. 無し ヘッドライトの完全な喪失 2. 異なる ヘッドライトの点灯 消灯が逆転 3. 過多 ヘッドライトの光量が多い 4. 過少 ヘッドライトの光量不足 次の手順では ID.1 のハザードを対象として故障モードを抽出していきます
手順 2: 故障モード分析結果 17 / 30 装置種別 装置 H/W 本体 + 入出力 起こり得る故障 次の手順では抽出した故障モードに対する対策を決定します
手順 3: 故障モードの対策定義結果 18 / 30 安全対策方針 ( 方針 1) 走行中における突然のヘッドライト喪失を回避するため ヘッドライト制御に関する故障検出時には点灯する側で制御する ( 方針 2) 通信に関する途絶 誤り検出時には受信側で方針 1 に基づいて制御する 安全対策定義 ID. 構成要素 故障モード 対策 1. ボデー IGスイッチ値のワイヤハーネス断線 H/W 回路で断線時のIGスイッチ値をオンとする 2. 制御 ECU ノイズ印加によるIGスイッチ値の逆転 IO-StackでIGスイッチ値のチャタリングを防止する 3. CAN 通信線断線 ヘッドライト制御 ECU 側で対応する 4. CAN 送信メッセージの値化け COM-Stackで誤り検出符号を付与する : : : 7. ヘッドライト CAN 通信線断線 COM-Stackで通信途絶時のIGスイッチ値をオンとする 8. 制御 ECU CAN 受信メッセージの値化け COM-Stackで誤り検出時のIGスイッチ値をオンとする : : : : : : :
手順 4:GSN を用いた説明 19 / 30 ハザード分析結果 故障モード分析結果 故障モードの対策定義結果 対策がシステムに組み込まれていることを確認した記録
GSN を用いた説明 : ハザード分析結果 20 / 30
GSN を用いた説明 : ハザード分析結果 21 / 30 前提ノード (C1) がハザードの網羅性に関する理解を助けてくれる
GSN を用いた説明 : 故障モード分析結果 22 / 30
GSN を用いた説明 : 故障モード分析結果 23 / 30
GSN を用いた説明 : 故障モードの対策定義結果 24 / 30 前提ノード (C7) で末端ゴール (G11) の合格条件を可視化するのがポイント
GSN を用いた説明 : 対策の組み込み状況の確認 25 / 30 前提ノード (C7) と証拠ノード (Sn1) の関係で組み込み状況が一目瞭然です
現場導入に向けた見通し 26 / 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. レビュー工数 初版 第二版 第三版に対して各 1 回実施 3.0h 3.0h 10. 手戻り工数 第二版 ( ハザード分析の構造から見直し ) 7.0h 11.0h 11. 第三版 ( 対策結果の確認構造のみ見直し ) 4.0h 12. 合計 42.5h
本事例に関するまとめ 27 / 30 ( 本事例で取り組んだ問題 ) 安全分析の結果を第三者が納得できるよう説明したい GSN を用いることで第三者の納得を助ける説明文書を提供できた 安全分析結果の全体俯瞰 判断に用いる根拠 基準 対策の組み込み状況の可視化 GSN の位置付け 分析 HAZOP FTA 外部 内部 GSN 確認 トレーサビリティ, テスト報告書等 凡例 : 仕事の流れ : 結果の総括
GSN を導入してみたいと思ってくれた方へ 28 / 30 弊社における導入の進め方 1 GSN の基本的な知識の教育 ( 記法や注意点等 ) 2 事例ベースで実際に GSN を用いて演習 3 使い勝手の良いツールを導入 (astah GSN) 4 活用できる場の提供 ( 設計成果のレビューに採用 ) 5 期待する GSN の構造の共有 ( レビュー時に指導 ) スムーズな導入のためのポイント GSN の良し悪しを判断できる人が 一人 居ると良いです 何をどう描いたら役に立つか自信が持てなくなるので はじめの 一人 の育成は DEOS 協会 D-Case 部会に協力を仰ぐと良いかと思います
D-Case に関するトレーニング 29 / 30 科目一覧 議論モデル境界 No. 科目名称概要 1. 導入 1D-Case の必要性 2D-Case の基本概念 3 活用事例の共有 2. 議論モデル境界 1 議論範囲の決定 2 議論範囲の妥当性評価 3. 議論モデル作成 1 主張の設定 2 主張を分解する説明の設定 3 主張 説明に対する 前提の設定 4 主張を支える証拠の設定 5 議論モデルの作成手順 4. 議論モデル妥当性確認 議論モデル作成 導入 議論モデル妥当性評価 議論モデル管理 議論モデル合意形成 1 用語の評価基準 2 主張の評価基準 3 説明の評価基準 4 前提の評価基準 5 証拠の評価基準 5. 議論モデル合意形成 1 合意形成の基礎 2 合意形成の手順 6. 議論モデル管理 1 議論モデルの変更要因 2 変更に対する影響範囲分析 3 変更に 対する追跡性の版管理 4 変更管理の手順 7. ツール支援 1 ツール要求 2 ツール評価 3 ツール導入手順 ツール支援 赤枠 : トレーニング提供可能範囲 弊社から D-Case トレーニング構造編を提供可能 (DEOS 認定取得済 )
D-Case 関連の参考情報 30 / 30 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