特開 2024-77173 車両監視装置

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

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

(11)【公開番号】P2024077173

(43)【公開日】2024-06-07

(54)【発明の名称】車両監視装置

(51)【国際特許分類】

   G06F 11/07 20060101AFI20240531BHJP

   G06F 11/34 20060101ALI20240531BHJP

【ＦＩ】

G06F11/07 178

G06F11/07 140R

G06F11/34 176

【審査請求】未請求

【請求項の数】7

【出願形態】ＯＬ

(21)【出願番号】P 2022189072

(22)【出願日】2022-11-28

(71)【出願人】

【識別番号】000003207

【氏名又は名称】トヨタ自動車株式会社

(71)【出願人】

【識別番号】000004260

【氏名又は名称】株式会社デンソー

(74)【代理人】

【識別番号】100105957

【弁理士】

【氏名又は名称】恩田 誠

(74)【代理人】

【識別番号】100068755

【弁理士】

【氏名又は名称】恩田 博宣

(72)【発明者】

【氏名】菅原 慎之介

(72)【発明者】

【氏名】松井 健

(72)【発明者】

【氏名】稲垣 徳也

(72)【発明者】

【氏名】渡邊 聖剛

(72)【発明者】

【氏名】村上 亮介

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

5B042

【Ｆターム（参考）】

5B042GB08

5B042KK07

5B042MA08

5B042MA09

5B042MC40

(57)【要約】

【課題】車両で発生する不特定の異常を監視可能とする。
【解決手段】車両監視装置１０のプロセッサ１１は、車載装置で発生したイベントのログ情報を取得することと、取得したログ情報に基づいて診断の要否を判定することと、診断要と判定した場合に診断データを外部のサーバ２６に送信することと、を行う。プロセッサ１１がサーバ２６に送信する診断データには、診断要との判定したログ情報と、診断要との判定前後に取得したログ情報と、が含まれる。
【選択図】図１

【特許請求の範囲】

【請求項1】

車両に搭載される車両監視装置であって、
車載装置で発生したイベントのログ情報を取得することと、
取得したログ情報に基づいて診断の要否を判定することと、
診断要と判定した場合に診断データを外部のサーバに送信することと、
を行うプロセッサを有しており、
前記診断データには、診断要との判定したログ情報と、診断要との判定前に取得したログ情報と、が含まれる
車両監視装置。

【請求項2】

前記診断データには、診断要と判定後に取得したログ情報が含まれる請求項１に記載の車両監視装置。

【請求項3】

前記プロセッサは、診断要との判定が２回行われ、かつ１回目の判定に応じて前記サーバに送信すべき第１の診断データと、２回目の判定に応じて前記サーバに送信すべき第２の診断データと、に重複するログ情報が含まれる状態となる場合、前記第１の診断データと前記第２の診断データをマージした単一の診断データを前記サーバに送信する請求項２に記載の車両監視装置。

【請求項4】

前記診断データは、既定期間に取得したログ情報の集合であり、前記既定期間は、診断要と判定したログ情報の取得時を基準に設定されている請求項１に記載の車両監視装置。

【請求項5】

前記プロセッサは、取得したログ情報が示すイベントの発生パターンが、複数のパターンのいずれかにマッチする場合に診断要と判定し、かつマッチしたパターンにより前記既定期間を変更する請求項４に記載の車両監視装置。

【請求項6】

前記診断データは、イベントの発生順序が連続した既定数のログ情報の集合である請求項１に記載の車両監視装置。

【請求項7】

前記プロセッサは、取得したログ情報が示すイベントの発生パターンが、複数のパターンのいずれかにマッチする場合に診断要と判定し、かつマッチしたパターンにより前記既定数を変更する請求項６に記載の車両監視装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、車両に搭載される車両監視装置に関する。

【背景技術】

【0002】

上記のような車両監視装置として、特許文献１に記載のシステムが知られている。この文献の車両監視装置は、車載装置で発生したイベントのログ情報を取得して診断の要否を判定する。そして、この車両監視装置は、診断要と判定したイベントのログ情報を外部のサーバに送信する。サーバは、受信したログ情報に基づいて、異常の有無を診断する。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２０２２－５５５５８号公報

【発明の概要】

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

【0004】

サイバー攻撃等の不特定の脅威による異常を監視の対象に含める場合、異常の疑いがあると判定されたイベントのログ情報だけでは、サーバが異常の有無を的確に診断できない場合がある。

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

【0005】

