JPWO2019107210A1 - 電子制御装置、不正検知サーバ、車載ネットワークシステム、車載ネットワーク監視システム及び車載ネットワーク監視方法 - Google Patents

Abstract

車載ネットワークを含む車載ネットワークシステムに関する情報を、車両外部の不正検知サーバに通知するゲートウェイ（９００）は、車載ネットワークシステムを搭載する車両の状態と、車載ネットワークで通信されるメッセージの識別子と、メッセージの不正検知結果とのうちの１つ以上を用いて優先度を決定する優先度決定部（９３０）と、車載ネットワークで通信されるメッセージを送受信するフレーム送受信部（９１０）と、車載ネットワークに関する情報を、フレーム送受信部（９１０）が受信したメッセージに基づいて抽出するフレーム解釈部（９２０）と、優先度と、車載ネットワークに関する情報とを含んだ通知情報を不正検知サーバに通知するフレームアップロード部（９５０）とを備える。

Description

本発明は、電子制御装置、不正検知サーバ、車載ネットワークシステム、車載ネットワーク監視システム及び車載ネットワーク監視方法に関する。

近年、自動車の中のシステムには、電子制御ユニット（以下、ＥＣＵ、Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）と呼ばれる装置が多数配置されている。これらのＥＣＵをつなぐネットワークは車載ネットワークと呼ばれる。車載ネットワークには、多数の規格が存在するが、その中でも最も主流な車載ネットワークの一つに、Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ（以降、ＣＡＮともいう）という規格が存在する。

ＣＡＮでは、不正なフレームが送信されるようなケースを想定したセキュリティ機能が存在しないため、不正なノードが勝手にＣＡＮのバスに接続し、不正にフレームを送信することで、車両を不正にコントロールしてしまうことが可能である。

特許文献１は、車載ネットワークに送信されたフレームに関する情報を、不正検知サーバにアップロードすることで、車載ネットワークにおいて送信されたフレームの異常度を算出する方法を開示している。

特開２０１７−１１１７９６号公報

しかしながら、特許文献１の方法では、車両ネットワークに関する情報が多数の車両からアップロードされた際に、ネットワークの通信量、又は、不正検知サーバの処理負荷が増大する。不正検知サーバの処理負荷の増大は、電力利用の観点で望ましくなく、また、不正なイベント検知の遅延の原因になる点でも望ましくない。

そこで、本発明は、車載ネットワークに関する情報が多数の車両から不正検知サーバにアップロードされたとしても、不正検知サーバの処理負荷の増大を抑える電子制御装置等を提供する。

上記目的を達成するために、本発明の一態様に係る電子制御装置は、車載ネットワークを含む車載ネットワークシステムに関する情報を、車両外部の不正検知サーバに通知する電子制御装置であって、前記車載ネットワークシステムを搭載する車両の状態と、前記車載ネットワークで通信されるメッセージの識別子と、前記メッセージの不正検知結果とのうちの１つ以上を用いて優先度を決定する優先度決定部と、前記車載ネットワークで通信されるメッセージを送受信する第一通信部と、前記車載ネットワークに関する情報を、前記第一通信部が受信した前記メッセージに基づいて抽出する車両ログ抽出部と、前記優先度と、前記車載ネットワークに関する情報とを含んだ通知情報を前記不正検知サーバに通知する第二通信部とを備える。

なお、これらの包括的または具体的な態様は、システム、方法、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ−ＲＯＭなどの記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。

本発明によれば、電子制御装置は、車載ネットワークに関する情報が多数の車両からアップロードされたとしても、不正検知サーバの処理負荷の増大を抑えることができる。

図１は、実施の形態１における、車載ネットワーク監視システムの全体構成を示す図である。 図２は、実施の形態１における、車載ネットワークシステムの全体構成を示す図である。 図３は、実施の形態１における、不正検知サーバの構成を示す図である。 図４は、実施の形態１における、車両情報ＤＢに格納される車両情報の例を示す図である。 図５は、実施の形態１における、車両ログ格納ＤＢに格納される車両ログの例を示す図である。 図６は、実施の形態１における、分析結果格納ＤＢに格納される分析結果の例を示す図である。 図７は、実施の形態１における、セキュリティ情報ＤＢに格納されるセキュリティ情報の例を示す図である。 図８は、実施の形態１における、ゲートウェイの構成を示す図である。 図９は、実施の形態１における、ルール保持部の優先度ルールの例を示す図である。 図１０は、実施の形態１における、車両と不正検知サーバとの間の処理シーケンスの例を示す図である。 図１１は、実施の形態１における、不正検知サーバでの車両ログ分析処理を示すフローチャートである。 図１２は、実施の形態２における、車載ネットワークシステムの構成を示す図である。 図１３は、実施の形態２における、ゲートウェイの構成を示す図である。 図１４は、実施の形態２における、不正通知フレームの例を示す図である。 図１５は、実施の形態２における、不正検知ルール保持部に格納される不正検知ルールの例を示す図である。 図１６は、実施の形態２における、ＥＣＵの構成を示す図である。 図１７は、実施の形態２における、優先度ルール保持部に格納される優先度ルールの例を示す図である。 図１８は、実施の形態２における、フレーム受信履歴保持部に格納されるフレーム受信履歴の例を示す図である。 図１９は、実施の形態２における、ゲートウェイのフレーム受信時の処理を示すフローチャートである。 図２０は、実施の形態２における、ＥＣＵの処理を示すフローチャートである。 図２１は、実施の形態２における、車両と不正検知サーバとの間の正常時の処理シーケンスを示す図である。 図２２は、実施の形態２における、車両と不正検知サーバとの間の不正検知時の処理シーケンスの第一例を示す図である。 図２３は、実施の形態２における、車両と不正検知サーバとの間の不正検知時の処理シーケンスの第二例を示す図である。 図２４は、実施の形態２における、車両と不正検知サーバとの間の不正検知時の処理シーケンスの第三例を示す図である。 図２５は、その他の変形例（６）における、車載ネットワーク監視システムの全体概要を示す図である。 図２６は、その他の変形例（７）における、不正検知サーバの処理フローチャートである。 図２７は、その他の変形例（８）における、車載ネットワークシステムの概要を示す図である。

本発明の一態様に係る電子制御装置は、車載ネットワークを含む車載ネットワークシステムに関する情報を、車両外部の不正検知サーバに通知する電子制御装置であって、前記車載ネットワークシステムを搭載する車両の状態と、前記車載ネットワークで通信されるメッセージの識別子と、前記メッセージの不正検知結果とのうちの１つ以上を用いて優先度を決定する優先度決定部と、前記車載ネットワークで通信されるメッセージを送受信する第一通信部と、前記車載ネットワークに関する情報を、前記第一通信部が受信した前記メッセージに基づいて抽出する車両ログ抽出部と、前記優先度と、前記車載ネットワークに関する情報とを含んだ通知情報を前記不正検知サーバに通知する第二通信部とを備える。

これにより、電子制御装置は、車載ネットワークシステムに関する情報を優先度とともに車外に設置される不正検知サーバにアップロードする。これにより、不正検知サーバは、車両内部の状況に応じた、通知情報の優先度を把握することが可能となる。そして、不正検知サーバにおいて、優先度に応じた分析等の処理が可能となり、分析に割り当てる計算資源の判断及び効率的な分析、対処すべき優先度の高い通知情報への即時対処につながり効果的である。

言い換えれば、車載ネットワークシステムにおける不正検知装置が受信する、車載ネットワークに関する情報が増大したとしても、車載ネットワークから通知される情報に優先度を示す情報が含まれているので、不正検知装置は、優先度を示す情報にしたがって上記情報を処理することができる。よって、不正検知装置の処理負荷を抑えつつ、即時の不正なイベント検出を可能にする。このようにして、電子制御装置は、車載ネットワークに関する情報が多数の車両から不正検知サーバにアップロードされたとしても、不正検知サーバの処理負荷の増大を抑えることができる。

例えば、前記車両の状態は、前記第一通信部が受信した前記メッセージをもとに算出される情報であって、前記車両の速度、前記車両の加速度、前記車両の操舵角度、前記車両の運転支援機能の動作状況、及び、前記車載ネットワークの帯域占有率のうちの１つ以上を含む情報であってもよい。

これにより、車両の走行状態又はリスクが比較的高い状況が反映された優先度が不正検知サーバに送信される。そして、よりリスクの高い状況において、不正検知サーバでの処理優先度が高まり、安全性向上につながる。

例えば、前記優先度決定部は、前記メッセージの識別子により定まる前記メッセージの種別が、運転支援及び自動運転に関わる制御メッセージ、前記車両に搭載されている電子制御装置のファームウェアアップデートに関わるメッセージ、前記車両の走行状態通知に関わるメッセージ、及び、前記車両の診断用メッセージのいずれかを含む場合に、より高い前記優先度を決定してもよい。

これにより、より車両制御への影響の高いメッセージであることを示す情報が反映された優先度が不正検知サーバに送信される。そして、よりリスクの高いメッセージにおいて、不正検知サーバでの処理優先度が高まり、安全性向上につながる。

例えば、前記不正検知結果は、前記車載ネットワークで通信されるメッセージに含まれる、メッセージ認証コードの検証結果を含み、前記優先度決定部は、前記メッセージ認証コードの検証結果が不当である場合に、より高い前記優先度を決定してもよい。

これにより、車両内部で発生した不正な状況が反映された優先度が不正検知サーバに送信される。そして、よりリスクの高い不正な状況において、不正検知サーバでの処理優先度が高まり、安全性向上につながる。

例えば、前記電子制御装置は、さらに、前記車載ネットワークで通信されるメッセージの不正を検知する不正検知部を備え、前記メッセージの不正検知結果は、前記不正検知部が前記メッセージの不正を検出したか否かを示す情報であり、前記優先度決定部は、前記不正検知結果が、前記メッセージの不正を検出したことを示す場合に、より高い前記優先度を決定してもよい。

これにより、車両内部で発生した不正な状況が反映された優先度が不正検知サーバに送信される。そして、よりリスクの高い不正なメッセージにおいて、不正検知サーバでの処理優先度が高まり、安全性向上につながる。

例えば、前記通知情報は、前記通知情報に含まれる前記車載ネットワークに関する情報に係る前記メッセージの識別子を含み、前記第二通信部は、前記不正検知サーバに過去に通知した過去の通知情報を保持しており、前記不正検知サーバに新たな通知情報を通知する前に、前記過去の通知情報の中に、前記新たな通知情報に含まれる前記車載ネットワークに関する情報に係る前記メッセージの識別子、前記メッセージの不正検知結果、及び、前記優先度のうちの所定の一部が一致する場合に、前記通知情報を前記不正検知サーバに通知することを禁止してもよい。

これにより、同種の通知情報を不正検知サーバに繰り返し通知することを回避できる。その結果、ネットワークの通信帯域の削減および、サーバの処理負荷軽減につながり効果的である。

例えば、前記第二通信部は、前記優先度が第一の所定の値以下である場合には、不正検知サーバに前記通知情報を通知することを禁止する処理、又は、所定の通信間隔を有する第一タイミングで不正検知サーバに前記通知情報を通知する処理のいずれかの処理を行い、前記優先度が第二の所定の値以上である場合には、前記第一タイミングとは異なる第二タイミングで不正検知サーバに前記通知情報を通知してもよい。

これにより、優先度が比較的高い通知情報を即時に、不正検知サーバへ通知することが可能となり、リスクの高い状況において、即時の分析及び、対処が期待でき効果的である。

また、本開示の一態様に係る不正検知サーバは、車載ネットワークを含む車載ネットワークシステムに関する情報を含んだ通知情報を１以上の車両から受信する不正検知サーバであって、前記１以上の車両から、優先度と前記車載ネットワークシステムに関する情報とを含んだ通知情報を受信する第三通信部と、前記車載ネットワークシステムに関する情報から、前記車載ネットワークシステムに不正が発生しているか否かを分析するログ分析部を備え、前記ログ分析部は、前記通知情報に含まれる前記優先度が大きい前記通知情報ほど、前記通知情報に含まれる前記車載ネットワークシステムに関する情報の分析をより優先的に行う。

これにより、不正検知サーバは、車両内部の状況に応じた、通知情報の優先度を把握することが可能となる。そして、不正検知サーバにおいて、優先度に応じた分析等の処理が可能となり、分析に割り当てる計算資源の判断及び効率的な分析、対処すべき優先度の高い通知情報への即時対処につながり効果的である。

例えば、前記ログ分析部は、前記通知情報に含まれる前記優先度が大きいほど、前記車載ネットワークに関する情報の分析の順番をより早くし、前記車載ネットワークに関する情報の分析に割り当てる計算資源をより大きくし、又は、前記車載ネットワークに関する情報の分析の実行をするか否かの判定において、より優先的に実行すると判定してもよい。

これにより、不正検知サーバは、優先度の大きさに応じてより具体的に、車載ネットワークに関する情報の分析の順番、当該分析に割り当てる計算資源の大きさ、当該分析を実行するか否かについて決定し、分析の処理を制御することができる。

例えば、前記不正検知サーバは、さらに、前記車載ネットワークの不正に対処する処理を行う対処部を備え、前記ログ分析部は、前記優先度が第一の所定の値以下である場合には、前記車載ネットワークに関する情報の分析を禁止し、前記対処部は、前記優先度が第二の所定の値以上である場合に、前記車載ネットワークの不正に対処する処理を行ってもよい。

これにより、あらかじめ定められた閾値をもとに、優先度に応じた分析等の処理が可能となる。そして、分析に割り当てる計算資源の判断及び効率的な分析、対処すべき優先度の高い通知情報への即時対処につながり効果的である。

例えば、前記対処部は、前記１以上の車両のうちの車両が備える前記車載ネットワークの不正に対する対処として、（ａ）不正検知サーバ外部の管理者への不正発生の通知、（ｂ）前記車両に対する、運転支援機能及び自動運転機能を無効化する制御信号の通知、（ｃ）前記車両に含まれる暗号鍵情報の更新、（ｄ）前記車両に対する、機能安全モードへの移行の通知、（ｅ）前記車両に対する、遠隔制御モードへの移行の通知、（ｆ）前記車両の外部に存在するオペレータとの通話、（ｇ）前記車両に含まれる情報系システムの強制終了、及び、（ｈ）前記車両に含まれる電子制御装置のファームウェアのアップデート、のいずれか１つ以上を行ってもよい。

これにより、不正検知サーバの分析結果にしたがって、安全な車両制御のための具体的な対処を促すことが可能となり、効果的である。

例えば、前記不正検知サーバは、さらに、前記１以上の車両が前記不正検知サーバに通知する前記通知情報の前記優先度の下限値を設定する設定部を備え、前記設定部は、前記不正検知サーバの処理負荷を測定し、計測した前記不正検知サーバの処理負荷が所定の値以上である場合に、前記優先度の下限値を上昇させて、前記車両に通知してもよい。

これにより、サーバの処理負荷に応じて、車両から通知される情報を制限することが可能となり、通信量の削減及び、サーバの処理負荷安定化の観点から効果的である。

また、本開示の一態様に係る車載ネットワークシステムは、車載ネットワークを含む車載ネットワークシステムに関する情報を含んだ通知情報を、車両外部の不正検知サーバに通知する車載ネットワークシステムであって、前記車載ネットワークシステムは、第一電子制御装置と、第二電子制御装置と、を備え、前記第一電子制御装置は、前記車載ネットワークで通信されるメッセージの不正を検知する不正検知部と、前記不正検知部が前記メッセージの不正検知結果を、前記第二電子制御装置に通知する不正通知部とを備え、前記第二電子制御装置は、前記車載ネットワークシステムを搭載する車両の状態と、前記車載ネットワークシステムで通信されるメッセージの識別子と、前記メッセージの不正検知結果とのうちの１つ以上を用いて優先度を決定する第二優先度決定部と、前記車載ネットワークで通信されるメッセージを送受信する第四通信部と、前記車載ネットワークに関する情報を、前記第四通信部が受信した前記メッセージに基づいて抽出する第二車両ログ抽出部と、前記第一電子制御装置から前記メッセージの不正検知結果を受信する第二不正検知結果受信部と、前記優先度と、前記車載ネットワークに関する情報とを含んだ通知情報を前記不正検知サーバへ通知する第五通信部とを備える。

