JP2023016844A - 不正検知サーバ、および、制御方法 - Google Patents

Abstract

【課題】不正な車両がアップロードするフレームを改ざんしたとしても、不正な車両を検知することを支援する。【解決手段】車両監視装置Ａ１は、対象車両を特定する特定情報をサーバから受信する第一通信部Ａ１１と、第一通信部Ａ１１が受信した特定情報により特定される対象車両の走行に関わる情報である走行情報を、対象車両から取得する取得部Ａ１２とを備え、第一通信部Ａ１１は、取得部Ａ１２が取得した走行情報をサーバに送信する。例えば、取得部Ａ１２は、対象車両から通信によって得られた走行情報を取得してもよい。【選択図】図１８

Description

本発明は、不正検知サーバ、および、制御方法に関する。

近年、自動車の中のシステムには、電子制御ユニット（以下、ＥＣＵ）と呼ばれる装置が多数配置されている。これらのＥＣＵをつなぐネットワークを車載ネットワークと呼ばれる。車載ネットワークには、多数の規格が存在するが、その中でも最も主流な車載ネットワークの一つに、Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ（以降、ＣＡＮともいう）という規格が存在する。

ＣＡＮでは、不正なフレームが送信されるようなケースを想定したセキュリティ機能が存在しないため、不正なノードが勝手にＣＡＮのバスに接続し、不正にフレームを送信することで、車両を不正にコントロールしてしまうことが可能である。

特許文献１は、車載ネットワークに送信されたフレームに関する情報を、不正検知サーバにアップロードすることで、車載ネットワークにおいて送信されたフレームの異常度を算出する方法を開示している。

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

しかしながら、特許文献１の方法では、不正な車両がアップロードするフレームを改ざんした場合に、不正検知サーバは、その不正な車両を検知することが難しい。また、その不正な車両を不正検知サーバが検知したとしても、フレームの改ざんによって実際にどのような影響が発生しているのかを正確に把握することは困難である。そのため、不正検知サーバは、その影響の良否、又は、その影響の大きさに応じた対処をすることができないという問題がある。

そこで、本発明は、不正な車両がアップロードするフレームを改ざんしたとしても、不正な車両を検知することを支援する不正検知サーバなどを提供する。

本発明の一態様に係る不正検知サーバは、対象車両の車載ネットワークで受信されたフレームの情報である第一走行情報を受信する第一通信部と、複数の車両又は路側機の現在位置を示す位置情報を保持している保持部と、（ａ）前記複数の車両又は路側機のうち、前記対象車両から所定距離以内の範囲に存在する１以上の車両又は路側機を、前記位置情報を参照して特定し、特定した前記１以上の車両又は路側機に対して、前記対象車両の状態を示す第二走行情報を取得する要求の通知を送信し、（ｂ）前記１以上の車両又は路側機から前記第二走行情報を受信する、第二通信部と、前記第一走行情報と前記第二走行情報の整合性を判定する判断部と、前記判断部において、不整合が発生している場合に、前記不整合の通知をする通知部とを備える不正検知サーバである。

なお、これらの包括的または具体的な態様は、システム、方法、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ－ＲＯＭなどの記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。

本発明の不正検知サーバは、不正な車両がアップロードするフレームを改ざんしたとしても、不正な車両を検知することを支援できる。

図１は、実施の形態における、車載ネットワーク監視システムの全体構成を示す図である。 図２は、実施の形態における、車載ネットワークシステムの全体構成を示す図である。 図３は、実施の形態における、不正検知サーバの構成を示す図である。 図４Ａは、実施の形態における、ゲートウェイの構成を示す図である。 図４Ｂは、実施の形態における、路側機の構成を示す図である。 図５は、実施の形態における、不正検知サーバの処理を示す第一のフロー図である。 図６は、実施の形態における、不正検知サーバの処理を示す第二のフロー図である。 図７は、実施の形態における、ゲートウェイの処理を示す第一のフロー図である。 図８は、実施の形態における、ゲートウェイの処理を示す第二のフロー図である。 図９は、実施の形態における、通信によって通信ログを取得する場合のシーケンス図である。 図１０は、実施の形態における、カメラによる撮影によって通信ログを取得する場合のシーケンス図である。 図１１は、実施の形態における、センサによるセンシングによって通信ログを取得する場合のシーケンス図である。 図１２は、実施の形態における、ドライバからセンシングによって通信ログを取得する場合のシーケンス図である。 図１３は、実施の形態における、車載ネットワーク監視システムの第一の動作例を示す説明図である。 図１４は、実施の形態における、車載ネットワーク監視システムの第二の動作例を示す説明図である。 図１５は、実施の形態における、監視ログによる優先度を決定するための条件を示す説明図である。 図１６は、実施の形態における、車載ネットワーク監視システムの第三の動作例を示す説明図である。 図１７は、実施の形態における、車両ログと監視ログとの一例を示す説明図である。 図１８は、実施の形態の変形例における車両監視装置の機能構成を示すブロック図である。 図１９は、実施の形態の変形例における不正検知サーバの機能構成を示すブロック図である。 図２０は、実施の形態の変形例における車両監視装置の制御方法を示すフロー図である。 図２１は、実施の形態の変形例における不正検知サーバの制御方法を示すフロー図である。

本発明の一態様に係る不正検知サーバは、対象車両の車載ネットワークで受信されたフレームの情報である第一走行情報を受信する第一通信部と、複数の車両又は路側機の現在位置を示す位置情報を保持している保持部と、（ａ）前記複数の車両又は路側機のうち、前記対象車両から所定距離以内の範囲に存在する１以上の車両又は路側機を、前記位置情報を参照して特定し、特定した前記１以上の車両又は路側機に対して、前記対象車両の状態を示す第二走行情報を取得する要求の通知を送信し、（ｂ）前記１以上の車両又は路側機から前記第二走行情報を受信する、第二通信部と、前記第一走行情報と前記第二走行情報の整合性を判定する判断部と、前記判断部において、不整合が発生している場合に、前記不整合の通知をする通知部とを備える不正検知サーバである。

また、本発明の一態様に係る車両監視装置は、対象車両を特定する特定情報をサーバから受信する第一通信部と、前記第一通信部が受信した前記特定情報により特定される前記対象車両の走行に関わる情報である走行情報を、前記対象車両から取得する取得部とを備え、前記第一通信部は、前記取得部が取得した前記走行情報を前記サーバに送信する。

上記態様によれば、車両監視装置は、サーバから得た特定情報により特定される対象車両の走行情報を対象車両から取得してサーバに送信する。そのため、対象車両がサーバにアップロードしたフレームが改ざんされていたとしても、車両監視装置がサーバに送信した対象車両の走行情報によって、サーバが対象車両の不正を検知し得る。よって、車両監視装置は、不正な車両がアップロードするフレームを改ざんしたとしても、不正な車両を検知することを支援できる。

例えば、前記取得部は、前記対象車両から通信によって得られた前記走行情報を取得してもよい。

上記態様によれば、車両監視装置は、特定車両との通信によって得られた走行情報を取得する。よって、車両監視装置は、より容易に対象車両の走行情報を得ることによって、不正な車両がアップロードするフレームを改ざんしたとしても不正な車両を検知することを支援できる。

例えば、前記取得部は、前記対象車両に対するセンシングによって得られた前記走行情報を取得してもよい。

上記態様によれば、車両監視装置は、特定車両に対するセンシングによって得られた走行情報を取得する。よって、車両監視装置は、より容易に対象車両の走行情報を得ることによって、不正な車両がアップロードするフレームを改ざんしたとしても不正な車両を検知することを支援できる。

例えば、前記車両監視装置は、さらに、前記通信によって得られた前記走行情報である第一走行情報と、前記センシングによって得られた前記走行情報である第二走行情報とが整合するか否かを判定する判定部を備え、前記第一通信部は、前記第一走行情報と前記第二走行情報とが整合しないと前記判定部が判定した場合にのみ、前記第一走行情報と前記第二走行情報とを前記サーバに送信してもよい。

上記態様によれば、車両監視装置は、通信によって取得した対象車両の走行情報と、センシングによって取得した対象車両の走行情報とが整合しない場合のみサーバに走行情報を送信するので、サーバへ送信する通信量が抑制される。よって、車両監視装置は、サーバへの通信量を抑制しながら、不正な車両がアップロードするフレームを改ざんしたとしても不正な車両を検知することを支援できる。

例えば、前記車両監視装置は、車両に搭載され、前記取得部は、前記車両のドライバに前記対象車両の走行状態を問いかけるための質問情報を提示し、提示した前記質問情報に対して前記ドライバからセンシングによって取得した回答情報に基づいて、前記走行情報を取得してもよい。

上記態様によれば、車両監視装置は、対象車両の走行状態についてのドライバによる判断の結果をセンシングにより取得する。よって、車両監視装置は、より多くの情報源から得られた対象車両の走行情報を用いて、不正な車両がアップロードするフレームを改ざんしたとしても不正な車両を検知することを支援できる。

例えば、前記対象車両の走行情報は、前記対象車両の速度を示す速度情報を含んでもよい。

上記態様によれば、車両監視装置は、特に対象車両の速度に関する不正を検知し得る。よって、車両監視装置は、不正な車両が、特に速度について改ざんしたフレームをアップロードしたとしても、不正な車両を検知することを支援できる。

また、本発明の一態様に係る不正検知サーバは、対象車両の走行に関わる情報である第一走行情報を受信する第一通信部と、複数の車両の現在位置を示す位置情報を保持している保持部と、（ａ）前記対象車両から受信した前記第一走行情報に異常を検知したときに、前記複数の車両のうち、前記対象車両から所定距離以内の範囲に存在する１以上の車両を前記位置情報を参照して特定し、特定した前記１以上の車両が備える車両監視装置に対して、前記対象車両の走行に関わる第二走行情報を取得する要求の通知を送信し、（ｂ）前記１以上の車両が備える車両監視装置から前記第二走行情報を受信する、第二通信部と、前記第一走行情報と前記第二走行情報とから、前記異常が優先的に分析されるべき度合いを示す優先度を決定し、前記優先度が高い前記異常ほど、より優先的に、前記異常の通知をする通知部とを備える。

上記態様によれば、不正検知サーバは、対象車両から所定距離以内に存在する車両の車両監視装置に対して、その対象車両から走行状態を取得させる。そのため、対象車両がサーバにアップロードしたフレームが改ざんされていたとしても、車両監視装置がサーバに送信した対象車両の走行情報によって、サーバが対象車両の不正を検知し得る。よって、不正検知サーバは、不正な車両がアップロードするフレームを改ざんしたとしても、不正な車両を検知することができる。

例えば、前記通知部は、前記第一走行情報と前記第二走行情報とが整合しないと判定した場合に、前記第一走行情報について検知された前記異常に、より高い前記優先度を決定してもよい。

上記態様によれば、不正検知サーバは、通信によって取得した対象車両の走行情報と、センシングによって取得した対象車両の走行情報とが整合しない場合に、より優先的にその異常をアナリストなどに通知する。よって、上記の２つの走行情報が整合しない場合に必要な対策をより優先的に、アナリストなどに実行させることができる。

また、本発明の一態様に係る車両監視装置の制御方法は、対象車両を特定する特定情報をサーバから受信し、受信した前記特定情報により特定される前記対象車両の走行に関わる情報である走行情報を、前記対象車両から取得し、取得した前記走行情報を前記サーバに送信する。

