システムズエンジニアリング・ MBSE概要...2014/08/25 · Benjamin D. Leea, William R....

Copyright©2014 Hidekazu Nishimura.

システムズエンジニアリング・MBSE概要

慶應義塾大学大学院システムデザイン・マネジメント研究科

教授西村秀和 http: lab.sdm.keio.ac.jp/nismlab/

1

SEC高信頼化技術セミナー

モデルベースシステムズエンジニアリング入門

～システムを考えるハンズオンワークショップ～

2014年8月25日（月）

Copyright©2014 Hidekazu Nishimura. IPA/SECセミナー

略歴と業績略歴 1985年3月慶應義塾大学理工学部機械工学科卒業

1987年3月同大学院理工学研究科機械工学専攻修士課程修了 1990年3月同大学院理工学研究科機械工学専攻博士後期課程修了工学博士 1990年4月より千葉大学工学部機械工学科助手 1995年より同助教授

2006年9月～10月デルフト工科大学訪問研究員 2007年2月～3月バージニア大学訪問准教授 2007年4月慶應義塾大学先導研究センター教授「SDM研究科設立準備」

2008年4月慶應義塾大学大学院システムデザイン・マネジメント研究科教授 2011年4月～2012年3月日本機械学会機械力学・制御部門部門長 2012年2月～2014年1月計測自動制御学会総務担当理事（2013年度副会長兼務）

著書 1998年『MATLABによる制御理論の基礎』（共著），『MATLABによる制御系設計』（共著）

2007年『運動と振動の制御の最前線』（共著） 2012年『システムズモデリング言語 SysML』 (監訳 A Practical Guide to SysML)

共同研究実績車両衝突時の乗員保護制御，次世代車両運動統合制御，Adaptive Cruise Control，EPS，エンジンベンチ制御，タワークレーンのアシスト制御，熱設計マネジメント，次世代プレス開発など

2

西村秀和


System ？

システムとは何か？

システム：

相互に関連し全体として機能するコンポーネントの集まり

ハードウェア，ソフトウェア，人，設備など複数のドメインで構成

3

System of interest

境界：boundary

アクター

actor：行為者

（人とは限らない）

Use Case１ Use Case 2

環境

System of interest

対象システム


System of Systems

様々なシステムが複雑に関連する中で、対象とするシステムを設計することは極めて難しい。

システム System of interest

システム1

システム2

システム3

システム4

4

Economics

（経済）

Policy（政策）

Technology（技術）

Environment（環境）


オペレータが介在するシステムの設計

オペレータと対象システムはどのような相互作用を起こすか？

オペレータによる操作とコントローラによる制御の間に矛盾が生じないようにシステムを構築する必要がある。

Operator-in-the-loop Designが必要となる。

認知判断行動

オペレータ

外部システム，環境

コントローラ

5

プラント

対象システム


システムズエンジニアリングとは何か？

システムズエンジニアリングの定義

システムを成功裏に実現するための複数の分野にまたがるアプローチおよび手段

システムズエンジニアリングでは、開発のライフサイクルの初期段階で顧客のニーズを明確化し、機能要求を定義し、関連する問題をすべて考慮しながら設計のための総合とシステムの妥当性確認を進める。

システムズエンジニアリングは、ユーザーニーズに合致した品質の製品を供給することを目的とし、ビジネスとすべての顧客の技術的要求を考慮する。

INCOSE: International Council on Systems Engineering

6


コミュニケーションの失敗

このシステムは、●●

と××から構成され、

△△の運用を考えた

ときに、、、

？

7


図を用いたコミュニケーション

このシステムは、●●

と××から構成され、

△△の運用を考えた

ときに、、、

8


“モデルベースでシステムを考える”とは？

モデル＊に基づくシステム開発

仕様書など文書だけではすぐに理解できないことが、図的に表現することで理解が容易になる。

