自動車ソフトウェアの外部連携サービス指向アーキテクチャの提案
M2011MM030 伊藤 智基
指導教員 青山 幹雄

1. はじめに自動車テレマティクスサービスではサードパーティサービスとの連携が進んでいる．今後，オープンかつシームレスな連携が必要となる[1]．しかし，サービス連携においてプロバイダ毎に開発環境が異なり，サービス間のインタフェースが固定的となっている．また，車載ソフトウェアにはリソース制約や車内環境といった様々な制約があることから，指定時間内のサービス利用が困難となっている．

2. 研究の課題
本稿の課題として以下の二つを挙げる．
(1)プラットフォーム依存
車外サービスではサービスを提供するプロバイダ毎に開発環境が異なり，特定の車種やベンダでサービス間のインタフェースが固定的となっている．よって，異なるプラットフ
ォーム上での車載ソフトウェア機能の再利用や機能追加，テレマティクスサービスの利用といったサービス連携が困難となっている．
(2)イベント配信のタイミング
車載ソフトウェアには様々な制約がある．そのため，車内外で発生するイベントやメッセージを処理し，制御対象が指定した要求時間内にイベント配信を行い，利用することが困難となっている．また，発生イベントやメッセージは指定時間以前のタイミングに通知されても意味をなさない．

3. 関連研究
本稿と関連する研究として以下の三つを挙げる．
3.1. Publish/Subscribe Architecture
相互作用の疎結合の形態を提供する対話方式である[2]．
パブリッシャは特定のサブスクライバを想定せずにメッセージを送信する．サブスクライバは，ブローカにサブスクリプションを送信し，関心のあるメッセージのみ受信する．また，パブリッシャとサブスクライバは相互のエンドポイントを知る必要がなく，空間的に分離される．
3.2. WS-Notification
Web サービス間の非同期メッセージングを Publish/Subscribe 型で実現する技術である．WS-Notification はいく
つ か の 仕様か ら 構成さ れ て お り ， 基本的な 部分はWS-BasedNotification[3]で規定され，メッセージを分類する

Topic の構造を規定した WS-Topics，NotificationProducer とNotificationConsumer の間に仲介する NotificationBroker の役割を規定した WS-Brokered Notification の三つの仕様からなる．
3.3. 車載イベント駆動アーキテクチャの提案[4]車内外で発生するイベントをモデル化し，車載ブローカを導入することでイベントを共有するアーキテクチャが提案されている．SOA(Service-Oriented Architecture)の適用と，イベントモデルに基づくイベント配信の統一化によって車載イベントブローカのサービス化を行っている．

4. アプローチ
本稿では以下の 2 点に着目し，オープンかつシームレスな連携を実現する(図 1)．
車内(1)サービス化
センサ
車内サービス(2)Pub/Sub
センサ

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

I/F登録

I/F検索

レジストリ

車載ブローカ

サービス
I/F呼び出しイベントモデル
イベント配信
サブスクリプション
車外サービス機能

図 1 アーキテクチャの全体像
4.1. 車内外システムのサービス化
車内外のシステムをサービスとみなすことでオープンな連携を実現する．車内システムと外部システムの機能を標
準インタフェースを介して提供するサービスととらえる．これにより，特定の車種やプラットフォームに依存しない外部連携が実現可能となる．
4.2. Publish/Subscribe Architecture の適用
Publish/Subscribe モデルに基づく車載ブローカを導入することでシームレスな連携を実現する．コンシューマは車載ブローカにサブスクリプションを登録する．サブスクリプションの条件として通知タイミングを指定する．これにより，車内外サービスは指定したタイミングにイベント通知を受け取ることが可能となる．また，車内外では多くのイベント配信が行われている．Publish/Subscribe Architecture の空間的分離により相互のエンドポイントを知る必要はなく，多対多のイベント配信が可能となる．

5. 外部連携アーキテクチャの提案
提案アーキテクチャは，すべてのイベントを処理する車載ブローカと車内外サービスから構成される．車内外で発生するイベントをイベントモデルに基づいた分類を行い，提案アーキテクチャ内で処理し，オープンかつシームレスな連携を実現する．
5.1. イベントモデル
イベントモデルに基づきイベント情報の登録とサブスクリプションの登録を行う(図 2)．
イベント通知リクエスト

発生タイミング
イベント発生時刻

要求タイミング
要求開始時刻要求時間

周期通知

非周期通知周期発生時刻