上記課題を解決する車両監視装置は、車両に搭載される。同車両監視装置は、車載装置で発生したイベントのログ情報を取得することと、取得したログ情報に基づいて診断の要否を判定することと、診断要と判定した場合に診断データを外部のサーバに送信することと、を行うプロセッサを有している。診断データには、診断データには、診断要との判定したログ情報と、診断要との判定前に取得したログ情報と、が含まれている。

【0006】

不特定の脅威による車載装置の異常を監視の対象に含める場合、異常時に発生するイベントが不明確であるため、診断要と判定したイベントのログ情報だけでは、異常を的確に診断できない場合がある。異常時には、診断要と判定する前にも、不特定の脅威による異常時には、診断要と判定したログ情報の取得前にも、異常の兆候となるイベントが発生している場合がある。そのため、不特定の脅威により異常についても、異常の有無や種別を診断できる可能性が高くなる。したがって、上記車両監視装置には、既知ではない不特定の異常も監視できるようにするという効果がある。

【図面の簡単な説明】

【0007】

【図1】第１実施形態の車両監視装置の構成を模式的に示す図である。

【図2】同実施形態の車両監視装置が実行する監視ルーチンのフローチャートである。

【図3】第２実施形態の車両監視装置が実行する監視ルーチンのフローチャートである。

【図4】車両監視装置の変更例が実行する監視ルーチンのフローチャートである。

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

【0008】

（第１実施形態）
以下、車両監視装置の第１実施形態を、図１及び図２を参照して詳細に説明する。
＜車両監視装置の構成＞
図１に示すように、本実施形態の車両監視装置１０を搭載した車両２０は、複数の電子制御ユニット２２が車載装置として設けられている。電子制御ユニット２２は、車両２０が有する車載コンピュータであり、プログラムを実行することで所定の機能を実現する。複数の電子制御ユニット２２には、例えばエンジン制御機能を有する電子制御ユニット、変速制御機能を有する電子制御ユニット、操舵制御機能を有する電子制御ユニット、ブレーキ制御機能を有する電子制御ユニットが含まれる。各電子制御ユニット２２は、車載ネットワーク２１に接続されている。

【0009】

車両監視装置１０は、車載ネットワーク２１に接続されており、各電子制御ユニット２２と相互にデータを送受信することが可能である。車両監視装置１０は、プロセッサ１１とストレージ１２とを備えている。プロセッサ１１は、プログラムを実行することで、車載装置の監視機能を実現する。ストレージ１２は、監視に用いるデータを記憶する記憶装置である。

【0010】

各電子制御ユニット２２には、セキュリティセンサ２３が設置されている。セキュリティセンサ２３は、設置された電子制御ユニット２２において、異常の兆候となるイベントの発生を検知する。そして、セキュリティセンサ２３は、そうしたイベントを検知すると、同イベントのログ情報を生成して車両監視装置１０に送信する。ここでの異常には、車外からのサイバー攻撃により生じた異常が含まれる。イベントには、電子制御ユニット２２が実行したプロセス、他の車載装置や車外の装置とのアクセス等が含まれる。セキュリティセンサ２３が車両監視装置１０に送信するログ情報には、イベントの種別を示す情報が含まれる。

【0011】

また、車両監視装置１０は、無線通信装置２４に接続されている。無線通信装置２４は、移動体通信サービス等の無線通信網２５を介して車外の装置との無線通信を行う装置である。無線通信装置２４は、無線通信網２５を介した、外部のデータセンタに設置されたサーバ２６と車両監視装置１０とのデータの送受信を実現する。

【0012】

＜車載装置の監視動作＞
次に、車両監視装置１０による車両２０の監視動作について説明する。
図２に、車両監視装置１０のプロセッサ１１が実行する監視ルーチンのフローチャートを示す。プロセッサ１１は、各電子制御ユニット２２のセキュリティセンサ２３からログ情報を受信する毎に、同ルーチンを実行する。

【0013】

本ルーチンを開始すると、プロセッサ１１は、まずステップＳ１００において、受信したログ情報をストレージ１２に格納する。プロセッサ１１は、ログ情報の取得順に値が大きくなる通し番号を、ログ情報の識別子であるＩＤ番号として設定している。そして、プロセッサ１１は、車載装置から受信したログ情報と共に、そのログ情報のＩＤ番号及び取得時刻をストレージ１２に格納する。

【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】

１０ 車両監視装置
１１ プロセッサ
１２ ストレージ
２０ 車両
２１ 車載ネットワーク
２２ 電子制御ユニット（車載装置）
２３ セキュリティセンサ
２４ 無線通信装置
２５ 無線通信網
２６ サーバ

【図1】

【図2】

【図3】

【図4】