JP7322806B2 - 車両用異常検出装置 - Google Patents

Description

本発明は、車両用異常検出装置に関する。

特許文献１には、車両制御の状態を把握するための電子制御装置が開示されている。具体的には、この電子制御装置は、予め設定されている監視前提条件が成立した際に、制御入力データ及び実行内容データの少なくとも一方を含む監視データを蓄積するように構成されている。また、データ送信要求を受け付けた際に、蓄積した監視データを外部装置へ送信することで、外部装置が制御入力データ及び実行内容データ等を用いて制御出力結果に至った要因を解析できる構成とされている。

特開２０１９－０３８３３１号公報

しかしながら、上記特許文献１に記載の技術では、車載ネットワーク上で異常が発生したことしか検出することができず、異常が発生した原因を解析するには手間を要する。

本発明は上記事実を考慮し、車載ネットワーク上で発生した異常の原因を効率良く解析することができる車両用異常検出装置を得ることを目的とする。

請求項１に記載の車両用異常検出装置は、ファイアウォールを介して多数階層で構成された車載ネットワークにおいて、複数の制御装置のうち異常が検出された一の制御装置の異常情報を受信する送受信部と、前記送受信部によって受信された前記一の制御装置の異常の原因となり得る他の制御装置の候補を取得する異常原因候補取得部と、前記異常原因候補取得部で取得された候補から、前記一の制御装置の異常が検出された時刻以前に異常が発生している前記他の制御装置があれば、当該他の制御装置を前記一の制御装置と共に異常原因制御装置として管理する異常情報管理部と、を有する。

請求項１に記載の車両用異常検出装置では、車載ネットワークはファイアウォールを介して多数階層で構成されており、複数の制御装置を備えている。ここで、送受信部は、異常が検出された一の制御装置の異常情報を受信する。また、異常原因候補取得部は、異常の原因となり得る他の制御装置の候補を取得する。

さらに、異常原因候補取得部で取得された候補から、一の制御装置の異常が検出された時刻以前に異常が発生している他の制御装置があった場合、異常情報管理部が当該他の制御装置を異常原因制御装置として管理する。このとき、異常情報管理部は、一の制御装置と共に他の制御装置を異常原因制御装置として管理するため、異常発生の原因となった制御装置を容易に特定することができる。

請求項２に記載の車両用異常検出装置は、請求項１において、前記異常原因制御装置の異常が検出された時刻以前に異常が発生している他の制御装置があった場合には、当該他の制御装置を新たに異常原因制御装置として管理する。

請求項２に記載の車両用異常検出装置では、一の制御装置の異常検出時刻以前に異常が発生している他の制御装置が異常原因制御装置として管理され、この異常原因制御装置の異常検出時刻以前に異常が発生している他の制御装置が新たな異常原因制御装置として管理される。これにより、異常の発端となった制御装置を容易に把握することができる。

請求項３に記載の車両用異常検出装置は、請求項１又は２において、前記車載ネットワークは、外部通信手段を有する第１階層を含んで構成されており、前記異常原因候補取得部は、前記一の制御装置と同階層の制御装置、及び、前記同階層に対して前記第１階層側に隣接する階層と前記同階層とを接続する制御装置を候補として取得する。

請求項３に記載の車両用異常検出装置では、外部通信手段を有する第１階層側に隣接する制御装置を候補として取得することで、外部からの攻撃が原因で発生した異常を早期に検出することができる。

請求項４に記載の車両用異常検出装置は、請求項１～３の何れか１項において、前記異常情報管理部によって管理された前記異常原因制御装置の異常が外部通信に関する異常であった場合に、外部からの攻撃であると特定する攻撃特定部をさらに備えている。

請求項４に記載の車両用異常検出装置では、攻撃特定部によって外部からの攻撃を特定することで、早期に攻撃に対する対策及び復旧を行うことができる。

請求項５に記載の車両用異常検出装置は、請求項１～４の何れか１項において、前記送受信部、前記異常原因候補取得部及び前記異常情報管理部の機能を実現するモジュールが車両に設けられている。

