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

SEC高信頼化技術セミナー
モデルベースシステムズエンジニアリング(MBSE)入門
~導入のポイントと適用事例の紹介~
2015年11月26日
モデルベースシステムズエンジニアリング
~システムモデルは何に活用できるか?
本当の話をしよう!~
慶應義塾大学 教授 IPA/SEC 連携委員 西村 秀和
http: lab.sdm.keio.ac.jp/nismlab/
Copyright©2015 Hidekazu Nishimura.
本日のお話の内容





システムズエンジニアリングの欧米での広がり
モデルに基づくシステムズエンジニアリング(MBSE)
の重要性
開発ステージでのシステムズエンジニアリングプロセ
スの概略の流れ
システムアーキテクチャの重要性とシステムモデル
の有効性
SysMLの適用事例と適用を試みた企業担当者から
の評価
1
Copyright©2015 Hidekazu Nishimura.
INCOSE INSIGHT Vol.18, Issue.2, 2015
2014年度 MBSE調査対象(回答)国
2
Copyright©2015 Hidekazu Nishimura.
MBSE は 広 範 囲 の
産業に採用されてい
る。
INCOSE INSIGHT
Vol.18, Issue.2, 2015
3
Copyright©2015 Hidekazu Nishimura.
MBSEの認知と採用

この3年間の変化は
極めて大きい。
INCOSE INSIGHT
Vol.18, Issue.2, 2015
4
Copyright©2015 Hidekazu Nishimura.
MBSEの取り組み
をどこに適用して
いるか?
Copyright©2015
Hidekazu
Nishimura.
Vol.18,
Issue.2,
2015
5 INCOSE INSIGHT
システムズエンジニアリング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
6
Copyright©2015 Hidekazu Nishimura.
MBSEのモチベーション
QCDを守りたい。
トレーサビリティを確保
したい。
Better productのために
Better engineeringを実現したい!
そのために
Systems Engineering
┃
ことで効果的、効率的にしたい
そのために
Model Based Systems Engineering
ドキュメントベースで
複雑なシステムを
システムズエンジニアリングをモデルに基づく
扱うのは辛い!
モデルベースで行うシステムズエンジニアリングを
活動範囲が社
国際的に認められた共通言語で行いたい
内だけに限定
されていない。
そのために
┃
SysMLによるMBSE
決してSysMLやMBSEがモチベーションの源泉や目的ではない
7
Copyright©2015 Hidekazu Nishimura.
システムとは何か?

システム:
相互に関連し全体として機能するコンポーネントの集まり
ハードウェア,ソフトウェア,人,設備など複数のドメインで構成
環境
アクター
actor:行為者
(人とは限らない)
境界:boundary
Use Case1
Use Case 2
System of interest
?
System of interest
対象システム
8
Copyright©2015 Hidekazu Nishimura.
システム:製品とそれを実現するプロセス
System
製品階層
製品
サブ
システム
製品
サブ
システム
IEEE 1220より
開発・テスト
プロセス
- 設備
- 機器
- 工程
- ソフトウェア
アプリ
- 計算機資源
- 人員
- サプライヤ
- ベンダー
製造
プロセス
- 設備
- 機器/ツール
- 工程
- ソフトウェア
アプリ
- 計算機資源
- 部品在庫
- 人員
- サプライヤ
- ベンダー
- 品質管理
9
ライフサイクルプロセス
販売・サポート
プロセス
- 設備
- 機器/ツール
- 工程
- ソフトウェア
アプリ
- 計算機資源
- スペア部品
在庫
- メンテナンス
サプライヤ
- ベンダー
運用・
トレーニング
プロセス
- 設備
- 機器/ツール
- 工程
- ソフトウェア
アプリ
- 計算機資源
- オペレータ
- トレーナー
廃棄
プロセス
- 設備
- 機器/ツール
- 工程
- 人員
Copyright©2015 Hidekazu Nishimura.
システムズエンジニアリングとは?
システムを成功裏に実現するための複数の分野にまたがる
アプローチおよび手段
コミュニケーションの重要性
ISO 15288:2015 システムライフサイクルステージ
10
Copyright©2015 Hidekazu Nishimura.
システムズエンジニアリングとは?



システムズエンジニアリングの定義
 システムを成功裏に実現するための複数の分野にまたが
るアプローチおよび手段
システムズエンジニアリングでは、開発の初期段階で顧客の
ニーズを明確化し、機能要求を定義し、関連する問題をすべ
て考慮しながら設計のための総合とシステムの妥当性確認
を進める。
システムズエンジニアリングは、ユーザーニーズに合致した
品質の製品を供給することを目的とし、ビジネスとすべての
顧客の技術的要求を考慮する。

INCOSE: International Council on Systems Engineering
11
Copyright©2015 Hidekazu Nishimura.
ISO 15288:2015 システムライフサイクルプロセス

合意プロセス
・取得プロセス
・供給プロセス

組織的プロジェクト実現
プロセス
・ライフサイクルモデル
マネジメントプロセス
・基盤マネジメントプロセ
ス
・ポートフォリオマネジメ
ントプロセス
・人的リソースマネジメ
ントプロセス
・品質マネジメントプロセ
ス
・知識マネジメントプロセ
ス

技術マネジメントプロセ
ス
・プロジェクト計画プロセス
・プロジェクト評価・統制
プロセス
・意思決定マネジメント
プロセス
・リスクマネジメントプロセ
ス
・構成管理プロセス
・情報マネジメントプロセス
・測定プロセス
・品質保証プロセス
12