非周期発生時刻図 2 イベントモデル
通知型とリクエスト型で保持する情報の違いに着目する．
通知型のイベントはセンサからのイベントであり，イベント発生時刻の情報を保持している．リクエスト型のイベントは車内外サービスである．リクエスト型はサービスであるため，イベント発生時刻とイベント処理完了までの要求時間を保持可能である．
通知型のサブタイプはセンサからのイベントなど，リクエストを期待しない場合であるため，要求タイミング型とは異なり時刻を表現する．センサからは定期的にイベントが発生する場合と，ユーザ操作など不定期にイベントが発生する場合が考えられる．よって，更に発生タイミング型を周期通知型と非周期通知型に特殊化し，時刻で表現する．周期通知型ではイベントの発生する間隔が一定であるため，周期発生時刻を定義する．非周期通知型ではイベント発生間隔が一定でないため，非周期に発生する非周期発生時刻として定義する．
5.2. 車載ブローカ
イベント情報の管理，イベント処理，タイミングの管理を行うために車載ブローカを拡張する．これらをイベントマネー
ジャ，サブスクリプションマネージャ，タイミングマネージャの三つのコンポーネントで実現する．
本稿では「プロデューサ」と「コンシューマ」のアクタが存在する．プロデューサはイベントの送信者であり，通知型のイベントまたはリクエスト型のイベントをメッセージとして送信する．例としてセンサや車内外サービスが挙げられる．コンシューマはイベントの受信者である．センサなど通知型のイベントの発生元がコンシューマとなることはない．

5.2.1. 車載ブローカのユースケース
車載ブローカのユースケースを図 3 に示し，拡張した点を示す．
車載ブローカイベント情報登録<<include>>

サブスクリプション登録<<extend>>

タイミングレベル<<include>>(4)更新，削除(2)タイミング条件付加

フィルタリング<<include>><<include>>

プロデューサ(3)タイミング制御
コンシューマイベント配信(1)インタフェース登録，検索，呼び出し

図 3 車載ブローカのユースケース図(1)インタフェース登録，検索，呼び出し
標準インタフェースを利用し，車内外サービス連携を実現する．車載ブローカのインタフェースを車外に公開し，車外のレジストリにインタフェース情報を登録しておく．車外
サービスは登録された車載ブローカのインタフェースを検索，呼び出すことで車内システムが利用可能となる．
(2)タイミング条件付加
サブスクリプションの登録としてタイミング条件を付加する
ことで，コンシューマはイベント配信のタイミングを指定する．
発生したイベントが指定した時刻以前に配信されても無効となる．また，指定時間を過ぎてからのイベント通知も無効となるため，そのサブスクリプションは有効期限切れとなり破棄される．
(3)タイミング制御
タイミング条件を満たすためにイベント配信のタイミングを管理しイベントを通知する．通知型イベントのようにタイミ
ング情報を保持していないイベントに対しては配信時間の情報を付加することでタイミングの制御を行う．リクエスト型
イベントのような配信時間の情報をあらかじめ保持しているイベントに対しては，その情報を基にタイミング制御を行う．
(4)サブスクリプションの更新，削除指定時間が変更された場合など，サブスクリプションの条件に変更があった際に，サブスクリプションの更新機能を行う．また要求時間内にイベントが配信されなかった場合など，イベント配信が無効となった際はサブスクリプションの削除機能を提供する．
5.2.2. 車載ブローカの構造
図 4 に拡張した車載ブローカの構造を示し，各コンポーネントの説明と関係を示す．
プロデューサコンシューマイベントDB
登録，参照
イベント登録イベント通知イベント
ディスパッチャイベント挿入(1)イベントマネージャ
キュー

サブスクリプション
登録，更新，削除
イベント照合イベント配信イベント取得(3)Subscription
マネージャ

登録，参照

イベント挿入要求(2)タイミングマネージャ

参照

サブスクリプションDB

