JP6490058B2 - 車載ネットワークシステム及び不正検知方法 - Google Patents

Description

本開示は、電子制御ユニットが通信を行う車載ネットワークにおいて送信された不正なフレームを検知する技術に関する。

近年、自動車の中のシステムには、電子制御ユニット（ＥＣＵ：Electronic Control Unit）と呼ばれる装置が多数配置されている。これらのＥＣＵをつなぐネットワークは車載ネットワークと呼ばれる。車載ネットワークには、多数の規格が存在する。その中でも最も主流な車載ネットワークの一つに、ＩＳＯ１１８９８−１で規定されているＣＡＮ（Controller Area Network）という規格が存在する（「非特許文献１」参照）。

ＣＡＮでは、通信路は２本のバスで構成され、バスに接続されているＥＣＵはノードと呼ばれる。バスに接続されている各ノードは、フレームと呼ばれるメッセージを送受信する。フレームを送信する送信ノードは、２本のバスに電圧をかけ、バス間で電位差を発生させることによって、レセシブと呼ばれる「１」の値と、ドミナントと呼ばれる「０」の値を送信する。複数の送信ノードが全く同一のタイミングで、レセシブとドミナントを送信した場合は、ドミナントが優先されて送信される。受信ノードは、受け取ったフレームのフォーマットに異常がある場合には、エラーフレームと呼ばれるフレームを送信する。エラーフレームとは、ドミナントを６ｂｉｔ連続して送信することで、送信ノードや他の受信ノードにフレームの異常を通知するものである。

またＣＡＮでは送信先や送信元を指す識別子は存在せず、送信ノードはフレーム毎にメッセージＩＤと呼ばれるＩＤを付けて送信し（つまりバスに信号を送出し）、各受信ノードは予め定められたメッセージＩＤのみを受信する（つまりバスから信号を読み取る）。また、ＣＳＭＡ／ＣＡ（Carrier Sense Multiple Access/Collision Avoidance）方式を採用しており、複数ノードの同時送信時にはメッセージＩＤによる調停が行われ、メッセージＩＤの値が小さいフレームが優先的に送信される。

また、異常なメッセージがＣＡＮのバス上に送信された場合にゲートウェイ装置が異常メッセージを検出して、他のバスに転送しないことで、バスの負荷の上昇を抑える技術が知られている（「特許文献１」参照）。

特開２００７−３８９０４号公報

"ＣＡＮ Ｓｐｅｃｉｆｉｃａｔｉｏｎ ２．０ Ｐａｒｔ Ａ"、［ｏｎｌｉｎｅ］、ＣＡＮ ｉｎ Ａｕｔｏｍａｔｉｏｎ（ＣｉＡ）、［平成２６年１１月１４日検索］、インターネット（ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｃａｎ−ｃｉａ．ｏｒｇ／ｆｉｌｅａｄｍｉｎ／ｃｉａ／ｓｐｅｃｉｆｉｃａｔｉｏｎｓ／ＣＡＮ２０Ａ．ｐｄｆ） ＲＦＣ２１０４ ＨＭＡＣ： Ｋｅｙｅｄ−Ｈａｓｈｉｎｇ ｆｏｒ Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ

ところで、車載ネットワークにおいて不正なノードがバスに接続され、不正なノードが不正にフレーム（メッセージ）を送信することで、車体を不正にコントロールしてしまう可能性があるため、その抑制のために不正なメッセージの検知が必要となる。

そこで、本開示は、ＣＡＮプロトコル等に従って通信する車載ネットワークシステムにおいて、車載バッテリーの消費抑制等のために効率的に、バスに送信される不正なメッセージを検知する不正検知電子制御ユニット（不正検知ＥＣＵ）を提供する。また、本開示は、効率的に不正なメッセージを検知するための不正検知方法、及び、不正検知ＥＣＵを備える車載ネットワークシステムを提供する。

本開示の一態様に係る不正検知方法は、１以上のバスを介して通信する複数の第１の電子制御ユニットを備える車載ネットワークシステムにおいて用いられる不正検知方法であって、前記車載ネットワークシステムを備えた車両の状態が第１の条件または第２の条件を満たしたことを検出する検出ステップと、(i)前記検出ステップにおいて前記車両の状態が前記第１の条件を満たしたことが検出された場合に、前記１以上のバスに接続された第２の電子制御ユニットの動作モードを、前記１以上のバス上の不正なメッセージを検知する第１の種類の検知処理を行う第１モードから前記第１の種類の検知処理を行わない第２モードへ切り替え、(ii)前記検出ステップにおいて前記車両の状態が前記第２の条件を満たしたことが検出された場合に、前記第２の電子制御ユニットの動作モードを、前記第２のモードから前記第１のモードへ切り替える、切替ステップとを含む。

また、上記課題を解決するために本開示の一態様に係る車載ネットワークシステムは、１以上のバスを介して通信する複数の電子制御ユニットと前記バスに接続された不正検知電子制御ユニットとを備える車載ネットワークシステムであって、前記車載ネットワークシステムを搭載する車両の状態が一定条件を満たしたことを検出する検出部と、前記検出部により前記車両の状態が一定条件を満たしたことが検出された場合に、前記バスに接続された不正検知電子制御ユニットの動作モードを、当該バス上の不正なメッセージを検知する所定種類の検知処理を行う第１モードと当該所定種類の検知処理を行わない第２モードとの間で切り替える切替部とを備える車載ネットワークシステムである。

また、上記課題を解決するために本開示の一態様に係る不正検知電子制御ユニット（不正検知ＥＣＵ）は、１以上のバスを介して通信する複数の電子制御ユニットが通信に用いるバスに接続される不正検知電子制御ユニットであって、前記複数の電子制御ユニットを搭載する車両の状態が一定条件を満たしたことを検出する検出部と、前記検出部により前記車両の状態が一定条件を満たしたことが検出された場合に、自装置の動作モードを、前記バス上の不正なメッセージを検知する所定種類の検知処理を行う第１モードと当該所定種類の検知処理を行わない第２モードとの間で切り替える切替部を備える不正検知電子制御ユニットである。

本開示によれば、例えば車載バッテリーの電力等で稼動する車載ネットワークシステムでバスに不正なノードが接続されて不正なメッセージが送信された場合にその検知が可能となり、車両の状態に応じて一定条件下で検知を省略するので、バッテリー消費が抑制され得る。

実施の形態１に係る車載ネットワークシステムの全体構成を示す図である。 ＣＡＮプロトコルで規定されるデータフレームのフォーマットを示す図である。 ＣＡＮプロトコルで規定されるエラーフレームのフォーマットを示す図である。 ヘッドユニットの構成図である。 受信ＩＤリストの一例を示した図である。 ゲートウェイの構成図である。 転送ルールの一例を示した図である。 実施の形態１に係るＥＣＵの構成図である。 受信ＩＤリストの一例を示した図である。 エンジンに接続されたＥＣＵから送信されるフレームにおけるＩＤ及びデータフィールドの一例を示す図である。 ブレーキに接続されたＥＣＵから送信されるフレームにおけるＩＤ及びデータフィールドの一例を示す図である。 ドア開閉センサに接続されたＥＣＵから送信されるフレームにおけるＩＤ及びデータフィールドの一例を示す図である。 窓開閉センサに接続されたＥＣＵから送信されるフレームにおけるＩＤ及びデータフィールドの一例を示す図である。 実施の形態１に係る不正検知ＥＣＵの構成図である。 不正検知ＥＣＵに保持される正規ＩＤリストの一例を示した図である。 不正検知ＥＣＵに保持される正規ＩＤリストの一例を示した図である。 メッセージＩＤ毎の不正検知カウンタの状態の一例を示す図である。 実施の形態１における不正なフレームの検知及び実行阻止に係る動作例を示すシーケンス図である。 実施の形態２に係る車載ネットワークシステムの全体構成を示す図である。 実施の形態２に係る不正検知ＥＣＵの構成図である。 不正検知ＥＣＵに保持されるデータ範囲リストの一例を示した図である。 実施の形態２における不正なフレームの検知及び実行阻止に係る動作例を示すシーケンス図である（図２３に続く）。 実施の形態２における不正なフレームの検知及び実行阻止に係る動作例を示すシーケンス図である（図２２から続く）。 実施の形態３に係る車載ネットワークシステムの全体構成を示す図である。 実施の形態３に係るＥＣＵの構成図である。 エンジンに接続されたＥＣＵから送信されるデータフレームにおけるＩＤ及びデータフィールドの一例を示す図である。 ブレーキに接続されたＥＣＵから送信されるデータフレームにおけるＩＤ及びデータフィールドの一例を示す図である。 ドア開閉センサに接続されたＥＣＵから送信されるデータフレームにおけるＩＤ及びデータフィールドの一例を示す図である。 窓開閉センサに接続されたＥＣＵから送信されるデータフレームにおけるＩＤ及びデータフィールドの一例を示す図である。 実施の形態３に係る不正検知ＥＣＵの構成図である。 実施の形態３に係るカウンタ保持部に保持されているメッセージＩＤ毎のカウンタ値の一例を示す図である。 実施の形態３における不正なフレームの検知及び実行阻止に係る動作例を示すシーケンス図である（図３３に続く）。 実施の形態３における不正なフレームの検知及び実行阻止に係る動作例を示すシーケンス図である（図３２から続く）。 実施の形態４に係る車載ネットワークシステムシステムの全体構成を示す図である。 実施の形態４に係るヘッドユニットの構成図である。 実施の形態４に係る不正検知ＥＣＵの構成図である。 実施の形態４におけるチェックモードへの移行シーケンスの一例を示す図である。 実施の形態４における待機モードへの移行シーケンスの一例を示す図である。 実施の形態４における待機モードへの移行シーケンスの一例を示す図である。 他の実施の形態に係るＥＣＵの構成図である。 他の実施の形態に係る不正検知ＥＣＵの構成図である。 他の実施の形態に係る不正検知ＥＣＵの構成図である。

本開示の一態様に係る不正検知方法は、１以上のバスを介して通信する複数の電子制御ユニットを備える車載ネットワークシステムにおいて用いられる不正検知方法であって、前記車載ネットワークシステムを搭載する車両の状態が一定条件を満たしたことを検出する検出ステップと、前記検出ステップにおいて前記車両の状態が一定条件を満たしたことが検出された場合に、前記バスに接続された不正検知電子制御ユニットの動作モードを、当該バス上の不正なメッセージを検知する所定種類の検知処理を行う第１モードと当該所定種類の検知処理を行わない第２モードとの間で切り替える切替ステップとを含む不正検知方法である。ここで、不正検知電子制御ユニット（不正検知ＥＣＵ）は、バスに接続され、そのバスに送信される不正なメッセージを検知するための所定種類の検知処理を実行する機能を有する。不正なメッセージか否かは、検知処理により、予め定められた条件に適合するか否かで判断される。例えば不正検知ＥＣＵが１種類の検知処理しか行えない場合には、検知処理を行うか行わないかが動作モードにより切り替わることになる。この不正検知方法によれば、車両の状態に応じて一定条件下で、不正検知ＥＣＵが不正なメッセージの所定種類の検知処理を省略可能となるため、車両のバッテリー消費が抑制され得る。

また、前記複数の電子制御ユニットは、Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＣＡＮ）プロトコルに従って前記バスを介して通信を行うこととしても良い。これにより、ＣＡＮプロトコルに従って通信する車載ネットワークシステムに不正なＥＣＵが接続されて不正なフレームが送信された場合にその不正を不正検知ＥＣＵが検知する期間が、車両の状態に応じて限定され得るため、電力消費量が低減され得る。

また、前記検出ステップでは、前記複数の電子制御ユニットのうち１つの電子制御ユニットが前記検出を行い、前記切替ステップでは、前記検出ステップで前記検出を行った１つの電子制御ユニットが切替指示メッセージを送信し、当該切替指示メッセージを受信した場合に前記不正検知電子制御ユニットが前記動作モードを切り替えることとしても良い。これにより、例えば、不正検知ＥＣＵは、不正なメッセージを検知する検知処理を行わない第２モードにおいては、切替指示メッセージ（つまり動作モードの切り替えのトリガーとなるトリガーフレーム）の検出を行うだけで足りるようになる。即ち、不正検知ＥＣＵは、車両の状態を直接検出するための検出部（例えばセンサ等）を有さなくても良い。

また、前記検出ステップでは、前記１つの電子制御ユニットが、前記バス上で不正なメッセージを検知した場合に、前記車両の状態が前記一定条件を満たしたとして前記検出を行い、前記切替ステップでは、前記検出ステップで前記検出を行った場合に前記１つの電子制御ユニットが、前記第１モードに切り替える旨を示す切替指示メッセージを送信し、当該切替指示メッセージを受信した場合に前記不正検知電子制御ユニットが前記動作モードを前記第１モードに切り替えることとしても良い。これにより、あるバス上に不正なメッセージが送信されていることが検出された場合に、不正検知ＥＣＵが第１モード（不正なメッセージを検知するチェックモード）になり、不正検知ＥＣＵが接続されたバス上の不正なメッセージが検知されるようになる。

また、前記検出ステップでは、前記１つの電子制御ユニットが、前記バス上で一定期間において不正なメッセージを検知しなかった場合に、前記車両の状態が前記一定条件を満たしたとして前記検出を行い、前記切替ステップでは、前記検出ステップで前記検出を行った場合に前記１つの電子制御ユニットが、前記第２モードに切り替える旨を示す切替指示メッセージを送信し、当該切替指示メッセージを受信した場合に前記不正検知電子制御ユニットが前記動作モードを前記第２モードに切り替えることとしても良い。これにより、あるバス上に一定期間、不正なメッセージが送信されなかったことが検出された場合に、不正検知ＥＣＵが第２モード（不正なメッセージを検知しない待機モード）になり電力消費量が低減され得る。

また、前記一定条件は、前記車両の使用が開始されたことであり、前記切替ステップでは、前記検出ステップで前記車両の使用が開始されたことが検出された場合に、前記動作モードを前記第１モードに切り替えることとしても良い。車両の使用とは、例えば、ユーザが、車両を走行させること、車両の走行の準備（ドア開け、乗車、エンジン始動等）をすること等である。また、例えば走行が不要となったときに、駐車（エンジン停止等）すること、降車すること等で使用が終わる。なお、ユーザの自宅の駐車場等といった特定の駐車場以外の場所における駐車中（給油所その他の外出先での駐車中）においては駐車及び降車があっても使用が終わらないと扱っても良い。これにより、車両の使用が開始された場合に、不正検知ＥＣＵが第１モード（不正なメッセージを検知するチェックモード）になり、不正検知ＥＣＵが接続されたバス上の不正なメッセージが検知されるようになる。従って、例えば駐車してユーザが車両から離れている間に車載ネットワークシステムに不正なＥＣＵが付加されたとしても、ユーザが車両に戻って車両の使用を開始してからはその不正なＥＣＵが不正なメッセージを送信すれば、その不正が検知されるようになる。

また、前記車両に搭載されたエンジンが始動したことを検出することにより、車両の使用が開始されたことの前記検出を行うこととしても良い。これにより、エンジンが始動したときから、不正検知ＥＣＵが不正なメッセージを検知する状態となる。従って、例えば駐車してユーザが車両から離れている間に車載ネットワークシステムに不正なＥＣＵが付加されたとしても、ユーザが車両に戻ってエンジンを始動してからはその不正なＥＣＵが不正なメッセージを送信すれば、その不正が検知されるようになる。

また、前記不正検知方法は更に、前記切替ステップで前記動作モードが前記第１モードに切り替えられた後に、前記車両の使用が開始されてから所定時間が経過した際に、前記動作モードを前記第２モードに切り替える再切替ステップを含むこととしても良い。これにより、車両の使用が開始されてから所定時間が経過した際に、無条件又は一定条件下で不正検知ＥＣＵが第２モード（不正なメッセージを検知しない待機モード）になり、電力消費量が低減され得る。

また、前記一定条件は、前記複数の電子制御ユニットのいずれかが前記車両の外部の装置と通信を開始する状態になったことであり、前記切替ステップでは、前記検出ステップで前記通信を開始する状態になったことが検出された場合に、前記動作モードを前記第１モードに切り替えることとしても良い。これにより、外部との通信が開始されると不正検知ＥＣＵが不正なメッセージを検知する状態となる。従って、例えば外部の装置から車載ネットワークシステムのヘッドユニット等が攻撃され、不正なメッセージ（フレーム）を外部から注入されても迅速に検知し得るようになる。なお、外部から不正なメッセージを送信するためのプログラム等が供給されたような場合にも同様に対処し得る。

また、前記一定条件は、前記複数の電子制御ユニットのいずれかが前記車両の外部の装置と通信して通信終了後の一定状態になったことであり、前記切替ステップでは、前記検出ステップで前記通信終了後の一定状態になったことが検出された場合に、前記動作モードを前記第２モードに切り替えることとしても良い。これにより、外部との通信が終了しバス上に不正なメッセージが送信される可能性が低下した場合に、不正なメッセージの検知の省略によりバッテリー消費を抑制できる。なお、不正なメッセージが送信される可能性が低下した場合は具体的には、例えば、通信が遮断された状態になった場合、通信終了から一定時間（例えば数分間）が経過した状態になった場合等である。

また、前記車載ネットワークシステムでは前記複数の電子制御ユニットの通信に複数のバスが用いられ、前記車載ネットワークシステムは更に前記複数のバスの間でメッセージを転送する機能を有するゲートウェイ装置を備え、前記検出ステップでは、前記複数の電子制御ユニットのうち、前記不正検知電子制御ユニットと異なるバスに接続された１つの電子制御ユニットが前記検出を行い、前記切替ステップでは、前記検出ステップで前記検出を行った１つの電子制御ユニットが切替指示メッセージを送信し、前記ゲートウェイ装置に転送された当該切替指示メッセージを受信した場合に前記不正検知電子制御ユニットが前記動作モードを切り替えることとしても良い。これにより、車載ネットワークシステムにおける１つのバスに接続されたＥＣＵにより検出された車両の状態に応じて別の１以上のバスそれぞれに接続された各不正検知ＥＣＵが動作モードを切り替えることができるようになる。

また、前記検出ステップでは、車両の状態が変化した場合において、所定のユーザインタフェースにより前記動作モードの切り替えの要否に係る入力を受け付け、当該入力が前記動作モードの切り替えを要する旨を示すときには、前記車両の状態が前記一定条件を満たしたとして前記検出を行うこととしても良い。これにより、不正検知ＥＣＵの動作モードの切り替えに、ユーザの判断が反映されるようになるので、ユーザの事情等に応じて適切に動作モードが切り替えられるようになる。

