JP7013694B2 - 車両用サービス連携システム - Google Patents

Description

本発明は車両用サービス連携システムに関する。

近年、車両に搭載された複数のＥＣＵ（Electronic Control Unit）が連携することでＥＣＵが有する機能を連携して使用することが提案されている（特許文献１～３参照）。例えば自動運転サービスでは、車両に各種車載センサを搭載し、自動運転ＥＣＵがそれらの検出結果を総合的に判断して自律制御することで、自動運転の実現を目的とした高度運転支援技術の開発がすすめられている。

特開２０１４－１５３５５８号公報 特開２０１５－１８７８５９号公報 特開２００６－１４２９９４号公報

ところが、車載センサによる自律制御のみでは、交差点の死角等の見通しの悪い場所での円滑な車両制御や、雪、ほこりによる道路形状の認識精度低下等の天候による悪影響には限界がある。

このような自律制御の限界に対応するために、ＩＴや道路インフラを含めた車外装置が提供する車外サービスにより見通しの悪い場所に位置する他車の状況を先読みする車外サービスの提供を受けることで、円滑な車両制御を補完しようと試みている。つまり、車外サービスにより車載機の機能を補完しようとするものである。

しかしながら、車載機の機能は固定しているのに対して、ＩＴや道路インフラを含めた車外装置が提供する車外サービスの進化は速く、車両の機能がすぐに陳腐化してしまう。このような課題は、ＩＴや道路インフラを含めた車外サービスと車両の機能のライフサイクルの違いから発生する。

本発明は上記事情に鑑みてなされたもので、その目的は、ＩＴ／道路インフラを含めた車外装置から提供される車外サービスの速い進化に合わせて、車両の機能を進化させることができる車両用サービス連携システムを提供することにある。

請求項１の発明によれば、車載装置（１～７）と車外装置（９）との間にローカルサービスバス上のサービスをインストール可能とすると共に車載通信や車外通信等の下位層を隠蔽するように仮想的なサービスバス（１３）が構築されるので、統合アプリケーション（１８）は、車載装置（１～７）が提供する車載サービスと車外装置が提供する車外サービスとを連携して利用することができる。これにより、車外サービスの進化に合わせて車両の機能を進化させることができる。

一実施形態における車載装置と車外装置の構成を模式的に示すブロック図 車載装置と車外装置を示すブロック図 サービスインターフェースとサービスバスとの関係を示す図 エッジサーバのサービスを利用する場合を説明する図 エッジサーバのサービスをサービスバスにインストールする概念を示す図 サービスバスによる連携を示す模式図 統合アプリケーションによるサービスの連携を示す図 サービス間通信のプロトコルを示す図 サービスの概要を示す図 サービスバスの機能を示す図 サービスバスを構成するモジュールを示す図 サービスをサービスバスにインストールする手順を示す図 車両情報提供プロキシサービスによる連携を示す模式図 サーバプロキシサービスによる連携を示す模式図 仮想車両プロキシサービスによる連携を示す模式図 車載サービスと車外サービスとを連携して利用する手順を示す図 ブラインド回避アプリが車載サービスと車外サービスとを連携して利用する手順を示す図 交通網に設定されたエッジ空間を示す図

以下、車両用サービス連携システムの一実施形態について図面を参照して説明する。
車両用サービス連携システムは、車載装置が提供する車載サービスと車外装置が提供する車外サービスとを応答性良く連携可能とする仕組みを提供するものである。サービスとは他のサービスやアプリケーション（以下、アプリ）に機能を提供することで、通常のサービスは、複数の機能から構成されている。

図２に示すように、車載装置は、拡張ゲートウェイ（（ＤＣＭ（Data Communication Module））、以下、拡張ＧＷと称する）１、基本ゲートウェイ（ＣＧＷ（Central gateway）、以下、基本ＧＷと称する）２、ディスプレイ３、ロケータＥＣＵ４、ブレーキＥＣＵ５、ライトＥＣＵ６、カメラＥＣＵ７が車載ネットワーク８により接続されることで構成されている。車載ネットワーク８のプロトコルは、ＣＡＮ（Controller Area Network）、ＬＩＮ（Local Interconnect Network）、ＦｌｅｘＲａｙ、Ｅｔｈｅｒｎｅｔ（登録商標）などでドメイン毎に適切なプロトコルが用いられる。尚、図２は代表的なＥＣＵを示したものであり、実際には車載ネットワーク８には１００台近くのＥＣＵが接続されている。

各ＧＷ１，２、ディスプレイ３、及び各ＥＣＵ４～７には周知の制御装置（図示せず）が設けられている。制御装置は、ＣＰＵ、ＲＯＭ、ＲＡＭ、Ｉ／Ｏを有するマイクロコンピュータにより構成されており、非遷移的実体的記録媒体に格納されている機能を実行することで、通常の処理に加えて機能をサービスとして提供する処理を実行する。

