特開 2024-116427 車載装置、サーバ及びシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024116427

(43)【公開日】2024-08-28

(54)【発明の名称】車載装置、サーバ及びシステム

(51)【国際特許分類】

   G08G 1/09 20060101AFI20240821BHJP

   H04Q 9/00 20060101ALI20240821BHJP

   H04M 11/00 20060101ALI20240821BHJP

   H04W 4/44 20180101ALI20240821BHJP

   H04W 4/38 20180101ALI20240821BHJP

   H04W 8/00 20090101ALI20240821BHJP

   G16Y 10/40 20200101ALI20240821BHJP

   G16Y 10/75 20200101ALI20240821BHJP

   G16Y 40/10 20200101ALI20240821BHJP

【ＦＩ】

G08G1/09 F

H04Q9/00 301B

H04Q9/00 311H

H04M11/00 301

H04W4/44

H04W4/38

H04W8/00 110

G16Y10/40

G16Y10/75

G16Y40/10

【審査請求】未請求

【請求項の数】9

【出願形態】ＯＬ

(21)【出願番号】P 2021110428

(22)【出願日】2021-07-02

(71)【出願人】

【識別番号】000002130

【氏名又は名称】住友電気工業株式会社

(71)【出願人】

【識別番号】000183406

【氏名又は名称】住友電装株式会社

(71)【出願人】

【識別番号】395011665

【氏名又は名称】株式会社オートネットワーク技術研究所

(74)【代理人】

【識別番号】100099933

【弁理士】

【氏名又は名称】清水 敏

(74)【代理人】

【識別番号】100124028

【弁理士】

【氏名又は名称】松本 公雄

(74)【代理人】

【識別番号】100078813

【弁理士】

【氏名又は名称】上代 哲司

(74)【代理人】

【識別番号】100094477

【弁理士】

【氏名又は名称】神野 直美

(72)【発明者】

【氏名】小川 明紘

【テーマコード（参考）】

5H181

5K048

5K067

5K201

【Ｆターム（参考）】

5H181AA01

5H181BB04

5H181BB13

5H181BB15

5H181CC03

5H181CC04

5H181CC12

5H181CC14

5H181FF13

5H181LL09

5H181MC19

5H181MC22

5K048BA34

5K048BA42

5K048DB01

5K048DC01

5K048EB10

5K048EB12

5K067AA21

5K067BB27

5K067EE02

5K067EE10

5K067EE16

5K201BA02

5K201BA06

5K201CC07

5K201CC09

5K201EC06

5K201ED04

5K201ED09

5K201FA03

(57)【要約】

【課題】車載装置とサーバとの連携システムにおいて、サーバの負荷を低減し、各サービスを提供するアプリケーションが効率的に機能することを可能にする車載装置、サーバ及びシステムを提供する。
【解決手段】車載装置は、サーバと通信する車載装置であって、当該車載装置が搭載された車両の機能を実現する機能制御部と、サーバから所定の要件が付された返信要求を受信する車載通信部と、車載通信部により受信された返信要求に付された要件が満たされるか否かを判定する車載仲介部とを含み、要件は、サーバにより提供されるサービスを実現するために処理対象とする被処理データを選別するための条件であり、車載仲介部は、車載装置が搭載された車両に搭載されたセンサ、車載通信部の通信状態、及び、機能制御部の状態の少なくともいずれか１つが要件を満たすか否かを判定し、車載通信部は、車載仲介部による判定の結果を、返信要求に対する返信データとしてサーバに送信する。
【選択図】図８

【特許請求の範囲】

【請求項1】

サーバと通信する車載装置であって、
当該車載装置が搭載された車両の機能を実現する機能制御部と、
前記サーバから所定の要件が付された返信要求を受信する車載通信部と、
前記車載通信部により受信された前記返信要求に付された前記要件が満たされるか否かを判定する車載仲介部とを含み、
前記要件は、前記サーバにより提供されるサービスを実現するために処理対象とする被処理データを選別するための条件であり、
前記車載仲介部は、前記車載装置が搭載された車両に搭載されたセンサ、前記車載通信部の通信状態、及び、前記機能制御部の状態の少なくともいずれか１つが前記要件を満たすか否かを判定し、
前記車載通信部は、前記車載仲介部による判定の結果を、前記返信要求に対する返信データとして前記サーバに送信する、車載装置。

【請求項2】

前記車載通信部はさらに、前記センサにより取得されたセンサデータを前記サーバに送信し、
前記被処理データは、前記センサデータを含む、請求項１に記載の車載装置。

【請求項3】

前記車載仲介部は、前記センサが前記要件を満たすか否かを判定し、
前記要件は、前記センサの種類に関する条件を含む、請求項１又は請求項２に記載の車載装置。

【請求項4】

前記車載仲介部は、前記車載通信部の通信状態が前記要件を満たすか否かを判定し、
前記要件は、通信速度及び遅延時間のうちの少なくとも１つに関する条件を含む、請求項１から請求項３のいずれか１項に記載の車載装置。

【請求項5】

前記車載仲介部は、前記機能制御部の状態が前記要件を満たすか否かを判定し、
前記要件は、前記機能制御部における、処理の負荷状態、処理遅延時間、メモリ使用率、並びに、前記車両の内部における通信速度及び通信負荷のうちの少なくとも１つに関する条件を含む、請求項１から請求項４のいずれか１項に記載の車載装置。

【請求項6】

請求項１から請求項５のいずれかに記載の複数の車載装置に、前記返信要求を送信し、前記返信データを受信する通信部と、
前記複数の車載装置の中から、前記返信データに基づいて前記要件を満たす車載装置を特定する仲介部とを含む、サーバ。

【請求項7】

前記サーバは、複数のサービスを提供し、
前記仲介部は、
前記要件を満たすとして特定した前記車載装置を、前記複数のサービスのうち、前記要件に対応するサービスに対応させ、
対応させた前記車載装置及び前記サービスを表す情報をネットワーク構成データとして記憶する、請求項６に記載のサーバ。

【請求項8】

前記仲介部は、前記複数のサービスの各々に応じた更新周期で、前記要件を満たす車載装置を特定し、前記ネットワーク構成データを更新する、請求項７に記載のサーバ。

【請求項9】

