JP2017220220A - 車両用電子制御装置及び車両用サービス管理システム - Google Patents

Abstract

【課題】車両用電子制御装置の機能を動的に相互利用することができるようにする。【解決手段】機能をサービスとしてサービスバス９に接続するサービスＩ／Ｆ８を設け、サービスがサービスＩ／Ｆ８を介して他のサービスを利用可能とし、さらにサービス管理部がサービスの位置を管理することでサービスを動的に相互利用可能とした。これにより、ＥＣＵ３〜５の機能を動的に相互利用することができるので、アプリケーション開発者は、最上位のアプリ層よりも下位のレイヤの存在を意識する必要なくアプリケーションを開発することができる。【選択図】図３

Description

本発明は、車両用電子制御装置及び車両用サービス管理システムに関する。

近年、車両では各種の車両機器を制御する電子制御装置が車載ネットワークによって接続されることで、連携して動作させることが行われている。さらには、車外のシステム（交通情報、娯楽情報、メールサービスなどを提供するサーバーや、家庭内システム）とも無線通信によって接続されることで、外部のシステムと連携することが行われつつある。

このようなシステムを連携する車両情報プラットフォームにおいて、従来は、アプリケーションを動作させるプラットフォームを同一にすることにより、新規システムを構築する際のアプリケーションの再利用性や、複数のアプリケーション間の相互運用性を確保することが提案されている（特許文献１参照）。

特開２０００−１６５４２２号公報

ところで、車両には、エンジン制御のような定期的にデータを収集して結果を常時出力する高度な信頼性が求められるアプリケーションや、ボデー系制御のようなユーザの操作をイベントとして一連のシーケンスを実施するアプリケーションや、ナビゲーションのような大規模なデータを使用するが比較的信頼性が求められないアプリケーション等、異質なアプリケーションが実装された複数の電子制御装置が共存している。

しかしながら、車両内でネットワーク化される複数の電子制御装置の機能を動的に相互利用する仕組みがなく、柔軟性が低いことが問題となっている。このため。アプリケーション開発者は、最上位のアプリ層よりも下位のレイヤの存在を意識する必要があり、アプリケーションの開発性を低める要因となっている。

本発明は上記事情を考慮してなされたもので、車両用電子制御装置の機能を動的に相互利用することができる車両用電子制御装置及び車両用サービス管理システムを提供することにある。

請求項１及び請求項５の発明によれば、車両用電子制御装置（１〜５）のアプリケーションが他の車両用電子制御装置（１〜５）の機能を利用する場合は、サービスインターフェース（８）を利用して他の車両用電子制御装置（１〜５）のサービスインターフェース（８）に対してサービスを要求する。すると、他の車両用電子制御装置（１〜５）のサービスインターフェース（８）は、車両用電子制御装置の機能をサービスとして生成して応答する。このとき、サービス管理部（１１）がサービスの位置を管理することでサービスを動的に相互利用可能としているので、車両用電子制御装置（１〜５）の機能を動的に相互利用することができる。

尚、動的とは、システムの動作状態でリスタートすることなく実行可能であることを意味する。

一実施形態における各ＥＣＵの機能ブロック図 車両用サービス管理システムを示すブロック図 アダプタが提供するサービスＩ／Ｆ及びサービスバスとの関係を示す図 アプリケーションの機能とサービスとの関係を示す図 サービス諸元情報を示す図 他のサービス諸元情報を示す図 サービス開始の処理シーケンスを示す図 要求送信時の処理シーケンスを示す図 出版送信時の処理シーケンスを示す図 統合アプリケーションの動作を示す図 車両用サービス管理システムの変形例を示すブロック図 統合アプリケーションの動作を示す図