技術プロセス
・ビジネス解析,ミッション解
析プロセス
・利害関係者要求定義プロセ
ス
・システム要求分析プロセス
・アーキテクチャ設計プロセス
・設計定義プロセス
・システム解析プロセス
・実装プロセス
・統合プロセス
・検証プロセス
・移行プロセス
・妥当性確認プロセス
・運用プロセス
・保守プロセス
・廃棄プロセス
Copyright©2015 Hidekazu Nishimura.
システム解析プロセス (ISO 15288:2015)

目的


成果






ライフサイクル全般にわたり意志決定を補助する技術的な理解に向け
てのデータと情報に関する厳格な基礎を提供する。
必要なシステム解析の特定
システム解析の仮定と結果の妥当性確認
決定のためのシステム解析結果の供給
システム解析を実現するために必要なシステムまたはサービス
システム解析結果のトレーサビリティの確立
準備





システム解析を必要とする問題の特定/利害関係者の特定
システム解析のスコープ,目的,忠実度の定義
解析に必要なデータと入力の収集
 手法の選定/戦略の定義
システム解析の実現に必要なシステムまたはサービスの特定と計画
システム解析の実現に必要なシステムまたはサービスへのアクセス
13
Copyright©2015 Hidekazu Nishimura.
モデル vs シミュレーション (SEH 4th Ed.)

“モデル”と“シミュレーション”には、それぞれに意味が
あるにもかかわらず、間違って受け取られることがある。

モデル=対象とするシステム、エンティティ、現象、プロ
セスの抽象または表現(観点:形状、機能、性能)

シミュレーション=時間に沿ってモデルを実行する特定
の環境へのモデルの実装。一般には、システム、ソフト
ウェア、ハードウェア、人、物理現象の複雑な動的振る
舞いを解析する手段を提供する。
SEH: Systems Engineering Handbook
14
Copyright©2015 Hidekazu Nishimura.
モデリングの目的(1) (SEH 4th Ed.)

実在するシステムの特徴づけ:文書で書かれた実在システム
のモデリングでそのアーキテクチャと設計を把握する。

ミッションおよびシステムコンセプトの定式化と評価:システム
ライフサイクル初期の段階で、モデルによりミッションおよび
システムコンセプト候補を総合(synthesis)し評価(evaluate)す
る。システム設計のモデリングと重要なシステムパラメータの
影響評価からトレードオフ解析の解空間を探索する。

システムアーキテクチャとシステム要求のフローダウン:モデ
ルを用いてシステム解のアーキテクティングを支援し、ミッショ
ンとシステム要求(機能要求、インタフェース要求、性能要求
、物理要求の他、信頼性、保守性、安全性、セキュリティなど
のいわゆる非機能要求)をシステム要素に割り当てる。
15
Copyright©2015 Hidekazu Nishimura.
モデリングの目的(2) (SEH 4th Ed.)

システム統合と検証の支援:システムへのハードウェア、ソフ
トウェアの統合の支援とシステムが要求を充足することの検
証の支援にモデルを用いる。Hardware-in-the-loop テスト、
Software-in-the-loop テスト。モデルは、テスト計画と実行を支
援するためテストケースやテストプログラムの他の観点を定
義する。

トレーニングの支援:システムと相互作用するユーザー(オペ
レータ、保守員、その他)を訓練するシステムの様々な観点を
模擬する。

知識の獲得とシステム設計の進展:システムに関する知識の
獲得と組織の知識としての維持のための効果的な手段をモ
デルは提供する。
16
Copyright©2015 Hidekazu Nishimura.
システムライフサイクルプロセス中の
シミュレーションモデルとシステムモデル

ビ ジネス 解析 とミッション 解 析 :解決すべき状況を表す 記述モデル (
Descriptive model)は、正しい問題に対処していることを保証する。

利害関係者要求定義とシステム要求定義:要求を正当なものとし、適切
な要求の特定を行う。

アーキテクチャ定義:選択基準をもとに候補となっている選択肢を評価し、
他のシステムとの統合など、ベストのアーキテクチャを見いだす。

設計定義:必要な設計データを取得し、最適化のためのパラメータを調整
し、システム要素に対する実際のデータが得られるよう忠実にモデルを更
新する。

検証と妥当性検証:システム環境をシミュレートして検証および妥当性確
認データを評価し、(シミュレーションは、直接観察できない重要なパラメ
ータの計算のための入力として観測可能なデータを用いる)、シミュレーシ
ョンの忠実度の妥当性を確認する。

