JP6956844B2 - 不正制御抑止方法、不正制御抑止装置及び車載ネットワークシステム - Google Patents

Description

本発明は、ネットワークに不正なメッセージを流して車両等を不正に制御することを防止するセキュリティ対策技術に関する。

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

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

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

ＣＡＮの車載ネットワークシステムについては、攻撃者がバスにアクセスして不正なフレームを送信することでＥＣＵを不正に制御するといった脅威が存在し、セキュリティ対策が検討されている。

例えば特許文献１には、ＣＡＮのバスに送信されたフレームについて測定される受信間隔と予め規定された通信間隔との差が規定された範囲から外れる場合にそのフレームを不正と判断することで、不正フレームによる制御を防止する方法が記載されている。また、特許文献２には、規定された通信間隔内に同一の識別子を有するフレームを２つ以上受信した場合にその各フレームを破棄することで、不正フレームによる制御を防止する方法が記載されている。

特許第５６６４７９９号公報 特許第５９１９２０５号公報

しかしながら、特許文献１の方法では、規定された通信間隔から外れない不正なフレームによる不正な制御を防ぐことができない。また、特許文献２の方法は、規定された通信間隔内に含まれる同一の識別子を有する不正なフレームと正常なフレームとの両方を破棄するので、車両の制御の安定性の観点から適切ではない。また、この方法は、不定期に送信される正常なフレームと同一の識別子を有する不正なフレームに対処できない。

そこで、本発明は、ネットワークに流される不正なフレームによる不正な制御を適切に抑止し得る不正制御抑止方法を提供する。また、本発明は、不正なフレームによる不正な制御を適切に抑止し得る不正制御抑止装置及び車載ネットワークシステムを提供する。

上記課題を解決するために本発明の一態様に係る不正制御抑止方法は、制御対象に対して所定制御を指示する制御フレームを含む複数のフレームの授受を通信路を介して行う複数の電子制御ユニットを備えるネットワークシステムにおける不正制御抑止方法であって、前記複数のフレームには、前記制御対象の状態に関する情報を含む状態フレームが含まれ、前記不正制御抑止方法は、前記通信路から複数のフレームを逐次受信する受信ステップと、前記受信ステップで受信された制御フレームに基づく前記所定制御を抑止すべきか否かを、当該制御フレームの受信時に先行する所定期間内に前記受信ステップで受信された状態フレームの集合に基づいて特定される、当該所定期間における前記制御対象の状態が、所定基準を満たすか否かに基づいて、判定する判定ステップとを含み、前記所定基準は、前記所定期間における前記制御対象の状態について、所定量以上の変化が継続する不整合状態が継続する時間が所定時間を超えている場合に満たされ、前記所定時間を超えていない場合に満たされず、前記判定ステップでは、前記所定基準が満たされた場合に前記所定制御を抑止すべきと判定する不正制御抑止方法である。

また、上記課題を解決するために本発明の一態様に係る不正制御抑止装置は、複数の電子制御ユニットが、制御対象に対して所定制御を指示する制御フレームを含む複数のフレームの授受を通信路を介して行うところの当該通信路に接続される不正制御抑止装置であって、前記複数のフレームには、前記制御対象の状態に関する情報を含む状態フレームが含まれ、前記不正制御抑止装置は、前記通信路から複数のフレームを逐次受信する受信部と、前記受信部により受信された制御フレームに基づく前記所定制御を抑止すべきか否かを、当該制御フレームの受信時に先行する所定期間内に前記受信部により受信された状態フレームの集合に基づいて特定される、当該所定期間における前記制御対象の状態が、所定基準を満たすか否かに基づいて、判定する判定部とを備え、前記所定基準は、前記所定期間における前記制御対象の状態について、所定量以上の変化が継続する不整合状態が継続する時間が所定時間を超えている場合に満たされ、前記所定時間を超えていない場合に満たされず、前記判定部は、前記所定基準が満たされた場合に前記所定制御を抑止すべきと判定する不正制御抑止装置である。

また、上記課題を解決するために本発明の一態様に係る車載ネットワークシステムは、車両の状態に関する情報を含むフレームである状態フレーム、及び、前記車両に対して所定制御を指示するフレームである制御フレームの授受をネットワークを介して行う複数の電子制御ユニットを備える車載ネットワークシステムであって、前記ネットワークから状態フレーム及び制御フレームを逐次受信する受信部と、前記受信部により受信された制御フレームに基づく前記所定制御を抑止すべきか否かを、当該制御フレームの受信時に先行する所定期間内に前記受信部により受信された状態フレームの集合に基づいて特定される、当該所定期間における前記車両の状態が、所定基準を満たすか否かに基づいて、判定する判定部とを備え、前記所定基準は、前記所定期間における前記車両の状態について、所定量以上の変化が継続する不整合状態が継続する時間が所定時間を超えている場合に満たされ、前記所定時間を超えていない場合に満たされず、前記判定部は、前記所定基準が満たされた場合に前記所定制御を抑止すべきと判定する車載ネットワークシステムである。

本発明によれば、ネットワークに流される不正なフレームによる不正な制御が適切に抑止され得る。

実施の形態１に係る車載ネットワークシステムの全体構成を示す図である。 ＣＡＮプロトコルで規定されるデータフレームのフォーマットを示す図である。 ＣＡＮプロトコルで規定されるエラーフレームのフォーマットを示す図である。 実施の形態１に係る監視ＥＣＵの構成図である。 実施の形態１に係る監視ＥＣＵが用いるフレーム受信履歴情報の一例を示す図である。 実施の形態１に係る監視ＥＣＵが用いる車両状態情報の一例を示す図である。 実施の形態１に係る監視ＥＣＵが用いる機能制限ルールの一例を示す図である。 車載ネットワークシステムにおけるＥＣＵの構成図である。 各種ＥＣＵが送信するデータフレームの例を示す図である。 実施の形態１における駐車支援機能の処理シーケンスを示す図である。 実施の形態１における駐車支援機能への攻撃及び不正制御抑止処理のシーケンスを示す図である。 実施の形態１に係る監視ＥＣＵによる監視動作の一例を示すフローチャートである。 実施の形態２に係る車載ネットワークシステムの全体構成を示す図である。 実施の形態２に係る監視ＥＣＵの構成図である。 実施の形態２に係る監視ＥＣＵが用いるフレーム受信履歴情報の一例を示す図である。 実施の形態２に係る監視ＥＣＵが用いる機能制限ルールの一例を示す図である。 車両状態を偽装する攻撃を受けた場合の車両状態の継続時間を説明するための図である。 実施の形態２における駐車支援機能に係る攻撃と不正制御抑止とのシーケンスを示す図である。 実施の形態２に係る監視ＥＣＵによる監視動作の一例を示すフローチャートである。 実施の形態３に係る車載ネットワークシステムの全体構成を示す図である。 実施の形態３に係るＥＣＵが送信するデータフレームの例を示す図である。 実施の形態３に係る監視ＥＣＵの構成図である。 実施の形態３に係る監視ＥＣＵが用いるフレーム受信履歴情報の一例を示す図である。 実施の形態３に係る監視ＥＣＵが用いる機能制限ルールの一例を示す図である。 実施の形態３に係る監視ＥＣＵが用いる計測関連情報の一例である。 実施の形態３におけるクルーズコントロール機能への攻撃と不正制御抑止とのシーケンスを示す図である。 実施の形態３に係る監視ＥＣＵによる監視動作の一例を示すフローチャートである。 他の実施の形態に係る不正制御抑止装置の構成の一例を示す図である。

本発明の一態様に係る不正制御抑止方法は、制御対象に対して所定制御を指示する制御フレームを含む複数のフレームの授受を通信路を介して行う複数の電子制御ユニットを備えるネットワークシステムにおける不正制御抑止方法であって、前記通信路から複数のフレームを逐次受信する受信ステップと、前記受信ステップで受信された制御フレームに基づく前記所定制御を抑止すべきか否かを、当該制御フレームの受信時に先行する所定期間内に前記受信ステップで受信されたフレームの集合に基づいて、判定する判定ステップとを含む不正制御抑止方法である。これにより、所定期間内に受信されたフレームの集合から、その所定期間における制御対象が異常状態であるか否か等の特定が可能となるので、制御フレームによる制御を抑止すべきか否かの判定を適切に行うことが可能となり得る。

また、前記複数のフレームには、前記制御対象の状態に関する情報を含む状態フレームが含まれ、前記判定ステップでは、前記受信ステップで受信された制御フレームに基づく前記所定制御を抑止すべきか否かを、当該制御フレームの受信時に先行する所定期間内に前記受信ステップで受信された状態フレームの集合に基づいて特定される、当該所定期間における前記制御対象の状態が、所定基準を満たすか否かに基づいて、判定することとしても良い。例えば、車両等といった制御対象の偽装状態を捉えるように所定基準を定めておく。これにより、攻撃者が、制御対象の状態を偽装する前準備をした上で制御対象を制御するための不正な制御フレームを送信した場合において、その不正な制御フレームによる制御を抑止すべきと適切に判定することが可能となり得る。

また、前記判定ステップでは、前記所定期間内に前記受信ステップで受信された状態フレームの集合に、異常な状態フレームが含まれている場合に前記制御対象の状態を偽装状態であると特定し、異常な状態フレームが含まれていない場合に前記制御対象の状態を偽装状態でないと特定し、前記所定基準は、特定される前記制御対象の状態が、偽装状態である場合に満たされ、前記制御対象の状態が偽装状態でない場合に満たされず、前記判定ステップでは、前記所定基準が満たされた場合に前記所定制御を抑止すべきと判定することとしても良い。異常な状態フレームは、例えば、通常とり得る値とは異なる値を示すデータを含む状態フレームである。これにより、攻撃者が、制御対象の状態を偽装して制御対象を制御するための不正な制御フレームを送信した場合にその不正な制御フレームの抑止が可能となる。

また、前記判定ステップでは、前記所定期間内に前記受信ステップで受信された状態フレームの集合に、所定閾値より短い受信間隔で受信された、前記所定制御の実行のために用いられる同一項目の情報を示す複数の状態フレームが含まれている場合に、当該集合に異常な状態フレームが含まれているとして、前記制御対象の状態を偽装状態であると特定することとしても良い。これにより、予め定められている状態フレームの送信間隔のマージンを踏まえて適切に所定閾値を定めておくことにより、偽装状態の特定を適切に行うことが可能となる。例えば、所定制御が車両のハンドル制御である場合に、そのハンドル制御の実行のために用いられる目標操舵角を示す状態フレームが、そのマージンに基づく所定閾値より短い受信間隔で複数受信された場合等に、車両等といった制御対象の状態を偽装状態であると特定し得る。このため、不正な所定制御の抑止を適切に行うことが可能となる。

また、前記判定ステップでは、前記所定期間内に前記受信ステップで受信された状態フレームの集合に、前記所定制御の実行のために用いられる同一項目の情報を示す状態フレームが所定数より多く含まれている場合に、当該集合に異常な状態フレームが含まれているとして、前記制御対象の状態を偽装状態であると特定することとしても良い。これにより、状態フレームが冗長に送信されているような偽装状態を適切に特定できるようになる。

また、前記判定ステップでは、前記所定期間内に前記受信ステップで受信された状態フレームの集合に、前記所定制御の実行のために用いられる同一項目の情報を示す２つの状態フレームが含まれ、当該２つの状態フレームが示す当該情報の値の差異が所定量より大きい場合に、当該集合に異常な状態フレームが含まれているとして、前記制御対象の状態を偽装状態であると特定することとしても良い。これにより、制御対象の真の状態を表す値の状態フレームと、攻撃者により送信された、その真の状態とは異なる偽の状態を表わす状態フレームとが混在する場合に、状態フレームが示す情報の値が所定量より大きく変化し得るので、このような偽装状態を適切に特定できるようになる。

また、前記判定ステップでは、前記所定期間内に前記受信ステップで受信された状態フレームの集合に、前記所定制御の実行のために用いられる同一項目の情報を示す複数の状態フレームが含まれ、受信された順に並べた当該複数の状態フレームが示す当該情報の値が所定規則に従っていない場合に、当該集合に異常な状態フレームが含まれているとして、前記制御対象の状態を偽装状態であると特定することとしても良い。これにより、例えば、車両の状態が第３状態に変化する前においては第１状態、第２状態をこの順に経るという所定規則を定めていたような場合には、車両状態が第１状態であることを示す状態フレームの次に第３状態であることを示す状態フレームが受信されると、偽装状態であると特定される。このため、例えば制御対象としての車両等の仕様に対応して適切に所定規則を定めておくことにより、適切に偽装状態の特定を行うことが可能となる。

また、前記所定基準は、前記所定期間における前記制御対象の状態が、安定状態でない場合に満たされ、安定状態である場合に満たされず、前記安定状態は、前記制御対象の状態を示す特定の状態フレームのデータ値がある一定値或いは一定範囲内である状態であり、前記判定ステップでは、制御フレームに基づく前記所定制御に係る前記判定を、当該制御フレームの受信時に連続する当該受信時の直前の前記所定期間内に前記受信ステップで受信された状態フレームの集合に基づいて特定される、当該所定期間における前記制御対象の状態に基づいて、行ない、前記判定ステップでは、前記所定基準が満たされた場合に前記所定制御を抑止すべきと判定することとしても良い。これにより、攻撃者が、不正な制御フレームの送信の前に、制御対象の状態を偽装する状態フレームを送信して、制御対象の状態が安定状態から外れている場合には、その不正な制御フレームによる制御を抑止すべきと適切に判定することが可能となり得る。

また、前記所定基準は、前記所定期間における前記制御対象の状態が、所定回数を超えて変化する変化多発状態である場合に満たされ、変化多発状態でない場合に満たされず、前記判定ステップでは、前記所定基準が満たされた場合に前記所定制御を抑止すべきと判定することとしても良い。この変化は、例えば、状態を量的に表した場合において一定量を超えた変化、或いは、状態を複数区分に分けて表した場合において区分が変わる変化等である。これにより、正常に送信されたフレームと攻撃者により送信されたフレームとが交互にネットワークの通信路に現れること等によって、瞬間ではなく所定期間において見ればそれらのフレームが示す情報に不整合が生じている状態が生じている場合において、攻撃者に送信された不正な制御フレームによる制御を抑止すべきと適切に判定することが可能となり得る。

また、前記不正制御抑止方法は更に、前記判定ステップで制御フレームに基づく前記所定制御を抑止すべきと判定された場合に、前記所定制御の抑止のための所定処理を実行する処理ステップを含み、前記所定処理は、当該制御フレームを破棄する処理、前記通信路上で当該制御フレームを上書きする処理、他の通信路への当該制御フレームの転送を抑止する処理、及び、前記電子制御ユニットに当該制御フレームに基づく前記所定制御を実行させないように指示する処理のいずれか１つを含むこととしても良い。これにより、攻撃者に送信された不正な制御フレームに基づく所定制御が適切に抑止され得る。

また、前記制御対象は、前記ネットワークシステムを搭載する車両であり、前記通信路は、前記車両における有線通信路であり、前記複数の電子制御ユニットは、ＣＡＮプロトコル又はＥｔｈｅｒｎｅｔ（登録商標）プロトコルに従って、前記複数のフレームの授受を行うこととしても良い。これにより、車載ネットワークのセキュリティの確保が可能となる。

また、前記所定制御は、前記車両の走行に関わる制御であることとしても良い。また、前記受信ステップでは、車速、車輪の回転速度、ヨーレート、加速度、操舵角、アクセルペダル開度、制動レベル、エンジンの回転数、モータの回転数、ギアポジション、及び、イグニッションスイッチの状態のいずれか１つについての情報を含むフレームである状態フレームを逐次受信することとしても良い。これにより、車両の走行を支配するための攻撃者による攻撃への防御が可能となり得る。

また、前記複数のフレームには、前記制御対象の状態に関する情報を含む状態フレームが含まれ、前記複数の電子制御ユニットは、前記通信路であるネットワークに接続され、ＣＡＮプロトコルに従って、データフレームである状態フレーム及び制御フレームの授受を行い、前記不正制御抑止方法は更に、前記判定ステップで制御フレームに基づく前記所定制御を抑止すべきと判定された場合に、当該制御フレームの少なくとも一部に上書きするように前記ネットワークにエラーフレームを送信する処理ステップを含むこととしても良い。これにより、車載ネットワークにおいて効率的に制御フレームを無効化することが可能となる。