また、前記第２モードでは、不正なメッセージを検知可能な程度が、前記所定種類の検知処理とは異なる種類の検知処理を行うこととしても良い。例えば不正検知ＥＣＵが、不正なメッセージを検知するために処理量の比較的多い第一種の検知処理と処理量の比較的少ない第二種の検知処理とを実行可能である場合に、第一種の検知処理を行うか第二種の検知処理を行うかが動作モードにより切り替わる。これにより、車両の状態に応じて一定条件下で、不正検知ＥＣＵが不正なメッセージの所定種類の検知処理（例えば第一種の検知処理）を省略可能となるため、車両のバッテリー消費が抑制され得る。なお、不正検知ＥＣＵにおける検知処理の処理量の多さは、必ずしも不正を検知可能な程度の高さに比例するものではないが、概ね不正なメッセージを検知可能な程度の高さと関連する傾向がある。このため、例えば概ね不正検知程度が高く処理量の多い検知処理を一定の場合に限って実行しその他の場合にはそれより処理量の少ない検知処理を行うように動作モードを切り換えること等が有用となる。

また、本開示の一態様に係る車載ネットワークシステムは、１以上のバスを介して通信する複数の電子制御ユニットと前記バスに接続された不正検知電子制御ユニットとを備える車載ネットワークシステムであって、前記車載ネットワークシステムを搭載する車両の状態が一定条件を満たしたことを検出する検出部と、前記検出部により前記車両の状態が一定条件を満たしたことが検出された場合に、前記バスに接続された不正検知電子制御ユニットの動作モードを、当該バス上の不正なメッセージを検知する所定種類の検知処理を行う第１モードと当該所定種類の検知処理を行わない第２モードとの間で切り替える切替部とを備える車載ネットワークシステムである。これにより、車両の状態に応じて一定条件下で、不正検知ＥＣＵが不正なメッセージの所定種類の検知処理を省略可能となるため、車両のバッテリー消費が抑制され得る。

また、本開示の一態様に係る不正検知電子制御ユニット（不正検知ＥＣＵ）は、１以上のバスを介して通信する複数の電子制御ユニットが通信に用いるバスに接続される不正検知電子制御ユニットであって、前記複数の電子制御ユニットを搭載する車両の状態が一定条件を満たしたことを検出する検出部と、前記検出部により前記車両の状態が一定条件を満たしたことが検出された場合に、自装置の動作モードを、前記バス上の不正なメッセージを検知する所定種類の検知処理を行う第１モードと当該所定種類の検知処理を行わない第２モードとの間で切り替える切替部を備える不正検知電子制御ユニットである。これにより、車両の状態に応じて一定条件下で、不正検知ＥＣＵが不正なメッセージの所定種類の検知処理を省略可能となるため、車両のバッテリー消費が抑制され得る。

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

以下、実施の形態に係る車載ネットワークシステム、不正検知ＥＣＵ等について、図面を参照しながら説明する。ここで示す実施の形態は、いずれも本開示の一具体例を示すものである。従って、以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置及び接続形態、並びに、ステップ（工程）及びステップの順序等は、一例であって本開示を限定するものではない。以下の実施の形態における構成要素のうち、独立請求項に記載されていない構成要素については、任意に付加可能な構成要素である。また、各図は、模式図であり、必ずしも厳密に図示されたものではない。

（実施の形態１）
以下、本開示の実施の形態として、メッセージＩＤを用いて他のノード（ＥＣＵ）において不正なフレームに基づく処理が実行されることを阻止するための不正対処方法を実現する不正検知ＥＣＵを含む車載ネットワークシステム１０について図面を用いて説明する。

［１．１ 車載ネットワークシステム１０の全体構成］
図１は、実施の形態１に係る車載ネットワークシステム１０の全体構成を示す図である。車載ネットワークシステム１０は、ＣＡＮプロトコルに従って通信するネットワーク通信システムの一例であり、制御装置、センサ等の各種機器が搭載された自動車におけるネットワーク通信システムである。車載ネットワークシステム１０は、バス５００ａ、５００ｂと、不正検知ＥＣＵ１００ａ、１００ｂ、ヘッドユニット２００、ゲートウェイ３００、及び、各種機器に接続されたＥＣＵ４００ａ〜４００ｄ等のＥＣＵといったバスに接続された各ノードとを含んで構成される。なお、図１では省略しているものの、車載ネットワークシステム１０にはＥＣＵ４００ａ〜４００ｄ以外にもいくつものＥＣＵが含まれ得るが、ここでは、便宜上ＥＣＵ４００ａ〜４００ｄに注目して説明を行う。ＥＣＵは、例えば、プロセッサ（マイクロプロセッサ）、メモリ等のデジタル回路、アナログ回路、通信回路等を含む装置である。メモリは、ＲＯＭ、ＲＡＭ等であり、プロセッサにより実行される制御プログラム（コンピュータプログラム）を記憶することができる。例えばプロセッサが、制御プログラム（コンピュータプログラム）に従って動作することにより、ＥＣＵは各種機能を実現することになる。なお、コンピュータプログラムは、所定の機能を達成するために、プロセッサに対する指令を示す命令コードが複数個組み合わされて構成されたものである。ここでは、バス５００ａ、５００ｂには不正なフレームを送信する不正ＥＣＵが接続されている可能性があることを前提として説明する。

不正検知ＥＣＵ１００ａ、１００ｂは、それぞれバス５００ａ、バス５００ｂに接続され、ＥＣＵ４００ａ〜４００ｄ等により送信されたフレームが不正であるかどうかを判定し、不正であればエラーフレームを送信する機能を有するＥＣＵである。

ＥＣＵ４００ａ〜４００ｄは、いずれかのバスと接続され、また、それぞれエンジン４０１、ブレーキ４０２、ドア開閉センサ４０３、窓開閉センサ４０４に接続されている。ＥＣＵ４００ａ〜４００ｄのそれぞれは、接続されている機器（エンジン４０１等）の状態を取得し、定期的に状態を表すフレーム（後述するデータフレーム）等をネットワーク（つまりバス）に送信している。

ゲートウェイ３００は、不正検知ＥＣＵ１００ａ、ＥＣＵ４００ａ及びＥＣＵ４００ｂがつながるバス５００ａと、不正検知ＥＣＵ１００ｂ、ＥＣＵ４００ｃ及びＥＣＵ４００ｄがつながるバス５００ｂと、ヘッドユニット２００がつながるバス５００ｃとに接続しており、それぞれのバスから受信したフレームを他のバスに転送する機能を有する。また受信したフレームを転送するかしないかを接続されたバス間毎に切り替えることも可能である。ゲートウェイ３００も一種のＥＣＵである。

ヘッドユニット２００は、フレームを受信する機能を持ち、ＥＣＵ４００ａ〜４００ｄから送信されるフレームを受信し、各種状態をディスプレイ（図示しない）に表示して、ユーザに提示する機能を持つ。ヘッドユニット２００も一種のＥＣＵである。

この車載ネットワークシステム１０においてはＣＡＮプロトコルに従って各ＥＣＵがフレームの授受を行う。ＣＡＮプロトコルにおけるフレームには、データフレーム、リモートフレーム、オーバーロードフレーム及びエラーフレームがある。説明の便宜上、まずはデータフレーム及びエラーフレームを中心に説明する。

［１．２ データフレームフォーマット］
以下、ＣＡＮプロトコルに従ったネットワークで用いられるフレームの１つであるデータフレームについて説明する。

図２は、ＣＡＮプロトコルで規定されるデータフレームのフォーマットを示す図である。同図には、ＣＡＮプロトコルで規定される標準ＩＤフォーマットにおけるデータフレームを示している。データフレームは、ＳＯＦ（Start Of Frame）、ＩＤフィールド、ＲＴＲ（Remote Transmission Request）、ＩＤＥ（Identifier Extension）、予約ビット「ｒ」、ＤＬＣ（Data Length Code）、データフィールド、ＣＲＣ（Cyclic Redundancy Check）シーケンス、ＣＲＣデリミタ「ＤＥＬ」、ＡＣＫ（Acknowledgement）スロット、ＡＣＫデリミタ「ＤＥＬ」、及び、ＥＯＦ（End Of Frame）の各フィールドで構成される。

ＳＯＦは、１ｂｉｔのドミナントで構成される。バスがアイドルの状態はレセシブになっており、ＳＯＦによりドミナントへ変更することでフレームの送信開始を通知する。

ＩＤフィールドは、１１ｂｉｔで構成される、データの種類を示す値であるＩＤ（メッセージＩＤ）を格納するフィールドである。複数のノードが同時に送信を開始した場合、このＩＤフィールドで通信調停を行うために、ＩＤが小さい値を持つフレームが高い優先度となるよう設計されている。

ＲＴＲは、データフレームとリモートフレームとを識別するための値であり、データフレームにおいてはドミナント１ｂｉｔで構成される。

ＩＤＥと「ｒ」とは、両方ドミナント１ｂｉｔで構成される。

ＤＬＣは、４ｂｉｔで構成され、データフィールドの長さを示す値である。なお、ＩＤＥ、「ｒ」及びＤＬＣを合わせてコントロールフィールドと称する。

データフィールドは、最大６４ｂｉｔで構成される送信するデータの内容を示す値である。８ｂｉｔ毎に長さを調整できる。送られるデータの仕様については、ＣＡＮプロトコルで規定されておらず、車載ネットワークシステム１０において定められる。従って、車種、製造者（製造メーカ）等に依存した仕様となる。

ＣＲＣシーケンスは、１５ｂｉｔで構成される。ＳＯＦ、ＩＤフィールド、コントロールフィールド及びデータフィールドの送信値より算出される。

ＣＲＣデリミタは、１ｂｉｔのレセシブで構成されるＣＲＣシーケンスの終了を表す区切り記号である。なお、ＣＲＣシーケンス及びＣＲＣデリミタを合わせてＣＲＣフィールドと称する。

ＡＣＫスロットは、１ｂｉｔで構成される。送信ノードはＡＣＫスロットをレセシブにして送信を行う。受信ノードはＣＲＣシーケンスまで正常に受信ができていればＡＣＫスロットをドミナントとして送信する。レセシブよりドミナントが優先されるため、送信後にＡＣＫスロットがドミナントであれば、送信ノードは、いずれかの受信ノードが受信に成功していることを確認できる。

ＡＣＫデリミタは、１ｂｉｔのレセシブで構成されるＡＣＫの終了を表す区切り記号である。

ＥＯＦは、７ｂｉｔのレセシブで構成されており、データフレームの終了を示す。

［１．３ エラーフレームフォーマット］
図３は、ＣＡＮプロトコルで規定されるエラーフレームのフォーマットを示す図である。エラーフレームは、エラーフラグ（プライマリ）と、エラーフラグ（セカンダリ）と、エラーデリミタとから構成される。

エラーフラグ（プライマリ）は、エラーの発生を他のノードに知らせるために使用される。エラーを検知したノードはエラーの発生を他のノードに知らせるために６ｂｉｔのドミナントを連続で送信する。この送信は、ＣＡＮプロトコルにおけるビットスタッフィングルール（連続して同じ値を６ｂｉｔ以上送信しない）に違反し、他のノードからのエラーフレーム（セカンダリ）の送信を引き起こす。

エラーフラグ（セカンダリ）は、エラーの発生を他のノードに知らせるために使用される連続した６ビットのドミナントで構成される。エラーフラグ（プライマリ）を受信してビットスタッフィングルール違反を検知した全てのノードがエラーフラグ（セカンダリ）を送信することになる。

エラーデリミタ「ＤＥＬ」は、８ｂｉｔの連続したレセシブであり、エラーフレームの終了を示す。

［１．４ ヘッドユニット２００の構成］
ヘッドユニット２００は、例えば、自動車のインパネ（インストルメントパネル）等に設けられ、運転者に視認されるための情報を表示する液晶ディスプレイ（ＬＣＤ：liquid crystal display）等の表示装置、運転者の操作を受け付ける入力手段等を備える一種のＥＣＵである。

図４は、ヘッドユニット２００の構成図である。ヘッドユニット２００は、フレーム送受信部２７０と、フレーム解釈部２６０と、受信ＩＤ判断部２４０と、受信ＩＤリスト保持部２５０と、フレーム処理部２２０と、表示制御部２１０と、フレーム生成部２３０とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、ヘッドユニット２００における通信回路、ＬＣＤ、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。

フレーム送受信部２７０は、バス５００ｃに対して、ＣＡＮプロトコルに従ったフレームを送受信する。バス５００ｃからフレームを１ｂｉｔずつ受信し、フレーム解釈部２６０に転送する。また、フレーム生成部２３０より通知を受けたフレームの内容をバス５００ｃに１ｂｉｔずつ送信する。

フレーム解釈部２６０は、フレーム送受信部２７０よりフレームの値を受け取り、ＣＡＮプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。フレーム解釈部２６０は、ＩＤフィールドと判断した値は受信ＩＤ判断部２４０へ転送する。フレーム解釈部２６０は、受信ＩＤ判断部２４０から通知される判定結果に応じて、ＩＤフィールドの値と、ＩＤフィールド以降に現れるデータフィールドとを、フレーム処理部２２０へ転送するか、その判定結果を受けた以降においてフレームの受信を中止する（つまりそのフレームとしての解釈を中止する）かを決定する。また、フレーム解釈部２６０は、例えば、ＣＲＣの値が合わなかったり、ドミナント固定とされている項目がレセシブだったりする等、ＣＡＮプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部２３０へ通知する。また、フレーム解釈部２６０は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。例えばデータフレームの途中からエラーフレームと解釈された場合においては、そのデータフレームの解釈は中止され、そのデータフレームに応じて特段の処理を行うことがなくなる。

受信ＩＤ判断部２４０は、フレーム解釈部２６０から通知されるＩＤフィールドの値を受け取り、受信ＩＤリスト保持部２５０が保持しているメッセージＩＤのリストに従い、そのＩＤフィールド以降のフレームの各フィールドを受信するかどうかの判定を行う。この判定結果を、受信ＩＤ判断部２４０は、フレーム解釈部２６０へ通知する。

受信ＩＤリスト保持部２５０は、ヘッドユニット２００が受信するＩＤ（メッセージＩＤ）のリストである受信ＩＤリストを保持する。図５は、受信ＩＤリストの一例を示した図である。ヘッドユニット２００は、エンジン４０１に接続されたＥＣＵ４００ａからメッセージＩＤが「１」であるフレーム（メッセージ）を受信し、ブレーキ４０２に接続されたＥＣＵ４００ｂからメッセージＩＤが「２」であるフレームを受信し、ドア開閉センサ４０３に接続されたＥＣＵ４００ｃからメッセージＩＤが「３」であるフレームを受信し、窓開閉センサ４０４に接続されたＥＣＵ４００ｄからメッセージＩＤが「４」であるフレームを受信する。

フレーム処理部２２０は、受信したフレームの内容（例えばメッセージＩＤ及びデータフィールドの内容）に基づいて、例えばＬＣＤに表示されるべき画像を形成して、表示制御部２１０に通知する。なお、フレーム処理部２２０は、受信したデータフィールドの内容を保持し、入力手段を通じて受け付けた運転者による操作に応じて、ＬＣＤに表示されるべき画像（例えば車速表示用の画像、窓開閉状態表示用の画像等）を選択して通知しても良い。

表示制御部２１０は、フレーム処理部２２０より通知を受けた内容をＬＣＤ等に表示する。

フレーム生成部２３０は、フレーム解釈部２６０からのエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部２７０へ通知して送信させる。

［１．５ 受信ＩＤリスト例１］
図５は、ヘッドユニット２００、ゲートウェイ３００、ＥＣＵ４００ｃ及びＥＣＵ４００ｄのそれぞれにおいて保持される受信ＩＤリストの一例を示す図である。同図に例示する受信ＩＤリストは、ＩＤ（メッセージＩＤ）の値が「１」、「２」、「３」及び「４」のいずれかであるメッセージＩＤを含むフレームを選択的に受信して処理するために用いられる。例えば、ヘッドユニット２００の受信ＩＤリスト保持部２５０に図５の受信ＩＤリストが保持されていると、メッセージＩＤが「１」、「２」、「３」及び「４」のいずれでもないフレームについては、フレーム解釈部２６０でのＩＤフィールド以後のフレームの解釈が中止される。

［１．６ ゲートウェイ３００の構成］
図６は、ゲートウェイ３００の構成図である。ゲートウェイ３００は、フレーム送受信部３６０と、フレーム解釈部３５０と、受信ＩＤ判断部３３０と、受信ＩＤリスト保持部３４０と、フレーム生成部３２０と、転送処理部３１０と、転送ルール保持部３７０とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、ゲートウェイ３００における通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。

フレーム送受信部３６０は、バス５００ａ、５００ｂ、５００ｃそれぞれに対して、ＣＡＮプロトコルに従ったフレームを送受信する。バスからフレームを１ｂｉｔずつ受信し、フレーム解釈部３５０に転送する。また、フレーム生成部３２０より通知を受けた転送先のバスを示すバス情報及びフレームに基づいて、そのフレームの内容をバス５００ａ、５００ｂ、５００ｃに１ｂｉｔずつ送信する。

フレーム解釈部３５０は、フレーム送受信部３６０よりフレームの値を受け取り、ＣＡＮプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。ＩＤフィールドと判断した値は受信ＩＤ判断部３３０へ転送する。フレーム解釈部３５０は、受信ＩＤ判断部３３０から通知される判定結果に応じて、ＩＤフィールドの値と、ＩＤフィールド以降に現れるデータフィールド（データ）とを、転送処理部３１０へ転送するか、その判定結果を受けた以降においてフレームの受信を中止する（つまりそのフレームとしての解釈を中止する）かを決定する。また、フレーム解釈部３５０は、ＣＡＮプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部３２０へ通知する。また、フレーム解釈部３５０は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。

受信ＩＤ判断部３３０は、フレーム解釈部３５０から通知されるＩＤフィールドの値を受け取り、受信ＩＤリスト保持部３４０が保持しているメッセージＩＤのリストに従い、そのＩＤフィールド以降のフレームの各フィールドを受信するかどうかの判定を行う。この判定結果を、受信ＩＤ判断部３３０は、フレーム解釈部３５０へ通知する。

受信ＩＤリスト保持部３４０は、ゲートウェイ３００が受信するＩＤ（メッセージＩＤ）のリストである受信ＩＤリスト（図５参照）を保持する。

転送処理部３１０は、転送ルール保持部３７０が保持する転送ルールに従って、受信したフレームのメッセージＩＤに応じて、転送するバスを決定し、転送するバスを示すバス情報とフレーム解釈部３５０より通知されたメッセージＩＤとデータとをフレーム生成部３２０へ通知する。なお、ゲートウェイ３００は、あるバスから受信されたエラーフレームについては他のバスに転送しない。

転送ルール保持部３７０は、バス毎のフレームの転送についてのルールを表す情報である転送ルールを保持する。図７は、転送ルールの一例を示した図である。

フレーム生成部３２０は、フレーム解釈部３５０から通知されたエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部３６０へ通知して送信させる。また、フレーム生成部３２０は、転送処理部３１０より通知されたメッセージＩＤとデータとを使ってフレームを構成し、フレーム及びバス情報をフレーム送受信部３６０へ通知する。