以下、一実施形態について図面を参照して説明する。
車両用サービス管理システムは、図２に示すように、車両用電子制御装置としての拡張ゲートウェイ（（ＤＣＭ（Data Communication Module）／ＨＣＵ（ＨＭＩ（Human Machine Interface） Control Unit））、以下、拡張ＧＷと称する）１、基本ゲートウェイ（ＣＧＷ（Central gateway）、以下、基本ＧＷと称する）２（ゲートウェイに相当）、エンジンＥＣＵ（Electronic Control Unit）３、ブレーキＥＣＵ４、メータＥＣＵ５が車載ネットワーク６により接続されることで構成されている。車載ネットワーク６のプロトコルは、ＣＡＮ（Controller Area Network）、ＬＩＮ（Local Interconnect Network）、ＦｌｅｘＲａｙ、Ｅｔｈｅｒｎｅｔ（登録商標）などでドメイン毎に適切なプロトコルが用いられる。尚、図２は代表的なＥＣＵを示したものであり、実際には車載ネットワーク６には１００台近くのＥＣＵが接続されている。

拡張ＧＷ１には車外通信サービスが搭載されており、車外のサービスを無線通信やケーブル接続により利用可能となっている。車外のサービスとしては、外部のシステム（交通情報、娯楽情報、メールサービスなどを提供するサーバーや、家庭内システム）が提供するサービスである。

基本ＧＷ２は、各ＥＣＵ３〜５が所属するドメイン間の情報をルーティング（中継）する機能を有する。ドメインとしては、車外サービス系ドメイン、人間系ドメイン、環境系ドメイン、ボデー系ドメイン、運動系ドメインなどである。基本ＧＷ２には図示しない管理テーブルが搭載されており、その管理テーブルにより後述するサービスの動的な追加や削除（抜き差し）を管理する。尚、動的とは、システムの動作状態でリスタートすることなく実行可能であることを意味する。

各ＧＷ１，２、及び各ＥＣＵ３〜５には周知の制御装置が設けられている。制御装置は、ＣＰＵ、ＲＯＭ、ＲＡＭ、Ｉ／Ｏを有するマイクロコンピュータにより構成されており、非遷移的実体的記録媒体に格納されている機能を実行することで、機能に対応する処理を実行する。

各ＥＣＵ３〜５には、当該ＥＣＵ３〜５により実行される各種の機能を他のＥＣＵが利用可能とするためのサービスを提供する機能がソフトウェアにより実装されている。このようなサービスにより、アプリケーションは、他のサービスに所望の機能の実行要求を行おうとした場合に、予め定められた要求情報のフォーマットの形式で要求情報を与えれば良い。要求情報は、他のサービスに対し、所望の機能を行うためのメッセージにより与えられる。

本実施形態では、図１に示すように、拡張ＧＷ１には燃費改善アプリケーション及び車外通信サービスが搭載されている。この燃費改善アプリケーションが燃費の改善を図るために用いるサービスとしては、エンジンＥＣＵ３に情報提供サービスやアクセル制御サービスが搭載されている。情報提供サービスは、燃料消費量提供サービス、エンジン温度提供サービス、エンジン冷却水温度提供サービス、エンジンオイル温度提供サービス等である。アクセル制御サービスは、ユーザによるアクセル制御を補助的に制御するものである。同様にブレーキＥＣＵ４にはブレーキ制御サービスが搭載されている。ブレーキ制御サービスは、ユーザによるブレーキ制御を補助的に制御するものである。メータＥＣＵ５には車速提供サービスが搭載されている。

一方、車外通信サービスは、車内外のサービスやアプリケーションが相互利用で連携するための機能である。つまり、車外通信方式は、物理層、プロトコルを含めて様々な方式を採用可能であることから、サービスバスの機能とはせず、１つのサービスとしてサービスバス上へ搭載されている。

以下、本実施形態におけるサービスを提供する機能に関して説明する。まず、車両における各種の車載機器による機能をサービスとして規定し、これらのサービスに関しては、車両情報プラットフォーム上での各サービスの使用方法を規定する。これにより、アプリケーションが他のアプリケーションによるサービスを使用する場合には、その使用方法に従うことになる。