複数の車載装置と、
サーバとを含み、
前記サーバは、
前記複数の車載装置に、所定の要件を付した返信要求を送信し、前記返信要求に対する返信データを受信する通信部と、
前記複数の車載装置の中から、前記返信データに基づいて前記要件を満たす車載装置を特定する仲介部とを含み、
前記要件は、前記サーバにより提供されるサービスを実現するために処理対象とする被処理データを選別するための条件であり、
前記複数の車載装置の各々は、
当該車載装置が搭載された車両の機能を実現する機能制御部と、
前記サーバから前記返信要求を受信する車載通信部と、
前記車載通信部により受信された前記返信要求に付された前記要件が満たされるか否かを判定する車載仲介部とを含み、
前記車載仲介部は、当該車載仲介部を含む車載装置が搭載された車両に搭載されたセンサ、当該車載装置の前記車載通信部の通信状態、及び、当該車載装置の前記機能制御部の状態の少なくともいずれか１つが前記要件を満たすか否かを判定し、
前記車載通信部は、前記車載仲介部による判定の結果を前記返信データとして前記サーバに送信する、システム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、車載装置、サーバ及びシステムに関する。

【背景技術】

【0002】

自動車及び自動二輪車等（以下、車両という）の運転に関して運転者を支援する種々のシステム（以下、運転支援システムという）が提案されている。運転支援システムでは、道路及びその周辺（以下、路側ともいう）に設定された種々のセンサ機器（カメラ、レーダ等）を備えた装置（以下、インフラセンサという）からセンサの情報を収集し、それを解析して交通に関する情報（事故、渋滞等）を、運転支援情報として車両に提供する。また、移動体通信回線（以下、通信回線ともいう）の高速化に伴い、インフラセンサに装備されたセンサ機器に限らず、車両に搭載されているセンサ機器からの情報を収集し、運転支援に有効利用することも提案されている。

【0003】

後掲の特許文献１には、複数のセンサからセンサ情報を、通信網を介して情報処理装置に伝送するシステムにおいて、状況に応じて、望ましい通信網を選択してセンサ情報を伝送する技術が開示されている。センサネットワークでは、多種多様なセンサを利用するため、センサ情報も多種多様であり、情報量が多いもの、少ないもの、伝送のリアルタイム性が要求されるもの、要求されないもの等がある。これらは状況に応じて変化する。これに対応するために、このシステムでは、伝送すべきセンサ情報に対応するセンサＩＤ（個々のセンサを特定するＩＤ）、センサの種類及び情報量のうち少なくとも１つに基づいて通信網を選択し、センサ情報を送信する。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２００３－１１０７４９号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

運転支援システムにおいて、車載装置及びインフラセンサからセンサデータをサーバコンピュータ（以下、単にサーバという）に送信し、サーバで解析する場合、センサ機器の反応速度、使用する通信回線（５Ｇ、ＬＴＥ等）の通信速度等により、センサデータがサーバに遅れて届く。したがって、ほぼ同じ時刻に複数のセンサデータを受信したとしても、センサの検出時刻（センサデータが生成された時刻）が異なるセンサデータが混在するので、それらをまとめて解析対象とすることは適切ではないという問題がある。遅延時間には、センサ応答による遅延、車載装置での処理による遅延、通信による遅延がある。

【0006】

したがって、複数の車載装置からセンサデータがサーバにアップロードされる場合、同時刻に受信されたセンサデータを解析対象とすれば、第１車両に装備されたセンサにより検知された対象（人）と、第２車両に装備されたセンサにより検知された対象（人）とは異なるにもかかわらず、異なる対象を同一対象として誤検出してしまう等により、誤った検出結果が得られてしまう可能性がある。同様に、同じ対象を異なる複数台の車載装置で検知した場合には、各車載装置からのセンサデータの遅延時間が大きく異なると、サーバによりほぼ同時刻には受信されず、異なる処理対象とされてしまい、解析結果の精度が低下する原因となる。この問題は、特許文献１に開示された技術によっては解決できない。

【0007】

この問題を解決するために、車載装置とサーバとの連携（協調）において、車載装置からセンサデータをサーバに送信するときに、遅延時間に応じてセンサデータを適切に分類及び解析することが考えられる。しかし、この連携サービス（コネクティッドサービス）を提供するシステムを構成する複数の車載装置には、種々の性能のものが含まれている。即ち、車載装置の通信速度、データ処理能力等の仕様（基本性能）が異なることに加えて、その状態（ＣＰＵの負荷状態、メモリ使用率）も刻々と変化する。したがって、車載装置から送信されるセンサデータを、一律に処理したのでは、十分な精度の高いサービスを提供できない問題がある。その対策として、サーバのサービスを提供するソフトウェア（以下、アプリケーションという）毎に、受信したセンサデータから、処理対象とするセンサデータを選別することが考えられる。しかし、サーバが複数のサービスを同時に提供するには、複数のアプリケーションを並行して実行する必要があり、サーバの負荷が大きくなる問題がある。

【0008】

したがって、本開示は、車載装置とサーバとの連携システムにおいて、サーバの負荷を低減し、各サービスを提供するアプリケーションが効率的に機能することを可能にする車載装置、サーバ及びシステムを提供することを目的とする。

【課題を解決するための手段】

【0009】

本開示のある局面に係る車載装置は、サーバと通信する車載装置であって、当該車載装置が搭載された車両の機能を実現する機能制御部と、サーバから所定の要件が付された返信要求を受信する車載通信部と、車載通信部により受信された返信要求に付された要件が満たされるか否かを判定する車載仲介部とを含み、要件は、サーバにより提供されるサービスを実現するために処理対象とする被処理データを選別するための条件であり、車載仲介部は、車載装置が搭載された車両に搭載されたセンサ、車載通信部の通信状態、及び、機能制御部の状態の少なくともいずれか１つが要件を満たすか否かを判定し、車載通信部は、車載仲介部による判定の結果を、返信要求に対する返信データとしてサーバに送信する。

【0010】

本開示の別の局面に係るサーバは、複数の上記の車載装置に、返信要求を送信し、返信データを受信する通信部と、複数の車載装置の中から、返信データに基づいて要件を満たす車載装置を特定する仲介部とを含む。

【0011】

本開示のさらに別の局面に係るシステムは、複数の車載装置と、サーバとを含み、サーバは、複数の車載装置に、所定の要件を付した返信要求を送信し、返信要求に対する返信データを受信する通信部と、複数の車載装置の中から、返信データに基づいて要件を満たす車載装置を特定する仲介部とを含み、要件は、サーバにより提供されるサービスを実現するために処理対象とする被処理データを選別するための条件であり、複数の車載装置の各々は、当該車載装置が搭載された車両の機能を実現する機能制御部と、サーバから返信要求を受信する車載通信部と、車載通信部により受信された返信要求に付された要件が満たされるか否かを判定する車載仲介部とを含み、車載仲介部は、当該車載仲介部を含む車載装置が搭載された車両に搭載されたセンサ、当該車載装置の車載通信部の通信状態、及び、当該車載装置の機能制御部の状態の少なくともいずれか１つが要件を満たすか否かを判定し、車載通信部は、車載仲介部による判定の結果を返信データとしてサーバに送信する。