請求項５に記載の車両用異常検出装置では、車両の外部にモジュールが設けられた構成と比較して、攻撃発生に対する検出を迅速に行うことができる。

以上説明したように、本発明に係る車両用異常検出装置によれば、車載ネットワーク上で発生した異常の原因を効率良く解析することができる。

第１実施形態に係る車両用異常検出装置を含む車載ネットワークの全体構成を示すブロック図である。 第１実施形態に係る車両用異常検出装置のハードウェア構成を示すブロック図である。 第１実施形態に係る車両用異常検出装置の機能構成を示すブロック図である。 第１実施形態に係る車両用異常検出装置による異常検出処理の流れの一例を示すフローチャートである。 第２実施形態に係る車両用異常検出装置を含む車載ネットワークの全体構成を示すブロック図である。 第３実施形態に係る車両用異常検出装置を含む車載ネットワークの全体構成を示すブロック図である。

＜第１実施形態＞
第１実施形態に係る車両用異常検出装置１０（以下、適宜「異常検出装置１０」と称する。）について、図面を参照して説明する。

図１には、異常検出装置１０が適用された車載ネットワーク１２の全体構成が示されている。この車載ネットワーク１２は、ファイアウォールを介して多数階層で構成されており、本実施形態では一例として、第１階層ＣＬ１、第２階層ＣＬ２及び第３階層ＣＬ３の３つの階層で構成されている。

第１階層ＣＬ１は、最も外側の階層であり、外部通信手段を有する制御装置を備えた階層とされている。本実施形態では一例として、第１階層ＣＬ１はＴＣＵ（Telematics Communication Unit）１４及びＩＶＩ（In-Vehicle Infotainment）１６を備えている。また、ＴＣＵ１４及びＩＶＩ１６はそれぞれ、制御装置であるＥＣＵ（Electronic Control Unit）の一種であり、自ＥＣＵのホストログを記録するための記憶領域を備えている。なお、ＩＶＩ１６とは、車載したＩＴ機器等によって情報及び娯楽を提供するシステムのことを指す。また、ＴＣＵ１４は、車両１１の外部のセンタ１８と無線通信を行うことができるように構成されており、センタ１８には車両１１とのデータの送受信の履歴であるＯＴＡ履歴を記憶する記憶領域を備えている。

第２階層ＣＬ２は、イーサネットスイッチ２０、ゲートウェイ２２、イーサネットＩＤＳ（Intrusion Detection System）２４を備えており、ファイアウォールとなるイーサネットスイッチ２０を介して第１階層ＣＬ１と第２階層ＣＬ２とが接続されている。イーサネットスイッチ２０、ゲートウェイ２２、イーサネットＩＤＳ２４は何れもＥＣＵであり、イーサネットスイッチ２０とＴＣＵ１４及びＩＶＩ１６とがそれぞれイーサネット（登録商標）の通信線によって接続されている。

また、イーサネットスイッチ２０とイーサネットＩＤＳ２４とがイーサネットの通信線で接続されており、イーサネットスイッチ２０とゲートウェイ２２とがイーサネットの通信線で接続されている。さらに、本実施形態の異常検出装置１０は、イーサネットスイッチ２０及びゲートウェイ２２に接続されている。具体的には、異常検出装置１０とイーサネットスイッチ２０とがイーサネットの通信線で接続されており、異常検出装置１０とゲートウェイ２２とがＣＡＮ（Controller Area Network）の通信線で接続されている。異常検出装置１０の詳細については後述する。

第３階層ＣＬ３は、ＥＣＵａ２６、ＥＣＵｂ２８、ＥＣＵｃ３０及びＣＡＮＩＤＳ３２を備えており、これらがＣＡＮの通信線によってゲートウェイ２２と接続されている。すなわち、ファイアウォールとなるゲートウェイ２２を介して第２階層ＣＬ２と第３階層ＣＬ３とが接続されている。

ＥＣＵａ２６、ＥＣＵｂ２８及びＥＣＵｃ３０は、それぞれ異なる車両制御を行うＥＣＵとされており、特にＥＣＵａ２６は、走行制御を行う高性能のＥＣＵとされており、自ＥＣＵのホストログを記録するための記憶領域を備えている。

