JP2018131172A - 監視装置、監視方法、およびコンピュータプログラム - Google Patents

Abstract

【課題】車両の異常を検知する精度を向上させる。【解決手段】運転監視装置１８は、運転者の運転特徴を示す運転者モデルを記憶する。運転監視装置１８は、トランスミッションＥＣＵ１２、エンジンＥＣＵ１４、ブレーキＥＣＵ１６から出力された車両の運転の態様を示す運転情報を、ＣＡＮ２２を介して受信する。運転監視装置１８は、受信した運転情報の内容が運転者モデルに整合する場合、運転者によって運転された車両の状態を正常と判定する。【選択図】図１

Description

本発明は、データ処理技術に関し、特に監視装置、監視方法、およびコンピュータプログラムに関する。

近年、自動車には、多数の電子制御ユニット（Electronic Control Unit、以下「ＥＣＵ」と呼ぶ。）が搭載されている。これらのＥＣＵを繋ぐネットワークは車載ネットワークと呼ばれる。車載ネットワークには多数の規格が存在するが、広く普及した規格としてＣＡＮ（Controller Area Network）がある。

車両内の不正機器が不正なデータを車載ネットワークへ送信するなりすまし攻撃を検知するために、車載ネットワークを流れるデータのＩＤがホワイトリストに合致するかを判定するとともに、データの送出周期が正常かを判定するネットワーク装置が提案されている（例えば、特許文献１参照）。

特開２０１４−１４６８６８号公報

運転の特徴（例えばアクセスペダル位置、ハンドル角度等）が異なる運転者間では、車載ネットワークで流れるフレームが異なる。しかし、上記特許文献１のネットワーク装置は、運転者間の個人差を考慮せず、一律にデータのＩＤと送出周期によって異常を検出する。そのため、実際には正常であるにも関わらず、運転の態様によっては異常と誤検知する可能性があり、また、異常であるにもかかわらず、その異常を検知漏れする可能性もある。

本発明はこうした状況に鑑みてなされたものであり、１つの目的は、車両の異常を検知する精度を向上することにある。

上記課題を解決するために、本発明のある態様の監視装置は、正常な運転の特徴を示す予め定められたモデルとして特定の運転者に非依存のデフォルトモデルと、特定の運転者の運転特徴を示す運転者モデルと、を記憶する記憶部と、ネットワークを介して、運転の態様を示す運転情報を受信する受信部と、運転情報の内容が運転者モデルに整合する場合、特定の運転者によって運転された車両の状態を正常と判定する検知部と、を備える。

本発明の別の態様は、監視方法である。この方法は、運転者の運転の特徴を示す運転者モデルを記憶部に記憶する監視装置が、ネットワークを介して、運転の態様を示す運転情報を受信し、運転情報の内容が運転者モデルに整合する場合、運転者によって運転された車両の状態を正常と判定する。

なお、以上の構成要素の任意の組合せ、本発明の表現を、コンピュータプログラム、コンピュータプログラムを記録した記録媒体、本装置を搭載した車両などの間で変換したものもまた、本発明の態様として有効である。

本発明によれば、車両の異常を検知する精度を向上することができる。

実施例の車載ネットワークシステム１０の構成を示す図である。 図１のトランスミッションＥＣＵに関連する機能構成を示すブロック図である。 図１のエンジンＥＣＵに関連する機能構成を示すブロック図である。 図１のブレーキＥＣＵに関連する機能構成を示すブロック図である。 図１の運転監視装置の機能構成を示すブロック図である。 運転者モデルのデータ構造を模式的に示す図である。 図７（ａ）と図７（ｂ）は、異常判定のパターンを示す図である。 図１の運転監視装置の動作を示すフローチャートである。 図８のＳ１６のデータ収集処理の詳細を示すフローチャートである。 図８のＳ２６の異常判定処理の詳細を示すフローチャートである。 第２実施例の運転監視装置の機能構成を示すブロック図である。 第２実施例の運転監視装置の動作を示すフローチャートである。 図１２のＳ９０の性能比較処理の詳細を示すフローチャートである。 図１４（ａ）と図１４（ｂ）は、データ収集処理を時系列に示す図である。 プライマリルールとセカンダリルールの入替タイミングを示す図である。

実施例の構成を説明する前に概要を説明する。これまでの異常検知システムは、フレームのＩＤや周期等、フレームの性質に焦点を当てており、運転者の車両運転の特徴（言い換えれば「運転習慣」）を考慮したものではなかった。そのため、これまでの異常検知システムでは、誤って車両（言い換えれば運転）が異常と検知してしまうことがあり、また、車両の異常を検知できないこともあった。一方、運転者の車両運転の特徴を考慮したシステムが提案されているが（例えば特開２００７−１７６３９６号公報、国際公開第２００９／１３６６１６号）、車載ネットワークのセキュリティを向上するための、現実的に運用可能なシステムは十分に開示されていない。

本発明者は、車両運転の特徴が異なる運転者間では、車載ネットワークで流れるフレームが異なるという知見を得た。車両運転の特徴は、アクセスペダル位置、ハンドル角度等を含む情報（詳細は後述）であり、また、急ステアリングが多い、急ブレーキが多い等を示す情報である。例えば、後進（駐車）するシーンにおいて、ある運転者は、アクセルを少ししか使わず、ステアリングアングルの変化範囲が小さく、さらに比較的低速の運転かもしれない。また、別の運転者は、アクセルを強く踏み、ステアリングアングルの変化範囲が大きく、さらに比較的高速の運転かもしれない。

実施例の運転監視装置は、発明者の上記知見に基づくものであり、車載ネットワークを流れるＣＡＮフレームを監視し、運転者個別の専用モデルを使用して車両の異常の有無を判定する。車両の異常は、車載ネットワークを構成するＣＡＮバスにおいて、従来（言い換えれば正常時）と異なるＣＡＮフレームのパターンが現れることとも言える。また、車両の異常の原因は、車載ネットワーク内のＥＣＵに対するハッキング（言い換えれば乗っ取り）、ＥＣＵの破損、運転者による従来と異なる操作、事故等を含む。

また、実施例の運転管理装置は、さらなる特徴として、次の（１）〜（３）を備える。すなわち、（１）運転中に動的にＣＡＮフレーム（ＣＡＮデータとも言える）を収集し、運転者モデルを生成する。具体的には、指定されたＩＤのＣＡＮフレームを収集し、機械学習等の特徴抽出手法を利用して、運転者の運転特徴を考慮した運転者モデルを生成する。また、（２）生成した運転者モデルを評価し、評価結果に応じて、異常検知に用いるモデルを切り替える。また、（３）運転者モデルを再構築するタイミングを適切に判断する。実施例の運転監視装置によると、運転者の運転習慣を考慮し、運転走行中の車両の異常を精度よく検知可能な車載ネットワークシステムを実現できる。

（第１実施例）
図１は、実施例の車載ネットワークシステム１０の構成を示す。車載ネットワークシステム１０は、車両内に構築された通信システムであり、トランスミッションＥＣＵ１２、エンジンＥＣＵ１４、ブレーキＥＣＵ１６、運転監視装置１８、ＨＭＩ装置２０を備える。これらの装置は、ＣＡＮ２２を介してデータを送受信する。

