モデルベースシステムズエンジニアリング - ipa...2015/11/26 ·...

Copyright©2015 Hidekazu Nishimura.

モデルベースシステムズエンジニアリング～システムモデルは何に活用できるか？

本当の話をしよう！～

慶應義塾大学教授 IPA/SEC 連携委員西村秀和

http: lab.sdm.keio.ac.jp/nismlab/

SEC高信頼化技術セミナーモデルベースシステムズエンジニアリング（MBSE）入門

～導入のポイントと適用事例の紹介～2015年11月26日


本日のお話の内容

システムズエンジニアリングの欧米での広がり

モデルに基づくシステムズエンジニアリング（MBSE）の重要性

開発ステージでのシステムズエンジニアリングプロセスの概略の流れ

システムアーキテクチャの重要性とシステムモデルの有効性

SysMLの適用事例と適用を試みた企業担当者からの評価

1


2014年度 MBSE調査対象（回答）国

2

INCOSE INSIGHT Vol.18, Issue.2, 2015

Copyright©2015 Hidekazu Nishimura.3

MBSEは広範囲の産業に採用されている。

INCOSE INSIGHT

Vol.18, Issue.2, 2015


MBSEの認知と採用

この3年間の変化は

極めて大きい。

4

INCOSE INSIGHT

Vol.18, Issue.2, 2015


MBSEの取り組みをどこに適用しているか？

INCOSE INSIGHT Vol.18, Issue.2, 2015


システムズエンジニアリング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

http://www.incose.org/docs/default-source/aboutse/se-vision-2025.pdf?sfvrsn=4


MBSEのモチベーション

7

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

対象システム

8


システム：製品とそれを実現するプロセス

9

System

製品

サブシステム

サブシステム

開発・テストプロセス

製造プロセス

販売・サポートプロセス

運用・トレーニングプロセス

廃棄プロセス

製品

-設備-機器-工程

-ソフトウェアアプリ

-計算機資源-人員-サプライヤ-ベンダー

-設備-機器/ツール-工程


-計算機資源-部品在庫-人員-サプライヤ-ベンダー-品質管理



-計算機資源

-スペア部品在庫

-メンテナンスサプライヤ

-ベンダー



-計算機資源-オペレータ- トレーナー

-設備-機器/ツール-工程-人員

製品階層ライフサイクルプロセス

IEEE 1220より


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

10

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

コミュニケーションの重要性

ISO 15288:2015 システムライフサイクルステージ


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

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

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

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

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

INCOSE: International Council on Systems Engineering

11


ISO 15288:2015 システムライフサイクルプロセス合意プロセス

・取得ﾌﾟﾛｾｽ

・供給ﾌﾟﾛｾｽ

組織的プロジェクト実現プロセス

・ライフサイクルモデルマネジメントﾌﾟﾛｾｽ

・基盤マネジメントﾌﾟﾛｾｽ

・ポートフォリオマネジメントﾌﾟﾛｾｽ

・人的リソースマネジメントﾌﾟﾛｾｽ

・品質マネジメントﾌﾟﾛｾｽ

・知識マネジメントﾌﾟﾛｾｽ

技術マネジメントプロセス

・プロジェクト計画ﾌﾟﾛｾｽ

・プロジェクト評価・統制

ﾌﾟﾛｾｽ

・意思決定マネジメント

ﾌﾟﾛｾｽ

・リスクマネジメントﾌﾟﾛｾｽ

・構成管理ﾌﾟﾛｾｽ

・情報マネジメントﾌﾟﾛｾｽ

・測定ﾌﾟﾛｾｽ

・品質保証ﾌﾟﾛｾｽ

12

技術プロセス

・ビジネス解析，ミッション解析ﾌﾟﾛｾｽ

・利害関係者要求定義ﾌﾟﾛｾｽ

・システム要求分析ﾌﾟﾛｾｽ

・アーキテクチャ設計ﾌﾟﾛｾｽ

・設計定義ﾌﾟﾛｾｽ

・システム解析ﾌﾟﾛｾｽ

・実装ﾌﾟﾛｾｽ

・統合ﾌﾟﾛｾｽ

・検証ﾌﾟﾛｾｽ

・移行ﾌﾟﾛｾｽ

・妥当性確認ﾌﾟﾛｾｽ

・運用ﾌﾟﾛｾｽ

・保守ﾌﾟﾛｾｽ

・廃棄ﾌﾟﾛｾｽ


