自動車ネットワークサービスのサービス連携アーキテクチャの提案と評価
M2008MM022 水谷 拓人
指導教員 ： 青山 幹雄

1. はじめに近年，サービスの再利用，連携を容易にする技術として
サ ー ビ ス 指 向 ア ー キ テ ク チ ャ (SOA ： Service-OrientedArchitecture)が注目されている．そこで，車載システムと外部システムをネットワークを介してサービスとして連携し，新たな機能を提供することが求められている[1]．
本稿では，車載システムが外部システムとネットワークを介したサービス連携可能なアーキテクチャを提案する．

2. 自動車ネットワークのサービス連携
自動車ネットワークサービスのサービス連携には図 1 で示すように車載システム内の連携と外部システムとの連携の 2種類が存在する．車載ネットワーク内のシステム連携を車内サービス連携，車載システムと外部システムのサービス連携を車外サービス連携とする．
（1）車内サービス連携
車載システムLight

Car Navigation
system
Door

ECU

ECU

ECU

（2）車外サービス連携

ゲートウェイWeb

外部システム

サービス
プロバイダ

ECU： Electronic Control Unit

図 1：サービス連携(1) 車内サービス連携
車内サービス連携とは，自動車の機能を制御している車載システム内の ECU 間のみでサービス連携が行われることである．
(2) 車外サービス連携
車外サービス連携とは，自動車の外に存在するシステムと車載システムとが連携することである．外部システムが車載システムのサービスを利用する場合と車載システムが外部システムのサービスを利用する場合の 2 つの形態がある．

3. 車外サービス連携の問題

4. 関連研究
現在の車外サービス連携を実現するために以下の提案が行われている．
4.1. NGTP (Next Generation Telematics Protocol)[4]NGTP のアーキテクチャは現在のテレマティックスサービ
スに加え，コンテンツプロバイダや e-Call サービスなどの公共のネットワークへの接続を可能とするように拡張されている．また，ディスパッチャと呼ばれるサービス配信機構を置き，サービスの提供と配信を分離する．しかし，サードパー
ティサービスとの連携についての拡張性は示されていな
い．
また，NGTP の仕様では，SOA のようなプラットフォーム独立性，疎結合性などは示されていない．また，独自の APIの標準化を行い，Web へ接続する構造であるため，Web サービスとの連携は十分に考慮されていない．
4.2. SCSN(Smart Car Sensor Network)[6]プラットフォーム
図 2 で示す SCSN プラットフォームは SCSN ドメインとメーカ側のドメイン間のゲートウェイの役割を果たす．SCSN ドメ
インのセンサ情報に加え，IEEE1394 や Bluetooth を使用する外部システムと車載システムの連携が可能である．
SCSN プラットフォームは OSGi を基盤としたプラットフォームである．このプラットフォームではソフトウェアの部品としてVS(Vehicle Service)がある．この VS のようなソフトウェア部品は bundle と呼ばれ OSGi フレームワーク上に実装されることで機能を実現する．また，CAN ゲートウェイの機能を搭載することで CAN プロトコルに柔軟に対応できる． また，
VSI (Vehicle Service Interface) ゲートウェイも VS 同様にbundle として実装されている．VSI ゲートウェイは VS の情報を CAN ゲートウェイへ提供する．CAN ゲートウェイと VSIゲートウェイ間では TCP/IP stack を用いる．そして，さらに通信処理方法に publish/subscribe モデルを適用することで車載システムからのデータ受渡しを減少させている．
Auto maker Domain

SCSN Platform

High Speed CAN

AMI-C HOSTSCSN Domain

consoleapplications

VSI Gateway

CAN
Gateway

Vehicle Service

AutoMaker’s
Gateway

Power Train
Body & Comfort

現状の車外サービス連携の問題点と車外サービス連携
へ SOA を適用する上での問題点として以下の 2 点が挙げられる．
(1) サービスインタフェースとプロトコルが固有
現状での車外サービス連携を行う場合，サービスを提供するベンダやテレマティックスサービスプロバイダごとにインタフェース，通信プロトコルが固有である．そのため，サードパーティサービスの利用が困難であり，異なるサービス間のサービス連携も困難である．そのため，本稿では車外サービス連携に SOA の技術を適用することで複数の車外サービスと連携を可能にする．
(2) 組込みシステムの処理能力の制約
現状の車載 ECU では処理能力の制約が厳しいため Web
サービスで用いられるメッセージを変換せず，個別の車載
ECU やネットワークへ送信することはできない．また，新たに Web サービスのメッセージプロトコルに対応する車載
ECU やネットワークを個別に提供することは組込みシステムの処理能力やリソースの制約があるため困難である．