ＨＭＩ装置２０は、運転者へ各種情報を提示するＨＭＩ（Human Machine Interface）機能を備える情報処理装置である。ＨＭＩ装置２０は、カーナビゲーション装置であってもよく、ＩＶＩ（In-Vehicle Infotainment）装置であってもよい。トランスミッションＥＣＵ１２は、車両のトランスミッションを制御するＥＣＵである。エンジンＥＣＵ１４は、車両のエンジンを制御するＥＣＵである。ブレーキＥＣＵ１６は、車両のブレーキを制御するＥＣＵである。

以下、車載ネットワークシステム１０の構成要素をブロック図を使用して説明する。本明細書のブロック図において示される各ブロックは、ハードウェア的には、コンピュータのＣＰＵ・メモリをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。

図２は、図１のトランスミッションＥＣＵ１２に関連する機能構成を示すブロック図である。トランスミッションＥＣＵ１２は、ギア部３０と車軸部４０に接続される。ギア部３０は、ギアレバー３２（言い換えればシフトレバー）とギアレバー位置センサ３４を含む。ギアレバー位置センサ３４は、ギアレバー３２の設定位置を示すギアレバー位置データをトランスミッションＥＣＵ１２へ出力する。車軸部４０は、車軸４２と車軸角速度センサ４４を含む。車軸角速度センサ４４は、車軸４２の角速度を示す軸角速度データをトランスミッションＥＣＵ１２へ出力する。

トランスミッションＥＣＵ１２は、データ収集部５０、計算部５２、ＣＡＮフレーム送信部５８を含む。計算部５２は、車速計算部５４とギア推定部５６を含む。データ収集部５０は、ギア部３０から出力されたギアレバー位置データを取得し、車軸部４０から出力された軸角速度データを取得する。車速計算部５４は、軸角速度データに基づいて車両速度を計算する。ギア推定部５６は、ギアレバー位置データと軸角速度データに基づいて車両のギアを推定する。ＣＡＮフレーム送信部５８は、ギアレバー位置データを含む第１フレーム、車速データを含む第２フレーム、推定ギアデータを含む第３フレーム、および軸角速度データを含む第４フレームをＣＡＮ２２へ送信する。

図３は、図１のエンジンＥＣＵ１４に関連する機能構成を示すブロック図である。エンジンＥＣＵ１４は、アクセル部６０とエンジン部７０に接続される。アクセル部６０は、アクセルペダル６２とアクセルペダル位置センサ６４を含む。アクセルペダル位置センサ６４は、アクセルペダル６２の位置（踏み込み角度等）を示すアクセルペダル位置データをエンジンＥＣＵ１４へ出力する。

エンジン部７０は、エンジン７２、スロットル７４、エンジン速度センサ７６、スロットル位置センサ７８を含む。エンジン速度センサ７６は、エンジン７２の回転数（ＲＰＭ（Rotation Per Minute））を検知し、その回転数を示すエンジン速度データをエンジンＥＣＵ１４へ出力する。スロットル位置センサ７８は、スロットル７４の位置、例えばエンジン７２への吸気の流入量を検知し、スロットル位置データをエンジンＥＣＵ１４へ出力する。

エンジンＥＣＵ１４は、データ収集部８０、計算部８２、ＣＡＮフレーム送信部９０を含む。計算部８２は、ドライバ要求トルク計算部８４、最大エンジントルク計算部８６、燃料消費率計算部８８を含む。データ収集部８０は、アクセル部６０から出力されたアクセルペダル位置データと、エンジン部７０から出力されたエンジン速度データおよびスロットル位置データを取得する。ドライバ要求トルク計算部８４は、アクセルペダル位置データに基づいてドライバ要求トルクを計算する。最大エンジントルク計算部８６は、エンジン速度データに基づいて最大エンジントルクを計算する。燃料消費率計算部８８は、スロットル位置データに基づいて燃料消費率を計算する。

ＣＡＮフレーム送信部９０は、アクセルペダル位置データを含む第５フレーム、エンジン速度データを含む第６フレーム、および最大エンジントルクデータを含む第７フレームをＣＡＮ２２へ送信する。ＣＡＮフレーム送信部９０は、ドライバ要求トルクデータを含む第８フレーム、燃料消費率データを含む第９フレーム、およびスロットル位置データを含む第１０フレームをＣＡＮ２２へ送信する。

図４は、図１のブレーキＥＣＵ１６に関連する機能構成を示すブロック図である。ブレーキＥＣＵ１６は、ブレーキ部１００とステアリング部１１０に接続される。ブレーキ部１００は、ブレーキペダル１０２とブレーキペダル位置センサ１０４を含む。ブレーキペダル位置センサ１０４は、ブレーキペダル１０２の位置（踏み込み角度等）を示すブレーキペダル位置データをブレーキＥＣＵ１６へ出力する。ステアリング部１１０は、ステアリングハンドル１１２とハンドル位置センサ１１４を含む。ハンドル位置センサ１１４は、ステアリングハンドル１１２の角度（回動角度等）を示すハンドル角度データをブレーキＥＣＵ１６へ出力する。

ブレーキＥＣＵ１６は、データ収集部１２０、計算部１２２、ＣＡＮフレーム送信部１２８を含む。計算部１２２は、横加速度計算部１２４とヨーレート計算部１２６を含む。データ収集部１２０は、ブレーキ部１００から出力されたブレーキペダル位置データと、ステアリング部１１０から出力されたハンドル角度データを取得する。ヨーレート計算部１２６は、ハンドル角度データに基づいて車両のヨーレートを計算する。横加速度計算部１２４は、算出されたヨーレートに基づいて車両の横加速度を計算する。ＣＡＮフレーム送信部１２８は、ブレーキペダル位置データを含む第１１フレーム、ハンドル角度データを含む第１２フレーム、横加速度データを含む第１３フレーム、ヨーレートデータを含む第１４フレームをＣＡＮ２２へ送信する。なお、上記の第１フレーム〜第１４フレームには、予め定められたＩＤ（ＣＡＮ−ＩＤまたはフレームＩＤとも言える）であり、互いに異なるＩＤが設定される。

図５は、図１の運転監視装置１８の機能構成を示すブロック図である。運転監視装置１８は、フレーム記憶部１３０、モデル記憶部１３２、運転者情報取得部１３４、フレーム受信部１３６、データ量判定部１３８、モデル生成部１４０、異常検知部１４４、結果出力部１４６を備える。

図５の各ブロックに対応するモジュールを含むコンピュータプログラムが、運転監視装置１８のメモリ（不図示）に格納されてもよい。運転監視装置１８のＣＰＵ（不図示）は、そのコンピュータプログラムを適宜読み出して実行することにより、各ブロックの機能を発揮してもよい。運転監視装置１８の機能は、ＣＡＮ２２（車載ネットワーク）を構成するバス間でフレームを中継するＣＧＷ（Central GateWay）のＥＣＵに実装されてもよい。また、運転監視装置１８の機能は、ＣＡＮ２２の複数のバスを流れるフレームを監視するＣＭＩ（Centralized Monitoring and Interceptor）のＥＣＵに実装されてもよい。例えば、図５の複数のブロックを含む運転監視モジュールがＣＧＷまたはＣＭＩに組み込まれてもよい。