協働してシステム開発をするには、共通言語が必要であり、それをサポートするには図的な言語が有効である。

モデルを再利用することにより開発の効率化が期待できる。

モデルを用いて抽象度を上げることにより革新に導く。

9

＊注：実行可能ではないモデルを含む


システムモデルの記述

システムモデル表記法：SysML（Systems Modeling Language）

システムを構造，振る舞い，要求，パラメトリック制約の観点で図的に表現することができる。

図的表現により、開発者の思考を支援できる。

複数のドメインにまたがる開発、分業化された開発環境で、共通言語として利用できる。

システム開発プロセスの中で要求のトレーサビリティが確保される。

構成管理、変更管理が容易になる。ーあるサブシステムやコンポーネントの要求の変更や設計の変更が生じた際に、他のサブシステムやコンポーネントにどのような影響が及ぶかを判断できる。

10


システムズエンジニアリング

「要求」と「アーキテクチャ」

要求の２つの鉄則

機能要求：“どのように要求を実現するか？”の前に

“それは何か？”，“なぜそれが必要か？”を明確にする。

要求は“測定可能”で“テスト可能”でなければならない。

アーキテクチャの３つのビュー

Operational view：システムの使い方、動かし方

Functional view：システムへ要求される機能

Physical view：機能を実現するハードウェア、ソフトウエア

11

高

抽象度

低

Architecting: the art and science of designing and building systems.


エンティティ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 CAD Electronic CAD Program code

SysML

① Operational view

12


二元V字開発モデル (Dual Vee Model)

Architecture Vee

Entity Vee

利害関係者

の要求

要求を満足する

システムの完成

13


二元V字モデルによるプロセスの理解

Architecture Vee

Entity Vee

利害関係者

の要求



アーキテクチャの検討，決定では，サブシステムやコンポーネントの実現可能性を検討しながら進めることがある．

14

早い段階での

手戻り


二元V字モデルによるプロセスの理解

Architecture Vee

Entity Vee 利害関係者

の要求



コンポーネント，

サブシステムの

検証，妥当性確認

を順序行い，システム

としての検証，妥当性

確認を行って行く．

15

致命的な

手戻り


利害関係者の要求

製作，コード化に向けた仕様

Entity要求の定義

アーキテクチャの選定とシステム仕様

購入，製作，コード化

検証検査，テスト，実証，分析

妥当性確認

妥当性確認の計画

要求の

抽出概念設計


詳細設計試験，検証製造，

運用

Customer Confirmation

Verification and Validation Planning

Verification Planning

検証検査，テスト，実証，分析

Cust

om

er

Confirm

ation

Cust

om

er

Confirm

ation

エンティティV : 検証と妥当性確認

ノミナル

オフノミナル

HILS/SILS

Human in the Loop Simulation

シナリオ

16


IEEE 1220 systems engineering process

要求と制約の矛盾

要求のトレードオフ

と影響

分解割り当ての

トレードオフと影響

分解と要求の割り当に関する候補

設計解の

トレードオフと影響

設計解の要求と候補

要求の基準

確認された要求の基準

機能アーキテクチャ

検証済み機能アーキテクチャ

物理アーキテクチャ

検証済み物理アーキテクチャ

SEプロセスへの入力

SEプロセスの出力

統制

設計の検証

機能の検証

要求の分析

要求の

妥当性確認

要求の

トレードオフ

分析と評価

設計の

トレードオフ分析と評価

総合

システム解析

機能の分析機能の

トレードオフ分析と評価

17


モデルベースシステムズエンジニアリング

の海外動向

MBSE wiki

http://www.omgwiki.org/MBSE/doku.php?id=start

最新のMBSEアクティビティと応用

MBSE関係者とのネットワークづくり

MBSE Workshop at INCOSE IW 2014

http://www.omgwiki.org/MBSE/doku.php?id=mbse:incose_mbs

e_iw_2014

MBSE Workshop at INCOSE IW 2013