さて、各ＥＣＵ３〜５や車外のクラウド、モバイル機器などのスマートフォン等の機器は、互いの機能を直接的に相互利用することができないと共に、サービスの削除や追加（抜き差し）に対応することができないことから、サービスの相互利用及びサービスの抜き差しを可能とするために、図３に示すように、アダプタ７が提供するサービスインターフェース（以下、サービスＩ／Ｆ）８と、所定のプロトコルによりサービスの要求及び応答に対応したメッセージを送受信するサービスバス９とを設けた。サービスバス９は、ハードウェア（Ｈ／Ｗ）１０を介して車載ネットワーク６と接続されている。

サービスバス９は、サービスの位置及び抜き差しを管理するサービス管理部の機能を有しており、本実施形態では、図１に示すように、サービス管理部１１を基本ＧＷ２に搭載した。つまり、基本ＧＷ２は、ドメイン間の情報をルーティングテーブルに基づいてルーティングする機能と、サービスの位置及び抜き差しを管理する機能とを有する。

ルーティングする機能とは、送信ＥＣＵと受信ＥＣＵとがＧＷを跨いだ異なるバスに接続されている場合に、受信ＥＣＵが必要とするメッセージＩＤをＧＷのルーティングテーブルに登録することである。つまり、ルーティングテーブルは、送信ＥＣＵのバスへメッセージをルーティングするためのルールが記載されたテーブル（バスＩＤとメッセージＩＤの組合せ）である。車載ネットワークにおけるメッセージＩＤとは、ＣＡＮ−ＩＤを指すのが通常である。

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

サービスＩ／Ｆ８は、アダプタ７が提供するインターフェースであり、車内外のサービスやアプリケーションがＥＣＵ３〜５や車外のクラウドやスマートフォン等の既存機能をサービスとして利用することを可能とする。サービスＩ／Ｆ８を持たせることでサービスやアプリケーションが機能をサービスとして利用できるようにするプロセスを「機能のサービス化」と呼ぶ。また、複数のサービスを連携するアプリケーションを統合アプリケーション（以下、統合アプリと称する）と呼ぶ。

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

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

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

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

サービスが提供する情報（属性）は、図５に示すサービス諸元情報を採用することを想定しているが、図６に示すような他のサービス諸元情報を採用するようにしても良い。
サービス諸元情報は、図５に示すサイズ（bit）により規定され、その意味は以下の通りである。

（１）サービスＩＤ
サービスを一意に特定するための識別子（０〜４２９４９６７２９５）を示す。

（２）サービスバージョン
サービスのバージョンを示す。
形式：［Ｉ／Ｆバージョン（８bit）］.［内部バージョン（８bit）］
Ｉ／Ｆバージョン…利用者に影響のある修正実施時にインクリメントする
・Ｉ／Ｆを追加した場合
・Ｉ／Ｆを削除した場合
・バージョンアップ前後で、Ｉ／Ｆの互換性がない場合
内部バージョン…利用者に影響のない修正実施時にインクリメントする
Ｉ／Ｆバージョンが変更された場合は、０に戻す

（３）ロール
サービスに割り当てられたロールを示す。該当するロールのビットを１とする。
bit０…ＯＥＭ、bit１…サプライヤ、bit２…３rd party、bit３〜１５…reserve

（４）ハートビート間隔
サービス異常を検知するためのハートビートの送信間隔（１〜６５５３５秒）を示す。秒オーダで指定し、０の場合はハートビート送信を行わない。

（５）ローカルサービスバスＩＤ
サービスがインストールされているローカルサービスバスを一意に特定するための識別子（０〜６５５３５）を示す。

（６）サービス状態
サービスの稼動状態を示す。
０：サービス開始不可、１：サービス開始可能、２：サービス開始済み

（７）提供するサービスＩ／Ｆ数
サービスが提供するサービスＩ／Ｆの数（０〜６５５３５）を示す。０の場合、「提供するサービスＩ／Ｆ」は保持しない。

（８）サービスＩ／Ｆ ＩＤ
サービスが提供するサービスＩ／ＦのＩＤ（０〜６５５３５）。

（９）提供方式
サービスＩ／Ｆの提供方式を示す。
０：Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ、１：Ｐｕｂｌｉｓｈ／Ｓｕｂｓｃｒｉｂｅ