フレーム記憶部１３０は、ＣＡＮ２２から受信された複数のフレームのデータを記憶する。モデル記憶部１３２は、車両の運転の特徴を示す複数種類のモデルのデータを記憶する。実施例のモデル記憶部１３２は、デフォルトモデルを記憶するとともに、１つ以上の運転者モデルを運転者の識別情報と対応付けて記憶する。

デフォルトモデルは、特定の運転者に依存しないモデルであり、正常な運転の特徴を示すものとして静的に予め定められたモデルである。デフォルトモデルは、運転者に非依存の正常運転の態様（言い換えれば範囲）を定めたデフォルトルールとも言える。また、デフォルトモデルは、異常と考えられる運転の特徴、および／または、ＥＣＵ等に攻撃を受けている場合の車両走行の特徴を排除した、運転の特徴を示すモデルであってもよい。一方、運転者モデルは、運転者による車両の運転の特徴を示すモデルであり、運転者ごとに動的に特徴が抽出され、動的に作成されたモデルである。運転者モデルは、運転者ごとの正常運転（言い換えれば正常な車両走行）の態様を定めた運転者ルールとも言える。

図６は、運転者モデルのデータ構造を模式的に示す。図６の運転者モデル１５０の縦軸は、運転の態様を示す１４種類のデータである。これら１４種類のデータは、トランスミッションＥＣＵ１２から出力された第１フレーム〜第４フレームのデータ、エンジンＥＣＵ１４から出力された第５フレーム〜第１０フレームのデータ、ブレーキＥＣＵ１６から出力された第１１フレーム〜第１４フレームのデータに対応する。図６の運転者モデル１５０の横軸は、モデルの境界を構成するパラメータである。各パラメータの値は、公知の特徴抽出手法（実施例ではＳＶＭ（Support Vector Machine））によるモデル生成時に決定される。例として、ＳＶＭを使用して運転者モデルを作成する場合、１４次元空間においてモデルの境界を構成する１４個のパラメータの値が決定される。デフォルトモデルのデータ構造も運転者モデルと同様である。

なお、実施例において、車両の運転の特徴を１４種類のデータで表現することは、以下の文献に基づく。
Miro Enev, Alex Takakuwa, Karl Koscher, and Tadayoshi Kohno, "Automobile Driver Fingerprinting", SPW & PETS 2016 Conference

図５に戻り、運転者情報取得部１３４は、ＨＭＩ装置２０から入力された運転者情報（運転者の識別情報等）を取得する。例えば、運転者は、ＨＭＩ装置２０の画面で自身の名称を選択し、ＨＭＩ装置２０は、選択された名称に対応付けられた運転者情報を運転監視装置１８へ送信してもよい。変形例として、ＨＭＩ装置２０または運転監視装置１８は、運転者を撮像したカメラ画像に基づく顔認識により運転者を識別する運転者識別部（不図示）を備えてもよく、運転者情報取得部１３４は、運転者識別部により識別された運転者情報を取得してもよい。

フレーム受信部１３６は、ＣＡＮ２２から車両の運転の態様を示す運転情報を含むフレームを受信する。具体的には、フレーム受信部１３６は、ＣＡＮ２２を流れる全てのフレームを受信し、受信したフレームのＩＤに基づいて上記の第１フレーム〜第１４フレームを抽出し、抽出したフレームのデータに受信時刻を対応付けてフレーム記憶部１３０に格納する。なお、フレーム受信部１３６が受信時刻を付与することに代えて、フレーム送信元の装置（トランスミッションＥＣＵ１２等）が送信時刻のタイムスタンプをフレームに付加してもよい。

データ量判定部１３８は、運転者モデルの生成に必要な量のデータが受信されたか否か、言い換えれば、運転者モデルの生成に必要な量のフレームがフレーム記憶部１３０に蓄積されたか否かを判定する。データ量判定部１３８は、（１）駐車時の運転の態様を示すフレームが第１の所定量以上受信され、かつ、（２）駐車を含む複数の運転状況に対応する複数のフレームが、第１の所定量とは異なる第２所定量以上受信された場合に、必要量のデータが受信されたと判定する。

具体的には、データ量判定部１３８は、ギアレバー位置データがリバースを示す第１フレームが連続して受信された延べ時間（以下「駐車運転時間」とも呼ぶ。）が第１の閾値（例えば２分）以上である場合に、上記（１）が満たされたと判定する。

また、データ量判定部１３８は、ギアレバー位置データがリバース以外を示す第１フレームが受信されるとともに、車速データが６０ＫＭ／ｈ以下を示す第２フレームが受信された延べ時間（以下「一般走行時間」とも呼ぶ。）を識別する。また、データ量判定部１３８は、ギアレバー位置データがリバース以外を示す第１フレームが受信されるとともに、車速データが６０ＫＭ／ｈ超を示す第２フレームが受信された延べ時間（以下「高速走行時間」とも呼ぶ。）を識別する。データ量判定部１３８は、駐車運転時間、一般走行時間、高速走行時間の合計が第２の閾値（例えば５０分）以上である場合に、上記（２）が満たされたと判定する。

モデル生成部１４０は、フレーム受信部１３６により受信されたフレームが示す運転の態様に応じて運転者モデルを生成する。実施例のモデル生成部１４０は、運転者モデルの生成に必要な量のデータが受信されたことがデータ量判定部１３８により判定された場合に、フレーム記憶部１３０に記憶された第１フレーム〜第１４フレーム、および、公知の特徴抽出手法（実施例ではＳＶＭ）に基づいて、現在の運転者専用の運転者モデルを生成する。モデル生成部１４０は、生成した運転者モデルのデータ（例えば図６）を、運転者情報取得部１３４により取得された運転者情報と対応付けてモデル記憶部１３２に格納する。

異常検知部１４４は、デフォルトモデルと運転者モデルのいずれかをプライマリルールとして使用する。また、異常検知部１４４は、所定の条件が充足されると、デフォルトモデルをセカンダリルールとして使用する。プライマリルールは、相対的に高い優先度のモデルを示し、セカンダリルールは、相対的に低い優先度のモデルを示す。例えば、プライマリルールを用いた異常判定結果は、セカンダリルールを用いた異常判定結果より高い優先度で扱われる。第１実施例の異常検知部１４４は、運転者モデルが未生成であれば、デフォルトモデルをプライマリルールとして使用する。この場合、セカンダリルールは存在しない。一方、運転者モデルが生成済であれば、異常検知部１４４は、運転者モデルをプライマリルールとして使用し、デフォルトモデルをセカンダリルールとして使用する。

