SOA に基づく車載イベント駆動アーキテクチャの提案
M2010MM039 武野 佑基
指導教員 青山 幹雄

1. はじめに
近年，自動車では車内外でソフトウェア連携が多く導入されている．車載ソフトウェアでは複数の ECU が車載ネットワークを介して協調制御を行っている[2]．車外との連携では車の状態を遠隔で確認する情報取得やドアロックなどの遠隔操作を提供する車外サービスが普及し始めている[3]．自動車は今後，機能拡張，サードパーティサービスなどの利用が予想され，車内外で発生するイベントをオープンかつシームレスに共有する必要がある．

2. 研究課題
イベントを共有する時，現在の車載ソフトウェアアーキ
テクチャでは以下の 3 点の問題が挙げられる．
(1) イベント配信がハードウェアの仕様に固定的
車載ソフトウェアでは各 ECU が保持しているセンサ情報の送信フレームに ID を付加し，他の ECU がその ID を指定することでイベントの配信を行っている．しかし，ID は各自動車のネットワーク，ECU 仕様に依存しており，センサの数，ネットワーク構成が異なる自動車の間で共通ではなく，車内外でセンサのイベントの一意な特定が困難である．
(2) 車内外におけるイベントの配信方法の制限
車内外でイベント配信を行う場合，各サービスは周期性，イベントソース，セマンティクスなどのイベントの特性や，センサデータの値によってイベントを配信する必要がある．
しかし，現在の車載ソフトウェアでは ID によるイベントの配信に限られている．
(3) ソフトウェアの連携が車種，車外サービスに固定的車載ソフトウェアや車外サービスのプラットフォームは異なるため，特定の車種，車外サービス間でインタフェース，イベントのメッセージング方式などが固定的となっている．
よって，車載ソフトウェアの機能追加，サードパーティ Webサービスの利用が困難である．

3. 関連研究3.1. NGTPNGTP(Next Generation Telematics Pattern)はテレマティックスサービスのプロトコルの標準仕様である[3]．自動車とサーバ間の API が定義されており，本稿では車外サービスからのイベントと考える．

3.2. WS-Notification
Web サービスにおいて，トピックベースフィルタリングを用いた PSA(Publish/Subscribe Architecture)に基づくイベント配信の仕様である[4]．

4. アプローチ
本稿では車内外で発生するイベントをモデル化し，PSA を適用した車載イベント駆動アーキテクチャを提案する(図 1)．PSA の空間的分離によってハードウェア構成を隠ぺいする．イベントモデルにはイベントの特性を表現できる型と属性を定義し，ブローカはその定義に基づいたタイプ
ベ ー ス の イ ベ ン ト 配 信 を 行 う [1] ． ま た ， SOA(Service-Oriented Architecture)の適用と，モデルに基づくイベント配信の統一化によって車載イベントブローカのサービス化を行う．
In-Vehicle
車速GPS情報

…

センサ
センサ

企業システム
携帯電話

イベント

ユーザ操作
センサ

イベント

制御サービス

サブスク
リプション

制御
アクチュエータ
アクチュエータエンジン

Out-Vehicle(2)車載イベントブローカ
イベント識別(1)イベントモデル

照合
イベントパーサ
値取得
フィルタリング

イベント配信ドアロック …

イベント
サブスク
リプション

ディスパッチャイベント配信…

テレマティックス
プロバイダ

サードパーティ
Webサービス…

(3)標準インタフェース

図 1: 車載イベント駆動アーキテクチャ

5. イベントモデルの提案
5.1. イベントの定義
イベントとは，車内外のサービスを駆動するトリガであり，全てのサービスの駆動はイベントの配信に依存する．また，イベントには通知とリクエストの 2 種類がある．通知とは送信先を想定せず状態変化及び状態通知を具体化するメッセージである．通知の例として車載センサからのイベントなどがある．リクエストとは送信先をあらかじめ指定し，場合によっては処理後にレスポンスを要求するメッセージである．リ
クエストの例として NGTP1.0 の 3 層アーキテクチャにおけるApplicationServiceLayer で定義されている Remote Serviceがある[3]．Remote Service では車外から車載アプリケーションサービスに対し，車両状態の取得もしくはアクチュエータの駆動要求を送信する．処理実行後，そのレスポンスとして車両状態やアクチュエータ駆動後状態を返す．

5.2. イベントモデルの提案
車内外で発生するイベントを統一的に表現できるイベン
トモデルを提案する(図 2)．
イベントプロトコル
イベントサイズ
イベントソース
周期性
時間単位

通知

リクエスト
リクエストデータ
サービスセマンティクス

