WO2024142981A1 - 車載機、データ提供方法、及びプログラム - Google Patents

Abstract

スケジュール管理部は、１つ以上の管理情報を用いて、取得条件を満たす管理情報が示すコマンドを、送信対象コマンドとして抽出すると共に、送信対象コマンドと要求元アプリとを対応づけたルーティング情報を生成する。要求元アプリは、車両データの要求元となるアプリケーションプログラムである。管理情報には、車両データの取得に用いるコマンドの種類、要求元アプリ、及び車両データの取得条件が示される。送信対象コマンドは、送信処理にて送信対象となるコマンドである。ルーティング部は、取得された車両データを、ルーティング情報を用いて要求元アプリに提供する。

Description

車載機、データ提供方法、及びプログラム 関連出願の相互参照

　本国際出願は、２０２２年１２月２８日に日本国特許庁に出願された日本国特許出願第２０２２－２１２０６５号に基づく優先権を主張するものであり、日本国特許出願第２０２２－２１２０６５号の全内容を本国際出願に参照により援用する。

　本開示は、車載ネットワークに接続される車載機にて動作するアプリケーションプログラムに対して車両データを提供する技術に関する。

　下記特許文献１には、ＣＡＮ等の車載ネットワークを介してＥＣＵ間で送受信されるデータを利用し、故障診断を行うダイアグ通信を行う装置が記載されている。ＣＡＮは登録商標である。ダイアグ通信では、車両に設けられたＯＢＤポート等の専用コネクタに診断テスターを接続し、診断テスターからＥＣＵへリクエストメッセージを送信し、ＥＣＵはレスポンスメッセージを返信する。ＯＢＤは、ｏｎ－ｂｏａｒｄ　ｄｉａｇｎｏｓｔｉｃの略である。

特開２０１９－２０９９６４号公報

　しかしながら、発明者の詳細な検討の結果、以下の課題が見出された。すなわち、車両が搭載するダイアグ通信用のポート数は、通常１つであり、１つの診断テスターが接続される。そして、診断テスターは、一つのアプリケーションを実行するだけであり、単一目的・単独利用しかできないという課題が見出された。

　本開示の１つの局面は、車載ネットワークに接続される車載機を、複数目的での同時利用を可能とする技術を提供する。

　本開示の一態様は、車載機であって、データ取得部と、アプリ実行部と、スケジュール管理部と、ルーティング部と、を備える。データ取得部は、車両データの取得に用いるコマンドを、車載ネットワークに送信する送信処理を実行するように構成される。アプリ実行部は、データ取得部にて取得される車両データを利用する１つ以上のアプリケーションプログラムを実行するように構成される。スケジュール管理部は、１つ以上の管理情報を用いて、取得条件を満たす管理情報が示すコマンドを、送信処理にて送信対象となるコマンドである送信対象コマンドとして抽出するように構成される。また、スケジュール管理部は、送信対象コマンドと要求元アプリとを対応づけたルーティング情報を生成するように構成される。管理情報は車両データの取得に用いるコマンドの種類、車両データの要求元となるアプリケーションプログラムである要求元アプリ、及び車両データの取得条件が示される。ルーティング部は、データ取得部が送信処理を実行することによって取得された車両データを、ルーティング情報を用いて要求元アプリに提供するように構成される。

　このような構成によれば、車載ネットワークを介して取得される車両データを、要求元アプリに提供することができる。つまり、車載ネットワークに接続される車載機に、それぞれが独自に車両データを利用する複数のアプリケーションを同時に搭載して、動作させることができる。

　本開示の一態様は、車両データを車両データの要求元となるアプリケーションプログラムである要求元アプリに提供するデータ提供方法である。このデータ提供方法は、車両データの取得に用いるコマンドを、車載ネットワークに送信する送信処理を実行し、送信処理によって取得される車両データを１つ以上のアプリケーションプログラムに提供する車載機に適用される。

　データ提供方法では、１つ以上の管理情報を用いて、取得条件を満たす管理情報が示すコマンドを、送信処理にて送信対象となるコマンドである送信対象コマンドとして抽出する。データ提供方法では、送信対象コマンドと要求元アプリとを対応づけたルーティング情報を生成する。管理情報には、車両データの取得に用いるコマンドの種類、要求元アプリ、及び車両データの取得条件が示される。データ提供方法では、送信処理を実行することによって取得された車両データを、ルーティング情報を用いて要求元アプリに提供する。

　このような方法によれば、上述の車載機と同様の効果を得ることができる。

　本開示の一態様は、プログラムである。プログラムは、車両データの取得に用いるコマンドを、車載ネットワークに送信する送信処理を実行し、送信処理によって取得される前記車両データを１つ以上のアプリケーションプログラムに提供する車載機において実行される。プログラムは、車両データを車両データの要求元となるアプリケーションプログラムである要求元アプリに提供するために実行される。

　プログラムは、車載機に、１つ以上の管理情報を用いて、送信対象コマンドを抽出すると共にルーティング情報を生成する処理を実行させる。管理情報には、車両データの取得に用いるコマンドの種類、要求元アプリ、及び車両データの取得条件が示される。送信対象コマンドは、送信処理にて送信対象となるコマンドであって、取得条件を満たす管理情報が示すコマンドである。ルーティング情報は、送信対象コマンドと要求元アプリとを対応づけた情報である。

　プログラムは、車載機に、送信処理を実行することによって取得された車両データを、ルーティング情報を用いて要求元アプリに提供する処理を実行させる。

　このようなプログラムを実行することにより、上述の車載機と同様の効果を得ることができる。

データ提供システムの機能構成を示すブロック図である。 クラウドサーバのハードウェア構成を示すブロック図である。 車載機のハードウェア構成を示すブロック図である。 マニュフェストの構造を示す説明図である。 コマンド管理テーブルの構造を示す説明図である。 車載機の電源投入時におけるシステム各部の動作を示すシーケンス図である。 ダイアグ系アプリ配信時における動作を示すシーケンス図である。 ダイアグコマンド送信時における動作を示すシーケンス図である。 ダイアグコマンドに対する応答の受信時における動作を示すシーケンス図である。 スケジュール調整処理の内容を示すフローチャートである。 各ｔｉｃｋで抽出されるダイアグコマンドの要求を例示する説明図である。 ダイアグコマンドの要求が重複する場合の動作を示す説明図である。 ＣＡＮバスの負荷が超過する可能性がある場合の動作を示す説明図である。 コマンドの送信方法についての説明図である。 ダイアグコマンドが同一のｔｉｃｋに集中しないようにするための送信スケジュールの設定例を示す説明図である。 ターンアラウンド時間測定時における動作を示すシーケンス図である。

　以下、図面を参照しながら、本開示の実施形態を説明する。

　［１．構成］
　図１に示すデータ提供システム１は、クラウドサーバ１０と、車載機３０とを備える。図１では、例示的に、１つのクラウドサーバ１０と、１つの車載機３０とを示しているが、データ提供システム１は、複数のクラウドサーバ１０及び複数の車載機３０を備えてもよい。

　［１－１．クラウドサーバ］
　クラウドサーバ１０は、広域通信ネットワークＮＷを介してアクセス可能に構成される。クラウドサーバ１０は、車載機３０にダイアグ系アプリケーションプログラム（以下、ダイアグ系アプリ）を実行させる際に必要となる各種情報を、車載機３０に配信する。ダイアグ系アプリは、ダイアグ通信を利用して収集される車両データを利用するアプリケーションである。ダイアグ通信は、英語ではDiagnostic Communicationと表記され、車載ネットワークを利用して、電子制御装置（以下、ＥＣＵ）６３から故障診断に必要な車両データを取得する通信方法である。本実施形態では、車載ネットワークとして、ＣＡＮバス６２が利用される。ＣＡＮは、Controller Area Networkの略である。ＣＡＮは登録商標である。

　車両データは、複数のデータ種別に分類される。データ種別は、「車体制御・パワトレ系」「ＡＤ・ＡＤＡＳ系」「ドライバモニタ系」「車両ボディ系」「車室内外環境制御系」「燃料・排気系」「メディア系」「故障診断コード（以下、ＤＴＣ）」等が存在してもよい。

　車体制御・パワトレ系の車両データは、車速、車体加速度、車体角速度、ギアポジション、アクセルペダルポジション、ブレーキペダルポジション、ブレーキ圧力等を含んでもよい。

　ＡＤ・ＡＤＡＳ系の車両データは、車間距離、標識制限速度、停止標識検出、レーンキープ警告、先行車追従、クリアランスソナー、障害物検知有無等を含んでもよい。

　ドライバモニタ系の車両データは、脇見検知ステータス、注意力低下検知ステータス、ドライバ異常検知ステータス等を含んでもよい。

　車両ボディ系の車両データは、総走行距離（すなわち、オドメータの値）、Global Positioning System（以下、ＧＰＳ）位置情報、ライト点灯状態、ドア／ウィンドウ開閉状態、ドア／ウィンドウロック状態、シートベルト状態、エアバッグ状態、タイヤ空気圧、エアコン作動状況、パーキングブレーキ状態等を含んでもよい。

　車室内外環境制御系の車両データは、車室内外温度、エアコン動作状況等を含んでもよい。

　燃料・排気系の車両データは、バッテリ充電状態、燃料タンク容量、残燃料量、平均燃料消費量等を含んでもよい。

　メディア系の車両データは、使用メディアステータス、音量、Bluetooth（以下、ＢＴ）接続有無、Data Communication Module（以下、ＤＣＭ）接続有無等を含んでもよい。Bluetoothは、登録商標である。

　ＤＴＣの車両データは、ＤＴＣリスト等を含んでもよい。

　車両データは、データ種別に従って、優先度が設定されていてもよい。優先度は、例えば、以下のように設定されてもよい。但し、データ種別による優先度の設定は、下記の順位に限定されるものではなく、任意に設定することが可能である。