また、本発明の一態様に係る不正制御抑止装置は、複数の電子制御ユニットが、制御対象に対して所定制御を指示する制御フレームを含む複数のフレームの授受を通信路を介して行うところの当該通信路に接続される不正制御抑止装置であって、前記通信路から複数のフレームを逐次受信する受信部と、前記受信部により受信された制御フレームに基づく前記所定制御を抑止すべきか否かを、当該制御フレームの受信時に先行する所定期間内に前記受信部により受信されたフレームの集合に基づいて、判定する判定部とを備える不正制御抑止装置である。これにより、所定期間内に受信されたフレームの集合から、その所定期間における制御対象が異常状態である場合に、制御フレームによる制御を抑止すべきと適切に判定され得る。この適切な判定に基づいて制御の抑止を適切に行うことが実現され得る。また、不正制御抑止装置は、複数の電子制御ユニットで構成されるネットワークシステムの通信路に接続するだけで利用され得るので、ネットワークシステムの構成を大きく変更することなく導入可能である。

また、本発明の一態様に係る車載ネットワークシステムは、車両の状態に関する情報を含むフレームである状態フレーム、及び、前記車両に対して所定制御を指示するフレームである制御フレームの授受をネットワークを介して行う複数の電子制御ユニットを備える車載ネットワークシステムであって、前記ネットワークから状態フレーム及び制御フレームを逐次受信する受信部と、前記受信部により受信された制御フレームに基づく前記所定制御を抑止すべきか否かを、当該制御フレームの受信時に先行する所定期間内に前記受信部により受信された状態フレームの集合に基づいて特定される、当該所定期間における前記車両の状態が、所定基準を満たすか否かに基づいて、判定する判定部とを備える車載ネットワークシステムである。これにより、例えば、車両の偽装状態を捉えるように所定基準を定めておくことにより、攻撃者が、車両の状態を偽装する前準備をした上で車両を制御するための不正な制御フレームを送信した場合において、その不正な制御フレームによる制御を抑止すべきと適切に判定し得る。このため、この車載ネットワークシステムは、攻撃に対する適切な防御を行うことが可能となる。

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

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

（実施の形態１）
以下、本発明の実施の形態１として、車載ネットワークを流れるフレームを監視する監視ＥＣＵを含む車載ネットワークシステム１０について、図面を用いて説明する。

［１．１ 車載ネットワークシステム１０の全体構成］
図１は、実施の形態１に係る車載ネットワークシステム１０の全体構成を示す図である。

車載ネットワークシステム１０は、ＣＡＮプロトコルに従って通信するネットワーク通信システムの一例であり、制御装置、センサ、アクチュエータ、ユーザインタフェース装置等の各種機器が搭載された車両におけるネットワーク通信システムである。車載ネットワークシステム１０は、バスを介してフレームに係る通信を行う複数の装置を備え、不正制御抑止方法を用いる。具体的には図１に示すように車載ネットワークシステム１０は、バス３００と、バス３００に接続された監視ＥＣＵ１００、ＥＣＵ２００ａ〜２００ｄ等とを含んで構成される。なお、車載ネットワークシステム１０には、監視ＥＣＵ１００及びＥＣＵ２００ａ〜２００ｄ以外にもいくつものＥＣＵが含まれ得るが、ここでは、便宜上、監視ＥＣＵ１００及びＥＣＵ２００ａ〜２００ｄに注目して説明を行う。車載ネットワークシステム１０を搭載する車両においては、複数のＥＣＵが通信して連携することで、例えば、先進運転者支援システム（ＡＤＡＳ：Advanced Driver Assistance System）
の一機能である駐車支援機能等が実現される。

各ＥＣＵは、例えば、プロセッサ（マイクロプロセッサ）、メモリ等のデジタル回路、アナログ回路、通信回路等を含む装置である。メモリは、ＲＯＭ、ＲＡＭ等であり、プロセッサにより実行されるプログラム（コンピュータプログラム）を記憶することができる。例えばプロセッサが、プログラムに従って動作することにより、ＥＣＵは各種機能を実現することになる。なお、コンピュータプログラムは、所定の機能を達成するために、プロセッサに対する指令を示す命令コードが複数個組み合わされて構成されたものである。ＥＣＵは、各種機器に接続され得る。ＥＣＵ２００ａは、速度センサ２１０に接続されている。ＥＣＵ２００ｂは、車両の後方を撮影するカメラであるリアカメラ２２０、及び、例えば映像、ＧＵＩ（Graphical User Interface）画像等を表示して操作を受け付けるタッチパネル等であるモニタ２３０と接続されている。ＥＣＵ２００ｃは、ハンドル（ステアリングホイール）２４０に接続されている。また、ＥＣＵ２００ｄは、変速機構であるギア２５０に接続されている。

各ＥＣＵは、ＣＡＮプロトコルに従って、バス３００を介してフレームの授受を行う。ＥＣＵ間で授受されるフレームには、例えば、車両の状態に関する情報を含むデータフレーム（状態フレームと称する）、車両に対して制御を指示するデータフレーム（制御フレームと称する）等がある。なお、ＥＣＵ間で、車両の状態に関する状態を含みかつ車両に対して制御を指示するデータフレーム、つまり状態フレームでありかつ制御フレームであるデータフレームの授受がなされても良い。

ＥＣＵ２００ａは、速度センサ２１０から得られる車速（つまり車両の速度）のデータをデータフレームに含めて周期的にバス３００へ送信する。ＥＣＵ２００ｂは、リアカメラ２２０から取得した車両後方の映像を、モニタ２３０に表示し、車両の運転者へ後方の様子を知らせる。また、ＥＣＵ２００ｂは、モニタ２３０へのタッチ操作等による、運転者からの駐車支援機能の開始要求を受け付ける。ここでは、駐車支援機能が、車両の後方の、運転者が指定した駐車スペースを目指して、自動的にハンドルを操作する機能であることとして説明する。ギア２５０を車両の後進のためのギアポジションである「リバース」にして駐車支援機能の開始要求の操作を行えば、運転者は、アクセル及びブレーキの操作を行うだけで、車両を後進させて駐車スペースに駐車させることができる。ＥＣＵ２００ｂは、運転者から駐車支援機能の開始要求を受けると、リアカメラ２２０の情報から、ハンドルを回すべき角度に係る目標操舵角を計算し、ハンドル制御指示を示すデータフレームに、制御フラグと目標操舵角とを示すデータを含めて、周期的にバス３００へ送信する。ここで、ハンドル制御指示を示すデータフレームの制御フラグは、１の値で制御を行うことを示し、０の値で制御を行わないことを示す。制御フラグが１の値であればハンドル制御指示を示すデータフレームは制御フレームである。ＥＣＵ２００ｃは、ＥＣＵ２００ｂから送信された、ハンドル制御指示の制御フレームに従い、ハンドル２４０を制御して車両の進行方向を変化させる。なお、ＥＣＵ２００ｃは、ＥＣＵ２００ａから通知される車速が１０ｋｍ／ｈ以下であり、かつ、ギア２５０のギアポジションが「リバース」であることを確認できた場合に、ハンドル２４０の制御を行う。ＥＣＵ２００ｄは、ギア２５０の現在のギアポジションを示すデータをデータフレームに含めて周期的にバス３００へ送信する。車速を示す状態フレーム及びギアポジションを示す状態フレームは、略一定の周期で逐次送信される。

監視ＥＣＵ１００は、不正制御抑止装置としての一種のＥＣＵであり、バス３００に接続される。監視ＥＣＵ１００は、バス３００に流れる状態フレーム、制御フレーム等のデータフレームを監視し、攻撃者の攻撃により送信された車両制御を指示する不正な制御フレームを検知した場合にその制御フレームを無効化することで不正な車両制御を抑止する。

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

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

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

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

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

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

ＤＬＣは、４ｂｉｔで構成され、データフィールドの長さを示す値である。

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

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

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

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

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

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

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

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

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

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

［１．４ 監視ＥＣＵ１００の構成］
図４は、監視ＥＣＵ１００の構成図である。監視ＥＣＵ１００は、フレーム送受信部１１０と、フレーム処理部１２０と、状態偽装検知部１３０と、機能制限部１４０と、フレーム生成部１５０と、受信履歴保持部１６０と、車両状態保持部１７０と、機能制限ルール保持部１８０とを含んで構成される。図４に示した監視ＥＣＵ１００の各構成要素は、監視ＥＣＵ１００のメモリ等の記憶媒体、通信回路、メモリに格納されたプログラムを実行するプロセッサ等で実現され得る。

フレーム送受信部１１０は、バス３００に対して、ＣＡＮのプロトコルに従ったフレームを送受信する。フレーム送受信部１１０は、バス３００からフレームを１ｂｉｔずつ受信する受信部としての機能を有する。フレーム送受信部１１０は、データフレームを受信して、データフレーム内のＩＤ、ＤＬＣ、データといった情報をフレーム処理部１２０に転送する。また、フレーム送受信部１１０は、ＣＡＮプロトコルに則っていないデータフレームと判断した場合は、エラーフレームを送信する。また、フレーム送受信部１１０は、データフレームの受信中にエラーフレームを受信した場合、つまり受け取ったデータフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのデータフレームを破棄する。フレーム送受信部１１０は、フレーム生成部１５０からデータフレームの送信要求を受けた場合には、そのデータフレームの内容をバス３００に１ｂｉｔずつ送信する。

フレーム処理部１２０は、フレーム送受信部１１０よりデータフレームの情報を受け取り、データフレームの内容を解釈する。また、フレーム処理部１２０は、受信中のデータフレームを状態偽装検知部１３０と機能制限部１４０とに通知する。

状態偽装検知部１３０は、車両の状態が偽装されているか否かを、受信履歴保持部１６０が保持する受信履歴情報を参照して判定する偽装検知処理を行う。受信履歴情報は、データフレームの受信履歴の情報である。状態偽装検知部１３０は、ＩＤ毎に予め規定されたデータフレームの送信間隔に基づいて、先行して受信されたデータフレームからその送信間隔後を中心としたマージンの範囲内に複数の同一のＩＤのデータフレームを受信したか否かによって、車両の状態が偽装されているか否かを判定する。例えば、ＥＣＵ２００ａが周期的に送信するＩＤ「０ｘ１００」の車速に係る状態フレームであるデータフレームの送信間隔が５０ｍｓと予め規定されている場合においては、監視ＥＣＵ１００が、あるＩＤ「０ｘ１００」のデータフレームを受信した時刻＋５０ｍｓ−マージンから、そのデータフレームを受信した時刻＋５０ｍｓ＋マージンまでの範囲の時間である期間Ｔに、ＩＤ「０ｘ１００」のデータフレームを受信する数は１つであると期待される。しかし、攻撃者がこの時間にＩＤ「０ｘ１００」のデータフレームを送信した場合には、ＥＣＵ２００ａから正常に送信されたＩＤ「０ｘ１００」のデータフレームと合わせて、２つのＩＤ「０ｘ１００」のデータフレームがその期間Ｔ内に監視ＥＣＵ１００に受信されることになる。このような場合に、状態偽装検知部１３０は、ＩＤ「０ｘ１００」の状態フレームが示す車速に関して車両の状態が偽装されている偽装状態であると判定する。なお、期間Ｔに２つのＩＤ「０ｘ１００」のデータフレームである状態フレームを監視ＥＣＵ１００が受信した場合には、監視ＥＣＵ１００に受信された状態フレームのうちに、異常な状態フレームが含まれていることになる。このような異常な状態フレームが受信された場合に、同じＩＤの状態フレームが示す車両の状態について、状態偽装検知部１３０によって偽装状態であると判定されることになる。状態偽装検知部１３０は、偽装の判定を行うべき状態フレームのＩＤ毎に予め規定された送信間隔の情報を保持している。また、状態偽装検知部１３０が用いるマージンは、正常に送信されるデータフレームの送信間隔の揺らぎを許容するように適切に定められ、例えば、３ｍｓ等と定められている。また、状態偽装検知部１３０は、偽装検知処理における判定結果に応じて、車両状態保持部１７０に格納されている車両状態情報を更新する。また、状態偽装検知部１３０は、ＥＣＵ２００ａ、ＥＣＵ２００ｄ等から送信される状態フレームのデータの値と、その状態フレームが受信された時刻とに基づいて、受信履歴保持部１６０に格納されている受信履歴情報を更新する。この更新において、状態偽装検知部１３０は、例えば、監視ＥＣＵ１００の起動時から、或いはその他の所定の時からの経過時刻をカウントするタイマにより、状態フレームが受信された時刻を取得して、受信履歴情報に記録する。

機能制限部１４０は、車両の制御のための制御フレームを受信した際に、車両状態保持部１７０に格納されている車両状態情報と、機能制限ルール保持部１８０に格納されている、車両の制御を抑止すべきか否かの基準となる機能制限ルールとを参照して、車両の制御を抑止すべきか否かを判定する。機能制限部１４０は、車両の制御を抑止すべきと判定した場合には、その車両の制御のための、受信中の制御フレームを無効化するために、エラーフレームの送信をフレーム生成部１５０に要求する。このエラーフレームにより、受信中の制御フレームがバス３００上で上書きされ、その制御フレームは無効化されることになる。エラーフレームによる上書きの効果で、ＥＣＵ２００ｃ等のＥＣＵは、バス３００から制御フレームの全体を完全に受信することができないので、制御フレームに従った制御を行わなくなる。

フレーム生成部１５０は、フレームの送信が要求された場合にそのフレームをフレーム送受信部１１０に送信させる。フレーム生成部１５０は、データフレームの送信が要求された場合にはデータフレームを生成して、そのデータフレームをフレーム送受信部１１０に送信させる。

受信履歴保持部１６０は、監視ＥＣＵ１００が受信したデータフレームの受信履歴を保持する。受信履歴保持部１６０は、例えば、直近の１００ｍｓ以内に受信した状態フレームに関するデータ値及び受信の時刻を示す受信履歴情報（図５参照）を保持する。

車両状態保持部１７０は、状態偽装検知部１３０による偽装検知処理において判定された車両状態を示す車両状態情報（図６参照）を保持する。

機能制限ルール保持部１８０は、受信中の制御フレームによる制御を抑止すべきか否かの判定基準となる機能制限ルール（図７参照）を保持する。

［１．５ 受信履歴情報］
図５は、受信履歴保持部１６０が保持する受信履歴情報の一例を示す。同図の例では、受信履歴情報は、直近１００ｍｓ以内に受信されたＩＤ「０ｘ１００」の車速を示す状態フレームと、ＩＤ「０ｘ３００」のギアポジションを示す状態フレームとの受信の時刻とデータ値とを含む。

この例の受信履歴情報によれば、車速に係るＩＤ「０ｘ１００」の状態フレームに関しては、最新の受信時におけるデータ値が４２．１ｋｍ／ｈであり、受信の時刻は１１０ｍｓである。１回前の受信時においては、その車速の状態フレームのデータ値が０．０ｋｍ／ｈであり、受信の時刻は６１ｍｓである。２回前の受信時においては、その車速の状態フレームのデータ値が４２．０ｋｍ／ｈであり、受信の時刻は６０ｍｓである。また、３回前の受信時においては、その車速の状態フレームのデータ値が４２．０ｋｍ／ｈであり、受信の時刻は１０ｍｓである。また、ギアポジションに係るＩＤ「０ｘ３００」の状態フレームに関しては、最新の受信時におけるデータ値が、車両の前進のためのギアポジションである「ドライブ」を示し、受信の時刻は１００ｍｓである。また、１回前の受信時においては、データ値が「ドライブ」を示し、受信の時刻は５０ｍｓである。図５の例では、更に前回には、ギアポジションに係る状態フレームは、受信されておらず、或いは、直近１００ｍｓより前に受信されており、保持されていない。

［１．６ 車両状態情報］
図６は、車両状態保持部１７０が保持する車両状態情報の一例を示す。同図の例では、車両状態情報として、車速に係るＩＤ「０ｘ１００」の状態フレームに関連する車両の状態と、ギアポジションに係るＩＤ「０ｘ３００」の状態フレームに関連する車両の状態とが、偽装フラグによって示されている。この例では偽装フラグは、１であれば車両の状態が偽装状態であることを示し、０であれば偽装状態でないことを示す。偽装状態は、例えば、攻撃者により、車両の状態としての車速、ギアポジション等について偽のデータ値を示す状態フレームがバス３００上に流された状態、つまり車両の状態が偽装されている状態である。図６の例では、ＩＤ「０ｘ１００」の状態フレームで示される車速に係る車両の状態が、偽装状態であることを示している。また、ＩＤ「０ｘ３００」の状態フレームで示されるギアポジションに係る車両の状態が、偽装状態ではないことを示している。

［１．７ 機能制限ルール］
図７は、機能制限ルール保持部１８０が保持する機能制限ルールの一例を示す。

機能制限ルールは、車両の制御を抑止すべきか否かの基準を示す情報であり、同図の例では、車両の制御を行う制御フレームを特定する情報である機能制限対象と、基準となる車両状態の条件とを対応付けたものである。同図には、機能制限ルールが複数項目のルールで構成される例を示しているが、ルールの項目数は１つであっても複数であっても良い。

