MaaS 時代の System of Systems 開発
2019 年 5 月 22 日
兼平 靖夫†
あらまし クルマがつながる時代となり MaaS の実現が現実味を帯びてきた、自動車単体でもADAS 統合制御、自動運転の開発が、駆動の電動化と相まって非常に複雑なシステムとなってきた。
本論では車と車、モビリティとインフラが一体となるような複雑なシステムを開発する手法として、システムズ・エンジニアリングを紹介し、System of Systems から実際の実装部品まで、いかにシームレスにプラットフォーム上で開発されるかを示す。

カーレンタル
カーシェア
ライドシェア

予約＆顧客管理
車両管理

顧客要求

ビジネス
複数モーダルプラットフォーム
提案
コンテント＆宣伝
渋滞、地図情報

ライドヘイリング

自動車業界の最近の動向としてはダイムラーが中期経営戦略として CASE（Connected / Autonomous/Shared&Service / Electric）と定め、コネクティッドとシェア&サービスを来るべき世界と定め
Daimler(2018), KPMG(2019)は 2030 年までの自動車業界 幹 部 によ る 主 要ト レ ン ド と して 、 1 位コ ネ ク
ティッドとデジタル化、2-4 位電動モビリティ(電池、燃料電池、ハイブリッド)としており、コネクティッドと電動化が産業の動向としている。
また同時に自動車をモビリティの一つの要素として考える MaaS (Mobility as a Service)が現実のものとなってきている。例えば、田中(2018)
自動車単体に目を向けるとこれまでには無かった様々な新しいセンサー（例えばステレオ・カメラ、ミリ波レーダ、LiDAR）が搭載され、車載システムの複雑さが増し、同時に各種位置情報をやり取りするために車が外部ネットワークと接続されるなど、車と車、車と交通インフラが一体となる。これは層状の非常に複雑なシステムを形成する。このような複雑な製品開発は新しい手法を要求する。

サイバー
インフラ

機能レイヤ
論理レイヤ

判断

通信

環境

データプロセス＆決定with humans and with machines

センサー

ソフトウェ
アアプリ
ケーション

カメラ レーダ ソナー LiDAR

ソフト
BSW, OSヒューマンインターフェイス

計算量バランス

通信プロトコル & サ イバーセキュリティ

プロセッサ

Cable 無線通信 ヘッドアップ
デ ィスプレイ,& Wires
音 声, LEDs, ...

ECUs, GPUs, FPGAs,…

IoT データ & 計算
コネクト
エッヂ＆マシン接続性

実行

感知

物理レイヤ

マルチスケールサービス

1．産業の状況

power, move, sound, heat, cool, …

アクチュエータ

機械部品

パワーマネ
ジメント

自動ビークル

通信

感知｜判断｜行動

パワー＆バッテリー

サイバーフィジカルシステム

物理環境

複合分野

ハード& ソフト
部品

ハード& ソフト
プラットフォーム

物理インフラ

複数産業

図 2. Mobility as a Service

2. システムズ・エンジニアリング
自動車は機能・構造関係が多対多対応で複雑に絡み合ったアーキテクチャであり、「インテグラル型」（すり合わせ型）であり 藤本(2014) 複雑な製品を開発部間のたくみな調整により開発をしてきた。
しかしながら MaaS のように車と交通インフラが一体となると、複雑さが増大し、すり合わせでは限界をむかえる。岡部(2016)
MaaS のような複合したシステムをシステムのシステム(System of Systems ;SoS)といい、このような複雑なシステム開発を可能にするものとしてシステムズ・エンジニアリングがある。

クラウド
サービス

機能レイヤ
論理レイヤ
物理レイヤ

感知

判断

センサー

ソフトウェ
アアプリ
ケーション

カメラ レーダ ソナー LiDA
R

ソフト
BSW, OS

通信

実行
ヒューマン
インターフェイス

計算量バ
ランス

通信プロトコル & サイバー
セキュリティ

プロセッサ

Cable 無線通信 ヘッドアップ
ディスプレイ,& Wires
音声, LEDs, ...

ECUs, GPUs,
FPGAs, …

必要な開発労力

アクチュエータ

サイバーフィジカルシステム