　車体制御・パワトレ系＞ＡＤ・ＡＤＡＳ系＞ドライバモニタ系＞車両ボディ系＞車室内外環境制御系＞燃料・排気系＞メディア系＞ＤＴＣ
　図２に示すように、クラウドサーバ１０は、制御部１１と、通信部１２と、記憶部１３と、を備える。

　制御部１１は、ＣＰＵ１１１と、ＲＯＭ１１２と、ＲＡＭ１１３と、を備える。制御部１１の各種機能は、ＣＰＵ１１１が非遷移的実体的記録媒体に格納されたプログラムを実行することにより実現される。この例では、ＲＯＭ１１２が、プログラムを格納した非遷移的実体的記録媒体に該当する。また、このプログラムの実行により、プログラムに対応する方法が実行される。

　通信部１２は、広域通信ネットワークＮＷを介して、無線通信により、車載機３０とデータ通信を行う。

　記憶部１３は、アプリケーションデータベース（以下、アプリＤＢ）１３１と、マスターデータベース（以下、マスターＤＢ）１３２を備える。アプリＤＢ１３１には、一つ以上のダイアグ系アプリに関する情報が記憶される。マスターＤＢ１３２には、車載機３０が接続される車両６０のＣＡＮバス６２に関する情報が記憶される。

　［１－２．車載機］
　図１に示すように、車載機３０は、車両６０に設けられたダイアグポート６１に接続して使用される。車載機３０は、クラウドサーバ１０から１つ以上のダイアグ系アプリ４１１をダウンロードして実行する。

　図３に示すように、車載機３０は、制御部３１と、車両インターフェース（以下、車両Ｉ／Ｆ）３２と、通信部３３と、記憶部３４と、を備える。

　制御部３１は、ＣＰＵ３１１と、ＲＯＭ３１２と、ＲＡＭ３１３と、を備える。制御部３１の各種機能は、ＣＰＵ３１１が非遷移的実体的記録媒体に格納されたプログラムを実行することにより実現される。本実施形態では、ＲＯＭ３１２が、プログラムを格納した非遷移的実体的記録媒体に相当する。また、このプログラムの実行により、プログラムに対応する方法が実行される。

　車両Ｉ／Ｆ３２は、ダイアグ用コネクタ３２１と、拡張用コネクタ３２２とを備える。

　図１に示すように、ダイアグ用コネクタ３２１は、車両６０が備えるダイアグポート６１（例えば、ＯＢＤポート）に接続される。つまり、車載機３０は、ダイアグ用コネクタ３２１が接続されたダイアグポート６１を介して、車両６０のＣＡＮバス６２に接続され、ＣＡＮバス６２を介してＥＣＵ６３が有する種々の車両データを、ダイアグ通信を利用して取得する。

　拡張用コネクタ３２２は、車両６０に後付けされる外装デバイス群７０からの信号が入力される。外装デバイス群７０には、通信チップ（例えば、ＢＬＥ、ＬＴＥ、ＮＦＣ等）、カメラ、マイク、スピーカ、加速度センサ、ジャイロセンサ等が含まれてもよい。ＢＬＥは、Bluetooth Low Energyの略であり、ＬＴＥは、Long Term Evolutionの略であり、ＮＦＣは、Near Field Communicationの略である。

　図３に戻り、通信部３３は、無線通信により、広域通信ネットワークＮＷに接続されたクラウドサーバ１０とデータ通信を行う。

　記憶部３４は、ダイアグコマンドデータベース（以下、ダイアグコマンドＤＢ３４１）と、フレーム解釈データベース（以下、フレーム解釈ＤＢ）３４２とを備える。

　ダイアグコマンドＤＢ３４１は、通信部３３を介してクラウドサーバ１０から取得されるダイアグコマンド情報を記憶する。フレーム解釈ＤＢ３４２は、通信部３３を介してクラウドサーバ１０から取得されるフレーム解釈情報を記憶する。ダイアグコマンド情報及びフレーム解釈情報については、後述する。

　［２．機能構成］
　次に、クラウドサーバ１０及び車載機３０の機能構成について説明する。

　［２－１．クラウドサーバ］
　図１に示すように、クラウドサーバ１０は、アプリＤＢ１３１と、マスターＤＢ１３２とを備える。アプリＤＢ１３１及びマスターＤＢ１３２は、記憶部１３上に構成される。

　アプリＤＢ１３１には、車載機３０に配布する１種類以上のダイアグ系アプリと、ダイアグ系アプリのそれぞれに対応づけられるマニュフェストとが記憶される。

　マニュフェストは、ダイアグ系アプリにて使用される１つ以上の車両データについて、各車両データの種類と、各車両データの取得条件等とを対応づけて記述した指示書である。マニュフェストは、アプリケーションの開発者によって作成される。マニュフェストは、アプリケーションの開発者が車両に関する専門的な知識がなくても理解できる形式で記述される。具体的には、図４に示すように、マニュフェストは、「要求情報」と「モード属性」とを含む。また、マニュフェストは、「モード属性」の内容に応じて、更に「モードサブ属性」及び「アプリメタデータ」を含んでもよい。

　「要求情報」は、車両データの種類を指定する情報である。車両データの種類を指定する際に、名称指定とコマンド指定とを用いることができる。名称指定は、車両データの意味を直感的に理解できる規格化された名称で指定する方法であり、車種によらず共通に定義される。コマンド指定は、車両のダイアグ通信で実際に送受信される形式（すなわち、ビットパターン）で指定する方法であり、車種毎に独自に定義される。

　「モード属性」は、「要求情報」に示された車両データの取得の仕方を指定する情報である。「モード属性」には、アプリ駆動、周期駆動、イベント駆動が存在する。アプリ駆動は、ダイアグ系アプリからの指示に従って、指定された車両データを限定された時間内に限定された回数だけ取得する場合に使用するモードである。アプリ駆動のうち、直ちに１回だけ取得する場合を即時駆動という。本実施形態では、アプリ駆動の一例として即時駆動について説明する。周期駆動は、指定された車両データを、指定された一定周期で繰り返し取得する場合に使用するモードである。イベント駆動は、指定されたイベントの発生時に検出される信号の変化をトリガとして、指定された車両データを取得する場合に使用するモードである。

　「モードサブ属性」は、「モード属性」の種類によって異なる情報であり、必要に応じて情報が設定される。なお、「モード属性」が即時駆動の場合、「モードサブ属性」として設定する情報は存在しなくてもよい。「モード属性」が周期駆動の場合、「モードサブ属性」として、車両データの取得周期を表す周期値、及び車両データの取得期間を表す期間値等が設定されてもよい。「モード属性」がイベント駆動の場合、「モードサブ属性」として、トリガ条件が設定されてもよい。トリガ条件は、どの信号がどのような状態になったことをトリガとするかを定義する情報である。トリガ条件は、ＣＡＮバス６２を介して得られる情報、外装デバイス群７０から得られる信号、及び外装デバイス群７０から得られる信号を加工（例えば、微分、積分、平滑化等）することで得られる情報等を利用してもよい。

　「アプリメタデータ」は、例えば、車両データの優先度を表す優先値が設定されてもよい。車両データの優先度は、同じタイミングで複数の車両データを取得することが要求され、かつ、全ての要求を処理することが困難な場合に、どの車両データの取得を優先させるかを決める際に用いる情報である。

　マスターＤＢ１３２には、ダイアグコマンド情報及びフレーム解釈情報が記憶される。

　フレーム解釈情報は、ＣＡＮバス６２で使用される通信フレームのフォーマット、及びフレームの各領域におけるビットアサインや、アサインされた領域に示される値の単位等を定義した情報である。フレーム解釈情報は、車種毎に用意され、ダイアグ通信で用いる通信フレームを解釈する際に必要となる情報である。

　ダイアグコマンド情報は、ＣＡＮバス６２で使用可能なダイアグコマンドの一覧を含む情報であり、マニュフェストの「要求情報」にて説明したように、名称指定に関する情報とコマンド指定に関する情報とが存在する。ダイアグコマンド情報は、フレーム解釈情報と同様に、車種毎に用意される。

　クラウドサーバ１０は、制御部１１が実行する処理によって実現される機能として、クラウド側アプリ管理部２１と、クラウド側ＤＢ管理部２２とを備える。

　クラウド側アプリ管理部２１は、車載機３０に対するダイアグ系アプリ等の配信、削除を実行し、配信されたたダイアグ系アプリの動作監視等も行う。クラウド側アプリ管理部２１は、アプリＤＢ１３１に記憶されるダイアグ系アプリ、及びダイアグ系アプリに関連づけられるマニュフェストに対してアプリＩＤを付与して管理する。クラウド側アプリ管理部２１は、ダイアグ系アプリを、該ダイアグ系アプリを開発した事業者と関連付けて管理してもよい。

　クラウド側ＤＢ管理部２２は、マスターＤＢ１３２の更新、及び車載機３０からの要求に応じてマスターＤＢ１３２に記憶されるダイアグコマンド情報及びフレーム解釈情報の配信を実行する。クラウド側ＤＢ管理部２２は、車両識別番号（以下、ＶＩＮ）から車種を特定できるように構成されてもよい。

　［２－２．車載機］
　車載機３０は、ダイアグコマンドＤＢ３４１と、フレーム解釈ＤＢ３４２と備える。ダイアグコマンドＤＢ３４１及びフレーム解釈ＤＢ３４２は、記憶部３４上に構成される。

　ダイアグコマンドＤＢ３４１は、車載機３０が取り付けられた車両（以下、搭載車両）６０の車種に適用されるダイアグコマンド情報が記憶される。

　フレーム解釈ＤＢ３４２は、搭載車両６０の車種に適用されるフレーム解釈情報が記憶される。