異常検知部１４４は、異常判定のプライマリルールがデフォルトモデルの場合、フレーム受信部１３６により受信されたフレームの内容がデフォルトモデルに整合する場合に、車両の状態を正常と判定する。異常検知部１４４は、ＳＶＭ等の公知の手法により、デフォルトモデルの外縁を構成する境界の内側にフレームが示すデータ（すなわち運転の態様）が含まれるか否かを判定し、含まれる場合、フレームの内容がデフォルトモデルに整合すると判定してもよい。異常判定に運転者モデルを用いる場合（後述）も同様である。

異常検知部１４４は、異常判定のプライマリルールが運転者モデルの場合、すなわち、モデル記憶部１３２に運転者モデルが記憶されている場合、プライマリルールである運転者モデルと、セカンダリルールであるデフォルトモデルの両方に基づいて車両の異常有無を判定する。

図７（ａ）と図７（ｂ）は、異常判定のパターンを示す。図７（ａ）の状況Ａ〜Ｄは、フレームのデータが運転者モデルに整合する（○）か否か（×）と、同フレームのデータがデフォルトモデルに整合するか否かとの組み合わせのパターンである。図７（ｂ）は、運転者モデル１５２の範囲（実線）とデフォルトモデル１５４の範囲（破線）を示している。実際には１４次元空間であるが、図７（ｂ）では簡易的に２次元空間で示している。図７（ａ）の状況Ａは、フレームのデータが図７（ｂ）の領域Ａに該当する状況である。図７（ａ）の状況Ｂ〜Ｄは、図７（ｂ）の領域Ｂ〜Ｄに対応する。

図７（ａ）の状況Ａは、フレームのデータが運転者モデルとデフォルトモデルの両方に整合する状況である。また、図７（ａ）の状況Ｃは、フレームのデータが運転者モデルに整合するが、デフォルトモデルには不整合の状況である。この場合、異常検知部１４４は、フレームのデータを正常と判定する。すなわち、異常検知部１４４は、フレームのデータが運転者モデルに整合する場合、そのフレームのデータがデフォルトモデルに整合するか否かにかかわらず、運転されている車両の状態を正常と判定する。

図７（ａ）の状況Ｄは、フレームのデータが運転者モデルとデフォルトモデルの両方に不整合となる状況である。この場合、異常検知部１４４は、当該フレームのデータを異常と判定し、言い換えれば、運転されている車両の状態を異常と判定する。

図７（ａ）の状況Ｂは、フレームのデータが運転者モデルに不整合であるが、デフォルトモデルに整合する状況である。この場合、異常検知部１４４は、所定の監視時間に亘りフレームの監視を継続する。具体的には、異常検知部１４４は、１時間に亘り、複数のフレームの異常有無を判定し、フレームのＩＤごとに異常判定の結果を蓄積する。

異常検知部１４４は、複数のフレームに対する異常判定において状況Ｂが連続して生じる場合に、車両の状態を異常と判定する。具体的には、異常検知部１４４は、同じＩＤのフレームに対する判定結果が、所定のＮ回（例えば１０回）以上連続して状況Ｂに該当する場合、車両の状態を異常と判定する。

また、異常検知部１４４は、複数のフレームに対する異常判定において状況Ｂが断続的に生じる場合に、運転者モデルの再構築（言い換えれば再学習）を決定する。具体的には、異常検知部１４４は、１時間のうちに、複数種類のフレームのＩＤに亘って所定のＭ回（例えば２０回）以上状況Ｂに該当する場合、運転者モデルの再構築を決定する。例えば、１時間のうちに、ＩＤ「０１」の８個のフレームが状況Ｂに該当し、ＩＤ「０２」の７個のフレームが状況Ｂに該当し、ＩＤ「０３」の５個のフレームが状況Ｂに該当した場合、すなわち、１時間のうちに合計２０個のフレームが状況Ｂに該当した場合、異常検知部１４４は、運転者モデルの再構築を決定する。

運転者の運転習慣は変化する可能性があり、その変化に伴い、運転者モデルは変更されるべきである。ここで、運転習慣は、突然変化するものではなく、ある程度の時間をかけて徐々に変化するものである。そこで実施例では、運転の態様が運転者モデルには不整合だがデフォルトモデルには整合する状況Ｂが連続して生じる場合、運転習慣の変化に起因するものではなく異常と判定する。その一方、状況Ｂが断続的に生じる場合、運転習慣の変化に起因するものと判断し、運転者モデルの再構築を決定する。

図５に戻り、結果出力部１４６は、異常検知部１４４による異常判定の結果を示す判定結果データをＨＭＩ装置２０へ出力する。ＨＭＩ装置２０は、運転監視装置１８から出力された判定結果データを画面に表示させる。結果出力部１４６は、判定結果データとして、現在プライマリルールとして使用しているモデルの種類（デフォルトモデルまたは運転者モデル）と、判定結果（正常、異常、モデル再構築等）を設定してもよい。変形例として、ＨＭＩ装置２０は、所定のランプを判定結果に応じた色で点灯させてもよい。例えば、ＨＭＩ装置２０は、判定結果データが正常を示す場合、ランプを緑色で点灯させ、判定結果データが異常を示す場合、ランプを赤色で点灯させ、判定結果データがモデル再構築を示す場合、ランプを黄色で点灯させてもよい。別の変形例として、ＨＭＩ装置２０は、判定結果に応じた態様（所定の形状、模様、色彩等）のアイコンを画面に表示させてもよい。

以上の構成による第１実施例の運転監視装置１８の動作を説明する。
図８は、図１の運転監視装置１８の動作を示すフローチャートである。運転者情報取得部１３４は、ＨＭＩ装置２０から送信された運転者の識別情報を取得し、取得した運転者の識別情報を運転監視装置１８内のメモリに格納する（Ｓ１０）。運転者情報取得部１３４により取得された運転者の識別情報に対応する運転者モデルがモデル記憶部１３２に存在しなければ、すなわち、現在の運転者向けの運転者モデルが未作成であれば（Ｓ１２のＮ）、異常検知部１４４は、予め静的に定められたデフォルトモデルをプライマリルールとして用いた異常判定処理を開始する（Ｓ１４）。

デフォルトモデルに基づく異常判定処理と並行して、運転者モデルの生成処理を実行する。具体的には、運転者モデルの生成に必要なデータを収集する（Ｓ１６）。モデル生成部１４０は、収集されたフレームのデータに基づいて、運転者の運転の特徴を示す運転者モデルを動的に生成する（Ｓ１８）。

異常検知部１４４は、運転者モデルをプライマリルールとして用い、デフォルトモデルをセカンダリルールとして用いて、後述の異常判定処理を実行する（Ｓ２６）。結果出力部１４６は、異常検知部１４４による異常有無の判定結果をＨＭＩ装置２０へ送信し、ＨＭＩ装置２０は、異常有無の判定結果を画面に表示する（Ｓ２８）。運転者情報取得部１３４により取得された運転者の識別情報に対応する運転者モデルがモデル記憶部１３２に存在すれば、すなわち、現在の運転者向けの運転者モデルが作成済みであれば（Ｓ１２のＹ）、Ｓ１４〜Ｓ２４をスキップし、Ｓ２６へ進む。