［１．７ 転送ルール例］
図７は、ゲートウェイ３００が保有する転送ルールの一例を示す。この転送ルールは、転送元のバスと転送先のバスと転送対象のＩＤ（メッセージＩＤ）とを対応付けている。図７中の「＊」はメッセージＩＤにかかわらずフレームの転送がなされることを表している。また、同図中の「−」は転送対象のフレームがないことを示す。同図の例は、バス５００ａから受信するフレームはメッセージＩＤにかかわらず、バス５００ｂ及びバス５００ｃに転送するように設定されていることを示している。また、バス５００ｂから受信するフレームのうち、バス５００ｃには全てのフレームが転送されるが、バス５００ａにはメッセージＩＤが「３」であるフレームのみが転送されるように設定されていることを示している。また、バス５００ｃから受信されるフレームは、バス５００ａにもバス５００ｂにも転送されないように設定されていることを示している。

［１．８ ＥＣＵ４００ａの構成］
図８は、ＥＣＵ４００ａの構成図である。ＥＣＵ４００ａは、フレーム送受信部４６０と、フレーム解釈部４５０と、受信ＩＤ判断部４３０と、受信ＩＤリスト保持部４４０と、フレーム処理部４１０と、フレーム生成部４２０と、データ取得部４７０とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、ＥＣＵ４００ａにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。

フレーム送受信部４６０は、バス５００ａに対して、ＣＡＮプロトコルに従ったフレームを送受信する。バス５００ａからフレームを１ｂｉｔずつ受信し、フレーム解釈部４５０に転送する。また、フレーム生成部４２０より通知を受けたフレームの内容をバス５００ａに送信する。

フレーム解釈部４５０は、フレーム送受信部４６０よりフレームの値を受け取り、ＣＡＮプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。ＩＤフィールドと判断した値は受信ＩＤ判断部４３０へ転送する。フレーム解釈部４５０は、受信ＩＤ判断部４３０から通知される判定結果に応じて、ＩＤフィールドの値と、ＩＤフィールド以降に現れるデータフィールドとを、フレーム処理部４１０へ転送するか、その判定結果を受けた以降においてフレームの受信を中止する（つまりそのフレームとしての解釈を中止する）かを決定する。また、フレーム解釈部４５０は、ＣＡＮプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部４２０へ通知する。また、フレーム解釈部４５０は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。

受信ＩＤ判断部４３０は、フレーム解釈部４５０から通知されるＩＤフィールドの値を受け取り、受信ＩＤリスト保持部４４０が保持しているメッセージＩＤのリストに従い、そのＩＤフィールド以降のフレームの各フィールドを受信するかどうかの判定を行う。この判定結果を、受信ＩＤ判断部４３０は、フレーム解釈部４５０へ通知する。

受信ＩＤリスト保持部４４０は、ＥＣＵ４００ａが受信するＩＤ（メッセージＩＤ）のリストである受信ＩＤリストを保持する。図９は、受信ＩＤリストの一例を示した図である。

フレーム処理部４１０は、受信したフレームのデータに応じてＥＣＵ毎に異なる機能に係る処理を行う。例えば、エンジン４０１に接続されたＥＣＵ４００ａは、時速が３０ｋｍを超えた状態でドアが開いている状態だと、アラーム音を鳴らす機能を備える。ＥＣＵ４００ａは、例えばアラーム音を鳴らすためのスピーカ等を有している。そして、ＥＣＵ４００ａのフレーム処理部４１０は、他のＥＣＵから受信したデータ（例えばドアの状態を示す情報）を管理し、エンジン４０１から取得された時速に基づいて一定条件下でアラーム音を鳴らす処理等を行う。

データ取得部４７０は、ＥＣＵにつながっている機器、センサ等の状態を示すデータを取得し、フレーム生成部４２０に通知する。

フレーム生成部４２０は、フレーム解釈部４５０から通知されたエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部４６０へ通知して送信させる。また、フレーム生成部４２０は、データ取得部４７０より通知されたデータの値に対して、予め定められたメッセージＩＤをつけてフレームを構成し、フレーム送受信部４６０へ通知する。

なお、ＥＣＵ４００ｂ〜４００ｄも、上述したＥＣＵ４００ａと基本的に同様の構成を備える。但し、受信ＩＤリスト保持部４４０に保持される受信ＩＤリストはＥＣＵ毎に異なる内容となり得る。ＥＣＵ４００ｂは図９に例示する受信ＩＤリストを保持し、ＥＣＵ４００ｃ及びＥＣＵ４００ｄは図５に例示する受信ＩＤリストを保持する。また、フレーム処理部４１０の処理内容は、ＥＣＵ毎に異なる。例えば、ＥＣＵ４００ｃにおけるフレーム処理部４１０の処理内容は、ブレーキがかかっていない状況でドアが開くとアラーム音を鳴らす機能に係る処理を含む。例えば、ＥＣＵ４００ｂ及びＥＣＵ４００ｄにおけるフレーム処理部４１０では特段の処理を行わない。なお、各ＥＣＵは、ここで例示した以外の機能を備えていても良い。なお、ＥＣＵ４００ａ〜４００ｄのそれぞれが送信するフレームの内容については後に図１０〜図１３を用いて説明する。

［１．９ 受信ＩＤリスト例２］
図９は、ＥＣＵ４００ａ及びＥＣＵ４００ｂのそれぞれにおいて保持される受信ＩＤリストの一例を示す図である。同図に例示する受信ＩＤリストは、ＩＤ（メッセージＩＤ）の値が「１」、「２」及び「３」のいずれかであるメッセージＩＤを含むフレームを選択的に受信して処理するために用いられる。例えば、ＥＣＵ４００ａの受信ＩＤリスト保持部４４０に図９の受信ＩＤリストが保持されていると、メッセージＩＤが「１」、「２」及び「３」のいずれでもないフレームについては、フレーム解釈部４５０でのＩＤフィールド以後のフレームの解釈が中止される。

［１．１０ エンジンに係るＥＣＵ４００ａの送信フレーム例］
図１０は、エンジン４０１に接続されたＥＣＵ４００ａから送信されるフレームにおけるＩＤ（メッセージＩＤ）及びデータフィールド（データ）の一例を示す図である。ＥＣＵ４００ａが送信するフレームのメッセージＩＤは「１」である。データは、時速（ｋｍ／時）を表し、最低０（ｋｍ／時）〜最高１８０（ｋｍ／時）までの範囲の値を取り、データ長は１ｂｙｔｅである。図１０の上行から下行へと、ＥＣＵ４００ａから逐次送信される各フレームに対応する各メッセージＩＤ及びデータを例示しており、０ｋｍ／時から１ｋｍ／時ずつ加速されている様子を表している。

［１．１１ ブレーキに係るＥＣＵ４００ｂの送信フレーム例］
図１１は、ブレーキ４０２に接続されたＥＣＵ４００ｂから送信されるフレームにおけるＩＤ（メッセージＩＤ）及びデータフィールド（データ）の一例を示す図である。ＥＣＵ４００ｂが送信するフレームのメッセージＩＤは「２」である。データは、ブレーキのかかり具合を割合（％）で表し、データ長は１ｂｙｔｅである。この割合は、ブレーキを全くかけていない状態を０（％）、ブレーキを最大限かけている状態を１００（％）としたものである。図１１の上行から下行へと、ＥＣＵ４００ｂから逐次送信される各フレームに対応する各メッセージＩＤ及びデータを例示しており、１００％から徐々にブレーキを弱めている様子を表している。

［１．１２ ドア開閉センサに係るＥＣＵ４００ｃの送信フレーム例］
図１２は、ドア開閉センサ４０３に接続されたＥＣＵ４００ｃから送信されるフレームにおけるＩＤ（メッセージＩＤ）及びデータフィールド（データ）の一例を示す図である。ＥＣＵ４００ｃが送信するフレームのメッセージＩＤは「３」である。データは、ドアの開閉状態を表し、データ長は１ｂｙｔｅである。データの値は、ドアが開いている状態が「１」、ドアが閉まっている状態が「０」である。図１２の上行から下行へと、ＥＣＵ４００ｃから逐次送信される各フレームに対応する各メッセージＩＤ及びデータを例示しており、ドアが開いている状態から次第に閉められた状態へと移った様子を表している。

［１．１３ 窓開閉センサに係るＥＣＵ４００ｄの送信フレーム例］
図１３は、窓開閉センサ４０４に接続されたＥＣＵ４００ｄから送信されるフレームにおけるＩＤ（メッセージＩＤ）及びデータフィールド（データ）の一例を示す図である。ＥＣＵ４００ｄが送信するフレームのメッセージＩＤは「４」である。データは、窓の開閉状態を割合（％）で表し、データ長は１ｂｙｔｅである。この割合は、窓が完全に閉まっている状態を０（％）、窓が全開の状態を１００（％）としたものである。図１３の上行から下行へと、ＥＣＵ４００ｄから逐次送信される各フレームに対応する各メッセージＩＤ及びデータを例示しており、窓が閉まっている状態から徐々に開いていく様子を表している。

［１．１４ 不正検知ＥＣＵ１００ａの構成］
図１４は、不正検知ＥＣＵ１００ａの構成図である。不正検知ＥＣＵ１００ａは、フレーム送受信部１６０と、フレーム解釈部１５０と、不正フレーム検知部１３０と、正規ＩＤリスト保持部１２０と、不正検知カウンタ保持部１１０と、フレーム生成部１４０とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、不正検知ＥＣＵ１００ａにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。なお、不正検知ＥＣＵ１００ｂも基本的に同様の構成を備えるが、正規ＩＤリスト保持部１２０が保持するリスト情報（正規ＩＤリスト）の内容が不正検知ＥＣＵ１００ａと不正検知ＥＣＵ１００ｂとでは異なる。

フレーム送受信部１６０は、バス５００ａに対して、ＣＡＮプロトコルに従ったフレームを送受信する。即ち、フレーム送受信部１６０は、バス上でのフレームの送信が開始された場合においてフレームを受信する言わば受信部として働き、また、バスにエラーフレーム等を送信する言わば送信部として働く。即ち、フレーム送受信部１６０は、バス５００ａからフレームを１ｂｉｔずつ受信し、フレーム解釈部１５０に転送する。また、フレーム生成部１４０より通知を受けたフレームの内容をバス５００ａに送信する。

フレーム解釈部１５０は、フレーム送受信部１６０よりフレームの値を受け取り、ＣＡＮプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。ＩＤフィールドと判断した値は、不正フレーム検知部１３０へ転送する。また、フレーム解釈部１５０は、ＣＡＮプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部１４０へ通知する。また、フレーム解釈部１５０は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。

不正フレーム検知部１３０は、フレーム解釈部１５０から通知されるＩＤフィールドの値を受け取り、ＩＤフィールドの値が不正を示す所定条件に該当するか否かを判定する。即ち不正フレーム検知部１３０は、受信されたフレームにおける所定フィールドの内容が不正を示す所定条件に該当するか否かを判定する言わば判定部として機能する。この不正を示す所定条件は、ＩＤフィールドの値が、正規ＩＤリスト保持部１２０が保持しているメッセージＩＤのリストに載っていないという条件である。即ち、正規ＩＤリスト保持部１２０が保持しているメッセージＩＤのリストに従い、通知されたＩＤフィールドの値（メッセージＩＤ）が不正かどうかの判定を行う。このリスト（つまり後述する正規ＩＤリスト）に載っていないメッセージＩＤを受信した場合は、不正の検知回数をインクリメントするために、受信したメッセージＩＤを不正検知カウンタ保持部１１０へ通知する。また、正規ＩＤリストに載っていないメッセージＩＤを受信した場合は、エラーフレームを送信するように、フレーム生成部１４０へ通知する。また、不正の検知回数が一定回数以上に達した場合に、不正検知カウンタ保持部１１０より通知を受け、該当するメッセージＩＤを発行する不正なＥＣＵが存在することを示すエラー表示メッセージ（フレーム）を送信するようフレーム生成部１４０へ通知する。エラー表示メッセージのメッセージＩＤは予め定められており、このメッセージＩＤのメッセージ（フレーム）をヘッドユニット２００が受信してエラー表示を行うようになっている。このエラー表示メッセージについては便宜上説明を省略していたが、エラー表示メッセージのメッセージＩＤは、ゲートウェイ３００及びヘッドユニット２００が保持する受信ＩＤリスト、及び、後述する正規ＩＤリストに掲載される。但し、図１５、図１６ではエラー表示メッセージについてのメッセージＩＤを省略している。

正規ＩＤリスト保持部１２０は、車載ネットワークシステム１０においてバス５００ａ上を送信されることとなるフレームに含まれるメッセージＩＤを予め規定したリストである正規ＩＤリストを保持する（図１５、図１６参照）。

不正検知カウンタ保持部１１０は、メッセージＩＤ毎に検知回数をカウントするための不正検知カウンタを保持しており、不正フレーム検知部１３０からメッセージＩＤが通知されると、該当する不正検知カウンタをインクリメント（増加）する。不正検知カウンタが一定数（所定回数）以上に達した場合、不正フレーム検知部１３０に一定数を超えたことを通知する。ここでいう一定数（所定回数）の一例は、ＣＡＮプロトコルにおける送信エラーカウンタの取り扱い規則に対応して定められた値である。ＣＡＮプロトコルでは、ＥＣＵがエラーフレームによって送信を阻止する度に送信エラーカウンタが８カウントアップする。そして、この結果として送信ノードにおける送信エラーカウンタが１２８迄カウントアップすれば送信ノードはパッシブ状態に遷移してフレーム送信をしなくなるように規定されている。従って、１２８／８（＝１６）より大きな１７をこの一定数として定めておけば、ＣＡＮプロトコルにおける送信エラーカウンタに係る規則を無視した送信ノード（不正なＥＣＵ）の存在が推定される場合に不正検知ＥＣＵ１００ａからエラー表示メッセージが送信されるようになる。なお、不正なフレームを送信する、不正なＥＣＵが、ＣＡＮプロトコルにおける送信エラーカウンタに係る規則に従うものであった場合には、不正検知ＥＣＵ１００ａによるエラーフレームの送信によって、不正なＥＣＵの送信エラーカウンタは８インクリメントされる。この場合、不正なフレームの送信を繰り返すことで不正なＥＣＵの送信エラーカウンタが１２８まで上昇すると、不正なＥＣＵがパッシブ状態に遷移し、不正なＥＣＵによる不正なフレームの送信が停止することになる。

フレーム生成部１４０は、フレーム解釈部１５０から通知されたエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部１６０へ通知して送信させる。また、フレーム生成部１４０は、不正フレーム検知部１３０から通知されたエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部１６０へ通知して送信させる。更にフレーム生成部１４０は、不正フレーム検知部１３０から通知されたエラー表示メッセージの送信を指示する通知に従い、エラー表示メッセージをフレーム送受信部１６０へ通知して送信させる。

［１．１５ 不正検知ＥＣＵ１００ａの正規ＩＤリスト例］
図１５は、不正検知ＥＣＵ１００ａの正規ＩＤリスト保持部１２０に保持される正規ＩＤリストの一例を示した図である。同図に例示する正規ＩＤリストは、ＩＤ（メッセージＩＤ）の値が「１」、「２」及び「３」のいずれかであるメッセージＩＤを含むフレームがバス５００ａに流れ得ることを示している。

［１．１６ 不正検知ＥＣＵ１００ｂの正規ＩＤリスト例］
図１６は、不正検知ＥＣＵ１００ｂの正規ＩＤリスト保持部１２０に保持される正規ＩＤリストの一例を示した図である。同図に例示する正規ＩＤリストは、ＩＤ（メッセージＩＤ）の値が「１」、「２」、「３」及び「４」のいずれかであるメッセージＩＤを含むフレームがバス５００ｂに流れ得ることを示している。

［１．１７ 不正検知カウンタ保存リスト例］
図１７は、メッセージＩＤ毎の不正検知カウンタの状態の一例を示す図である。同図の例は、メッセージＩＤが「４」の不正検知カウンタだけが、不正を一度検知しており、その他のメッセージＩＤでは一度も検知していないことを示す。即ち、この例はバス５００ａに本来流れるはずがないメッセージＩＤ「４」のメッセージ（フレーム）が一度送信されたことを不正検知ＥＣＵ１００ａが検知し、該当するメッセージＩＤ「４」に対応する不正検知カウンタを１インクリメントした場合を示している。

［１．１８ 不正フレームの検知に係るシーケンス］
以下、上述の構成を備える車載ネットワークシステム１０のバス５００ａに不正なＥＣＵが接続された場合について、バス５００ａに接続された不正検知ＥＣＵ１００ａ、ＥＣＵ４００ａ、ＥＣＵ４００ｂ、ゲートウェイ３００等の動作について説明する。

図１８は、不正検知ＥＣＵ１００ａが不正なフレーム（メッセージ）を検知して、他のＥＣＵによりその不正なフレームに対応した処理がなされることを阻止する動作例を示すシーケンス図である。同図では、不正なＥＣＵが、バス５００ａにメッセージＩＤが「４」でデータフィールド（データ）が「２５５（０ｘＦＦ）」となるデータフレームを送信する場合の例を示している。ここでの各シーケンスは、各種装置における各処理手順（ステップ）を意味する。

まず、不正なＥＣＵは、メッセージＩＤが「４」、データが「２５５（０ｘＦＦ）」となるデータフレームの送信を開始する（シーケンスＳ１００１）。フレームを構成する各ビットの値は、上述したデータフレームフォーマットに従ってＳＯＦ、ＩＤフィールド（メッセージＩＤ）といった順に逐次バス５００ａ上に送出される。

不正なＥＣＵがＩＤフィールド（メッセージＩＤ）までをバス５００ａに送出し終えたときにおいて、不正検知ＥＣＵ１００ａ、ＥＣＵ４００ａ、ＥＣＵ４００ｂ及びゲートウェイ３００はそれぞれメッセージＩＤを受信する（シーケンスＳ１００２）。

ＥＣＵ４００ａ、ＥＣＵ４００ｂ及びゲートウェイ３００はそれぞれ、保持している受信ＩＤリストを用いてメッセージＩＤをチェックする（シーケンスＳ１００３）。このとき、不正検知ＥＣＵ１００ａは、保持している正規ＩＤリストを用いてメッセージＩＤをチェックする（シーケンスＳ１００４）。即ち、不正検知ＥＣＵ１００ａは、送信されたフレームにおけるＩＤフィールドの内容が、不正を示す所定条件（正規ＩＤリストに掲載されていないこと）に該当するか否かを判定する。

シーケンスＳ１００３において、ＥＣＵ４００ａ及びＥＣＵ４００ｂは、それぞれが保持している受信ＩＤリストに「４」が含まれていないため（図９参照）、受信を終了する。つまりこれ以上不正なＥＣＵが送信を継続するフレームの解釈をせずフレームに対応した処理を行わない。また、シーケンスＳ１００３においてゲートウェイ３００は、保持している受信ＩＤリストに「４」が含まれているため（図５参照）、受信を継続する。また、シーケンスＳ１００４において不正検知ＥＣＵ１００ａは、保持している正規ＩＤリストに「４」が含まれていないため、不正なメッセージＩＤであると判断して、続いてエラーフレームの発行準備を開始する（シーケンスＳ１００５）。

