ｽﾗｲﾄﾞﾀｲﾄﾙなし

Size: px

Start display at page:

Download "ｽﾗｲﾄﾞﾀｲﾄﾙなし"

ゆみかおとべ
5 years ago
Views:

1 高信頼アーキテクチャ設計手法 ATAM の実践いざというときの安全性を担保してくれる信頼性の高いアーキテクチャを作るために関西事業部藤原 1

2 経験発表の内容はじめに本手法を適用している事業の説明改善に至った経緯手法の概要本手法の流れシステム設計書間のトレーサビリティシステム方式設計本方式設計の特徴機能方式設計基盤方式設計本開発手法の適用効果さらなる応用機能安全への拡張 2

3 < はじめに > 3

4 弊社の事業分野 : 本手法を適用している事業説明さまざまな事業分野の多岐に亘るソフトウェア開発及びシステム設計支援開発を請負にて行う会社ロケット航法誘導解析 (JAXA) 人工衛星搭載ソフトウェア (JAXA) 衛星管制システム衛星通信システム高速通信ネットワークシステム特殊用途通信システム社会インフラシステムネットワークセキュリティ ( 製品 ) カーエレクトロニクスカーマルチメディア ( ナビゲーション ) 電動パワーステアリング EV インバータ制御三菱リージョナルジェット DNA バンクシステムゲノム解析システム解析ソフトウェア新幹線地震防災システム自治体向け防災システム海底地震津波システム緊急地震速報システム (ASP 製品 ) 研究機関向け基幹システムデータ解析システム ( 官公庁 ) 企業向け基幹システム粒子線治療計画装置胸部 X 線診断支援システム ( 製品 ) 4

5 改善に至った経緯 2004 年 CMM 正式アセスメントにてレヘル 4 達成を確認 2013 年 Automotiv-SPICE v2.5 正式アセスメントにて ENG4~8 レヘル 4 達成を確認組織品質は ( 表面上 ) 良くなったスクラッチ開発が少なくなり派生開発が多くなってきたプロセス偏重プロダクト品質確保に必要な開発技術力維持育成がおきざりスクラッチ開発力 ( 例 : アーキテクチャ設計結合テスト ) を実践の場で磨く機会が少なくなってきたいざスクラッチ開発を行うと設計品質が極端に下がる外部も同じ傾向なので社外から優秀な人材を調達することも難しくなっている ( 1) 特に機能安全設計はアーキテクチャ開発力が必須であるスクラッチ開発を形式化手順化し自社の組織的開発力を底上げすることが最優先課題となってきた 1 SPI Japan2011 設計力強化全社活動 ( パナソニック ) 5

6 < 手法の概要 > 設計の詳細化が形式化されているので設計を進めることで自然とトレーサビリティが確保できる 6

7 本設計手法の流れ ( システム設計部 ) 本手法はシステム要求分析 ~ 方式設計までを下記の流れ (MBSE) で設計する 1 開発対象内で扱うドメイン用語の構造定義 2 システム要求の構造化 3 ユースケースと具体的要求仕様システム要求分析 + USDM ゴール指向要求図 / システムコンテキスト図 4 ドメイン分割 5 ユースケースの振る舞い定義 6 システムを論理的に機能分割する A ドメイン D ドメインシステム方式設計ロバストネス分析図 / シーケンス図ブロック定義図状態遷移図等 7 システム制約を検討し HW と SW に分割する論理アーキテクチャ物理アーキテクチャ等凡例設計分割境界に関して矢印元から強く影響を受ける 7

8 システム設計書間のトレーサビリティツール利用により要求仕様項目単位でトレーサビリティの欠陥確認ならびに設計の濃淡確認が自動可能製品企画製品企画書機能要求品質要求法規 xxx 規格システム要求分析要求図 ( 要件 ) システム要求仕様書要件検討書 ( 根拠資料 ) ドメイン辞書利用ユースケース振る舞い分析横断的関心事の要件非機能要件の詳細利用 USDM ( ユースケース ) USDM ( 横断的関心事 ) USDM ( 非機能 ) システム方式設計論理アーキテクチャシステム方式設計書 ( それとなく ) 規格の取込み物理アーキテクチャ凡例 A A A B B B A は B を含む B は A から導出する B は A を利用する SW 要求仕様へ 8

