自動車ネットワークサービスの連携アーキテクチャ
2007MI028 濱千代 正弥 2007MI093 片桐 雅仁 指導教員 青山 幹雄1. はじめに
近年，車載システムと外部ネットワークシステムが連携 する自動車ネットワークサービスが実用化されている．しか し，この連携にはインタフェースやプロトコルの違いと，車 載システムが組み込みシステムであるため処理能力の制 約という問題がある． 本稿で は， これ ら の問題を解決す る た め に SOA (Service-Oriented Architecture)[5]を適用する．自動車の外 部ネットワークシステムと車載システムの機能を標準インタ フェースを介して提供するサービスととらえ，連携可能なソ フトウェアアーキテクチャを提案する．2.
研究の背景
本稿では，車外サービス連携に着目する．車外サービス 連携とは，車載システムと自動車の外部ネットワークシステ ムの連携と定義する． 現状の車外サービス連携では，サービスを提供するプロ バイダごとにインタフェースやプロトコルが固有である．そ のため，サードパーティサービスの利用や異なるサービス 間のサービス連携も困難である(図 1)． 図1 車外サービス連携の現状3. 研究課題
サードパーティサービスの利用や異なるサービス間の サ ー ビ ス 連 携 を 容 易 に す る た め ，SOAP や REST (REpresentational State Transfer)などの Web サービスで標準 化されたメッセージプロトコルを適用することが考えられる． また，SOAP に準処したメッセージを SOAP メッセージ， REST に準処したメッセージの一つを POX メッセージと呼 ぶ．これらを車外サービス連携に適用するにはプロトコルの変換が必要となる．
しかし，現状のECU(Electronic Control Unit)では，処理 能力の制約が厳しいため，CAN(Controller Area Network) やMOST(Media Oriented Systems Transport)などの車載ネ ットワークに対して，SOAP メッセージや POX メッセージの プロトコル変換を個別のECU で行うことは困難である．よっ てECU で行うのではなく，新たにプロトコル変換を行うシス テムを追加する必要がある．
4. 関連研究
4.1. OSGi(Open Service Gateway initiative)
OSGi[7]は家電製品をインターネットに接続し，パソコン や機器間で相互にサービスを提供するための仕様であり， ホームネットワークでのゲートウェイの機能を持っている． OS 上で JVM(Java Virtual Machine)がプロセスとして実行さ れ，そのプロセス上でJava 言語により記述されたミドルウェ アであるOSGiフレームワークが動作する．この上にBundle と呼ばれるプラグ&プレイ可能なソフトウェアコンポーネント がインストールされ実行される． また，OSGi 仕様では，多くの開発者にとって利用価値 が高い共通的なサービスとユーティリティクラスを定義して いる．これらを Bundle の形態で提供されたものを Basic Service Bundle と呼ぶ．一方，各事業者や機器に依存し標 準化されていないBundle を Application Bundle と呼ぶ． 4.2. SCSN(Smart Car Sensor Network)
SCSN プラットフォーム[8]は，車載システムの中でも追 加や変更が特に多いセンサに対応するために提案されて いる．また，SCSN プラットフォームは OSGi フレームワーク を基盤としたアーキテクチャである． 4.3. 軽量 Web サービスアーキテクチャ Web サービスのメッセージ交換では，主に SOAP が利 用されている．しかし，SOAP 構文の生成や解析に多くの 処理が必要となるため，性能低下が問題となる．この問題 に対し，メッセージ交換の手段としてREST を利用したアー キテクチャを提案している[3]．また，提案を検証するために プロトタイプを開発し，応答時間を比較している．
5.
アプローチ
本稿では，プロトコル変換の必要性に着目し，ゲートウェ イの機能を持つ車載サービスブローカを提案する(図 2)． 車載サービスブローカでプロトコル変換を行うことにより， SOAP/REST を用いた車外サービス連携が可能となり，サ ：現状での車外サービス連携 ：現状では困難な車外サービス連携 自動車メーカAの 車載システム 自動車メーカBの 車載システム 外部システム サードパーティ サービスd サービスc Web プロバイダB サービスf サービスe プロバイダA サービスb サービスa ECU4 ECU5 ECU6 ゲー ト ウ ェ イ ゲー ト ウ ェ イ ECU2 ECU3 ECU1ードパーティサービスの利用や異なるサービス間のサービ ス連携を容易にする． プロトタイプ実装によりSOAP メッセージと POX メッセー ジを比較し，サービス間連携の性能評価を行うことで，提案 するアーキテクチャの妥当性を示す． 図2 車外サービス連携モデル
6. 提案方法
6.1. 車載サービスブローカのアーキテクチャ プロトコル変換を行う車載サービスブローカ[6]を用いた ソフトウェアアーキテクチャを提案する(図 3)． また，この車載サービスブローカには OSGi フレームワ ークを用いる．OSGi では，プロトコル変換の機能を持つ Bundle が標準化されて，提供されており，SOAP/POX メッ セージの利用が容易である．さらに，複雑化している車載ソ フトウェア開発に対して，Bundle を用いたモジュール化によ り開発効率，運用効率の向上が図れる．車載サービスブロ ーカのOSGi フレームワーク上に以下に挙げる機能を持つ 四つのBundle を実装する． a) テレマティクスサービスの機能を持つ Telematics Application Bundle b) SOAP/POX メ ッ セ ー ジ の 生 成 と 解 析 を 行 う SOAP/POX Proxy Processor Bundlec) HTTP による通信を行う HTTP Server Bundle d) CAN Gateway を通して車載ネットワークへ通信を行う
Interface Gateway Bundle
これらの Bundle が連携して動作することで車載ネットワ ークと外部システムのサービス連携を実現する． 図3 車載サービスブローカのアーキテクチャ 6.2. Bundle 間連携 Bundle 間連携とは，車載サービスブローカ内の OSGi フ レームワーク上の異なる Bundle 同士の連携である．OSGi の機能であるパッケージの公開と読み込み，サービスの登 録，検索と取得を利用することで実現される(図 4)． 図4 Bundle 間連携 6.3. 外部システムとの連携 外部システムとの連携とは，車載サービスブローカと外 部システムとの連携である．Telematics Application Bundle がSOAP/POX Proxy Processor Bundle，HTTP Server Bundle と連携し，サービスプロバイダが提供する外部システムの サービスと連携を行う．また，SOAP/POX Proxy Processor Bundle と HTTP Server Bundle は 4.1 節で説明した Basic Service Bundle を複数まとめた総称である．
6.4. 車載ネットワークとの連携
車載ネットワークとの連携とは，車載サービスブローカと 車載ネットワークの連携である．Telematics Application Bundle が Interface Gateway Bundle と連携して CAN Gateway と連携を行う．Interface Gateway Bundle を実現する ことで車載ネットワーク内の実装が変更された場合にも Interface Gateway Bundle を変更するだけで対応可能である． Interface Gateway Bundle と CAN Gateway により Telematics Application Bundle と ECU 間の連携が可能となる．
7. 車載サービスブローカのプロトタイプ
Web サービスのインタフェースを用いた接続性と応答時 間の性能を評価するためオープンソースのOSGi フレーム ワークである Knoplerfish を用いてプロトタイプを開発した [1,4]．CAN Gateway と ECU はスタブとして Java で実装を行 い，Interface Gateway と CAN Gateway 間，CAN Gateway と ECU 間には TCP 接続を用いる(図 5)． 図5 プロトタイプ構成 外部システム We b サー ビ ス プロ バ イ ダ WS DL We b サー ビ ス プロ バ イ ダ WS DL POX メッセージ SOAP メッセージ 車載システム 車内 サ ー ビ ス イン タ フ ェ ー ス ゲー ト ウ ェ イ WS DL 記述 イン タ フ ェ ー ス 車載サービスブローカ HTTP HTTP 車載 ネット ワーク ECU ECU ECU 車載 システム 車載サービスブローカ CA N G ate W ay JVM OSGi Framework In te rfa ce Ga te w ay Te le m at ic s A ppl ic at ion s 外部 システム WS D L We b サー ビ ス プロ バ イ ダ We b サー ビ ス プロ バ イ ダ WS D L HT T P S er ver HTTP SOAP メッセージ POX メッセージ SO A P /P O X Pro xy Pro ce sso r B und le 間連 携 B und le 間連 携 B und le 間連 携 車載 ネット ワーク ECU ECU ECU HTTP start() start() Bundle B MANIFEST
File ・・・ ActivatorClass Bundle A
・・・ MANIFEST
File ActivatorClass
registerService() getServiceReference() getService() OSGi Framework 外部システム 車載 システム 車載サービスブローカ PC3 PC4 PC2 PC1 CAN Gateway スタブ In te rfac e Ga te w ay HT T P S er ve r SO AP/ PO X P rox y P roc es so r ECU スタブ Telematics Application ドア ロ ッ ク A pplic at ion うっ か り 通知 A pplic at ion WS D L JVM JVM Apache Tomcat サー ブレ ッ ト A pac he Ax is 2 We bサー ビ ス ネットワーク環境：TCP/IP, 100Mbps HT T Pサー バ JVM Knopflerfish(OSGi Framework) PC1
(ECU) PC2(CANGateway) PC3(OSGiFramework) PC4(外部システム) OS Windows XP SP3 Windows XP SP3 Windows XP SP3 Windows XP SP3 メモリ 2.00GB 1.00GB 1.00GB 2.00GB CPU Intel Celeron(R)M 2.00GHz Intel Pentium(R)4 2.00GHz Intel Pentium(R)4 2.00GHz Intel Celeron(R)M 2.00GHz
テレマティクスサービスの例として，以下の二つのサー ビスを実装した． (1) うっかり通知サービス うっかり通知サービスは，自動車の鍵の閉め忘れを検 知し，所有者に通知する(図 6)． 図6 うっかり通知サービスのシーケンス図 (2) リモートドアロックサービス リモートドアロックサービスは，携帯電話などの機器を 用いて，外部からドアロックを行う(図 7)． 図7 リモートドアロックサービスのシーケンス図
8. プロトタイプによる評価
8.1. Web サービスのインタフェースを用いた接続性 提案した車載サービスブローカを用いて，車載サービス ブローカと外部のWeb サービスが接続可能であり，車載シ ステムと外部システム間の双方向の通信が可能であること を確認した． 8.2. 外部システムとの連携の性能評価 うっかり通知サービスの外部システムとの連携処理の性 能を測定した．そのため，実行回数，データ量による応答 時間を測定するために，外部システムとの連携を非同期で はなく，受け取った文字列をそのまま返す同期に変更を行 い，応答時間を測定した． 8.2.1. 実行回数による応答時間の変化 サービスリクエスタが文字列データ(100Byte)を送信し， 返り値としてデータをそのまま受信する．実行回数を変化さ せて応答時間を測定した．図8 に SOAP メッセージ，図 9 に POX メッセージの実行回数による応答時間を示す． 図8，図 9 よりほぼ一定周期で異常に大きな遅延が発生 している．これはJVM のガベージコレクションによると推定 される．そこで平均値の約2 倍以上を特異値とし，SOAP メ ッセージは20 ミリ秒以上，POX メッセージは 10 ミリ秒以上 を特異値とした．この特異値を除いた平均応答時間を補修 値とした．測定値と共に補修値を図10 に，補修値の平均応 答時間と標準偏差を表1 に示す．平均応答時間に対し，標 準偏差が約5%であることからデータのばらつきが少ないと いえる． 図8 SOAP メッセージによる応答時間 図9 POX メッセージによる応答時間 図10 実行回数による応答時間 表1 平均応答時間と標準偏差 8.2.2. データ量に対する応答時間の変化 送信するデータ量の増加によるSOAP メッセージと POX メッセージの応答時間の変化を測定した．測定には， 車載 システム 外部システム 車載サービスブローカ HT T P Se rv e r Se rv ic e A p pl ic at io n HT T P Se rv e r In te rfa ce Ga te w a y OSGi Framework CA N Ga te w a y EC U TCP SOAP (POX) TCP TCP TCP S endS tat us () S O AP/ PO X Pr o x y P roc es s o r S O AP/ PO X Pr o x y P roc es s o r out.println()out.println() RdsPost() RdsGet() RdsPost()RdsPost() RdsPost() RdsPost()
Ge tS ta tu s() 車載 システム 車載サービスブローカ 外部システム H TTP Se rve r Se rvi ce A pplic at ion H TTP Se rve r In te rfa ce Ga te w a y OSGi Framework CA N Ga te w a y EC U TCP SOAP (POX) TCP SOAP (POX) TCP TCP SO AP/ PO X Pro x y P roc es s o r SO AP/ PO X Pro x y P roc es s o r D oor Loc k() RdlRequest() RdlRequest() RdlRequest() RdlRequest() RdlRequest() dlRequest() out.println() out.println() 0 10 20 30 40 50 60 0 10 20 30 40 50 60 70 80 90 100 応 答時間 （ ミ リ 秒 ） 実行回数(回) 0 10 20 30 40 50 0 10 20 30 40 50 60 70 80 90 100 応答 時間 (ミリ 秒 ) 実行回数（回） 11.89 11.30 10.80 10.50 10.33 10.21 10.15 10.08 10.03 10.00 9.83 9.46 9.11 8.91 8.78 8.70 8.64 8.60 8.57 8.54 5.73 5.61 5.50 5.44 5.21 5.12 5.02 4.94 4.87 4.85 4.54 4.53 4.50 4.48 4.30 4.18 4.10 4.03 3.98 3.94 0 2 4 6 8 10 12 14 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 応答時 間 （ ミリ 秒 ） 実行回数（回）
SOAP(測定値) SOAP(補修値) POX（測定値） POX（補修値）
平均応答(ミリ秒) 標準偏差
SOAP（補修値） 8.91 0.41
100Byteごとに100回実行し，ガベージコレクションによる特 異値を除いた平均応答時間を補修値として，線形近似直線 と共に図11 に示す． 図11 データ量における応答時間の差 8.2.3. 性能評価 性能測定より以下の二点が明らかになった． (1) 実行回数に依存せず POX メッセージの応答時間は SOAP メッセージに対して約 50%短い． (2) データ量が約 3Kbyte まで POX メッセージの応答時 間はSOAP メッセージに対して短い．しかし，線形近 似直線の傾きがSOAP メッセージに比べ POX メッセ ージが約2.5倍であることからデータ量の増大に従い 応答時間の差は縮小する． これはPOX メッセージには SOAP エンベローブのような 構造がなく，簡潔な構造のためメッセージの生成，解析処 理が SOAP メッセージに比べ少ないためだと思われる．し かし，データ量の増加により相対的にデータ量に対する SOAP エンベローブのオーバヘッドによる割合が縮小する ので応答時間の差も縮小したと思われる． さらに，データ量が2KByte までの応答時間は SOAP メッ セージ，POX メッセージ共に平均 20 ミリ秒以内である．そ のため提案するアーキテクチャはうっかり通知サービスやリ モートドアロックサービスなどの自動車ネットワークサービス の応答時間の要求を満たしている．
9. 考察
9.1. 車載サービスブローカを用いた車外サービス連携 現状の車外サービス連携では利用できるサービスは， 自動車メーカの提供するサービスに限定される．提案した アーキテクチャではWeb サービスとして標準化されている メッセージプロトコルであるSOAP/REST を用いることにより 外部システムとの連携が容易となり，サードパーティサービ スが利用できる．さらにサービスの組み合わせが可能であ り，組み合わされた新たなサービスの利用も可能である． 9.2. 外部システムとの連携の性能評価 応答時間を用いて性能評価を行い，外部システムとの 連携の応答時間がうっかり通知サービスやリモートドアロッ クサービスなどの自動車ネットワークサービスの応答時間 の要求を満たしていることを示した．よって応答時間の観点 から提案するアーキテクチャは妥当性があるといえる． ただし，JVM のガベージコレクションにより一定周期に 異常に大きな遅延が発生するためリアルタイム性の要求が 厳しい自動車ネットワークサービスにはJava言語のリアルタ イム仕様であるRTSJ(Real Time Specification for Java)[2]の 適用が必要である．10.
今後の課題
10.1. 車載ネットワークとの連携においての応答時間 外部システムとの連携部分のみでは性能評価が不十分 である．CAN Gateway と ECU を用いてサービス全体の応 答時間を測定することが必要である． 10.2. 車外サービス連携におけるセキュリティ セキュリティの観点からの検証が必要である．さらに，セ キュリティ機能を付加したうえでの応答時間の評価が必要 である． 10.3. ガベージコレクションによる遅延の解決 リアルタイム性の要求が厳しい自動車ネットワークサービ スを利用するにはRTSJ の適用によりガベージコレクション による遅延を無くすための構造が必要である．
11. まとめ
本稿ではSOA を用いて，車載システムと外部ネットワー クシステムのサービス連携可能なアーキテクチャを提案し た．さらに，OSGi を基盤とし，プロトコル変換を可能にする 車載サービスブローカを提案した．車載サービスブローカ のプロトタイプを開発し，応答時間を測定し，妥当性を確認 した．参考文献
[1]Apache axis2, http://axis.apache.org/axis2/java/core/. [2]P. C. Dibble, Real-Time Java Platform Programming,
PrenticeHall, 2002.
[3]池崎 崇，軽量サービス指向アーキテクチャ設計方法の 提案と評価，2008 年度南山大学修士論文，2009. [4]Knoplerfish OSGi-Open Source OSGi Service Platform,
http://www.knopflerfish.org/index.html.
[5]D. Krafzig, et al., Enterprize SOA, Prentice Hall, 2005. [6]水谷 拓人，自動車ネットワークサービスのサービス連
携アーキテクチャの提案と評価，2009年度南山大学修士 論文, 2010.
[7]OSGi(Open Service Gateway Initiative) Alliance, http://www.osgi.org/Main/HomePage.
[8]P. Park, et al., An OSGi Based In-Vehicle Gateway Platform Architecture for Improved Sensor Extensibility and Interoperability, Proc. IEEE COMPSAC 2009, pp.140-147.
13.0 15.4 15.2 15.5 15.2 15.6 15.8 17.3 15.8 17.8 18.3 18.2 18.1 18.1 18.6 20.1 18.2 19.8 17.4 19.2 5.4 5.1 5.3 8.0 7.0 6.9 7.7 10.8 10.4 9.9 13.2 11.9 14.1 13.1 15.0 14.1 13.4 13.9 15.0 15.4 y = 0.27x + 14.25 y = 0.58x + 4.68 0 5 10 15 20 25 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 2 応 答 時間（ ミ リ 秒） データ量（KByte） SOAP POX 線形 (SOAP) 線形 (POX)