図１に示すように、拡張ＧＷ１、基本ＧＷ２、ディスプレイ３、各ＥＣＵ４～７には車載サービスやアプリが搭載されている。
拡張ＧＷ１は、車外装置との間で無線通信を確立する機能を有するもので、更新通知サービス、ブラインド回避アプリ、不審者検知アプリ、駐車場空き枠検知アプリが搭載されている。更新通知サービスは、車外サービスが更新されたことを通知するものである。車外サービスとは、外部のシステム（交通情報、娯楽情報、メールサービスなどを提供するサーバや、家庭内システム）が提供するサービスである。

基本ＧＷ２は、ディスプレイ３や各ＥＣＵ４～７が所属するドメイン間の情報をルーティングする機能を有する。ドメインとしては、車外サービス系ドメイン、人間系ドメイン、環境系ドメイン、ボデー系ドメイン、運動系ドメインなどである。

ディスプレイ３は、エアコンやオーディオ等を操作するための各種操作ボタンを表示したり、ナビゲーション用の地図画面を表示したりするもので、画像表示サービスが搭載されている。

ロケータＥＣＵ４は、自動運転のための自律制御に必要な自車位置を高精度で測定するもので、位置情報提供サービスが搭載されている。ロケータＥＣＵ４が測定した自車位置を自動運転システムに与えることで、自動運転システムは、自律走行を実行可能となる。

ブレーキＥＣＵ５は、運転者によるブレーキ操作や自動運転時にブレーキ制御を実行するもので、ブレーキ制御サービスが搭載されている。
ライトＥＣＵ６は、運転者による点灯操作や自動点灯時にライトの点灯を制御するもので、ライト制御サービスが搭載されている。
カメラＥＣＵ７は、自車の前方に位置する前方車両や障害物を撮影するもので、画像撮影サービスが搭載されている。

一方、車外装置としてエッジサーバ９が設けられており、衝突判定サービス、不審者検知サービス、駐車場空き枠通知サービスが搭載されている。これらのサービスはエッジサーバ９の狭域通信エリアであるエッジ空間に応じて適切なサービスが搭載されている。エッジサーバ９とは、クラウドサーバとデバイスとの中間層に置くサーバのことで、クラウドと比較してリアルタイム性が問われる処理やクラウドサーバが収集するクラウド情報の内、特定の情報を提供する。特定の情報とは、他デバイス１０から収集したセンシング情報である。

他デバイス１０とは、例えば、他の車両に搭載された車載装置、自転車に乗車している人や歩行者が携帯するスマートフォン、駐車場や交差点に設置された監視カメラなどで、画像撮影サービスや位置提供サービスが搭載されている。これらのサービスは他デバイス１０の種別に応じて適切なサービスが搭載されているもので、例えば車載装置やスマートフォンには位置提供サービスが搭載され、監視カメラには画像撮影サービスが搭載されている。つまり、自車の周辺を走行する車両からの位置情報や自転車に乗車している人が携帯するスマートフォンは車両や自転車の位置情報を提供する。また、交差点に設置されている監視カメラは撮影情報により交差点の死角に隠れている歩行者の位置情報を提供する。また、自宅の駐車場に設置されている監視カメラは撮影情報により不審者の位置情報を提供する。また、会社や大型店舗の駐車場に設置された監視カメラは撮影情報により空きスペースの存在や自車がセンシングできていない他の車両や歩行者などの位置情報を提供する。

さて、上述した車載装置や車外装置は、互いが有するサービスを直接的に相互利用することができないと共に、サービスの削除や追加（抜き差し）に対応することができない。
そこで、車載装置や車外装置が有する機能を直接的に相互利用するために、図３に示すように、アダプタ（サービスアダプタと称することもある）１１が提供するサービスインターフェース（以下、サービスＩ／Ｆと称する）１２と、所定のプロトコルによりサービスの要求及び応答に対応したメッセージを送受信するサービスバス１３とを設けた。

サービスバス１３は、サービスの位置及び抜き差しを管理するサービス管理の機能を有しており、本実施形態では、図１に示すように、基本ＧＷ２のサービスバス１３にサービス管理部１３ａを搭載した。つまり、基本ＧＷ２は、ドメイン間の情報をルーティングする機能と、サービスの位置及び抜き差しを管理する機能とを有する。また、サービスバス１３は、ハードウェア（Ｈ／Ｗ）１４を介して車載ネットワーク８と接続される。

アプリやサービスが他のサービスを利用する場合は、図３に示すように、サービスＩ／Ｆ１２を介在して行う。このようにサービスＩ／Ｆ１２を介在させることで、アプリ開発者は、最上位のアプリ層よりも下位のレイヤの存在を意識する必要がなくなる。また、サービス管理部１３ａによりサービスの位置及び抜き差しを管理することで、アプリ開発者は、利用したいアプリの位置及び抜き差しを意識する必要がなくなる。