9 システム方式設計 9

10 アーキテクチャとは複数の視点 ( ビュー ) でシステムやソフトウェアの構造振る舞いを表現したものがアーキテクチャである運用アーキテクチャと視点論理機能 ( 静的構造 / 振る舞い ) ソフトウェアアーキテクチャデータ構造並行性実装メカニズムプログラム ( 実装構造 ) アプリケーションミドルウェア制御構造フレームワークプラットフォーム OS( システムコール ) ハードウェア( ドライバ ) 配置 ( 割り付け ) 10

11 システム方式設計で行うことシステム方式設計ではハードウェア / ソフトウェアの役割分割を主目的に下記事項を明確にするシステムの振る舞い ( ユースケース ) から大きな機能への変換 ( 論理アーキテクチャ ) 論理アーテキテクチャから物理アーキテクチャへの変換 (CPU 毎の機能アサイン ) 明確な実行プロセス ( タスク ) が定義できる場合その役割定義と機能割当論理アーキテクチャプラットフォームや実装に依存しない機能分割のアーキテクチャ m1 F1 F2 物理アーキテクチャ m2 m3 m4 F3 m5 非機能要件 ( 性能信頼性保守コスト ) を満たす論理アーキテクチャからの変更構造想定プラットフォームへの機能アサイン機能 CPU#1 F1 m1 m2 F2 m3 m4 CPU#2 F3 m5 CPU 間メッセージ通信形式 11

12 < 本方式設計の特徴 > 機能要求と非機能要求に対応した設計書に分けることでアーキテクチャ設計の出来高質を定量的に把握できる 12

13 機能方式設計と基盤方式設計を分けるソフトウェア方式設計書はそれが対応する要求 ( 機能非機能 ) に応じて大きく論理と物理アーキテクチャの 2 つに分ける要求方式設計説明機能要求機能方式設計論理アーキテクチャ SW 機能要件を満たす論理構造とそれに対応する振る舞いを設計すること非機能要求基盤方式設計 ( 実装技術 ) 物理アーキテクチャ SW 非機能要件 ( 性能品質等 ) を満たすように論理アーキテクチャに対して実装方式を設計することメリット 2 冊別々に作成することで基盤方式設計 ( アーキテクチャ ) の出来具合を物理量 ( ページ数 ) として把握することができる保守 ( 派生開発 ) の段階でアーキテクチャが存在しないという声を良く聞くがこれは機能と非機能の設計が混じり合った方式設計書を 1 冊にまとめて作る為に設計段階で物理アーキテクチャの出来高を定量的に把握し難くしていることも原因の一つである 13

14 方式設計の流れ : 論理と物理を分けて設計する機能要求と非機能要求は準独立関係にあり適用を分けて方式設計を行う (IEEE1220) 1 機能要求から論理アーキテクチャ ( 具体的な基盤に依存しない概念的な論理構造 ) を作成する 2 論理アーキテクチャを踏まえて物理アーキテクチャを設計するこの時アーキテクチャスタイルを活用するまた構造検討において複数の選択肢が生じた際には設計方針に照らしてトレードオフする 3 一貫性の必要な局所構造をテキスチャ ( ) として定義する 4 方式設計以降の設計において従うべき原則を非機能要求に反映して残す機能ビュー機能要求アーキテクチャスタイル設計方針設計トレードオフ時の価値基準を与える 1 詳細化と統合 2 構造化の原則として参考活用プログラム ( 実装構造 ) 非機能要求 ( 品質特性 ) 論理アーキテクチャ 5 実装アプリケーション原則 4 非機能ビュー 2 分離と集約決めた原則を非機能要求に反映 3 物理アーキテクチャ実行構造開発構造配置構造一貫性の必要な局所構造を定義するテキスチャ 5 実装ミドルウェア制御構造フレームワークプラットフォーム OS( システムコール ) ハードウェア( ドライバ ) テキスチャとはエラー処理方法やユーザとのインタラクションの方法などソフトウェアの様々な部分に表れ一貫性のある方針で作られる小構造である 14