運用:実際の動作を反映し、計画、検証、オペレータの訓練のための実行
の前に動作を模擬する。
SEH 4th Ed.
17
Copyright©2015 Hidekazu Nishimura.
システムを構築するプロセス(簡易版)
システム
アーキテクチャ
利害関係者
ニーズ
システム要求
システム統合 システム
とテスト
解決策
システム設計
と仕様
コンポーネント
要求
検証済み
コンポーネント
コンポーネント
設計の 設計,実装,テスト
フィードバック
統合とテストからのフィードバック
18
Copyright©2015 Hidekazu Nishimura.
システムズエンジニアリングプロセスの概要
システムズエンジニアリングを構成する4つのアクティビティ
1. システム設計
– 要求分析、アーキテクチャ設計を実施し、サブシステ
ム(システム要素)への要求を導出する.
2. インテグレーション(統合)
– 検証済みのサブシステムを統合する.
3. 評価・解析
– エンジニアリング活動における解析および検証
(verification)・妥当性確認(validation)等を実施する.
4. システムズエンジニアリングマネジメント
– QCDを満たすように、各種活動の計画・実施・評価を
行う.
19
Copyright©2015 Hidekazu Nishimura.
左側の「要求の分析」から「設計の検証」に至る流れが、一方的に進むのではなく、
右側の「システム解析」の中でトレードオフ分析と評価をそれぞれのステップで行い、
IEEE 1220 systems engineering process
繰り返しが存在することに注意されたい。
SEプロセスへの入力
要求と制約の矛盾
要求の分析
要求のトレードオフ
と影響
要求の基準
要求の
妥当性確認
確認された要求の基準
分解と要求の割り当に
関する候補
機能の分析
分解割り当ての
トレードオフと影響
機能アーキテクチャ
機能の検証
検証済み機能アーキテクチャ
総合
システム解析
機能の
トレード分析
と評価
設計解の要求と候補
設計解の
トレードオフと影響
物理アーキテクチャ
要求の
トレード分析
と評価
設計の検証
設計の
トレード分析
と評価
検証済み物理アーキテクチャ
統制
SEプロセスの出力
20
Copyright©2015 Hidekazu Nishimura.
システムアーキテクチャ
システムズエンジニアリングプロセスでは、対象とするシステム
(system of interest)に関してライフサイクル全体を見渡した上で
、要求分析を行い、そしてそのアーキテクチャを構築することが
極めて重要となる。システムアーキテクチャの決定には,さまざ
まな観点(View,例えば,安全性,信頼性,可用性,保守性)か
らの検討が必要になる.
アーキテクチャの定義:ISO/IEC/IEEE 42010

「アーキテクチャは,システム要素とその関係性の中で具体
化された,ある環境中のシステムの基本概念または特性であ
り,またシステムを設計し進化させるその原則である.」
21
Copyright©2015 Hidekazu Nishimura.
exhibits
1
1
1
identifies
expresses
has interests in
1
1..*
identifies
Stakeholder
対象とするシステムは
Academic Version
アーキテクチャを明示する。
Commercial Devel
Architecture
1
ビューポイントは
関心事をフレームする。
利害関係者は 利害関係者は
関心事を持つ。 SoIに興味を持つ。
System of Interest
1
Architecture
Discription
1
アーキテクチャ記述は
対象システム、利害関
係者、関心事を特定す
る。
1..*
1
1..*
1..*
Architecture
Rationale
has
identifies
1..*
Concern
1..*
0..*
1..*
0..*
Correspomdemce
Rule
Correspondence
1..*
addresses
frames
1..*
1..*
1..*
Architecture
Viewpoint
1..*
Architecture
View
1
governs
1
ビューポイントがビューを支配する
1..*
Model Kind
1..*
1
1..*
governs
22
Architecture
Model
ビューを設定することが
Academic Version for Teachin
アーキテクチャに重要で
Commercial Development is s
ある。
このビューが利害関係
者の持つ関心事に対処
する。
ISO/IEC/IEEE 42010
Copyright©2015 Hidekazu Nishimura.
二元V字開発モデル (Dual Vee Model)
要求を満足する
システムの完成
Architecture Vee
利害関係者
の要求
Entity Vee
Entity Veeのそれぞ
れのステップで,サブ
システムやコンポー
ネントのインテグレー
ションが繰り返される.
23
Copyright©2015 Hidekazu Nishimura.
エンティティV (Entity Vee)
顧客による確認
概念設計,アーキテ
クチャの選定,設計
に向けた仕様
見込み調査,
リスク調査
製作,コード
化に向けた
仕様
顧客による確認
検証と妥当性確認の計画
顧客による確認
Entity要求の定義
妥当性確認
検証の計画
購入,製作,
コード化
解決策の達成
24
妥当性確認の計画
検証
検査,テスト,
実証,分析
検証
検査,テスト,
実証,分析
不具合調査
利害関係者の要求
Copyright©2015 Hidekazu Nishimura.
二元V字モデルによるプロセスの理解
要求を満足する
システムの完成
Architecture Vee
利害関係者
の要求
早い段階での
手戻り
Entity Vee
アーキテクチャの検討,
決定では,サブシステ
ムやコンポーネントの
実現可能性を検討しな
がら進めることがある.
25
Copyright©2015 Hidekazu Nishimura.
二元V字モデルによるプロセスの理解
要求を満足する
システムの完成
Architecture Vee
利害関係者
の要求
致命的な
手戻り
Entity Vee
コンポーネント,
サブシステムの
検証,妥当性確認
を順序行い,システム
としての検証,妥当性
確認を行って行く.
26
Copyright©2015 Hidekazu Nishimura.
どの部署がどこと連携して
いつ、何を用いて、何をするのか?
エンジンシステムアーキテクチャ
エンジンシステム検証:
Hardware-in-theloop simulation
(エンジンベンチ)
制御系検証:
Hardware-in-theloop simulation
制御系設計:
Model-in-theloop simulation
ソフトウェア検証:
Software-in-theloop simulation
ソフトウェア設計:
Software-in-theloop simulation
27
Copyright©2015 Hidekazu Nishimura.
コミュニケーションの失敗
?
このシステムは、●●
と××から構成され、
△△の運用を考えた
ときに、、、
28
Copyright©2015 Hidekazu Nishimura.
図を用いたコミュニケーション
このシステムは、●●
と××から構成され、
△△の運用を考えた
ときに、、、
29
Copyright©2015 Hidekazu Nishimura.
“モデルベースでシステムを考える”とは?