物理環境

機械部品

パワーマネ
ジメント

必要な開発労力 = A x 複雑さ1+B

典型的な開発手法とシステムズ・エンジニアリングによる協調的な手法との臨界点

パワー＆バッテリー

典型的な開発プロセス（プロジェクトに対するウォーターフォール的な取り組みと暗黙的な方法論とに基づく）

システムズ・エンジニアリング
プロセス（プロジェクトに対する協調的な取り組みと明確な方法論とに基づく）

図 1. つながる時代の自動車
製品のインタフェースの数(統合の複雑さ)†ダッソーシステムズ株式会社
システムズ・エンジニアリング・プリンシパル
Yasuo.Kanehira@3ds.com

図 3. システムズ・エンジニアリング導入 岡部(2016)

Rev1.2

1

プロセス

ピラー
要求
ステークホルダ
ニーズと要求定義問題

ソリューション

システム
要求定義

実装

物理要求
定義

振舞い

構造

パラメータ

運用コンセプト開発
システムアーキテクチャ定義
高次 (領域クロス) 設計定義
詳細 (領域特化) 設計定義
実装

図 5. MagicGrid によるメソッド

人

テクノロジ

メソッド
ツール
環境
図 4.PMTE メソドロジ

ドメイン

Estifan(2008)

プロセスはシステムズ・エンジニアリングの専門家団体である INCOSE やアメリカ航空宇宙局NASA などが定義をするが、プロセスでは実行する内容の定義であり、実施方法は定義しない、よって次段のメソッドによって、いかにシステムを開発していくかを定義する。
メソッドには各種あり Estifan(2008) それぞれ長所・短所があり、対象に応じて最適なメソッドを選択することが重要である。
ダッソー・システムズはフランス CESAMES 社
が 考 案 し た 9 Views Krob(2015) そ れ を 拡 張 し たModeling Methodology for Systems © (MMS)、NoMagic社 MagicGrid などのメソッドをサポートする。
また、初期のシステムズ・エンジニアリングは文書によってなされたが、文書を使ってのシステム
ズ・エンジニアリングは意思疎通に祖語や変更があった際に修正が極めて難しいため、モデルを使ってシステムズ・エンジニアリングを行う手法、モデル・ベースド・システムズ・エンジニアリング(以下 MBSE)の利用が進んでいる。
以下 MagicGrid を例にとって説明すると、横軸には対象の捕らえ方、要求、振舞い、構造、パラメータなどのビュー。
縦軸には対象をいかにとらえるか問題、ソリューション、実装という観点で分解する。
さらにすべてを貫くものとして、特化型エンジニアリングがあり、これはセーフティやセキュリティなどの観点でシステムをみるものである。

このように縦、横軸でそれぞれ異なるビュー、上位ではどう実現するかではなく、何を行うのかのサービスの視点でモデル化（ブラックボックス）、して考えるために想定・検証もれが少なくなりや意思の疎通が良くなる利点がある。
以下メソッドは対象の複雑さ、開発形態によって下図のようにサブシステム、そのサブシステムと層状に展開されていき、マルチ・デシプリン（車載システムの場合、メカ、電気電子、ソフトウェア）へと分割していく。

図 5. メソッドのサブシステム、コンポーネントへの展開

MaaS で対象となる SoS を記述した場合、最上位はその運用の観点から様々なサービス（配車、ナビゲート、充電）や利用するモビリティなどがサブシステム、サブサブシステムと展開されていき、その過程で対象が機能レベル(Functional)、論理レベル(Component)に展開されていく。

図 6. 上位要求から下位要求への開発

2

特化型エンジニアリング

システムズ・エンジニアリングは、「システムを成功裏に実現するための、学際的なアプローチ及び手段」西村(2019)である。
システムズ・エンジニアリングは特定の手法を意味せず、Estefan(2008)はシステムズ・エンジニア
リングを PMTE(プロセス, メソッド, ツール,環境(Environment))により構成されるメソドロジと定義し、それぞれの間関係を図４とした。

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

MaaS 時代の System of Systems 開発

MaaS 時代の System of Systems 開発