【発明の効果】

【0012】

本開示によれば、車載装置及びインフラセンサとサーバとの連携システムにおいて、サーバの負荷を低減し、各サービスを提供するアプリケーションが効率的に機能することを可能にする車載装置、サーバ及びシステムを提供できる。

【図面の簡単な説明】

【0013】

【図1】図１は、本開示の実施形態に係る連携システムの構成を示す模式図である。

【図2】図２は、図１に示したサーバのハードウェア構成を示すブロック図である。

【図3】図３は、図１に示した車載装置のハードウェア構成を示すブロック図である。

【図4】図４は、図３に示した車載ゲートウェイの構成を示すブロック図である。

【図5】図５は、図２に示したサーバのソフトウェア構成を示すブロック図である。

【図6】図６は、図３に示した車載装置のソフトウェア構成を示すブロック図である。

【図7】図７は、サーバにより実行される仲介部を示すフローチャートである。

【図8】図８は、車載装置により実行される車載仲介部を示すフローチャートでる。

【図9】図９は、図８に示したフローチャートにおける無線リンク状態を評価する処理を示すフローチャートである。

【図10】図１０は、図１に示した車両（車載装置）により構成される複数の連携ネットワークを示す模式図である。

【発明を実施するための形態】

【0014】

［本開示の実施形態の説明］
本開示の実施形態の内容を列記して説明する。以下に記載する実施形態の少なくとも一部を任意に組合せてもよい。

【0015】

（１）本開示の第１の局面に係る車載装置は、サーバと通信する車載装置であって、当該車載装置が搭載された車両の機能を実現する機能制御部と、サーバから所定の要件が付された返信要求を受信する車載通信部と、車載通信部により受信された返信要求に付された要件が満たされるか否かを判定する車載仲介部とを含み、要件は、サーバにより提供されるサービスを実現するために処理対象とする被処理データを選別するための条件であり、車載仲介部は、車載装置が搭載された車両に搭載されたセンサ、車載通信部の通信状態、及び、機能制御部の状態の少なくともいずれか１つが要件を満たすか否かを判定し、車載通信部は、車載仲介部による判定の結果を、返信要求に対する返信データとしてサーバに送信する。これにより、サーバは、複数の車載装置と連携してサービスを提供する場合に、各サービスの要件を満たす車載装置を容易に特定でき、その車載装置からアップロードされたデータを容易に使用できる。したがって、サーバの負荷を低減でき、各サービスを提供するアプリケーションを効率的に機能させることができる。車載装置はサーバから、良好で精度の高いサービスを受けることができる。

【0016】

（２）車載通信部はさらに、センサにより取得されたセンサデータをサーバに送信し、被処理データは、センサデータを含むことができる。これにより、サーバによる運転支援情報の提供等のサービスが可能になる。

【0017】

（３）車載仲介部は、センサが要件を満たすか否かを判定し、要件は、センサの種類に関する条件を含むことができる。これにより、画像解像度等の高精度のセンサデータを送信できる車載装置を選択できるので、サーバにより提供される運転支援情報等の精度が高くなり、サービスの信頼性が向上する。

【0018】

（４）車載仲介部は、車載通信部の通信状態が要件を満たすか否かを判定し、要件は、通信速度及び遅延時間のうちの少なくとも１つに関する条件を含んでもよい。これにより、通信速度が高く、遅延時間が短い車載装置を選択できるので、リアルタイム性の高いサービスにおける精度を向上できる。

【0019】

（５）車載仲介部は、機能制御部の状態が要件を満たすか否かを判定し、要件は、機能制御部における、処理の負荷状態、処理遅延時間、メモリ使用率、並びに、車両の内部における通信速度及び通信負荷のうちの少なくとも１つに関する条件を含んでもよい。これにより、処理の遅延時間が短い車載装置から送信されたデータ（センサデータ等）を用いることができ、リアルタイム性の高いサービスにおける精度を向上できる。

【0020】

（６）本開示の第２の局面に係るサーバは、複数の上記の車載装置に、返信要求を送信し、返信データを受信する通信部と、複数の車載装置の中から、返信データに基づいて要件を満たす車載装置を特定する仲介部とを含む。これにより、サーバは、複数の車載装置と連携してサービスを提供する場合に、各サービスの要件を満たす車載装置を容易に特定でき、その車載装置からアップロードされたデータを容易に使用できる。したがって、サーバの負荷を低減でき、各サービスを提供するアプリケーションを効率的に機能させることができる。

【0021】

（７）サーバは、複数のサービスを提供し、仲介部は、要件を満たすとして特定した車載装置を、複数のサービスのうち、要件に対応するサービスに対応させ、対応させた車載装置及びサービスを表す情報をネットワーク構成データとして記憶できる。これにより、各サービスと、それに適したデータ（センサデータ等）を送信する車載装置との対応関係を効率的に管理でき、各サービスを実行するアプリケーションのデータ処理効率を向上できる。

【0022】

（８）仲介部は、複数のサービスの各々に応じた更新周期で、要件を満たす車載装置を特定し、ネットワーク構成データを更新してもよい。これにより、効率的にネットワーク構成データを更新でき、サーバの負荷を抑制できる。複数のネットワーク構成データを同じ周期で更新する場合には、比較的長い周期で更新できればよいサービスに関するネットワーク構成データを短時間で更新することによる無駄な処理が発生する。それに対して、複数のサービスの各々に応じた更新周期で更新することにより、無駄な処理を抑制できる。

【0023】

（９）本開示の第３の局面に係るシステムは、複数の車載装置と、サーバとを含み、サーバは、複数の車載装置に、所定の要件を付した返信要求を送信し、返信要求に対する返信データを受信する通信部と、複数の車載装置の中から、返信データに基づいて要件を満たす車載装置を特定する仲介部とを含み、要件は、サーバにより提供されるサービスを実現するために処理対象とする被処理データを選別するための条件であり、複数の車載装置の各々は、当該車載装置が搭載された車両の機能を実現する機能制御部と、サーバから返信要求を受信する車載通信部と、車載通信部により受信された返信要求に付された要件が満たされるか否かを判定する車載仲介部とを含み、車載仲介部は、当該車載仲介部を含む車載装置が搭載された車両に搭載されたセンサ、当該車載装置の車載通信部の通信状態、及び、当該車載装置の機能制御部の状態の少なくともいずれか１つが要件を満たすか否かを判定し、車載通信部は、車載仲介部による判定の結果を返信データとしてサーバに送信する。これにより、サーバは、複数の車載装置と連携してサービスを提供する場合に、各サービスの要件を満たす車載装置を容易に特定でき、その車載装置からアップロードされたデータを容易に使用できる。したがって、サーバの負荷を低減でき、各サービスを提供するアプリケーションを効率的に機能させることができる。車載装置はサーバから、良好で精度の高いサービスを受けることができる。