上記態様によれば、上記の車両監視装置と同様の効果を奏する。

また、本発明の一態様に係る不正検知サーバの制御方法は、不正検知サーバの制御方法であって、対象車両の車載ネットワークで受信されたフレームの情報である第一走行情報を受信し、複数の車両又は路側機の現在位置を示す位置情報を保持し、前記複数の車両又は路側機のうち、前記対象車両から所定距離以内の範囲に存在する１以上の車両又は路側機を前記位置情報を参照して特定し、特定した前記１以上の車両又は路側機に対して、前記対象車両の状態を示す第二走行情報を取得する要求の通知を送信し、前記１以上の車両又は路側機から前記第二走行情報を受信し、前記第一走行情報と前記第二走行情報の整合性を判定し、不整合が発生している場合に、前記不整合の通知をする。

また、本発明の一態様に係る不正検知サーバの制御方法は、不正検知サーバの制御方法であって、対象車両の走行に関わる情報である第一走行情報を受信し、複数の車両の現在位置を示す位置情報を保持し、前記対象車両から受信した前記第一走行情報に異常を検知したときに、前記複数の車両のうち、前記対象車両から所定距離以内の範囲に存在する１以上の車両を前記位置情報を参照して特定し、特定した前記１以上の車両が備える車両監視装置に対して、前記対象車両の走行に関わる第二走行情報を取得する要求の通知を送信し、前記１以上の車両が備える車両監視装置から前記第二走行情報を受信し、前記第一走行情報と前記第二走行情報とから、前記異常が優先的に分析されるべき度合いを示す優先度を決定し、前記優先度が高い前記異常ほど、より優先的に、前記異常の通知をする。

上記態様によれば、上記の不正検知サーバと同様の効果を奏する。

なお、これらの包括的または具体的な態様は、システム、方法、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ－ＲＯＭなどの記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラムまたは記録媒体の任意な組み合わせで実現されてもよい。

以下、実施の形態について、図面を参照しながら具体的に説明する。

なお、以下で説明する実施の形態は、いずれも包括的または具体的な例を示すものである。以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置位置及び接続形態、ステップ、ステップの順序などは、一例であり、本発明を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素については、任意の構成要素として説明される。

（実施の形態）
以下、複数の電子制御ユニット（ＥＣＵ）がＣＡＮバスを介して通信する車載ネットワーク（車載ネットワークシステム）を搭載した複数台の車両と、サーバ（不正検知サーバ）とを、含む不正車両監視システムについて説明する。

この不正車両監視システムは、不正な車両がアップロードするフレームを改ざんしたとしても、不正な車両を検知することを支援する車両監視装置を含む。

［１．１ 不正車両監視システムの全体構成］
図１は、本実施の形態に関わる不正車両監視システムの全体構成を示す図である。

図１に示されるように、不正車両監視システムは、不正検知サーバ８０と、路側機９０と、車両１０１０ａ、１０１０ｂ、１０１０ｃ、１０１０ｄ、１０１０ｅ及び１０１０ｆとが、通信路であるネットワーク８１で接続されて構成される。

ネットワーク８１は、インターネットあるいは、専用回線を含みうる。車両１０１０ａ、１０１０ｂ、１０１０ｃ、１０１０ｄ、１０１０ｅ及び１０１０ｆは、車内の制御装置、センサ、アクチュエータ、ユーザインタフェース装置等の各種機器に接続されて、車内のバス（ＣＡＮバス）を介して通信を行う複数のＥＣＵを含んで構成される車載ネットワークを備える。

各車両の車載ネットワークでは、各ＥＣＵはＣＡＮプロトコルにしたがって通信を行う。ＣＡＮプロトコルにおけるフレームには、データフレーム、リモートフレーム、オーバーロードフレーム及びエラーフレームがある。ここでは主としてデータフレームに注目して説明する。なお、ＣＡＮにおいてデータフレームは、ＩＤを格納するＩＤフィールド、データ長を示すＤＬＣ（Ｄａｔａ Ｌｅｎｇｔｈ Ｃｏｄｅ）、データを格納するデータフィールドを含むように規定されている。

路側機９０、並びに、車両１０１０ａ、１０１０ｂ、１０１０ｃ及び１０１０ｄは、地域Ａに存在している。ここで、同一の地域に存在する、とは、互いにＶ２Ｘ（Ｖｅｈｉｃｌｅ－ｔｏ－Ｅｖｅｒｙｔｈｉｎｇ）通信を行うことが可能な範囲に存在することを意味することとする。

また、車両１０１０ｅ及び１０１０ｆは、地域Ｂに存在している。

［１．２ 車載ネットワークシステムの全体構成］
図２は、車種Ａの車両１０１０ａにおける車載ネットワークシステムの構成の一例を示す図である。他の車種の車両においても、図２に示す構成と同様の構成あるいは、一部異なる構成等を備える。

車両１０１０ａ等における車載ネットワークシステムは、バス（ＣＡＮバス）１０、２０、３０、４０及び５０により接続された、複数のＥＣＵ（ＥＣＵ１００、１０１、２００、２０１、３００、３０１、３０２、４００及び４０１）とゲートウェイ９００にといった各ノードを含んで構成される。なおゲートウェイ９００もＥＣＵの１つである。図２では省略しているものの、車載ネットワークシステムには、さらに多くのＥＣＵが含まれうる。

ＥＣＵは、例えば、プロセッサ（マイクロプロセッサ）、メモリ等のデジタル回路、アナログ回路、通信回路等を含む装置である。メモリは、ＲＯＭ、ＲＡＭであり、プロセッサにより実行される制御プログラム（コンピュータプログラム）を記憶することができる。例えばプロセッサが、制御プログラムにしたがって動作することにより、ＥＣＵは各種機能を実現する。なお、コンピュータプログラムは、所定の機能を実現するために、プロセッサに対する命令コードが複数個組み合わされて構成されたものである。

バス１０には、それぞれエンジン１１０及びトランスミッション１１１に接続されたＥＣＵ（エンジンＥＣＵ）１００及びＥＣＵ（トランスミッションＥＣＵ）１０１を含む、モータ、燃料、電池の制御といった車両の「走る」に関連するパワートレイン系のＥＣＵが、接続されている。

バス２０には、それぞれ、ブレーキ２１０及びステアリング２１１に接続されたＥＣＵ（ブレーキＥＣＵ）２００及びＥＣＵ（ステアリングＥＣＵ）２０１を含む、「曲がる」、「止まる」等といった車両の挙動等の制御に関連するシャーシ系のＥＣＵが、接続されている。

バス３０には、それぞれカメラ３１０、ＩＶＩ（Ｉｎ－Ｖｅｈｉｃｌｅ Ｉｎｆｏｔａｉｎｍｅｎｔ Ｓｙｓｔｅｍ）３１１、Ｖ２Ｘ通信モジュール３１２に接続されたＥＣＵ３００、ＥＣＵ３０１及びＥＣＵ３０２を含む、カメラ情報を元に運転支援の認知、判断及び制御を行う機能、又は、オーディオヘッドユニットに関わる機能、Ｖ２Ｘ通信といった情報系に関連するＥＣＵが接続されている。

バス４０には、それぞれドア４１０及びライト４１１に接続されたＥＣＵ４００及びＥＣＵ４０１を含む、エアコン又はウィンカー等といった車両の装備の制御に関連するボディ系のＥＣＵが、接続されている。

バス５０には、例えばＯＢＤ２（Ｏｎ－Ｂｏａｒｄ Ｄｉａｇｎｏｓｔｉｃｓ２）等といった、外部の診断ツール（故障診断ツール）等と通信するためのインタフェースである診断ポート５１０が接続されている。

ＥＣＵ（ＥＣＵ１００及び２００等）のそれぞれは、接続されている機器（エンジン１１０及びブレーキ２１０等）の状態を取得し、定期的に状態を表すフレーム等を車載ネットワークつまりＣＡＮバスに送信している。

バス１０に接続されたＥＣＵ１００及び１０１と、バス２０に接続されたＥＣＵ２００、２０１と、バス３０に接続されたＥＣＵ３００、３０１及び３０２とは、メッセージ認証コード（ＭＡＣ、Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）を処理する機能を有するＥＣＵであるＭＡＣ対応ＥＣＵである。ＭＡＣを処理する機能とは、具体的には、ＭＡＣの生成機能及び検証機能などである。

また、バス４０に接続されたＥＣＵ４００及び４０１は、ＭＡＣを処理する機能を有しないＭＡＣ非対応ＥＣＵである。

ゲートウェイ９００は、ＭＡＣの生成機能および検証機能を有するＭＡＣ対応ＥＣＵである。

ゲートウェイ９００は、異なる複数の通信路を接続して通信路間でデータを転送するＥＣＵである。ゲートウェイ９００は、バス１０、バス２０、バス３０、バス４０、バス５０、と接続している。つまり、ゲートウェイ９００は、一方のバスから受信したフレーム（データフレーム）を、一定条件下で他のバス（つまり条件に応じて選択した転送先バス）に転送する機能を有する一種のＥＣＵである。ゲートウェイ９００は、車両の外部の不正検知サーバ８０と通信するための通信装置（通信回路等）を備え、例えば、各バスから受信したフレームについての情報を不正検知サーバ８０に送信（アップロード）する機能を有する。ゲートウェイ９００の構成については、後に詳細に説明する。

［１．３ 不正検知サーバの構成］
図３は、不正検知サーバ８０の構成図である。不正検知サーバ８０は、車両１０１０ａ等の車載ネットワークで送信される不正なフレームに対処するためのサーバである。不正検知サーバ８０は、例えばプロセッサ、メモリ、通信インタフェース等を備えるコンピュータにより実現され、通信部８１０と、処理判断部８２０と、ログ収集部８３０と、ログ分析部８４０と、結果通知部８５０と、監視ログ通信部８６０と、優先度判断部８７０と、車両情報ＤＢ８８０と、車両ログ格納ＤＢ８８１と、分析結果格納ＤＢ８８２、監視ログ格納ＤＢ８８３とを含んで構成される。

車両情報ＤＢ８８０と、車両ログ格納ＤＢ８８１と、分析結果格納ＤＢ８８２と、監視ログ格納ＤＢ８８３とは、例えば、メモリ、ハードディスクといった記憶媒体等により実現されうる。

また、処理判断部８２０、ログ収集部８３０、ログ分析部８４０および優先度判断部８７０それぞれの機能は、例えば、メモリに格納された制御プログラムがプロセッサにより実行されることにより、実現されうる。

通信部８１０は、通信インタフェース、メモリに格納された制御プログラムを実行するプロセッサ等により実現される。

通信部８１０は、車両１０１０ａ、１０１０ｂ、１０１０ｃ、１０１０ｄ、１０１０ｅ及び１０１０ｆと、ネットワークを介して通信することで、各車載ネットワークに関する情報を受信する。車載ネットワークに関する情報は、例えば、各車載ネットワークのＣＡＮバス上に流れたフレームの内容、受信タイミング（間隔又は頻度等）、バス負荷率及びフレームのＭＡＣ検証結果に関する情報が含まれうる。