シーケンスＳ１００３に続いて、ゲートウェイ３００はフレームの受信を継続する。例えば、不正検知ＥＣＵ１００ａがエラーフレームの発行準備をしている間に、不正なＥＣＵからはバス５００ａ上にＩＤフィールドより後の部分であるＲＴＲ、コントロールフィールド（ＩＤＥ、ｒ、ＤＬＣ）が逐次送出され、続いてデータフィールドが１ビットずつ逐次送出される。ゲートウェイ３００はこのＲＴＲ、コントロールフィールド（ＩＤＥ、ｒ、ＤＬＣ）を受信し、続いてデータフィールドの受信を開始する（シーケンスＳ１００６）。

次にエラーフレームの発行準備が終わって、不正検知ＥＣＵ１００ａがエラーフレームを送信する（シーケンスＳ１００７）。このエラーフレームの送信は、不正なフレームの最後尾が送信される前（例えばＣＲＣシーケンスの最後尾が送信される前等）に行われる。この動作例においては、データフィールドの途中で行われる。このエラーフレームの送信が開始されることによりバス５００ａでは、不正なＥＣＵから送信中のフレームのデータフィールドの途中部分がエラーフレーム（優先されるドミナントのビット列）により上書きされることになる。

シーケンスＳ１００７において送信されたエラーフレームを受信したゲートウェイ３００は、データフィールドの受信途中で不正なＥＣＵが送信していたフレームの受信を中止する（シーケンスＳ１００８）。つまり、ゲートウェイ３００は、不正なＥＣＵからのデータフィールドがエラーフレームで上書きされており、エラーフレームを検出するので、不正なＥＣＵが送信していたフレームの受信を継続しない。

不正検知ＥＣＵ１００ａは、エラーフレームを送信する対象となったデータフレームのメッセージＩＤ「４」に対応する不正検知カウンタをインクリメントする（シーケンスＳ１００９）。

インクリメントした結果としてメッセージＩＤ「４」に対応する不正検知カウンタが１７以上となった場合、不正検知ＥＣＵ１００ａは、ヘッドユニット２００に受信されるようにエラー表示を通知するフレーム（エラー表示メッセージ）を送信する（シーケンスＳ１０１０）。この結果としてヘッドユニット２００のフレーム処理部２２０によってエラー表示のための処理がなされＬＣＤ等を介してエラーが報知される。なお、エラーの報知は、ＬＣＤ等への表示の他、音声出力、発光等によるものでも良い。

［１．１９ 実施の形態１の効果］
実施の形態１で示した不正検知ＥＣＵは、送信されたフレーム（データフレーム）が不正なフレームか否かを、フレームのＩＤフィールドについて正規ＩＤリストを用いて判定する。これにより、データフレームにおけるＩＤフィールドによって不正を判定できるため、既存のノード（つまり不正検知ＥＣＵ及び不正なＥＣＵ以外のＥＣＵ）において不正なフレームが解釈されてそのフレームに対応する処理が実行されることを阻止できる。また、データフレームの先頭のＳＯＦに続くＩＤフィールドまで受信するだけで判定ができるため、データフレームの後部等を受信して判定を行う場合よりも、バスのトラフィックを抑えることが可能となる。

また、不正検知ＥＣＵが、不正検知カウンタを用いてエラーフレームを送信した回数をカウントすることで、エラーフレームの受信により不正なメッセージＩＤを送信するノードにおける送信エラーカウンタがＣＡＮプロトコルに従えばパッシブ状態に遷移すべき上限値まで到達していることを検出することができる。これにより、不正なメッセージＩＤを送信するノードが、ＣＡＮプロトコルのエラーカウンタの仕様に準拠しているか否かを判定することが可能となる。

また、不正なフレームの判定を行うノードを不正検知ＥＣＵのみとすることで、既存のネットワーク構成への影響を最小限に抑えることができ、システム全体として処理量、電力消費量を抑えることができる。

なお、上述した車載ネットワークシステム１０における１つ又は複数の不正検知ＥＣＵが、検知を行うか否かを切り替え可能にしても良い。そして、車両の状態が、例えば使用開始から一定期間が経過した等といった一定の場合に限って、不正検知ＥＣＵが不正なメッセージの検知を行わないこととしても良い。これにより、電力消費量を抑えることが可能となり、車載ネットワークシステム１０の電力供給源である車載バッテリーの消費を抑制できる。

（実施の形態２）
以下、本開示の実施の形態として、メッセージＩＤ毎に許容されるデータ範囲に基づいて、他のノード（ＥＣＵ）において不正なフレームに基づく処理が実行されることを阻止するための不正対処方法を実現する不正検知ＥＣＵを含む車載ネットワークシステム１１について説明する。

［２．１ 車載ネットワークシステム１１の全体構成］
図１９は、実施の形態２に係る車載ネットワークシステム１１の全体構成を示す図である。車載ネットワークシステム１１は、実施の形態１で示した車載ネットワークシステム１０の一部を変形したものである。車載ネットワークシステム１１は、バス５００ａ、５００ｂと、不正検知ＥＣＵ２１００ａ、２１００ｂ、ヘッドユニット２００、ゲートウェイ３００、及び、各種機器に接続されたＥＣＵ４００ａ〜４００ｄ等のＥＣＵといったバスに接続された各ノードとを含んで構成される。車載ネットワークシステム１１の構成要素のうち、実施の形態１と同様の機能を有する構成要素は、同じ符号を付して説明を省略する。

不正検知ＥＣＵ２１００ａ、２１００ｂは、それぞれバス５００ａ、バス５００ｂに接続され、ＥＣＵ４００ａ〜４００ｄ等により送信されたフレームが不正であるかどうかを判定し、不正であればエラーフレームを送信する機能を有するＥＣＵである。

［２．２ 不正検知ＥＣＵ２１００ａの構成］
図２０は、不正検知ＥＣＵ２１００ａの構成図である。不正検知ＥＣＵ２１００ａは、フレーム送受信部１６０と、フレーム解釈部２１５０と、不正フレーム検知部２１３０と、データ範囲リスト保持部２１２０と、不正検知カウンタ保持部１１０と、フレーム生成部１４０とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、不正検知ＥＣＵ２１００ａにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。不正検知ＥＣＵ２１００ａは、実施の形態１で示した不正検知ＥＣＵ１００ａの一部を変形したものであり、実施の形態１と同様の機能を有する構成要素は、同じ符号を付して説明を省略する。なお、不正検知ＥＣＵ２１００ｂも不正検知ＥＣＵ２１００ａと同様の構成を備える。

フレーム解釈部２１５０は、実施の形態１で示したフレーム解釈部１５０を変形したものであり、フレーム送受信部１６０よりフレームの値を受け取り、ＣＡＮプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。フレームがデータフレームであると判断した場合においてデータフィールドと判断した値（データ）は、ＩＤフィールドのＩＤ（メッセージＩＤ）と共に、不正フレーム検知部２１３０へ転送する。また、フレーム解釈部２１５０は、ＣＡＮプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部１４０へ通知する。また、フレーム解釈部２１５０は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。

不正フレーム検知部２１３０は、実施の形態１で示した不正フレーム検知部１３０を変形したものであり、フレーム解釈部２１５０から通知されるメッセージＩＤと、データフィールドの値（データ）を受け取り、これらの値が不正を示す所定条件に該当するか否かを判定する。即ち不正フレーム検知部２１３０は、受信されたフレームにおける所定フィールドの内容が不正を示す所定条件に該当するか否かを判定する言わば判定部として機能する。この不正を示す所定条件は、データが、データ範囲リスト保持部２１２０が保持しているデータ範囲リストにメッセージＩＤと対応付けて載っているデータ範囲に入らないという条件である。不正フレーム検知部２１３０は、データ範囲リスト保持部２１２０に保持しているメッセージＩＤ毎のデータ範囲を定めたリストであるデータ範囲リストに従い、不正かどうかの判定を行う。不正フレーム検知部２１３０は、データ範囲リストで示される範囲以外のデータを受信した場合は、不正の検知回数をインクリメントするために、受信したメッセージＩＤを不正検知カウンタ保持部１１０へ通知する。この不正の検知回数が一定回数以上に達した場合において、ヘッドユニット２００で受信されるようにエラー表示メッセージを送信するための制御については実施の形態１で説明した通りであるため、ここでの説明を省略する。また、データ範囲リストで示される範囲以外のデータを受信した場合は、エラーフレームを送信するように、フレーム生成部１４０へ通知する。

データ範囲リスト保持部２１２０は、車載ネットワークシステム１１においてバス上を送信されるデータフレームに含まれるデータ（データフィールドの値）について許容される範囲を予め規定したリストであるデータ範囲リストを保持する（図２１参照）。

［２．３ データ範囲リスト例］
図２１は、不正検知ＥＣＵ２１００ａのデータ範囲リスト保持部２１２０に保持されるデータ範囲リストの一例を示した図である。このデータ範囲リストは、各ＩＤ（メッセージＩＤ）と、そのメッセージＩＤのデータフレームにおけるデータフィールドの値（データ）として許容されるデータ範囲とを対応付けたものである。図２１の例では、メッセージＩＤが「１」のデータフレームについては、データ範囲「０〜１８０」、メッセージＩＤが「２」又は「４」のデータフレームについては、データ範囲「０〜１００」、メッセージＩＤが「３」のデータフレームについて、データ範囲「０、１」をそれぞれ正常としている。

［２．４ 不正フレームの検知に係るシーケンス］
以下、上述の構成を備える車載ネットワークシステム１１のバス５００ａに不正なＥＣＵが接続された場合について、バス５００ａに接続された不正検知ＥＣＵ２１００ａ、ＥＣＵ４００ａ、ＥＣＵ４００ｂ、ゲートウェイ３００等の動作について説明する。

図２２及び図２３は、不正検知ＥＣＵ２１００ａが不正なフレーム（メッセージ）を検知して、他のＥＣＵによりその不正なフレームに対応した処理がなされることを阻止する動作例を示すシーケンス図である。図２２及び図２３では、実施の形態１で示した図１８の場合と同様に、不正なＥＣＵが、バス５００ａにメッセージＩＤが「４」でデータフィールド（データ）が「２５５（０ｘＦＦ）」となるデータフレームを送信する場合の例を示している。実施の形態１で示したシーケンスと同じシーケンスには同じ符号を付しており、ここでは説明を簡略化する。

まず、不正なＥＣＵは、不正なデータフレームの送信を開始する（シーケンスＳ１００１）。不正検知ＥＣＵ２１００ａ、ＥＣＵ４００ａ、ＥＣＵ４００ｂ及びゲートウェイ３００はそれぞれメッセージＩＤを受信する（シーケンスＳ１００２）。ＥＣＵ４００ａ、ＥＣＵ４００ｂ及びゲートウェイ３００はそれぞれ、保持している受信ＩＤリストを用いてメッセージＩＤをチェックする（シーケンスＳ１００３）。ＥＣＵ４００ａ及びＥＣＵ４００ｂは、それぞれが保持している受信ＩＤリストに「４」が含まれていないため（図９参照）、受信を終了する。ゲートウェイ３００は、保持している受信ＩＤリストに「４」が含まれているため（図５参照）、受信を継続しデータフィールドの受信を行う（シーケンスＳ１００６ａ）。同様に不正検知ＥＣＵ２１００ａもデータフィールドの受信を行う（シーケンスＳ１００６ａ）。

シーケンスＳ１００６ａに続いて、不正検知ＥＣＵ２１００ａは、データ範囲リスト（図２１参照）を用いて、データフィールドのデータをチェックする（シーケンスＳ２００１）。即ち、不正検知ＥＣＵ２１００ａは、送信されたフレームにおけるＩＤフィールドの内容が、不正を示す所定条件（データ範囲リストに記載されているデータの範囲に入らないこと）に該当するか否かを判定する。不正検知ＥＣＵ２１００ａは、データ範囲リストにおいてＩＤ「４」に対応する「２５５（０ｘＦＦ）」の値が記載されていないため、不正なデータフレームであると判断し、続いてエラーフレームの発行準備を開始する（シーケンスＳ１００５）。

不正検知ＥＣＵ２１００ａがエラーフレームの発行準備をしている間に、不正なＥＣＵからはバス５００ａ上にデータフィールドより後の部分であるＣＲＣフィールド（ＣＲＣシーケンス及びＣＲＣデリミタ）が１ビットずつ逐次送出される。ゲートウェイ３００はこのＣＲＣフィールドの受信を開始する（シーケンスＳ２００２）。

次にエラーフレームの発行準備が終わって、不正検知ＥＣＵ２１００ａがエラーフレームを送信する（シーケンスＳ１００７）。このエラーフレームの送信が開始されることによりバス５００ａでは、不正なＥＣＵから送信中のフレームのＣＲＣシーケンスの途中部分がエラーフレーム（優先されるドミナントのビット列）により上書きされることになる。

シーケンスＳ１００７において送信されたエラーフレームを受信したゲートウェイ３００は、ＣＲＣシーケンスを含むＣＲＣフィールドの受信途中で、不正なＥＣＵが送信していたデータフレームの受信を中止する（シーケンスＳ２００３）。つまり、ゲートウェイ３００は、不正なＥＣＵからのＣＲＣシーケンスがエラーフレームで上書きされており、エラーフレームを検出するので、不正なＥＣＵが送信していたデータフレームの受信を継続しない。

不正検知ＥＣＵ２１００ａは、エラーフレームを送信する対象となったデータフレームのＩＤ「４」に対応する不正検知カウンタをインクリメントする（シーケンスＳ１００９）。インクリメントした結果としてＩＤ「４」に対応する不正検知カウンタが１７以上となった場合、不正検知ＥＣＵ２１００ａは、エラー表示メッセージを送信する（シーケンスＳ１０１０）。

［２．５ 実施の形態２の効果］
実施の形態２で示した不正検知ＥＣＵは、送信されたフレームが不正なフレームか否かを、フレーム（データフレーム）のＩＤフィールド及びデータフィールドについてデータ範囲リストを用いて判定する。これにより、データフレームにおけるＩＤフィールドとデータフィールドとの組み合わせによって不正を判定できるため、既存のＥＣＵ（つまり不正検知ＥＣＵ及び不正なＥＣＵ以外のＥＣＵ）において不正なフレームが解釈されてそのフレームに対応する処理が実行されることを阻止することができる。また、データフレームのデータフィールドまで受信するだけで判定ができるため、データフレームの後部を受信して判定を行う場合よりも、バスのトラフィックを抑えることが可能となる。

また、不正検知ＥＣＵが、不正検知カウンタを用いてエラーフレームを送信した回数をカウントすることで、エラーフレームの受信により不正なメッセージＩＤを送信するノードにおける送信エラーカウンタがＣＡＮプロトコルに従えばパッシブ状態に遷移すべき上限値まで到達していることを検出することができる。これにより、不正なメッセージＩＤを送信するノードが、ＣＡＮプロトコルのエラーカウンタの仕様に準拠しているか否かを判定することが可能となる。

また、不正なフレームの判定を行うノードを不正検知ＥＣＵのみとすることで、既存のネットワーク構成への影響を最小限に抑えることができ、システム全体として処理量、電力消費量を抑えることができる。

なお、上述した車載ネットワークシステム１１における１つ又は複数の不正検知ＥＣＵが、検知を行うか否かを切り替え可能にしても良い。そして、車両の状態が、例えば使用開始から一定期間が経過した等といった一定の場合に限って、不正検知ＥＣＵが不正なメッセージの検知を行わないこととしても良い。これにより、電力消費量を抑えることが可能となる。

（実施の形態３）
以下、本開示の実施の形態として、メッセージＩＤ、データ及びカウンタ値から算出されるメッセージ認証コード（ＭＡＣ：Message Authentication Code）を用いて、他のノード（ＥＣＵ）において不正なフレームに基づく処理が実行されることを阻止するための不正対処方法を実現する不正検知ＥＣＵを含む車載ネットワークシステム１２について説明する。

［３．１ 車載ネットワークシステム１２の全体構成］
図２４は、実施の形態３に係る車載ネットワークシステム１２の全体構成を示す図である。車載ネットワークシステム１２は、実施の形態１で示した車載ネットワークシステム１０の一部を変形したものである。車載ネットワークシステム１２は、バス５００ａ、５００ｂと、不正検知ＥＣＵ３１００ａ、３１００ｂ、ヘッドユニット２００、ゲートウェイ３００、及び、各種機器に接続されたＥＣＵ３４００ａ〜３４００ｄ等のＥＣＵといったバスに接続された各ノードとを含んで構成される。車載ネットワークシステム１２の構成要素のうち、実施の形態１と同様の機能を有する構成要素は、同じ符号を付して説明を省略する。

不正検知ＥＣＵ３１００ａ、３１００ｂは、それぞれバス５００ａ、バス５００ｂに接続され、ＥＣＵ３４００ａ〜３４００ｄ等により送信されたフレームが不正であるかどうかを判定し、不正であればエラーフレームを送信する機能を有するＥＣＵである。

ＥＣＵ３４００ａ〜３４００ｄは、いずれかのバスと接続され、また、それぞれエンジン４０１、ブレーキ４０２、ドア開閉センサ４０３、窓開閉センサ４０４に接続されている。ＥＣＵ３４００ａ〜３４００ｄのそれぞれは、接続されている機器（エンジン４０１等）の状態を取得し、定期的に状態を表すデータフレームをネットワーク（つまりバス）に送信している。送信されるデータフレームのデータフィールドには、メッセージＩＤとデータ値と送信毎にインクリメントされるカウンタ値とから計算により導出されるメッセージ認証コード（ＭＡＣ）が付与される。

［３．２ ＥＣＵ３４００ａの構成］
図２５は、ＥＣＵ３４００ａの構成図である。ＥＣＵ３４００ａは、フレーム送受信部４６０と、フレーム解釈部４５０と、受信ＩＤ判断部４３０と、受信ＩＤリスト保持部４４０と、フレーム処理部４１０と、フレーム生成部３４２０と、データ取得部４７０と、ＭＡＣ生成部３４１０と、ＭＡＣ鍵保持部３４３０と、カウンタ保持部３４４０とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、ＥＣＵ３４００ａにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。ＥＣＵ３４００ａは、実施の形態１で示したＥＣＵ４００ａの一部を変形したものであり、実施の形態１と同様の機能を有する構成要素は、同じ符号を付して説明を省略する。