【0024】

［本開示の実施形態の詳細］
以下の実施形態では、同一の部品には同一の参照番号を付してある。それらの名称及び機能も同一である。したがって、それらについての詳細な説明は繰返さない。

【0025】

［全体構成］
図１を参照して本開示の実施形態に係る連携システム１００は、サーバ１０２、基地局１０４、インフラセンサ１０６、車両１１０、１１２、１１４及び１１６、並びに、車両１１０に搭載された車載装置１１８を含む。車両１１２、１１４及び１１６にも、車両１１０と同様に車載装置が搭載されている。サーバ１０２は、所定の管理対象領域内に存在する車両（車載装置）及びインフラセンサと連携して、種々のサービスを提供する。即ち、サーバ１０２は、車載装置及びインフラセンサからアップロードされるデータ（センサデータ等）を処理し、その結果を用いて、運転支援情報の提供等のサービスを行う。図１において、４台の車両は、サーバ１０２と連携する車両を代表的に表している。また、基地局１０４及びインフラセンサ１０６も代表的に示しており、複数台存在している。なお、サーバ１０２からのサービス用データの送信先は、所定の領域内に存在する車両（車載装置）及び携帯端末装置等であり、車両の運転者及び携帯端末装置の利用者等がサービスを利用する。

【0026】

車載装置１１８は、基地局１０４が提供している移動体通信回線（ＬＴＥ回線及び５Ｇ回線等）により情報を送信及び受信する。道路の周囲には、Ｗｉ－Ｆｉルータ（図示せず）等が設置され、車載装置１１８にＷｉ－Ｆｉによる通信サービスが提供されていてもよい。また、複数の車両に搭載された車載装置間で基地局１０４を介さずに直接無線通信することもできる。

【0027】

インフラセンサ１０６は路側に設置され、路側における情報を取得する機能を備えた装置であり、基地局１０４との通信機能を有している。インフラセンサ１０６は、例えば、イメージセンサ（デジタルの監視カメラ等）、レーダ（ミリ波レーダ等）、又はレーザセンサ（ＬｉＤＡＲ（Ｌｉｇｈｔ Ｄｅｔｅｃｔｉｏｎ ａｎｄ Ｒａｎｇｉｎｇ）等）等である。

【0028】

［サーバのハードウェア構成］
図２を参照して、サーバ１０２は、制御部１２０、メモリ１２２、通信部１２４、タイマ１２６、解析処理部１２８、操作部１３０及びバス１３２を含む。サーバ１０２は、例えばコンピュータである。各部の間のデータ伝送は、バス１３２を介して行われる。制御部１２０は、例えばＣＰＵを含み、各部を制御してサーバ１０２の種々の機能を実現する。メモリ１２２は、書換可能な不揮発性の半導体メモリ及びＨＤＤ等の大容量記憶装置を含む。メモリ１２２には、制御部１２０が実行するプログラムが記憶されており、制御部１２０がそのプログラムを読出して実行することにより、後述するサーバ１０２の種々の処理が実行される。メモリ１２２は、制御部１２０が実行するプログラムのワーク領域を提供する。

【0029】

通信部１２４は、車載装置１１８及びインフラセンサ１０６からアップロードされるセンサデータ等を受信する。通信部１２４は、無線通信において採用されている変調及び多重化を行うためのＩＣ、所定周波数の電波を送信及び受信するためのアンテナ、並びにＲＦ回路等を含む。通信部１２４は、Ｗｉ－Ｆｉ通信機能を有していてもよい。通信部１２４により受信されたデータは、メモリ１２２に伝送され、データベースとして記憶される。制御部１２０は、メモリ１２２からデータを読出し、解析処理部１２８を用いて所定の解析処理（例えば、運転支援情報を得るための解析）を実行し、その結果をメモリ１２２に記憶する。運転支援情報を得るための解析には、例えば、画像データから対象物（人、車両等）を抽出する処理、抽出された対象物の移動方向、移動速度等を算出する処理が含まれる。制御部１２０は、メモリ１２２から運転支援情報（センサデータ自体を含む）等を読出し、車載装置１１８等に送信する。タイマ１２６は、制御部１２０からの要求を受けて現在時刻を提供する。操作部１３０は、管理者等が制御部１２０に対する指示を入力するための装置であり、コンピュータ用のキーボード及びマウス等の操作装置である。

【0030】

［車載装置のハードウェア構成］
図３を参照して、車両１１０に搭載されている車載装置１１８のハードウェア構成の一例を示す。車載装置１１８は、通信部１４０、車載ゲートウェイ１４２、複数のＥＣＵ（Ｅｌｅｃｔｒｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）（第１ＥＣＵ１４４～第ｎＥＣＵ１４６）及びバス１４８を含む。図３には、車両１１０に搭載されているセンサ部１５０も示している。ＥＣＵは、それが搭載されている車両の走行機能に限らず、安全性向上のための機能等を実現するための機能制御部である。

【0031】

通信部１４０は、車両１１０の外部装置と無線通信（例えば、基地局１０４を介したサーバ１０２との通信）を行う。通信部１４０は、無線通信において採用されている変調及び多重化を行うためのＩＣ、所定周波数の電波を送信及び受信するためのアンテナ、並びにＲＦ回路等を含む。通信部１４０は、Ｗｉ－Ｆｉ通信機能を有していてもよい。

【0032】

車載ゲートウェイ１４２は、車外との通信機能（通信仕様）と車内での通信機能（通信仕様）とを接合する役割（通信プロトコル変換等）を担う。また、車載ゲートウェイ１４２は、後述するように、サーバ１０２からの指示を受けて、それに応じた処理を実行し、その結果をサーバ１０２に返信する機能を有する。図４を参照して、車載ゲートウェイ１４２は、制御部１６０、メモリ１６２及びバッファ１６４を含む。制御部１６０は、例えばＣＰＵを含む。メモリ１６２は、書換可能な不揮発性の半導体メモリ及びＨＤＤ等の大容量記憶装置を含む。メモリ１６２には、制御部１６０が実行するプログラムが記憶されており、制御部１６０がそのプログラムを読出して実行することにより、上記したように、車外との通信機能と車内での通信機能との接合処理、及び、サーバ１０２の指示に応じた処理等を実行する。メモリ１６２は、制御部１６０が実行するプログラムのワーク領域を提供する。バッファ１６４は、車載ゲートウェイ１４２が、バス１４８を介して車載装置１１８の各部と通信する場合、又は、通信部１４０を介して外部装置と通信する場合に、通信相手の性能に合わせて正常に通信を行うために、データを一時的に記憶するためのメモリである。