この例では、ルール番号１の制限対象機能は、ハンドル制御指示に係るＩＤ「０ｘ２００」のデータフレームに含まれる制御フラグが１であるデータフレーム（つまりハンドル制御指示に係る制御フレーム）であり、ハンドル制御を抑止するための車両状態の条件は、車速に係るＩＤ「０ｘ１００」の状態フレームに関連する車両の状態が偽装状態（つまり偽装フラグが１）であることである。また、ルール番号２の制限対象機能も、同様に、ハンドル制御指示に係る制御フレームであり、ハンドル制御を抑止するための車両状態の条件は、ギアポジションに係るＩＤ「０ｘ３００」の状態フレームに関連する車両の状態が偽装状態（つまり偽装フラグが１）であることである。

機能制限部１４０は、機能制限ルールを参照して、受信中の制御フレームに該当する機能制限対象に対応する車両状態の条件が満たされている場合に、その制御フレームによる車両の制御を抑止すべきと判定し、その制御フレームを無効化すべくフレーム生成部１５０にエラーフレームの送信の要求を行う。具体的には、機能制限部１４０は、ハンドル制御指示に係る制御フレームを受信した際に、図７のルール番号１の項目のルールに従って、車両状態保持部１７０が保持する車両状態情報においてＩＤ「０ｘ１００」の状態フレームで示される車速に係る車両の状態が偽装状態（つまり偽装フラグが１）となっていた場合に、その制御フレームを無効化するために、フレーム生成部１５０に対してエラーフレームの送信要求を行う。機能制限部１４０は、図７のルール番号２の項目のルールに従って、車両状態情報においてＩＤ「０ｘ３００」の状態フレームで示されるギアポジションに係る車両の状態が偽装状態（つまり偽装フラグが１）となっていた場合には、そのハンドル制御指示に係る制御フレームを無効化するために、フレーム生成部１５０に対してエラーフレームの送信要求を行う。そのハンドル制御指示に係る制御フレームの受信の際において機能制限部１４０は、車速に係る車両の状態が偽装状態でなく、ギアポジションに係る車両の状態が偽装状態でない場合には、エラーフレームの送信要求を行わない。

［１．８ ＥＣＵ２００ａの構成］
図８は、ＥＣＵ２００ａの構成図である。ＥＣＵ２００ａは、フレーム送受信部２０１と、フレーム処理部２０２と、機器入出力部２０３と、フレーム生成部２０４とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、ＥＣＵ２００ａにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。なお、ＥＣＵ２００ｂ、ＥＣＵ２００ｃ及びＥＣＵ２００ｄもＥＣＵ２００ａと概ね同様の構成を有する。

フレーム送受信部２０１は、バス３００に対して、ＣＡＮのプロトコルに従ったフレームを送受信する。フレーム送受信部２０１は、バス３００からデータフレームを１ｂｉｔずつ受信し、エラー無くデータフレームの受信を完了すると、データフレーム内のＩＤ、ＤＬＣ、データといった情報をフレーム処理部２０２に転送する。フレーム送受信部２０１は、ＣＡＮプロトコルに則っていないデータフレームと判断した場合は、エラーフレームを送信する。フレーム送受信部２０１は、データフレームの受信中にエラーフレームを受信した場合には、それ以降そのデータフレームを破棄する。また、フレーム送受信部２０１は、フレーム生成部２０４より通知を受けたフレームの内容をバス３００に送信する。通信調停といったＣＡＮのプロトコルに則った処理も、フレーム送受信部２０１において実現される。

フレーム処理部２０２は、受信したデータフレームの内容を解釈する。ＥＣＵ２００ａと同様の構成を備えるＥＣＵ２００ｃを例として説明すると、ＥＣＵ２００ｃのフレーム処理部２０２では、ＥＣＵ２００ａ、ＥＣＵ２００ｂ及びＥＣＵ２００ｄから送信されるデータフレームに含まれる車速、ハンドル制御指示、ギアポジション等の情報を解釈し、必要に応じてハンドル２４０の制御を行うための制御情報を、機器入出力部２０３に通知する。なお、ＥＣＵ２００ｃのフレーム処理部２０２では、ＥＣＵ２００ａから通知される車速が１０ｋｍ／ｈを超えている場合、或いは、ＥＣＵ２００ｄから通知されるギアポジションが、「リバース」以外である場合には、ハンドル制御指示に係る制御フレーム（つまりＩＤ「０ｘ２００」を有し、制御フラグが１であるデータフレーム）が受信されても、ハンドル２４０を制御しない。

機器入出力部２０３は、ＥＣＵに接続される機器と通信を行う通信回路等で構成される。ＥＣＵ２００ａの機器入出力部２０３は、速度センサ２１０から現在の車速を取得し、車速を示すデータフレームを生成して送信させるべくフレーム生成部２０４に車速を通知する。ＥＣＵ２００ｂの機器入出力部２０３は、リアカメラ２２０から、車両後方の状況を示す映像データを取得する。また、ＥＣＵ２００ｂの機器入出力部２０３は、モニタ２３０に対する運転者の駐車支援機能の開始要求の操作を受付け、車両後方の状況から、ハンドル２４０を制御するための目標操舵角を計算し、ハンドル制御指示に係る制御フレームの生成のために目標操舵角を、フレーム生成部２０４に通知する。また、ＥＣＵ２００ｃの機器入出力部２０３は、ＥＣＵ２００ｂから通知されたハンドル制御指示に係る制御フレーム等に基づく制御情報に応じて、ハンドル２４０を制御する。また、ＥＣＵ２００ｄの機器入出力部２０３は、ギア２５０から現在のギアポジションを取得し、ギアポジションを示すデータフレームを生成して送信させるべくフレーム生成部２０４にギアポジションを通知する。

フレーム生成部２０４は、機器入出力部２０３から通知された情報に基づいてバス３００へ送信するデータフレームを生成し、生成したデータフレームを、フレーム送受信部２０１を介してバス３００へ送信する。例えばＥＣＵ２００ａにおいては、フレーム生成部２０４は、機器入出力部２０３から通知された速度センサ２１０からの車速の情報を含んだデータフレームを、予め定められた周期である５０ｍｓ間隔で生成し、フレーム送受信部２０１に通知する。なお、データフレームの生成の間隔としての５０ｍｓは、周期の一例に過ぎず、５０ｍｓ以外であっても良い。ＥＣＵ２００ａ、ＥＣＵ２００ｂ及びＥＣＵ２００ｄがそれぞれ送信するデータフレームの例について次に図９を用いて説明する。

［１．９ ＥＣＵが送信するデータフレーム］
図９は、ＥＣＵ２００ａ、ＥＣＵ２００ｂ及びＥＣＵ２００ｄのそれぞれにより送信されるデータフレームの例を示す。

図９において（ａ）の例は、ＥＣＵ２００ａが送信するデータフレーム、つまり車速に係る状態フレームの例である。この車速に係る状態フレームは、ＩＤ「０ｘ１００」を有し、ＤＬＣが２であり、そのデータフィールドは、１バイト目と２バイト目とを合わせた２バイトで車速（０．１ｋｍ／ｈ単位）を表す。図９の（ａ）のデータフレームの例は、車速として４２．１ｋｍ／ｈ（０ｘ１Ａ５）を示す状態フレームを表している。

図９において（ｂ）の例は、ＥＣＵ２００ｂが送信するデータフレーム、つまりハンドル制御指示に係るデータフレームの例である。このハンドル制御指示に係るデータフレームは、ＩＤ「０ｘ２００」を有し、ＤＬＣが４であり、そのデータフィールドは、１バイト目が、ハンドル制御を行うか否か表す制御フラグであり、１の場合には、ハンドル２４０の制御が行われるべきことを示し、０の場合にはハンドル２４０の制御が行われるべきでないことを示す。２バイト目は、ハンドル制御を指示する場合に、左右いずれの方向にハンドル２４０が回されるべきかを、右は０、左は１で示す。データフィールドの３バイト目と４バイト目とを合わせた２バイトとで、ハンドル２４０の制御のための目標操舵角を示す。図９の（ｂ）のデータフレームの例は、右に４８度回すというハンドル制御指示を示す制御フレームを表している。

図９において（ｃ）の例は、ＥＣＵ２００ｄが送信するデータフレーム、つまりギアポジションに係る状態フレームの例である。このギアポジションに係る状態フレームは、ＩＤ「０ｘ３００」を有し、ＤＬＣが１であり、そのデータフィールドは、１バイトでギアポジションを表す。その１バイトの値が０で、「ニュートラル」を表し、１で「リバース」を表し、２で「ドライブ」を表し、３で「パーキング」を表す。図９の（ｃ）のデータフレームの例は、ギアポジションとして「リバース」を示す状態フレームを表している。

［１．１０ 駐車支援機能のシーケンス］
図１０は、正常状態での駐車支援機能に係る処理シーケンスの一例を示す。

ＥＣＵ２００ａは、車速を示す状態フレーム（つまりＩＤ「０ｘ１００」を有するデータフレーム）をバス３００に送信する（ステップＳ１１）。データフレームは、バス３００に接続される全てのＥＣＵにブロードキャストされることになる。ハンドル２４０の制御を担うＥＣＵ２００ｃは、その車速を示す状態フレームを受信すべきＩＤのデータフレームとしてバス３００から受信し、その状態フレームに基づいて、現在の車速を、更新して保持する。なお、ＥＣＵ２００ａは、車速を示す状態フレームを予め規定された５０ｍｓの送信間隔で送信するが、図１０では、以降の、車速に係る状態フレームの送信を省略している。

また、ＥＣＵ２００ｄは、ギアポジションを示す状態フレーム（つまりＩＤ「０ｘ３００」を有するデータフレーム）をバス３００に送信する（ステップＳ１２）。ＥＣＵ２００ｃは、そのギアポジションを示す状態フレームを受信すべきＩＤのデータフレームとしてバス３００から受信し、その状態フレームに基づいて、現在のギアポジションを、更新して保持する。なお、ＥＣＵ２００ｄは、ギアポジションを示す状態フレームを５０ｍｓの送信間隔で送信するが、図１０では、以降の、ギアポジションに係る状態フレームの送信を省略している。

モニタ２３０に対して運転者が駐車支援機能の実行開始の操作を行うと、モニタ２３０から駐車支援要求がＥＣＵ２００ｂに伝えられる（ステップＳ１３）。

ＥＣＵ２００ｂは、駐車支援要求が伝えられると、リアカメラ２２０から取得した、車両の後方の映像をモニタ２３０へ表示する（ステップＳ１４）。

モニタ２３０に表示された映像を見て、運転者がモニタ２３０の操作により駐車位置を指定すると、モニタ２３０は、その駐車位置を示す駐車位置決定通知を、ＥＣＵ２００ｂに伝える（ステップＳ１５）。

ＥＣＵ２００ｂは、駐車位置決定通知が示す駐車位置に基づいて、目標となるハンドル２４０の操舵角（つまり目標操舵角）を計算し、ＩＤ「０ｘ２００」を有するデータフレームとして、制御フラグを１にし、目標操舵角の情報を含ませて送信する（ステップＳ１６）。つまり、ＥＣＵ２００ｂは、ハンドル制御指示に係る制御フレームを送信する。なお、ＥＣＵ２００ｂは、ＩＤ「０ｘ２００」を有するデータフレームを、ハンドル２４０の目標操舵角を適切な値に逐次更新して、周期的に送信するが、図１０では、以降の、ＩＤ「０ｘ２００」を有するデータフレームの送信を省略している。

ＥＣＵ２００ｃは、ハンドル制御指示に係る制御フレーム（つまりＩＤ「０ｘ２００」を有し制御フラグが１であるデータフレーム）を受信し、かつ、現在の車速が１０ｋｍ／ｈ以下であり、かつ、ギアポジションが「リバース」である場合にのみ、ハンドル２４０を目標操舵角になるように回す制御を行う（ステップＳ１７）。

［１．１１ 駐車支援機能に対する攻撃の抑止に係るシーケンス］
図１１は、駐車支援機能への攻撃、及び、監視ＥＣＵ１００による不正制御抑止処理に係るシーケンスの一例を示す。ここでは、監視ＥＣＵ１００は、図７に例示した機能制限ルールを保持しているものとする。また、駐車支援機能の実行開始の操作がなされておらず車両は前進走行を行っていることとする。また、ＥＣＵ２００ｄは、ギアポジションが「ドライブ」であることを示す状態フレームを周期的に送信していることとする。なお、図１１では、ギアポジションに係る状態フレームについての記載を省略する。

ＥＣＵ２００ａは、車速を示す状態フレーム（つまりＩＤ「０ｘ１００」を有するデータフレーム）をバス３００に送信する（ステップＳ２１）。この例では、現在の車速は、４２．１ｋｍ／ｈである。

ＥＣＵ２００ｃがハンドル２４０の制御を行うためには、車速が１０ｋｍ／ｈ以下という条件を満たす必要がある。このため、攻撃ＥＣＵは、ハンドル２４０を不正に制御する前段階として、ＩＤ「０ｘ１００」を有し車速が０ｋｍ／ｈであるという偽の情報を示すデータフレーム、つまり車速に係る偽の情報を示す状態フレームを送信する（ステップＳ２２）。攻撃ＥＣＵは、バス３００に接続されたＥＣＵであり、例えば、攻撃者がバス３００に接続したＥＣＵ、攻撃者がハッキング等により支配したＥＣＵ等である。なお、攻撃ＥＣＵは、例えば、ＥＣＵ２００ａによる車速に係る状態フレームの送信周期を観測し、予め規定された送信間隔のマージンの範囲の期間に、同じＩＤを有する車速に係る偽の情報を示す状態フレームを送信する。これにより、車速に係る偽の情報を示す状態フレームが、送信タイミングから単純に不正なフレームであると検知され難くなる。

ステップＳ２２で送信された車速に係る偽の情報を示す状態フレームを受信したＥＣＵ２００ｃは、保持する現在の車速を、０ｋｍ／ｈに更新する。また、監視ＥＣＵ１００は、偽装検知処理により、車速に係るＩＤ「０ｘ１００」の状態フレームが、１回受信されることが期待される期間において、つまり予め規定された送信間隔に係るマージンの範囲内の期間において、２回受信されたことから、ＩＤ「０ｘ１００」の状態フレームで示される車速に関する車両の状態が偽装状態であると判定する。これにより、車両状態情報における車速に関する偽装フラグが１になる。

ＥＣＵ２００ｂは、ＩＤ「０ｘ２００」を有する、ハンドル制御指示を示すデータフレームを送信する（ステップＳ２３）。このとき駐車支援機能の実行は開始されていないので、ハンドル制御を行うか否かを示す制御フラグは０であり、ハンドル２４０は制御されない。これに対して監視ＥＣＵ１００は、ＩＤ「０ｘ２００」を有するデータフレームに含まれる制御フラグが０であることから、機能制限ルールの各ルールの機能制限対象ではないので、エラーフレームの送信等を行わない。

次に攻撃ＥＣＵは、ハンドル２４０を不正に制御するために、ＩＤ「０ｘ２００」を有し制御フラグを１にしたデータフレーム（つまりハンドル制御指示に係る制御フレーム）を送信する（ステップＳ２４）。これに対して、監視ＥＣＵ１００は、その制御フレームの受信中に、機能制限ルール及び車両状態情報に基づいて、車両の制御を抑止すべきか否かを判定する。監視ＥＣＵ１００は、ステップＳ２４で送信された制御フレームが機能制限ルールのルール番号１の項目のルールの機能制限対象に合致して、対応する車両状態の条件が満たされているので、その制御フレームによる車両の制御を抑止すべきと判定する。

続いて、監視ＥＣＵ１００は、受信中の制御フレームによる車両の制御を抑止すべきと判定したので、そのハンドル制御指示に係る制御フレームを無効化するために、エラーフレームを送信する（ステップＳ２５）。エラーフレームの送信により、監視ＥＣＵ１００は、攻撃によるハンドル２４０の不正な制御を抑止し得る。このエラーフレームにより、送信中であったＩＤ「０ｘ２００」を有するデータフレームが上書きされ、結果的に、攻撃ＥＣＵによるそのデータフレームの送信が中断されたことになる。ＥＣＵ２００ｃは、そのエラーフレームを受信することにより、受信中のデータフレームを破棄して、そのデータフレームに基づくハンドル２４０の制御を行わない。

このように、監視ＥＣＵ１００は、機能制限ルールに基づく判定結果次第でエラーフレームの送信を行うことで、攻撃ＥＣＵによるハンドル２４０を不正に制御するためのデータフレームのＥＣＵ２００ｃによる受信を、阻止することができる。