また、各車載ネットワークに関する情報に加えて、現在の車両の状態等のメタ情報が併せて通知される。メタ情報は、現在の車両の位置、ＢＳＭ（Ｂａｓｉｃ Ｓａｆｅｔｙ Ｍｅｓｓａｇｅ）、天候を示す情報が含まれうる。車両の位置は、例えばＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）により取得されるＧＰＳ位置である。

処理判断部８２０は、通信部８１０から通知される、車載ネットワークに関する情報に対する処理内容を判断する。

ログ収集部８３０は、各車両から収集したログ情報の内容である各種データ（車載ネットワークで受信されたフレームについての情報等）を、車両情報ＤＢ８８０に格納されている情報に基き、車両ログ格納ＤＢ８８１に格納する。

ログ収集部８３０は、各種データを車両ログ格納ＤＢ８８１へ格納する際に、各種データに所定の正規化等の処理を施してもよい。

ログ分析部８４０は、車両ログ格納ＤＢ８８１に格納された各車両から収集されたログ情報を用いて分析することにより、ある車両の車載ネットワークで受信されたフレームが不正であるか否か、つまり、攻撃者によりその車載ネットワークに攻撃フレームが送信されたか否かを判断する機能を有する。

ログ分析部８４０は、蓄積されたログ情報が表す、各車両から収集された複数のフレームについての情報、より具体的には、複数のフレームそれぞれの内容、受信タイミング等の情報について、例えば、統計処理等を行いうる。

ログ分析部８４０は、通信部８１０により取得された複数のフレームについての情報と、その複数のフレームについての取得より後に、通信部８１０により取得された、一の車両（例えば車両１０１０ａ）の車載ネットワークおいて受信されたフレームについての情報とに基いて、その一の車両の車載ネットワークにおいて受信されたそのフレームの異常度、又は、異常の有無を判断する機能を持つ。

ログ分析部８４０は、例えば、正常状態において車載ネットワークで流れる各フレームについての所定モデルであって、異常状態との比較用に用いることができる所定モデルを構築し、逐次取得されるログ情報に基づいて機械学習を用いて所定モデルをより適切なものへと調整（更新）することとしてもよい。

この場合に、ログ分析部８４０は、集積したログ情報が表す複数のフレームについての情報に適宜、加工処理（例えば多変量解析等）を施して、所定モデルの学習のために供給し得る。所定モデルの学習には、教師あり学習、教師なし学習のいずれの方式を用いてもよい。

例えば、各車両の車載ネットワークシステムにおいて、所定ルールに基づいてそのルールに適合しないフレーム（不正フレーム）がＣＡＮバスに流れたことを検知する不正検知機能がある場合には、不正フレームか不正でないフレームかの区別を示す情報をログ情報に含ませてもよく、ログ分析部８４０では、その区別を示す情報に基づいて、所定モデルについて教師あり学習を行ってもよい。

また、ログ分析部８４０では、各車両から不正フレームでないフレームについてのログ情報を収集して、或いは不正フレームか否かについて区別せずにログ情報を収集して、これらのログ情報に基づいて、所定モデルについて教師なし学習を行ってもよい。

この所定モデルは、ある車両の車載ネットワークで受信されたフレームについての異常度（異常の度合い）の算定に利用される。所定モデルの内容は、そのフレームの異常度の算定に用いることのできるものであればよい。

異常度は、例えば、そのフレームについての情報と所定モデルとの比較（つまりフレームについての情報と所定モデルとを用いた演算処理）により算定される。ログ分析部８４０は、異常度の算定のための所定モデルとして、例えば、同一車種の各車両におけるログ情報に基づいて、正常状態において車載ネットワークで受信されるフレームについての特徴量、より具体的には、フレームの内容、受信間隔、受信頻度等の各成分を含む特徴ベクトル等の分布を表わすように所定モデルを構築し得る。

なお、所定モデルは、例えば、異常度を目的変数としてログ情報を説明変数とする場合の目的変数と説明変数との間の関係を表すモデルであってもよい。異常度は、例えば、異常なし（つまり正常）の場合に０（ゼロ）とし、異常ありの場合に異常の度合いに応じた正の数値をとるように定め得る。異常度は、０（例えば異常なし）と１（例えば異常あり）との２値をとるものであってもよいし、異常ありを複数段階に区別して３値以上をとるものであってもよい。

異常度が所定閾値を超える場合に異常ありと判別するような活用も可能である。一例としては、ある車両の車載ネットワークで受信されたフレームの異常度は、そのフレームの特徴量が、既に集積されたログ情報に基づいて定められた所定モデルが示す特徴量の分布（例えば平均値と分散で特定される正規分布）に対する標準偏差に所定係数（例えば３）を乗じて定まる閾値を境界とする範囲の内に位置するか否かで算定でき、また、所定係数を複数用いることで異常度を複数段階に算定できる。異常度を算定するための所定モデルの構築に用いられる手法としては、外れ値検出、又は、時系列上の急激な変化を検出する変化点検出等の手法がある。

このようにログ分析部８４０は、集積されたログ情報（車両ログ情報）が表す各車両の車載ネットワークで受信された複数のフレームについての情報に基づいて、その複数のフレームについての受信より後に、ある車両の車載ネットワークにおいて受信されたフレームの異常度等を算定する。ある車両の車載ネットワークにおいて受信されたフレームの情報もその車両のログ情報から得ることができる。

ある車両の車載ネットワークで受信されたフレームについて算定した異常度により異常ありと判別した場合に、ログ分析部８４０は、異常なフレームによる影響を確認するため、異常と判断したフレームを送信した車両と同じ地域に存在する、車両へ監視要求を送信するために、監視ログ通信部８６０へ通知する。

ログ分析部８４０は、集積したログ情報に基づく統計処理、所定モデルの更新（学習）、ある車両の車載ネットワークで受信されたフレームの異常度の算定等の各種分析処理を逐次行う。そしてログ分析部８４０は、その分析処理の結果（例えば更新後の所定モデルを表わす情報、算定した異常度に関する情報等）を、分析結果格納ＤＢ８８２に格納して保存し、次回の分析処理（フレームの異常度の算定等）に利用する。

ログ分析部８４０は、上記に述べた異常の検知に限らず、例えば、急ハンドル、急ブレーキ、急加速、又は、緊急ブレーキの発動の有無といった、車両の走行状態として、異常な挙動を検出してもよい。

結果通知部８５０は、優先度判断部８７０から、不正車両監視システムの管理者に通知すべき不正なイベントがあると判断された場合に、分析結果格納ＤＢ８８２に格納される不正なイベントに関わる情報を、不正車両監視システムの管理者へ通知する手段を備える。

例えば、結果通知部８５０は、ディスプレイに接続され、不正な発生のイベントをディスプレイ上に表示する等を行う。また、結果通知部８５０は、Ｗｅｂサーバとして機能してもよいし、監視ログ格納ＤＢ８８３に格納される、車両周辺の情報を録画した動画および、車両ログ格納ＤＢ８８１に格納された車両ログを用いて、車両周辺の状況をＶＲ（Ｖｉｒｔｕａｌ Ｒｅａｌｉｔｙ）として視覚的に再現することで、アナリストに現場状況把握をさせてもよいし、メールサーバとして、管理者にメール通知を行ってもよい。

なお通知先は、車載ネットワーク監視システムの管理者でなくてもよく、例えば車載ネットワーク監視業務を委託されたセキュリティオペレーションセンターのセキュリティアナリストへ通知するとしてもよい。

監視ログ通信部８６０は、ログ分析部８４０から異常を検知したことを通知されると、異常を検知した車両と同じ地域に存在する車両または路側機に対して、異常を検知した車両の監視を要求するメッセージ（監視要求通知）を送信する。異常を検知した車両と同一の地域に存在する車両または路側機は、車両ログ格納ＤＢ８８１に格納されているＧＰＳ情報などから選出される。

また、監視ログ通信部８６０は、上記メッセージ（監視要求通知）を送信した相手の車両から監視ログを受信するまで待機する。監視ログ通信部８６０は、監視ログを受信したら、受信した監視ログを監視ログ格納ＤＢ８８３に格納する。さらに、監視ログ通信部８６０は、検知した異常の優先度を算出するように優先度判断部８７０に通知する。なお、監視要求通知には、監視すべき対象となる車両の、ナンバープレート情報又はＶＩＮ（Ｖｅｈｉｃｌｅ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｎｕｍｂｅｒ）等を含んでもよい。これにより、監視要求通知を受信した車両または路側機は、監視すべき対象を集中的に監視することができ、より詳細な監視データを取得することができる。また、監視すべき対象となる車両のナンバープレート情報又はＶＩＮ等を含まずに、単に周辺の監視を行うように通知してもよい。これにより、車両のプライバシ情報に配慮した処理が可能となる。この場合、車両の位置関係を把握している不正検知サーバ８０が、動画処理を行うことで監視対象車両の走行データ（例えば、走行速度、又は、ステアリング操舵角等）を抽出することが可能となる。

優先度判断部８７０は、監視ログ格納ＤＢ８８３から、検知した異常の度合いを確認し、その度合いに応じて優先度を算出し、算出した優先度を結果通知部８５０へ通知する。ここで、優先度とは、他よりも優先的に当該異常についての対処が必要とされる度合いを意味する。

優先度判断部８７０は、急ハンドル、急ブレーキ、急減速、又は、ふらつき運転などの、事故を引き起こしうる危険な走行がなされているとき、あるいは、既に事故が発生しているときに、比較的高い優先度を算出する。

また、優先度判断部８７０は、監視ログからは、異常と判断した車両の存在を確認できない場合、又は、車両ログと監視ログとに不整合が発生している場合には、中程度の優先度を算出する。この場合、ログに含まれる位置情報等が改ざんされており、状況が確認できないからである。

また、優先度判断部８７０は、異常と判断した車両を監視した結果、特に異常が見られなかった場合は、比較的低い優先度を算出する。この場合、ただちに危険を引き起こす危険性が低いと判断されるからである。

検知した異常の度合いの確認方法としては、例えば、Ｖ２Ｘ通信ログに含まれる、エアバッグ作動情報、緊急ブレーキ作動情報、加速度、ステアリング情報、又は、速度等から監視対象車両の状態を把握する方法がある。また、上記確認方法として、動画または画像情報分析によって車両の走行状態を認識することで、車両の走行への影響を認識する方法、又は、事故現場を認識する方法もある。さらに、上記確認方法として、ドライバによる報告が音声又は文字情報である場合は、テキスト分析又は音声認識により、異常な車両の状態を把握する方法などが考えうる。

また、優先度判断部８７０は、単に、監視ログのみから優先度を判断しなくてもよい。例えば、異常と検知した車両の車両ログと、監視ログを通知した車両の車両ログとを用いた、監視ログの整合性を検証してもよい。例えば、優先度判断部８７０は、上記監視ログに含まれるカメラ画像から車両の速度又はステアリング角度を算出し、算出した速度又はステアリング角度と、異常を検知した車両の車両ログに含まれる速度又はステアリング角度とを比較し、その差が所定の値よりも大きい場合に整合性がないと判断してもよい。これにより、優先度判断部８７０は、複数の車両の車両ログ、および、監視ログ間の整合性を検証することが可能となり、最も整合性が低いログは、改ざんされたものであると判断することができる。

なお、通信部８１０は、車両の走行に関わる情報である第一走行情報を受信する第一通信部に相当する。