【0033】

センサ部１５０は、車両１１０外部の情報を取得するためのセンサ（ビデオ映像の撮像装置（例えば、デジタルカメラ（ＣＣＤカメラ、ＣＭＯＳカメラ））、レーザセンサ（ＬｉＤＡＲ）等）、及び、車両自体の情報を取得するためのセンサ（加速度センサ、荷重センサ等）を含む。センサ部１５０は、インターフェイス部（以下、ＩＦ部という）を含み、センサ部１５０の信号はＩＦ部によりデジタルデータとしてバス１４８に出力される。

【0034】

第１ＥＣＵ１４４～第ｎＥＣＵ１４６の各々も、図４に示した車載ゲートウェイ１４２と同様に、制御部、メモリ及びバッファを含む。第１ＥＣＵ１４４～第ｎＥＣＵ１４６は、車載ゲートウェイ１４２及び通信部１４０を介して、外部装置と通信してもよい。車載ゲートウェイ１４２は、車両１１０の位置における通信環境に応じて、通信部１４０、第１ＥＣＵ１４４～第ｎＥＣＵ１４６等が主体となる通信を制御する。各部間のデータ交換は、バス１４８を介して行われる。

【0035】

上記したように、第１ＥＣＵ１４４～第ｎＥＣＵ１４６は、車両１１０の機能を実現するための機能制御部であり、実現する機能に関連する各部を制御する。例えば、第１ＥＣＵ１４４は、車両１１０の外部を監視する機能を実現するためのセンシング用ＥＣＵである。第１ＥＣＵ１４４は、センサ部１５０によるセンサデータの収集条件を制御し、センサ部１５０からセンサデータを取得する。第１ＥＣＵ１４４は、取得したセンサデータを、バス１４８を介して他のＥＣＵに伝送してもよい。また、第１ＥＣＵ１４４は、センサデータを、車載ゲートウェイ１４２及び通信部１４０を介して外部装置に送信する。第ｎＥＣＵ１４６は、例えば、自動運転機能を実現するための自動運転用ＥＣＵである。第ｎＥＣＵ１４６は、外部装置から、通信部１４０及び車載ゲートウェイ１４２を介して運転支援情報、交通情報等を受信し、第１ＥＣＵ１４４からセンサ部１５０のセンサデータを取得し、それらを用いて自動運転に関連する機構を制御する。

【0036】

［サーバのソフトウェア構成］
図５を参照して、サーバ１０２におけるサービス提供に関するソフトウェア構成を示す。ここでは、上位層、中位層及び下位層の３層により構成されているとする。上位層には、複数のサービス（運転支援情報の提供等）の各々を提供するためのアプリケーションを示している。これらのサービスは、例えば、何らかの事象（イベント）が発生してから情報を提供するまでの時間によって分類され得る。例えば、第１～第３サービスは、リアルタイム、準リアルタイム及び非リアルタイムのサービスを提供する。リアルタイム、準リアルタイム及び非リアルタイムとは、例えば、イベントが発生してからそれぞれ約１秒未満、約１秒以上数秒未満、及び、数秒以上数分未満に、何らかのサービスを提供することを意味する。第１～第３サービスのアプリケーションは、サーバ１０２の制御部１２０により実行される。

【0037】

中位層は、上位層（各アプリケーション）と下位層（通信部）との仲介を行い、第１～第３サービスのアプリケーションにそれぞれ対応する第１～第３仲介部により構成されている。第１～第３仲介部は、サーバ１０２の制御部１２０により実行されるソフトウェアである。第１～第３仲介部の各々は、後述するように、対応するサービスを提供するために利用できるデータを取得可能な車載装置を選別し、それらにより連携ネットワークを構築し、定期的に更新する。連携ネットワークは、サービス毎に構築される。

【0038】

下位層の通信部は、図２に示した通信部１２４とそれを動作させるためのデバイスドライバ（ソフトウェア）とにより構成される。第１～第３仲介部は、デバイスドライバを用いて通信部１２４を動作させ、図１に示した基地局１０４、インフラセンサ１０６及び車両１１０～１１６の車載装置（車載装置１１８等）と通信する。

【0039】

［車載装置のソフトウェア構成］
図６を参照して、車載装置１１８におけるソフトウェア構成を示す。ここでは、上位層、中位層及び下位層の３層により構成されているとする。上位層には、複数のＥＣＵ（ハードウェア）の各々の機能を実現するためのアプリケーションを、第１ＥＣＵ～第３ＥＣＵとして示している。図６に示した第１ＥＣＵ～第３ＥＣＵ（アプリケーション）は、例えば、図３に示したセンサ部１５０の制御用アプリケーション、自動運転用アプリケーション、モータ制御用アプリケーション等である。第１ＥＣＵ～第３ＥＣＵの各々は、対応するＥＣＵの制御部により実行される。

【0040】

中位層は、上位層の第１ＥＣＵ～第３ＥＣＵ（アプリケーション）と下位層（通信部）との仲介を行う。車載仲介部は、車載ゲートウェイ１４２により実行されるソフトウェア（プログラム）である。車載仲介部は、後述するように、サーバ１０２による連携ネットワークの構築のための情報をサーバ１０２に提供する処理を行う。

【0041】

下位層の通信部は、図３に示した通信部１４０とそれを動作させるためのデバイスドライバ（ソフトウェア）により構成される。車載仲介部は、デバイスドライバを用いて、通信部１４０を動作させ、図１に示したサーバ１０２と通信する。

【0042】

［サーバの動作］
図７を参照して、連携ネットワークの構築及びその更新に関するサーバ１０２の動作を説明する。図７に示した処理は、図２に示したサーバ１０２の制御部１２０が、所定のプログラムをメモリ１２２から読出して実行することにより実現される。図７に示した処理は、図５に示した第１～第３仲介部の各々に対応し、サーバ１０２は、第１～第３サービスの各々に対応して、図７に示した複数のプログラムを並列に実行する。即ち、制御部１２０は、複数のプログラムをメモリ１２２から読出し、マルチタスクで実行する。以下、並列に実行される複数のプログラムのうちの１つ（１つの仲介部）に関して説明する。なお、メモリ１２２には、サービス毎に対応させた所定時間が予め記憶されているとする。

【0043】