［１．１２ 監視ＥＣＵ１００による監視動作］
図１２は、監視ＥＣＵ１００による監視動作の一例を示すフローチャートである。この監視動作に係る処理は、バス３００にデータフレームが現れる度に行われる。

監視ＥＣＵ１００は、データフレームを受信し、受信中のデータフレームのＩＤが、受信履歴保持部１６０に受信履歴を保持すべきデータフレームのＩＤであるか否かを判断する（ステップＳ３１）。なお、この例では、受信履歴の保持対象のデータフレームのＩＤは、機能制限ルールにおける機能制限対象となるデータフレームのＩＤとは異なることとするが、これは一例に過ぎない。例えば、受信履歴の保持対象に係るＩＤは、車速に係る状態フレームのＩＤ「０ｘ１００」及びギアポジションに係る状態フレームのＩＤ「０ｘ３００」である（図５参照）。

監視ＥＣＵ１００は、受信中のデータフレームのＩＤが、受信履歴保持部１６０に受信履歴を保持すべきデータフレームのＩＤである場合は、受信中のデータフレームの車速等を示すデータ値と、受信の時刻とを含ませるように、受信履歴保持部１６０が保持する受信履歴情報を更新する（ステップＳ３２）。なお、監視ＥＣＵ１００は、この受信履歴情報の更新に際して、例えば、受信の時刻が現在時刻より一定時間（例えば１００ｍｓ）より前の受信履歴の情報を消去しても良い。

また、監視ＥＣＵ１００は、受信履歴保持部１６０が保持する受信履歴情報を参照して偽装検知処理を行う（ステップＳ３３）。具体的には、監視ＥＣＵ１００は、状態偽装検知部１３０により、例えば、受信履歴情報における１つのＩＤに係る状態フレーム（データフレーム）の受信履歴のうち最も古い状態フレームの受信の時刻に、予め規定された送信間隔（例えば５０ｍｓ）を加算した時刻を基準時刻として、マージン（例えば３ｍｓ）を基準時刻から減算した時刻からと加算した時刻までの範囲（受信タイミング範囲と称する）に、いくつの状態フレームを受信しているかを数える。そして、２以上の状態フレームを受信している場合に、車両の状態が偽装されていると判定し、車両状態保持部１７０の対応するＩＤの偽装フラグを１にする。同様に、受信タイミング範囲内に最初に受信した状態フレームの受信の時刻から、予め規定された送信間隔（例えば５０ｍｓ）を加算した時刻を基準として、次の受信タイミング範囲を求め、車両の状態が偽装されているかを、最近に受信した状態フレームまで繰り返す。更に、いずれの受信タイミング範囲内にも含まれない状態フレームが受信履歴に含まれる場合に、偽装フラグを１に更新する。このような処理で、偽装フラグを１にしない場合には、偽装フラグを０にする。この偽装検知処理では、車両の状態が偽装状態であるか否かの判定が行なわれるが、受信履歴保持部１６０が保持する受信履歴情報に受信履歴が示される各状態フレームが不正か否か（つまり攻撃によるものか否か）の識別までは行われない。

監視ＥＣＵ１００は、ステップＳ３１で、受信中のデータフレームのＩＤが、受信履歴保持部１６０に受信履歴を保持すべきデータフレームのＩＤでないと判断した場合には、機能制限対象となるデータフレームのＩＤであるか否かを判断する（ステップＳ３４）。監視ＥＣＵ１００は、受信中のデータフレームのＩＤが、機能制限対象となるデータフレームのＩＤでないと判断した場合には、処理を終了する。

監視ＥＣＵ１００は、ステップＳ３４で、受信中のデータフレームのＩＤが、機能制限対象となるデータフレームのＩＤであると判断した場合には、受信中のデータフレームが機能制限対象のデータフレームであるか否かを判断する（ステップＳ３５）。具体的には、監視ＥＣＵ１００は、機能制限ルール保持部１８０が保持する機能制限ルールを参照することで、制御フラグが１であるハンドル制御指示に係るデータフレームである制御フレームか否かを判断する。受信中のデータフレームが機能制限対象の制御フレームでなければ、監視ＥＣＵ１００は、処理を終了する。

ステップＳ３５で、受信中のデータフレームが機能制限対象の制御フレームであると判断した場合には、監視ＥＣＵ１００は、その制御フレームに係る車両の制御を抑止すべきか否かを判定する。具体的には、監視ＥＣＵ１００は、機能制限ルールと、車両状態保持部１７０が保持する車両状態情報とを参照し、その制御フレームが機能制限対象であってその車両状態の条件が成立しているか否かを検証することでその判定を行う（ステップＳ３６）。監視ＥＣＵ１００は、ステップＳ３６での検証の結果、機能制限ルールにおいてその制御フレームを機能制限対象とする各項目のルールについて、いずれも車両状態の条件が成立していなければ、処理を終了する。

監視ＥＣＵ１００は、ステップＳ３６での検証の結果、車両状態の条件が成立していれば、受信中のデータフレームを無効化するために、受信中のデータフレームの最後尾が受信される前にエラーフレームをバス３００に送信する（ステップＳ３７）。これにより、その受信中のデータフレームにエラーフレームが上書きされて、そのデータフレームは無効化される。このため、バス３００に接続されたＥＣＵ（例えばＥＣＵ２００ｃ）は、その無効化されたデータフレームに基づく車両の制御を行わない。

［１．１３ 実施の形態１の効果］
実施の形態１に係る車載ネットワークシステム１０では、監視ＥＣＵ１００が、一定期間に受信した状態フレームの集合に基づいて、状態フレームの送信間隔に係る予め定められた規定を利用することで、一定期間における車両の状態が偽装状態であったことを検知する。そして、監視ＥＣＵ１００は、車両の状態が偽装状態であった場合において、車両の制御を行うための制御フレームが送信されているときにその制御フレームを無効化することで、その車両の制御を抑止する。これにより、車両の状態を偽装して車両を不正に制御するような攻撃に対する防御が可能となり、車載ネットワークのセキュリティが確保され得る。また、この防御のための不正制御抑止方法は、監視ＥＣＵ１００を、車載ネットワークに配置することで実現できるので、コストを抑えて車載ネットワークを保護することが可能となる。

（実施の形態２）
以下、実施の形態１で示した車載ネットワークシステム１０の一部を変形した車載ネットワークシステム１１について説明する。

本実施の形態に係る車載ネットワークシステム１１における監視ＥＣＵは、車載ネットワークを流れる状態フレームを監視し、現在の車両の状態が継続している時間を計測し、車両の状態が、一定時間継続した安定状態であるか否かに係る基準に基づいて、車両を制御する制御フレームによる制御機能を制限する。

［２．１ 車載ネットワークシステム１１の全体構成］
図１３は、本発明に関わる車載ネットワークシステム１１の全体構成を示す図である。

車載ネットワークシステム１１は、図１３に示すように、バス３００と、バス３００に接続された監視ＥＣＵ２１００、ＥＣＵ２００ａ〜２００ｄ等とを含んで構成される。車載ネットワークシステム１１は、ここで特に説明しない点については実施の形態１で示した車載ネットワークシステム１０（図１参照）と同じである。車載ネットワークシステム１１の構成要素のうち、車載ネットワークシステム１０と同様の構成要素については、図１３において、図１と同じ符号を付しており、ここでの説明を省略する。

監視ＥＣＵ２１００は、不正制御抑止装置としての一種のＥＣＵであり、バス３００に接続される。監視ＥＣＵ２１００は、バス３００に流れる状態フレーム、制御フレーム等のデータフレームを監視し、車両の状態の継続時間を計測する。監視ＥＣＵ２１００は、計測した車両の状態の継続時間に応じて、車両を制御する制御フレームによる制御を抑止すべきか否かを判定し、抑止すべき場合に制御フレームを無効化することで不正な車両制御を抑止する。

［２．２ 監視ＥＣＵ２１００の構成］
図１４は、監視ＥＣＵ２１００の構成図である。監視ＥＣＵ２１００はフレーム送受信部１１０と、フレーム処理部１２０と、車両状態監視部２１３０と、機能制限部２１４０と、フレーム生成部１５０と、受信履歴保持部２１６０と、機能制限ルール保持部２１８０とを含んで構成される。図１４に示した監視ＥＣＵ２１００の各構成要素は、監視ＥＣＵ２１００のメモリ等の記憶媒体、通信回路、メモリに格納されたプログラムを実行するプロセッサ等で実現され得る。監視ＥＣＵ２１００は、ここで特に説明しない点については実施の形態１で示した監視ＥＣＵ１００（図４参照）と同じである。監視ＥＣＵ２１００の構成要素のうち、監視ＥＣＵ１００と同様の機能を有する構成要素は、図１４において図４と同じ符号を付しており、ここでの説明を適宜省略する。

フレーム処理部１２０は、受信中のデータフレームを車両状態監視部２１３０と機能制限部２１４０とに通知する。

車両状態監視部２１３０は、フレーム処理部１２０から通知されたデータフレームについて、受信履歴保持部２１６０が保持している受信履歴情報における、対応するＩＤに関する受信履歴を更新する。具体的には、車両状態監視部２１３０は、ＥＣＵ２００ａ、ＥＣＵ２００ｄ等から送信される状態フレームのデータの値と、その状態フレームが受信された時刻とに基づいて、受信履歴情報を更新する。この更新において、車両状態監視部２１３０は、例えば、監視ＥＣＵ２１００の起動時から、或いはその他の所定の時からの経過時刻をカウントするタイマにより、状態フレームが受信された時刻を取得して、直近１００ｍｓ以内に受信した状態フレームに関する情報を示すように、受信履歴情報を更新する。

機能制限部２１４０は、車両の制御のための制御フレームを受信した際に、機能制限ルール保持部２１８０に格納されている、車両の制御を抑止すべきか否かの基準となる機能制限ルールと、受信履歴保持部２１６０が保持する受信履歴情報とを参照して、車両の制御を抑止すべきか否かを判定する。機能制限部２１４０は、車両の制御を抑止すべきと判定した場合には、その車両の制御のための、受信中の制御フレームを無効化するために、エラーフレームの送信をフレーム生成部１５０に要求する。具体的には、車両の制御を抑止すべきか否かの判定のために、機能制限部２１４０は、機能制限ルールにおいて機能制限対象とされている制御フレームが受信中である場合に、車両の状態の継続時間の計測結果を取得し、受信履歴情報が示す状態フレームの受信履歴が示す車両の状態が、機能制限ルールにおける車両状態継続時間の条件を満たす不安定状態であるか、否か（つまり安定状態であるか）を判定する。

受信履歴保持部２１６０は、監視ＥＣＵ２１００が受信したデータフレームの受信履歴を保持する。受信履歴保持部２１６０は、例えば、直近の１００ｍｓ以内に受信した状態フレームに関するデータ値及び受信の時刻を示す受信履歴情報（図１５参照）を保持する。

機能制限ルール保持部２１８０は、受信中の制御フレームによる制御を抑止すべきか否かの判定基準となる機能制限ルール（図１６参照）を保持する。

［２．３ 受信履歴情報］
図１５は、受信履歴保持部２１６０が保持する受信履歴情報の一例を示す。同図の例では、受信履歴情報は、直近１００ｍｓ以内に受信されたＩＤ「０ｘ１００」の車速を示す状態フレームと、ＩＤ「０ｘ３００」のギアポジションを示す状態フレームとの受信の時刻とデータ値とを含む。

この例の受信履歴情報によれば、車速に係るＩＤ「０ｘ１００」の状態フレームに関しては、最新の受信時におけるデータ値が０．０ｋｍ／ｈであり、受信の時刻は２１１ｍｓである。１回前の受信時においては、その車速の状態フレームのデータ値が４２．１ｋｍ／ｈであり、受信の時刻は２１０ｍｓである。また、２回前の受信時においては、その車速の状態フレームのデータ値が４２．０ｋｍ／ｈであり、受信の時刻は１６０ｍｓである。また、ギアポジションに係るＩＤ「０ｘ３００」の状態フレームに関しては、最新の受信時におけるデータ値が「リバース」を示し、受信の時刻は２０１ｍｓである。１回前の受信時においては、データ値が「ドライブ」を示し、受信の時刻は２００ｍｓである。また、２回前の受信時においては、データ値が「ドライブ」を示し、受信の時刻は１５０ｍｓである。

［２．４ 機能制限ルール］
図１６は、機能制限ルール保持部２１８０が保持する機能制限ルールの一例を示す。

機能制限ルールは、車両の制御を抑止すべきか否かの基準を示す情報であり、同図の例では、車両の制御を行う制御フレームを特定する情報である機能制限対象と、基準となる車両状態の条件（具体的には車両状態継続時間の条件）とを対応付けたものである。同図には、機能制限ルールが複数項目のルールで構成される例を示しているが、ルールの項目数は１つであっても複数であっても良い。

この例では、ルール番号１の制限対象機能は、ハンドル制御指示に係るＩＤ「０ｘ２００」のデータフレームに含まれる制御フラグが１であるデータフレーム（つまりハンドル制御指示に係る制御フレーム）であり、ハンドル制御を抑止すべきと判定するための車両状態の条件は、車速に係るＩＤ「０ｘ１００」の状態フレームに関連する車両の状態が不安定状態であることである。図１６の例では、車速に係る不安定状態は、車速が１０ｋｍ／ｈ以下の状態である継続時間が６０ｍｓより短い状態を意味する。車速が１０ｋｍ／ｈ以下の状態である継続時間が６０ｍｓ以上であれば安定状態となる。つまり、機能制限部２１４０は、現在から６０ｍｓ前までの間に、１０ｋｍ／ｈより大きい車速を示す状態フレームが１つ以上受信されていれば、ルール番号１の車両状態継続時間の条件が満たされているとして、機能制限対象であるハンドル制御指示に係る制御フレームによる制御を抑止すべきと判定する。

図１６の例では、ルール番号２の項目のルールは、ギアポジションに係るＩＤ「０ｘ３００」の状態フレームに関連する車両の状態が不安定状態であることである。図１６の例では、ギアポジションに係る不安定状態は、ギアポジションが「リバース」である状態の継続時間が６０ｍｓより短い状態を意味する。機能制限部２１４０は、現在から６０ｍｓ前までの間に、「リバース」以外のギアポジションを示す状態フレームが１つ以上受信されていれば、ルール番号２の車両状態継続時間の条件が満たされているとして、機能制限対象であるハンドル制御指示に係る制御フレームによる制御を抑止すべきと判定する。なお、車両状態継続時間の条件については、対象となる状態フレームについて予め規定された送信間隔等を考慮して設定しておくことが有用である。例えば状態フレームの送信間隔が５０ｍｓであった場合に、車両状態継続時間の条件としての継続時間を６０ｍｓとすると、６０ｍｓの間に、少なくとも１つのデータフレームを受信することになる。攻撃者が、車速等の車両の状態を偽装する情報を示す状態フレームを送信した場合でも、正常な状態フレームの受信により、車両状態継続時間が０にリセットされる。このため、機能制限を解除する安定状態となるように６０ｍｓより長い継続時間に亘って車速等の車両の状態を偽装することができない。図１７に、車速に係る車両の状態を偽装する偽装フレームの送信という攻撃がなされた場合における車両の状態の継続時間を示す。図１７では、時刻ｔ１、ｔ３、ｔ５において０．０ｋｍ／ｈという偽の車速を示す状態フレームが、時刻ｔ０、ｔ２、ｔ４等にＥＣＵ２００ａが周期的に送信する正常な車速（例えば４２．０Ｋｍ／ｈ）を示す状態フレームの直後に送信されている。逐次送信される状態フレームによって示される車速が１０ｋｍ／ｈ以下である時間は６０ｍｓより短くなる。このように攻撃がなされている場合のハンドル制御指示に係る制御フレームの受信時においては、機能制限部２１４０は、例えば図１７のルール番号１の項目のルールに従って、直近の６０ｍｓの期間において車両の状態が安定状態でないので、ハンドル制御指示に係る制御フレームを無効化するために、フレーム生成部１５０に対してエラーフレームの送信要求を行う。