これにより、第一及び第二の電子制御装置を用いて通知された優先度と情報とに基づいて、不正検知サーバが、車両内部の状況に応じた、通知情報の優先度を把握することが可能となる。そして、不正検知サーバにおいて、優先度に応じた分析等の処理が可能となり、分析に割り当てる計算資源の判断及び効率的な分析、対処すべき優先度の高い通知情報への即時対処につながり効果的である。

例えば、前記車載ネットワークシステムは、さらに、第三電子制御装置を備え、前記第三電子制御装置は、前記車載ネットワークシステムを搭載する車両の状態と、前記車載ネットワークシステムに通信されるメッセージの識別子と、前記メッセージの不正検知結果とのうちの１つ以上を用いて優先度を決定する第三優先度決定部と、前記車載ネットワークで通信されるメッセージを送受信する第六通信部と、前記車載ネットワークに関する情報を、前記第六通信部が受信した前記メッセージに基づいて抽出する第三車両ログ抽出部と、前記第一電子制御装置から前記メッセージの不正検知結果を受信する第三不正検知結果受信部と、前記優先度と、前記車載ネットワークに関する情報とを含んだ通知情報を前記不正検知サーバへ通知する第七通信部とを備え、前記不正通知部は、検知した不正なメッセージに含まれる識別子が、第一電子制御装置が送信するメッセージの識別子である場合に、前記不正検知結果を前記第三電子制御装置へ通知してもよい。

これにより、車両内部の不正である疑いがある電子制御装置を介さずに、車載ネットワークに関する情報を、不正検知サーバに通知することが可能となり、安全性の向上に効果的である。

また、本開示の一態様に係る車載ネットワーク監視システムは、車両に搭載される車載ネットワークを監視する、車載ネットワーク監視システムであって、前記車載ネットワーク監視システムは、前記車載ネットワークを含む車載ネットワークシステムに関する情報を、車両外部の不正検知サーバに通知する電子制御装置と、前記不正検知サーバと、を含み、前記電子制御装置は、前記車載ネットワークシステムを搭載する車両の状態と、前記車載ネットワークで通信されるメッセージの識別子と、前記メッセージの不正検知結果とのうちの１つ以上を用いて優先度を決定する優先度決定部と、前記車載ネットワークで通信されるメッセージを送受信する第一通信部と、前記車載ネットワークに関する情報を、前記第一通信部が受信した前記メッセージに基づいて抽出する車両ログ抽出部と、前記優先度と、前記車載ネットワークに関する情報とを含んだ通知情報を前記不正検知サーバに通知する第二通信部とを備え、前記不正検知サーバは、前記１以上の車両から、優先度と前記車載ネットワークシステムに関する情報とを含んだ通知情報を受信する第三通信部と、前記車載ネットワークシステムに関する情報から、前記車載ネットワークシステムに不正が発生しているか否かを分析するログ分析部を備え、前記ログ分析部は、前記通知情報に含まれる前記優先度が大きい前記通知情報ほど、前記通知情報に含まれる前記車載ネットワークシステムに関する情報の分析をより優先的に行う。

これにより、車載ネットワーク監視システムは、上記電子制御装置及び上記不正検知サーバと同様の効果を奏する。

また、本開示の一態様に係る車載ネットワーク監視方法は、車両に搭載される車載ネットワークを監視する、車載ネットワーク監視方法であって、車載ネットワークシステムを搭載する車両の状態と、前記車載ネットワークで通信されるメッセージの識別子と、前記メッセージの不正検知結果とのうちの１つ以上を用いて優先度を決定する優先度決定ステップと、前記車載ネットワークで通信されるメッセージを送受信する第一通信ステップと、前記車載ネットワークに関する情報を、前記第一通信ステップで受信した前記メッセージに基づいて抽出する車両ログ抽出ステップと、前記優先度と、前記車載ネットワークに関する情報とを含んだ通知情報を通知する第二通信ステップと、前記１以上の車両から、優先度と前記車載ネットワークシステムに関する情報とを含んだ通知情報を受信する第三通信ステップと、前記車載ネットワークシステムに関する情報から、前記車載ネットワークシステムに不正が発生しているか否かを分析するログ分析ステップとを含み、前記ログ分析ステップでは、前記通知情報に含まれる前記優先度が大きい前記通知情報ほど、前記通知情報に含まれる前記車載ネットワークシステムに関する情報の分析をより優先的に行う。

これにより、車載ネットワーク監視方法は、上記電子制御装置及び上記不正検知サーバと同様の効果を奏する。

なお、これらの包括的または具体的な態様は、システム、方法、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ−ＲＯＭなどの記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラムまたは記録媒体の任意な組み合わせで実現されてもよい。

以下、実施の形態について、図面を参照しながら具体的に説明する。

なお、以下で説明する実施の形態は、いずれも包括的または具体的な例を示すものである。以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置位置及び接続形態、ステップ、ステップの順序などは、一例であり、本発明を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素については、任意の構成要素として説明される。

（実施の形態１）
以下、複数の電子制御ユニット（電子制御装置又はＥＣＵともいう）がＣＡＮバスを介して通信する車載ネットワーク（車載ネットワークシステム）を搭載した複数台の車両と、サーバ（不正検知サーバともいう）とを含む車載ネットワーク監視システム、並びに、車載ネットワークシステムに関する情報を不正検知サーバに通知する情報通知方法について説明する。

この情報通知方法では、車載ネットワークシステム上に流れるフレームの情報に加えて、不正検知サーバの処理の優先度を示す情報を含めて、電子制御装置が不正検知サーバに情報を通知する。

不正検知サーバは、車載ネットワークシステム上のフレームを大量に通知されたとしても、優先度に従い、不正検知処理を行うことができるので、即時の不正検知および、サーバの処理負荷低減につながり有用である。

［１．１ 車載ネットワーク監視システムの全体構成］
図１は、本実施の形態に関わる車載ネットワーク監視システムの全体構成を示す図である。車載ネットワーク監視システムは、不正検知サーバ８０と、車両１０１０ａ、１０１０ｂ、１０１０ｃ、１０１０ｄ、１０１０ｅ及び１０１０ｆとが、通信路であるネットワーク８１で接続されて構成される。

ネットワーク８１は、インターネットあるいは、専用回線を含みうる。車両１０１０ａ、１０１０ｂ、１０１０ｃ、１０１０ｄ、１０１０ｅ及び１０１０ｆは、車内の制御装置、センサ、アクチュエータ、ユーザインタフェース装置等の各種機器に接続されて、車内のバス（ＣＡＮバス）を介して通信を行う複数のＥＣＵを含んで構成される車載ネットワークを備える。

各車両の車載ネットワークでは、各ＥＣＵはＣＡＮプロトコルにしたがって通信を行う。ＣＡＮプロトコルにおけるフレームには、データフレーム、リモートフレーム、オーバーロードフレーム及びエラーフレームがある。ここでは主としてデータフレームに注目して説明する。なお、ＣＡＮにおいてデータフレームは、ＩＤを格納するＩＤフィールド、データ長を示すＤＬＣ（Ｄａｔａ Ｌｅｎｇｔｈ Ｃｏｄｅ）、データを格納するデータフィールドを含むように規定されている。

車両１０１０ａ及び１０１０ｂは、車種Ａの車両であり、車両１０１０ｃ及び１０１０ｄは、車種Ｂの車両であり、車両１０１０ｅ及び１０１０ｆは、車種Ｃの車両である。

ここで、車種が同一の車両同士は、車載ネットワークの構成が同一である。すなわち、ここでの車種が同一の車両は、例えば、型式（車両型式）が同一の車両であり、車両の識別情報としての車両ＩＤの一部が同一の車両である。同一車種の複数の車両において、車載ネットワークのＣＡＮバスに流れるデータフレーム（メッセージ）の利用に関する仕様（メッセージＩＤごとのデータフィールドの内容の規定等）は同じである。

また、車種が相違する車両同士において、同種のＥＣＵを備えることもある。同種のＥＣＵとは、構成が同一のＥＣＵであり、例えば、同じ製造業者による同型式のＥＣＵであり、また、主たる機能を実現するための構成が同一のＥＣＵを含むこととしてもよい。

車種が相違する車両同士において同種のＥＣＵを搭載している場合には、その各車両の同種ＥＣＵが送信するフレームのＩＤは互いに異なり得る。

［１．２ 車載ネットワークシステムの構成］
図２は、車種Ａの車両１０１０ａ（車両１０１０ｂも同様）における車載ネットワークシステムの構成の一例を示す図である。他の車種の車両においては、図２に示す構成と同様の構成あるいは、一部異なる構成等を備える。

車両１０１０ａ等における車載ネットワークシステムは、バス（ＣＡＮバス）１０、２０、３０、４０及び５０により接続された複数のＥＣＵ（ＥＣＵ１００、１０１、２００、２０１、３００、３０１、３０２、４００及び４０１）とゲートウェイ９００といった各ノードを含んで構成される。なおゲートウェイ９００もＥＣＵの１つである。図２では省略しているものの、車載ネットワークシステムには、さらに多くのＥＣＵが含まれうる。

ＥＣＵは、例えば、プロセッサ（マイクロプロセッサ）、メモリ等のデジタル回路、アナログ回路、通信回路等を含む装置である。メモリは、ＲＯＭ、ＲＡＭであり、プロセッサにより実行される制御プログラム（コンピュータプログラム）を記憶することができる。例えばプロセッサが、制御プログラムにしたがって動作することにより、ＥＣＵは各種機能を実現する。なお、コンピュータプログラムは、所定の機能を実現するために、プロセッサに対する命令コードが複数個組み合わされて構成されたものである。

バス１０には、それぞれエンジン１１０及びトランスミッション１１１に接続されたＥＣＵ（エンジンのＥＣＵ）１００及びＥＣＵ（トランスミッションのＥＣＵ）１０１を含む、モータ、燃料、電池の制御といった車両の「走る」に関連するパワートレイン系のＥＣＵが、接続されている。

バス２０には、それぞれ、ブレーキ２１０及びステアリング２１１に接続されたＥＣＵ（ブレーキのＥＣＵ）２００及びＥＣＵ（ステアリングのＥＣＵ）２０１を含む、「曲がる」、「止まる」等といった車両の挙動等の制御に関連するシャーシ系のＥＣＵが、接続されている。

バス３０には、それぞれカメラ３１０、カーナビゲーション装置（カーナビともいう）３１１及び車車間通信モジュール３１２に接続されたＥＣＵ３００、ＥＣＵ３０１及びＥＣＵ３０２を含む、カメラ情報を元に運転支援の認知、判断及び制御を行う機能、又は、オーディオヘッドユニットに関わる機能、車車間通信といった情報系に関連するＥＣＵが接続されている。

バス４０には、それぞれドア４１０及びライト４１１に接続されたＥＣＵ４００及びＥＣＵ４０１を含む、エアコン又はウィンカー等といった車両の装備の制御に関連するボディ系のＥＣＵが、接続されている。

バス５０には、例えばＯＢＤ２（Ｏｎ−Ｂｏａｒｄ Ｄｉａｇｎｏｓｔｉｃｓ２）等といった、外部の診断ツール（故障診断ツール）等と通信するためのインタフェースである診断ポート５１０が接続されている。

ＥＣＵ（ＥＣＵ１００及び２００等）のそれぞれは、接続されている機器（エンジン１１０、ブレーキ２１０等）の状態を取得し、定期的に状態を表すフレーム等を車載ネットワークつまりＣＡＮバスに送信している。

バス１０に接続されたＥＣＵ１００、１０１と、バス２０に接続されたＥＣＵ２００、２０１と、バス３０に接続されたＥＣＵ３００、３０１及び３０２とは、メッセージ認証コード（ＭＡＣ、Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）を処理する機能を有するＥＣＵであるＭＡＣ対応ＥＣＵである。ＭＡＣを処理する機能とは、具体的には、ＭＡＣの生成機能及びＭＡＣの検証機能などである。

バス４０に接続されたＥＣＵ４００及び４０１は、ＭＡＣを処理する機能を有しないＭＡＣ非対応ＥＣＵである。

ゲートウェイ９００は、ＭＡＣの生成機能および検証機能を有するＭＡＣ対応ＥＣＵである。

ゲートウェイ９００は、異なる複数の通信路を接続して通信路間でデータを転送するＥＣＵである。ゲートウェイ９００は、バス１０、バス２０、バス３０、バス４０及びバス５０と接続している。つまり、ゲートウェイ９００は、ゲートウェイ９００に接続されている一のバスから受信したフレーム（データフレーム）を、一定条件下で他のバス（つまり条件に応じて選択した転送先バス）に転送する機能を有する一種のＥＣＵである。

ゲートウェイ９００は、車両の外部の不正検知サーバ８０と通信するための通信装置（通信回路等）を備え、例えば、各バスから受信したフレームについての情報を不正検知サーバ８０に送信（アップロード）する機能を有する。ゲートウェイ９００の構成については、後に詳細に説明する。

［１．３ 不正検知サーバの構成］
図３は、不正検知サーバ８０の構成図である。不正検知サーバ８０は、車両１０１０ａ等の車載ネットワークで送信される不正なフレームに対処するためのサーバである。不正検知サーバ８０は、例えばプロセッサ、メモリ、通信インタフェース等を備えるコンピュータにより実現され、通信部８１０と、処理判断部８２０と、ログ収集部８３０と、ログ分析部８４０と、結果通知部８５０と、受付部８６０と、対処部８７０と、車両情報ＤＢ８８０と、車両ログ格納ＤＢ８８１と、分析結果格納ＤＢ８８２と、セキュリティ情報ＤＢ８８３と、設定部８９０とを含んで構成される。

車両情報ＤＢ８８０と、車両ログ格納ＤＢ８８１と、分析結果格納ＤＢ８８２と、セキュリティ情報ＤＢ８８３とは、例えば、メモリ、ハードディスクといった記憶媒体等により実現されうる。

また、処理判断部８２０、ログ分析部８４０、ログ収集部８３０、対処部８７０および設定部８９０それぞれの機能は、例えば、メモリに格納された制御プログラムがプロセッサにより実行されることにより、実現されうる。

通信部８１０は、通信インタフェース、メモリに格納された制御プログラムを実行するプロセッサ等により実現される。通信部８１０は、第三通信部に相当する。

通信部８１０は、車両１０１０ａ、１０１０ｂ、１０１０ｃ、１０１０ｄ、１０１０ｅ及び１０１０ｆと、ネットワークを介して通信することで、各車載ネットワークに関する情報を受信する。車載ネットワークに関する情報は、例えば、各車載ネットワークのＣＡＮバス上に流れたフレームの内容、受信タイミング（間隔又は頻度等）、バス負荷率及びフレームのＭＡＣ検証結果に関する情報が含まれうる。

また、各車載ネットワークに関する情報に加えて、現在の車両の状態等のメタ情報が併せて通知される。メタ情報は、現在の車両の位置、ＢＳＭ（Ｂａｓｉｃ Ｓａｆｅｔｙ Ｍｅｓｓａｇｅ）、天候、車載ネットワークに関する情報の処理優先度を示す情報が含まれうる。車両の位置は、例えばＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）により取得されるＧＰＳ位置である。

また、通信部８１０は、対処部８７０から通知される、車両セキュリティインシデントに対処するためのセキュリティ用情報を、各車両に送信する。セキュリティ用情報は、例えば、車両の乗員等を対象としたアラート（警告）通知のための提示用情報、車両の走行等の制御指示を示す制御情報、車両において暗号処理の適用に際して用いられる暗号鍵の更新を指示するための制御情報、車両側でフレームに関わる不正を検知するための不正検知用情報、自動運転システム若しくは運転支援システムを無効化するための情報、オーディオヘッドユニット若しくは外部通信モジュールの機能を無効化するための情報、又は、車両をフェイルセーフモードへ移行させる制御情報等である。

処理判断部８２０は、通信部８１０から通知される、車載ネットワークに関する情報に対する処理内容を判断する。このとき、メタ情報をもとに、処理内容を判断する。

処理判断部８２０は、例えば、メタ情報に含まれる優先度が比較的低いときは、通知された情報をログ収集部８３０へ通知することで、車両ログ格納ＤＢ８８１へ保存する。なお、優先度が比較的低いとは、例えば、優先度が所定の閾値以下である範囲に属すること、又は、優先度が比較的低いことを意味する所定値であることをいう。より具体的には、所定値は、優先度が０〜５の範囲の整数値で表現される場合において０とする。