サービスＩ／Ｆ１２は、アダプタ１１が提供するインターフェースであり、車載装置や車外装置のアプリやサービスが他の車載装置や車外装置の既存機能をサービスとして利用することを可能とする。サービスＩ／Ｆ１２を持たせることでサービスやアプリが機能をサービスとして利用できるようにするプロセスを「機能のサービス化」と呼ぶ。また、複数のサービスから構成されるアプリを統合アプリと呼ぶ。

「機能のサービス化」を実現するには車載装置や車外装置にローカルサービスバスを搭載し、それらが接続することにより仮想的なサービスバス１３を構築する。
即ち、図４に示すように、車載装置が車外装置であるエッジサーバ９のサービスＡをインストール、つまり利用可能な状態にする場合、自車のローカルサービスバス１５上にサービスＡの実体が存在しなくても、自車のローカルサービスバス１５と接続された車外のローカルサービスバス１５上にサービスＡの実体が存在するため、サービスバス１３上にサービスＡがインストールされていると言える。

サービスＡを実際に使用可能とするには、サービスＡを自車にダウンロードする必要があるが、本実施形態でサービスＡをダウンロードするとは、図５に示すように、ローカルサービスバス１５上にサービスＡの実体をインストールにより移動させることである。クラウド環境が発展することで、サービスＡを車載装置にダウンロードすることなくインストールすることが可能になる。

ローカルサービスバス１５は、１つのメモリ空間に対して、１つだけ存在する。メモリ空間はＯＳ１６（図１参照）によって生成され、１つのＣＰＵに対して、ＯＳ１６が２つ以上のメモリ空間が生成する場合も、それぞれのメモリ空間に対してローカルサービスバス１５が存在する。これにより、サービスバス１３は、ＯＳ１６以下の物理配置であるＥＣＵ仕様や構成に依存せず、搭載可能となる。

図６に示すように、ローカルサービスバス１５は、車載装置であるＧＷ１，２、ディスプレイ３、ＥＣＵ４～７や、車外装置であるエッジサーバ９や、他デバイス１０であるスマートフォン等に搭載されるミドルウェアソフトであり、個々のローカルサービスバス１５がアプリ間通信や車載通信や車外通信によって接続されて仮想的に１本のサービスバス１３を構築する。サービスバス１３が車載通信等の下位層を隠蔽することで、サービス開発者がサービス開発に専念できる。また、既に構築されているサービスバス１３に、ローカルサービスバス１５を搭載した機器を追加することでサービスバス１３を再構築（拡張）する。

図７に示すように、サービスは、サービスＩ／Ｆ１２を介してメッセージを交換することで他のサービスの相互利用が可能となる。また、サービス同士がサービスを利用するのに限定されることなくアプリがサービスを利用することもできるし、統合アプリ１８がサービスを利用することも可能である。

図８に示すように、サービス間通信のプロトコルは、１対１でメッセージの要求／応答を行うＲｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ型と、不特定多数の購読登録者にメッセージを出版するＰｕｂｌｉｓｈ／Ｓｕｂｓｃｒｉｂｅ型が存在する。

（Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ型）
サービス同士が１対１でやり取りするもので、要求（Ｒｅｑｕｅｓｔ）に対して応答（Ｒｅｓｐｏｎｓｅ）を返す。

（Ｐｕｂｌｉｓｈ／Ｓｕｂｓｃｒｉｂｅ型）
サービス同士が１対多でデータを送るもので、出版（Ｐｕｂｌｉｓｈ）に対して応答を返さない。出版した場合、購読（Ｓｕｂｓｃｒｉｂｅ）登録している不特定多数のサービスに通知される。

サービスが提供する情報（属性）は、図９に示す各種情報を採用することを想定しているが、それ以外の情報を採用するようにしても良い。
サービスバス１３の機能は次の通りである。
（１）サービスバス管理
（ａ）車両システムやサービスからの起動要求を受けて、サービスバス１３を起動すること。
（ｂ）車両システムからの終了要求を受けて、サービスバス１３を終了すること。
（ｃ）サービスバス１３の状態を管理すること。

（２）サービス管理
（ａ）インストール／アンインストール／アップデート管理サービスの要求を受けて、サービスをインストール／アンインストール／アップデートすること。
（ｂ）サービスバス起動時か、開始管理サービスの要求を受けて、サービスを開始すること。
（ｃ）サービスバス停止時か、停止管理サービスの要求を受けて、サービスを停止すること。
（ｄ）サービスの状態を管理すること

（３）サービス実行
（ａ）コンシューマサービス（あるサービスを利用するサービス）の実行要求を受けて、プロバイダサービス（あるサービスを提供するサービス）を実行できること。
（ｂ）プロバイダサービスの搭載位置を解決すること（位置透過性）。
（ｃ）コンシューマサービス（サービス利用者）に応じて、プロバイダサービス毎に異なるアクセス制御（許可/拒否）ができること。
（ｄ）サービス単位／メッセージ単位での優先度制御ができること（調停）。