ステップ３００において、制御部１２０は、連携ネットワークを構築するか否かを判定する。連携ネットワークが構築されていない場合には、判定結果はＹＥＳとなる。既に連携ネットワークが構築されている場合には、それを更新する時間になったか否かを判定する。具体的には、制御部１２０は、タイマ１２６から現在時刻を取得し、対応する所定時間をメモリ１２２から読出し、それらを比較して、前回連携ネットワークを更新した時間から所定時間が経過したか否かを判定する。経過したと判定された場合、制御はステップ３０２に移行する。そうでなければ、制御はステップ３１０に移行する。

【0044】

所定時間は、連携ネットワークを更新する周期であり、サービスの種類により異なる時間が設定されることが好ましい。例えば、リアルタイム、準リアルタイム及び非リアルタイムのサービスに応じて、要求されるデータの更新時間は異なる。複数の連携ネットワークを同じ周期で更新する場合、無駄な処理が発生する。例えば、比較的長い周期で更新できればよいサービスに関する連携ネットワークを短時間で更新することは、無駄な処理を含む。それに対して、複数のサービスの各々に応じた更新周期で更新することにより、無駄な処理を抑制でき、効率的に連携ネットワークを更新でき、サーバ１０２の負荷を抑制できる。

【0045】

ステップ３０２において、制御部１２０は、対応するサービスのアプリケーションから要件を取得する。その後、制御はステップ３０４に移行する。要件は、そのサービスを提供するために利用できるデータに関する条件であり、サービス毎に異なる。要件には、例えば、収集データ種別、無線リンク状態及び車内状態を含む。収集データ種別は、例えば、車両に搭載されているセンサの種類及びその性能を含む。例えば、センサがビデオカメラであれば、その解像度及びフレームレート等である。無線リンク状態は、サーバ１０２の管理対象領域に存在する車両の車載装置の無線通信（ＬＴＥ、５Ｇ、Ｗｉ－Ｆｉ等）の状態を意味し、例えば、車載装置の外部との無線通信速度及び遅延時間のうちの少なくとも１つであり、無線通信の種類毎に条件が指定される。車内状態は、車両内に存在するＥＣＵのうち、サービスのためにサーバ１０２に送信するデータに関係する各ＥＣＵの状態を意味する。例えば、ＥＣＵにおける、ＣＰＵの負荷状態、処理遅延時間、メモリ使用率、並びに、車両内部における通信速度及び通信負荷のうちの少なくとも１つである。

【0046】

ステップ３０４において、制御部１２０は、サーバ１０２の管理対象領域に存在する車両の車載装置に返信要求を送信する。具体的には、制御部１２０は、ステップ３０２で取得した要件に含まれる条件と、サービスを特定する情報（サービスＩＤ等）とを付した所定のコマンドをブロードキャストする。ここで、返信要求に付する要件は、上記の収集データ種別、無線リンク状態及び車内状態のうち、収集データ種別及び無線リンク状態に関する条件とする。その後、制御はステップ３０６に移行する。

【0047】

ステップ３０６において、制御部１２０は、ステップ３０４で送信した返信要求に対して車載装置から返信されたデータをメモリ１２２に記憶する。その後、制御はステップ３０８に移行する。上記したように本プログラムは、図５に示した各仲介部に対応するので、並列に動作している複数の仲介部の各々から返信要求が送信され（ステップ３０４）、それに対する返信データが車載装置から送信される。後述するように、車載装置から返信されるデータには、サービスＩＤが付されているので、各仲介部（制御部１２０）は、サービスＩＤにより、自己がステップ３０４で送信した返信要求に対する返信データを特定できる。

【0048】

ステップ３０８において、制御部１２０は、ステップ３０６でメモリ１２２に記憶されたデータに基づき、ステップ３０２で取得した要件を満たす車載装置を選択し、選択された車載装置を特定する情報（車載装置ＩＤ）を、そのサービスに対応する連携ネットワークの構成要素として、サービスＩＤと対応させてメモリ１２２に記憶する（ネットワーク構成データ）。その後、制御はステップ３１０に移行する。

【0049】

ステップ３１０において、制御部１２０は、終了するか否かを判定する。例えば、サーバ１０２の管理者により操作部１３０（図２参照）が操作され、終了が指示された場合に、終了すると判定される。終了すると判定された場合、本プログラムは終了する。そうでなければ、制御はステップ３００に戻る。

【0050】

以上により、図５に示した各仲介部は、対応するサービスに対応する連携ネットワークを構築でき、一度連携ネットワークが構築された後には、対応するサービスに応じた周期（所定時間）で連携ネットワークを更新できる。後述するように、サーバ１０２の管理対象領域に存在するインフラセンサ１０６及び車載装置１１８等からアップロードされるデータ（センサデータ等）は、順次メモリ１２２の所定領域にデータベースとして記憶される。各サービスのアプリケーションは、自己のサービスＩＤを用いて自己の連携ネットワークを特定し、その連携ネットワークに含まれる車載装置ＩＤから送信されたデータをメモリ１２２から読出して解析処理部１２８を用いて解析し、その結果をサービスの提供に利用できる。即ち、各サービスのアプリケーションは、アップロードされたデータの中から、自己のサービスに適した処理対象データを容易に取得できる。

【0051】

［車載装置の動作］
図８を参照して、サーバ１０２からの返信要求を受けて車載装置及びインフラセンサの各々が行う動作を説明する。ここでは、代表として車載装置１１８により実行される処理を説明する。図８に示した処理は、車載装置１１８を構成する車載ゲートウェイ１４２の制御部１６０（図４参照）が、所定のプログラムをメモリ１６２から読出して実行することにより実現される。図８に示したプログラムは、図６に示した車載仲介部に対応する。なお、メモリ１６２には、サーバ１０２に返信するデータを記憶する領域（以下、返信データ領域という）が予め確保されているとする。

【0052】

ステップ４００において、制御部１６０は、サーバ１０２から返信要求（所定のコマンド）を受信したか否かを判定する。上記したように、返信要求は、図７のステップ３０４においてサーバ１０２によりブロードキャストされる。受信したと判定された場合、制御はステップ４０２に移行する。そうでなければ、制御はステップ４１６に移行する。

【0053】

ステップ４０２において、制御部１６０は、ステップ４００で受信した返信要求に付加された条件のうちの収集データ種別に関する条件を満たすセンサが、当該車両に搭載されているか否かを判定する。搭載されていると判定された場合、制御はステップ４０４に移行する。そうでなければ、制御はステップ４０６に移行する。上記したように、各センサが対応するＥＣＵにより制御されることによりセンサデータが取得されるので、収集データ種別は、所望のデータを生成可能なＥＣＵが搭載されているか否かを判定することに相当する。

【0054】