図 4 車載ブローカの構造(1)イベントマネージャ
イベントマネージャはイベント情報の管理を行うコンポーネントである．プロデューサからのイベント通知をイベントモデルに基づきイベントデータベースに登録する．また，Subscription マネージャからサブスクリプションの照合をする際には，イベント情報をイベントデータベースに対して問い合わせを実行し，参照する．
(2)タイミングマネージャ
タイミングマネージャはイベント配信のタイミングなど，イベントにタイミング条件を付加し制御するコンポーネントである．サブスクリプションデータベースからコンシューマがサブスクリプション条件として登録した要求時間を参照する．
通知型イベントに対しては，イベント情報に通知タイミングを付加することでタイミングを制御し，キューに挿入される．
(3)Subscription マネージャ
Subscription マネージャはコンシューマからのサブスクリプションを管理するコンポーネントである．コンシューマからのサブスクリプションをサブスクリプションデータベースへ登録する．また，サブスクリプションの更新や削除が行われた場合にもデータベースへアクセスし管理する．その際，サブスクリプションの更新やキャンセルなどを行う．また，フィルタリングを行いイベントを配信する．
5.2.3. 車載ブローカの振舞い
イベント配信時のブローカの振舞いを図 5 に示す．
Subscription マネージャ，タイミングマネージャを用いて，(1)イベント登録，(2)サブスクリプション登録，(3)イベント配信の三つに分けて示す．
(1)イベント登録の振舞い
プロデューサはイベント情報として，イベント ID とタイミングレベルの登録を行う．タイミングレベルとは時間制約のことであり，制約が厳しい処理を優先的に実行することで時間制約を達成する．例えば，カーナビゲーションシステムにおいて，「GPS からの位置情報処理」は「ルート表示」よりも時間制約が厳しく，優先的に処理される必要がある．
(2)サブスクリプション登録の振舞い
コンシューマからSubscriptionマネージャにブスクリプションが登録されると，その条件を基にイベント照合を行う．
Subscription マネージャからイベントマネージャに照合依頼が通知され，イベントとサブスクリプション条件が一致した場合にイベント配信を行う．また，サブスクリプションの有効期限切れなどサブスクリプションに変更があった場合などは，コンシューマから再び Subscription マネージャに対して変更内容を通知し，サブスクリプションの更新を行う．
(3)イベント配信の振舞い
リクエスト型イベントの場合，要求時間をあらかじめ保持しているため要求時間に応じてイベントディスパッチャにイベントが通知される．通知型イベントの場合，イベント発生時刻は保持されているが要求時間は保持していない．そのためタイミングマネージャがサブスクリプション条件に基づき，要求時間の情報を付加してイベントディスパッチャにイベントが通知される．
プロデューサイベントマネージャ

コンシューマイベント
ディスパッチャタイミングマネージャ

Subscription
マネージャ

キュー

イベント情報登録

サブスクリプション送信
イベント照合opt[例外イベント時]
サブスクリプションの更新，削除依頼

opt

変更

[通知型イベント]

サブスクリプション参照

イベント通知イベント挿入依頼

イベント挿入イベント取得要求
フィルタリング
イベント配信図 5 車載ブローカの振舞い

6. テレマティクスサービスへの適用
本稿で提案した外部連携アーキテクチャ内において，イベント配信のタイミング管理がテレマティクスサービスの例
題で対応可能か確認する．テレマティクスサービスの例題
としてオートアラームシステム[5]とウォーニング通知[5]に適用し，評価を行う．
6.1. オートアラームシステムへの適用
オートアラームシステムでのユースケース分析の結果から抽出した機能は「センサ状態送信サービス」，「オートアラームセットサービス」，「アラーム通知サービス」，「車内検知サービス」の四つである．各サービスとアクタの関係を以下に表1にまとめ，提案を適用した際の振舞いを図6に示す．
表 1 オートアラームの構成サービスとアクタの関係
サービス名

対応アクタ

センサ状態送信サービス

プロデューサオートアラームセットサービス

プロデューサ，コンシューマ

アラーム通知サービス

コンシューマ

車内検知サービス

コンシューマプロデューサコンシューマ

イベント
マネージャ

イベント
ディスパッチャタイミングマネージャ

キュー

Subscription
マネージャ

イベント情報登録

サブスクリプション送信
イベント照合opt[例外イベント時]
サブスクリプションの更新，削除依頼

opt

変更

[通知型イベント]サブスクリプション参照

イベント通知イベント挿入依頼

イベント挿入イベント取得要求
フィルタリング
イベント配信図 6 オートアラームにおける車載ブローカの振舞い6.2. ウォーニング通知システムへの適用
ウォーニング通知システムでのユースケース分析の結果から抽出した機能は「センサ状態送信サービス」，「ウォーニング通知サービス」，「車両情報通知サービス」，「取り次ぎメール送信サービス」の四つである．各サービスとアクタの関係を表2 にまとめ，提案を適用した際の振舞いを図7に示す．
表 2 ウォーニング通知の構成サービスとアクタの関係
サービス名