MBSE では記述言語を問わないが、現在システムの記述言語としては SysML が多く使われる。
SysML で記述された上位モデルは必ずしもシミュレーション実行や下位モデルに自動変換される必要はなく、まずステークホルダ間で開発対象への意思の疎通を果たす。
act

手戻り！

制御設計

ibd

仕様決定

エレ設計

振る舞い

経緯が！ 残らない

メカ設計

構造

VoC収集・分析

手戻り実現不可！ と発覚！ 部署間の“壁”

結合・検証

図 9. 従来手法、手戻りが多発

reqpar

次に MBSE を適用したフローを示す、ここで特筆すべきことはアーキテクチャ分析であり、ここで機能を行うために最適な割り付けを行う、
VoC収集要求

パラメトリック

図 7. SysML 基本モデル Friedenthal(2009)

アーキテクチャ分析
経緯が残る仕様議論会
関係者全員が納得バーチャル検証
トレードオフ分析

実用性OK

仕様決定
制御設計

エレ設計

メカ設計

結合

図 8. SysML 記述による初期検証

図 10. アーキテクトが全体最適問題からソリューションに進む段階で、MBSEの特徴であるアーキテクチャ定義を行う、その利点を示すために、まずシステム視点ではない開発を示す、仕様より、メカ・電子・制御（ソフト）の割り付けは通常はメカ、電子、制御いずれかの部署においてなされ、全体システムの観点が抜けている、そのため、実装時に手戻り、機能の無理な実装が行われることがある。

1
本来 SysML は記述型モデルであるので、シミュレーション等は出来ないが、最近のツールでは例えばシーケンス図など以下、サブシステムとして車載システムが選定された例を見ていく

3. モデルベース開発
MBSE はライフサイクルを含むシステム開発・運用全般を含み、この項で説明するモデルベース開発 MBD も含むが、ここでは詳細設計定義（開発）として説明を行う。
機能レベル、論理レベルにまで設計が進むと、対象を詳細モデルで記述できる、これは先の SysMLが記述型モデルと呼ばれ、基本シミュレーションが出来ないのに対し 1
この詳細モデルは分析型モデルと呼ばれシミュレーションに供することが出来、バーチャルに検証が行える。開発の抽象度が高い上流工程でシミュレーションにより検証が出来れば、処理スピードもはシミレーションできる。

3MaaS 時代の System of Systems 開発速いため、効率よく検証ができる。また問題があっても、その手戻りも少なくなる。
以下に電子制御、機械制御の活用例を示す。
battery

インバータ

Vcapacitor

C=0.5e-3

voltageSensor

batteryモータ

controller

modulationMethod

invertermachinecontroller

modulationMethod

invertermachinemultiSensor

desiredTorquestartTime=10

power tau w

ground

図 13. FMU による連携シミュレーション

quadraticSpeedDependentTorque

制御

J=1

変調方式
inertia

図 11. Modelica による電動モータ制御

例えばサプライヤにサブシステム開発を依頼するケースであれば、サプライヤは内部のコードを開示することなく FMU を作成でき、早期での検証が行える。

図 12 メカ連携例

MBD では ECU 内部で組込みソフトウェアになる制御部分は Mathworks 社 Simulink©などで記述されることが多く、モーター、トランスミッションなどプラントモデルは Modelica アソシエーションが定義したモデリング言語 Modelica がよく利用される。
Modelica には電動モビリティでよく使われるコンポーネント、電動モータ、インバータ、トランスミッション等のモデルもサードベンダーから提供され て い い る 。 ま た 3D メ カ は CAD デ ー タ か らModelica 機構データに変換でき、Functional Mockup
Unit (FMU)を用いれば、Simulink©/Modelica で書かれたモデルによりメカ＝電気＝ソフト（制御）の複合物理の検証が出来る。

図 14．周辺環境も含めたシミュレーション

各種シミュレーション条件は設定により自動実行され、例えばメカ＝電子＝ソフト間で、どの組み合わせが対象に対して最適であるかのトレードオフ
が 開 発 の初 期 に 可 能 とな る。 実 行結 果 がレ ー ダチャートで表示され、コスト、性能などの条件比較により最適な組み合わせを選択する。