所定の終了条件が満たされた場合（Ｓ３０のＹ）、本図のフローを終了する。所定の終了条件は、例えば、車両の電源がオフにされた場合、および／または、運転者により入力された異常判定処理の終了指示がＨＭＩ装置２０から入力された場合に満たされてもよい。所定の終了条件が満たされず（Ｓ３０のＮ）、Ｓ２６の判定結果が、運転者モデルの再構築であれば（Ｓ３２のＹ）、異常検知部１４４は、Ｓ２６で使用した運転者モデル（言い換えれば現在の運転者に対応する現在の運転者モデル）を破棄し、Ｓ１４に戻る。すなわち、デフォルトモデルによる異常判定処理へ移行し、新たな運転者モデルを構築する。Ｓ２６の判定結果が、運転者モデルの再構築以外（例えば正常または異常）であれば（Ｓ３２のＮ）、Ｓ２６に戻り、現在の運転者モデルに基づく異常判定処理を継続する。

図９は、図８のＳ１６のデータ収集処理の詳細を示すフローチャートである。フレーム受信部１３６は、ＣＡＮ２２のバスから第１フレーム〜第１４フレームを受信し、受信したフレームをフレーム記憶部１３０へ格納する（Ｓ４０）。データ量判定部１３８は、駐車運転時間Ｘが予め定められた閾値Ａ（例えば２分）以上であり（Ｓ４２のＹ）、かつ、駐車運転時間Ｘと一般走行時間Ｙと高速走行時間Ｚの合計時間が予め定められた閾値Ｂ（例えば５０分）以上である場合に（Ｓ４４のＹ）、運転者モデルの生成に必要な量のデータが蓄積されたと判定し、本図のフローを終了する。駐車運転時間Ｘが閾値Ａ未満（Ｓ４２のＮ）、または、上記の合計時間が閾値Ｂ未満である場合（Ｓ４４のＮ）、データ量判定部１３８は、運転者モデルの生成に必要なデータが不足していると判定し、Ｓ４０に戻る。

図１０は、図８のＳ２６の異常判定処理の詳細を示すフローチャートである。フレーム受信部１３６は、ＣＡＮ２２のバスから第１フレーム〜第１４フレームのいずれかを受信する（Ｓ６０）。異常検知部１４４は、受信されたフレームのデータが運転者モデルに整合する場合（Ｓ６２のＹ）、車両の状態を正常と判定する（Ｓ６４）。異常検知部１４４は、受信されたフレームのデータが運転者モデルに不整合であり（Ｓ６２のＮ）、かつ、デフォルトモデルにも不整合であれば（Ｓ６６のＮ）、走行中の車両の状態を異常と判定する（Ｓ６８）。

また、受信されたフレームのデータが運転者モデルに不整合であるが、運転者モデルには整合する状況（図７の状況Ｂ）が生じた場合（Ｓ６６のＹ）、異常検知部１４４は、フレームのＩＤごとに状況Ｂの発生状況を継続して監視する。異常検知部１４４は、共通のＩＤが付与された複数のフレームに亘って状況Ｂが連続Ｎ回発生した場合（Ｓ７０のＹ）、Ｓ６８へ進み、走行中の車両の状態を異常と判定する。共通のＩＤが付与された複数のフレームに亘って状況Ｂが連続Ｎ回発生していないが（Ｓ７０のＮ）、受信された全てのフレームを母集団として状況Ｂが断続的に発生した場合（Ｓ７２のＹ）、異常検知部１４４は、運転者モデルの再構築を決定する（Ｓ７４）。状況Ｂが断続的に発生することがなければ（Ｓ７２のＮ）、Ｓ７４をスキップし、本図のフローを終了する。この場合、図８のＳ３０のＮ、Ｓ３２のＮを辿ってＳ２６へ戻り、次のフレームに基づく異常判定処理を実行する。

（第２実施例）
図１１は、第２実施例の運転監視装置１８の機能構成を示すブロック図である。第２実施例の運転監視装置１８は、第１実施例での機能ブロックに加えて、モデル評価部１４２をさらに備える。図１１では、図５に示した機能ブロックと同一または対応する機能ブロックに同一の符号を付している。以下、第１実施例と重複する説明は適宜省略する。

モデル評価部１４２は、複数の評価項目のそれぞれについて運転者モデルがデフォルトモデルより優位か否かを評価する。複数の評価項目は、運転者モデルおよびデフォルトモデルの性能を評価する項目であり、実施例では、網羅率とモデル中心点からの平均距離の２つを含む。網羅率は、モデル生成時に使用されたフレームとは異なるフレームが示す運転の態様がモデルに整合する割合である。また、モデル中心点からの平均距離は、モデル生成時に使用されたフレームとは異なるフレームが示す運転の態様をモデルにマッピングした場合の位置と、モデルの中心点との距離の平均値である。モデルの中心点は、実施例ではモデルの重心であり、モデルの重心からの平均距離を以下「重心距離」と呼ぶ。

モデル評価部１４２は、運転者モデルの網羅率がデフォルトモデルの網羅率以上である場合に運転者モデルが優位と判定する。また、モデル評価部１４２は、運転者モデルにおける重心距離がデフォルトモデルにおける重心距離以下である場合に運転者モデルが優位と評価する。具体的には、モデル生成部１４０により運転者モデルが生成されると、フレーム記憶部１３０は、一定時間（例えば３０分間）、ＣＡＮ２２を流れる第１フレーム〜第１４フレームをモデル評価用データとして蓄積する。モデル評価部１４２は、モデル評価用データを使用して、（１）網羅率、（２）重心距離の２つにより運転者モデルを評価する。

（１）網羅率：

式１の「c」は網羅率を意味し、モデル評価用データに含まれるフレームの総数（p_all）に対するモデルに含まれるフレーム数（p_include）の割合を示すものである。モデル評価部１４２は、ＳＶＭ等の公知の手法により、モデルの外縁を構成する境界の内側にフレームが示すデータ（すなわち運転の態様）が含まれるか否かを判定してもよい。また、式２で示すように、モデル評価部１４２は、デフォルトモデルの網羅率（c_default）と、運転者モデルの網羅率（c_driver）の両方を算出する。モデル評価部１４２は、運転者モデルの網羅率がデフォルトモデルの網羅率以上である場合に、網羅率の観点から運転者モデルの方が優位と判定する。

（２）重心距離：

式３の「dist」は、モデルの重心からの平均距離を示す。具体的には、「dist」は、モデルの重心（c_rule）から、モデル評価用データに含まれる各フレームが示すデータをモデルにマッピングした位置（言い換えればモデルが存在する１４次元空間内にマッピングした位置）（p_i）までの距離を合計し、フレーム総数（N）で割った値である。また、式４で示すように、モデル評価部１４２は、デフォルトモデルにおける重心距離（dist_default）と、運転者モデルにおける重心距離（dist_driver）の両方を算出する。モデル評価部１４２は、運転者モデルにおける重心距離がデフォルトモデルにおける重心距離以下である場合に、モデルの重心からの平均距離の観点から運転者モデルの方が優位と判定する。