車両ログ格納ＤＢ８８１は、複数の車両の現在位置を示す位置情報を保持している保持部に相当する。保持部は、記憶装置などにより実現され得る。

監視ログ通信部８６０は、（ａ）対象車両から受信した第一走行情報に異常を検知したときに、複数の車両のうち、対象車両から所定距離以内の範囲に存在する１以上の車両を位置情報を参照して特定し、特定した１以上の車両が備える車両監視装置に対して、対象車両の走行に関わる第二走行情報を取得する要求の通知を送信し、（ｂ）１以上の車両が備える車両監視装置から第二走行情報を受信する、第二通信部に相当する。

優先度判断部８７０及び結果通知部８５０は、第一走行情報と第二走行情報とから、異常が優先的に分析されるべき度合いを示す優先度を決定し、優先度が高い異常ほど、より優先的に、異常の通知をする通知部に相当する。

なお、優先度判断部８７０は、第一走行情報と第二走行情報とが整合しないと判定した場合に、第一走行情報について検知された異常に、より高い優先度を決定してもよい。

［１．４ ゲートウェイの構成］
図４Ａは、ある車両（例えば車両１０１０ａ）の車載ネットワークにおけるゲートウェイ９００の構成を示す。ゲートウェイ９００は、車両監視装置の一例である。

図４Ａに示すように、ゲートウェイ９００は、フレーム送受信部９１０と、フレーム解釈部９２０と、整合性検証部９３０と、更新処理部９４０と、フレームアップロード部９５０と、転送制御部９６０と、鍵処理部９７０と、フレーム生成部９８０と、ルール保持部９９０と、転送ルール保持部９９１と、鍵保持部９９２とを含んで構成される。

これらの構成要素の各機能は、例えばゲートウェイ９００における通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。例えば、フレームアップロード部９５０及び、更新処理部９４０は、不正検知サーバ８０と通信するための通信回路等により実現される。

フレーム送受信部９１０は、バス１０、バス２０、バス３０、バス４０及びバス５０のそれぞれに対して、ＣＡＮプロトコルに従ったフレームを送受信する。フレーム送受信部９１０は、バスからフレームを１ｂｉｔずつ受信し、フレーム解釈部９２０に通知する。

また、フレーム送受信部９１０は、フレーム生成部９８０より通知を受けた転送先のバスを示すバス情報及び送信用のフレームに基いて、そのフレームの内容を、バス１０、バス２０、バス３０、バス４０及びバス５０のうち転送先のバスに、１ｂｉｔずつ送信する。

フレーム解釈部９２０は、フレーム送受信部９１０よりフレームの値を受け取り、ＣＡＮプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。フレーム解釈部９２０は、受信されたフレームの各フィールドの情報を整合性検証部９３０へ通知する。

なお、フレーム解釈部９２０は、受け取ったフレームがＣＡＮプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部９８０へ通知する。

また、フレーム解釈部９２０は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降は、そのフレームを破棄する、つまりエラーフレームの解釈を中止する。

整合性検証部９３０は、フレームに含まれる、自車の走行状態と、センシングにより認識した他車の車両状態（センシング車両状態と呼ぶ）と、Ｖ２Ｘ通信により受信した、他車の通知する他車の車両状態（Ｖ２Ｘ車両状態と呼ぶ）との整合性を検証する。上記の他車は、不正検知サーバ８０の監視ログ通信部８６０からＩＶＩ３１１を介して受信する監視要求通知により特定され得る。また、上記の他車、自車と同一の地域に存在する車両から任意に特定されてもよい。

例えば、Ｖ２Ｘ車両状態では、他車の走行速度が２０ｋｍ／ｈであるにも関わらず、センシング車両状態では、他車の走行速度が６０ｋｍ／ｈであるという場合がある。このように、他社の走行速度について所定値よりも大きな差を検出した場合に、整合性検証部９３０は、センシング車両状態とＶ２Ｘ車両状態との整合が取れていないと判断し、不正検知サーバ８０へ不正な車両に関する情報を通知する。

センシング車両状態は、車両に備え付けられているセンサ、例えば、カメラ（ドライブレコーダ）、ミリ波レーダ、Ｌｉｄａｒ（Ｌｉｇｈｔ Ｄｅｔｅｃｔｉｏｎ ａｎｄ Ｒａｎｇｉｎｇ）等から直接に得られるデータから取得されてもよいし、ＣＡＮなどを通じて得られる情報から取得されてもよい。さらに、これらのセンサの値と、自車の車両状態とを組み合わせ加工することによって、センシング車両状態が取得されてもよい。例えば、ミリ波レーダのセンサ値を処理することによって、前方車両との相対速度を算出し、算出した相対速度に自車の走行速度を加算することによって、他車の車両の速度を算出し、センシング車両状態としてもよい。また、車両に備え付けのカメラにより得られた画像に画像処理を施すことによって、車両の速度、ハンドル操作の有無、加減速中などの車両の挙動を算出し、センシング車両状態としてもよい。

また、車両状態の整合性の検証方法も、上記に述べたものに限らない。例えば、前方車両が監視対象であるときには、整合性検証部９３０は、前方車両から通知されるＶ２Ｘ車両状態の時系列変化と、自車の車両状態の時系列変化との相関関係を算出することによって、整合性を検証してもよい。より具体的には、整合性検証部９３０は、他車のＶ２Ｘ車両状態から取得した車両の速度の時系列データと、自車の車両状態の車両の速度の時系列データの自己相関を算出し、これらが大きく乖離している場合に整合がとれていないと判断する。これにより、整合性検証部９３０は、自車と前方車両とが同じ道路を走行していることからほぼ同じ走行挙動を有しているにも関わらず、前方車両から自車に通知されるＶ２Ｘ車両状態が自車の車両状態と大きく異なることを検出することが可能となる。その結果、ゲートウェイ９００は、Ｖ２Ｘ車両状態あるいは、自車の車両状態のいずれかが改ざんされていることを検知することができ安全性が高まる。

更新処理部９４０は、ルール保持部９９０が保持している優先度ルールを、不正検知サーバ８０から取得される情報に基いて更新する。

フレームアップロード部９５０は、フレーム解釈部９２０から通知される、いずれかのＣＡＮバスから受信されたフレームを逐次取得し、受信されたフレームについての情報（例えば、フレームの内容、受信間隔、受信頻度等）を含むログ情報を不正検知サーバ８０に送信（アップロード）する。

この時にログ情報に加えて、メタ情報をアップロードする。メタ情報は、その他の各種情報（車両の状態情報、Ｂａｓｉｃ Ｓａｆｅｔｙ Ｍｅｓｓａｇｅ、車両の位置情報、バス負荷率）を含んでもよい。

さらに、フレームアップロード部９５０は、ログ情報に、車両の識別情報（車両ＩＤ）を含める。フレームアップロード部９５０は、受信されたフレームについての情報として、不正検知サーバ８０で統計処理、機械学習等を行う場合に取り扱いやすいように、フレームの内容、受信間隔、又は、受信頻度等を加工する加工処理を施してもよい。

ここで、フレームの受信間隔は、例えば、そのフレームの受信時刻と、そのフレームと同一ＩＤのフレームが前回受信された時刻との差である。

また、フレームの受信頻度は、例えば、一定の単位時間において、そのフレームと同一ＩＤのフレームが受信された数である。この加工処理は、例えば、フレームの内容、受信間隔、受信頻度等の特徴から特徴量を抽出し、正規化等を行い、特徴量の情報量の縮約を行うこと等である。特徴量の情報量の縮約は、例えば、特徴量を各成分としての特徴ベクトルで表し、不正検知サーバ８０と連携して得た情報に基いて、特徴ベクトルの次元数を主成分分析等の次元削減アルゴリズムを用いることで実現されうる。

なお、ＣＡＮバスから受信されたフレームについての情報を、迅速に不正検知サーバ８０へ伝えると、そのフレームが異常であるか否かを不正検知サーバ８０に迅速に検知させて対処を可能にしうる。

また、フレームアップロード部９５０は、例えば不正検知サーバ８０とのトラフィック量を削減すべく、無条件で、又は通信状況に応じて、ログ情報を圧縮して不正検知サーバ８０に送信してもよい。また、フレームアップロード部９５０は、フレーム送受信部９１０がＣＡＮバスから受信したフレームのうち全てのフレームについての情報ではなく特定の１つまたは複数のＩＤのフレームだけについての情報をログ情報に含めて送信してもよい。

なお、不正検知サーバ８０からの通知に対応して、ゲートウェイ９００は、ＣＡＮバスを介してあらかじめ定められたＥＣＵに必要な情報を送信する等によって、ファームウェアの更新、運転支援機能の無効化、及び、遠隔制御等の機能を実現させる。

転送制御部９６０は、転送ルール保持部９９１が保持する転送ルールに従って、受信したフレームのＩＤ、及び転送元バス（つまりそのフレームを受信したバス）に応じて、転送先のバスを選択し、転送先のバスを示すバス情報と、転送されるべきフレームの内容（例えばフレーム解釈部９２０より通知されたＩＤ、ＤＬＣ、データ等）をフレーム生成部９８０へ通知して、送信を要求する。

フレーム生成部９８０は、転送制御部９６０からの送信の要求に従い、転送制御部９６０より通知されたフレームの内容を用いて送信用のフレームを構成し、その送信用のフレーム及びバス情報（例えば転送先のバスの識別子等）をフレーム送受信部９１０へ通知する。

転送ルール保持部９９１は、バスごとのフレームの転送についてのルールを示す転送ルール情報を保持する。転送ルール情報は、転送元となりうる各バスについて、そのバスで受信された転送すべきフレームのＩＤと転送先のバスとを示す。

また転送ルール情報は、各バスが、フレーム内容を暗号化すると規定されたバスか否か、及び、フレームにＭＡＣが付与されると規定されたバスか否かを示す情報を含む。この情報を参照することで転送制御部９６０は、転送元が暗号化に対応している場合は、鍵保持部９９２が保持している、転送元のバスに接続された各ＥＣＵと共有している暗号鍵を用いて、鍵処理部９７０にフレームの内容を復号させる。

そして、転送先が暗号化に対応している場合は、転送制御部９６０は、鍵保持部９９２が保持している、転送先のバスに接続された各ＥＣＵと共有している暗号鍵を用いて、鍵処理部９７０にフレームの内容を暗号化させて転送するように制御する。

鍵処理部９７０では、フレームの内容の暗号化、復号、及び、フレームの内容等に基くＭＡＣの生成及び検証のそれぞれについて、いかなる方式を用いてもよい。

ＭＡＣは、例えばフレームのデータフィールド内の一部の値に基いて生成してもよいし、その値と、他のフィールドの値あるいは、その他の情報（例えばフレームの受信回数をカウントするカウンタ値等）を結合したものに基いて生成してもよい。

ＭＡＣの計算方法としては、例えばＨＭＡＣ（Ｈａｓｈ－ｂａｓｅｄ Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）、ＣＭＡＣ（Ｃｉｐｈｅｒ－ｂａｓｅｄ Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）等を用いることができる。

なお、フレームアップロード部９５０は、対象車両を特定する特定情報を不正検知サーバ８０から受信するとともに、フレーム送受信部９１０が取得した走行情報を不正検知サーバ８０に送信する第一通信部に相当する。