対応アクタ

センサ状態送信サービス

プロデューサウォーニング通知サービス

プロデューサ，コンシューマ

車両情報通知サービス

プロデューサ，コンシューマ

取り次ぎ送信サービス

コンシューマ

販売店

ECU

マルチディスプレイ

G-BOOK
センタ

イベント
マネージャ

イベント
ディスパッチャ

タイミング
マネージャ

キュー

Subscription
マネージャ

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

サブスクリプション送信
イベント照合故障・障害通知タイミング要求

サブスクリプション参照

イベント挿入依頼
イベント挿入イベント取得要求
フィルタリング
通知型イベント配信

opt[通知不可]
サブスクリプションの更新，削除依頼変更
不可能通知

コンシューマのサブスクリプションの条件で指定した要求タイミングをタイミングマネージャが付加することで，コンシューマの要求時間内のイベント配信が可能となった．サービスなどあらかじめ時間情報を保持しているイベントに対しては，要求時間を付加する必要はない．サービスのサブスクリプションの条件に従い，Subscription マネージャがタイミングの管理を行うことで配信が可能となった．
また，例題では通知タイミングが変更された場合の処理として，サブスクリプションの変更などを行っている．これによりコンシューマの要求時間や通知タイミングの変更に対し，サブスクリプションの更新を反映することでイベント配信のタイミングを変更することで対応可能となった．
従って，センサやサービスなど保持する情報が異なるアクタからのイベント通知を統一的に管理，変更，削除を行うことによる，統一的なイベント配信が可能となった．

8. 今後の課題(1)プロトタイプを実装しての検討
実際にプロトタイプを作成し，サービスが指定したタイミング以内に利用可能であるかを検証する必要がある．
(2)例外処理の検討
例外イベントなどが発生した場合の例外処理について考慮されていないため検討する必要がある．その後，イベントを再送信する処理についても考慮する必要がある．

対処方法依頼要求

イベント挿入イベント取得要求
フィルタリング
リクエスト型イベント配信
対処方法取得図 7 ウォーニング通知における車載ブローカの振舞い

7. 提案アーキテクチャの評価
提案アーキテクチャをテレマティクスサービスの例題に適用した結果を用いて，多様なイベントへの対応，イベント配信のタイミングの観点から評価する．
(1)多様なイベントへの対応
車内外では多くのセンサやサービスからのイベント配信が行われている．例題ではセンサからのイベント通知やサービスからのイベント通知が行われている．それぞれがプロデューサ，コンシューマ，または両方の可能性がある．リクエストを期待するアクタ，リクエストを期待しないアクタと多様である．オートアラームシステムでは通知型のイベント配信のみの処理である．ウォーニング通知では，リクエスト型と通知型の両方からのイベント配信が行われている．イベントモデルを用い，イベント照合を行うことでいずれのケースでもイベントを識別することが可能となり，それぞれのイベントに合った処理を行うことが可能となった．
(2)イベント配信のタイミング
センサなど時刻情報しか保持しないイベントに対して，

9. まとめ
本稿では，外部連携サービス指向アーキテクチャを提案した．提案アーキテクチャでは，車内外システムをサービスとみなし，標準技術を用いることでオープンな連携を提案した ． シ ー ム レ ス な 連携を 実現す る た め に Publisher/
Subscribe モデルに基づく車載ブローカを導入し，イベント配信のタイミング管理を行った．提案アーキテクチャをテレマティクスサービスに適用し，有効性を示した．

参考文献[1] 青山 幹雄，ほか，車載ソフトウェアのサービスプラット
フォームのモデルとアーキテクチャ，自動車技術会 2008
年秋季大会 学術講演会前刷集，No. 97-08, Oct. 2008, pp.
21-26.
[2] P. T. Eugster, et al., The Many Faces of Publish/Subscribe,
ACM Computing Survey, Jun. 2003. pp. 114-131.
[3] OASIS, Web Services Base Notification 1.3(WS-BaseNotification), 2006, http://docs.oasis-open.org/
wsn/wsn-ws_base_notification-1.3-spec-os.pdf.
[4] 武野 佑基，ほか，SOA に基づく車載イベント駆動アー
キテクチャの提案，情報処理学会 第 74 回全国大会 講演論文集，Vol. 1, Mar. 2012. pp. 369-370.
[5] トヨタ自動車，Lexus LS 電子技術マニュアル，2006．