　車載機３０は、制御部３１が実行する処理によって実現される機能として、アプリ実行環境４１と、ＡＰＩ群４２と、ルーティング部４３と、ＣＡＮ送信部４４と、ＣＡＮ受信部４５と、車側アプリ管理部４６と、マニュフェスト管理部４７と、スケジュール管理部４８と、車側ＤＢ管理部４９と、外装デバイス管理部５０とを備える。

　外装デバイス管理部５０は、車載機３０の拡張用コネクタ３２２に接続された外装デバイス群７０の管理を行う。外装デバイス管理部５０は、外装デバイス群７０に属する各外装デバイスから入力される信号を監視する。外装デバイス管理部５０は、監視対象の信号が、スケジュール管理部４８から通知されるトリガ条件を充足する場合、スケジュール管理部４８にイベントの発生を通知する機能を有する。外装デバイス管理部５０は、車載機３０の起動時に、拡張用コネクタ３２２に接続された外装デバイス群７０が、前回の起動時と比較して変化があることを検出した場合、スケジュール管理部４８にハードウェア構成の変更を通知する機能を有してもよい。

　車側ＤＢ管理部４９は、車載機３０が搭載車両６０への初回接続時に、クラウドサーバ１０から搭載車両６０に適合するダイアグコマンド情報及びフレーム解釈情報を取得し、ダイアグコマンドＤＢ３４１及びフレーム解釈ＤＢ３４２に記憶させる。

　アプリ実行環境４１は、ＯＳ及びミドルウェア等を含み、クラウドサーバ１０から配布されるダイアグ系アプリの実行環境を提供する。

　車側アプリ管理部４６は、広域通信ネットワークＮＷを介してクラウドサーバ１０からダイアグ系アプリ４１１を取得し、取得したダイアグ系アプリ４１１を、アプリ実行環境４１にて実行できるようにデプロイ（すなわち、配置、展開）する。また、車側アプリ管理部４６は、デプロイされたダイアグ系アプリ４１１の動作監視、及びデプロイされているダイアグ系アプリ４１１の削除等も行う。さらに、車側アプリ管理部４６は、ダイアグ系アプリ４１１と共に、クラウドサーバ１０から配布されるマニュフェストを、マニュフェスト管理部４７に提供する。車側アプリ管理部４６は、ダイアグ系アプリのデプロイ及び削除が行われる毎に、スケジュール管理部４８にソフトウェア構成の変更を通知する機能を有してもよい。

　ＡＰＩ群４２は、アプリ実行環境４１にて実行されるダイアグ系アプリ４１１に様々な機能を提供するアプリケーションプログラミングインターフェース（以下、ＡＰＩ）の集合である。ＡＰＩ群４２には、搭載車両６０のＣＡＮバス６２を介して車両データを取得する機能を提供するＡＰＩが少なくとも含まれる。

　ルーティング部４３は、スケジュール管理部４８から通知されるルーティング情報を有する。ルーティング情報は、車両データの要求元となるダイアグ系アプリ４１１（以下、要求元アプリ）と、要求に従ってＣＡＮバス６２に送信されるダイアグコマンドとを対応づけた情報である。ルーティング部４３は、ＣＡＮ送信部４４がダイアグコマンドを送信することによって、ＣＡＮ受信部４５で受信される車両データを、ルーティング情報を参照して、要求元アプリに配布する。

　つまり、ＣＡＮは、通信相手を特定するセッション管理を行わない通信であるため、要求元アプリが複数存在する場合に、受信フレームが、どのダイアグ系アプリ４１１からの要求に基づくものであるかを判定できない。そこで、ルーティング部４３では、要求元アプリとコマンドＩＤとを対応づけたルーティング情報を参照することにより、ＣＡＮ受信部４５を介してＣＡＮバス６２から取得された車両データが、各要求元アプリに正しく届くようにしている。

　マニュフェスト管理部４７は、記憶部４７１と、解釈部４７２とを備える。

　記憶部４７１は、車側アプリ管理部４６から提供されるマニュフェストを記憶する。

　解釈部４７２は、記憶部４７１に記憶されたマニュフェストの内容を解釈することで、コマンド管理テーブルの設定に必要な情報を抽出及び生成して、スケジュール管理部４８に提供する。具体的には、解釈部４７２は、マニュフェストの「要求情報」から車両データを特定し、特定された車両データを取得する際に使用するコマンドのコマンドＩＤを、ダイアグコマンド情報から抽出する。解釈部４７２は、マニュフェストの「モード属性」「モードサブ属性」の内容を、車両データの取得条件として抽出する。解釈部４７２は、マニュフェストの「アプリメタデータ」の内容を、送信優先度を表す優先値として抽出する。解釈部４７２は、「アプリメタデータ」に設定された優先値を用いる代わりに、マニュフェストの「モード属性」及び「モードサブ属性」（すなわち、車両データの取得条件）から、例えば次のように優先値を自動的に設定してもよい。

　「即時駆動ｏｒイベント駆動」＜「周期駆動：長周期」＜「周期駆動：短周期」
　つまり、周期駆動コマンドの優先度を、即時駆動コマンド及びイベント駆動コマンドの優先度を高くし、また、周期駆動コマンド同士では、より短周期のコマンドの優先度を高くしてもよい。但し、優先度の順位は、上記記載に限定されるものではなく、任意に設定することが可能である。

　また、解釈部４７２は、「アプリメタデータ」に設定された優先値を用いる代わりに、マニュフェストの「要求情報」から特定される車両データのデータ種別に応じて設定される優先値を用いてもよい。また、車両データの取得条件に基づいて設定される優先値と、データ種別に応じて設定される優先値とを組み合わせて用いてもよい。

　スケジュール管理部４８は、設定部４８１と、調整部４８２と、負荷算出部４８３とを備える。

　設定部４８１は、解釈部４７２でのマニュフェストの解釈結果に基づいて、コマンド管理テーブルに、車両データの取得条件が示された管理情報を追加する。コマンド管理テーブルは、ダイアグコマンドの送信タイミングを管理するために用いる情報が示されたテーブルである。

　図５に示すように、コマンド管理テーブルに設定される管理情報には、「アプリＩＤ」「コマンドＩＤ」「送信待ステータス」「補足情報」「送信優先度」を含む。コマンド管理テーブルは、「モード属性」の種類毎に生成され、「モード属性」毎に「補足情報」の内容が互いに異なる。

　「アプリＩＤ」は、要求元アプリを特定する情報であり、車側アプリ管理部４６によってダイアグ系アプリがデプロイされたときに付与される。

　「コマンドＩＤ」は、マニュフェストの「要求情報」に示された車両データを取得する際に使用するダイアグコマンドを特定する情報である。

　「送信待ステータス」は、送信までの残りｔｉｃｋ数が示される。ｔｉｃｋは、ダイアグコマンド送信処理の実行周期であり、例えば、１００ｍｓに設定される。残りｔｉｃｋ数は、ｔｉｃｋ毎に値がデクリメントされ、残りｔｉｃｋ数が０になった管理情報が、次回のｔｉｃｋで処理される。

　但し、「モード属性」が周期駆動の場合、「送信待ステータス」は、コマンドの送信が実行される毎に、「モードサブ属性」に示された周期値に対応するｔｉｃｋ数にプリセットされる。その結果、周期駆動の場合は周期値に応じた周期でコマンドの送信が繰り返される。

　「モード属性」がイベント駆動の場合、「送信待ステータス」は、通常時は、要求が無いことを示す無効値に設定され、指定されたトリガ条件を充足した場合に０に設定され、コマンド送信後、再び無効値に設定される。無効値は、例えば、全ビットを１でパディングした値であってもよい。

　「モード属性」が即時駆動の場合、「送信待ステータス」は、通常時は無効値に設定され、ダイアグ系アプリ４１１からの要求が発生した場合に０に設定され、コマンド送信後、再び無効値に設定される。「送信待ステータス」が無効値に設定されている場合、ｔｉｃｋ毎のデクリメントは行われず、無効値が維持される。

　「モード属性」が周期駆動の場合、「補足情報」として「送信残数」が設定されてもよい。「送信残数」は、マニュフェストの「モードサブ属性」に有効期間の情報が含まれている場合に、有効期間を残りｔｉｃｋ数で示した値が設定される。有効期限が無制限の場合、「送信残数」は、無効値に設定される。「送信残数」の残りｔｉｃｋ数は、ｔｉｃｋ毎に値がデクリメントされる。但し、無効値に設定されている場合は、ｔｉｃｋ毎のデクリメントは行われず無効値が維持される。「送信残数」のｔｉｃｋ数が０になった管理情報は、コマンド管理テーブルから削除される。

　「モード属性」がイベント駆動の場合、「補足情報」として「トリガ種類」が設定されてもよい。「トリガ種類」には、イベントの発生を通知する条件であるトリガ条件が設定される。設定部４８１は、「トリガ種類」の内容に従って、外装デバイス管理部５０及びＣＡＮ受信部４５に、トリガ条件を通知する。

　「モード属性」が即時駆動の場合、「補足情報」として「ペイロード」が設定されてもよい。「ペイロード」は、ＣＡＮフレームのペイロードに書き込まれるビット形式で示されたコマンドそのものが設定される。

　「送信優先度」には、優先値が設定される。優先値は、コマンド管理テーブルに従って、送信候補となるコマンドを抽出したときに、負荷超過等の理由ですべての送信候補を次回のｔｉｃｋで処理することが困難である場合、どのダイアグコマンドを優先させるかを決めるための情報である。ここでは、優先値が大きいほど優先度も高いとする。マニュフェストの「アプリメタデータ」として優先値が設定されている場合は、この優先値を用いてもよい。優先値が設定されていない場合、最低優先度とみなしてもよい。

　調整部４８２は、コマンド管理テーブルを参照して、次回のｔｉｃｋで処理する管理情報、すなわち送信対象となるダイアグコマンドを決定して、ＣＡＮ送信部４４に通知する。なお、送信対象となるダイアグコマンドの決定には、各ダイアグコマンドのターンアラウンド時間、ＣＡＮバス６２のトラフィック、ダイアグコマンドの送信優先度が勘案される。