15 < 機能方式設計 > 機能の塊であるサブシステムを定義するただしシステム方式設計はハードウェア / ソフトウェア境界を分けることが最小限の作業なのでソフトウェア構造のサブシステム構造分割が過度にならないよう注意すること 15

16 機能方式設計の位置づけ機能方式設計を赤枠 ( 黄色 ) に示す 1 開発対象内で扱うドメイン用語の構造定義 2 システム要求の構造化 3 ユースケースと具体的要求仕様システム要求分析 + USDM ゴール指向要求図 / システムコンテキスト図 4 ドメイン分割 5 ユースケースの振る舞い定義 6 システムを論理的に機能分割する A ドメイン D ドメインシステム方式設計ロバストネス分析図 / シーケンス図ブロック定義図状態遷移図等 7 システム制約を検討し HW と SW に分割する論理アーキテクチャ物理アーキテクチャ等凡例設計分割境界に関して矢印元から強く影響を受ける 16

17 要求仕様分析から論理サブシステム抽出までの流れ要求仕様 ( 要求図他 ) からロバストネス分析図を作成することでシームレスに論理サブシステムを抽出することができる各サブシステム抽出は 1 凝集度が高く 2 結合度が疎になるようにする 17

18 DSM により論理サブシステムを決定する DSM(Dependency Structure Matrix) を使ってサブシステムを決定する独立したモジュール群 (= 外部との相互作用が少なく内部間の結合度が高いモジュール群 ) を選ぶという経験的システムアーキテクチャ評価原則を使ってサブシステムを決定する具体的可視化手法として DSM を用いるコンポーネント A コンポーネント B コンポーネント C コンポーネント D コンポーネント E コンポーネント F A B C D E F 左図はあるシステムが A,B,C,D,E,F の 5 つのコンポーネントで構成されていることを示しているコンポーネント A の依存関係は行 / 列 1 に表示されコンポーネント B,D に依存していることを表しているセルの中の数字はコンポーネント間に設定したルールによる重みである DSM によるサブシステム決定 / 評価例 A サブシステム B サブシステム結合度の高いコンポーネントが C サブシステムの中に多く存在する A サブシステム B サブシステムアーキテクチャの見直しにより結合度の高い C サブシステム割合を減らす C サブシステム C サブシステム D サブシステム D サブシステム 18

19 < 基盤方式設計 > ATAM ( ) で物理設計を行いアーキテクチャ設計のレビュー効率設計品質を上げる ( )Architecture Trade-off Analysis Method 19

20 基盤方式設計の位置づけ基盤方式設計を赤枠 ( 黄色 ) に示す 1 開発対象内で扱うドメイン用語の構造定義 2 システム要求の構造化 3 ユースケースと具体的要求仕様システム要求分析 + USDM ゴール指向要求図 / システムコンテキスト図 4 ドメイン分割 5 ユースケースの振る舞い定義 6 システムを論理的に機能分割する A ドメイン D ドメインシステム方式設計ロバストネス分析図 / シーケンス図ブロック定義図状態遷移図等 7 システム制約を検討し HW と SW に分割する論理アーキテクチャ物理アーキテクチャ等凡例設計分割境界に関して矢印元から強く影響を受ける 20