（１０）Ｓｕｂｓｃｒｉｂｅ数
Ｐｕｂｌｉｓｈ／ＳｕｂｓｃｒｉｂｅのサービスＩ／Ｆに対して、Ｓｕｂｓｃｒｉｂｅしているサービスの数（０〜２５５）を示す。０の場合、「Ｓｕｂｓｃｒｉｂｅサービス情報」は保持しない。

（１１）利用するサービス数
サービスが利用する他のサービスの数（０〜２５５）を示す。０の場合、「利用するサービス情報」は保持しない。

（１２）利用サービスバージョン指定
「利用するサービス情報」の「サービスバージョン」指定方法を示す。
形式：［Ｉ／Ｆバージョンのバージョン指定（３bit）］［内部バージョンのバージョン指定（３bit）］

０：固定バージョン…「利用するサービス情報」の「サービスバージョン」の「Ｉ／Ｆバージョン」、または「サービスバージョン」が示す値と同一のサービスのみ利用する。
１：指定バージョン以上…「利用するサービス情報」の「サービスバージョン」の「Ｉ／Ｆバージョン」、または「サービスバージョン」が示す値以上のサービスを利用する。

２：指定バージョン以下…「利用するサービス情報」の「サービスバージョン」の「Ｉ／Ｆバージョン」、または「サービスバージョン」が示す値以下のサービスを利用する。
３：最新バージョン…指定のサービスＩＤの全サービス中、「サービスバージョン」の「Ｉ／Ｆバージョン」、または「サービスバージョン」が示す値が最も大きいサービスを利用する。「利用するサービス情報」の「サービスバージョン」の値は不定とする。

例えば、「利用するサービス情報」のサービスバージョン＝３.２、「Ｉ／Ｆバージョンのバージョン指定」＝固定バージョン、「内部バージョンのバージョン指定」＝指定バージョン以下の場合は、利用対象となるサービスのバージョンは３.２、３.１、３.０となる。

次に、上述したサービスを提供するためのプログラムの開発言語について簡単に説明する。
１．Adapter
（１）サービス開始（Start）
サービス開始（Start）は、サービスを開始する。

（２）サービス開始完了（onStarted）
サービス開始完了（onStarted）は、サービス開始完了時のハンドラであり、サービス開始（Start）を呼び出した後、サービス開始が完了した際に、１回のみ呼び出される。

（３）サービス開始状態取得
サービス開始状態取得（isStarted）は、サービスの開始が完了済みかどうかを取得する。

（４）サービス情報取得（getServiceInfo）
サービス情報取得（getServiceInfo）は、サービスの情報を所得するもので、サービス開始時に、サービス情報を本メソッドにより取得する。

（５）サービスＩＤ取得（getServiceId）
サービスＩＤ取得（getServiceId）は、サービスＩＤを取得するもので、サービス情報取得（getServiceInfo）で取得できる情報を基にサービスＩＤを返却する。

（６）サービスバージョン取得（getServiceVersion）
サービスバージョン取得（getServiceVersion）は、サービスバージョンを取得するもので、サービス情報取得（getServiceInfo）で取得できる情報を基にサービスバージョンを返却する。

（７）サービス情報プロトコル取得（getServiceProtocol）
サービス情報プロトコル取得（getServiceProtocol）は、サービスが提供するプロトコルを取得する。

（８）利用サービス情報取得（getRequireServiceInfo）
利用サービス情報取得（getRequireServiceInfo）は、利用するサービスのサービス情報を取得するもので、サービス開始時に、利用するサービスのサービス情報を本メソッドにより取得し、サービス開始処理を実施する。

（９）送信要求（request）
送信要求（request）は、指定されたサービスに要求を送信するもので、要求を正常に受け付けた場合には、要求受付番号を返す。要求に対する応答を受信した際に、応答受信ハンドラ（onResponseReceived）が呼び出される。
パラメータとして、要求先のサービスＩＤ、要求先のサービスバージョン、要求のデータ長、要求データ、要求の優先度が設定されている。