モデル*に基づくシステム開発




仕様書など文書だけではすぐに理解できないことが、図的
に表現することで理解が容易になる。
協働してシステム開発をするには、共通言語が必要であり、
それをサポートするには図的な言語が有効である。
モデルを再利用することにより開発の効率化が期待できる。
モデルを用いて抽象度を上げる → 問題点を明らかにす
る → 改善点や新たに取り組むべきことを理解する
*注:実行可能ではないモデルを含む.
もちろん,実行可能なモデルも含む.
30
Copyright©2015 Hidekazu Nishimura.
複雑なシステムの開発をいかに
マネジメントするか?
自動
変速
複数の機能がサブシステム間に
またがっている複雑システム:
トレーサビリティを確保した上で、
QCDを守って開発を進めたい。
Traction
control
クラスタ
CAN
速度表示
ABS
エンジン
T/M
ACC
コンテキスト を明確にし、機能性
を把握した上で、要求される機
能を実現する システムアーキテ
クチャを構築する。
サブシステム(構成要素)




要求される機能を分解=機能アーキテクチャ
分解された機能を構成要素に割り当てる=物理アーキテクチャ
アーキテクチャの選定には、Viewの設定が重要となる。
システム解析による検証:トレードオフ分析と評価
31
Copyright©2015 Hidekazu Nishimura.
システム境界の定義
(コンテキストレベル)



対象とするシステム:自動車
外部システム:ドライバー,ガスポンプ(燃料供給),道路
など.他にもさまざまな利害関係者が関係する.
要求:自動車はドライバーの運転により,道路上を移動
して,ある地点から目的の場所へ人や物を運ぶことがで
きる.=ユーザーに提供したい価値
自動車
ドライバー
ガソリンスタンド
道路
32
Copyright©2015 Hidekazu Nishimura.
システムの機能要求




自動車の機能の1つ:「加速する」
機能「加速する」を入出力の関係で記述する.
自動車はドライバーの加速指令を受けて,「加速する」と
いう機能を持つ.
ドライバーに対して,自動車は「速度を提示する」という
機能を持つ.
速度表示
加速指令入力
速度を
提示する
加速する
33
速度
駆動力
Copyright©2015 Hidekazu Nishimura.
システムの性能要求

機能の評価:「加速する」の評価
ドライバーからの指令に対して,どれだけ加速することが
要求されているのか?
自動車の速度 [km / h]

×
100
50
O
2
4
6
時間 [秒]
34
8
Copyright©2015 Hidekazu Nishimura.
機能の分析(Analysis)と設計の総合(Synthesis)

システムの機能を分析する.<振る舞い図>
加速指令
加速
指令

回転力を
発生する
加速する
発生した
回転力を
調整する
加速力の発生
調整した力
をタイヤに
分配する
タイヤが
回転する
加速力
の発生
機能を物理へ割り当てると,,,(Allocation)
インタフェースの明確化
35
Copyright©2015 Hidekazu Nishimura.
システムの構造の明確化



自動車はタイヤ,エンジン,トランスミッション,デフなど
のコンポーネントから構成される.
コンポーネント間のインタフェースを明確にする.
構造図としては,,,
36
Copyright©2015 Hidekazu Nishimura.
システムモデルで明確にすること

ライフサイクルステージ
コンセプト⇒開発⇒製造⇒運用と保守⇒廃棄
それぞれについて検討する必要がある.さもなければ,システムは
実現しない.

それぞれのステージについてコンテキスト(文脈,脈略)を最初に考
え,抜け漏れがないことを確認する.その際,利害関係者の要求
や懸念事項をすべて洗い出す.その上で,対象システムの境界 ,
ユースケース,機能性を明確にする.

次に対象システムの内部を分析し,総合する.最初に機能を分解
して,その分解された機能をシステム構成要素に割り当てる .これ
により,システム構成要素間のインタフェース が定義され,アーキ
テクチャの候補が導出できる.
要求や懸念事項に応じてView(観点)を設定し,トレードオフ分析に
よりいくつかの候補の中から適切なアーキテクチャを選定する.

37
Copyright©2015 Hidekazu Nishimura.
MBSEのモチベーション
QCDを守りたい。
トレーサビリティを確保
したい。
Better productのために
Better engineeringを実現したい!
そのために
Systems Engineering
┃
ことで効果的、効率的にしたい
そのために
Model Based Systems Engineering
ドキュメントベースで
複雑なシステムを
システムズエンジニアリングをモデルに基づく
扱うのは辛い!
モデルベースで行うシステムズエンジニアリングを
活動範囲が社
国際的に認められた共通言語で行いたい
内だけに限定
されていない。
そのために
┃
SysMLによるMBSE
決してSysMLやMBSEがモチベーションの源泉や目的ではない
38
Copyright©2015 Hidekazu Nishimura.
MBSE=Systems Engineering

あくまでもSystems Engineeringである。
システムモデルに基づいてSystems Engineeringを行う。

Systems Engineeringの無いMBSEはあり得ない。

Systems Engineeringには大きく4つの活動がある。