フレーム生成部３４２０は、実施の形態１で示したフレーム生成部４２０の一部を変形したものである。フレーム生成部３４２０は、フレーム解釈部４５０から通知されたエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部４６０へ通知して送信させる。また、フレーム生成部３４２０は、データ取得部４７０より通知されたデータの値と予め定められたメッセージＩＤとをＭＡＣ生成部３４１０へ通知して、算出されたＭＡＣを受け取る。フレーム生成部３４２０は、予め定められたメッセージＩＤとデータ取得部４７０より通知されたデータの値とＭＡＣ生成部３４１０から受け取ったＭＡＣとを含むようにフレームを構成し（図２６参照）、フレーム送受信部４６０へ通知する。

ＭＡＣ生成部３４１０は、フレーム生成部３４２０より通知されるメッセージＩＤとデータの値と、カウンタ保持部３４４０で保持するカウンタ値とを結合した値（結合値）に対し、ＭＡＣ鍵保持部３４３０で保持するＭＡＣ鍵を用いて、ＭＡＣを算出（計算により導出）して、この算出した結果であるＭＡＣをフレーム生成部３４２０へと通知する。ここではＭＡＣの計算方法として、ＨＭＡＣ（Hash-based Message Authentication Code)（非特許文献２参照）を採用し、上述した結合値に対し、所定のブロック分（例えば４ｂｙｔｅｓ）までパディングした値でＭＡＣ鍵を使って計算し、出てきた計算結果の先頭４ｂｙｔｅｓをＭＡＣとする。なお、ここでは、ＭＡＣを算出するために用いる結合値は、メッセージＩＤとデータの値とカウンタ保持部３４４０で保持するカウンタ値とを使用しているが、これらの３つのうち、いずれか１つ又は２つの組み合わせを用いてＭＡＣを算出しても良い。

ＭＡＣ鍵保持部３４３０は、ＭＡＣを計算するため必要となるＭＡＣ鍵を保持する。

カウンタ保持部３４４０は、ＭＡＣを計算するために必要となるカウンタ値を保持する。なお、このカウンタ値は、フレーム送受信部４６０においてデータフレームが正常に送信された度にインクリメントされる。

なお、ＥＣＵ３４００ｂ〜３４００ｄは、それぞれ実施の形態１で示したＥＣＵ４００ｂ〜４００ｄの一部を変形したものであり、上述したＥＣＵ３４００ａと基本的に同様の構成を備える。但し、受信ＩＤリスト保持部４４０に保持される受信ＩＤリストはＥＣＵ毎に異なる内容となり得る。例えばＥＣＵ３４００ａ及びＥＣＵ３４００ｂは図９に例示する受信ＩＤリストを保持し、ＥＣＵ３４００ｃ及びＥＣＵ３４００ｄは図５に例示する受信ＩＤリストを保持する。また、フレーム処理部４１０の処理内容は、実施の形態１で示したようにＥＣＵ毎に異なる。以下、ＥＣＵ３４００ａ〜３４００ｄのそれぞれが送信するフレームの内容について図２６〜図２９を用いて説明する。

［３．３ エンジンに係るＥＣＵ３４００ａの送信フレーム例］
図２６は、エンジン４０１に接続されたＥＣＵ３４００ａから送信されるデータフレームにおけるＩＤ（メッセージＩＤ）及びデータフィールド（データ）の一例を示す図である。ＥＣＵ３４００ａが送信するフレームのメッセージＩＤは「１」である。データは、同図において１バイト毎に空白で区分して表しており、先頭の１ｂｙｔｅが時速（ｋｍ／時）を表し、次の１ｂｙｔｅはカウンタ値を表し、次の４ｂｙｔｅｓがＭＡＣを表す。なお、図２６の例においてＭＡＣは１６進数で表記している。先頭１ｂｙｔｅの時速（ｋｍ／時）は、最低０（ｋｍ／時）〜最高１８０（ｋｍ／時）までの範囲の値を取る。図２６の上行から下行へと、ＥＣＵ３４００ａから逐次送信される各フレームに対応する各メッセージＩＤ及びデータを例示しており、カウンタ値が次第に増加し、時速が０ｋｍ／時から１ｋｍ／時ずつ加速されている様子を表している。

［３．４ ブレーキに係るＥＣＵ３４００ｂの送信フレーム例］
図２７は、ブレーキ４０２に接続されたＥＣＵ３４００ｂから送信されるデータフレームにおけるＩＤ（メッセージＩＤ）及びデータフィールド（データ）の一例を示す図である。ＥＣＵ３４００ｂが送信するフレームのメッセージＩＤは「２」である。データは、同図において１バイト毎に空白で区分して表しており、先頭の１ｂｙｔｅがブレーキのかかり具合を割合（％）で表し、次の１ｂｙｔｅはカウンタ値を表し、次の４ｂｙｔｅｓがＭＡＣを表す。なお、図２７の例においてＭＡＣは１６進数で表記している。先頭１ｂｙｔｅのブレーキのかかり具合は、ブレーキを全くかけていない状態を０（％）、ブレーキを最大限かけている状態を１００（％）としたものである。図２７の上行から下行へと、ＥＣＵ３４００ｂから逐次送信される各フレームに対応する各メッセージＩＤ及びデータを例示しており、カウンタ値が次第に増加し、ブレーキについては１００％から徐々にブレーキを弱めている様子を表している。

［３．５ ドア開閉センサに係るＥＣＵ３４００ｃの送信フレーム例］
図２８は、ドア開閉センサ４０３に接続されたＥＣＵ３４００ｃから送信されるデータフレームにおけるＩＤ（メッセージＩＤ）及びデータフィールド（データ）の一例を示す図である。ＥＣＵ３４００ｃが送信するフレームのメッセージＩＤは「３」である。データは、同図において１バイト毎に空白で区分して表しており、先頭の１ｂｙｔｅがドアの開閉状態を表し、次の１ｂｙｔｅはカウンタ値を表し、次の４ｂｙｔｅｓがＭＡＣを表す。なお、図２８の例においてＭＡＣは１６進数で表記している。先頭１ｂｙｔｅのドアの開閉状態は、ドアが開いている状態を「１」、ドアが閉まっている状態を「０」としたものである。図２８の上行から下行へと、ＥＣＵ３４００ｃから逐次送信される各フレームに対応する各メッセージＩＤ及びデータを例示しており、カウンタ値が次第に増加し、ドアが開いている状態から次第に閉められた状態へと移った様子を表している。

［３．６ 窓開閉センサに係るＥＣＵ３４００ｄの送信フレーム例］
図２９は、窓開閉センサ４０４に接続されたＥＣＵ３４００ｄから送信されるデータフレームにおけるＩＤ（メッセージＩＤ）及びデータフィールド（データ）の一例を示す図である。ＥＣＵ３４００ｄが送信するフレームのメッセージＩＤは「４」である。データは、同図において１バイト毎に空白で区分して表しており、先頭の１ｂｙｔｅが窓の開閉状態を割合（％）で表し、次の１ｂｙｔｅはカウンタ値を表し、次の４ｂｙｔｅｓがＭＡＣを表す。なお、図２９の例においてＭＡＣは１６進数で表記している。先頭１ｂｙｔｅの窓の開閉状態は、窓が完全に閉まっている状態を０（％）、窓が全開の状態を１００（％）としたものである。図２９の上行から下行へと、ＥＣＵ３４００ｄから逐次送信される各フレームに対応する各メッセージＩＤ及びデータを例示しており、カウンタ値が次第に増加し、窓が閉まっている状態から徐々に開いていく様子を表している。

［３．７ 不正検知ＥＣＵ３１００ａの構成］
図３０は、不正検知ＥＣＵ３１００ａの構成図である。不正検知ＥＣＵ３１００ａは、フレーム送受信部１６０と、フレーム解釈部３１５０と、不正ＭＡＣ検知部３１３０と、ＭＡＣ鍵保持部３１８０と、カウンタ保持部３１９０と、フレーム生成部１４０と、ＭＡＣ生成部３１７０と、不正検知カウンタ保持部１１０から構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、不正検知ＥＣＵ３１００ａにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。不正検知ＥＣＵ３１００ａは、実施の形態１で示した不正検知ＥＣＵ１００ａの一部を変形したものであり、実施の形態１と同様の機能を有する構成要素は、同じ符号を付して説明を省略する。なお、不正検知ＥＣＵ３１００ｂも同様の構成である。

フレーム解釈部３１５０は、実施の形態１で示したフレーム解釈部１５０を変形したものであり、フレーム送受信部１６０よりフレームの値を受け取り、ＣＡＮプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。フレームがデータフレームであると判断した場合においてデータフィールドと判断した値（データ）は、ＩＤフィールドのＩＤ（メッセージＩＤ）と共に、不正ＭＡＣ検知部３１３０へ転送する。また、フレーム解釈部３１５０は、ＣＡＮプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部１４０へ通知する。また、フレーム解釈部３１５０は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。

不正ＭＡＣ検知部３１３０は、フレーム解釈部３１５０から通知されるメッセージＩＤと、データフィールドの値（データ）を受け取ってデータフィールド中のＭＡＣを検証する機能を有する。不正ＭＡＣ検知部３１３０は、通知されたメッセージＩＤ及びデータフィールドの値を、ＭＡＣ生成部３１７０へと通知し、ＭＡＣ生成部３１７０により生成されたＭＡＣを取得する。不正ＭＡＣ検知部３１３０は、データフィールドのデータが不正を示す所定条件に該当するか否かを判定する。即ち不正ＭＡＣ検知部３１３０は、受信されたフレームにおける所定フィールドの内容が不正を示す所定条件に該当するか否かを判定する言わば判定部として機能する。この不正を示す所定条件は、定められた検証処理手順（ＭＡＣの生成、ＭＡＣの比較等を含む手順）での検証に失敗することであり、つまり、データに含まれるＭＡＣが、ＭＡＣ生成部３１７０により生成されたＭＡＣと相違するという条件である。不正ＭＡＣ検知部３１３０は、ＭＡＣ生成部３１７０から取得したＭＡＣと、データフィールド中のＭＡＣとを比較することで、不正かどうかの判定（即ちＭＡＣの検証）を行う。両ＭＡＣの値の比較の結果、不一致の場合は、不正の検知回数をインクリメントするために、受信したメッセージＩＤを不正検知カウンタ保持部１１０へ通知する。この不正の検知回数が一定回数以上に達した場合において、ヘッドユニット２００で受信されるようにエラー表示メッセージを送信するための制御については実施の形態１で説明した通りであるため、ここでの説明を省略する。また、両ＭＡＣの値の比較の結果、不一致の場合は、エラーフレームを送信するように、フレーム生成部１４０へ通知する。ＭＡＣ値の比較の結果、一致する場合は、カウンタ保持部３１９０が保持する、メッセージＩＤに対応するカウンタ値をインクリメントするようにＭＡＣ生成部３１７０へ通知する。

ＭＡＣ生成部３１７０は、不正ＭＡＣ検知部３１３０より通知されたメッセージＩＤを使って、ＭＡＣ鍵保持部３１８０より、対応するＭＡＣ鍵を取得し、カウンタ保持部３１９０より対応するカウンタをそれぞれ取得する。ＭＡＣ生成部３１７０は、不正ＭＡＣ検知部３１３０より通知されたデータフィールドの値（先頭１ｂｙｔｅの値）と、カウンタ保持部３１９０より取得したカウンタ値に対して、ＭＡＣ鍵保持部３１８０より取得したＭＡＣ鍵を使ってＭＡＣを算出（計算により導出）し、算出したＭＡＣを不正ＭＡＣ検知部３１３０へ通知する。なお、不正検知ＥＣＵ３１００ａ、３１００ｂ及びＥＣＵ３４００ａ〜３４００ｄのいずれにおいても、ＭＡＣ鍵を用いてＭＡＣを算出するアルゴリズムは同一のものを用いる。

ＭＡＣ鍵保持部３１８０は、ＭＡＣを計算するため必要となるＭＡＣ鍵をメッセージＩＤ毎に対応付けて保持する。このＭＡＣ鍵保持部３１８０が保持するＭＡＣ鍵は、対応付けられたメッセージＩＤ毎に異なる値である。なお、ＥＣＵ及び不正検知ＥＣＵにおいて用いられるＭＡＣ鍵は、１つの送信ノードが複数のメッセージＩＤそれぞれのフレームを送信する場合を想定すると、送信ノード毎に異なる鍵であることとしても良い。また、ＭＡＣ鍵は、例えば同一のバス上で送信されるフレームに同一の値が用いられるようにしても良いし、異なるバス上であっても同一の鍵（値）としても良いし、車一台あたり同一の鍵としても良く、同一車種で同一の鍵としても良く、同一製造メーカ毎に同一の鍵としても良く、異なる製造メーカであっても同一の鍵としても良い。

カウンタ保持部３１９０は、ＭＡＣ値を計算するために必要となるカウンタ値をメッセージＩＤ毎に保持する。このカウンタ値は、フレームを正常に受信した場合（つまり不正ＭＡＣ検知部３１３０において比較した両ＭＡＣが一致する場合）には、インクリメントされる。

［３．８ カウンタ値の例］
図３１は、カウンタ保持部３１９０に保持されているメッセージＩＤ毎のカウンタ値の一例を示す図である。同図では、メッセージＩＤが「１」のカウンタが１回、メッセージＩＤが「２」のカウンタが１０回、メッセージＩＤが「３」のカウンタが１５回、メッセージＩＤが「４」のカウンタが１００回をそれぞれ示している。この各メッセージＩＤに対応するカウンタ値は、そのメッセージＩＤを含むフレームが正常に受信されている回数を表している。

［３．９ 不正フレームの検知に係るシーケンス］
以下、上述の構成を備える車載ネットワークシステム１２のバス５００ａに不正なＥＣＵが接続された場合について、バス５００ａに接続された不正検知ＥＣＵ３１００ａ、ＥＣＵ３４００ａ、ＥＣＵ３４００ｂ、ゲートウェイ３００等の動作について説明する。

図３２及び図３３は、不正検知ＥＣＵ３１００ａが不正なフレーム（メッセージ）を検知して、他のＥＣＵによりその不正なフレームに対応した処理がなされることを阻止する動作例を示すシーケンス図である。図３２及び図３３では、実施の形態１で示した図１８並びに実施の形態２で示した図２２及び図２３の場合と同様に、不正なＥＣＵが、バス５００ａに接続された例を示している。この不正なＥＣＵは、メッセージＩＤが「４」でデータフィールド（データ）が「０ｘＦＦ ＦＦ ＦＦＦＦＦＦＦＦ」（６ｂｙｔｅｓ）となるデータフレームを送信する。実施の形態１又は２で示したシーケンスと同じシーケンスには同じ符号を付しており、ここでは説明を簡略化する。

まず、不正なＥＣＵは、上述した不正なデータフレームの送信を開始する（シーケンスＳ１００１ａ）。不正検知ＥＣＵ３１００ａ、ＥＣＵ３４００ａ、ＥＣＵ３４００ｂ及びゲートウェイ３００はそれぞれメッセージＩＤを受信する（シーケンスＳ１００２）。ＥＣＵ３４００ａ、ＥＣＵ３４００ｂ及びゲートウェイ３００はそれぞれ、保持している受信ＩＤリストを用いてメッセージＩＤをチェックする（シーケンスＳ１００３）。ＥＣＵ３４００ａ及びＥＣＵ３４００ｂは、それぞれが保持している受信ＩＤリストに「４」が含まれていないため（図９参照）、受信を終了する。ゲートウェイ３００は、保持している受信ＩＤリストに「４」が含まれているため（図５参照）、受信を継続しデータフィールドの受信を行う（シーケンスＳ１００６ａ）。同様に不正検知ＥＣＵ３１００ａもデータフィールドの受信を行う（シーケンスＳ１００６ａ）。

シーケンスＳ１００６ａに続いて、不正検知ＥＣＵ３１００ａは、データフィールドにおけるデータに含まれるＭＡＣを検証（チェック）する（シーケンスＳ３００１）。即ち、不正検知ＥＣＵ３１００ａは、送信されたフレームにおけるＩＤフィールドの内容が、不正を示す所定条件（ＭＡＣの検証に失敗すること）に該当するか否かを判定する。不正検知ＥＣＵ３１００ａは、不正なＥＣＵにより送信されたデータフレームにおけるデータフィールドの６ｂｙｔｅｓのデータ「０ｘＦＦＦＦＦＦＦＦ」について、後半４ｂｙｔｅｓのＭＡＣと、メッセージＩＤ「４」に対応するＭＡＣ鍵とカウンタを用いて算定したＭＡＣとを比較することでＭＡＣの検証を行う。この比較の結果は不一致になり検証が失敗するので、不正検知ＥＣＵ３１００ａでは、不正なデータフレームであると判断し、続いてエラーフレームの発行準備を開始する（シーケンスＳ１００５）。

不正検知ＥＣＵ３１００ａがエラーフレームの発行準備をしている間に、ゲートウェイ３００はＣＲＣフィールドの受信を開始する（シーケンスＳ２００２）。

次にエラーフレームの発行準備が終わって、不正検知ＥＣＵ３１００ａがエラーフレームを送信する（シーケンスＳ１００７）。このエラーフレームの送信が開始されることによりバス５００ａでは、不正なＥＣＵから送信中のフレームのＣＲＣシーケンスの途中部分がエラーフレームにより上書きされることになる。

シーケンスＳ１００７において送信されたエラーフレームを受信したゲートウェイ３００は、ＣＲＣシーケンスを含むＣＲＣフィールドの受信途中で、不正なＥＣＵが送信していたデータフレームの受信を中止する（シーケンスＳ２００３）。

不正検知ＥＣＵ３１００ａは、エラーフレームを送信する対象となったデータフレームのＩＤ「４」に対応する不正検知カウンタをインクリメントする（シーケンスＳ１００９）。インクリメントした結果としてＩＤ「４」に対応する不正検知カウンタが１７以上となった場合、不正検知ＥＣＵ３１００ａは、エラー表示メッセージを送信する（シーケンスＳ１０１０）。

［３．１０ 実施の形態３の効果］
実施の形態３で示した不正検知ＥＣＵは、送信されたフレームが不正なフレームか否かを、フレーム（データフレーム）のデータフィールドに含ませたＭＡＣを検証することによって判定する。これにより、既存のＥＣＵ（つまり不正検知ＥＣＵ及び不正なＥＣＵ以外のＥＣＵ）において不正なフレームが解釈されてそのフレームに対応する処理が実行されることを阻止することができる。また、データフレームのデータフィールドまで受信するだけで判定ができるため、データフレームの後部を受信して判定を行う場合よりも、バスのトラフィックを抑えることが可能となる。

また、不正検知ＥＣＵが、不正検知カウンタを用いてエラーフレームを送信した回数をカウントすることで、エラーフレームの受信により不正なメッセージＩＤを送信するノードにおける送信エラーカウンタがＣＡＮプロトコルに従えばパッシブ状態に遷移すべき上限値まで到達していることを検出することができる。これにより、不正なメッセージＩＤを送信するノードが、ＣＡＮプロトコルのエラーカウンタの仕様に準拠しているか否かを判定することが可能となる。