付加情報
イベントセマンティクス周期通知
周期間隔

非周期通知
制限・非制限型
最小間隔
最大間隔

アクチュエータ駆動
WCET
タイムアウト時間

図 2: イベントモデルのクラス図
イベント型のサブタイプは通知とリクエストの違いに着目している．リクエストは決められたデータを特定のコンポーネントに送信するのに対し，通知ではイベントがどのようなデータを保持しているかを表現する．必要な属性が異なっており，別の型として定義する．
イベント型のサブサブタイプはタイミング制約に着目している．通知型のサブタイプでは実行時間の要求がないため，周期性を表現する．周期的イベントはその発生間隔を属性として保持する．非周期的イベントは制限性を表現する属性と制限型の場合にその発生の最大，最小間隔の値を持つ．また，リクエスト型のサブタイプとして WCET とタイ
ムアウト時間を表現するアクチュエータ駆動型を定義する．
これは情報取得のリクエストと区別するためである．

以下に拡張した機能の概要を説明する．
(1) イベント情報登録
提案アーキテクチャにおいて，実際に配信されるイベントは「動的に変化する情報」と「一意に識別できる情報」のみ保持する．イベントモデルに基づいてサブスクリプションと優先度処理を行うために，実際にイベントを送信する前にイベントモデルに基づく情報をあらかじめブローカに登録する処理である．
(2) レスポンス処理
リクエスト型のイベントは通知と異なり，送信者はレスポンスを待つ場合がある．PSA の基本機能は通知の配信のみを想定しているため，リクエスト型イベントに対するレスポンスを配信する機能を拡張する．
(3) 処理優先度決定
ブローカが受信したイベントを配信する優先度を算出する．本研究ではブローカ内での算出のタイミングを提案する(表 1)．
表 1: 優先度の算出
優先度更新のタイミング
イベント情報登録時
サブスクリプション登録時

6.2. ブローカの構造
上述の機能を実現するブローカのアーキテクチャの構成を図 4 に示す．
ServiceRequester

車載イベントブローカ
イベント情報登録
Notification
Producer<<include>>
処理優先度決定<<include>>

サブスクリプション
登録

レスポンス処理
エンドポイント付加<<include>><<include>>
Notification
Consumer

ServiceRequester

イベント配信<<include>>タイプベースフィルタリング<<include>>
イベントパーサ

Service
ProviderNotification
Producer

6. 車載イベントブローカの提案
6.1. ブローカのユースケース
車載イベントブローカの機能を図3 に示す．基本機能はタイプベース PSA に基づいているが，車載ドメインの性質及びイベントモデルの定義より「処理優先度決定」と「レスポンス処理」，「イベント情報登録」を拡張する．アクタは通知型 の イ ベ ン ト を 送 受 信 す る Notification Producer とNotification Consumer およびリクエスト型のイベントを送受信する Service Requester と Service Provider である．

ServiceProvider

図 3: 車載イベントブローカのユースケース図

優先度算出に用いる情報
イベントモデルで定義されているタイミング属性と登録済みイベントの情報
サブスクリプションメッセージに付加するクリティカル要求

Notification
Consumer

車載イベントブローカ
レスポンス配信

レスポンス

レスポンス
マネージャ

イベント情報イベントマネージャ
登録参照

イベント情報ストア

イベントディスパッチャ

イベントリクエ
スト
配信
挿入

通知
配信

優先度
キュー

取り出し
問合せ
優先度
更新依頼 サブスクリプション
マネージャ
マネージャ

更新依頼
更新

参照

優先度テーブル

参照
サービスエンドポイントストア

登録

サブス
クリプ
ション

参照

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

図 4: 車載イベントブローカの構造図
主な構成要素の機能を説明する．
(1) イベントマネージャ
ブローカで扱うイベントに関してイベントモデルに基づいた情報を管理する．また，イベント情報を登録すると同時に優先度マネージャに優先度決定処理を依頼する．
(2) 優先度マネージャ
イベント情報登録時，サブスクリプション登録時にイベント処理優先度を算出，登録する．イベント受信時にはイベントディスパッチャから優先度参照処理を依頼される．

(3)イベントディスパッチャ
イベントを受信するコンポーネント．受信したイベントを識別し，適切な優先度キューに挿入する．
(4) サブスクリプションマネージャ
イベントの配信処理をする．優先度キューからイベントを取り出し，送信先エンドポイントを付加して配信する．通知型イベントであればフィルタリングを行った上でエンドポイントを付加する．