システム設計
システムの解析と検証
システムの統合
システムズエンジニアリングのマネジメント
注:MBD(モデルベース開発)はMBSEの一部分である。
システムモデル=シミュレーションモデル
39
Copyright©2015 Hidekazu Nishimura.
SysMLダイアグラムの分類
SysML: Systems Modeling Language
パッケージ図
要求図
SysML
ダイアグラム
振る舞い図
パラメトリック図
構造図
40
ユースケース図
シーケンス図
アクティビティ図
状態機械図
ブロック定義図
内部ブロック図
Copyright©2015 Hidekazu Nishimura.
システムモデルを
SysMLダイアグラムで表現する(例)
モデル編成の定義
パッ
ケー
ジ図
要
求
図
pkg
req
パラメ
トリッ
ク図
振る舞い図
act
seq
stm
uc
par
SoIのユースケー
スシナリオ
ibd
✔
✔
✔
✔
✔
✔
✔
機能および物理
アーキテクチャ
✔
システムの分析
✔
システムの検証
bdd
✔
SoIと外部システム
の関係
SoIに対する要求
構造図
✔
✔
✔
✔
✔
✔
41
Copyright©2015 Hidekazu Nishimura.
コンカレントデザインを促進するフレームワーク
システムモデル
トレーサビリティ
根拠
外部からの
要求
解析
振る舞い
構造
ダイナミクス
解析
ビュー
ポイント
システム
仕様書
解析モデル
性能
評価
要求
パラメトリック制約
制御システム
解析
1D-CAEなど
製品データ管理
(PDM)
・部品表(BOM)
・物理設計(CAD)
ハードウェア
設計モデル
電気回路
設計モデル
42
ソフトウェア
設計モデル
テスト方法
テストモデル
Copyright©2015 Hidekazu Nishimura.
システムモデルは組織に何をもたらすか?

システムとして考えることで得られる気付き
 「システム」の重要性、ライフサイクルステージの考慮
 「システムアーキテクチャ」を持つことの必要性
 「システムアーキテクチャ」を検討することでシステム全体と
してのトレードオフ検討、最適化を行えること
 構成要素への明確な要求の規定、インタフェースの定義
 要求のトレーサビリティの確保
 要求および設計変更への対応
 システム設計の検証

QCDを守って、システムを構築するプロセスを明確にする。
43
Copyright©2015 Hidekazu Nishimura.
MBSEの適用事例

自動車のパワーバックドアシステム開発のための
モデルベースシステムズエンジニアリングの適用

MBSE に基づきSysML(Systems ModelingLanguage)を利用して
パワーバックドアシステムのシステムモデルを記述しアーキ
テクチャを構築するまでのプロセスを示す。

部分として考えるのではなく、システムとして考えることによる
技術者の気づきや明らかになった点を示す。
44
Copyright©2015 Hidekazu Nishimura.
MBSEの適用で得られた気付きと
明確になったこと

要求のトレーサビリティ


コンテキスト分析におけるシーケンス図による効果


エンジニアが要求やビューを把握し、トレースを確保できる。
要求から導かれる機能を明確にすることができる。
機能の割り当て



構成要素間の関係性が明らかとなり、コンポーネント担当エン
ジニア間のコミュニケーションが円滑になる。
従来の”部品ありき”の設計スタイルでは、見いだすことので
きなった組織の枠にとらわれない、対象とするシステム全体と
しての最適化の検討が行える。
意図しない手戻りを減らすことでQCDを守ることが可能。
45
Copyright©2015 Hidekazu Nishimura.
(1)要求のトレーサビリティ



全てのシステムモデルおよび情報は要求図に示されて
いる元来の要求に遡ることができるため、エンジニアは
システムのすべてのビューを把握することができる。
要求に関連するシステムモデルはSysML ツールに保存
されているため、例えば、ECU を追加して新たな機能を
実現する追加開発の際には、要求およびコンポーネント
間の関係性を要求図で追いながら検討できる。
要求のトレーサビリティを確保しておくことは非常に重要
である。
46
Copyright©2015 Hidekazu Nishimura.
(2)コンテキスト分析の効果1



コンテキスト分析で、絵を描き、またシーケンス図を用い
た検討を行うことにより、LED 光には地面からの反射が
あることに気づいた。ユーザーへの「おもてなし」あるい
はLED としての機能が、地面の状態に依存することを見
いだせた。
バックドアの開閉の動作をイメージすることにより、I-key
の検出を行うためのアンテナの配置に関する検討の見
逃しを防ぐことができた。
バックドアが閉まっているときと、開いているときでは、電
波環境が異なるので、I-key位置検出のチューニングをバ
ックドア開閉状態それぞれで実施する必要があるという
気付きも得ている。
47
Copyright©2015 Hidekazu Nishimura.
(2)コンテキスト分析の効果2



Vehicle2013 が持つべき機能と新たに追加するOSBDS
が持つべき機能を明確にすることができた。
移動検出器とVehicle2013への機能の割り当てやそれら
の統合の可能性、およびBD2013 CU とSonar CU の統
合の可能性をそれぞれ示唆することができた。
SysMLを用いたシステムモデルの記述により、従来の”部
品ありき”の設計スタイルでは、見いだすことのできなっ
た組織の枠にとらわれない、対象とするシステム全体と
しての最適化の検討が行えたことは大きなメリットとして
認識された。
48
Copyright©2015 Hidekazu Nishimura.
(3)機能の割り当て1