　ダイアグ通信において、コマンドの並列送信が禁止され、コマンドの交互通信を行うようにされている場合、ｔｉｃｋ当たりの送信可能なコマンドの数は、ターンアラウンド時間から推定できる。交互通信は、図１４の上段に示すように、コマンドの送信後、その応答を受信してから次のコマンドを送信する方法である。並列送信は、図１４の下段に示すように、コマンドの送信後、その応答の受信を待つことなく次のコマンドを送信する方法である。

　トラフィックは、ＣＡＮバス６２が使用されている割合である。トラフィックが高いほどターンアラウンド時間が長くなるため、ｔｉｃｋ当たりの送信可能なコマンドの数は少なくなる。また、ＣＡＮバス６２において許容されるトラフィックの上限値（以下、許容値）は、車種毎に設定されていてもよい。

　負荷算出部４８３は、車載機３０の起動時の初期化処理後に、調整部４８２での処理に用いるターンアラウンド時間の測定を行う。ターンアラウンド時間の測定は、ＣＡＮ送信部４４にＣＡＮバス６２にコマンドを送信させ、ＣＡＮ受信部４５が応答を受信するまでの時間を測定する。この測定を、複数のコマンドについて繰り返し実行する。負荷算出部４８３は、測定されたターンアラウンド時間の平均値を算出してもよい。負荷算出部４３８は、コマンド毎に測定されたターンアラウンド時間、及びターンアラウンド時間の平均値のいずれか又は両方を、ダイアグコマンドＤＢ３４１に格納する。なお、ターンアラウンド時間の平均値に代えて、ターンアラウンド時間の平均値に安全マージンを加えた値を用いてもよい。

　負荷算出部４８３は、車載機３０が起動する毎にターンアラウンド時間の測定を行ってもよい。また、図１６に点線で示すように、負荷算出部４８３は、外装デバイス管理部５０からハードウェア構成の変更を示す通知を受けた場合にターンアラウンド時間の測定を行ってもよい。負荷算出部４８３は、車側アプリ管理部４６からソフトウェア構成の変更を示す通知を受けた場合に、ターンアラウンド時間の測定を行ってもよい。

　ＣＡＮ送信部４４は、コマンド生成部４４１を備える。コマンド生成部４４１は、スケジュール管理部４８の調整部４８２からの指示に従い、ダイアグコマンドＤＢ３４１を参照して、ダイアグコマンドを生成する。コマンド生成部４４１は、更に、ダイアグコマンドをペイロードに格納したＣＡＮフレームを生成して、送信バッファに格納する。ＣＡＮ送信部４４は、送信バッファに格納されたＣＡＮフレームを、ダイアグ用コネクタ３２１を介してＣＡＮバス６２に送信する。

　ＣＡＮ受信部４５は、フレーム解釈部４５１を備える。ＣＡＮ受信部４５は、ダイアグ用コネクタ３２１を介してＣＡＮバス６２から受信したＣＡＮフレーム（すなわち、ダイアグコマンドに対する応答）を、受信バッファに格納する。フレーム解釈部４５１は、フレーム解釈ＤＢ３４２に記憶されたフレーム解釈情報を参照して、受信したＣＡＮフレーム（以下、受信フレーム）の内容を解釈する。フレーム解釈部４５１は、受信フレームのペイロードに示され、車両６０に固有な形式で記述された車両データを、要求元アプリにて理解可能な形式に変換する。そして、フレーム解釈部４５１は、解釈され変換された車両データを、送信したダイアグコマンドのコマンドＩＤと共にルーティング部４３に提供する。

　ＣＡＮ受信部４５は、周期的に受信する車両データを監視する機能を有する。ＣＡＮ受信部４５は、監視対象信号が、スケジュール管理部４８から通知されるトリガ条件を充足する場合、スケジュール管理部４８にイベントの発生を通知する機能を有する。ＣＡＮ受信部４５は、ＣＡＮ送信部４４にてコマンドが送信されてから、そのコマンドに対する応答がＣＡＮ受信部４５にて受信されるまでの時間であるターンアラウンド時間を測定して、負荷算出部４８３に通知する機能を有する。

　ルーティング部４３は、ＣＡＮ受信部４５から提供される車両データを、スケジュール管理部４８の調整部４８２から通知されるルーティング情報に従って、要求元アプリに提供する。

　［３．動作］
　［３－１．車載機の電源投入時の動作］
　車載機３０の電源投入時における、システム各部の動作について、図６に示すシーケンス図を用いて説明する。

　図６に示すように、車載機３０に電源が投入されると、車載機３０は、車載機３０を初期化する処理（以下、車載機初期化処理）Ｓ１を実行する。この車載機初期化処理Ｓ１により、車載機３０は、標準コマンドを用いたダイアグ通信が可能な状態となる。

　車側ＤＢ管理部４９は、標準コマンドの１つであるＶＩＮ取得コマンドを、ＣＡＮ送信部４４を介してＣＡＮバス６２に送信し、その応答を、ＣＡＮ受信部４５を介して受信することで、車両６０からＶＩＮ情報を取得する。

　車側ＤＢ管理部４９は、取得したＶＩＮ情報を用いて、ダイアグコマンドＤＢ３４１及びフレーム解釈ＤＢ３４２の更新の要否を判定する。具体的には、ダイアグコマンドＤＢ３４１及びフレーム解釈ＤＢ３４２に、ＶＩＮ関連情報が記憶されていない場合は、更新要と判定する。ＶＩＮ関連情報は、取得したＶＩＮ情報に紐づけられるダイアグコマンド情報及びフレーム解釈情報である。ダイアグコマンドＤＢ３４１及びフレーム解釈ＤＢ３４２にＶＩＮ関連情報が既に記憶されている場合、更新不要と判定する。

　例えば、車載機３０が初めて車両に取り付けられた場合には更新要と判定される。また、第１の車両６０から車載機３０が取り外され、第１の車両６０のＶＩＮ関連情報がダイアグコマンドＤＢ３４１及びフレーム解釈ＤＢ３４２に残されている状態で、第２の車両６０に取り付けられ、改めて第２の車両６０のＶＩＮ情報を取得した場合には、更新要と判定される。

　車側ＤＢ管理部４９は、更新不要と判定した場合、動作を終了する。

　車側ＤＢ管理部４９は、更新要と判定した場合、取得したＶＩＮ情報と共にデータ取得要求を、クラウドサーバ１０に対して送信することで、クラウドサーバ１０から、搭載車両６０の車種に対応したＶＩＮ関連情報を取得する。このとき、クラウドサーバ１０のクラウド側ＤＢ管理部２２は、データ取得要求に示されたＶＩＮ情報から車種を特定し、特定した車種に対応するＶＩＮ関連情報をマスターＤＢ１３２から読み出して、車載機３０に返信する。

　車側ＤＢ管理部４９は、クラウドサーバ１０から受信したＶＩＮ関連情報によって、ダイアグコマンドＤＢ３４１及びフレーム解釈ＤＢ３４２を更新する。なお、更新されるＶＩＮ関連情報は、ＶＩＮ情報に対応付けて記憶される。

　以下では、図６を用いて説明した処理のうち、車載機初期化処理Ｓ１の後に実行される一連の処理をデータベース更新処理Ｓ２ともいう。

　［３－２．ターンアラウンド時間測定］
　車載機３０が使用するダイアグコマンドのターンアラウンド時間を測定するときのシステム各部の動作を、図１６に示すシーケンス図を用いて説明する。

　図１６に示すように、図６を用いて先に説明した車載機初期化処理Ｓ１、データベース更新処理Ｓ２が終了すると、負荷算出部４８３は、ターンアラウンド時間測定用に、予め指定された複数のコマンドをダイアグコマンドＤＢ３４１から読みだす。読み出したコマンドの１つを測定対象コマンドとして選択し、選択した測定対象コマンドを用いてターンアラウンド時間を測定するように、ＣＡＮ送信部４４に通知する。

　ＣＡＮ送信部４４は、ＣＡＮバス６２に測定対象コマンドを送信する。このとき、ＣＡＮ受信部４５は、ターンアラウンド時間の計測を開始する。ＣＡＮ受信部４５は、ＣＡＮバス６２から応答を受信すると、ターンアラウンド時間の計測を停止し、測定結果を負荷算出部４８３に送信する。

　負荷算出部４８３は、ダイアグコマンドＤＢ３４１から読み出したすべてのコマンドについて、同様の処理を行うことによって、各コマンドのターンアラウンド時間を取得する。負荷算出部４８３は、指定されたすべてのコマンドの送信が終了すると、ターンアラウンド時間の平均値を算出する。更に、負荷算出部４８３は、個々のコマンドのターンアラウンド時間の測定結果、及びターンアラウンド時間の平均値の算出結果を、調整部４８２の処理にて利用できるように、ダイアグコマンドＤＢ３４１に格納する。

　負荷算出部４８３は、車載機３０が起動する毎にターンアラウンド時間の測定を行ってもよい。また、負荷算出部４８３は、外装デバイス管理部５０からハードウェア構成の変更を示す通知を受けた場合、又は、車側アプリ管理部４６からソフトウェア構成の変更を示す通知を受けた場合に、ターンアラウンド時間の測定を行ってもよい。

　［３－３．アプリ配信／コマンド管理テーブル設定］
　クラウドサーバ１０から車載機３０へのダイアグ系アプリ配信時におけるシステム各部の動作について、図７に示すシーケンス図を用いて説明する。

　図７に示すように、配信待ちのダイアグ系アプリがアプリＤＢ１３１に記憶されている場合、クラウドサーバ１０のクラウド側アプリ管理部２１が、車載機３０にダイアグ系アプリの配信受け入れを要求する配信要求を送信する。

