自動車ソフトウェアにおけるサービス指向アーキテクチャの提案
2005MT029 生駒 光平 2005MT055 近藤 貴大 2005MT115 田邊 隼希
指導教員 青山 幹雄

1. はじめに複数のベンダで開発した自動車ソフトウェアのネットワー
クを介した協調制御が必要となっている[2]．本稿では，プロパティに基づき従来のサービス指向アーキテクチャ(SOA: Service-Oriented Architecture)の直接的なサービス提供に加え，イベント起動や間接的なサービス提供を含むモデルとそれを実現するアーキテクチャを提案する．

(2) 協調的サービス提供

2. SOA 適用の現状と問題点(1) 自律的サービス提供

自動車ソフトウェアにおいてセントラルロッキングシステ
ム[4]を例として SOA を適用する研究がある．SOA の適用によって，メッセージベースの処理が可能となる．しかし，従来の SOA には以下の問題がある．
(1) イベントの処理が未対応
自動車などでは，イベント処理が重要であるが，従来のSOA ではイベントの処理を扱えない．
(2) 空間を介したサービス提供の必要性
自動車などでは，ユーザが直接結果を受けるサービスと，空間を介してユーザが効果を得るサービスも存在する．空間を介したサービス提供の例を図 1 に示す．
外部環境に応じて相互に作用

天候
センサ

車内

路面状況

協調制御
センサ

ユーザ

ステアリング制御ECU

センサ 変化
速度

エンジン制御ECU
ブレーキ制御ECU

エアコン制御ECU

ネットワークで連携ロパティが目標値に収束するように自身を制御する．目
標値とはユーザの要求を示す．
(2) 協調的サービス提供：複数のサービスを協調動作させることで全体としてユーザの要求を満たす．
これらの異なる制御モデルのアーキテクチャは異なり，統一性を欠くことから，振舞いの一貫性の欠如や制御が競合する可能性があるため，これらを統合できる SOA の拡張とその設計方法が必要となる．

外部環境

図 1 空間を介したサービス提供

3. プロパティ中心サービス提供モデル
3.1. プロパティ中心サービス提供モデル
SOA を適用する上でプロパティ中心にモデル化を行う．
プロパティを次の三つに分類する．
(1) サービスプロパティ：動的に変化するサービスの特性や状態．
(2) 環境プロパティ：ユーザを取り巻く環境の状態．
(3) ユーザプロパティ：ユーザの特性，システムへの要求．
3.2. 自律的サービス提供と協調的サービス提供
図2に示すように，自動車ソフトウェアのサービス提供における相互作用をその性質に着目し分類する．
(1) 自律的サービス提供：各機器は，それを取り巻く環境プ

サービスプロパティ

エンジン制御スロットル開度

setThr
エアコン制御ユーザ

自動車ユーザ
プロパティ

環境
プロパティ

サービスプロパティ
温度

走行モード

燃料使用量

電源

目標値

影響

影響

影
響

setTemp
ON
OFF
外部環境

図 2 自律的サービス提供と協調的サービス提供

4. モデルに基づく SOA 設計方法
サービス提供を様々な観点から分類し，そのサービス提供を実現するアーキテクチャパターンを決定する．
4.1. 対話型サービス提供と自律型サービス提供
サービスが制御するプロパティの性質とユーザとの相互作用の違いに着目し，分類する．
（1） 対話型サービス提供：ユーザの要求に対しプロパティを動的に変更する．
（2） 自律型サービス提供：操作対象のプロパティ値を一定に保つためシステムが自律的にサービス提供を行う．
4.2. 直接的サービス提供と間接的サービス提供
ユーザとサービス間の相互作用に着目し，分類する．
（1） 直接的サービス提供：サービスとユーザが直接相互作用する．
（2） 間接的サービス提供：環境プロパティを制御する場合，サービスは環境を介してユーザに影響を与える．
4.3. アーキテクチャパターンの決定と統合
対話型サービス提供では，ユーザはスイッチ操作などでサービスプロバイダを直接指定，起動し，その結果を待つ．
従ってメッセージベースの要求/応答を用いる．
自律型サービス提供では，環境の情報をセンサなどでイベントとして検出し，検出内容と関連するサービスを起動する．環境情報の発生とそれに応じた処理を独立に行うためイベントベースのパブリッシュ/サブスクライブを用いる．
この二つのアーキテクチャパターンは振舞いが異なるが，システム全体としては統一的に制御する必要がある．このため，ブローカを用いてこれらのアーキテクチャパターンの振舞いを統合する．