（異常検出装置１０のハードウェア構成）
図２には、異常検出装置１０のハードウェア構成のブロック図が図示されている。この図２に示されるように、異常検出装置１０は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）４２、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）４４、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）４６、ストレージ４８及び通信インタフェース５０を含んで構成されている。各構成は、バス５２を介して相互に通信可能に接続されている。また、ＣＰＵ４２はプロセッサの一例であり、ＲＡＭ４６はメモリの一例である。

ＣＰＵ４２は、中央演算処理ユニットであり、各種プログラムを実行したり、各部を制御したりする。すなわち、ＣＰＵ４２は、ＲＯＭ４４又はストレージ４８からプログラムを読み出し、ＲＡＭ４６を作業領域としてプログラムを実行する。ＣＰＵ４２は、ＲＯＭ４４又はストレージ４８に記録されているプログラムに従って、上記各構成の制御および各種の演算処理を行う。

ＲＯＭ４４は、各種プログラムおよび各種データを格納する。ＲＡＭ４６は、作業領域として一時的にプログラム又はデータを記憶する。ストレージ４８は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）又はＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）により構成され、オペレーティングシステムを含む各種プログラム、及び各種データを格納する。本実施形態では、ＲＯＭ４４には、異常検出処理を行うための異常検出プログラム等が格納されている。

通信インタフェース５０は、異常検出装置１０が他の制御装置とコンピュータネットワークによって通信するためのインタフェースであり、たとえば、イーサネット、ＣＡＮ等の規格が用いられる。

（車両用異常検出装置１０の機能構成）
車両用異常検出装置１０は、上記のハードウェア資源を用いて、各種の機能を実現する。車両用異常検出装置１０が実現する機能構成について図３を参照して説明する。

図３に示されるように、車両用異常検出装置１０は、機能構成として、送受信部５４、車載ネットワーク情報管理部５６、車載ネットワーク情報記憶部５８、車載ログ管理部６０、車載ログ記憶部６２、正常定義情報管理部６４、正常定義情報記憶部６６、異常情報管理部６８、異常情報記憶部７０、異常原因候補取得部７２、異常判定部７４及び攻撃特定部７６を含んで構成されている。各機能構成は、ＣＰＵ４２がＲＯＭ４４又はストレージ４８に記憶されたプログラムを読み出し、実行することにより実現される。

送受信部５４は、イーサネット及びＣＡＮ等を介して、車載ネットワーク１２上の各ＥＣＵのログ及び解析結果等の送受信を行う。また、送受信部５４は、車載ネットワーク１２を構成する各ＥＣＵのうち異常が検出されたＥＣＵの異常情報を受信するように構成されている。さらに、送受信部５４は、異常情報管理部６８で管理されている異常情報及び攻撃特定部７６で外部からの攻撃として特定された事象をセンタ１８へ送信する機能を備えている。

車載ネットワーク情報管理部５６は、車載ネットワーク１２の構成に関する情報、及び車載ネットワーク１２上の各ＥＣＵが記録しているログの情報を管理する。また、車載ネットワーク情報記憶部５８は、車載ネットワーク１２の情報を記憶する機能であり、本実施形態では、車載ネットワーク情報記憶部５８は、構成情報とＥＣＵ情報とが記憶されている。構成情報とは、車載ネットワーク１２の階層数及び各階層に接続されているＥＣＵに関する情報である。また、ＥＣＵ情報とは、各ＥＣＵが扱うプロトコルと各ＥＣＵによって記録されるログ情報に関する情報である。このため、ＥＣＵ情報を参照すれば、例えば、ＴＣＵ１４に、外部通信ログ、システム監査ログ及び故障コードログが記録されることが分かる。そして、車載ネットワーク情報管理部５６は、構成情報及びＥＣＵ情報が変更された場合に、車載ネットワーク情報記憶部５８に記憶されている情報の更新を行う。