フレーム送受信部９１０は、第一通信部が受信した特定情報により特定される対象車両の走行に関わる情報である走行情報を、対象車両から取得する取得部に相当する。

例えば、フレーム送受信部９１０は、Ｖ２Ｘ通信モジュール３１２による通信によって特定車両から得られた走行情報を取得してもよい。

例えば、フレーム送受信部９１０は、カメラ３１０のようなセンサによる、特定車両に対するセンシングによって得られた走行情報を取得してもよい。

また、整合性検証部９３０は、Ｖ２Ｘ通信モジュール３１２による通信によって得られた走行情報である第一走行情報と、センサによるセンシングによって得られた走行情報である第二走行情報とが整合するか否かを判定する判定部に相当する。この場合、フレームアップロード部９５０は、第一走行情報と第二走行情報とが整合しないと判定部が判定した場合にのみ、第一走行情報と第二走行情報とを不正検知サーバ８０に送信するようにしてもよい。

なお、対象車両の走行情報は、対象車両の速度を示す速度情報を含んでいてもよい。

［１．５ 路側機の構成］
図４Ｂは、路側機９０の構成を示す。路側機９０は、車両監視装置の一例である。

図４Ｂに示されるように、路側機９０は、通信モジュール９１と、制御部９２と、Ｖ２Ｘ通信モジュール９３とを備える。

通信モジュール９１は、不正検知サーバ８０と通信することができる通信モジュールである。通信モジュール９１は、対象車両を特定する特定情報を不正検知サーバ８０から受信する。通信モジュール９１は、第一通信部に相当する。

制御部９２は、通信モジュール９１が受信した特定情報により特定される対象車両の走行に関わる情報である走行情報を、対象車両から取得する処理部である。制御部９２は、取得部に相当する。

Ｖ２Ｘ通信モジュール９３は、車両との通信を行う通信モジュールである。

なお、路側機９０は、カメラなどのセンサをさらに備えてもよい。

以上のように構成された不正検知サーバ８０及び車両１０１０ｂの処理を説明する。具体的には、不正検知サーバ８０の処理についての２つの例と、車両１０１０ｂの処理についての２つの例を説明する。ここでは、車両１０１０ａが不正な車両である場合を想定して説明する。なお、以下に示すゲートウェイ９００の処理は、路側機９０によって行われてもよい。

（１）不正検知サーバ８０の処理の第一例
図５は、本実施の形態における、不正検知サーバ８０の処理を示す第一のフロー図である。

ステップＳ１０１において、通信部８１０は、車両１０１０ａから車両ログを受信する。受信した車両ログは、処理判断部８２０を経由してログ収集部８３０に提供される。

ステップＳ１０２において、ログ収集部８３０は、ステップＳ１０１で提供された車両ログを車両ログ格納ＤＢ８８１に格納する。

ステップＳ１０３において、ログ分析部８４０は、車両ログ格納ＤＢ８８１に格納された車両ログを分析することにより、車載ネットワークで受信されたフレームが不正であるか否かを判断する。

ステップＳ１０４において、ログ分析部８４０は、ステップＳ１０３でフレームが不正であると判定したか否か、つまり、フレームの異常を検知したか否かを判定する。フレームの異常を判定した場合（ステップＳ１０４でＹｅｓ）には、ステップＳ１０５に進み、そうでない場合（ステップＳ１０４Ｎｏ）には、図５に示された一連の処理を終了する。

ステップＳ１０５において、監視ログ通信部８６０は、ステップＳ１０４でフレームの異常を検知した車両と同一の地域に存在する車両又は路側機に対して、異常を検知した車両の監視を要求するメッセージを送信する。

ステップＳ１０６において、監視ログ通信部８６０は、ステップＳ１０５で送信したメッセージに対して車両又は路側機が送信する監視ログの受信待ちをする。上記監視ログを受信したらステップＳ１０７に進む。

ステップＳ１０７において、監視ログ通信部８６０は、ステップＳ１０６で車両又は路側機から監視ログを所定数以上受信したか否かを判定する。所定数以上受信した場合（ステップＳ１０７でＹｅｓ）にはステップＳ１０８に進み、そうでない場合（ステップＳ１０７でＮｏ）には、ステップＳ１２０に進む。

ステップＳ１０８において、優先度判断部８７０は、車両ログと監視ログとの整合性の検証を行う。

ステップＳ１０９において、優先度判断部８７０は、ステップＳ１０８での検証の結果、車両ログと監視ログとの不整合が発生しているか否かを検討する。不整合が発生している場合（ステップＳ１０９でＹｅｓ）には、ステップＳ１１０に進み、そうでない場合（ステップＳ１０９でＮｏ）には、ステップＳ１１１に進む。

ステップＳ１１０において、優先度判断部８７０は、車両ログと監視ログとの不整合が発生することに基づいて、車両ログが改ざんされていることを検知する。

ステップＳ１１１において、優先度判断部８７０は、ステップＳ１０４で検知した異常に対する対応の優先度を算出する。

ステップＳ１２０において、優先度判断部８７０は、異常を検知した車両の位置情報に異常があることを検知する。

図５に示される一連の処理により、不正検知サーバ８０は、車両ログの改ざん、つまり車両ログの不正を検知することができる。

（２）不正検知サーバ８０の処理の第二例
図６は、本実施の形態における、不正検知サーバ８０の処理を示す第二のフロー図である。図６において、ステップＳ１０１からＳ１１０までの処理、及び、ステップＳ１２０の処理は、図５におけるものと同じである。

ステップＳ１３１において、優先度判断部８７０は、車両ログと監視ログとの多数決によって異常を特定する。

図６に示される一連の処理により、不正検知サーバ８０は、複数の車両監視装置からの監視ログを用いて、車両ログの改ざん、つまり車両ログの不正を検知することができる。

（３）車両１０１０ｂの処理の第一例
図７は、本実施の形態における、ゲートウェイ９００の処理を示す第一のフロー図である。

ステップＳ２０１において、車両１０１０ｂの整合性検証部９３０は、不正検知サーバ８０が送信する監視要求通知を受信する。この監視要求通知は、例えば、不正検知サーバ８０が、車両１０１０ａが不正な車両であると判断した結果、車両１０１０ａと同一の地域に存在している車両１０１０ｂを選択して送信されたものである。なお、車両１０１０ａを対象車両ともいう。

ステップＳ２０２において、整合性検証部９３０は、ステップＳ２０１で受信した監視要求通知により特定される監視対象の車両（「対象車両」ともいう）に対して、Ｖ２Ｘ通信モジュール３１２が通信接続をすることができるか否かを判定する。通信接続をすることができると判定した場合（ステップＳ２０２でＹｅｓ）には、ステップＳ２０３に進み、そうでない場合（ステップＳ２０２でＮｏ）には、ステップＳ２０４に進む。

ステップＳ２０３において、整合性検証部９３０は、Ｖ２Ｘ通信モジュール３１２による通信を介して、Ｖ２Ｘ通信ログを取得する。

ステップＳ２０４において、整合性検証部９３０は、対象車両をカメラ３１０により撮影可能であるか否かを判定する。撮影可能であるか否かの判定は、例えば、対象車両が自車から撮影可能な位置に存在しているか否かを判定することでなされ得る。撮影可能な位置に存在しているか否かは、対象車両と自車の位置情報によって判定されてもよいし、カメラ３１０により撮影された画像に対象車両が映っているか否かによって判定されてもよい。撮影可能であると判定した場合（ステップＳ２０４でＹｅｓ）には、ステップＳ２０５に進み、そうでない場合（ステップＳ２０４でＮｏ）には、ステップＳ２０６に進む。

ステップＳ２０５において、整合性検証部９３０は、カメラ３１０により対象車両の画像又は動画を撮影し、画像データ又は動画データを生成する。

ステップＳ２０６において、整合性検証部９３０は、対象車両に異常がないかの質問情報をドライバに提示し、回答情報を取得する。

ステップＳ２０７において、整合性検証部９３０は、ステップＳ２０３のＶ２Ｘ通信ログ、ステップＳ２０５の画像データ又は動画データ、ステップＳ２０６のドライバからの回答情報のうち１以上の情報を含む監視ログを不正検知サーバ８０に送信する。

図７に示される一連の処理により、車両１０１０ｂは、不正な車両つまり対象車両がアップロードするフレームを改ざんしたとしても、不正検知サーバ８０が不正な車両を検知することを支援することができる。

（４）車両１０１０ｂの処理の第二例
図８は、本実施の形態における、ゲートウェイ９００の処理を示す第二のフロー図である。

ステップＳ３０１において、整合性検証部９３０は、対象車両との間でＶ２Ｘ通信モジュール３１２による通信を開始する。なお、対象車両は、予め、不正検知サーバ８０が送信する監視要求通知を受信して、その監視要求通知により特定される監視対象車両に基づいて定められてもよいし、任意に定められてもよい。

ステップＳ３０２において、整合性検証部９３０は、Ｖ２Ｘ通信モジュール３１２による通信を介して、対象車両の走行状態を取得する。

ステップＳ３０３において、整合性検証部９３０は、対象車両をカメラ３１０によって撮影可能であるか否かを判定する。撮影可能であると判定した場合（ステップＳ３０３でＹｅｓ）には、ステップＳ３０４に進み、そうでない場合（ステップＳ３０３でＮｏ）には、図８に示される一連の処理を終了する。

ステップＳ３０４において、整合性検証部９３０は、対象車両の走行状態をカメラ３１０により認識する。

ステップＳ３０５において、整合性検証部９３０は、Ｖ２Ｘ通信により取得した走行状態と、カメラ３１０により取得した走行状態とに整合性があるか否かを判定する。上記整合性がある場合（ステップＳ３０５でＹｅｓ）には、ステップＳ３０６に進み、そうでない場合（ステップＳ３０５でＮｏ）には、ステップＳ３１１に進む。

ステップＳ３０６において、整合性検証部９３０は、整合性があることを示す通知を不正検知サーバ８０に送信する。なお、ステップＳ３０６は実行されなくてもよい。

ステップＳ３１１において、整合性検証部９３０は、整合性がないことを示す通知を不正検知サーバ８０に送信する。

図８に示される一連の処理により、車両１０１０ｂは、不正な車両つまり対象車両がアップロードするフレームを改ざんしたとしても、不正検知サーバ８０が不正な車両を検知することを支援することができる。

［１．６ 車両と不正検知サーバの処理シーケンス例１］
図９は、車両１０１０ａ及び１０１０ｂと、路側機９０と、不正検知サーバ８０との処理シーケンス例を示した図である。

まず、車両１０１０ａが、車両１０１０ａ内部で通信されるＣＡＮログ等の車両ログを不正検知サーバ８０へ送信する（ステップＳ４０１）。不正検知サーバ８０は、送信された車両ログを受信する（ステップＳ４０２）。

不正検知サーバ８０は、車両ログを受信すると、車両ログに異常が存在するか否かを分析する（ステップＳ４０３）。不正検知サーバ８０は、車両ログに異常が発生していることを検知すると（ステップＳ４０４）、車両１０１０ａと同一地域に存在する車両または路側機に対して、状況確認要求通知を送信する（ステップＳ４０５）。この例では、車両１０１０ａと同一の地域に車両１０１０ｂと、路側機９０とが存在しており、不正検知サーバ８０は、車両１０１０ｂと、路側機９０とに対して、状況確認通知を行っている。なお、ステップＳ４０１～Ｓ４０５は、例えば図５のステップＳ１０１～Ｓ１０５に相当する。