また、優先度が中程度であるときは、通知された情報をログ収集部８３０へ通知するとともに、ログ分析部８４０に、通知されたログの分析を処理するように通知する。なお、優先度が中程度であるとは、例えば、優先度が比較的低い場合と、比較的高い場合との間の範囲に属すること、又は、優先度が中程度であることを意味する所定値であることをいう。より具体的には、所定値は、優先度が０〜５の範囲の整数値で表現される場合において、１、２又は３とする。

また、優先度が比較的高いときは、通知された情報をログ収集部８３０へ通知するとともに、ログ分析部８４０に、通知されたログの分析をするように通知するとともに、優先的に、分析処理にメモリまたはＣＰＵのリソースを割り当てる。なお、優先度が比較的高いとは、例えば、優先度が所定の閾値以上である範囲に属すること、又は、優先度が比較的高いことを意味する所定値であることをいう。より具体的には、所定値は、優先度が０〜５の範囲の整数値で表現される場合において４又は５とする。

さらに、優先度が最高であるときは、通知された情報をログ収集部８３０へ通知するとともに、ログ分析部８４０へ、分析をするように通知し、さらに、結果通知部８５０へ、情報を通知することで、不正なイベントを車載ネットワーク監視システムの管理者、またはセキュリティオペレーションセンターのセキュリティアナリストへ通知する。なお、優先度が最高であるとは、優先度が、とりうる値のうちでの最高の値であることをいう。例えば、優先度が０〜５の範囲の整数値で表現される場合において、５とする。

ログ収集部８３０は、各車両から収集したログ情報の内容である各種データ（車載ネットワークで受信されたフレームについての情報等）を、車両情報ＤＢ８８０に格納されている情報に基づき、車両ログ格納ＤＢ８８１に格納する。

ログ収集部８３０は、各種データを車両ログ格納ＤＢ８８１へ格納する際に、各種データに所定の正規化等の処理を施してもよい。

車両情報ＤＢ８８０に格納されるデータについては、図４を用いて後に説明する。また、車両ログ格納ＤＢ８８１に格納されるデータ（車両ログ情報）については図５を用いて後に説明する。

ログ分析部８４０は、車載ネットワークシステムに関する情報から、車載ネットワークシステムに不正が発生しているか否かを分析する。ログ分析部８４０は、通知情報に含まれる優先度が大きい通知情報ほど、通知情報に含まれる車載ネットワークシステムに関する情報の分析をより優先的に行う。なお、ログ分析部８４０は、優先度が第一の所定の値以下である場合には、車載ネットワークに関する情報の分析を禁止してもよい。第一の所定の値は、例えばゼロである。

具体的には、ログ分析部８４０は、車両ログ格納ＤＢ８８１に格納された各車両から収集されたログ情報を用いて分析することにより、ある車両の車載ネットワークで受信されたフレームが不正であるか否か、つまり、攻撃者によりその車載ネットワークに攻撃フレームが送信されたか否かを判断する機能を有する。

ログ分析部８４０は、蓄積されたログ情報が表す、各車両から収集された複数のフレームについての情報、より具体的には、複数のフレームそれぞれの内容、受信タイミング等の情報について、例えば、統計処理等を行いうる。

ログ分析部８４０は、通信部８１０により取得された複数のフレームについての情報と、その複数のフレームについての取得より後に、通信部８１０により取得された、一の車両（例えば車両１０１０ａ）の車載ネットワークおいて受信されたフレームについての情報とに基づいて、その一の車両の車載ネットワークにおいて受信されたそのフレームの異常度、又は、異常の有無を判断する機能を持つ。

ログ分析部８４０は、例えば、正常状態において車載ネットワークで流れる各フレームについての所定モデルであって、異常状態との比較に用いることができる所定モデルを構築し、逐次取得されるログ情報に基づいて機械学習を用いて所定モデルをより適切なものへと調整（更新）することとしてもよい。

この場合に、ログ分析部８４０は、集積したログ情報が表す複数のフレームについての情報に適宜、加工処理（例えば多変量解析等）を施して、所定モデルの学習のために供給し得る。所定モデルの学習には、教師あり学習、教師なし学習のいずれの方式を用いてもよい。

例えば、各車両の車載ネットワークシステムにおいて、所定ルールに基づいてそのルールに適合しないフレーム（不正フレーム）がＣＡＮバスに流れたことを検知する不正検知機能がある場合には、不正フレームか不正でないフレームかの区別を示す情報をログ情報に含ませてもよく、ログ分析部８４０では、その区別を示す情報に基づいて、所定モデルについて教師あり学習を行ってもよい。

また、ログ分析部８４０では、各車両から不正フレームでないフレームについてのログ情報を収集して、或いは不正フレームか否かについて区別せずにログ情報を収集して、これらのログ情報に基づいて、所定モデルについて教師なし学習を行ってもよい。

この所定モデルは、ある車両の車載ネットワークで受信されたフレームについての異常度（異常の度合い）の算定に利用される。所定モデルの内容は、そのフレームの異常度の算定に用いることができるものであればよい。

異常度は、例えば、そのフレームについての情報と所定モデルとの比較（つまりフレームについての情報と所定モデルとを用いた演算処理）により算定される。ログ分析部８４０は、異常度の算定のための所定モデルとして、例えば、同一車種の各車両におけるログ情報に基づいて、正常状態において車載ネットワークで受信されるフレームについての特徴量、より具体的には、フレームの内容、受信間隔、受信頻度等の各成分を含む特徴ベクトル等の分布を表わすように所定モデルを構築し得る。

なお、所定モデルは、例えば、異常度を目的変数としてログ情報を説明変数とする場合の目的変数と説明変数との間の関係を表すモデルであってもよい。異常度は、例えば、異常なし（つまり正常）の場合に０（ゼロ）とし、異常ありの場合に異常の度合いに応じた正の数値をとるように定め得る。異常度は、０（例えば異常なし）と１（例えば異常あり）との２値をとるものであってもよいし、異常ありを複数段階に区別して３値以上をとるものであってもよい。

異常度が所定閾値を超える場合に異常ありと判別するような活用も可能である。一例としては、ある車両の車載ネットワークで受信されたフレームの異常度は、そのフレームの特徴量が、既に集積されたログ情報に基づいて定められた所定モデルが示す特徴量の分布（例えば平均値と分散で特定される正規分布）に対する標準偏差に所定係数（例えば３）を乗じて定まる閾値を境界とする範囲の内に位置するか否かで算定でき、また、所定係数を複数用いることで異常度を複数段階に算定できる。異常度を算定するための所定モデルの構築に用いられる手法としては、外れ値検出、又は、時系列上の急激な変化を検出する変化点検出等の手法がある。

このようにログ分析部８４０は、集積されたログ情報（車両ログ情報）が表す各車両の車載ネットワークで受信された複数のフレームについての情報に基づいて、その複数のフレームについての受信より後に、ある車両の車載ネットワークにおいて受信されたフレームの異常度等を算定する。ある車両の車載ネットワークにおいて受信されたフレームの情報もその車両のログ情報から得ることができる。

ある車両の車載ネットワークで受信されたフレームについて算定した異常度により異常ありと判別した場合（つまり攻撃フレームを検知した場合）に、ログ分析部８４０は、結果通知部８５０へ、分析結果を通知することで、不正なイベントの発生を車載ネットワーク監視システムの管理者あるいは、セキュリティオペレーションセンターに所属するセキュリティアナリストへ通知する。

ログ分析部８４０は、集積したログ情報に基づく統計処理、所定モデルの更新（学習）、ある車両の車載ネットワークで受信されたフレームの異常度の算定等の各種分析処理を逐次行う。

そしてログ分析部８４０は、その分析処理の結果（例えば更新後の所定モデルを表わす情報、算定した異常度に関する情報等）を、分析結果格納ＤＢ８８２に格納して保存し、次回の分析処理（つまりフレームの異常度の算定等）に利用する。分析結果格納ＤＢ８８２に格納されるデータは図６を用いて後に説明する。

結果通知部８５０は、処理判断部８２０、またはログ分析部８４０から、車載ネットワーク監視システムの管理者に通知すべき不正なイベントがあると判断された場合に、分析結果格納ＤＢ８８２に格納される不正なイベントに関わる情報を、車載ネットワーク監視システムの管理者Ｕへ通知する手段を備える。

例えば、結果通知部８５０は、ディスプレイに接続され、不正な発生のイベントをディスプレイ上に表示する等を行う。また、結果通知部８５０は、Ｗｅｂサーバとして機能してもよいし、メールサーバとして、管理者Ｕにメール通知を行ってもよい。

なお通知先は、車載ネットワーク監視システムの管理者Ｕでなくてもよい、例えば車載ネットワーク監視業務を委託されたセキュリティオペレーションセンターのセキュリティアナリストへ通知するとしてもよい。

受付部８６０は、車載ネットワーク監視システムの管理者Ｕから、不正なイベントに対する対処のための操作を受け付ける。例えば、受付部８６０は、ＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）を備えており、ＧＵＩを介して不正なイベントに対する対処のための操作を受け付けてもよい。なお、受付部８６０は、マイクと備え、マイクによって取得した管理者Ｕの音声に対する音声認識処理により、不正なイベントに対する対処のための操作を受け付けてもよい。

対処の例としては、車両の乗員等を対象としたアラート（警告）通知、車両の走行等の遠隔制御、車両において暗号処理の適用に際して用いられる暗号鍵の更新、車載ネットワークシステムのアップデート、自動運転システム若しくは運転支援システムを無効化、オーディオヘッドユニット若しくは外部通信モジュールの機能を無効化、車両のフェイルセーフモードへの移行、又は、オペレータとの通話などが含まれうる。

受付部８６０は、車載ネットワーク監視システムの管理者から、対処の処理を受け付けると、対処部８７０へ、その処理の内容を通知する。

対処部８７０は、車載ネットワークの不正に対処する処理を行う。対処部８７０は、受付部８６０から通知された内容を実現するために、セキュリティ情報ＤＢ８８３に格納される情報をもとに、通信部８１０へ通信内容を通知する。セキュリティ情報ＤＢ８８３に格納されるデータは図７を用いて後に説明する。

対処部８７０は、１以上の車両のうちの車両が備える車載ネットワークの不正に対する対処として、例えば、（ａ）不正検知サーバ８０外部の管理者への不正発生の通知、（ｂ）車両に対する、運転支援機能及び自動運転機能を無効化する制御信号の通知、（ｃ）車両に含まれる暗号鍵情報の更新、（ｄ）車両に対する、機能安全モードへの移行の通知、（ｅ）車両に対する、遠隔制御モードへの移行の通知、（ｆ）車両の外部に存在するオペレータとの通話、（ｇ）車両に含まれる情報系システムの強制終了、及び、（ｈ）車両に含まれる電子制御装置のファームウェアのアップデート、のいずれか１つ以上を行う。

なお、優先度が第二の所定の値以上である場合に限り、車載ネットワークの不正に対処する処理を行うようにしてもよい。第二の所定の値は、例えば１である。

設定部８９０は、１以上の車両が不正検知サーバ８０に通知する通知情報の優先度の下限値を設定する。設定部８９０は、不正検知サーバ８０の処理負荷を測定し、計測した不正検知サーバ８０の処理負荷が所定の値以上である場合に、優先度の下限値を上昇させて、車両に通知する。所定の値は、例えば、７０％〜８０％とすることができる。なお、設定部８９０は、必須の構成ではない。

なお、本実施の形態においては、不正検知サーバ８０内に受付部８６０と対処部８７０を含む構成を示したが、これらは同一サーバ内に含まれていなくてもよい。例えば、ログ分析を行った結果を通知する不正検知サーバ８０とは別に、対処を行うインシデントレスポンスサーバが存在し、その構成に受付部８６０と、対処部８７０とが含まれていてもよい。

［１．４ 車両情報ＤＢ］
図４は、不正検知サーバ８０の車両情報ＤＢ８８０が保持する車両情報の一例を示す図である。図４に示すように車両情報は、車種ごとに共通の設計情報などを含む。設計情報は、その車種の車両が搭載しているＥＣＵのＩＤ（つまりＥＣＵの種別を識別するための型式等）と、そのＥＣＵが送信するフレームのＩＤ（つまりＣＡＮメッセージＩＤ）と、フレームの送信されるバスの識別情報と、そのフレームにＭＡＣが含まれているか否かとを対応付けた情報である。

なお、車両情報はこれらに限らない。例えば、フレームの送信設定周期、又は、フレームに含まれるデータフィールドを適切なフィールドに分割する信号表を保持していてもよい。

例えば、図４に示される車両情報では、車種Ａの車載ネットワークを構成するＥＣＵ ＩＤが「００１」であるＥＣＵが、ＣＡＮメッセージＩＤ「０ｘ１００」のフレームと、ＣＡＮメッセージＩＤ「０ｘ１０１」のフレームとを送信することが示されている。

そして、ＣＡＮメッセージＩＤが「０ｘ１００」のフレームがバス１０に送信されること、及び、ＣＡＮメッセージＩＤが「０ｘ１０１」のフレームがバス２０に送信されることが示されている。また、いずれのフレームもＭＡＣを含んでいることが示されている。

同様に、図４に示される車両情報では、ＥＣＵ ＩＤが「００２」のＥＣＵが、ＣＡＮメッセージＩＤが「０ｘ２００」のフレームをバス１０に、ＭＡＣを含めずに送信することが示されている。

また、図４に示される車両情報では、車種Ｂの車載ネットワークを構成するＥＣＵ ＩＤが「００１」であるＥＣＵが、ＣＡＮメッセージＩＤ「０ｘ１１０」のフレームと、ＣＡＮメッセージＩＤ「０ｘ１１１」のフレームとを送信することが示されている。

そして、ＣＡＮメッセージＩＤが「０ｘ１１０」のフレームがバス１０に送信されること、及び、ＣＡＮメッセージＩＤが「０ｘ１１１」のフレームがバス２０に送信されることが示されている。また、いずれのフレームもＭＡＣを含んでいることが示しされいる。

同様に、図４に示される車両情報では、ＥＣＵ ＩＤが「００３」のＥＣＵが、ＣＡＮメッセージＩＤが「０ｘ３０１」のフレームをバス３０に、ＭＡＣを含めて送信するが示されている。

この例では、車種Ａの車両と車種Ｂの車両とは、同種のＥＣＵ（つまり、ＥＣＵ ＩＤが「００１」のＥＣＵ）を搭載しているが、それぞれのＥＣＵが送信するフレームについてのＣＡＮメッセージＩＤが互いに異なることを示している。このように同種のＥＣＵは、複数の車種の車両に搭載されうる。相違する車種の各車両に搭載された、同種のＥＣＵそれぞれが送信するフレームについては、フレームのＣＡＮメッセージＩＤが相違しうるだけで、そのほかのフレームの内容は、同一である。

［１．５ 車両ログ格納ＤＢ］
図５は、不正検知サーバ８０の車両ログ格納ＤＢ８８１の内容である車両ログ情報の一例を示す図である。図５に示すように車両ログ情報は、カーメーカが製造する各種車両について、車種と、車種ごとに車両を識別するための車両ＩＤと、車両に搭載される各ＥＣＵのＥＣＵ ＩＤと、その各ＥＣＵが送信するフレームについての情報であるＣＡＮログとを関連付けて表す情報である。この車両ログ情報は、不正検知サーバ８０が各車両から取得したログ情報を集積することで生成されている。

ここで、ＣＡＮログは、例えばＣＡＮフレームの識別情報（ＩＤ）、フレームの受信周期、フレームのＤＬＣが示すデータ長、又は、フレームのデータフィールドの内容であるデータ等を示し、各車両から受信したログ情報の内容に基づく情報である。

なお、ＣＡＮログの各情報は、ログ情報が示すＣＡＮのフレームについての特徴量（例えば特徴ベクトル等）を正規化したものであってもよい。

なお、車両ログ情報における車種は、例えば車両ＩＤに基づいて特定されうる。この車両ログ情報に基づく分析処理により、ログ分析部８４０では、ある車両の車載ネットワークで受信されたフレームについての異常度の算定等が行われる。