　車載機３０の車側アプリ管理部４６は、配信要求を受信すると、配信要求に示された情報に従って配信を受け入れるか否かを判定し、受け入れる場合は、許諾通知をクラウドサーバ１０に送信する。配信の受け入れ可否を判定するための情報としては、プログラムの保存に必要なメモリ容量、アプリの実行に必要なＣＰＵの処理能力及びメモリ容量等が含まれてもよい。

　クラウド側アプリ管理部２１は、アプリＤＢ１３１に記憶されているダイアグ系アプリ及びマニュフェストを、許諾通知を返信してきた車載機３０に配信送信する。このとき、クラウド側アプリ管理部２１は、配信先の車載機３０に関する情報（例えば、車載機３０を搭載する車両のＶＩＮ情報等）を、アプリＤＢ１３１に登録してもよい。

　車側アプリ管理部４６は、クラウドサーバ１０からダイアグ系アプリを受信すると、受信したダイアグ系アプリ４１１をアプリ実行環境４１にて実行できるようにデプロイする。また、車側アプリ管理部４６は、ダイアグ系アプリ４１１に添付されたマニュフェストを、マニュフェスト管理部４７に提供する。デプロイされたダイアグ系アプリ４１１には、アプリＩＤが付与され、このアプリＩＤが、マニュフェスト管理部４７に提供するマニュフェストにも対応づけられる。

　マニュフェスト管理部４７は、車側アプリ管理部４６から提供されるマニュフェストを記憶部４７１に記憶すると共に、解釈部４７２にてマニュフェストの内容を解釈して、コマンド管理テーブルへの登録に必要な情報を抽出する。具体的には、解釈部４７２は、マニュフェストに対応づけられたアプリＩＤ、コマンドＩＤ、車両データ取得条件（すなわち、「モード属性」及び「モードサブ属性」）、送信優先度を抽出して、スケジュール管理部４８に提供する。

　なお、マニュフェストの「モード属性」が周期駆動であり、「モードサブ属性」に示された周期値がｔｉｃｋより短い場合、要求通りのタイミングで車両データを取得できない旨を、車側アプリ管理部４６に通知してもよい。通知を受けた車側アプリ管理部４６は、対応するダイアグ系アプリを削除し、配信元のクラウドサーバ１０に、アプリを削除した旨を理由と共に通知してもよい。

　スケジュール管理部４８の設定部４８１は、マニュフェスト管理部４７の解釈部４７２から提供された情報（以下、更新用情報）を用いて、コマンド管理テーブルを更新する。

　なお、図５に示すように、コマンド管理テーブルは、「モード属性」の種類毎に用意される。コマンド管理テーブルの更新は、新たな管理情報（すなわち、アプリＩＤ、コマンドＩＤ、送信待ステータス、補助情報、送信優先度）を追加することで行う。

　［３－４．送信待ステータス更新］
　スケジュール管理部４８の調整部４８２が、コマンド管理テーブルの「送信待ステータス」を更新する動作について説明する。

　調整部４８２は、周期駆動用のコマンド管理テーブルに登録された管理情報については、後述するスケジュール調整処理が終了する毎に、「送信待ステータス」及び「補助情報（すなわち、送信残数）」に示された残りｔｉｃｋ数を、いずれも１減じる。但し、調整部４８２は、減じる前の「送信待ステータス」の残りｔｉｃｋ数が０である管理情報については、残りｔｉｃｋ数を減じる代わりに、残りｔｉｃｋ数を周期値に応じた値にプリセットする。

　調整部４８２は、「補助情報」の残りｔｉｃｋ数を減じた結果、「補助情報」の残りｔｉｃｋ数が０となる管理情報については、その管理情報をコマンド管理テーブルから削除する。

　調整部４８２は、外装デバイス管理部５０又はＣＡＮ受信部４５からトリガ信号を受信した場合、イベント駆動用のコマンド管理テーブルにおいて、受信したトリガ信号に対応する管理情報の「送信待ステータス」を０に設定する。

　調整部４８２は、ダイアグ系アプリからＡＰＩ群４２を介して車両データの即時取得要求を受信した場合、即時駆動用のコマンド管理テーブルにおいて、受信した即時取得要求に対応する管理情報の「送信待ステータス」を０に設定する。

　［３－５．スケジュール調整］
　スケジュール管理部４８の調整部４８２が、コマンド管理テーブルを用いて、次回のｔｉｃｋにて送信するダイアグコマンドを決定するスケジュール調整処理を、図８のシーケンス図、及び図１０のフローチャートを用いて説明する。

　調整部４８２は、スケジュール調整処理を、ｔｉｃｋ毎に実行する。

　スケジュール調整処理が開始されると、まずＳ１１０にて、調整部４８２は、ＣＡＮバス６２のトラフィック状況を取得する。トラフィック状況は、ＣＡＮバス６２のトラフィックを測定するＥＣＵ６３から取得される情報を用いてもよいし、車載機３０にて別途測定することで取得される情報を用いてもよい。また、トラフィック状況は、予めシステムに登録されている静的な情報（以下、静的トラフィック情報）を用いてもよい。静的トラフィック情報は、例えば、車種毎に測定された平均値、又は平均値に安全マージンを加えた値であってもよい。また、静的トラフィック情報は、例えば、ダイアグコマンドＤＢ３４１に格納される情報に含まれていてもよい。更に、静的トラフィック情報は、例えば、ＥＣＵ６３又は車載機３０から、その時々で測定される動的なトラフィック状況を表す情報である動的トラフィック情報を取得できない場合に使用してもよい。

　続くＳ１２０では、調整部４８２は、コマンド管理テーブルの「送信待ステータス」を参照して、残りｔｉｃｋ数が０に設定されているすべての管理情報、すなわち、次回のｔｉｃｋで処理対象となる全ての管理情報を、送信候補コマンドとして抽出する。コマンド管理テーブルに基づき、各ｔｉｃｋにて抽出される送信候補コマンド（すなわち、ダイアグコマンドの送信要求）を、図１１に例示する。図１１では、３つの周期駆動コマンドＣ１～Ｃ３が存在し、イベント駆動コマンドが１回、即時駆動コマンドが２回発生した場合を示す。なお、周期駆動コマンドＣ１は０．５ｓ（すなわち、５ｔｉｃｋ）周期で処理され、周期駆動コマンドＣ２は０．２ｓ（すなわち、２ｔｉｃｋ）周期で処理され、周期駆動コマンドＣ３は０．１ｓ（すなわち、１ｔｉｃｋ）周期で処理される。図１１は、負荷調整前におけるダイアグコマンドの送信スケジュールを示す。

　続くＳ１３０では、調整部４８２は、送信候補コマンドとして抽出された管理情報の中に、同一のコマンドＩＤを有する重複した管理情報が存在する場合、１つの管理情報を残して、他の重複した管理情報を送信候補コマンドから除外する。また、調整部４８２は、ルーティング部４３に提供するルーティング情報を生成する。ルーティング情報は、コマンド管理テーブルに示された情報に基づいて、送信候補コマンドが示すコマンドＩＤと、送信候補コマンドの要求元アプリのアプリＩＤとを対応づけた情報である。ルーティング情報において、各コマンドＩＤは、それぞれ１つ以上のアプリＩＤに対応づけられる。

　例えば、図１２に示すように、複数のダイアグ系アプリ４１１から異なる周期で、同一の車両データを取得する周期駆動コマンドＣ４，Ｃ５を送信するように設定されている場合、両アプリからの要求が同一のｔｉｃｋで重なることがある。このような場合に、重複する周期駆動コマンドＣ４，Ｃ５をいずれも送信するのではなく、いずれか一つ（例えば、図１２ではコマンドＣ５）だけ送信するように調整を行う。但し、セッション管理を行わないＣＡＮの情報だけでは、取得した車両データと要求元アプリとの対応が不明となるため、取得した車両データが、要求元アプリに正しく提供されるように、ルーティング情報が利用される。

　続くＳ１４０では、調整部４８２は、すべての送信候補コマンドのターンアラウンド時間を取得する。コマンド毎のターンアラウンド時間は、先に説明した通り、車載機３０の起動時に計測され、ダイアグコマンドＤＢ３４１に記憶された計測値を用いてもよいし、計測値から算出されたターンアラウンド時間の平均値を用いてもよいし、設計値を用いてもよい。

　続くＳ１５０では、調整部４８２は、すべての送信候補コマンドを交互通信で送信した場合に必要となる必要時間Ｔｎｅｅｄを算出する。必要時間Ｔｎｅｅｄは、すべての送信候補コマンドのターンアラウンド時間の合計値である。但し、ターンアラウンド時間は、Ｓ１１０で取得したトラフィック状況に応じて、混雑しているほど長くなるように補正されてもよい。

　続くＳ１６０では、調整部４８２は、次のｔｉｃｋでの処理が負荷超過となるか否かを判定する。負荷超過とは、Ｓ１５０で算出された必要時間Ｔｎｅｅｄがｔｉｃｋより大きい場合、又は、送信候補コマンドを送信するとＣＡＮバス６２の推定トラフィックが許容値を超える場合のことをいう。調整部４８２は、Ｓ１６０にて負荷超過とはならないと判定した場合、処理をＳ２００に移行し、負荷超過となると判定した場合、処理をＳ１７０に移行する。

　Ｓ１７０では、調整部４８２は、送信候補コマンドの中に除外可コマンドがあるか否かを判定する。例えば、優先値が除外可しきい値以下である送信候補コマンドを、除外可コマンドとしてもよい。

　調整部４８２は、送信候補コマンドの中に除外可コマンドがある場合、処理をＳ１８０に移行し、除外可コマンドがない場合、処理をＳ１９０に移行する。

　Ｓ１８０では、調整部４８２は、送信候補コマンドに含まれる除外可コマンドの少なくとも１つを送信候補コマンドから除外すると共に、除外した送信候補コマンドに関する情報を、ルーティング情報からも除外して、処理をＳ１５０に戻す。なお、調整部４８２は、除外した送信候補コマンドの要求元アプリに対して、要求が処理されなかったことを通知してもよい。