なお、状況確認通知先は、車両１０１０ａと同一の地域に現時点では存在していない（つまり、車両１０１０ａとＶ２Ｘ通信を行える距離に存在しない）車両又は路側機であっても、車両１０１０ａの経路の予測により得られる、将来に同一地域となる可能性のある車両又は路側機を含めてもよい。

状況確認要求通知を受信した車両１０１０ｂと路側機９０とは、車両１０１０ａとＶ２Ｘ通信を行い（ステップＳ４０６及びＳ４０７）、車両１０１０ａの車両の状態通知（例えば、車両の速度、走行方向、加速度等）を受信する（ステップＳ４０８及びＳ４０９）。車両１０１０ｂと路側機９０とは、受信した車両１０１０ａの車両状態通知を含むＶ２Ｘ通信ログを監視ログとして、不正検知サーバ８０へ通知する（ステップＳ４１０及びＳ４１１）。

不正検知サーバ８０は、監視ログを受信すると、監視ログと車両ログとを用いて再分析を行い最終的な判断を行う（ステップＳ４１２）。再分析では、車両ログと監視ログとの整合性の検証が行われうる。

図９では、不正検知サーバ８０が車両ログを受信した後に監視ログを受信するシーケンスを示しているが、不正検知サーバ８０は、車両ログと監視ログとを同時に受信し続け、例えば通知される速度に不整合が生じていないかを検証してもよい。そして、不整合が生じている場合には、いずれかのログが不正に改ざんされているおそれがあるとして、異常を検知し、セキュリティアナリストへ提示する。このとき、不正検知サーバ８０が複数の監視ログを受信している場合には、最も多く整合がとれているグループについて正しいログであると判断し、そのグループのログと不整合なログ（車両ログを含む）を、改ざんされたログであると判断し、改ざんされたログを送信する車両も併せて、セキュリティアナリストへ通知する。不整合がない場合は、車両ログのみで検知した異常が発生しているとして、セキュリティアナリストへ提示する。このとき付加情報として、監視ログを併せて提示する。

［１．７ 車両とサーバ間の処理シーケンス例２］
図１０は、車両１０１０ａ及び１０１０ｂと路側機９０と、不正検知サーバ８０の処理シーケンス例２を示した図である。車両１０１０ａが車両ログをサーバへ通知し、不正検知サーバ８０が車両ログを分析し、異常を検知する。その後、状況確認要求通知を、車両１０１０ｂおよび、路側機９０に送信するまでは、図１０と同様である（ステップＳ４０１～４０５）。

状況確認要求通知を受信すると、車両１０１０ｂと路側機９０とは、備え付けのカメラによる撮影により車両１０１０ａを監視する（ステップＳ５０１及びＳ５０２）。このとき、車両１０１０ｂと、路側機９０とは、不正検知サーバ８０から通知される情報を用いて車両１０１０ａを認識してもよいし、単に指定されたタイミングで動画または画像を取得するだけでもよい。車両１０１０ａを認識した場合に、さらに画像処理により、車両１０１０ａの速度、加減速状況又はステアリング状態などを抽出してもよい。また、カメラは車両１０１０ｂに備えつけのドライブレコーダを活用してもよく、サーバからの状況監視要求通知により、動画を保存するようにしてもよい。車両１０１０ｂと路側機９０とは、取得した画像あるいは動画を含めて監視ログとして、不正検知サーバ８０へ通知する（ステップＳ５０３、５０４）。

不正検知サーバ８０は、監視ログを受信すると、監視ログと車両ログとを用いて再分析を行う（ステップＳ５０５）。不正検知サーバ８０は、上記再分析において、受信した画像、または動画を、異常検知時の状況証拠として、セキュリティアナリストへ提示する。また、不正検知サーバ８０内に、画像処理エンジンが搭載されていてもよく、画像を処理することによって、車両１０１０ａの車両の速度、加減速状況又はステアリング角度等を抽出し、車両ログとの整合性を検証してもよい。あるいは、事故の発生状況や、車の異常挙動が、画像分析の結果確認された場合に、検知した異常の優先度を高として、セキュリティアナリストへ優先的に提示する。

［１．８ 車両と不正検知サーバの処理シーケンス例３］
図１１は、車両１０１０ａと１０１０ｂと、不正検知サーバ８０との処理シーケンス例３を示した図である。不正検知サーバ８０が状況確認要求を車両１０１０ｂに通知するまでは、図９又は図１０と同様のシーケンスである（ステップＳ４０１～４０５）。

車両１０１０ｂは、不正検知サーバ８０から状況確認要求通知を受信すると、車両１０１０ａの車両走行状態のセンシングを開始する（ステップＳ６０１）。センシングは、車両に備え付けられた、カメラ、レーダ又はＬｉＤＡＲ等のセンサを用いて行う。例えば、車両１０１０ａを先行車両として認識した場合に、前方車両との相対速度等を取得する。車両１０１０ｂはセンシングした、車両１０１０ａの情報を監視ログとして、不正検知サーバ８０へ通知する（ステップＳ６０２）。不正検知サーバ８０は、受信した監視ログと車両ログとを用いて再分析を行い、監視ログと車両ログとに不整合が発生していないかを検証する（ステップＳ６０３）。

［１．９ 車両と不正検知サーバの処理シーケンス例４］
図１２は、車両１０１０ａ及び１０１０ｂと、不正検知サーバ８０の処理シーケンス例４を示した図である。不正検知サーバ８０が状況確認要求を車両１０１０ｂに通知するまでは、図９、図１０又は図１１と同様のシーケンスである（ステップＳ４０１～４０５）。

車両１０１０ｂは、状況確認通知を受信すると、車両１０１０ｂのドライバに、周辺に異常がないかの確認の要求を示す提示情報を、ヘッドユニットのディスプレイ経由、または、音声により提示する（ステップＳ７０１）。ドライバが周囲の状況の確認、つまり、対象車両の挙動の確認を行い、その結果の報告を、音声またはタッチパネル操作により入力をする。車両１０１０ｂは、そのドライバからの入力を受ける（ステップＳ７０２）。車両１０１０ｂは、ドライバから受けた情報を監視ログとして、不正検知サーバ８０へ通知する（ステップＳ７０３）。不正検知サーバ８０は監視ログと車両ログとを用いて再分析を行う（ステップＳ７０４）。再分析において、不正検知サーバ８０は、ドライバからの報告をもとに、検知した異常に対する対応の優先度を決定し、優先度の高いものから、優先的にセキュリティアナリストへ通知する。

ドライバの報告は、例えば、「周囲で事故発生」、「急ハンドル、急ブレーキ、急加速の異常な車両あり」、「気になる車両あり」、「特に異常なし」等の選択式で、ドライバに選択させてもよいし、ドライバの報告をそのまま音声情報あるいは、音声認識の結果の文字情報を監視ログとしてもよい。これにより、異常を検知した車両の状況を迅速にかつ、正確に把握することが可能となり、検知したログに対する優先度を危険度に応じて付与することができ、セキュリティアナリストへ優先的に通知することが可能となる。

なお、不正検知サーバ８０は、状況確認要求を、異常を検知した車両と同地域に存在する車両へ通知しているが、通知先は、車両１０１０ｂまたは路側機９０に限らない。例えば、交通安全情報を受信するアプリケーションをインストールした端末に対して通知してもよい。このとき、当該アプリケーションは、端末の位置情報を不正検知サーバ８０に送信しており、不正検知サーバ８０は、端末の位置情報が、異常と検知した車両の近くに存在する場合に、当該端末にインストールされたアプリケーションに対して、状況確認要求通知を行う。アプリケーションは端末の所有者に対して、周辺の異常確認通知を行い、端末所有者の報告を不正検知サーバ８０へ通知する。

以降において、車載ネットワーク監視システムの動作例を説明する。

図１３は、本実施の形態における、車載ネットワーク監視システムの第一の動作例を示す説明図である。図１３の例は、車両１０１０ａの速度が６０ｋｍ／ｈであるにもかかわらず、速度が２０ｋｍ／ｈであると偽装して不正検知サーバ８０等に通知している状況で、不正検知サーバ８０が車両１０１０ａの不正を検知する状況を示している。また、この例では、車両１０１０ｂが自発的に、つまり、不正検知サーバ８０からの通知を受けることなく車両１０１０ａの異常を検知する例を示している。

図１３の（１）において、車両１０１０ａは、自車の速度が２０ｋｍ／ｈであると偽装して、不正検知サーバ８０へ通知する。

（２）において、車両１０１０ａは、自車の速度が２０ｋｍ／ｈであると偽装して、Ｖ２Ｘ通信により車両１０１０ｂに通知する。

（３）において、車両１０１０ｂは、車両１０１０ａの走行状態をカメラ又はレーダ等によるセンシングによって取得する。取得された走行状態において、自車に対する車両１０１０ａの相対速度が３０ｋｍ／ｈであることが示されているとする。

（４）車両１０１０ｂは、上記（３）でセンシングにより取得した車両１０１０ａとの相対速度と、自車の速度（３０ｋｍ／ｈとする）とから、車両１０１０ａの速度を６０ｋｍ／ｈと算出する。そして、車両１０１０ｂは、算出した車両１０１０ａの速度と、上記（２）で通知された車両１０１０ａの速度とに整合性がない、つまり異常があると判断する。

（５）車両１０１０ｂは、検知した異常を不正検知サーバ８０へ通知する。

図１４は、本実施の形態における、車載ネットワーク監視システムの第二の動作例を示す説明図である。図１５は、本実施の形態における、監視ログによる優先度を決定するための条件を示す説明図である。

図１４の例は、車両１０１０ａが急加速をしたときに、不正検知サーバ８０が車両１０１０ｂに対して、車両１０１０ａが実際に急加速をしたか否かを確認させる状況を示している。

図１４の（１）において、車両１０１０ａは、自車が急加速をしたことを含む車両ログを不正検知サーバ８０に送信する。

（２）において、不正検知サーバ８０は、上記（１）で送信された車両ログを分析して、車両１０１０ａに異常が発生したことを検知する。そして、車両１０１０ａの近くに存在している車両１０１０ｂに対して、車両１０１０ａの監視をさせる要求（監視要求ともいう）を送信する。車両１０１０ｂは、送信された監視要求を受信する。

（３）において、車両１０１０ｂは、上記（２）で受信した監視要求に応じて、Ｖ２Ｘ通信により車両１０１０ａのログ（監視ログ）を取得する。

（４）において、車両１０１０ｂは、上記（２）で受信した監視要求に応じて、車両１０１０ａの走行状態をカメラ又はレーダ等によるセンシングによって取得する。取得された走行状態において、上記の図１３の場合と同様、自車に対する車両１０１０ａの相対速度が３０ｋｍ／ｈであることが示されているとする。このとき、車両１０１０ｂのドライバに対して、車両１０１０ａの挙動を確認するための質問情報を提示して回答を得てもよい。例えば、車両１０１０ｂの前方に車両１０１０ａが存在している場合に、「前方車両が急加速をしましたか？ Ｙｅｓ／Ｎｏ」というような問いかけをし、それに対して「Ｙｅｓ」の回答を得た場合に、車両１０１０ａが急加速をしたという監視ログを生成する。