（１０）要求送信失敗（onRequestError）
要求送信失敗（onRequestError）は、要求送信失敗時のハンドラであり、要求受付番号（requestNumber）には、送信要求（request）の戻り値で発行された要求受付番号が格納される。
パラメータとして、失敗した要求に対応する要求受付番号が設定されている。

（１１）要求受信（onRequestReceived）
要求受信（onRequestReceived）は、要求受信時のハンドラであり、本メソッドで返した応答が、要求元サービスの応答受信（onResponse）に通知される。
パラメータとして、要求データ長、要求データが設定されている。

（１２）応答受信（onResponseRedeived）
応答受信（onResponseRedeived）は、要求に対する応答受信時のハンドラである。
パラメータとして、応答元のサービスＩＤ、応答元のサービスバージョン、要求の優先度、要求受付番号、応答データが設定されている。

（１３）出版送信（Publish）
出版送信（Publish）は、出版する。
パラメータとして、length（出版データ長）、data（出版データ）が設定されている。

（１４）出版受信（onPublishReceived）
出版受信（onPublishReceived）は、利用サービス情報取得（getRequireServiceInfo）で利用対象としたサービスから、出版を受信した際のハンドラである。
パラメータとして、出版元サービスＩＤ、出版元サービスバージョン、出版データ長、出版データが設定されている。

以上のようなアダプタ７により実現される処理シーケンスとして、サービス開始の処理シーケンスを図７に示し、要求送信時の処理シーケンスを図８に示し、出版送信時の処理シーケンスを図９に示した。

２．ServiceInfo
（１）コンストラクタ（ServiceInfo）
コンストラクタ（ServiceInfo）は、サービスＩＤとサービスバージョンからサービス情報を生成する。
パラメータとして、サービスＩＤ、サービスバージョン、サービスの提供プロトコルが設定されている。

（２）サービスＩＤ取得（getId）
サービスＩＤ取得（getId）は、サービスＩＤを所得する。

（３）サービスＩＤ設定（setId）
サービスＩＤ設定（setId）は、サービスＩＤを設定する。
パラメータとして、サービスＩＤが設定されている。

（４）サービスバージョン取得（getVersion）
サービスバージョン取得（getVersion）は、サービスバージョンを取得する。

（５）サービスバージョン設定（setversion）
サービスバージョン設定（setversion）は、サービスバージョンを設定する。
パラメータとして、サービスバージョンが設定されている。

（６）提供プロトコル取得（gerProtocol）
提供プロトコル取得（gerProtocol）は、提供プロトコルを取得する。

（７）提供プロトコル設定（setProtocol）
提供プロトコル設定（setProtocol）は、提供プロトコルを設定する。
パラメータとして、プロトコルが設定されている。

３．Response
（１）Responseは、応答データを１byteずつ指定してResponseを生成する。
パラメータとして、data1（応答データの１byte目）、data２（応答データの２byte目）が設定されている。
（２）応答バイトデータ取得（getPayloadBytes）
応答バイトデータ取得（getPayloadBytes）は、応答データをバイト配列で取得する。
（３）応答データ取得（getPayload）
応答データ取得（getPayload）は、応答データを取得する。

４．Protocol列挙体
Protocol列挙体の定義を示す。
（１）None（提供プロトコル無し）
（２）PUBLISH_AND_SUBSCRIBE（出版／購読のプロトコルを提供）
（３）REQUEST_AND_RESPONSE（要求／応答のプロトコルを提供）

次に、複数のサービスを連携する統合アプリの具体例について説明する。
図１において、エンジンＥＣＵ３に搭載された情報提供サービスである燃料消費量提供サービス、エンジン温度提供サービス、エンジン冷却水温度提供サービス、エンジンオイル温度提供サービスのプロトコルはPUBLISH_AND_SUBSCRIBEである。アクセル制御サービスのプロトコルはREQUEST_AND_RESPONSEである。ブレーキＥＣＵ４に搭載されたブレーキ制御サービスのプロトコルはREQUEST_AND_RESPONSEである。メータＥＣＵ５に搭載された車速提供サービスの通信プロトコルはPUBLISH_AND_SUBSCRIBEである。