変形例として、モデル評価部１４２は、運転者モデルの重心からの距離を求める対象のフレームを、運転者モデルに含まれるフレームに限定してもよい。同様に、モデル評価部１４２は、デフォルトモデルの重心からの距離を求める対象のフレームを、デフォルトモデルに含まれるフレームに限定してもよい。

実施例のモデル評価部１４２は、網羅率と、重心距離との両方で運転者モデルの方が優位である場合に、運転者モデルがデフォルトモデルより優位と判定する。言い換えれば、モデル評価部１４２は、網羅率と重心距離の少なくとも一方で運転者モデルの方が劣位であれば、運転者モデルがデフォルトモデルより劣位と判定する。モデル評価部１４２は、運転者モデルがデフォルトモデルより優位と判定すると、異常判定のプライマリルールを運転者モデルに切り替える。

なお、モデル生成部１４０は、運転者モデルがデフォルトモデルより劣位と評価された場合、運転者モデルを更新する。具体的には、モデル生成部１４０は、評価対象の運転者モデルの生成時に用いたフレームとは異なるフレームに基づいて新たな運転者モデルを生成し、モデル評価部１４２は、その新たな運転者モデルを評価する。

異常検知部１４４は、異常判定のプライマリルールがデフォルトモデルの場合、フレーム受信部１３６により受信されたフレームの内容がデフォルトモデルに整合する場合に、車両の状態を正常と判定する。異常検知部１４４は、異常判定のプライマリルールが運転者モデルの場合、言い換えれば、モデル評価部１４２により運転者モデルがデフォルトモデルより優位と判定された場合、プライマリルールである運転者モデルと、セカンダリルールであるデフォルトモデルの両方に基づいて車両の異常有無を判定する。異常検知部１４４による判定処理は、第１実施例と同様である。

以上の構成による第２実施例の運転監視装置１８の動作を説明する。図１２は、第２実施例の運転監視装置１８の動作を示すフローチャートである。Ｓ８０〜Ｓ８８の処理は、図８のＳ１０〜Ｓ１８と同じであるため説明を省略する。モデル評価部１４２は、生成された運転者モデルとデフォルトモデルとの性能を比較する（Ｓ９０）。モデル評価部１４２は、運転者モデルがデフォルトモデルより劣位と評価した場合（Ｓ９２のＮ）、評価対象の運転者モデルのデータを廃棄するとともに、フレーム記憶部１３０に記憶されたフレームのデータを廃棄する（Ｓ９４）。そしてＳ８６に戻り、フレームの再収集と運転者モデルの再構築を実行する。

運転者モデルがデフォルトモデルより優位と評価された場合（Ｓ９２のＹ）、異常検知部１４４は、運転者モデルをプライマリルールとして用い、デフォルトモデルをセカンダリルールとして用いて、後述の異常判定処理を実行する（Ｓ９６）。Ｓ９６〜Ｓ１０２の処理は、図８のＳ２６〜Ｓ３２と同じであるため説明を省略する。

図１３は、図１２のＳ９０の性能比較処理の詳細を示すフローチャートである。モデル評価部１４２は３０分間待機し、その間に、フレーム受信部１３６は、ＣＡＮ２２のバスから第１フレーム〜第１４フレームを受信し、受信したフレームをフレーム記憶部１３０へ格納する。すなわち、フレーム記憶部１３０は、運転者モデル生成後の３０分間に受信された複数のフレームをモデル評価用データとして蓄積する（Ｓ１１０）。モデル評価部１４２は、モデル評価用データに対する運転者モデルの網羅率とデフォルトモデルの網羅率とを算出する。

運転者モデルの網羅率がデフォルトモデルの網羅率以上であれば（Ｓ１１２のＹ）、モデル評価部１４２は、モデル評価用データの各フレームが示す運転の態様を運転者モデルの空間内にマッピングする。モデル評価部１４２は、各フレームが示す運転の態様をマッピングした位置と、運転者モデルの重心との距離を求め、複数のフレームに亘る平均距離を重心距離として算出する。同様に、モデル評価部１４２は、モデル評価用データの各フレームが示す運転の態様をデフォルトモデルの空間内にマッピングする。モデル評価部１４２は、各フレームが示す運転の態様をマッピングした位置と、デフォルトモデルの重心との距離を求め、複数のフレームに亘る平均距離を重心距離として算出する。

モデル評価部１４２は、運転者モデルにおける重心距離がデフォルトモデルにおける重心距離以下であれば（Ｓ１１４のＹ）、運転者モデルがデフォルトモデルより性能面で優位と判定する（Ｓ１１６）。その一方、運転者モデルの網羅率がデフォルトモデルの網羅率未満であり（Ｓ１１２のＮ）、または、運転者モデルにおける重心距離がデフォルトモデルにおける重心距離より長ければ（Ｓ１１４のＮ）、運転者モデルがデフォルトモデルより性能面で劣位と判定する（Ｓ１１８）。

図１４（ａ）と図１４（ｂ）は、データ収集処理を時系列に示す。まず、図１４（ａ）を説明する。図１４（ａ）は、実施例におけるデータ収集処理を左から右へ時系列に示している。運転監視装置１８は、モデル生成用データを収集して運転者モデルを生成し、その後にモデル評価用データを収集して運転者モデルを評価する。タイミング（１）では、評価がＮＧ（すなわち運転者モデルが劣位）であったため、それまでに収集したデータを廃棄し、新たなモデル生成用データの収集を開始する。タイミング（２）では、評価がＯＫであったため、運転者モデルをプライマリルールとして設定し、デフォルトモデルをセカンダリルールとして設定する。

タイミング（３）は、運転者モデルを再構築すべきと判断されたタイミングである。このとき、それまでの運転者モデルを廃棄する。そして、デフォルトモデルより優位な新たな運転者モデルが生成されるまでは、デフォルトモデルのみを用いて異常検知処理を実行する。また、タイミング（３）では、新たなモデル生成用データの収集を開始する。

次に、図１４（ｂ）を説明する。図１４（ｂ）は、変形例におけるデータ収集処理を左から右へ時系列に示している。以下、図１４（ａ）と重複する説明は省略し、主に差分を説明する。同図のタイミング（１）では、運転者モデルに対する評価がＮＧであったが、この変形例では、それまでに収集したデータの少なくとも一部を次の運転者モデルを作成するためのデータとして使用する。図１４（ｂ）では、モデル評価用データを次のモデル生成用データとして使用し、すなわち、範囲１６０のデータを次のモデル生成用データとして使用する。これにより、モデル生成用データの収集時間を短縮でき、新たな運転者モデルの生成に要する時間を短縮できる。

また、タイミング（２）では、運転者モデルをプライマリルールとして設定し、デフォルトモデルをセカンダリルールとして設定した後に、フレーム受信部１３６およびフレーム記憶部１３０は、フレームのデータ（モデル生成用データ）の収集を継続する。これにより、運転者モデルを再構築すべきことが判断されたタイミング（３）で、モデル生成部１４０は、フレーム記憶部１３０に格納済のモデル生成用データを用いて新たな運転者モデルを生成することができ、新たな運転者モデルの生成に要する時間を短縮できる。