SensorNetworkCAN

OSGi
JVM

Low Speed
CAN

Network Drivers
CAN
TCP/IP ・・・ CAN
RTOS

図 2：SCSN アーキテクチャ

infortainment
IEEE 1394
Bluetooth
AMI-C Network

REST

サービス
Web
プロバイダ

Door

SOAP

サービス
Web
プロバイダ

Light

ネットワーク

ＥＣＵ

記述
WSDL
インタフェース

ＥＣＵ

車載サービスブローカ

記述
WSDLインタフェース

車載LAN(CAN)

ゲ ー トウェイ…

外部システムCAR（車載システム）

車 内サービス
インタフェース

Basic Service

Basic Service

Basic Service

Basic Service

Application

Application

Application

Application…

本稿ではメッセージ/プロトコル変換を行う車載ゲートウェ
イを車載サービスブローカとして提案する(図 4)．車載サービスブローカでメッセージ/プロトコル変換を行うことにより，SOAP/POX のメッセージによる車外サービス連携を可能にし，現在のテレマティクスサービスや NGTP よりも柔軟なサービス連携を実現可能にする．

Car Navigation
systemBasic Service bundle

Application bundle

6. 車載サービスブローカの提案

記述
WSDL
インタフェース

4.3. OSGi(Open Service Gateway Initiative)[5]OSGi[5]は家電製品をインターネットに接続し，パソコンや機器間で相互にサービスを提供するための技術仕様である．OSGi フレームワークは Java 言語を前提とした技術である．図 3 で示すように Java 仮想マシン上で動作する実行環
境と Java で記述された bundle と呼ぶ各種アプリケーションソ
フトウエアやミドルウェアで構成される．そのため，bundle はOSGi フレームワークを実装する異なるプラットフォーム間で再利用を可能である．

OSGi
JVM(Java Virtual Machine)

図 4：車載サービスブローカ

OSHardware

図 3：OSGi の構成
4.4. 車外サービス連携の比較
3 つのテレマティックスサービスの比較を表 1 に示す．既存のテレマティックスサービスではテレマティクプロバイダ固有のインタフェースやメッセージプロトコルを提供する．本稿
では Web サービス標準の技術を用いることで，車載システ
ムとテレマティックスサービスとのサービス連携を容易にする．
表 1：車外サービス連携の比較
要素技術

現在のテレマティックス

ＮＧＴＰ

ＳＯＡ

通信プロトコル

SMS,HTTP,SMTP

HTTP

HTTP，SMTP

メッセージ
プロトコル

固有

固有

SOAP，POX

サービス
インタフェース

固有固有(API を標準化)

WSDL

サービスの動的発見

無し(固定)

NA

サービスレジストリを利用サービスの組合せ

無し(固定)NA

BEPL などを用いて組合せ

Web コンテンツの利用なし(クローズ)

NA可能

セキュリティ
(認証/暗号化)

固有(認証)

共通(認証/暗号化)共通(WS-Security 仕様)[End to End セキュリティ](認証/暗号化)

POX

SOAP

Telematics
Application

SOAP/POX
Processor/proxy

SOAP

SMTP

記述
WSDL
インタフェース

車載サービスブローカ(OSGi)

HTTP

記述
WSDL
インタフェース

外部システムサービスWeb
プロバイダ

5.1. 車載サービスブローカアーキテクチャ
車載システムへ SOA の技術を導入する形態を示す．車載システムのサービスプロバイダとしての振る舞いと，サービスリクエスタとしての振る舞いについて説明する．
(1) 外部システムのサービスの利用
車載システムが外部システムのサービスを利用する場合，システム内の機器が外部システムのサービスを利用することになる．
(2) 車載システムのサービスの利用
外部システムが車載システムのサービスする利用する場
合，外部システムから車載システムの各機器の機能が利用可能となる．例として，NGTP でも利用されている窓の開閉やハザードランプ等の点灯と消灯，ドアロックの on と off 等がある．

