システムズエンジニアリング・ mbse概要 - ipa...2015/09/04 ·...
TRANSCRIPT
Copyright©2015 Hidekazu Nishimura.
システムズエンジニアリング・MBSE概要
慶應義塾大学大学院システムデザイン・マネジメント研究科
教授 西村 秀和 http: lab.sdm.keio.ac.jp/nismlab/
1
SEC高信頼化技術セミナーモデルベースシステムズエンジニアリング入門~システムを考えるハンズオンワークショップ~
2015年9月4日(金)
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
略歴と業績略歴1985年3月 慶應義塾大学理工学部機械工学科卒業
1987年3月 同大学院理工学研究科機械工学専攻修士課程修了1990年3月 同大学院理工学研究科機械工学専攻博士後期課程修了 工学博士1990年4月より千葉大学工学部機械工学科助手 1995年より同助教授
2007年2月~3月 バージニア大学訪問准教授2007年4月 慶應義塾大学先導研究センター教授 「SDM研究科設立準備」2008年4月 慶應義塾大学大学院システムデザイン・マネジメント研究科教授
2011年4月~2012年3月 日本機械学会 機械力学・制御部門 部門長2012年2月~2014年1月 計測自動制御学会 総務担当理事(2013年度副会長兼務)2013年1月~ 日本機械学会フェロー
著書1998年『MATLABによる制御理論の基礎』 (共著) ,『MATLABによる制御系設計』(共著)
2007年『運動と振動の制御の最前線』 (共著)2012年『システムズモデリング言語 SysML』 (監訳 A Practical Guide to SysML)2014年『デザイン・ストラクチャー・マトリクス DSM』 (監訳 MIT Press書籍)
2015年『モデルに基づくシステムズエンジニアリング』(総監修)
2
西村秀和
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
システムズエンジニアリング2025のあるべき姿
システムズエンジニアリングの基盤は,アカデミアを横断して一貫性のある形で定義され,教授される.
システムの複雑度と関連するリスクが正しく評価され,特徴付けられ,そして管理される.
システムズエンジニアリングは,信頼でき回復力のあるシステムを設計し,そして予測するための分析的なフレームワークを与える.
モデルベースシステムズエンジニアリングは標準となり,企業体におけるデジタル機能とともにモデリングとシミュレーションが統合される.
システムズエンジニアリングは,競争力をもって新たなものを生み出し,大きな価値を与えるように,産業,政府,アカデミアを横断して認められる.
システムズエンジニアリングは,技術の評価,政策の分析を行うために必須の学問として確立される.
システム思考は教育のすべてのレベルで教授される.
INCOSE Systems Engineering Vision 2025 (June 2014)
http://www.incose.org/docs/default-source/aboutse/se-vision-2025.pdf?sfvrsn=4
INCOSE: International Council on Systems Engineering
3
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
?
システムとは何か?
システム:
相互に関連し全体として機能するコンポーネントの集まり
ハードウェア,ソフトウェア,人,設備など複数のドメインで構成
4
System of interest
境界:boundary
アクターactor:行為者(人とは限らない)
Use Case1Use Case 2
環境
System of interest
対象システム
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
System of Systems
様々なシステムが複雑に関連する中で、対象とするシステムを設計することは極めて難しい。
システムSystem of interest
システム1
システム2
システム3
システム4
5
Economics
(経済)
Policy(政策)
Technology(技術)
Environment(環境) ライフサイクルが互いに異なる
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
システム:製品とそれを実現するプロセス
6
System
製品
サブシステム
サブシステム
開発・テストプロセス
製造プロセス
販売・サポートプロセス
運用・トレーニングプロセス
廃棄プロセス
製品
-設備-機器-工程-ソフトウェアアプリ
-計算機資源-人員-サプライヤ-ベンダー
-設備-機器/ツール-工程-ソフトウェアアプリ
-計算機資源-部品在庫-人員-サプライヤ-ベンダー-品質管理
-設備-機器/ツール-工程-ソフトウェアアプリ
-計算機資源-スペア部品在庫
-メンテナンスサプライヤ
-ベンダー
-設備-機器/ツール-工程-ソフトウェアアプリ
-計算機資源-オペレータ- トレーナー
-設備-機器/ツール-工程-人員
製品階層 ライフサイクルプロセス
IEEE 1220より
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
システムズエンジニアリングとは何か?
システムズエンジニアリングの定義
システムを成功裏に実現するための複数の分野にまたがるアプローチおよび手段
システムズエンジニアリングでは、開発のライフサイクルの初期段階で顧客のニーズを明確化し、機能要求を定義し、関連する問題をすべて考慮しながら設計のための総合とシステムの妥当性確認を進める。
システムズエンジニアリングは、ユーザーニーズに合致した品質の製品を供給することを目的とし、ビジネスとすべての顧客の技術的要求を考慮する。
INCOSE: International Council on Systems Engineering
7
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
システムズエンジニアリングは「アプローチ」
8
システムを成功裏に実現するための複数の分野にまたがるアプローチおよび手段
コミュニケーションの重要性
ISO 15288:2015 システムライフサイクルステージ
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
システムズエンジニアリング標準の歴史
MIL-STD-499
MIL-STD-499A
EIA/IS632
IEEE1220
IEEE1220
IEEE1220
ANSI/EIA632
ISO15288
ANSI/EIA632
EIA/IS731
Others..
1969 1974
1994
1994
1998
1998
2000+
Trial Use Standard
IEEE Standard for Application and
Management of the Systems
Engineering Process
Software & Systems
Engineering Std. Cmt.
IEEE Computer Society
Military Standard
電子工業会Electronic Industries Alliance
Interim standard
米国国家規格協会American National Standards Institute
9
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
ISO 15288:2015 システムライフサイクルプロセス 合意プロセス
・取得プロセス
・供給プロセス
組織的プロジェクト実現プロセス
・ライフサイクルモデルマネジメントプロセス
・基盤マネジメントプロセス
・ポートフォリオマネジメントプロセス
・人的リソースマネジメントプロセス
・品質マネジメントプロセス
・知識マネジメントプロセス
技術マネジメントプロセス
・プロジェクト計画プロセス
・プロジェクト評価・統制
プロセス
・意思決定マネジメント
プロセス
・リスクマネジメントプロセス
・構成管理プロセス
・情報マネジメントプロセス
・測定プロセス
・品質保証プロセス
技術プロセス
・ビジネス解析,ミッション解析プロセス
・利害関係者要求定義プロセス
・システム要求分析プロセス
・アーキテクチャ定義プロセス
・設計定義プロセス
・システム解析プロセス
・実装プロセス
・統合プロセス
・検証プロセス
・移行プロセス
・妥当性確認プロセス
・運用プロセス
・保守プロセス
・廃棄プロセス
10
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
モデル vs シミュレーション (SEH 4th Ed.)
“モデル”と“シミュレーション”には、それぞれに意味があるにもかかわらず、間違って受け取られることがある。
モデル=対象とするシステム、エンティティ、現象、プロセスの抽象または表現(観点:形状、機能、性能)
シミュレーション=時間に沿ってモデルを実行する特定の環境へのモデルの実装。一般には、システム、ソフトウェア、ハードウェア、人、物理現象の複雑な動的振る舞いを解析する手段を提供する。
11
SEH: Systems Engineering Handbook
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
コミュニケーションの失敗
このシステムは、●●と××から構成され、△△の運用を考えたときに、、、
?
12
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
図を用いたコミュニケーション
このシステムは、●●と××から構成され、△△の運用を考えたときに、、、
13
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
モデリングの目的(1) (SEH 4th Ed.)
実在するシステムの特徴づけ:文書で書かれた実在システムのモデリングでそのアーキテクチャと設計を把握する。
ミッションおよびシステムコンセプトの定式化と評価:システムライフサイクル初期の段階で、モデルによりミッションおよびシステムコンセプト候補を総合(synthesis)し評価(evaluate)す
る。システム設計のモデリングと重要なシステムパラメータの影響評価からトレードオフ解析の解空間を探索する。
システムアーキテクチャとシステム要求のフローダウン:モデルを用いてシステム解のアーキテクティングを支援し、ミッションとシステム要求(機能要求、インタフェース要求、性能要求、物理要求の他、信頼性、保守性、安全性、セキュリティなどのいわゆる非機能要求)をシステム要素に割り当てる。
14
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
モデリングの目的(2) (SEH 4th Ed.)
システム統合と検証の支援:システムへのハードウェア、ソフトウェアの統合の支援とシステムが要求を充足することの検証の支援にモデルを用いる。Hardware-in-the-loop テスト、Software-in-the-loop テスト。モデルは、テスト計画と実行を支
援するためテストケースやテストプログラムの他の観点を定義する。
トレーニングの支援:システムと相互作用するユーザー(オペレータ、保守員、その他)を訓練するシステムの様々な観点を模擬する。
知識の獲得とシステム設計の進展:システムに関する知識の獲得と組織の知識としての維持のための効果的な手段をモデルは提供する。
15
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
システムライフサイクルプロセス中のシミュレーションモデルとシステムモデル
ビジネス解析とミッション解析:解決すべき状況を表す記述モデル(Descriptive model)は、正しい問題に対処していることを保証する。
利害関係者要求定義とシステム要求定義:要求を正当なものとし、適切な要求の特定を行う。
アーキテクチャ定義:選択基準をもとに候補となっている選択肢を評価し、他のシステムとの統合など、ベストのアーキテクチャを見いだす。
設計定義:必要な設計データを取得し、最適化のためのパラメータを調整し、システム要素に対する実際のデータが得られるよう忠実にモデルを更新する。
検証と妥当性検証:システム環境をシミュレートして検証および妥当性確認データを評価し、(シミュレーションは、直接観察できない重要なパラメータの計算のための入力として観測可能なデータを用いる)、シミュレーションの忠実度の妥当性を確認する。
運用:実際の動作を反映し、計画、検証、オペレータの訓練のための実行の前に動作を模擬する。
16
SEH 4th Ed.
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
システムズエンジニアリング「要求」と「アーキテクチャ」
要求の2つの鉄則
機能要求:“どのように要求を実現するか?”の前に
“それは何か?”,“なぜそれが必要か?”を明確にする。
要求は“測定可能”で“テスト可能”でなければならない。
アーキテクチャの3つのビュー
Operational view:システムの使い方、動かし方
Functional view:システムへ要求される機能
Physical view:機能を実現するハードウェア、ソフトウエア
17
高
抽象度
低
Architecting: the art and science of designing and building systems.
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
エンティティV:ビューの位置づけ
利害関係者の要求
製作,コード化に向けた仕様
Entity要求の定義
概念設計,アーキテクチャの選定,設計に向けた仕様
購入,製作,コード化
検証検査,テスト,実証,分析
妥当性確認
妥当性確認の計画
要求の
抽出概念設計
アーキテクチャ
詳細設計 試験,検証製造,
運用
Customer Confirmation
Verification and
Validation Planning
Verification
Planning
検証検査,テスト,実証,分析
Custo
me
r
Confirm
atio
n
Custo
me
r
Confirm
atio
n
見込み調査,
リスク調査
不具合調査
解決策の達成
② Functional view
③ Physical view
MATLAB/Simulink
Mechanical CADElectronic CADProgram code
SysML
① Operational view
18
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
二元V字開発モデル (Dual Vee Model)
Architecture Vee
Entity Vee
利害関係者の要求
要求を満足するシステムの完成
19
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
二元V字モデルによるプロセスの理解
Architecture Vee
Entity Vee
利害関係者の要求
要求を満足するシステムの完成
アーキテクチャの検討,決定では,サブシステムやコンポーネントの実現可能性を検討しながら進めることがある.
20
早い段階での手戻り
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
二元V字モデルによるプロセスの理解
Architecture Vee
Entity Vee利害関係者の要求
要求を満足するシステムの完成
コンポーネント,サブシステムの検証,妥当性確認を順序行い,システムとしての検証,妥当性確認を行って行く.
21
致命的な手戻り
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
利害関係者の要求
製作,コード化に向けた仕様
Entity要求の定義
アーキテクチャの選定とシステム仕様
購入,製作,コード化
検証検査,テスト,実証,分析
妥当性確認
妥当性確認の計画
要求の
抽出概念設計
アーキテクチャ
詳細設計 試験,検証製造,
運用
Customer Confirmation
Verification andValidation Planning
VerificationPlanning
検証検査,テスト,実証,分析
Cust
om
er
Confirm
ation
Cust
om
er
Confirm
ation
エンティティV : 検証と妥当性確認
ノミナル
オフノミナル
HILS/SILS
Human in the LoopSimulation
シナリオ
22
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
IEEE 1220 systems engineering process
要求と制約の矛盾
要求のトレードオフと影響
分解割り当てのトレードオフと影響
分解と要求の割り当に関する候補
設計解のトレードオフと影響
設計解の要求と候補
要求の基準
確認された要求の基準
機能アーキテクチャ
検証済み機能アーキテクチャ
物理アーキテクチャ
検証済み物理アーキテクチャ
SEプロセスへの入力
SEプロセスの出力
統制
設計の検証
機能の検証
要求の分析
要求の妥当性確認
要求のトレードオフ分析と評価
設計のトレードオフ分析と評価
総合
システム解析
機能の分析機能の
トレードオフ分析と評価
23
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
INCOSE IW2014
Digital systems engineeringの必要性 例:Industry 4.0 (ドイツ)
システムズエンジニアリングが,プロジェクトマネジメントや政策決定者,意思決定者に対して,意思決定のための分析の支援を行う.
Model-based architectures 正しいシステムモデルを得る! (Boeing)
Requirement Architecture 正しい要求
Functional Architecture 正しい機能,インタフェース
Logical Architecture 正しいコンポーネント
モデリングのスキル (Boeing)
問題に応じた詳細度で何をモデル化するべきかを知る.
解析するべきデータは何か,それをどのようにモデルで解析するかを知る.
価値の最大化,Value-driven Systems Engineering (Georgia Institute of Tech.)
SoSでアーキテクチャを考える.モデルベースで考える.
24
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
INCOSE IW2015
MBSEに関する調査 MBSEの浸透は進んでいるのか? 障害となるものは何か?
システムライフサイクルマネジメントについて MBSEとPLMの統合
FMI(Functional Mockup Interface)について INCOSE/NAMEFS SMSWGの活動 Systems Modeling & Simulation Working Group (SMSWG) http://www.omgwiki.org/MBSE/doku.php?id=mbse:smswg NAFEMS:The International Association of the Engineering
Modelling, Analysis and Simulation Community
http://www.nafems.org/
25
http://www.omgwiki.org/MBSE/doku.php?id=mbse:incose_mbse_iw_2015
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
複雑化する自動車T
/M
エンジン
AB
S
CA
N
クラスタ
速度表示
ACC
自動変速
機能がサブシステム間に分布されている。
サブシステム
要求50ECU×1000reqts
要求50ECU×1000reqts
要求50ECU×1000reqts
要求50ECU×1000reqts
要求50ECU×1000reqts
・アーキテクチャ・振る舞いモデル・プラントモデル・制御系設計・ソフトウェア・ハードウェア・適合・テスト・・・
車両/ECU
BOM
・状態遷移・アクション・パラメトリック・チャート・・・
・テスト環境・データ辞書・機械設置・チャート・・・
Christopher Davey, Senior Technical Leader,
Ford Motor Company
26
Traction
control
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
システム
モデル
プロジェクトマネジメント
要求
シミュレーション/CAE
ライブラリ/
データベース
生産/サプライチェーン
最適化
CAD
SLIM (System Lifecycle Management)
PLM (Product Lifecycle Management), SCM (Supply Chain Management)
SLIMby intercax
システムアーキテクチャと同義
27
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
INDUSTRIE 4.0に向けて...システムズエンジニアリングとCyber Physical Systemの意味
ライフサイクル全般にわたるモデリング
それぞれのステージに応じて適切なデジタルモデルを持つ。
デジタルモデルは実システムと整合し、正しい情報を持つ必要がある。
INDUSTRIE 4.0では、サプライチェーン、生産の効率化にデジタルモデルを活用することの重要性を強調。2030年の実現を目指す。
要求抽出
概念設計
アーキテクチャ
詳細設計
試験
検証製造
運用
保守廃棄
ドライバー
コントローラ (DYC)
車両
車両横変位
車両ハンドル角車速ヨーレート横滑り角
駆動・制動トルク信号
開発
28
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
モデルに基づくシステムズエンジニアリング
MBSE:Model-Based Systems Engineering
モデルベースシステムズエンジニアリング基本的なプロセスは同じ
(文書に基づく)システムズエンジニアリング INCOSE (International Council on Systems Engineering) MBSE WG
IEEE 1220, ISO 15288:2015のとおり、システムズエンジニアリングには、システム解析が必要である。そこでは、シミュレーションモデルによる解析が行われる。制御ソフトウェア開発ではシミュレーションモデルに基づく、いわゆるモデルベース開発(MBD: Model-Based Development)が用いられるが、システムズエンジニアリングの中では一部に過ぎない。
29
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
“モデルベースでシステムを考える”とは?
モデル*に基づくシステムズエンジニアリング
仕様書など文書だけではすぐに理解できないことが、図的に表現することで理解が容易になる。
協働してシステム開発をするには、共通言語が必要であり、それをサポートするには図的な言語が有効である。
モデルを再利用することにより開発の効率化が期待できる。
モデルを用いて抽象度を上げることにより革新に導く。
30
*注:実行可能ではないモデルを含む
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
システムモデルの記述
システムモデル表記法:SysML(Systems Modeling Language)
システムを構造,振る舞い,要求,パラメトリック制約の観点で図的に表現することができる。
図的表現により、開発者の思考を支援できる。
複数のドメインにまたがる開発、分業化された開発環境で、共通言語として利用できる。
システム開発プロセスの中で要求のトレーサビリティが確保される。
構成管理、変更管理が容易になる。ーあるサブシステムやコンポーネントの要求の変更や設計の変更が生じた際に、他のサブシステムやコンポーネントにどのような影響が及ぶかを判断できる。
31
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
SysMLで何ができるのか?
システムを構成するサブシステムに対する機能要求とその振る舞いを把握できる。
設計変更があった場合にも、要求のトレースが可能なため、その影響を容易に把握できる。
SysMLを用いることで、開発者の思考を支援し、ドメインをまたがる協働作業が可能となる。
コンカレントデザインを促進するフレームワークが実現可能となる。ただし、組織の硬直化などが弊害となり得る。
参考資料:システムズモデリング言語 SysML (A Practical Guide to SysML翻訳本)
西村 秀和(監訳)
訳者:白坂成功,成川輝真,長谷川堯一,中島裕生,翁志強
著者:Sanford Friedenthal, Alan Moore, Rick Steiner
出版社:東京電機大学出版局(2012年5月10日)
32
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
構造
要求
振る舞い
パラメトリック制約・数式表現・運動方程式・パラメータによる性能評価など
SysMLのダイアグラムは,互いに関連している。→ 設計変更があった場合にもその影響を容易に把握できる。
ibd act
reqpar
33
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
ソフトウェアモデル ハードウェアモデル
要求・仕様
設計・統合
要求・仕様
設計・統合
SysMLを用いた協働作業
構造
要求
振る舞い
パラメトリック
34
システムモデル
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
ダイナミクス解析
制御システム解析
1D-CAEなど
ハードウェア設計モデル
電気回路設計モデル
ソフトウェア設計モデル
テスト方法テストモデル
解析モデル外部からの要求
解析
性能評価
システム仕様書
システムモデル
コンカレントデザインを促進するフレームワーク
構造
要求
振る舞い
パラメトリック制約
トレーサビリティ根拠
ビューポイント
35
製品データ管理(PDM)
・部品表(BOM)・物理設計(CAD)
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
SysMLダイアグラムの分類
SysML
ダイアグラム
振る舞い図
構造図
要求図
ユースケース図
シーケンス図
アクティビティ図
状態機械図
ブロック定義図
パラメトリック図
内部ブロック図
パッケージ図
SysML: Systems Modeling Language
36
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
SysMLによるMBSEのサポート
システム仕様の決定 ← 以下の活動の反復 ブラックボックスのシステム要求の取得と分析(コンテキストレベル)
要求管理ツールでの文書ベースでの要求の獲得
SysMLモデリングツールへの要求のインポート
システムのユースケースからシステムレベルでの機能の特定
ユースケースと要求間のトレーサビリティの獲得
ユースケースシナリオの実現:アクティビティ図,シーケンス図,状態機械図
システムコンテキスト図の創出
システム検証をサポートするシステムのテストケースの特定
要求を満たすシステムアーキテクチャ候補の開発
ブロック定義図を用いたシステムの分解
アクティビティ図またはシーケンス図を用いたパート間の相互作用の定義
内部ブロック図を用いたパート間の相互接続の定義
37
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
SysMLによるMBSEのサポート(続き)
所望のアーキテクチャの評価と選択のためのエンジニアリング解析と
トレードオフ分析の実行
性能,信頼性,コスト,その他の重要なプロパティの分析をサポートするためのパラメトリック図を用いたシステムプロパティの制約の獲得
システムプロパティの予算を決定するためのエンジニアリング解析の実行
(通常,別のエンジニアリング解析ツールで行われる)
コンポーネント要求の規定とシステム要求に対するコンポーネント要求のトレーサビリティの規定
アーキテクチャにおける,各コンポーネント(ブロック)のための機能要求,インタフェース要求,性能要求の獲得
システム要求へのコンポーネント要求のトレース
システムレベルでのテストケースの実行→システム設計に関する要求の充足の検証
38
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
SysML-Liteとは?
SysMLの9つのダイアグラムの内、6つのダイアグラム、パ
ッケージ図、要求図、アクティビティ図、ブロック定義図、内部ブロック図、パラメトリック図を用いてシステムモデルを記述する考え。
39
SysML
ダイアグラム
振る舞い図
構造図
要求図
ユースケース図
シーケンス図
アクティビティ図
状態機械図
ブロック定義図
パラメトリック図
内部ブロック図
パッケージ図
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
ユースケース図 システムの使われ方と動作
対象とするシステムはどのように使われ,どのような動作をするのか?
対象システムの境界はどこか?
境界:boundary
ユースケース1
ユースケース2
System of interest
対象システム
外部システム2
外部システム1
外部システム3
40
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
効果指標(Measures of Effectiveness)の把握
ミッションレベルの性能要求:パラメトリック図
利害関係者(顧客など)の価値
<<moe>>
運用コスト
<<moe>>
運用の可用性
<<moe>>
緊急時の応答時間
<<moe>>
緊急事態の発生確率
運用の目的関数
oc
avail ert eop
41
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
機能の明確化とインタフェース(1)
コンテキストレベルでの外部システムとのインタフェース
システムのユースケース(使われ方、動作)をシーケンス図により記述する. → パート間の相互作用
外部システム3
システム
メッセージ(相互作用) 自己
メッセージ
機能を記述するユースケース2をシーケンス図で記述し、システムの機能の抽出を行う。
↓
・システムは、外部システムからメッセージを受けるという機能1をもつ。・システムは、自己メッセージを処理するという機能2をもつ。
次に、抽出された各機能を実現するシーケンスを考える。
42
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
内部ブロック図 システムコンテキスト図
外部システムと対象システムとのインタフェースの把握
ibd [システムコンテキスト]
外部システム1
外部システム2
外部システム3
対象システム
アイテムフローポートコネクタ
43
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
機能の明確化とインタフェース(2)
システムの分解を検討する。
ブロック定義図
機能1, 2を実現するシーケンスを検討
サブシステム間の相互作用を明確
にする。
各サブシステムの生存線上にそれ
ぞれの機能が抽出される。
サブシステム1 サブシステム2
同期メッセージ
システム
サブシステム1 サブシステム2
・サブシステム2はサブシステム1から同期メッセージを受け、自己メッセージを処理する。・サブシステム2はサブシステム1にメッセージを返信する。
返信メッセージ
44
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
機能のコンポーネントへの割り当て
アクティビティ図でさらに信号のフローを検討する。
コンポーネントとインタフェースを明確化する。 サブシステム
サブシステム サブシステム2-1
サブシステム2-2
アクション1-1
アクション2-1
アクション1-2
アクション2-2
制御フローオブジェクトフロー
スイムレーイン or アクティビティ区画
開始ノード
アクティビティ終了ノード
ピン
パラメータ 1
パラメータ 2
1
45
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
ブロック定義図
シーケンス図とアクティビティ図での検討により、サブシステム2は、サブシステム2-1, 2-2に分解された。
システム
サブシステム1 サブシステム2
サブシステム2-1
サブシステム2-2
46
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
内部ブロック図
内部ブロック図によるコンポーネント間のインタフェースの記述
システムの内部構造システム[Block] ibd [ ]
サブシステム2-1
サブシステム2-2
サブシステム2
サブシステム1
[サブシステムの内部構造]
サブシステム1
サブシステム2
サブシステム2-1
サブシステム2-2
47
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
状態機械図(ステートマシン図)
イベントで生じる状態の遷移
状態1
状態2
entry/振る舞い1do/振る舞い2exit/振る舞い3
状態3
トリガー1[ガード条件]/遷移効果
トリガー2トリガー3
イベント=sd: メッセージ=act: アクション
48
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
要求の詳細化とトレーサビリティの確保<<Requirement>>
対象システムの要求
対象システムはxxの状況で、△△へ○○すること。
<<Requirement>>
R1
外部システムがxxの状況で○○すること。
<<Requirement>>
R2
△△に対応すること。
+
<<Functional Requirement>>
機能要求1
<<Functional Requirement>>
機能要求2-1
<<Functional Requirement>>
機能要求2-2
<<block>>
サブシステム1
<<derivedReqt>> <<derivedReqt>>
<<allocate>>
<<block>>
サブシステ2-1
<<allocate>><<allocate>>
<<derivedReqt>>
<<block>>
サブシステム2-2
<<activity>>
アクション1
<<satisfy>>
<<activity>>
アクション2-1
<<satisfy>>
<<activity>>
アクション2-2
<<satisfy>>
49
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
SysMLの活用で見えてくること
システムをモデルで表現する。
構造/振る舞い/要求/パラメトリック制約
- What – そもそも、何をしなければならないのか?
革新に導く。 オペレータや外部システムとの相互作用の明確化
サブシステム間のインタフェース
最適化“問題”やトレードオフ“問題”の設定・定義
アーキテクチャと仕様決定までの要求のトレース
50
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
エレベータに対する要求(例)
エレベーターは、ビルの各階から“コール(呼び)”を受けること。(入力に関する要求)
エレベーターは、想定される乗員に対して、エレベーターを呼んでいることを表示すること。(出力に関する要求)
エレベーターは、緊急コールに対してビルにある標準電話を利用すること。(外部インタフェースに関する要求)
The Engineering Design of
Systems, - Models and Methods -,
2nd Edition, Dennis M. Buede,
John Wiley & Sons, Inc.
51
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
ユースケース図
52
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
シーケンス図(コンテキストレベル)
53
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
シーケンス図(コンテキストレベル)
54
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
コンテクストレベルでの機能分析
エレベータシステムの機能
55
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
ユースケース「ドアを開く」→シーケンス図
56
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
アナリシスレベル01での機能分析
エレベータコントローラの機能
57
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
ブロック間のインタフェース
58
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
要求を詳細化したユースケース → テストケース
詳細化
59
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
サブ機能「エレベータを呼ぶ」
60
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
サブ機能「目的階に移動する」
61
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
サブ機能「ドアを開く」
62
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
サブ機能「ドアを閉じる」
63
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
ブロック定義図(アナリシスレベル)
64
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
エレベータシステムの状態機械図
65
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
ブロック定義図:フロアでのエレベータ待ち時間
66
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
パラメトリック図:フロアでのエレベータ待ち時間
67
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
まとめ
複数のドメインで構成されるシステムや、オペレータの介在する複雑なシステム(System of Systems (SoS)の一つ)を設計するために、MBSE(モデルベースシステムズエンジニアリング)の活用が重要であることを述べた。
モデルを用いたシステム開発では、システムモデルの記述に際して、
構造/振る舞い/要求/パラメトリック制約
の4つの柱で考えることが重要である。
SysMLはこれをサポートしている。
SysMLの適用手順を概説するとともに、エレベータ開発の事例を紹介し、MBSEで思考する過程を示した。
68
Copyright©2015 Hidekazu Nishimura.IPA/SECセミナー
参考文献 Systems Engineering Handbook 4th Edition, INCOSE, 2015
INTERNATIONAL STANDARD, ISO/IEC 15288:2015, First edition, 2015-05-15
Visualizing Project Management, Third Edition
Kevin Forsberg, Hal Mooz, Howard Cotterman, John Wiley & Sons, Inc.
IEEE 1220: For Practical Systems Engineering, Teresa Doran
http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1631953&userType=inst
システムズモデリング言語 SysML(A Practical Guide to SysMLの翻訳本)
西村 秀和(監訳),東京電機大学出版局,2012
The Engineering Design of Systems, - Models and Methods -, 2nd Edition
Dennis M. Buede, John Wiley & Sons, Inc.
The Art of Systems Architecting, Second Edition, Mark W. Maier, Eberhardt Rechtin,
CRC Press, 2002
MBSE wiki: http://www.omgwiki.org/MBSE/doku.php?id=start
複雑化する統合システム(SoS)の開発方法論 モデルベースシステムズエンジニアリング導入の手引き,IPA/SEC:http://www.ipa.go.jp/sec/reports/20130823.html
モデルに基づくシステムズエンジニアリング,西村秀和(総監修),藤倉俊幸(企画・監修),日経BP,2015
69