システム解析プロセス (ISO 15288:2015)

目的

ライフサイクル全般にわたり意志決定を補助する技術的な理解に向けてのデータと情報に関する厳格な基礎を提供する。

成果必要なシステム解析の特定システム解析の仮定と結果の妥当性確認決定のためのシステム解析結果の供給システム解析を実現するために必要なシステムまたはサービスシステム解析結果のトレーサビリティの確立

準備システム解析を必要とする問題の特定／利害関係者の特定システム解析のスコープ，目的，忠実度の定義解析に必要なデータと入力の収集システム解析の実現に必要なシステムまたはサービスの特定と計画システム解析の実現に必要なシステムまたはサービスへのアクセス

13

手法の選定／戦略の定義


モデル vs シミュレーション (SEH 4th Ed.)

“モデル”と“シミュレーション”には、それぞれに意味があるにもかかわらず、間違って受け取られることがある。

モデル＝対象とするシステム、エンティティ、現象、プロセスの抽象または表現（観点：形状、機能、性能）

シミュレーション＝時間に沿ってモデルを実行する特定の環境へのモデルの実装。一般には、システム、ソフトウェア、ハードウェア、人、物理現象の複雑な動的振る舞いを解析する手段を提供する。

14

SEH: Systems Engineering Handbook


モデリングの目的（１） (SEH 4th Ed.)

実在するシステムの特徴づけ：文書で書かれた実在システムのモデリングでそのアーキテクチャと設計を把握する。

ミッションおよびシステムコンセプトの定式化と評価：システムライフサイクル初期の段階で、モデルによりミッションおよびシステムコンセプト候補を総合（synthesis）し評価（evaluate）す

る。システム設計のモデリングと重要なシステムパラメータの影響評価からトレードオフ解析の解空間を探索する。

システムアーキテクチャとシステム要求のフローダウン：モデルを用いてシステム解のアーキテクティングを支援し、ミッションとシステム要求（機能要求、インタフェース要求、性能要求、物理要求の他、信頼性、保守性、安全性、セキュリティなどのいわゆる非機能要求）をシステム要素に割り当てる。

15


モデリングの目的（２） (SEH 4th Ed.)

システム統合と検証の支援：システムへのハードウェア、ソフトウェアの統合の支援とシステムが要求を充足することの検証の支援にモデルを用いる。Hardware-in-the-loop テスト、Software-in-the-loop テスト。モデルは、テスト計画と実行を支

援するためテストケースやテストプログラムの他の観点を定義する。

トレーニングの支援：システムと相互作用するユーザー（オペレータ、保守員、その他）を訓練するシステムの様々な観点を模擬する。

知識の獲得とシステム設計の進展：システムに関する知識の獲得と組織の知識としての維持のための効果的な手段をモデルは提供する。

16


システムライフサイクルプロセス中のシミュレーションモデルとシステムモデル

ビジネス解析とミッション解析：解決すべき状況を表す記述モデル（Descriptive model）は、正しい問題に対処していることを保証する。

利害関係者要求定義とシステム要求定義：要求を正当なものとし、適切な要求の特定を行う。

アーキテクチャ定義：選択基準をもとに候補となっている選択肢を評価し、他のシステムとの統合など、ベストのアーキテクチャを見いだす。

設計定義：必要な設計データを取得し、最適化のためのパラメータを調整し、システム要素に対する実際のデータが得られるよう忠実にモデルを更新する。

検証と妥当性検証：システム環境をシミュレートして検証および妥当性確認データを評価し、（シミュレーションは、直接観察できない重要なパラメータの計算のための入力として観測可能なデータを用いる）、シミュレーションの忠実度の妥当性を確認する。

運用：実際の動作を反映し、計画、検証、オペレータの訓練のための実行の前に動作を模擬する。

17SEH 4th Ed.


システムを構築するプロセス（簡易版）

18

利害関係者ニーズ

システム設計と仕様

システム統合とテスト

システム解決策

システム要求

コンポーネント設計，実装，テスト

コンポーネント要求

検証済みコンポーネント

設計のフィードバック

統合とテストからのフィードバック

システムアーキテクチャ


システムズエンジニアリングプロセスの概要

システムズエンジニアリングを構成する４つのアクティビティ

1. システム設計

– 要求分析、アーキテクチャ設計を実施し、サブシステム（システム要素）への要求を導出する．

2. インテグレーション（統合）

– 検証済みのサブシステムを統合する．