車載装置や車外装置のアプリやサービスが他のサービスを利用するとき、サービスバス１３が他のサービスの位置を解決する。そのため、各機器上のサービスは他のサービスの位置を知ることなく利用できる。このことは、サービスの位置透過性を有することを意味する。

図１０に示すように、サービスバス１３およびアダプタ１１は、各機器内のソフトウェア構成に位置付けされており、サービスバス１３は、ローカルサービスバス１５が実装上の実体となる。

サービスバス１３は、ＯＳ１６および通信プロトコルスタック（ＣＡＮ、ＴＣＰ／ＩＰ等）上に配置し、それらの資源を利用してサービス間の連携を実現する。
アダプタ１１は、サービスに対してサービスＩ／Ｆ１２を提供し、サービスから受け付けた要求をサービスバス１３に通知する。

図１１に示すように、サービスバス１３は以下のモジュールから構成されている。
サービスバス管理１９：サービスバス１３の起動／終了を制御し、各機器のサービスが他のサービスの利用や、他のサービスへのサービス提供可能な状態を維持する。

サービス管理２０：サービスバス１３上のサービスを管理し、その動作を制御する。
サービス認証２１：サービスバス１３にインストールするサービスを認証する。
ユーザ認証２２：サービスバス１３を利用するエンドユーザを認証する。

エンドユーザとは、コンシューマサービスやプロバイダサービス、開発支援ソフトを介して、サービスバス１３にアクセスする人、例えば車両オーナー、サービス開発者等を指す。

メッセージ送受信２３：サービスバス１３を流れる情報（メッセージ）を伝達する。
サービス検索２４：サービスバス１３上のサービスを検索する。
稼動履歴管理２５：サービスバス稼働中のサービスおよびサービスバス１３の動作履歴を収集・提供する。

開発支援２６：サービスおよびサービスバス１３の開発作業を支援する機能を提供する。
保守支援２７：サービスバス１３の運用時の保守作業を支援する機能を提供する。

サービスをサービスバス１３にインストールする場合、インストールを実行する主体はインストール管理サービスである。インストール管理サービスは、統合アプリ１８がエッジサーバ９や他デバイス１０のサービスを利用するような場合は、外部との通信を行う拡張ＧＷ１に搭載されている。

さて、インストール管理サービスがサービスをインストールする手順について簡単に説明する。図１２に示すように、インストール管理サービスは、自己のアダプタに対してサービスのインストールを要求する。

インストール管理サービスのアダプタは、その要求に応じて他のローカルサービスバスに対してサービスインストールが可能か否かの確認を要求する。
他のローカルサービスバスは、その要求に応じてサービスのインストールが可能か否かを判定し、その判定結果示す応答をインストール管理サービスのローカルサービスバスに返信する。

インストール管理サービスのローカルサービスバスは、サービスのインストールが可能と判定した場合は、サービスバスを構成するＰｎＰ（Plug and Play）基盤にサービスをインストールする。

ＰｎＰ基盤は、サービスをインストールした場合は、そのことをインストール管理サービスのローカルサービスバスに応答する。
インストール管理サービスのローカルサービスバスは、その応答に応じてサービスインストールを自己のアダプタに通知するので、その通知はインストール管理サービスに通知される。
以上のようにして、インストール管理サービスは、サービスが正常にインストールされたことを確認することができる。

一方、インストール管理サービスのローカルサービスバスは、サービスの起動をＰｎＰ基盤に要求する。ＰｎＰ基盤は、その要求に応じてサービスの起動をインストール対象サービスに要求し、インストール対象サービスは、その要求に応じて自己のアダプタにサービスの起動を要求すると共にサービス情報の登録を要求する。

インストール対象サービスのアダプタは、サービス情報を登録した場合は、そのことをインストール管理サービスのローカルサービスバスに通知する。
以上のようにして、インストール管理サービスのローカルサービスバスは、インストールしたサービスが可能となったことを確認することができるので、インストール対象サービスのアダプタにサービス開始を要求し、その要求はインストール対象サービスに要求される。

インストール対象サービスは、その要求に応じてサービスを開始し、サービス開始を自己のアダプタに応答し、その応答はインストール管理サービスのローカルサービスに応答される。
以上のようにして、インストール管理サービスのローカルサービスは、インストールしたサービスが利用可能となったことを確認することができる。

ところで、ローカルサービスバス１５が搭載されていない車載装置が車両に搭載されることが想定される。このような場合、当該車載装置に関してサービスバス１３を構築できないことから、当該車載装置の機能を統合アプリ１８が利用できないことになる。

そこで、ローカルサービスバス１５が搭載されていない車載装置の機能を統合アプリ１８が利用する場合は、図１３に示すように、基本ＧＷ２に車両情報提供プロキシサービス２８を搭載する。この車両情報提供プロキシサービス２８は、ローカルサービスバス１５が搭載されていない車載装置とサービスバス１３との間を中継するメッセージの翻訳者として機能する。

