モデルに基づくシステムズエンジニアリング （MBSE）入門 ～システムモデルの意味と活用について～ 慶應義塾大学大学院システムデザイン・マネジメント研究科 教授 西村 秀和 ET2015/IoT2015 SEC先端技術入門ゼミ 2015年11月18-20日
？
システムとは何か？
システム： 相互に関連し全体として機能するコンポーネントの集まり． ハードウェア，ソフトウェア，人，設備などで構成される． System of interest 境界：boundary アクター actor：行為者 （人とは限らない） Use Case１ Use Case 2 環境 System of interest 対象システムシステムにはライフサイクルがある
ISO 15288:2015 システムライフサイクルステージ システムが生まれてから
システムが なくなるまで
システム：製品とそれを実現するプロセス
System 製品 サブ システム サブ システム 開発・テスト プロセス 製造 プロセス 販売・サポート プロセス 運用・ トレーニング プロセス 廃棄 プロセス 製品 - 設備 - 機器 - 工程 - ソフトウェア アプリ - 計算機資源 - 人員 - サプライヤ - ベンダー - 設備 - 機器/ツール - 工程 - ソフトウェア アプリ - 計算機資源 - 部品在庫 - 人員 - サプライヤ - ベンダー - 品質管理 - 設備 - 機器/ツール - 工程 - ソフトウェア アプリ - 計算機資源 - スペア部品 在庫 - メンテナンス サプライヤ - ベンダー - 設備 - 機器/ツール - 工程 - ソフトウェア アプリ - 計算機資源 - オペレータ - トレーナー - 設備 - 機器/ツール - 工程 - 人員 製品階層 ライフサイクルプロセス IEEE 1220よりISO 15288:2015 システムライフサイクルプロセス
合意プロセス ・取得ﾌﾟﾛｾｽ ・供給ﾌﾟﾛｾｽ 組織的プロジェクト実現 プロセス ・ライフサイクルモデル マネジメントﾌﾟﾛｾｽ ・基盤マネジメントﾌﾟﾛｾ ｽ ・ポートフォリオマネジメ ントﾌﾟﾛｾｽ ・人的リソースマネジメ ントﾌﾟﾛｾｽ ・品質マネジメントﾌﾟﾛｾ ｽ ・知識マネジメントﾌﾟﾛｾ ｽ 技術マネジメントプロセ ス ・プロジェクト計画ﾌﾟﾛｾｽ ・プロジェクト評価・統制 ﾌﾟﾛｾｽ ・意思決定マネジメント ﾌﾟﾛｾｽ ・リスクマネジメントﾌﾟﾛｾ ｽ ・構成管理ﾌﾟﾛｾｽ ・情報マネジメントﾌﾟﾛｾｽ ・測定ﾌﾟﾛｾｽ ・品質保証ﾌﾟﾛｾｽ 技術プロセス ・ビジネス解析，ミッション解 析ﾌﾟﾛｾｽ ・利害関係者要求定義ﾌﾟﾛｾ ｽ ・システム要求分析ﾌﾟﾛｾｽ ・アーキテクチャ設計ﾌﾟﾛｾｽ ・設計定義ﾌﾟﾛｾｽ ・システム解析ﾌﾟﾛｾｽ ・実装ﾌﾟﾛｾｽ ・統合ﾌﾟﾛｾｽ ・検証ﾌﾟﾛｾｽ ・移行ﾌﾟﾛｾｽ ・妥当性確認ﾌﾟﾛｾｽ ・運用ﾌﾟﾛｾｽ ・保守ﾌﾟﾛｾｽ ・廃棄ﾌﾟﾛｾｽシステムを構築するプロセス（簡易版）
利害関係者 ニーズ システム設計 と仕様 システム統合 とテスト システム 解決策 システム要求 コンポーネント 設計，実装，テスト コンポーネント 要求 検証済み コンポーネント 設計の フィードバック 統合とテストからのフィードバック システム アーキテクチャシステムとシステムアーキテクチャ
システムズエンジニアリングプロセスでは、対象とするシステム （system of interest）に関してライフサイクル全体を見渡した上で 、要求分析を行い、そしてそのアーキテクチャを構築することが 極めて重要となる。システムアーキテクチャの決定には，さまざ まな観点（View，例えば，安全性，信頼性，可用性，保守性）か らの検討が必要になる． アーキテクチャの定義：ISO/IEC/IEEE 42010 「アーキテクチャは，システム要素とその関係性の中で具体 化された，ある環境中のシステムの基本概念または特性であ り，またシステムを設計し進化させるその原則である．」複雑なシステムの開発をいかに
マネジメントするか？
要求される機能を分解＝機能アーキテクチャ 分解された機能を構成要素に割り当てる＝物理アーキテクチャ アーキテクチャの選定には、Viewの設定が重要となる。 システム解析による検証：トレードオフ分析と評価 T/M エンジン ABS CAN クラスタ 速度表示 ACC 自動 変速 複数の機能がサブシステム間に またがっている複雑システム： トレーサビリティを確保した上で、 QCDを守って開発を進めたい。 サブシステム（構成要素） Traction control コンテキストを明確にし、機能性 を把握した上で、要求される機 能を実現するシステムアーキテ クチャを構築する。システム
境界
の定義
（
コンテキストレベル
）
対象とするシステム：自動車
外部システム：ドライバー，ガスポンプ（燃料供給），道路
など．他にもさまざまな利害関係者が関係する．
要求：自動車はドライバーの運転により，道路上を移動
して，ある地点から目的の場所へ人や物を運ぶことがで
きる．＝ユーザーに提供したい価値
道路 ドライバー 自動車 ガソリンスタンドシステムの
機能要求
自動車の機能の
1つ：「加速する」
機能「加速する」を入出力の関係で記述する．
自動車はドライバーの加速指令を受けて，「加速する」と
いう機能を持つ．
ドライバーに対して，自動車は「速度を提示する」という
機能を持つ．
加速指令入力 加速する 駆動力 速度表示 速度を 提示する 速度システムの
性能要求
機能の評価：「加速する」の評価
ドライバーからの指令に対して，どれだけ加速することが
要求されているのか？
自動車の速度 [km / h] 100 50 O 2 4 6 8 ×機能の
分析
(Analysis)
と設計の
総合
(Synthesis)
システムの機能を分析する．＜振る舞い図＞
機能を物理へ割り当てると，，，
(Allocation)
加速する 加速指令 加速力の発生 回転力を 発生する 発生した 回転力を 調整する 加速 指令 調整した力 をタイヤに 分配する 加速力 の発生 タイヤが 回転する インタフェースの明確化システムの構造の明確化
自動車はタイヤ，エンジン，トランスミッション，デフなど
のコンポーネントから構成される．
コンポーネント間のインタフェースを明確にする．
システム思考，論理思考（１）
システムを考える力
箸をシステムとして考える＝アーキテクチャ
①箸の機能性（ユースケース）をコンテキストで考える．
「箸で食べ物をつまむ」，「箸でつまんだ食べ物を口に入れる」
ユースケースの実現
箸の外部システム：「箸をもつ手」，「食べ物」，「口」
②システムの内部を分析し，総合する．
Analysis & Synthesis
構造：親指側で支える側の棒，薬指側で支える側の棒
振る舞い：2本の棒の相互作用で機能性を実現する．
箸の「要求」を充足することの確認
パラメトリック制約：箸の大きさ，重さ，重心，使いやすさを測る
システム思考，論理思考（２）
機能を表現する力
朝食の前に、子供はお母さんから、「テーブルに牛乳を出し ておいてね」と言われた。 この子供は何をどうすれば良いのか？ 1. 冷蔵庫から牛乳パックを取り出す。 2. 取り出した牛乳パックをテーブルに置く。 3. 食器棚からグラスを人数分取り出す。 4. 取り出したグラスをテーブルに置く。 5. 牛乳パックから各グラスに牛乳を注ぐ。システムズエンジニアリングは「アプローチ」
システムを成功裏に実現するための複数の分野にまたがる
アプローチおよび手段
コミュニケーションの重要性
システムモデルで明確にすること
ライフサイクルステージ コンセプト⇒開発⇒製造⇒運用と保守⇒廃棄 それぞれについて検討する必要がある．さもなければ，システムは 実現しない． それぞれのステージについてコンテキスト（文脈，脈略）を最初に考 え，抜け漏れがないことを確認する．その際，利害関係者の要求 や懸念事項をすべて洗い出す．その上で，対象システムの境界， ユースケース，機能性を明確にする． 次に対象システムの内部を分析し，総合する．最初に機能を分解 して，その分解された機能をシステム構成要素に割り当てる．これ により，システム構成要素間のインタフェースが定義され，アーキ テクチャの候補が導出できる． 要求や懸念事項に応じてView（観点）を設定し，トレードオフ分析に よりいくつかの候補の中から適切なアーキテクチャを選定する．コミュニケーションの失敗
このシステムは、●● と××から構成され、 △△の運用を考えた ときに、、、？
図を用いたコミュニケーション
このシステムは、●● と××から構成され、 △△の運用を考えた ときに、、、
MBSEのモチベーション
Systems Engineering
┃
Model Based Systems Engineering
┃
SysMLによるMBSE
Better productのために Better engineeringを実現したい! システムズエンジニアリングをモデルに基づく ことで効果的、効率的にしたい モデルベースで行うシステムズエンジニアリングを 国際的に認められた共通言語で行いたい そのために そのために そのために 決してSysMLやMBSEがモチベーションの源泉や目的ではない ドキュメントベースで 複雑なシステムを 扱うのは辛い！ QCDを守りたい。 トレーサビリティを確保 したい。 活動範囲が社 内だけに限定 されていない。MBSE＝Systems Engineering
あくまでも
Systems Engineeringである。
システムモデルに基づいて
Systems Engineeringを行う。
Systems Engineeringの無いMBSEはあり得ない
。
Systems Engineeringには大きく４つの活動がある。
システム設計 システムの解析と検証 システムの統合 システムズエンジニアリングのマネジメント 注：MBD（モデルベース開発）はMBSEの一部分である。 システムモデル＝シミュレーションモデルSysMLダイアグラムの分類
SysML ダイアグラム 振る舞い図 構造図 要求図 ユースケース図 シーケンス図 アクティビティ図 状態機械図 ブロック定義図 内部ブロック図 SysML: Systems Modeling Languageパラメトリック図 パッケージ図
システムモデルを
SysMLダイアグラムで表現する（例）
pkg req act seq stm uc par bdd ibd
SoIと外部システム の関係 SoIのユースケー スシナリオ SoIに対する要求 機能および物理 アーキテクチャ システムの分析 システムの検証 振る舞い図 構造図 要 求 図 パラメ トリッ ク図 モデル編成の定義 ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ パッ ケー ジ図
ダイナミクス 解析 制御システム 解析 1D-CAEなど ハードウェア 設計モデル 電気回路 設計モデル ソフトウェア 設計モデル テスト方法 テストモデル 解析モデル 外部からの 要求 解析 性能 評価 システム 仕様書 システムモデル
コンカレントデザインを促進するフレームワーク
構造 要求 振る舞い パラメトリック制約 トレーサビリティ 根拠 ビュー ポイント 製品データ管理 （PDM） ・部品表（BOM） ・物理設計（CAD）システム モデル プロジェクト マネジメント 要求 シミュレー ション/CAE ライブラリ/ データベース 生産/サプライ チェーン 最適化 CAD
システムライフサイクルのマネジメント
PLM (Product Lifecycle Management), SCM (Supply Chain Management) システム
参考文献
Systems Engineering Handbook 4th Edition, INCOSE, 2015
INTERNATIONAL STANDARD, ISO/IEC 15288:2015, First edition, 2015-05-15 INTERNATIONAL STANDARD, ISO/IEC 26702, IEEE Std 1220-2005, First edition,
2007-07-15
INTERNATIONAL STANDARD, ISO/IEC/IEEE 42010 1st ed., Systems and software
engineering —Architecture description. 2011
Visualizing Project Management, Third Edition
Kevin Forsberg, Hal Mooz, Howard Cotterman, John Wiley & Sons, Inc.
システムズモデリング言語 SysML（A Practical Guide to SysMLの翻訳本）
西村 秀和（監訳），東京電機大学出版局，2012
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
モデルに基づくシステムズエンジニアリング，西村秀和（総監修），藤倉俊幸（企画・監修），