なお、ＩＤ「０ｘ２００」を有し制御フラグが１であるデータフレーム（つまりハンドル制御指示に係る制御フレーム）は、車速が１０ｋｍ／ｈ以下であり、ギアポジションが「リバース」であるときにしかバス３００に流されないように、車載ネットワークシステム１１は、設計されている。そして、運転者により、駐車支援機能の実行開始の操作及び駐車位置の指定の操作がなされた後に、ハンドル制御指示に係る制御フレームは、バス３００に送信される。運転者が車両を停車させ、ギアポジションを「リバース」に変更してから、モニタ２３０の操作により駐車支援機能の実行開始を要求して駐車位置を指定するまでに、数秒は時間が経過すると考えられる。正常に駐車支援機能を利用した場合には、機能制限対象の正常なデータフレーム（つまりハンドル制御指示に係る制御フレーム）が送信される際には、１０ｋｍ／ｈ以下の車速、及び、「リバース」というギアポジションに係る車両の状態が６０ｍｓよりも長く継続している。このため、その正常な制御フレームによるハンドルの制御が、機能制限部２１４０により抑止されるべきと判定されることはない。従って、攻撃を受けずに正常に駐車支援機能が利用された場合のハンドル制御指示に係る制御フレームの受信時においては、機能制限部２１４０は、直近の６０ｍｓの期間において、１０ｋｍ／ｈ以下の車速、及び、「リバース」というギアポジションに係る車両の状態が、継続する安定状態であるので、エラーフレームの送信要求を行わない。

［２．５ 駐車支援機能に対する攻撃の抑止に係るシーケンス］
図１８は、駐車支援機能への攻撃、及び、監視ＥＣＵ２１００による不正制御抑止処理に係るシーケンスの一例を示す。ここでは、監視ＥＣＵ２１００は、図１６に例示した機能制限ルールを保持しているものとする。また、駐車支援機能の実行開始の操作がなされておらず車両は前進走行を行っていることとする。

ＥＣＵ２００ａは、車速を示す状態フレーム（つまりＩＤ「０ｘ１００」を有するデータフレーム）をバス３００に送信する（ステップＳ２１１）。この例では、現在の車速は、４２．１ｋｍ／ｈである。ステップＳ２１１で送信された車速に係る状態フレームを受信したＥＣＵ２００ｃは、保持する現在の車速を、４２．１ｋｍ／ｈに更新する。また、その状態フレームを受信した監視ＥＣＵ２１００は、受信履歴保持部２１６０に保持される受信履歴情報における車速に係る受信履歴を更新する。

ＥＣＵ２００ｃがハンドル２４０の制御を行うためには、車速が１０ｋｍ／ｈ以下という条件を満たす必要がある。このため、攻撃ＥＣＵは、ハンドル２４０を不正に制御する前段階として、ＩＤ「０ｘ１００」を有し車速が０ｋｍ／ｈであるという偽の情報を示すデータフレーム、つまり車速に係る偽の情報を示す状態フレームを送信する（ステップＳ２１２）。ステップＳ２１２で送信された車速に係る偽の情報を示す状態フレームを受信したＥＣＵ２００ｃは、保持する現在の車速を、０ｋｍ／ｈに更新する。また、その状態フレームを受信した監視ＥＣＵ２１００は、受信履歴情報における車速に係る受信履歴を更新する。

ＥＣＵ２００ｄは、ギアポジションを示す状態フレーム（つまりＩＤ「０ｘ３００」を有するデータフレーム）をバス３００に送信する（ステップＳ２１３）。この例では、現在のギアポジションは、「ドライブ」である。ステップＳ２１３で送信されたギアポジションに係る状態フレームを受信したＥＣＵ２００ｃは、保持する現在のギアポジションを、「ドライブ」に更新する。また、その状態フレームを受信した監視ＥＣＵ２１００は、受信履歴情報におけるギアポジションに係る受信履歴を更新する。

ＥＣＵ２００ｃがハンドル２４０の制御を行うためには、ギアポジションが「リバース」であるという条件を満たす必要がある。このため、攻撃ＥＣＵは、ハンドル２４０を不正に制御する前段階として、ＩＤ「０ｘ３００」を有しギアポジションが「リバース」であるという偽の情報を示すデータフレーム、つまりギアポジションに係る偽の情報を示す状態フレームを送信する（ステップＳ２１４）。ステップＳ２１４で送信されたギアポジションに係る偽の情報を示す状態フレームを受信したＥＣＵ２００ｃは、保持する現在のギアポジションを、「リバース」に更新する。また、その状態フレームを受信した監視ＥＣＵ２１００は、受信履歴情報におけるギアポジションに係る受信履歴を更新する。

次に攻撃ＥＣＵは、ハンドル２４０を不正に制御するために、ＩＤ「０ｘ２００」を有し制御フラグを１にしたデータフレーム（つまりハンドル制御指示に係る制御フレーム）を送信する（ステップＳ２１５）。これに対して、監視ＥＣＵ２１００は、その制御フレームの受信中に、機能制限ルールに基づいて、車両の制御を抑止すべきか否かを判定する。

監視ＥＣＵ２１００は、ステップＳ２１５で送信された制御フレームが機能制限ルールのルール番号１の項目のルールの機能制限対象に合致して、対応する車両状態継続時間の条件が満たされているので、その制御フレームによる車両の制御を抑止すべきと判定する。なお、監視ＥＣＵ２１００は、その制御フレームが機能制限ルールのルール番号２の項目のルールの機能制限対象に合致して、対応する車両状態継続時間の条件が満たされていることからも、その制御フレームによる車両の制御を抑止すべきと判定し得る。監視ＥＣＵ２１００は、受信履歴情報が示す所定期間における車両の状態が、機能制限ルールの少なくとも１つの項目のルールが示す車両状態継続の条件に該当すれば、その該当したルールの機能制限対象の制御フレームによる車両の制御を抑止すべきと判定し得る。

監視ＥＣＵ２１００は、ステップＳ２１５で送信された制御フレームの受信中において、その制御フレームによる車両の制御を抑止すべきと判定したので、そのハンドル制御指示に係る制御フレームを無効化するために、エラーフレームを送信する（ステップＳ２１６）。エラーフレームの送信により、監視ＥＣＵ２１００は、攻撃によるハンドル２４０の不正な制御を抑止し得る。このエラーフレームにより、送信中であったＩＤ「０ｘ２００」を有するデータフレームが上書きされ、結果的に、攻撃ＥＣＵによるそのデータフレームの送信が中断されたことになる。ＥＣＵ２００ｃは、そのエラーフレームを受信することにより、受信中のデータフレームを破棄して、そのデータフレームに基づくハンドル２４０の制御を行わない。

このように、監視ＥＣＵ２１００は、機能制限ルールに基づく判定結果に応じてエラーフレームの送信を行うことで、攻撃ＥＣＵによるハンドル２４０を不正に制御するためのデータフレームのＥＣＵ２００ｃによる受信を、阻止することができる。

ＥＣＵ２００ａは、４２．１ｋｍ／ｈという車速を示す状態フレームをバス３００に送信する（ステップＳ２１７）。ステップＳ２１７で送信された車速に係る状態フレームを受信したＥＣＵ２００ｃは、保持する現在の車速を、４２．１ｋｍ／ｈに更新する。また、その状態フレームを受信した監視ＥＣＵ２１００は、受信履歴保持部２１６０に保持される受信履歴情報における車速に係る受信履歴を更新する。

［２．６ 監視ＥＣＵ２１００による監視動作］
図１９は、監視ＥＣＵ２１００による監視動作の一例を示すフローチャートである。この監視動作に係る処理は、バス３００にデータフレームが現れる度に行われる。

監視ＥＣＵ２１００は、データフレームを受信し、受信中のデータフレームのＩＤが、受信履歴保持部２１６０に受信履歴を保持すべきデータフレームのＩＤであるか否かを判断する（ステップＳ２２１）。例えば、受信履歴の保持対象に係るＩＤは、車速に係る状態フレームのＩＤ「０ｘ１００」及びギアポジションに係る状態フレームのＩＤ「０ｘ３００」である（図１５参照）。

監視ＥＣＵ２１００は、受信中のデータフレームのＩＤが、受信履歴保持部２１６０に受信履歴を保持すべきデータフレームのＩＤである場合は、受信中のデータフレームの車速等を示すデータ値と、受信の時刻とを含ませるように、受信履歴保持部２１６０が保持する受信履歴情報における、そのＩＤに係る受信履歴を更新する（ステップＳ２２２）。なお、監視ＥＣＵ２１００は、この受信履歴情報の更新に際して、例えば、受信の時刻が現在時刻より一定時間（例えば１００ｍｓ）より前の受信履歴の情報を消去しても良い。

監視ＥＣＵ２１００は、ステップＳ２２１で、受信中のデータフレームのＩＤが、受信履歴保持部２１６０に受信履歴を保持すべきデータフレームのＩＤでないと判断した後、或いは、ステップＳ２２２での処理の後に、受信中のデータフレームが、機能制限ルール保持部２１８０に保持されている機能制限ルールにおいて機能制限対象となる制御フレームであるか否かを判断する（ステップＳ２２３）。監視ＥＣＵ２１００は、ステップＳ２２３で、受信中のデータフレームが、機能制限対象となる制御フレームでないと判断した場合には、処理を終了する。

ステップＳ２２３で、受信中のデータフレームが機能制限対象の制御フレームであると判断した場合には、監視ＥＣＵ２１００は、その制御フレームに係る車両の制御を抑止すべきか否かを、機能制限ルールに基づいて直近の期間における車両の状態が不安定状態であるか否かを検証することで、判定する（ステップＳ２２４）。具体的には、監視ＥＣＵ２１００は、機能制限ルールの各項目のルールにおいて、受信中の制御フレームに合致する機能制限対象に対応する車両状態継続時間の条件を満たしているかを、受信履歴保持部２１６０に保持される、対応する車両の状態に係る状態フレームの受信履歴と、現在時刻とを参照することで検証することで、その判定を行う。監視ＥＣＵ２１００は、機能制限ルールにおける車両状態継続時間の条件が満たされるか否かに係る検証の結果、機能制限ルールにおける各項目のルールについて、いずれも車両状態継続期間の条件が成立していなければ、処理を終了する。

ステップＳ２２４での検証の結果、機能制限ルールにおける車両状態継続時間の条件が満たされていれば、受信中の制御フレームによる車両の制御を抑止すべく、その制御フレームを無効化するために、受信中の制御フレームであるデータフレームの最後尾が受信される前にエラーフレームをバス３００に送信する（ステップＳ２２５）。これにより、その受信中のデータフレームにエラーフレームが上書きされて、そのデータフレームは無効化される。このため、バス３００に接続されたＥＣＵ（例えばＥＣＵ２００ｃ）は、その無効化されたデータフレームに基づく車両の制御を行わない。

［２．７ 実施の形態２の効果］
実施の形態２に係る車載ネットワークシステム１１では、監視ＥＣＵ２１００が、一定期間に受信した状態フレームの集合に基づいて、車両の状態を示す特定の状態フレームのデータ値がある一定値或いは一定範囲内であるか否か、つまり安定状態であるか否かを検証する。特定の状態フレームは、機能制限対象とされる車両の制御を行う制御フレームに対応して定められている。この検証は、例えば、図１６に示す機能制限ルールに基づいて、特定の状態フレームのデータ値が一定値或いは一定範囲内であることの継続時間がその一定期間続くか否かにより行われる。そして、監視ＥＣＵ２１００は、車両の制御を行うための制御フレームが送信されているときに、特定の状態フレームが示す車両の状態が一定期間において安定状態でない場合（つまり状態が一定期間において継続していない場合）に、その制御フレームを無効化することで、その車両の制御を抑止する。この一定期間の長さを、予め規定されているその状態フレームの送信間隔より長い時間に定めておくことが有用となる。これにより、攻撃者が、車両の状態を偽装した上で、不正な制御を引き起こす制御フレームを送信したとしても、その車両の状態の継続時間の短さによって、監視ＥＣＵ２１００にその制御フレームが無効化される。更に、正常に機能を利用する場合を考慮して、機能制限対象のデータフレームを無効化する条件としての車両状態継続時間を設定しておくことが有用である。これにより、正常に機能を利用する場合において、機能制限対象のデータフレームが無効化されず、攻撃者による不正な制御を引き起こすデータフレームのみが無効化され得る。

この監視ＥＣＵ２１００により、車両の状態を偽装して車両を不正に制御するような攻撃に対する防御が可能となり、車載ネットワークのセキュリティが確保され得る。また、この防御のための不正制御抑止方法は、監視ＥＣＵ２１００を、車載ネットワークに配置することで実現できるので、コストを抑えて車載ネットワークを保護することが可能となる。

（実施の形態３）
以下、実施の形態１で示した車載ネットワークシステム１０の一部を変形した車載ネットワークシステム１２について説明する。

本実施の形態に係る車載ネットワークシステム１２における監視ＥＣＵは、車載ネットワークを流れる状態フレームを監視し、車両の状態の変化を計測し、車両の状態が、一定期間において所定回数を超えて変化する変化多発状態であるか否かに係る基準に基づいて、車両を制御する制御フレームによる制御機能を制限する。変化多発状態であるか否かは、データフレームが示すデータ値の所定量以上の変化の回数を観測することの他、所定量以上の変化が生じていることが継続する時間を観測すること等によっても判別可能である。具体例として、監視ＥＣＵは、クルーズコントロールモードか否か等といった制御指示の状態を示す状態フレームであるデータフレームに関して、制御指示が整合しない不整合状態の継続により変化多発状態が生じる場合において、そのデータフレームの制御指示が特定の指示であるときのその指示による制御を抑止する。この特定の指示を示すデータフレームは、制御指示の状態を示す状態フレームでありかつ車両の制御を指示する制御フレームでもある。監視ＥＣＵは、不整合状態が継続する時間に基づいて制御フレームを無効化し得る。

［３．１ 車載ネットワークシステム１２の全体構成］
図２０は、本発明に関わる車載ネットワークシステム１２の全体構成を示す図である。

車載ネットワークシステム１２は、図２０に示すように、バス３００と、バス３００に接続された監視ＥＣＵ３１００、ＥＣＵ２００ａ、３２００ｅ、３２００ｆ等とを含んで構成される。車載ネットワークシステム１２を搭載する車両においては、複数のＥＣＵが通信して連携することで、クルーズコントロール機能が実現される。車載ネットワークシステム１２は、ここで特に説明しない点については実施の形態１で示した車載ネットワークシステム１０（図１参照）と同じである。車載ネットワークシステム１２の構成要素のうち、車載ネットワークシステム１０と同様の構成要素については、図２０において、図１と同じ符号を付しており、ここでの説明を省略する。

監視ＥＣＵ３１００は、不正制御抑止装置としての一種のＥＣＵであり、バス３００に接続される。監視ＥＣＵ３１００は、バス３００に流れる状態フレーム、制御フレーム等のデータフレームを監視し、データフレームに含まれる制御指示等の情報に不整合が生じていないかを監視し、不整合が生じている場合には、不整合の継続時間を計測する。ここではクルーズコントロールモードか否か等の制御指示の状態を一種の車両の状態に係る情報であるとして、制御指示を含むデータフレームを、状態フレームとも表現する。また、その制御指示が車両の制御のための特定の指示である場合のそのデータフレームは、制御フレームである。監視ＥＣＵ３１００は、計測した不整合の継続時間に応じて、車両を制御する制御フレームによる制御を抑止すべきか否かを判定し、抑止すべき場合に制御フレームを無効化することで不正な車両制御を抑止する。

ＥＣＵ３２００ｅと、ＥＣＵ３２００ｆとはそれぞれ、スイッチ３２６０、モータ３２７０に接続されている。ＥＣＵ３２００ｅは、クルーズコントロールに関する情報を含むデータフレームを８０ｍｓの送信間隔でバス３００へ送信する。クルーズコントロールに関する情報は、現在クルーズコントロールモードに入っているか否かを示すフラグと、加減速の情報とを含む。ＥＣＵ３２００ｅは、運転者がスイッチ３２６０を押した場合に、クルーズコントロールモードに入る。ＥＣＵ３２００ｅは、車速をＥＣＵ２００ａからのデータフレームにより取得しており、クルーズコントロールモードに入った時点の車速を保つように、加速度の大きさを計算し、データフレームに含めて送信する。運転者が再度スイッチ３２６０を押すか、ブレーキを踏むか等によりクルーズコントロールモードは解除される。ＥＣＵ３２００ｆは、モータ３２７０の制御を行い、車両の走る機能を実現する。また、ＥＣＵ３２００ｆは、ＥＣＵ３２００ｅから送信されるデータフレームを受信し、クルーズコントロールモードのフラグが立っている場合は、加速度の情報に基づいて、モータ３２７０を制御することで、車両の速度が一定に保たれるように制御する。

［３．２ ＥＣＵ３２００ｅが送信するデータフレームの例］
図２１は、ＥＣＵ３２００ｅにより送信されるデータフレームの例を示す。