21 基盤方式設計とはこれがアーキテクチャである基盤方式設計書要件特に強い影響を受ける非機能要件機能要件品質属性 + 客観的な尺度アーキテクチャ設計に要求される特性分類モジュールビュー ( 構造的特性 ) ソフトウェアの構造コンポーネントコネクタービュー ( 動的特性 ) ソフトウェアが動作する時の仕組み割り当て ( 配置 ) どの部分が誰によって作られどのコンピュータに配置されるか基盤方式設計の記述内容システム構成 (HW,SW 構成 ) レイヤ構造レイヤ間インタフェース利用フレームワーク論理パッケージ構成イベント処理並行性とリソースアーキテクチャインスタンス管理リアルタイム制御メモリ管理状態遷移 / 決定表の実装多国語対応セキュリティ管理障害管理 ( 可用性 ) ログ管理共通ライブラリ設計上の留意点要求 ( 品質特性 ) セ変試使キ可更験い性ュ用容可や能リ性易能すテ性性さィ可用性変更容易性性能使いやすさテスト容易性セキュリティ 21

22 品質特性間のトレードオフ関係非機能要件を満足するように論理アーキテクチャから物理アーキテクチャへの変換したい! しかし全ての品質特性をベストな状態にする万能の設計はなく下図のような経験的な品質特性間の関係 ( ) をトレードオフするしかないこれは一方の要求満足度を高めると他方が損なわれることを示しているただし逆が同じ傾向になるとは限らない例 ) ソフトウェア構造の柔軟性を高めようとすると性能は多少犠牲にせざるを得ない可用性 (Availability) 性能効率性 (Efficency) 柔軟性 (Flexibility) インテグリティ (Integrity) 相互運用性 (Interoperablity) 保守性 (Maintainability) 移植性 (Portability) 信頼性 (Reliability) 再利用性 (Reusability) 堅牢性 (Robustness) 使用性 (Usability) - + ( 判例 ) + : 対応する行の特性を上げると列の特性にプラスの影響を与える - : 対応する行の特性を上げると列の特性にマイナスの影響を与える空白 : ほとんど影響を与えない ( )IPA SEC 編 : 要求工学設計開発技術研究部会非機能要求とアーキテクチャ WG2006 年度報告書 22

23 論理アーキテクチャから物理アーキテクチャへの変換 23

24 論理サブシステムから物理サブシステムへのマッピング論理サブシステムから物理サブシステムへのマッピングは通常 1 対 1 であるが別のサブシステム枠になることもある品質属性を考慮しながら論理コンポーネントを物理コンポーネントにマッピングすることでその枠組みが決まる 24

ATAM 設計シートと設計過程のアーキテクチャ図 class D1 クラス図外部サブシステムの型違いは Application 層に影響しない同じ機能を実現する場合外部サブシステムが異なっても Application 層の実装は共通となる複数機種で同じ仕様変更を対応する際に機種毎の設計検討は不要となる引き渡し情報は通信メッセージのみなので Interface

検討した最終アーキテクチャ ) 詳細分解課題検討結果詳細 ( トレードオフ & リスク ) ( トレードオフ & リスク ) ( トレードオフ & リスク ) + EventHandler NObject + DeviceLib NObject Converter::SPL_RecieveConverter + Franca Converter::SPL_SendConverter +