車載ログ管理部６０は、車載ネットワーク１２上のＥＣＵで記録されるログを取得して管理する。また、車載ログ記憶部６２は、車載ログ管理部６０によって取得されたログを記憶する機能であり、センタ１８のＯＴＡ履歴等もログとして記憶する。車載ログ管理部６０によるログの取得は、各ＥＣＵから自動的に送信されることで取得してもよい。また、車載ログ管理部６０によって各ＥＣＵへログの送信を命令することで取得してもよい。ここで、全てのログには、車内で同期のとれたクロックによってタイムスタンプが付与されるように構成されている。例えば、ＴＣＵ１４の外部通信ログとして、タイムスタンプが付与されたログが記録されており、この外部通信ログが車載ログ記憶部６２に記憶される。

正常定義情報管理部６４は、各ＥＣＵで記録するログの正常定義情報を管理する。また、正常定義情報記憶部６６は、正常定義情報をＥＣＵ毎に記憶する。ここでいう正常定義情報とは、正常定義に関するルール、及びホワイトリスト等である。そして、正常定義情報記憶部６６は、車載ネットワーク情報記憶部５８に格納されたＥＣＵ情報に記載されているＥＣＵの各種のログに対して正常定義を記憶する。すなわち、正常定義情報記憶部６６は、車載ログ記憶部６２に記憶されている車載ログのそれぞれに対して正常定義を記憶している。このため、車載ネットワーク情報管理部５６によってＥＣＵ情報が更新された際には、車載ログ管理部６０で管理されるログの情報も更新され、正常定義情報管理部６４がログに対応する正常定義情報を更新する。

異常情報管理部６８は、車両１１で検出された異常情報を管理する機能であり、例えば、異常情報管理部６８は、イーサネットＩＤＳ２４及びＣＡＮＩＤＳ３２の検出結果を管理する。また、異常情報管理部６８は、車載ログのうち、正常定義から外れた事象を異常情報として管理する。このとき、異常情報は、攻撃特定の解析単位でまとめて管理される。異常情報記憶部７０は、車両１１での異常情報を記憶する機能であり、車載ネットワーク１２上のＥＣＵからの異常通知を記憶する。

異常原因候補取得部７２は、送受信部５４によって受信された一のＥＣＵの異常の原因となり得る他のＥＣＵの候補を異常原因ＥＣＵとして取得する。具体的には、異常原因候補取得部７２は、一のＥＣＵと同階層のＥＣＵ、及び、同階層に対して第１階層ＣＬ１側に隣接する階層と同階層とを接続するＥＣＵを異常原因ＥＣＵとして取得する。例えば、図１において、送受信部５４がＣＡＮＩＤＳ３２から異常情報を受信した場合、異常原因候補取得部７２は、ＣＡＮＩＤＳ３２と同階層のＥＣＵであるＥＣＵａ２６を異常原因ＥＣＵとして取得する。また、異常原因候補取得部７２は、ＣＡＮＩＤＳ３２に対して第１階層ＣＬ１側に隣接する第２階層ＣＬ２と第３階層ＣＬ３とを接続するゲートウェイ２２を異常原因ＥＣＵとして取得する。なお、本実施形態の異常原因候補取得部７２は、ＣＡＮＩＤＳ３２と同階層のＥＣＵであっても、ログを保持しないＥＣＵｂ２８及びＥＣＵｃ３０は異常原因の候補として取得しない。

異常判定部７４は、車載ログと正常定義情報とを比較し、車載ログのうち正常定義情報から外れた事象を異常と判定する。すなわち、異常判定部７４は、車載ログ記憶部６２に記憶されている車載ログと、正常定義情報記憶部６６に記憶されている正常定義情報とを取得し、これらを比較することで異常な事象であるか否かを判定する。そして、異常であると判定された場合は、異常情報管理部６８により異常情報として管理される。

ここで、異常情報管理部６８は、異常原因候補取得部７２で取得された候補から、一のＥＣＵの異常が検出された時刻以前に異常が発生している他のＥＣＵがあれば、他のＥＣＵを一のＥＣＵと共に異常原因ＥＣＵとして管理する。