また、ＭＡＣの検証を行うノードを不正検知ＥＣＵのみとすることで、不正検知ＥＣＵ以外のＥＣＵで検証する必要がなく、システム全体として処理量、電力消費量を抑えることができる。

なお、上述した車載ネットワークシステム１２における１つ又は複数の不正検知ＥＣＵが、検知を行うか否かを切り替え可能にしても良い。そして、車両の状態が、例えば使用開始から一定期間が経過した等といった一定の場合に限って、不正検知ＥＣＵが不正なメッセージの検知を行わないこととしても良い。これにより、電力消費量を抑えることが可能となる。

（実施の形態４）
以下、本開示の実施の形態として、車両の状態に応じて不正なメッセージ（フレーム）を検知する特定の検知処理を実行するか否かに係る不正検知ＥＣＵの動作モードを切り替えるための不正検知方法を実現する車載ネットワークシステム１３について説明する。

［４．１ 車載ネットワークシステム１３の全体構成］
図３４は、実施の形態４に係る車載ネットワークシステム１３の全体構成を示す図である。車載ネットワークシステム１３は、実施の形態１で示した車載ネットワークシステム１０の一部を変形したものである。車載ネットワークシステム１３は、バス５００ａ〜５００ｃと、不正検知ＥＣＵ４１００ａ、４１００ｂ、ヘッドユニット４２００、ゲートウェイ３００、及び、各種機器に接続されたＥＣＵ４００ａ〜４００ｄ等のＥＣＵといったバスに接続された各ノードとを含んで構成される。車載ネットワークシステム１３の構成要素のうち、実施の形態１と同様の機能を有する構成要素は、同じ符号を付して説明を省略する。

不正検知ＥＣＵ４１００ａ、４１００ｂは、それぞれバス５００ａ、バス５００ｂに接続され、ＥＣＵ４００ａ〜４００ｄ等により送信されたフレーム（メッセージ）が不正であるかどうかを判定し、不正であればエラーフレームを送信する機能を有するＥＣＵである。不正検知ＥＣＵ４１００ａ、４１００ｂは、それぞれ実施の形態１で示した不正検知ＥＣＵ１００ａ、１００ｂの一部を変形したものである。不正検知ＥＣＵ４１００ａ、４１００ｂは動作モードとして、ＥＣＵ４００ａ〜４００ｄが送信するフレーム（メッセージ）が不正であるかどうかを判定するチェックモード（検知モード）と、ＥＣＵ４００ａ〜ｄが送信するフレーム（メッセージ）が不正であるかどうかを判定しない待機モードとを持つ。そして不正検知ＥＣＵ４１００ａ、４１００ｂは、ヘッドユニット４２００からの指示（トリガーフレーム）を受けて、動作モードを切り替える機能を有する。トリガーフレームは動作モードの切り替えのトリガーとなる切替指示メッセージである。動作モードを待機モードにした場合には、不正なメッセージの検知に係る一定の処理を省略するため、チェックモードの場合と比べて処理量の軽減、消費電力の抑制等が実現され得る。

ヘッドユニット４２００は、フレームを送受信する機能を持ち、ＥＣＵ４００ａ〜４００ｄから送信されるフレームを受信し、各種状態をディスプレイ（図示しない）に表示して、ユーザに提示する機能を有する。ヘッドユニット４２００は、実施の形態１で示したヘッドユニット２００の一部を変形したものである。ヘッドユニット４２００は、例えばＥＣＵ４００ａ〜４００ｄが送信するフレームが不正であるかどうかを判定し、不正なフレームが送信された場合に不正検知ＥＣＵ４１００ａ、４１００ｂへチェックモードへの切り替えを指示する機能を有する。即ち、ヘッドユニット４２００は、車両の状態が一定条件を満たす場合に、不正検知ＥＣＵ４１００ａ、４１００ｂへトリガーフレームを送信して動作モードを変更するように指示する機能を有する。一定条件は、不正検知ＥＣＵにより不正なメッセージを検知する必要性の高さを左右する事象の発生を判断するための条件である。動作モードをチェックモードに切り替える場合の一定条件としては、例えば、車両に搭載された車載ネットワークシステムにおいて、不正なメッセージが伝送されたことが検知された場合、車両の使用が開始された場合、車両の外部の装置と通信を開始する状態になった場合等が挙げられる。また、動作モードを待機モードに切り替える場合の一定条件としては、例えば、一定期間において不正なメッセージが検知されなかった場合、車両の使用が開始されてから一定時間が経過した場合、車両の外部の装置と通信を終了して一定状態となった場合等のそれぞれ又は複数の組み合わせ等が挙げられる。

なお、本実施の形態では、ゲートウェイ３００は、バス５００ａ〜５００ｃ間で、トリガーフレームを転送するものとする。

［４．２ ヘッドユニット４２００の構成］
図３５は、ヘッドユニット４２００の構成図である。ヘッドユニット４２００は、フレーム送受信部２７０と、フレーム解釈部４２６０と、受信ＩＤ判断部２４０と、受信ＩＤリスト保持部２５０と、フレーム処理部２２０と、表示制御部２１０と、フレーム生成部４２３０と、不正フレーム検出部４２８０と、モード変更指示部４２８１と、車使用開始検出部４２８２と、通信開始・終了検出部４２８３とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、ヘッドユニット４２００における通信回路、ＬＣＤ、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。なお、実施の形態１と同様の機能を有する構成要素は、同じ符号を付して説明を省略する。

フレーム解釈部４２６０は、実施の形態１で示したフレーム解釈部２６０の一部を変形したものである。フレーム解釈部４２６０は、フレーム送受信部２７０よりフレームの値を受け取り、ＣＡＮプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。フレーム解釈部４２６０は、ＩＤフィールドと判断した値は受信ＩＤ判断部２４０へ転送する。フレーム解釈部４２６０は、受信ＩＤ判断部２４０から通知される判定結果に応じて、ＩＤフィールドの値と、ＩＤフィールド以降に現れるデータフィールドとを、フレーム処理部２２０及び不正フレーム検出部４２８０へ転送するか、その判定結果を受けた以降においてフレームの受信を中止する（つまりそのフレームとしての解釈を中止する）かを決定する。また、フレーム解釈部４２６０は、ＣＡＮプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部４２３０へ通知する。また、フレーム解釈部４２６０は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。例えばデータフレームの途中からエラーフレームと解釈された場合においては、そのデータフレームの解釈は中止され、そのデータフレームに応じて特段の処理を行うことがなくなる。

フレーム送受信部２７０は、バス５００ｃに対して、ＣＡＮプロトコルに従ったフレームを送受信する。バス５００ｃからフレームを１ｂｉｔずつ受信し、フレーム解釈部４２６０に転送する。また、フレーム生成部４２３０より通知を受けたフレームの内容をバス５００ｃに１ｂｉｔずつ送信する。

受信ＩＤ判断部２４０は、フレーム解釈部４２６０から通知されるＩＤフィールドの値を受け取り、受信ＩＤリスト保持部２５０が保持しているメッセージＩＤのリストに従い、そのＩＤフィールド以降のフレームの各フィールドを受信するかどうかの判定を行う。この判定結果を、受信ＩＤ判断部２４０は、フレーム解釈部４２６０へ通知する。

フレーム生成部４２３０は、実施の形態１のフレーム生成部２３０と同様に、フレーム解釈部４２６０からのエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部２７０へ通知して送信させる。更に、フレーム生成部４２３０は、モード変更指示部４２８１からのトリガーフレームの送信の依頼に従い、トリガーフレームを構成し、トリガーフレームをフレーム送受信部２７０へ通知して送信させる。

不正フレーム検出部４２８０は、フレーム解釈部４２６０から通知されるＩＤフィールドの値とデータフィールドの値とを受け取り、不正なフレームがバス５００ｃ上に送信された場合に検出する。不正フレーム検出部４２８０は、不正なフレームを検出した場合に、モード変更指示部４２８１へ不正検知ＥＣＵ４１００ａ、４１００ｂのチェックモードへの移行指示の通知を依頼する。不正フレーム検出部４２８０は、チェックモードへの移行指示の通知を依頼してから一定期間において不正なフレームを検出しなかった場合に、モード変更指示部４２８１へ不正検知ＥＣＵ４１００ａ、４１００ｂの待機モードへの移行指示の通知を依頼しても良い。不正フレーム検出部４２８０における不正フレームの検出方法は、例えば、実施の形態１の不正フレーム検知部１３０と同じ方法である。また、不正フレーム検出部４２８０における不正フレームの検出方法は、例えば実施の形態２の不正フレーム検知部２１３０と同じ方法、実施の形態３の不正ＭＡＣ検知部３１３０と同じ方法、或いは、その他の方法であっても良い。

モード変更指示部４２８１は、不正検知ＥＣＵ４１００ａ、４１００ｂの動作モードの変更を指示するトリガーフレームの不正検知ＥＣＵ４１００ａ、４１００ｂへの送信をフレーム生成部４２３０へ依頼する機能を有する。モード変更指示部４２８１は、車両の状態が一定条件を満たした場合に、不正フレーム検出部４２８０、車使用開始検出部４２８２或いは通信開始・終了検出部４２８３から依頼を受けて、フレーム生成部４２３０にトリガーフレームの送信の依頼を行う。このトリガーフレームは不正検知ＥＣＵの動作モードの切り替えのトリガーとなる切替指示メッセージである。トリガーフレームには、待機モードからチェックモードへの移行を指示するものと、チェックモードから待機モードへの移行を指示するものとがあり、両者は例えばＩＤフィールドのメッセージＩＤ、データフィールド内に設けた識別子等で区別される。トリガーフレームが送信されると、ゲートウェイ３００はバス間でトリガーフレームを転送し、各不正検知ＥＣＵがトリガーフレームを受信する。

車使用開始検出部４２８２は、車両の使用が開始されたことを検出し、モード変更指示部４２８１へ、不正検知ＥＣＵ４１００ａ、４１００ｂのチェックモードへの移行指示の通知を依頼する。車使用開始検出部４２８２は、車両の使用が開始されたことの検出を、例えば、各ＥＣＵからのメッセージ等により、ドアロックの解除、ドアのオープン、エンジンの始動等を検知することで実現する。この結果として、例えば、駐車場に駐車された車両に不正ＥＣＵが取り付けられた場合にも、その後に車両が使用開始された際に、不正検知ＥＣＵ４１００ａ、４１００ｂがチェックモードとなり不正ＥＣＵの検出が行えるようになる。なお、車両の使用開始前においてもバッテリー等から電力が供給されていれば車載ネットワークシステムは稼動し得る。また、車使用開始検出部４２８２は、車両の使用が開始されたことを検出してから一定時間が経過したことを検出し、モード変更指示部４２８１へ、不正検知ＥＣＵ４１００ａ、４１００ｂの待機モードへの移行指示の通知を依頼する。この一定時間は、車両の使用開始前に仮に不正なＥＣＵが車載ネットワークシステムのバスに接続されていたとした場合において車両の使用開始後にその不正なＥＣＵが不正なメッセージを送信するのに要すると想定される時間より長い時間（例えば数分間）である。

通信開始・終了検出部４２８３は、ヘッドユニット４２００が外部と通信を開始したことを検出し、モード変更指示部４２８１へ、不正検知ＥＣＵ４１００ａ、４１００ｂのチェックモードへの移行指示の通知を依頼する。この結果として、例えば、外部から通信によりヘッドユニット４２００を介して不正に車載ネットワークシステムのバス上に不正なフレームが送信された場合に、チェックモードの不正検知ＥＣＵ４１００ａ、４１００ｂにより不正の検出が行える。なお、外部からの通信によりヘッドユニット４２００の制御プログラムが不正に書き換えられて、不正フレーム検出部４２８０、モード変更指示部４２８１等が機能しなくなることが想定される。しかし、外部との通信の前に、不正検知ＥＣＵ４１００ａ、４１００ｂへチェックモードへの移行を指示しておくことで、不正フレーム検出部４２８０、モード変更指示部４２８１等が機能しなくなっても、不正なフレームを検出できる。また、通信開始・終了検出部４２８３は、ヘッドユニット４２００が外部との通信を終了した後の一定状態になったことを検出し、モード変更指示部４２８１へ、不正検知ＥＣＵ４１００ａ、４１００ｂの待機モードへの移行指示の通知を依頼する。外部との通信を終了した後の一定状態は、例えば外部との通信を終了した状態である。また、外部との通信を終了した後の一定状態は、外部との通信を終了した後に一定時間が経過した状態であるとしても良い。これにより、外部との通信により不正に書き換えられた制御プログラムが外部との通信の終了後に不正なフレームを送信するような場合に対応できる。この場合における一定時間は、外部との通信で外部から不正なプログラム等が供給された場合において通信終了後にそのプログラムが実行されて不正なメッセージを送信するのに要すると想定される時間より長い時間（例えば数分間）である。

なお、モード変更指示部４２８１は、不正フレーム検出部４２８０、車使用開始検出部４２８２及び通信開始・終了検出部４２８３と連携して、一定期間において不正なメッセージが検知されなかった状況であり、かつ、車両の使用が開始されてから一定時間が経過した状況であり、かつ、車両の外部の装置と通信を終了して一定状態となった状況である場合に限って待機モードへの移行を指示するトリガーフレームの送信をフレーム生成部４２３０に依頼することとしても良い。モード変更指示部４２８１は、車両の状態に応じてどのような条件が満たされたらトリガーフレームの送信を依頼するかについて、判断基準となる予め定められたルールを保持し得る。このルールは、単一でも複数であっても良い。また、ルールは、ヘッドユニット４２００の出荷時、車載ネットワークシステムを搭載する車両の出荷時、販売時等に設定され得る。また、ヘッドユニット４２００が外部から通信によりルールを取得及び更新しても良い。また、ヘッドユニット４２００を、ルールを保持する記録媒体が着脱自在となるように構成しても良い。なお、車両の状態として、駐車中、停車中、給油中、充電中、外部との通信中等を検知することを前提としたルールを定めていても良い。トリガーフレームの内容（例えばデータフィールド内）に例えば不正検知ＥＣＵを個別に識別する情報を含ませる等により、特定の不正検知ＥＣＵにだけ動作モードの変更を指示するようにしても良い。例えば、駐車中で外部と通信中に不正なフレームが検出され、不正フレーム検出部４２８０から不正検知ＥＣＵ４１００ａ、４１００ｂのチェックモードへの移行指示の通知を依頼された場合、不正検知ＥＣＵ４１００ｂにのみチェックモードへの移行を指示するトリガーフレームを送信すると判断するルールが設定されていても良い。これは、駐車中であればエンジン４０１やブレーキ４０２の動作に影響を与えるような不正なフレームは送信されない、或いは、不正なフレームが送信されたとしても駐車中であれば問題ないと考えた場合のルールの例である。なお、特定の不正検知ＥＣＵに動作モードの変更を指示するようにトリガーフレームを構成する場合には、ゲートウェイ３００はその特定の不正検知ＥＣＵにトリガーフレームが伝達されるために必要なバスにだけトリガーフレームの転送を行うようにしても良い。

［４．３ 不正検知ＥＣＵ４１００ａの構成］
図３６は、不正検知ＥＣＵ４１００ａの構成図である。不正検知ＥＣＵ４１００ａは、フレーム送受信部１６０と、フレーム解釈部４１５０と、不正フレーム検知部１３０と、正規ＩＤリスト保持部１２０と、不正検知カウンタ保持部１１０と、フレーム生成部１４０と、トリガーフレーム検出部４１７０と、モード保持部４１８０とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、不正検知ＥＣＵ４１００ａにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。実施の形態１と同様の機能を有する構成要素は、同じ符号を付して説明を省略する。なお、不正検知ＥＣＵ４１００ｂも基本的に同様の構成を備える。

フレーム解釈部４１５０は、実施の形態１のフレーム解釈部１５０と同様に、フレーム送受信部１６０よりフレームの値を受け取り、ＣＡＮプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。また、フレーム解釈部４１５０は、モード保持部４１８０から不正検知ＥＣＵ４１００ａの動作モードを取得し、受け取ったフレームの値の転送先を動作モードに応じて判断する。例えば、不正検知ＥＣＵ４１００ａがチェックモードである場合には、ＩＤフィールドの値を不正フレーム検知部１３０とトリガーフレーム検出部４１７０とへ転送し、ＩＤフィールドの後のデータフィールドの値をトリガーフレーム検出部４１７０へ転送する。不正検知ＥＣＵ４１００ａが待機モードである場合には、ＩＤフィールドの値とその後のデータフィールドの値とをトリガーフレーム検出部４１７０へのみ転送する。これにより、動作モードがチェックモードである場合に限って、不正フレーム検知部１３０による不正の検知がなされるようになる。つまり、動作モードが待機モードである場合には、不正フレーム検知部１３０による不正の検知に係る処理が行われない。

トリガーフレーム検出部４１７０は、不正検知ＥＣＵ４１００ａが受信したフレームが、ヘッドユニット４２００が送信したトリガーフレームであるかどうかを判断する。トリガーフレーム検出部４１７０は、不正検知ＥＣＵ４１００ａが受信したフレームがトリガーフレームの場合は、モード保持部４１８０に、動作モードとしてのチェックモード或いは待機モードを記録する。即ち、トリガーフレーム検出部４１７０は、受信されたフレームが待機モードからチェックモードへの移行を指示すトリガーフレームであった場合には、チェックモードであることを記録する。また、トリガーフレーム検出部４１７０は、受信されたフレームがチェックモードから待機モードへの移行を指示するトリガーフレームであった場合には、待機モードであることを記録する。

モード保持部４１８０は、自機（不正検知ＥＣＵ４１００ａ）の動作モードが待機モードであるか、チェックモードであるかをメモリ等の記憶媒体に保持する機能を有する。

［４．４ チェックモードへの移行に係るシーケンス］
以下、上述の構成を備える車載ネットワークシステム１３のバス５００ｃに不正なフレーム（メッセージ）が送信された場合におけるヘッドユニット４２００及び不正検知ＥＣＵ４１００ａの動作について説明する。

図３７は、ヘッドユニット４２００が不正なメッセージを検知し、不正検知ＥＣＵ４１００ａへチェックモードへの移行を指示し、不正検知ＥＣＵ４１００ａがチェックモードへ移行する動作例を示すシーケンス図である。

この動作例の開始段階では、不正検知ＥＣＵ４１００ａは、待機モードになっている（シーケンスＳ４００１）。例えば、この段階以前に待機モードへの移行を指示するトリガーフレームを不正検知ＥＣＵ４１００ａが受けた結果として、待機モードになっている状態である。このとき不正検知ＥＣＵ４１００ａは、不正フレーム検知部１３０による不正なメッセージの検知を行っていない。

ヘッドユニット４２００は、バス５００ｃに送信されたフレーム（メッセージ）を受信する（シーケンスＳ４００２）。