図１５は、プライマリルールとセカンダリルールの入替タイミングを示す。同図の（２）〜（４）は、図１４（ａ）の（１）〜（３）に対応する。図１５の（１）の時点では、運転者モデルが未作成であるため、デフォルトモデルをプライマリルールとした異常検知処理を実行する。（２）の時点では、運転者モデルが作成されたもののデフォルトモデルより劣位と評価されたため、デフォルトモデルをプライマリルールとした異常検知処理を継続する。（３）の時点では、作成された運転者モデルがデフォルトモデルより優位と評価されたため、運転者モデルをプライマリルールとし、デフォルトモデルをセカンダリルールとした異常検知処理へ切り替える。（４）の時点では、運転者モデルを再構築するため、現在の運転者モデルを廃棄するとともに、デフォルトモデルをプライマリルールとした異常検知処理に戻る。

以上、本発明を第１実施例および第２実施例をもとに説明した。これらの実施例は例示であり、各構成要素あるいは各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

上記実施例の異常検知部１４４は、ホワイトリスト方式にてフレームのデータの異常有無を判定した。変形例として、異常検知部１４４は、ブラックリスト方式にてフレームのデータの異常有無を判定してもよい。例えば、デフォルトモデルは、異常と考えられる運転の特徴、および／または、ＥＣＵ等に攻撃を受けている場合の車両走行の特徴を示すモデルであってもよい。この変形例において、異常検知部１４４は、フレームのデータがデフォルトモデルに整合する場合に、走行中の車両の状態を異常と判定してもよい。

上記実施例のモデル生成部１４０は、トランスミッションＥＣＵ１２、エンジンＥＣＵ１４、ブレーキＥＣＵ１６が出力する１４種類のデータに基づいて運転者モデルを生成した。実施例でのＥＣＵの種類、および、データの種類は例示であり、様々な変形例が考えられる。例えば、ステアリング部１１０に関連するデータを出力するＥＣＵは、ステアリングＥＣＵ（不図示）であってもよい。また、モデル生成部１４０は、１４種類より多いまたは少ないデータに基づいて運転者モデルを生成してもよい。

上記実施例のデータ量判定部１３８は、運転者モデルに必要な量のデータが収集されたか否かを時間に基づいて判定した。変形例として、データ量判定部１３８は、運転者モデルに必要な量のデータが収集されたか否かを、時間に代えてもしくは時間とともに、時間以外の要素に基づいて判定してもよい。時間以外の要素は、例えば、フレーム記憶部１３０に記憶されたフレームの個数であってもよく、フレーム記憶部１３０に記憶されたフレーム全体のデータ量であってもよい。

上記実施例の運転監視装置１８は、車両に搭載されることとしたが、変形例として、運転監視装置１８は、車両外部に設けられてもよい。例えば、インターネットを介して車両と接続されたクラウド上の情報処理装置（サーバ等）が、運転監視装置１８として機能してもよい。また、図５に示した運転監視装置１８の機能ブロックのうち、フレーム記憶部１３０、データ量判定部１３８、およびモデル生成部１４０をクラウド上の情報処理装置が備え、残りの機能ブロックを車両内の運転監視装置が備える構成でもよい。

また、図１１に示した運転監視装置１８の機能ブロックのうち、フレーム記憶部１３０、データ量判定部１３８、モデル生成部１４０、モデル記憶部１３２、およびモデル評価部１４２をクラウド上の情報処理装置が備え、残りの機能ブロックを車両内の運転監視装置が備える構成でもよい。また、図１１に示した運転監視装置１８の機能ブロックのうち、フレーム記憶部１３０、データ量判定部１３８、モデル生成部１４０、モデル記憶部１３２、モデル評価部１４２、異常検知部１４４をクラウド上の情報処理装置が備え、残りの機能ブロックを車両内の運転監視装置が備える構成でもよい。

なお、実施例および変形例に記載の技術は、以下の項目によって特定されてもよい。
［項目１］
正常な運転の特徴を示す予め定められたモデルとして特定の運転者に非依存のデフォルトモデルと、特定の運転者の運転特徴を示す運転者モデルと、を記憶する記憶部と、
ネットワークを介して、運転の態様を示す運転情報を受信する受信部と、
前記運転情報の内容が前記運転者モデルに整合する場合、前記特定の運転者によって運転された車両の状態を正常と判定する検知部と、
を備える監視装置。
この監視装置によると、特定の運転者によって運転された車両の異常を検知する精度を向上することができる。
［項目２］
前記検知部は、前記運転情報の内容が前記運転者モデルに不整合の状態で、かつ、前記運転情報の内容が前記デフォルトモデルに整合する状態が連続して生じる場合、前記車両の状態を異常と判定する、
項目１に記載の監視装置。
運転者の運転習慣は、突然に変化するものではなく、徐々に変化していくものである。本項目の態様によると、運転者の運転習慣の変化ではない運転または車両の異常を精度よく検知することができる。
［項目３］
前記検知部は、前記運転情報の内容が前記運転者モデルに不整合の状態で、かつ、前記運転情報の内容が前記デフォルトモデルに整合する状態が断続的に生じる場合、前記運転者モデルの更新を決定する、
項目１または２に記載の監視装置。
運転者の運転習慣は、突然に変化するものではなく、徐々に変化していくものである。本項目の態様によると、運転者の運転習慣が変化したことを検知して、運転者の運転習慣に追従するように運転者モデルを後進することができる。
［項目４］
前記運転者モデルを生成する生成部をさらに備える、
項目１乃至３のいずれかに記載の監視装置。
この態様によると、特定の運転者の運転特徴に応じた運転者モデルを動的に生成し、異常の検知精度を向上することができる。
［項目５］
前記検知部は、前記生成部によって前記運転者モデルが生成されていない場合、前記運転情報の内容が前記デフォルトモデルに整合する場合、運転者によって運転された車両の状態を正常と判定する、
項目４に記載の監視装置。
この態様によると、運転者モデルが未生成の状況でも、デフォルトモデルを使用して、運転された車両の状態を判定することができる。
［項目６］
所定の評価項目について前記運転者モデルが前記デフォルトモデルより優位かを評価する評価部をさらに備え、
前記検知部は、前記運転者モデルが前記デフォルトモデルより優位と評価された場合、前記運転者モデルを用いて、前記車両の状態が正常かを判定する、
項目１乃至５のいずれかに記載の監視装置。
この態様によると、デフォルトモデルより性能面で優位な運転者モデルが得られた場合に、運転者モデルを用いて車両の異常を検知することで、異常の検知精度を向上することができる。
［項目７］
所定の評価項目について前記運転者モデルが前記デフォルトモデルより優位かを評価する評価部をさらに備え、
前記生成部は、前記運転者モデルが前記デフォルトモデルより劣位と評価された場合、前記運転者モデルを更新する、
項目４または５に記載の監視装置。
この態様によると、デフォルトモデルより性能がよい運転者モデルを生成しやすくなる。
［項目８］
前記評価部は、前記運転者モデルの網羅率が前記デフォルトモデルの網羅率以上である場合、前記運転者モデルが優位と評価し、網羅率は、前記運転者モデルの生成時に使用された第一の運転情報とは異なる第二の運転情報の内容がモデルに整合する割合である、
項目６または７に記載の監視装置。
この態様によると、運転者による実際の運転の態様に則した運転者モデルを異常判定に使用することができる。
［項目９］
前記運転者モデルにおける重心距離が前記デフォルトモデルにおける重心距離以下である場合、前記運転者モデルが優位と評価し、重心距離は、前記運転者モデルの生成時に使用された第一の運転情報とは異なる第二の運転情報の内容をモデルにマッピングした場合の位置と前記モデルの重心との距離である、
項目６または７に記載の監視装置。
この態様によると、運転者モデルのサイズ、言い換えれば、運転者モデルに該当する値の範囲が過度に大きくならないように抑制することができる。
［項目１０］
前記生成部は、駐車時の運転の態様を示す運転情報が所定量以上受信されたとき、前記運転者モデルを生成する、
項目４に記載の監視装置。
この態様によると、運転者による運転の特徴が現れやすい駐車時の運転の態様を運転者モデルに反映させることができ、異常検知の精度を一層向上させることができる。
［項目１１］
前記生成部は、駐車時運転を含む複数の運転状況のそれぞれにおける運転特徴を示す複数の運転情報が所定量以上受信されたとき、前記複数の運転情報のそれぞれが示す運転の態様に応じて、運転者モデルを生成する、
項目４に記載の監視装置。
この態様によると、運転者による運転の特徴が現れやすい駐車時を含む複数の運転状況における運転の態様を運転者モデルに反映させることができ、異常検知の精度を一層向上させることができる。
［項目１２］
運転者の運転の特徴を示す運転者モデルを記憶部に記憶する監視装置が、
ネットワークを介して、運転の態様を示す運転情報を受信し、
前記運転情報の内容が前記運転者モデルに整合する場合、前記運転者によって運転された車両の状態を正常と判定する、
監視方法。
この監視方法によると、運転者によって運転された車両の異常を検知する精度を向上することができる。
［項目１３］
運転者の運転の特徴を示す運転者モデルを記憶部に記憶する監視装置に、
ネットワークを介して、運転の態様を示す運転情報を受信し、
前記運転情報の内容が前記運転者モデルに整合する場合、前記運転者によって運転された車両の状態を正常と判定する、
ことを実行させるためのコンピュータプログラム。
このコンピュータプログラムによると、運転者によって運転された車両の異常を検知する精度を向上することができる。