（５）において、車両１０１０ｂは、上記（３）及び（４）で車両１０１０ａから取得した車両ログ及び監視ログを不正検知サーバ８０に送信する。

（６）において、不正検知サーバ８０は、上記（２）で検知された異常の優先度を「高」に設定する。なお、優先度を決定するには、例えば、図１５に示される条件に該当する監視ログに対応する異常に対して、当該条件に対応する優先度を設定する。

図１６は、本実施の形態における、車載ネットワーク監視システムの第三の動作例を示す説明図である。図１７は、本実施の形態における、車両ログと監視ログの一例を示す説明図である。

図１６の例は、車両１０１０ａが速度を偽装して不正検知サーバ８０に送信した場合に、車両１０１０ｂ及び路側機９０により車両１０１０ｂの走行状態を把握する状況を示している。

図１６の（１）において、車両１０１０ａは、車両の速度を偽装して、不正検知サーバ８０に通知する。

（２）において、不正検知サーバ８０は、車両１０１０ａの車両ログに異常を検知する。そして、不正検知サーバ８０は、車両１０１０ａの近くに存在する車両１０１０ｂおよびと、路側機９０とに、車両１０１０ａを監視する監視要求を送信する。

（３）において、車両１０１０ｂは、上記（２）で受信した監視要求に応じて、Ｖ２Ｘ通信により車両１０１０ａのログ（監視ログ）を取得する。路側機９０も同様に処理を行う。

（４）において、車両１０１０ｂは、上記（２）で受信した監視要求に応じて、車両１０１０ａの走行状態をカメラ又はレーダ等によるセンシングによって取得する。路側機９０も同様に処理を行う。

（５）において、車両１０１０ｂは、上記（３）及び（４）で車両１０１０ａから取得した車両ログ及び監視ログを不正検知サーバ８０に送信する。路側機９０も同様に処理を行う。

（６）において、不正検知サーバ８０は、上記（５）で送信された車両ログ及び監視ログとの整合性を検証し、多数決で実際の車両１０１０ｂの走行状態を把握する。例えば、上記（５）で送信された車両ログと監視ログとの一例が図１７に示されている。ここで、車両の速度については、車両ログにおいて「速度２０ｋｍ／ｈ」、監視ログＬ１において「速度０ｋｍ／ｈ（センシングによる取得）」及び「速度２０ｋｍ／ｈ（Ｖ２Ｘ通信による取得）」、監視ログＬ２において「停車中（カメラによる取得）」及び「速度２０ｋｍ／ｈ（Ｖ２Ｘ通信による取得）」の５つの情報が含まれている。単純に多数決をとる場合、車両１０１０ｂの速度は２０ｋｍ／ｈであると判定される。また、車両ログにおける「速度２０ｋｍ／ｈ」と、監視ログＬ１及びＬ２における「速度２０ｋｍ／ｈ」の情報が単一の情報源から出たものであることを考慮して、これらを１つと数えることも可能である。その場合、多数決をとると、車両の速度は０ｋｍ／ｈであると判定される。

（実施の形態の変形例）
本変形例では、上記実施の形態に係る車両監視装置、不正検知サーバ及び制御方法の別形態を説明する。

図１８は、本変形例における車両監視装置Ａ１の機能構成を示すブロック図である。

図１８に示されるように、車両監視装置Ａ１は、第一通信部Ａ１１と、取得部Ａ１２とを備える。

第一通信部Ａ１１は、対象車両を特定する特定情報を不正検知サーバＡ２から受信する。また、第一通信部Ａ１１は、取得部Ａ１２が取得した走行情報を不正検知サーバＡ２に送信する。

取得部Ａ１２は、第一通信部Ａ１１が受信した特定情報により特定される対象車両の走行に関わる情報である走行情報を、対象車両から取得する。

図１９は、本変形例における不正検知サーバＡ２の機能構成を示すブロック図である。

図１９に示されるように、不正検知サーバＡ２は、第一通信部Ａ２１と、保持部Ａ２２と、第二通信部Ａ２３と、通知部Ａ２４とを備える。

第一通信部Ａ２１は、対象車両の走行に関わる情報である第一走行情報を受信する。

保持部Ａ２２は、複数の車両の現在位置を示す位置情報を保持している。

第二通信部Ａ２３は、（ａ）対象車両から受信した第一走行情報に異常を検知したときに、複数の車両のうち、対象車両から所定距離以内の範囲に存在する１以上の車両を位置情報を参照して特定し、特定した１以上の車両が備える車両監視装置に対して、対象車両の走行に関わる第二走行情報を取得する要求の通知を送信し、（ｂ）１以上の車両が備える車両監視装置Ａ１から第二走行情報を受信する。

通知部Ａ２４は、第一走行情報と第二走行情報とから、異常が優先的に分析されるべき度合いを示す優先度を決定し、優先度が高い異常ほど、より優先的に、異常の通知をする。

図２０は、本変形例における車両監視装置Ａ１の制御方法を示すフロー図である。

図２０に示されるように、ステップＳＡ１１において、対象車両を特定する特定情報を不正検知サーバＡ２から受信する。

ステップＳＡ１２において、ステップＳＡ１１で受信した特定情報により特定される対象車両の走行に関わる情報である走行情報を、対象車両から取得する。

ステップＳＡ１３において、ステップＳＡ１２で取得した走行情報を不正検知サーバＡ２に送信する。

図２１は、本変形例における不正検知サーバＡ２の制御方法を示すフロー図である。

図２１に示されるように、ステップＳＡ２１において、対象車両の走行に関わる情報である第一走行情報を受信する。

ステップＳＡ２２において、複数の車両の現在位置を示す位置情報を保持する。

ステップＳＡ２３において、対象車両から受信した第一走行情報に異常を検知したときに、複数の車両のうち、対象車両から所定距離以内の範囲に存在する１以上の車両を位置情報を参照して特定し、特定した１以上の車両が備える車両監視装置Ａ１に対して、対象車両の走行に関わる第二走行情報を取得する要求の通知を送信する。

ステップＳＡ２４において、１以上の車両が備える車両監視装置Ａ１から第二走行情報を受信する。

ステップＳＡ２５において、第一走行情報と第二走行情報とから、異常が優先的に分析されるべき度合いを示す優先度を決定し、優先度が高い異常ほど、より優先的に、異常の通知をする。

これにより、車両監視装置Ａ１は、不正な車両がアップロードするフレームを改ざんしたとしても、不正な車両を検知することを支援することができる。

また、不正検知サーバＡ２は、不正な車両がアップロードするフレームを改ざんしたとしても、不正な車両を検知することができる。

以上のように、上記実施の形態及び変形例に係る車両監視装置は、サーバから得た特定情報により特定される対象車両の走行情報を対象車両から取得してサーバに送信する。そのため、対象車両がサーバにアップロードしたフレームが改ざんされていたとしても、車両監視装置がサーバに送信した対象車両の走行情報によって、サーバが対象車両の不正を検知し得る。よって、車両監視装置は、不正な車両がアップロードするフレームを改ざんしたとしても、不正な車両を検知することを支援できる。

また、車両監視装置は、特定車両との通信によって得られた走行情報を取得する。よって、車両監視装置は、より容易に対象車両の走行情報を得ることによって、不正な車両がアップロードするフレームを改ざんしたとしても不正な車両を検知することを支援できる。

また、車両監視装置は、特定車両に対するセンシングによって得られた走行情報を取得する。よって、車両監視装置は、より容易に対象車両の走行情報を得ることによって、不正な車両がアップロードするフレームを改ざんしたとしても不正な車両を検知することを支援できる。

また、車両監視装置は、特定車両に対するセンシングによって得られた走行情報を取得する。よって、車両監視装置は、より容易に対象車両の走行情報を得ることによって、不正な車両がアップロードするフレームを改ざんしたとしても不正な車両を検知することを支援できる。

また、車両監視装置は、対象車両の走行状態についてのドライバによる判断の結果をセンシングにより取得する。よって、車両監視装置は、より多くの情報源から得られた対象車両の走行情報を用いて、不正な車両がアップロードするフレームを改ざんしたとしても不正な車両を検知することを支援できる。

また、車両監視装置は、特に対象車両の速度に関する不正を検知し得る。よって、車両監視装置は、不正な車両が、特に速度について改ざんしたフレームをアップロードしたとしても、不正な車両を検知することを支援できる。

また、上記実施の形態及び変形例に係る不正検知サーバは、対象車両から所定距離以内に存在する車両の車両監視装置に対して、その対象車両から走行状態を取得させる。そのため、対象車両がサーバにアップロードしたフレームが改ざんされていたとしても、車両監視装置がサーバに送信した対象車両の走行情報によって、サーバが対象車両の不正を検知し得る。よって、不正検知サーバは、不正な車両がアップロードするフレームを改ざんしたとしても、不正な車両を検知することができる。

また、不正検知サーバは、通信によって取得した対象車両の走行情報と、センシングによって取得した対象車両の走行情報とが整合しない場合に、より優先的にその異常をアナリストなどに通知する。よって、上記の２つの走行情報が整合しない場合に必要な対策をより優先的に、アナリストなどに実行させることができる。

（その他変形例）
なお、本発明を上記各実施の形態に基づいて説明してきたが、本発明は、上記各実施の形態に限定されないのはもちろんである。以下のような場合も本発明に含まれる。

（１）上記の実施の形態では、車載ネットワークをＣＡＮとして説明したが、これに限定されることなく、ＣＡＮ－ＦＤ、Ｅｔｈｅｒｎｅｔ、ＬＩＮ、Ｆｌｅｘｒａｙであってもよいし、それぞれを組み合わせた構成であってもよい。

（２）上記の実施の形態では、機械学習による異常検知処理を、クラウドサーバ側で行っているが、車両内部の装置で処理してもよい。例えば、ヘッドユニット上のＧＰＵで行うようにしてもよい。このようにすることで、即時検出性を上げる事が可能となる。この場合、クラウドでは、車両ローカルで異常検知した結果を集約するようにしてもよい。この時、処理の優先度はヘッドユニット内部で算出してもよいし、他の装置、例えばゲートウェイなどにより、ＣＡＮメッセージに含めて通知されてもよい。

（３）上記の実施の形態では、特徴ベクトルを作成する際の前処理をローカル側で行っているが、クラウドサーバ側で行うようにしてもよい。

（４）上記の実施の形態では、クラウドサーバ側で異常検知処理をしているが、よりローカル環境に近いエッジサーバで異常検知処理をするようにしてもよい。このようにすることで、クラウド側で異常検知処理するよりも、ネットワーク遅延処理の影響が少なくなる。例えばエッジサーバが路側機であって、路側機がクラウドサーバと接続されており、車両は路側機に車載メッセージ情報をアップロードし、路側機で異常検知処理し、異常検知した結果をクラウドサーバにアップロードするようにしてもよい。

（５）上記の実施の形態では、車両やクラウドサーバ側で異常検知時にアラートを通知する先として車載ネットワーク監視システム管理者としていたが、それに限定されない。例えば、カーメーカやＥＣＵサプライヤ、ユーザが所有する情報端末に通知するようにしてもよい。また、複数のカーメーカ間で共通で利用可能なセキュリティプロバイダーに通知するようにしてもよい。