また、異常情報管理部６８は、一のＥＣＵと共に他のＥＣＵが異常原因ＥＣＵとして管理されている場合において、他の異常原因ＥＣＵの異常が検出された時刻以前に異常が発生している、さらに他のＥＣＵがあった場合には、このＥＣＵを新たに異常原因ＥＣＵとして管理する。すなわち、異常情報管理部６８は、送受信部５４によって受信された一のＥＣＵの異常情報から時刻を遡りながら異常が発生しているＥＣＵをまとめて異常原因ＥＣＵとして異常情報記憶部７０に記憶させる。

攻撃特定部７６は、イーサネットＩＤＳ２４及びＣＡＮＩＤＳ３２による異常検出をトリガとして、外部からの攻撃を特定する。具体的には、攻撃特定部７６は、異常情報管理部６８によって管理された異常原因ＥＣＵの異常が外部通信に関する異常であった場合に、外部からの攻撃であると特定する。

（作用）
次に、本実施形態の作用を説明する。

（異常検出処理の一例）
図４は、車両用異常検出装置１０による異常検出処理の流れの一例を示すフローチャートである。この異常検出処理は、ＣＰＵ４２がＲＯＭ４４又はストレージ４８からプログラムを読み出して、ＲＡＭ４６に展開して実行することによって実行される。また、本実施形態の異常検出処理は、送受信部５４によって異常情報が受信された場合に実行される（受信ステップ）。

図４に示されるように、ＣＰＵ４２は、ステップＳ１０２で異常情報が実際にログに記録されているか否かについて判定する。具体的には、ＣＰＵ４２は、車載ログ記憶部６２に記憶されている車載ログの中から異常の発生時刻の車載ログを参照して、異常ログが存在しているか否かを確認する。そして、ＣＰＵ４２は、ステップＳ１０２で異常ログが確認された場合は、ステップＳ１０４の処理へ移行する。

一方、ＣＰＵ４２は、ステップＳ１０２で異常の発生時刻に異常ログが確認されなかった場合は、ステップＳ１２４の処理へ移行する。ＣＰＵ４２は、ステップＳ１２４で誤報処理を行う。すなわち、ＣＰＵ４２は、誤報であった旨のログを残す。そして、ＣＰＵ４２は、異常検出処理を終了する。

ＣＰＵ４２は、異常ログが確認された場合は、ステップＳ１０４で異常発生の原因候補となるＥＣＵを取得する（異常原因候補取得ステップ）。具体的には、ＣＰＵ４２は、異常原因候補取得部７２の機能により、送受信部５４によって受信された一のＥＣＵの異常の原因となり得る他のＥＣＵの候補を異常原因ＥＣＵとして取得する。すなわち、ＣＰＵ４２は、一のＥＣＵと同階層のＥＣＵ、及び、同階層に対して第１階層ＣＬ１側に隣接する階層と同階層とを接続するＥＣＵを異常原因ＥＣＵとして取得する。

次に、ＣＰＵ４２は、ステップＳ１０６で解析の優先度が高い順番にＥＣＵを並べ替える。具体的には、ＣＰＵ４２は、異常原因候補取得部７２によって取得された複数の異常原因ＥＣＵを所定のルールに基づいて並べ替える。ここでいう所定のルールとは、各ＥＣＵに重み付けを行い、この重み付けの数値の大きさによって異常原因ＥＣＵを並べ替えるものであり、例えば、第３階層ＣＬ３から第１階層ＣＬ１へ向かうにつれて重み付けの数値が大きくなるように設定してもよい。また、外部通信手段を備えたＥＣＵが外部通信手段を備えていないＥＣＵよりも重み付けの数値が大きくなるように設定してもよい。さらに、高機能のＥＣＵほど重み付けの数値が大きくなるように設定してもよい。

続いて、ＣＰＵ４２は、ステップＳ１０８で解析の優先度順に並べ替えられたＥＣＵに対して、順番に異常の発生検出時刻以前に故障ログがあったか否かについて判定する。具体的には、ＣＰＵ４２は、車載ネットワーク情報記憶部５８に記憶されている各ＥＣＵのログ情報を参照し、異常の発生検出時刻以前に故障ログがあった場合は、ステップＳ１２２の処理へ移行する。そして、ＣＰＵ４２は、ステップＳ１２２で送受信部５４によって受信された異常情報が故障によるものだったとしてセンタ１８へ解析結果を出力する。このとき、ＣＰＵ４２は、故障コードをセンタ１８へ通知する。そして、ＣＰＵ４２は、異常検出処理を終了させる。