アクティビティ図は、機能がどのようにシステムコンポー
ネントに割り当てられているかを示すことができ、これは
システムに関与するシステムズエンジニアだけではなく、
コンポーネントの設計者にとっても、設計するコンポーネ
ントがシステムの中でどのように機能するのかを知るこ
とができるため、有用である。
技術者が良く活用するステートマシン図や状態遷移表と
合わせて検討することによって、コンポーネントの機能に
漏れがないかを検討することができる。
機能のコンポーネントへの割り当てやコンポーネント間
の統合をシステムとして俯瞰して見ることができるように
なる。⇒最適化の検討が行えるようになる。⇒次頁へ
49
Copyright©2015 Hidekazu Nishimura.
(3)機能の割り当て2



コンポーネントに依存する形で分割された組織では、機
能の割り当てやコンポーネント間の統合を検討する際に
、技術者自身の 組織内のコンポーネント のみに影響が
留まり、自身が属する 組織外のコンポーネント に対して
影響が出ないように設計をしがちである。
そうした思考の枠にとらわれずに全体を俯瞰することで
、実プロジェクトにおけるQCDの最適化が図れる可能性
がある。
こうした検討がシステム開発の早い段階で行えることは
、試作やプロトタイプを減らすことができ、意図しない手
戻りの減少に大いに効果があるものと期待される。
50
Copyright©2015 Hidekazu Nishimura.
システムズエンジニアリングの導入に向けて
成果物の形式および質の向上

エンジニア個人のスキルに依存

文書として残すべき成果物と関連するシステムモデルを明
確に区別できることの優位性
問題と課題



MBSEとSysMLの導入⇒乗り越えるべき壁がいくつかある。
システムズエンジニアリング活動を行う組織が存在しない。
システムズエンジニアリング活動を行うために組織を編成し、
SysMLを導入するためのコスト、エンジニアをトレーニングする
ためのコストなどの負担への対処は大きな課題となる。また、
追加開発も含んだエンジニアリングプロセスの中での活用方
法を検討しなければならない。
51
Copyright©2015 Hidekazu Nishimura.
E/Eアーキテクチャの課題




ECU(Electronic Control Unit)搭載数:50~100個/台
複数のECU をネットワークで構成するE/E アーキテクチャ
新たな機能の追加要求
⇒ ECU の増加、E/E アーキテクチャの複雑化
追加開発
⇒意図しない手戻り、業務上の効率低下

既存システムのどこを活かし、何を追加し、改良すれば良い
かを明確にしたい。 ⇒ システムズエンジニアリングの活用

他のサブシステムやコンポーネントとどのような関係性をもつ
のかを担当技術者にわかるようにする。
52
Copyright©2015 Hidekazu Nishimura.
As-Is分析
非接触パワーバックドアシステム(CPBDS)
Vehicle 2013
Contactless sensor
detecting
open request
open
Sensor CU
BCM
unlock M
BD CU
M
Cancel SW
I-key
53
Copyright©2015 Hidekazu Nishimura.
ワンステップ・バックドアシステム
(OSBDS)の検討

ユーザーニーズ(新たな要求の追加)