図 15. 各種 KPI によるトレードオフ支援
4MaaS 時代の System of Systems 開発

能で、実装後の手戻りを大きく減らす。

4. E/E アーキテクチャ設計
ここまででシステムから機能レベルまでの検証が完成している、ここから論理レベル、実装レベルに展開をしていく。
車のような組込み機器では、処理を実行するコンピュータ(ECU)は複数あり、それらがバスで接続されている。
今日の車載電気電子のシステム(以下 E/E システム)では使われる ECU は 100 近くあり、接続されるセンサー、アクチュエータ合わせると、非常に複雑な E/E アーキテクチャを構成する。
また ECU の心臓部であるマイコン(MCU ; MicroController Unit)は半導体であり、新しい世代になるとスピード、メモリ容量などが数倍になることも珍しくないが、ソフトウェアの移植性、リアルタイム性などの問題により実際には追加機能毎に新しいECU が追加される事も多く、車載システムで利用する ECU の個数が増大する。
これを避けるため機能をフレキシブルに E/E シス
テムに再割り当てが出来る事が求められている。
3D EXPERIENCE プラットフォームでは機能レベ
ルから ECU のアーキテクチャを定義し、機能を後述する車載ソフトウェア標準規格 AUTOSAR 準拠を採用し、各 ECU にフレキシブルな割当てが行える。
HW architecture 1
ECU 1

Function (->S/W) A architecture

F
Allocated toSensor A

ECU 1

Used byActuator Z

LCom.
matrix

System Mapping of Function (S/W) A
on HW architecture 1

図 16. 機能の ECU アーキテクチャへのマッピング

図 18．バス容量の見積もり

5. 車載ソフトウェア標準 AUTOSAR 実装
ECU 内部にある MCU は半導体ベンダーから供給され、命令アーキテクチャが異なり、また周辺ペリフェラルも異なり複数の ECU を統合することは非常に困難な作業となる。
機能の ECU へのフレキシブルな割付はソフトウェア（特にアプリケーション）の標準化が必要となる。これを一つの目的に制定された車載ソフト
ウ ェ ア の 標 準 規 格 AUTOSAR(AUTomotive OpenSystem ARchitecture)はソフトウェアに層別のアーキテクチャを導入し、車載アプリケーションソフトウェアにソースレベルでの互換性を持たそうとしている。
下図は AUTOSAR の概念図で従来のソフトウェ
アはハードウェア(ECU)構造と密接に関連し(くさびの形で表現)、他の ECU には移植しにくいのに対し、
AUTOSAR では中間に ECU の構造の違いを吸収する中間レイヤーを入れることによりアプリケーションの移植性を向上させている。兼平(2007)
AUTOSARソフトウェアはハードに完全依存

Application Software
Softwarestandardized

この段階でいくつの ECU で構成するか、どのようなバス構成にするかが柔軟に試行出来る。

AUTOSAR RTE
Services
ECU Abstraction
and Complex Drivers
Microcontroller Abstraction

HW-specificHardware
Hardware

図 19. AUTOSAR による移植難易度の変化

図 17．ECU アーキテクチャの構築

AUTOSAR Builder は AUTOSAR 準拠の開発ソリューションであり、コンポーネント定義、コントラクトフェーズ RTE 生成、ECU 割り当て、ジェネレーションフェーズ RTE 生成のメソドロジをサポートする。
また下位の ECU 決定以前の VFB(Virtual FunctionBus)レベル、上位サービス層のみを考慮したレベル、BSW まで統合した完全レベルなど、各種抽象度でシミュレーション機能を提供する。

またこの抽象度でバスの負荷を見積もる事も可5

MaaS 時代の System of Systems 開発

6. 協働協調開発プラットフォーム

設計