一方、ＣＰＵ４２は、異常の発生検出時刻以前に故障ログがなかった場合は、ステップＳ１１０の処理へ移行し、優先度順に並べ替えられたＥＣＵのそれぞれに対して、故障ログを除く全ての車載ログを列挙する。

次に、ＣＰＵ４２は、ステップＳ１１２で列挙された車載ログと正常定義とを比較する。具体的には、ＣＰＵ４２は、異常判定部７４の機能により、車載ログと正常定義情報とを順番に比較する。

ＣＰＵ４２は、ステップＳ１１４で異常の発生検出時刻以前に異常ログが有ったか否かについて判定する。具体的には、ＣＰＵ４２は、ステップＳ１１２で車載ログと正常定義とを比較して、正常定義から外れたログが確認された時点で、ステップＳ１１４に移行して異常有りとして判定され、ステップＳ１１６の処理へ移行される。すなわち、ステップＳ１１２では、異常ログが確認された時点で、車載ログと正常定義との比較の処理が終了される。ステップＳ１１６の処理については後述する。

ＣＰＵ４２は、ステップＳ１１４で異常の発生検出時刻以前に異常ログが無かったと判定した場合、すなわち、ステップＳ１１２で列挙された全ての車載ログと正常定義とを比較した結果、異常ログが確認されなかった場合は、ステップＳ１２０の処理へ移行する。

ＣＰＵ４２は、ステップＳ１２０で送受信部５４によって受信された異常の原因が判別不能であるとしてセンタ１８へ解析結果を出力する。このとき、ＣＰＵ４２は、解析を人に引継ぐために、ステップＳ１１２で正常定義と比較を行った車載ログの情報をセンタ１８へ通知する。そして、ＣＰＵ４２は、異常検出処理を終了させる。

一方、ステップＳ１１４に移行して異常有りとして判定された場合、ＣＰＵ４２は、ステップＳ１１６で外部通信のログであるか否かについて判定する。具体的には、ＣＰＵ４２は、ステップＳ１１４で検出された異常ログが外部通信に関するログであった場合、ステップＳ１１８の処理へ移行する。

ＣＰＵ４２は、ステップＳ１１８で、攻撃特定部７６の機能により、送受信部５４によって受信された異常情報が外部からの攻撃であると特定してセンタ１８へ解析結果を出力する。このとき、ＣＰＵ４２は、解析に使った異常情報の一式をセンタ１８へ通知する。そして、ＣＰＵ４２は、異常検出処理を終了させる。

また、ＣＰＵ４２は、ステップＳ１１４では、異常ログが外部通信に関するログではない場合、ステップＳ１２６の処理へ移行する。そして、ＣＰＵ４２は、ステップＳ１２６で異常情報管理部６８の機能により、ステップＳ１１４で検出された異常ログを保持するＥＣＵを新たな異常原因ＥＣＵとして管理する（異常情報管理ステップ）。そして、新たな異常原因ＥＣＵに対して、ステップＳ１０４移行の処理を行う。

以上のように、本実施形態では、異常原因候補取得部７２で取得された候補から、一のＥＣＵの異常が検出された時刻以前に異常が発生している他のＥＣＵがあった場合、当該他のＥＣＵを異常原因ＥＣＵとして管理する（ステップＳ１２６参照）。このとき、異常情報管理部６８は、一のＥＣＵと共に他のＥＣＵを異常原因ＥＣＵとして管理することで、異常発生の原因となったＥＣＵを容易に特定することができる。これにより、復旧を効率よく行うことができる。

また、本実施形態では、ステップＳ１２６で新たな異常原因ＥＣＵとして管理されたＥＣＵに対して、ステップＳ１１４で異常検出時刻以前に異常が発生している他のＥＣＵが検出された場合、このＥＣＵを新たな異常原因ＥＣＵとして管理する。これにより、異常の原因となるＥＣＵを遡って解析することができ、異常の発端となったＥＣＵを容易に把握することができる。