3. 評価・解析

– エンジニアリング活動における解析および検証(verification)・妥当性確認(validation)等を実施する．

4. システムズエンジニアリングマネジメント

– QCDを満たすように、各種活動の計画・実施・評価を行う．

19


IEEE 1220 systems engineering process

要求と制約の矛盾

要求のトレードオフと影響

分解割り当てのトレードオフと影響

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

設計解のトレードオフと影響

設計解の要求と候補

要求の基準

確認された要求の基準

機能アーキテクチャ

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

物理アーキテクチャ

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

SEプロセスへの入力

SEプロセスの出力

統制

設計の検証

機能の検証

要求の分析

要求の妥当性確認

要求のトレード分析と評価

設計のトレード分析と評価

総合

システム解析

機能の分析機能の

トレード分析と評価

左側の「要求の分析」から「設計の検証」に至る流れが、一方的に進むのではなく、右側の「システム解析」の中でトレードオフ分析と評価をそれぞれのステップで行い、繰り返しが存在することに注意されたい。

20


システムアーキテクチャ

システムズエンジニアリングプロセスでは、対象とするシステム（system of interest）に関してライフサイクル全体を見渡した上で

、要求分析を行い、そしてそのアーキテクチャを構築することが極めて重要となる。システムアーキテクチャの決定には，さまざまな観点（View，例えば，安全性，信頼性，可用性，保守性）からの検討が必要になる．

アーキテクチャの定義：ISO/IEC/IEEE 42010

「アーキテクチャは，システム要素とその関係性の中で具体化された，ある環境中のシステムの基本概念または特性であり，またシステムを設計し進化させるその原則である．」

21


Academic Version for Teaching Only

Commercial Development is strictly Prohibited



Architecture Description42010[Model] pkg Data [ ]

Correspomdemce

Rule

System of Interest

Architecture

Discription

Correspondence

Architecture

Stakeholder

Concern

Architecture

Viewpoint

Architecture

View

Model Kind

Architecture

Model

Architecture

Rationale

1..*

governs 11

governs

1..*1

addresses

1..*

1..*

identifies

1..*

1

identifies

1..*

1

exhibits

11

identifies

1

1..*

1..*

0..*

frames

1..*

1..*

0..*

has interests in

1

1..*

expresses

1

1

has

1..*

1..*

1..* 1..*

ISO/IEC/IEEE 42010

ビューを設定することがアーキテクチャに重要である。

このビューが利害関係者の持つ関心事に対処する。

ビューポイントがビューを支配する

対象とするシステムはアーキテクチャを明示する。

アーキテクチャ記述は対象システム、利害関係者、関心事を特定する。

ビューポイントは

関心事をフレームする。

利害関係者は

SoIに興味を持つ。

利害関係者は

関心事を持つ。


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

Architecture Vee

Entity Vee

利害関係者の要求

要求を満足するシステムの完成

Entity Veeのそれぞ

れのステップで，サブシステムやコンポーネントのインテグレーションが繰り返される．

23


エンティティV (Entity Vee)


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

Entity要求の定義

概念設計，アーキテクチャの選定，設計に向けた仕様

購入，製作，コード化

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

妥当性確認

妥当性確認の計画

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

見込み調査，

リスク調査

不具合調査

解決策の達成

顧客による確認

検証と妥当性確認の計画

検証の計画



24


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

Architecture Vee

Entity Vee



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

早い段階での手戻り

25


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

Architecture Vee

Entity Vee利害関係者の要求


コンポーネント，サブシステムの検証，妥当性確認を順序行い，システムとしての検証，妥当性確認を行って行く．

致命的な手戻り

26


どの部署がどこと連携していつ、何を用いて、何をするのか？

27

制御系検証：Hardware-in-the-

loop simulation

制御系設計：Model-in-the-

loop simulation

ソフトウェア設計：Software-in-the-

loop simulation

エンジンシステム検証：Hardware-in-the-

loop simulation

（エンジンベンチ）

エンジンシステムアーキテクチャ

ソフトウェア検証：Software-in-the-

loop simulation


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

このシステムは、●●と××から構成され、△△の運用を考えたときに、、、

？

28


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

このシステムは、●●と××から構成され、△△の運用を考えたときに、、、

29


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

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

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

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

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

モデルを用いて抽象度を上げる → 問題点を明らかにする → 改善点や新たに取り組むべきことを理解する

＊注：実行可能ではないモデルを含む．もちろん，実行可能なモデルも含む．