なお、図５では、記載を省略したが、車両ログ格納ＤＢ８８１には、車両状態、位置情報、又は、処理優先度等のメタ情報が含まれていてもよい。

［１．６ 分析結果格納ＤＢ］
図６は、不正検知サーバ８０の分析結果格納ＤＢ８８２の内容である分析結果の一例を示す図である。図６に示すように分析結果は、車種、車両ＩＤ、時刻、位置情報、車両状態、検知された異常、及び、優先度を含んで構成される。

例えば、図６の分析結果では、車種Ａであり、車両ＩＤが１０１０ａの車両が、時刻が２０２０年５月６日の１３時５１分３０秒であるときに東京を高速走行しており、そのときに、バスの負荷が高い「高バス負荷」の異常が検知されたことが示されている。また、上記の情報とともにゲートウェイ９００から通知された優先度が３であったことが示されている。

同様に、車種Ａであり、車両ＩＤが１０１０ａの車両が、時刻が２０２０年５月６日の１３時５１分２０秒であるときに東京を高速走行しており、そのときに、「高バス負荷」の異常が検知されたことが示されている。また、上記の情報とともにゲートウェイ９００から通知された優先度は２であったことが示されている。

また、車種Ａであり、車両ＩＤが１０１０ａの車両が、時刻が２０２０年５月６日の１３時４１分１８秒であるときに大阪を走行しており、そのときに偽装メッセージが検知された「偽装メッセージ検知」の異常が検知されたことが示されている。また、上記の情報とともにゲートウェイ９００から通知されたメタ情報の優先度は２であったことが示されている。

なお、図６では、位置情報を都道府県単位で記載しているが、ＧＰＳ情報などの情報であってもよい。

［１．７ セキュリティ情報ＤＢ］
図７は、不正検知サーバ８０のセキュリティ情報ＤＢ８８３の内容であるセキュリティ情報の一例を示す図である。図７に示すように、セキュリティ情報は、各車両が実行可能又は実行不可能である処理の一覧を保持している。

車載ネットワーク監視システムの管理者は、車種ごとに実行可能な処理のうちから、車載ネットワークの不正に対する対処として実行する処理を決定する。図７の例では、車種Ａは、運転支援の無効化とファームウェアの更新とを実行することが可能であるが、遠隔制御を実行することが不可であることが示されている。同様に車種Ｂは、運転支援の無効化と、遠隔制御と、ファームウェアの更新との全てを実行することが可能であることが示されている。また、車種Ｃは、ファームウェア更新を実行することが可能であり、運転支援の無効化と遠隔制御とを実行することが不可であることが示されている。また、車種Ｄは、車種Ａと同様に、運転支援の無効化とファームウェアの更新とを実行することが可能であるが、遠隔制御を実行することが不可であることを示している。

［１．８ ゲートウェイの構成］
図８は、ある車両（例えば車両１０１０ａ）の車載ネットワークにおけるゲートウェイ９００の構成を示す。ゲートウェイ９００は、車載ネットワークを含む車載ネットワークシステムに関する情報を、車両外部の不正検知サーバ８０に通知するＥＣＵである。

図８に示すように、ゲートウェイ９００は、フレーム送受信部９１０と、フレーム解釈部９２０と、優先度決定部９３０と、更新処理部９４０と、フレームアップロード部９５０と、転送制御部９６０と、鍵処理部９７０と、フレーム生成部９８０と、ルール保持部９９０と、転送ルール保持部９９１と、鍵保持部９９２とを含んで構成される。

これらの構成要素の各機能は、例えばゲートウェイ９００における通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。例えば、フレームアップロード部９５０及び、更新処理部９４０は、不正検知サーバ８０と通信するための通信回路等により実現される。

フレーム送受信部９１０は、バス１０、バス２０、バス３０、バス４０及びバス５０のそれぞれに対して、ＣＡＮプロトコルに従ったフレームを送受信する。フレーム送受信部９１０は、バスからフレームを１ｂｉｔずつ受信し、フレーム解釈部９２０に通知する。フレーム送受信部９１０は、第一通信部に相当する。

また、フレーム送受信部９１０は、フレーム生成部９８０より通知を受けた転送先のバスを示すバス情報及び送信用のフレームに基づいて、そのフレームの内容を、バス１０、バス２０、バス３０、バス４０及びバス５０のうち転送先のバスに、１ｂｉｔずつ送信する。

フレーム解釈部９２０は、フレーム送受信部９１０よりフレームの値を受け取り、ＣＡＮプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。フレーム解釈部９２０は、受信されたフレームの各フィールドの情報を優先度決定部９３０へ通知する。フレーム解釈部９２０は、車載ネットワークに関する情報を、フレーム送受信部９１０が受信したメッセージに基づいて抽出する車両ログ抽出部に相当する。

なお、フレーム解釈部９２０は、受け取ったフレームがＣＡＮプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部９８０へ通知する。

また、フレーム解釈部９２０は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降は、そのフレームを破棄する、つまりエラーフレームの解釈を中止する。

優先度決定部９３０は、車載ネットワークシステムを搭載する車両の状態と、車載ネットワークで通信されるメッセージの識別子と、メッセージの不正検知結果とのうちの１つ以上を用いて優先度を決定する。

優先度決定部９３０は、具体的には、ルール保持部９９０が保持する優先度ルールを参照し、不正検知サーバ８０へ通知するメッセージに含める優先度を決定する。一例としては、車両の走行状態を判断し、走行中であれば、優先度を中程度と決定する。ルール保持部９９０が保持するルールについては図９を用いて後に説明する。なお、優先度決定部９３０が優先度を決定することを、優先度を判断する、又は、優先度を算出すると表現することもできる。

優先度決定部９３０は、優先度を決定すると、フレームアップロード部９５０に、受信したフレームと、決定した優先度を通知する。優先度決定部９３０は、車両のイグニッションがＯＮになってからの起動時刻を保持するタイマ、又は、受信したフレームの個数を表すカウンタを保持するメモリ等を保有しており、バスごとに単位時間あたり（例えば１秒間）の受信フレームの個数を算出する。

また、優先度決定部９３０は、現在の車両の状態を保持するメモリを保有しており、例えば、現在の車両の速度情報、又は、加速度情報を記憶している。

ここで、車両の状態は、フレーム送受信部９１０が受信したメッセージをもとに算出される情報であって、車両の速度、車両の加速度、車両の操舵角度、車両の運転支援機能の動作状況、及び、車載ネットワークの帯域占有率のうちの１つ以上を含む情報であってもよい。

また、優先度決定部９３０は、メッセージの識別子により定まるメッセージの種別が、運転支援及び自動運転に関わる制御メッセージ、車両に搭載されている電子制御装置のファームウェアアップデートに関わるメッセージ、車両の走行状態通知に関わるメッセージ、及び、車両の診断用メッセージのいずれかを含む場合に、より高い優先度を決定してもよい。

また、上記不正検知結果は、車載ネットワークで通信されるメッセージに含まれる、メッセージ認証コードの検証結果を含んでいてもよい。その場合、優先度決定部９３０は、メッセージ認証コードの検証結果が不当である場合に、より高い優先度を決定する。

さらに、優先度決定部９３０は、さらに、車載ネットワークで通信されるメッセージの不正を検知する不正検知部９３１を備えてもよい。この場合、メッセージの不正検知結果は、不正検知部９３１がメッセージの不正を検出したか否かを示す情報とする。そして、優先度決定部９３０は、不正検知結果が、メッセージの不正を検出したことを示す場合に、より高い優先度を決定する。

更新処理部９４０は、ルール保持部９９０が保持している優先度ルールを、不正検知サーバ８０から取得される情報に基づいて更新する。

フレームアップロード部９５０は、優先度決定部９３０から通知される、いずれかのＣＡＮバスから受信されたフレームを逐次取得し、受信されたフレームについての情報（例えば、フレームの内容、受信間隔、受信頻度等）を含むログ情報を不正検知サーバ８０に送信（アップロード）する。フレームアップロード部９５０は、第二通信部に相当する。

この時にログ情報に加えて、優先度決定部９３０から通知される優先度をメタ情報として含めてアップロードする。メタ情報はさらに、その他の各種情報（車両の状態情報、Ｂａｓｉｃ Ｓａｆｅｔｙ Ｍｅｓｓａｇｅ、車両の位置情報、バス負荷率）を含めてもよい。

さらに、フレームアップロード部９５０は、ログ情報に、車両の識別情報（車両ＩＤ）を含める。フレームアップロード部９５０は、受信されたフレームについての情報として、不正検知サーバ８０で統計処理、機械学習等を行う場合に取り扱いやすいように、フレームの内容、受信間隔、又は、受信頻度等を加工する加工処理を施してもよい。

ここで、フレームの受信間隔は、例えば、そのフレームの受信時刻と、そのフレームと同一ＩＤのフレームが前回受信された時刻との差である。

また、フレームの受信頻度は、例えば、一定の単位時間において、そのフレームと同一ＩＤのフレームが受信された数である。この加工処理は、例えば、フレームの内容、受信間隔、受信頻度等の特徴から特徴量を抽出し、正規化等を行い、特徴量の情報量の縮約を行うこと等である。特徴量の情報量の縮約は、例えば、特徴量を各成分としての特徴ベクトルで表し、不正検知サーバ８０と連携して得た情報に基づいて、特徴ベクトルの次元数を主成分分析等の次元削減アルゴリズムを用いることで実現されうる。

また、フレームアップロード部９５０は、優先度決定部９３０から通知を受けるたびに、そのフレームについての情報を含むログ情報を不正検知サーバ８０に送信することとしてもよいし、優先度にしたがって不正検知サーバ８０に送信しないとしてもよい。但し、ＣＡＮバスから受信されたフレームについての情報を、迅速に不正検知サーバ８０へ伝えると、そのフレームが異常であるか否かを不正検知サーバ８０に迅速に検知させて対処を可能にしうる。

また、フレームアップロード部９５０は、例えば不正検知サーバ８０とのトラフィック量を削減すべく、無条件で、又は通信状況に応じて、ログ情報を圧縮して不正検知サーバ８０に送信してもよい。また、フレームアップロード部９５０は、フレーム送受信部９１０がＣＡＮバスから受信したフレームのうち全てのフレームについての情報ではなく特定の１つまたは複数のＩＤのフレームだけについての情報をログ情報に含めて送信してもよい。

また、フレームアップロード部９５０は、不正検知サーバ８０に過去に通知した過去の通知情報を保持しており、不正検知サーバ８０に新たな通知情報を通知する前に、過去の通知情報の中に、新たな通知情報に含まれる車載ネットワークに関する情報に係るメッセージの識別子、メッセージの不正検知結果、及び、優先度のうちの所定の一部が一致する場合に、通知情報を不正検知サーバ８０に通知することを禁止するようにしてもよい。ここで、通知情報は、通知情報に含まれる車載ネットワークに関する情報に係るメッセージの識別子を含んでいるとする。

また、フレームアップロード部９５０は、優先度が第一の所定の値以下である場合には、不正検知サーバ８０に通知情報を通知することを禁止する処理、又は、所定の通信間隔を有する第一タイミングで不正検知サーバ８０に通知情報を通知する処理のいずれかの処理を行い、優先度が第二の所定の値以上である場合には、上記第一タイミングとは異なる第二タイミングで不正検知サーバ８０に通知情報を通知するようにしてもよい。

なお、不正検知サーバ８０からの通知に対応して、ゲートウェイ９００は、ＣＡＮバスを介してあらかじめ定められたＥＣＵに必要な情報を送信する等によって、ファームウェアの更新、運転支援機能の無効化、及び、遠隔制御等の機能を実現させる。

転送制御部９６０は、転送ルール保持部９９１が保持する転送ルールに従って、受信したフレームのＩＤ、及び転送元バス（つまりそのフレームを受信したバス）に応じて、転送先のバスを選択し、転送先のバスを示すバス情報と、転送されるべきフレームの内容（例えばフレーム解釈部９２０より通知されたＩＤ、ＤＬＣ、データ等）をフレーム生成部９８０へ通知して、送信を要求する。

フレーム生成部９８０は、転送制御部９６０からの送信の要求に従い、転送制御部９６０より通知されたフレームの内容を用いて送信用のフレームを構成し、その送信用のフレーム及びバス情報（例えば転送先のバスの識別子等）をフレーム送受信部９１０へ通知する。

転送ルール保持部９９１は、バスごとのフレームの転送についてのルールを示す転送ルール情報を保持する。転送ルール情報は、転送元となりうる各バスについて、そのバスで受信された転送すべきフレームのＩＤと転送先のバスとを示す。

また転送ルール情報は、各バスが、フレーム内容を暗号化すると規定されたバスか否か、及び、フレームにＭＡＣが付与されると規定されたバスか否かを示す情報を含む。この情報を参照することで転送制御部９６０は、転送元が暗号化に対応している場合は、鍵保持部９９２が保持している、転送元のバスに接続された各ＥＣＵと共有している暗号鍵を用いて、鍵処理部９７０にフレームの内容を復号させる。

そして、転送先が暗号化に対応している場合は、転送制御部９６０は、鍵保持部９９２が保持している、転送先のバスに接続された各ＥＣＵと共有している暗号鍵を用いて、鍵処理部９７０にフレームの内容を暗号化させて転送するように制御する。

鍵処理部９７０では、フレームの内容の暗号化、復号、及び、フレームの内容等に基づくＭＡＣの生成・検証のそれぞれについて、いかなる方式を用いてもよい。

ＭＡＣは、例えばフレームのデータフィールド内の一部の値に基いて生成してもよいし、その値と、他のフィールドの値あるいは、その他の情報（例えばフレームの受信回数をカウントするカウンタ値等）を結合したものに基づいて生成してもよい。

ＭＡＣの計算方法としては、例えばＨＭＡＣ（Ｈａｓｈ−ｂａｓｅｄ Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）、ＣＭＡＣ（Ｃｉｐｈｅｒ−ｂａｓｅｄ Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）等を用いることができる。

［１．９ ルール保持部］
図９は、ゲートウェイ９００のルール保持部９９０の内容である優先度ルールの一例を示す図である。図９に示すように優先度ルールには、優先度を決定するための条件のテーブルが記載されている。

図９に示される優先度ルールでは、例えばＣＡＮのフレームから取得される車両の速度が０ｋｍ／ｈより大きい場合、すなわち走行中に、優先度を「＋１」（すなわち１加算、以下同様）することが示されている。さらに、速度が８０ｋｍ／ｈより大きい場合（すなわち高速走行中）に、優先度を「＋１」することが示されている。また、診断フレーム又はファームウェアアップデートに関わるフレーム、並びに、運転支援及び自動運転に関わるフレームについても優先度を「＋１」することが示されている。進行又は旋回に関わる加速度が０．４Ｇを超える場合も優先度が「＋１」されることが示されている。優先度決定部９３０が保持する、１秒ごとにリセットされるフレーム受信カウンタが１０００を超える（すなわち高バス負荷）時は、異常発生の度合いが高いとして、優先度が「＋２」されることが示されている。ＭＡＣ検証が失敗した場合は、異常が既に発生しているとして、優先度を「＋３」することが示されている。

優先度決定部９３０は、優先度のデフォルト値を０として、ルール保持部９９０に保持される条件を検証していき、最終的な優先度を算出する。なお、優先度は、予め定められた範囲の上限値（例えば５）を超えないように調整される。

［１．１０ 車両と不正検知サーバ間の処理シーケンス］
図１０は、不正検知サーバ８０と車両との処理シーケンスの一例を示す図である。図１０は、主として、ある車両（車両１０１０ａ）が、車載ネットワークＣＡＮバスで受信されたフレームについての情報（具体的には、フレームの情報を加工処理して得られた特徴ベクトル）と、優先度を示す情報とを含むログ情報を、不正検知サーバ８０に送信し、不正検知サーバ８０がフレームの分析を行う動作例を示す。具体的には、ある車両のゲートウェイ９００が１つのフレームを受信する際の動作例を表している。

この例では車両１０１０ａがログ情報を不正検知サーバ８０に送信する例を示すが、不正検知サーバ８０に対しては、その他の各車両（車両１０１０ｂ、１０１０ｃ、１０１０ｄ、１０１０ｅ及び１０１０ｆ等）が同様のログ情報を送信する。以下、図１０に即して動作例を説明する。