以下、統合アプリの動作を、図１０に示すように、拡張ＧＷ１、基本ＧＷ２、エンジンＥＣＵ３、ブレーキＥＣＵ４、メータＥＣＵ５のサービス及びアダプタで記述する。
拡張ＧＷ１には燃費改善アプリケーションが搭載されている。この燃費改善アプリケーションは、各サービスを連携することで燃費の改善を図るためのものである。つまり、燃費改善アプリケーションは、メータＥＣＵ５の車速提供サービス、エンジンＥＣＵ３の各種情報提供サービスを使用して、燃費測定に必要な情報を取得し、取得した情報に基づいて燃費を測定し、燃費改善の余地があるか否かを判断する。燃費改善の余地があると判断した場合は、エンジンＥＣＵ３のアクセル制御サービス、ブレーキＥＣＵ４のブレーキ制御サービスを使用して、アクセル及びブレーキを補助的に制御することで燃費の改善を図る。

尚、燃費情報をディスプレイに表示する場合は、ディスプレイＥＣＵ、ディスプレイＥＣＵアダプタ、表示サービスを追加する。また、信号機のような車外のインフラ情報を利用したい場合は、車外インフラ、インフラ情報提供サービスを追加する。
この場合、予めサービスＩ／Ｆ８により機能をサービス化しておくことで、動的に統合アプリを生成して複数のサービスを連携することが可能となる。

ところで、例えばＩＴ（Information Technology）の変化に応じて統合アプリやアプリケーションのソフトを適宜更新する必要な場合がある。この場合、静的なソフト書換えでは、ユーザが車両を使用したいときに使用することができないことが課題となる。また、リアルタイム性の高い車外サービスと連携することを想定した場合、動的にソフトを更新できるシステムの構築が課題となる。

即ち、高度運転支援等、今後続出する統合アプリ開発の際にソフトを書換えしようとした場合に、その都度、ユーザが所有している車両に対して静的にソフトの書換えを実施することは、工数の関係で非現実的である。例えば車両のラインオフ後に車載ネットワークに新規ＥＣＵを追加する場合、既存ＥＣＵと追加ＥＣＵとが制御信号を送受信するために既存ＥＣＵを静的にソフト書換したり、基本ＧＷ２が新しい制御信号を中継（ルーティング）するために静的にルーティングテーブルを書換えしたりする必要を生じる。

以下、動的なソフト更新に関する具体例として、時間／天気／車速／車間／充電量（ハイブリッド車、電気自動車の場合）等の情報を基に走行環境を判断し、必要なタイミングで音声を鳴動し、運転者に注意喚起を促す統合アプリを生成する場合を説明する。この場合、静的にソフトを書換える構成では、追加した新規のアプリケーション（拡張ＧＷ１上の新規追加サービス）から送信される新しい制御信号に基づいて新しい動作を実行するために既存ＥＣＵや基本ＧＷ２のソフトの更新が必要となる。

そこで、図１１に示すように、拡張ＧＷ１は情報センタ１２と通信可能に構成されている。情報センタ１２は、図１２に示すように車両のサービス移動状態を監視しており、必要が生じた場合は拡張ＧＷ１に新規アプリケーション（新規サービス）をダウンロードする。

拡張ＧＷ１が新規サービスをインストールすると、拡張ＧＷアダプタは基本ＧＷアダプタにサービス登録を要求するので、基本ＧＷアダプタは、ルーティングテーブルを更新する。つまり、サービスを実行する場合に必要となるＥＣＵをルーティングテーブルに登録することでルーティングを更新する。

基本ＧＷアダプタは、その他ＥＣＵ１４から情報を収集しており、拡張ＧＷアダプタから情報の収集サービス実行を要求された場合は、その他ＥＣＵ１４から収集した各種情報を新規追加サービスに通知する。新規追加サービスは所定のアプリ処理を実行することで音声鳴動アダプタに音声鳴動を要求し、拡張ＧＷアダプタは、音声鳴動ＥＣＵ１３の音声鳴動ＥＣＵアダプタに対して音声鳴動のサービス実行を要求する。