7. 提案アーキテクチャの検証と評価
提案アーキテクチャを例題に適用し，その妥当性評価を行う．例題には ACC(Adaptive Cruise Control System)[5]，NGTP[3]を用いる．
7.1. ACC への適用
(1) 提案アーキテクチャにおけるアクタへの対応付け
ACC を構成している既存のサービスを抽出し，提案アーキテクチャでのアクタとの対応を確認する．ACC の車間
維持走行機能は図 5 に示すように構成されている．

表 3: ACC のセンサへの適用例
イベント名型

速度
ACC 起動
目標速度増
目標速度減
ブレーキ
先行車検知
先行車距離
相対速度
ステアリング
減速要求

ソース

付加情報/リク
エストデータ
速度 S
速度
メイン SW
なし
セット SW
目標速度増加レジューム SW
目標速度減少ブレーキペダル
踏込量
レーダーS
先行車有無
レーダーS
先行車距離
レーダーS
相対速度
ステアリング S
操舵角
車間制御サービス 制動トルク

周期通知
非周期通知
非周期通知
非周期通知
非周期通知
周期通知
周期通知
周期通知
周期通知
アクチュエータ駆動
アクチュエ 車間制御サービス 駆動トルクータ駆動

加速要求

(3)

ACC 実行時の振舞いの例
ACC において，レーダセンサの値を受信し，ブレーキ制御を駆動する場合の振舞いを図 6 に示す．
レーダセンサ

ブレー
キ制御

車間制御

優先度
マネー
ジャ

イベント
ディスパッチャ

イベント
マネージャ

優先度
キュー

サブスクリ
プション
マネージャ

イベント情報登録
イベント情報登録

ACC:車間制御モード

ストア登録
優先度登録依頼

アクセルセンサ
速度制御

レーダーセンサ

サブスクリプション送信

レーダセン
サドライバ
スロットル
アクチュエータ

イベント情報の照合<<include>><<include>>
車間制御

ACCスイッチ<<include>>

アクチュエータ駆動型イベント送信

opt

速度センサ

対応アクタ
Notification Producer，Service Provider

レーダセンササービス

Notification Producer

車間制御サービス

Notification Producer，Service Requester，
Notification Consumer
Service Provider，Notification Consumer，
Notification ProducerNotification Consumer

表示サービスキュー挿入
イベント取り出し

速度制御サービス(2)

イベント識別優先度取得

表示

図 5: ACC の車間維持走行のユースケース図
図 5 から ACC の車間維持走行は「速度制御サービス」，「レーダセンササービス」，「車間制御サービス」，「ブレーキ制御サービス」，「表示サービス」の 5 つのサービスから構成されることが分かる．抽出されたサービスと提案アーキテ
クチャにおけるアクタの対応付けを表 2 に示す．
表 2: ACC を構成するサービスの対応アクタ

ブレーキ制御サービス

周期通知型イベント送信

ブレーキ
アクチュエータ

コンビネーション
メータ

サービス名

ストア登録
loop

ブレーキ制御ブレーキペダル

優先度更新依頼

ステアリングセンサ

ACC におけるイベントへのイベントモデルの適用
イベントモデルを ACC で用いられるセンサ類，駆動要求へ適用した結果を表3に示す．速度値など，イベントが値を持つ場合は付加情報属性で表現する．

[通知型イベント]
フィルタリング

エンドポイント付加
周期通知型イベント配信
アクチュエータ駆動型イベント配信

図 6: ACC におけるブローカの振舞い
7.2. NGTP への適用
(1) NGTP における API へのイベントモデルの適用
NGTP へ の 適 用 に よ る 評 価 で は NGTP1.0 のApplicationServiceLayer で定義されている API の一部をイベントモデルに適用した結果を表 4 に示す．型の決定基準はリクエスト内容に依存する．
表 4: NGTP1.0 の API への適用例
イベント名
Remote Car Data
Remote Door Control
I-CallConditional Action

型
リクエスト
アクチュエータ駆動
リクエスト
リクエスト

ソース
車外
車外
車内
車内

周期性
非周期
非周期
非周期
周期

(2) Remote Door Lock 実行時の振舞いの例
Remote Door Lock を提案アーキテクチャで実行した場合の振舞いを図 7 に示す．関連するサービスは表 5 のようにアクタに対応づけられる．

表 5 Remote Door Lock
サービス名
車外サービス
ドアロックサービス
車外サービス

ドアロックサービス

対応アクタ
Service Requester
Service Provider

イベント優先度
ディスパッ
マネー
チャ
ジャ
イベント情報登録

イベント
マネージャ

優先度
キュー

サブスクリ
プション
マネージャ

レスポンス
マネージャ

ストア登録