車両１０１０ａの車載ネットワークにおけるバス１０に接続された１つのＥＣＵ（例えば、エンジンのＥＣＵ１００、又は、トランスミッションのＥＣＵ１０１等）がバス１０にＣＡＮのフレームを送信し始める（ステップＳ１０１）。

車両１０１０ａのゲートウェイ９００は、ステップＳ１０１により送信されているフレームをバス１０から受信する（ステップＳ１０２）。

ゲートウェイ９００は、受信したフレームに関して、ルール保持部９９０を参照しながら優先度を決定する（ステップＳ１０３）。

ゲートウェイ９００は、フレームアップロード部９５０により、決定した優先度と、フレームに関する情報（ＩＤ、ＤＬＣ、データフィールド、受信間隔、受信頻度等）とを含むログ情報を、不正検知サーバ８０に送信する（ステップＳ１０４）。

また、ゲートウェイ９００は、転送制御部９６０により、フレーム転送処理（つまり転送ルール情報に基づいてフレームの転送を行う処理）を行う（ステップＳ１０５）。図１０の例では、フレーム転送処理により、ゲートウェイ９００は、バス２０にフレームを転送し、バス２０に接続されたブレーキのＥＣＵ２００或いは、ステアリングのＥＣＵ２０１は、転送されたフレームを受信する（ステップＳ１０６）。

不正検知サーバ８０は、ゲートウェイ９００から、車両１０１０ａの車載ネットワークで受信されたフレームに関する情報を含むログ情報を受信する（ステップＳ１０７）。そして、不正検知サーバ８０は、受信したログ情報を利用して、ログ分析を行う（ステップＳ１０８）。

次に、ログ分析について図１１を用いて詳しく説明する。

［１．１１ 不正検知サーバのログ分析フローチャート］
図１１は、不正検知サーバ８０におけるログ分析の一例を示すフローチャートである。以下、図１１に即して、ログ分析について説明する。

不正検知サーバ８０は、各車両から送信されたログ情報（つまり各車両の車載ネットワークで受信されたフレームについての情報を含むログ情報）を、車両ログ格納ＤＢ８８１に保存する（ステップＳ２０１）。

次に、不正検知サーバ８０は、ログ情報とともに受信した、メタ情報、具体的には優先度を取得する（ステップＳ２０２）。

不正検知サーバ８０は、ステップＳ２０２で取得した優先度に基づいて処理を分岐する（ステップＳ２０３）。

ステップＳ２０２で取得した優先度が０である場合（ステップＳ２０３で「＝０」）、不正検知サーバ８０は、図１１に示された処理を終了する。

ステップＳ２０２で取得した優先度が１である場合（ステップＳ２０３で「＝１」）は、不正検知サーバ８０は、ステップＳ２０１で受信したログの分析を行う（ステップＳ２０５）。ログの分析はログ情報に基づいて、例えば、統計的異常検知処理を行う。

統計的異常検知処理は、各車両から取得したログ情報（つまり車両ログ情報として集積した各ログ情報）を参照して、車載ネットワークで受信されたフレームについての情報に基づいて統計処理、多変量解析等を行うことで、異常状態との比較用に用いることのできる所定モデルの構築あるいは、機械学習による所定モデルの更新を行う処理を含む。

また、統計的異常検知処理は、過去に各車両の車載ネットワークで受信されたフレームに基づくその所定モデルと、ある車両（ここでは１０１０ａとする）から最後に取得したログ情報が含むその車両の車載ネットワークで受信されたフレームについての情報とを用いた演算処理（比較等）により、その車両１０１０ａで受信されたフレームの異常度について算定する処理を含む。この演算処理は、例えば、外れ値検出、時系列上の急激な変化を検出する変化点検出等のための処理を含み得る。

不正検知サーバ８０では上述したログ分析部８４０により、フレームの異常度を算定し、異常度があらかじめ定められた閾値より高いか否かにより、当該フレームが異常であるかを判断する。

なお、不正検知サーバ８０が、異常度について算定するフレームは、車両１０１０ａの車載ネットワークで受信されたフレームに限定されるものではなく、他の車両の車載ネットワークで受信されたフレームでもよい。

ステップＳ２０２で取得した優先度が２〜４である場合（ステップＳ２０３で「＝２〜４」）は、不正検知サーバ８０のログ分析部８４０は、ログ情報の分析に割り当てる計算資源を、その優先度に応じて優先的に割り当てる（ステップＳ２０７）。具体的には、優先度が大きいほど、車載ネットワークに関する情報の分析に割り当てる計算資源をより大きくする。なお、ログ分析部８４０は、上記とともに、又は、上記に代えて、優先度が大きいほど、車載ネットワークに関する情報の分析の順番をより早くしてもよいし、また、車載ネットワークに関する情報の分析の実行をするか否かの判定において、より優先的に実行すると判定してもよい。このようにして、ログ分析部８４０は、優先度が大きいほど、より優先的にログ情報の分析を行えるようにする。

その後、ログ分析部８４０は、ステップＳ２０１で受信したログの分析を行う（ステップＳ２０５）。ステップＳ２０５の処理内容は上記のとおりである。なお、ステップＳ２０７で、車載ネットワークに関する情報の分析の実行をするか否かの判定において、実行しないと判定された場合には、ステップＳ２０５は実行されない。

ステップＳ２０２で取得した優先度が５である場合（ステップＳ２０３で「＝５」）は、不正検知サーバ８０は、即座に、車載ネットワーク監視システムの管理者に不正なイベントとして、受信ログ情報を通知する（ステップＳ２０８）。その後、ステップＳ２０５（ログの分析）を実行する。

次に、結果通知部８５０は、ログの分析（ステップＳ２０５）の結果、異常を検知したかを確認する（ステップＳ２０９）。異常を検知していない場合（ステップＳ２０９でＮｏ）は、図１１に示された一連の処理を終了する。異常を検知した場合（ステップＳ２０９でＹｅｓ）は、分析結果を車載ネットワーク監視システムの管理者に通知する（ステップＳ２１０）。

［１．１２ 実施の形態１の効果］
実施の形態１に係る車載ネットワーク監視システムでは、ゲートウェイ９００は、ルール保持部９９０に保持される優先度ルールに従って、優先度を算出し、車載ネットワークから受信したフレームに関する情報とともに、不正検知サーバ８０に通知する。優先度ルールは、現在の車両の走行状態、受信したフレームの種類、受信したフレームを観測したバスの負荷率、フレームに含まれるＭＡＣの検証結果等を条件に規定される。

このような条件を元に算出された優先度にしたがって、不正検知サーバ８０は分析処理を変更する。

これにより、即時検知が要求される、車両の状況において、例えば、高速走行中、運転支援動作中のログを優先的に分析することが可能になる。また、高バス負荷、ＭＡＣの検証失敗などの異常度の高い状況においては、ログの分析結果を待たずに、車載ネットワーク監視システムの管理者に通知することができ効果的である。

（実施の形態２）
以下、複数の電子制御ユニット（電子制御装置又はＥＣＵ）がＣＡＮバスを介して通信する車載ネットワーク（車載ネットワークシステム）を搭載した複数台の車両と、サーバ（不正検知サーバ）とを含む車載ネットワーク監視システム、並びに、車載ネットワークシステムに関する情報を不正検知サーバに通知する情報通知方法について説明する。本実施の形態で示す車載ネットワーク監視システムの構成は、実施の形態１で示したもの（図１参照）と同様である。

［２．１ 車載ネットワークシステムの全体構成］
図１２は、本実施の形態に関わる車載ネットワークシステムの構成を示す図である。実施の形態１の車載ネットワークシステム（図２参照）と同様の機能を実現するものは、実施の形態１と同様の番号を付与し、説明を省略する。

ゲートウェイ１９００は、異なる複数の通信路を接続して通信路間でデータを転送するＥＣＵである。ゲートウェイ１９００は、バス１０、バス２０、バス３０、バス４０及びバス５０と接続している。

つまり、ゲートウェイ１９００は、ゲートウェイ１９００に接続されている一のバスから受信したフレーム（データフレーム）を、一定条件下で他のバス（つまり条件に応じて選択した転送先バス）に転送する機能を有する一種のＥＣＵである。

ゲートウェイ１９００は、ＩＤＳ（Ｉｎｔｒｕｓｉｏｎ Ｄｅｔｅｃｔｉｏｎ Ｓｙｓｔｅｍ）機能または、ＩＰＳ機能（Ｉｎｔｒｕｓｉｏｎ Ｐｒｅｖｅｎｔｉｏｎ Ｓｙｓｔｅｍ）機能を備え、車載ネットワークシステムにおける不正なメッセージを、検知する機能、又は、検知して排除する機能を持つ。

さらにゲートウェイ１９００は、検知した不正なメッセージに関する情報を、ＣＡＮバスを介して、他の装置に通知する機能をもつ。ゲートウェイ１９００の構成については後に、詳細に説明する。

ＥＣＵ１３０１と、ＥＣＵ１３０２は、車両の外部の不正検知サーバ８０と通信するための通信装置（通信回路等）を備え、例えば、ゲートウェイ１９００から通知される不正なメッセージに関する情報を不正検知サーバ８０に送信（アップロード）する機能を有する。ＥＣＵ１３０１と、ＥＣＵ１３０２の構成は後に、詳細に説明する。

なお、ゲートウェイ１９００、ＥＣＵ１３０１、及び、ＥＣＵ１３０２は、それぞれ、第一電子制御装置、第二電子制御装置、及び、第三電子制御装置に相当する。

［２．２ ゲートウェイ１９００の構成］
図１３は、ゲートウェイ１９００の構成を示す図である。ゲートウェイ１９００は、フレーム送受信部９１０と、フレーム解釈部９２０と、不正フレーム検知部１９３０と、不正通知部１９４０と、更新処理部９４０と、転送制御部９６０と、鍵処理部９７０と、フレーム生成部９８０と、不正検知ルール保持部１９９０と、鍵保持部９９２とを含んで構成される。

なお、実施の形態１と同様の構成要素を示すものは、同じ番号を付与して説明を省略する。

フレーム解釈部９２０は、実施の形態１における場合と同様、フレーム送受信部９１０よりフレームの値を受け取り、解釈を行う。そして、フレーム解釈部９２０は、受信されたフレームの各フィールドの情報を不正フレーム検知部１９３０へ通知する。

不正フレーム検知部１９３０は、フレーム解釈部９２０から通知されたフレームが不正なフレームであるかを、不正検知ルール保持部１９９０を参照することで判断する。不正なフレームの判断基準としては、例えば、メッセージに含まれる特定のフィールドがあらかじめ定められた値以外の不正な値となっている場合、又は、予め定められた受信間隔から逸脱している場合などである。不正フレーム検知部１９３０は、フレーム解釈部９２０から通知されたフレームが上記場合に該当することを検知したら、不正なフレームと判断する。

不正フレーム検知部１９３０は、不正なフレームを検知すると、不正通知部１９４０に不正なフレームを検知したことを通知する。また、不正フレーム検知部１９３０は、不正なフレームを判断するために、車両のイグニッション時からの経過時間を示すタイマと、過去に受信したフレームに関する情報を保持するメモリとを保有している。不正フレーム検知部１９３０は、不正検知部に相当する。

不正通知部１９４０は、不正フレーム検知部１９３０から、不正なフレームを検知したことを通知されると、不正なフレームを検知したことをゲートウェイ１９００外部に通知するために、転送制御部９６０に不正通知フレームの送信要求を行う。転送制御部９６０は、この送信要求を受けると、フレーム送受信部９１０を通じて不正通知フレームを送信する。

不正通知フレームの通知先を表す情報、又は、送信先のバスは、検知した不正により変わりうる。例えば、不正通知フレームは、通常、ＥＣＵ１３０１を介して、不正検知サーバ８０に通知される。そして、ＥＣＵ１３０１が送信するフレームに関して、不正なフレームを検知した場合には、ＥＣＵ１３０２を介して不正通知フレームが不正検知サーバ８０に通知される。

このように、車両に不正な機器が接続されている場合に、不正な機器を介さずに、不正検知サーバ８０へ情報を通知することができるようになり、安全性の観点から望ましい。

これを実現するためには不正通知フレーム内に、通知先の宛先情報（ＥＣＵ１３０１あるいはＥＣＵ１３０２を示す情報）を含めておき、不正通知フレームのＩＤを通知先に応じて変更する、といった手段がとられ得る。不正通知フレームについては、図１４を用いて後に、詳細に説明する。

不正検知ルール保持部１９９０は、不正フレーム検知部１９３０が参照する、不正なフレームと判断するための判断条件を保持している。不正検知ルール保持部１９９０に格納されるデータについては、図１５を用いて後に詳細に説明する。

［２．３ 不正通知フレーム］
図１４は、ゲートウェイ１９００が不正なフレームを検知したときに、他のＥＣＵに不正なフレームの検知を通知する不正通知フレームの一例を示す図である。図では、検知した不正なフレームを３つのＣＡＮフレームにわたり通知する例を示している。

なお、図１４におけるフレームフィールドは、１６進数で表現されており、１つの数値が４ビットに対応している。

不正通知フレーム１は、ＣＡＮ ＩＤが０ｘ６００である不正通知フレームであり、ゲートウェイ１９００がバス３０に送信したものである。データの上位４ビットの「０」は、不正通知フレームの順序を示すカウンタであり、不正通知フレーム１が１つ目のフレームであることから「０」が設定されている。

次の４ビットの「３」は、当該通知に用いる不正通知フレームの総数を表す。この例では、３つの不正通知フレームを当該通知に用いるので「３」と設定されている。

次の８ビットの「０１」は、不正検知コードを表す。不正検知コードは、不正検知の種類を示す。例えば、不正検知ルール保持部１９９０に格納されている不正検知ルールのうちのどのルールに該当することで不正と検知されたのかを示す。この例では、フレームの受信間隔が不正であったことを「０１」で表している。

次の３２ビットは、不正を検知したフレーム（つまり不正フレーム）のＩＤを表す。この例では、ＩＤが「１００」のフレームにおいて不正が検知されたことが示されている。

最後の１６ビットは、不正検知に関する付加情報用のフィールドである。この例では「００ ００」となっており、特に情報が含まれていないことを示している。このフィールドでは、例えば、フレームの受信間隔が不正と判断されたときに、実際にフレームの受信間隔がいくつであったかの情報などを含めてもよい。

不正通知フレーム２は、同じくＣＡＮ ＩＤが０ｘ６００である不正通知フレームであり、ゲートウェイ１９００がバス３０に送信したものである。データの上位４ビット「１」は、不正通知フレームの順序を示すカウンタであり、不正通知フレーム２が２つ目のフレームであることから「１」が設定されている。

次の４ビットは予約ビットであり特に意味を持たず「０」が設定されている。

次の２４ビットは、タイムスタンプであり、車両のイグニッションがＯＮになってからの秒数が含まれている。この例では「２１」であり、３３秒が経過したことが示されている。

次の３２ビットは、不正通知フレームの正当性を検証するためのＭＡＣが含まれている。ＭＡＣの生成は、不正フレームのＩＤ、タイムスタンプ、不正フレームのデータフィールドを含めて算出され、上位３２ビットが使用される。この例で、算出されたＭＡＣは「Ｅ６ Ａ１ ２３ ５Ｃ」であることが示されている。

不正通知フレーム３は、同じくＣＡＮ ＩＤが０ｘ６００である不正通知フレームであり、ゲートウェイ１９００がバス３０に送信したものである。不正通知フレーム３には、不正と検知されたフレームのデータフィールドが含まれており、この例では、不正と判定されたＩＤが０ｘ１００のデータフレームのデータフィールドは「ＦＦ ＦＦ ＦＦ ＦＦ ＦＦ ＦＦ ＦＦ ＦＦ」であったことが示されている。

なお、不正通知フレーム３には、不正通知フレームの順序を示すカウンタは含まれていない。

なお、上記では不正通知フレームの個数が３である例を示したが、不正通知フレームの個数は３に限らず、１以上であればいくつでもよい。

［２．４ 不正検知ルール］
図１５は、ゲートウェイ１９００の不正検知ルール保持部１９９０の内容である不正検知ルールの一例を示す図である。図１５では、４つの不正検知ルールが保持されている例を示している。