このような構成によれば、基本ＧＷ２に搭載された統合アプリ１８は，ローカルサービスバス１５を搭載していない車載装置の機能を利用可能となるので、基本ＧＷ２により車両制御サービスを管理することが可能となる。この場合、車両情報提供プロキシサービス２８がサービスＩ／Ｆ１２やアダプタ１１を搭載していない車載装置との間の通信を仲介するので、基本ＧＷ２により車載装置を隠蔽することができる。

また、車両情報提供プロキシサービス２８を設けたことでクラウド／エッジ側のメッセージ送受信や、ローカルサービスバス１５が搭載されていないＥＣＵ４～７との間のＣＡＮ通信や、サービスバスメッセージ送受信のプロトコルの相違を吸収可能となる。

一方、エッジサーバ９にローカルサービスバス１５が搭載されていない場合は、エッジサーバ９との間でサービスバス１３を構築することができないので、図１４に示すように、拡張ＧＷ１にサーバプロキシサービス２９を搭載する。このサーバプロキシサービス２９は、車両側のサービスバス１３とエッジサーバ９との間を中継するメッセージの翻訳者として機能することになる。

このような構成によれば、車外装置にローカルサービスバス１５を搭載する必要がないので、車外装置として汎用のものを利用することが可能となる。また、拡張ＧＷ１により車載装置を隠蔽することができる。

さて、エッジサーバ９に統合アプリ１８を搭載した場合、統合アプリ１８により車外装置から車両制御サービスを管理する仮想車両を実現することが考えられる。つまり、車両制御を実行する頭脳を車外装置に設け、車両側には車両を実際に制御する手足を設けるというもので、車両側には制御に関わるリアルタイム性の高いサービスのみをダウンロードすれば良いと共に、車両側の制御負荷の軽減を図ることができる。

このような構成によれば、エッジ空間に位置する車両の自動運転を補助したり、エッジ空間に位置する複数の車両を統合制御したりすることが可能となる。
しかしながら、このように車外装置から車両を制御する構成では、セキュリティの脆弱性が懸念される。

そこで、図１５に示すように、エッジサーバ９に仮想車両プロキシサービス３０を搭載する。この仮想車両プロキシサービス３０は、車両側のサービスバス１３とエッジサーバ９との間を中継するメッセージの翻訳者として機能することになる。エッジサーバ９毎に仮想車両プロキシサービス３０の翻訳規約（プロトコル）が異なるような場合は、クラウドサーバ上で仮想車両プロキシサービスの翻訳規約を公開し、車両側がその翻訳規約を取得することで翻訳規約に適合したメッセージによる通信を行うことが可能となる。

このような構成によれば、エッジサーバ９に仮想車両プロキシサービス３０を搭載することで、セキュリティ性を確保しながら、ＯＥＭによる車両仕様の相違、車種の相違、さらにはエッジサーバ９側のセンサの相違等を吸収可能となる。

ところで、自車を自律制御により自動運転する際に、基本的には自車が有するセンシング情報に基づいた自律走行機能により自動運転は可能であるが、交通網を構成する場所によっては、自車ではセンシングできないものの、例えば監視カメラによるセンシング情報を、自動運転を支援する情報として利用することが可能となる。この場合、自車がクラウドサーバにより統合管理されるセンシング情報をサービスとして利用することが考えられる。

しかしながら、クラウドサーバが物理的に離れた場所に配置されていたり、クラウドサーバが扱う情報量が膨大なことによる処理時間の長時間化等により自車がクラウドサーバにより取集されたセンシング情報を取得するまでに時間を要したりするおそれがある。また、クラウドサーバの統合管理によるデータ量の爆発的な増加に対して、車両数やデータ量と比較してクラウドサーバの絶対数が少ないこともサービスの応答性が低下する要因となる。このため、クラウド連携には応答性が悪く、高速の対応が要求される交通状況には対応が困難である。

このような事情から、クラウドサーバのエッジとしてエッジサーバ９が設けられており、応答性の改善を図っている。このようにクラウドサーバとの間にエッジサーバ９を設けることで車外装置から提供可能なサービスの多様性を図ることができる。

車外装置から提供可能なサービスとしては、高度運転支援（自動運転）、テレマティクスサービス、高度運転支援、ビッグデータサービス等が考えられる。
（１）高度運転支援（自動運転）
高い応答性が要求される車両側が主体となるサービスであり、同一車線自動走行、車両死角認知、オートバレーパーキング、すれ違い支援、車両距離表示等である。

（２）テレマティクスサービス
車外のテレマティクスサービスと連携するサービスであり、ｅＣａｌｌ（emergency call）／ｂＣａｌｌ（Breakdown Call）、リモートスタータ、後進支援、運転者運転状態監視、家電／ＨＥＭＳ制御、エンターテインメント連携（音楽、ビデオ）、車内空調制御、スピード超過補助等である。

（３）高度運転支援
エッジ空間で提供されるサービスであり、飛び出し歩行者通知、周辺・死角情報提供、前方死角支援、ＥＶ充電予約、ホームセキュリティ、ドア／ライト／ホーン制御等が想定される。