このデータフレームは、ＩＤ「０ｘ４００」を有し、ＤＬＣが３であり、そのデータフィールドは、１バイト目が、車両の状態がクルーズコントロールモードであるか否かを示すフラグであり、０の場合にはクルーズコントロールモードがＯＦＦ（つまり非制御状態）であることを示し、１の場合にはクルーズコントロールモードがＯＮ（つまり制御状態）になっていることを示す。２バイト目は、クルーズコントロールモードがＯＮのときに、加速を行うか、減速を行うかを示すフラグであり、０で加速を、１で減速を示す。３バイト目は、加減速の大きさを示した量であり、０．０１ｍ／ｓ２単位で表される。図２１のデータフレームの例では、クルーズコントロールモードであり、加速度０．８０ｍ／ｓ２の加速を要求するデータフレームを示している。つまり、このデータフレームは、車両がクルーズコントロールモードであるという状態フレームであり、かつ、加速を要求して車両を制御するための制御フレームである。

［３．３ 監視ＥＣＵ３１００の構成］
図２２は、監視ＥＣＵ３１００の構成図である。監視ＥＣＵ３１００はフレーム送受信部１１０と、フレーム処理部１２０と、フレーム生成部１５０と、制御情報監視部３１３０と、機能制限部３１４０と、受信履歴保持部３１６０と、機能制限ルール保持部３１８０と、不整合継続時間計測部３１９０とを含んで構成される。図２２に示した監視ＥＣＵ３１００の各構成要素は、監視ＥＣＵ３１００のメモリ等の記憶媒体、通信回路、メモリに格納されたプログラムを実行するプロセッサ等で実現され得る。監視ＥＣＵ３１００は、ここで特に説明しない点については実施の形態１で示した監視ＥＣＵ１００（図４参照）と同じである。監視ＥＣＵ３１００の構成要素のうち、監視ＥＣＵ１００と同様の機能を有する構成要素は、図２２において図４と同じ符号を付しており、ここでの説明を適宜省略する。

フレーム処理部１２０は、受信中のデータフレームを制御情報監視部３１３０と機能制限部３１４０とに通知する。

制御情報監視部３１３０は、制御指示を含むデータフレームを監視し、フレーム処理部１２０から通知されたデータフレームについて、受信履歴保持部２１６０が保持している受信履歴情報における、対応するＩＤに関する受信履歴を更新する。具体的には、制御情報監視部３１３０は、ＥＣＵ３２００ｅから送信されるクルーズコントロールモードがＯＮか否かを示す制御指示のフラグ等を含む状態フレームのデータの値（例えば制御指示のフラグ値）と、その状態フレームが受信された時刻とに基づいて、受信履歴情報を更新する。更に、制御情報監視部３１３０は、受信履歴情報を参照して、一定期間に受信される同じＩＤを有するデータフレームにおける制御指示に係る状態（例えばクルーズコントロールモード）に不整合が生じていないかを判断する。制御情報監視部３１３０は、制御指示に係る状態に不整合が生じている場合に、不整合継続時間計測部３１９０に、不整合継続時間の計測開始要求を行う。

このような制御指示に係る状態の不整合は、例えば、運転者がスイッチ３２６０を押してクルーズコントロールモードをＯＮにした時等といった、制御を行う機能がＯＦＦ状態からＯＮ状態に変化した時、或いは、ＯＮ状態からＯＦＦ状態に変化した時に発生し得る。しかし、正常に機能を利用している限りでは、このような不整合が長時間継続し続けることはない。制御情報監視部３１３０は、一定期間のデータフレームの監視により、不整合が生じている場合は、その継続時間である不整合継続時間を計測するように、不整合継続時間計測部３１９０に要求し、不整合が生じていない場合は、不整合継続時間計測部３１９０に対して、不整合継続時間を０にリセットして計測を停止するよう要求する。

機能制限部３１４０は、データフレームを受信した際に、機能制限ルール保持部３１８０に保持される機能制限ルールを参照し、受信中のデータフレームが機能制限対象の制御フレームである場合にその制御フレームによる車両の制御を抑止すべきか否かを判定する。その制御フレームによる制御を抑止すべきか否かの判定は、その制御フレームに関連して、不整合継続時間計測部３１９０により計測された不整合継続時間を参照することで行なわれる。機能制限部３１４０は、車両の制御を抑止すべきと判定した場合には、その車両の制御のための、受信中の制御フレームを無効化するために、エラーフレームの送信をフレーム生成部１５０に要求する。具体的には、車両の制御を抑止すべきか否かの判定のために、機能制限部２１４０は、機能制限ルールにおいて機能制限対象とされている制御フレームが受信中である場合に、不整合継続時間が機能制限ルールの条件を満たすという一種の変化多発状態であるか否かを判定する。

受信履歴保持部３１６０は、監視ＥＣＵ３１００が受信したデータフレームの受信履歴を保持する。受信履歴保持部３１６０は、例えば、直近の１００ｍｓ以内に受信した、クルーズコントロールモードの制御指示のフラグを含むデータフレーム等といった状態フレームに関するデータ値及び受信の時刻を示す受信履歴情報（図２３参照）を保持する。

機能制限ルール保持部３１８０は、受信中の制御フレームによる制御を抑止すべきか否かの判定基準となる機能制限ルール（図２４参照）を保持する。この機能制限ルールは、受信中のデータフレームを無効化すべきか否かの判定基準であるとも言える。

不整合継続時間計測部３１９０は、制御指示毎について、制御指示の不整合の継続している時間を計測して計測結果等の計測関連情報（図２５参照）を保持する。また、不整合継続時間計測部３１９０は、制御情報監視部３１３０からの計測開始要求を受けて、計測関連情報としての計測中フラグの値を更新する。不整合継続時間計測部３１９０は、この計測中フラグに従って、不整合継続時間の計測を開始、或いは、リセット（つまり停止）することができるタイマを制御指示毎に保持する。

［３．４ 受信履歴情報］
図２３は、受信履歴保持部３１６０が保持する受信履歴情報の一例を示す。同図の例では、直近１００ｍｓ以内に受信されたＩＤ「０ｘ４００」のデータフレームのデータ値としての制御指示のフラグの値と、その受信の時刻とを含む。

この受信履歴情報によれば、直近１００ｍｓの間に４回、ＩＤ「０ｘ４００」を有するデータフレームを受信しており、最新の受信時におけるフラグの値は１（つまりクルーズコントロールモードがＯＮ状態で、制御を行う意味）であり、受信の時刻は３０１ｍｓである。１回前の受信時においては、フラグの値は０（つまりクルーズコントロールモードがＯＦＦ状態で、制御を行わない意味）であり、受信の時刻は３００ｍｓである。２回前の受信時においては、フラグの値は１であり、受信の時刻は２２１ｍｓである。３回前の受信時においては、フラグの値は０であり、受信の時刻は２２０ｍｓである。

［３．５ 機能制限ルール］
図２４に、機能制限ルール保持部３１８０が保持する機能制限ルールの一例を示す。

機能制限ルールは、車両の制御を抑止すべきか否かの基準を示す情報であり、同図の例では、車両の制御を行う制御フレームを特定する情報である機能制限対象及び制限機能と、基準となる車両状態の条件（具体的には不整合継続時間の条件）とを対応付けたものである。同図には、機能制限ルールが１つの項目のルールで構成される例を示しているが、ルールの項目数は複数であっても良い。制限機能は、不整合継続時間の条件が満たされた場合に制限する特定の制御指示を示す。制限機能が、「制限」であれば、不整合継続時間の条件が満たされた場合に、受信中の機能制限対象のデータフレームが、クルーズコントロールモードがＯＮ状態であることを１で示すフラグを有する制御フレームである場合に、その制御フレームによる制御を抑止すべきこと、つまり、その制御フレームを無効化すべきことを意味する。また、例えば制限機能が「継続」であれば、不整合が生じる前の制御指示による状態を維持するように、制御フレームを無効化すべきことを意味する。例えば、不整合が生じる前に、クルーズコントロールモードを示すフラグが０であった場合は、不整合継続時間の条件が満たされた場合に、クルーズコントロールモードを示すフラグが１のデータフレームである制御フレームを無効化する。不整合継続時間の条件は、機能制限のための条件としての不整合継続時間の長さを示す条件であり、この条件が満たされる場合に、機能制限対象のデータフレームに対する機能制限を行う。図２４の例では、機能制限対象は、クルーズコントロールに係るＩＤ「０ｘ４００」を有するデータフレームであり、制限機能は「制御」であり、クルーズコントロールモードのＯＮ状態を示す制御指示を含むデータフレームが、無効化されるべき制御フレームになる。また、図２４の例では、不整合継続時間の条件は、不整合継続時間が５００ｍｓ以上であることである。図２４の例の機能制限ルールは、クルーズコントロールモードの制御指示の状態についての不整合継続時間が５００ｍｓ以上の長さとなる変化多発状態において、クルーズコントロールの特定の制御指示による制御を抑止すべきという基準を示しているとも言える。この変化多発状態においては、監視ＥＣＵ３１００は、クルーズコントロールに係る特定の制御指示を示すデータフレームである制御フレームを、エラーフレームの送信により無効化する。

［３．６ 不整合継続時間］
図２５は、不整合継続時間計測部３１９０が計測して保持する不整合継続時間等を含む計測関連情報の一例を示す。この例の計測関連情報は、データフレームのＩＤ毎に、制御指示についての不整合が継続した時間である不整合継続時間と、不整合継続時間を計測中であるか否かを示した計測中フラグと、不整合の発生前に制御を行っていたか否かを示す不整合発生前状態とを含んでいる。この例では、クルーズコントロールに係るＩＤ「０ｘ４００」のデータフレームについて、計測された不整合継続時間は１００ｍｓであり、計測中フラグは１で継続時間の計測中を意味し、不整合発生前状態は「非制御」（つまりクルーズコントロールモードを示す制御指示のフラグが０）であることを示している。

［３．７ クルーズコントロール機能に対する攻撃の抑止に係るシーケンス］
図２６は、クルーズコントロール機能への攻撃、及び、監視ＥＣＵ３１００による不正制御抑止処理に係るシーケンスの一例を示す。ここでは、監視ＥＣＵ３１００は、図２４に例示した機能制限ルールを保持しているものとする。また、クルーズコントロール機能をＯＮにするためのスイッチ３２６０の操作がなされていない状態であるとする。また、図２６では、ＥＣＵ２００ａが送信している車速に係るデータフレームについての記載を省略している。

ＥＣＵ３２００ｅは、クルーズコントロールに係るＩＤ「０ｘ４００」を有するデータフレームについてクルーズコントロールモードがＯＦＦ状態であることを示すように制御指示のフラグを０にしてバス３００に送信する（ステップＳ３１１）。このデータフレームをＥＣＵ３２００ｆと、監視ＥＣＵ３１００とが受信する。ＥＣＵ３２００ｆはクルーズコントロールモードに係るフラグが０のため、車速を一定にするための加速或いは減速等といったモータ３２７０の制御を行わない。監視ＥＣＵ３１００は、受信履歴保持部３１６０に保持される受信履歴情報を、受信したデータフレームに基づいて更新する。

攻撃ＥＣＵは、クルーズコントロールに係るＩＤ「０ｘ４００」を有するデータフレームについて、クルーズコントロールモードがＯＮ状態であることを示すように制御指示のフラグを１にして送信する（ステップＳ３１２）。このデータフレームをＥＣＵ３２００ｆと、監視ＥＣＵ３１００とが受信する。ＥＣＵ３２００ｆはクルーズコントロールモードに係るフラグが１のため、そのデータフレームの加速或いは減速を示す加速度の値に従って、モータ３２７０を制御する。監視ＥＣＵ３１００は、受信履歴保持部３１６０に保持される受信履歴情報を、受信したデータフレームに基づいて更新する。このとき、監視ＥＣＵ３１００は、直近１００ｍｓ以内に受信したデータフレームから、クルーズコントロールに関して、「制御」（つまりクルーズコントロールモードがＯＮ状態である制御指示）と、「非制御」（つまりクルーズコントロールモードがＯＦＦ状態である制御指示）との両方のデータフレームを受信していることから、不整合と判断して、不整合継続時間の計測を開始する。

その後、ステップＳ３１１と同様のＩＤ「０ｘ４００」を有しクルーズコントロールについて「非制御」を示すデータフレームの送信と、ステップＳ３１２と同様のＩＤ「０ｘ４００」を有しクルーズコントロールについて「制御」を示すデータフレームの送信とが５００ｍｓ間、繰り返される（ステップＳ３１３）。

続いてＥＣＵ３２００ｅは、クルーズコントロールに係るＩＤ「０ｘ４００」を有し「非制御」を示すデータフレームを送信する（ステップＳ３１４）。このデータフレームを、ＥＣＵ３２００ｆと、監視ＥＣＵ３１００とが受信する。

続いて攻撃ＥＣＵは、ＩＤ「０ｘ４００」を有し「制御」（つまりクルーズコントロールモードがＯＮ状態である制御指示）を示すデータフレームを送信する（ステップＳ３１５）。

ステップＳ３１５での送信に対応して、監視ＥＣＵ３１００は、受信中のデータフレームが、機能制限ルールの機能制限対象及び制限機能で特定される制御フレームである場合に、機能制限ルールの車両状態の条件（つまり不整合継続時間の条件）が満たされるか否かにより、その制御フレームによる制御を抑止すべきか否かを判定する。この時点では、不整合継続時間が５００ｍｓ以上続いた状態で、クルーズコントロールモードを示す制御指示（つまりフラグが１）を含むデータフレームである制御フレームを受信中であるので、監視ＥＣＵ３１００は、その制御フレームによる制御を抑止すべきと判定する。そして、その制御フレームの無効化のためにエラーフレームを送信する（ステップＳ３１６）。エラーフレームの送信により、監視ＥＣＵ３１００は、攻撃によるクルーズコントロールに係る不正な制御を抑止し得る。このエラーフレームにより、送信中であったＩＤ「０ｘ４００」を有しクルーズコントロールモードがＯＮ状態であることを示す制御指示を含む制御フレームが上書きされ、結果的に、攻撃ＥＣＵによるそのデータフレームの送信が中断されたことになる。ＥＣＵ３２００ｆは、そのエラーフレームを受信することにより、受信中のデータフレームを破棄して、そのデータフレームに基づくクルーズコントロールのための加速或いは減速等の制御を行わない。

このように、監視ＥＣＵ３１００は、機能制限ルールに基づく判定結果に応じてエラーフレームの送信を行うことで、攻撃ＥＣＵによるクルーズコントロールに係る不正な制御を行うためのデータフレームのＥＣＵ３２００ｆによる受信を、阻止することができる。

［３．８ 監視ＥＣＵ３１００による監視動作］
図２７は、監視ＥＣＵ３１００による監視動作の一例を示すフローチャートである。この監視動作に係る処理は、バス３００にデータフレームが現れる度に行われる。

監視ＥＣＵ３１００は、データフレームを受信し、受信中のデータフレームのＩＤが、受信履歴保持部３１６０に受信履歴を保持すべきデータフレームのＩＤであるか否かを判断する（ステップＳ３２１）。例えば、受信履歴の保持対象に係るＩＤは、クルーズコントロールモードの状態に係る状態フレームであるデータフレームのＩＤ「０ｘ４００」である（図２３参照）。

監視ＥＣＵ３１００は、受信中のデータフレームのＩＤが、受信履歴保持部３１６０に受信履歴を保持すべきデータフレームのＩＤである場合は、受信中のデータフレームにおける状態（例えばクルーズコントロールモードに係る制御指示のフラグ）を示すデータ値と、受信の時刻とを含ませるように、受信履歴保持部３１６０が保持する受信履歴情報における、そのＩＤに係る受信履歴を更新する（ステップＳ３２２）。なお、監視ＥＣＵ３１００は、この受信履歴情報の更新に際して、例えば、受信の時刻が現在時刻より一定時間（例えば１００ｍｓ）より前の受信履歴の情報を消去しても良い。

続いて監視ＥＣＵ３１００は、受信履歴情報に基づいて、制御指示等を示すデータ値に不整合が生じているか否かを判断する（ステップＳ３２３）。

次に監視ＥＣＵ３１００は、ステップＳ３２３で判断した、不整合の有無に基づき、不整合継続時間計測部３１９０に不整合継続時間の計測を開始させ、或いは、停止させる（ステップＳ３２４）。

監視ＥＣＵ３１００は、ステップＳ３２１で受信中のデータフレームのＩＤが、受信履歴保持部３１６０に受信履歴を保持すべきデータフレームのＩＤでないと判断した後、或いは、ステップＳ３２４での処理の後に、受信中のデータフレームが、機能制限ルール保持部３１８０に保持されている機能制限ルールにおいて機能制限対象及び制限機能により特定される制御フレームであるか否かを判断する（ステップＳ３２５）。監視ＥＣＵ３１００は、ステップＳ３２５で、受信中のデータフレームが、機能制限対象となる制御フレームでないと判断した場合には、処理を終了する。