さらに、本実施形態では、ステップＳ１１６の処理で、攻撃特定部７６によって異常ログが外部通信に関するログである場合、攻撃であると特定する。これにより、外部からの攻撃との関連性を示す情報を集めることができる。

さらにまた、本実施形態では、ステップＳ１０４で外部通信手段を有する第１階層側に隣接するＥＣＵを候補として取得することで、外部からの攻撃が原因で発生した異常を早期に把握することができる。以上のように、本実施形態では、車載ネットワーク上で発生した異常の原因を効率良く解析することができる。

なお、上記実施形態におけるステップＳ１１８では、送受信部５４によって受信された異常情報が外部からの攻撃であると特定してセンタ１８へ解析結果を出力したが、これに加えて、攻撃による影響度をセンタ１８に通知してもよい。このとき、最初に送受信部５４によって受信した異常情報が第３階層ＣＬ３の異常（ＣＡＮの階層での異常）ではなかった場合は、ＣＡＮの階層で異常が発生していないかチェックしてもよい。そして、異常ログが検出された場合は、攻撃による影響度をセンタ１８へ通知し、異常ログが検出されなかった場合は、影響度が不明である旨をセンタ１８へ通知してもよい。

＜第２実施形態＞
第２実施形態に係る車両用異常検出装置８０（以下、適宜「異常検出装置８０」と称する。）について、図５を参照して説明する。なお、第１実施形態と同様の構成については同じ符号を付し適宜説明を省略する。

第１実施形態では、送受信部５４、異常原因候補取得部７２及び異常情報管理部６８の機能を実現する車両用異常検出装置１０（モジュール）が車両１１に設けられているのに対して、本実施形態では、このモジュールが車両１１の外部に設けられている点で異なる。

図５に示されるように、本実施形態の異常検出装置８０は、センタ１８に接続されており、この異常検出装置８０は、第１実施形態の異常検出装置１０と同様の構成とされている。すなわち、異常検出装置８０は、図３に示される機能構成を備えている。

また、車載ネットワーク１２には一時記憶部８２が設けられており、この一時記憶部８２は、車載ログ記憶部６２及び異常情報記憶部７０の機能を備えている。

（作用）
次に、本実施形態の作用を説明する。

本実施形態では、異常検出装置８０が車両１１の外部に設けられているため、車両１１の外部のリソースを使って解析が行われる。また、解析に必要なデータは、車両側のＴＣＵ１４等から送信される。これにより、第１実施形態と比較して、車両側のリソースの使用を抑制することができる。その他の作用については第１実施形態と同様である。

なお、車両１１とセンタ１８との間で通信が出来ない状態の場合、一時記憶部８２は車両１１からＰＵＳＨ通知されたデータのバッファとして機能する。

＜第３実施形態＞
第３実施形態に係る車両用異常検出装置９０（以下、適宜「異常検出装置９０」と称する。）について、図６を参照して説明する。なお、第１実施形態と同様の構成については同じ符号を付し適宜説明を省略する。

図６に示されるように、異常検出装置９０は、イーサネットスイッチ２０及びゲートウェイ２２に接続された第１検出装置９２及び第２検出装置９４を備えている。第１検出装置９２及び第２検出装置９４は、それぞれ第１実施形態の異常検出装置１０と同様の構成とされている。すなわち、第１検出装置９２及び第２検出装置９４のそれぞれが図３に示される機能構成を備えている。

（作用）
次に、本実施形態の作用を説明する。

本実施形態では、第１検出装置９２及び第２検出装置９４の一方が故障又は異常になった場合であっても、第１検出装置９２及び第２検出装置９４の他方によって故障又は異常を検出することができる。

また、第１検出装置９２及び第２検出装置９４が検出した検出結果が異なる場合、何れかの検出装置が故障又は異常であることが分かるため、センタ１８及び車両１１は、異常検出装置９０からの指示を受け付けない。これにより、第１検出装置９２又は第２検出装置９４が異常となった場合でも、車載ネットワーク１２を外部の攻撃から良好に保護することができる。