サービスWeb
プロバイダ

5. 車外サービス連携への SOA の適用

メッセージ/プロトコル変換を行う車載サービスブローカに4.3 節で説明した OSGi フレームワークを用いた車載ゲートウェイのアーキテクチャを提案する．OSGi フレームワークはゲートウェイとしてアーキテクチャが提案されている．HTTPの機能を持つ bundle など通信に関連した bundle がデフォルトで提供されている．そのため，Web サービス等の外部システムと通信を行う機能を車載サービスブローカの実現が容易である．また，OSGi フレームワークでは組込みシステムへの対応も考慮されており，組込みシステムでも実装可能となっている．
6.1. 車載サービスブローカでのメッセージの送受信
車外サービス連携に SOAP，POX[2]のメッセージを用いるため，車載サービスブローカでは SOAP，POX の解析を行う必要がある．そのため，OSGi フレームワークには XMLパーサや SOAP/POX processor/proxy の機能を持つ bundleを利用する．また，車載サービスブローカの SOAP/POXprocessor/proxy では外部システムとの通信プロトコルにHTTP や SMTP を用いるため，HTTP サーバ bundle や
SMTP サーバ bundle を実装し外部システムと車外サービス連係を実現する(図 5)．

bundle

図 5：SOAP/POX の送受信
6.2. テレマティクスサービスの実現
上記で述べたようにテレマティクスサービスの利用形態として車載システムからのサービスの利用する形態が考えられる．この利用形態では車載サービスブローカへ接続される車載 LAN に MOST，接続する機器はカーナビゲーションシステムが考えられる(図 6)．

車載サービスブローカ

CANフレーム

フォーマット変換

OSGi

ECU
Car Navigation
system

SMTP

MOST

SOAP

Telematics
Application

SOAP/POX
Processor/proxy

HTTP

POX

CAN
GatewayInterfaceGateway

SOAP

Telematics Application bundle よりサービスプロバイダへ
SOAP/POX メッセージが送信され，車載の情報をサービスプロバイダへ受け渡すことができる．そして，そのメッセージをもとにサービスプロバイダはユーザへうっかり状態を通知する(図 8)．
車載サービスブローカ
サービスプロバイダ
Service車載LANOSGi

SOAP/POX
proxy/processor

SOAP/POX
proxy/processor

Telematics
Application

イーサネットフレーム

CAN
GatewayInterfaceGateway

cdRequest()

out.println()
TCP

RcdReport()

ただし，現在の MOST ではイーサネットフレームをそのまま用いることが可能であるため，車載サービスブローカでのメッセージ変換を行わずにメッセージ送信することが可能である．
6.3. 車載サービスブローカのアーキテクチャ
NGTP のようなテレマティクスサービスを実行するためには CAN 等で接続された ECU にメッセージを送信する必要がある．そのため，車載サービスブローカ内で各車載 ECUに対応したメッセージにメッセージ/プロトコル変換機能が必要である．この機能を実現するため，車載サービスブローカ
では OSGi フレームワーク上の bundle とは別に CAN
Gateway 等の車載 ECU とリアルタイム性を保って通信可能な機能を実装する．
車載サービスブローカでテレマティクスサービスを実現する場合，OSGi フレームワークにテレマティクスサービスの機能をもつ Telematics Application bundle を実装する．ただし，
Telematics Application bundle では 車載サービスブローカの車内 ECU との通信を行う．Telematics Application bundle
では Can Gateway へ直接フォーマット変換したデータを渡さず，Interface Gateway でフォーマット変換を行う．
メッセージ/プロトコル変換を行う車載ゲートウェイとして図7 に示す車載サービスブローカのアーキテクチャを提案す
る．OSGi フレームワークを用いることで，機能の追加，変更を容易にする．

WSDL

HTTP

Web
サービス
プロバイダ

REST
SOAP/REST
proxy/processor

WSDL

HTTP

SMTP

XML

CAN
Gateway

AXIS2
ServerServicebundleWSDL4J

Telematics
Application

ECU

InterfaceGateway

ECU

ECUInterface

ECU

SMTP

外部システム
Web
サービス
プロバイダ