25 ATAM 設計シートと設計過程のアーキテクチャ図 class D1 クラス図外部サブシステムの型違いは Application 層に影響しない同じ機能を実現する場合外部サブシステムが異なっても Application 層の実装は共通となる複数機種で同じ仕様変更を対応する際に機種毎の設計検討は不要となる引き渡し情報は通信メッセージのみなので Interface に通信以外の責務を持たない制限につながる外部サブシステム (from クラス図 ) Interface 外部サブシステムに依存する対象 Victoria メッセージ型で呼び出し先のSend 関数を自動解決するので誤りがない誤ったメッセージを指定した場合はコンパイル時にエラーを検出できる解決すべき課題検討すべき非機能要件内容 ( 内容 ) 前提事項 ( 内容 ) 決定事項 ( 検討した最終アーキテクチャ ) 詳細分解課題検討結果詳細 ( トレードオフ & リスク ) ( トレードオフ & リスク ) ( トレードオフ & リスク ) + EventHandler NObject + DeviceLib NObject Converter::SPL_RecieveConverter + Franca Converter::SPL_SendConverter + FunctionDB <<HMI(Chart)>> <<Interface>> + IPI + Send(SPL_VoiceRequest&, SPL_VoiceResponse&*): BOOL Send 関数を送信メッセージ + NotifyAnyScreenDisp(UICARPLAY_SCREEN_PRIORITY): void + Resona オーバーロード (from Interface) 生成参照 ExternalInterface:: Template 引数での送信 SPL_RecieveExternalInterface NObject NObject Interface Application メッセージ引き渡し DTO::SPL_DTO + Recieve(MESSAGE&): BOOL ExternalInterface::SPL_SendExternalInterface 間の転送オブジェクト + Recieve(MESSAGE&, MESSAGE&*): BOOL - m_id_: SPL_DTO_ID + GetInstance: SPL_SendExternalInterface* + GetInstance: SPL_RecieveExternalInterface* を機種共通化 + Send(MESSAGE&): BOOL 要求 - 応答型の非同期通信 <<property get>> + Send(MESSAGE&, MESSAGE&): BOOL + GetId: SPL_DTO_ID {query} を同期応答で提供 Application Interface の窓口一本化 <<use>> Application 生成 Interface Application の Application 側では外部サブシステムの窓口一本化非同期応答の待ち合わせが不要とな NObject り手続きが簡略化できる待ち合わ ControlService::CPY_ControlService 各サブシステム Template 引数での受信せ状態の管理が不要となる + ExecuteSync(MESSAGE&, MESSAGE&): BOOL + ExecuteAsync(MESSAGE&): BOOL メッセージ引き渡し CPY_TService CPY_TService - Dispatcher(SPL_DTO&): void ScreenController:: - ExecuteSyncImpl(SPL_CarPlayStatusRequest&, SPL_CarPlayStatusResponse&*): BOOL AudioController:: CPY_AudioService CPY_ScreenService <<property get>> + GetInstance: CPY_ControlService* Interfaceの下記機能拡張がApplicationに影響を及ぼさない通信相手の外部サブシステム追加 tionの下記機能拡張がinterface 通信メッセージの種類追加を及ぼさないシステムの追加 / 削除 / 統合システムの提供機能追加非同期応答 :Dispatcher 関数は抽象型 Applicationの対応するメッセージ具象型を隠ぺいできで受け取り各サブシステムに振り分けるので Interfaceのみ先行してメッセージ具象型を追加しても Applicationに影響を及ぼさない同期応答 :ExecuteSyncImpl 関数を同期メッセージ型で呼び出し先のExecuteSyncImpl 関数を自応答メッセージの種類分オーバーロード動解決するので誤りがない誤ったメッセージを指定した場合はコンパイル時にエラーを検出できる class D1-2 詳細 Interface と MiddleWare のレイヤ間インタフ... 外部サブシステム (from クラス図 ) Interface 外部サブシステムに依存する対象 Victoria + EventHandler + DeviceLib + Franca + FunctionDB + IPI + Resona (from Interface) Interface MiddleWare にアクセス MiddleWare 直接 VideoPlayerHandler MiddleWare::DiPOAdapter <<use>> <<subsystem>> VideoPlayerHandler (from MiddleWare レイヤ ) 箇所を MiddleWare のみとする 25

26 アーキテクチャスタイル蓄積が技術の見える化であるアーキテクチャスタイルは複数のアーキテクチャに繰り返し現れる構造のことであるスタイル例 : 複数センサを監視し状況変化に応じてアクチュエータを制御するスタイルセンサ制御 1 アプリケーション ( 制御目的オブジェクト ) センサ制御 2 センサ制御 n 監視制御アクチュエータ制御 1 アクチュエータ制御 2 HW 制御 ( 物理オブジェクト ) アクチュエータ制御 m ドメイン名称意味処理内容アプリケーション HW 制御制御目的オブジェクト物理オブジェクト全体制御 ( 制御したいこと ) 制御の競合調整状態遷移センサ情報間の加工処理センサ情報の相関関係による整合性検証制御対象機器を表現センサ制御 ( 入力 ) アクチュエータ制御 ( 出力 ) 26