（６）上記の実施の形態では、優先度は、低、中、高の３値をとり得るが、優先度はこれに限らない。例えば、０～１００のスコアとして優先度を表してもよい。これにより、不正検知サーバの優先度の割り当てが詳細に行えるようになり効果的である。

（７）上記の実施の形態では、不正検知サーバに通知する車両ログは、ＣＡＮのフレームにかかわる情報であったが、不正検知サーバに通知する車両ログはこれに限らない。例えばＥｔｈｅｒｎｅｔのフレーム、ＣＡＮ－ＦＤフレーム、ＦｌｅｘＲａｙフレームであってもよいし、車載ネットワークフレームでなくてもよい。例えば、車両の現在位置を表すＧＰＳ情報、オーディオヘッドユニットへのアクセスログ、動作プロセスに関するログ、ファームウェアのバージョン情報、Ｖ２Ｘ通信のログ等といった情報であってもよい。

（８）上記の実施の形態では、車両または路側機は、監視要求通知を受信すると、Ｖ２Ｘ通信、センサ（カメラ、レーダ）、ドライバの報告を監視ログとして、不正検知サーバに通知するが、いずれかを監視ログとして通知すればよい。また、不正検知サーバは、監視要求通知に、どのような監視ログが必要かを含めて送信してもよい。例えば、後続車両に対しては、センサ情報の取得を通知し、後続車両以外に対しては、Ｖ２Ｘ通信のログの取得を通知し、Ｖ２Ｘ通信の通信範囲外ではあるが、周辺の車両と判断された車両に対しては、ドライバの報告を要求するように、監視要求通知を送信してもよい。これにより、異常と検知した車両との、位置関係によって適切な情報を効率的に収集することが可能となる。

（９）上記の実施の形態における各装置は、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ、ハードディスクユニット、ディスプレイユニット、キーボード、マウスなどから構成されるコンピュータシステムである。前記ＲＡＭまたはハードディスクユニットには、コンピュータプログラムが記録されている。前記マイクロプロセッサが、前記コンピュータプログラムにしたがって動作することにより、各装置は、その機能を達成する。ここでコンピュータプログラムは、所定の機能を達成するために、コンピュータに対する指令を示す命令コードが複数個組み合わされて構成されたものである。

（１０）上記の実施の形態における各装置は、構成する構成要素の一部または全部は、１個のシステムＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ：大規模集積回路）から構成されているとしてもよい。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどを含んで構成されるコンピュータシステムである。前記ＲＡＭには、コンピュータプログラムが記録されている。前記マイクロプロセッサが、前記コンピュータプログラムにしたがって動作することにより、システムＬＳＩは、その機能を達成する。

また、上記の各装置を構成する構成要素の各部は、個別に１チップ化されていても良いし、一部又はすべてを含むように１チップ化されてもよい。

また、ここでは、システムＬＳＩとしたが、集積度の違いにより、ＩＣ、ＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサーを利用しても良い。

さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。

（１１）上記の各装置を構成する構成要素の一部または全部は、各装置に脱着可能なＩＣカードまたは単体のモジュールから構成されているとしてもよい。前記ＩＣカードまたは前記モジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどから構成されるコンピュータシステムである。前記ＩＣカードまたは前記モジュールは、上記の超多機能ＬＳＩを含むとしてもよい。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、前記ＩＣカードまたは前記モジュールは、その機能を達成する。このＩＣカードまたはこのモジュールは、耐タンパ性を有するとしてもよい。

（１２）本発明は、上記に示す方法であるとしてもよい。また、これらの方法をコンピュータにより実現するコンピュータプログラムであるとしてもよいし、前記コンピュータプログラムからなるデジタル信号であるとしてもよい。

また、本発明は、前記コンピュータプログラムまたは前記デジタル信号をコンピュータ読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ－ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ－ＲＯＭ、ＤＶＤ－ＲＡＭ、ＢＤ（Ｂｌｕ－ｒａｙ（登録商標） Ｄｉｓｃ）、半導体メモリなどに記録したものとしてもよい。また、これらの記録媒体に記録されている前記デジタル信号であるとしてもよい。

また、本発明は、前記コンピュータプログラムまたは前記デジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしてもよい。

また、本発明は、マイクロプロセッサとメモリを備えたコンピュータシステムであって、前記メモリは、上記コンピュータプログラムを記録しており、前記マイクロプロセッサは、前記コンピュータプログラムにしたがって動作するとしてもよい。

また、前記プログラムまたは前記デジタル信号を前記記録媒体に記録して移送することにより、または前記プログラムまたは前記デジタル信号を前記ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。

（１３）上記実施の形態及び上記変形例をそれぞれ組み合わせるとしてもよい。

なお、上記実施の形態及び変形例において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、ＣＰＵまたはプロセッサなどのプログラム実行部が、ハードディスクまたは半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。ここで、上記実施の形態及び変形例の社労監視装置などを実現するソフトウェアは、次のようなプログラムである。

すなわち、このプログラムは、コンピュータに、車両監視装置の制御方法であって、前記対象車両を特定する特定情報をサーバから受信し、受信した前記特定情報により特定される前記対象車両の走行に関わる情報である走行情報を、前記対象車両から取得し、取得した前記走行情報を前記サーバに送信する制御方法を実行させる。

また、このプログラムは、コンピュータに、不正検知サーバの制御方法であって、対象車両の走行に関わる情報である第一走行情報を受信し、複数の車両の現在位置を示す位置情報を保持し、前記対象車両から受信した前記第一走行情報に異常を検知したときに、前記複数の車両のうち、前記対象車両から所定距離以内の範囲に存在する１以上の車両を前記位置情報を参照して特定し、特定した前記１以上の車両が備える車両監視装置に対して、前記対象車両の走行に関わる第二走行情報を取得する要求の通知を送信し、前記１以上の車両が備える車両監視装置から前記第二走行情報を受信し、前記第一走行情報と前記第二走行情報とから、前記異常が優先的に分析されるべき度合いを示す優先度を決定し、前記優先度が高い前記異常ほど、より優先的に、前記異常の通知をする制御方法を実行させる。

以上、一つまたは複数の態様に係る車両監視装置などについて、実施の形態に基づいて説明したが、本発明は、この実施の形態に限定されるものではない。本発明の趣旨を逸脱しない限り、当業者が思いつく各種変形を本実施の形態に施したものや、異なる実施の形態における構成要素を組み合わせて構築される形態も、一つまたは複数の態様の範囲内に含まれてもよい。

本発明は、車両を監視する車両監視装置に利用可能である。

１０、２０、３０、４０、５０ バス
８０、Ａ２ 不正検知サーバ
８１ ネットワーク
９０ 路側機
９１ 通信モジュール
９２ 制御部
９３、３１２ Ｖ２Ｘ通信モジュール
１００、１０１、２００、２０１、３００、３０１、３０２、４００、４０１、１３０１、１３０２ ＥＣＵ
１１０ エンジン
１１１ トランスミッション
２１０ ブレーキ
２１１ ステアリング
３１０ カメラ
３１１ ＩＶＩ
４１０ ドア
４１１ ライト
５１０ 診断ポート
８１０ 通信部
８２０ 処理判断部
８３０ ログ収集部
８４０ ログ分析部
８５０ 結果通知部
８６０ 監視ログ通信部
８７０ 優先度判断部
８８０ 車両情報ＤＢ
８８１ 車両ログ格納ＤＢ
８８２ 分析結果格納ＤＢ
８８３ 監視ログ格納ＤＢ
９００ ゲートウェイ
９１０ フレーム送受信部
９２０ フレーム解釈部
９３０ 整合性検証部
９４０ 更新処理部
９５０ フレームアップロード部
９６０ 転送制御部
９７０ 鍵処理部
９８０ フレーム生成部
９９０ ルール保持部
９９１ 転送ルール保持部
９９２ 鍵保持部
１０１０ａ、１０１０ｂ、１０１０ｃ、１０１０ｄ、１０１０ｅ、１０１０ｆ 車両
Ａ１ 車両監視装置
Ａ１１、Ａ２１ 第一通信部
Ａ１２ 取得部
Ａ２２ 保持部
Ａ２３ 第二通信部
Ａ２４ 通知部

Claims (8)

1. 対象車両の車載ネットワークで受信されたフレームの情報である第一走行情報を受信する第一通信部と、
   複数の車両又は路側機の現在位置を示す位置情報を保持している保持部と、
   （ａ）前記複数の車両又は路側機のうち、前記対象車両から所定距離以内の範囲に存在する１以上の車両又は路側機を、前記位置情報を参照して特定し、特定した前記１以上の車両又は路側機に対して、前記対象車両の状態を示す第二走行情報を取得する要求の通知を送信し、
   （ｂ）前記１以上の車両又は路側機から前記第二走行情報を受信する、第二通信部と、
   前記第一走行情報と前記第二走行情報の整合性を判定する判断部と、
   前記判断部において、不整合が発生している場合に、前記不整合の通知をする通知部とを備える
   不正検知サーバ。
2. 前記第二走行情報は、前記対象車両から通信によって得られた前記対象車両の状態、前記対象車両に対するセンシングによって得られた前記対象車両の状態、ドライバの報告によって得られた前記対象車両の状態のうち少なくとも１つを含む、
   請求項１記載の不正検知サーバ。
3. 特定した対象車両以外の前記１以上の車両又は路側機に対して、前記対象車両の走行に関わる第二走行情報を取得する要求の通知は、取得したい前記対象車両の状態の出処を含む、
   請求項１記載の不正検知サーバ。
4. 特定した対象車両以外の前記１以上の車両又は路側機のそれぞれの前記対象車両との位置関係に応じて、取得したい前記対象車両の状態の出処が異なる、
   請求項１記載の不正検知サーバ。
5. さらに、前記対象車両から受信した前記第一走行情報を分析することで、対象車両の車載ネットワークによって受信されたフレームが異常であるか否かを判定し、
   前記異常である場合に、前記第一走行情報と前記第二走行情報の整合性を判定する、
   請求項１記載の不正検知サーバ。
6. 前記異常である場合に、前記判定において、前記第一走行情報と前記第二走行情報とから、前記対象車両の異常が優先的に分析されるべき度合いを示す優先度を決定する、
   請求項５記載の不正検知サーバ。
7. 前記通知部は、前記第一走行情報と前記第二走行情報が不整合と判定した場合に、前記第一走行情報について検知された前記異常に、より高い前記優先度を決定する
   請求項６に記載の不正検知サーバ。
8. 不正検知サーバの制御方法であって、
   対象車両の車載ネットワークで受信されたフレームの情報である第一走行情報を受信し、
   複数の車両又は路側機の現在位置を示す位置情報を保持し、
   前記複数の車両又は路側機のうち、前記対象車両から所定距離以内の範囲に存在する１以上の車両又は路側機を前記位置情報を参照して特定し、特定した前記１以上の車両又は路側機に対して、前記対象車両の状態を示す第二走行情報を取得する要求の通知を送信し、
   前記１以上の車両又は路側機から前記第二走行情報を受信し、
   前記第一走行情報と前記第二走行情報の整合性を判定し、不整合が発生している場合に、前記不整合の通知をする
   制御方法。

Images