JP6839963B2 - 異常検知方法、異常検知装置及び異常検知システム - Google Patents

異常検知方法、異常検知装置及び異常検知システム Download PDF

Info

Publication number
JP6839963B2
JP6839963B2 JP2016212574A JP2016212574A JP6839963B2 JP 6839963 B2 JP6839963 B2 JP 6839963B2 JP 2016212574 A JP2016212574 A JP 2016212574A JP 2016212574 A JP2016212574 A JP 2016212574A JP 6839963 B2 JP6839963 B2 JP 6839963B2
Authority
JP
Japan
Prior art keywords
vehicle
unit
bus
feature information
determination
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.)
Active
Application number
JP2016212574A
Other languages
English (en)
Other versions
JP2017126978A (ja
Inventor
良浩 氏家
良浩 氏家
芳賀　智之
智之 芳賀
前田　学
学 前田
松島　秀樹
秀樹 松島
剛 岸川
剛 岸川
淳一 鶴見
淳一 鶴見
久嗣 鹿島
久嗣 鹿島
雪乃 鳥海
雪乃 鳥海
拓也 桑原
拓也 桑原
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Intellectual Property Corp of America
Original Assignee
Panasonic Intellectual Property Corp of America
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Panasonic Intellectual Property Corp of America filed Critical Panasonic Intellectual Property Corp of America
Priority to CN202110213461.7A priority Critical patent/CN113014464B/zh
Priority to EP16883746.6A priority patent/EP3402128B1/en
Priority to PCT/JP2016/087134 priority patent/WO2017119246A1/ja
Priority to CN201680051251.XA priority patent/CN108028790B/zh
Priority to EP20168399.2A priority patent/EP3697031B1/en
Publication of JP2017126978A publication Critical patent/JP2017126978A/ja
Priority to US16/026,040 priority patent/US10986008B2/en
Application granted granted Critical
Publication of JP6839963B2 publication Critical patent/JP6839963B2/ja
Priority to US17/201,839 priority patent/US11296965B2/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/82—Protecting input, output or interconnection devices
    • G06F21/85—Protecting input, output or interconnection devices interconnection devices, e.g. bus-connected or in-line devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/145—Network analysis or design involving simulating, designing, planning or modelling of a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0823—Errors, e.g. transmission errors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1416—Event detection, e.g. attack signature detection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/61—Time-dependent
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/48—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for in-vehicle communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40208—Bus networks characterized by the use of a particular bus standard
    • H04L2012/40215—Controller Area Network CAN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40267—Bus for use in transportation systems
    • H04L2012/40273—Bus for use in transportation systems the transportation system being a vehicle

Description

本発明は、車載ネットワークにおいて送信されるメッセージについての異常を検知する技術に関する。
近年、自動車の中のシステムには、電子制御ユニット（ＥＣＵ：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）、半導体メモリ等に記録したものとしても良い。また、これらの記録媒体に記録されている前記デジタル信号であるとしても良い。また、本発明の一態様としては、前記コンピュータプログラム又は前記デジタル信号を、電気通信回線、無線又は有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしても良い。また、本発明の一態様としては、マイクロプロセッサとメモリを備えたコンピュータシステムであって、前記メモリは、上記コンピュータプログラムを記録しており、前記マイクロプロセッサは、前記コンピュータプログラムに従って動作するとしても良い。また、前記プログラム若しくは前記デジタル信号を前記記録媒体に記録して移送することにより、又は、前記プログラム若しくは前記デジタル信号を、前記ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしても良い。
（１３）上記実施の形態及び上記変形例で示した各構成要素及び機能を任意に組み合わせることで実現される形態も本発明の範囲に含まれる。
本発明は、車載ネットワークに対する攻撃を検知するために利用可能である。
１０ 異常検知システム
４０ ネットワーク
１００ａ エンジンＥＣＵ
１００ｂ ブレーキＥＣＵ
１００ｃ ドア開閉センサＥＣＵ
１００ｄ ウィンドウ開閉センサＥＣＵ
１０１ エンジン
１０２ ブレーキ
１０３ ドア開閉センサ
１０４ ウィンドウ開閉センサ
１１０、３１０ フレーム送受信部
１２０、３２０ フレーム解釈部
１３０、３３０ 受信ＩＤ判断部
１４０、３４０ 受信ＩＤリスト保持部
１５０ フレーム処理部
１６０ データ取得部
１７０、３９０ フレーム生成部
２００ａ、２００ｂ バス
３００、１３００ ゲートウェイ（異常検知装置）
３５０、１３５０ 加工処理部
３６０ 外部通信部
３６１ 車両識別情報保持部
３７０、１３７０ 異常検知処理部
３７１、１３７１ モデル保持部
３８０ 転送処理部
３８１ 転送ルール保持部
４００ サーバ
４１０ 通信部
４２０ データ蓄積部
４３０、１４３０ 学習部
４４０ 検出窓サイズ特定部
４５０ 検出窓サイズ特定用テーブル保持部
４６０、１４６０ 異常検知結果保持部
１４４０ 検出窓サイズ決定部

Claims (18)

  1. ＣＡＮ（Controller Area Network）プロトコルに従って車両内のバスを介してメッセ
    ージの授受を行う複数の電子制御ユニットを備える車載ネットワークシステムにおける異常の検知のための異常検知方法であって、
    前記車両のエンジン始動又はアクセサリ−オンの際または所定時間毎に、前記車両の識別のための車両識別情報に基づいて単位時間の決定を行い、
    前記決定された単位時間内に前記バスから受信されたメッセージの数に基づく特徴情報と、メッセージの出現頻度に係る基準を表す所定モデルとを用いた演算処理を行い、当該演算処理の結果に応じて異常か否かを判定する
    異常検知方法。
  2. 前記単位時間の決定は、
    前記車両のエンジン始動又はアクセサリ−オンの際または所定時間毎に、前記車両の識別のための車両識別情報を、サーバに送信し、前記サーバが前記車両識別情報に応じて特定した単位時間情報を前記サーバから受信し、前記単位時間の決定を行う
    請求項１記載の異常検知方法。
  3. 前記メッセージは、メッセージの種類を示すメッセージＩＤを含み、
    前記異常検知方法は、
    前記車両のエンジン始動又はアクセサリ−オンの際または所定時間毎に、前記車両の識別のための車両識別情報に基づいて単位時間の前記決定を行う決定ステップと、
    前記決定ステップで決定された単位時間内に前記バスから受信されたメッセージＩＤ毎のメッセージの数を成分とする特徴ベクトルを前記特徴情報として特定する特定ステップと、
    前記特定ステップで特定された前記特徴情報と前記所定モデルとを用いて前記演算処理を行い、当該演算処理の結果に応じて前記判定を行う判定ステップとを含む
    請求項１記載の異常検知方法。
  4. 前記車両識別情報は、前記車両の製造事業者を示す
    請求項３記載の異常検知方法。
  5. 前記車両識別情報は、前記車両の車種を示す
    請求項３記載の異常検知方法。
  6. 前記車両識別情報は、前記車両を他の車両と区別する情報である
    請求項３記載の異常検知方法。
  7. 前記決定ステップでは、前記車両識別情報により識別される車両の集合における各車両の車載ネットワークシステムで当該車両内のバスに正常状態で送信されるべき、互いに異なる複数種類のメッセージのうち、送信周期が最短の一種類のメッセージの当該送信周期を、単位時間とするように前記決定を行う
    請求項３〜６のいずれか一項に記載の異常検知方法。
  8. 前記判定ステップでは、前記車両識別情報に対応した前記所定モデルを用いて前記演算処理を行う
    請求項３〜７のいずれか一項に記載の異常検知方法。
  9. 前記特定ステップでは、前記決定ステップで決定された単位時間毎に、当該単位時間内で前記バスから受信されたメッセージの数に基づく前記特徴情報を、逐次特定し、
    前記判定ステップでは、前記特定ステップで逐次特定された各前記特徴情報について、当該特徴情報と前記所定モデルとを用いて前記演算処理を行い、
    前記異常検知方法は更に、前記特定ステップで逐次特定された複数の前記特徴情報に基づいて前記所定モデルを逐次更新する更新ステップを含む
    請求項３〜８のいずれか一項に記載の異常検知方法。
  10. 前記決定ステップでは、前記車両の製造の際に規定された情報に基づいて、前記車両において単位時間の前記決定を行い、
    前記特定ステップでは、前記車両において前記特徴情報を特定する
    請求項３〜９のいずれか一項に記載の異常検知方法。
  11. 前記決定ステップでは、前記車両のエンジン始動又はアクセサリ−オンの際に、前記車両において単位時間の前記決定を行い、
    前記特定ステップでは、前記車両において前記特徴情報を特定する
    請求項３〜９のいずれか一項に記載の異常検知方法。
  12. 前記決定ステップでは、所定時間毎に単位時間の前記決定を行い、
    前記特定ステップでは、前記決定ステップで決定された最新の単位時間毎に、当該単位時間内で前記バスから受信されたメッセージの数に基づく前記特徴情報を、逐次特定し、
    前記判定ステップでは、前記特定ステップで逐次特定された各前記特徴情報について、当該特徴情報と前記所定モデルとを用いて前記演算処理を行う
    請求項３〜９のいずれか一項に記載の異常検知方法。
  13. 前記メッセージは、メッセージの種類を示すメッセージＩＤを含み、
    前記特徴情報は、前記決定された単位時間内に前記バスから受信された、全てのメッセージＩＤのメッセージの総数を示す
    請求項１記載の異常検知方法。
  14. ＣＡＮ（Controller Area Network）プロトコルに従って車両内のバスを介してメッセ
    ージの授受を行う複数の電子制御ユニットを備える車載ネットワークシステムにおける異常の検知のための異常検知方法であって、
    単位時間の決定を行い、
    前記決定された単位時間内に前記バスから受信されたメッセージの数に基づく特徴情報と、メッセージの出現頻度に係る基準を表す所定モデルとを用いた演算処理を行い、当該演算処理の結果に応じて異常か否かを判定し、
    前記メッセージは、メッセージの種類を示すメッセージＩＤを含み、
    前記異常検知方法は、
    単位時間の前記決定を行う決定ステップと、
    前記決定ステップで決定された単位時間内に前記バスから受信されたメッセージＩＤ毎のメッセージの数を成分とする特徴ベクトルを前記特徴情報として特定する特定ステップと、
    前記特定ステップで特定された前記特徴情報と前記所定モデルとを用いて前記演算処理を行い、当該演算処理の結果に応じて前記判定を行う判定ステップとを含み、
    前記決定ステップでは、前記車両のエンジン始動又はアクセサリ−オンの際または所定時間毎に、前記車両の識別のための車両識別情報に基づいて単位時間の前記決定を行い、
    前記決定ステップでは、前記車両識別情報により識別される車両の集合における各車両の車載ネットワークシステムで当該車両内のバスに正常状態で送信されるべき、互いに異なる複数種類のメッセージのうち、送信周期が最短の一種類のメッセージの当該送信周期を、単位時間とするように前記決定を行う
    異常検知方法。
  15. ＣＡＮ（Controller Area Network）プロトコルに従って車両内のバスを介してメッセ
    ージの授受を行う複数の電子制御ユニットを備える車載ネットワークシステムにおける異常の検知のための異常検知方法であって、
    前記車両のエンジン始動又はアクセサリ−オンの際または所定時間毎に、前記車両の識別のための車両識別情報に基づいて単位時間の決定を行い、
    前記決定された単位時間内に前記バスから受信されたメッセージの数に基づく特徴情報と、メッセージの出現頻度に係る基準を表す所定モデルとを用いた演算処理を行い、当該演算処理の結果に応じて異常か否かを判定し、
    前記メッセージは、メッセージの種類を示すメッセージＩＤを含み、
    前記異常検知方法は、
    単位時間の前記決定を行う決定ステップと、
    前記決定ステップで決定された単位時間内に前記バスから受信されたメッセージＩＤ毎のメッセージの数を成分とする特徴ベクトルを前記特徴情報として特定する特定ステップと、
    前記特定ステップで特定された前記特徴情報と前記所定モデルとを用いて前記演算処理を行い、当該演算処理の結果に応じて前記判定を行う判定ステップとを含み、
    前記特定ステップでは、前記決定ステップで決定された単位時間毎に、当該単位時間内で前記バスから受信されたメッセージの数に基づく前記特徴情報を、逐次特定し、
    前記判定ステップでは、前記特定ステップで逐次特定された各前記特徴情報について、当該特徴情報と前記所定モデルとを用いて前記演算処理を行い、
    前記異常検知方法は更に、前記特定ステップで逐次特定された複数の前記特徴情報に基づいて前記所定モデルを逐次更新する更新ステップを含む
    異常検知方法。
  16. ＣＡＮ（Controller Area Network）プロトコルに従って車両内のバスを介してメッセ
    ージの授受を行う複数の電子制御ユニットを備える車載ネットワークシステムにおいて、前記バスに接続されて異常を検知する異常検知装置であって、
    前記バスからメッセージを受信する受信部と、
    前記車両のエンジン始動又はアクセサリ−オンの際または所定時間毎に前記車両の識別のための車両識別情報に基づいて単位時間を決定する決定部と、
    前記決定部により決定された単位時間内に前記受信部により受信されたメッセージの数に基づく特徴情報を特定する特定部と、
    前記特定部で特定された前記特徴情報とメッセージの出現頻度に係る基準を表す所定モデルとを用いた演算処理の結果に応じて、異常か否かを判定する判定部とを備える
    異常検知装置。
  17. 一の車両とサーバとを備える異常検知システムであって、
    前記一の車両は、ＣＡＮ（Controller Area Network）プロトコルに従って前記一の車
    両内のバスを介してメッセージの授受を行う複数の電子制御ユニットと当該バスに接続された異常検知装置とを備える車載ネットワークシステムを有し、
    前記異常検知装置は、
    前記バスからメッセージを受信する受信部と、
    前記車両のエンジン始動又はアクセサリ−オンの際または所定時間毎に前記一の車両の識別のための車両識別情報を前記サーバに送信し、前記サーバからの応答に基づいて単位時間を決定する決定部と、
    前記決定部により決定された単位時間内に前記受信部により受信されたメッセージの数に基づく特徴情報を特定する特定部と、
    前記特定部で特定された前記特徴情報とメッセージの出現頻度に係る基準を表す所定モデルとを用いた演算処理の結果に応じて、異常か否かを判定する判定部とを備え、
    前記サーバは、前記一の車両から前記車両識別情報を受信し、当該車両識別情報に基づいて特定した単位時間を示す情報を、前記一の車両に送信する通信部を備える
    異常検知システム。
  18. 一の車両とサーバとを備える異常検知システムであって、
    前記一の車両は、ＣＡＮ（Controller Area Network）プロトコルに従って前記一の車
    両内のバスを介してメッセージの授受を行う複数の電子制御ユニットと当該バスに接続された異常検知装置とを備える車載ネットワークシステムを有し、
    前記異常検知装置は、
    前記バスからメッセージを受信する受信部と、
    前記一の車両の識別のための車両識別情報を前記サーバに送信し、前記サーバからの応答に基づいて単位時間を決定する決定部と、
    前記決定部により決定された単位時間内に前記受信部により受信されたメッセージの数に基づく特徴情報を特定する特定部と、
    前記特定部で特定された前記特徴情報とメッセージの出現頻度に係る基準を表す所定モデルとを用いた演算処理の結果に応じて、異常か否かを判定する判定部とを備え、
    前記サーバは、前記一の車両から前記車両識別情報を受信し、当該車両識別情報に基づいて特定した単位時間を示す情報を、前記一の車両に送信する通信部を備え、
    前記サーバは、更に、前記一の車両から受信した前記車両識別情報に基づいて特定した単位時間内に、当該車両識別情報により識別される車両の集合における１つ以上の車両の車載ネットワークシステムで当該車両内のバスから受信されたメッセージの数に基づく所定情報を取得し、当該所定情報に基づいて、メッセージの出現頻度に係る基準を表す基準モデルを更新する学習部を備え、
    前記通信部は、前記学習部により更新した前記基準モデルを示す情報を前記一の車両に送信し、
    前記異常検知装置は、前記サーバから受信した前記基準モデルを示す情報に基づいて、前記所定モデルを更新し、
    前記判定部は、前記特徴情報と、前記更新された前記所定モデルとを用いた演算処理を行い、当該演算処理の結果に応じて、異常か否かの前記判定を行う
    異常検知システム。
JP2016212574A 2016-01-08 2016-10-31 異常検知方法、異常検知装置及び異常検知システム Active JP6839963B2 (ja)

Priority Applications (7)

Application Number Priority Date Filing Date Title
EP16883746.6A EP3402128B1 (en) 2016-01-08 2016-12-14 Abnormality detection method, abnormality detection device, and abnormality detection system
PCT/JP2016/087134 WO2017119246A1 (ja) 2016-01-08 2016-12-14 異常検知方法、異常検知装置及び異常検知システム
CN201680051251.XA CN108028790B (zh) 2016-01-08 2016-12-14 异常检测方法、异常检测装置及异常检测系统
EP20168399.2A EP3697031B1 (en) 2016-01-08 2016-12-14 Abnormality detection method, abnormality detection device, and abnormality detection system in a vehicle network
CN202110213461.7A CN113014464B (zh) 2016-01-08 2016-12-14 异常检测方法、异常检测装置及异常检测系统
US16/026,040 US10986008B2 (en) 2016-01-08 2018-07-02 Abnormality detection in an on-board network system
US17/201,839 US11296965B2 (en) 2016-01-08 2021-03-15 Abnormality detection in an on-board network system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2016003035 2016-01-08
JP2016003035 2016-01-08

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2021022678A Division JP7013603B2 (ja) 2016-01-08 2021-02-16 異常検知方法、異常検知装置及び異常検知システム

Publications (2)

Publication Number Publication Date
JP2017126978A JP2017126978A (ja) 2017-07-20
JP6839963B2 true JP6839963B2 (ja) 2021-03-10

Family

ID=59364469

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2016212574A Active JP6839963B2 (ja) 2016-01-08 2016-10-31 異常検知方法、異常検知装置及び異常検知システム
JP2021022678A Active JP7013603B2 (ja) 2016-01-08 2021-02-16 異常検知方法、異常検知装置及び異常検知システム

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2021022678A Active JP7013603B2 (ja) 2016-01-08 2021-02-16 異常検知方法、異常検知装置及び異常検知システム

Country Status (4)

Country Link
US (1) US10986008B2 (ja)
EP (2) EP3697031B1 (ja)
JP (2) JP6839963B2 (ja)
CN (1) CN108028790B (ja)

Families Citing this family (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10630699B2 (en) * 2017-08-14 2020-04-21 Argus Cyber Security Ltd. Automotive cybersecurity
DE102017217195A1 (de) * 2017-09-27 2019-03-28 Continental Teves Ag & Co. Ohg Verfahren zum Erfassen eines Angriffs auf ein Steuergerät eines Fahrzeugs
DE102017218134B3 (de) * 2017-10-11 2019-02-14 Volkswagen Aktiengesellschaft Verfahren und Vorrichtung zum Übertragen einer Botschaftsfolge über einen Datenbus sowie Verfahren und Vorrichtung zum Erkennen eines Angriffs auf eine so übertragene Botschaftsfolge
CN110226310B (zh) * 2017-12-01 2022-07-19 松下电器（美国）知识产权公司 电子控制装置、不正当检测服务器、车载网络系统、车载网络监视系统以及方法
JP7006295B2 (ja) * 2018-01-19 2022-01-24 富士通株式会社 攻撃検知装置および攻撃検知方法
US11012409B2 (en) * 2018-03-30 2021-05-18 Intel Corporation Anomaly detection in a controller area network
US11110895B2 (en) * 2018-04-09 2021-09-07 Cisco Technology, Inc. Vehicle network intrusion detection system (IDS) using vehicle state predictions
JP7121737B2 (ja) 2018-05-23 2022-08-18 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 異常検知装置、異常検知方法およびプログラム
CN111373701B (zh) * 2018-05-23 2022-05-17 松下电器（美国）知识产权公司 异常检测装置、异常检测系统以及控制方法
JP7378089B2 (ja) 2018-06-13 2023-11-13 パナソニックＩｐマネジメント株式会社 不正通信検知装置、不正通信検知方法及び製造システム
DE102018209407A1 (de) * 2018-06-13 2019-12-19 Robert Bosch Gmbh Verfahren und Vorrichtung zur Behandlung einer Anomalie in einem Kommunikationsnetzwerk
JP6555559B1 (ja) * 2018-06-15 2019-08-07 パナソニックＩｐマネジメント株式会社 電子制御装置、監視方法、プログラム及びゲートウェイ装置
CN108958217A (zh) * 2018-06-20 2018-12-07 长春工业大学 一种基于深度学习的can总线报文异常检测方法
US11354406B2 (en) * 2018-06-28 2022-06-07 Intel Corporation Physics-based approach for attack detection and localization in closed-loop controls for autonomous vehicles
CN108923904A (zh) * 2018-06-29 2018-11-30 百度在线网络技术（北京）有限公司 汽车指令处理方法、装置、设备、云平台及存储介质
JP7000271B2 (ja) * 2018-07-25 2022-01-19 株式会社日立製作所 車両不正アクセス対策装置、及び車両不正アクセス対策方法
US11711384B2 (en) * 2018-08-27 2023-07-25 Lear Corporation Method and system for detecting message injection anomalies
US11038911B2 (en) * 2018-10-19 2021-06-15 Blackberry Limited Method and system for determining risk in automotive ECU components
WO2020105234A1 (ja) * 2018-11-21 2020-05-28 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 異常検知方法、及び異常検知装置
CN112912282A (zh) * 2018-11-27 2021-06-04 住友电气工业株式会社 车辆故障预测系统、监视装置、车辆故障预测方法及车辆故障预测程序
JP7269955B2 (ja) * 2018-11-30 2023-05-09 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 車両ログ送信装置、車両ログ解析サーバおよび車両ログ解析システム
JP7312769B2 (ja) * 2018-12-28 2023-07-21 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 統計情報生成装置、統計情報生成方法、および、プログラム
WO2020160761A1 (de) * 2019-02-06 2020-08-13 Lisa Dräxlmaier GmbH Verfahren und prüfvorrichtung
CN117118776A (zh) * 2019-02-08 2023-11-24 松下电器（美国）知识产权公司 异常判定方法、异常判定装置以及程序
WO2020179021A1 (ja) * 2019-03-06 2020-09-10 三菱電機株式会社 攻撃検知装置および攻撃検知プログラム
JP7176456B2 (ja) * 2019-03-29 2022-11-22 株式会社デンソー メッセージ監視システム、メッセージ送信電子制御装置、および監視用電子制御装置
WO2020202850A1 (ja) * 2019-04-01 2020-10-08 株式会社デンソー 情報処理装置
JP7234832B2 (ja) * 2019-07-03 2023-03-08 株式会社デンソー 電子制御装置
JP7316129B2 (ja) * 2019-07-16 2023-07-27 株式会社ベリサーブ 処理システム、及び処理プログラム
JP7234839B2 (ja) 2019-07-17 2023-03-08 株式会社デンソー ゲートウェイ装置、異常監視方法、及び異常監視プログラム
JP7284673B2 (ja) * 2019-09-17 2023-05-31 株式会社日立ソリューションズ 変換装置、変換方法、および変換プログラム
JP7065356B2 (ja) 2019-11-11 2022-05-12 パナソニックＩｐマネジメント株式会社 情報処理装置、情報処理方法、およびプログラム
CN110912908B (zh) * 2019-11-28 2022-08-02 中国电子产品可靠性与环境试验研究所（（工业和信息化部电子第五研究所）（中国赛宝实验室）） 网络协议异常检测方法、装置、计算机设备和存储介质
JPWO2021106446A1 (ja) * 2019-11-28 2021-06-03
US11363059B2 (en) * 2019-12-13 2022-06-14 Microsoft Technology Licensing, Llc Detection of brute force attacks
DE112020006470T5 (de) * 2020-01-09 2022-10-27 Sumitomo Electric Industries, Ltd. Detektionsvorrichtung, Fahrzeugsystem und Detektionsverfahren
WO2021144858A1 (ja) * 2020-01-14 2021-07-22 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 異常検知システム、異常検知装置、及び異常検知方法
CN111581037B (zh) * 2020-04-22 2024-03-29 长城汽车股份有限公司 车辆联网检测系统、方法
EP3979590A4 (en) * 2020-04-29 2022-07-27 Huawei Technologies Co., Ltd. METHOD AND DEVICE FOR IDENTIFYING ABNORMAL MESSAGES
CN111708661A (zh) * 2020-05-14 2020-09-25 东风汽车集团有限公司 一种适用于中央网关的压力测试系统及方法
CN114205261B (zh) * 2020-08-27 2024-02-20 中车株洲电力机车研究所有限公司 网络通信数据正确性的自动化测试方法及存储介质
CN112866327B (zh) * 2020-11-03 2023-08-11 联合汽车电子有限公司 车辆数据的传输方法、装置、设备、系统和存储介质
CN112565341A (zh) * 2020-11-13 2021-03-26 华人运通(江苏)技术有限公司 诊断路由的方法、装置、系统、设备和存储介质
CN112637013B (zh) * 2020-12-21 2022-11-04 苏州三六零智能安全科技有限公司 Can总线报文异常检测方法及装置、设备、存储介质
CN112668523A (zh) * 2020-12-31 2021-04-16 深圳云天励飞技术股份有限公司 车辆行驶异常检测方法、装置、电子设备及存储介质
JP2022135190A (ja) * 2021-03-04 2022-09-15 トヨタ自動車株式会社 情報処理装置、情報処理方法、およびプログラム
CN113103973A (zh) * 2021-04-06 2021-07-13 深圳元戎启行科技有限公司 无人驾驶车辆的检测方法、装置、介质及无人驾驶车辆
CN115242575B (zh) * 2021-04-22 2023-10-03 广州汽车集团股份有限公司 基于canfd网络的报文处理方法、装置、设备及存储介质
CN113204226B (zh) * 2021-04-25 2022-12-09 重庆长安汽车股份有限公司 整车诊断系统及方法
CN113347022B (zh) * 2021-05-13 2022-11-11 中国航空工业集团公司西安航空计算技术研究所 一种民用飞机机载信息系统网络安保能力检测系统及方法
CN113259200B (zh) * 2021-05-18 2022-06-17 东风汽车集团股份有限公司 车载以太网交换机硬件测试方法、装置、设备及存储介质
CN113625681B (zh) * 2021-07-19 2022-12-13 湖南大学 Can总线异常检测方法、系统及存储介质
CN113904955B (zh) * 2021-09-29 2023-04-07 东风汽车有限公司东风日产乘用车公司 数据传输链路的检测方法、装置及系统
CN114513475B (zh) * 2022-02-15 2024-03-19 一汽解放汽车有限公司 报文交互方法、装置、控制器、存储介质和程序产品
CN115412370B (zh) * 2022-10-31 2023-03-21 广汽埃安新能源汽车股份有限公司 车辆通信数据检测方法、装置、电子设备和可读介质

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006287739A (ja) * 2005-04-01 2006-10-19 Fujitsu Ten Ltd ゲートウェイ装置
JP2007235313A (ja) * 2006-02-28 2007-09-13 Nissan Motor Co Ltd 計測装置および該計測装置の計測方法
JP2009035237A (ja) * 2007-08-03 2009-02-19 Mitsubishi Fuso Truck & Bus Corp 故障診断装置及び故障診断方法
JP5222002B2 (ja) * 2008-04-03 2013-06-26 株式会社オートネットワーク技術研究所 車載用の中継接続ユニット
CN103999410B (zh) * 2011-12-22 2017-04-12 丰田自动车株式会社 通信系统及通信方法
CN103259686B (zh) * 2013-05-31 2016-04-27 浙江大学 基于离散错误事件的can总线网络故障诊断方法
JP2015026252A (ja) 2013-07-26 2015-02-05 株式会社豊田中央研究所 異常検知装置及びプログラム
JP6361175B2 (ja) 2014-03-06 2018-07-25 株式会社豊田中央研究所 異常診断装置及びプログラム
US8955130B1 (en) * 2014-04-10 2015-02-10 Zephyr Technology Co., Limited Method for protecting vehicle data transmission system from intrusions
CN106170953B (zh) * 2014-04-17 2019-10-18 松下电器（美国）知识产权公司 车载网络系统、网关装置以及不正常检测方法
US10798114B2 (en) * 2015-06-29 2020-10-06 Argus Cyber Security Ltd. System and method for consistency based anomaly detection in an in-vehicle communication network

Also Published As

Publication number Publication date
US10986008B2 (en) 2021-04-20
EP3697031A1 (en) 2020-08-19
EP3402128A4 (en) 2019-01-09
CN108028790B (zh) 2021-02-26
EP3402128B1 (en) 2020-05-27
JP2021073829A (ja) 2021-05-13
CN108028790A (zh) 2018-05-11
JP7013603B2 (ja) 2022-01-31
EP3402128A1 (en) 2018-11-14
EP3697031B1 (en) 2023-11-15
US20180316584A1 (en) 2018-11-01
JP2017126978A (ja) 2017-07-20

Similar Documents

Publication Publication Date Title
JP7013603B2 (ja) 異常検知方法、異常検知装置及び異常検知システム
WO2017119246A1 (ja) 異常検知方法、異常検知装置及び異常検知システム
US11570184B2 (en) In-vehicle network system, fraud-detection electronic control unit, and fraud-detection method
JP6539363B2 (ja) 不正通信検知方法、不正通信検知システム及びプログラム
JP7053449B2 (ja) 不正通信検知基準決定方法、不正通信検知基準決定システム及びプログラム
CN106105105B (zh) 网络通信系统、不正常检测电子控制单元以及不正常应对方法
JP6152228B2 (ja) 電子制御ユニット、車載ネットワークシステム及び車両用通信方法
US20170013005A1 (en) System and method for consistency based anomaly detection in an in-vehicle communication network
US20170109521A1 (en) Vehicle network system whose security is improved using message authentication code
CN110546921B (zh) 不正当检测方法、不正当检测装置以及程序
JP2018026791A (ja) フレーム伝送阻止装置、フレーム伝送阻止方法及び車載ネットワークシステム
CN109076016B (zh) 非法通信检测基准决定方法、决定系统以及记录介质
WO2018186053A1 (ja) 不正通信検知方法、不正通信検知システム及びプログラム
JPWO2019187350A1 (ja) 不正検知方法、不正検知装置及びプログラム
US20220311781A1 (en) Selection method, selection system, and recording medium

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190828

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20200526

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200625

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20200818

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200929

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20210126

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20210216

R150 Certificate of patent or registration of utility model

Ref document number: 6839963

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150