次に監視ＥＣＵ３１００は、受信中の制御フレームによる制御が抑止されるべきであるか否かを、不整合継続時間計測部３１９０により計測された不整合継続時間が、機能制限ルールにおける不整合継続時間の条件を満たすか否かに基づいて判定する（ステップＳ３２６）。不整合継続時間に係る車両の状態の条件が成立すれば、その制御フレームによる制御は抑止されるべきであると判定される。監視ＥＣＵ３１００は、その制御フレームによる制御が抑止されるべきでないと判定した場合、つまり、不整合継続時間の条件が満たされていない場合には、処理を終了する。

ステップＳ３２６でその受信中の制御フレームによる制御は抑止されるべきであると判定した場合には、監視ＥＣＵ３１００は、その制御フレームを無効化するために、受信中の制御フレームであるデータフレームの最後尾が受信される前にエラーフレームをバス３００に送信する（ステップＳ３２１）。これにより、その受信中のデータフレームにエラーフレームが上書きされて、そのデータフレームは無効化される。このため、バス３００に接続されたＥＣＵ（例えばＥＣＵ３２００ｆ）は、その無効化されたデータフレームに基づく車両の制御を行わない。

［３．９ 実施の形態３の効果］
実施の形態３に係る車載ネットワークシステム１２では、監視ＥＣＵ３１００が、一定期間に受信した制御指示に関連する状態フレームの集合に基づいて、制御指示の状態の変化が多発する変化多発状態であるか否かを検証する。この検証は、例えば、図２４に示す機能制限ルールに基づいて、状態の変化による不整合が継続する時間である不整合継続時間が一定期間続くか否かにより行われる。そして、監視ＥＣＵ３１００は、不整合継続時間に応じて、機能制限ルールの機能制限対象及び機能制限により特定される制御フレームを無効化するか否かを判定する。これにより、攻撃者が、不正な制御を引き起こすデータフレームを送信し続けたとしても、不正な制御を引き起こし続けることができなくなる。これは、不正な制御を継続されることにより被害が大きくなるような、制御に関連するデータフレームを監視対象とすることで有効な対策となる。また、監視ＥＣＵ３１００によれば、例えばクルーズコントロール機能等の特定の機能の正常な利用において、その制御指示の状態の変化が時折発生する場合（つまり不整合継続時間が一定時間以下の場合）には、その制御が抑止されず、その変化が一定期間に多発するような攻撃の場合にその制御が抑止される。このため、正常なデータフレームが誤って無効化されない。

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

（１）上記実施の形態では、状態偽装検知部と、機能制限部と、車両状態監視部と、制御情報監視部とは、複数のＥＣＵがフレームの授受を行うためのバス３００に接続された監視ＥＣＵの構成要素として説明したが、その他の１つ又は複数のＥＣＵの構成要素としても良い。上述した監視ＥＣＵは、車載ネットワークシステムにおいてバスに接続されたＥＣＵであれば、監視専用のＥＣＵである必要はなく、監視及び対処とは異なる機能を併せ持っても構わない。また、例えば監視ＥＣＵにおける１つ以上の構成要素を他のＥＣＵに移動させても良い。偽装状態の検知、機能制限ルールに基づく制御が抑止されるべき制御フレームの検知、制御の抑止のための制御フレームの無効化等を、どのＥＣＵが行っても良い。例えば、制御フレームを受信しその制御フレームの内容に応じて制御を行うＥＣＵ等が、上述した監視ＥＣＵと同様の構成要素を有することとしても良い。また、例えば、車載ネットワークを複数のバスで構成した場合におけるバス間でのデータフレームの転送を行うゲートウェイＥＣＵに、上述した監視ＥＣＵの構成要素を含ませても良い。これは、ゲートウェイＥＣＵが、各バスの状態を監視できるので、有用である。この監視ＥＣＵの構成を含むゲートウェイＥＣＵでは、不正な制御フレームによる制御の抑止のために、エラーフレームによる制御フレームの無効化の他に、制御を抑止すべきと判定された制御フレームのバス間での転送を抑止する等の処理を行うことができる。また、ゲートウェイＥＣＵでは、多数の車載ネットワークの情報を監視できることから、不正な制御フレームによる制御の抑止のために実現できる機能の幅も広がる。

（２）上記実施の形態で示した制御フレームは、車両の制御に利用される情報を含むデータフレームであれば、いかなるフレームであっても良い。また、制御フレームには、車両の制御を抑止するという一種の制御のための、車両の制御の抑止指示を行うデータフレームも含まれると看做すこととしても良い。

（３）また、上記実施の形態では、機能制限対象となった制御フレームによる制御を抑止する例として、監視ＥＣＵがエラーフレームにより、受信中の制御フレームをバス上で上書きして無効化する例を示した。しかし、制御フレームによる制御の抑止の実現方法は、制御フレームの受信中にエラーフレームを送信する方法に限られない。例えば、制御フレームを受信しその制御フレームの内容に応じて制御を行うＥＣＵが、機能制限対象として制御が抑止されるべきと判定された制御フレームを破棄して、その制御フレームに対応した制御を行わないことで、制御フレームによる制御の抑止を実現しても良い。これは、車載ネットワークの構成に監視専用の監視ＥＣＵを含ませない場合等に有用となる。また、上述したようにゲートウェイＥＣＵで、制御を抑止すべきと判定した制御フレームの転送を抑止することで、制御フレームによる制御の抑止を実現しても良い。また、制御フレームによる制御の抑止の実現方法の例として、他のＥＣＵにその制御に係る機能を制限することを通知するデータフレームを送信する方法、ユーザにその機能を制限することを通知する方法、ＡＤＡＳの機能等といった自動制御機能の縮退を含み得る予め定めたフェールセーフモードに車両を移行させる方法等が挙げられる。

（４）上記実施の形態では、ＣＡＮプロトコルにおけるデータフレームを標準ＩＤフォーマットで記述しているが、拡張ＩＤフォーマットであっても良く、データフレームの識別子であるＩＤは、拡張ＩＤフォーマットでの拡張ＩＤ等であっても良い。

（５）上記実施の形態では、監視ＥＣＵが受信履歴保持部に直近１００ｍｓに受信したデータフレームの情報を含む受信履歴情報を保持する例を示したが、その情報の受信からの保持期間として１００ｍｓは一例に過ぎない。その保持期間として、車両の状態が偽装されていることを判定するのに必要な情報が得られる最低限の時間、或いは、制御指示に係る情報の不整合が継続していることを判断するのに必要な情報が得られる最低限の時間を設定すれば十分であり、例えば、目安としてデータフレームの送信間隔より長い任意の期間を設定することが想定される。また、監視ＥＣＵが、受信履歴情報として記録する受信履歴の対象となるデータフレームのＩＤは、１つでも複数でも良い。また、監視ＥＣＵが、保持する機能制限ルールの項目も１つでも複数でも良い。また、監視ＥＣＵが、車両状態保持部に保持する車両状態情報は、１つのＩＤに関する偽装フラグを含んでも良いし、複数のＩＤそれぞれに関する偽装フラグを含んでも良い。

（６）上記実施の形態では、監視ＥＣＵが受信履歴保持部に受信履歴情報として、データフレームのデータフィールドのデータ値、及び、受信の時刻を含む受信履歴を保持することとしたが、データ値、受信の時刻は一例に過ぎず、データ値或いは受信の時刻の保持の省略も可能である。受信履歴保持部は、その他の情報を保持しても良いし、データフィールドの一部のデータ値を保持しても良いし、受信したデータフレームの全てのフィールドの内容を保持しても良い。

（７）上記実施の形態では、機能制限ルール保持部に保持される機能制限ルールが示す基準として、車速に係る車両状態継続時間の条件と、ギアポジションに係る車両状態継続時間の条件とを示したが、その基準として各条件を組み合わせて、各条件の論理和或いは論理積等を用いても良い。また条件の数を増やしても良いし、少なくしても良い。機能制限ルールにおける機能制限対象の制御が正常に実行される場合において、確実に生じる車両状態を踏まえて車両状態の条件を定めることで、正常なデータフレームを誤って無効化することを防ぐことが可能となる。また、車速、ギアポジション等といった、車両の制御の条件となる車両の状態を適切に選定して、その車両の状態に係る条件を機能制限ルールにおいて定めておくことで、攻撃者による車両の状態の偽装用の状態フレーム送信後の制御フレームによる不正な制御を抑止することが可能となる。例えば、実施の形態１及び実施の形態２で示した駐車支援機能を有する車載ネットワークシステムの例においては、制御を示す制御フラグを含む、正常なハンドル制御指示に係る制御フレームが送信され始めるタイミングは、運転者が駐車支援機能の実行開始の操作をした後からである。ここで、運転者は、駐車支援機能の実行開始の操作に先立ってギアポジションを「リバース」に変更し、モニタ上に表示される車両後方の映像を参照しながら駐車位置を指定する。このため、機能制限ルールに係る基準となる車両状態の条件として、例えば、制御を示す制御フラグを含む、正常なハンドル制御指示に係る制御フレームが送信され始めるタイミングで車速が０ｋｍ／ｈであることを設定しても良い。また、駐車支援機能でハンドルの操舵角を計算するに当たって、ハンドルを直進状態に戻すことを運転者に要求する方式が用いられる場合には、機能制限ルールに係る基準となる車両状態の条件として、例えば制御を示す制御フラグを含む、正常なハンドル制御指示に係る制御フレームが送信され始めるタイミングでハンドルの操舵状態が概ね直進状態であることを設定しても良い。また、運転者が駐車支援機能を使用する際の操作シーケンスを踏まえ、車両状態の条件として、例えば、車速が０ｋｍ／ｈであること、ギアポジションが「リバース」であること、ハンドルの操舵状態が概ね直進状態にあること等の各々が、制御を示す制御フラグを含む、正常なハンドル制御指示に係る制御フレームが送信され始めるタイミングまでに、順に発生していることを設定しても良い。

（８）上記実施の形態では、車両の状態の偽装検知について、状態フレームについて規定された送信間隔に基づいて、予め規定された送信間隔に係るマージンの範囲内の期間に複数の状態フレームを受信した場合にその状態フレームに係る車両の状態が偽装されていると判定する例を示した。しかし、車両の状態の偽装検知の方法は、この例の方法に限らない。例えば、一定期間内のデータフレームの受信数の閾値を予め規定しておき、閾値を超えた場合に車両の状態が偽装されていると判定しても良い。また、一定期間内或いは一定受信回数内のデータフレームの値の変化量の閾値、或いは、値の変化回数の閾値を予め規定しておき、閾値を超えた場合に車両の状態が偽装されていると判定しても良い。また、異なるＩＤのデータフレームの関係性により、関係性の崩れから車両の状態の偽装を判定しても良い。また、車載ネットワークに流れるデータフレーム以外から取得できる情報、例えばＧＰＳ（Global Positioning System）情報、地図情報、イグニッションの状態に関する情報、各種センサ情報等を組み合わせて車両の状態の偽装を判定しても良い。

（９）上記実施の形態では、データフレームが平文でバスを流れる例を示したが、暗号化されていても良い。またデータフレームに、メッセージ認証コードを含んでいても良い。

（１０）上記実施の形態では、機能制限ルールを、平文で保持している例を示したが、暗号化して保持していても良い。

（１１）上記実施の形態では、車両状態継続時間の計算方法として、受信履歴情報を参照することにより、現在の時刻から、車両の状態が継続している時間を計算する例を示したが、この方法に限らない。例えば受信履歴情報として、特定のＩＤを有する状態フレームの最終の受信の時刻と、その時のデータ値のみを保持することによって、車両の状態の継続時間を計測しても良い。また、機能制限ルールにおける車両状態継続時間の条件に対応して、所定の時間が経過しているか否かが判別できれば良く、必ずしも車両の状態の継続時間を計算する必要はない。例えば、車両の状態が機能制限ルールに示される所定の条件を満たしたときにタイマをセットし、タイマが所定の時間よりも大きいか否かを判別することによって、機能制限ルールにおける条件が満たされるか否かを判別しても良い。また、車両の状態が機能制限ルールに示される所定の条件を満たしたときに、所定の時間のカウントダウンタイマをセットし、タイマが０となっているか否かを確認することで、機能制限ルールにおける条件が満たされるか否かを判別しても良い。

（１２）上記実施の形態では、監視ＥＣＵが、機能制限ルールにおける車両状態継続時間が予め規定された閾値以上の時間を経過しないと、車両の状態が安定状態でないので機能制限対象に係る制御フレームによる制御を抑止する例を示した。しかし、車両状態継続時間が予め規定された閾値以上の時間を経過していないことで、車両の状態が安定状態でない場合に必ずしも直ちに制御フレームによる制御を抑止しなくても良く、安定状態でない状態がある程度継続した場合に抑止することとしても良い。これは、不正に送信されても危険性が低い制御に係る制御フレームに関して、正常な制御フレームを誤って無効化してしまう誤検知を抑制するために有用となる。

（１３）上記実施の形態では、不整合継続時間として、制御を示す制御指示の情報を含むデータフレームと、非制御を示す制御指示の情報を含むデータフレームとの両方が一定期間に観測される時間を示したが、不整合継続時間の計測方法はこれに限らない。例えば、一定期間に受信された、制御のために用いられるデータ値を含む複数のデータフレームにおける、そのデータ値の変化量が閾値を超える場合に、不整合が発生しているとして、継続時間を計測しても良い。

（１４）上記実施の形態では、車両の状態の例として、車速、ギアポジション等の例を示したが、監視ＥＣＵが監視する車両の状態はこれに限られるものではない。車両の状態は、例えば、車輪の回転速度、ヨーレート、加速度、操舵角、アクセルペダル開度、制動レベル、エンジンの回転数、モータの回転数、ギアポジション、イグニッションスイッチの状態、ハンドルの操舵トルク、前方障害物の有無、後方障害物の有無、前方障害物までの距離、後方障害物までの距離、左右の区画線の認識状態、左右の区画線までの距離等であり得る。車両の状態は、例えば、センサにより取得された状態であり得る。

（１５）上記実施の形態では、監視ＥＣＵにおける抑止すべきか否かの判定の対象となる制御として、駐車支援機能と、クルーズコントロール機能とに係る制御の例を示したが、監視ＥＣＵにより抑止すべきか否かが判定される、制御フレームに基づく制御は、駐車支援機能に係るハンドル制御と、クルーズコントロール機能に係る加速又は減速の制御とに限られない。監視ＥＣＵにおける抑止すべきか否かの判定の対象となる制御は、例えば、衝突軽減ブレーキシステム、アダプティブクルーズコントロールシステム、レーンキープアシストシステム等に関連する制御であっても良い。また、監視ＥＣＵにおける抑止すべきか否かの判定の対象となる制御は、例えば、車両の走行に関わる制御であることとしても良い。車両の走行に関わる制御は、走ることに関する制御（例えば加速制御）、曲がることに関する制御（例えば操舵制御）、及び、止まることに関する制御（例えば制動制御）のいずれかである。また、監視ＥＣＵにおける抑止すべきか否かの判定の対象となる制御は、インストルメンタルパネル等の運転者への情報提示をする制御等といった、間接的に車両の走行に関わる制御に影響を与える制御であることとしても良い。

例えば、衝突軽減ブレーキシステムに関連する制御を、監視ＥＣＵにおける抑止すべきか否かの判定の対象とする場合には、監視ＥＣＵは、例えば、機能制限ルールにおける車両状態の条件として、前方障害物までの距離が偽装されていることとし、前方障害物までの距離を示す状態フレームの受信時刻、データ値等を監視して偽装の有無を判定しても良い。監視ＥＣＵは、例えば、前方障害物が存在しない状態、或いは、前方障害物が遠方に存在する状態から、前方障害物が突如として目前に存在する状態へ変化した場合に偽装がなされている判定しても良い。そして、監視ＥＣＵは、偽装がなされている状態で、衝突軽減ブレーキシステムに関連する制御のための制御フレームがバスに現れると、その制御フレームの無効化等を行う。

また、例えば、アダプティブクルーズコントロールシステムに関連する制御を、監視ＥＣＵにおける抑止すべきか否かの判定の対象とする場合には、監視ＥＣＵは、例えば、機能制限ルールにおける車両状態の条件として、先行車両までの距離が偽装されていることとし、先行車両までの距離を示す状態フレームの受信時刻、データ値等を監視して偽装の有無を判定しても良い。監視ＥＣＵは、例えば、先行車両が存在しない状態、若しくは、先行車両が遠方に存在する状態から、先行車両が突如として目前に存在する状態へ変化した場合、又は、先行車両が目前に存在する状態から、先行車両が突如として遠方に存在する状態、若しくは、先行車両が存在しない状態へ変化した場合に、偽装がなされていると判定しても良い。