30


複雑なシステムの開発をいかにマネジメントするか？

要求される機能を分解＝機能アーキテクチャ

分解された機能を構成要素に割り当てる＝物理アーキテクチャ

アーキテクチャの選定には、Viewの設定が重要となる。

システム解析による検証：トレードオフ分析と評価

31

T/M

エンジン

AB

S

CA

N

クラスタ

速度表示

ACC

自動変速

複数の機能がサブシステム間にまたがっている複雑システム：トレーサビリティを確保した上で、QCDを守って開発を進めたい。

サブシステム（構成要素）

Traction

control

コンテキストを明確にし、機能性を把握した上で、要求される機能を実現するシステムアーキテクチャを構築する。


システム境界の定義（コンテキストレベル）

対象とするシステム：自動車

外部システム：ドライバー，ガスポンプ（燃料供給），道路など．他にもさまざまな利害関係者が関係する．

要求：自動車はドライバーの運転により，道路上を移動して，ある地点から目的の場所へ人や物を運ぶことができる．＝ユーザーに提供したい価値

32

道路

ドライバー

自動車ガソリンスタンド


システムの機能要求

33

自動車の機能の1つ：「加速する」

機能「加速する」を入出力の関係で記述する．

自動車はドライバーの加速指令を受けて，「加速する」という機能を持つ．

ドライバーに対して，自動車は「速度を提示する」という機能を持つ．

加速指令入力加速する

駆動力

速度表示速度を提示する

速度


システムの性能要求

34

機能の評価：「加速する」の評価

ドライバーからの指令に対して，どれだけ加速することが要求されているのか？

自動車の速度

[km

/ h

] 100

50

O 2 4 6 8

時間 [秒]

×


機能の分析(Analysis)と設計の総合(Synthesis)

35

システムの機能を分析する．＜振る舞い図＞

機能を物理へ割り当てると，，，(Allocation)

加速する加速指令加速力の発生

回転力を発生する

発生した回転力を調整する

加速指令

調整した力をタイヤに分配する

加速力の発生

タイヤが回転する

インタフェースの明確化


システムの構造の明確化

36

自動車はタイヤ，エンジン，トランスミッション，デフなどのコンポーネントから構成される．

コンポーネント間のインタフェースを明確にする．

構造図としては，，，


システムモデルで明確にすること

ライフサイクルステージ

コンセプト⇒開発⇒製造⇒運用と保守⇒廃棄

それぞれについて検討する必要がある．さもなければ，システムは実現しない．

それぞれのステージについてコンテキスト（文脈，脈略）を最初に考え，抜け漏れがないことを確認する．その際，利害関係者の要求や懸念事項をすべて洗い出す．その上で，対象システムの境界，ユースケース，機能性を明確にする．

次に対象システムの内部を分析し，総合する．最初に機能を分解して，その分解された機能をシステム構成要素に割り当てる．これにより，システム構成要素間のインタフェースが定義され，アーキテクチャの候補が導出できる．

要求や懸念事項に応じてView（観点）を設定し，トレードオフ分析によりいくつかの候補の中から適切なアーキテクチャを選定する．

37


MBSEのモチベーション

Systems Engineering┃

Model Based Systems Engineering

┃SysMLによるMBSE

Better productのためにBetter engineeringを実現したい!

システムズエンジニアリングをモデルに基づくことで効果的、効率的にしたい

モデルベースで行うシステムズエンジニアリングを国際的に認められた共通言語で行いたい

そのために

そのために

そのために

決してSysMLやMBSEがモチベーションの源泉や目的ではない

ドキュメントベースで複雑なシステムを扱うのは辛い！

QCDを守りたい。

トレーサビリティを確保したい。

活動範囲が社内だけに限定されていない。

38


MBSE＝Systems Engineering

あくまでもSystems Engineeringである。

システムモデルに基づいてSystems Engineeringを行う。

Systems Engineeringの無いMBSEはあり得ない。

Systems Engineeringには大きく４つの活動がある。システム設計

システムの解析と検証

システムの統合

システムズエンジニアリングのマネジメント

注：MBD（モデルベース開発）はMBSEの一部分である。

システムモデル＝シミュレーションモデル

39


SysMLダイアグラムの分類

SysML

ダイアグラム振る舞い図

構造図

要求図ユースケース図

シーケンス図

アクティビティ図

状態機械図

ブロック定義図

内部ブロック図

SysML: Systems Modeling Language