上述した実施例および変形例の任意の組み合わせもまた本発明の実施の形態として有用である。組み合わせによって生じる新たな実施の形態は、組み合わされる実施例および変形例それぞれの効果をあわせもつ。また、請求項に記載の各構成要件が果たすべき機能は、実施例および変形例において示された各構成要素の単体もしくはそれらの連携によって実現されることも当業者には理解されるところである。

１０ 車載ネットワークシステム、 １８ 運転監視装置、 ２２ ＣＡＮ、 １３０ フレーム記憶部、 １３２ モデル記憶部、 １３６ フレーム受信部、 １４０ モデル生成部、 １４２ モデル評価部、 １４４ 異常検知部。

Claims (13)

1. 正常な運転の特徴を示す予め定められたモデルとして特定の運転者に非依存のデフォルトモデルと、特定の運転者の運転特徴を示す運転者モデルと、を記憶する記憶部と、
   ネットワークを介して、運転の態様を示す運転情報を受信する受信部と、
   前記運転情報の内容が前記運転者モデルに整合する場合、前記特定の運転者によって運転された車両の状態を正常と判定する検知部と、
   を備える監視装置。
2. 前記検知部は、前記運転情報の内容が前記運転者モデルに不整合の状態で、かつ、前記運転情報の内容が前記デフォルトモデルに整合する状態が連続して生じる場合、前記車両の状態を異常と判定する、
   請求項１に記載の監視装置。
3. 前記検知部は、前記運転情報の内容が前記運転者モデルに不整合の状態で、かつ、前記運転情報の内容が前記デフォルトモデルに整合する状態が断続的に生じる場合、前記運転者モデルの更新を決定する、
   請求項１または２に記載の監視装置。
4. 前記運転者モデルを生成する生成部をさらに備える、
   請求項１乃至３のいずれかに記載の監視装置。
5. 前記検知部は、前記生成部によって前記運転者モデルが生成されていない場合、前記運転情報の内容が前記デフォルトモデルに整合する場合、運転者によって運転された車両の状態を正常と判定する、
   請求項４に記載の監視装置。
6. 所定の評価項目について前記運転者モデルが前記デフォルトモデルより優位かを評価する評価部をさらに備え、
   前記検知部は、前記運転者モデルが前記デフォルトモデルより優位と評価された場合、前記運転者モデルを用いて、前記車両の状態が正常かを判定する、
   請求項１乃至５のいずれかに記載の監視装置。
7. 所定の評価項目について前記運転者モデルが前記デフォルトモデルより優位かを評価する評価部をさらに備え、
   前記生成部は、前記運転者モデルが前記デフォルトモデルより劣位と評価された場合、前記運転者モデルを更新する、
   請求項４または５に記載の監視装置。
8. 前記評価部は、前記運転者モデルの網羅率が前記デフォルトモデルの網羅率以上である場合、前記運転者モデルが優位と評価し、網羅率は、前記運転者モデルの生成時に使用された第一の運転情報とは異なる第二の運転情報の内容がモデルに整合する割合である、
   請求項６または７に記載の監視装置。
9. 前記運転者モデルにおける重心距離が前記デフォルトモデルにおける重心距離以下である場合、前記運転者モデルが優位と評価し、重心距離は、前記運転者モデルの生成時に使用された第一の運転情報とは異なる第二の運転情報の内容をモデルにマッピングした場合の位置と前記モデルの重心との距離である、
   請求項６または７に記載の監視装置。
10. 前記生成部は、駐車時の運転の態様を示す運転情報が所定量以上受信されたとき、前記運転者モデルを生成する、
    請求項４に記載の監視装置。
11. 前記生成部は、駐車時運転を含む複数の運転状況のそれぞれにおける運転特徴を示す複数の運転情報が所定量以上受信されたとき、前記複数の運転情報のそれぞれが示す運転の態様に応じて、運転者モデルを生成する、
    請求項４に記載の監視装置。
12. 運転者の運転の特徴を示す運転者モデルを記憶部に記憶する監視装置が、
    ネットワークを介して、運転の態様を示す運転情報を受信し、
    前記運転情報の内容が前記運転者モデルに整合する場合、前記運転者によって運転された車両の状態を正常と判定する、
    監視方法。
13. 運転者の運転の特徴を示す運転者モデルを記憶部に記憶する監視装置に、
    ネットワークを介して、運転の態様を示す運転情報を受信し、
    前記運転情報の内容が前記運転者モデルに整合する場合、前記運転者によって運転された車両の状態を正常と判定する、
    ことを実行させるためのコンピュータプログラム。

Images