ヘッドユニット４２００は、不正フレーム検出部４２８０により受信したメッセージが、不正なメッセージであるかどうかを確認する（シーケンスＳ４００３）。不正なメッセージでなかった場合には、メッセージの受信の処理手順（シーケンスＳ４００２）へ戻る。

ヘッドユニット４２００は、受信したメッセージが不正なメッセージであることを検出した場合に、以前の不正検知ＥＣＵ４１００ａへの指示履歴から不正検知ＥＣＵ４１００ａの動作モードが既にチェックモードであるか否かを判断する（シーケンスＳ４００４）。なお、不正なメッセージは、例えば不正なＥＣＵがバスに接続されて送信され得る。ヘッドユニット４２００は、トリガーフレームにより不正検知ＥＣＵ４１００ａ等にチェックモードへの移行指示又は待機モードへの移行指示をした場合に指示履歴を保持する等により、各不正検知ＥＣＵの動作モードを把握している。

ヘッドユニット４２００は、不正検知ＥＣＵ４１００ａの動作モードがチェックモードではない（待機モードである）と判断した場合、チェックモードへの移行を指示する（シーケンスＳ４００５）。具体的には、ヘッドユニット４２００は、チェックモードへの移行を指示するトリガーフレームを送信する。なお、シーケンスＳ４００４で不正検知ＥＣＵ４１００ａの動作モードが既にチェックモードであると判断した場合には、ヘッドユニット４２００はチェックモードへの移行の指示の処理手順をスキップして動作を終える。

ヘッドユニット４２００からバス５００ｃに送信されたチェックモードへの移行を指示するトリガーフレームは、ゲートウェイ３００によりバス５００ａ、５００ｂに転送される。

不正検知ＥＣＵ４１００ａは、バス５００ａに送信されたトリガーフレームを受信して、動作モードをチェックモードに移行する（シーケンスＳ４００６）。このときから、不正検知ＥＣＵ４１００ａは、不正フレーム検知部１３０により不正なメッセージの検知を行う。即ち、チェックモードでは、不正検知ＥＣＵ４１００ａは、他のノード（ＥＣＵ）において不正なフレームに基づく処理が実行されることを阻止するための不正対処方法を実現する状態になる。従って、実施の形態１で示したように、不正検知ＥＣＵ４１００ａが接続されているバス上に不正なメッセージが送信されても、その不正なメッセージに対応して処理がなされることを阻止できるようになる（図１８参照）。

ここでは不正検知ＥＣＵのうち不正検知ＥＣＵ４１００ａに着目して説明したが、例えば不正検知ＥＣＵ４１００ｂについても同様に、シーケンスＳ４００５において送信されたトリガーフレームに対応して、動作モードをチェックモードにし得る。また、ヘッドユニット４２００は、シーケンスＳ４００４での判断を省略してシーケンスＳ４００５でのチェックモードへの移行の指示を行うこととしても良い。シーケンスＳ４００４での判断を省略する場合には、各不正検知ＥＣＵの動作モードを把握しなくても良く、指示履歴の保持を省略できる。但し、シーケンスＳ４００４は、無用のトリガーフレームがバスに流れるのを防ぐために有用である。

ここで示したシーケンスＳ４００３の場合以外では、チェックモードへの移行は、例えば、通信開始・終了検出部４２８３が外部との通信開始を検出した場合、或いは車使用開始検出部４２８２が車両の使用開始を検出した場合に行われる。

［４．５ 待機モードへの移行に係るシーケンス（外部との通信終了時）］
以下、ヘッドユニット４２００が外部との通信を終了した場合におけるヘッドユニット４２００及び不正検知ＥＣＵ４１００ａの動作について説明する。

図３８は、ヘッドユニット４２００が外部との通信の終了を検知し、不正検知ＥＣＵ４１００ａへ待機モードへの移行を指示し、不正検知ＥＣＵ４１００ａが待機モードへ移行する動作例を示すシーケンス図である。

この動作例の開始段階では、不正検知ＥＣＵ４１００ａは、チェックモードになっている（シーケンスＳ４１０１）。例えば、この段階以前に、ヘッドユニット４２００が外部との通信を開始する際にチェックモードへの移行を指示するトリガーフレームを不正検知ＥＣＵ４１００ａが受けた結果として、チェックモードになっている状態である。このとき不正検知ＥＣＵ４１００ａは、不正フレーム検知部１３０により不正なメッセージの検知を行う状態である。

ヘッドユニット４２００は、通信開始・終了検出部４２８３により外部との通信の終了が検出されると（シーケンスＳ４１０２）、車両の使用開始から一定時間が経過したか否かを判断する（シーケンスＳ４１０３）。車両の使用開始から一定時間が経過していない場合には、待機モードへ移行してはならないため、待機モードへの移行を指示するトリガーフレームを送信しない（つまりシーケンスＳ４１０４、Ｓ４１０５をスキップする）。

車両の使用開始から一定時間が経過した場合には、ヘッドユニット４２００は、不正なメッセージを検出したかを判断する（シーケンスＳ４１０４）。チェックモードへの移行を指示するトリガーフレームの送信後に不正なメッセージを検出していた場合には、待機モードへ移行してはならないため、待機モードへの移行を指示するトリガーフレームを送信しない（つまりシーケンスＳ４１０５をスキップする）。

シーケンスＳ４１０４において不正なメッセージを検出していないと判断した場合には、ヘッドユニット４２００は、待機モードへの移行を指示する（ステップＳ４１０５）。具体的には、ヘッドユニット４２００は、待機モードへの移行を指示するトリガーフレームを送信する。

ヘッドユニット４２００からバス５００ｃに送信された待機モードへの移行を指示するトリガーフレームは、ゲートウェイ３００によりバス５００ａ、５００ｂに転送される。

不正検知ＥＣＵ４１００ａは、バス５００ａに送信されたトリガーフレームを受信して、動作モードを待機モードに移行する（シーケンスＳ４１０６）。このときから、不正検知ＥＣＵ４１００ａは、不正フレーム検知部１３０による不正なメッセージの検知を行わなくなる。

ここでは不正検知ＥＣＵのうち不正検知ＥＣＵ４１００ａに着目して説明したが、例えば不正検知ＥＣＵ４１００ｂについても同様に、シーケンスＳ４１０５において送信されたトリガーフレームに対応して、動作モードを待機モードにし得る。

［４．６ 待機モードへの移行に係るシーケンス（車両の使用開始から一定時間経過時）］
以下、車両の使用が開始されてから一定時間が経過した場合におけるヘッドユニット４２００及び不正検知ＥＣＵ４１００ａの動作について説明する。

図３９は、ヘッドユニット４２００が車両の使用開始から一定時間が経過したことを検知し、不正検知ＥＣＵ４１００ａへ待機モードへの移行を指示し、不正検知ＥＣＵ４１００ａが待機モードへ移行する動作例を示すシーケンス図である。

この動作例の開始段階では、不正検知ＥＣＵ４１００ａは、チェックモードになっている（シーケンスＳ４２０１）。例えば、この段階以前に、ヘッドユニット４２００が車両の使用開始を検出した際にチェックモードへの移行を指示するトリガーフレームを不正検知ＥＣＵ４１００ａが受けた結果として、チェックモードになっている状態である。このとき不正検知ＥＣＵ４１００ａは、不正フレーム検知部１３０により不正なメッセージの検知を行う状態である。

ヘッドユニット４２００は、車使用開始検出部４２８２により車両の使用が開始されてから一定時間が経過したことが検出されると（シーケンスＳ４２０２）、外部との通信中であるか否かを判断する（シーケンスＳ４２０３）。外部と通信している場合には、待機モードへ移行してはならないため、待機モードへの移行を指示するトリガーフレームを送信しない（つまりシーケンスＳ４２０４、Ｓ４２０５をスキップする）。

外部と通信中ではない場合には、ヘッドユニット４２００は、不正なメッセージを検出したかを判断する（シーケンスＳ４２０４）。チェックモードへの移行を指示するトリガーフレームの送信後に不正なメッセージを検出していた場合には、待機モードへ移行してはならないため、待機モードへの移行を指示するトリガーフレームを送信しない（つまりシーケンスＳ４２０５をスキップする）。

シーケンスＳ４２０４において不正なメッセージを検出していないと判断した場合には、ヘッドユニット４２００は、待機モードへの移行を指示する（シーケンスＳ４２０５）。具体的には、ヘッドユニット４２００は、待機モードへの移行を指示するトリガーフレームを送信する。

ヘッドユニット４２００からバス５００ｃに送信された待機モードへの移行を指示するトリガーフレームは、ゲートウェイ３００によりバス５００ａ、５００ｂに転送される。

不正検知ＥＣＵ４１００ａは、バス５００ａに送信されたトリガーフレームを受信して、動作モードを待機モードに移行する（シーケンスＳ４２０６）。このときから、不正検知ＥＣＵ４１００ａは、不正フレーム検知部１３０による不正なメッセージの検知を行わなくなる。

ここでは不正検知ＥＣＵのうち不正検知ＥＣＵ４１００ａに着目して説明したが、例えば不正検知ＥＣＵ４１００ｂについても同様に、シーケンスＳ４２０５において送信されたトリガーフレームに対応して、動作モードを待機モードにし得る。

［４．７ 実施の形態４の効果］
車載ネットワークシステム１３では、車両の状態に応じて不正検知ＥＣＵ４１００ａ、４１００ｂが、動作モードを、不正なメッセージの検知を行うチェックモードと不正なメッセージの検知を行わない待機モードとの間で切り替える。これにより、車両の状態に応じて必要な場合にだけ不正なメッセージの検知を行うようにすることで電力消費量を抑えることができる。また、不正検知ＥＣＵ４１００ａ、４１００ｂは、車両の状態を直接検知する機構を有さなくても、ヘッドユニット４２００からのトリガーフレームにより、動作モードを切り替えるタイミングを得ることができる。

（他の実施の形態等）
以上のように、本開示に係る技術の例示として実施の形態１〜４を説明した。しかしながら、本開示に係る技術は、これに限定されず、適宜、変更、置き換え、付加、省略等を行った実施の形態にも適用可能である。例えば、以下のような変形例も本開示の一実施態様に含まれる。

（１）上記実施の形態では、ＥＣＵ４００ａ〜４００ｄ或いはＥＣＵ３４００ａ〜３４００ｄによりフレームが定期的に送信される例を示したが、フレームは、状態変化を通知するイベントとして送信されることとしても良い。例えば、ＥＣＵは、ドアの開閉状態を定期的に送信するのではなく、ドアの開閉状態が変化した場合にのみ、フレームを送信するとしても良い。また、ＥＣＵがフレームを、定期的に送信、かつ、状態変化が発生した時に送信することとしても良い。

（２）実施の形態３では、データ値とカウンタ値からＭＡＣを算出する例を示したが、データ値のみからＭＡＣを算出することとしても良い。またカウンタ値のみからＭＡＣを算出することとしても良い。また、フレームに含まれるＭＡＣのサイズは４ｂｙｔｅｓに制限されるものではなく、送信毎に異なるサイズであっても良い。同様に時速等のデータ値のサイズ及びカウンタ値のサイズも１ｂｙｔｅに制限されるものではない。また、必ずしもフレームにカウンタ値が含まれていなくても良い。

（３）実施の形態３では、カウンタ値を送信毎にインクリメントする例を示したが、カウンタ値が時刻に応じて自動的にインクリメントされる値であっても良い。また、時刻そのものの値をカウンタの代わりに使用しても良い。即ち、データフレームが送信される度に変化する変数（カウンタ、時刻等）に基づいてＭＡＣが生成されるようにすると、ＭＡＣの不正な解読を困難化することが可能となる。また、実施の形態３では、不正検知ＥＣＵにおけるＭＡＣ生成部３１７０が、メッセージＩＤとデータフィールドの先頭１ｂｙｔｅと、カウンタ保持部３１９０のカウンタ値とからＭＡＣ値を算出することとした。この代わりに、メッセージＩＤとデータフィールドの先頭１ｂｙｔｅと、データフィールドの次の１ｂｙｔｅであるカウンタ値とからＭＡＣ値を算出することとしても良い。また、不正ではないと判定されたデータフィールドにおけるカウンタ値に合わせるように、カウンタ保持部３１９０のカウンタ値を更新することとしても良い。

（４）上記実施の形態では、ＣＡＮプロトコルにおけるデータフレームを標準ＩＤフォーマットで記述しているが、拡張ＩＤフォーマットであっても良い。拡張ＩＤフォーマットの場合には、標準ＩＤフォーマットにおけるＩＤ位置のベースＩＤと、拡張ＩＤとを合わせて２９ビットでＩＤ（メッセージＩＤ）を表すので、この２９ビットのＩＤを上述の実施の形態におけるＩＤ（メッセージＩＤ）と扱えば良い。

（５）上記実施の形態では、ＭＡＣ算出のアルゴリズムをＨＭＡＣとしているが、これＣＢＣ−ＭＡＣ（Cipher Block Chaining Message Authentication Code）、ＣＭＡＣ（(Cipher-based MAC）であっても良い。また、ＭＡＣ計算に用いられるパディングについては、ゼロパディング、ＩＳＯ１０１２６、ＰＫＣＳ＃１、ＰＫＣＳ＃５、ＰＫＣＳ＃７、その他、ブロックのデータサイズが計算に必要となるパディングの方式であれば何でも良い。また４ｂｙｔｅｓ等のブロックへのサイズの変更方法についても、先頭、最後尾、中間のいずれの部分にパディングを行っても良い。また、ＭＡＣ算出に用いるデータは、連続しているデータ（例えば４ｂｙｔｅｓ分の連続データ）でなくても、特定のルールに従って１ｂｉｔずつ収集して結合したものでも良い。

（６）上記実施の形態で示したＣＡＮプロトコルは、ＴＴＣＡＮ（Time-Triggered CAN)、ＣＡＮＦＤ（CAN with Flexible Data Rate）等の派生的なプロトコルをも包含する広義の意味を有するものであっても良い。

（７）上記実施の形態では、不正なＥＣＵがバスに接続される例を示したが、ＥＣＵ４００ａ〜４００ｄ或いはＥＣＵ３４００ａ〜３４００ｄのような既存のＥＣＵが何らかの要因によって不正なＥＣＵとして働く可能性もある。その場合であっても、上記実施の形態で示したように不正検知ＥＣＵが適切に不正なフレームを検知してエラーフレームを送信することで、他のＥＣＵが不正なフレームを処理してしまうことを阻止できる。

（８）実施の形態２では、メッセージＩＤと許容されているデータ範囲とが対応付けられたデータ範囲リストを用いて、受信されたデータフレームのデータが、メッセージＩＤ毎に許容されているデータ範囲に含まれているか否かによって、不正か否かの判定を行うこととしたが、データ範囲リストにメッセージＩＤを含ませず、全てのメッセージＩＤに共通して許容されているデータ範囲（例えば「０〜１８０」）を定めておき、メッセージＩＤにかかわらず不正か否かの判定を行うこととしても良い。また、不正検知ＥＣＵが保持するデータ範囲リストは、その不正検知ＥＣＵが接続されたバスにおいて送信され得るメッセージＩＤとデータ範囲とを対応付けたものとしても良い。これにより、データ範囲リストが、実施の形態１で示した正規ＩＤリストとしても用いることができるようになる。これを利用して実施の形態２に示した不正検知ＥＣＵにおいても実施の形態１で示したメッセージＩＤのチェック（シーケンスＳ１００４）を行うようにしても良い。

（９）実施の形態２で示したメッセージＩＤと許容されているデータ範囲とが対応付けられたデータ範囲リストの代わりに、不正検知ＥＣＵが、メッセージＩＤと、許容されているデータ長とを対応付けたデータ長リストを用いることとしても良い。この場合には、不正検知ＥＣＵは、受信されたデータフレームのコントロールフィールドの値が不正を示す所定条件に該当するか否かを判定する。この不正を示す所定条件は、コントロールフィールドにおけるデータ長（ＤＬＣ）が、データ長リストにおいてメッセージＩＤに対応付けられているデータ長ではないという条件である。不正検知ＥＣＵは、受信されたＤＣＬが、データ長リストにおいてメッセージＩＤ毎に許容されているデータ長であるか否かによって、不正か否かの判定を行う。

（１０）上記実施の形態では、特にデータフレームに注目して説明したが、リモートフレームについても不正検知ＥＣＵが一定の不正を検知することが可能である。例えば、不正検知ＥＣＵが、実施の形態１で示した正規ＩＤリストを用いて受信したリモートフレームにおけるメッセージＩＤが不正か否かを判定しても良い。また、不正検知ＥＣＵが、上述したデータ長リストを用いて受信したリモートフレームにおけるコントロールフィールドにおけるデータ長（ＤＬＣ）が、メッセージＩＤ毎に許容されているデータ長であるか否かにより不正か否かを判定しても良い。また、上記実施の形態で示した不正検知ＥＣＵが不正なフレームを受信することで不正の検知を行った場合に送信するエラーフレームは、不正の検知後に迅速に送信されると良い。なお、不正検知ＥＣＵは、不正の検知後、その不正なフレームのＣＲＣシーケンスの最後尾が送信される前までにエラーフレームを送信することは有用である。これにより他のＥＣＵは、エラーフレームの検出或いはＣＲＣのチェックでのエラー検出により、その不正なフレームの処理を中止することになる。なお、リモートフレームもデータフレームと同様にメッセージＩＤ、コントロールフィールド及びＣＲＣシーケンスを含む。

（１１）上記実施の形態では、不正検知ＥＣＵが一定条件下でエラー表示メッセージを送信することを示したが、エラー表示メッセージを送信しないこととしても良い。この場合には、ゲートウェイ及びヘッドユニット等のＥＣＵは特に不正検知ＥＣＵに対応した構成（エラー表示メッセージを受信するための受信ＩＤリスト等）を保持する必要がなくなる。なお、不正検知ＥＣＵは、エラー表示メッセージの送信の代わりに自らスピーカ或いはディスプレイ等を備える場合においてエラーを自ら報知しても良いし、エラーのログを記憶媒体等に記録しても良い。

（１２）実施の形態４で示した車載ネットワークシステム１３において、動作モードを切り替え可能な不正検知ＥＣＵと、動作モードを切り替えない不正検知ＥＣＵ（つまり常時チェックモードと同様である不正検知ＥＣＵ）が混在しても良い。また、不正検知ＥＣＵは、バス上で送信される不正なメッセージを検知する機能の他に、他のＥＣＵと同様に、不正でないメッセージに応じて予め定められた処理を実行する機能、或いは、車両の状態の検知又は車両の制御等の処理を実行する機能を有していても良い。動作モードが特定の不正検知を行わない待機モードである場合においては、電力消費の低減の他に、不正検知ＥＣＵの処理負荷の低減及びバスでのトラフィック低減等の効果も生じ得る。