ルール番号１の不正検知ルールは「周期」に関するルールであり、フレームの正常な受信間隔を規定したルールである。対象バスは「バス１０」であり、対象フレームのＣＡＮ ＩＤは「１００」である。ルールである正常な受信間隔は「９〜１１ｍｓ」であることを示している。つまりゲートウェイ１９００は、バス１０から受信したＣＡＮ ＩＤが１００であるデータフレームの受信間隔が９〜１１ｍｓの範囲に収まっていない場合に、不正なフレームを受信したとして、不正通知フレームの送信を行う。

同様に、ルール番号２の不正検知ルールは「周期」に関するルールである。対象バスは「バス２０」であり、対象ＣＡＮ ＩＤは「２００」、正常な受信間隔は「１８〜２２ｍｓ」であることを示している。

ルール番号３の不正検知ルールは「周期」に関するルールである。対象バスは「バス３０」であり、対象ＣＡＮ ＩＤは「３００」、正常な受信間隔は「３６〜４４ｍｓ」であることを示している。

ルール番号４の不正検知ルールは「データ」に関するルールである。対象バスは「バス１０」であり、対象ＣＡＮ ＩＤは「１００」である。正常なデータを表すルールは「０バイト目が０ｘ００」であることを示している。つまりゲートウェイ１９００はバス１０から受信したＣＡＮ ＩＤが１００であるデータフレームのデータフィールドの０バイト目が０ｘ００以外である場合に、不正なフレームを受信したとして、不正通知フレームの送信を行う。

［２．５ ＥＣＵ１３０１の構成図］
図１６は、ＥＣＵ１３０１の構成を示す図である。なお、ＥＣＵ１３０２も同様の構成である。ＥＣＵ１３０１は、フレーム送受信部９１０と、フレーム解釈部１３２０と、優先度決定部１３３０と、サーバ通信部１３４０と、接続機器通信部１３５０と、フレーム生成部９８０と、優先度ルール保持部１３６０と、フレーム履歴保持部１３７０とを含んで構成される。なお、ＥＣＵ１３０１のフレーム送受信部９１０を第四通信部ともいう。

フレーム解釈部１３２０は、フレーム送受信部９１０よりフレームの値を受け取り、ＣＡＮプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。

また、フレーム解釈部１３２０には、鍵処理部９７０と鍵保持部９９２が含まれており、受信したフレームにＭＡＣが含まれる場合に、フレームの正当性を検証し、検証に失敗したフレームを破棄する。

フレーム解釈部１３２０は、受信したフレームを接続機器通信部１３５０へ通知する。

また、フレーム解釈部１３２０は、ゲートウェイ１９００から受信した不正通知フレームと不正検知サーバ８０に通知する予め定められたフレームとを優先度決定部１３３０へ通知する。予め定められたフレームとは、例えば、車両の走行に関わる信号を含むフレーム（例えば、車両の速度、操舵角度、加速度、ブレーキ油圧等）が含まれる。フレーム解釈部１３２０は、第二不正検知結果受信部及び第二車両ログ抽出部に相当する。

なお、フレーム解釈部１３２０は、受け取ったフレームがＣＡＮプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部９８０へ通知する。

また、フレーム解釈部１３２０は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降は、そのフレームを破棄する、つまりエラーフレームの解釈を中止する。

優先度決定部１３３０は、優先度ルール保持部１３６０が保持する、優先度ルールを参照し、不正検知サーバ８０へ通知するメッセージに含める優先度を決定する。あらかじめ定められたフレームの優先度は０であり、不正通知フレームに含まれている不正なフレームについては１以上の優先度が設定される。優先度ルール保持部１３６０が保持するルールについては図１７を用いて後に説明する。なお、優先度決定部１３３０は、第二優先度決定部に相当する。

優先度決定部１３３０は、優先度を決定すると、サーバ通信部１３４０に、通知するフレームと、決定した優先度とを通知する。優先度ルール保持部１３６０が保持するルールについては図１７を用いて後に説明する。

サーバ通信部１３４０は、優先度決定部１３３０から通知されたフレームと優先度とを不正検知サーバ８０に通知する機能を持つ。サーバ通信部１３４０は、優先度決定部１３３０から通知された情報（フレーム及び優先度）をフレーム履歴保持部１３７０へ格納する。サーバ通信部１３４０は、第五通信部に相当する。

サーバ通信部１３４０では、定期通信用のフレームに含まれる信号（車両の速度、操舵角度、加速度、ブレーキ油圧等）は、優先度０で受信され、内部に保持されるメモリに常に最新値が保持されている。定期通信用フレームの情報は定期的（例えば１秒ごと）に不正検知サーバ８０へ通知される。

一方で優先度が１以上であるフレームの情報（不正検知されたフレームに関する情報）は、優先度決定部１３３０から通知されたタイミングで、不正検知サーバ８０へ通知する。このとき、フレーム履歴保持部１３７０を参照し、不正検知サーバ８０へ前回に通知した情報が、今回送信する情報と同一のＩＤであり、かつ、同一の不正コードをもつ場合には、不正検知サーバ８０への通知を行わず、言い換えれば、通知を禁止する。

これにより、車載ネットワークで継続的に不正なフレームが送信されている場合において、比較的高い優先度のフレームを不正検知サーバ８０に頻繁に通知することがなくなり、通信量削減および、不正検知サーバ８０の処理負荷低減につながり効果的である。

また、サーバ通信部１３４０は、不正検知サーバ８０からの制御コマンドを受信し、接続機器通信部１３５０へ通知あるいは、フレーム生成部９８０へ通知する。フレーム履歴保持部１３７０が保持するフレーム履歴については、図１８を用いて後に詳細に説明する。

接続機器通信部１３５０は、ＥＣＵ１３０１が接続する機器（カーナビ３１１）の制御を行う。例えば、サーバ通信部１３４０から、セキュリティアラートの表示を通知された場合には、カーナビ３１１の画面に、セキュリティアラートの表示を行うように制御する。

ＥＣＵ１３０２は、ＥＣＵ１３０１と同じ構成を有する。ただし、ＥＣＵ１３０２の優先度決定部１３３０を第三優先度決定部という。また、ＥＣＵ１３０２のフレーム解釈部１３２０のうち第二不正検知結果受信部に相当する機能を、第三不正検知結果受信部という。また、ＥＣＵ１３０２のフレーム解釈部１３２０のうち第二車両ログ抽出部に相当する機能を、第三車両ログ抽出部という。また、ＥＣＵ１３０２のフレーム送受信部９１０を、第六通信部という。ＥＣＵ１３０２のサーバ通信部１３４０を、第七通信部という。

［２．６ 優先度ルール保持部］
図１７は、ＥＣＵ１３０１の優先度ルール保持部１３６０の内容の優先度ルールの一例を示す図である。優先度ルールには、優先度を決定するための条件と、優先度とが規定されている。

図１７に示される１番目の優先度ルールでは、定期通信用フレーム（車両の速度、操舵角度、加速度、ブレーキ油圧等）が通知された場合に優先度を０とする。

図１７に示される２番目の優先度ルールでは、不正通知フレームが受信され、かつ、不正フレームが車両の制御に関わらないフレームであった場合に優先度を１とする。車両の制御に関わらないフレームとは、車両の走る、曲がる、止まる、に関わる制御に、直接的あるいは間接的に影響しない信号のみを含むフレームを表す。例えば、ドア若しくはウィンドウの開閉状態、又は、ライトの点灯状態といった、状態通知に関わるフレームが該当する。

図１７に示される３番目の優先度ルールでは、不正通知フレームが受信され、かつ、不正フレームが車両の制御に関わるフレームであり、かつ、車両が停車中である場合に、優先度を２とする。車両の制御に関わるフレームとは、ステアリングの操舵指示若しくは減速要求といった直接的に車両の制御に関わる信号、又は、車両の速度、白線検知状態若しくは前方車両との距離等の運転支援機能の制御判断に必要となるセンサ情報の間接的に車両の制御に関わる信号が含まれるフレームを表す。

図１７に示される４番目の優先度ルールでは、不正通知フレームが受信され、かつ、不正フレームが車両制御に関わるフレームであり、かつ、車両が走行中である場合に、危険度が高いとし、優先度を３とする。

なお、本実施の形態においては、不正フレームが車両の制御に関わる又は関わらない、および、現在の車両状態によって、優先度が決定されるとしたが、優先度の決定の方法は、これに限らない。例えば、診断コマンド、ファームウェアアップデートに関わるコマンド、あるいは、あらかじめ決められたＩＤのリストと、不正検知コードとの組み合わせによって、優先度が決定されてもよい。

［２．７ フレーム履歴保持部］
図１８は、ＥＣＵ１３０１のフレーム履歴保持部１３７０の内容のフレーム履歴の一例を示す図である。フレーム履歴には、フレームの時刻、フレームの種類、不正の種類、優先度、及び、サーバへの通知の有無が含まれうる。

図１８の例では、上から新しい順にフレームが保持されている。

図１８に示される１番目のフレーム履歴では、時刻３４１．０００（秒）において、定期通信のフレームが不正検知サーバ８０へ通知されたことが示されている（「サーバへの通知」＝１）。また、このフレームは、不正が検知されず（不正の種類が「無」）、優先度がゼロであることが示されている。

図１８に示される２番目のフレーム履歴では、時刻３４０．３３０（秒）において、シフトポジションの信号を含むフレームに関する不正が不正検知サーバ８０へ通知されなかったことが示されている（「サーバへの通知」＝０）。また、このフレームは、周期ルールの不正であり（不正の種類が「周期」）、優先度が２であることが示されている。

図１８に示される３番目のフレーム履歴では、時刻３４０．２３０（秒）において、シフトポジションの信号を含むフレームに関する不正が不正検知サーバ８０へ通知されたことが示されている（「サーバへの通知」＝１）。また、このフレームは、周期ルールの不正であり（不正の種類が「周期」）、優先度が２であることが示されている。

上記３番目のフレームが送信され、上記２番目のフレームが送信されなかったのは、サーバ通信部１３４０が、最初に通知されたシフトポジションを含むフレームを不正検知サーバ８０へ通知した後に、同様の不正通知フレームが通知されたため、不正検知サーバ８０への通知を省略又は禁止したことを示している。

図１８に示される４番目のフレーム履歴では、時刻３４０．０００（秒）において、定期通信のフレームが不正検知サーバ８０へ通知されたことが示されている（「サーバへの通知」＝１）。また、このフレームは、不正が検知されず（不正の種類が「無」）、優先度がゼロであることが示されている。

［２．８ ゲートウェイ１９００の処理フローチャート］
図１９は、ゲートウェイ１９００のフレーム受信時の処理フローチャートである。以下、図１９に即して、フレーム受信時の処理フローチャートについて説明する。

ゲートウェイ１９００は、フレームを受信する（ステップＳ１１０１）。

ゲートウェイ１９００は、受信したフレームの不正検知処理を行う（ステップＳ１１０２）。

ゲートウェイ１９００は、不正検知処理の結果、不正フレームが検知されたか否かを判断する（ステップＳ１１０３）。

ステップＳ１１０３で不正なフレームが検知された場合（ステップＳ１１０３でＹｅｓ）は、その不正フレームが、ＥＣＵ１３０１に関する不正フレームであるか否かを判定する（ステップＳ１１０４）。具体的には、不正フレームに含まれるＣＡＮ ＩＤを参照して、ＥＣＵ１３０１が送信したフレームであるか否かを判定する。

ステップＳ１１０４において、ステップＳ１１０３で検知された不正フレームに含まれるＩＤが、ＥＣＵ１３０１に関連するフレームである場合（ステップＳ１１０４でＹｅｓ）は、ゲートウェイ１９００は、ＥＣＵ１３０２に対して、不正なフレームを検知したことを通知する不正通知フレームを送信する（ステップＳ１１０６）。具体的には、不正フレームを検知したときにＥＣＵ１３０１に対して送信する不正通知フレームのＩＤとは異なるＩＤで、不正通知フレームを送信する。その後処理を終了する。

ステップＳ１１０４において、ステップＳ１１０３で検知された不正フレームに含まれるＩＤが、ＥＣＵ１３０１に関連するフレームでない場合（ステップＳ１１０４でＮｏ）は、ゲートウェイ１９００は、ＥＣＵ１３０１に対して不正フレームを検知したことを通知する不正通知フレームの送信を行う（ステップＳ１１０７）。その後処理を終了する。

ステップＳ１１０３で不正フレームが検知されなかった場合（ステップＳ１１０３でＮｏ）は、転送ルール保持部９９１に保持されている転送ルールに従って、受信したフレームの転送を行う（ステップＳ１１０５）。その後処理を終了する。

［２．９ ＥＣＵ１３０１の処理フローチャート］
図２０は、ＥＣＵ１３０１の処理フローチャートを示す図である。以下、図２０に即してＥＣＵ１３０１の処理フローチャートを説明する。

なお、図２０に示される一連の処理は、ＥＣＵ１３０１の内部のタイマがリセットされた状態から開始する。

ＥＣＵ１３０１は、所定の時間（例えば１秒）が経過したかを内部のタイマを用いて判断する（ステップＳ１２０１）。

ＥＣＵ１３０１は、所定の時間が経過していた場合（ステップＳ１２０１でＹｅｓ）、定期通信用フレームの情報と、優先度（０）とを含めて不正検知サーバ８０に通知する（ステップＳ１２０２）。定期通信用フレームは、最新の車両の走行状態に関わる情報（車両の速度、操舵角度、加速度、ブレーキ油圧等）を含み、これらの情報は、バス３０から受信されるフレームから取得される。

その後、ＥＣＵ１３０１は、フレーム履歴保持部１３７０が保持するフレーム履歴を更新する（ステップＳ１２０３）。

そして、ＥＣＵ１３０１は、タイマをリセットし（ステップＳ１２０４）、ステップＳ１２０１に戻る。

ＥＣＵ１３０１は、ステップＳ１２０１で所定の時間が経過していなかった場合（ステップＳ１２０１でＮｏ）に、フレームを受信していたか否かを判定する（ステップＳ１２０５）。フレームを受信していないと判定した場合（ステップＳ１２０５でＮｏ）は、ステップＳ１２０１に戻る。フレームを受信していたと判定した場合（ステップＳ１２０５でＹｅｓ）は、そのフレームが不正通知フレームであるかを判断する（ステップＳ１２０６）。

ＥＣＵ１３０１は、受信したフレームが不正通知フレームであった場合（ステップＳ１２０６でＹｅｓ）は、優先度ルール保持部１３６０を参照し、不正通知フレームの優先度を決定する（ステップＳ１２０７）。

その後、ＥＣＵ１３０１は、フレーム履歴保持部１３７０を参照し、受信した不正通知フレームが、前回に受信した不正通知フレームと同種のものであるか否かを判定する（ステップＳ１２０８）。具体的には、今回に受信した不正検知フレームと、前回に受信した不正検知フレームとで、ＣＡＮ ＩＤ及び不正の種類が一致した場合に、同種の不正通知フレームであったと判定する。前回に受信した不正通知フレームと同種のものであった場合（ステップＳ１２０８でＮｏ）は、不正通知フレームを不正検知サーバ８０に送信せずに、フレーム履歴保持部１３７０のフレーム受信履歴を更新して（ステップＳ１２１０）、ステップＳ１２０１に戻る。前回に受信した不正通知フレームと同種のものでない、つまり異なる場合（ステップＳ１２０８でＹｅｓ）は、不正通知フレームに関連する情報と優先度とを含めて、不正検知サーバ８０へ通知する（ステップＳ１２０９）。

その後、ＥＣＵ１３０１は、フレーム履歴保持部１３７０のフレーム受信履歴を更新して（ステップＳ１２１０）、ステップＳ１２０１に戻る。

ステップＳ１２０６で受信したフレームが不正通知フレームでないと判定した場合（ステップＳ１２０６でＮｏ）、ＥＣＵ１３０１は、受信したフレームが定期通信用フレームに関連するフレームであるか否かを判定する（ステップＳ１２１１）。具体的には、定期通信用フレームに含まれる情報（車両の速度、操舵角度、加速度、ブレーキ油圧等）のいずれかの情報を含んだフレームであるか否かを判定する。