（４）ビッグデータサービス
多くの情報量を必要とするクラウド側が主体となるサービスであり、クラウドサーバと車両とが対話して車両を診断するクラウド診断、クラウドとの通信セキュリティの穴に対するアタックを監視してその穴を埋めるバッチソフトを配信するアタック監視、クラウドサーバから車両のソフトを通信により書換えるＯＴＡリプログ、車両の運行管理、高精度地図の自動作成、運転適性に基づく自動車保険、盗難車追跡、空きパーキング通知、スマートグリッド、エコ診断、シェアカー等が想定される。

次に、統合アプリ１８が車内サービスやエッジサーバ９から提供される車外サービスを、サービスバス１３を介して連携して利用する場合の動作について説明する。統合アプリ１８の動作として、エッジサーバ９から提供される自車、他車、歩行者の位置情報を基に衝突判定し、衝突の危険性がある場合にディスプレイ３に注意喚起する場面を想定する。

図１６に示すように、自車が、ロケータＥＣＵ４の位置情報提供サービスにより車外サービスを提供するエッジ空間に進入すると、エッジサーバ９が自車に対してサービスが有ることを通知する。すると、車外サービスを認証し、インストール管理サービスが、車外サービスが使用する車載サービスが存在するかをサービスバス１３に問い合わせる。この場合、統合アプリ１８を実現するための最低限必要な車載サービスが存在しない場合は終了する。一方、最低限必要な車載サービスは存在するが、全てのスペックで車載サービスや車載センサが搭載されていない場合は、サービスの実行結果に差を生じる。例えば、ブラインド回避アプリであれば、ブレーキＥＣＵ５のサービスとしてブレーキ制御サービスが搭載されている場合はブレーキを制御して自車を停止するが、ブレーキ制御サービスが搭載されていない場合は、ディスプレイ３に搭載されている画像表示サービスによる注意喚起表示に留めることになる。

次に、統合アプリ１８が車載サービスと車外サービスとを同時に使用する場合は、統合アプリ１８が使用する車載サービスと車外サービスとをサービスバス１３が接続してから、車載サービスと車外サービスとが連携して、ユーザに統合アプリ１８を提供する。
以上のようにして、統合アプリ１８は、車載サービスと車外サービスとを連携したサービスをユーザに提供することができる。

次に、統合アプリ１８が車載サービスと車外サービスとを連携する一例として、ブラインド回避アプリについて説明する。
図１７に示すように、ロケータＥＣＵ４の位置情報提供サービスは、位置情報を繰り返して出版している。

一方、車外サービスを持つエッジサーバ９は、エッジ空間に対しサービスがあることを通知している。自車がエッジサーバ９のエッジ空間に進入すると、拡張ＧＷ１のサービスバス１３が車外サービスを認証し、車外サービスが使用する車載サービスが自車の中に存在するか、基本ＧＷ２のサービスバス１３に問い合わせる。

基本ＧＷ２は、車外サービスが使用する車載サービスが自車の中に存在するか、サービスバス１３に問い合わせ、車外サービスが利用するサービスの購読処理を行ってから、購読するサービスに対するアクセス制御を行い、必要な車載サービスが存在した場合、車外サービスを許可する。

エッジサーバ９の衝突判定サービスは、自車から出版通知を受信すると、出版受信処理を実行し、自車からの位置情報に加えて、他デバイス１０から位置情報を収集し、自車、歩行者、他車の位置情報から衝突の危険性を判定し、衝突の危険性があると判定すると、衝突の危険性を表示するための画像表示の要求を通知する。この要求が拡張ＧＷ１のブラインド回避アプリに通知されると、ブラインド回避アプリは、要求受信処理を実行し、衝突の危険性があるため、ディスプレイ３に注意喚起し、画像表示の要求をサービスバス１３に通知する。

ディスプレイ３の画像表示サービスは、サービスバス１３から画像表示の要求を受信すると、要求受信処理を実行し、ディスプレイ３に注意喚起を表示する。尚、注意喚起の方法としては、音声通知サービスによる音声通知としても良い。

以上のようにして、例えば交差点のブラインドに歩行者や他車が存在した場合には、ディスプレイ３に衝突の危険性が表示されるので、運転者は、ブランインドに注意しながら運転するようになり、衝突の危険性を事前に回避することができる。

ここで、上述したように車両の移動に伴って使用したい車外サービスが随時変化するような場合に、静的なソフト書換えによりサービスを提供したのでは、リアルタイム性の高い車外サービスとの連携が動的に困難である。尚、動的とは、システムの動作状態でリスタートすることなく実行可能であることを意味する。

そこで、以下のようにして動的なソフト書換えを行うことでリアルタイム性の高い車外サービスとの連携するようにした。つまり、車両が有するスペックに合わせてエッジ空間毎に動的なソフト書換えを行うことで車両の動作を変更する。この動的なソフト書換えとは、拡張ＧＷ１に新規アプリをインストールすることであり、インストールされた新規アプリは、サービスＩ／Ｆ、アダプタによってサービス化された車両制御機能を利用する統合アプリ１８を生成する。