優先度登録依頼
アクチュエータ駆動型イベント送信
イベント識別確認
優先度取得
キュー挿入
イベント取り出し
エンドポイント付加
ドアロック実行

アクチュエータ駆動型イベント配信
レスポンス送信イベントソース確認
レスポンス配信

図 7: Remote Door Lockにおけるブローカの振舞い
7.3. 評価
提案するアーキテクチャを例題へ適用した結果を基に以下の 4 点で評価する．
(1) 多様なイベントへの対応
イベントモデルを用いることにより車内外で発生するイベントを一意に識別する．ACC に関連するセンサのイベン
トおよびサービスからのリクエスト，NGTP で定義されているAPI をイベントモデルの型に適用することが可能であり，サブスクリプションの際のフィルタリング条件も車内，車外に関わらず型と属性に基づいて指定することができる．
(2) イベントの統一制御
イベントモデルからも分かるように，インタラクションに着目するとイベントは通知型イベントとリクエスト型イベントに大きく分けられる．提案アーキテクチャではこの両者のインタラクションの違いをサブスクリプションマネージャが吸収し，統一的制御を可能にする．例題では周期通知型イベン
トとして発生する ACC のレーダセンサのイベントに関してはフィルタリングを行い，アクチュエータ駆動型として発生する NGTP のドアロック要求ではエンドポイントを付加してサービスへ配信する．サブスクリプションマネージャでの処理が異なるのみで他の処理プロセスはイベント型に依存せずに処理することが可能である．
(3) 既存サービスの提案アーキテクチャへの置換え
提案アーキテクチャを車内外の既存サービスへ適用する場合，サービスの振舞いとして提案アーキテクチャにおける既存サービスのアクタを決定する必要がある．本研究ではサービスが送受信するイベントの型によって．そのアクタを決定できる．例題では，ユースケース分析から抽出したACC のサービス群の機能から，送受信するイベントを判断し，アクタへの割り当てを行った．また，NGTP で想定されているサービスはそのイベント分析から，Service Requester として振舞うことが分かる．このように各サービスのアクタをイベントから判断することが可能である．アクタには提案アーキテク

チャにおける振舞いが定義されているため，対応アクタを基にそのサービスが実装するインタフェースのオペレーション，サービスが呼び出すブローカのオペレーションを確定できる．
(4) 車外サービス構築の容易性
NGTP への適用から分かるように，提案アーキテクチャ
では現在提供されている標準的な車外サービスにもService Requester として対応可能である．同時に，車載センサから発生する通知型イベントをサブスクリプションすることで，車外からリアルタイムに自動車情報を取得できる．これら よ り ， 提案ア ー キ テ ク チ ャ で は 車外で Notification
Consumer と Service Requester を実装したサービスを構築することで，リアルタイムな車両状態の変化に対応したコンテキストアウェアな車外サービスの構築が容易となる．

8. 今後の課題(1)

完全なタイプベースフィルタリングの実現
本来のタイプベースフィルタリングでは静的条件は型の指定であり，動的条件は属性値を指定する．提案モデルには動的に属性値が変化しない属性があり，サブスクリプションでその属性値を指定した場合は型以外の静的条件でフィルタリングする．完全なタイプベースフィルタリングを行うには固定値を取る属性を型として汎化する必要がある．
(2) 優先度算出アルゴリズムの提案と検証
本研究では優先度マネージャに実装する算出アルゴリ
ズムは未定義である．アルゴリズムはクリティカル性とタイミング要求という異なる性質の値から算出できる必要がある．
また，車種毎に異なるアルゴリズムを用いる可能性もある．

9. まとめ本稿は車内外で発生するイベントのオープンかつシームレスな共有を目的としている．現状の車載ソフトウェアアーキテクチャの問題点を指摘した上で，アプローチとしてSOA に基づく車載イベント駆動アーキテクチャを示し，イベントモデルと車載イベントブローカを提案した．提案内容はACC と NGTP に適用して評価をした．

参考文献[1] P. T. Eugster, et al., The Many Faces of Publish/Subscribe,
ACM Computing Survey, Jun. 2003. pp. 114 -131.
[2] 加藤 光治, 図解 カーエレクトロニクス〈下〉要素技術編,
日経 BP 社, 2010.
[3] NGTP(Next Generation Telematics Pattern), 2011,
http://www.ngtp.org/.
[4] OASIS, WS-BaseNotification,
Ver. 1.3,
2006,
http://docs.oasis-open.org/wsn/wsn-ws_base_notification-1.
3-spec-os.pdf[5] トヨタ自動車, CROWN MAJESTA 新型車解説書, URS
206 / UZS207, Mar. 2009.