(57)【要約】車載ネットワークにおける通信のログを出力するログ出力方法であって、車載ネットワークに送出されたメッセージの異常性を互いに異なる方法でそれぞれ判定する複数の判定処理を行う異常判定ステップ（Ｓ１００２）と、複数の判定処理の結果に従って、ログを生成するログ生成ステップ（Ｓ１００４）と、生成したログを送信するログ送信ステップ（Ｓ１００５）とを含み、ログ生成ステップ（Ｓ１００４）では、複数の判定処理の結果の組み合わせに従って、ログに含まれる情報に重複が発生しないように、ログに含まれる情報を決定する。
2019193786.tif 000002
【特許請求の範囲】
【請求項１】
車載ネットワークにおける通信のログを出力するログ出力方法であって、
前記車載ネットワークに送出されたメッセージの異常性を互いに異なる方法でそれぞれ判定する複数の判定処理を行う異常判定ステップと、
前記複数の判定処理の結果に従って、前記ログを生成するログ生成ステップと、
生成した前記ログを送信するログ送信ステップとを含み、
前記ログ生成ステップでは、前記複数の判定処理の結果の組み合わせに従って、前記ログに含まれる情報に重複が発生しないように、前記ログに含まれる情報を決定する、
ログ出力方法。
【請求項２】
前記複数の判定処理は、前記異なる方法の一つとして、前記メッセージのＭＡＣ（Ｍｅｓｓａｇｅ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｃｏｄｅ）を検証することにより前記異常性を判定するＭＡＣ検証処理を含む、
請求項１に記載のログ出力方法。
【請求項３】
前記複数の判定処理は、前記異なる方法の一つとして、前記メッセージから車両の振る舞いを検知することにより前記異常性を判定する振る舞い検知処理を含む、
請求項１又は２に記載のログ出力方法。
【請求項４】
前記複数の判定処理は、前記異なる方法の一つとして、前記メッセージに異常を示す兆候が現れているか否かを監視することにより前記異常性を判定する兆候監視処理を含む、
請求項１〜３のいずれか１項に記載のログ出力方法。
【請求項５】
前記複数の判定処理は、前記メッセージから車両の振る舞いを検知することにより前記異常性を判定する振る舞い検知処理と、前記メッセージに異常を示す兆候が現れているか否かを監視することにより前記異常性を判定する兆候監視処理とを含み、
前記ログ生成ステップでは、
前記振る舞い検知処理と前記兆候監視処理の両方において前記メッセージに異常性があると判定されたとき、
（Ａ）前記振る舞い検知処理と前記兆候監視処理において、メッセージに異常性があると判定された理由が異なる場合、前記振る舞い検知処理で異常性があると判定された値と、前記兆候監視処理で異常性があると判定された値とを、前記ログとして出力し、
（Ｂ）前記振る舞い検知処理と前記兆候監視処理において、前記メッセージに異常性があると判定された理由が同じ場合、前記振る舞い検知処理で異常性があると判定された値と、前記兆候監視処理で異常性があると判定された値とのいずれか一方を、前記ログとして出力する、
請求項１又は２に記載のログ出力方法。
【請求項６】
車載ネットワークシステムにおける通信のログを出力するログ出力装置であって、
１個以上のプロセッサと、
記憶部とを含み、
前記記憶部を用いて、前記１個以上のプロセッサは、
前記車載ネットワークに送出されたメッセージの異常性を互いに異なる方法でそれぞれ判定する複数の判定処理を行う異常判定ステップと、
前記複数の判定処理の結果に従って、前記ログを生成するログ生成ステップと、
生成した前記ログを送信するログ送信ステップとを行い、
前記ログ生成ステップでは、前記複数の判定処理の結果の組み合わせに従って、前記ログに含まれる情報に重複が発生しないように、前記ログに含まれる情報を決定する、
ログ出力装置。
【請求項７】
コンピュータに請求項１に記載のログ出力方法を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、車載ネットワークにおける通信のログを出力するログ出力方法等に関する。
【背景技術】
【０００２】
近年、自動車の中のシステムには、電子制御ユニット（ＥＣＵ：Ｅｌｅｃｔｒｏｎｉｃ  Ｃｏｎｔｒｏｌ  Ｕｎｉｔ、以下、ＥＣＵとも表記する）と呼ばれる装置が多数配置されている。これらのＥＣＵを用いて構成された通信ネットワークは車載ネットワークと呼ばれる。車載ネットワークで用いられる通信には、多数の通信規格が存在する。主流である車載ネットワークの通信規格の一つに、Ｃｏｎｔｒｏｌｌｅｒ  Ａｒｅａ  Ｎｅｔｗｏｒｋ（ＣＡＮ）がある。【０００３】
ＣＡＮの規格を採用したネットワーク（ＣＡＮネットワーク）では、通信路（バス）は２本のケーブルで構成され、バスに接続されているＥＣＵはノードとも呼ばれる。バスに接続されている各ノードは、メッセージと呼ばれる単位又はメッセージを分割したフレームと呼ばれる単位でデータを送受信する。またＣＡＮでは、データの送信先又は送信元を示す識別子は用いられない。【０００４】
フレームを送信するノード（送信ノード）は、メッセージ毎にメッセージの種類を示すメッセージＩＤと呼ばれるＩＤを付けてメッセージを送信、つまりバスに信号を送出する。メッセージを受信するノード（受信ノード）は、予め決められたメッセージＩＤを含むメッセージのみを受信、つまりバスから信号を読み取る。同一ＩＤのメッセージは、一定の周期で送信される。【０００５】
上述の通り、自動車の中のシステムに多数配置されているＥＣＵは、それぞれがＣＡＮネットワークに接続され、メッセージを互いに送受信しながら動作している。【０００６】
ここで、ＣＡＮネットワークの外部と通信機能を持つＥＣＵが、外部から不正にアクセスされること等により、何者かに不正に制御され、ＣＡＮネットワークに対して異常なメッセージを送信することが起こり得る。このような何者かに不正に制御されたＥＣＵ（不正ＥＣＵ）は、例えば他のＥＣＵになりすまして異常なメッセージを送信し、車両を不正に制御することが可能となる。このような、いわゆるなりすまし攻撃を検知するための方法が、例えば、特許文献１に開示されている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】国際公開第２０１４／１１５４５５号
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、特許文献１に開示されている方法では、ＥＣＵ内部において異常なメッセージを検知することしかできず、サーバなどの外部の装置を用いた検知は難しい。また、メッセージが送信された時ではなく、事後的に、異常なメッセージについて精査することができないという課題がある。【０００９】
本開示は、上記課題を解決するもので、バスに送出された個々のメッセージが異常なメッセージであるか否かを判定するために必要なログ情報を生成し出力するログ出力方法、ログ出力装置等を提供することを目的とする。
【課題を解決するための手段】
【００１０】
上記課題を解決するために、本開示の一態様に係るログ出力方法は、車載ネットワークシステムにおける通信のログを出力するログ出力方法であって、前記ネットワークに送出されたメッセージの異常性を互いに異なる方法でそれぞれ判定する複数の判定処理を行う異常判定ステップと、前記複数の判定処理の結果の組み合わせに従って、前記ログに含まれる情報が重複しないように前記ログを生成するログ生成ステップと、生成した前記ログを送信するログ送信ステップとを含む。【００１１】
なお、これらの包括的または具体的な態様は、システム、装置、方法、集積回路、コンピュータプログラム又はコンピュータ読み取り可能なＣＤ−ＲＯＭなどの非一時的な記録媒体で実現されてもよく、システム、装置、方法、集積回路、コンピュータプログラム及び記録媒体の任意な組み合わせで実現されてもよい。
【発明の効果】
【００１２】
本開示の一態様に係るログ出力方法等によれば、ネットワークに送出されたメッセージを異常であるか否かを判定した結果に応じて、ログを生成するために用いる情報を決定することにより、必要最小限のログを生成し、出力することで、コストを抑えることができる。
【図面の簡単な説明】
【００１３】
【図１】図１は、実施の形態１における車載ネットワークシステムの全体構成を示すブロック図である。
【図２】図２は、実施の形態１におけるＣＡＮプロトコルのメッセージ（データフレーム）のフォーマットを示す図である。
【図３】図３は、実施の形態１における車載ネットワークシステムに含まれるゲートウェイの一例を示すブロック図である。
【図４】図４は、実施の形態１における受信ＩＤリストの一例を示す図である。
【図５】図５は、実施の形態１における転送ルールの一例を示す図である。
【図６】図６は、実施の形態１における異常検知処理機能群の一例を示すブロック図である。
【図７】図７は、実施の形態１における振る舞い検知部の一例を示すブロック図である。
【図８】図８は、実施の形態１におけるログ出力処理機能群の一例を示すブロック図である。
【図９】図９は、実施の形態１におけるログ出力制御部におけるログ出力の判定例を示す図である。
【図１０】図１０は、実施の形態１におけるログに含めるＮＧと判定した値の一例を示す図である。
【図１１】図１１は、実施の形態１における車載ネットワークシステムに含まれるＥＣＵの一例を示すブロック図である。
【図１２】図１２は、実施の形態１における車載ネットワークシステムに含まれるサーバの一例を示すブロック図である。
【図１３】図１３は、実施の形態１における異常検知処理の一例を示すフローチャートである。
【図１４】図１４は、実施の形態１における転送処理の一例を示すフローチャートである。
【図１５】図１５は、変形例におけるゲートウェイの一例を示すブロック図である。
【図１６】図１６は、変形例におけるログ出力処理機能群の一例を示すブロック図である。
【図１７】図１７は、変形例におけるゲートウェイの一例を示すブロック図である。
【図１８】図１８は、変形例におけるＥＣＵの一例を示すブロック図である。
【図１９】図１９は、変形例におけるＥＣＵの一例を示すブロック図である。
【図２０】図２０は、変形例におけるＥＣＵの一例を示すブロック図である。
【図２１】図２１は、変形例におけるゲートウェイの別の一例を示すブロック図である。
【図２２】図２２は、変形例におけるＥＣＵの一例を示すブロック図である。
【発明を実施するための形態】
【００１４】
（本開示の基礎になった知見）
ＣＡＮネットワーク上に異常なメッセージが送信されたことを判定する機能において、その判定結果、および、判定結果に関連する情報をログとして生成し、出力する場合、異常という判定に至った状況を後で詳細に確認するためには、多くのデータを必要とする。しかし、ログの出力先で必要となる記憶容量又は、出力先にデータを送信する際の通信量が多いと、多大なコストがかかってしまう。
【００１５】
そこで、本開示の一態様に係るログ出力方法は、車載ネットワークシステムにおける通信のログを出力するログ出力方法であって、前記ネットワークに送出されたメッセージの異常性を互いに異なる方法でそれぞれ判定する複数の判定処理を行う異常判定ステップと、前記複数の判定処理の結果に従って、ログを生成するログ生成ステップと、生成した前記ログを送信するログ送信ステップとを含み、前記ログ生成ステップでは、前記複数の判定処理の結果の組み合わせに従って、前記ログに含まれる情報に重複が発生しないように、前記ログに含まれる情報を決定する。
【００１６】
これにより、ネットワークに送出されたメッセージを異常であると判定した結果に応じて、ログを生成するために用いる情報を決定することにより、必要最小限の情報を含むログを生成し、出力することで、コストを抑えることができる。
【００１７】
また、本開示の一態様に係るログ出力方法において、前記複数の判定処理は、前記異なる方法の一つとして、前記メッセージのＭＡＣ（Ｍｅｓｓａｇｅ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｃｏｄｅ）を検証することにより前記異常性を判定するＭＡＣ検証処理を含む。
【００１８】
これにより、受信したメッセージの完全性を確認することができ、ネットワークに送出されたメッセージの異常性を判定することができる。
【００１９】
また、本開示の一態様に係るログ出力方法において、前記複数の判定処理は、前記メッセージから車両の振る舞いを検知することにより前記異常性を判定する振る舞い検知処理を含む。
【００２０】
これにより、車両に含まれるＥＣＵが、外部から攻撃されること等により、何者かに乗っ取られ、車両が異常な振る舞いを行っていることを検知でき、ネットワークに送出されたメッセージの異常性を判定することができる。
【００２１】
また、本開示の一態様に係るログ出力方法において、前記複数の判定処理は、前記メッセージに異常を示す兆候が現れているか否かを監視することにより前記異常性を判定する兆候監視処理を含む。
【００２２】
これにより、メッセージの送信周期等の異常を検知することができ、ネットワークに送出されたメッセージの異常性を判定することができる。
【００２３】
また、本開示の一態様に係るログ出力方法において、前記複数の判定処理は、前記メッセージから車両の振る舞いを検知することにより前記異常性を判定する振る舞い検知処理と、前記メッセージに異常を示す兆候が現れているか否かを監視することにより前記異常性を判定する兆候監視処理とを含み、前記ログ生成ステップでは、前記振る舞い検知処理と前記兆候監視処理の両方において異常性があると判定されたとき、（Ａ）前記振る舞い検知処理と前記兆候監視処理において、メッセージに異常性があると判定された理由が異なる場合、前記振る舞い検知処理で異常性があると判定された値と、前記兆候監視処理で異常性があると判定された値とを、ログとして出力し、（Ｂ）前記振る舞い検知処理と前記兆候監視処理において、異常と判定された理由が同じ場合、前記振る舞い検知処理で異常性があると判定された値と、前記兆候監視処理で異常性があると判定された値とのいずれか一方を、ログとして出力する。
【００２４】
これにより、ネットワークに創出されたメッセージに異常性があると判断された場合に、出力されるログのデータ量を低減させることができる。
【００２５】
また、本開示の一態様に係るログ出力装置は、車載ネットワークシステムにおける通信のログを出力するログ出力装置であって、１個以上のプロセッサと、記憶部とを含み、前記記憶部を用いて、前記１個以上のプロセッサは、前記ネットワークに送出されたメッセージの異常性を互いに異なる方法でそれぞれ判定する複数の判定処理を行う異常判定ステップと、前記複数の判定処理の結果に従って、ログを生成するログ生成ステップと、生成した前記ログを送信するログ送信ステップとを含み、前記ログ生成ステップでは、前記複数の判定処理の結果の組み合わせに従って、前記ログに含まれる情報に重複が発生しないように、前記ログに含まれる情報を決定する。
【００２６】
これにより、ネットワークに送出されたメッセージを異常であると判定した結果に応じてログを生成するために用いる情報を決定することにより、必要最小限のログを生成し、出力することで、コストを抑えることができる。
【００２７】
また、本開示の一態様に係るプログラムは、上記のログ出力装置において、前記１個以上のプロセッサに上記のログ出力方法を実施させるためのプログラムである。
【００２８】
これにより、ネットワークに送出されたメッセージを異常と判定した結果に応じてログを生成するために用いる情報を決定することにより、必要最小限のログを生成し、出力することで、コストを抑えることができる。
【００２９】
以下、実施の形態について図面を参照しながら具体的に説明する。
【００３０】
なお、以下で説明する実施の形態は、いずれも包括的または具体的な例を示すものである。以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置および接続形態、ステップ、ステップの順序などは一例であり、本開示を限定する趣旨ではない。以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素は、任意で含まれる構成要素として説明されるものである。
【００３１】
（実施の形態１）
［１．概要］
本実施の形態では、車載ネットワークシステムにおいて、送信されているメッセージが異常なメッセージであるか否かの判定がなされ、その判定結果に応じてログを出力する場合について図面を参照しながら説明する。
【００３２】
［１．１  車載ネットワークシステムの全体構成］
図１は、本実施の形態における車載ネットワークシステム１０の全体構成を示すブロック図である。
【００３３】
図１において、車載ネットワークシステム１０は、ＣＡＮネットワークで構成され、ＥＣＵ１００ａ、ＥＣＵ１００ｂ、ＥＣＵ１００ｃ、及びＥＣＵ１００ｄと、バス２００ａ及びバス２００ｂと、ゲートウェイ３００と、外部ネットワーク４００と、サーバ５００とを含む。
【００３４】
以下では、ＥＣＵ１００ａ、ＥＣＵ１００ｂ、ＥＣＵ１００ｃ、ＥＣＵ１００ｄを、集合的にＥＣＵ１００とする場合がある。又、ＥＣＵ１００ａ、ＥＣＵ１００ｂ、ＥＣＵ１００ｃ、ＥＣＵ１００ｄのいずれかを指して、ＥＣＵ１００として説明する場合がある。
【００３５】
また、以下では、バス２００ａ、バス２００ｂを、集合的にバス２００とする場合がある。又、バス２００ａ及びバス２００ｂのいずれか一方を指して、バス２００とする場合がある。
【００３６】
ＥＣＵ１００ａはエンジン１０１に接続され、ＥＣＵ１００ｂはブレーキ１０２に接続される。また、ＥＣＵ１００ｃはドア開閉センサ１０３に接続され、ＥＣＵ１００ｄはウィンドウ開閉センサ１０４に接続されている。
【００３７】
ＥＣＵ１００は、ＥＣＵ１００と接続されている機器の状態を取得し、機器の状態を表す取得したメッセージを周期的にバス２００に送出する。例えばＥＣＵ１００ａは、エンジン１０１の回転数を取得し、この回転数を表すデータ値を含むメッセージに所定のＩＤを付けてバス２００に送出する。
【００３８】
また、各ＥＣＵ１００は、他のＥＣＵ１００が送信したメッセージをバス２００から読み出し、メッセージに付されたＩＤに応じて選択的に受信する。この選択的な受信については後述する。
【００３９】
ゲートウェイ３００は、ＥＣＵ１００ａ及びＥＣＵ１００ｂが接続されているバス２００ａと、ＥＣＵ１００ｃ及びＥＣＵ１００ｄが接続されているバス２００ｂとを接続している。ゲートウェイ３００は一方のバス２００から受信したメッセージを、もう一方のバス２００に転送する機能を持つ。ゲートウェイ３００もまた、ＣＡＮネットワーク上ではひとつのノードである。
【００４０】
外部ネットワーク４００は、ゲートウェイ３００とサーバ５００が通信するための通信ネットワークである。外部ネットワーク４００の通信方法は、有線であっても良いし、無線であっても良い。また、無線通信方式はＷｉ−Ｆｉ（登録商標）又は、３Ｇ／ＬＴＥであっても良い。
【００４１】
サーバ５００は、外部ネットワーク４００を介して、ゲートウェイ３００と通信を行う。
【００４２】
なお、車載ネットワークシステム１０は、メッセージが異常なメッセージであるか否かの判定をし、ログを出力するログ出力システム等が適用可能な対象を説明するための例である。また、ログ出力システムの適用対象は車載ネットワークシステム１０に限定されない。
【００４３】
［１．２  メッセージのデータフォーマット］
図２は、ＣＡＮプロトコルのメッセージ（データフレーム）のフォーマットを示す図である。ここではＣＡＮプロトコルにおける標準ＩＤフォーマットにおけるメッセージを示している。
【００４４】
メッセージは、ＳＯＦ（Ｓｔａｒｔ  Ｏｆ  Ｆｒａｍｅ）と、ＩＤフィールド、ＲＴＲ（Ｒｅｍｏｔｅ  Ｔｒａｎｓｉｍｉｓｓｉｏｎ  Ｒｅｑｕｅｓｔ）、ＩＤＥ（Ｉｄｅｎｔｉｆｉｅｒ  Ｅｘｔｅｎｓｉｏｎ）、予約ｂｉｔ（ｒとも呼ぶ）、ＤＬＣ（Ｄａｔａ  Ｌｅｎｇｔｈ  Ｃｏｄｅ）、データフィールド、ＣＲＣ（Ｃｙｃｒｉｃ  Ｒｅｄｕｎｄａｎｃｙ  Ｃｈｅｃｋ）シーケンス、ＣＲＣデリミタ（図中、左のＤＥＬ）と、ＡＣＫ（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）スロットと、ＡＣＫデリミタ（図中、右のＤＥＬ）と、ＥＯＦ（Ｅｎｄ  Ｏｆ  Ｆｒａｍｅ）から構成される。
【００４５】
ＳＯＦは、１ｂｉｔのドミナントである。ドミナントは、優性の意である。ドミナントは、データの伝達にデジタル方式が用いられるＣＡＮネットワークにおいて、“０”の値を送信するようにバスを構成する２本のケーブルに電圧がかけられた状態、または送信されるこの“０”の値のことである。これに対し、“バスを構成する２本のケーブルに１”の値を送信するように電圧がかけられた状態、または送信されるこの“１”の値のことはレセシブと呼ばれる。レセシブは、劣勢の意である。２つのノードからバスに同時に“０”の値と“１”の値とが送信された場合には、“０”の値が優先される。アイドル状態の時のバスは、レセシブの状態である。各ＥＣＵ１００は、バス２００の状態をレセシブからドミナントへ変化させることでメッセージの送信を開始し、他のＥＣＵ１００はこの変化を読み取って同期する。図２において、メッセージを構成するドミナント又はレセシブを示す線が実線である部分は、ドミナント又はレセシブの各値を取り得ることを示す。ＳＯＦはドミナントの状態で固定されているため、ドミナントの線は実線であり、レセシブの線は破線である。
【００４６】
ＩＤとは、メッセージが含むデータの種類を示す１１ｂｉｔの値である。またＣＡＮでは、複数のノードが同時に送信を開始したメッセージ間での通信調停において、ＩＤの値がより小さいメッセージがより高い優先度となるよう設計されている。
【００４７】
ＲＴＲとは、フレームがメッセージ（データフレーム）であることを示す１ｂｉｔのドミナントである。
【００４８】
ＩＤＥとｒは、それぞれ１ｂｉｔのドミナントである。
【００４９】
ＤＬＣは、続くデータフィールドの長さを示す４ｂｉｔの値である。
【００５０】
データフィールドは、送信されるデータの内容を示す値であり、最大６４ｂｉｔ長で、８ｂｉｔ単位で長さを調整できる。送信されるデータのデータフィールドへの割り当てに関する仕様は、車種及び製造者等に依存する。
【００５１】
ＣＲＣシーケンスは、ＳＯＦ、ＩＤフィールド、コントロールフィールド、データフィールドの送信値より算出される１５ｂｉｔの値である。
【００５２】
ＣＲＣデリミタは１ｂｉｔのレセシブで固定されており、ＣＲＣシーケンスの終了を表す区切り記号である。受信ノードは、受信したメッセージのＳＯＦ、ＩＤフィールド、コントロールフィールド、及びデータフィールドの値から算出した結果をＣＲＣシーケンスの値と比較することで異常の有無を判断する。
【００５３】
ＡＣＫスロットは１ｂｉｔ長で、送信ノードはＡＣＫスロットにおいてレセシブを送信する。受信ノードはＣＲＣシーケンスまで正常に受信ができていれば確認応答としてドミナントを送信する。ドミナントが優先されるため、１メッセージにおける通信がＣＲＣシーケンスまで正常に行われていれば、ＡＣＫスロットの送信中のバス２００はドミナントの状態である。
【００５４】
ＡＣＫデリミタは１ｂｉｔのレセシブに固定されており、ＡＣＫスロットの終了を表す区切り記号である。
【００５５】
ＥＯＦは７ｂｉｔのレセシブに固定されており、メッセージの終了を示す。
【００５６】
［１．３  ゲートウェイの構成］
図３は、本実施の形態における車載ネットワークシステムに含まれるゲートウェイの一例を示すブロック図である。図３において、ゲートウェイ３００は、フレーム送受信部３１０と、フレーム解釈部３２０と、受信ＩＤ判定部３３０と、受信ＩＤリスト保持部３４０と、フレーム処理部３５０と、転送ルール保持部３６０と、異常検知処理機能群３７０と、ログ出力処理機能群３７５と、フレーム生成部３８０と、外部通信部３９０とを備える。
【００５７】
なお、これらの構成は機能を示す構成であり、ゲートウェイ３００は、例えばプロセッサで実現される処理部、半導体メモリ等で実現される記憶部、入出力ポートで実現される入出力部等を備える情報処理装置として提供される。
【００５８】
上記の機能を示す構成は、記憶部に保持されるプログラムを処理部により読み出し、実行し、記憶部へ所定のデータを保持し、若しくは入出力部を介してデータの送受信を実行することで実現されてもよい。又は、上記の機能を示す構成は、これらの組み合わせで実現されてもよい。
【００５９】
なお、本開示の一態様に係るログ出力方法は、ゲートウェイによって実現されるものに限らない。フレーム送受信部３１０と、フレーム解釈部３２０と、受信ＩＤ判定部３３０と、受信ＩＤリスト保持部３４０と、フレーム処理部３５０と、転送ルール保持部３６０と、異常検知処理機能群３７０と、ログ出力処理機能群３７５と、フレーム生成部３８０と、外部通信部３９０とは、単数又は複数のＥＣＵ１００によって実現されてもよい。
【００６０】
フレーム送受信部３１０は、バス２００ａ、２００ｂのそれぞれに対して、ＣＡＮのプロトコルに従ったメッセージを送受信する。
【００６１】
より具体的には、フレーム送受信部３１０は、バス２００に送出されたメッセージを１ｂｉｔずつ読み出し、読み出したメッセージをフレーム解釈部３２０に転送する。
【００６２】
また、フレーム送受信部３１０は、フレーム生成部３８０より送信されたバス情報に応じて、メッセージをバス２００ａ及び２００ｂに１ｂｉｔずつ送出する。
【００６３】
フレーム送受信部３１０は、バス２００ａから受信したメッセージをバス２００ｂに送信し、バス２００ｂから受信したメッセージをバス２００ａに送信することでバス２００間でのメッセージの転送を実行する。
【００６４】
フレーム解釈部３２０は、フレーム送受信部３１０よりメッセージの値を受け取り、ＣＡＮプロトコルにおける各フィールドにマッピングして、受信したメッセージの解釈を行う。フレーム解釈部３２０は、ＩＤフィールドの値と解釈した一連の値を、受信ＩＤ判定部３３０へ転送する。
【００６５】
フレーム解釈部３２０はさらに、受信ＩＤ判定部３３０から通知される判定結果に応じて、メッセージのＩＤフィールドの値及びＩＤフィールド以降に現れるデータフィールドをフレーム処理部３５０へ転送するか、メッセージの受信を中止するかを決定する。
【００６６】
また、フレーム解釈部３２０は、受信したメッセージがＣＡＮプロトコルに則っていないメッセージであると判断した場合は、エラーフレームを送信するようにフレーム生成部３８０へ要求する。
【００６７】
エラーフレームは、ＣＡＮネットワーク上でエラーが発生した場合に、ノードから送信される、上述のメッセージとは異なる、ＣＡＮプロトコルで規定される所定のフォーマットのフレームである。エラーフレームがバスに送出されると、そのネットワークでのメッセージの送信は中断される。
【００６８】
また、フレーム解釈部３２０は、他のノードが送信したエラーフレームを受信したと解釈した場合、読み取り中のメッセージを破棄する。
【００６９】
受信ＩＤ判定部３３０は、フレーム解釈部３２０からＩＤフィールドの値を受け取り、受信ＩＤリスト保持部３４０が保持しているメッセージＩＤのリストに従い、読み出したメッセージを受信するか否かの判定を行う。受信ＩＤ判定部３３０は、この判定の結果をフレーム解釈部３２０へ通知する。
【００７０】
受信ＩＤリスト保持部３４０は、ゲートウェイ３００が受信するメッセージＩＤのリスト（以下、受信ＩＤリストともいう）を保持する。図４は、本実施の形態における受信ＩＤリストの一例を示す図である。図４における受信ＩＤリストの詳細は、後述する。
【００７１】
フレーム処理部３５０は、転送ルール保持部３６０が保持するデータ転送に関するルールに従って、受信したメッセージのＩＤに応じて転送先となるバス２００を決定し、転送先となるバス２００と、フレーム解釈部３２０より通知されたメッセージＩＤと、転送するデータとをフレーム生成部３８０へ通知する。
【００７２】
またフレーム処理部３５０は、フレーム解釈部３２０より受け取ったメッセージを異常検知処理機能群３７０へ送り、異常検知処理機能群３７０に対して、そのメッセージが、異常なメッセージであるか否かの判定を行うように要求する。異常検知処理機能群３７０において異常なメッセージであると判定されたメッセージを、フレーム処理部３５０は転送しない。
【００７３】
転送ルール保持部３６０は、各バス２００のデータ転送に関するルール（以下、転送ルールともいう）を保持する。図５は、本実施の形態における転送ルールの一例を示す図である。図５における転送ルールの詳細は、後述する。
【００７４】
異常検知処理機能群３７０は、受信中のメッセージが異常なメッセージであるか否かの判定する機能群である。異常検知処理機能群３７０に含まれる機能構成の詳細は後述する。異常検知処理機能群３７０は、判定結果をフレーム処理部３５０とログ出力処理機能群３７５へ通知する。
【００７５】
ログ出力処理機能群３７５は、異常検知処理機能群３７０で受信中のメッセージが異常なメッセージであると判定した場合に、その判定結果に応じてログを生成し、外部通信部３９０を介してログをサーバ５００へ出力する。ログ出力処理機能群３７５に含まれる機能構成の詳細は後述する。
【００７６】
フレーム生成部３８０は、フレーム解釈部３２０からのエラーフレーム送信の要求に従い、エラーフレームを生成し、フレーム送受信部３１０にエラーフレームを送出させる。
【００７７】
またフレーム生成部３８０は、フレーム処理部３５０より受け取ったメッセージＩＤ及びデータを使ってメッセージフレームを生成し、バス情報とともに、フレーム送受信部３１０にメッセージフレームを送出する。
【００７８】
外部通信部３９０は、外部ネットワーク４００を通して、サーバ５００との通信を行う。
【００７９】
［１．４  受信ＩＤリスト］
図４は、本実施の形態における受信ＩＤリストの一例を示す図である。受信ＩＤリストは、ゲートウェイ３００が受信して処理するメッセージのメッセージＩＤのリストであり、受信ＩＤリスト保持部３４０で保持されている。
【００８０】
図４において、受信ＩＤリストは、各行にメッセージのＩＤが格納されている。図４の受信ＩＤリストは、メッセージＩＤが、「１」、「２」、「３」及び「４」であり、ゲートウェイ３００は、これらのメッセージＩＤのメッセージを受信する。ゲートウェイ３００は、受信ＩＤリストに含まれないメッセージＩＤのメッセージの受信を中止する。
【００８１】
なお、ＩＤの値及び受信ＩＤリストに含まれるＩＤの個数は説明のための一例であり、ゲートウェイ３００で用いられる受信ＩＤリストの構成をこれに限定するものではない。
【００８２】
［１．５  転送ルール］
図５は、本実施の形態における転送ルールの一例を示す図である。転送ルールは、転送ルール保持部３６０で保持されている。図５において、転送ルールは、各行にメッセージの転送元のバス２００と転送先のバス２００、及び転送対象のメッセージＩＤの組み合わせが格納されている。
【００８３】
具体的には、転送ルールの１行目は、転送元「バス２００ａ」、転送先「バス２００ｂ」、ＩＤ「＊」であり、ゲートウェイ３００は、バス２００ａから受信するメッセージを、ＩＤが何であってもバス２００ｂに転送する、というルールである。転送ルールの２行目は、転送元「バス２００ｂ」、転送先「バス２００ａ」、ＩＤ「３」であり、ゲートウェイ３００は、バス２００ｂから受信するメッセージは、ＩＤが「３」のメッセージであればバス２００ａに転送する、というルールである。
【００８４】
［１．６  異常検知処理機能群の構成］
図６は、本実施の形態におけるゲートウェイ３００が備える異常検知処理機能群３７０の一例を示すブロック図である。図６において、異常検知処理機能群３７０は、ＭＡＣ（Ｍｅｓｓａｇｅ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｃｏｄｅ）検証部３７１と、振る舞い検知部３７２と、兆候監視部３７３とを含む。
【００８５】
なお、これらの構成は機能を示す構成であり、ゲートウェイ３００において記憶部に記録されるプログラムを処理部により読み出し、実行し、記憶部へ所定のデータを記録することで実現される。若しくは記憶部へ所定のデータを記録することの代わりに、入出力部を介してデータの送受信を実行することで、これらの構成が実現されてもよい。又、これらの構成は、上記の組み合わせで実現されてもよい。
【００８６】
ＭＡＣ検証部３７１は、フレーム処理部３５０から受信したメッセージのＭＡＣを検証し、ＯＫ／ＮＧを出力する。受信したメッセージは、メッセージ本体とＭＡＣから構成される。ＭＡＣ検証部３７１は、メッセージ本体と事前に設定された鍵からＭＡＣを計算し、計算したＭＡＣとフレーム処理部３５０から受信したメッセージに含まれるＭＡＣとを比較し、一致する場合にＯＫを出力し、一致しない場合にＮＧを出力する。
【００８７】
ここで、ＭＡＣのアルゴリズムは、一般に知られているアルゴリズムであればいずれでもよく、ＨＭＡＣ（Ｈａｓｈ−ｂａｓｅｄ  Ｍｅｓｓａｇｅ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｃｏｄｅ）、ＯＭＡＣ（Ｏｎｅ−ｋｅｙ  Ｍｅｓｓａｇｅ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｃｏｄｅ）、ＣＭＡＣ（Ｃｉｐｈｅｒ−ｂａｓｅｄ  Ｍｅｓｓａｇｅ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｃｏｄｅ）、ＣＢＣ−ＭＡＣ（Ｃｉｐｈｅｒ  Ｂｌｏｃｋ  Ｃｈａｉｎｉｎｇ  Ｍｅｓｓａｇｅ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｃｏｄｅ）などを用いることが出来る。
【００８８】
また、フレーム処理部３５０から受信したメッセージに含まれるＭＡＣは、ＭＡＣのアルゴリズムにより計算された値そのものでもよいし、計算された値の一部のみを用いてもよいし、計算された値を更に変換した値を用いてもよい。この時、ＭＡＣ検証部３７１には、事前に、計算された値のどの部分を利用するかに関する情報及び、値をどのように変換するかに関する情報が与えられており、ＭＡＣ検証部３７１はそれらの情報にもとづいて、受信したメッセージに含まれるＭＡＣの検証を行う。
【００８９】
なお、フレーム処理部３５０から受信したメッセージには、ＭＡＣが含まれないことがある。この場合、ＭＡＣ検証部３７１は、検証結果としてＯＫを出力してもよいし、ＭＡＣが無い旨を示す結果を出力してもよい。
【００９０】
振る舞い検知部３７２は、フレーム処理部３５０から受信したメッセージが異常なメッセージであるか否かを判定する。
【００９１】
振る舞い検知部３７２は、複数の検知機能を持ち、事前に設定されたルールをそれぞれの検知機能が参照し、フレーム処理部３５０から受信したメッセージが異常なメッセージであるか否かを判定する。
【００９２】
図７は、本実施の形態における振る舞い検知部の一例を示すブロック図である。図７において、振る舞い検知部３７２は、６種類の判定機能を含んでいる。具体的には、判定機能として、メッセージのＩＤフィールドをチェックする機能であるＩＤ判定機能、メッセージのデータ長をチェックする機能であるデータ長判定機能、メッセージが送信される周期（時間間隔）をチェックする機能である送信周期判定機能、メッセージが送信される頻度をチェックする機能である送信頻度判定機能及びメッセージのデータフィールドの値（データ値）をチェックする機能であるデータ値判定機能を含む。さらに、これらの判定機能の判定結果、送信周期、頻度、データ値、又はデータ値の変化量などに基づいて車両の状態を認識し、車両状態をチェックする機能である車両状態判定機能を含む。また、さらに、振る舞い検知部３７２は、フレーム処理部３５０から受信したメッセージが異常なメッセージであるか否かを、これらの判定機能による判定結果から総合的に判定する総合判定機能を含む。総合判定機能の結果が、振る舞い検知部３７２による検知処理の結果となる。
【００９３】
図６に戻って、異常検知処理機能群３７０の説明を続ける。
【００９４】
図６において、兆候監視部３７３は、フレーム処理部３５０から受信したメッセージが、異常の兆候を示しているかどうかを判定する。具体的には、判定機能の内容は、振る舞い検知部３７２と同様である。兆候監視部３７３には、振る舞い検知部３７２に設定されているルールとは異なるルールを設定する。
【００９５】
例えば、兆候監視部３７３は、メッセージが送信される周期（時間間隔）が、ルールで設定された値より短い場合に、異常が発生している兆候があると判断し、ＮＧの判定を出力してもよい。このとき、振る舞い検知部３７２の送信周期判定機能が保持しているルールは、兆候監視部３７３におけるルールとは異なるため、兆候監視部３７３は、受信したメッセージを明確に異常なメッセージであるとは判断できないことから、ＯＫの判定を出力してもよい。
【００９６】
また、振る舞い検知部３７２は、周期以外の判定結果からＮＧの判定を出力する場合もある。また、兆候監視部３７３は、送信頻度がルールで設定された値より大きくなった場合に、異常が発生している兆候があると判断し、ＮＧの判定を出力してもよい。
【００９７】
異常検知処理機能群３７０は、ＭＡＣ検証部３７１の判定結果と、振る舞い検知部３７２の判定結果と、兆候監視部３７３の判定結果とのうち、ＭＡＣ検証部３７１の判定結果又は振る舞い検知部３７２の判定結果のどちらかがＮＧであった場合に、フレーム処理部３５０へＮＧの結果を出力する。
【００９８】
異常検知処理機能群３７０は、ＭＡＣ検証部３７１の判定結果と、振る舞い検知部３７２の判定結果と、兆候監視部３７３の判定結果のそれぞれと、振る舞い検知部３７２の内部のそれぞれの判定機能の判定結果と、兆候監視部３７３の内部のそれぞれの判定機能の判定結果とを、ログ出力処理機能群３７５へ通知する。
【００９９】
なお、兆候監視部３７３の判定機能は、振る舞い検知部３７２と同一であるとしたが、これに限定するものではない。例えば、兆候監視部３７３の判定機能は、振る舞い検知部３７２の判定機能のうちの一部の判定機能だけであってもよい。また、兆候監視部３７３の判定機能に、更に他の判定機能が追加されてもよい。他の判定機能は、車両に取り付けられた各種センサの値又は、車両の外部の機器から得られたデータなどを用いた判定を行うものでもよい。
【０１００】
なお、兆候監視部３７３は、振る舞い検知部３７２とは異なるルールを設定するとしたが、これに限定するものではない。例えば、兆候監視部３７３の判定機能の一部のルールが、振る舞い検知部３７２の判定機能と同じルールになっていてもよい。判定対象となるメッセージのデータの範囲が設定されているルールにおいて、１つのルールに、振る舞い検知部３７２がＮＧと判定する範囲と、それを含むより広い範囲である兆候監視部３７３がＮＧと判定する範囲の両方が含まれていてもよい。
【０１０１】
また、ここでは、異常だけでなく異常の兆候等も含めて、包括的に異常性と呼ぶ場合がある。異常検知処理機能群では、メッセージの異常性を互いに異なる方法でそれぞれ判定する複数の判定処理が行われる。また、これらの判定処理は、基本的に、互いに独立して、並列に行われる。
【０１０２】
［１．７  ログ出力処理機能群の構成］
図８は、本実施の形態におけるログ出力処理機能群の一例を示すブロック図である。図８において、ゲートウェイ３００が備えるログ出力処理機能群３７５は、ログ出力制御部３７６と、ログ関連情報保持部３７７とを含む。
【０１０３】
なお、これらの構成は機能を示す構成であり、ゲートウェイ３００において記憶部に保持されるプログラムを処理部により読み出し、実行し、記憶部へ所定のデータを記録することで実現される。若しくは記憶部へ所定のデータを記録することの代わりに、入出力部を介してデータの送受信を実行することで、これらの構成が実現されてもよい。又、これらの構成は、上記の組み合わせで実現されてもよい。
【０１０４】
ログ出力制御部３７６は、異常検知処理機能群３７０から検知結果と受信したメッセージに関連した情報、例えば、受信したメッセージ又は受信時刻等、の通知を受け、ログ出力を行うかどうかの判定を行う。
【０１０５】
ログ出力制御部３７６がログ出力を行うと判定した場合には、検知結果に応じた情報を含むログを生成する。
【０１０６】
ログ出力制御部３７６は、生成したログを外部通信部３９０へ通知し、ログをサーバへ送信するよう要請する。この時、車両を識別するために車両ごとに個別に割り当てられた車両識別子も同時に送信する。
【０１０７】
ログ出力制御部３７６による判定例を、図９を用いて説明する。図９は、本実施の形態におけるログ出力制御部におけるログ出力の判定例を示す図である。図９においては、ＭＡＣ検証部３７１の判定結果を「ＭＡＣ検証」の列に示し、振る舞い検知部３７２の判定結果を「振る舞い検知」の列に示し、兆候監視部３７３の判定結果を「兆候監視」の列に示している。
【０１０８】
ログ出力制御部３７６は、ＭＡＣ検証部３７１、振る舞い検知部３７２、兆候監視部３７３のそれぞれの判定結果から、ログを出力するか否か及び、ログを出力する場合にログにどのような内容を含めて生成するか等決定する。
【０１０９】
例えば、図９の１行目の、ＭＡＣ検証部３７１の判定結果がＯＫであり、振る舞い検知部３７２の判定結果がＯＫであり、兆候監視部３７３の判定結果がＯＫの場合、ログ出力制御部３７６は、ログを出力しないと判定し、それ以外の場合には、ログ出力制御部３７６は、ログを出力すると判定する。
【０１１０】
更に、ログ出力制御部３７６は、ログを出力すると判定した場合に、ＭＡＣ検証部３７１の判定結果と、振る舞い検知部３７２の判定結果と、兆候監視部３７３の判定結果に応じて、ログに出力する情報を変更する。
【０１１１】
例えば、図９の２行目の、ＭＡＣ検証部３７１の判定結果がＯＫであり、振る舞い検知部３７２の判定結果がＯＫであり、兆候監視部３７３の判定結果がＮＧの場合、ログに出力する情報として「兆候ログ」を生成する。「兆候ログ」は、兆候監視部３７３がＮＧと判定したことを示す識別子であるログ種別識別子と、兆候監視部３７３がＮＧと判定した理由を示す識別子である兆候ログ識別子と、兆候監視部３７３がＮＧと判定した値と、さらに、必要に応じて、受信したメッセージのＩＤとを含む。
【０１１２】
また、図９の３行目の、ＭＡＣ検証部３７１の判定結果がＯＫであり、振る舞い検知部３７２の判定結果がＮＧであり、兆候監視部３７３の判定結果がＯＫの場合、ログに出力する情報として「振る舞いログ」を生成する。「振る舞いログ」は、振る舞い検知部３７２がＮＧと判定したことを示す識別子であるログ種別識別子と、振る舞い検知部３７２がＮＧと判定した理由を示す識別子である振る舞いログ識別子と、振る舞い検知部３７２がＮＧと判定した値と、振る舞い検知部３７２がＮＧと判定した値の過去に受信したメッセージの該当する値と、さらに、必要に応じて、受信したメッセージのＩＤとを含む。
【０１１３】
振る舞い検知部３７２がＮＧと判定した値の過去に受信したメッセージの該当する値としては、同じＩＤを持つメッセージの一つ前に受信したメッセージの該当する値でもよいし、あらかじめ決められた時間又はあらかじめ決められたメッセージ数だけ前のメッセージから直前に受信したメッセージまでの複数の値でもよい。ログ出力制御部３７６は、ログ関連情報保持部３７７から過去に受信したメッセージに関連する情報を取得し、振る舞いログを生成する。
【０１１４】
また、図９の４行目の、ＭＡＣ検証部３７１の判定結果がＯＫであり、振る舞い検知部３７２の判定結果がＮＧであり、兆候監視部３７３の判定結果がＮＧの場合、振る舞い検知部３７２のＮＧと判定した理由と、兆候監視部３７３のＮＧと判定した理由が同じであるか、異なるかによって、生成するログが異なるものになる。
【０１１５】
例えば、振る舞い検知部３７２がＮＧと判定した理由と、兆候監視部３７３がＮＧと判定した理由が同じ場合は、ログ出力制御部３７６は、振る舞いログと、兆候監視部３７３がＮＧと判定したことを示す識別子であるログ種別識別子と、兆候ログ識別子とを含むログ情報を生成する。
【０１１６】
また、振る舞い検知部３７２が受信したメッセージをＮＧと判定した理由と、兆候監視部３７３が受信したメッセージをＮＧと判定した理由が異なる場合は、振る舞いログと、兆候ログとを含むログ情報を生成する。
【０１１７】
すなわち、特定理由が同じ場合、振る舞い検知部３７２がＮＧと判定した値と、兆候監視部３７３がＮＧと判定した値とのうち、一方のみがログとして出力される。上記では、振る舞い検知部３７２がＮＧと判定した値のみが出力されているが、兆候監視部３７３がＮＧと判定した値のみが出力されてもよい。受信したメッセージがＮＧと判定された判定理由が異なる場合、これらの両方の値が出力される。
【０１１８】
また、図９の５行目の、ＭＡＣ検証部３７１の判定結果がＮＧであり、振る舞い検知部３７２の判定結果がＯＫであり、兆候監視部３７３の判定結果がＯＫの場合、「全フィールドログ」を生成する。「全フィールドログ」は、ＭＡＣ検証部３７１がＮＧと判定したことを示す識別子であるログ種別識別子と、受信したメッセージ全体を含む。
【０１１９】
また、図９の６、７、８行目の、ＭＡＣ検証部３７１の判定結果がＮＧであり、と、振る舞い検知部３７２の判定結果と、兆候監視部３７３の判定結果が、図９の５行目以外の組み合わせに関しては、上記ログ及び識別子の組み合わせになる。
【０１２０】
以上のように、受信したメッセージに対する複数の判定処理の結果の組み合わせに従って、出力される情報に重複が発生しないように、ログに含まれる情報が決定される。
【０１２１】
なお、図９の７、８行目のログのうち、振る舞いログは、振る舞い検知部３７２がＮＧと判定したことを示す識別子であるログ種別識別子と、振る舞い検知部３７２がＮＧと判定した理由を示す識別子である振る舞いログ識別子と、振る舞い検知部３７２がＮＧと判定した値の過去に受信したメッセージの該当する値とを含む。振る舞いログは、振る舞い検知部３７２がＮＧと判定した値と、受信したメッセージのＩＤとを含む必要は無い。
【０１２２】
振る舞いログと兆候ログは、ログ種別識別子と、振る舞いログ識別子及び兆候ログ識別子と、振る舞い検知部３７２及び兆候監視部３７３がＮＧと判定した値と、さらに、必要に応じて、受信したメッセージのＩＤとを含む。
【０１２３】
ここで、振る舞いログ識別子及び兆候ログ識別子と、振る舞い検知部３７２及び兆候監視部３７３がＮＧと判定した値について説明する。図１０は、本実施の形態におけるログに含まれるＮＧと判定した値の一例を示す図である。図１０に示すように、振る舞い検知部３７２又は兆候監視部３７３の内部でＮＧと判定した判定機能に応じて、ログとして生成する値が変更される。例えば、ＩＤ判定機能がＮＧと判定した場合は、ＮＧと判定した値はログに含まれない。ログ出力制御部３７６は、ログ種別識別子と、振る舞いログ識別子又は兆候ログ識別子と、受信したメッセージのＩＤとを含むログを生成する。
【０１２４】
また、データ長判定機能がＮＧと判定した場合は、ＮＧと判定した値として、受信したメッセージに含まれるＤＬＣの値を設定する。
【０１２５】
また、送信周期判定機能がＮＧと判定した場合は、ＮＧと判定した値として、１つ前に受信した同じＩＤを持つメッセージの受信時刻からの時間差である受信時刻差を設定する。
【０１２６】
また、送信頻度判定機能がＮＧと判定した場合は、ＮＧと判定した値として、メッセージの受信頻度を設定する。この時、受信したメッセージに含まれるＩＤの値に関係なく、全受信メッセージを対象に送信頻度を判定した際にＮＧと判定した場合は、ログに受信したメッセージのＩＤを含まない。一方、ＩＤごとに送信頻度を判定した際にＮＧと判定した場合は、ログに受信したメッセージのＩＤを含めてもよい。
【０１２７】
また、データ値判定機能がＮＧと判定した場合は、ＮＧと判定した値として、受信したメッセージに含まれるデータのうちＮＧと判定したデータの位置を示す識別子であるデータ識別子と、判定対象のデータ値である対象データ値を、ログとして設定する。
【０１２８】
データ識別子としては、例えば０ｂｉｔ目から３ｂｉｔ目のデータをデータ識別子「１」、４ｂｉｔ目のデータをデータ識別子「２」、５ｂｉｔ目から６ｂｉｔ目のデータをデータ識別子「３」とするというような対応表をＩＤごとに作成してもよい。また、０ｂｉｔ目から３ｂｉｔ目のデータをデータ識別子「（０，３）」と表すことでＩＤによらずデータの位置を示してもよい。また、０ｂｉｔ目から３ｂｉｔ目のデータをサイズ（４ｂｉｔ）を用いて、データ識別子「（０，４）」と表してもよい。
【０１２９】
データ識別子は、ＣＡＮプロトコルのメッセージのフォーマットにおけるデータフィールド内のどの位置のデータであるかを示すことが出来ればよい。そのため、上記以外のデータ識別子を用いてもよい。
【０１３０】
また、車両状態判定機能がＮＧと判定した場合は、ＮＧと判定した値として、その時の車両状態を表す車両状態識別子と、その状態へ遷移した要因となった情報である要因情報とを設定する。受信したメッセージにより車両状態が変化し、車両状態判定機能がＮＧと判定した場合は、受信したメッセージのＩＤとをログに含む。一方で、受信したメッセージによらず車両状態が変化した場合は、受信したメッセージのＩＤをログに含まない。ここで、要因情報としては、ＩＤ、送信周期、送信頻度、データ値、又はデータ値の変化量など状態が遷移した要因がどの情報によるものなのかを示す識別子である要因識別子と、その値を含む。
【０１３１】
ログ種別識別子は、ＭＡＣ検証部３７１と、振る舞い検知部３７２と、兆候監視部３７３のどれがＮＧと判定したかを示す識別子である。振る舞い検知部３７２がＮＧと判定した理由を示す識別子である振る舞いログ識別子及び兆候監視部３７３がＮＧと判定した理由を示す識別子である兆候ログ識別子は、ＩＤ判定機能又はデータ長判定機能、送信周期判定機能、送信頻度判定機能、データ値判定機能及び車両状態判定機能の各機能でＮＧと判定したときの理由を示す。
【０１３２】
例えば、本来送信されるべきではないＩＤのメッセージを受信したことを示したり、受信したメッセージの送信周期がルールに記載されている値より小さかったことを示したり、受信したメッセージのペイロードに含まれるデータの値がルールに記載されている値と異なることを示したり、データの値の前回受信時からの変化量がルールに記載されている値と異なることを示す。
【０１３３】
また、ログ出力制御部３７６は、振る舞い検知部３７２と兆候監視部３７３に含まれるＩＤ判定機能、データ長判定機能、送信周期判定機能、送信頻度判定機能、データ値判定機能及び車両状態判定機能の各機能において、１つの受信したメッセージに対して、複数の機能がＮＧと判定した場合又は、ある機能において複数の理由によりＮＧと判定した場合には、複数のログを出力してもよい。また、事前に決められた優先度に応じて、優先度の一番高いメッセージのみをログとして出力してもよい。
【０１３４】
また、ログ出力制御部３７６は、受信したメッセージに関連した情報をログ関連情報保持部３７７へ通知し、情報の保持を依頼する。メッセージに関連した情報としては、受信したメッセージ又は、受信したメッセージの受信時刻、ログ出力制御部３７６が出力するログ、ログを生成するために必要な情報等を含む。ログ出力制御部３７６は、ログを生成する際に、必要に応じて、ログ関連情報保持部３７７から受信したメッセージに関連した情報を取得する。
【０１３５】
ログ関連情報保持部３７７は、ログ出力制御部３７６から保持の依頼を受けた、受信したメッセージに関連した情報を保持する。また、ログ関連情報保持部３７７は、ログ出力制御部３７６からの受信したメッセージに関連した情報の取得依頼に応じて、保持している情報をログ出力制御部３７６へ通知する。
【０１３６】
なお、ログ出力制御部３７６は、生成するログに、受信したメッセージの受信時刻を含めてもよい。
【０１３７】
［１．８  ＥＣＵの構成］
図１１は、本実施の形態における車載ネットワークシステムに含まれるＥＣＵの一例を示すブロック図である。図１１において、ＥＣＵ１００は、フレーム送受信部１１０と、フレーム解釈部１２０と、受信ＩＤ判定部１３０と、受信ＩＤリスト保持部１４０と、フレーム処理部１５０と、データ取得部１７０と、フレーム生成部１８０とを備える。
【０１３８】
なお、これらの構成は機能を示す構成であり、ＥＣＵ１００は、例えばプロセッサで実現される処理部、半導体メモリ等で実現される記憶部、入出力ポート等で実現される入出力部等を備える情報処理装置として提供される。
【０１３９】
上記の機能を示す構成は、記憶部に保持されるプログラムを処理部により読み出し、実行し、記憶部へ所定のデータを記録することで実現される。若しくは記憶部へ所定のデータを記録することの代わりに、入出力部を介してデータの送受信を実行することで、これらの構成が実現されてもよい。又、これらの構成は、上記の組み合わせで実現されてもよい。
【０１４０】
フレーム送受信部１１０は、バス２００を介して、ＣＡＮのプロトコルに従ったメッセージを送受信する。
【０１４１】
より具体的には、フレーム送受信部１１０は、バス２００に送出されたメッセージを１ｂｉｔずつ読み出し、読み出したメッセージをフレーム解釈部１２０に転送する。
【０１４２】
また、フレーム送受信部１１０は、フレーム生成部１８０より通知を受けたメッセージをバス２００に送出する。
【０１４３】
フレーム解釈部１２０は、フレーム送受信部１１０よりメッセージの値を受け取り、ＣＡＮプロトコルにおける各フィールドにマッピングするようにしてメッセージの解釈を行う。フレーム解釈部１２０は、ＩＤフィールドであると解釈した一連の値を、受信ＩＤ判定部１３０へ転送する。
【０１４４】
フレーム解釈部１２０はさらに、受信ＩＤ判定部１３０から通知される判定結果に応じて、メッセージのＩＤフィールドの値、及び、ＩＤフィールド以降に現れるデータフィールドを、フレーム処理部１５０へ転送するか、メッセージの受信を中止するかを決定する。
【０１４５】
また、フレーム解釈部１２０は、受信したメッセージがＣＡＮプロトコルに則っていないメッセージであると判断した場合は、エラーフレームを送信するようにフレーム生成部１８０に要求する。
【０１４６】
また、フレーム解釈部１２０は、他のノードが送信したエラーフレームを受信したと解釈した場合、読取中のメッセージを破棄する。
【０１４７】
受信ＩＤ判定部１３０は、フレーム解釈部１２０からＩＤフィールドの値を受け取り、受信ＩＤリスト保持部１４０が保持しているメッセージＩＤのリストに従い、読み出したメッセージを受信するか否かの判定を行う。受信ＩＤ判定部１３０は、この判定の結果をフレーム解釈部１２０へ通知する。
【０１４８】
受信ＩＤリスト保持部１４０は、ＥＣＵ１００が受信する受信ＩＤリストを保持する。受信ＩＤリストは、図４と同様の形式であるため、ここではその説明を省略する。
【０１４９】
フレーム処理部１５０は、受信したメッセージのデータに応じた処理を行う。処理の内容は、ＥＣＵ１００ごとに異なる。
【０１５０】
例えば、ＥＣＵ１００ａでは、自動車の時速が３０ｋｍを超えているときに、ドアが開いていることを示すメッセージを受信すると、アラーム音を鳴らすための処理を実行する。ＥＣＵ１００ｃは、ブレーキがかかっていないことを示すメッセージを受信しているときにドアが開くと、アラーム音を鳴らすための処理を実行する。
【０１５１】
これらの処理は、説明のために一例として挙げているだけであり、ＥＣＵ１００は上記以外の処理を実行してもよい。このような処理を実行するためにフレーム処理部１５０が送出するフレームを、フレーム処理部１５０はフレーム生成部１８０に生成させる。
【０１５２】
データ取得部１７０は、ＥＣＵ１００に接続されている機器の状態、又は、センサによる計測値等を示す出力データを取得し、出力データをフレーム生成部１８０に転送する。
【０１５３】
フレーム生成部１８０は、フレーム解釈部１２０からのエラーフレーム送信の要求に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部１１０へ送る。
【０１５４】
またフレーム生成部１８０は、データ取得部１７０から受け取ったデータの値に対して予め定められたメッセージＩＤを付けてメッセージフレームを構成し、メッセージフレームをフレーム送受信部１１０へ送る。
【０１５５】
［１．９  サーバの構成］
図１２は、本実施の形態における車載ネットワークシステムに含まれるサーバの一例を示すブロック図である。図１２において、サーバ５００は、受信部５１０と、ログ保持部５２０と、解析部５３０とから構成される。
【０１５６】
受信部５１０は、ゲートウェイ３００の外部通信部３９０を通して、ログ出力制御部３７６より、ログを受信する。また、受信部５１０は、ログ保持部５２０へ受信したログの保持を依頼する。
【０１５７】
ログ保持部５２０は、受信部５１０からの依頼に応じて、ログを保持する。また、ログ保持部５２０は、解析部５３０からの依頼に応じて保持しているログを送信する。
【０１５８】
解析部５３０は、ログ保持部５２０からログを取得し、そのログを解析することで、車両で異常が発生しているかどうかの解析を行う。
【０１５９】
なお、ログ保持部５２０は、ログを保持する際に、車両ごとにログを別々に保持してもよいし、車両ごとのログを統合して保持してもよいし、車両ごとのログと車両ごとのログを統合したログの両方を保持していてもよい。車両ごとのログを統合する時には、全てのログを統合してもよいし、各車両の製造メーカ又は車種、型式、グレードごとに統合してもよいし、車両の大きさ又は車両の排気量等で決まる各車両の車両クラスごとに統合してもよい。また、車両ごとのログを統合する時には、車両ごとのログを各車両の所在地ごとに統合してもよいし、各車両が持つ機能（自動運転機能、運転支援機能、通信機能等）ごとに統合してもよい。なお、車両ごとのログを統合する方法は、上に挙げた方法の組み合わせでもよい。
【０１６０】
なお、サーバ５００は、受信したログ又は、解析部５３０の解析結果を表示するための表示部（図示せず）を備えてもよい。
【０１６１】
［１．１０  異常検知処理］
図１３は、本実施の形態における異常検知処理の一例を示すフローチャートである。
【０１６２】
まず、異常検知処理機能群３７０は、フレーム処理部３５０からメッセージを受信する（ステップＳ１００１）。
【０１６３】
異常検知処理機能群３７０のＭＡＣ検証部３７１と、振る舞い検知部３７２と、兆候監視部３７３は、フレーム処理部３５０から受け取ったメッセージに対して、それぞれ判定を行う（Ｓ１００２）。
【０１６４】
ログ出力制御部３７６は、ＭＡＣ検証部３７１と、振る舞い検知部３７２と、兆候監視部３７３で判定した結果に、ＮＧの判定が含まれるか否かを確認する（Ｓ１００３）。
【０１６５】
全ての判定結果がＯＫだった場合（ステップＳ１００３でＮｏの場合）には、処理を終了する。
【０１６６】
ＭＡＣ検証部３７１と、振る舞い検知部３７２と、兆候監視部３７３で判定した結果に、ＮＧが含まれる場合（ステップＳ１００３でＹｅｓの場合）、ログ出力制御部３７６はログを生成する（ステップＳ１００４）。
【０１６７】
ログ出力制御部３７６は、生成したログを、外部通信部３９０を介して、サーバへ送信する（Ｓ１００５）。ここで、ログ出力制御部３７６は、処理を終了する。
【０１６８】
［１．１１  転送処理］
図１４は、本実施の形態における転送処理の一例を示すフローチャートである。ゲートウェイ３００が行う転送処理は、転送の方向によらず実質的に共通であるため、ゲートウェイ３００がバス２００ａから受信したメッセージをバス２００ｂへ転送する場合を例に説明する。
【０１６９】
まず、フレーム送受信部３１０は、バス２００ａからメッセージを読み出す（ステップＳ１１０１）。その後、フレーム送受信部３１０は、読み出したメッセージの各フィールドのデータをフレーム解釈部３２０へ通知する。
【０１７０】
次に、フレーム解釈部３２０は、受信ＩＤ判定部３３０と連携して、読み出したメッセージのＩＤフィールドの値（メッセージＩＤ）から、受信して処理する対象のメッセージであるか否かを判定する（ステップＳ１１０２）。
【０１７１】
フレーム解釈部３２０が処理する対象のメッセージではないと判定した場合（ステップＳ１１０２でＮｏ）、当該メッセージの転送は行われない。
【０１７２】
フレーム解釈部３２０は、受信したメッセージが、受信して処理する対象のメッセージであると判断した場合には（ステップＳ１１０２でＹｅｓの場合）、フレーム処理部３５０へメッセージ内の各フィールドの値を転送する。
【０１７３】
その後、フレーム処理部３５０は、転送ルール保持部３６０に保持される転送ルールに従って、転送先のバスを決定する（ステップＳ１１０３）。
【０１７４】
フレーム処理部３５０は、フレーム解釈部３２０から受け取ったメッセージ内の各フィールドの値を異常検知処理機能群３７０へ通知し、異常なメッセージであるか否かの判定を要求する。異常検知処理機能群３７０は、通知されたメッセージの各フィールドの値から、通知されたメッセージが異常なメッセージであるか否かを判定し、その判定の結果をフレーム処理部３５０へ通知する（ステップＳ１１０４）。
【０１７５】
異常検知処理機能群３７０が、メッセージは異常なメッセージであると判定した場合（ステップＳ１１０５でＹｅｓの場合）、そのメッセージの転送は行われない。
【０１７６】
異常検知処理機能群３７０が、メッセージは異常なメッセージではなく正常なメッセージであると判定した場合（ステップＳ１１０５でＮｏの場合）、フレーム処理部３５０は、そのメッセージをステップＳ１１０３で決定した転送先のバスに、転送するようフレーム生成部３８０へ要求する。
【０１７７】
フレーム生成部３８０は、フレーム処理部３５０からの要求を受けて、指定された転送先が受信するようメッセージを生成し、このメッセージをフレーム送受信部３１０に送出させる（ステップＳ１１０６）。
【０１７８】
なお、上記の例では、受信したメッセージの転送先の決定（ステップＳ１１０３）の後にこのメッセージが異常なメッセージであるかの判定（ステップＳ１１０４）がなされているが、これに限定されない。受信したメッセージが異常なメッセージであるかの判定の後にこのメッセージの転送先の決定がなされてもよい。また、受信したメッセージの転送先の決定と異常なメッセージであるかの判定が並行して行われてもよい。
【０１７９】
［１．１２  効果］
本実施の形態では、異常検知処理機能群３７０は、車載ネットワークシステムのネットワークを流れるメッセージを監視する。異常検知処理機能群３７０が異常を検知した場合、ログ出力処理機能群３７５によりログを生成し、サーバ５００へ出力する。サーバ５００は、ログを蓄積し、このログを解析することで、異常検知処理機能群３７０で検知できなかった異常を検知することができる。これにより従来の不正検知の技術で用いられていたような、例えば所定の周期より短い時間間隔でメッセージを受信したときに、不正が発生したと判断する技術では、正常なメッセージであるか異常なメッセージであるかの判定が困難であったメッセージに関しても、多くのログからより高い精度でメッセージが異常であるか否かを判定することが可能になる。その結果、車載ネットワークシステムの安全性が高められる。
【０１８０】
［２．その他の変形例］
本開示は、上記で説明した各実施の形態に限定されないのはもちろんであり、本開示の趣旨を逸脱しない限り、当業者が思いつく各種変形を実施の形態に施したもの、及び異なる実施の形態における構成要素を組み合わせて構築される形態も、本開示の範囲内に含まれる。例えば以下のような変形例も本開示に含まれる。
【０１８１】
（１）上記の実施の形態では、異常検知処理機能群３７０は、ＭＡＣ検証部３７１と、振る舞い検知部３７２と、兆候監視部３７３とを備えるとしたが、これに限定するものではない。例えば、異常検知処理機能群３７０は、ＭＡＣ検証部３７１と、振る舞い検知部３７２とを備えてもよいし、ＭＡＣ検証部３７１と、兆候監視部３７３とを備えてもよいし、振る舞い検知部３７２と、兆候監視部３７３とを備えてもよい。また、異常検知処理機能群３７０は、ＭＡＣ検証部３７１だけを備えてもよいし、振る舞い検知部３７２だけを備えてもよいし、兆候監視部３７３だけを備えてもよい。
【０１８２】
上記のそれぞれの場合において、ログ出力制御部３７６における判定例としては、例えば、図９において、ＭＡＣ検証部３７１と、振る舞い検知部３７２と、兆候監視部３７３とのうち、存在しない部の結果をＯＫとした場合のログを出力してもよい。
【０１８３】
つまり、異常検知処理機能群３７０が、ＭＡＣ検証部３７１と、振る舞い検知部３７２とを備える場合、図９の「兆候監視」の列がＯＫの行で、「ＭＡＣ検証」と「振る舞い検知」の列が、それぞれの判定結果にあった行のログを出力する。
【０１８４】
（２）上記の実施の形態では、ゲートウェイ３００は、フレーム送受信部３１０と、フレーム解釈部３２０と、受信ＩＤ判定部３３０と、受信ＩＤリスト保持部３４０と、フレーム処理部３５０と、転送ルール保持部３６０と、異常検知処理機能群３７０と、ログ出力処理機能群３７５と、フレーム生成部３８０と、外部通信部３９０とを備えると説明したが、これに限定されない。
【０１８５】
図１５は、変形例におけるゲートウェイの一例を示すブロック図である。図１５に示すように、ゲートウェイ３００ａは、フレーム送受信部３１０と、フレーム解釈部３２０と、受信ＩＤ判定部３３０と、受信ＩＤリスト保持部３４０と、フレーム処理部３５０と、転送ルール保持部３６０と、異常検知処理機能群３７０と、ログ出力処理機能群３７５ａと、フレーム生成部３８０とを備える。
【０１８６】
図１６は、変形例におけるログ出力処理機能群の一例を示すブロック図である。図１６において、ログ出力処理機能群３７５ａは、ログ出力制御部３７６ａと、ログ関連情報保持部３７７と、ログ保持部３７８とを備える。
【０１８７】
実施の形態１のログ出力制御部３７６が、外部通信部３９０を介して、サーバ５００へログを出力するのに対して、ログ出力制御部３７６ａは、ログ保持部３７８へログを出力する。
【０１８８】
ログ保持部３７８は、ログ出力制御部３７６ａからログを受信し、保持する。
【０１８９】
また、ログ保持部３７８は、ゲートウェイ３００ａの外部に接続された機器（図示せず）より、ログ取得の依頼があった際に、保持しているログを出力する。
【０１９０】
なお、上記の実施の形態におけるゲートウェイ３００が、ログ出力処理機能群３７５の代わりにログ出力処理機能群３７５ａを備え、ゲートウェイ３００ａ外部の機器からの要求に応じて、外部通信部３９０を介して、ログ保持部３７８が保持しているログを出力してもよい。
【０１９１】
また、ログ出力処理機能群３７５ａは、バス２００に接続された別の機器から、バス２００を介して、ログの取得依頼を受信し、バス２００を介してログを出力してもよい。図１７は、変形例におけるゲートウェイ３００ｂの一例を示すブロック図である。図１７に示すように、ログ出力処理機能群３７５ｂは、フレーム処理部３５０を介してログをバス２００へ出力する。
【０１９２】
これにより、ゲートウェイ３００ｂ内部にログを保持できる。そのため、サーバ５００と常時接続できる機能が無い場合においても、ログを収集・保持し、必要に応じてゲートウェイ３００ｂ外部の機器へログを出力できるため、ログ出力タイミングを柔軟に選択すること又は、通信コストを抑えることが出来る。
【０１９３】
（３）上記実施の形態では、ＥＣＵ１００は、フレーム送受信部１１０と、フレーム解釈部１２０と、受信ＩＤ判定部１３０と、受信ＩＤリスト保持部１４０と、フレーム処理部１５０と、データ取得部１７０と、フレーム生成部１８０とを備えると説明したが、本開示における車載ネットワークシステムが備えるＥＣＵ１００の構成はこれに限定されるものではない。
【０１９４】
図１８は、変形例におけるＥＣＵの一例を示すブロック図である。図１８においてＥＣＵ１００ｅは、ＥＣＵ１００に対して、さらに異常検知処理機能群３７０と、ログ出力処理機能群３７５ａとを備える。ＥＣＵ１００ｅにおいて、異常なメッセージであるか否かの判定を、フレーム処理部１５０が異常検知処理機能群３７０へ要求してもよいし、フレーム解釈部１２０が異常検知処理機能群３７０へ要求してもよい。
【０１９５】
図１９は、変形例におけるＥＣＵの一例を示すブロック図である。図１９において、ＥＣＵ１００ｆは、フレーム送受信部１１０と、フレーム解釈部１２０と、フレーム生成部１８０と、異常検知処理機能群３７０と、ログ出力処理機能群３７５ａとで構成される。フレーム解釈部１２０は、例えばＩＤによらず全てのメッセージを受信し、全てのメッセージについて異常検知処理機能群３７０へ異常なメッセージであるかどうかの判定を依頼してもよい。
【０１９６】
また、ＥＣＵ１００ｆは、図１９の構成に加えて、受信ＩＤ判定部１３０と、受信ＩＤリスト保持部１４０とを備え、受信ＩＤリスト保持部が保持する受信ＩＤリストに記載されたメッセージＩＤを持つメッセージのみを受信してもよい。また、そのメッセージに関して、異常検知処理機能群３７０へ異常なメッセージであるか否かの判定を依頼してもよい。
【０１９７】
なお、ログ出力処理機能群３７５ａは、上述のログ出力処理機能群３７５に代えられてもよい。また、ＥＣＵ１００ｅ又はＥＣＵ１００ｆは、ログ出力処理機能群３７５ａとして、更に、外部通信部３９０を備えてもよい。
【０１９８】
これにより、ゲートウェイだけでなく、ＥＣＵでも、バスに送信されているメッセージが異常なメッセージであるか否かを解析するためのログを出力できる。その結果、例えば車載ネットワークシステムにおける異常検知のための仕組の冗長性が向上し、より安全性が確保される。
【０１９９】
図２０は、変形例におけるＥＣＵの一例を示すブロック図である。図２０に示すＥＣＵ１００ｇは、バス２００へ送信するデータを他の接続機器又は外部の機器等から取得する送信データ取得部１７１と、異常検知処理機能群３７０ｇと、ログ出力処理機能群３７５ａとを備えてもよい。ＥＣＵ１００ｇが備える異常検知処理機能群３７０ｇは、送信データ取得部１７１から受信したデータが異常なメッセージであるか否かについても判定してもよい。また、異常なメッセージではないと判定した場合のみ、フレーム生成部１８０へメッセージの送信を依頼してもよい。
【０２００】
なお、ログ出力処理機能群３７５ａの構成は、ログ出力処理機能群３７５に代えられ、ＥＵＣ１００ｇに、更に、外部通信部３９０を備えてもよい。
【０２０１】
これにより、例えば、何者かに不正に制御されたカーナビゲーションから異常なメッセージが車載ネットワークシステム等に向けて送信されるような場合において、カーナビゲーションと一緒に利用されるＥＣＵ１００ｇがサーバ５００でログを解析することによって、異常なメッセージの車載ネットワークシステム内での拡散を抑制することができる。また、車載ネットワークシステム内部への異常なメッセージの車両外からの送信を抑制することができる。
【０２０２】
（４）上記の実施の形態では、ゲートウェイ３００は、フレーム送受信部３１０と、フレーム解釈部３２０と、受信ＩＤ判定部３３０と、受信ＩＤリスト保持部３４０と、フレーム処理部３５０と、転送ルール保持部３６０と、異常検知処理機能群３７０と、ログ出力処理機能群３７５と、フレーム生成部３８０と、外部通信部３９０とを備えるとしたが、これに限定されない。
【０２０３】
図２１は、変形例におけるゲートウェイの一例を示すブロック図である。図２１に示すように、ゲートウェイ３００ｃは、フレーム送受信部３１０と、フレーム解釈部３２０と、受信ＩＤ判定部３３０と、受信ＩＤリスト保持部３４０と、フレーム処理部３５０と、転送ルール保持部３６０と、異常検知処理機能群３７０と、ログ出力処理機能群３７５と、フレーム生成部３８０とを備える。
【０２０４】
ログ出力処理機能群３７５は、外部通信部３９０を介してサーバ５００へログを出力するのではなく、バス２００を介してＥＣＵ１００ｈへログを出力するため、フレーム処理部３５０へログ情報の送信を依頼する。
【０２０５】
図２２は、変形例におけるＥＣＵの一例を示すブロック図である。図２２において、ＥＣＵ１００ｈは、ＥＣＵ１００の構成に加え、ログ保持部１９０を備え、フレーム処理部１５０の代わりにフレーム処理部１５０ｈを備える。
【０２０６】
フレーム処理部１５０ｈは、受信したメッセージがログであった場合に、ログ保持部１９０へ通知し、ログの保持を依頼する。また、フレーム処理部１５０ｈは、受信したメッセージがログであるかどうかを、受信したメッセージのＩＤを用いて判定する。受信したメッセージのＩＤが、事前に決められたログを示すＩＤの場合、フレーム処理部１５０ｈは、受信したメッセージがログであると判定し、ログ保持部１９０へ受信したメッセージがログであった旨を通知する。
【０２０７】
なお、ＥＣＵ１００ｅ又はＥＣＵ１００ｆ、ＥＣＵ１００ｇに、ログ出力処理機能群３７５を備え、ログ出力処理機能群３７５がフレーム処理部１５０へログの送信を依頼してもよい。
【０２０８】
（５）上記実施の形態では、ゲートウェイ３００ｃ又はＥＣＵ１００ｈがサーバ５００へログを出力する場合と、ゲートウェイ３００ｃ又はＥＣＵ１００ｈがログをゲートウェイ３００ｃ又はＥＣＵ１００ｈの内部に保持しつつ、要求に応じてログを出力する場合と、ゲートウェイ３００ｃ又はＥＣＵ１００ｈが他のＥＣＵ１００ｈへログを出力する場合だけに限定されない。
【０２０９】
例えば、ゲートウェイ３００ｃ又はＥＣＵ１００ｈがログをゲートウェイ３００ｃ又はＥＣＵ１００ｈ内部に保持しつつ、サーバ５００へログを出力してもよい。また、ゲートウェイ３００ｃ又はＥＣＵ１００ｈがログをゲートウェイ３００ｃ又はＥＣＵ１００ｈ内部に保持しつつ、他のＥＣＵ１００ｈへログを出力してもよい。また、ゲートウェイ３００ｃ又はＥＣＵ１００ｈがサーバ５００へログを出力しつつ、他のＥＣＵ１００ｈへログを出力してもよい。また、ゲートウェイ３００ｃ又はＥＣＵ１００ｈがログをゲートウェイ３００ｃ又はＥＣＵ１００ｈ内部に保持しつつ、サーバ５００と他のＥＣＵ１００ｈへログを出力してもよい。
【０２１０】
それぞれの場合において、同じログを出力してもよいし、出力先ごとにログを変えてもよい。例えば、ゲートウェイ３００ｃ又はＥＣＵ１００ｈ内部にログを保持出来る量が少なく、他のＥＣＵ１００ｈ又はサーバ５００に大量にログを保持できる場合は、ゲートウェイ３００ｃ又はＥＣＵ１００ｈ内部には識別子に関する情報のみを保持しておき、他のＥＣＵ１００ｈ又はサーバ５００にＮＧと判定した値又は、ＣＡＮメッセージの全フィールドのログを保持してもよい。また、ゲートウェイ３００ｃ又はＥＣＵ１００ｈ内部には、ログを特定できる情報を保持しておき、ログを、ログを特定できる情報と一緒に他のＥＣＵ１００ｈ又はサーバ５００へ保持してもよい。また、全ての受信したメッセージを、異常検知処理機能群３７０の検知結果に関係なく、他のＥＣＵ１００ｈへログとして出力してもよい。
【０２１１】
また、ログ出力制御部３７６は、ＭＡＣ検証部３７１、振る舞い検知部３７２、兆候監視部３７３のそれぞれの判定結果から、ログを出力する対象を決定してもよい。
【０２１２】
例えば、ＭＡＣ検証部３７１がＮＧと判定した場合には、サーバ５００へ、ＭＡＣ検証部３７１がＮＧと判定した旨を通知し、他のＥＣＵ１００ｈへ「全フィールドログ」を出力してもよい。また、振る舞い検知部３７２がＮＧと判定した場合には、「振る舞いログ」を他のＥＵＣ１００へ出力してもよいし、「振る舞いログ」に含まれるログ種別識別子、振る舞いログ識別子をゲートウェイ３００ｃ又はＥＣＵ１００ｈ内部に保持しつつ、「振る舞いログ」を他のＥＵＣ１００ｈへ出力してもよい。加えて、「振る舞いログ」に含まれるログ種別識別子、振る舞いログ識別子をゲートウェイ３００ｃ又はＥＣＵ１００ｈ内部に保持しつつ、「振る舞いログ」をサーバ５００へ出力し、「振る舞いログ」に受信したメッセージの全フィールドを加えたログを他のＥＣＵ１００ｈへ出力してもよい。
【０２１３】
また、兆候監視部３７３がＮＧと判定した場合には、「兆候ログ」を他のＥＣＵ１００ｈへ出力してもよいし、「兆候ログ」に含まれるログ種別識別子、兆候ログ識別子をゲートウェイ３００ｃ又はＥＣＵ１００ｈ内部に保持しつつ、「兆候ログ」を他のＥＣＵ１００ｈへ出力してもよい。加えて、「兆候ログ」に含まれるログ種別識別子、兆候ログ識別子をゲートウェイ３００ｃ又はＥＣＵ１００ｈ内部に保持しつつ、「兆候ログ」をサーバ５００へ出力し、「兆候ログ」に受信したメッセージの全フィールドを加えたログを他のＥＣＵ１００ｈへ出力してもよい。
【０２１４】
なお、個別にログ出力のパターンは、上記のパターンに限定するものではなく、上記のパターンの組み合わせでもよい。
【０２１５】
（６）上記実施の形態では、異常の検知に応じたアクションとして、受信したメッセージを転送しない例を示したが、これに限定されない。例えば、上述の異常検知処理機能群３７０を備えるゲートウェイ３００ｃ又はＥＣＵ１００ｈは、メッセージの受信中に異常検知処理を行い、異常なメッセージであると判定した時点で、エラーフレームを送信することで、ネットワークから受信中のメッセージを無効化してもよい。
【０２１６】
これにより、異常なメッセージが見つかったバスに接続された他のＥＣＵ１００ｈが異常なメッセージを受信することを防止することができる。これは、転送しないメッセージに対しても適用できる。
【０２１７】
また、上述の異常検知処理機能群３７０を備えるゲートウェイ３００ｃ又はＥＣＵ１００ｈは、さらに、異常の発生に関するユーザ若しくは外部のサーバ等への通知、異常の発生のログへの記録、又は車両のフェールセーフモードへの移行を実行してもよい。
【０２１８】
これにより、異常検知後の柔軟な対応が可能となる。また異常なメッセージと判定した複数のメッセージをデータの１以上の系列として扱い、各系列について、データの値又は受信間隔の集合を異常なラベルとして学習してもよい。
【０２１９】
（７）上記実施の形態では、標準フォーマットのＩＤにおける例を示したが、拡張フォーマットのＩＤであってもよい。
【０２２０】
（８）上記実施の形態では、メッセージは平文で送信される例を示したが、暗号化されていてもよい。またメッセージにメッセージ認証コードを含んでいてもよい。
【０２２１】
（９）上記実施の形態では、正常モデルと、受信ログとを平文で保持している例を示したが、正常モデルと受信ログとを暗号化して保持していてもよい。
【０２２２】
（１０）上記の実施の形態では、ＣＡＮプロトコルに従って通信するネットワーク通信システムの例として車載ネットワークを示した。本開示に係る技術は、車載ネットワークでの利用に限定されるものではなく、ロボット、産業機器等のネットワークその他、車載ネットワーク以外のＣＡＮプロトコルに従って通信するネットワーク通信システム等に利用してもよい。
【０２２３】
また、車載ネットワークとしてＣＡＮプロトコルを用いていたが、これに限るものではない。例えば、ＣＡＮ−ＦＤ（ＣＡＮ  ｗｉｔｈ  Ｆｌｅｘｉｂｌｅ  Ｄａｔａ  Ｒａｔｅ）、ＦｌｅｘＲａｙ、Ｅｔｈｅｒｎｅｔ、ＬＩＮ（Ｌｏｃａｌ  Ｉｎｔｅｒｃｏｎｎｅｃｔ  Ｎｅｔｗｏｒｋ）、ＭＯＳＴ（Ｍｅｄｉａ  Ｏｒｉｅｎｔｅｄ  Ｓｙｓｔｅｍｓ  Ｔｒａｎｓｐｏｒｔ）などを用いてもよい。あるいはこれらのネットワークをサブネットワークとして、組み合わせたネットワークであってもよい。
【０２２４】
（１１）上記の実施の形態における各装置は、具体的には、マイクロプロセッサ、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、ハードディスクユニット、ディスプレイユニット、キーボード、マウスなどから構成されるコンピュータシステムである。ＲＡＭまたはハードディスクユニットには、コンピュータプログラムが記録されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、各装置は、その機能を達成する。ここでコンピュータプログラムは、所定の機能を達成するために、コンピュータに対する指令を示す命令コードが複数個組み合わされて構成されたものである。
【０２２５】
（１２）上記の実施の形態における各装置は、構成する構成要素の一部または全部は、１個のシステムＬＳＩ（Ｌａｒｇｅ  Ｓｃａｌｅ  Ｉｎｔｅｇｒａｔｉｏｎ：大規模集積回路）から構成されているとしてもよい。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどを含んで構成されるコンピュータシステムである。ＲＡＭには、コンピュータプログラムが記録されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、システムＬＳＩは、その機能を達成する。
【０２２６】
また、上記の各装置を構成する構成要素の各部は、個別に１チップ化されていても良いし、一部又はすべてを含むように１チップ化されてもよい。
【０２２７】
また、ここでは、システムＬＳＩとしたが、集積度の違いにより、ＩＣ（Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）、ＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）又は、ＬＳＩ内部の回路セルの接続又は設定を再構成可能なリコンフィギュラブル・プロセッサを利用しても良い。
【０２２８】
さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の集積回路化技術への適用等の可能性がある。
【０２２９】
（１３）上記の各装置を構成する構成要素の一部または全部は、各装置に脱着可能なＩＣカードまたは単体のモジュールから構成されていてもよい。ＩＣカードまたはモジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどから構成されるコンピュータシステムである。ＩＣカードまたはモジュールは、上記の超多機能ＬＳＩを含んでもよい。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、ＩＣカードまたは前記モジュールは、その機能を達成する。このＩＣカードまたはこのモジュールは、耐タンパ性を有してもよい。
【０２３０】
（１４）本開示は、上記に示す方法であってもよい。また、これらの方法をコンピュータにより実現するコンピュータプログラムであってもよいし、コンピュータプログラムからなるデジタル信号であってもよい。
【０２３１】
また、本開示は、コンピュータプログラムまたはデジタル信号をコンピュータ読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＢＤ（Ｂｌｕ−ｒａｙ（登録商標）  Ｄｉｓｃ）、半導体メモリなどに記録したものでもよい。また、これらの記録媒体に記録されているデジタル信号であってもよい。
【０２３２】
また、本開示は、コンピュータプログラムまたはデジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、又は、データ放送等を経由して伝送してもよい。
【０２３３】
また、本開示は、マイクロプロセッサとメモリとを備えたコンピュータシステムであって、メモリは、上記コンピュータプログラムを記録しており、マイクロプロセッサは、コンピュータプログラムにしたがって動作してもよい。
【０２３４】
また、プログラムまたはデジタル信号を記録媒体に記録して移送すること、またはプログラムまたはデジタル信号を、ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにおいて実施してもよい。
【０２３５】
（１５）上記実施の形態及び上記変形例をそれぞれ組み合わせてもよい。
【０２３６】
これらの各実施の形態及びその変形例では、車載ネットワークシステムに接続されて通信するゲートウェイ若しくはＥＣＵ、又はこれらとサーバコンピュータとの組み合わせによって不正通信検知の基準として用いられるメッセージが決定される。
【０２３７】
このような不正通信検知を実行する、１個以上のプロセッサ及び記憶部を含むシステムを、本開示では不正通信検知基準決定システムと呼ぶ。
【０２３８】
したがって、不正通信検知基準決定システムは車載ネットワークシステムに接続される１台のゲートウェイのように１個の装置によって実現されるものも、このようなゲートウェイとＥＣＵとの組み合わせ、又はゲートウェイ若しくはＥＣＵと遠隔にあるサーバコンピュータとの組み合わせのように複数個の装置によって実現されるものも含む。
【０２３９】
また、この技術は、上記各実施の形態又はその変形例において、各構成要素が実行する処理のステップの一部又は全部を含む方法として、又は不正通信検知基準決定システムのプロセッサに実行されて、不正通信検知基準決定システムがこの方法を実施させるためのプログラムとしても実現可能である。
【０２４０】
また、上記実施の形態又はその変形例において、特定の構成要素が実行する処理を特定の構成要素の代わりに別の構成要素が実行してもよい。また、複数の処理の順序が変更されてもよいし、複数の処理が並行して実行されてもよい。
【産業上の利用可能性】
【０２４１】
本開示にかかるログ出力方法等は、メッセージ送信時に調停が発生したか否かを判定することで不正を検知するための基準時刻を決定する。これにより従来では、正常なメッセージであるか異常なメッセージであるかの識別が困難であったメッセージに関しても、精度よく、正常なメッセージであると識別することができ、車載ネットワークの保護が可能となる。
【符号の説明】
【０２４２】
１０  車載ネットワークシステム
１００、１００ａ、１００ｂ、１００ｃ、１００ｄ、１００ｅ、１００ｆ、１００ｈ  ＥＣＵ
１０１  エンジン
１０２  ブレーキ
１０３  ドア開閉センサ
１０４  ウィンドウ開閉センサ
１１０  フレーム送受信部
１２０  フレーム解釈部
１３０  受信ＩＤ判定部
１４０  受信ＩＤリスト保持部
１５０、１５０ｈ  フレーム処理部
１７０  データ取得部
１７１  送信データ取得部
１８０、３８０  フレーム生成部
１９０、３７８  ログ保持部
２００、２００ａ、２００ｂ  バス
３００、３００ａ、３００ｂ、３００ｃ  ゲートウェイ
３１０  フレーム送受信部
３２０  フレーム解釈部
３３０  受信ＩＤ判定部
３４０  受信ＩＤリスト保持部
３５０  フレーム処理部
３６０  転送ルール保持部
３７０  異常検知処理機能群
３７１  ＭＡＣ検証部
３７２  振る舞い検知部
３７３  兆候監視部
３７５、３７５ａ、３７５ｂ  ログ出力処理機能群
３７６、３７６ａ  ログ出力制御部
３７７  ログ関連情報保持部
３９０  外部通信部
４００  外部ネットワーク
５００  サーバ
５１０  受信部
５２０  ログ保持部
５３０  解析部
【図１】
2019193786.tif 000003
【図２】
2019193786.tif 000004
【図３】
2019193786.tif 000005
【図４】
2019193786.tif 000006
【図５】
2019193786.tif 000007
【図６】
2019193786.tif 000008
【図７】
2019193786.tif 000009
【図８】
2019193786.tif 000010
【図９】
2019193786.tif 000011
【図１０】
2019193786.tif 000012
【図１１】
2019193786.tif 000013
【図１２】
2019193786.tif 000014
【図１３】
2019193786.tif 000015
【図１４】
2019193786.tif 000016
【図１５】
2019193786.tif 000017
【図１６】
2019193786.tif 000018
【図１７】
2019193786.tif 000019
【図１８】
2019193786.tif 000020
【図１９】
2019193786.tif 000021
【図２０】
2019193786.tif 000022
【図２１】
2019193786.tif 000023
【図２２】
2019193786.tif 000024
【手続補正書】
【提出日】平成31年4月15日(2019.4.15)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
車載ネットワークにおける通信のログを出力するログ出力方法であって、
前記車載ネットワークに送出されたメッセージの異常性を互いに異なる方法でそれぞれ判定する複数の判定処理を行う異常判定ステップと、
前記複数の判定処理の結果に従って、前記ログを生成するログ生成ステップと、
生成した前記ログを送信するログ送信ステップとを含み、
前記ログ生成ステップでは、前記複数の判定処理の結果の組み合わせに従って、前記ログに含まれる情報を決定し、
前記複数の判定処理は、第１の判定処理と第２の判定処理とを含み、
前記ログ生成ステップでは、前記第１の判定処理と前記第２の判定処理との両方においてメッセージに異常性があると判定された時、
（Ａ）前記第１の判定処理と前記第２の判定処理とにおいて、メッセージに異常性があると判定された理由が異なる場合、
前記第１の判定処理で異常性があると判定されたことを示す第１種別識別子と、
前記第１の判定処理で異常性があると判定された理由に関する情報と、
前記第２の判定処理で異常性があると判定されたことを示す第２種別識別子と、
前記第２の判定処理で異常性があると判定された理由に関する情報とを、
前記ログに含まれる情報とし、
（Ｂ）前記第１の判定処理と前記第２の判定処理とにおいて、メッセージに異常性があると判定された理由が同じ場合、
前記第１種別識別子と、
前記第２種別識別子と、
前記第１の判定処理又は前記第２の判定処理で異常性があると判定された理由に関する情報とを、
前記ログに含まれる情報とする、
ログ出力方法。
【請求項２】
前記複数の判定処理は、前記異なる方法の一つとして、前記メッセージのＭＡＣ（Ｍｅｓｓａｇｅ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｃｏｄｅ）を検証することにより前記異常性を判定するＭＡＣ検証処理を含む、
請求項１に記載のログ出力方法。
【請求項３】
前記複数の判定処理は、前記異なる方法の一つとして、前記メッセージから車両の振る舞いを検知することにより前記異常性を判定する振る舞い検知処理を含む、
請求項１又は２に記載のログ出力方法。
【請求項４】
前記複数の判定処理は、前記異なる方法の一つとして、前記メッセージに異常を示す兆候が現れているか否かを監視することにより前記異常性を判定する兆候監視処理を含む、
請求項１〜３のいずれか１項に記載のログ出力方法。
【請求項５】
前記第１の判定処理は、前記メッセージから車両の振る舞いを検知することにより前記異常性を判定する振る舞い検知処理であり、
前記第２の判定処理は、前記メッセージに異常を示す兆候が現れているか否かを監視することにより前記異常性を判定する兆候監視処理である、
請求項１に記載のログ出力方法。
【請求項６】
車載ネットワークシステムにおける通信のログを出力するログ出力装置であって、
１個以上のプロセッサと、
記憶部とを含み、
前記記憶部を用いて、前記１個以上のプロセッサは、
前記車載ネットワークに送出されたメッセージの異常性を互いに異なる方法でそれぞれ判定する複数の判定処理を行う異常判定ステップと、
前記複数の判定処理の結果に従って、前記ログを生成するログ生成ステップと、
生成した前記ログを送信するログ送信ステップとを行い、
前記ログ生成ステップでは、前記複数の判定処理の結果の組み合わせに従って、前記ログに含まれる情報を決定し、
前記複数の判定処理は、第１の判定処理と第２の判定処理とを含み、
前記ログ生成ステップでは、前記第１の判定処理と前記第２の判定処理との両方においてメッセージに異常性があると判定された時、
（Ａ）前記第１の判定処理と前記第２の判定処理とにおいて、メッセージに異常性があると判定された理由が異なる場合、
前記第１の判定処理で異常性があると判定されたことを示す第１種別識別子と、
前記第１の判定処理で異常性があると判定された理由に関する情報と、
前記第２の判定処理で異常性があると判定されたことを示す第２種別識別子と、
前記第２の判定処理で異常性があると判定された理由に関する情報とを、
前記ログに含まれる情報とし、
（Ｂ）前記第１の判定処理と前記第２の判定処理とにおいて、メッセージに異常性があると判定された理由が同じ場合、
前記第１種別識別子と、
前記第２種別識別子と、
前記第１の判定処理又は前記第２の判定処理で異常性があると判定された理由に関する情報とを、
前記ログに含まれる情報とする、
ログ出力装置。
【請求項７】
コンピュータに請求項１に記載のログ出力方法を実行させるためのプログラム。
【国際調査報告】
2019193786.tif 000025
2019193786.tif 000026
2019193786.tif 000027
2019193786.tif 000028