HTTP

車載LAN(CAN)

ECU

SOAP

FileInput
Stream()RcdReport()

図 6：内部のメッセージ変換処理の流れ

車載サービスブローカ

ECUout.println()
TCP

OSGi
JVM

図 7：車載サービスブローカのアーキテクチャ
6.4. メッセージ/プロトコル変換
車載サービスブローカにテレマティクスサービスのリモートセキュリティシステムの機能を適用する．
(1) うっかり通知
う っ か り 通 知 で は ま ず 車 載 LAN 内 の Telematics
Application bundle からドアの状を取得する．ECU の状態は車載サービスブローカの CAN ゲートウェイへ通知され，CAN ゲートウェイからフォーマット変換されたデータをInterface Gateway bundle が 受 け 取 り ， Telematics
Application bundle へ 車 載 の 情 報 が 渡 さ れ る ． さ ら に

RcdReport()
SOAP

図 8：うっかり通知での処理の流れ(2) リモートドアロック
ユーザのリモートドアロックサービスを実行した場合，まず，ユーザはサービスプロバイダのシステムにログインし，リモート操作を送信する．そして，サービスプロバイダは操作受付完了メールを送信し，リモート操作命令を実行する．車載
サービスブローカの Telematics Application bundle を実行しInterface Gateway bundle と連携を行い CAN Gateway へデータを受け渡す(図 9)．
車載サービスブローカ
サービスプロバイダ
Service

SOAP/POX
proxy/processor

SOAP/POX
proxy/processor

リモートドアロック
SOAP/REST

OSGi
Telematics
Application

サービスの実行

車載LAN
InterfaceGateway

ドアロックの実行

CAN
Gateway

ドアロック
命令送信

ドアの状態のデータ送信

サービスの実行

ECU

ドアロック
命令送信
ドアの状態のデータ送信

施錠

ドアの状態を通知
SOAP/REST
ドアの状態を確認
SOAP/REST

サービスの
実行

ドアの状態を確認サービスの実行

状態を取得
命令送信

ドアの状態のデータ送信

状態を取得
命令送信
ドアの状態のデータ送信

状態を確認

ドアの状態を通知
SOAP/REST図 9：リモートロックサービスの処理の流れ

7. プロトタイプ
オープンソースの OSGi フレームワークを用いた車載サービスブローカのプロトタイプの実装を以下に示す．
(1) OSGi フレームワーク
本稿では OSGi フレームワークに knopflerfish[2]を用いた．HTTP-Server 等の knopflerfish で提供される BasicService bundle を利用する．
(2) SOAP/REST Processor/Proxy
SOAP/REST に よ る サ ー ビ ス 実 現 す る た め にknopflerfish で提供されている Axis2-Server と Web サービ
スの処理 を行う bundle を利用する．
(3) Telematics Application bundle
リモートセキュリティサービスのリモートドアロックサービスを実装する． また，車載システムの情報を外部システムへ返す機能を実装する．
(4) Interface Gateway bundle
Interface Gateway bundle は Telematics Application
bundle と連携して車内へ情報を出力する．また，車内の情報を取得し，Telematics Application bundle へ車内の情報を渡す機能を実装する．

8. 車載サービスブローカの評価
8.1. Web サービスとの相互運用性
本稿では外部の Web サービスと相互運用可能な車載サービスブローカの提案を行った．提案した車載サービスブローカによって車載サービスが外部の Web サービスと相互運用可能であるか実装したプロトタイプを用いて検証を行った．
車載サービスブローカでは OSGi フレームワークの Axis2の機能を実装可能である．そのため，車載サービスブローカ内にサービスを実装し，そのサービスを外部システムから実行することが可能である．
プロトタイプでも OSGi フレームワーク上で Web サービスとして実装されるサービスが実行でき，独立して動作するプログラムとのプロセス間通信による動作も可能である．
そのため，テレマティクスサービスでのリモートセキュリティシステムのリモートドアロックや車載の状態を取得するサービスのように，外部システムからの公開した車載サービスを実行可能である．
OSGi フレームワークからでもうっかり通知のように自動車自身が車載の状態を検出し，車載の状態を外部システムに通知するサービスのように車載側から外部システムのサービスを実行することが可能である．そのため，車載サービスブローカでは外部システムのサービスも利用することができる．
このように，車載サービスブローカでも外部システムと車載サービスブローカ間の双方向の通信が可能である．そのため，テレマティクスサービスの同様のサービスを実現できるといえる．
8.2. メッセージ変換
車載サービスブローカでは SOAP メッセージを受信し, サービスの実行をする．そのため，ドアロックを要求するにはサービスを実行する記述により車載サービスブローカのサービスを実行する．
車載サービスブローカ
サービスプロバイダ
Service