40

パラメトリック図

パッケージ図


システムモデルをSysMLダイアグラムで表現する（例）

41

pkg req act seq stm uc par bdd ibd

SoIと外部システムの関係

SoIのユースケースシナリオ

SoIに対する要求

機能および物理アーキテクチャ

システムの分析

システムの検証

振る舞い図構造図要求図

パラメトリック図

モデル編成の定義 ✔

✔ ✔

✔✔

✔

✔ ✔ ✔ ✔

✔ ✔✔

✔✔ ✔

パッケージ図


ダイナミクス解析

制御システム解析

1D-CAEなど

ハードウェア設計モデル

電気回路設計モデル

ソフトウェア設計モデル

テスト方法テストモデル

解析モデル外部からの要求

解析

性能評価

システム仕様書

システムモデル

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

構造

要求

振る舞い

パラメトリック制約

トレーサビリティ根拠

ビューポイント

製品データ管理（PDM）

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

42


システムモデルは組織に何をもたらすか？

システムとして考えることで得られる気付き

「システム」の重要性、ライフサイクルステージの考慮

「システムアーキテクチャ」を持つことの必要性

「システムアーキテクチャ」を検討することでシステム全体としてのトレードオフ検討、最適化を行えること

構成要素への明確な要求の規定、インタフェースの定義

要求のトレーサビリティの確保

要求および設計変更への対応

システム設計の検証

QCDを守って、システムを構築するプロセスを明確にする。

43


MBSEの適用事例

自動車のパワーバックドアシステム開発のための

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

MBSE に基づきSysML（Systems ModelingLanguage）を利用して

パワーバックドアシステムのシステムモデルを記述しアーキテクチャを構築するまでのプロセスを示す。

部分として考えるのではなく、システムとして考えることによる技術者の気づきや明らかになった点を示す。

44


MBSEの適用で得られた気付きと明確になったこと

要求のトレーサビリティ

エンジニアが要求やビューを把握し、トレースを確保できる。

コンテキスト分析におけるシーケンス図による効果

要求から導かれる機能を明確にすることができる。

機能の割り当て

構成要素間の関係性が明らかとなり、コンポーネント担当エンジニア間のコミュニケーションが円滑になる。

従来の”部品ありき”の設計スタイルでは、見いだすことのできなった組織の枠にとらわれない、対象とするシステム全体としての最適化の検討が行える。

意図しない手戻りを減らすことでQCDを守ることが可能。

45


（１）要求のトレーサビリティ

全てのシステムモデルおよび情報は要求図に示されている元来の要求に遡ることができるため、エンジニアはシステムのすべてのビューを把握することができる。

要求に関連するシステムモデルはSysML ツールに保存されているため、例えば、ECU を追加して新たな機能を

実現する追加開発の際には、要求およびコンポーネント間の関係性を要求図で追いながら検討できる。

要求のトレーサビリティを確保しておくことは非常に重要である。

46


（２）コンテキスト分析の効果１

コンテキスト分析で、絵を描き、またシーケンス図を用いた検討を行うことにより、LED 光には地面からの反射が

あることに気づいた。ユーザーへの「おもてなし」あるいはLED としての機能が、地面の状態に依存することを見いだせた。

バックドアの開閉の動作をイメージすることにより、I-key

の検出を行うためのアンテナの配置に関する検討の見逃しを防ぐことができた。

バックドアが閉まっているときと、開いているときでは、電波環境が異なるので、I-key位置検出のチューニングをバ

ックドア開閉状態それぞれで実施する必要があるという気付きも得ている。

47


（２）コンテキスト分析の効果２

Vehicle2013 が持つべき機能と新たに追加するOSBDS

が持つべき機能を明確にすることができた。

移動検出器とVehicle2013への機能の割り当てやそれらの統合の可能性、およびBD2013 CU とSonar CU の統合の可能性をそれぞれ示唆することができた。

SysMLを用いたシステムモデルの記述により、従来の”部

品ありき”の設計スタイルでは、見いだすことのできなった組織の枠にとらわれない、対象とするシステム全体としての最適化の検討が行えたことは大きなメリットとして認識された。

48


（３）機能の割り当て１

アクティビティ図は、機能がどのようにシステムコンポーネントに割り当てられているかを示すことができ、これはシステムに関与するシステムズエンジニアだけではなく、コンポーネントの設計者にとっても、設計するコンポーネントがシステムの中でどのように機能するのかを知ることができるため、有用である。