なお、本実施形態において、使用リソースが第１実施形態の異常検出装置１０の２倍になるのを抑制するため、一部の機能を共用してもよい。例えば、第１検出装置９２を構成する車載ネットワーク情報記憶部５８、車載ログ記憶部６２、正常定義情報記憶部６６及び異常情報記憶部７０を、第２検出装置９２と共用してもよい。

以上、実施形態及び変形例について説明したが、本発明の要旨を逸脱しない範囲において、種々なる態様で実施し得ることは勿論である。例えば、上記実施形態では、第１階層ＣＬ１、第２階層ＣＬ２及び第３階層ＣＬ３によって車載ネットワーク１２を構成したが、これに限定されない。例えば、第４階層以上の階層を備えていてもよい。この場合であっても、隣り合う階層はファイアウォールを介して接続される。

また、上記実施形態では、第１階層ＣＬ１のみに外部通信手段を有するＥＣＵを配置したが、これに限定されない。例えば、第１階層ＣＬ１よりも下層である第２階層ＣＬ２に外部通手段を有するＥＣＵを配置してもよい。このようなＥＣＵは、異常検出処処理のステップＳ１０６において、他のＥＣＵよりも優先度が高く設定される。

さらに、上記実施形態でＣＰＵ４２がソフトウェア（プログラム）を読み込んで実行した異常検出処理を、ＣＰＵ以外の各種のプロセッサが実行してもよい。この場合のプロセッサとしては、ＦＰＧＡ（Ｆｉｅｌｄ－Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）等の製造後に回路構成を変更可能なＰＬＤ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｄｅｖｉｃｅ）、及びＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）等の特定の処理を実行させるために専用に設計された回路構成を有するプロセッサである専用電気回路等が例示される。また、異常検出処理を、これらの各種のプロセッサのうちの１つで実行してもよいし、同種又は異種の２つ以上のプロセッサの組み合わせ（例えば、複数のＦＰＧＡ、及びＣＰＵとＦＰＧＡとの組み合わせ等）で実行してもよい。また、これらの各種のプロセッサのハードウェア的な構造は、より具体的には、半導体素子等の回路素子を組み合わせた電気回路である。

１０、８０、９０ 車両用異常検出装置
１１ 車両
１２ 車載ネットワーク
２０ イーサネットスイッチ（ファイアウォール、制御装置）
２２ ゲートウェイ（ファイアウォール、制御装置）
５４ 送受信部
６８ 異常情報管理部
７２ 異常原因候補取得部
７６ 攻撃特定部
ＣＬ１ 第１階層

Claims (5)

1. ファイアウォールを介して多数階層で構成された車載ネットワークにおいて、複数の制御装置のうち異常が検出された一の制御装置の異常情報を受信する送受信部と、
   前記送受信部によって受信された前記一の制御装置の異常の原因となり得る他の制御装置の候補を取得する異常原因候補取得部と、
   前記異常原因候補取得部で取得された候補から、前記一の制御装置の異常が検出された時刻以前に異常が発生している前記他の制御装置があれば、当該他の制御装置を前記一の制御装置と共に異常原因制御装置として管理する異常情報管理部と、
   を有する車両用異常検出装置。
2. 前記異常原因制御装置の異常が検出された時刻以前に異常が発生している他の制御装置があった場合には、当該他の制御装置を新たに異常原因制御装置として管理する請求項１に記載の車両用異常検出装置。
3. 前記車載ネットワークは、外部通信手段を有する第１階層を含んで構成されており、
   前記異常原因候補取得部は、前記一の制御装置と同階層の制御装置、及び、前記同階層に対して前記第１階層側に隣接する階層と前記同階層とを接続する制御装置を候補として取得する請求項１又は２に記載の車両用異常検出装置。
4. 前記異常情報管理部によって管理された前記異常原因制御装置の異常が外部通信に関する異常であった場合に、外部からの攻撃であると特定する攻撃特定部をさらに備えた請求項１～３の何れか１項に記載の車両用異常検出装置。
5. 前記送受信部、前記異常原因候補取得部及び前記異常情報管理部の機能を実現するモジュールが車両に設けられている請求項１～４の何れか１項に記載の車両用異常検出装置。