このように統合アプリをエッジ空間毎に生成する例としては、図１８に示すように、クラウドサーバ３１と接続された複数のエッジサーバ９の狭域通信領域であるエッジ空間が交通網の一部である例えば会社の駐車場、道路、交差点、自宅に設けられている。エッジ空間に自車が進入すると、当該エッジ空間のエッジサーバ９と自車とが通信によりサービスをインストールすることで統合アプリを生成すると共にサービスバスを構築し、エッジ空間に対応したサービスを順次実行するというものである。

具体的には、衝突の危険性がある場合に、自車のブレーキを制御したい場合は、ブレーキＥＣＵ５、ブレーキＥＣＵアダプタ１１、ブレーキＥＣＵサービスバス１３、ブレーキ制御サービスを追加する。位置情報をカメラ画像から取得したい場合は、カメラＥＣＵ７、カメラＥＣＵアダプタ１１、カメラＥＣＵサービスバス１３、画像撮影サービスを追加する。

カメラＥＣＵ７の画像撮影サービスを利用した統合アプリ１８の例としては、会社の駐車場走行時は、車載カメラを駐車空スペース検出カメラとして機能させ、駐車場監視カメラと連携することで、駐車空スペースを検知して通知する。道路走行時は、車載カメラを前方監視カメラとして機能させ、道路に設置された監視カメラと連携することで、前方車両や自転車や歩行者等の接近を検知してブレーキを制御する。交差点走行時は歩行者検知カメラとして機能させ、交差点に設置された監視カメラと連携することで、交差点のブラインドに隠れた歩行者を検知し、歩行者の存在を通知したり、ブレーキを制御したりする。自宅到着時は、防犯カメラとして機能させ、自宅の監視カメラと連携することで、不審者を検知してホーンやライトで威嚇する。

交差点に設置された信号機等の車外のインフラ情報を利用したい場合は、車外インフラにローカルサービスバス１５及びインフラ情報提供サービスを追加する。例えば信号機にローカルサービスバス１５及び信号情報提供サービスを搭載し、信号機と連携することで信号機の切替時間を通知したり、自車の停止状態で信号機が切替わったことを通知したりする。
サービスバス１３が車外装置の各サービスを動的にルーティングし、繋ぐことで、既販車に対して、車外装置から新規アプリを追加することも可能である。

このような実施形態によれば、次のような効果を奏することができる。
車載装置や車外装置であるエッジサーバ９との間でメッセージの送受信を中継する仮想的なサービスバス１３を構築し、統合アプリ１８により車載サービスとエッジサーバ９が提供する車外サービスとを連携して利用するようにしたので、エッジサーバ９が提供する車外サービスの速い進化に合わせて、車両の機能を進化させることができる。

サービス管理部１３ａがサービスの位置を管理することでサービスを動的に相互利用可能としているので、車載装置と車外装置の機能を動的に相互利用することができる。
サービス管理部１３ａがサービスの抜き差しを管理することでサービスの動的な抜き差しを可能としたので、車載装置や車外装置を動的に抜き差しできる。

拡張ＧＷ１と各ＥＣＵ４～７との間のデータの送受信を仲介する基本ＧＷ２のサービスバス１３にサービス管理部１３ａを搭載するようにしたので、車内外のサービスを動的に管理できる。これにより、アプリケーション開発者は、利用したアプリケーションの位置及び抜き差しを意識することなくアプリケーションを開発することができる。

基本ＧＷ２や拡張ＧＷ１に車両情報提供プロキシサービス２８を搭載するようにしたので、ローカルサービスバス１５が搭載されていない車載装置が有する機能を他のサービスが利用することができると共に、車外装置から車載装置を秘匿することができる。

エージサーバ９に搭載した統合アプリ１８によりサービスバス１３を介して車両を制御する仮想車両を実現する場合は、エッジサーバ９に仮想車両プロキシサービス３０を搭載するようにしたので、セキュリティが低下してしまうことを防止することができる。

車載装置はエッジサーバ９との間で近距離通信するので、クラウドサーバ３１から車外サービスの提供を受ける場合と比較して、エッジサーバ９から高速で車外サービスの提供を受けることができる。

エッジサーバ９の狭域通信エリアは車両の走行シーンに対応した所定領域であることから、車外サービスの提供範囲を限定することができる。
エッジサーバ９の車外サービスは狭域通信エリア特有のサービスであることから、自宅を出発して、目的地に出発するまでのエッジ空間を渡り歩く中で、エリア毎に異なる車外サービスと連携し、自律制御を補完することができる。

エッジサーバ９は、車外サービスとして自車がセンシングできないブラインドに関する情報を提供するので、自動運転時の安全性を高めることができる。
エッジサーバ９はクラウドサーバのエッジとして設けられているので、車載装置から収集した情報をクラウドサーバ３１により集中管理してクラウド情報として車載装置に提供することが可能となる。