技術者が良く活用するステートマシン図や状態遷移表と合わせて検討することによって、コンポーネントの機能に漏れがないかを検討することができる。

機能のコンポーネントへの割り当てやコンポーネント間の統合をシステムとして俯瞰して見ることができるようになる。⇒最適化の検討が行えるようになる。⇒次頁へ

49


（３）機能の割り当て２

コンポーネントに依存する形で分割された組織では、機能の割り当てやコンポーネント間の統合を検討する際に、技術者自身の組織内のコンポーネントのみに影響が留まり、自身が属する組織外のコンポーネントに対して影響が出ないように設計をしがちである。

そうした思考の枠にとらわれずに全体を俯瞰することで、実プロジェクトにおけるQCDの最適化が図れる可能性がある。

こうした検討がシステム開発の早い段階で行えることは、試作やプロトタイプを減らすことができ、意図しない手戻りの減少に大いに効果があるものと期待される。

50


システムズエンジニアリングの導入に向けて

成果物の形式および質の向上

エンジニア個人のスキルに依存

文書として残すべき成果物と関連するシステムモデルを明確に区別できることの優位性

問題と課題

MBSEとSysMLの導入⇒乗り越えるべき壁がいくつかある。

システムズエンジニアリング活動を行う組織が存在しない。

システムズエンジニアリング活動を行うために組織を編成し、SysMLを導入するためのコスト、エンジニアをトレーニングする

ためのコストなどの負担への対処は大きな課題となる。また、追加開発も含んだエンジニアリングプロセスの中での活用方法を検討しなければならない。

51


E/Eアーキテクチャの課題

ECU（Electronic Control Unit）搭載数：50～100個／台

複数のECU をネットワークで構成するE/E アーキテクチャ

新たな機能の追加要求

⇒ ECU の増加、E/E アーキテクチャの複雑化

追加開発

⇒意図しない手戻り、業務上の効率低下

既存システムのどこを活かし、何を追加し、改良すれば良いかを明確にしたい。 ⇒ システムズエンジニアリングの活用

他のサブシステムやコンポーネントとどのような関係性をもつのかを担当技術者にわかるようにする。

52


As-Is分析非接触パワーバックドアシステム（CPBDS)

53

Sensor CU

BCM BD CU

Contactless sensor

I-key

M Cancel SW

M

unlock

open

Vehicle 2013

detecting open request


ワンステップ・バックドアシステム（OSBDS）の検討

ユーザーニーズ（新たな要求の追加）

“ユーザーフレンドリー（操作性の良さ）”

“おもてなし”

54

操作可能エリア受信可能エリアLED 点灯エリア

B A


ユースケース図

55


Commercial Development is strictly ProhibitedUse case of OSBDS[Packag e] uc [ ]

«useCaseModel»

One-Step Back D oor System (OSBDS)

ęü¶üLK’�̧ZkŠĆÆÉ¢’‰�‹

ęü¶üLK’�̧ZkŠĆÆÉ¢’‹O

ęü¶ü’� Y‹Vehicle

2013ęü¶ü

0b


Commercial Development is strictly ProhibitedUse case of OSBDS[Package] uc [ ]

«useCaseModel»

One-Step Back Door System (OSBDS)

ユーザーが手を使わずに

バックドアを閉める

ユーザーが手を使わず

にバックドアを開く

ユーザーを誘導するVehicle

2013ユーザー

地面


ユースケース「バックドアを開く」を記述したシーケンス図（コンテキスト）

56



















ŠĆÆÉ¢’‹O[Interaction] sd

: I-key’:/Y‹ęü¶ü

«block»

: Vehicle2013

«block»

: OSBDS : 0b

[ ]

[ ]loop

[ ]par

[else]

alt

[ ]

[ ]par

車両への接近

I-keyの探索

I-keyの検出

探索モードの判断

[ ユーザーが差し出す足が検出される前 ]

LEDの点灯/消灯

センサーのOn/Off

LEDの光の反射

LEDの光の認知

I-keyの受信可能エリア内での移動検出

LEDの点滅開始/停止

LEDの点滅の光の反射

LEDの点滅の光の認知

LED点滅部へ足を踏み出す

ユーザーが差し出した足の検出

ユーザーが差し出した足の検出信号の送信

バックドアの開閉の判断

バックドアのアンロック

バックドアを開く

[ ユーザーが差し出す足が検出される後 ]



