ステップ４０４において、制御部１６０は、メモリ１６２の返信データ領域に第１データをセットする。その後、制御はステップ４０８に移行する。

【0055】

ステップ４０６において、制御部１６０は、メモリ１６２の返信データ領域に第１データとは異なる第２データをセットする。その後、制御はステップ４０８に移行する。

【0056】

ステップ４０８において、制御部１６０は、ステップ４００で受信した返信要求に付加された条件のうちの無線リンク状態を評価する。ステップ４０８の処理は、具体的には図９に示されている。即ち、ステップ４３０において、制御部１６０は、現在使用している通信インターフェイスを、通信部１４０（図４参照）が有する複数の無線インターフェイス（無線ＩＦ）のうち、最も優先度が高いものに切替える。その後、制御はステップ４３２に移行する。最優先度インターフェイスが現在使用している通信インターフェイスであれば、そのまま維持する。また、通信部１４０が１つの無線インターフェイスしか有していなければ、現在使用している通信インターフェイスを維持する。

【0057】

無線インターフェイスの最優先度を判断する基準は、車載装置毎に予め定められていればよい。例えば、通信部１４０による実際の無線通信状態（通信速度）、無線通信による消費電力、又は、サーバ１０２により統計処理されて生成され、予め配信されて車載ゲートウェイ１４２のメモリ１６２（図４参照）に記憶された情報等に基づき決定される。サーバ１０２から配信される情報には、例えば、サーバ１０２の管理対象領域における無線通信の性能、通信回線全体のトラフィック負荷、通信料金、消費電力等が含まれる。また、通信部１４０が現在サーバ１０２と無線通信している状態であれば、その無線インターフェイスを、最優先の無線インターフェイスと判定してもよい。

【0058】

ステップ４３２において、制御部１６０は、ステップ４３０で切替えられ新たに使用される無線インターフェイスを介しての通信状態を監視する。例えば、制御部１６０は無線通信速度を算出する。

【0059】

ステップ４３４において、制御部１６０は、ステップ４３２で算出した無線通信速度が、ステップ４００で受信した返信要求に付加された要件のうちの無線リンク状態に関する条件を満たすか否かを判定する。満たすと判定された場合、制御はステップ４３６に移行する。そうでなければ、制御はステップ４３８に移行する。

【0060】

ステップ４３６において、制御部１６０は、メモリ１６２の返信データ領域に第３データをセットする。第３データは、第１データ及び第２データのいずれとも異なるデータである。その後、制御は図８のフローチャートに戻り、ステップ４１０に移行する。

【0061】

ステップ４３８において、制御部１６０は、ステップ４３０で切替えた無線インターフェイスとは別の無線インターフェイスを通信部１４０が有するか否かを判定する。有しないと判定された場合、制御はステップ４４０に移行する。そうでなければ、制御はステップ４４２に移行する。

【0062】

ステップ４４０において、制御部１６０は、メモリ１６２の返信データ領域に第４データをセットする。第４データは、第１～第３データのいずれとも異なるデータである。その後、制御は図８のフローチャートに戻り、ステップ４１０に移行する。

【0063】

一方、ステップ４３８の判定結果がＹＥＳの場合（通信部１４０が別の無線インターフェイスを有する場合）、ステップ４４２において、制御部１６０は、ステップ４３０と同様に、現在使用している無線インターフェイスを切替える。但し、既にステップ４３２の対象となった無線インターフェイスは除外する。その後、制御はステップ４３２に戻る。

【0064】

図８に戻り、ステップ４１０において、制御部１６０は、車両１１０の車内状態を観測する。具体的には、制御部１６０は、車両１１０内部に存在する複数のＥＣＵのうち、サーバ１０２にデータをアップロードする処理に関係するＥＣＵに関して、リソース状態（例えば、ＣＰＵの負荷状態、処理遅延時間、メモリ使用率、並びに、車両内部における通信速度及び通信負荷）を測定する。制御部１６０は、測定結果をメモリ１６２の返信データ領域に記憶する。その後、制御はステップ４１２に移行する。

【0065】

ステップ４１２において、制御部１６０は、メモリ１６２の返信データ領域に記憶されたデータを読出し、自己の車載装置ＩＤと、ステップ４００で受信した返信要求に付されたサービスＩＤとを付して、通信部１４０を介してサーバ１０２に送信する。その後、制御はステップ４１４に移行する。

【0066】

ステップ４１４において、制御部１６０は、終了するか否かを判定する。例えば、車両１１０の運転者により電力系統のオフ（車両１１０のイグニッションボタン等のオフ）が指示された場合に、終了すると判定され、本プログラムを終了する。そうでなければ、制御はステップ４００に戻る。

【0067】

一方、ステップ４００において判定結果がＮＯであった場合、ステップ４１６において、制御部１６０は、サーバ１０２にセンサデータ等をアップロードするか否かを判定する。アップロードすると判定された場合、制御はステップ４１８に移行する。そうでなければ、制御はステップ４１４に移行する。制御部１６０は、車両１１０に搭載されたセンサ部１５０（図３参照）により新たなデータ（サーバ１０２に未送信のデータ）が取得されたか否かにより、アップロードするか否かを判定する。新たなデータがあれば、アップロードすると判定する。また、一定の周期でアップロードしてもよい。その場合、制御部１６０は、前回アップロードしてから所定時間が経過したか否かを判定し、経過していれば、アップロードすると判定する。

【0068】

ステップ４１８において、制御部１６０は、自己の車載装置ＩＤを付してセンサデータを、通信部１４０を介してサーバ１０２に送信（アップロード）する。その後、制御はステップ４１４に移行する。

【0069】

以上により、車両１１０の車載装置１１８は、サーバ１０２から返信要求を受信すれば、それに付加された条件を満たすか否かを判定し、判定結果を、車両１１０の車内状態の観測結果と共にサーバ１０２に返信できる。これにより、図５に示した各仲介部は、受信した返信データに付されたサービスＩＤから、自己の返信要求に対する返信データであることを特定し、要件を満たす車載装置を特定でき、その車載装置ＩＤを、連携ネットワークを構成する要素としてメモリ１２２に記録できる。

【0070】

例えば、仲介部は、返信データに第１データ又は第３データが含まれていれば、その車載装置ＩＤを連携ネットワークの構成要素としてメモリ１２２に記録する。既に連携ネットワークの構成要素となっていれば、それを維持する。一方、仲介部は、返信データに第２データ又は第４データが含まれており、その車載装置のＩＤが連携ネットワークの構成要素になっていれば、構成要素から除外（メモリ１２２から消去）する。また、仲介部は、返信データに含まれる車内状態の観測結果（図８のステップ４１０参照）が、サービスのアプリケーションから取得した車内状態の条件（図７のステップ３０２参照）を満たすか否かを判定し、満たす場合には、その車載装置ＩＤを連携ネットワークの構成要素としてメモリ１２２に記録する。