これまで見た MBSE, MBD, EE アーキテクチャ設計および AUTOSAR による実装までの開発はウオー
ターフォールのように上位から下位に一方向に行うのではなく、各工程間で修正・変更をアジャイルに繰り返すことが効率的な開発につながる。
また自動運転においては対象となる条件パターン(例えば、対処しなければいけない道路のシーン、シナリオなど)が指数関数的に増大し、これまでの管理では破綻する可能性がある。
その様な複雑な開発にも 3D EXPERIENCE プ
ラットフォームは威力を発揮する。
OEM-サプライヤ間、また全世界に点在する拠点で同時に開発・変更を繰り返す開発プロセスにおいて起こりがちな、要求変更もれ、仕様 - モデル ソースコード間の一貫性などを保つことは、協働開発プラットフォームで管理しないと非常に難しい作業となる。
また現在では複雑な制御システムの安全を確保するために、従来の IATF16949 に加え、電気電子システムには機能安全 ISO26262 の適応が求められ、開発プロセス管理には AutomotiveSPICE への適用も多くの OEM、サプライヤで要求される。
ISO26262 / AutotmotiveSPICE では開発プロセスでの成果物の定義、承認管理、一貫性、トレーサビリティなどの管理を要求する。兼平(2013)

V&V
WP

WP

WP

WP

図 21. V 字開発での成果物管理

現在の車載開発においては先の機能安全に加えセキュリティも考慮して開発を行う必要があり、そのデータ管理は煩雑を極める。Klauda(2015)
セキュリティ機能安全

ThreatAnalysis

Hazard andRisk
assessment

Security
goals

Safetygoals

Securityarchitecture

Security
designanalysis

機能開発

System safetyconcept

FMEA, FTA,
FMEDA

Requirements
analysis

System Test

SystemdesignDesignSystemintegration

Unit Test

ImplementationSafety case

Securitycase

Validation
safetyassumptions

Validatesecurity
assumptions

Test safetymechanisms

Test safetymechanisms

Integration andpenetration tests

Functional andpenetration test

Guidelines
reviews,
analysis

1.Vocabulary
2.Management of functional safety

3. Concept phase
3-5 Item definition
5. 安全ゴールから設計への3-8 Institution of the safety lifecycle
トレーサビリティ

2-7. safety management after releasefor production

2-6 safety management
During item development

2-5 Overall safety management

4.Product development - system level
4-5 Initiation of product7.Production and operation

development at the system level
4-6 Specification of the technicalsafety requirements

7-5 Production

4-11 Release for production

3-7 Hazard analysis and risk
assessment
3-8 Functional safety concept

4-7 System design

5.Product development
hardware level

5-5Initiation of product development
at the hardware level
5-6 Specification of hardware
safety requirements

4-10 Function safety assessment

6.Product development
software level
6-5 Initiation of product development
at the software level
6-6 Specification of software safety
requirements

5-7 Hardware design

6-7 Software architectural design

5-8 Hardware architectural metrics

6-8 Software unit design andimplementation

5-9 Evaluation of violation of the safety
goal due to random HW failures

6-9 Software unit testing

5-10 Hardware integration and testing

7-5 Operation, service(maintenance and repair),and decommissioning

4-9 Safety validation
4-6 Item integration and testing

1. V字プロセス管理
2. 成果物管理

6-11 Verification of software safetyrequirements

図 22. セキュリティ、機能安全、機能開発でのプロセス
管理 Klauda(2015)

3D EXPERIENCE プラットフォーム上でプロセスのタスク、成果物を管理し、レビューのゲートも定義できる。

8. Supporting processes

3. 構成管理4. 変更管理

8-5 Interfaces within distributed developments

8-10 Documentation
8-11 Qualification of software tools
8-12Qualiffication of software components
8-13 Qualification of hardware components
8-14 Proven in use argument

8-6 Specification and management of safety requirements
8-7 Configuration management
8-8 Change management
8-9 Verification

9.ASIL –oriented and safety –oriented analysis

9-5 requirements decomposition with respect ASIL tailoring
9-6 Criteria for coexistence of elements

9-7 Analysis of dependent failures
9-8 Safety analyses

図 20. ISO26262 で要求されるデータ管理

これまで見たような System of Systems の定義か
ら System 多くの Sub System までの膨大なデータに対し、要求される成果物管理、その一貫性、トレーサビリティの確保は多大な労力を要する。
一般に V 字開発においてステージ毎に検証を行い、成果物等を保存する。
図 23. フェーズゲート管理

6

MaaS 時代の System of Systems 開発

7．参考文献図 24．小粒度でのトレーサビリティ