“ユーザーフレンドリー(操作性の良さ)”
“おもてなし”
B
操作可能エリア
LED 点灯エリア
54
A
受信可能エリア
Copyright©2015 Hidekazu Nishimura.
ユースケース図
uc[Packag
[Package]
Usecase
case
OSBDS] ]
uc
e] [ [Use
ofof
OSBDS
«useCaseModel»
«useCaseM
odel»
One-Step
Back
Door
System
(OSBDS)
One-Step
Back
D oor
System
(OSBDS)
AcademicVersion
Versi
Academic
CommercialDeve
De
Commercial
ユーザーが手を使わず
ęü¶üLK’
¸Z
にバックドアを開く
kŠĆÆÉ¢’‹
O
ęü¶ü’
Y‹
ユーザーを誘導する
Vehicle
Vehicle
2013
2013
ęü¶ü
ユーザー
ęü¶üLK’
¸Zk
ユーザーが手を使わずに
ŠĆÆÉ¢
’‰
‹
バックドアを閉める
0b
地面
55
Copyright©2015 Hidekazu Nishimura.
LEDの点灯/消灯
[]
ユースケース「バックドアを開く」
を記述したシーケンス図(コンテキスト)
センサーのOn/Off
Academic Version for Teaching Only
Commercial Development is strictly Prohibited
LEDの光の反射
LEDの光の認知
sd [Interaction] ŠĆÆÉ¢’‹O
«block»
: I-key’
:/Y‹ęü¶ü
: 0b
par
[]
Academic Version for Teaching Only
Commercial Development is strictly Prohibited
: OSBDS
loop
[]
I-keyの受信可能エリア内での移動検出
«block»
: Vehicle
2013
Academic Version for Teaching Only
Commercial Development is strictly Prohibited
LEDの点滅開始/停止
車両への接近
LEDの点滅の光の反射
Academic Version for Teaching Only
Commercial Development is strictly Prohibited
[]
LEDの点滅の光の認知
I-keyの探索
Academic Version for Teaching Only
Commercial Development is strictly Prohibited
g Only
rictly Prohibited
LED点滅部へ足を踏み出す
I-keyの検出
ユーザーが差し出した足の検出
探索モードの判断
ユーザーが差し出した足の検出信号の送信
alt
[ [] ユーザーが差し出す足が検出される前 ]
Academic Version for Teaching Only
Commercial Development is strictly Prohibited
Academic Version for Teaching Only
Commercial Development is strictly Prohibited
par
[]
[ ユーザーが差し出す足が検出される後 ]
[else]
LEDの点灯/消灯
バックドアの開閉の判断
センサーのOn/Off
Academic Version for Teaching Only
Commercial Development is strictly Prohibited
バックドアのアンロック
LEDの光の反射
バックドアを開く
LEDの光の認知
loop
[]
I-keyの受信可能エリア内での移動検出
56
Copyright©2015 Hidekazu Nishimura.
ワンステップ・バックドアシステムの
システム構成要素を表すブロック定義図
bdd [Package] [ ワンステップ・バックドアシステムのシステム構成要素 ]
«block»
OSBDS
1
«block»
LED
1
1
«block»
I-key 移動検出器
1
«block»
非接触センサー
«block»
«block»
静電容量センサー レーザー・レーダ
57
«block»
ソナーシステム
«block»
BD2020 CU
«block»
赤外線センサー
Copyright©2015 Hidekazu Nishimura.
「I-key の受信可能エリア内での
移動検出」を表すシーケンス図
58
Copyright©2015 Hidekazu Nishimura.
「ユーザーが差し出した足の検出」
を表すシーケンス図
Only
tly Prohibited
sd [Interaction] ęü¶üLīWśW_³nś
: 0b
: I-key’
:/Y‹ęü¶ü
«block»
«block»
: ½Źü
: ½ŹüCU
超音波を送信
pa r
[ ]
Academic Version for Teaching Only
Commercial Development is strictly Prohibited
超音波を反射
反射した超音波を受信
[ ]
opt
[ [ユーザーがLED点滅部へ足を踏み出した場合
]
Academic Version for Teaching Only ]
Commercial Development is strictly Prohibited
超音波を反射
反射した超音波を受信
受信した超音波を解析
Academic Version for Teaching Only
Commercial Development is strictly Prohibited
LED点灯エリアでの足の存在を判断
59
Copyright©2015 Hidekazu Nishimura.
コンポーネント間のインタフェース
を表すブロック定義図
ソナー
インタフェース
ソナーCU インタフェース1○
operations
○
operations
+LED点灯エリアでの足の存在を判断()
+ソナーをOn/Off()
+反射した超音波を受信()
ソナーCU インタフェース2○
operations
+超音波を送信()
+ソナーを終了()
ソナーCU インタフェース3○
operations
+BD2020 CUから,高頻度探索モードへの切り替えコマンドを受信()
+BD2020 CUから,低頻度探索モードへの切り替えコマンドを受信()
+受信した超音波を解析()
LED インタフェース○
operations
BD2020 CU インタフェース1○
+LED終了()
+LEDの点灯を起動()
+LEDの点滅を起動/終了()
operations
+ユーザーが差し出した足の検出信号の送信()
BD2020 CU インタフェース2○
operations
+移動検出器から,高頻度探索モードへの切り替えコマンドを受信()
+移動検出器から,低頻度探索モードへの切り替えコマンドを受信()
+LEDの点滅開始/停止,LEDの点灯/消灯()
I-key 移動検出器 インタフェース 1○
operations
+探索モードの判断()
+受信可能エリア内でI-keyの距離情報を受信()
BD2020 CU インタフェース2○
operations
+LED点灯エリアからのI-keyの位置を算出()
+操作可能エリア内のI-keyの位置を判断し,その位置情報のVehicle2013への送信()
60
Copyright©2015 Hidekazu Nishimura.
アクティビティ図による
物理アーキテクチャの総合
act [Activity] [ アクティビティ図による物理アーキテクチャの総合 ]
«allocate»
«allocate»
Vehicle
2013
OSBDS
«allocate»
«allocate»
«allocate»
«allocate»
I-key 移動検出器
BD2020 CU
ソナーCU
ソナー
LED
LEDの消灯
[I-keyなし]
時間カウント
5秒
[高頻度
モード]
[低頻度
モード]
[高頻度
モード]
[ 高頻度モードで1分経過
かつI-keyなし5秒継続]
低頻度探索
モードへ移行
探索モードの判断
操作可能エリア内での
I-key情報を受信
バックドアのロック
バックドアを開く
バックドアの
アンロック
移動検出器から,
高頻度探索モード
への切り替え
コマンドを受信
BD2020 CUから,
高頻度探索モード
への切り替え
コマンドを受信
ソナーを終了
超音波を反射
超音波を送信
探索頻度
時間調整
ソナーをOn
LEDの点灯
LEDの点灯
を起動
LEDの点滅開始
LEDの点滅
を起動
操作可能エリア内の
I-keyの位置を判断し,
その位置情報のVehicl
e2013への送信
LEDの光
を反射
LEDの点滅
を終了
[操作可能なエリアの内で
I-keyが検出される場合]
[操作可能なエリアの外で
I-keyが検出される場合]
バックドア
を閉める
BD2020 CUから,
低頻度探索モード
への切り替え
コマンドを受信
受信可能エリア
内でI-keyの距
離情報を受信
LED点灯エリアからの
I-keyの位置を算出
受信可能エリア内で
I-keyの距離を送信
移動検出器から,
低頻度探索モード
への切り替え
コマンドを受信
[低頻度
モード]
[高頻度モードで1分未満
またはI-keyなし5秒未満]
時間カウント
1分
LED終了
ソナーをOff
時間カウント
1分
高頻度探索
モードへ移行
地面
«allocate»
I-keyを探索する
[I-keyあり]
«allocate»
LEDの点滅停止
受信した超音波
を解析
反射した超
音波を受信
ユーザーが差し出
した足の検出信号
の送信
LED点灯エリアでの
足の存在を判断
バックドアの開閉の判断
I-keyを持つユーザーの足
61
Copyright©2015 Hidekazu Nishimura.
低頻度探索モードと高頻度探索モード間
の遷移を表す状態機械図
stm
[State Machine] [ 低頻度探索モードと高頻度探索モード間の遷移]
[低頻度探索モード状態で
I-keyが検出されない場合]
低頻度探索モード
To Do = "I-keyを探索する()
I-keyを探索する()
探索頻度時間調整()
探索頻度時間調整()
LEDの消灯/終了()
LEDの消灯/終了()
ソナーOff/終了()"
ソナーOff/終了()
[低頻度探索モードで
I-keyが検出される場合]
[高頻度モードで1分経過
かつI-Keyなし5秒継続 ]
高頻度探索モード
To Do = "I-keyを探索する()
I-keyを探索する()
探索頻度時間調整()
探索頻度時間調整()
LEDの点滅開始/起動/停止()
LEDの点滅開始/起動/停止()
LEDの点灯/起動()
LEDの点灯/起動()
ソナーをOn()
ソナーをOn()
受信可能エリア内でI-keyの距離情報を受信()
受信可能エリア内でI-keyの距離情報を受信()
LED点灯エリアからのI-keyの位置を算出()
LED点灯エリアからのI-keyの位置を算出()
操作可能エリア内のI-keyの位置を判断し,その位置情報
操作可能エリア内のI-keyの位置を判断し,その位置情報の
のVehicle2013への送信()
Vehicle2013への送信()
操作可能エリア内でのI-key情報を受信()
操作可能エリア内でのI-key情報を受信()
ユーザーが差し出した足の検出信号の送信()
ユーザーが差し出した足の検出信号の送信()
反射した超音波を受信()
反射した超音波を受信()
受信した超音波を解析()
受信した超音波を解析()
LED点灯エリアでの足の存在を判断()"
LED点灯エリアでの足の存在を判断()
[高頻度モードで1分未満
またはI-Keyなし5秒未満]
62
Copyright©2015 Hidekazu Nishimura.
要求図によるトレーサビリティの確保
ユーザーに対して、自動車が
ユーザ ーを歓迎する際、また
は、ユーザーのために何かを
準備する際に、おもてなしを感
じさせること
«derivedReqt»
«derivedReqt»
«derivedReqt»
«derivedReqt»
«derivedReqt»
«derivedReqt»
«derivedReqt»
«derivedReqt»
«derivedReqt»
«derivedReqt»
«derivedReqt»
«performanceRequirement»
«derivedReqt»
«satisfy»
«satisfy»
«satisfy»
«allocate»
«satisfy»
«satisfy»
«satisfy»
«satisfy»
«allocate»
«derivedReqt»
«allocate»
«allocate»
«allocate»
«allocate»
«satisfy»
«satisfy»
63
«allocate»
«satisfy»
Copyright©2015 Hidekazu Nishimura.
システムライフサイクルのマネジメント
プロジェクト
マネジメント
ここを繋ぐ
仕組みが
大変重要
になって
いる。
CAD
要求
システムアーキ
テクチャと同義
システム
最適化
モデル
シミュレー
ション/CAE
ライブラリ/
生産/サプライ
チェーン
データベース
PLM (Product Lifecycle Management), SCM (Supply Chain Management)
64
Copyright©2015 Hidekazu Nishimura.
まとめ

システムズエンジニアリングの標準をもとに基本的な考え方を
紹介し、欧米で幅広い産業に採用されているモデルに基づくシ
ステムズエンジニアリング(MBSE)の重要性を述べた。

開発のステージに焦点を絞り、システムズエンジニアリングプ
ロセスの概略の流れを示すとともに、システムアーキテクチャ
を構築するまでにシステムモデルを記述することの有効性を述
べた。

システムモデルを構造/振る舞い/要求/パラメトリック制約
の4つの柱で記述することができるSysMLの適用事例を紹介し
た。また、自動車のパワーバックドアシステムへの適用を試み
た企業担当者からの評価を示した。
65
Copyright©2015 Hidekazu Nishimura.
参考文献

Systems Engineering Handbook 4th Edition, INCOSE, 2015

Visualizing Project Management, Third Edition

Kevin Forsberg, Hal Mooz, Howard Cotterman, John Wiley & Sons, Inc.

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, First edition, 2011-12-01

システムズモデリング言語 SysML(A Practical Guide to SysMLの翻訳本)

西村 秀和(監訳),白坂成功,成川輝真,長谷川堯一,中島裕生,翁志強(翻訳),東京
電機大学出版局,2012

モデルベースシステムズエンジニアリング導入の手引き,情報処理推進機構,
https://www.ipa.go.jp/files/000033609.pdf

15-A-14 自動車のパワーバックドアシステム開発のためのモデルベースシステムズエンジ
ニアリングの適用,「先進的な設計・検証技術の適用事例報告書 2015年度版」,情報処理
推進機構,西村秀和,中本貴之,宮下真 http://www.ipa.gp.jp/sec/reports/20151118.html

モデルに基づくシステムズエンジニアリング,西村秀和(総監修),藤倉俊幸(企画・監修),
日経BP,2015
66
Copyright©2015 Hidekazu Nishimura.