ŠĆÆÉ¢’‹O[Interaction] sd


«block»

: Vehicle2013

«block»

: OSBDS : 0b

[ ]

[ ]loop

[ ]par

[else]

alt

[ ]

[ ]par

車両への接近

I-keyの探索

I-keyの検出


[ ユーザーが差し出す足が検出される前 ]

LEDの点灯/消灯

センサーのOn/Off

LEDの光の反射

LEDの光の認知

I-keyの受信可能エリア内での移動検出

LEDの点滅開始/停止

LEDの点滅の光の反射

LEDの点滅の光の認知

LED点滅部へ足を踏み出す

ユーザーが差し出した足の検出

ユーザーが差し出した足の検出信号の送信


バックドアのアンロック

バックドアを開く

[ ユーザーが差し出す足が検出される後 ]


ワンステップ・バックドアシステムのシステム構成要素を表すブロック定義図

57

ワンステップ・バックドアシステムのシステム構成要素[Package] bdd [ ]

«block»

静電容量センサー

«block»

I-key 移動検出器

«block»

レーザー・レーダ

«block»

非接触センサー

«block»

赤外線センサー

«block»

ソナーシステム

«block»

BD2020 CU

«block»

OSBDS

«block»

LED

11 11


「I-key の受信可能エリア内での移動検出」を表すシーケンス図

58


「ユーザーが差し出した足の検出」を表すシーケンス図

59











ęü¶üLīWśW_³n ś[Interaction] sd


«block»

: ½ŹüCU : 0b «block»

: ½Źü

[ ]

[ ]

[ ]

opt

par

超音波を送信

超音波を反射

反射した超音波を受信

[ユーザーがLED点滅部へ足を踏み出した場合 ]

超音波を反射

反射した超音波を受信

受信した超音波を解析

LED点灯エリアでの足の存在を判断


コンポーネント間のインタフェースを表すブロック定義図

60

ソナーCU インタフェース１○operations

+LED点灯エリアでの足の存在を判断()+ソナーをOn/Off()

operations+超音波を送信()+ソナーを終了()

ソナーCU インタフェース2○

operations+BD2020 CUから，高頻度探索モードへの切り替えコマンドを受信()+BD2020 CUから，低頻度探索モードへの切り替えコマンドを受信()+受信した超音波を解析()

ソナーCU インタフェース3○

operations+ユーザーが差し出した足の検出信号の送信()

BD2020 CU インタフェース1○

operations+移動検出器から，高頻度探索モードへの切り替えコマンドを受信()+移動検出器から，低頻度探索モードへの切り替えコマンドを受信()+LEDの点滅開始/停止，LEDの点灯/消灯()


operations+探索モードの判断()+受信可能エリア内でI-keyの距離情報を受信()

I-key 移動検出器インタフェース 1○

operations+LED点灯エリアからのI-keyの位置を算出()+操作可能エリア内のI-keyの位置を判断し，その位置情報のVehicle2013への送信()


ソナーインタフェース

operations+反射した超音波を受信()

○

operations+LED終了()+LEDの点灯を起動()+LEDの点滅を起動/終了()

LED インタフェース○


アクティビティ図による物理アーキテクチャの総合

61

アクティビティ図による物理アーキテクチャの総合[Activity] act [ ]

I-keyを持つユーザーの足

«allocate»

OSBDS

«allocate»

I-key 移動検出器

«allocate»

BD2020 CU

«allocate»

ソナーCU

«allocate»

LED

«allocate»

ソナー

LED点灯エリアからの

I-keyの位置を算出

操作可能エリア内の

I-keyの位置を判断し，

その位置情報のVehicl

e2013への送信


受信可能エリア

内でI-keyの距

離情報を受信

LEDの点滅

を終了

LED終了

LEDの点滅

を起動

LEDの点灯

を起動

操作可能エリア内での

I-key情報を受信


受信可能エリア内で

I-keyの距離を送信

I-keyを探索する

バックドアのロックバックドアを開く

高頻度探索

モードへ移行

低頻度探索

モードへ移行

時間カウント

１分

時間カウント

5秒

時間カウント

１分

バックドアの

アンロック

探索頻度

時間調整

バックドア

を閉める

ソナーを終了

超音波を送信

反射した超

音波を受信

LED点灯エリアでの

足の存在を判断

受信した超音波

を解析

BD2020 CUから，

低頻度探索モード

への切り替え

コマンドを受信

BD2020 CUから，

高頻度探索モード