http://www.omgwiki.org/MBSE/doku.php?id=mbse:incose_mbs

e_iw_2013

18




http://www.omgwiki.org/MBSE/doku.php?id=mbse:incose_mbse_iw_2014





IPA/SECセミナー Copyright©2014 Hidekazu Nishimura.

システム


形式の変換

分析的な

統合

PDM: Product Data Management

要求分析

実行可能なシミュレーションモデル文書化と文書管理

コスト分析

リスク分析

最適化

視覚化

部品表（BOM）サプライチェーンマネジメント

物理設計（3D CAD）

要求管理

Christopher Oster, Lockheed Martin Corporationの資料より改変

High Fidelity

Simulations

忠実度の高い

シミュレーション

19


正しいシステムを得ること

「正しい要求」＋「正しいインタフェース」

→ 「正しいコンポーネント」

正しい要求 ←整合→ 要求のモデル

正しいインタフェース ←整合→ インタフェースのモデル

正しいコンポーネント ←整合→ コンポーネントのモデル

シミュレーションモデル：「要求のモデル」をサポートする。

正しいシステム←整合→ シミュレーションモデル

→ 仕様を正しく得る。

20

Ron Carson, MBSE Implementation Across Diverse Domains at The Boeing Company

より改変


MBSE 今後の重要ポイント

MBSE = SE

「モデルベースシステムズエンジニアリング」は、「システムズエンジニアリング」である。

企業体、組織へのSE導入には、時間がかかる。NASA JPL

でも、2009年から7年間程度のロードマップを用意してMBSE

の導入を図っている。

Digital Systems Engineering：これまでの文書ベースのSE

に対して、それらの活動がデジタル化されることによりSEがメインストリームになる重要性を強調している。

INCOSEの今後5年間の方針

製品、サービスにより価値をもたらすよう協働で進展させること。

これまでの文書ベースのSEをモデルベースに移行させること。

21


Value-Driven Systems Engineering

価値駆動型システムズエンジニアリング

22

Global Context in SoS

環境的側面

経済的側面

政策的側面

技術的側面

価値の最大化

技術によって価値を

生む機会をとらえる。

新しいシステムの開発

Benjamin D. Leea, William R. Bindera, Christiaan J.J. Paredisa,

A Systematic Method for Specifying Effective Value Models,

Procedia Computer Science 28 ( 2014 ) 228 – 236

System of Systemsの中でグローバルコンテキストを考える。


SysMLで何ができるのか？

システムを構成するサブシステムに対する機能要求とその振る舞いを把握できる。

設計変更があった場合にも、要求のトレースが可能なため、その影響を容易に把握できる。

SysMLを用いることで、開発者の思考を支援し、ドメインをまたがる協働作業が可能となる。

コンカレントデザインを促進するフレームワークが実現可能となる。ただし、組織の硬直化などが弊害となり得る。

参考資料：システムズモデリング言語 SysML （A Practical Guide to SysML翻訳本)

西村秀和（監訳）

訳者：白坂成功，成川輝真，長谷川堯一，中島裕生，翁志強

著者：Sanford Friedenthal, Alan Moore, Rick Steiner

出版社：東京電機大学出版局（2012年5月10日）

23


構造

要求

振る舞い

パラメトリック

制約・数式表現

・運動方程式

・パラメータによる

性能評価

など

SysMLのダイアグラムは，互いに関連している。

→ 設計変更があった場合にもその影響を容易に把握できる。

ibd act

req par

24


ソフトウェアモデルハードウェアモデル

要求・仕様

設計・統合

要求・仕様

設計・統合

SysMLを用いた協働作業

構造

要求

振る舞い

パラメトリック

25

システムモデル


ダイナミクス解析

制御システム解析

1D-CAEなど

ハードウェア

設計モデル

電気回路

設計モデル

ソフトウェア

設計モデル

テスト方法テストモデル

解析モデル外部からの