（その他の実施形態）
上記実施形態では、エッジサーバ９と無線通信によりサービスバス１３を構築するようにしたが、例えば公衆無線通信網を介してサービスバス１３を構築するようにしても良い。この場合、統合アプリ１８を生成する場合に、位置情報提供サービスによる位置情報に基づいて都道府県（州）毎（つまり地域毎）や国毎に異なるサービスをインストールして統合アプリを生成するようにしても良い。また、位置情報提供サービスによる位置情報に基づいて都道府県（州）毎（つまり地域毎）や国毎に適した高度運転支援（自動運転）、テレマティクスサービス、高度運転支援、ビッグデータサービスを提供するようにしても良い。

上記実施形態では、車両用サービス連携システムを自動運転システムに適用した例を示したが、手動運転時にブラインドに存在する人や車両を注意喚起するようにしても良い。
他車のサービスバス１３と接続することで、走行時に他車の接近を通知したり、他車との衝突を事前回避したりするようにしても良い。

本開示は、実施例に準拠して記述されたが、本開示は当該実施例や構造に限定されるものではないと理解される。本開示は、様々な変形例や均等範囲内の変形をも包含する。加えて、様々な組み合わせや形態、さらには、それらに一要素のみ、それ以上、あるいはそれ以下、を含む他の組み合わせや形態をも、本開示の範疇や思想範囲に入るものである。

図面中、１は拡張ゲートウェイ（車載装置）、２は基本ゲートウェイ（車載装置）、３はディスプレイ（車載装置）、４～７はＥＣＵ（車載装置）、９はエッジサーバ（車外装置）、１２はサービスインターフェース、１３はサービスバス、１３ａはサービス管理部、１８は統合アプリ、１５はローカルサービスバス、２８は車両情報提供プロキシサービス、３０は仮想車両プロキシサービス、３１はクラウドサーバである。

Claims (11)

1. 車載ネットワーク（８）に接続された車載装置（１～７）や無線通信により接続された車外装置（９）の機能をサービスとして利用する車両用サービス連携システムであって、
   前記車載装置または前記車外装置である他装置に搭載されたアプリケーションからの要求に応じて当該他装置に対してサービスを要求すると共に、前記他装置からサービスの要求を受けた場合は自己の機能をサービスとして生成して応答するサービスインターフェース（１２）と、
   自己の前記サービスインターフェースと前記他装置の前記サービスインターフェースとの間で所定のプロトコルによりサービスの要求及び応答に対応したメッセージを送受信するローカルサービスバス（１５）と、
   前記ローカルサービスバス上のサービスをインストール可能とすると共に車載通信や車外通信等の下位層を隠蔽するように前記ローカルサービスバスが互いに接続されることで仮想的に構築されるサービスバス（１３）と、
   前記車載装置が提供する車載サービスと前記車外装置が提供する車外サービスとを前記サービスバスを介して連携して利用するアプリケーションである統合アプリケーション（１８）と、
   を備えた車両用サービス連携システム。
2. 前記サービスの位置を管理することで前記サービスを他装置との間で動的に相互利用可能とするサービス管理部（１３ａ）を備えた請求項１に記載の車両用サービス連携システム。
3. 前記サービス管理部は、前記サービスの抜き差しを管理することで前記サービスの動的な抜き差しを可能とする請求項２に記載の車両用サービス連携システム。
4. 前記ローカルサービスバスを有しない他装置との間でメッセージの送受信を中継することで前記サービスバスを構築する車両情報提供プロキシサービス（２８）を備えた請求項１から３のいずれか一項に記載の車両用サービス連携システム。
5. 前記車外装置は、前記統合アプリケーションが搭載されており、前記車載装置のローカルサービスバスとの間でメッセージの送受信を中継することで前記サービスバスを構築する仮想車両プロキシサービス（３０）を備えた請求項１から４のいずれか一項に記載の車両用サービス連携システム。
6. 前記車載装置は、前記車外装置と近距離通信する請求項１から５のいずれか一項に記載の車両用サービス連携システム。
7. 前記車外装置は、車両の走行シーンに対応した所定領域を狭域通信エリアとする請求項６に記載の車両用サービス連携システム。
8. 前記車外装置は、前記狭域通信エリア特有のサービスを提供する請求項７に記載の車両用サービス連携システム。
9. 前記車外装置は、前記狭域通信エリア特有の前記車外サービスとして自動運転を支援するためのサービスを提供する請求項８に記載の車両用サービス連携システム。
10. 前記車外サービスは、車両が前記狭域通信エリアに進入したときにインストールされる請求項７から９のいずれか一項に記載の車両用サービス連携システム。
11. 前記車外装置は、クラウドサーバ（３１）のエッジとして設けられたエッジサーバである請求項１から１０のいずれか一項に記載の車両用サービス連携システム。

Images