同時に ISO26262 / AutomotiveSPICE では要件単位でのトレーサビリティが要求される。
これまでに説明した MBSE/MBD/構成管理ツール
群は全て 3D EXPERIENCE プラットフォーム上で統合されており、ユーザは上位要求から実装部品まで、変更管理・構成管理・プロジェクト管理が可能である。またそれぞれのプロセス間のレビューなど承認管理、成果物管理も厳密に管理する。
その全ての過程で要求は任意の粒度でトレーサビリティが提供される。
全体の進捗状況はコックピット機能によりグラフ化され、ボトルネック箇所などが容易に分かる。

図 25. 検証状況をコックピットで俯瞰

6．むすび
MaaS の時代には極めて複雑なシステムに対処する必要がある、その複雑さに対峙する一つの方法がシステムズ・エンジニアリングであり、モデルを用いて MBSE を導入し、モデルベース開発で早期に機能検証を行う事が有効である事を示した。
トレードオフで決定された、アーキテクチャ開発の例として、多数の ECU を持つ E/E にフレキシブルにマッピングが必要な事を示した。また使用するデータは共通開発プラットフォームによりシームレスに管理することが必要で、ダッソー・システムズの 3D EXPERENCE プラットフォームはこの様な開発に最適である。

Daimler(2018) - Daimler Q2 2018 Corporate Presentation,
https://www.daimler.com/dokumente/investoren/praesentationen/daimler-ir-corporatepresentation-q2-2018.pdf
Estifan(2008) - Estefan, Jeff “A. Survey of Model-Based
Systems Engineering (MBSE) methodology”, INCOSE MBSE
Initiative, May 23, 2008Friedenthal(2009) - Frienthal, Sanford, et.al.,西村秀和監訳「システムズモデリング言語 SysML」, 東京電機大学出版会
Klauda(2015) – Klauda, Matthias, et al. ”Position of Points
2020 Paradigm Shift in E/E Architectures”, ATZ elekronik
2015/02 Vol 10 p.4-10
KPMG(2019) – KPMG "Global Automotive Executive Survey
2019", https://automotive-institute.kpmg.de/Krob(2015) - Krob, Daniel 「システムズ・エンジニアリングと自動車業界」ダッソー・システムズシステムズ・
エンジニアリングセミナー資料 2015 年 12 月 15 日
岡部(2016) - 岡部英幸「システムズエンジニアリングとフランス産業界の動向」, 『日本機械学会誌』日本機械学会 2016 年 12 月 Vol.119, p. 650-653
兼平(2009) - 兼平靖夫「AUTOSAR の目的とアーキテクチャ ― 自動車業界に見る組み込みソフト開発効率化の取り組み（1）」, 組込みネット CQ 出版社, 2009 年 1 月 6日
兼平(2013) - 兼平靖夫 「ISO 26262 管理インフラでの必要要件」、『品質』日本品質管理学会 2013 年 43 巻 3 号
p. 312-317
経産省(2018) 「自動車新時代戦略会議（第一回資料）」,経済産業省 2018 年 4 月 18 日
田中(2018) - 田中紘一「Open innovation と Digitalization
フィンランドが MaaS を進めるその背景」フィンランド大使館商務部、立命館大学 FutureMobility 研究会資料,2018 年1 月 26 日
西村(2019) - 西村秀和「システムズエンジニアリングハンドブック第４版」慶応義塾大学出版会、2019 年 4 月 25
日
藤本(2014) - 藤本隆宏「いわゆる「自動車のモジュール化」に関する一考察」自動車技術, Vol.68, No.6, 2014 p.2733

7

MaaS 時代の System of Systems 開発

お手持ちのスマートフォンで、YouTube ビデオを！

仏レンヌ市の MaaS 運転実験

機能モックアップと MBD 連携

https://www.youtube.com/watch?v=cS2zsPp9eSA

https://www.youtube.com/watch?v=Yl0nv8g12zo

お問い合わせはダッソー・システムズ株式会社 マーケティング〒141-6020 東京都品川区大崎 2-1-1 ThinkParkTower
TEL: 03-4321-3506 E-mail: Japan.Marketing@3ds.com
各社製品名は各社の登録商標です8