音声鳴動ＥＣＵアダプタは、新規追加サービスからサービス実行が要求された場合は、音声鳴動サービスに対して応答受信を送信し、それに応じて音声鳴動サービスは音声を出力する。
以上のようにして、ソフトの書換えを行うことなくサービスを連携することで運転者に対して注意を喚起する統合アプリを生成することができる。

一方、ラインオフされた後の車両に対して、上述した燃費改善アプリケーションと同様な動作を実行する統合アプリを後付けしたい場合がある。このような場合、拡張ＧＷ１に新規アプリケーション（新規追加サービス）を追加し、予め各ＥＣＵが公開している情報提供サービス（燃料消費、エンジン温度、車速等）や制御サービス（アクセル、ブレーキ等）を連携して利用することで、燃費改善を図る統合アプリを動的に生成することができる。そして、統合アプリは、各ＥＣＵや車載センサから得た情報を基に燃費を測定し、燃費改善の余地があるかどうか判断し、その判断結果に基づいてブレーキ／アクセルを制御する。

尚、拡張ＧＷ１の機能を基本ＧＷ２に一体化して設けても良い。このような構成を採用した場合、コストを削減できると共に重量を削減して車両の軽量化を図ることができ、さらに車載ネットワークのグローバル通信量の削減を図ることができる。

このような実施形態によれば、次のような効果を奏することができる。
アプリケーションの機能をサービスとしてサービスバス９に接続するサービスＩ／Ｆ８を設け、サービスがサービスＩ／Ｆ８を介して他のサービスを利用可能とし、さらにサービス管理部（１１）がサービスの位置を管理することでサービスを動的に相互利用可能としたので、ＥＣＵ３〜５の機能を動的に相互利用することができる。これにより、アプリケーション開発者は、最上位のアプリ層よりも下位のレイヤの存在を意識する必要なくアプリケーションを開発することができる。

サービス管理部１１がサービスの抜き差しを管理することでサービスの動的な抜き差しを可能としたので、ＥＣＵ３〜５の機能を動的に抜き差しできる。
基本ＧＷ２にサービス管理部１１を搭載するようにしたので、車内外のサービスを動的に管理できる。これにより、アプリケーション開発者は、利用したいアプリケーションの位置及び抜き差しを意識する必要なくアプリケーションを開発することができる。

開発者がサービスの連携を考慮することなく、追加した新規追加サービスから既存のサービスを要求するだけで統合アプリを生成できる。つまり、複数の車内外のサービスを連携させることにより動的に統合アプリを安く早く開発できるので、開発効率を向上したり、進化し続ける車両を提供できる。

搭載した新規アプリケーションと既存サービスとが連携することにより新しい統合アプリを動的に生成できるので、ユーザはＩＴを含む車外サービスの進化に追従でき、車両の価値を継続的に向上できる。

拡張ＧＷ１と基本ＧＷ２とを独立して設け、両者の機能を分離するようにしたので、セキュリティ性を高めることができると共に統合アプリから車載制御機能を隠蔽することができる。

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

（その他の実施形態）
本発明は、上記実施形態に限定されることなく、次のように変形または拡張できる。
サービス管理部１１を基本ＧＷ２に搭載するようにしたが、これに限らず、拡張ＧＷ１の他、全てのＥＣＵ３〜５に配置したり、拡張ＧＷ１やＥＣＵ３〜５のいずれかに配置したりするようにしても良い。

基本ＧＷ２が持つサービス管理部の機能をいずれかのＥＣＵが持つようにしても良いし、複数のＧＷ、或いはＥＣＵが分散して持つようにしても良い。
プログラムの開発言語は、Ｊａｖａ（登録商標）、Ｃ言語、Ｃ＋＋、Ｒｕｂｙなどを用いることができる。
今後提供される各種サービスを連携するようにしても良い。