【0071】

このように、サーバ１０２は、提供する各サービスに対応する連携ネットワークを構築でき、一度連携ネットワークが構築された後には、対応するサービスに応じた周期（所定時間）で連携ネットワークを更新できる。例えば、図１０を参照して、図１に示した複数の車両１１０～１１６の車載装置は、連携ネットワークＡ～Ｃの構成要素となる。例えば、連携ネットワークＡは、リアルタイムサービスを提供するためのネットワークであり、車両１１０及び１１２の車載装置を含む。サーバ１０２のメモリ１２２には、連携ネットワークＡの構成要素として、車両１１０及び１１２の車載装置ＩＤが記憶される。連携ネットワークＢは、準リアルタイムサービスを提供するためのネットワークであり、車両１１２及び１１４の車載装置を含む。メモリ１２２には、連携ネットワークＢの構成要素として、車両１１２及び１１４の車載装置ＩＤが記憶される。連携ネットワークＣは、非リアルタイムサービスを提供するためのネットワークであり、車両１１０～１１６の車載装置を含む。メモリ１２２には、連携ネットワークＣの構成要素として、車両１１０～１１６の車載装置ＩＤが記憶される。

【0072】

サーバ１０２は、複数の車載装置と連携してサービスを提供する場合に、各サービスの要件を満たす車載装置を容易に特定でき、その車載装置からアップロードされたデータを容易に使用できる。サーバ１０２は、車載装置等からデータを受信する度に、どのサービスに利用できるかを判定する必要がないので、負荷を低減でき、各サービスを提供するアプリケーションを効率的に機能させることができる。車載装置はサーバ１０２から、良好で精度の高いサービスを受けることができる。

【0073】

上記したように、車両１１０の車載装置１１８は、サーバ１０２から返信要求を受信していなければ、適宜センサデータ等をサーバ１０２に送信する。サーバ１０２は、受信したセンサデータを記憶し、解析処理部１２８等により解析することにより、運転支援情報の提供等のサービスが可能になる。

【0074】

上記したように、サービスの要件として、車両１１０に搭載されたセンサ部１５０の種類に関する条件を用いることにより、画像解像度等の高精度のセンサデータを送信できる車両（車載装置）を選択できる。したがって、サーバ１０２により提供される運転支援情報等の精度が高くなり、サービスの信頼性が向上する。

【0075】

上記したように、サービスの要件として、車載装置１１８の通信部１４０の通信状態（無線リンク状態）に関する条件（通信速度及び遅延時間のうちの少なくとも１つ）を使用できる。これにより、通信速度が高く、遅延時間が短い車載装置を選択できるので、リアルタイム性の高いサービスにおける精度を向上できる。

【0076】

上記したように、サービスの要件として、ＥＣＵにおける、処理の負荷状態、処理遅延時間、メモリ使用率、並びに、車両内部における通信速度及び通信負荷のうちの少なくとも１つを使用できる。これにより、処理の遅延時間が短い車載装置を連携ネットワークの構成要素として選択できる。したがって、その車載装置から送信されたデータ（センサデータ等）を用いることができ、リアルタイム性の高いサービスにおける精度を向上できる。

【0077】

図７～図９に示した処理は種々変更されて実行され得る。上記では、図７に示したステップ３０４が常に実行される場合を説明した。ステップ３０２により取得した要件が、前回取得した要件から変化していない場合でも、車載装置の状態は変化し得る。また、更新時間が比較的長ければ、サーバ１０２の管理対象領域に存在する車両は変化し得る。したがって、ステップ３０２により取得した要件が変化していなくても、返信要求を送信することが好ましい。しかし、これに限定されない。更新周期が比較的短いサービスに対応する仲介部であれば、ステップ３０２により取得した要件が変化していない場合には、返信要求を送信しなくてもよい。また、要件の変化の有無と更新周期とを考慮して、車載装置に返信要求を送信するか否かを判定してもよい。

【0078】

上記では、サーバ１０２から返信要求を送信し、それに対して車載装置から返信データを送信する場合を説明したが、これに限定されない。各車載装置が、自発的に、収集データ種別、無線リンク状態及び車両状態をサーバ１０２に送信してもよい。

【0079】

上記では、図７に示したステップ３０６において、仲介部が返信データを記憶する場合を説明したが、これに限定されない。車載装置からの返信データは、どの仲介部が送信した返信要求に対するものであるかに拘わらず、メモリ１２２に記憶されればよいので、別のプログラムによりメモリ１２２に記憶されてもよい。返信データであるか否かは、サーバ１０２が受信したデータにサービスＩＤが含まれているか否かにより判定できる。そのようにすれば、各仲介部が、自己が送信した返信要求に対する返信データであるか否かを判定する必要がなく、効率的である。

【0080】

上記では、車載装置から車内状態の観測結果をサーバに送信し、サーバ（仲介部）において、サービスの要件のうちの車内状態の条件を満たすか否かを判定する場合を説明したが、これに限定されない。サーバから車載装置に送信する要求に車内状態の条件を含めておけば、車載装置がその条件を満たすか否かを判定し、判定結果をサーバに送信してもよい。そのようにすれば、複数の仲介部（ソフトウェア）を並列して実行するサーバの負荷を軽減できる。

【0081】

以上、実施の形態を説明することにより本開示を説明したが、上記した実施の形態は例示であって、本開示は上記した実施の形態のみに制限されるわけではない。本開示の範囲は、発明の詳細な説明の記載を参酌した上で、特許請求の範囲の各請求項によって示され、そこに記載された文言と均等の意味及び範囲内での全ての変更を含む。

【符号の説明】

【0082】

１００ 連携システム
１０２ サーバ
１０４ 基地局
１０６ インフラセンサ
１１０、１１２、１１４、１１６ 車両
１１８ 車載装置
１２０、１６０ 制御部
１２２、１６２ メモリ
１２４、１４０ 通信部
１２６ タイマ
１２８ 解析処理部
１３０ 操作部
１３２、１４８ バス
１４２ 車載ゲートウェイ
１４４ 第１ＥＣＵ
１４６ 第ｎＥＣＵ
１５０ センサ部
１６４ バッファ
３００、３０２、３０４、３０６、３０８、３１０、４００、４０２、４０４、４０６、４０８、４１０、４１２、４１４、４１６、４１８、４３０、４３２、４３４、４３６、４３８、４４０、４４２ ステップ
Ａ、Ｂ、Ｃ 連携ネットワーク

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】