車載LAN

OSGi

SOAP/POX
proxy/processor

SOAP/POX
proxy/processor

Telematics
Application

SOAP解析

CAN
GatewayInterfaceGatewayString 型
データ送信

String 型
データ送信

out.println()

SOAP送信サービス実行ECU

TCP

out.println()

う，アプリケーションに依存する．そのため，あらたなサービスを実行する場合には bundle のアップデートを行うサービス，機構が必要である．

9. 今後の課題
9.1. 軽量な SOA メッセージの利用
POX での軽量なメッセージはセキュリティの観点からテレマティクスサービスのような車載システムのサービスに用いるには脆弱であるため，セキュリティの強化ができる SOAPの軽量メッセージが必要である．
9.2. 車外サービス連携におけるセキュリティ
車外サービス連携において Web サービスの SOAP メッセージを用いることで WS-Security によるエンド to エンドのセキュリティが可能なことを述べた．しかし，SOAP は SOAP のヘッダなどによる処理時間が長くなる．そのため，車外サービス連携でのセキュリティを強化する場合，組込みシステムのリソース制約を考慮したセキュリティが必要である．

10. 考察OSGi フ レ ー ム ワ ー ク 上 で は Telematics Application
bundle と Interface Gateway bundle の bundle が連携する．
そして，Interface Gateway bundle と CAN gateway で連携することでメッセージ/プロトコル変換を実行する． Telematics
Application と Interface Gateway bundle を分離することで各 bundle の再利用性は高くなる．
ただし，アプリケーションに依存した，テレマティクスサービスであるため，サービスに対する柔軟性を考慮する場合は bundle をアップデートできるような機構が必要である．

11. まとめ
本稿では自動車ネットワークの車載システムと外部システ
ムとのサービス連携可能なアーキテクチャを SOA を用いて実現する方法を提案した．また，OSGi を基盤とし，メッセージ/プロトコル変換を可能にする車載サービスブローカを提案した．車載サービスブローカの妥当性を確認するためプロトタイプ開発を行っている．

謝辞
本研究のご支援頂いた，㈱デンソーの岩井明史氏と佐藤洋介氏に感謝する．

TCP

参考文献
ドアロックに対応した操作を実行

データ送信
内容から操作を実行[1]

図 10：メッセージフォーマット変換
プロトタイプでは ECU の操作を行うデータとして何を送信するかは Interface Gateway bundle が決定する．そして，CAN Gateway へデータを受け渡し，CAN Gateway からString 型のデータの送信を行い ECU の操作を行う．サービスが実行されてからの処理の流れを図 10 に示す．
このように Telematics Application bundle のサービスとInterface Gateway bundle の機能を用いて SOAP メッセージの要求を別のデータ型としてフォーマット変換を行い，テレマティクスサービスを実現可能である．しかし，本稿で提案するメッセージ/フォーマット変換では SOAP メッセージによるサービスの実行によってメッセージ/フォーマット変換を行

[2]
[3]
[4]
[5]
[6]

青山 幹雄, ほか, 車載ソフトウェアのサービスプラット
フォームのモデルとアーキテクチャ, 自動車技術会
2008 年秋季大会, Oct. 2008, No. 97-08, pp. 21-26.
Knopflerfish , http://www.knopflerfish.org/index.html/
L. Richardson, and S. Ruby, RESTful Web Service,
O’Reilly, Jul. 2008.
NGTP (Next Generation Telematics Protocol),http//www.ngtp.org/.
OSGi(Open Service Gateway Initiative) Alliance,
http://www.osgi.org/.
P. Park, et. al., An OSGi Based In-vehicle Gateway
Platform Architecture for Sensor Extensibility andInteroperability, Proc. IEEE COMPSAC 2009, Jul.
2009.