（１３）実施の形態４では、ヘッドユニット４２００が、車両の状態が一定条件を満たした場合にトリガーフレームを送信する機能を有することとしたが、この機能を他のＥＣＵが有することとしても良い。この車両の状態が一定状態を満たした場合にトリガーフレームを送信する機能は、車載ネットワークシステム１３における１台のＥＣＵが有しても良いし、複数のＥＣＵ（全ＥＣＵであっても一部のＥＣＵであっても良い。）が有しても良い。即ち、実施の形態４で示したヘッドユニット４２００の不正フレーム検出部４２８０、モード変更指示部４２８１、車使用開始検出部４２８２及び通信開始・終了検出部４２８３を、他のＥＣＵ（ＥＣＵ４００ａ等）に含ませることとしても良い。図４０は、ＥＣＵ４００ａを一部変形して、不正フレーム検出部４２８０、モード変更指示部４２８１、車使用開始検出部４２８２及び通信開始・終了検出部４２８３を含ませてなるＥＣＵ４４００の構成図である。図４０に示すＥＣＵ４４００におけるフレーム解釈部４４５０は、実施の形態１で示したフレーム解釈部４５０を一部変形したものである。フレーム解釈部４４５０は、フレーム処理部４１０、フレーム生成部４４２０及び受信ＩＤ判断部４３０へのデータの転送に加えて、不正フレーム検出部４２８０、車使用開始検出部４２８２及び通信開始・終了検出部４２８３へも、受信したフレームを転送する。この転送は、全ての受信したフレームの転送でも良いし、各検出部に関連するフレームのみの転送であっても良い。不正フレーム検出部４２８０は、実施の形態４の不正フレーム検出部４２８０と同じ動作を行う。車使用開始検出部４２８２及び通信開始・終了検出部４２８３は、ＥＣＵ４４００が受信したフレームから、車体が使用開始されたこと、通信が開始されたこと、通信が終了されたこと等を検出する。例えば、ヘッドユニット４２００や外部との通信機能を持つＥＣＵが通信の開始或いは終了を知らせるフレームを送信し、通信開始・終了検出部４２８３がそのフレームの受信に対応して通信の開始或いは通信の終了を検出しても良い。モード変更指示部４２８１は、実施の形態４の機能と同様である。フレーム生成部４４２０は、実施の形態１のフレーム生成部４２０の機能を有する。フレーム生成部４４２０は更に、モード変更指示部４２８１からのモード変更のためのトリガーフレームの送信依頼に従ってトリガーフレームを構成してトリガーフレームをフレーム送受信部２７０へ通知して送信させる機能を有する。このＥＣＵ４４００は、図３７のシーケンスＳ４００２〜Ｓ４００５で示す処理手順、図３８のシーケンスＳ４１０２〜Ｓ４１０５で示す処理手順、及び、図３９のシーケンスＳ４２０２〜Ｓ４２０５で示す処理手順と、同様の処理手順を実行する。この車両の状態が一定状態を満たした場合にトリガーフレームを送信する機能は、不正検知ＥＣＵが有しても良い。

（１４）実施の形態４で示したヘッドユニット４２００による待機モードへの移行を指示すべきか否かの判断（図３８、図３９参照）は、有用な判断の一例にすぎず、この他の判断も可能である。例えば、単に通信終了を検出した場合に待機モードへの移行の指示がなされても良く、また、車両の使用開始から所定時間が経過した場合に待機モードへの移行の指示がなされても良い。この所定時間は、例えば数分間等の一定時間であっても良いし、また、車両の使用開始後にバス上で一定数のメッセージの送信がなされるまでに要した時間、使用開始後に一定の処理手順が実行されるまでに要した時間であっても良い。また、単にバス上で一定期間において不正なメッセージを検知しなかった場合に待機モードへの移行の指示がなされても良い。即ち、車両の状態に応じて不正検知ＥＣＵの動作モードをチェックモード或いは待機モードに変更するために、実験、理論等に基づき有用であるならば任意の判断材料に基づき任意の判断方法（判断アルゴリズム等）を利用し得る。例えば、ヘッドユニット４２００は、車使用開始検出部４２８２及び通信開始・終了検出部４２８３の両方を必ずしも含まなくても良く、どちらか一方のみ含んでも良いし、他の車両の状態を検出するための検出部を含んでも良い。検出部としては、例えば駐車中か否かの検出部、停車中か否かの検出部、ドアの開閉の検出部、給油口の開閉の検出部、充電中か否かの検出部、走行中か否かの検出部、シートへの着席の検出部、乗車中の検出部、乗車完了の検出部、降車中の検出部等が挙げられる。車載ネットワークシステムは、車両の状態が一定条件を満たしたことが検出された場合に、不正検知ＥＣＵの動作モードを、バス上の不正なメッセージを検知する所定種類の検知処理を行う第１モード（チェックモード）とその検知処理を行わない第２モード（待機モード等）との間で切り替えるように構成されていれば良い。また、第２モードで不正なメッセージの検知処理を全く行わない方式の他に、第２モードでは、その所定種類の検知処理を行わないが、その所定種類の検知処理よりは処理量の少ない、ある種の不正なメッセージの検知処理を実行する方式も採り得る。また、ヘッドユニット４２００が不正検知ＥＣＵの動作モード変更用ボタンその他のユーザインタフェースを備え、そのユーザインタフェースへのユーザによる操作、入力等に応じて不正検知ＥＣＵへ動作モードの変更を指示しても良い。そのユーザインタフェースとしては、物理的なボタンの他、タッチパネル等に表示したボタン等であっても良いし、音声入力機構を用いても良い。なお、車使用開始検出部４２８２、通信開始・終了検出部４２８３等の検出部により車両の状態の変化が検出されたときに、画面表示、音声出力等により、ユーザに動作モードの変更が必要か否かを問い合わせても良い。ヘッドユニット４２００は、ユーザからの応答としての動作モードの変更の要否に係る入力を受け付けると、その入力が動作モードの切り替えを要する旨を示すならば不正検知ＥＣＵへ動作モードの変更を指示し得る。例えば、ヘッドユニット４２００が、車両の使用開始から一定時間が経過した際に待機モードに移行するか否かをユーザに問い合わせ、これに対してユーザがチェックモードを継続することを選択し得る。また、ヘッドユニット４２００が単に車両の使用開始、通信開始、通信終了等のイベントの情報だけを不正検知ＥＣＵ４１００ａ等に通知し、どの動作モードに移行するべきかを不正検知ＥＣＵ４１００ａ等が判断するようにしても良い。

（１５）実施の形態４で示した不正検知ＥＣＵ４１００ａは、実施の形態１の不正検知ＥＣＵ１００ａの機能を含むものとしたが、不正検知ＥＣＵにおける不正対処方法の具体的な実現態様は、実施の形態２、３に示したものであっても良い。即ち、車載ネットワークシステム１３における各不正検知ＥＣＵ（不正検知ＥＣＵ４１００ａ等）を、例えば図４１に示すように実施の形態２の不正検知ＥＣＵ２１００ａの機能を含む不正検知ＥＣＵ５１００としても良い。また、不正検知ＥＣＵ４１００ａ等を、図４２に示すように実施の形態３の不正検知ＥＣＵ３１００ａの機能を含む不正検知ＥＣＵ６１００としても良い。なお、図４１に示した不正検知ＥＣＵ５１００及び図４２に示した不正検知ＥＣＵ６１００はいずれも、不正検知ＥＣＵ４１００ａと同様にフレーム解釈部４１５０、トリガーフレーム検出部４１７０、モード保持部４１８０を含む。また、不正検知ＥＣＵ４１００ａが、実施の形態１〜３のそれぞれで示した不正検知の処理手順の２つ以上を、切り替えて実行できるように構成されても良い。例えば、不正検知ＥＣＵが、不正なメッセージを検知するために処理量の比較的多い実施の形態２又は３で示した不正検知の処理手順と、処理量の比較的少ない実施の形態１で示した不正検知の処理手順とを動作モードにより切り替えることとしても良い。この場合において、動作モードは、例えば処理量の比較的多い検知処理を行う第１モードと、処理量の比較的多い検知処理を行わず処理量の比較的少ない検知処理を行う第２モードとの間で切り替えられることになる。

（１６）上記実施の形態で示した不正フレーム検知部及び不正ＭＡＣ検知部はＣＡＮコントローラと呼ばれるハードウェア、または、ＣＡＮコントローラと接続して動作するプロセッサ上で動作するファームウェアに実装しても良い。また、ＭＡＣ鍵保持部、カウンタ保持部、正規ＩＤリスト保持部、データ範囲リスト保持部は、ＣＡＮコントローラと呼ばれるハードウェアのレジスタ、または、ＣＡＮコントローラと接続して動作するプロセッサ上で動作するファームウェアに格納されていても良い。

（１７）上記実施の形態における各ＥＣＵ（ゲートウェイ及びヘッドユニットを含む）は、例えば、プロセッサ、メモリ等のデジタル回路、アナログ回路、通信回路等を含む装置であることとしたが、ハードディスク装置、ディスプレイ、キーボード、マウス等の他のハードウェア構成要素を含んでいても良い。また、メモリに記憶された制御プログラムがプロセッサにより実行されてソフトウェア的に機能を実現する代わりに、専用のハードウェア（デジタル回路等）によりその機能を実現することとしても良い。

（１８）上記実施の形態における各装置を構成する構成要素の一部または全部は、１個のシステムＬＳＩ（Large Scale Integration：大規模集積回路）から構成されているとしても良い。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ等を含んで構成されるコンピュータシステムである。前記ＲＡＭには、コンピュータプログラムが記録されている。前記マイクロプロセッサが、前記コンピュータプログラムに従って動作することにより、システムＬＳＩは、その機能を達成する。また、上記各装置を構成する構成要素の各部は、個別に１チップ化されていても良いし、一部又はすべてを含むように１チップ化されても良い。また、ここでは、システムＬＳＩとしたが、集積度の違いにより、ＩＣ、ＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現しても良い。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用しても良い。さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行っても良い。バイオ技術の適用等が可能性としてあり得る。

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

（２０）本開示の一態様としては、上記に示す不正検知方法、不正対処方法等の方法であるとしても良い。また、これらの方法をコンピュータにより実現するコンピュータプログラムであるとしても良いし、前記コンピュータプログラムからなるデジタル信号であるとしても良い。また、本開示の一態様としては、前記コンピュータプログラムまたは前記デジタル信号をコンピュータ読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＢＤ（Blu-ray（登録商標） Disc）、半導体メモリ等に記録したものとしても良い。また、これらの記録媒体に記録されている前記デジタル信号であるとしても良い。また、本開示の一態様としては、前記コンピュータプログラムまたは前記デジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしても良い。また、本開示の一態様としては、マイクロプロセッサとメモリを備えたコンピュータシステムであって、前記メモリは、上記コンピュータプログラムを記録しており、前記マイクロプロセッサは、前記コンピュータプログラムに従って動作するとしても良い。また、前記プログラムまたは前記デジタル信号を前記記録媒体に記録して移送することにより、または前記プログラムまたは前記デジタル信号を前記ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしても良い。

（２１）上記実施の形態及び上記変形例で示した各構成要素及び機能を任意に組み合わせることで実現される形態も本開示の範囲に含まれる。

本開示は、車載ネットワークシステムにおいて不正なＥＣＵによる影響を効率的に抑制するために利用可能である。

１０，１１，１２，１３ 車載ネットワークシステム
１００ａ，１００ｂ，２１００ａ，２１００ｂ，３１００ａ，３１００ｂ，４１００ａ，４１００ｂ，５１００，６１００ 不正検知電子制御ユニット（不正検知ＥＣＵ）
１１０ 不正検知カウンタ保持部
１２０ 正規ＩＤリスト保持部
１３０，２１３０ 不正フレーム検知部
１４０，２３０，３２０，４２０，３４２０，４２３０，４４２０ フレーム生成部
１５０，２６０，３５０，４５０，２１５０，３１５０，４１５０，４２６０，４４５０ フレーム解釈部
１６０，２７０，３６０，４６０ フレーム送受信部
２００，４２００ ヘッドユニット
２１０ 表示制御部
２２０，４１０ フレーム処理部
２４０，３３０，４３０ 受信ＩＤ判断部
２５０，３４０，４４０ 受信ＩＤリスト保持部
３００ ゲートウェイ
３１０ 転送処理部
３７０ 転送ルール保持部
４００ａ，４００ｂ，４００ｃ，４００ｄ，３４００ａ，３４００ｂ，３４００ｃ，３４００ｄ，４４００ 電子制御ユニット（ＥＣＵ）
４０１ エンジン
４０２ ブレーキ
４０３ ドア開閉センサ
４０４ 窓開閉センサ
４７０ データ取得部
５００ａ，５００ｂ，５００ｃ バス
２１２０ データ範囲リスト保持部
３１３０ 不正ＭＡＣ検知部
３４１０，３１７０ ＭＡＣ生成部
３４３０，３１８０ ＭＡＣ鍵保持部
３４４０，３１９０ カウンタ保持部
４１７０ トリガーフレーム検出部
４１８０ モード保持部
４２８０ 不正フレーム検出部
４２８１ モード変更指示部
４２８２ 車使用開始検出部
４２８３ 通信開始・終了検出部

Claims (13)

1. １以上のネットワークを介して通信する複数の電子制御ユニットを備える車載ネットワークシステムにおいて用いられる不正検知方法であって、
   前記複数の電子制御ユニットは、第１の電子制御ユニットと第２の電子制御ユニットと第３の電子制御ユニットを含み、
   前記１以上のネットワークは、第１のネットワークと第２のネットワークを含み、
   前記第１の電子制御ユニットは前記第１のネットワークに接続され、
   前記第２の電子制御ユニットは前記第２のネットワークに接続され、
   前記不正検知方法は、
   前記第３の電子制御ユニットが前記車載ネットワークシステムを備えた車両の状態が第１の条件または第２の条件を満たしたことを検出する検出ステップと、
   前記車両の状態が前記第１の条件または前記第２の条件を満たしたことを検出した場合に、前記第３の電子制御ユニットが切替指示メッセージを前記第１の電子制御ユニットと前記第２の電子制御ユニットへ送信し、
   （ｉ）前記車両の状態が前記第１の条件を満たしたことが検出された場合に、前記第１の電子制御ユニットと前記第２の電子制御ユニットは、動作モードを、前記１以上のネットワーク上の不正なメッセージを検知する第１の種類の検知処理を行わない第１のモードへ移行し、
   （ｉｉ）前記車両の状態が前記第２の条件を満たしたことが検出された場合に、前記第２の電子制御ユニットは、動作モードを、前記第１の種類の検知処理を行う第２のモードへ移行する、切替ステップと、を含む、
   不正検知方法。
2. 前記第２の条件は、前記第３の電子制御ユニットが、前記１以上のネットワーク上で不正なメッセージを検知したことである、
   請求項１記載の不正検知方法。
3. 前記第１の条件は、前記第３の電子制御ユニットが、前記１以上のネットワーク上で所
   定の期間において不正なメッセージを検知しなかったことである、
   請求項２記載の不正検知方法。
4. 前記第２の条件は、前記第３の電子制御ユニットが前記車両の外部の装置と通信を開始する状態になったことである、
   請求項１記載の不正検知方法。
5. 前記第１の条件は、前記第３の電子制御ユニットが前記車両の外部の装置との通信を終了して所定の状態になったことである、
   請求項４記載の不正検知方法。
6. 前記第２の条件は、前記車両の状態が駐車中である、
   請求項１記載の不正検知方法。
7. 前記第２のネットワークは、前記複数の電子制御ユニットのうち、前記車両の駆動に関する電子制御ユニットを含まない、
   請求項６記載の不正検知方法。
8. 前記１以上のネットワークは、さらに、第３のネットワークを含み、
   前記第３の電子制御ユニットは、前記第３のネットワークに接続され、
   前記車載ネットワークシステムは更に、前記第１のネットワークと前記第２のネットワークと前記第３のネットワークとの間でメッセージを転送するゲートウェイ装置を備え、
   前記切替ステップでは、
   前記第３の電子制御ユニットが切替指示メッセージを前記ゲートウェイ装置へ送信し、
   前記車両の状態が前記第１の条件を満たしたことが検出された場合は、前記ゲートウェイ装置は、前記切替指示メッセージを前記第１の電子制御ユニットと前記第２の電子制御ユニットへ送信し、
   前記車両の状態が前記第２の条件を満たしたことが検出された場合は、前記ゲートウェイ装置は、前記切替指示メッセージを前記第２の電子制御ユニットへ送信する、
   請求項１記載の不正検知方法。
9. 前記第１の条件または前記第２の条件は、
   前記車両の状態が変化した場合において、所定のユーザインタフェースで前記動作モードの切り替えを要することを示す入力を受け付けることである、
   請求項１記載の不正検知方法。
10. 前記第１のモードでは、不正なメッセージを検知可能な程度が、前記第１の種類の検知処理とは異なる、第２の種類の検知処理を行う、
    請求項１記載の不正検知方法。
11. 前記第３の電子制御ユニットは、前記第１のネットワークと前記第２のネットワークの間でメッセージを転送するゲートウェイ装置であり、
    前記切替ステップでは、
    前記車両の状態が前記第１の条件を満たしたことが検出された場合は、前記第３の電子制御ユニットは、前記切替指示メッセージを前記第１の電子制御ユニットと前記第２の電子制御ユニットへ送信し、
    前記車両の状態が前記第２の条件を満たしたことが検出された場合は、前記第３の電子制御ユニットは、前記切替指示メッセージを前記第２の電子制御ユニットへ送信する、
    請求項１記載の不正検知方法。
12. 前記複数の電子制御ユニットは、Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＣＡＮ）プロトコルに従って前記１以上のネットワークを介して通信を行う、
    請求項１記載の不正検知方法。
13. 車載ネットワークシステムであって、
    １以上のネットワークを介して通信する複数の電子制御ユニットと、
    前記複数の電子制御ユニットは、第１の電子制御ユニットと第２の電子制御ユニットと第３の電子制御ユニットを含み、
    前記１以上のネットワークは、第１のネットワークと第２のネットワークを含み、
    前記第１の電子制御ユニットは前記第１のネットワークに接続され、
    前記第２の電子制御ユニットは前記第２のネットワークに接続され、
    前記第３の電子制御ユニットは、
    前記車載ネットワークシステムを備えた車両の状態が第１の条件または第２の条件を満たしたことを検出する検出部と、
    前記検出部により前記車両の状態が前記第１の条件または前記第２の条件を満たしたことが検出された場合に、切替指示メッセージを前記第１の電子制御ユニットと前記第２の電子制御ユニットへ送信する送信部と、を備え、
    前記車両の状態が前記第１の条件を満たしたことが検出された場合に、
    前記第１の電子制御ユニットと前記第２の電子制御ユニットは、動作モードを、前記１以上のネットワーク上の不正なメッセージを検知する第１の種類の検知処理を行わない第１のモードへ移行し
    前記車両の状態が前記第２の条件を満たしたことが検出された場合に、
    前記第２の電子制御ユニットは、動作モードを、前記第１の種類の検知処理を行う第２のモードへ移行する、
    車載ネットワークシステム。

Images