また、例えば、レーンキープアシストシステムに関連する制御を、監視ＥＣＵにおける抑止すべきか否かの判定の対象とする場合には、監視ＥＣＵは、例えば、機能制限ルールにおける車両状態の条件として、区画線までの距離が偽装されていることとし、車両が走行する車線の左右いずれかに存在する区画線までの距離を示す状態フレームの受信時刻、データ値等を監視して偽装の有無を判定しても良い。監視ＥＣＵは、例えば、区画線が認識できていない状態、或いは、区画線までの距離が十分にある状態から、区画線までの距離が突如として短くなり、車両が区画線に迫っている状態へ変化した場合に、偽装がなされていると判定しても良い。

（１６）上記実施の形態で監視ＥＣＵ１００、２１００、３１００によって不正制御抑止装置を例示したが、不正制御抑止装置は、必ずしも上述の監視ＥＣＵの全ての構成要素を有する必要はない。不正制御抑止装置は、図２８に示すような構成であっても良い。同図に示す不正制御抑止装置４１００は、ＣＡＮプロトコルに従う車載ネットワークに係る車載ネットワークシステムにおいて、複数のＥＣＵが車両の状態に関する情報を含むフレームである状態フレーム、及び、車両に対して所定制御（例えばハンドル制御）を指示するフレームである制御フレームの授受を行うバス３００（図１参照）に接続される。不正制御抑止装置４１００は、受信部４１１０及び判定部４１２０を含んで構成される。受信部４１１０は、バス３００から状態フレーム及び制御フレームを逐次受信する。受信部４１１０は、例えば、ＣＡＮコントローラ等の通信回路、プロセッサ、メモリ等で実現される。判定部４１２０は、受信部４１１０により受信された制御フレームに基づく所定制御を抑止すべきか否かを、その制御フレームの受信時に先行する所定期間（例えば１００ｍｓ間等）内に受信部４１１０により受信された状態フレームの集合に基づいて特定される、その所定期間における車両の状態が、所定基準（例えば上述の機能制限ルール等で示される基準）を満たすか否かに基づいて、判定する。判定部４１２０は、例えば、所定期間内に受信部４１１０により受信された状態フレームの集合に基づいて、所定期間における車両の状態を特定し得る。なお、所定期間における車両の状態は、例えば、１つ種類の状態フレーム（例えば同じＩＤを有する状態フレーム）の内容から特定されても良いし、複数種類の状態フレーム（例えば互いに異なるＩＤを有する状態フレーム）の内容から特定されても良い。

判定部４１２０で判定に用いる所定基準として、例えば、所定期間における車両の状態が偽装状態である場合に満たされて偽装状態でない場合に満たされない基準を用いても良いし、所定期間における車両の状態が安定状態でない場合に満たされて安定状態である場合に満たされない基準を用いても良いし、所定期間における車両の状態が、所定回数を超えて変化する変化多発状態である場合に満たされて変化多発状態でない場合に満たされない基準を用いても良い。これらのいずれかの基準を用いる場合には、判定部４１２０は、所定基準が満たされた場合に所定制御を抑止すべきと判定する。これらの例とは逆に、所定基準として、判定部４１２０がその所定基準が満たされない場合に所定制御を抑止すべきと判定するための基準を定めても良い。なお、判定部４１２０は、例えば、所定期間内に受信された状態フレームの集合に、異常な状態フレームが含まれている場合に車両の状態を偽装状態であると特定し、異常な状態フレームが含まれていない場合に車両の状態を偽装状態でないと特定し得る。この場合に、判定部４１２０は、その状態フレームの集合に異常な状態フレームが含まれているか否かを、いかなる方法で判別しても良い。例えば、所定期間内に受信された状態フレームの集合に、所定閾値より短い受信間隔で受信された、所定制御の実行のために用いられる同一のＩＤを有する（つまり同一項目の情報を示す）複数の状態フレームが含まれている場合に、その集合に異常な状態フレームが含まれていると判別しても良い。また、例えば、所定期間内に受信された状態フレームの集合に、所定制御の実行のために用いられる同一のＩＤを有する状態フレームが所定数より多く含まれている場合に、その集合に異常な状態フレームが含まれていると判別しても良い。また、例えば、所定期間内に受信された状態フレームの集合に、所定制御の実行のために用いられる同一のＩＤを有する２つの状態フレームが含まれ、その２つの状態フレームが示す情報の値の差異が所定量より大きい場合に、その集合に異常な状態フレームが含まれていると判別しても良い。また、例えば、所定期間内に受信された状態フレームの集合に、所定制御の実行のために用いられる同一のＩＤを有する複数の状態フレームが含まれ、受信された順に並べたその複数の状態フレームが示す情報の値が所定規則に従っていない場合に、その集合に異常な状態フレームが含まれていると判別しても良い。

判定部４１２０は、例えば、プロセッサ、タイマ、メモリ等で実現される。判定部４１２０は、判定結果に応じた出力を行い得る。判定部４１２０は、制御フレームに基づく所定制御を抑止すべきと判定した場合に、ＣＡＮコントローラ等によって、その制御フレームの少なくとも一部に上書きするようにバス３００にエラーフレームを送信することとしても良い。また、不正制御抑止装置４１００は、例えば複数の通信路間でフレームの転送を担う転送機能を有することとしても良く、この場合において、判定部４１２０は、制御フレームに基づく所定制御を抑止すべきと判定した場合に、その制御フレームを転送対象から除外して転送しないこととしても良い。

また、不正制御抑止装置、或いは、監視ＥＣＵが、車両に搭載され、車載ネットワークシステムに含まれる例を示したが、車両以外の制御対象の制御のためのネットワークシステムに含まれるものであっても良い。車両以外の制御対象は、例えば、ロボット、航空機、船舶、機械等である。

（１７）上記の実施の形態では、車載ネットワークでは、ＣＡＮプロトコルに従って、状態フレーム、制御フレーム等のデータフレームの伝送が行われるものとしたが、ＣＡＮプロトコルは、オートメーションシステム内の組み込みシステム等に用いられるＣＡＮＯｐｅｎ、或いは、ＴＴＣＡＮ（Time-Triggered CAN）、ＣＡＮＦＤ（CAN with Flexible Data Rate）等の派生的なプロトコルを包含する広義の意味のものと扱われることとしても良い。また、車載ネットワークは、ＣＡＮプロトコル以外のプロトコルを用いるものであっても良い。車両の状態に関する情報を含むフレームである状態フレーム、及び、車両に対して所定制御を指示するフレームである制御フレームの伝送がなされる車載ネットワークのプロトコルとして、例えば、ＬＩＮ（Local Interconnect Network）、ＭＯＳＴ（登録商標）（Media Oriented Systems Transport）、ＦｌｅｘＲａｙ（登録商標）、Ｅｔｈｅｒｎｅｔ（登録商標）等を用いても良い。また、これらのプロトコルを用いたネットワークをサブネットワークとして、複数種類のプロトコルに係るサブネットワークを組み合わせて、車載ネットワークを構成しても良い。また、Ｅｔｈｅｒｎｅｔ（登録商標）プロトコルは、ＩＥＥＥ８０２．１に係るＥｔｈｅｒｎｅｔ（登録商標）ＡＶＢ（Audio Video Bridging）、或いは、ＩＥＥＥ８０２．１に係るＥｔｈｅｒｎｅｔ（登録商標）ＴＳＮ（Time Sensitive Networking）、Ｅｔｈｅｒｎｅｔ（登録商標）／ＩＰ（Industrial Protocol）、ＥｔｈｅｒＣＡＴ（登録商標）（Ethernet（登録商標） for Control Automation Technology）等の派生的なプロトコルを包含する広義の意味のものと扱われることとしても良い。なお、車載ネットワークの通信路は、ネットワークバス（例えばバス３００）或いはその他のワイヤ、光ファイバ等で構成される有線通信路であっても良いし、その他の通信路であっても良い。

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

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

（２０）本発明の一態様としては、例えば図１２、図１９、図２７等に示す処理手順の全部又は一部を含む不正制御抑止方法であるとしても良い。例えば、不正制御抑止方法は、車両に対して所定制御（例えばハンドル制御等）を指示する制御フレームを含む複数のフレームの授受を、通信路（例えばバス３００）を介して行う複数のＥＣＵを備える車載ネットワークシステムにおける不正制御抑止方法であって、その通信路から複数のフレームを逐次受信する受信ステップ（例えばステップＳ３１、Ｓ２２１、Ｓ３２１）と、受信ステップで受信された制御フレームに基づく所定制御を抑止すべきか否かを、その制御フレームの受信時に先行する所定期間内に受信ステップで受信されたフレームの集合に基づいて、判定する判定ステップ（例えばステップＳ３６、Ｓ２２４、Ｓ３２６）とを含む方法である。この不正制御抑止方法は、更に、判定ステップで制御フレームに基づく所定制御を抑止すべきと判定された場合に、所定制御の抑止のための所定処理を実行する処理ステップ（例えばステップＳ３７、Ｓ２２５、Ｓ３２７）を含んでも良い。制御フレームに基づく所定制御の抑止のための所定処理は、例えば、その制御フレームを破棄する処理、エラーフレームの送信等によって通信路上でその制御フレームを上書きする処理、他の通信路へのその制御フレームの転送を抑止する処理、或いは、ＥＣＵにその制御フレームに基づく所定制御を実行させないように指示する処理等である。また、この方法をコンピュータにより実現するプログラム（コンピュータプログラム）であるとしても良いし、前記コンピュータプログラムからなるデジタル信号であるとしても良い。また、本発明の一態様としては、前記コンピュータプログラム又は前記デジタル信号をコンピュータで読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＢＤ（Blu-ray（登録商標） Disc）、半導体メモリ等に記録したものとしても良い。また、これらの記録媒体に記録されている前記デジタル信号であるとしても良い。また、本発明の一態様としては、前記コンピュータプログラム又は前記デジタル信号を、電気通信回線、無線又は有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしても良い。また、本発明の一態様としては、マイクロプロセッサとメモリを備えたコンピュータシステムであって、前記メモリは、上記コンピュータプログラムを記録しており、前記マイクロプロセッサは、前記コンピュータプログラムに従って動作するとしても良い。また、前記プログラム若しくは前記デジタル信号を前記記録媒体に記録して移送することにより、又は、前記プログラム若しくは前記デジタル信号を、前記ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしても良い。

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

本発明は、車載ネットワークを含む車載ネットワークシステムに利用可能である。

１０、１１、１２ 車載ネットワークシステム
１００、２１００、３１００ 監視ＥＣＵ
１１０、２０１ フレーム送受信部
１２０、２０２ フレーム処理部
１３０ 状態偽装検知部
１４０、２１４０、３１４０ 機能制限部
１５０、２０４ フレーム生成部
１６０、２１６０、３１６０ 受信履歴保持部
１７０ 車両状態保持部
１８０、２１８０、３１８０ 機能制限ルール保持部
２００ａ〜２００ｄ、３２００ｅ、３２００ｆ 電子制御ユニット（ＥＣＵ）
２０３ 機器入出力部
２１０ 速度センサ
２２０ リアカメラ
２３０ モニタ
２４０ ハンドル
２５０ ギア
３００ バス
２１３０ 車両状態監視部
３１３０ 制御情報監視部
３１９０ 不整合継続時間計測部
３２６０ スイッチ
３２７０ モータ
４１００ 不正制御抑止装置
４１１０ 受信部
４１２０ 判定部

Claims (9)

1. 制御対象に対して所定制御を指示する制御フレームを含む複数のフレームの授受を通信路を介して行う複数の電子制御ユニットを備えるネットワークシステムにおける不正制御抑止方法であって、
   前記複数のフレームには、前記制御対象の状態に関する情報を含む状態フレームが含まれ、
   前記不正制御抑止方法は、
   前記通信路から複数のフレームを逐次受信する受信ステップと、
   前記受信ステップで受信された制御フレームに基づく前記所定制御を抑止すべきか否かを、当該制御フレームの受信時に先行する所定期間内に前記受信ステップで受信された状態フレームの集合に基づいて特定される、当該所定期間における前記制御対象の状態が、所定基準を満たすか否かに基づいて、判定する判定ステップとを含み、
   前記所定基準は、前記所定期間における前記制御対象の状態について、所定量以上の変化が継続する不整合状態が継続する時間が所定時間を超えている場合に満たされ、前記所定時間を超えていない場合に満たされず、
   前記判定ステップでは、前記所定基準が満たされた場合に前記所定制御を抑止すべきと判定する
   不正制御抑止方法。
2. 前記判定ステップでは、前記所定基準が満たされない場合に前記所定制御を抑止しないと判定する、
   請求項１記載の不正制御抑止方法。
3. 前記不正制御抑止方法は更に、前記判定ステップで制御フレームに基づく前記所定制御を抑止すべきと判定された場合に、前記所定制御の抑止のための所定処理を実行する処理ステップを含み、
   前記所定処理は、当該制御フレームの異常を通知する処理、当該制御フレームを破棄する処理、前記通信路上で当該制御フレームを上書きする処理、他の通信路への当該制御フレームの転送を抑止する処理、及び、前記電子制御ユニットに当該制御フレームに基づく前記所定制御を実行させないように指示する処理のいずれか１つを含む
   請求項１又は２記載の不正制御抑止方法。
4. 前記制御対象は、前記ネットワークシステムを搭載する車両であり、
   前記通信路は、前記車両における有線通信路であり、
   前記複数の電子制御ユニットは、ＣＡＮプロトコル又はＥｔｈｅｒｎｅｔ（登録商標）プロトコルに従って、前記複数のフレームの授受を行う
   請求項１〜３のいずれか一項に記載の不正制御抑止方法。
5. 前記所定制御は、前記車両の走行に関わる制御である
   請求項４記載の不正制御抑止方法。
6. 前記受信ステップでは、車速、車輪の回転速度、ヨーレート、加速度、操舵角、アクセルペダル開度、制動レベル、エンジンの回転数、モータの回転数、ギアポジション、及び、イグニッションスイッチの状態のいずれか１つについての情報を含むフレームである状態フレームを逐次受信する
   請求項４又は５記載の不正制御抑止方法。
7. 前記複数のフレームには、前記制御対象の状態に関する情報を含む状態フレームが含まれ、
   前記複数の電子制御ユニットは、前記通信路であるネットワークに接続され、ＣＡＮプロトコルに従って、データフレームである状態フレーム及び制御フレームの授受を行い、
   前記不正制御抑止方法は更に、前記判定ステップで制御フレームに基づく前記所定制御を抑止すべきと判定された場合に、当該制御フレームの少なくとも一部に上書きするように前記ネットワークにエラーフレームを送信する処理ステップを含む
   請求項４〜６のいずれか一項に記載の不正制御抑止方法。
8. 複数の電子制御ユニットが、制御対象に対して所定制御を指示する制御フレームを含む複数のフレームの授受を通信路を介して行うところの当該通信路に接続される不正制御抑止装置であって、
   前記複数のフレームには、前記制御対象の状態に関する情報を含む状態フレームが含まれ、
   前記不正制御抑止装置は、
   前記通信路から複数のフレームを逐次受信する受信部と、
   前記受信部により受信された制御フレームに基づく前記所定制御を抑止すべきか否かを、当該制御フレームの受信時に先行する所定期間内に前記受信部により受信された状態フレームの集合に基づいて特定される、当該所定期間における前記制御対象の状態が、所定基準を満たすか否かに基づいて、判定する判定部とを備え、
   前記所定基準は、前記所定期間における前記制御対象の状態について、所定量以上の変化が継続する不整合状態が継続する時間が所定時間を超えている場合に満たされ、前記所定時間を超えていない場合に満たされず、
   前記判定部は、前記所定基準が満たされた場合に前記所定制御を抑止すべきと判定する
   不正制御抑止装置。
9. 車両の状態に関する情報を含むフレームである状態フレーム、及び、前記車両に対して所定制御を指示するフレームである制御フレームの授受をネットワークを介して行う複数の電子制御ユニットを備える車載ネットワークシステムであって、
   前記ネットワークから状態フレーム及び制御フレームを逐次受信する受信部と、
   前記受信部により受信された制御フレームに基づく前記所定制御を抑止すべきか否かを、当該制御フレームの受信時に先行する所定期間内に前記受信部により受信された状態フレームの集合に基づいて特定される、当該所定期間における前記車両の状態が、所定基準を満たすか否かに基づいて、判定する判定部とを備え、
   前記所定基準は、前記所定期間における前記車両の状態について、所定量以上の変化が継続する不整合状態が継続する時間が所定時間を超えている場合に満たされ、前記所定時間を超えていない場合に満たされず、
   前記判定部は、前記所定基準が満たされた場合に前記所定制御を抑止すべきと判定する
   車載ネットワークシステム。

Images