27 本開発手法による効果 27

28 手法適用の効果本手法適用プロジェクト例 : 業務系通信システム種別規模開発形態プロジェクト説明 2M 新規工期 1 年プロセス初適用 ( 適用そのものが要件 ) 40KL 新規協力会社に適用 200KL 新規開発手法の本格適用 600KL (1M) 流用短工期システム要求仕様曖昧システム換装車載制御機器 30KL~50KL 新規 / 派生短工期アジャイル効果 : 小規模 ~ 大規模まで統一的に行える手法が確立できプロジェクトの成功確率が高まった (2007 年以降弊社基準のプロジェクト崩れはゼロ ) 設計書の出来不出来判定がし易くなり設計スキル評価がし易くなった要求仕様と方式設計の記述重複を解消できた ( 1) 辞書 ( 用語検索 ) ツールやサブシステム定義ツール等手法の支援ツールの整備が加速された ( 現在進行形 : 手順を固めることで自動化がより見えてきた ) ( 1)SPI Japan2016( デンソー ) プロセス分析に基づくドキュメント再構成によるプロセスの改善 28

29 さらなる応用機能安全への拡張 29

機能安全とは機能安全とは機能により電気電子システムの安全性を確保するという考え方故障が発生しても安全状態に移行させる機能 ( 安全メカニズム ) を実装しているプロセス (A-SPICE レベル 3 以上 ) とプロダクト ( 安全アーキテクチャ ) を重視する < 背景にある考え > 部品単位での安全対策にいくらコストをかけても故障を完全に無くすのは極めて困難

30 機能安全とは機能安全とは機能により電気電子システムの安全性を確保するという考え方故障が発生しても安全状態に移行させる機能 ( 安全メカニズム ) を実装しているプロセス (A-SPICE レベル 3 以上 ) とプロダクト ( 安全アーキテクチャ ) を重視する < 背景にある考え > 部品単位での安全対策にいくらコストをかけても故障を完全に無くすのは極めて困難安全メカニズムをシステムとして確実に実装することでユーザレベルの安全性を担保する機能安全に必要な活動故障しても危険状態に移行しないことを論理的に説明できることプロセスマネージメントだけではない! < 具体的には > 科学的手法 / 根拠による分析明瞭な安全系アーキテクチャ設計で安全性を実現するそれらを厳格なプロセス定義で確実に実施しエビデンスやトレーサビリティで確認する 30

31 サブシステム分割の基準 ( 論理設計 ) コンポーネントの決め方は既に説明したとおり ( 下図 ) 機能安全規格はシステム方式設計の科学的根拠を示せと言っているソフトウェアコンポーネント 31

32 サブシステム分割の基準 ( 論理設計 ) コンポーネントの決め方は既に説明したとおり ( 下図 ) 機能安全規格はシステム方式設計の科学的根拠を示せと言っている要求 ( ユースケース USDM) コントロール ( ロバストネス分析 ) 論理統合 ( 凝集度結合度 ) 物理論理サブシステム分離集約 ( 非機能制約 ) ソフトウェアコンポーネント物理サブシステム 32

33 アーキテクチャ設計 ( 安全設計 ) 安全要求を最優先にすれば良い 33

34 Mitsubishi Space Software 私たちには宇宙品質を支え続けてきたスピリッツテクノロジーストーリーがあります豊富な経験値集合知形式知を活かしお客様の課題を一緒に考えながら解決しますご用命頂きましたら全手法の詳細をご説明させて頂きますご清聴ありがとうございました 34

15288解説_D.pptx

15288解説_D.pptx ISO/IEC 15288:2015 テクニカルプロセス解説 2015/8/26 システムビューロシステムライフサイクル 2 テクニカルプロセス a) Business or mission analysis process b) Stakeholder needs and requirements definieon process c) System requirements definieon

ｽﾗｲﾄﾞ ﾀｲﾄﾙなし

ｽﾗｲﾄﾞﾀｲﾄﾙなし