システムズエンジニアリング・
MBSE概要
慶應義塾大学大学院システムデザイン・マネジメント研究科 教授 西村 秀和 http: lab.sdm.keio.ac.jp/nismlab/SEC高信頼化技術セミナー
モデルベースシステムズエンジニアリング入門
～システムを考えるハンズオンワークショップ～
2015年12月10日（木）
略歴と業績
略歴 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年『モデルに基づくシステムズエンジニアリング』（総監修）
システムズエンジニアリング
2025のあるべき姿
システムズエンジニアリングの基盤は，アカデミアを横断して一貫性のある形 で定義され，教授される． システムの複雑度と関連するリスクが正しく評価され，特徴付けられ，そして 管理される． システムズエンジニアリングは，信頼でき回復力のあるシステムを設計し，そ して予測するための分析的なフレームワークを与える． モデルベースシステムズエンジニアリングは標準となり，企業体におけるデジ タル機能とともにモデリングとシミュレーションが統合される． システムズエンジニアリングは，競争力をもって新たなものを生み出し，大き な価値を与えるように，産業，政府，アカデミアを横断して認められる． システムズエンジニアリングは，技術の評価，政策の分析を行うために必須 の学問として確立される． システム思考は教育のすべてのレベルで教授される．INCOSE Systems Engineering Vision 2025 (June 2014)
http://www.incose.org/docs/default-source/aboutse/se-vision-2025.pdf?sfvrsn=4
MBSEのモチベーション
Systems Engineering
┃
Model Based Systems Engineering
┃
SysMLによるMBSE
Better productのために
Better engineeringを実現したい!
システムズエンジニアリングをモデルに基づく
ことで効果的、効率的にしたい
モデルベースで行うシステムズエンジニアリングを
国際的に認められた共通言語で行いたい
そのために そのために そのために決して
SysMLやMBSEがモチベーションの源泉や目的ではない
ドキュメントベースで 複雑なシステムを 扱うのは辛い！ QCDを守りたい。 トレーサビリティを確保 したい。 活動範囲が社 内だけに限定 されていない。？
システムとは何か？
システム：
相互に関連し全体として機能するコンポーネントの集まり
ハードウェア，ソフトウェア，人，設備など複数のドメインで構成
System of interest
境界：boundary
アクター actor：行為者 （人とは限らない） Use Case１ Use Case 2環境
System of interest
対象システム
システム：製品とそれを実現するプロセス
System 製品 サブ システム サブ システム 開発・テスト プロセス 製造 プロセス 販売・サポート プロセス 運用・ トレーニング プロセス 廃棄 プロセス 製品 - 設備 - 機器 - 工程 - ソフトウェア アプリ - 計算機資源 - 人員 - サプライヤ - ベンダー - 設備 - 機器/ツール - 工程 - ソフトウェア アプリ - 計算機資源 - 部品在庫 - 人員 - サプライヤ - ベンダー - 品質管理 - 設備 - 機器/ツール - 工程 - ソフトウェア アプリ - 計算機資源 - スペア部品 在庫 - メンテナンス サプライヤ - ベンダー - 設備 - 機器/ツール - 工程 - ソフトウェア アプリ - 計算機資源 - オペレータ - トレーナー - 設備 - 機器/ツール - 工程 - 人員 製品階層 ライフサイクルプロセス IEEE 1220よりシステムズエンジニアリングとは何か？
システムズエンジニアリングの定義
システムを成功裏に実現するための複数の分野にまたが
るアプローチおよび手段
システムズエンジニアリングでは、開発のライフサイクルの初
期段階で顧客のニーズを明確化し、機能要求を定義し、関連
する問題をすべて考慮しながら設計のための総合とシステム
の妥当性確認を進める。
システムズエンジニアリングは、ユーザーニーズに合致した
品質の製品を供給することを目的とし、ビジネスとすべての
顧客の技術的要求を考慮する。
システムズエンジニアリングは「アプローチ」
システムを
成功裏に実現
するための
複数の分野
にまたがる
アプローチおよび手段
コミュニケーションの重要性
システムズエンジニアリング標準の歴史
MIL-STD-499 MIL-STD-499A EIA/IS 632 IEEE 1220 IEEE 1220 IEEE 1220 ANSI/EIA 632 ISO 15288 ANSI/EIA 632 EIA/IS 731 Others.. 1969 1974 1994 1994 1998 1998 2000+Trial Use Standard
IEEE Standard for Application and Management of the Systems
Software & Systems Engineering Std. Cmt. IEEE Computer Society Military Standard
電子工業会
Electronic Industries Alliance
Interim standard
米国国家規格協会
ISO 15288:2015 システムライフサイクルプロセス
合意プロセス ・取得ﾌﾟﾛｾｽ ・供給ﾌﾟﾛｾｽ 組織的プロジェクト実現 プロセス ・ライフサイクルモデル マネジメントﾌﾟﾛｾｽ ・基盤マネジメントﾌﾟﾛｾ ｽ ・ポートフォリオマネジメ ントﾌﾟﾛｾｽ ・人的リソースマネジメ ントﾌﾟﾛｾｽ ・品質マネジメントﾌﾟﾛｾ ｽ ・知識マネジメントﾌﾟﾛｾ ｽ 技術マネジメントプロセ ス ・プロジェクト計画ﾌﾟﾛｾｽ ・プロジェクト評価・統制 ﾌﾟﾛｾｽ ・意思決定マネジメント ﾌﾟﾛｾｽ ・リスクマネジメントﾌﾟﾛｾ ｽ ・構成管理ﾌﾟﾛｾｽ ・情報マネジメントﾌﾟﾛｾｽ ・測定ﾌﾟﾛｾｽ ・品質保証ﾌﾟﾛｾｽ 技術プロセス ・ビジネス解析，ミッション解 析ﾌﾟﾛｾｽ ・利害関係者要求定義ﾌﾟﾛｾ ｽ ・システム要求分析ﾌﾟﾛｾｽ ・アーキテクチャ定義ﾌﾟﾛｾｽ ・設計定義ﾌﾟﾛｾｽ ・システム解析ﾌﾟﾛｾｽ ・実装ﾌﾟﾛｾｽ ・統合ﾌﾟﾛｾｽ ・検証ﾌﾟﾛｾｽ ・移行ﾌﾟﾛｾｽ ・妥当性確認ﾌﾟﾛｾｽ ・運用ﾌﾟﾛｾｽ ・保守ﾌﾟﾛｾｽ ・廃棄ﾌﾟﾛｾｽモデル
vs シミュレーション (SEH 4
th
Ed.)
“モデル”と“シミュレーション”には、それぞれに意味が
あるにもかかわらず、間違って受け取られることがある。
モデル＝対象とするシステム、エンティティ、現象、プロ
セスの抽象または表現（観点：形状、機能、性能）
シミュレーション＝時間に沿ってモデルを実行する特定
の環境へのモデルの実装。一般には、システム、ソフト
ウェア、ハードウェア、人、物理現象の複雑な動的振る
舞いを解析する手段を提供する。
コミュニケーションの失敗
このシステムは、●● と××から構成され、 △△の運用を考えた ときに、、、？
図を用いたコミュニケーション
このシステムは、●● と××から構成され、 △△の運用を考えた ときに、、、
モデリングの目的（１）
(SEH 4
th
Ed.)
実在するシステムの特徴づけ
：文書で書かれた実在システム
のモデリングでそのアーキテクチャと設計を把握する。
ミッションおよびシステムコンセプトの定式化と評価
：システム
ライフサイクル初期の段階で、モデルによりミッションおよび
システムコンセプト候補を総合（
synthesis）し評価（evaluate）す
る。システム設計のモデリングと重要なシステムパラメータの
影響評価からトレードオフ解析の解空間を探索する。
システムアーキテクチャとシステム要求のフローダウン
：モデ
ルを用いてシステム解のアーキテクティングを支援し、ミッショ
ンとシステム要求（機能要求、インタフェース要求、性能要求
、物理要求の他、信頼性、保守性、安全性、セキュリティなど
のいわゆる非機能要求）をシステム要素に割り当てる。
モデリングの目的（２）
(SEH 4
th
Ed.)
システム統合と検証の支援
：システムへのハードウェア、ソフ
トウェアの統合の支援とシステムが要求を充足することの検
証の支援にモデルを用いる。
Hardware-in-the-loop テスト、
Software-in-the-loop テスト。モデルは、テスト計画と実行を支
援するためテストケースやテストプログラムの他の観点を定
義する。
トレーニングの支援
：システムと相互作用するユーザー（オペ
レータ、保守員、その他）を訓練するシステムの様々な観点を
模擬する。
知識の獲得とシステム設計の進展
：システムに関する知識の
獲得と組織の知識としての維持のための効果的な手段をモ
デルは提供する。
システムライフサイクルプロセス中の
シミュレーションモデルとシステムモデル
ビ ジネス解 析 と ミ ッ ション解 析 ：解決すべき状況を表す
記述モデル
（
Descriptive model）は、正しい問題に対処していることを保証する。
利害関係者要求定義とシステム要求定義：要求を正当なものとし、適切
な要求の特定を行う。
アーキテクチャ定義：選択基準をもとに候補となっている選択肢を評価し、
他のシステムとの統合など、ベストのアーキテクチャを見いだす。
設計定義：必要な設計データを取得し、最適化のためのパラメータを調整
し、システム要素に対する実際のデータが得られるよう忠実にモデルを更
新する。
検証と妥当性検証：システム環境をシミュレートして検証および妥当性確
認データを評価し、（シミュレーションは、直接観察できない重要なパラメ
ータの計算のための入力として観測可能なデータを用いる）、シミュレーシ
ョンの忠実度の妥当性を確認する。
運用：実際の動作を反映し、計画、検証、オペレータの訓練のための実行
の前に動作を模擬する。
SEH 4th Ed.システムズエンジニアリング
「要求」と「アーキテクチャ」
要求の２つの鉄則
機能要求：“どのように要求を実現するか？”の前に
“
それは何か？
”，“
なぜそれが必要か？
”を明確にする。
要求は“
測定可能
”で“
テスト可能
”でなければならない。
アーキテクチャの３つのビュー
Operational view：システムの使い方、動かし方
Functional view：システムへ要求される機能
Physical view：機能を実現するハードウェア、ソフトウエア
高
抽
象
度
低
エンティティ
V:ビューの位置づけ
利害関係者の要求 製作，コード 化に向けた 仕様 Entity要求の定義 概念設計，アーキテクチャ の選定，設計に向けた仕様 購入，製作， コード化 検証 検査，テスト， 実証，分析 妥当性確認 妥当性確認の計画 要求の 抽出 概念設計 アーキテ クチャ 詳細設計 試験，検証 製造， 運用 Customer Confirmation Verification and Validation Planning Verification Planning 検証 検査，テスト， 実証，分析 Cus tome r Conf irma tio n Cus tome r Conf irma tio n 見込み調査， リス ク調 査 不具合調査 解決策の達成 ② Functional view ③ Physical view MATLAB/Simulink Mechanical CAD Electronic CAD Program code SysML ① Operational view二元
V字開発モデル (Dual Vee Model)
Architecture Vee Entity Vee 利害関係者 の要求 要求を満足する システムの完成二元
V字モデルによるプロセスの理解
Architecture Vee Entity Vee 利害関係者 の要求 要求を満足する システムの完成 アーキテクチャの検討， 決定では，サブシステ ムやコンポーネントの 実現可能性を検討しな がら進めることがある．早い段階での
手戻り
二元
V字モデルによるプロセスの理解
Architecture Vee Entity Vee 利害関係者 の要求 要求を満足する システムの完成 コンポーネント， サブシステムの 検証，妥当性確認 を順序行い，システム としての検証，妥当性 確認を行って行く．致命的な
手戻り
利害関係者の要求 製作，コード 化に向けた 仕様 Entity要求の定義 アーキテクチャの 選定とシステム仕様 購入，製作， コード化 検証 検査，テスト， 実証，分析 妥当性確認 妥当性確認の 計画 要求の 抽出 概念設計 アーキテ クチャ 詳細設計 試験，検証 製造， 運用 Customer Confirmation Verification and Validation Planning Verification Planning 検証 検査，テスト， 実証，分析 Customer Conf irmatio n Customer Conf irmatio n
エンティティ
V : 検証と妥当性確認
ノミナル オフノミナル HILS/SILS Human in the Loop Simulation シナリオIEEE 1220 systems engineering process
要求と制約の矛盾 要求のトレードオフ と影響 分解割り当ての トレードオフと影響 分解と要求の割り当に 関する候補 設計解の トレードオフと影響 設計解の要求と候補 要求の基準 確認された要求の基準 機能アーキテクチャ 検証済み機能アーキテクチャ 物理アーキテクチャ 検証済み物理アーキテクチャ SEプロセスへの入力 SEプロセスの出力 統制 設計の検証 機能の検証 要求の分析 要求の 妥当性確認 要求の トレードオフ 分析と評価 設計の トレードオフ 分析と評価 総合 システム解析 機能の分析 機能の トレードオフ 分析と評価“モデルベースでシステムを考える”とは？
モデル
＊に基づくシステムズエンジニアリング
仕様書など文書だけではすぐに理解できないことが、
図的
に表現する
ことで理解が容易になる。
協働してシステム開発をする
には、共通言語が必要であり、
それをサポートするには
図的な言語
が有効である。
モデルを再利用
することにより開発の効率化が期待できる。
モデルを用いて
抽象度を上げる
ことにより
革新
に導く。
＊注：実行可能ではないモデルを含む
システムモデルの記述
システムモデル表記法：
SysML（Systems Modeling Language）
システムを
構造
，
振る舞い
，
要求
，
パラメトリック制約
の観
点で図的に表現することができる。
図的表現により、
開発者の思考
を支援できる。
複数のドメインにまたがる開発、分業化された開発環境で、
共通言語
として利用できる。
システム開発プロセスの中で
要求のトレーサビリティ
が確
保される。
構成管理
、
変更管理
が容易になる。ーあるサブシステムや
コンポーネントの要求の変更や設計の変更が生じた際に、
他のサブシステムやコンポーネントにどのような影響が及
ぶかを判断できる。
SysMLで何ができるのか？
システムを構成するサブシステムに対する機能要求とその振
る舞いを把握できる。
設計変更があった場合にも、要求のトレースが可能なため、
その影響を容易に把握できる。
SysMLを用いることで、開発者の思考を支援し、ドメインをまた
がる協働作業が可能となる。
コンカレントデザインを促進するフレームワークが実現可能と
なる。ただし、組織の硬直化などが弊害となり得る。
参考資料：システムズモデリング言語 SysML （A Practical Guide to SysML翻訳本)
西村 秀和（監訳）
訳者：白坂成功，成川輝真，長谷川堯一，中島裕生，翁志強 著者：Sanford Friedenthal, Alan Moore, Rick Steiner
構造
要求
振る舞い
パラメトリック
制約
・数式表現 ・運動方程式 ・パラメータによる 性能評価 など ibd act req parシステムモデルを支える
4つの柱
SysMLダイアグラムの分類
SysML
ダイアグラム
振る舞い図
構造図
要求図
ユースケース図
シーケンス図
アクティビティ図
状態機械図
ブロック定義図
内部ブロック図
SysML: Systems Modeling Language
パラメトリック図
パッケージ図
ダイナミクス 解析 制御システム 解析 1D-CAEなど ハードウェア 設計モデル 電気回路 設計モデル ソフトウェア 設計モデル テスト方法 テストモデル 解析モデル 外部からの 要求 解析 性能 評価 システム 仕様書 システムモデル
コンカレントデザインを促進するフレームワーク
構造 要求 振る舞い パラメトリック制約 トレーサビリティ 根拠 ビュー ポイントシステムモデルを
SysMLダイアグラムで表現する（例）
pkg req act seq stm uc par bdd ibd
SoIと外部システム の関係 SoIのユースケー スシナリオ SoIに対する要求 機能および物理 アーキテクチャ システムの分析 システムの検証 振る舞い図 構造図 要 求 図 パラメ トリッ ク図 モデル編成の定義 ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ パッ ケー ジ図
システムモデルで明確にすること
ライフサイクルステージ
コンセプト⇒開発⇒製造⇒運用と保守⇒廃棄
それぞれについて検討する必要がある．さもなければ，システムは
実現しない．
それぞれのステージについて
コンテキスト（文脈，脈略）
を最初に考
え，抜け漏れがないことを確認する．その際，利害関係者の要求
や懸念事項をすべて洗い出す．その上で，
対象システムの境界
，
ユースケース
，
機能性
を明確にする．
次に対象システムの内部を分析し，総合する．最初に
機能を分解
して，その
分解された機能をシステム構成要素に割り当てる
．これ
により，
システム構成要素間のインタフェース
が定義され，アーキ
テクチャの候補が導出できる．
要求や懸念事項に応じて
View
（観点）
を設定し，トレードオフ分析に
アーキテクチャを選定
SysMLによるMBSEのサポート
システム仕様の決定 ← 以下の活動の反復
ブラックボックスのシステム要求の取得と分析（コンテキストレベル）
要求管理ツールでの文書ベースでの要求の獲得 SysMLモデリングツールへの要求のインポート システムのユースケースからシステムレベルでの機能の特定 ユースケースと要求間のトレーサビリティの獲得 ユースケースシナリオの実現：アクティビティ図，シーケンス図，状態機械図 システムコンテキスト図の創出 システム検証をサポートするシステムのテストケースの特定 要求を満たすシステムアーキテクチャ候補の開発
ブロック定義図を用いたシステムの分解 アクティビティ図またはシーケンス図を用いたパート間の相互作用の定義 内部ブロック図を用いたパート間の相互接続の定義SysMLによるMBSEのサポート（続き）
所望のアーキテクチャの評価と選択のためのエンジニアリング解析と
トレードオフ分析
の実行
性能，信頼性，コスト，その他の重要なプロパティの分析をサポートするための パラメトリック図を用いたシステムプロパティの制約の獲得 システムプロパティの予算を決定するためのエンジニアリング解析の実行 （通常，別のエンジニアリング解析ツールで行われる） コンポーネント要求の規定とシステム要求に対するコンポーネント要求の
トレーサビリティの規定
アーキテクチャにおける，各コンポーネント（ブロック）のための機能要求，イン タフェース要求，性能要求の獲得 システム要求へのコンポーネント要求のトレース システムレベルでの
テストケース
の実行→システム設計に関する要求の
充足の検証
ユースケース図 システムの使われ方と動作
対象とするシステムはどのように使われ，どのような動
作をするのか？
対象システムの境界はどこか？
境界：boundary
ユースケース１ ユースケース2System of interest
対象システム
外部システム2 外部システム１ 外部システム3効果指標（
Measures of Effectiveness）の把握
ミッションレベルの性能要求：パラメトリック図
利害関係者（顧客など）の価値
<<moe>> 運用コスト <<moe>> 運用の可用性 <<moe>> 緊急時の 応答時間 <<moe>> 緊急事態の 発生確率 運用の目的関数 oc機能の明確化とインタフェース（１）
コンテキストレベルでの外部システムとのインタフェース
システムのユースケース（使われ方、動作）をシーケンス図に
より記述する． → パート間の相互作用
外部
システム3
システム
メッセージ （相互作用） 自己 メッセージ機能を記述するユースケース2をシーケンス
図で記述し、
システムの機能の抽出
を行う。
↓
・システムは、外部システムから
メッセージを受けるという
機能１
をもつ。
・システムは、自己メッセージを処理する
という
機能２
をもつ。
次に、抽出された各機能を実現する
シーケンスを考える。
内部ブロック図 システムコンテキスト図
外部システムと対象システムとのインタフェースの把握
ibd [システムコンテキスト] 外部 システム1 外部 システム2 外部 システム3 対象システム アイテムフロー コネクタ ポート機能の明確化とインタフェース（２）
システムの分解を検討する。
ブロック定義図
機能
1, 2を実現するシーケンスを検討
サブシステム間の相互作用を明確
にする。
各サブシステムの生存線上にそれ
ぞれの機能が抽出される。
サブシステム１
サブシステム２
同期メッセージシステム
サブシステム１
サブシステム２
・サブシステム2はサブシステム1から
同期メッセージを受け、自己メッセー
ジを処理する。
・サブシステム2はサブシステム1に
メッセージを返信する。
返信メッセージ機能のコンポーネントへの割り当て（１）
アクティビティ図でさらに信号のフローを検討する。
コンポーネントとインタフェースを明確化する。
システム : アクション 1-1 : アクション 1-2 オブジェクト フロー 開始ノード アクティビティ 終了ノード ピン : アクション 2 制御フロー In :パラメータ Out :パラメータ機能のコンポーネントへの割り当て（２）
アクティビティ図でさらに信号のフローを検討する。
コンポーネントとインタフェースを明確化する。
: アクション 1-1 : アクション 2-1 : アクション 1-2 : アクション 2-2 制御フロー オブジェクト フロー 開始 ノード アクティビティ 終了ノード ピン サブシステム１ サブシステム２ In :パラメータ Out :パラメータ機能のコンポーネントへの割り当て（３）
アクティビティ図でさらに信号のフローを検討する。
コンポーネントとインタフェースを明確化する。
: アクション 1-1 : アクション 2-1 : アクション 1-2 : アクション 2-2 制御 フロー オブジェクト フロー 開始 ノード アクティビティ終了ノード ピン サブシステム1 サブシステム2-1 In :パラメータ Out :パラメータ サブシステム2-2ブロック定義図
シーケンス図とアクティビティ図での検討により、サブシ
ステム
2は、サブシステム2-1, 2-2に分解された。
システム
サブシステム1
サブシステム2
サブシステム
2-1
サブシステム
2-2
内部ブロック図
内部ブロック図によるコンポーネント間のインタフェース
の記述
システムの内部構造 システム [Block] ibd [ ] サブシステム2-1 サブシステム2-2 サブシステム2 サブシステム1 [サブシステムの内部構造] サブシステム1 サブシステム2 サブシステム 2-1 サブシステム 2-2状態機械図（ステートマシン図）
イベントで生じる状態の遷移
状態１ 状態２ entry/振る舞い１ do/振る舞い２ exit/振る舞い３ 状態３ トリガー１[ガード条件]／遷移効果 トリガー２ トリガー３ イベント ＝sd: メッセージ ＝act: アクション要求の詳細化とトレーサビリティの確保
<<Requirement>> 対象システムの要求 対象システムはxxの状況で、△△へ○○すること。 <<Requirement>> R1 外部システムがxxの状 況で○○すること。 <<Requirement>> R2 △△に対応すること。 ＋ <<Functional Requirement>> 機能要求1 <<Functional Requirement>> 機能要求2-1 <<Functional Requirement>> 機能要求2-2 <<derivedReqt>> <<derivedReqt>> <<allocate>> <<allocate>> <<allocate>> <<derivedReqt>> <<block>> <<activity>> アクション1 <<satisfy>> <<activity>> アクション2-1 <<satisfy>> <<activity>> アクション2-2 <<satisfy>>SysMLの活用で見えてくること
システムをモデルで表現する。⇒アーキテクチャ
構造／振る舞い／要求／パラメトリック制約
- What – そもそも、何をしなければならないのか？
革新に導くことに繋がる。
オペレータや外部システムとの相互作用の明確化
サブシステム間のインタフェース
最適化
“問題”
やトレードオフ
“問題”
の
設定・定義
アーキテクチャと仕様決定までの要求のトレース
ダイナミクス 解析 制御システム 解析 1D-CAEなど ハードウェア 設計モデル 電気回路 設計モデル ソフトウェア 設計モデル テスト方法 テストモデル 解析モデル 外部からの 要求 解析 性能 評価 システム 仕様書 システムモデル
コンカレントデザインを促進するフレームワーク
構造 要求 振る舞い パラメトリック制約 トレーサビリティ 根拠 ビュー ポイント 製品データ管理 （PDM） ・部品表（BOM） ・物理設計（CAD）システム
モデル
プロジェクト
マネジメント
要求
シミュレー
ション
/CAE
ライブラリ
/
データベース
生産
/サプライ
チェーン
最適化
CAD
SLIM (System Lifecycle Management)
PLM (Product Lifecycle Management), SCM (Supply Chain Management)
SLIM
INDUSTRIE 4.0に向けて．．．
システムズエンジニアリングと
Cyber Physical Systemの意味
ライフサイクル全般にわたるモデリング
それぞれのステージに応じて適切な
デジタルモデル
を持つ。
デジタルモデルは実システムと
整合
し、
正しい情報
を持つ必
要がある。
INDUSTRIE 4.0では、サプライチェーン、生産の効率化にデジ
タルモデルを活用することの重要性を強調。
2030年の実現を
目指す。
要求 抽出 概念 設計 アーキテク チャ 詳細 設計 試験 検証 製造 運用 保守 廃棄 ドライバー コントローラ (DYC) 車両 車両横変位 車両ハンドル角 車速 ヨーレート 横滑り角 駆動・制動トルク信号エレベータに対する要求（例）
エレベーターは、ビルの各階から“コール（呼び）”を受けるこ
と。（入力に関する要求）
エレベーターは、想定される乗員に対して、エレベーターを呼
んでいることを表示すること。（出力に関する要求）
エレベーターは、緊急コールに対してビルにある標準電話を
利用すること。（外部インタフェースに関する要求）
The Engineering Design of
Systems, - Models and Methods -, 2ndEdition, Dennis M. Buede,
シーケンス図（コンテキストレベル）
ライフライン上に
機能が並んでいる
コンテクストレベルでの機能分析
ユースケース「ドアを開く」
アナリシスレベル
01での機能分析
要求を詳細化したユースケース
→ テストケース
パラメトリック図：
フロアでのエレベータ待ち時間
待ち時間は
何によって
決まるのか？
緊急時のドア開停止
などを決める要因は
何か？
乗客の操作は
どの程度頻繁か？
まとめ
複数のドメインで構成されるシステムや、オペレータの介在す
る複雑なシステム（
System of Systems (SoS)の一つ）を設計する
ために、
MBSE（モデルベースシステムズエンジニアリング）の活
用が重要であることを述べた。
モデルを用いたシステム開発では、システムモデルの記述に
際して、
構造／振る舞い／要求／パラメトリック制約
の４つの柱で考えることが重要である。
SysMLはこれをサポートしている。
SysMLの適用手順を概説するとともに、エレベータ開発の事例
を紹介し、
MBSEで思考する過程を示した。
参考文献
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
モデルに基づくシステムズエンジニアリング，西村秀和（総監修），藤倉俊幸（企画・監修），