への切り替え


ソナーをOff

ソナーをOn

移動検出器から，


への切り替え


ユーザーが差し出

した足の検出信号

の送信

移動検出器から，


への切り替え


LEDの点滅停止

LEDの点滅開始

LEDの消灯

LEDの点灯

超音波を反射

LEDの光

を反射

«allocate»

Vehicle

2013

«allocate»

地面

[操作可能なエリアの内で

I-keyが検出される場合]

[操作可能なエリアの外で


[高頻度モードで1分未満

またはI-keyなし5秒未満]

[低頻度

モード]

[高頻度

モード]

[I-keyなし]

[低頻度

モード]

[I-keyあり]

[ 高頻度モードで1分経過

かつI-keyなし5秒継続]

[高頻度

モード]


低頻度探索モードと高頻度探索モード間の遷移を表す状態機械図

62

低頻度探索モードと高頻度探索モード間の遷移[State Machine] stm [ ]


To Do = "I-keyを探索する()

探索頻度時間調整（）

LEDの消灯/終了()

ソナーOff/終了()"


To Do = "I-keyを探索する()

探索頻度時間調整（）

LEDの点滅開始/起動/停止()

LEDの点灯/起動()

ソナーをOn()

受信可能エリア内でI-keyの距離情報を受信（）

LED点灯エリアからのI-keyの位置を算出()

操作可能エリア内のI-keyの位置を判断し，その位置情報

のVehicle2013への送信（）

操作可能エリア内でのI-key情報を受信（）

ユーザーが差し出した足の検出信号の送信()

反射した超音波を受信()

受信した超音波を解析()

LED点灯エリアでの足の存在を判断()"

[低頻度探索モード状態で

I-keyが検出されない場合]

[高頻度モードで1分未満

またはI-Keyなし5秒未満]

[高頻度モードで1分経過

かつI-Keyなし5秒継続 ]

[低頻度探索モードで


I-keyを探索する()探索頻度時間調整()LEDの消灯/終了()ソナーOff/終了()

I-keyを探索する()探索頻度時間調整（）LEDの点滅開始/起動/停止()LEDの点灯/起動()ソナーをOn()受信可能エリア内でI-keyの距離情報を受信（）LED点灯エリアからのI-keyの位置を算出()操作可能エリア内のI-keyの位置を判断し，その位置情報のVehicle2013への送信（）操作可能エリア内でのI-key情報を受信（）ユーザーが差し出した足の検出信号の送信()反射した超音波を受信()受信した超音波を解析()LED点灯エリアでの足の存在を判断()


要求図によるトレーサビリティの確保

63

ユーザーに対して、自動車がユーザーを歓迎する際、または、ユーザーのために何かを準備する際に、おもてなしを感じさせること

«performanceRequirement»

«derivedReqt»

«derivedReqt»

«derivedReqt»

«derivedReqt» «derivedReqt»

«derivedReqt»«derivedReqt»

«derivedReqt»

«derivedReqt»

«derivedReqt»

«derivedReqt»

«derivedReqt»

«satisfy»

«allocate»

«satisfy»«satisfy»

«allocate»

«allocate»«allocate»

«allocate»

«satisfy»

«satisfy»

«satisfy»

«satisfy»

«allocate»

«satisfy»«allocate»

«satisfy»

«derivedReqt»

«satisfy»


システム

モデル

プロジェクトマネジメント

要求

シミュレーション/CAE

ライブラリ/

データベース生産/サプライチェーン

最適化

CAD

システムライフサイクルのマネジメント

PLM (Product Lifecycle Management), SCM (Supply Chain Management)

システムアーキテクチャと同義

64

ここを繋ぐ仕組みが大変重要になっている。


まとめ

システムズエンジニアリングの標準をもとに基本的な考え方を紹介し、欧米で幅広い産業に採用されているモデルに基づくシステムズエンジニアリング（MBSE）の重要性を述べた。

開発のステージに焦点を絞り、システムズエンジニアリングプロセスの概略の流れを示すとともに、システムアーキテクチャを構築するまでにシステムモデルを記述することの有効性を述べた。

システムモデルを構造／振る舞い／要求／パラメトリック制約の4つの柱で記述することができるSysMLの適用事例を紹介し

た。また、自動車のパワーバックドアシステムへの適用を試みた企業担当者からの評価を示した。

65


参考文献 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

モデルベースシステムズエンジニアリング - ipa...2015/11/26 ·...

Documents