受信したフレームが定期通信用フレームに関連するフレームであると判定した場合（ステップＳ１２１１でＹｅｓ）は、ＥＣＵ１３０１は、内部のメモリに保持する、定期通信用フレームに含まれる情報を更新し（ステップＳ１２１２）、ステップＳ１２０１に戻る。

ステップＳ１２１１で定期通信用フレームに関連するフレームでないと判定した場合（ステップＳ１２１１でＮｏ）、ＥＣＵ１３０１は、受信したフレームに従った処理を行う。具体的には、接続されている機器の制御等を実行し（ステップＳ１２１３）、ステップＳ１２０１に戻る。

［２．１０ 車両とサーバ間の正常時の処理シーケンス］
図２１は、車両内部で不正なフレームが検知されていない正常時の不正検知サーバ８０と車両との処理シーケンスの一例を示す図である。図２１は、主として、ある車両（車両１０１０ａ）が、車載ネットワークのＣＡＮバスで受信されたフレームについての情報（フレームの情報を加工処理して得られた特徴ベクトル）と、優先度を示す情報とを含むログ情報を不正検知サーバ８０に送信し、不正検知サーバ８０がフレームの分析を行う動作例を示す。

具体的には、ある車両のゲートウェイ１９００が１つのフレームを受信する際の動作例およびＥＣＵ１３０１の動作例を表している。この例では車両１０１０ａがログ情報を不正検知サーバ８０に送信する例を示すが、不正検知サーバ８０に対しては、その他の各車両（車両１０１０ｂ、１０１０ｃ、１０１０ｄ、１０１０ｅ及び１０１０ｆ等）が同様のログ情報を送信する。以下、図２１に即して動作例を説明する。

バス１０に接続されたＥＣＵがフレームを送信し、ゲートウェイ１９００がそのフレームをバス３０に転送し、ＥＣＵ１３０１がそのフレームを受信する。この一連のシーケンスをＳ２００１とする。Ｓ２００１は繰り返し実行される。

ＥＣＵ１３０１は、内部のタイマに従って、定期通信用フレームと、優先度（０）とを不正検知サーバ８０に送信する（Ｓ２００２）。

不正検知サーバ８０は、定期通信用フレームを車両ログとして受信する（Ｓ２００３）。優先度が０であるので、不正検知サーバ８０は、受信した車両ログを保存するのみである。

［２．１１ 車両とサーバ間の不正検知時の処理シーケンス１］
図２２は、車両内部で不正なフレームが検知された場合の、不正検知サーバ８０と車両との処理シーケンスの第一例を示す図である。以下、図２２に即して、動作例を説明する。

図２１と同様に、ＥＣＵ１３０１が定期通信用フレームを不正検知サーバ８０へ通知している。その後、あるフレームがゲートウェイ１９００により不正フレームと判断され、言い換えれば、あるフレームが不正であることがゲートウェイ１９００により検知される（Ｓ２１０１）。

ゲートウェイ１９００は、不正フレームを検知すると、フレームが不正であることを通知する不正通知フレームの送信を行う（Ｓ２１０２）。

ＥＣＵ１３０１は、不正通知フレームを受信する（Ｓ２１０３）。

ＥＣＵ１３０１は、不正通知フレームに基づいて、優先度を決定する（Ｓ２１０４）。

ＥＣＵ１３０１は、Ｓ２１０４で決定した優先度と、不正通知フレームとを、不正検知サーバ８０へ通知する（Ｓ２１０５）。

不正検知サーバ８０は、受信した車両ログを、受信した優先度に従って分析する。

［２．１２ 車両とサーバ間の不正検知時の処理シーケンス２］
図２３は、車両内部で不正なフレームが検知された場合の、不正検知サーバ８０と車両の処理シーケンスの第二例を示す図である。以下、図２３に即して、動作例を説明する。

ＥＣＵ１３０１が、不正通知フレームを受信し、優先度を決定し、不正検知サーバ８０へ通知する処理は、図２２と共通である。

なお、ＥＣＵ１３０１は、図２０に示すように、定期通信用フレームを不正検知サーバ８０へ通知しているが、図２０では記載を省略している。

ＥＣＵ１３０１は、２回目の不正通知フレームを受信したときは、フレーム履歴保持部１３７０を参照し、前回に受信した不正通知フレームと同種の不正であったため、不正検知サーバ８０への通知を行わない（Ｓ２２０１）。その後、また別の不正通知フレームを受信したため、優先度と、不正通知フレームに関する情報とを含めて、不正検知サーバ８０へ送信する（Ｓ２２０２）例を示している。

［２．１３ 車両とサーバ間の不正検知時の処理シーケンス３］
図２４は、車両内部で不正なフレームが検知された場合の不正検知サーバ８０と車両との処理シーケンスの第三例を示す図である。以下、図２４に即して、動作例を説明する。

ＥＣＵ１３０１が定期通信用フレームを不正検知サーバ８０へ通知する点は、図２０と共通である。

ＥＣＵ１３０１は、バス３０へフレームを送信する（Ｓ２３０１）。

ゲートウェイ１９００は、このフレームを不正なフレームとして判断する（Ｓ２３０２）。

ゲートウェイ１９００は、不正通知フレームを送信するが、ＥＣＵ１３０１が、不正な動作をしている可能性があるため、通知先をＥＣＵ１３０１から、ＥＣＵ１３０２に切り替える（Ｓ２３０３）。具体的には、不正通知フレームのＩＤを、ＥＣＵ１３０１に通知する場合とは異なるものに変更する。

ＥＣＵ１３０２は、不正通知フレームを受信し、優先度を決定し、不正通知フレームに関する情報と、優先度とを、不正検知サーバ８０に送信する。不正検知サーバ８０は、受信した車両ログを、優先度に従って分析する。

［実施の形態２の効果］
実施の形態２に係る車載ネットワーク監視システムでは、車両内部に、不正検知処理を行うゲートウェイ１９００を保持しており、車載ネットワークを常に監視することが可能となる。これにより、不正検知時のみに、検知した不正なフレームを、不定期的に不正検知サーバ８０へ通知することができ、車両ログの通信量を削減および、不正検知サーバ８０の処理負荷の低減につながる。

また、ＥＣＵ１３０２は、車載ネットワークにおいて観測された同種の不正なフレームを、不正検知サーバ８０に通知しないことにより、通信量の削減および、不正検知サーバ８０の処理負荷低減につながり効果的である。

またゲートウェイ１９００は、検知した不正なフレームのＩＤに基づいて、不正検知サーバ８０へ不正なフレームを通知するための経路を変更する。これにより、車両ログ通知経路の途中に不正な動作を行っている疑いのある装置を迂回して、不正検知サーバ８０に、車両ログを通知することが可能となり、車載ネットワーク監視システムの安全性の向上が期待できる。

（その他変形例）
なお、本発明を上記各実施の形態に基づいて説明してきたが、本発明は、上記各実施の形態に限定されないのはもちろんである。以下のような場合も本発明に含まれる。

（１）上記の実施の形態では、車載ネットワークをＣＡＮとして説明したが、これに限定されることなく、ＣＡＮ−ＦＤ（ＣＡＮ ｗｉｔｈ Ｆｌｅｘｉｂｌｅ Ｄａｔａ ｒａｔｅ）、Ｅｔｈｅｒｎｅｔ、ＬＩＮ（Ｌｏｃａｌ Ｉｎｔｅｒｃｏｎｎｅｃｔ Ｎｅｔｗｏｒｋ）、Ｆｌｅｘｒａｙであってもよいし、それぞれを組み合わせた構成であってもよい。

（２）上記の実施の形態では、機械学習による異常検知処理を、クラウドサーバ側で行っているが、車両内部の装置で処理してもよい。例えば、ヘッドユニット上のＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）で行うようにしてもよい。このようにすることで、即時検出性を上げる事が可能となる。この場合、クラウドでは、車両ローカルで異常検知した結果を集約するようにしてもよい。この時、処理の優先度はヘッドユニット内部で算出してもよいし、他の装置、例えばゲートウェイなどにより、ＣＡＮメッセージに含めて通知されてもよい。

（３）上記の実施の形態では、特徴ベクトルを作成する際の前処理をローカル側で行っているが、クラウドサーバ側で行うようにしてもよい。

（４）上記の実施の形態では、クラウドサーバ側で異常検知処理をしているが、よりローカル環境に近いエッジサーバで異常検知処理をするようにしてもよい。このようにすることで、クラウド側で異常検知処理するよりも、ネットワーク遅延処理の影響が少なくなる。例えばエッジサーバが路側機であって、路側機がクラウドサーバと接続されており、車両は路側機に車載メッセージ情報をアップロードし、路側機で異常検知処理し、異常検知した結果をクラウドサーバにアップロードするようにしてもよい。

（５）上記の実施の形態では、車両やクラウドサーバ側で異常検知時にアラートを通知する先として車載ネットワーク監視システム管理者としていたが、それに限定されない。例えば、カーメーカ又はＥＣＵサプライヤ、ユーザが所有する情報端末に通知するようにしてもよい。また、複数のカーメーカ間で共通で利用可能なセキュリティプロバイダーに通知するようにしてもよい。

（６）上記の実施の形態では、不正検知サーバは、優先度が高いときに、車両ログの分析に用いるサーバの計算資源を多く割り当てるとしたが、計算資源を多く割り当てるだけでなく、優先度の高いものから順番に処理していくとしてもよい（図２５）。不正検知サーバがシングルスレッドで処理されている場合に、優先度の高いものから順番に分析することが可能となり、即時の不正検知および対処につながり効果的である。

（７）上記の実施の形態では、優先度が最高の時には、車載ネットワーク監視システムの管理者へ即時通知を行った後に、車両ログの分析を行っていたが、車両ログの分析は行わなくてもよい（図２６）。これにより、明らかな不正なイベントは、即時に管理者に通知するとともに、分析の処理を省くことができ、サーバの処理負荷軽減につながり効果的である。

（８）上記の実施の形態２では、優先度決定部が、不正検知サーバと通信を行うＥＣＵに存在したが、ゲートウェイにあってもよい。また図２６に示すような車載ネットワークアーキテクチャにおいて、複数のドメインコントローラ内に、優先度決定部があってもよい。この時ゲートウェイは、各ドメインコントローラから通知される、優先度およびログをもとに、高優先度のログから順番に、不正検知サーバに通知してもよいし、優先度を再計算してもよいし、同一の優先度のログを、一括で不正検知サーバに通知してもよい。

（９）上記の実施の形態２では、不正検知処理部と、サーバ通信部が異なる装置に分かれて存在していたが、同一の装置内に両要素が存在してもよい。例えば、ゲートウェイにサーバ通信部が存在してもよいし、ＥＣＵ内に不正検知処理部が存在してもよい。

（１０）上記の実施の形態２では、不正通知フレームの通知先を切り替える時に、同一のバスに、ＣＡＮ ＩＤを変更した不正通知フレームを送信することで、通知先を変更していたが、通知先を変更する方法はこれに限らない。例えば同一のＣＡＮ ＩＤで、データフィールドの中に通知先を指定することでも実現可能である。また同一のバスではなく、異なるバスに不正通知フレームを送信してもよい。これにより、異常度の高いバスを迂回して、不正通知フレームを送信することが可能となり安全性の向上につながるため、効果的である。

（１１）上記の実施の形態では、不正検知サーバへ通知するログとともに常に優先度が含まれていたが、常に優先度が含まれていなくてもよい。例えば、実施の形態２における、定期通信用フレームには、優先度を含めなくてもよい。

（１２）上記の実施の形態では、優先度は、０〜５の値をとり得るが、優先度はこれに限らない。例えば、０〜１００のスコアとして優先度を表してもよい。これにより、不正検知サーバの優先度の割り当てがより、詳細に行えるようになり効果的である。この時、所定の第１の閾値未満の優先度の場合は、ログの保存のみ、第１の閾値以上、第２の閾値未満の場合は、優先度の高い順に車両のログ分析、第２の閾値以上の場合は、車載ネットワーク監視システムの管理者へ通知するとしてサーバの処理を実現してもよい。

（１３）上記の実施の形態では、現在の車両の状態に従って算出される優先度と、不正なフレームに対して算出される優先度が、実施の形態１および、実施の形態２で分けて記載したが、両者を同時に扱ってもよい。この時、車両状態に基づく優先度と、フレームに対する優先度を分けて、不正検知サーバに通知してもよいし、両者を併せた新たな優先度ルールに基づき、１つの優先度を算出してもよい。これにより、より多面的に優先度を算出することが可能となり、リスクの高い不正なイベントを不正検知サーバが優先的に処理でき効果的である。

（１４）上記の実施の形態２では、同種の不正通知フレームを受信した場合は、不正検知サーバに通知しないとしたが、不正検知サーバに通知しない条件はこれに限らない。例えば単位時間当たりに通知可能な通信量の閾値を定めておき、通信量の閾値を超えている場合は、不正検知サーバに通知しないとしてもよい。

（１５）上記の実施の形態では、どの優先度の車両ログも、不正検知サーバに通知していたが、優先度によっては、不正検知サーバへの通知を省略してもよい。例えば、優先度が所定の閾値以下の場合は、車両ログを不正検知サーバへ通知しないようにしてもよい。さらに、所定の閾値を不正検知サーバから指定できるような構成にしてよい。これにより、不正検知サーバの処理負荷状況に応じて、車両からアップロードされる車両ログを制限することが可能となり、通信量の削減および、不正検知サーバの処理負荷軽減に効果的である。

（１６）上記の実施の形態では、優先度の高いフレームを、不正検知サーバに即座に通知する例を示したが、車両ログを即座に通知しなくてもよい。例えば、同種の優先度の高いフレームが、所定の期間内に、所定数以上検知された場合にのみ、不正検知サーバに、フレームに関する情報を通知してもよい。また優先度が所定の期間、蓄積されるようにしてもよく、所定の閾値を超えた場合に、不正検知サーバに通知してもよい。これにより、通信量の削減および、不正検知サーバの処理負荷軽減に効果的である。

（１７）上記の実施の形態２では、不正と判断したフレームを、不定期的に不正検知サーバに通知したが、さらに不正と判断したフレームと同一のＣＡＮ ＩＤをもつフレームを、所定の期間保持するようにしてもよい。これにより、後からサーバの要求により、不正と判断したフレームと同一のＣＡＮ ＩＤを持つフレームの受信履歴を参照することが可能になり、フレームの分析に効果的な情報を得られる。

（１８）上記の実施の形態では、不正検知サーバに通知する車両ログは、ＣＡＮのフレームにかかわる情報であったが、不正検知サーバに通知する車両ログはこれに限らない。例えばＥｔｈｅｒｎｅｔのフレーム、ＣＡＮ−ＦＤフレーム、ＦｌｅｘＲａｙフレームであってもよいし、車載ネットワークフレームでなくてもよい。例えば、車両の現在位置を表すＧＰＳ情報、オーディオヘッドユニットへのアクセスログ、動作プロセスに関するログ、ファームウェアのバージョン情報等といった情報であってもよい。

（１９）上記の実施の形態における各装置は、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ、ハードディスクユニット、ディスプレイユニット、キーボード、マウスなどから構成されるコンピュータシステムである。ＲＡＭまたはハードディスクユニットには、コンピュータプログラムが記録されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、各装置は、その機能を達成する。ここでコンピュータプログラムは、所定の機能を達成するために、コンピュータに対する指令を示す命令コードが複数個組み合わされて構成されたものである。

（２０）上記の実施の形態における各装置は、構成する構成要素の一部または全部は、１個のシステムＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ：大規模集積回路）から構成されているとしてもよい。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどを含んで構成されるコンピュータシステムである。ＲＡＭには、コンピュータプログラムが記録されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、システムＬＳＩは、その機能を達成する。

また、上記の各装置を構成する構成要素の各部は、個別に１チップ化されていてもよいし、一部又はすべてを含むように１チップ化されてもよい。

また、ここでは、システムＬＳＩとしたが、集積度の違いにより、ＩＣ、ＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサーを利用してもよい。

さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。