　Ｓ１９０では、調整部４８２は、送信候補コマンドの中で優先値が最も低いコマンド、又は周期値が所定値（例えば、１０ｔｉｃｋ）以上であるコマンドの少なくとも１つを、送信候補コマンドから除外して、送信保留コマンドとする。また、調整部４８２は、ルーティング情報から、送信保留コマンドに関する情報を除外する。更に、調整部４８２は、送信保留コマンドが、次のｔｉｃｋにて、再び送信候補コマンドとして抽出されるように、コマンド管理テーブルにおいて、送信保留コマンドの「送信待ステータス」の残りｔｉｃｋ数を１増加させて、処理をＳ１５０に戻す。なお、残りｔｉｃｋ数を増加させる数は、１に限定されるものではなく、例えば、一定の範囲内でランダムに選択される数を用いてもよい。また、一定の範囲は、ＣＡＮバス６２のトラフィック状況に応じて混雑時ほど大きくなるように設定してもよい。

　Ｓ２００では、調整部４８２は、送信候補コマンドを送信対象コマンドとして、ＣＡＮ送信部４４に通知すると共に、ルーティング情報をルーティング部４３に通知して、処理を終了する。

　つまり、図１３に示すように、負荷超過が生じた場合、送信候補コマンドに除外可コマンドＣＲが含まれていれば、その除外可コマンドＣＲを除外することでＣＡＮバス６２の負荷を調整する。また、除外可コマンドＣＲが含まれていなければ、送信候補コマンドのうち優先度の低い低優先コマンドＣＬ、又は周期値が所定値以上であるコマンドが次回以降のｔｉｃｋで送信されるようにすることでＣＡＮバス６２の負荷を調整する。

　図８に示すように、ＣＡＮ送信部４４は、送信対象コマンドの通知を受けると、送信対象コマンドの管理情報に示されたコマンドＩＤ従って、ダイアグコマンドＤＢ３４１からダイアグコマンドを表すビットパターンを取得する。ＣＡＮ送信部４４は、取得したビットパターンをペイロードに設定した送信フレーム（すなわち、ＣＡＮフレーム）を生成して、送信バッファに転送する。

　送信バッファに転送されたＣＡＮフレームは、ＣＡＮバス６２におけるダイアグ通信の送受信プロセスに従って送受信される。

　［３－６．レスポンス受信］
　車載機３０が、ダイアグコマンドを載せたＣＡＮフレームを送信し、ダイアグコマンドに対する応答（すなわち、車両データ）を載せたＣＡＮフレームを車両６０から受信したときの動作について、図９に示すシーケンス図を用いて説明する。

　図９に示すように、ＣＡＮ受信部４５は、ダイアグコマンドの応答が示されたＣＡＮフレームを受信すると、フレーム解釈部４５１にて、受信したＣＡＮフレームのペイロードをビット解析する。ビット解析には、フレーム解釈ＤＢ３４２に記憶されたフレーム解釈情報が用いられる。ビット解析により得られる車両データは、何らかの状態（例えば、スイッチのオンオフ等）を表す値であってもよいし、アナログ信号のサンプリング値（すなわち、物理量）であってもよい。車両データが物理量を表している場合、フレーム解釈部４５１は、取得した物理量を、所定の単位（例えば、要求元アプリで使用される単位）に換算してもよいし、取得した物理量に対して時系列処理等を施してもよい。時系列処理は、取得した車両データに対して微分、積分、平滑化等を施す処理である。

　ＣＡＮ受信部４５は、フレーム解釈部４５１にて処理された車両データを、その車両データを取得するために送信したダイアグコマンドを表すコマンドＩＤと共にルーティング部４３に通知する。

　ルーティング部４３は、ＣＡＮ受信部４５から通知されるコマンドＩＤ及び車両データに基づき、スケジュール管理部４８から通知されたルーティング情報を参照して、コマンドＩＤに対応するアプリＩＤを特定する。更に、ルーティング部４３は、アプリＩＤが示す要求元アプリに、アプリ実行環境４１を介して車両データを通知する。

　［４．用語の対応］
　本実施形態において、ＣＡＮ送信部４４及びＣＡＮ受信部４５が本開示におけるデータ取得部に相当し、アプリ実行環境４１が本開示におけるアプリ実行部に相当する。車側ＤＢ管理部４９が本開示における周辺情報取得部に相当し、ダイアグコマンド情報及びフレーム解釈情報が本開示における周辺情報に相当する。

　［５．効果］
　以上詳述した実施形態によれば、以下の効果を奏する。

　（５ａ）データ提供システム１において、車載機３０は、クラウドサーバ１０からダイアグ系アプリ４１１と共に配信されるマニュフェストに従って、コマンド管理テーブルに登録する管理情報を生成する。そして、車載機３０は、コマンド管理テーブルに登録された管理情報を用いることで、複数のダイアグ系アプリからの車両データの取得要求を処理するタイミングを調整する。

　従って、車載機３０によれば、ダイアグ通信を利用する複数のダイアグ系アプリを同時に動作させることができる。すなわち、車両６０のダイアグポート６１を、異なった複数の目的について同時使用することができる。

　（５ｂ）車載機３０は、車両データの取得条件が示されたマニュフェストに従って、車両データの取得スケジュールを管理する。また、車載機３０は、ダイアグコマンド情報及びフレーム解釈情報に従って、搭載車両６０に適合したダイアグコマンドの生成、及び搭載車両６０からの応答の解釈を行う。従って、アプリの開発者は、配信先の車両６０のダイアグ通信に関する知識が不足していても、ダイアグ系アプリ４１１を開発することができる。

　（５ｃ）車載機３０では、ルーティング情報を作成することで、送信するダイアグコマンドと、要求元アプリとの対応づけを行っている。従って、同一ｔｉｃｋタイミングで同一コマンドの送信要求が重複することで、重複するコマンドが削除された場合でも、ルーティング情報を参照して、取得した車両データを、すべての要求元アプリに正しく提供することができる。

　（５ｄ）車載機３０では、コマンド管理テーブルから抽出されるすべての送信候補コマンドを送信すると、負荷超過が生じる可能性がある場合、負荷調整を行う。負荷調整では、送信候補コマンドの一部を、送信対象から除外したり、次回以降のｔｉｃｋで処理されるように調整したりする。従って、ＣＡＮバス６２のトラフィックを許容範囲内に抑えることができ、ＥＣＵ６３間で送受信される正規のコマンド（例えば、車両制御用のコマンド）の送受信に遅延などの影響が生じることを抑制できる。また、アプリの開発者は、各車両６０におけるＣＡＮバス６２のトラフィック制限等についての知識がなくても、安全に動作するダイアグ系アプリ４１１を開発することができる。

　（５ｅ）車載機３０では、周期駆動の要求の場合、周期値が大きいほど優先度を低く設定している。つまり、負荷超過により処理が保留されることによる低優先度コマンドの送信周期のずれ（すなわち、遅延）による影響は、保留されたコマンドの周期値が大きいほど相対的に小さくなるため、要求元アプリが実現する機能への影響を小さく抑えることができる。

　［６．他の実施形態］
　以上、本開示の実施形態について説明したが、本開示は上述の実施形態に限定されることなく、種々変形して実施することができる。

　（６ａ）上記実施形態では、負荷超過時に、除外可コマンドがない場合、低優先度のコマンドの処理を遅延させているが、即時駆動又はイベント駆動に関するコマンドの処理を遅らせるようにしてもよい。

　（６ｂ）上記実施形態では、ＣＡＮバス６２上でのダイアグ通信を、図１４の上段に示すように、コマンドに対する車両からの応答を待って１つずつ完結させる交互送信を前提としている。本開示は、交互送信に限定されるものではなく、図１４の下段に示すように、車両からの応答を待たず並列で送信操作（以下、並列送信）を行ってもよい。この場合、トラフィックが許容範囲を超えないように、並列送信できるコマンドの数を調整する必要がある。

　（６ｃ）上記実施形態では、マニュフェストに従って、コマンド管理テーブルに管理情報を追加する際に、「送信待ステータス」の初期値を、周期値に応じた値に設定している。「送信待ステータス」の初期値は、送信候補コマンドが同一ｔｉｃｋに集中しないよう、調整されてもよい。例えば、図１５に示すように、取得周期が３ｔｉｃｋである３個の周期駆動コマンドＣ６～Ｃ８が存在する場合、各周期駆動コマンドＣ６～Ｃ８のそれぞれが、異なるｔｉｃｋで処理されるように、管理情報登録時における「送信待ステータス」の初期値を調整してもよい。

　（６ｄ）上記実施形態では、スケジュール調整処理のＳ１２０において、調整部４８２は、コマンド管理テーブルの「送信ステータス」を参照して、残りｔｉｃｋ数が０に設定されているすべての管理情報、すなわち、次回のｔｉｃｋで処理対象となるすべての管理情報を送信候補コマンドとして抽出している。しかしながら、送信候補コマンドの抽出方法は、これに限定されない。例えば、Ｓ１２０において、調整部４８２は、コマンド管理テーブルの「送信ステータス」を参照して、残りｔｉｃｋ数が１に設定されているすべての管理情報、すなわち、次々回のｔｉｃｋで処理対象となるすべての管理情報を送信候補コマンドとして抽出してもよい。この場合、Ｓ１３０～Ｓ１９０では、今回のスケジュール調整処理におけるＳ１２０で抽出された次々回のｔｉｃｋで処理対象となる送信候補コマンドを絞り込む。そして、Ｓ２００では、残りｔｉｃｋ数が０に設定されている送信候補コマンド、即ち前回のスケジュール調整処理で抽出され絞り込まれた送信候補コマンドを送信対象コマンドとして処理を実行してもよい。

