JP2018131172A - 監視装置、監視方法、およびコンピュータプログラム - Google Patents
監視装置、監視方法、およびコンピュータプログラム Download PDFInfo
- Publication number
- JP2018131172A JP2018131172A JP2017028360A JP2017028360A JP2018131172A JP 2018131172 A JP2018131172 A JP 2018131172A JP 2017028360 A JP2017028360 A JP 2017028360A JP 2017028360 A JP2017028360 A JP 2017028360A JP 2018131172 A JP2018131172 A JP 2018131172A
- Authority
- JP
- Japan
- Prior art keywords
- model
- driver
- driving
- driver model
- unit
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Control Of Driving Devices And Active Controlling Of Vehicle (AREA)
- Traffic Control Systems (AREA)
- Small-Scale Networks (AREA)
Abstract
【課題】車両の異常を検知する精度を向上させる。【解決手段】運転監視装置18は、運転者の運転特徴を示す運転者モデルを記憶する。運転監視装置18は、トランスミッションECU12、エンジンECU14、ブレーキECU16から出力された車両の運転の態様を示す運転情報を、CAN22を介して受信する。運転監視装置18は、受信した運転情報の内容が運転者モデルに整合する場合、運転者によって運転された車両の状態を正常と判定する。【選択図】図1
Description
本発明は、データ処理技術に関し、特に監視装置、監視方法、およびコンピュータプログラムに関する。
近年、自動車には、多数の電子制御ユニット(Electronic Control Unit、以下「ECU」と呼ぶ。)が搭載されている。これらのECUを繋ぐネットワークは車載ネットワークと呼ばれる。車載ネットワークには多数の規格が存在するが、広く普及した規格としてCAN(Controller Area Network)がある。
車両内の不正機器が不正なデータを車載ネットワークへ送信するなりすまし攻撃を検知するために、車載ネットワークを流れるデータのIDがホワイトリストに合致するかを判定するとともに、データの送出周期が正常かを判定するネットワーク装置が提案されている(例えば、特許文献1参照)。
運転の特徴(例えばアクセスペダル位置、ハンドル角度等)が異なる運転者間では、車載ネットワークで流れるフレームが異なる。しかし、上記特許文献1のネットワーク装置は、運転者間の個人差を考慮せず、一律にデータのIDと送出周期によって異常を検出する。そのため、実際には正常であるにも関わらず、運転の態様によっては異常と誤検知する可能性があり、また、異常であるにもかかわらず、その異常を検知漏れする可能性もある。
本発明はこうした状況に鑑みてなされたものであり、1つの目的は、車両の異常を検知する精度を向上することにある。
上記課題を解決するために、本発明のある態様の監視装置は、正常な運転の特徴を示す予め定められたモデルとして特定の運転者に非依存のデフォルトモデルと、特定の運転者の運転特徴を示す運転者モデルと、を記憶する記憶部と、ネットワークを介して、運転の態様を示す運転情報を受信する受信部と、運転情報の内容が運転者モデルに整合する場合、特定の運転者によって運転された車両の状態を正常と判定する検知部と、を備える。
本発明の別の態様は、監視方法である。この方法は、運転者の運転の特徴を示す運転者モデルを記憶部に記憶する監視装置が、ネットワークを介して、運転の態様を示す運転情報を受信し、運転情報の内容が運転者モデルに整合する場合、運転者によって運転された車両の状態を正常と判定する。
なお、以上の構成要素の任意の組合せ、本発明の表現を、コンピュータプログラム、コンピュータプログラムを記録した記録媒体、本装置を搭載した車両などの間で変換したものもまた、本発明の態様として有効である。
本発明によれば、車両の異常を検知する精度を向上することができる。
実施例の構成を説明する前に概要を説明する。これまでの異常検知システムは、フレームのIDや周期等、フレームの性質に焦点を当てており、運転者の車両運転の特徴(言い換えれば「運転習慣」)を考慮したものではなかった。そのため、これまでの異常検知システムでは、誤って車両(言い換えれば運転)が異常と検知してしまうことがあり、また、車両の異常を検知できないこともあった。一方、運転者の車両運転の特徴を考慮したシステムが提案されているが(例えば特開2007−176396号公報、国際公開第2009/136616号)、車載ネットワークのセキュリティを向上するための、現実的に運用可能なシステムは十分に開示されていない。
本発明者は、車両運転の特徴が異なる運転者間では、車載ネットワークで流れるフレームが異なるという知見を得た。車両運転の特徴は、アクセスペダル位置、ハンドル角度等を含む情報(詳細は後述)であり、また、急ステアリングが多い、急ブレーキが多い等を示す情報である。例えば、後進(駐車)するシーンにおいて、ある運転者は、アクセルを少ししか使わず、ステアリングアングルの変化範囲が小さく、さらに比較的低速の運転かもしれない。また、別の運転者は、アクセルを強く踏み、ステアリングアングルの変化範囲が大きく、さらに比較的高速の運転かもしれない。
実施例の運転監視装置は、発明者の上記知見に基づくものであり、車載ネットワークを流れるCANフレームを監視し、運転者個別の専用モデルを使用して車両の異常の有無を判定する。車両の異常は、車載ネットワークを構成するCANバスにおいて、従来(言い換えれば正常時)と異なるCANフレームのパターンが現れることとも言える。また、車両の異常の原因は、車載ネットワーク内のECUに対するハッキング(言い換えれば乗っ取り)、ECUの破損、運転者による従来と異なる操作、事故等を含む。
また、実施例の運転管理装置は、さらなる特徴として、次の(1)〜(3)を備える。すなわち、(1)運転中に動的にCANフレーム(CANデータとも言える)を収集し、運転者モデルを生成する。具体的には、指定されたIDのCANフレームを収集し、機械学習等の特徴抽出手法を利用して、運転者の運転特徴を考慮した運転者モデルを生成する。また、(2)生成した運転者モデルを評価し、評価結果に応じて、異常検知に用いるモデルを切り替える。また、(3)運転者モデルを再構築するタイミングを適切に判断する。実施例の運転監視装置によると、運転者の運転習慣を考慮し、運転走行中の車両の異常を精度よく検知可能な車載ネットワークシステムを実現できる。
(第1実施例)
図1は、実施例の車載ネットワークシステム10の構成を示す。車載ネットワークシステム10は、車両内に構築された通信システムであり、トランスミッションECU12、エンジンECU14、ブレーキECU16、運転監視装置18、HMI装置20を備える。これらの装置は、CAN22を介してデータを送受信する。
図1は、実施例の車載ネットワークシステム10の構成を示す。車載ネットワークシステム10は、車両内に構築された通信システムであり、トランスミッションECU12、エンジンECU14、ブレーキECU16、運転監視装置18、HMI装置20を備える。これらの装置は、CAN22を介してデータを送受信する。
HMI装置20は、運転者へ各種情報を提示するHMI(Human Machine Interface)機能を備える情報処理装置である。HMI装置20は、カーナビゲーション装置であってもよく、IVI(In-Vehicle Infotainment)装置であってもよい。トランスミッションECU12は、車両のトランスミッションを制御するECUである。エンジンECU14は、車両のエンジンを制御するECUである。ブレーキECU16は、車両のブレーキを制御するECUである。
以下、車載ネットワークシステム10の構成要素をブロック図を使用して説明する。本明細書のブロック図において示される各ブロックは、ハードウェア的には、コンピュータのCPU・メモリをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。
図2は、図1のトランスミッションECU12に関連する機能構成を示すブロック図である。トランスミッションECU12は、ギア部30と車軸部40に接続される。ギア部30は、ギアレバー32(言い換えればシフトレバー)とギアレバー位置センサ34を含む。ギアレバー位置センサ34は、ギアレバー32の設定位置を示すギアレバー位置データをトランスミッションECU12へ出力する。車軸部40は、車軸42と車軸角速度センサ44を含む。車軸角速度センサ44は、車軸42の角速度を示す軸角速度データをトランスミッションECU12へ出力する。
トランスミッションECU12は、データ収集部50、計算部52、CANフレーム送信部58を含む。計算部52は、車速計算部54とギア推定部56を含む。データ収集部50は、ギア部30から出力されたギアレバー位置データを取得し、車軸部40から出力された軸角速度データを取得する。車速計算部54は、軸角速度データに基づいて車両速度を計算する。ギア推定部56は、ギアレバー位置データと軸角速度データに基づいて車両のギアを推定する。CANフレーム送信部58は、ギアレバー位置データを含む第1フレーム、車速データを含む第2フレーム、推定ギアデータを含む第3フレーム、および軸角速度データを含む第4フレームをCAN22へ送信する。
図3は、図1のエンジンECU14に関連する機能構成を示すブロック図である。エンジンECU14は、アクセル部60とエンジン部70に接続される。アクセル部60は、アクセルペダル62とアクセルペダル位置センサ64を含む。アクセルペダル位置センサ64は、アクセルペダル62の位置(踏み込み角度等)を示すアクセルペダル位置データをエンジンECU14へ出力する。
エンジン部70は、エンジン72、スロットル74、エンジン速度センサ76、スロットル位置センサ78を含む。エンジン速度センサ76は、エンジン72の回転数(RPM(Rotation Per Minute))を検知し、その回転数を示すエンジン速度データをエンジンECU14へ出力する。スロットル位置センサ78は、スロットル74の位置、例えばエンジン72への吸気の流入量を検知し、スロットル位置データをエンジンECU14へ出力する。
エンジンECU14は、データ収集部80、計算部82、CANフレーム送信部90を含む。計算部82は、ドライバ要求トルク計算部84、最大エンジントルク計算部86、燃料消費率計算部88を含む。データ収集部80は、アクセル部60から出力されたアクセルペダル位置データと、エンジン部70から出力されたエンジン速度データおよびスロットル位置データを取得する。ドライバ要求トルク計算部84は、アクセルペダル位置データに基づいてドライバ要求トルクを計算する。最大エンジントルク計算部86は、エンジン速度データに基づいて最大エンジントルクを計算する。燃料消費率計算部88は、スロットル位置データに基づいて燃料消費率を計算する。
CANフレーム送信部90は、アクセルペダル位置データを含む第5フレーム、エンジン速度データを含む第6フレーム、および最大エンジントルクデータを含む第7フレームをCAN22へ送信する。CANフレーム送信部90は、ドライバ要求トルクデータを含む第8フレーム、燃料消費率データを含む第9フレーム、およびスロットル位置データを含む第10フレームをCAN22へ送信する。
図4は、図1のブレーキECU16に関連する機能構成を示すブロック図である。ブレーキECU16は、ブレーキ部100とステアリング部110に接続される。ブレーキ部100は、ブレーキペダル102とブレーキペダル位置センサ104を含む。ブレーキペダル位置センサ104は、ブレーキペダル102の位置(踏み込み角度等)を示すブレーキペダル位置データをブレーキECU16へ出力する。ステアリング部110は、ステアリングハンドル112とハンドル位置センサ114を含む。ハンドル位置センサ114は、ステアリングハンドル112の角度(回動角度等)を示すハンドル角度データをブレーキECU16へ出力する。
ブレーキECU16は、データ収集部120、計算部122、CANフレーム送信部128を含む。計算部122は、横加速度計算部124とヨーレート計算部126を含む。データ収集部120は、ブレーキ部100から出力されたブレーキペダル位置データと、ステアリング部110から出力されたハンドル角度データを取得する。ヨーレート計算部126は、ハンドル角度データに基づいて車両のヨーレートを計算する。横加速度計算部124は、算出されたヨーレートに基づいて車両の横加速度を計算する。CANフレーム送信部128は、ブレーキペダル位置データを含む第11フレーム、ハンドル角度データを含む第12フレーム、横加速度データを含む第13フレーム、ヨーレートデータを含む第14フレームをCAN22へ送信する。なお、上記の第1フレーム〜第14フレームには、予め定められたID(CAN−IDまたはフレームIDとも言える)であり、互いに異なるIDが設定される。
図5は、図1の運転監視装置18の機能構成を示すブロック図である。運転監視装置18は、フレーム記憶部130、モデル記憶部132、運転者情報取得部134、フレーム受信部136、データ量判定部138、モデル生成部140、異常検知部144、結果出力部146を備える。
図5の各ブロックに対応するモジュールを含むコンピュータプログラムが、運転監視装置18のメモリ(不図示)に格納されてもよい。運転監視装置18のCPU(不図示)は、そのコンピュータプログラムを適宜読み出して実行することにより、各ブロックの機能を発揮してもよい。運転監視装置18の機能は、CAN22(車載ネットワーク)を構成するバス間でフレームを中継するCGW(Central GateWay)のECUに実装されてもよい。また、運転監視装置18の機能は、CAN22の複数のバスを流れるフレームを監視するCMI(Centralized Monitoring and Interceptor)のECUに実装されてもよい。例えば、図5の複数のブロックを含む運転監視モジュールがCGWまたはCMIに組み込まれてもよい。
フレーム記憶部130は、CAN22から受信された複数のフレームのデータを記憶する。モデル記憶部132は、車両の運転の特徴を示す複数種類のモデルのデータを記憶する。実施例のモデル記憶部132は、デフォルトモデルを記憶するとともに、1つ以上の運転者モデルを運転者の識別情報と対応付けて記憶する。
デフォルトモデルは、特定の運転者に依存しないモデルであり、正常な運転の特徴を示すものとして静的に予め定められたモデルである。デフォルトモデルは、運転者に非依存の正常運転の態様(言い換えれば範囲)を定めたデフォルトルールとも言える。また、デフォルトモデルは、異常と考えられる運転の特徴、および/または、ECU等に攻撃を受けている場合の車両走行の特徴を排除した、運転の特徴を示すモデルであってもよい。一方、運転者モデルは、運転者による車両の運転の特徴を示すモデルであり、運転者ごとに動的に特徴が抽出され、動的に作成されたモデルである。運転者モデルは、運転者ごとの正常運転(言い換えれば正常な車両走行)の態様を定めた運転者ルールとも言える。
図6は、運転者モデルのデータ構造を模式的に示す。図6の運転者モデル150の縦軸は、運転の態様を示す14種類のデータである。これら14種類のデータは、トランスミッションECU12から出力された第1フレーム〜第4フレームのデータ、エンジンECU14から出力された第5フレーム〜第10フレームのデータ、ブレーキECU16から出力された第11フレーム〜第14フレームのデータに対応する。図6の運転者モデル150の横軸は、モデルの境界を構成するパラメータである。各パラメータの値は、公知の特徴抽出手法(実施例ではSVM(Support Vector Machine))によるモデル生成時に決定される。例として、SVMを使用して運転者モデルを作成する場合、14次元空間においてモデルの境界を構成する14個のパラメータの値が決定される。デフォルトモデルのデータ構造も運転者モデルと同様である。
なお、実施例において、車両の運転の特徴を14種類のデータで表現することは、以下の文献に基づく。
Miro Enev, Alex Takakuwa, Karl Koscher, and Tadayoshi Kohno, "Automobile Driver Fingerprinting", SPW & PETS 2016 Conference
Miro Enev, Alex Takakuwa, Karl Koscher, and Tadayoshi Kohno, "Automobile Driver Fingerprinting", SPW & PETS 2016 Conference
図5に戻り、運転者情報取得部134は、HMI装置20から入力された運転者情報(運転者の識別情報等)を取得する。例えば、運転者は、HMI装置20の画面で自身の名称を選択し、HMI装置20は、選択された名称に対応付けられた運転者情報を運転監視装置18へ送信してもよい。変形例として、HMI装置20または運転監視装置18は、運転者を撮像したカメラ画像に基づく顔認識により運転者を識別する運転者識別部(不図示)を備えてもよく、運転者情報取得部134は、運転者識別部により識別された運転者情報を取得してもよい。
フレーム受信部136は、CAN22から車両の運転の態様を示す運転情報を含むフレームを受信する。具体的には、フレーム受信部136は、CAN22を流れる全てのフレームを受信し、受信したフレームのIDに基づいて上記の第1フレーム〜第14フレームを抽出し、抽出したフレームのデータに受信時刻を対応付けてフレーム記憶部130に格納する。なお、フレーム受信部136が受信時刻を付与することに代えて、フレーム送信元の装置(トランスミッションECU12等)が送信時刻のタイムスタンプをフレームに付加してもよい。
データ量判定部138は、運転者モデルの生成に必要な量のデータが受信されたか否か、言い換えれば、運転者モデルの生成に必要な量のフレームがフレーム記憶部130に蓄積されたか否かを判定する。データ量判定部138は、(1)駐車時の運転の態様を示すフレームが第1の所定量以上受信され、かつ、(2)駐車を含む複数の運転状況に対応する複数のフレームが、第1の所定量とは異なる第2所定量以上受信された場合に、必要量のデータが受信されたと判定する。
具体的には、データ量判定部138は、ギアレバー位置データがリバースを示す第1フレームが連続して受信された延べ時間(以下「駐車運転時間」とも呼ぶ。)が第1の閾値(例えば2分)以上である場合に、上記(1)が満たされたと判定する。
また、データ量判定部138は、ギアレバー位置データがリバース以外を示す第1フレームが受信されるとともに、車速データが60KM/h以下を示す第2フレームが受信された延べ時間(以下「一般走行時間」とも呼ぶ。)を識別する。また、データ量判定部138は、ギアレバー位置データがリバース以外を示す第1フレームが受信されるとともに、車速データが60KM/h超を示す第2フレームが受信された延べ時間(以下「高速走行時間」とも呼ぶ。)を識別する。データ量判定部138は、駐車運転時間、一般走行時間、高速走行時間の合計が第2の閾値(例えば50分)以上である場合に、上記(2)が満たされたと判定する。
モデル生成部140は、フレーム受信部136により受信されたフレームが示す運転の態様に応じて運転者モデルを生成する。実施例のモデル生成部140は、運転者モデルの生成に必要な量のデータが受信されたことがデータ量判定部138により判定された場合に、フレーム記憶部130に記憶された第1フレーム〜第14フレーム、および、公知の特徴抽出手法(実施例ではSVM)に基づいて、現在の運転者専用の運転者モデルを生成する。モデル生成部140は、生成した運転者モデルのデータ(例えば図6)を、運転者情報取得部134により取得された運転者情報と対応付けてモデル記憶部132に格納する。
異常検知部144は、デフォルトモデルと運転者モデルのいずれかをプライマリルールとして使用する。また、異常検知部144は、所定の条件が充足されると、デフォルトモデルをセカンダリルールとして使用する。プライマリルールは、相対的に高い優先度のモデルを示し、セカンダリルールは、相対的に低い優先度のモデルを示す。例えば、プライマリルールを用いた異常判定結果は、セカンダリルールを用いた異常判定結果より高い優先度で扱われる。第1実施例の異常検知部144は、運転者モデルが未生成であれば、デフォルトモデルをプライマリルールとして使用する。この場合、セカンダリルールは存在しない。一方、運転者モデルが生成済であれば、異常検知部144は、運転者モデルをプライマリルールとして使用し、デフォルトモデルをセカンダリルールとして使用する。
異常検知部144は、異常判定のプライマリルールがデフォルトモデルの場合、フレーム受信部136により受信されたフレームの内容がデフォルトモデルに整合する場合に、車両の状態を正常と判定する。異常検知部144は、SVM等の公知の手法により、デフォルトモデルの外縁を構成する境界の内側にフレームが示すデータ(すなわち運転の態様)が含まれるか否かを判定し、含まれる場合、フレームの内容がデフォルトモデルに整合すると判定してもよい。異常判定に運転者モデルを用いる場合(後述)も同様である。
異常検知部144は、異常判定のプライマリルールが運転者モデルの場合、すなわち、モデル記憶部132に運転者モデルが記憶されている場合、プライマリルールである運転者モデルと、セカンダリルールであるデフォルトモデルの両方に基づいて車両の異常有無を判定する。
図7(a)と図7(b)は、異常判定のパターンを示す。図7(a)の状況A〜Dは、フレームのデータが運転者モデルに整合する(○)か否か(×)と、同フレームのデータがデフォルトモデルに整合するか否かとの組み合わせのパターンである。図7(b)は、運転者モデル152の範囲(実線)とデフォルトモデル154の範囲(破線)を示している。実際には14次元空間であるが、図7(b)では簡易的に2次元空間で示している。図7(a)の状況Aは、フレームのデータが図7(b)の領域Aに該当する状況である。図7(a)の状況B〜Dは、図7(b)の領域B〜Dに対応する。
図7(a)の状況Aは、フレームのデータが運転者モデルとデフォルトモデルの両方に整合する状況である。また、図7(a)の状況Cは、フレームのデータが運転者モデルに整合するが、デフォルトモデルには不整合の状況である。この場合、異常検知部144は、フレームのデータを正常と判定する。すなわち、異常検知部144は、フレームのデータが運転者モデルに整合する場合、そのフレームのデータがデフォルトモデルに整合するか否かにかかわらず、運転されている車両の状態を正常と判定する。
図7(a)の状況Dは、フレームのデータが運転者モデルとデフォルトモデルの両方に不整合となる状況である。この場合、異常検知部144は、当該フレームのデータを異常と判定し、言い換えれば、運転されている車両の状態を異常と判定する。
図7(a)の状況Bは、フレームのデータが運転者モデルに不整合であるが、デフォルトモデルに整合する状況である。この場合、異常検知部144は、所定の監視時間に亘りフレームの監視を継続する。具体的には、異常検知部144は、1時間に亘り、複数のフレームの異常有無を判定し、フレームのIDごとに異常判定の結果を蓄積する。
異常検知部144は、複数のフレームに対する異常判定において状況Bが連続して生じる場合に、車両の状態を異常と判定する。具体的には、異常検知部144は、同じIDのフレームに対する判定結果が、所定のN回(例えば10回)以上連続して状況Bに該当する場合、車両の状態を異常と判定する。
また、異常検知部144は、複数のフレームに対する異常判定において状況Bが断続的に生じる場合に、運転者モデルの再構築(言い換えれば再学習)を決定する。具体的には、異常検知部144は、1時間のうちに、複数種類のフレームのIDに亘って所定のM回(例えば20回)以上状況Bに該当する場合、運転者モデルの再構築を決定する。例えば、1時間のうちに、ID「01」の8個のフレームが状況Bに該当し、ID「02」の7個のフレームが状況Bに該当し、ID「03」の5個のフレームが状況Bに該当した場合、すなわち、1時間のうちに合計20個のフレームが状況Bに該当した場合、異常検知部144は、運転者モデルの再構築を決定する。
運転者の運転習慣は変化する可能性があり、その変化に伴い、運転者モデルは変更されるべきである。ここで、運転習慣は、突然変化するものではなく、ある程度の時間をかけて徐々に変化するものである。そこで実施例では、運転の態様が運転者モデルには不整合だがデフォルトモデルには整合する状況Bが連続して生じる場合、運転習慣の変化に起因するものではなく異常と判定する。その一方、状況Bが断続的に生じる場合、運転習慣の変化に起因するものと判断し、運転者モデルの再構築を決定する。
図5に戻り、結果出力部146は、異常検知部144による異常判定の結果を示す判定結果データをHMI装置20へ出力する。HMI装置20は、運転監視装置18から出力された判定結果データを画面に表示させる。結果出力部146は、判定結果データとして、現在プライマリルールとして使用しているモデルの種類(デフォルトモデルまたは運転者モデル)と、判定結果(正常、異常、モデル再構築等)を設定してもよい。変形例として、HMI装置20は、所定のランプを判定結果に応じた色で点灯させてもよい。例えば、HMI装置20は、判定結果データが正常を示す場合、ランプを緑色で点灯させ、判定結果データが異常を示す場合、ランプを赤色で点灯させ、判定結果データがモデル再構築を示す場合、ランプを黄色で点灯させてもよい。別の変形例として、HMI装置20は、判定結果に応じた態様(所定の形状、模様、色彩等)のアイコンを画面に表示させてもよい。
以上の構成による第1実施例の運転監視装置18の動作を説明する。
図8は、図1の運転監視装置18の動作を示すフローチャートである。運転者情報取得部134は、HMI装置20から送信された運転者の識別情報を取得し、取得した運転者の識別情報を運転監視装置18内のメモリに格納する(S10)。運転者情報取得部134により取得された運転者の識別情報に対応する運転者モデルがモデル記憶部132に存在しなければ、すなわち、現在の運転者向けの運転者モデルが未作成であれば(S12のN)、異常検知部144は、予め静的に定められたデフォルトモデルをプライマリルールとして用いた異常判定処理を開始する(S14)。
図8は、図1の運転監視装置18の動作を示すフローチャートである。運転者情報取得部134は、HMI装置20から送信された運転者の識別情報を取得し、取得した運転者の識別情報を運転監視装置18内のメモリに格納する(S10)。運転者情報取得部134により取得された運転者の識別情報に対応する運転者モデルがモデル記憶部132に存在しなければ、すなわち、現在の運転者向けの運転者モデルが未作成であれば(S12のN)、異常検知部144は、予め静的に定められたデフォルトモデルをプライマリルールとして用いた異常判定処理を開始する(S14)。
デフォルトモデルに基づく異常判定処理と並行して、運転者モデルの生成処理を実行する。具体的には、運転者モデルの生成に必要なデータを収集する(S16)。モデル生成部140は、収集されたフレームのデータに基づいて、運転者の運転の特徴を示す運転者モデルを動的に生成する(S18)。
異常検知部144は、運転者モデルをプライマリルールとして用い、デフォルトモデルをセカンダリルールとして用いて、後述の異常判定処理を実行する(S26)。結果出力部146は、異常検知部144による異常有無の判定結果をHMI装置20へ送信し、HMI装置20は、異常有無の判定結果を画面に表示する(S28)。運転者情報取得部134により取得された運転者の識別情報に対応する運転者モデルがモデル記憶部132に存在すれば、すなわち、現在の運転者向けの運転者モデルが作成済みであれば(S12のY)、S14〜S24をスキップし、S26へ進む。
所定の終了条件が満たされた場合(S30のY)、本図のフローを終了する。所定の終了条件は、例えば、車両の電源がオフにされた場合、および/または、運転者により入力された異常判定処理の終了指示がHMI装置20から入力された場合に満たされてもよい。所定の終了条件が満たされず(S30のN)、S26の判定結果が、運転者モデルの再構築であれば(S32のY)、異常検知部144は、S26で使用した運転者モデル(言い換えれば現在の運転者に対応する現在の運転者モデル)を破棄し、S14に戻る。すなわち、デフォルトモデルによる異常判定処理へ移行し、新たな運転者モデルを構築する。S26の判定結果が、運転者モデルの再構築以外(例えば正常または異常)であれば(S32のN)、S26に戻り、現在の運転者モデルに基づく異常判定処理を継続する。
図9は、図8のS16のデータ収集処理の詳細を示すフローチャートである。フレーム受信部136は、CAN22のバスから第1フレーム〜第14フレームを受信し、受信したフレームをフレーム記憶部130へ格納する(S40)。データ量判定部138は、駐車運転時間Xが予め定められた閾値A(例えば2分)以上であり(S42のY)、かつ、駐車運転時間Xと一般走行時間Yと高速走行時間Zの合計時間が予め定められた閾値B(例えば50分)以上である場合に(S44のY)、運転者モデルの生成に必要な量のデータが蓄積されたと判定し、本図のフローを終了する。駐車運転時間Xが閾値A未満(S42のN)、または、上記の合計時間が閾値B未満である場合(S44のN)、データ量判定部138は、運転者モデルの生成に必要なデータが不足していると判定し、S40に戻る。
図10は、図8のS26の異常判定処理の詳細を示すフローチャートである。フレーム受信部136は、CAN22のバスから第1フレーム〜第14フレームのいずれかを受信する(S60)。異常検知部144は、受信されたフレームのデータが運転者モデルに整合する場合(S62のY)、車両の状態を正常と判定する(S64)。異常検知部144は、受信されたフレームのデータが運転者モデルに不整合であり(S62のN)、かつ、デフォルトモデルにも不整合であれば(S66のN)、走行中の車両の状態を異常と判定する(S68)。
また、受信されたフレームのデータが運転者モデルに不整合であるが、運転者モデルには整合する状況(図7の状況B)が生じた場合(S66のY)、異常検知部144は、フレームのIDごとに状況Bの発生状況を継続して監視する。異常検知部144は、共通のIDが付与された複数のフレームに亘って状況Bが連続N回発生した場合(S70のY)、S68へ進み、走行中の車両の状態を異常と判定する。共通のIDが付与された複数のフレームに亘って状況Bが連続N回発生していないが(S70のN)、受信された全てのフレームを母集団として状況Bが断続的に発生した場合(S72のY)、異常検知部144は、運転者モデルの再構築を決定する(S74)。状況Bが断続的に発生することがなければ(S72のN)、S74をスキップし、本図のフローを終了する。この場合、図8のS30のN、S32のNを辿ってS26へ戻り、次のフレームに基づく異常判定処理を実行する。
(第2実施例)
図11は、第2実施例の運転監視装置18の機能構成を示すブロック図である。第2実施例の運転監視装置18は、第1実施例での機能ブロックに加えて、モデル評価部142をさらに備える。図11では、図5に示した機能ブロックと同一または対応する機能ブロックに同一の符号を付している。以下、第1実施例と重複する説明は適宜省略する。
図11は、第2実施例の運転監視装置18の機能構成を示すブロック図である。第2実施例の運転監視装置18は、第1実施例での機能ブロックに加えて、モデル評価部142をさらに備える。図11では、図5に示した機能ブロックと同一または対応する機能ブロックに同一の符号を付している。以下、第1実施例と重複する説明は適宜省略する。
モデル評価部142は、複数の評価項目のそれぞれについて運転者モデルがデフォルトモデルより優位か否かを評価する。複数の評価項目は、運転者モデルおよびデフォルトモデルの性能を評価する項目であり、実施例では、網羅率とモデル中心点からの平均距離の2つを含む。網羅率は、モデル生成時に使用されたフレームとは異なるフレームが示す運転の態様がモデルに整合する割合である。また、モデル中心点からの平均距離は、モデル生成時に使用されたフレームとは異なるフレームが示す運転の態様をモデルにマッピングした場合の位置と、モデルの中心点との距離の平均値である。モデルの中心点は、実施例ではモデルの重心であり、モデルの重心からの平均距離を以下「重心距離」と呼ぶ。
モデル評価部142は、運転者モデルの網羅率がデフォルトモデルの網羅率以上である場合に運転者モデルが優位と判定する。また、モデル評価部142は、運転者モデルにおける重心距離がデフォルトモデルにおける重心距離以下である場合に運転者モデルが優位と評価する。具体的には、モデル生成部140により運転者モデルが生成されると、フレーム記憶部130は、一定時間(例えば30分間)、CAN22を流れる第1フレーム〜第14フレームをモデル評価用データとして蓄積する。モデル評価部142は、モデル評価用データを使用して、(1)網羅率、(2)重心距離の2つにより運転者モデルを評価する。
式1の「c」は網羅率を意味し、モデル評価用データに含まれるフレームの総数(pall)に対するモデルに含まれるフレーム数(pinclude)の割合を示すものである。モデル評価部142は、SVM等の公知の手法により、モデルの外縁を構成する境界の内側にフレームが示すデータ(すなわち運転の態様)が含まれるか否かを判定してもよい。また、式2で示すように、モデル評価部142は、デフォルトモデルの網羅率(cdefault)と、運転者モデルの網羅率(cdriver)の両方を算出する。モデル評価部142は、運転者モデルの網羅率がデフォルトモデルの網羅率以上である場合に、網羅率の観点から運転者モデルの方が優位と判定する。
式3の「dist」は、モデルの重心からの平均距離を示す。具体的には、「dist」は、モデルの重心(crule)から、モデル評価用データに含まれる各フレームが示すデータをモデルにマッピングした位置(言い換えればモデルが存在する14次元空間内にマッピングした位置)(pi)までの距離を合計し、フレーム総数(N)で割った値である。また、式4で示すように、モデル評価部142は、デフォルトモデルにおける重心距離(distdefault)と、運転者モデルにおける重心距離(distdriver)の両方を算出する。モデル評価部142は、運転者モデルにおける重心距離がデフォルトモデルにおける重心距離以下である場合に、モデルの重心からの平均距離の観点から運転者モデルの方が優位と判定する。
変形例として、モデル評価部142は、運転者モデルの重心からの距離を求める対象のフレームを、運転者モデルに含まれるフレームに限定してもよい。同様に、モデル評価部142は、デフォルトモデルの重心からの距離を求める対象のフレームを、デフォルトモデルに含まれるフレームに限定してもよい。
実施例のモデル評価部142は、網羅率と、重心距離との両方で運転者モデルの方が優位である場合に、運転者モデルがデフォルトモデルより優位と判定する。言い換えれば、モデル評価部142は、網羅率と重心距離の少なくとも一方で運転者モデルの方が劣位であれば、運転者モデルがデフォルトモデルより劣位と判定する。モデル評価部142は、運転者モデルがデフォルトモデルより優位と判定すると、異常判定のプライマリルールを運転者モデルに切り替える。
なお、モデル生成部140は、運転者モデルがデフォルトモデルより劣位と評価された場合、運転者モデルを更新する。具体的には、モデル生成部140は、評価対象の運転者モデルの生成時に用いたフレームとは異なるフレームに基づいて新たな運転者モデルを生成し、モデル評価部142は、その新たな運転者モデルを評価する。
異常検知部144は、異常判定のプライマリルールがデフォルトモデルの場合、フレーム受信部136により受信されたフレームの内容がデフォルトモデルに整合する場合に、車両の状態を正常と判定する。異常検知部144は、異常判定のプライマリルールが運転者モデルの場合、言い換えれば、モデル評価部142により運転者モデルがデフォルトモデルより優位と判定された場合、プライマリルールである運転者モデルと、セカンダリルールであるデフォルトモデルの両方に基づいて車両の異常有無を判定する。異常検知部144による判定処理は、第1実施例と同様である。
以上の構成による第2実施例の運転監視装置18の動作を説明する。図12は、第2実施例の運転監視装置18の動作を示すフローチャートである。S80〜S88の処理は、図8のS10〜S18と同じであるため説明を省略する。モデル評価部142は、生成された運転者モデルとデフォルトモデルとの性能を比較する(S90)。モデル評価部142は、運転者モデルがデフォルトモデルより劣位と評価した場合(S92のN)、評価対象の運転者モデルのデータを廃棄するとともに、フレーム記憶部130に記憶されたフレームのデータを廃棄する(S94)。そしてS86に戻り、フレームの再収集と運転者モデルの再構築を実行する。
運転者モデルがデフォルトモデルより優位と評価された場合(S92のY)、異常検知部144は、運転者モデルをプライマリルールとして用い、デフォルトモデルをセカンダリルールとして用いて、後述の異常判定処理を実行する(S96)。S96〜S102の処理は、図8のS26〜S32と同じであるため説明を省略する。
図13は、図12のS90の性能比較処理の詳細を示すフローチャートである。モデル評価部142は30分間待機し、その間に、フレーム受信部136は、CAN22のバスから第1フレーム〜第14フレームを受信し、受信したフレームをフレーム記憶部130へ格納する。すなわち、フレーム記憶部130は、運転者モデル生成後の30分間に受信された複数のフレームをモデル評価用データとして蓄積する(S110)。モデル評価部142は、モデル評価用データに対する運転者モデルの網羅率とデフォルトモデルの網羅率とを算出する。
運転者モデルの網羅率がデフォルトモデルの網羅率以上であれば(S112のY)、モデル評価部142は、モデル評価用データの各フレームが示す運転の態様を運転者モデルの空間内にマッピングする。モデル評価部142は、各フレームが示す運転の態様をマッピングした位置と、運転者モデルの重心との距離を求め、複数のフレームに亘る平均距離を重心距離として算出する。同様に、モデル評価部142は、モデル評価用データの各フレームが示す運転の態様をデフォルトモデルの空間内にマッピングする。モデル評価部142は、各フレームが示す運転の態様をマッピングした位置と、デフォルトモデルの重心との距離を求め、複数のフレームに亘る平均距離を重心距離として算出する。
モデル評価部142は、運転者モデルにおける重心距離がデフォルトモデルにおける重心距離以下であれば(S114のY)、運転者モデルがデフォルトモデルより性能面で優位と判定する(S116)。その一方、運転者モデルの網羅率がデフォルトモデルの網羅率未満であり(S112のN)、または、運転者モデルにおける重心距離がデフォルトモデルにおける重心距離より長ければ(S114のN)、運転者モデルがデフォルトモデルより性能面で劣位と判定する(S118)。
図14(a)と図14(b)は、データ収集処理を時系列に示す。まず、図14(a)を説明する。図14(a)は、実施例におけるデータ収集処理を左から右へ時系列に示している。運転監視装置18は、モデル生成用データを収集して運転者モデルを生成し、その後にモデル評価用データを収集して運転者モデルを評価する。タイミング(1)では、評価がNG(すなわち運転者モデルが劣位)であったため、それまでに収集したデータを廃棄し、新たなモデル生成用データの収集を開始する。タイミング(2)では、評価がOKであったため、運転者モデルをプライマリルールとして設定し、デフォルトモデルをセカンダリルールとして設定する。
タイミング(3)は、運転者モデルを再構築すべきと判断されたタイミングである。このとき、それまでの運転者モデルを廃棄する。そして、デフォルトモデルより優位な新たな運転者モデルが生成されるまでは、デフォルトモデルのみを用いて異常検知処理を実行する。また、タイミング(3)では、新たなモデル生成用データの収集を開始する。
次に、図14(b)を説明する。図14(b)は、変形例におけるデータ収集処理を左から右へ時系列に示している。以下、図14(a)と重複する説明は省略し、主に差分を説明する。同図のタイミング(1)では、運転者モデルに対する評価がNGであったが、この変形例では、それまでに収集したデータの少なくとも一部を次の運転者モデルを作成するためのデータとして使用する。図14(b)では、モデル評価用データを次のモデル生成用データとして使用し、すなわち、範囲160のデータを次のモデル生成用データとして使用する。これにより、モデル生成用データの収集時間を短縮でき、新たな運転者モデルの生成に要する時間を短縮できる。
また、タイミング(2)では、運転者モデルをプライマリルールとして設定し、デフォルトモデルをセカンダリルールとして設定した後に、フレーム受信部136およびフレーム記憶部130は、フレームのデータ(モデル生成用データ)の収集を継続する。これにより、運転者モデルを再構築すべきことが判断されたタイミング(3)で、モデル生成部140は、フレーム記憶部130に格納済のモデル生成用データを用いて新たな運転者モデルを生成することができ、新たな運転者モデルの生成に要する時間を短縮できる。
図15は、プライマリルールとセカンダリルールの入替タイミングを示す。同図の(2)〜(4)は、図14(a)の(1)〜(3)に対応する。図15の(1)の時点では、運転者モデルが未作成であるため、デフォルトモデルをプライマリルールとした異常検知処理を実行する。(2)の時点では、運転者モデルが作成されたもののデフォルトモデルより劣位と評価されたため、デフォルトモデルをプライマリルールとした異常検知処理を継続する。(3)の時点では、作成された運転者モデルがデフォルトモデルより優位と評価されたため、運転者モデルをプライマリルールとし、デフォルトモデルをセカンダリルールとした異常検知処理へ切り替える。(4)の時点では、運転者モデルを再構築するため、現在の運転者モデルを廃棄するとともに、デフォルトモデルをプライマリルールとした異常検知処理に戻る。
以上、本発明を第1実施例および第2実施例をもとに説明した。これらの実施例は例示であり、各構成要素あるいは各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
上記実施例の異常検知部144は、ホワイトリスト方式にてフレームのデータの異常有無を判定した。変形例として、異常検知部144は、ブラックリスト方式にてフレームのデータの異常有無を判定してもよい。例えば、デフォルトモデルは、異常と考えられる運転の特徴、および/または、ECU等に攻撃を受けている場合の車両走行の特徴を示すモデルであってもよい。この変形例において、異常検知部144は、フレームのデータがデフォルトモデルに整合する場合に、走行中の車両の状態を異常と判定してもよい。
上記実施例のモデル生成部140は、トランスミッションECU12、エンジンECU14、ブレーキECU16が出力する14種類のデータに基づいて運転者モデルを生成した。実施例でのECUの種類、および、データの種類は例示であり、様々な変形例が考えられる。例えば、ステアリング部110に関連するデータを出力するECUは、ステアリングECU(不図示)であってもよい。また、モデル生成部140は、14種類より多いまたは少ないデータに基づいて運転者モデルを生成してもよい。
上記実施例のデータ量判定部138は、運転者モデルに必要な量のデータが収集されたか否かを時間に基づいて判定した。変形例として、データ量判定部138は、運転者モデルに必要な量のデータが収集されたか否かを、時間に代えてもしくは時間とともに、時間以外の要素に基づいて判定してもよい。時間以外の要素は、例えば、フレーム記憶部130に記憶されたフレームの個数であってもよく、フレーム記憶部130に記憶されたフレーム全体のデータ量であってもよい。
上記実施例の運転監視装置18は、車両に搭載されることとしたが、変形例として、運転監視装置18は、車両外部に設けられてもよい。例えば、インターネットを介して車両と接続されたクラウド上の情報処理装置(サーバ等)が、運転監視装置18として機能してもよい。また、図5に示した運転監視装置18の機能ブロックのうち、フレーム記憶部130、データ量判定部138、およびモデル生成部140をクラウド上の情報処理装置が備え、残りの機能ブロックを車両内の運転監視装置が備える構成でもよい。
また、図11に示した運転監視装置18の機能ブロックのうち、フレーム記憶部130、データ量判定部138、モデル生成部140、モデル記憶部132、およびモデル評価部142をクラウド上の情報処理装置が備え、残りの機能ブロックを車両内の運転監視装置が備える構成でもよい。また、図11に示した運転監視装置18の機能ブロックのうち、フレーム記憶部130、データ量判定部138、モデル生成部140、モデル記憶部132、モデル評価部142、異常検知部144をクラウド上の情報処理装置が備え、残りの機能ブロックを車両内の運転監視装置が備える構成でもよい。
なお、実施例および変形例に記載の技術は、以下の項目によって特定されてもよい。
[項目1]
正常な運転の特徴を示す予め定められたモデルとして特定の運転者に非依存のデフォルトモデルと、特定の運転者の運転特徴を示す運転者モデルと、を記憶する記憶部と、
ネットワークを介して、運転の態様を示す運転情報を受信する受信部と、
前記運転情報の内容が前記運転者モデルに整合する場合、前記特定の運転者によって運転された車両の状態を正常と判定する検知部と、
を備える監視装置。
この監視装置によると、特定の運転者によって運転された車両の異常を検知する精度を向上することができる。
[項目2]
前記検知部は、前記運転情報の内容が前記運転者モデルに不整合の状態で、かつ、前記運転情報の内容が前記デフォルトモデルに整合する状態が連続して生じる場合、前記車両の状態を異常と判定する、
項目1に記載の監視装置。
運転者の運転習慣は、突然に変化するものではなく、徐々に変化していくものである。本項目の態様によると、運転者の運転習慣の変化ではない運転または車両の異常を精度よく検知することができる。
[項目3]
前記検知部は、前記運転情報の内容が前記運転者モデルに不整合の状態で、かつ、前記運転情報の内容が前記デフォルトモデルに整合する状態が断続的に生じる場合、前記運転者モデルの更新を決定する、
項目1または2に記載の監視装置。
運転者の運転習慣は、突然に変化するものではなく、徐々に変化していくものである。本項目の態様によると、運転者の運転習慣が変化したことを検知して、運転者の運転習慣に追従するように運転者モデルを後進することができる。
[項目4]
前記運転者モデルを生成する生成部をさらに備える、
項目1乃至3のいずれかに記載の監視装置。
この態様によると、特定の運転者の運転特徴に応じた運転者モデルを動的に生成し、異常の検知精度を向上することができる。
[項目5]
前記検知部は、前記生成部によって前記運転者モデルが生成されていない場合、前記運転情報の内容が前記デフォルトモデルに整合する場合、運転者によって運転された車両の状態を正常と判定する、
項目4に記載の監視装置。
この態様によると、運転者モデルが未生成の状況でも、デフォルトモデルを使用して、運転された車両の状態を判定することができる。
[項目6]
所定の評価項目について前記運転者モデルが前記デフォルトモデルより優位かを評価する評価部をさらに備え、
前記検知部は、前記運転者モデルが前記デフォルトモデルより優位と評価された場合、前記運転者モデルを用いて、前記車両の状態が正常かを判定する、
項目1乃至5のいずれかに記載の監視装置。
この態様によると、デフォルトモデルより性能面で優位な運転者モデルが得られた場合に、運転者モデルを用いて車両の異常を検知することで、異常の検知精度を向上することができる。
[項目7]
所定の評価項目について前記運転者モデルが前記デフォルトモデルより優位かを評価する評価部をさらに備え、
前記生成部は、前記運転者モデルが前記デフォルトモデルより劣位と評価された場合、前記運転者モデルを更新する、
項目4または5に記載の監視装置。
この態様によると、デフォルトモデルより性能がよい運転者モデルを生成しやすくなる。
[項目8]
前記評価部は、前記運転者モデルの網羅率が前記デフォルトモデルの網羅率以上である場合、前記運転者モデルが優位と評価し、網羅率は、前記運転者モデルの生成時に使用された第一の運転情報とは異なる第二の運転情報の内容がモデルに整合する割合である、
項目6または7に記載の監視装置。
この態様によると、運転者による実際の運転の態様に則した運転者モデルを異常判定に使用することができる。
[項目9]
前記運転者モデルにおける重心距離が前記デフォルトモデルにおける重心距離以下である場合、前記運転者モデルが優位と評価し、重心距離は、前記運転者モデルの生成時に使用された第一の運転情報とは異なる第二の運転情報の内容をモデルにマッピングした場合の位置と前記モデルの重心との距離である、
項目6または7に記載の監視装置。
この態様によると、運転者モデルのサイズ、言い換えれば、運転者モデルに該当する値の範囲が過度に大きくならないように抑制することができる。
[項目10]
前記生成部は、駐車時の運転の態様を示す運転情報が所定量以上受信されたとき、前記運転者モデルを生成する、
項目4に記載の監視装置。
この態様によると、運転者による運転の特徴が現れやすい駐車時の運転の態様を運転者モデルに反映させることができ、異常検知の精度を一層向上させることができる。
[項目11]
前記生成部は、駐車時運転を含む複数の運転状況のそれぞれにおける運転特徴を示す複数の運転情報が所定量以上受信されたとき、前記複数の運転情報のそれぞれが示す運転の態様に応じて、運転者モデルを生成する、
項目4に記載の監視装置。
この態様によると、運転者による運転の特徴が現れやすい駐車時を含む複数の運転状況における運転の態様を運転者モデルに反映させることができ、異常検知の精度を一層向上させることができる。
[項目12]
運転者の運転の特徴を示す運転者モデルを記憶部に記憶する監視装置が、
ネットワークを介して、運転の態様を示す運転情報を受信し、
前記運転情報の内容が前記運転者モデルに整合する場合、前記運転者によって運転された車両の状態を正常と判定する、
監視方法。
この監視方法によると、運転者によって運転された車両の異常を検知する精度を向上することができる。
[項目13]
運転者の運転の特徴を示す運転者モデルを記憶部に記憶する監視装置に、
ネットワークを介して、運転の態様を示す運転情報を受信し、
前記運転情報の内容が前記運転者モデルに整合する場合、前記運転者によって運転された車両の状態を正常と判定する、
ことを実行させるためのコンピュータプログラム。
このコンピュータプログラムによると、運転者によって運転された車両の異常を検知する精度を向上することができる。
[項目1]
正常な運転の特徴を示す予め定められたモデルとして特定の運転者に非依存のデフォルトモデルと、特定の運転者の運転特徴を示す運転者モデルと、を記憶する記憶部と、
ネットワークを介して、運転の態様を示す運転情報を受信する受信部と、
前記運転情報の内容が前記運転者モデルに整合する場合、前記特定の運転者によって運転された車両の状態を正常と判定する検知部と、
を備える監視装置。
この監視装置によると、特定の運転者によって運転された車両の異常を検知する精度を向上することができる。
[項目2]
前記検知部は、前記運転情報の内容が前記運転者モデルに不整合の状態で、かつ、前記運転情報の内容が前記デフォルトモデルに整合する状態が連続して生じる場合、前記車両の状態を異常と判定する、
項目1に記載の監視装置。
運転者の運転習慣は、突然に変化するものではなく、徐々に変化していくものである。本項目の態様によると、運転者の運転習慣の変化ではない運転または車両の異常を精度よく検知することができる。
[項目3]
前記検知部は、前記運転情報の内容が前記運転者モデルに不整合の状態で、かつ、前記運転情報の内容が前記デフォルトモデルに整合する状態が断続的に生じる場合、前記運転者モデルの更新を決定する、
項目1または2に記載の監視装置。
運転者の運転習慣は、突然に変化するものではなく、徐々に変化していくものである。本項目の態様によると、運転者の運転習慣が変化したことを検知して、運転者の運転習慣に追従するように運転者モデルを後進することができる。
[項目4]
前記運転者モデルを生成する生成部をさらに備える、
項目1乃至3のいずれかに記載の監視装置。
この態様によると、特定の運転者の運転特徴に応じた運転者モデルを動的に生成し、異常の検知精度を向上することができる。
[項目5]
前記検知部は、前記生成部によって前記運転者モデルが生成されていない場合、前記運転情報の内容が前記デフォルトモデルに整合する場合、運転者によって運転された車両の状態を正常と判定する、
項目4に記載の監視装置。
この態様によると、運転者モデルが未生成の状況でも、デフォルトモデルを使用して、運転された車両の状態を判定することができる。
[項目6]
所定の評価項目について前記運転者モデルが前記デフォルトモデルより優位かを評価する評価部をさらに備え、
前記検知部は、前記運転者モデルが前記デフォルトモデルより優位と評価された場合、前記運転者モデルを用いて、前記車両の状態が正常かを判定する、
項目1乃至5のいずれかに記載の監視装置。
この態様によると、デフォルトモデルより性能面で優位な運転者モデルが得られた場合に、運転者モデルを用いて車両の異常を検知することで、異常の検知精度を向上することができる。
[項目7]
所定の評価項目について前記運転者モデルが前記デフォルトモデルより優位かを評価する評価部をさらに備え、
前記生成部は、前記運転者モデルが前記デフォルトモデルより劣位と評価された場合、前記運転者モデルを更新する、
項目4または5に記載の監視装置。
この態様によると、デフォルトモデルより性能がよい運転者モデルを生成しやすくなる。
[項目8]
前記評価部は、前記運転者モデルの網羅率が前記デフォルトモデルの網羅率以上である場合、前記運転者モデルが優位と評価し、網羅率は、前記運転者モデルの生成時に使用された第一の運転情報とは異なる第二の運転情報の内容がモデルに整合する割合である、
項目6または7に記載の監視装置。
この態様によると、運転者による実際の運転の態様に則した運転者モデルを異常判定に使用することができる。
[項目9]
前記運転者モデルにおける重心距離が前記デフォルトモデルにおける重心距離以下である場合、前記運転者モデルが優位と評価し、重心距離は、前記運転者モデルの生成時に使用された第一の運転情報とは異なる第二の運転情報の内容をモデルにマッピングした場合の位置と前記モデルの重心との距離である、
項目6または7に記載の監視装置。
この態様によると、運転者モデルのサイズ、言い換えれば、運転者モデルに該当する値の範囲が過度に大きくならないように抑制することができる。
[項目10]
前記生成部は、駐車時の運転の態様を示す運転情報が所定量以上受信されたとき、前記運転者モデルを生成する、
項目4に記載の監視装置。
この態様によると、運転者による運転の特徴が現れやすい駐車時の運転の態様を運転者モデルに反映させることができ、異常検知の精度を一層向上させることができる。
[項目11]
前記生成部は、駐車時運転を含む複数の運転状況のそれぞれにおける運転特徴を示す複数の運転情報が所定量以上受信されたとき、前記複数の運転情報のそれぞれが示す運転の態様に応じて、運転者モデルを生成する、
項目4に記載の監視装置。
この態様によると、運転者による運転の特徴が現れやすい駐車時を含む複数の運転状況における運転の態様を運転者モデルに反映させることができ、異常検知の精度を一層向上させることができる。
[項目12]
運転者の運転の特徴を示す運転者モデルを記憶部に記憶する監視装置が、
ネットワークを介して、運転の態様を示す運転情報を受信し、
前記運転情報の内容が前記運転者モデルに整合する場合、前記運転者によって運転された車両の状態を正常と判定する、
監視方法。
この監視方法によると、運転者によって運転された車両の異常を検知する精度を向上することができる。
[項目13]
運転者の運転の特徴を示す運転者モデルを記憶部に記憶する監視装置に、
ネットワークを介して、運転の態様を示す運転情報を受信し、
前記運転情報の内容が前記運転者モデルに整合する場合、前記運転者によって運転された車両の状態を正常と判定する、
ことを実行させるためのコンピュータプログラム。
このコンピュータプログラムによると、運転者によって運転された車両の異常を検知する精度を向上することができる。
上述した実施例および変形例の任意の組み合わせもまた本発明の実施の形態として有用である。組み合わせによって生じる新たな実施の形態は、組み合わされる実施例および変形例それぞれの効果をあわせもつ。また、請求項に記載の各構成要件が果たすべき機能は、実施例および変形例において示された各構成要素の単体もしくはそれらの連携によって実現されることも当業者には理解されるところである。
10 車載ネットワークシステム、 18 運転監視装置、 22 CAN、 130 フレーム記憶部、 132 モデル記憶部、 136 フレーム受信部、 140 モデル生成部、 142 モデル評価部、 144 異常検知部。
Claims (13)
- 正常な運転の特徴を示す予め定められたモデルとして特定の運転者に非依存のデフォルトモデルと、特定の運転者の運転特徴を示す運転者モデルと、を記憶する記憶部と、
ネットワークを介して、運転の態様を示す運転情報を受信する受信部と、
前記運転情報の内容が前記運転者モデルに整合する場合、前記特定の運転者によって運転された車両の状態を正常と判定する検知部と、
を備える監視装置。 - 前記検知部は、前記運転情報の内容が前記運転者モデルに不整合の状態で、かつ、前記運転情報の内容が前記デフォルトモデルに整合する状態が連続して生じる場合、前記車両の状態を異常と判定する、
請求項1に記載の監視装置。 - 前記検知部は、前記運転情報の内容が前記運転者モデルに不整合の状態で、かつ、前記運転情報の内容が前記デフォルトモデルに整合する状態が断続的に生じる場合、前記運転者モデルの更新を決定する、
請求項1または2に記載の監視装置。 - 前記運転者モデルを生成する生成部をさらに備える、
請求項1乃至3のいずれかに記載の監視装置。 - 前記検知部は、前記生成部によって前記運転者モデルが生成されていない場合、前記運転情報の内容が前記デフォルトモデルに整合する場合、運転者によって運転された車両の状態を正常と判定する、
請求項4に記載の監視装置。 - 所定の評価項目について前記運転者モデルが前記デフォルトモデルより優位かを評価する評価部をさらに備え、
前記検知部は、前記運転者モデルが前記デフォルトモデルより優位と評価された場合、前記運転者モデルを用いて、前記車両の状態が正常かを判定する、
請求項1乃至5のいずれかに記載の監視装置。 - 所定の評価項目について前記運転者モデルが前記デフォルトモデルより優位かを評価する評価部をさらに備え、
前記生成部は、前記運転者モデルが前記デフォルトモデルより劣位と評価された場合、前記運転者モデルを更新する、
請求項4または5に記載の監視装置。 - 前記評価部は、前記運転者モデルの網羅率が前記デフォルトモデルの網羅率以上である場合、前記運転者モデルが優位と評価し、網羅率は、前記運転者モデルの生成時に使用された第一の運転情報とは異なる第二の運転情報の内容がモデルに整合する割合である、
請求項6または7に記載の監視装置。 - 前記運転者モデルにおける重心距離が前記デフォルトモデルにおける重心距離以下である場合、前記運転者モデルが優位と評価し、重心距離は、前記運転者モデルの生成時に使用された第一の運転情報とは異なる第二の運転情報の内容をモデルにマッピングした場合の位置と前記モデルの重心との距離である、
請求項6または7に記載の監視装置。 - 前記生成部は、駐車時の運転の態様を示す運転情報が所定量以上受信されたとき、前記運転者モデルを生成する、
請求項4に記載の監視装置。 - 前記生成部は、駐車時運転を含む複数の運転状況のそれぞれにおける運転特徴を示す複数の運転情報が所定量以上受信されたとき、前記複数の運転情報のそれぞれが示す運転の態様に応じて、運転者モデルを生成する、
請求項4に記載の監視装置。 - 運転者の運転の特徴を示す運転者モデルを記憶部に記憶する監視装置が、
ネットワークを介して、運転の態様を示す運転情報を受信し、
前記運転情報の内容が前記運転者モデルに整合する場合、前記運転者によって運転された車両の状態を正常と判定する、
監視方法。 - 運転者の運転の特徴を示す運転者モデルを記憶部に記憶する監視装置に、
ネットワークを介して、運転の態様を示す運転情報を受信し、
前記運転情報の内容が前記運転者モデルに整合する場合、前記運転者によって運転された車両の状態を正常と判定する、
ことを実行させるためのコンピュータプログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2017028360A JP2018131172A (ja) | 2017-02-17 | 2017-02-17 | 監視装置、監視方法、およびコンピュータプログラム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2017028360A JP2018131172A (ja) | 2017-02-17 | 2017-02-17 | 監視装置、監視方法、およびコンピュータプログラム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2018131172A true JP2018131172A (ja) | 2018-08-23 |
Family
ID=63249458
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2017028360A Pending JP2018131172A (ja) | 2017-02-17 | 2017-02-17 | 監視装置、監視方法、およびコンピュータプログラム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2018131172A (ja) |
-
2017
- 2017-02-17 JP JP2017028360A patent/JP2018131172A/ja active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109421630B (zh) | 用于监测自主车辆的健康的控制器架构 | |
US11182884B2 (en) | Enhanced high-dynamic-range imaging and tone mapping | |
CN108248609B (zh) | 混合动力车辆和在混合动力车辆中预测驾驶样式的方法 | |
US11325591B2 (en) | System and method for teleoperation service for vehicle | |
US11670091B2 (en) | Method and arrangement for validating speed limit information for a road vehicle | |
JP5712845B2 (ja) | 車両用故障診断装置 | |
KR101802858B1 (ko) | 자동차용 통합데이터 처리 제어 시스템 및 방법 | |
US20180281784A1 (en) | Using a driver profile to enhance vehicle-to-everything applications | |
US20210149394A1 (en) | Systems and methods for collecting vehicle data to train a machine learning model to identify a driving behavior or a vehicle issue | |
CN110793537A (zh) | 一种导航路径推荐方法、车机及车辆 | |
CN115344117A (zh) | 适配的眼睛追踪机器学习模型引擎 | |
US20190071073A1 (en) | Vehicle control apparatus, vehicle, processing method of vehicle control apparatus, and storage medium | |
CN111731318B (zh) | 车辆控制装置、车辆控制方法、车辆以及存储介质 | |
CN113232668B (zh) | 一种驾驶辅助方法、系统、介质及终端 | |
JP7302411B2 (ja) | 運転技量評価装置 | |
CN112543937A (zh) | 数据处理方法、装置及设备 | |
US20230174085A1 (en) | Driving diagnosis device, driving diagnosis method, and storage medium | |
JP2018131172A (ja) | 監視装置、監視方法、およびコンピュータプログラム | |
JP7024352B2 (ja) | 異常推定装置 | |
CN115601852A (zh) | 一种处理车辆数据的方法、装置及车辆 | |
KR101788663B1 (ko) | 초음파 센서와 영상 센서의 데이터 통합처리 시스템 | |
JP2019079467A (ja) | 車両状態判定装置、車両状態判定システム、車両状態判定方法、及び、車両状態判定プログラム | |
JP6933677B2 (ja) | 車両制御装置、車両制御方法、車両およびプログラム | |
KR101772929B1 (ko) | 네비게이터와 avm 카메라의 영상 통합처리와 avm 카메라의 영상 통합처리 시스템 | |
WO2018078889A1 (ja) | 情報処理装置、情報処理方法および情報処理プログラム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20180416 |