（２１）上記の各装置を構成する構成要素の一部または全部は、各装置に脱着可能なＩＣカードまたは単体のモジュールから構成されているとしてもよい。前記ＩＣカードまたは前記モジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどから構成されるコンピュータシステムである。ＩＣカードまたは前記モジュールは、上記の超多機能ＬＳＩを含むとしてもよい。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、ＩＣカードまたは前記モジュールは、その機能を達成する。このＩＣカードまたはこのモジュールは、耐タンパ性を有するとしてもよい。

（２２）本発明は、上記に示す方法であるとしてもよい。また、これらの方法をコンピュータにより実現するコンピュータプログラムであるとしてもよいし、コンピュータプログラムからなるデジタル信号であるとしてもよい。

また、本発明は、コンピュータプログラムまたはデジタル信号をコンピュータ読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＢＤ（Ｂｌｕ−ｒａｙ（登録商標） Ｄｉｓｃ）、半導体メモリなどに記録したものとしてもよい。また、これらの記録媒体に記録されている前記デジタル信号であるとしてもよい。

また、本発明は、前記コンピュータプログラムまたは前記デジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしてもよい。

また、本発明は、マイクロプロセッサとメモリを備えたコンピュータシステムであって、前記メモリは、上記コンピュータプログラムを記録しており、マイクロプロセッサは、コンピュータプログラムにしたがって動作するとしてもよい。

また、プログラムまたはデジタル信号を前記記録媒体に記録して移送することにより、またはプログラムまたはデジタル信号を、ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。

（２３）上記実施の形態及び上記変形例をそれぞれ組み合わせるとしてもよい。

なお、上記実施の形態において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、ＣＰＵまたはプロセッサなどのプログラム実行部が、ハードディスクまたは半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。ここで、上記実施の形態の車載ネットワーク監視システムなどを実現するソフトウェアは、次のようなプログラムである。

すなわち、このプログラムは、コンピュータに、車両に搭載される車載ネットワークを監視する、車載ネットワーク監視方法であって、車載ネットワークシステムを搭載する車両の状態と、前記車載ネットワークで通信されるメッセージの識別子と、前記メッセージの不正検知結果とのうちの１つ以上を用いて優先度を決定する優先度決定ステップと、前記車載ネットワークで通信されるメッセージを送受信する第一通信ステップと、前記車載ネットワークに関する情報を、前記第一通信ステップで受信した前記メッセージに基づいて抽出する車両ログ抽出ステップと、前記優先度と、前記車載ネットワークに関する情報とを含んだ通知情報を通知する第二通信ステップと、前記１以上の車両から、優先度と前記車載ネットワークシステムに関する情報とを含んだ通知情報を受信する第三通信ステップと、前記車載ネットワークシステムに関する情報から、前記車載ネットワークシステムに不正が発生しているか否かを分析するログ分析ステップとを含み、前記ログ分析ステップでは、前記通知情報に含まれる前記優先度が大きい前記通知情報ほど、前記通知情報に含まれる前記車載ネットワークシステムに関する情報の分析をより優先的に行う車載ネットワーク監視方法を実行させる。

以上、一つまたは複数の態様に係る電子制御装置などについて、実施の形態に基づいて説明したが、本発明は、この実施の形態に限定されるものではない。本発明の趣旨を逸脱しない限り、当業者が思いつく各種変形を本実施の形態に施したものや、異なる実施の形態における構成要素を組み合わせて構築される形態も、一つまたは複数の態様の範囲内に含まれてもよい。

本発明は、車両に搭載される電子制御装置、及び、車載ネットワークにおける不正を検知する不正検知サーバなどに適用可能である。

１０、２０、３０、４０、５０ バス
８０ 不正検知サーバ
８１ ネットワーク
１００、１０１、２００、２０１、３００、３０１、３０２、４００、４０１、１３０１、１３０２ ＥＣＵ
１１０ エンジン
１１１ トランスミッション
２１０ ブレーキ
２１１ ステアリング
３１０ カメラ
３１１ カーナビ
３１２ 車車間通信モジュール
４１０ ドア
４１１ ライト
５１０ 診断ポート
８１０ 通信部
８２０ 処理判断部
８３０ ログ収集部
８４０ ログ分析部
８５０ 結果通知部
８６０ 受付部
８７０ 対処部
８８０ 車両情報ＤＢ
８８１ 車両ログ格納ＤＢ
８８２ 分析結果格納ＤＢ
８８３ セキュリティ情報ＤＢ
８９０ 設定部
９００、１９００ ゲートウェイ
９１０ フレーム送受信部
９２０、１３２０ フレーム解釈部
９３０、１３３０ 優先度決定部
９３１ 不正検知部
９４０ 更新処理部
９５０ フレームアップロード部
９６０ 転送制御部
９７０ 鍵処理部
９８０ フレーム生成部
９９０ ルール保持部
９９１ 転送ルール保持部
９９２ 鍵保持部
１０１０ａ、１０１０ｂ、１０１０ｃ、１０１０ｄ、１０１０ｅ、１０１０ｆ 車両
１３４０ サーバ通信部
１３５０ 接続機器通信部
１３６０ 優先度ルール保持部
１３７０ フレーム履歴保持部
１９３０ 不正フレーム検知部
１９４０ 不正通知部
１９９０ 不正検知ルール保持部
Ｕ 管理者

Claims (16)

1. 車載ネットワークを含む車載ネットワークシステムに関する情報を、車両外部の不正検知サーバに通知する電子制御装置であって、
   前記車載ネットワークシステムを搭載する車両の状態と、前記車載ネットワークで通信されるメッセージの識別子と、前記メッセージの不正検知結果とのうちの１つ以上を用いて優先度を決定する優先度決定部と、
   前記車載ネットワークで通信されるメッセージを送受信する第一通信部と、
   前記車載ネットワークに関する情報を、前記第一通信部が受信した前記メッセージに基づいて抽出する車両ログ抽出部と、
   前記優先度と、前記車載ネットワークに関する情報とを含んだ通知情報を前記不正検知サーバに通知する第二通信部とを備える、
   電子制御装置。
2. 前記車両の状態は、前記第一通信部が受信した前記メッセージをもとに算出される情報であって、前記車両の速度、前記車両の加速度、前記車両の操舵角度、前記車両の運転支援機能の動作状況、及び、前記車載ネットワークの帯域占有率のうちの１つ以上を含む情報である、
   請求項１記載の電子制御装置。
3. 前記優先度決定部は、前記メッセージの識別子により定まる前記メッセージの種別が、運転支援及び自動運転に関わる制御メッセージ、前記車両に搭載されている電子制御装置のファームウェアアップデートに関わるメッセージ、前記車両の走行状態通知に関わるメッセージ、及び、前記車両の診断用メッセージのいずれかを含む場合に、より高い前記優先度を決定する、
   請求項１または２記載の電子制御装置。
4. 前記不正検知結果は、前記車載ネットワークで通信されるメッセージに含まれる、メッセージ認証コードの検証結果を含み、
   前記優先度決定部は、前記メッセージ認証コードの検証結果が不当である場合に、より高い前記優先度を決定する、
   請求項１から３のいずれか１項に記載の電子制御装置。
5. 前記電子制御装置は、さらに、
   前記車載ネットワークで通信されるメッセージの不正を検知する不正検知部を備え、
   前記メッセージの不正検知結果は、前記不正検知部が前記メッセージの不正を検出したか否かを示す情報であり、
   前記優先度決定部は、前記不正検知結果が、前記メッセージの不正を検出したことを示す場合に、より高い前記優先度を決定する、
   請求項１から４のいずれか１項に記載の電子制御装置。
6. 前記通知情報は、前記通知情報に含まれる前記車載ネットワークに関する情報に係る前記メッセージの識別子を含み、
   前記第二通信部は、
   前記不正検知サーバに過去に通知した過去の通知情報を保持しており、
   前記不正検知サーバに新たな通知情報を通知する前に、前記過去の通知情報の中に、前記新たな通知情報に含まれる前記車載ネットワークに関する情報に係る前記メッセージの識別子、前記メッセージの不正検知結果、及び、前記優先度のうちの所定の一部が一致する場合に、前記通知情報を前記不正検知サーバに通知することを禁止する、
   請求項１から５のいずれか１項に記載の電子制御装置。
7. 前記第二通信部は、
   前記優先度が第一の所定の値以下である場合には、不正検知サーバに前記通知情報を通知することを禁止する処理、又は、所定の通信間隔を有する第一タイミングで不正検知サーバに前記通知情報を通知する処理のいずれかの処理を行い、
   前記優先度が第二の所定の値以上である場合には、前記第一タイミングとは異なる第二タイミングで不正検知サーバに前記通知情報を通知する、
   請求項１から６のいずれか１項に記載の電子制御装置。
8. 車載ネットワークを含む車載ネットワークシステムに関する情報を含んだ通知情報を１以上の車両から受信する不正検知サーバであって、
   前記１以上の車両から、優先度と前記車載ネットワークシステムに関する情報とを含んだ通知情報を受信する第三通信部と、
   前記車載ネットワークシステムに関する情報から、前記車載ネットワークシステムに不正が発生しているか否かを分析するログ分析部を備え、
   前記ログ分析部は、
   前記通知情報に含まれる前記優先度が大きい前記通知情報ほど、前記通知情報に含まれる前記車載ネットワークシステムに関する情報の分析をより優先的に行う
   不正検知サーバ。
9. 前記ログ分析部は、
   前記通知情報に含まれる前記優先度が大きいほど、
   前記車載ネットワークに関する情報の分析の順番をより早くし、
   前記車載ネットワークに関する情報の分析に割り当てる計算資源をより大きくし、又は、
   前記車載ネットワークに関する情報の分析の実行をするか否かの判定において、より優先的に実行すると判定する
   請求項８記載の不正検知サーバ。
10. 前記不正検知サーバは、さらに、
    前記車載ネットワークの不正に対処する処理を行う対処部を備え、
    前記ログ分析部は、前記優先度が第一の所定の値以下である場合には、前記車載ネットワークに関する情報の分析を禁止し、
    前記対処部は、前記優先度が第二の所定の値以上である場合に、前記車載ネットワークの不正に対処する処理を行う、
    請求項９記載の不正検知サーバ。
11. 前記対処部は、
    前記１以上の車両のうちの車両が備える前記車載ネットワークの不正に対する対処として、
    （ａ）不正検知サーバ外部の管理者への不正発生の通知、
    （ｂ）前記車両に対する、運転支援機能及び自動運転機能を無効化する制御信号の通知、
    （ｃ）前記車両に含まれる暗号鍵情報の更新、
    （ｄ）前記車両に対する、機能安全モードへの移行の通知、
    （ｅ）前記車両に対する、遠隔制御モードへの移行の通知、
    （ｆ）前記車両の外部に存在するオペレータとの通話、
    （ｇ）前記車両に含まれる情報系システムの強制終了、及び、
    （ｈ）前記車両に含まれる電子制御装置のファームウェアのアップデート、のいずれか１つ以上を行う、
    請求項１０記載の不正検知サーバ。
12. 前記不正検知サーバは、さらに、
    前記１以上の車両が前記不正検知サーバに通知する前記通知情報の前記優先度の下限値を設定する設定部を備え、
    前記設定部は、
    前記不正検知サーバの処理負荷を測定し、
    計測した前記不正検知サーバの処理負荷が所定の値以上である場合に、前記優先度の下限値を上昇させて、前記車両に通知する、
    請求項８から１０のいずれか１項に記載の不正検知サーバ。
13. 車載ネットワークを含む車載ネットワークシステムに関する情報を含んだ通知情報を、車両外部の不正検知サーバに通知する車載ネットワークシステムであって、
    前記車載ネットワークシステムは、
    第一電子制御装置と、
    第二電子制御装置と、を備え、
    前記第一電子制御装置は、
    前記車載ネットワークで通信されるメッセージの不正を検知する不正検知部と、
    前記不正検知部が前記メッセージの不正検知結果を、前記第二電子制御装置に通知する不正通知部とを備え、
    前記第二電子制御装置は、
    前記車載ネットワークシステムを搭載する車両の状態と、前記車載ネットワークシステムで通信されるメッセージの識別子と、前記メッセージの不正検知結果とのうちの１つ以上を用いて優先度を決定する第二優先度決定部と、
    前記車載ネットワークで通信されるメッセージを送受信する第四通信部と、
    前記車載ネットワークに関する情報を、前記第四通信部が受信した前記メッセージに基づいて抽出する第二車両ログ抽出部と、
    前記第一電子制御装置から前記メッセージの不正検知結果を受信する第二不正検知結果受信部と、
    前記優先度と、前記車載ネットワークに関する情報とを含んだ通知情報を前記不正検知サーバへ通知する第五通信部とを備える、
    車載ネットワークシステム。
14. 前記車載ネットワークシステムは、さらに、
    第三電子制御装置を備え、
    前記第三電子制御装置は、
    前記車載ネットワークシステムを搭載する車両の状態と、前記車載ネットワークシステムに通信されるメッセージの識別子と、前記メッセージの不正検知結果とのうちの１つ以上を用いて優先度を決定する第三優先度決定部と、
    前記車載ネットワークで通信されるメッセージを送受信する第六通信部と、
    前記車載ネットワークに関する情報を、前記第六通信部が受信した前記メッセージに基づいて抽出する第三車両ログ抽出部と、
    前記第一電子制御装置から前記メッセージの不正検知結果を受信する第三不正検知結果受信部と、
    前記優先度と、前記車載ネットワークに関する情報とを含んだ通知情報を前記不正検知サーバへ通知する第七通信部とを備え、
    前記不正通知部は、
    検知した不正なメッセージに含まれる識別子が、第一電子制御装置が送信するメッセージの識別子である場合に、前記不正検知結果を前記第三電子制御装置へ通知する、
    請求項１３記載の車載ネットワークシステム。
15. 車両に搭載される車載ネットワークを監視する、車載ネットワーク監視システムであって、
    前記車載ネットワーク監視システムは、
    前記車載ネットワークを含む車載ネットワークシステムに関する情報を、車両外部の不正検知サーバに通知する電子制御装置と、前記不正検知サーバと、を含み、
    前記電子制御装置は、
    前記車載ネットワークシステムを搭載する車両の状態と、前記車載ネットワークで通信されるメッセージの識別子と、前記メッセージの不正検知結果とのうちの１つ以上を用いて優先度を決定する優先度決定部と、
    前記車載ネットワークで通信されるメッセージを送受信する第一通信部と、
    前記車載ネットワークに関する情報を、前記第一通信部が受信した前記メッセージに基づいて抽出する車両ログ抽出部と、
    前記優先度と、前記車載ネットワークに関する情報とを含んだ通知情報を前記不正検知サーバに通知する第二通信部とを備え、
    前記不正検知サーバは、
    前記１以上の車両から、優先度と前記車載ネットワークシステムに関する情報とを含んだ通知情報を受信する第三通信部と、
    前記車載ネットワークシステムに関する情報から、前記車載ネットワークシステムに不正が発生しているか否かを分析するログ分析部を備え、
    前記ログ分析部は、
    前記通知情報に含まれる前記優先度が大きい前記通知情報ほど、前記通知情報に含まれる前記車載ネットワークシステムに関する情報の分析をより優先的に行う
    車載ネットワーク監視システム。
16. 車両に搭載される車載ネットワークを監視する、車載ネットワーク監視方法であって、
    車載ネットワークシステムを搭載する車両の状態と、前記車載ネットワークで通信されるメッセージの識別子と、前記メッセージの不正検知結果とのうちの１つ以上を用いて優先度を決定する優先度決定ステップと、
    前記車載ネットワークで通信されるメッセージを送受信する第一通信ステップと、
    前記車載ネットワークに関する情報を、前記第一通信ステップで受信した前記メッセージに基づいて抽出する車両ログ抽出ステップと、
    前記優先度と、前記車載ネットワークに関する情報とを含んだ通知情報を通知する第二通信ステップと、
    前記１以上の車両から、優先度と前記車載ネットワークシステムに関する情報とを含んだ通知情報を受信する第三通信ステップと、
    前記車載ネットワークシステムに関する情報から、前記車載ネットワークシステムに不正が発生しているか否かを分析するログ分析ステップとを含み、
    前記ログ分析ステップでは、
    前記通知情報に含まれる前記優先度が大きい前記通知情報ほど、前記通知情報に含まれる前記車載ネットワークシステムに関する情報の分析をより優先的に行う
    車載ネットワーク監視方法。

Images