(57)【要約】【課題】ＣＡＮプロトコルに従って車両内のバスを介してメッセージの授受を行う複数の電子制御ユニットを備える車載ネットワークシステムでバスに送信され得る異常なメッセージ（攻撃フレーム）の検知のために有用な異常検知方法を提供する。【解決手段】異常検知方法では、例えばゲートウェイ３００が車両識別情報をサーバ４００に送信して応答を受信すること等により、検出窓サイズ（単位時間）の決定を行い（例えばステップＳ１３０５）、決定された単位時間内にバスから受信されたメッセージの数に基づく特徴情報と、メッセージの出現頻度に係る基準を表す所定モデルとを用いた演算処理を行い、その演算処理の結果に応じて異常か否かを判定する。【選択図】図１６
2017126978.tif 000002
【特許請求の範囲】
【請求項１】
ＣＡＮ（Controller Area Network）プロトコルに従って車両内のバスを介してメッセージの授受を行う複数の電子制御ユニットを備える車載ネットワークシステムにおける異常の検知のための異常検知方法であって、
単位時間の決定を行い、
前記決定された単位時間内に前記バスから受信されたメッセージの数に基づく特徴情報と、メッセージの出現頻度に係る基準を表す所定モデルとを用いた演算処理を行い、当該演算処理の結果に応じて異常か否かを判定する
異常検知方法。
【請求項２】
前記メッセージは、メッセージの種類を示すメッセージＩＤを含み、
前記異常検知方法は、
単位時間の前記決定を行う決定ステップと、
前記決定ステップで決定された単位時間内に前記バスから受信されたメッセージＩＤ毎のメッセージの数を成分とする特徴ベクトルを前記特徴情報として特定する特定ステップと、
前記特定ステップで特定された前記特徴情報と前記所定モデルとを用いて前記演算処理を行い、当該演算処理の結果に応じて前記判定を行う判定ステップとを含む
請求項１記載の異常検知方法。
【請求項３】
前記決定ステップでは、前記車両の識別のための車両識別情報に基づいて単位時間の前記決定を行う
請求項２記載の異常検知方法。
【請求項４】
前記車両識別情報は、前記車両の製造事業者を示す
請求項３記載の異常検知方法。
【請求項５】
前記車両識別情報は、前記車両の車種を示す
請求項３記載の異常検知方法。
【請求項６】
前記車両識別情報は、前記車両を他の車両と区別する情報である
請求項３記載の異常検知方法。
【請求項７】
前記決定ステップでは、前記車両識別情報により識別される車両の集合における各車両の車載ネットワークシステムで当該車両内のバスに正常状態で送信されるべき、互いに異なる複数種類のメッセージのうち、送信周期が最短の一種類のメッセージの当該送信周期を、単位時間とするように前記決定を行う
請求項３〜６のいずれか一項に記載の異常検知方法。
【請求項８】
前記判定ステップでは、前記車両識別情報に対応した前記所定モデルを用いて前記演算処理を行う
請求項３〜７のいずれか一項に記載の異常検知方法。
【請求項９】
前記特定ステップでは、前記決定ステップで決定された単位時間毎に、当該単位時間内で前記バスから受信されたメッセージの数に基づく前記特徴情報を、逐次特定し、
前記判定ステップでは、前記特定ステップで逐次特定された各前記特徴情報について、当該特徴情報と前記所定モデルとを用いて前記演算処理を行い、
前記異常検知方法は更に、前記特定ステップで逐次特定された複数の前記特徴情報に基づいて前記所定モデルを逐次更新する更新ステップを含む
請求項２〜８のいずれか一項に記載の異常検知方法。
【請求項１０】
前記決定ステップでは、前記車両の製造の際に規定された情報に基づいて、前記車両において単位時間の前記決定を行い、
前記特定ステップでは、前記車両において前記特徴情報を特定する
請求項２〜９のいずれか一項に記載の異常検知方法。
【請求項１１】
前記決定ステップでは、前記車両のエンジン始動又はアクセサリ−オンの際に、前記車両において単位時間の前記決定を行い、
前記特定ステップでは、前記車両において前記特徴情報を特定する
請求項２〜９のいずれか一項に記載の異常検知方法。
【請求項１２】
前記決定ステップでは、所定時間毎に単位時間の前記決定を行い、
前記特定ステップでは、前記決定ステップで決定された最新の単位時間毎に、当該単位時間内で前記バスから受信されたメッセージの数に基づく前記特徴情報を、逐次特定し、
前記判定ステップでは、前記特定ステップで逐次特定された各前記特徴情報について、当該特徴情報と前記所定モデルとを用いて前記演算処理を行う
請求項２〜９のいずれか一項に記載の異常検知方法。
【請求項１３】
前記メッセージは、メッセージの種類を示すメッセージＩＤを含み、
前記特徴情報は、前記決定された単位時間内に前記バスから受信された、全てのメッセージＩＤのメッセージの総数を示す
請求項１記載の異常検知方法。
【請求項１４】
ＣＡＮ（Controller Area Network）プロトコルに従って車両内のバスを介してメッセージの授受を行う複数の電子制御ユニットを備える車載ネットワークシステムにおいて、前記バスに接続されて異常を検知する異常検知装置であって、
前記バスからメッセージを受信する受信部と、
単位時間を決定する決定部と、
前記決定部により決定された単位時間内に前記受信部により受信されたメッセージの数に基づく特徴情報を特定する特定部と、
前記特定部で特定された前記特徴情報とメッセージの出現頻度に係る基準を表す所定モデルとを用いた演算処理の結果に応じて、異常か否かを判定する判定部とを備える
異常検知装置。
【請求項１５】
一の車両とサーバとを備える異常検知システムであって、
前記一の車両は、ＣＡＮ（Controller Area Network）プロトコルに従って前記一の車両内のバスを介してメッセージの授受を行う複数の電子制御ユニットと当該バスに接続された異常検知装置とを備える車載ネットワークシステムを有し、
前記異常検知装置は、
前記バスからメッセージを受信する受信部と、
前記一の車両の識別のための車両識別情報を前記サーバに送信し、前記サーバからの応答に基づいて単位時間を決定する決定部と、
前記決定部により決定された単位時間内に前記受信部により受信されたメッセージの数に基づく特徴情報を特定する特定部と、
前記特定部で特定された前記特徴情報とメッセージの出現頻度に係る基準を表す所定モデルとを用いた演算処理の結果に応じて、異常か否かを判定する判定部とを備え、
前記サーバは、前記一の車両から前記車両識別情報を受信し、当該車両識別情報に基づいて特定した単位時間を示す情報を、前記一の車両に送信する通信部を備える
異常検知システム。
【請求項１６】
前記サーバは、更に、前記一の車両から受信した前記車両識別情報に基づいて特定した単位時間内に、当該車両識別情報により識別される車両の集合における１つ以上の車両の車載ネットワークシステムで当該車両内のバスから受信されたメッセージの数に基づく所定情報を取得し、当該所定情報に基づいて、メッセージの出現頻度に係る基準を表す基準モデルを更新する学習部を備え、
前記通信部は、前記学習部により更新した前記基準モデルを示す情報を前記一の車両に送信し、
前記異常検知装置は、前記サーバから受信した前記基準モデルを示す情報に基づいて、前記所定モデルを更新し、
前記判定部は、前記特徴情報と、前記更新された前記所定モデルとを用いた演算処理を行い、当該演算処理の結果に応じて、異常か否かの前記判定を行う
請求項１５記載の異常検知システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車載ネットワークにおいて送信されるメッセージについての異常を検知する技術に関する。
【背景技術】
【０００２】
近年、自動車の中のシステムには、電子制御ユニット（ＥＣＵ：Electronic Control Unit）と呼ばれる装置が多数配置されている。これらのＥＣＵをつなぐネットワークは車載ネットワークと呼ばれる。車載ネットワークには、多数の規格が存在する。その中でも最も主流な車載ネットワークの一つに、ＩＳＯ１１８９８−１で規定されているＣＡＮ（Controller Area Network）という規格が存在する。
【０００３】
ＣＡＮでは、通信路は２本のワイヤで構成されたバス（ＣＡＮバス）であり、バスに接続されているＥＣＵはノードと呼ばれる。ＣＡＮバスに接続されている各ノードは、フレーム（メッセージ）を送受信する。またＣＡＮでは、送信先や送信元を指す識別子は存在せず、送信ノードはフレーム毎に、メッセージＩＤと呼ばれるＩＤを付けて送信し（つまりバスに信号を送出することでブロードキャストし）、各受信ノードは予め定められたメッセージＩＤのみを受信する（つまりバスから信号を読み取る）。自動車の中のシステムにおいては、多数のＥＣＵそれぞれは、様々なフレームの授受を行う。
【０００４】
ＣＡＮバスに不正なノードを接続すること、或いは、携帯情報端末、車外の通信装置等と通信する機能を有するＥＣＵ等を攻撃して不正なノードに変化させること等により、攻撃者が、攻撃フレームをＣＡＮバスに送信して、自動車を不正にコントロールする可能性がある。攻撃フレームは、不正な攻撃者によってＣＡＮバスに送信されたフレームであり、車載ネットワークの正常状態において本来は送信されないフレーム（異常なメッセージ）である。
【０００５】
このような攻撃フレームを検知するための技術として、ＣＡＮのバス上に送信されたフレームが異常なフレームか否かを統計的な手法を用いて判定する技術が知られている（特許文献１、特許文献２参照）。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１５−０２６２５２号公報
【特許文献２】特開２０１５−１７０１２１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
車載ネットワークでの攻撃フレームの検知（つまり異常の検知）のためには、特許文献１、２の技術で十分とは限らず、異常検知のための更なる技術の研究開発が望まれている。
【０００８】
そこで、本発明は、自動車等の車両の車載ネットワークで送信され得る異常なメッセージ（攻撃フレーム）の検知のために有用な異常検知方法を提供する。
【課題を解決するための手段】
【０００９】
上記課題を解決するために本発明の一態様に係る異常検知方法は、ＣＡＮ（Controller Area Network）プロトコルに従って車両内のバスを介してメッセージの授受を行う複数の電子制御ユニットを備える車載ネットワークシステムにおける異常の検知のための異常検知方法であって、単位時間の決定を行い、前記決定された単位時間内に前記バスから受信されたメッセージの数に基づく特徴情報と、メッセージの出現頻度に係る基準を表す所定モデルとを用いた演算処理を行い、当該演算処理の結果に応じて異常か否かを判定する異常検知方法である。
【００１０】
また、上記課題を解決するために本発明の一態様に係る異常検知装置は、ＣＡＮ（Controller Area Network）プロトコルに従って車両内のバスを介してメッセージの授受を行う複数の電子制御ユニットを備える車載ネットワークシステムにおいて、前記バスに接続されて異常を検知する異常検知装置であって、前記バスからメッセージを受信する受信部と、単位時間を決定する決定部と、前記決定部により決定された単位時間内に前記受信部により受信されたメッセージの数に基づく特徴情報を特定する特定部と、前記特定部で特定された前記特徴情報とメッセージの出現頻度に係る基準を表す所定モデルとを用いた演算処理の結果に応じて、異常か否かを判定する判定部とを備える異常検知装置である。
【００１１】
また、上記課題を解決するために本発明の一態様に係る異常検知システムは、一の車両とサーバとを備える異常検知システムであって、前記一の車両は、ＣＡＮ（Controller Area Network）プロトコルに従って前記一の車両内のバスを介してメッセージの授受を行う複数の電子制御ユニットと当該バスに接続された異常検知装置とを備える車載ネットワークシステムを有し、前記異常検知装置は、前記バスからメッセージを受信する受信部と、前記一の車両の識別のための車両識別情報を前記サーバに送信し、前記サーバからの応答に基づいて単位時間を決定する決定部と、前記決定部により決定された単位時間内に前記受信部により受信されたメッセージの数に基づく特徴情報を特定する特定部と、前記特定部で特定された前記特徴情報とメッセージの出現頻度に係る基準を表す所定モデルとを用いた演算処理の結果に応じて、異常か否かを判定する判定部とを備え、前記サーバは、前記一の車両から前記車両識別情報を受信し、当該車両識別情報に基づいて特定した単位時間を示す情報を、前記一の車両に送信する通信部を備える異常検知システムである。
【発明の効果】
【００１２】
本発明によれば、攻撃者により攻撃フレーム（メッセージ）がバスに流された場合に、車載ネットワークシステムで決定された単位時間におけるメッセージの数が基準と相違することとなり得るので、異常を検知し得る。
【図面の簡単な説明】
【００１３】
【図１】実施の形態１に係る異常検知システムの全体構成を示す図である。
【図２】ＣＡＮプロトコルで規定されるデータフレームのフォーマットを示す図である。
【図３】電子制御ユニット（ＥＣＵ）の構成図である。
【図４】受信ＩＤリストの一例を示す図である。
【図５】エンジンＥＣＵが送信するフレームにおけるＩＤ及びデータフィールドの一例を示す図である。
【図６】ブレーキＥＣＵが送信するフレームにおけるＩＤ及びデータフィールドの一例を示す図である。
【図７】ドア開閉センサＥＣＵが送信するフレームにおけるＩＤ及びデータフィールドの一例を示す図である。
【図８】ウィンドウ開閉センサＥＣＵが送信するフレームにおけるＩＤ及びデータフィールドの一例を示す図である。
【図９】実施の形態１に係るゲートウェイの構成図である。
【図１０】実施の形態１に係るゲートウェイが保持する車両識別情報の一例を示す図である。
【図１１】実施の形態１に係るゲートウェイが用いる転送ルールの一例を示す図である。
【図１２】実施の形態１に係るサーバの構成図である。
【図１３】実施の形態１に係るサーバが保持する検出窓サイズ特定用テーブルの一例を示す図である。
【図１４】ＥＣＵにおけるフレーム送信処理シーケンスの一例を示す図である。
【図１５】実施の形態１に係るゲートウェイにおけるフレーム転送処理シーケンスの一例を示す図である。
【図１６】実施の形態１に係るゲートウェイ及びサーバにおける検出窓サイズ決定処理シーケンスの一例を示す図である。
【図１７】実施の形態１に係るゲートウェイ及びサーバにおける学習処理シーケンスの一例を示す図である。
【図１８】実施の形態１に係るゲートウェイが用いる検出窓の説明のための図である。
【図１９】実施の形態１に係るゲートウェイ及びサーバにおけるモデル更新処理シーケンスの一例を示す図である。
【図２０】実施の形態１に係るゲートウェイ及びサーバにおける異常検知処理シーケンスの一例を示す図である。
【図２１】実施の形態２に係る車両の車載ネットワークシステムの構成図である。
【図２２】実施の形態２に係るゲートウェイの構成図である。
【図２３】実施の形態２に係るゲートウェイにおける検出窓サイズ決定処理シーケンスの一例を示す図である。
【図２４】実施の形態２に係るゲートウェイにおける学習処理シーケンスの一例を示す図である。
【図２５】実施の形態２に係るゲートウェイにおける異常検知処理シーケンスの一例を示す図である。
【図２６】実施の形態の変形例に係る検出窓の一例を示す図である。
【発明を実施するための形態】
【００１４】
（本発明の基礎となった知見等）
攻撃者により攻撃フレーム（メッセージ）が車載ネットワークのバスに流された場合に、単位時間においてバスから受信されたフレームの数が、正常状態においてその単位時間におけるフレームの出現頻度を示す基準（モデル）と相違することとなれば、異常を検知し得る。車載ネットワークシステムの構成、仕様等（バスで接続されたＥＣＵの編成、仕様等）によって正常状態における単位時間におけるバスへのフレームの出現頻度は限定的となり得るためである。このとき単位時間が適切であるか否かは、異常の検知精度に影響を及ぼす。そこで、車両の車載ネットワークシステムで、多様な時間幅の中から例えば１０ｍｓ等と単位時間を決定（選定）し、決定した単位時間を用いて異常を検知し得る異常検知方法に想到した。車載ネットワークシステムの構成、仕様等は、例えば車両毎或いは車種毎等に異なり得るので、一例としては、車両の車載ネットワークシステムにおいて、その車両、車種等の識別のための車両識別情報に基づいて単位時間を決定し得る。また、攻撃手法の変化、多様化等により、攻撃された状態と正常状態とを区別するために適した単位時間が過去から不変とは限らないので、車両の車載ネットワークシステムにおいて異常の検知のために、単位時間を決定してから異常を検知する方法は有用となり得る。例えば、同一車種の複数車両から集積した、フレームに係る情報の最新の解析結果等に基づいて、異常の検知のために用いる単位時間を決定すること等が有用となる。
【００１５】
本発明の一態様に係る異常検知方法は、ＣＡＮ（Controller Area Network）プロトコルに従って車両内のバスを介してメッセージの授受を行う複数の電子制御ユニットを備える車載ネットワークシステムにおける異常の検知のための異常検知方法であって、単位時間の決定を行い、前記決定された単位時間内に前記バスから受信されたメッセージの数に基づく特徴情報と、メッセージの出現頻度に係る基準を表す所定モデルとを用いた演算処理を行い、当該演算処理の結果に応じて異常か否かを判定する異常検知方法である。これにより、攻撃者により攻撃フレーム（メッセージ）がバスに流された場合に、車載ネットワークシステムで決定された単位時間（例えば１０ｍｓ等）におけるメッセージの数が基準と相違することとなり得るので、適切に異常が検知され得る。
【００１６】
また、例えば、前記メッセージは、メッセージの種類を示すメッセージＩＤを含み、前記異常検知方法は、単位時間の前記決定を行う決定ステップと、前記決定ステップで決定された単位時間内に前記バスから受信されたメッセージＩＤ毎のメッセージの数を成分とする特徴ベクトルを前記特徴情報として特定する特定ステップと、前記特定ステップで特定された前記特徴情報と前記所定モデルとを用いて前記演算処理を行い、当該演算処理の結果に応じて前記判定を行う判定ステップとを含むこととしても良い。これにより、車載ネットワークシステムにおいてメッセージの種類別の受信数に基づきメッセージの出現状況を適切に表す特徴ベクトルが定められることとなり、適切な異常の検知が可能となり得る。
【００１７】
また、例えば、前記決定ステップでは、前記車両の識別のための車両識別情報に基づいて単位時間の前記決定を行うこととしても良い。これにより、車両識別情報で識別される車載ネットワークシステムに対応して精度良い異常の検知が可能となり得る。
【００１８】
また、例えば、前記車両識別情報は、前記車両の製造事業者を示すこととしても良い。これにより、車両製造事業者毎の車載ネットワークの特徴に対応して、異常の検知に用いる単位時間を定め得るので、精度良い異常の検知が可能となり得る。
【００１９】
また、例えば、前記車両識別情報は、前記車両の車種を示すこととしても良い。これにより、車種毎の車載ネットワークの特徴に対応して、異常の検知に用いる単位時間を定め得るので、精度良い異常の検知が可能となり得る。
【００２０】
また、例えば、前記車両識別情報は、前記車両を他の車両と区別する情報であることとしても良い。これにより、個々の車両毎の車載ネットワークシステムの特徴に適応した異常の検知が可能となり得る。
【００２１】
また、例えば、前記決定ステップでは、前記車両識別情報により識別される車両の集合における各車両の車載ネットワークシステムで当該車両内のバスに正常状態で送信されるべき、互いに異なる複数種類のメッセージのうち、送信周期が最短の一種類のメッセージの当該送信周期を、単位時間とするように前記決定を行うこととしても良い。これにより、精度良い異常の検知が可能となり得る。
【００２２】
また、例えば、前記判定ステップでは、前記車両識別情報に対応した前記所定モデルを用いて前記演算処理を行うこととしても良い。これにより、車載ネットワークシステムにおいて決定した単位時間に対応した所定モデルと、車載ネットワークで単位時間において受信したメッセージの数とによって異常を検知することになるので、適切な異常の検知が可能となる。
【００２３】
また、例えば、前記特定ステップでは、前記決定ステップで決定された単位時間毎に、当該単位時間内で前記バスから受信されたメッセージの数に基づく前記特徴情報を、逐次特定し、前記判定ステップでは、前記特定ステップで逐次特定された各前記特徴情報について、当該特徴情報と前記所定モデルとを用いて前記演算処理を行い、前記異常検知方法は更に、前記特定ステップで逐次特定された複数の前記特徴情報に基づいて前記所定モデルを逐次更新する更新ステップを含むこととしても良い。これにより、異常の検知に用いる所定モデルを逐次更新するので、例えば、車載ネットワークの最近の状況（例えば車両の最近の使用状況等）に対応して、適切に異常の検知を行うことが可能となり得る。
【００２４】
また、例えば、前記決定ステップでは、前記車両の製造の際に規定された情報に基づいて、前記車両において単位時間の前記決定を行い、前記特定ステップでは、前記車両において前記特徴情報を特定することとしても良い。これにより、車両において異常の検知に用いる特徴情報の生成の基礎となる単位時間を、車両の製造の際に規定された情報（例えば車台番号等）に基づいて決定し得るので、車両に適応した適切な異常の検知が可能となり得る。
【００２５】
また、例えば、前記決定ステップでは、前記車両のエンジン始動又はアクセサリ−オンの際に、前記車両において単位時間の前記決定を行い、前記特定ステップでは、前記車両において前記特徴情報を特定することとしても良い。これにより、車両において異常の検知に用いる特徴情報の生成の基礎となる単位時間を、車両の使用開始の際（走行開始の際等）に決定し得るので、例えば最近の状況に適応して、適切な異常の検知が可能となり得る。
【００２６】
また、例えば、前記決定ステップでは、所定時間毎に単位時間の前記決定を行い、前記特定ステップでは、前記決定ステップで決定された最新の単位時間毎に、当該単位時間内で前記バスから受信されたメッセージの数に基づく前記特徴情報を、逐次特定し、前記判定ステップでは、前記特定ステップで逐次特定された各前記特徴情報について、当該特徴情報と前記所定モデルとを用いて前記演算処理を行うこととしても良い。これにより、車両において異常の検知に用いる特徴情報の生成の基礎となる単位時間を、所定時間毎に決定するので、例えば最近の状況に適応して、適切な異常の検知が可能となり得る。
【００２７】
また、例えば、前記メッセージは、メッセージの種類を示すメッセージＩＤを含み、前記特徴情報は、前記決定された単位時間内に前記バスから受信された、全てのメッセージＩＤのメッセージの総数を示すこととしても良い。これにより、ＩＤを区別しないことで効率的に異常の検知を行うことが可能となり得る。
【００２８】
また、本発明の一態様に係る異常検知装置は、ＣＡＮ（Controller Area Network）プロトコルに従って車両内のバスを介してメッセージの授受を行う複数の電子制御ユニットを備える車載ネットワークシステムにおいて、前記バスに接続されて異常を検知する異常検知装置であって、前記バスからメッセージを受信する受信部と、単位時間を決定する決定部と、前記決定部により決定された単位時間内に前記受信部により受信されたメッセージの数に基づく特徴情報を特定する特定部と、前記特定部で特定された前記特徴情報とメッセージの出現頻度に係る基準を表す所定モデルとを用いた演算処理の結果に応じて、異常か否かを判定する判定部とを備える異常検知装置である。演算処理は、例えば、異常検知装置で行っても、外部の装置（サーバ）で行っても良く、その結果に応じて、異常検知装置の判定部で判定を行えば良い。演算処理をサーバで行う場合においては、異常検知装置は、例えば、特定部で特定された特徴情報をサーバに送信し、演算処理の結果をサーバから受信することとしても良い。これにより、攻撃者により攻撃フレーム（メッセージ）がバスに流された場合に、異常検知装置で決定された単位時間（例えば１０ｍｓ等）におけるメッセージの数が基準と相違することとなり得るので、適切に異常が検知され得る。
【００２９】
また、本発明の一態様に係る異常検知システムは、一の車両とサーバとを備える異常検知システムであって、前記一の車両は、ＣＡＮ（Controller Area Network）プロトコルに従って前記一の車両内のバスを介してメッセージの授受を行う複数の電子制御ユニットと当該バスに接続された異常検知装置とを備える車載ネットワークシステムを有し、前記異常検知装置は、前記バスからメッセージを受信する受信部と、前記一の車両の識別のための車両識別情報を前記サーバに送信し、前記サーバからの応答に基づいて単位時間を決定する決定部と、前記決定部により決定された単位時間内に前記受信部により受信されたメッセージの数に基づく特徴情報を特定する特定部と、前記特定部で特定された前記特徴情報とメッセージの出現頻度に係る基準を表す所定モデルとを用いた演算処理の結果に応じて、異常か否かを判定する判定部とを備え、前記サーバは、前記一の車両から前記車両識別情報を受信し、当該車両識別情報に基づいて特定した単位時間を示す情報を、前記一の車両に送信する通信部を備える異常検知システムである。例えば、判定部は、特定部で特定された特徴情報をサーバに送信し、サーバからの応答（例えば、異常か否かを示す情報等）に応じて異常か否かを判定するものであっても良い。この場合にはサーバは、例えば、受信した特徴情報を用いて、所定モデルに係る演算処理を行ってその結果に基づく情報を、受信した特徴情報に対する応答として車両に送信し得る。これにより、車両の車両識別情報に対応して単位時間が決定されるので、車両の車載ネットワークに係る異常か否かの判定が適切に行われ得る。
【００３０】
また、例えば、前記サーバは、更に、前記一の車両から受信した前記車両識別情報に基づいて特定した単位時間内に、当該車両識別情報により識別される車両の集合における１つ以上の車両の車載ネットワークシステムで当該車両内のバスから受信されたメッセージの数に基づく所定情報を取得し、当該所定情報に基づいて、メッセージの出現頻度に係る基準を表す基準モデルを更新する学習部を備え、前記通信部は、前記学習部により更新した前記基準モデルを示す情報を前記一の車両に送信し、前記異常検知装置は、前記サーバから受信した前記基準モデルを示す情報に基づいて、前記所定モデルを更新し、前記判定部は、前記特徴情報と、前記更新された前記所定モデルとを用いた演算処理を行い、当該演算処理の結果に応じて、異常か否かの前記判定を行うこととしても良い。これにより、サーバでは、車両識別情報により識別される車両の集合（例えば同一車種の車両等）における車載ネットワークで受信されたメッセージの数に基づく所定情報（例えば特徴情報と同様の情報）を用いた学習により基準モデルを更新する。そして、車両の異常検知装置では、基準モデルに基づいて、例えば一致させるように、所定モデルを更新して異常か否かの判定に利用できる。従って、異常検知装置では、自装置を搭載する車両（車両識別情報で識別される車両）に適応した、適切な異常の検知（判定）の実行が可能となり得る。
【００３１】
なお、これらの全般的又は具体的な態様は、システム、方法、集積回路、コンピュータプログラム又はコンピュータで読み取り可能なＣＤ−ＲＯＭ等の記録媒体で実現されても良く、システム、方法、集積回路、コンピュータプログラム又は記録媒体の任意な組み合わせで実現されても良い。
【００３２】
以下、実施の形態に係る異常検知方法を用いる異常検知システム、異常検知装置等について、図面を参照しながら説明する。ここで示す実施の形態は、いずれも本発明の一具体例を示すものである。従って、以下の実施の形態で示される数値、構成要素、構成要素の配置及び接続形態、並びに、ステップ（工程）及びステップの順序等は、一例であって本発明を限定するものではない。以下の実施の形態における構成要素のうち、独立請求項に記載されていない構成要素については、任意に付加可能な構成要素である。また、各図は、模式図であり、必ずしも厳密に図示されたものではない。
【００３３】
（実施の形態１）
以下、本発明の実施の一態様として、車両において車載ネットワークの異常を検知する異常検知装置が、異常の検知に用いる検出窓サイズ（単位時間）を、車両外部のサーバとの連携により決定する異常検知システムについて、図面を用いて説明する。この異常検知システムにおいては、異常検知装置は、自装置を搭載している車両の車両識別情報をサーバに通知して応答を得ることで、異常の検知に用いる検出窓サイズを決定する。
【００３４】
［１．１  異常検知システム１０の全体構成］
図１は、実施の形態１に係る異常検知システム１０の全体構成を示す図である。
【００３５】
異常検知システム１０は、車載ネットワークシステムを有する車両と、相互に通信可能なサーバ４００とを備える。異常検知システム１０は、サーバ４００と通信可能な複数台の車両を備えても良いが、図１では、便宜上、一台の車両について示している。
【００３６】
図１に示す車両における車載ネットワークシステムは、ＣＡＮプロトコルに従って通信するネットワーク通信システムの一例であり、制御装置、センサ、アクチュエータ、ユーザインタフェース装置等の各種機器が搭載された車両におけるネットワーク通信システムである。この車載ネットワークシステムは、車両に搭載され各種機器に接続されたＥＣＵ１００ａ（エンジンＥＣＵ）、ＥＣＵ１００ｂ（ブレーキＥＣＵ）、ＥＣＵ１００ｃ（ドア開閉センサＥＣＵ）、及び、ＥＣＵ１００ｄ（ウィンドウ開閉センサＥＣＵ）と、バス２００ａ、２００ｂと、ゲートウェイ３００（異常検知装置の一例）とを含んで構成される。なお、車載ネットワークシステムには、ゲートウェイ３００、ＥＣＵ１００ａ〜１００ｄ以外にもいくつものＥＣＵが含まれ得るが、ここでは、便宜上ゲートウェイ３００及びＥＣＵ１００ａ〜１００ｄに注目して説明を行う。ＥＣＵは、例えば、プロセッサ（マイクロプロセッサ）、メモリ等のデジタル回路、アナログ回路、通信回路等を含む装置である。メモリは、ＲＯＭ、ＲＡＭ等であり、プロセッサにより実行される制御プログラム（ソフトウェアとしてのコンピュータプログラム）を記憶することができる。例えばプロセッサが、制御プログラム（コンピュータプログラム）に従って動作することにより、ＥＣＵは各種機能を実現することになる。なお、コンピュータプログラムは、所定の機能を達成するために、プロセッサに対する指令を示す命令コードが複数個組み合わされて構成されたものである。ＥＣＵは、ＣＡＮプロトコルに従って車両内のバス２００ａ、２００ｂを介してフレームの授受を行い得る。
【００３７】
ＥＣＵ１００ａ〜１００ｄは、それぞれ、エンジン１０１、ブレーキ１０２、ドア開閉センサ１０３、ウィンドウ開閉センサ１０４といった機器に接続されており、その機器の状態を取得し、周期的に状態を表すフレーム（データフレーム）を、バス２００ａ、バス２００ｂ等で構成される車載ネットワークに送信している。
【００３８】
ゲートウェイ３００は、ＥＣＵ１００ａとＥＣＵ１００ｂとが接続されたバス２００ａ、及び、ＥＣＵ１００ｃとＥＣＵ１００ｄとが接続されたバス２００ｂと接続され、一方のバスから受信したフレームを他方のバスに転送する機能を有する一種のＥＣＵである。また、ゲートウェイ３００は、バスから受信したフレームに基づいて異常か否かを判定すること（例えば攻撃フレームがバスに流れている異常状態であるか否かを判定すること）で異常を検知し、その検知結果（異常検知結果）をサーバ４００に通知する機能を有する異常検知装置である。異常検知装置としてのゲートウェイ３００における異常の検知は、概ね、検出窓サイズの時間長を有する期間である検出窓毎に、その検出窓内に車載ネットワークに係るバス２００ａ、２００ｂから受信されたデータフレーム（メッセージ）の数に基づく特徴情報と、メッセージの出現頻度に係る基準を表す所定モデルとを用いた比較等の演算処理の結果に応じて異常か否かを判定することで、行われる。また、ゲートウェイ３００は、ネットワーク４０を介してサーバ４００と通信することで、異常検知（異常か否かの判定）に用いるための情報（例えば検出窓サイズ、所定モデルを表す情報等のパラメータ等）を決定する機能を有する。
【００３９】
サーバ４００は、車両外部のコンピュータであり、ネットワーク４０を介して、各車両におけるゲートウェイ３００と通信し、受信した車両識別情報に基づいて、異常検知用の情報（検出窓サイズを示す情報等）をゲートウェイ３００に応答（返信）する機能を有する。また、サーバ４００は、ゲートウェイ３００より通知された異常検知結果を保存する機能を有する。また、サーバ４００は、各車両におけるゲートウェイ３００と通信し、各車両における車載ネットワークで受信されたフレームに係る情報を集積、解析等を行う機能を有しても良い。なお、ネットワーク４０における通信には、無線通信、或いは、有線通信のいかなる通信プロトコルを適用しても良い。
【００４０】
［１．２  データフレームフォーマット］
以下、ＣＡＮプロトコルに従ったネットワークで用いられるフレームの１つであるデータフレーム（メッセージ）について説明する。
【００４１】
図２は、ＣＡＮプロトコルで規定されるデータフレームのフォーマットを示す図である。同図には、ＣＡＮプロトコルで規定される標準ＩＤフォーマットにおけるデータフレームを示している。データフレームは、ＳＯＦ（Start Of Frame）、ＩＤフィールド、ＲＴＲ（Remote Transmission Request）、ＩＤＥ（Identifier Extension）、予約ビット「ｒ」、ＤＬＣ（Data Length Code）、データフィールド、ＣＲＣ（Cyclic Redundancy Check）シーケンス、ＣＲＣデリミタ「ＤＥＬ」、ＡＣＫ（Acknowledgement）スロット、ＡＣＫデリミタ「ＤＥＬ」、及び、ＥＯＦ（End Of Frame）の各フィールドで構成される。
【００４２】
ＳＯＦは、１ｂｉｔのドミナントで構成される。バスがアイドルの状態はレセシブになっており、ＳＯＦによりドミナントへ変更することでフレームの送信開始を通知する。
【００４３】
ＩＤフィールドは、１１ｂｉｔで構成される、データの種類を示す値であるＩＤ（メッセージＩＤ）を格納するフィールドである。複数のノードが同時に送信を開始した場合、このＩＤフィールドで通信調停を行うために、ＩＤが小さい値を持つフレームが高い優先度となるよう設計されている。
【００４４】
ＲＴＲは、データフレームとリモートフレームとを識別するための値であり、データフレームにおいてはドミナント１ｂｉｔで構成される。
【００４５】
ＩＤＥと「ｒ」とは、両方ドミナント１ｂｉｔで構成される。
【００４６】
ＤＬＣは、４ｂｉｔで構成され、データフィールドの長さを示す値である。なお、ＩＤＥ、「ｒ」及びＤＬＣを合わせてコントロールフィールドと称する。
【００４７】
データフィールドは、最大６４ｂｉｔで構成される送信するデータの内容を示す値である。８ｂｉｔ毎に長さを調整できる。送られるデータの仕様については、ＣＡＮプロトコルで規定されておらず、車載ネットワークシステムにおいて定められる。従って、車種、製造者（製造メーカ）等に依存した仕様となる。
【００４８】
ＣＲＣシーケンスは、１５ｂｉｔで構成される。ＳＯＦ、ＩＤフィールド、コントロールフィールド及びデータフィールドの送信値より算出される。
【００４９】
ＣＲＣデリミタは、１ｂｉｔのレセシブで構成されるＣＲＣシーケンスの終了を表す区切り記号である。なお、ＣＲＣシーケンス及びＣＲＣデリミタを合わせてＣＲＣフィールドと称する。
【００５０】
ＡＣＫスロットは、１ｂｉｔで構成される。送信ノードはＡＣＫスロットをレセシブにして送信を行う。受信ノードはＣＲＣシーケンスまで正常に受信ができていればＡＣＫスロットをドミナントとして送信する。レセシブよりドミナントが優先されるため、送信後にＡＣＫスロットがドミナントであれば、送信ノードは、いずれかの受信ノードが受信に成功していることを確認できる。
【００５１】
ＡＣＫデリミタは、１ｂｉｔのレセシブで構成されるＡＣＫの終了を表す区切り記号である。
【００５２】
ＥＯＦは、７ｂｉｔのレセシブで構成されており、データフレームの終了を示す。
【００５３】
［１．３  ＥＣＵ１００ａの構成］
図３は、ＥＣＵ１００ａの構成図である。ＥＣＵ１００ａは、フレーム送受信部１１０と、フレーム解釈部１２０と、受信ＩＤ判断部１３０と、受信ＩＤリスト保持部１４０と、フレーム処理部１５０と、データ取得部１６０と、フレーム生成部１７０とを含んで構成される。これらの各構成要素の各機能は、例えばＥＣＵ１００ａにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。なお、ＥＣＵ１００ｂ〜１００ｄも、ＥＣＵ１００ａと同様の構成を備える。
【００５４】
フレーム送受信部１１０は、バス２００ａに対して、ＣＡＮのプロトコルに従ったフレームを送受信する。バス２００ａからフレームを１ｂｉｔずつ受信し、フレーム解釈部１２０に転送する。また、フレーム生成部より通知を受けたフレームの内容をバス２００ａに送信する。
【００５５】
フレーム解釈部１２０は、フレーム送受信部１１０よりフレームの値を受け取り、ＣＡＮプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。ＩＤフィールドと判断した値は受信ＩＤ判断部１３０へ転送する。フレーム解釈部１２０は、受信ＩＤ判断部１３０から通知される判定結果に応じて、ＩＤフィールドの値と、ＩＤフィールド以降に現れるデータフィールドとを、フレーム処理部１５０へ転送するか、その判定結果を受けた以降においてフレームの受信を中止する（つまりそのフレームとしての解釈を中止する）かを決定する。また、フレーム解釈部１２０は、ＣＡＮプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部１７０へ通知する。また、フレーム解釈部１２０は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。
【００５６】
受信ＩＤ判断部１３０は、フレーム解釈部１２０から通知されるＩＤフィールドの値を受け取り、受信ＩＤリスト保持部１４０が保持しているメッセージＩＤのリストに従い、そのＩＤフィールド以降のフレームの各フィールドを受信するかどうかの判定を行う。この判定結果を、受信ＩＤ判断部１３０は、フレーム解釈部１２０へ通知する。
【００５７】
受信ＩＤリスト保持部１４０は、ＥＣＵ１００ａが受信するＩＤ（メッセージＩＤ）のリストである受信ＩＤリストを保持する。図４に、受信ＩＤリストの一例を示す。
【００５８】
フレーム処理部１５０は、受信したフレームのデータに応じてＥＣＵ毎に異なる機能に係る処理を行う。例えば、エンジン１０１に接続されたＥＣＵ１００ａは、時速が３０ｋｍを超えた状態でドアが開いている状態だと、アラーム音を鳴らす機能を備える。ＥＣＵ１００ａは、例えばアラーム音を鳴らすためのスピーカ等を有している。そして、ＥＣＵ１００ａのフレーム処理部１５０は、他のＥＣＵから受信したデータ（例えばドアの状態を示す情報）を管理し、エンジン１０１から取得された時速に基づいて一定条件下でアラーム音を鳴らす処理等を行う。なお、フレーム処理部１５０は、ここで例示した以外のフレームのデータに係る処理を行っても良い。
【００５９】
データ取得部１６０は、ＥＣＵにつながっている機器、センサ等の状態を示すデータを取得し、フレーム生成部１７０に通知する。
【００６０】
フレーム生成部１７０は、フレーム解釈部１２０から通知されたエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部１１０へ通知して送信させる。また、フレーム生成部１７０は、データ取得部１６０より通知されたデータの値に対して、予め定められたメッセージＩＤをつけてフレーム（データフレーム）を構成し、フレーム送受信部１１０へ通知する。なお、ＥＣＵ１００ａ〜１００ｄのそれぞれが送信するフレームの内容については後に図５〜図８を用いて説明する。
【００６１】
［１．４  受信ＩＤリスト例］
図４は、ＥＣＵ１００ａ〜１００ｄのそれぞれにおいて保持される受信ＩＤリストの一例を示す図である。同図に例示する受信ＩＤリストは、ＩＤ（メッセージＩＤ）の値が「１」、「２」、「３」及び「４」のいずれかであるメッセージＩＤを含むフレーム（メッセージ）を選択的に受信して処理するために用いられる。例えば、ＥＣＵ１００ａの受信ＩＤリスト保持部１４０に図４の受信ＩＤリストが保持されていると、メッセージＩＤが「１」、「２」、「３」及び「４」のいずれでもないフレームについては、フレーム解釈部１２０でのＩＤフィールド以後のフレームの解釈が中止される。
【００６２】
［１．５  エンジンＥＣＵ１００ａの送信フレーム例］
図５は、エンジン１０１に接続されたＥＣＵ１００ａから送信されるフレームにおけるＩＤ（メッセージＩＤ）及びデータフィールド（データ）の一例を示す図である。ＥＣＵ１００ａが送信するフレームのメッセージＩＤは「１」である。データは、時速（ｋｍ／時）を表し、最低０（ｋｍ／時）〜最高１８０（ｋｍ／時）までの範囲の値を取り、データ長は１ｂｙｔｅである。図５の上行から下行へと、ＥＣＵ１００ａから逐次送信される各フレームに対応する各メッセージＩＤ及びデータを例示しており、０ｋｍ／時から１ｋｍ／時ずつ加速されている様子を表している。
【００６３】
［１．６  ブレーキＥＣＵ１００ｂの送信フレーム例］
図６は、ブレーキ１０２に接続されたＥＣＵ１００ｂから送信されるフレームにおけるＩＤ（メッセージＩＤ）及びデータフィールド（データ）の一例を示す図である。ＥＣＵ１００ｂが送信するフレームのメッセージＩＤは「２」である。データは、ブレーキのかかり具合を割合（％）で表し、データ長は１ｂｙｔｅである。この割合は、ブレーキを全くかけていない状態を０（％）、ブレーキを最大限かけている状態を１００（％）としたものである。図６の上行から下行へと、ＥＣＵ１００ｂから逐次送信される各フレームに対応する各メッセージＩＤ及びデータを例示しており、１００％から徐々にブレーキを弱めている様子を表している。
【００６４】
［１．７  ドア開閉センサＥＣＵ１００ｃの送信フレーム例］
図７は、ドア開閉センサ１０３に接続されたＥＣＵ１００ｃから送信されるフレームにおけるＩＤ（メッセージＩＤ）及びデータフィールド（データ）の一例を示す図である。ＥＣＵ１００ｃが送信するフレームのメッセージＩＤは「３」である。データは、ドアの開閉状態を表し、データ長は１ｂｙｔｅである。データの値は、ドアが開いている状態が「１」、ドアが閉まっている状態が「０」である。図７の上行から下行へと、ＥＣＵ１００ｃから逐次送信される各フレームに対応する各メッセージＩＤ及びデータを例示しており、ドアが開いている状態から次第に閉められた状態へと移った様子を表している。
【００６５】
［１．８  ウィンドウ開閉センサＥＣＵ１００ｄの送信フレーム例］
図８は、ウィンドウ開閉センサ１０４に接続されたＥＣＵ１００ｄから送信されるフレームにおけるＩＤ（メッセージＩＤ）及びデータフィールド（データ）の一例を示す図である。ＥＣＵ１００ｄが送信するフレームのメッセージＩＤは「４」である。データは、窓（ウィンドウ）の開閉状態を割合（％）で表し、データ長は１ｂｙｔｅである。この割合は、窓が完全に閉まっている状態を０（％）、窓が全開の状態を１００（％）としたものである。図８の上行から下行へと、ＥＣＵ１００ｄから逐次送信される各フレームに対応する各メッセージＩＤ及びデータを例示しており、窓が閉まっている状態から徐々に開いていく様子を表している。
【００６６】
［１．９  ゲートウェイ３００の構成］
図９は、ゲートウェイ３００の構成図である。ゲートウェイ３００は、フレーム送受信部３１０と、フレーム解釈部３２０と、受信ＩＤ判断部３３０と、受信ＩＤリスト保持部３４０と、加工処理部３５０と、外部通信部３６０と、車両識別情報保持部３６１と、異常検知処理部３７０と、モデル保持部３７１と、転送処理部３８０と、転送ルール保持部３８１と、フレーム生成部３９０とを含んで構成される。これらの各構成要素の各機能は、例えばゲートウェイ３００における通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。
【００６７】
フレーム送受信部３１０は、バス２００ａ、２００ｂそれぞれに対して、ＣＡＮプロトコルに従ったフレームを送受信する。フレーム送受信部３１０は、バスからフレームを１ｂｉｔずつ受信する受信部として機能し、受信したフレームをフレーム解釈部３２０に転送する。また、フレーム生成部３９０より通知を受けた転送先のバスを示すバス情報及びフレームに基づいて、そのフレームの内容をバス２００ａ、２００ｂに１ｂｉｔずつ送信する。
【００６８】
フレーム解釈部３２０は、フレーム送受信部３１０よりフレームの値を受け取り、ＣＡＮプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。ＩＤフィールドと判断した値は受信ＩＤ判断部３３０へ転送する。フレーム解釈部３２０は、受信ＩＤ判断部３３０から通知される判定結果に応じて、ＩＤフィールドの値と、ＩＤフィールド以降に現れるデータフィールド（データ）とを、転送処理部３８０へ転送するか、その判定結果を受けた以降においてフレームの受信を中止するかを決定する。また、フレーム解釈部３２０は、ＩＤフィールドの値を、加工処理部３５０に通知する。また、フレーム解釈部３２０は、ＣＡＮプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部３９０へ通知する。また、フレーム解釈部３２０は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。
【００６９】
受信ＩＤ判断部３３０は、フレーム解釈部３２０から通知されるＩＤフィールドの値を受け取り、受信ＩＤリスト保持部３４０が保持しているメッセージＩＤのリストに従い、そのＩＤフィールド以降のフレームの各フィールドを受信するかどうかの判定を行う。この判定結果を、受信ＩＤ判断部３３０は、フレーム解釈部３２０へ通知する。
【００７０】
受信ＩＤリスト保持部３４０は、ゲートウェイ３００が受信するＩＤ（メッセージＩＤ）のリストである受信ＩＤリスト（図４参照）を保持する。
【００７１】
加工処理部３５０は、サーバ４００から通知された検出窓サイズを示す情報に基づいて検出窓サイズを決定してその検出窓サイズを保持する。つまり加工処理部３５０は、検出窓サイズを決定する決定部として機能する。加工処理部３５０は、フレーム解釈部３２０から通知されるＩＤフィールドの値に基づいて、検出窓サイズの時間長の検出窓毎に、バス２００ａ、２００ｂから逐次受信されたフレームの集合（逐次通知されたＩＤフィールドの値の集合）を、検出窓におけるＩＤ（メッセージＩＤ）別のフレームの受信数（検出窓サイズの検出窓内でフレームの受信をＩＤ別にカウントして得られたカウント数）を示す特徴情報に変換して特徴情報を外部通信部３６０へ通知する。つまり加工処理部３５０は、特徴情報を特定する特定部としても機能する。また、加工処理部３５０は、バス２００ａ、２００ｂから検出窓サイズの検出窓内に逐次受信されたフレームの数に基づくその特徴情報を異常検知処理部３７０へ逐次通知する。
【００７２】
外部通信部３６０は、車両識別情報保持部３６１が保持する車両識別情報を、ネットワーク４０を介してサーバ４００へ通知（送信）し、応答としてサーバ４００から通知された検出窓サイズを示す情報を加工処理部３５０へ通知する。また、外部通信部３６０は、加工処理部３５０から通知された特徴情報をサーバ４００に通知（送信）する。また、外部通信部３６０は、サーバ４００から通知されたモデル情報（データフレームの出現頻度に係る基準を表す基準モデルを示す情報）を異常検知処理部３７０へと通知する。また、外部通信部３６０は、異常検知処理部３７０から通知された異常検知結果をサーバ４００へ通知（送信）する。
【００７３】
車両識別情報保持部３６１は、車両の識別のための車両識別情報を保持する。図１０に、車両識別情報の一例を示す。
【００７４】
異常検知処理部３７０は、サーバ４００から通知されたモデル情報を、外部通信部３６０を介して取得し、モデル情報に従ってモデル保持部３７１が保持している所定モデル（データフレームの出現頻度に係る基準を表すモデル）を更新する。例えば、異常検知処理部３７０は、モデル情報が示す基準モデルと一致させるように所定モデルを更新し得る。また、異常検知処理部３７０は、フレーム解釈部３２０から通知されるＩＤフィールドの値に基づいて加工処理部３５０で変換された特徴情報を受け取り、モデル保持部３７１が保持している所定モデルと、その特徴情報とを用いた演算処理を行い、その演算処理の結果に応じて異常か否かを判定する判定部として機能する。即ち、異常検知処理部３７０は、バスから受信されたフレームの集合に係る特徴情報が、所定モデルが表す基準に適合しているか否かを、特徴情報及び所定モデルを用いた演算処理により判定する。この判定では、特徴情報に反映された検出窓サイズでのＩＤ別のデータフレームの受信数が、所定モデルが表す基準（例えば正常状態におけるデータフレームの出現頻度を示す基準）に適合していると正常であり、基準に適合していない（つまり基準を逸脱している）と異常であると判定される。このように判定するために演算処理は定められており、演算処理は、例えば所定モデルと特徴情報との比較、算術演算、論理演算、条件判断等といった各種処理の１つ以上の組み合わせである。異常検知処理部３７０は、その演算処理による異常か否かの判定結果（つまり異常検知結果）を、外部通信部３６０へ通知する。
【００７５】
モデル保持部３７１は、異常検知処理部３７０から通知された所定モデルを保持する。
【００７６】
転送処理部３８０は、転送ルール保持部３８１が保持する転送ルールに従って、受信したフレームのＩＤ（メッセージＩＤ）に応じて、転送するバス（転送先のバス）を決定し、転送するバスを示すバス情報とフレーム解釈部３２０より通知されたメッセージＩＤとデータとをフレーム生成部３９０へ通知する。
【００７７】
転送ルール保持部３８１は、バス毎のフレームの転送についてのルールを表す情報である転送ルールを保持する。図１１に、転送ルールの一例を示す。
【００７８】
フレーム生成部３９０は、フレーム解釈部３２０から通知されたエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部３１０へ通知して送信させる。また、フレーム生成部３９０は、転送処理部３８０より通知されたメッセージＩＤとデータとを使ってフレームを構成し、そのフレーム及びバス情報をフレーム送受信部３１０へ通知する。
【００７９】
［１．１０  車両識別情報］
図１０は、ゲートウェイ３００が保持する車両識別情報の一例を示す。車両識別情報は、車両の識別のための情報であり、図１０では、車両識別情報が、カーメーカ（車両の製造事業者）、車種、及び、車台番号を示す例を示している。この例では、例えば、車台番号は、個々の車両を他の車両と区別する情報（各車両を識別する情報）であり、型式（車両形式）と製造番号とから構成される。ここで、車種が同一の車両同士は、車載ネットワークの構成が同一であり、車載ネットワークのＣＡＮバスに流れるデータフレーム（メッセージ）の利用に関する仕様（メッセージＩＤ毎のデータフィールドの内容の規定等）は同じである。即ち、ここでの車種が同一の車両は、例えば、車両型式が同一の車両である。なお、車両識別情報は、この例に限られず、例えば、車両識別番号（ＶＩＮ：Vehicle Identification Number）等であっても良い。例えば、車両識別番号における先頭からシリアル番号の前までの桁の値が同一の車両は、同一車種の車両である。なお、車両識別情報は、必ずしも、それだけで個々の車両が識別可能となる情報である必要はない。例えば、車両識別情報は、車両の車種のみを示す情報であっても良く、車両の製造事業者のみを示す情報であっても良く、車台番号のみを示す情報であっても良く、或いはこれらのいずれかと他の情報とを組み合わせた情報等であっても良い。
【００８０】
［１．１１  転送ルール］
図１１は、ゲートウェイ３００の転送ルール保持部３８１が保持する転送ルールの一例を示す。
【００８１】
この転送ルールは、転送元のバスと転送先のバスと転送対象のＩＤ（メッセージＩＤ）とを対応付けている。図１１中の「＊」はメッセージＩＤにかかわらずフレームの転送がなされることを表している。図１１の例は、バス２００ａから受信されるフレームはメッセージＩＤにかかわらず、バス２００ｂに転送するように設定されていることを示している。また、バス２００ｂから受信されるフレームのうちメッセージＩＤが「３」であるフレームのみがバス２００ａに転送されるように設定されていることを示している。
【００８２】
［１．１２  サーバ４００の構成］
サーバ４００は、車両外部に所在し、例えば複数の車両を管理し得るコンピュータであり、メモリ、ハードディスク等の記憶媒体、プロセッサ、通信回路等を含む。
【００８３】
図１２は、サーバ４００の構成図である。サーバ４００は、同図に示すように、通信部４１０と、データ蓄積部４２０と、学習部４３０と、検出窓サイズ特定部４４０と、検出窓サイズ特定用テーブル保持部４５０と、異常検知結果保持部４６０とを含んで構成される。これらの各構成要素は、サーバ４００における通信回路、メモリに格納された制御プログラムを実行するプロセッサ等により実現される。
【００８４】
通信部４１０は、ネットワーク４０を介して各車両のゲートウェイ３００と通信する。また、通信部４１０は、ゲートウェイ３００から逐次通知される、検出窓サイズ当たりのＩＤ別のカウント数を反映した特徴情報を、車両毎に区別して、データ蓄積部４２０に蓄積する。また、通信部４１０は、学習部４３０から通知された基準モデルを示すモデル情報を、ゲートウェイ３００へ通知（送信）する。また、通信部４１０は、ゲートウェイ３００から通知された車両識別情報を検出窓サイズ特定部４４０に通知して、検出窓サイズ特定部４４０から通知された検出窓サイズを示す情報をゲートウェイ３００に通知（送信）する。また、通信部４１０は、ゲートウェイ３００から通知された異常検知結果を異常検知結果保持部４６０に保持させる。
【００８５】
データ蓄積部４２０は、通信部４１０から通知された特徴情報を車両毎に区別して蓄積（保持）する。
【００８６】
学習部４３０は、データ蓄積部４２０に蓄積された車両毎の特徴情報に基づいて、車両毎に対応する基準モデル（車両の車載ネットワークのバスに現れるデータフレームの出現頻度に係る基準を表すモデル）を構築し保持し、特徴情報に基づいて必要に応じて基準モデルを更新する。学習部４３０は、例えば、通信部４１０及びデータ蓄積部４２０によって逐次収集される特徴情報に基づいて、例えば機械学習により、保持している基準モデルを逐次更新する。
【００８７】
検出窓サイズ特定部４４０は、検出窓サイズ特定用テーブル保持部４５０が保持する検出窓サイズ特定用テーブルを参照して、通信部４１０から通知された車両識別情報に応じて検出窓サイズを特定し、特定した検出窓サイズを示す情報を通信部４１０へと通知する。
【００８８】
検出窓サイズ特定用テーブル保持部４５０は、車両識別情報に応じて検出窓サイズを特定するために用いられる検出窓サイズ特定用テーブルを保持する。検出窓サイズ特定用テーブルの一例を図１３に示す。
【００８９】
異常検知結果保持部４６０は、通信部４１０から通知された異常検知結果を、車両毎にログとして保持する。なお、サーバ４００が複数の車両を管理する場合においては、例えば、車両から受信した車両識別情報に基づいて各車両からの情報を類別して管理しても良く、例えば、車両のゲートウェイ３００は、特徴情報或いは異常検知結果をサーバ４００へ送信する際にも車両識別情報の全部或いは一部を付して送信することとしても良い。
【００９０】
［１．１３  検出窓サイズ特定用テーブル］
図１３は、サーバ４００で保持する検出窓サイズ特定用テーブルの一例を示す。図１３に示す検出窓サイズ特定用テーブルは、車両識別情報と検出窓サイズとを対応付けたテーブルである。図１３に例示する検出窓サイズ特定用テーブルの車両識別情報は、図１０の例と同様に、カーメーカ、車種、及び、車台番号を含む。この検出窓サイズは、例えば、車両識別情報により識別される車両の集合における各車両の車載ネットワークシステムでＣＡＮバスに正常状態で送信されるべき、複数種類のデータフレーム（つまりメッセージＩＤが互いに異なる複数のデータフレーム）のうち、送信周期が最短の一種類のデータフレームのその送信周期と一致するように定められ得る。この検出窓サイズを定めるために、車載ネットワークシステムの仕様、或いは、車載ネットワークシステムの正常状態の実情の分析結果等が参照され得る。例えば、車両識別情報が、個々の車両ではなく車種のみを識別するものであれば、その車種の各車両における車載ネットワークシステムで、正常状態で送信される複数のＩＤのフレームの送信周期のうち最短の周期のものと一致するように、検出窓サイズが定められ得る。検出窓サイズ特定用テーブルにおける検出窓サイズの定め方は、この他の方法によっても良く、結果的に車両の異常検知装置（ゲートウェイ３００）において、正常状態と攻撃された状態とを適切に区別できるように、検出窓サイズを定めておくことが有用である。
【００９１】
［１．１４  ＥＣＵ１００ａのフレーム送信処理］
図１４は、ＥＣＵ１００ａにおけるフレーム送信処理シーケンスの一例を示す。以下、同図に即してＥＣＵ１００ａによるフレーム送信処理について説明する。
【００９２】
ＥＣＵ１００ａは、データ取得部１６０により、センサからデータ（例えばエンジン１０１に関連してセンサで測定された車速）を取得する（ステップＳ１１０１）。
【００９３】
次にＥＣＵ１００ａは、取得したセンサのデータに基づいて、フレーム生成部１７０により、送信すべきフレーム（データフレーム）を生成する（ステップＳ１１０２）。
【００９４】
次にＥＣＵ１００ａは、生成したフレームをバス２００ａに対して送信（ブロードキャスト）する（ステップＳ１１０３）。このステップＳ１１０１からＳ１１０３までの処理は、概ね一定の周期で、周期的に繰り返され得る。
【００９５】
ＥＣＵ１００ｂ〜１００ｄにおいても、ＥＣＵ１００ａと同様な手順でフレーム送信処理が行われ得る。但し、送信の周期は、ＥＣＵ毎に異なり得る。
【００９６】
［１．１５  ゲートウェイ３００のフレーム転送処理］
図１５は、ゲートウェイ３００におけるフレーム転送処理シーケンスの一例を示す。以下、同図に即してゲートウェイ３００によるフレーム転送処理について説明する。ゲートウェイ３００は、バス２００ａ及びバス２００ｂのいずれかからフレーム（データフレーム）を受信する度にこのフレーム転送処理を行う。ここでは、ゲートウェイ３００が、バス２００ａから受信したフレームをバス２００ｂに転送する例を用いて説明する。
【００９７】
ゲートウェイ３００は、バス２００ａに送信（ブロードキャスト）されたフレームを受信する（ステップＳ１２０１）。
【００９８】
次に、ゲートウェイ３００は、転送ルール（図１１参照）を確認する（ステップＳ１２０２）。
【００９９】
ゲートウェイ３００は、転送ルールに基づいて、受信したフレームが転送されるべきフレームであると判定した場合には、そのフレームの内容に基づいて転送用フレームを生成する（ステップＳ１２０３）。
【０１００】
次に、ゲートウェイ３００は、転送用フレームをバス２００ｂに送信（ブロードキャスト）して、フレーム転送処理を終える（ステップＳ１２０４）。なお、ステップＳ１２０２で確認した転送ルールに基づいて、受信したフレームが転送されるべきフレームでないと判定した場合には、ゲートウェイ３００は、フレームの転送を行わずにフレーム転送処理を終える。
【０１０１】
［１．１６  検出窓サイズ決定処理シーケンス］
図１６は、ゲートウェイ３００及びサーバ４００の連携による検出窓サイズ決定処理シーケンスの一例を示す。以下、同図に即して検出窓サイズ決定処理シーケンスについて説明する。
【０１０２】
ゲートウェイ３００は、車両識別情報を取得する（ステップＳ１３０１）。ゲートウェイ３００は、車両識別情報を車両識別情報保持部３６１から取得する。車両識別情報保持部３６１には、例えば、ゲートウェイ３００が車両に搭載された際（例えば車両の製造の際等）において車両識別情報が保持されていても良いし、予め記録された車両識別情報を保持する車両内のＥＣＵからゲートウェイ３００がその車両識別情報を受信することで、車両識別情報保持部３６１に保持させることとしても良い。
【０１０３】
ゲートウェイ３００は、ステップＳ１３０１で取得した車両識別情報を、サーバ４００に送信する（ステップＳ１３０２ａ）。これにより、サーバ４００は、車両識別情報を受信する（ステップＳ１３０２ｂ）。なお、ゲートウェイ３００が、サーバ４００に車両識別情報を送信するタイミングは、例えば、ゲートウェイ３００が車両に搭載された際（例えば車両の製造の際等）であるが、この他のタイミングであっても良いし、そのタイミングは複数であっても良い。この他のタイミング（ゲートウェイ３００がサーバ４００に車両識別情報を送信するタイミング）の例としては、車両の走行開始時等といった車両を使用する際毎（例えば車両のエンジン始動の際、アクセサリ−オン（ＡＣＣ−ＯＮ）の際等）、所定時間（例えば１日）毎等が挙げられる。そして、ゲートウェイ３００が、サーバ４００に車両識別情報を送信するタイミングの到来に合わせて図１６に示す検出窓サイズ決定処理シーケンスの全体が実行され得る。
【０１０４】
サーバ４００では、ステップＳ１３０２ｂで受信した車両識別情報に応じて、検出窓サイズ特定部４４０により検出窓サイズを特定し（ステップＳ１３０３）、特定した検出窓サイズを示す情報（検出窓サイズ情報）を、車両識別情報に対する応答として、ゲートウェイ３００に送信する（ステップＳ１３０４ａ）。これにより、ゲートウェイ３００は、検出窓サイズ情報を受信する（ステップＳ１３０４ｂ）。
【０１０５】
ゲートウェイ３００は、受信した検出窓サイズ情報に従って、加工処理部３５０において検出窓サイズを決定して、検出窓サイズを保持する（ステップＳ１３０５）。
【０１０６】
［１．１７  学習処理シーケンス］
図１７は、ゲートウェイ３００及びサーバ４００の連携による学習処理シーケンスの一例を示す。学習処理シーケンスでは、車両の車載ネットワークにおいてゲートウェイ３００が受信したフレームの集合に加工処理を加えてなる特徴情報をサーバ４００に送信し、サーバ４００では特徴情報を基準モデルへ反映する。以下、図１７に即して学習処理シーケンスについて説明する。
【０１０７】
ゲートウェイ３００は、加工処理部３５０において、保持している検出窓サイズの時間長の検出窓毎に、バス２００ａ及びバス２００ｂからフレーム（データフレーム）を受信すると（ステップＳ１４０１）、検出窓内におけるＩＤ（メッセージＩＤ）別のフレームの受信数をカウントする（ステップＳ１４０２）。
【０１０８】
加工処理部３５０は、検出窓サイズ分の時間の経過（つまり１つの検出窓の終期の到来）を判定し（ステップＳ１４０３）、検出窓の終期が到来したら、ＩＤ別のフレームの受信数（カウント数）に基づき加工処理により特徴情報を生成する（ステップＳ１４０４）。続いてゲートウェイ３００は、加工処理部３５０で生成した特徴情報をサーバ４００に送信し（ステップＳ１４０５ａ）、加工処理部３５０ではカウント数をクリアして（ステップＳ１４０６）、次の検出窓についての処理に戻る（つまりステップＳ１４０１での処理へ戻る）。なお、ゲートウェイ３００は、ステップＳ１４０３で、検出窓の終期が到来していないと判定された場合には、ステップＳ１４０１での処理に戻る。
【０１０９】
ステップＳ１４０５ａでのゲートウェイ３００による特徴情報の送信に呼応して、サーバ４００では、特徴情報を受信し（ステップＳ１４０５ｂ）、学習部４３０で、受信した特徴情報を基準モデルに反映する（ステップＳ１４０７）。なお、サーバ４００は、特徴情報を受信する毎に基準モデルへの反映を行うこととしても良いし、複数の特徴情報を受信してからデータ蓄積部４２０に蓄積し、複数の特徴情報をまとめて学習部４３０で特徴情報の基準モデルへの反映を行うこととしても良い。この学習処理シーケンスは、車両の車載ネットワークにおいて正常状態で受信されたフレームに係る特徴情報を基準モデルに反映することで、基準モデルが、その車両の車載ネットワークのバスに現れるフレームの出現頻度に係る基準となることを想定している。基準モデルは、例えば、車両から取得した車両識別情報毎に定められる。基準モデルは、例えば車両毎に定められるが、例えば、同一車種の車両においては共通にすることとしても良い。即ち、サーバ４００が車両からの車両識別情報に応じて検出窓サイズを示す情報を送信したその送信先の車両に対応して、基準モデルが存在し、その基準モデルを示すモデル情報が、後述のモデル更新処理シーケンスでその車両に送信される。なお、特徴情報の基準モデルへの反映は、例えば、特徴情報を用いた機械学習により基準モデルを更新することで行われるようにしても良い。
【０１１０】
以下、学習処理シーケンスで用いた検出窓サイズの時間長の検出窓と加工処理により生成された特徴情報との一例について、図１８を用いて説明する。
【０１１１】
ゲートウェイ３００の加工処理部３５０では、検出窓サイズの時間長の各期間（各検出窓Ｔ１、Ｔ２、Ｔ３）において、検出窓内にバスから受信されたフレームの数に基づく特徴情報を特定する。図１８では、特徴情報として、受信されたメッセージＩＤ毎のフレームの数を成分とする特徴ベクトルを特徴情報として特定する例を示している。図１８では、ＩＤが１であるフレームをＩＤ１、ＩＤが２であるフレームをＩＤ２等と表現している。特徴ベクトルは、例えば、検出窓内におけるＩＤ１の受信数（カウント数）、ＩＤ２の受信数、ＩＤ３の受信数、ＩＤ４の受信数のそれぞれを成分とするベクトルである。ベクトルの成分数は、例えば、バスに出現する全てのメッセージＩＤの数である。図１８の例では、ＩＤ１、ＩＤ２、ＩＤ３、ＩＤ４の各受信数をこの順に並べた成分を有する特徴ベクトルを示している。検出窓Ｔ１においてＩＤ１、ＩＤ２、ＩＤ３の受信数は１でありＩＤ４の受信数は０であるので、検出窓Ｔ１における特徴ベクトルは［１，１，１，０，・・・］となっている。また、検出窓Ｔ２においてＩＤ１、ＩＤ２、ＩＤ４の受信数は１でありＩＤ３の受信数は０であるので、検出窓Ｔ２における特徴ベクトルは［１，１，０，１，・・・］となっている。また、検出窓Ｔ３においてＩＤ１、ＩＤ３の受信数は１でありＩＤ２、ＩＤ４の受信数は０であるので、検出窓Ｔ３における特徴ベクトルは［１，０，１，０，・・・］となっている。なお、ゲートウェイ３００で検出窓サイズの期間においてカウントしたＩＤ毎の受信したフレームの数を、サーバ４００の基準モデルへ反映するまでにおける、ゲートウェイ３００とサーバ４００との処理（加工処理等）の分担は、いかなるものでも良い。また、加工処理において、主成分分析等を用いることで、特徴情報としての特徴ベクトルの次元数（成分の数）を削減しても良い。
【０１１２】
サーバ４００では、特徴情報を基準モデルに反映する際に、例えば、その基準モデルと同様の所定モデルを用いたゲートウェイ３００での異常の検知を効率的に行えるようにするための加工等を施しても良い。一例としては、サーバ４００は、ゲートウェイ３００から逐次取得した特徴情報としての、上述の次元数を削減等した特徴ベクトルの集合を、ｋｄ木（k-dimensional tree）等の最近傍距離の計算に適したデータ構造にすることをもって基準モデルへの反映を行う。
【０１１３】
［１．１８  モデル更新処理シーケンス］
図１９は、ゲートウェイ３００及びサーバ４００の連携によるモデル更新処理シーケンスの一例を示す。モデル更新処理シーケンスでは、サーバ４００において更新された基準モデルを、車両のゲートウェイ３００が保持する所定モデルに反映する。以下、図１９に即してモデル更新処理シーケンスについて説明する。モデル更新処理シーケンスは、任意のタイミング（例えば１日毎）に実行される。
【０１１４】
サーバ４００は、上述の学習処理シーケンスの結果として基準モデルの更新（基準モデルの内容の変化）があったか否かを判定する（ステップＳ１５０１）。基準モデルの更新があった場合には、サーバ４００は、更新後の基準モデルを示すモデル情報を、ゲートウェイ３００に送信する（ステップＳ１５０２ａ）。これに呼応してゲートウェイ３００は、基準モデルを示すモデル情報を受信する（ステップＳ１５０２ｂ）。
【０１１５】
ゲートウェイ３００は、モデル情報を受信すると、異常検知処理部３７０で、モデル情報に従ってモデル保持部３７１が保持している所定モデルを更新する（ステップＳ１５０３）。これにより、所定モデルは、例えばサーバ４００における基準モデルと同様となる。
【０１１６】
［１．１９  異常検知処理シーケンス］
図２０は、ゲートウェイ３００及びサーバ４００の連携による異常検知処理シーケンスの一例を示す。異常検知処理シーケンスは、例えば車両が使用される段階において実行される。ゲートウェイ３００が車両の車載ネットワークのバス２００ａ、２００ｂを流れるフレームを監視して、所定モデルを用いて異常状態が生じているか否かを判定することで異常を検知する処理を含む。所定モデルは、上述のモデル更新処理シーケンスにより、上述の学習処理シーケンスで更新された基準モデルと同様となるように構成されている。なお、上述の学習処理シーケンスは、この異常検知処理シーケンスより前（例えば、車両の使用前、つまり製造或いは検査段階等）に行われ得るが、車両が使用される段階で異常検知処理シーケンスと並行して行われても良い。以下、図２０に即して異常検知処理シーケンスについて説明する。
【０１１７】
ゲートウェイ３００では、フレームが受信されると（ステップＳ１６０１）、加工処理部３５０で、検出窓サイズの検出窓内におけるＩＤ別のフレームの受信数をカウントし（ステップＳ１６０２）、加工処理によって例えば特徴ベクトルである特徴情報を生成する（ステップＳ１６０３）。１つの検出窓においてステップＳ１６０１〜ステップＳ１６０２での処理が繰り返し行われ、検出窓の終期においてステップＳ１６０３での特徴情報の生成が行われてＩＤ別のフレームの受信数をカウントするカウンタがクリアされる。
【０１１８】
次にゲートウェイ３００は、異常検知処理部３７０により、加工処理部３５０で生成された特徴情報を受け取り、その特徴情報が、モデル保持部３７１が保持している所定モデルが示す基準に適合しているか、その基準を逸脱しているかを判定する（ステップＳ１６０４）。即ち、異常検知処理部３７０は、特徴情報と所定モデルとを用いた演算処理を行い、その演算処理の結果に応じて、特徴情報が、所定モデルが表す基準を逸脱しているか否か（つまり異常か否か）を判定する。演算処理の一例としては、加工処理部３５０から受け取った特徴情報としての特徴ベクトル（図１８参照）の、ｋｄ木等のデータ構造で表された所定モデルが示す基準（例えば正常状態での特徴ベクトルの分布）に対する最近傍距離を計算して、閾値と比較する処理が、挙げられる。例えば、最近傍距離が正規分布に従うとして、閾値で定めた、平均から標準偏差の一定倍（例えば３倍）の範囲内を逸脱した場合に、異常と判定される。
【０１１９】
ゲートウェイ３００は、ステップＳ１６０４で特徴情報が、所定モデルが示す基準を逸脱していない（基準に適合している）と判定した場合には、正常と判定して（ステップＳ１６０５）、特にサーバ４００への送信を行わない。一方、特徴情報が、所定モデルが示す基準を逸脱していると判定した場合には、異常と判定して（ステップＳ１６０６）、異常検知結果をサーバ４００に送信する（ステップＳ１６０７ａ）。
【０１２０】
サーバ４００は、異常検知結果を受信すると（ステップＳ１６０７ｂ）、異常検知結果をログとして保存する（ステップＳ１６０８）。
【０１２１】
［１．２０  実施の形態１の効果］
実施の形態１に係る異常検知システム１０では、車両に搭載された異常検知装置としてのゲートウェイ３００が、その車両の識別のための車両識別情報をサーバ４００に送信し、サーバ４００からの応答に基づいて検出窓サイズ（異常検知のためにフレームの受信数をカウントするための単位時間）を決定する。これにより、車両毎に適切な検出窓サイズを用いて車載ネットワークの異常の検知を精度良く行うことが可能となり得る。また、異常検知システム１０では、異常の判定（検知）に用いるモデル（所定モデル或いは基準モデル）の学習のために、ゲートウェイ３００側で受信したフレームに係る特徴ベクトルを生成する加工処理を行うことで、サーバ４００との間の通信量の削減が可能となる。また、加工処理では、主成分分析等による特徴ベクトルの次元の削減等も行い得るので、これにより更に通信量を削減することが可能となり、また、結果的にモデルに基づく異常の判定のための演算量を削減することが可能となり得る。また、サーバ４００が、データ（車両から受信した特徴情報）の蓄積、特徴情報を反映したモデルの構築（基準モデルの更新等）を行うことで、車載のゲートウェイ３００の限られたリソースにより制限を受けることなく、最適なモデルを構築し得る。また、サーバ４００で構築（更新）した基準モデルをゲートウェイ３００が取得して、異常の判定（検知）のために用いることで、車両において迅速に異常か否かの判定（つまり異常の検知）を行うことが可能となり得る。そして、ゲートウェイ３００は、異常検知結果をサーバ４００に通知するので、サーバ４００では異常検知結果をログとして保存し、車両を管理することができ、また、その異常検知結果に基づいて、より適切な基準モデルを構築する等が可能となり得る。また、例えば、車両識別情報で車種を示すようにした場合においては、サーバ４００は、同一車種の複数の車両から特徴情報を収集することでその車種に対応する基準モデルを、その車種で攻撃された状況と正常状態を区別可能に適切に構築することが可能となる。そして、サーバ４００が、その同一車種の車両のゲートウェイ３００に対して、基準モデルを示すモデル情報を送信することで、同一車種の各車両は、基準モデルと同様の所定モデルに基づいて適切に異常を検知し得る。なお、異常の検知により、異常に対する各種対処（警告の報知、安全のための走行制御その他の処理）が可能となり得る。
【０１２２】
（実施の形態２）
以下、実施の形態１で示した異常検知システムにおける車両の車載ネットワークシステムを変形した実施態様について説明する。
【０１２３】
実施の形態１では、車両のゲートウェイ３００が、車両外部のサーバ４００と通信することで検出窓サイズを決定し、車載ネットワークの異常の検知のために用いる所定モデルの基礎となる基準モデルを学習により更新するために、検出窓サイズ分の時間におけるＩＤ別のフレームの受信数に基づく特徴情報をサーバ４００に送信した。これに対して、本実施の形態では、車両の車載ネットワークシステムにおける異常検知装置が独立して（つまり車両外部のサーバに依存せずに）、異常の検知に用いる検出窓サイズを決定する例について説明する。
【０１２４】
［２．１  車載ネットワークシステムの構成］
図２１は、本実施の形態に係る車両の車載ネットワークシステムの構成を示す。なお、実施の形態１（図１参照）と同様の構成については、図２１において図１と同一の符号を付しており、説明を省略する。
【０１２５】
図２１に示す車両における車載ネットワークシステムは、ＥＣＵ１００ａ、ＥＣＵ１００ｂ、ＥＣＵ１００ｃ及びＥＣＵ１００ｄと、バス２００ａ、２００ｂと、ゲートウェイ１３００（異常検知装置の一例）とを含んで構成される。各ＥＣＵは、ＣＡＮプロトコルに従って車両内のバス２００ａ、２００ｂを介してフレームの授受を行い得る。
【０１２６】
ゲートウェイ１３００は、実施の形態１で示したゲートウェイ３００を部分的に変形した異常検知装置であり、ここで特に示さない点についてはゲートウェイ３００と同様である。
【０１２７】
ゲートウェイ１３００は、バス２００ａ及びバス２００ｂと接続され、一方のバスから受信したフレームを他方のバスに転送する機能を有し、バスから受信したフレームに基づいて異常か否かを判定すること（例えば攻撃フレームがバスに流れている異常状態であるか否かを判定すること）で異常を検知する機能を有する。また、ゲートウェイ１３００は、異常検知（異常か否かの判定）等に用いるための検出窓サイズを決定する機能、検出窓サイズの時間長の期間である検出窓内に、車載ネットワークで受信されたフレームの数に係る特徴情報に基づいて、異常検知に用いるための所定モデルを更新する機能を有する。
【０１２８】
［２．２  ゲートウェイ１３００の構成］
図２２は、ゲートウェイ１３００の構成図である。ゲートウェイ１３００は、フレーム送受信部３１０と、フレーム解釈部３２０と、受信ＩＤ判断部３３０と、受信ＩＤリスト保持部３４０と、加工処理部１３５０と、車両識別情報保持部３６１と、異常検知処理部１３７０と、モデル保持部１３７１と、転送処理部３８０と、転送ルール保持部３８１と、フレーム生成部３９０と、検出窓サイズ決定部１４４０と、検出窓サイズ特定用テーブル保持部４５０と、学習部１４３０と、異常検知結果保持部１４６０とを含んで構成される。これらの各構成要素の各機能は、例えばゲートウェイ１３００における通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。なお、図９に示したゲートウェイ３００と同様の構成、或いは、図１２に示したサーバ４００と同様の構成については、図２２において同一の符号を付しており、説明を省略する。
【０１２９】
検出窓サイズ決定部１４４０は、検出窓サイズを決定する決定部として機能する。検出窓サイズ決定部１４４０は、車両識別情報保持部３６１が保持する車両識別情報に応じて、検出窓サイズ特定用テーブル保持部４５０が保持する検出窓サイズ特定用テーブル（図１３参照）を用いて検出窓サイズを決定し、加工処理部１３５０へと通知する。
【０１３０】
加工処理部１３５０は、実施の形態１で示した加工処理部３５０の一部を変形したものであり、検出窓サイズ決定部１４４０から通知された検出窓サイズを保持し、フレーム解釈部３２０から通知されるＩＤフィールドの値に基づいて、検出窓サイズの時間長の検出窓毎に、バス２００ａ、２００ｂから逐次受信されたフレームの集合（逐次通知されたＩＤフィールドの値の集合）を、検出窓におけるＩＤ（メッセージＩＤ）別のフレームの受信数（検出窓サイズの検出窓内でフレームの受信をＩＤ別にカウントして得られたカウント数）を示す特徴情報に変換して特徴情報を定期的に学習部１４３０へ通知する。つまり加工処理部１３５０は、特徴情報を特定する特定部として機能する。また、加工処理部１３５０は、バス２００ａ、２００ｂから検出窓サイズの検出窓内に逐次受信されたフレームの数に基づくその特徴情報を異常検知処理部１３７０へ逐次通知する。
【０１３１】
モデル保持部１３７１は、所定モデル（車両の車載ネットワークのバスに現れるデータフレームの出現頻度に係る基準を表すモデル）を保持する。
【０１３２】
学習部１４３０は、加工処理部１３５０から通知された特徴情報に基づいて、所定モデルを構築して、モデル保持部１３７１に保持させる。即ち、学習部１４３０は、モデル保持部１３７１が保持する所定モデルを、特徴情報に基づいて更新する。学習部１４３０による所定モデルの更新は、実施の形態１で示した学習部４３０による基準モデルの更新と同様の方法で行われ得る。学習部１４３０は、例えば、逐次通知される特徴情報に基づいて、例えば機械学習により、所定モデルを逐次更新し得る。
【０１３３】
異常検知処理部１３７０は、フレーム解釈部３２０から通知されるＩＤフィールドの値に基づいて加工処理部１３５０で生成された特徴情報を受け取り、モデル保持部１３７１が保持している所定モデルと、その特徴情報とを用いた演算処理を行い、その演算処理の結果に応じて異常か否かを判定する。即ち、異常検知処理部１３７０は、バスから受信されたフレームの集合に係る特徴情報が、所定モデルが表す基準に適合しているか否かを、特徴情報及び所定モデルを用いた演算処理により判定する判定部として機能する。この判定では、特徴情報に反映された検出窓サイズでのＩＤ別のデータフレームの受信数が、所定モデルが表す基準（例えば正常状態におけるデータフレームの出現頻度を示す基準）に適合していると正常であり、基準に適合していない（つまり基準を逸脱している）と異常であると判定される。また、異常検知処理部３７０は、その演算処理による異常か否かの判定結果（つまり異常検知結果）を、異常検知結果保持部１４６０にログとして保存する。
【０１３４】
［２．３  検出窓サイズ決定処理シーケンス］
図２３は、ゲートウェイ１３００における検出窓サイズ決定処理シーケンスの一例を示す。以下、同図に即して検出窓サイズ決定処理シーケンスについて説明する。この検出窓サイズ決定処理シーケンスが実行されるタイミングは、例えば、ゲートウェイ１３００が車両に搭載された際（例えば車両の製造の際等）であるが、この他のタイミングであっても良いし、そのタイミングは複数であっても良い。この他のタイミングの例としては、車両を使用する際毎（例えば車両のエンジン始動の際、アクセサリ−オン（ＡＣＣ−ＯＮ）の際等）、所定時間（例えば１日）毎等が挙げられる。なお、図１６と同様のステップについては、図２３において同一の符号を付しており、説明を適宜省略する。
【０１３５】
ゲートウェイ１３００は、車両識別情報を取得する（ステップＳ１３０１）。
【０１３６】
次にゲートウェイ１３００は、ステップＳ１３０１で取得した車両識別情報に応じて、検出窓サイズ特定用テーブル（図１３参照）を用いて検出窓サイズを決定する（ステップＳ２３０３）。ゲートウェイ１３００は、決定した検出窓サイズを保持し、加工処理部１３５０で加工処理を実行する際に検出窓サイズを用いる。なお、ゲートウェイ１３００は、車両外部との通信機能を有していても良く、その場合に、検出窓サイズ特定用テーブルを通信により、車両外部から取得することとしても良いし、記録媒体等から検出窓サイズ特定用テーブルを読み出すことで取得することとしても良い。
【０１３７】
［２．４  学習処理シーケンス］
図２４は、ゲートウェイ１３００における学習処理シーケンスの一例を示す。学習処理シーケンスでは、ゲートウェイ１３００が、バス２００ａ、２００ｂから受信したフレームの集合に加工処理を加えてなる特徴情報に基づく学習により、モデル保持部１３７１が保持する所定モデルを更新する。以下、図２４に即して学習処理シーケンスについて説明する。なお、図１７と同様のステップについては、図２４において同一の符号を付しており、説明を適宜省略する。
【０１３８】
ゲートウェイ１３００は、検出窓サイズの時間長の検出窓毎に、バス２００ａ及びバス２００ｂからフレームを受信すると（ステップＳ１４０１）、検出窓内におけるＩＤ別のフレームの受信数をカウントする（ステップＳ１４０２）。
【０１３９】
加工処理部１３５０は、検出窓サイズ分の時間が経過（検出窓の終期が到来）したら、ＩＤ別のフレームの受信数（カウント数）に基づき加工処理により特徴情報を生成する（ステップＳ１４０４）。
【０１４０】
ゲートウェイ１３００は、加工処理部１３５０で生成した特徴情報を、学習部１４３０で、モデル保持部１３７１が保持する所定モデルに反映する（ステップＳ２４０７）。この学習処理シーケンスは、車載ネットワークにおいて正常状態で受信されたフレームに係る特徴情報を所定モデルに反映することで、所定モデルが、この車載ネットワークのバスに現れるフレームの出現頻度に係る基準となることを想定している。特徴情報の所定モデルへの反映は、例えば、特徴情報を用いた機械学習により所定モデルを更新することで行われるようにしても良い。なお、加工処理部１３５０は、実施の形態１で示した加工処理部３５０と同様に、検出窓において受信されたメッセージＩＤ毎のフレームの数を成分とする特徴ベクトルを特徴情報としても良く、加工処理において、主成分分析等を用いることで、特徴ベクトルの次元数を削減しても良い。また、学習部１４３０は、特徴情報を所定モデルに反映する際に、例えば、その所定モデルを用いた異常の検知を効率的に行えるようにするための加工等を施しても良い。一例としては、学習部１４３０は、特徴ベクトルの集合を、ｋｄ木等の最近傍距離の計算に適したデータ構造にすることをもって所定モデルへの反映を行う。
【０１４１】
ステップＳ２４０７での処理に続いて、ゲートウェイ１３００は、カウント数をクリアして（ステップＳ１４０６）、ステップＳ１４０１での処理に戻る。
【０１４２】
［２．５  異常検知処理シーケンス］
図２５は、ゲートウェイ１３００における異常検知処理シーケンスの一例を示す。異常検知処理シーケンスは、例えば車両が使用される段階において実行される。異常検知処理シーケンスでは、ゲートウェイ１３００が、車両の車載ネットワークのバス２００ａ、２００ｂを流れるフレームを監視して、所定モデルを用いて異常状態が生じているか否かを判定することで異常を検知する。なお、上述の学習処理シーケンスは、この異常検知処理シーケンスより前（例えば、車両の使用前、つまり製造或いは検査段階等）に行われ得るが、車両が使用される段階で異常検知処理シーケンスと並行して行われても良い。以下、図２５に即して異常検知処理シーケンスについて説明する。なお、図２０と同様のステップについては、図２５において同一の符号を付しており、説明を適宜省略する。
【０１４３】
ゲートウェイ１３００では、フレームが受信されると（ステップＳ１６０１）、加工処理部１３５０で、検出窓サイズの検出窓内におけるＩＤ別のフレームの受信数をカウントし（ステップＳ１６０２）、加工処理によって例えば特徴ベクトルである特徴情報を生成する（ステップＳ１６０３）。１つの検出窓においてステップＳ１６０１〜ステップＳ１６０２での処理が繰り返し行われ、検出窓の終期においてステップＳ１６０３での特徴情報の生成が行われてＩＤ別のフレームの受信数をカウントするカウンタがクリアされる。
【０１４４】
次にゲートウェイ１３００は、異常検知処理部１３７０により、加工処理部１３５０で生成された特徴情報を受け取り、その特徴情報が、モデル保持部１３７１が保持している所定モデルが示す基準に適合しているか、その基準を逸脱しているかを判定する（ステップＳ１６０４）。
【０１４５】
ゲートウェイ１３００は、ステップＳ１６０４で、特徴情報が、所定モデルが示す基準を逸脱していない（基準に適合している）と判定した場合には、正常と判定し（ステップＳ１６０５）、一方、特徴情報が、所定モデルが示す基準を逸脱していると判定した場合には、異常と判定して（ステップＳ１６０６）、その判定結果をログとして保存する（ステップＳ２６０８）。なお、ゲートウェイ１３００は、この判定結果を用いて機械学習（例えば教師有り学習）等により所定モデルを更新しても良い。
【０１４６】
［２．６  実施の形態２の効果］
実施の形態２に係る異常検知装置（ゲートウェイ１３００）は、サーバ等と通信しなくても、自ら自装置が搭載されている車両の識別のための車両識別情報を取得してその車両識別情報に応じて検出窓サイズ（異常検知のためにフレームの受信数をカウントするための単位時間）を決定し得る。これにより、ゲートウェイ１３００は、自装置を搭載した車両に適切な検出窓サイズを用いて車載ネットワークの異常の検知を精度良く行うことが可能となり得る。また、ゲートウェイ１３００は、車載ネットワークの監視に基づいて生成した特徴情報を反映した所定モデルの構築（所定モデルの更新等）を行い、所定モデルを用いて異常の判定（検知）を行うので、車両において迅速に異常か否かの判定（つまり異常の検知）を行うことが可能となり得る。また、ゲートウェイ１３００は、異常か否かの判定結果をログとして保存でき、その判定結果を活用し得る。
【０１４７】
（その他変形例）
以上のように、本発明に係る技術の例示として実施の形態１、２を説明した。しかしながら、本発明に係る技術は、これに限定されず、適宜、変更、置き換え、付加、省略等を行った実施の形態にも適用可能である。例えば、以下のような変形例も本発明の一実施態様に含まれる。
【０１４８】
（１）上記実施の形態では、決定された検出窓サイズの時間長の検出窓が重複なく連続する例を示したが（図１８参照）、検出窓サイズ分の期間である各検出窓は、重複なく連続するものに限られない。図２６に示すように、ゲートウェイ（異常検知装置）が、検出窓Ｔ１と一部重複する検出窓ＴＡ内においてもバスから受信されるフレームの数をＩＤ別にカウントすることで、ＩＤ別の受信数（カウント数）を成分とする特徴ベクトルを生成して特徴情報としても良い。この場合において、例えば、ゲートウェイは、検出窓ＴＡの開始時点と基準となる開始時点（例えば先行する検出窓Ｔ１の開始時点）との差であるオフセット時間を示す情報を特徴情報に含ませてサーバに送信することとしても良い。また、例えば、検出窓サイズ（例えば１０ｍｓ）分の各検出窓の開始時点を一定時間（例えば１ｍｓ）毎等と定めることとしても良い。また、バスから特定のＩＤのフレームを受信したタイミング等を検出窓の開始時点とすることとしても良い。
【０１４９】
（２）上記の実施の形態では、データフレーム（メッセージ）の転送機能を有するゲートウェイ３００、１３００を、異常を検知する異常検知装置の一例として示したが、異常検知装置は、１つ以上のバスに接続された装置であれば良く、必ずしも転送機能を有する必要はない。異常検知装置は、異常を検知する機能以外の機能を併せ持つＥＣＵであっても良い。また、例えば、異常検知装置は、ゲートウェイ３００、１３００における１つ以上の構成要素を省略し得るし、その１つ以上の構成要素を他のＥＣＵに移動させても良い。
【０１５０】
（３）上記実施の形態では、ＣＡＮプロトコルにおけるデータフレーム（メッセージ）を標準ＩＤフォーマット（図２参照）で記述しているが、拡張ＩＤフォーマットであっても良く、メッセージＩＤは、拡張ＩＤフォーマットでの拡張ＩＤ等であっても良い。また、上記実施の形態で示したＣＡＮプロトコルは、ＴＴＣＡＮ（Time-Triggered CAN）、ＣＡＮＦＤ（CAN with Flexible Data Rate）等の派生的なプロトコルも包含する広義の意味のものとしても良い。
【０１５１】
（４）上記実施の形態１では、ゲートウェイ３００が外部通信部３６０を有する例を示したが、車載ネットワークに接続されたヘッドユニット或いは他のＥＣＵ（車外と通信する機能を有する装置）を経由して通信するとしても良い。ヘッドユニットは、例えば、マルチメディア再生、カーナビゲーション等の機能のために、車両外部との通信機能を有しているＥＣＵである。また、車載ネットワークにおいて、ＯＢＤ２（On-Board Diagnostics２）等の診断ポートに接続される診断ツール（故障診断ツール）等が、サーバ４００との通信機能を有する場合において、ゲートウェイ３００は、その診断ツールを経由してサーバ４００と通信することとしても良い。
【０１５２】
（５）上記実施の形態では、ゲートウェイ３００、１３００は、検出窓サイズの期間でのＩＤ別のフレームの受信数に基づく特徴情報が、所定モデルが示す基準から逸脱する場合に異常と判定しているが、例えば所定モデルの示す内容を逆にすることで、所定モデルに適合する場合（逸脱しない場合）を異常と判定し、逸脱する場合を正常と判定しても良い。また、実施の形態１では、異常検知結果が異常である場合のみ、ゲートウェイ３００がサーバ４００へ異常検知結果を送信してサーバ４００で異常検知結果を保存することとしたが、正常な場合にも異常検知結果を保存するとしても良い。
【０１５３】
（６）上記実施の形態では、ゲートウェイ３００、１３００が検出窓サイズ分の期間である検出窓内にバスから受信したデータフレームの数をＩＤ別にカウントすることでその受信数（カウント数）に基づいて特徴情報を生成する例を示した。しかし、特徴情報は、ＩＤ別にカウントしたカウント数の総数（受信した全てのＩＤのデータフレームの総数）に基づいて、特徴情報を生成するようにしても良い。なお、この場合においては、ＩＤを問わずに受信したデータフレームの数をカウントすることとしても良く、また、基準モデル或いは所定モデルは、その特徴情報と対比し得るように同様の構成（つまりＩＤを区別せずにフレームの出現頻度の基準を示す構成）とする。
【０１５４】
（７）上記実施の形態では、所定モデルが、ゲートウェイ３００、１３００で検出窓サイズの期間にバスから受信されたフレームの数に基づく特徴情報と対比可能な基準（特徴情報が適合すべき基準）を表す例を示した。この他に、所定モデルを、バスから受信されたフレームと対比可能な基準を表すように構成することとしても良い。この場合には、図２０及び図２５におけるステップＳ１６０２、Ｓ１６０３を省略し、ステップＳ１６０４において、バスから受信されたフレームが、所定モデルが示す基準に適合するか否（逸脱する）かを判定することとしても良い。また、上記実施の形態１では、ゲートウェイ３００で加工処理を行うことで特徴情報を生成してサーバ４００に送信することとしたが（例えばステップＳ１４０４、Ｓ１４０５ａ）、ゲートウェイ３００では、バスから受信した各フレームについてのＩＤ及び受信時刻をサーバ４００に送信するようにして、サーバ４００で加工処理を行うこととしても良い。
【０１５５】
（８）上記実施の形態で示した異常検知結果に係るログは、サーバ４００及びゲートウェイ１３００以外の装置（例えば車内のデータ保存専用の装置、ストレージの豊富なヘッドユニット等）に保存することとしても良い。ログの情報は、必要に応じて読み出して、車両の管理、或いは、異常の検知に用いるモデルの設計、構築等に活用し得る。
【０１５６】
（９）上記実施の形態におけるゲートウェイその他のＥＣＵは、例えば、プロセッサ、メモリ等のデジタル回路、アナログ回路、通信回路等を含む装置であることとしたが、ハードディスク装置、ディスプレイ、キーボード、マウス等のハードウェア構成要素を含んでいても良い。また、上記実施の形態で示した各装置は、メモリに記憶された制御プログラムがプロセッサにより実行されてソフトウェア的に機能を実現する代わりに、専用のハードウェア（デジタル回路等）によりその機能を実現することとしても良い。
【０１５７】
（１０）上記実施の形態における各装置を構成する構成要素の一部又は全部は、１個のシステムＬＳＩ（Large Scale Integration：大規模集積回路）から構成されているとしても良い。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ等を含んで構成されるコンピュータシステムである。前記ＲＡＭには、コンピュータプログラムが記録されている。前記マイクロプロセッサが、前記コンピュータプログラムに従って動作することにより、システムＬＳＩは、その機能を達成する。また、上記各装置を構成する構成要素の各部は、個別に１チップ化されていても良いし、一部又は全部を含むように１チップ化されても良い。また、ここでは、システムＬＳＩとしたが、集積度の違いにより、ＩＣ、ＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現しても良い。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用しても良い。更には、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行っても良い。バイオ技術の適用等が可能性としてあり得る。
【０１５８】
（１１）上記各装置を構成する構成要素の一部又は全部は、各装置に脱着可能なＩＣカード又は単体のモジュールから構成されているとしても良い。前記ＩＣカード又は前記モジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭ等から構成されるコンピュータシステムである。前記ＩＣカード又は前記モジュールは、上記の超多機能ＬＳＩを含むとしても良い。マイクロプロセッサが、コンピュータプログラムに従って動作することにより、前記ＩＣカード又は前記モジュールは、その機能を達成する。このＩＣカード又はこのモジュールは、耐タンパ性を有するとしても良い。
【０１５９】
（１２）本発明の一態様としては、例えば図１４〜図１７、図１９、図２０、図２３〜図２５等に示す処理手順の全部又は一部を含む異常検知方法であるとしても良い。例えば、異常検知方法は、ＣＡＮプロトコルに従って車両内のバスを介してメッセージの授受を行う複数のＥＣＵを備える車載ネットワークシステムにおける異常の検知のための異常検知方法であって、単位時間（例えば検出窓サイズ分の時間）の決定を行い、決定された単位時間内にバスから受信されたメッセージの数に基づく特徴情報と、メッセージの出現頻度に係る基準を表す所定モデルとを用いた演算処理を行い、演算処理の結果に応じて異常か否かを判定する。単位時間の決定は、例えば車両識別情報、車両に関連する者等の識別情報、その他の情報等に基づいて行い得る。メッセージは、メッセージの種類を示すメッセージＩＤを含み、異常検知方法は、例えば、車両の識別のための車両識別情報に基づいて単位時間の決定を行う決定ステップ（例えばステップＳ１３０５、Ｓ２３０３等）と、決定ステップで決定された単位時間（決定が複数回行われる場合においては例えば最新の単位時間）内にバスから受信されたメッセージＩＤ毎のメッセージの数を成分とする特徴ベクトルを特徴情報として特定する特定ステップ（例えばステップＳ１４０４等）と、特定ステップで特定された特徴情報と所定モデルとを用いて演算処理を行い、演算処理の結果に応じて異常か否かの判定を行う判定ステップ（例えばステップＳ１６０４等）とを含む。また、例えば、異常検知方法は更に、特定ステップで逐次特定された複数の特徴情報に基づいて所定モデルを逐次更新する更新ステップ（例えばステップＳ１５０３、Ｓ２４０７等）を含む。また、本発明の一態様としては、この異常検知方法に係る処理をコンピュータにより実現するコンピュータプログラムであるとしても良いし、前記コンピュータプログラムからなるデジタル信号であるとしても良い。また、本発明の一態様としては、前記コンピュータプログラム又は前記デジタル信号をコンピュータで読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＢＤ（Blu-ray（登録商標） Disc）、半導体メモリ等に記録したものとしても良い。また、これらの記録媒体に記録されている前記デジタル信号であるとしても良い。また、本発明の一態様としては、前記コンピュータプログラム又は前記デジタル信号を、電気通信回線、無線又は有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしても良い。また、本発明の一態様としては、マイクロプロセッサとメモリを備えたコンピュータシステムであって、前記メモリは、上記コンピュータプログラムを記録しており、前記マイクロプロセッサは、前記コンピュータプログラムに従って動作するとしても良い。また、前記プログラム若しくは前記デジタル信号を前記記録媒体に記録して移送することにより、又は、前記プログラム若しくは前記デジタル信号を、前記ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしても良い。
【０１６０】
（１３）上記実施の形態及び上記変形例で示した各構成要素及び機能を任意に組み合わせることで実現される形態も本発明の範囲に含まれる。
【産業上の利用可能性】
【０１６１】
本発明は、車載ネットワークに対する攻撃を検知するために利用可能である。
【符号の説明】
【０１６２】
１０  異常検知システム
４０  ネットワーク
１００ａ  エンジンＥＣＵ
１００ｂ  ブレーキＥＣＵ
１００ｃ  ドア開閉センサＥＣＵ
１００ｄ  ウィンドウ開閉センサＥＣＵ
１０１  エンジン
１０２  ブレーキ
１０３  ドア開閉センサ
１０４  ウィンドウ開閉センサ
１１０、３１０  フレーム送受信部
１２０、３２０  フレーム解釈部
１３０、３３０  受信ＩＤ判断部
１４０、３４０  受信ＩＤリスト保持部
１５０  フレーム処理部
１６０  データ取得部
１７０、３９０  フレーム生成部
２００ａ、２００ｂ  バス
３００、１３００  ゲートウェイ（異常検知装置）
３５０、１３５０  加工処理部
３６０  外部通信部
３６１  車両識別情報保持部
３７０、１３７０  異常検知処理部
３７１、１３７１  モデル保持部
３８０  転送処理部
３８１  転送ルール保持部
４００  サーバ
４１０  通信部
４２０  データ蓄積部
４３０、１４３０  学習部
４４０  検出窓サイズ特定部
４５０  検出窓サイズ特定用テーブル保持部
４６０、１４６０  異常検知結果保持部
１４４０  検出窓サイズ決定部
【図１】
2017126978.tif 000003
【図２】
2017126978.tif 000004
【図３】
2017126978.tif 000005
【図４】
2017126978.tif 000006
【図５】
2017126978.tif 000007
【図６】
2017126978.tif 000008
【図７】
2017126978.tif 000009
【図８】
2017126978.tif 000010
【図９】
2017126978.tif 000011
【図１０】
2017126978.tif 000012
【図１１】
2017126978.tif 000013
【図１２】
2017126978.tif 000014
【図１３】
2017126978.tif 000015
【図１４】
2017126978.tif 000016
【図１５】
2017126978.tif 000017
【図１６】
2017126978.tif 000018
【図１７】
2017126978.tif 000019
【図１８】
2017126978.tif 000020
【図１９】
2017126978.tif 000021
【図２０】
2017126978.tif 000022
【図２１】
2017126978.tif 000023
【図２２】
2017126978.tif 000024
【図２３】
2017126978.tif 000025
【図２４】
2017126978.tif 000026
【図２５】
2017126978.tif 000027
【図２６】
2017126978.tif 000028