図面中、１は拡張ゲートウェイ（車両用電子制御装置）、２は基本ゲートウェイ（車両用電子制御装置、ゲートウェイ）、３〜５はＥＣＵ（車両用電子制御装置）、６は車載ネットワーク、８はサービスＩ／Ｆ、９はサービスバス、１１はサービス管理部である。

Claims (9)

1. 車載ネットワーク（６）に接続され、搭載されているアプリケーションにより所定の機能を実行する車両用電子制御装置（１〜５）であって、
   前記アプリケーションからの要求に応じて前記車載ネットワークに接続された他の車両用電子制御装置に搭載されている機能を利用するサービスを要求すると共に、前記他の車両用電子制御装置からサービスの要求を受けた場合はサービスを生成して応答するサービスインターフェース（８）と、
   前記サービスインターフェースと、前記他の車両用電子制御装置の前記サービスインターフェースとの間で所定のプロトコルによりサービスの要求及び応答に対応したメッセージを送受信するサービスバス（９）と、
   前記サービスの位置を管理することで前記サービスを動的に相互利用可能とするサービス管理部（１１）と、
   を備えた車両用電子制御装置。
2. 前記サービス管理部は、前記サービスの抜き差しを管理することで前記サービスの動的な抜き差しを可能とする請求項１に記載の車両用電子制御装置。
3. 前記車両用電子制御装置に搭載されている所定のアプリケーションは、他の車両用電子制御装置のサービスと連携することで統合アプリケーションを生成する請求項１または２に記載の車両用電子制御装置。
4. 前記サービスバスが前記車載ネットワークを介して通信するプロトコルとして、
   １対１でメッセージの要求／応答を行うＲｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ型と、
   不特定多数の購読登録者にメッセージを出版するＰｕｂｌｉｓｈ／Ｓｕｂｓｃｒｉｂｅ型とが設けられている請求項１ないし３のいずれか一項に記載の車両用電子制御装置。
5. 車載ネットワーク（６）に接続され、アプリケーションにより所定の機能を実行する車両用電子制御装置（３〜５）と、前記車載ネットワークに接続され、前記車両用電子制御装置間の情報をルーティングするゲートウェイ（２）と、を備えた車両用サービス管理システムであって、
   前記車両用電子制御装置は、
   前記アプリケーションからの要求に応じて前記車載ネットワークに接続された他の車両用電子制御装置に搭載されている機能を利用するサービスを要求すると共に、前記他の車両用電子制御装置からサービスの要求を受けた場合は前記アプリケーションによりサービスを生成して応答するサービスインターフェース（８）と、
   前記サービスインターフェースと、前記他の車両用電子制御装置の前記サービスインターフェースとの間で所定のプロトコルによりサービスの要求及び応答に対応したメッセージを送受信するサービスバス（９）と、を備え、
   前記ゲートウェイは、前記サービスの位置を管理することで前記サービスを動的に相互利用可能とするサービス管理部（１１）を備えた車両用サービス管理システム。
6. 前記サービス管理部は、前記サービスの抜き差しを管理することで前記サービスの動的な抜き差しを可能とする請求項５に記載の車両用サービス管理システム。
7. 前記車載ネットワークに接続され、車両外部のサービスを利用する拡張ゲートウェイ（１）を備えた請求項５または６に記載の車両用サービス管理システム。
8. 前記拡張ゲートウェイは、車両外部から新規アプリケーションを搭載可能であり、
   前記拡張ゲートウェイに搭載された新規アプリケーションは、前記車両用電子制御装置のサービスや車両外部のサービスと連携することで統合アプリケーションを生成する請求項７に記載の車両用サービス管理システム。
9. 前記サービスバスが前記車載ネットワークを介して通信するプロトコルとして、
   １対１でメッセージの要求／応答を行うＲｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ型と、
   不特定多数の購読登録者にメッセージを出版するＰｕｂｌｉｓｈ／Ｓｕｂｓｃｒｉｂｅ型とが設けられている請求項５から８のいずれか一項に記載の車両用サービス管理システム。

Images