　このスケジュール調整処理を採用する場合、「モード属性」が即時駆動の「送信待ステータス」は、ダイアグ系アプリ４１１からの要求が発生した場合に１以上の所定数に設定されてもよい。同様に、「モード属性」がイベント駆動の「送信待ステータス」は、指定されたトリガ条件を充足した場合に１以上の所定数に設定されてもよい。

　またスケジュール調整処理のＳ１２０において、調整部４８２は、コマンド管理テーブルの「送信待ステータス」を参照して、残りｔｉｃｋ数が１よりも大きい所定ｔｉｃｋ数に設定されているすべての管理情報を送信候補コマンドとして抽出してもよい。Ｓ２００では、調整部４８２は、コマンド管理テーブルの「送信待ステータス」を参照して、残りｔｉｃｋ数が０に設定されている送信候補コマンドを送信対象コマンドとして、処理を行ってもよい。この場合、「モード属性」が即時駆動の「送信待ステータス」は、ダイアグ系アプリ４１１からの要求が発生した場合に所定ｔｉｃｋ数以上の数に設定されてもよい。同様に、「モード属性」がイベント駆動の「送信待ステータス」は、指定されたトリガ条件を充足した場合に所定ｔｉｃｋ数以上の数に設定されてもよい。

　また上記実施形態では、スケジュール調整処理のＳ１２０～Ｓ１９０は、送信周期毎、すなわちｔｉｃｋ毎に実行されるが、複数の送信周期毎、例えば、２ｔｉｃｋ毎に実行されてもよい。この場合、Ｓ１２０において、調整部４８２は、コマンド管理テーブルの「送信待ステータス」を参照して、例えば、残りｔｉｃｋ数が０又は１に設定されているすべての管理情報を、送信候補コマンドとして抽出してもよい。この場合Ｓ１３０～Ｓ１９０では、Ｓ１２０にて抽出された送信候補コマンドを絞り込む。Ｓ２００では、絞り込みによって除外されることなく残ったすべての送信候補コマンドを送信対象コマンドとして、処理を実行してもよい。

　（６ｅ）上記実施形態では、即時駆動は、ダイアグ系アプリからの指示に従って、指定された車両データを「直ちに」１回だけ取得する場合に使用するモードであった。しかしスケジュール調整処理の変形例で説明したように、「モード属性」が即時駆動の「送信待ステータス」は、ダイアグ系アプリ４１１からの要求が発生した場合に０に設定されることに限定されず、１以上の所定ｔｉｃｋ数に設定されてもよい。つまり、車両データを「直ちに」取得する代わりに、限定された時間内に取得するようにしてもよい。この場合、の「モード属性」は、即時駆動の上位概念となるアプリ駆動として把握することができる。アプリ駆動は、アプリケーションプログラムからの要求に応じて車両データ取得するモードである。

　（６ｆ）上記実施形態では、「モード属性」が即時駆動又はイベント駆動の場合に、「送信待ステータス」として設定されるｔｉｃｋ数は、処理を実行するタイミングを示しているが、処理の実行について許容される最も遅いタイミングを表していてもよい。この場合、スケジュール調整処理では、処理負荷に余裕がある場合、残りｔｉｃｋ数が０以外の送信候補コマンドを、送信対象コマンドに加えて処理を行ってもよい。

　（６ｇ）本開示に記載の制御部３１及びその手法は、コンピュータプログラムにより具体化された一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリを構成することによって提供された専用コンピュータにより、実現されてもよい。あるいは、本開示に記載の制御部３１及びその手法は、一つ以上の専用ハードウェア論理回路によってプロセッサを構成することによって提供された専用コンピュータにより、実現されてもよい。もしくは、本開示に記載の制御部３１及びその手法は、一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリと一つ以上のハードウェア論理回路によって構成されたプロセッサとの組み合わせにより構成された一つ以上の専用コンピュータにより、実現されてもよい。また、コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体に記憶されてもよい。制御部３１に含まれる各部の機能を実現する手法には、必ずしもソフトウェアが含まれている必要はなく、その全部の機能が、一つあるいは複数のハードウェアを用いて実現されてもよい。

　（６ｈ）上記実施形態における１つの構成要素が有する複数の機能を、複数の構成要素によって実現したり、１つの構成要素が有する１つの機能を、複数の構成要素によって実現したりしてもよい。また、複数の構成要素が有する複数の機能を、１つの構成要素によって実現したり、複数の構成要素によって実現される１つの機能を、１つの構成要素によって実現したりしてもよい。また、上記実施形態の構成の一部を省略してもよい。また、上記実施形態の構成の少なくとも一部を、他の上記実施形態の構成に対して付加又は置換してもよい。

　（６ｉ）上述した車載機３０の他、当該車載機３０を構成要素とするシステム、当該車載機３０としてコンピュータを機能させるためのプログラム、このプログラムを記録した半導体メモリ等の非遷移的実体的記録媒体、データ提供方法など、種々の形態で本開示を実現することもできる。

　［７．本明細書が開示する技術思想］
　［項目１］
　車両データの取得に用いるコマンドを、車載ネットワークに送信する送信処理を繰り返し実行するように構成されたデータ取得部（４４，４５）と、
　前記データ取得部にて取得される前記車両データを利用する１つ以上のアプリケーションプログラムを実行するように構成されたアプリ実行部（４１）と、
　前記車両データの取得に用いる前記コマンドの種類、前記車両データの要求元となる前記アプリケーションプログラムである要求元アプリ、及び前記車両データの取得条件が示された１つ以上の管理情報を用いて、前記取得条件を満たす前記管理情報が示す前記コマンドを、前記送信処理にて送信対象となる前記コマンドである送信対象コマンドとして抽出すると共に、前記送信対象コマンドと前記要求元アプリとを対応づけたルーティング情報を生成するように構成されたスケジュール管理部（４８）と、
　前記データ取得部が前記送信処理を実行することによって取得された前記車両データを、前記ルーティング情報を用いて前記要求元アプリに提供するように構成されたルーティング部（４３）と、
　を備える車載機。

　［項目２］
　項目１に記載の車載機であって、
　前記データ取得部は、前記送信処理を予め設定された実行周期で繰り返し実行するように構成され、
　前記スケジュール管理部は、前記取得条件を満たす前記管理情報が示す前記コマンドを、次回以降の実行周期にて送信対象となる前記コマンドである前記送信対象コマンドとして抽出するように構成された
　車載機。

　［項目３］
　項目１又は項目２に記載の車載機であって、
　前記スケジュール管理部は、前記アプリケーションプログラムに紐づけられ、前記アプリケーションプログラムが要求する前記車両データの種類、及び前記車両データの取得条件が記述されたマニュフェストを、前記アプリケーションプログラムの配布元から取得し、前記マニュフェストに従って、前記管理情報を生成するように構成された、
　車載機。

　［項目４］
　項目３に記載の車載機であって、
　前記マニュフェストは、前記車両データの取得条件を指定する方法として、一定周期で繰り返し取得する周期駆動、前記アプリケーションプログラムからの要求に応じて取得するアプリ駆動、及び指定したイベントが発生したときに取得するイベント駆動を含む
　車載機。

　［項目５］
　項目３又は項目４に記載の車載機であって、
　前記マニュフェストは、前記車両データの種類を指定する方法として、前記車両データの意味を表す規格化された名称で指定する名称指定、及び前記車載ネットワークで送受信される形式で指定するコマンド指定を含む
　車載機。

　［項目６］
　項目３から項目５までのいずれか１項に記載の車載機であって、
　当該車載機が接続された車両の前記車載ネットワークから受信したフレームを解釈するための情報、及び前記車両にて使用可能な前記コマンドの一覧を示した情報を含む周辺情報を、前記車両の外部に設けられたサーバとの無線通信によって取得する周辺情報取得部（４９）を更に備え、
　前記データ取得部は、前記マニュフェストに基づく前記管理情報を、前記周辺情報を用いて前記車載ネットワークで送信可能な形式に変換し、前記車載ネットワークからの応答を、前記周辺情報を用いて解釈するように構成された
　車載機。

　［項目７］
　項目１から項目６までのいずれか１項に記載の車載機であって、
　前記スケジュール管理部は、前記１つ以上の管理情報から抽出されるすべての前記送信対象コマンドを前記送信処理で送信すると、前記車載ネットワークが負荷超過となる可能性がある場合、前記負荷超過が生じないように、前記送信対象コマンドの一部を、当該送信処理の処理対象から除外するように構成された、
　車載機。

　［項目８］
　項目７に記載の車載機であって、
　前記スケジュール管理部は、前記車載ネットワークのトラフィックが許容値を超える場合を、前記負荷超過と判定するように構成された、
　車載機。

　［項目９］
　項目２を引用する項目７に記載の車載機であって、
　前記スケジュール管理部は、前記送信対象コマンドのターンアラウンド時間の合計値が、前記実行周期の周期を超える場合を、前記負荷超過と判定するように構成された、
　車載機。

　［項目１０］
　項目９に記載の車載機であって、
　当該車載機の起動時に前記ターンアラウンド時間を測定する
　車載機。

　［項目１１］
　項目９又は項目１０に記載の車載機であって、
　当該車載機に接続されるハードウェアの構成、又は前記アプリ実行部にて実行される前記アプリケーションプログラムの構成に変更がある場合に、前記ターンアラウンド時間を測定する
　車載機。

　［項目１２］
　項目２を引用する項目７から項目１１までのいずれか１項に記載の車載機であって、
　前記スケジュール管理部は、前記送信対象コマンドから除外された前記管理情報が、当該送信対象コマンドから除外された前記実行周期よりも後の実行周期で、前記送信対象コマンドとして抽出されるように前記管理情報を調整するように構成された、
　車載機。