要求

解析

性能

評価システム

仕様書

システムモデル

コンカレントデザインを促進するフレームワーク

構造

要求

振る舞い

パラメトリック制約

トレーサビリティ

根拠

ビュー

ポイント

26

製品データ管理（PDM）

・部品表（BOM）・物理設計（CAD）


SysMLダイアグラムの分類

SysML

ダイアグラム

振る舞い図

構造図

要求図

ユースケース図

シーケンス図

アクティビティ図

状態機械図

ブロック定義図

パラメトリック図

内部ブロック図

パッケージ図

SysML: Systems Modeling Language

27


SysMLによるMBSEのサポート

システム仕様の決定 ← 以下の活動の反復ブラックボックスのシステム要求の取得と分析（コンテキストレベル）

要求管理ツールでの文書ベースでの要求の獲得

SysMLモデリングツールへの要求のインポート

システムのユースケースからシステムレベルでの機能の特定

ユースケースと要求間のトレーサビリティの獲得

ユースケースシナリオの実現：アクティビティ図，シーケンス図，状態機械図

システムコンテキスト図の創出

システム検証をサポートするシステムのテストケースの特定

要求を満たすシステムアーキテクチャ候補の開発

ブロック定義図を用いたシステムの分解

アクティビティ図またはシーケンス図を用いたパート間の相互作用の定義

内部ブロック図を用いたパート間の相互接続の定義

28


SysMLによるMBSEのサポート（続き）

所望のアーキテクチャの評価と選択のためのエンジニアリング解析と

トレードオフ分析の実行

性能，信頼性，コスト，その他の重要なプロパティの分析をサポートするためのパラメトリック図を用いたシステムプロパティの制約の獲得

システムプロパティの予算を決定するためのエンジニアリング解析の実行

（通常，別のエンジニアリング解析ツールで行われる）

コンポーネント要求の規定とシステム要求に対するコンポーネント要求のトレーサビリティの規定

アーキテクチャにおける，各コンポーネント（ブロック）のための機能要求，インタフェース要求，性能要求の獲得

システム要求へのコンポーネント要求のトレース

システムレベルでのテストケースの実行→システム設計に関する要求の充足の検証

29


SysML-Liteとは？

SysMLの9つのダイアグラムの内、6つのダイアグラム、パ

ッケージ図、要求図、アクティビティ図、ブロック定義図、内部ブロック図、パラメトリック図を用いてシステムモデルを記述する考え。

30

SysML

ダイアグラム

振る舞い図

構造図

要求図


シーケンス図

アクティビティ図

状態機械図


パラメトリック図


パッケージ図


機能の明確化とインタフェース（１）

コンテキストレベルでの外部システムとのインタフェース

システムのユースケース（使われ方、動作）を考える。

シーケンス図による記述パート間の相互作用

31

外部システム

システム

メッセージ

（相互作用）自己

メッセージ

機能を記述するユースケースをシーケンス

図で記述し、システムの機能の抽出を行う。

↓

・システムは、外部システムから

メッセージを受けるという機能１をもつ。

・システムは、自己メッセージを処理する

という機能２をもつ。

次に、抽出された各機能を実現する

シーケンスを考える。


機能の明確化とインタフェース（２）

システムの分解を検討する。


機能１を実現するシーケンスを検討

サブシステム間の相互作用を明確

にする。

各サブシステムの生存線上にそれ

ぞれの機能が抽出される。

32

サブシステム１サブシステム２

同期メッセージ

システム

サブシステム１サブシステム２

・サブシステム2はサブシステム1から

同期メッセージを受け、自己メッセー

ジを処理する。

・サブシステム2はサブシステム1に

メッセージを返信する。

返信メッセージ


機能のコンポーネントへの割り当て

アクティビティ図でさらに信号のフローを検討する。

コンポーネントとインタフェースを明確化する。

33

サブシステム

サブシステムサブシステム2-1