5. ブローカアーキテクチャ
メッセージベース，イベントベースの異なるモデルを統一的に制御するブローカアーキテクチャを提案する．
5.1. 導入するブローカ
ブローカをイベント処理とサービス起動に分離する．イベ
ント処理をイベントマネージャ，サービス起動をサービスコーディネータが行う(図 3)．
（1） イベントマネージャ：センサからのイベントを受信し，登録されたサブスクリプションに基づきフィルタリングを行い，サービスコーディネータにイベントを配信．
（2） サービスコーディネータ：ユーザ，サービスからの要求やイベントマネージャとの連携でサービスを起動．
ユーザ
イベント
ユーザ要求センサ
イベント通知
イベント
マネージャ
環境

イベント

結果

結果

制御サービスC
制御サービスA
起動

要求
イベント配信サービス
コーディネータ

起動
起動

結果
サブスクリプション
イベント通知起動
サブスクリプション
制御サービスB
外部環境センサ

ユーザ
アプリケーションサービス
表示サービス

図 3 ブローカアーキテクチャ
5.2. ブローカアーキテクチャの振舞い
ブローカアーキテクチャの振舞いを対話型，自律型複合ユースケースにより検証する(図 4)．
対話型，自律型サービス提供パターンという制御モデルの異なるサービス提供パターンを実現し，サービス提供を統一的に制御できた．またパブリッシュ/サブスクライブを用いて，イベントを複数のサービスに通知できる．
ユーザ 制御 A 制御 B 表示

アプリ
ケーション

するセンサ，サービスを決定する．
b) ユースケース図に基づき，ユースケース記述を作成し，シナリオによりサービス提供パターンを発見する．
(2) 相互作用分析
a) シナリオからシーケンス図を作成し，実行順序に着目した相互作用分析をする．
b) シーケンス図からコミュニケーション図を作成し，要素間の相互作用分析をする．
6.1. 機能分析(1) ユースケース分析
ACC の提供機能とアクタの関係を示す(図 6)．アクタは，ユーザ，レーダ，車速センサ，エンジン制御サービス，ブレーキ制御サービスである．メインスイッチの操作はユーザの操作なのでユースケース図には示さない．ACC は距離計算，追従制御，速度制御，ブレーキ制御に分割できる．

サービス
イベント ユーザ
コーディネータ マネージャ 要求

外部環境

サブスクリプション
サブスクリプション

ユーザ

Aを起動する要求
起動

応答

要求
起動

エンジン ブレーキ表示
制御
制御

イベント
配信

イベント通知(1) 機能分析(2) 相互作用分析a)ユースケース分析b)シナリオ分析a)実行順序に着目した相互作用分析

b)要素間の関係に着目した相互作用分析

ユースケース記述

シーケンス図

コミュニケーション図

図 5 ACC の分析プロセス(1) 機能分析a) ACC の機能をユースケース図を用いて分析し，構成ブレーキ制御
サービス

par

イベント
通知

起動
応答
起動表示

イベント
配信

制御
要求
起動
要求

イベント
配信制御
要求起動
要求

イベント
配信

par

par

スロットル開度変更

6. ブローカアーキテクチャの適用例

仕様書

エンジン制御
サービス

サービス
イベント
車速
メイン
レーダ
コーディネータ マネージャ スイッチ
センサ

メインスイッチON

図 4 ブローカアーキテクチャの振舞い

ユースケース図

ACC
制御

自律型
サービス提供ブローカアーキテクチャを ACC(Adaptive Cruise
Control System)に適用し，分析する(図 5)．

センサ

サブスクリプション
サブスクリプション
サブスク
リプション
サブスク
リプション

対話型
サービス提供

par
実行結果

レーダ

図 6 ACC のユースケース図(2) シナリオ分析
図 6 のユースケース図に基づき，ACC の開始から追従走行制御までのシナリオを作成した．ユーザがサービスを指定して要求を行いサービスが起動する対話型サービス提供パターンと，環境プロパティの変化からサービスが起動する自律型サービス提供パターンがある．
6.2. 相互作用分析(1) 実行順序に着目した相互作用分析
ACC の相互作用を分析するために，シナリオに基づきシーケンス図を作成した(図 7)．シーケンス図から，次の二つのサービス提供パターンを発見できた．

サブスクリプション
サブスクリプション

ACC制御サービス
距離計算<<include>>
追従制御<<include>>
速度制御<<include>>
ブレーキ制御スロットル開度変更
ブレーキ強度変更
ブレーキ作動表示

対話型
サービス提供イベント通知イベント通知イベント通知イベント通知自律型
サービス提供図 7 ACC のシーケンス図1) 対話型サービス提供パターン：ユーザ要求により ACC制御サービスが起動．
2) 自律型サービス提供パターン：環境プロパティの変化
により ACC 制御サービスが起動され，プロパティの値を保持するために制御．