　［項目１３］
　項目７から項目１２までのいずれか１項に記載の車載機であって、
　前記管理情報には、前記コマンドの送信に関する優先度が含まれ、
　前記スケジュール管理部は、前記負荷超過と判定した場合、前記送信対象コマンドの中で、前記優先度が最低であるか、又は前記優先度が除外可しきい値以下である前記管理情報を除外するように構成された、
　車載機。

　［項目１４］
　項目１３に記載の車載機であって、
　前記優先度は、前記コマンドによって取得される前記車両データのデータ種別に応じて設定される
　車載機。

　［項目１５］
　項目１３又は項目１４に記載の車載機であって、
　前記優先度は、前記コマンドによって取得される前記車両データの取得条件に応じて設定される
　車載機。

　［項目１６］
　項目１から項目１５までのいずれか１項に記載の車載機であって、
　前記データ取得部が取得する前記車両データには、車速、総走行距離、車体加速度、車体角速度、ＧＰＳ位置情報、ギアポジション、バッテリ充電状態、燃料タンク容量、残燃料量、平均燃料消費量、ライト点灯状態、車室内外温度、エアコン作動状況、ドア・ウィンドウ開閉状態、ドア・ウィンドウロック状態、シートベルト状態、エアバッグ状態、タイヤ空気圧、パーキングプレーキ状態、アクセルペダルポジション、ブレーキペダルポジション、ブレーキ圧力、故障診断コードリストのうち、少なくとも１つが含まれる
　車載機。

　［項目１７］
　項目１から項目１６までのいずれか１項に記載の車載機であって、
　当該車載機は、車両に設けられたダイアグポート（６１）を介して前記車載ネットワークに接続され、
　前記データ取得部は、前記コマンドとして、ダイアグ通信で使用されるダイアグコマンドを用いるように構成された、
　車載機。

Claims (19)

1. 　車両データの取得に用いるコマンドを、車載ネットワークに送信する送信処理を実行するように構成されたデータ取得部（４４，４５）と、
   　前記データ取得部にて取得される前記車両データを利用する１つ以上のアプリケーションプログラムを実行するように構成されたアプリ実行部（４１）と、
   　前記車両データの取得に用いる前記コマンドの種類、前記車両データの要求元となる前記アプリケーションプログラムである要求元アプリ、及び前記車両データの取得条件が示された１つ以上の管理情報を用いて、前記取得条件を満たす前記管理情報が示す前記コマンドを、前記送信処理にて送信対象となる前記コマンドである送信対象コマンドとして抽出すると共に、前記送信対象コマンドと前記要求元アプリとを対応づけたルーティング情報を生成するように構成されたスケジュール管理部（４８）と、
   　前記データ取得部が前記送信処理を実行することによって取得された前記車両データを、前記ルーティング情報を用いて前記要求元アプリに提供するように構成されたルーティング部（４３）と、
   　を備える車載機。
2. 　請求項１に記載の車載機であって、
   　前記データ取得部は、前記送信処理を予め設定された実行周期で繰り返し実行するように構成され、
   　前記スケジュール管理部は、前記取得条件を満たす前記管理情報が示す前記コマンドを、次回以降の実行周期にて送信対象となる前記コマンドである前記送信対象コマンドとして抽出するように構成された
   　車載機。
3. 　請求項１又は請求項２に記載の車載機であって、
   　前記スケジュール管理部は、前記アプリケーションプログラムに紐づけられ、前記アプリケーションプログラムが要求する前記車両データの種類、及び前記車両データの取得条件が記述されたマニュフェストを、前記アプリケーションプログラムの配布元から取得し、前記マニュフェストに従って、前記管理情報を生成するように構成された、
   　車載機。
4. 　請求項３に記載の車載機であって、
   　前記マニュフェストは、前記車両データの取得条件を指定する方法として、一定周期で繰り返し取得する周期駆動、前記アプリケーションプログラムからの要求に応じて取得するアプリ駆動、及び指定したイベントが発生したときに取得するイベント駆動を含む
   　車載機。
5. 　請求項３に記載の車載機であって、
   　前記マニュフェストは、前記車両データの種類を指定する方法として、前記車両データの意味を表す規格化された名称で指定する名称指定、及び前記車載ネットワークで送受信される形式で指定するコマンド指定を含む
   　車載機。
6. 　請求項３に記載の車載機であって、
   　当該車載機が接続された車両の前記車載ネットワークから受信したフレームを解釈するための情報、及び前記車両にて使用可能な前記コマンドの一覧を示した情報を含む周辺情報を、前記車両の外部に設けられたサーバとの無線通信によって取得する周辺情報取得部（４９）を更に備え、
   　前記データ取得部は、前記マニュフェストに基づく前記管理情報を、前記周辺情報を用いて前記車載ネットワークで送信可能な形式に変換し、前記車載ネットワークからの応答を、前記周辺情報を用いて解釈するように構成された
   　車載機。
7. 　請求項１又は請求項２に記載の車載機であって、
   　前記スケジュール管理部は、前記１つ以上の管理情報から抽出されるすべての前記送信対象コマンドを前記送信処理で送信すると、前記車載ネットワークが負荷超過となる可能性がある場合、前記負荷超過が生じないように、前記送信対象コマンドの一部を、当該送信処理の処理対象から除外するように構成された、
   　車載機。
8. 　請求項７に記載の車載機であって、
   　前記スケジュール管理部は、前記車載ネットワークのトラフィックが許容値を超える場合を、前記負荷超過と判定するように構成された、
   　車載機。
9. 　請求項２を引用する請求項７に記載の車載機であって、
   　前記スケジュール管理部は、前記送信対象コマンドのターンアラウンド時間の合計値が、前記実行周期を超える場合を、前記負荷超過と判定するように構成された、
   　車載機。
10. 　請求項９に記載の車載機であって、
    　当該車載機の起動時に前記ターンアラウンド時間を測定する
    　車載機。
11. 　請求項９に記載の車載機であって、
    　当該車載機に接続されるハードウェアの構成、又は前記アプリ実行部にて実行される前記アプリケーションプログラムのソフトウェア構成に変更がある場合に、前記ターンアラウンド時間を測定する
    　車載機。
12. 　請求項２を引用する請求項７に記載の車載機であって、
    　前記スケジュール管理部は、前記送信対象コマンドから除外された前記管理情報が、当該送信対象コマンドから除外された前記実行周期よりも後の実行周期で、前記送信対象コマンドとして抽出されるように前記管理情報を調整するように構成された、
    　車載機。
13. 　請求項７に記載の車載機であって、
    　前記管理情報には、前記コマンドの送信に関する優先度が含まれ、
    　前記スケジュール管理部は、前記負荷超過と判定した場合、前記送信対象コマンドの中で、前記優先度が最低であるか、又は前記優先度が除外可しきい値以下である前記管理情報を除外するように構成された、
    　　車載機。
14. 　請求項１３に記載の車載機であって、
    　前記優先度は、前記コマンドによって取得される前記車両データのデータ種別に応じて設定される
    　車載機。
15. 　請求項１３に記載の車載機であって、
    　前記優先度は、前記コマンドによって取得される前記車両データの前記取得条件に応じて設定される
    　車載機。
16. 　請求項１に記載の車載機であって、
    　前記データ取得部が取得する前記車両データには、車速、総走行距離、車体加速度、車体角速度、ＧＰＳ位置情報、ギアポジション、バッテリ充電状態、燃料タンク容量、残燃料量、平均燃料消費量、ライト点灯状態、車室内外温度、エアコン作動状況、ドア・ウィンドウ開閉状態、ドア・ウィンドウロック状態、シートベルト状態、エアバッグ状態、タイヤ空気圧、パーキングプレーキ状態、アクセルペダルポジション、ブレーキペダルポジション、ブレーキ圧力、故障診断コードリストのうち、少なくとも１つが含まれる
    　車載機。
17. 　請求項１に記載の車載機であって、
    　当該車載機は、車両に設けられたダイアグポート（６１）を介して前記車載ネットワークに接続され、
    　前記データ取得部は、前記コマンドとして、ダイアグ通信で使用されるダイアグコマンドを用いるように構成された、
    　車載機。
18. 　車両データの取得に用いるコマンドを、車載ネットワークに送信する送信処理を実行し、前記送信処理によって取得される前記車両データを１つ以上のアプリケーションプログラムに提供する車載機において、前記車両データを前記車両データの要求元となる前記アプリケーションプログラムである要求元アプリに提供するデータ提供方法であって、
    　前記車両データの取得に用いる前記コマンドの種類、前記要求元アプリ、及び前記車両データの取得条件が示された１つ以上の管理情報を用いて、前記取得条件を満たす前記管理情報が示す前記コマンドを、前記送信処理にて送信対象となる前記コマンドである送信対象コマンドとして抽出すると共に、前記送信対象コマンドと前記要求元アプリとを対応づけたルーティング情報を生成し、
    　前記送信処理を実行することによって取得された前記車両データを、前記ルーティング情報を用いて前記要求元アプリに提供する、
    　データ提供方法。
19. 　車両データの取得に用いるコマンドを、車載ネットワークに送信する送信処理を実行し、前記送信処理によって取得される前記車両データを１つ以上のアプリケーションプログラムに提供する車載機において実行され、前記車両データを前記車両データの要求元となる前記アプリケーションプログラムである要求元アプリに提供するプログラムであって、
    　前記車載機に、
    　前記車両データの取得に用いる前記コマンドの種類、前記要求元アプリ、及び前記車両データの取得条件が示された１つ以上の管理情報を用いて、前記取得条件を満たす前記管理情報が示す前記コマンドを、前記送信処理にて送信対象となる前記コマンドである送信対象コマンドとして抽出すると共に、前記送信対象コマンドと前記要求元アプリとを対応づけたルーティング情報を生成する処理と、
    　前記送信処理を実行することによって取得された前記車両データを、前記ルーティング情報を用いて前記要求元アプリに提供する処理と、を実行させるプログラム。

Images