サブシステム2-2

アクション1－1




制御フローオブジェクトフロー

スイムレーイン or アクティビティ区画

開始ノード

アクティビティ終了ノード

ピン

パラメータ 1

パラメータ 2



シーケンス図とアクティビティ図での検討により、サブシステム2は、サブシステム2-1, 2-2に分解された。

34

システム

サブシステム1 サブシステム2





内部ブロック図によるコンポーネント間のインタフェースの記述

35

システムの内部構造システム[Block] ibd [ ]



サブシステム2

サブシステム1

[サブシステムの内部構造]

サブシステム1

サブシステム2




要求の詳細化とトレーサビリティの確保

36

<<Requirement>>

対象システムの要求

対象システムはxxの状況で、△△へ○○すること。

<<Requirement>>

R1

外部システムがxxの状況で○○すること。

<<Requirement>>

R2

△△に対応すること。

＋

<<Functional Requirement>>

機能要求1


機能要求2-1


機能要求2-2

<<block>>

サブシステム1

<<derived>> <<derived>>

<<satisfy>>

<<block>>


<<satisfy>> <<satisfy>>

<<derived>>

<<block>>



SysMLの活用で見えてくること

システムをモデルで表現する。

構造／振る舞い／要求／パラメトリック制約

- What – そもそも、何をしなければならないのか？

革新に導く。

オペレータや外部システムとの相互作用の明確化

サブシステム間のインタフェース

最適化“問題”やトレードオフ“問題”の設定・定義

アーキテクチャと仕様決定までの要求のトレース

37


エレベータに対する要求（例）

エレベーターは、ビルの各階から“コール（呼び）”を受けること。（入力に関する要求）

エレベーターは、想定される乗員に対して、エレベーターを呼んでいることを表示すること。（出力に関する要求）

エレベーターは、緊急コールに対してビルにある標準電話を利用すること。（外部インタフェースに関する要求）

The Engineering Design of

Systems, - Models and Methods -,

2nd Edition, Dennis M. Buede,

John Wiley & Sons, Inc.

38



39


シーケンス図（コンテキストレベル）

40


シーケンス図（コンテキストレベル）

41


コンテクストレベルでの機能分析

エレベータシステムの機能

42


ユースケース「ドアを開く」

→シーケンス図

43


アナリシスレベル01での機能分析

エレベータコントローラの機能

44


ブロック間のインタフェース

45


要求を詳細化したユースケース → テストケース

詳細化

46


サブ機能「エレベータを呼ぶ」

47


サブ機能「目的階に移動する」

48


サブ機能「ドアを開く」

49


サブ機能「ドアを閉じる」

50


ブロック定義図（アナリシスレベル）

51


エレベータシステムの状態機械図

52


ブロック定義図：フロアでのエレベータ待ち時間

53


パラメトリック図：

フロアでのエレベータ待ち時間

54


まとめ

複数のドメインで構成されるシステムや、オペレータの介在する複雑なシステム（System of Systems (SoS)の一つ）を設計するために、MBSE（モデルベースシステムズエンジニアリング）の活用が重要であることを述べた。

モデルを用いたシステム開発では、システムモデルの記述に際して、

構造／振る舞い／要求／パラメトリック制約

の４つの柱で考えることが重要である。

SysMLはこれをサポートしている。

SysMLの適用手順を概説するとともに、エレベータ開発の事例を紹介し、MBSEで思考する過程を示した。

55


参考文献 Systems Engineering Handbook Ver.3.2, INCOSE, 2010

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.

西村秀和，二輪自動車のコーナリング特性と走行安定化制御，自動車技術会，Vol.64, No.12, (2010), pp.43-48

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

56

システムズエンジニアリング・ MBSE概要...2014/08/25 · Benjamin D. Leea, William R....

Documents

Transcript of システムズエンジニアリング・ MBSE概要...2014/08/25 · Benjamin D. Leea, William R....