ACC 制御サービスはコンテキストに応じてエンジン制御サービスとブレーキ制御サービスの協調制御を行う．
(2) 要素間の関係に着目した相互作用分析
図7 のシーケンス図より，コミュニケーション図を作成し要素間の相互作用を分析した(図 8)．
イベントはイベントマネージャに通知され，サービスコーディネータに配信される．サービスコーディネータはイベン
トやサービスの要求に基づきサービスを起動する． サービ
スはサービスコーディネータを介して起動され，サービス間で直接メッセージのやり取りはしない．ブローカアーキテク
チャの適用でイベント処理とサービス起動を分離できた．
エンジン制御

レーダ
イベント
通知
車速センサ
イベント
通知
メインスイッチ

スロットル開度変更

イベント
通知

表示要求

ユーザ

スキッドコントロール

ディスタンス
コントロール

エンジンコントロール

制御状態

制御要求
ACC制御
ブレーキ強度変更/スロットル開度変更

par

提案するアーキテクチャの評価のために，6章の分析プ
ロセスにより従来のシステム，従来の SOA から構成されるシステムを分析，比較を行う．対象システムは ACC とする．
7.1. 従来 ACC システムの分析
7.1.1. 機能分析
(1) ユースケース分析
ACC は追従制御，速度制御，ブレーキ制御という三つの機能から構成される．アクタは仕様[5]に基づきユーザ，レーダ，ディスタンスコントロールコンピュータ，車速センサ，エンジンコントロールコンピュータ，スキッドコントロールコ
ンピュータとした．追従制御にはメインスイッチも関係するがユーザの操作なのでユースケース図には示さない．

ブレーキ制御要求

目標速度

メインスイッチ

スキッド
コントロール

目標速度
ブレーキ制御ディスタンス要求
コントロール
イベント通知イベント通知イベント
通知

イベント通知イベント通知イベント通知
エンジンコントロール

ユーザ

車速センサ

レーダ

エンジン制御ブレーキ制御ACC制御

表示

メインスイッチON
起動表示

スロットル開度変更

par

図 9 従来 ACC システムのユースケース図(2) シナリオ分析
図 9 のユースケース図に基づき ACC の開始から追従走行制御までのシナリオを作成した．
7.1.2. 相互作用分析(1) 実行順序に着目した相互作用分析
従来ACC システムの相互作用分析のためにシナリオに基づき，シーケンス図を作成し，分析した(図 10)．
(2) 要素間の関係に着目した相互作用分析
図 10 のシーケンス図より，コミュニケーション図を作成し要素間の相互作用を分析した(図 11)．
コンピュータとコンピュータが直接制御を行っており，コ

イベント通知7.2. 従来の SOA による ACC の分析
機能分析に関しては，6.1 節の分析結果を用いる．
7.2.1. 相互作用分析
従来の SOA による ACC の相互作用分析のために 6.1
節のシナリオよりシーケンス図を作成し，分析した(図 12)．

ディスタンスコントロール
コンピュータ
車速センサ
エンジンコントロール
コンピュータメータ
制御状態

図 11 従来 ACC システムのコミュニケーション図

レーダ

スキッドコントロール
コンピュータ

イベント
通知

制御状態

ACC

ブレーキ制御車速センサ

図 10 従来 ACC システムのシーケンス図

7. ACC によるアーキテクチャの評価

ユーザ

レーダ

目標速度
par

図 8 ACC のコミュニケーション図<<include>>
速度制御<<include>>

メインスイッチ

par

表示

追従制御

メータ

メインスイッチON

ブレーキ
制御

ブレーキ
強度変更

イベント配信イベント
サービス
マネージャ サブスクリプション コーディネータ

ンピュータ間の結合が強い．またセンサとコンピュータも直接イベント通知を行っているため，この二つの要素間でも結合が強い．
従って新しい機能，センサの追加や変更を行う際には，システムの大規模な変更が必要となる．センサのイベントはあらかじめ指定されたコンピュータにしか配信できず，イベント配信は固定的である．よってセンサのイベントが追加されたコンピュータで必要な場合に対応することが難しい．

メインスイッチ

レーダ

車速センサ

イベント
通知
par
イベント通知イベント通知parイベント通知
イベント通知スロットル開度変更
ブレーキ強度変更
ブレーキ作動表示

図 12 従来の SOA による ACC のシーケンス図
車速センサ，レーダのイベントが ACC 制御サービスに通知されているが，従来の SOA ではイベントを扱えない．またエンジン制御サービスやブレーキ制御サービスの実行
結果は間接的にユーザに作用し，従来の SOA の直接的なサービス提供形態とは異なる．
7.3. 提案アーキテクチャの評価
従来のシステム，従来の SOA と提案アーキテクチャをSOA，イベント，プロパティという三つの観点から比較を行い，評価した(表 1)．

表 1 ACC によるアーキテクチャの評価
評価の観点
SOA

イベント

プロパティ

評価項目
インタフェース形式
プラットフォー
ムへの依存性イベントの処理
イベントの配信制御
サービス
提供形態

従来のシステム
ベンダごとに異なる

標準化
されている

提案
アーキテクチャ
標準化
されている

依存

非依存

非依存

可能

不可能
イベントの処理はできない
直接的
サービス提供可能追加・変更が可能
直接的・間接的サービス提供固定的サービスは存在しない

従来の SOA(1) インタフェース形式
従来のシステムの場合，インタフェースがベンダごとに異なりソフトウェアの連携が困難であった．提案アーキテクチ
ャや従来の SOA ではインタフェースの標準化により，サービスの再利用性が高まり，車内のサービスとテレマティクスサービスの連携も容易となる．
(2) プラットフォームへの依存性
従来のシステムはプラットフォームに依存しソフトウェアの連携が困難である．一方，従来の SOA や提案アーキテ
クチャはプラットフォームに非依存で，プラットフォームが異なるベンダ間で開発されたサービスの連携が容易である．
(3) イベントの処理
自動車ソフトウェアはイベントにより制御を行うが，従来のSOA ではイベントを扱えない．従来のシステムはイベント処理が可能である．提案アーキテクチャでもイベントマネー
ジャとサービスコーディネータの連携により，イベント処理が可能である．
(4) イベントの配信制御
従来のシステムではセンサとコンピュータ間で直接イベント通知を行い，センサのイベント配信先は固定的である．
提案アーキテクチャはパブリッシュ/サブスクライブを用いてイベント配信先の追加と変更が可能となり，またイベントを複数サービスに配信できる．
(5) サービス提供形態
ACC ではサービスの実行結果が間接的にユーザに作用し，従来の SOA では対応できない．提案アーキテクチャ
ではプロパティに着目し制御を行うため，間接的なサービス提供が可能になる．
以上の議論より，提案アーキテクチャは SOA に基づく自動車ソフトウェアの実現に有効なアーキテクチャといえる．

8. 考察
8.1. ブローカアーキテクチャの妥当性
サービス提供を対話型，自律型に着目し，この分類からアーキテクチャパターンを決定した．自律型サービス提供にパブリッシュ/サブスクライブを用いることで同時多発的イベントに対して適切なサービスの提供が可能となる．
8.2. サービスの再利用性
図13 に ACC と CC(Cruise Control System)のユースケース図を示す．この図から ACC は CC に距離計算，追従制御とレーダの追加で実現可能であることがわかる．既存の機能に新機能を追加すれば一から開発を行う必要が無く，再利用により開発期間の短縮やコスト削減が期待できる．
a)クルーズコントロールシステムb)アダプティブクルーズコントロールシステム
ACCへの機能追加

速度制御

速度制御

車速センサ

<<include>>

エンジン制御サービス

ユーザ

ACC制御サービス<<include>>
距離計算
追従制御
<<include>>

ブレーキ制御CC制御サービス

ユーザ

ブレーキ制御サービス

図 13

ブレーキ制御CC制御サービス

レーダ

車速センサ
エンジン制御サービス
ブレーキ制御サービス

サービスの再利用

9. 関連研究9.1. 組込みネットワークへの SOA 適用
組込みネットワークシステムにおいて SOA を拡張する研究が行われ，ホームネットワークシステム（HNS：HomeNetwork System）に適用されている[1]．
9.2. AUTOSARAUTOSAR では，ネットワーク上でソフトウェアを連携することを主眼とし， ECU ソフトウェアに関する技術の研究が行われている[3]．しかし，ネットワークを介したアプリケーション間でのインタフェースの標準化は行われていない．

10. 今後の課題
本稿で検証した ACC は間接的サービス提供に限られ，直接的サービス提供を含むシナリオを検証する必要がある．
また，自動車ソフトウェアの SOA ではタイミング協調やリアルタイム性を考慮する必要がある．

11. まとめ
従来の SOA の直接サービス提供に加え，イベント起動と空間を介したサービス提供を含むプロパティ中心サービス提供モデルを提案した．ブローカを用いたアーキテクチ
ャを提案し，シナリオを用いて有効性を評価した．

参考文献
[1]

[2]

[3]
[4]

[5]

青山 幹雄，藤山 麻衣，組込みネットワークシステムのユニバーサルサービス指向アーキテクチャ，SES
2008 論文集, Sep. 2008, pp. 147-154.
青山 幹雄, ほか, 車載ソフトウェアのサービスプラッ
トフォームのモデルとアーキテクチャ, 自動車技術学会秋季論文集, 2008.
AUTOSAR, http://www.autosar.org.
I. H. Kruger, et al, Service-Based Software
Development for Automotive Applications, Proc.
Convergence 2004, No. 2004-21-0040 CTE, 2004.
トヨタ自動車，CROWN MAJESTA 新型車解説書，
2004.