(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022190041
(43)【公開日】2022-12-22
(54)【発明の名称】不正検知ルール更新方法、不正検知電子制御ユニット及び車載ネットワークシステム
(51)【国際特許分類】
H04L 43/0876 20220101AFI20221215BHJP
【FI】
H04L43/0876
【審査請求】有
【請求項の数】13
【出願形態】OL
(21)【出願番号】P 2022175644
(22)【出願日】2022-11-01
(62)【分割の表示】P 2021071457の分割
【原出願日】2015-10-30
(31)【優先権主張番号】62/105,363
(32)【優先日】2015-01-20
(33)【優先権主張国・地域又は機関】US
(71)【出願人】
【識別番号】514136668
【氏名又は名称】パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
【氏名又は名称原語表記】Panasonic Intellectual Property Corporation of America
(74)【代理人】
【識別番号】100109210
【弁理士】
【氏名又は名称】新居 広守
(74)【代理人】
【識別番号】100137235
【弁理士】
【氏名又は名称】寺谷 英作
(74)【代理人】
【識別番号】100131417
【弁理士】
【氏名又は名称】道坂 伸一
(72)【発明者】
【氏名】氏家 良浩
(72)【発明者】
【氏名】松島 秀樹
(72)【発明者】
【氏名】芳賀 智之
(72)【発明者】
【氏名】海上 勇二
(72)【発明者】
【氏名】岸川 剛
(57)【要約】
【課題】車載ネットワークシステムにおいて必要に応じて不正なフレームを検知する為の基準となるルールの更新を可能にする不正検知ルール更新方法を提供する。
【解決手段】車両が走行しているか否かを示す車両状態の問合せを受信し、外部装置へ車両状態を送信し、ネットワーク上で送信されるメッセージについてのルールへの適合性の判定を、不正検知ルールに基づいて行い、更新用不正検知ルールと、更新用不正検知ルールの適用対象のネットワークの種別を示す種別情報とを含む配信データを受信し、車両が走行しているか否かを判定し、車両が走行していると判定した場合に、種別情報が走行に関連する駆動系のネットワークを示しているか否かを判定し、(i)種別情報が走行に関連する駆動系のネットワークを示している場合には、更新用不正検知ルールによる更新処理を行わず、(ii)(i)でない場合には、不正検知ルールを更新用不正検知ルールへと更新する。
【選択図】
図1
【特許請求の範囲】
【請求項1】
複数の電子制御ユニットがメッセージの授受を行う通信に用いるネットワークに接続される不正検知電子制御ユニットにおいて用いられる不正検知ルール更新方法であって、
車載ネットワークシステムの外部の外部装置から、前記車載ネットワークシステムを搭載する車両が走行しているか否かを示す車両状態の問合せを受信し、前記外部装置へ前記車両状態を送信し、
自ユニットが接続された前記ネットワーク上で送信されるメッセージについてのルールへの適合性の判定を、不正検知ルールに基づいて行い、
前記外部装置から更新用不正検知ルールと、前記更新用不正検知ルールの適用対象のネットワークの種別を示す種別情報とを含む配信データを受信し、
前記車両が走行しているか否かを判定し、
前記車両が走行していると判定した場合に、前記種別情報が走行に関連する駆動系のネットワークを示しているか否かを判定し、
(i)前記種別情報が走行に関連する駆動系のネットワークを示している場合には、前記更新用不正検知ルールによる更新処理を行わず、
(ii)前記種別情報が走行に関連する駆動系のネットワークを示していない場合には、前記不正検知ルールを前記更新用不正検知ルールへと更新する
不正検知ルール更新方法。
【請求項2】
前記不正検知電子制御ユニットが接続された前記ネットワークの種別を前記種別情報が示す場合に、所定更新条件が満たされたとして前記更新を行う
請求項1記載の不正検知ルール更新方法。
【請求項3】
前記配信データは、複数の更新用不正検知ルールを含み、当該複数の更新用不正検知ルールそれぞれに対応した、ネットワークの種別を示す種別情報を含み、
前記車載ネットワークシステムの外部の外部装置と通信することにより前記配信データの前記受信を行い、当該不正検知電子制御ユニットが接続された前記ネットワークの種別に該当する種別情報に対応する更新用不正検知ルールを前記配信データから抽出して、前記判定に係る前記不正検知ルールを、抽出した当該更新用不正検知ルールへと更新する
請求項1記載の不正検知ルール更新方法。
【請求項4】
前記配信データは、複数の更新用不正検知ルールを含み、当該複数の更新用不正検知ルールそれぞれに対応した、ネットワークの種別を示す種別情報を含み、
前記不正検知電子制御ユニットが接続された前記ネットワークの種別に応じた、不正検知ルール更新用のメッセージIDのメッセージを当該ネットワークから受信し、前記判定に係る前記不正検知ルールを、当該メッセージに含まれる更新用不正検知ルールへと更新する
請求項1記載の不正検知ルール更新方法。
【請求項5】
前記配信データは、付属情報を含み、
所定更新条件は、前記付属情報に関する条件であり、
前記不正検知ルールの前記更新を、受信した前記配信データにおける前記付属情報が前記所定更新条件を満たす場合には行い、前記付属情報が前記所定更新条件を満たさない場合には行わない
請求項1記載の不正検知ルール更新方法。
【請求項6】
前記所定更新条件を満たすか否かを、前記付属情報と前記不正検知電子制御ユニットが保持する情報とを比較した結果に応じて判別する
請求項5記載の不正検知ルール更新方法。
【請求項7】
前記付属情報は、前記更新用不正検知ルールのバージョンを示し、
前記判定の基礎としている前記不正検知ルールのバージョンよりも新しいバージョンを前記付属情報が示す場合に、前記所定更新条件が満たされたと判別して前記更新を行う
請求項6記載の不正検知ルール更新方法。
【請求項8】
前記付属情報は、前記更新用不正検知ルールの適用対象の車両種別を示し、
前記付属情報が、前記車載ネットワークシステムを搭載する車両に係る車両種別を示す場合に、前記所定更新条件が満たされたとして前記更新を行う
請求項5記載の不正検知ルール更新方法。
【請求項9】
前記不正検知ルール及び前記更新用不正検知ルールは、ルールへの適合性を判定するためのプログラムを含んで構成される
請求項1記載の不正検知ルール更新方法。
【請求項10】
前記配信データには、暗号処理が施されており、
前記配信データの前記受信に際して前記暗号処理に呼応する処理を施す
請求項1記載の不正検知ルール更新方法。
【請求項11】
前記複数の電子制御ユニットは、CAN(Controller Area Network)プロトコルに従って前記ネットワークを介して通信を行う
請求項1記載の不正検知ルール更新方法。
【請求項12】
複数の電子制御ユニットが通信に用いるネットワークに接続される不正検知電子制御ユニットであって、
車載ネットワークシステムの外部の外部装置から、前記車載ネットワークシステムを搭載する車両が走行しているか否かを示す車両状態の問合せを受信し、前記外部装置へ前記車両状態を送信する通信部と、
不正検知ルールを保持する不正検知ルール保持部と、
自ユニットが接続された前記ネットワーク上で送信されるメッセージについてのルールへの適合性の判定を、前記不正検知ルールに基づいて行う不正検知処理部と、
前記外部装置から更新用不正検知ルールと、前記更新用不正検知ルールの適用対象のネットワークの種別を示す種別情報とを含む配信データを受信して、
前記車載ネットワークシステムを搭載する車両が走行しているか否かを判定し、
前記車両が走行していると判定した場合に、更に、前記種別情報が走行に関連する駆動系のネットワークを示しているか否かを判定し、
(i)前記種別情報が走行に関連する駆動系のネットワークを示している場合には、前記更新用不正検知ルールによる更新処理を行わず、
(ii)前記種別情報が走行に関連する駆動系のネットワークを示していない場合には、前記不正検知ルールを前記更新用不正検知ルールへと更新する更新判定部とを備える
不正検知電子制御ユニット。
【請求項13】
1以上のネットワークを介した通信によりメッセージの授受を行う複数の電子制御ユニット及び前記ネットワークに接続された不正検知電子制御ユニットを備える車載ネットワークシステムであって、
前記不正検知電子制御ユニットは、
前記車載ネットワークシステムの外部の外部装置から、前記車載ネットワークシステムを搭載する車両が走行しているか否かを示す車両状態の問合せを受信し、前記外部装置へ前記車両状態を送信し、
前記不正検知電子制御ユニットが接続された前記ネットワーク上で送信されるメッセージについてのルールへの適合性の判定を、不正検知ルールに基づいて行い、
前記電子制御ユニットは、前記外部装置から更新用不正検知ルールと、前記更新用不正検知ルールの適用対象のネットワークの種別を示す種別情報とを含む配信データを受信して、当該更新用不正検知ルールを前記ネットワークを介して送信し、
前記不正検知電子制御ユニットは、前記ネットワークから前記更新用不正検知ルールを受信し、
前記車両が走行しているか否かを判定し、
前記車両が走行していると判定した場合に、更に、前記種別情報が走行に関連する駆動系のネットワークを示しているか否かを判定し、
(i)前記種別情報が走行に関連する駆動系のネットワークを示している場合には、前記更新用不正検知ルールによる更新処理を行わず、
(ii)前記種別情報が走行に関連する駆動系のネットワークを示していない場合には、前記不正検知ルールを前記更新用不正検知ルールへと更新する
車載ネットワークシステム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、電子制御ユニットが通信を行う車載ネットワークにおいて、送信された不正なフレームを検知するために用いられる不正検知ルールについてのアップデート(更新)技術に関する。
【背景技術】
【0002】
近年、自動車の中のシステムには、電子制御ユニット(ECU:Electronic Control Unit)と呼ばれる装置が多数配置されている。これらのECUをつなぐネットワークは車載ネットワークと呼ばれる。車載ネットワークには、多数の規格が存在する。その中でも最も主流な車載ネットワークの一つに、ISO11898-1で規定されているCAN(Controller Area Network)という規格が存在する。
【0003】
CANでは、通信路は2本のバスで構成され、バスに接続されているECUはノードと呼ばれる。バスに接続されている各ノードは、フレームと呼ばれるメッセージを送受信する。フレームを送信する送信ノードは、2本のバスに電圧をかけ、バス間で電位差を発生させることによって、レセシブと呼ばれる「1」の値と、ドミナントと呼ばれる「0」の値を送信する。複数の送信ノードが全く同一のタイミングで、レセシブとドミナントを送信した場合は、ドミナントが優先されて送信される。受信ノードは、受け取ったフレームのフォーマットに異常がある場合には、エラーフレームと呼ばれるフレームを送信する。エラーフレームとは、ドミナントを6bit連続して送信することで、送信ノードや他の受信ノードにフレームの異常を通知するものである。
【0004】
またCANでは送信先や送信元を指す識別子は存在せず、送信ノードはフレーム毎にメッセージIDと呼ばれるIDを付けて送信し(つまりバスに信号を送出し)、各受信ノードは予め定められたメッセージIDのみを受信する(つまりバスから信号を読み取る)。また、CSMA/CA(Carrier Sense Multiple Access/Collision Avoidance)方式を採用しており、複数ノードの同時送信時にはメッセージIDによる調停が行われ、メッセージIDの値が小さいフレームが優先的に送信される。
【0005】
従来、異常なメッセージがCANのバス上に送信された場合に、バス間を接続するゲートウェイ装置が異常メッセージを検出して、他のバスに転送しないことで、バスの負荷の上昇を抑える技術が知られている(「特許文献1」参照)。また、周期的に送られてくるメッセージの周期をチェックし、不正なフレームを判定する技術が知られている(「非特許文献1」参照)。
【先行技術文献】
【特許文献】
【0006】
【非特許文献】
【0007】
【非特許文献1】大塚 敏史、石郷岡 祐、「既存ECUを変更不要な車載LAN向け侵入検知手法」、研究報告組込みシステム(EMB)、情報処理学会、2013年3月6日、2013-EMB-28巻、6号、1-5頁
【発明の概要】
【発明が解決しようとする課題】
【0008】
ところで、例えば車載ネットワークシステムを構成するECUの機能の変更(改良等)に伴い、メッセージ(フレーム)を不正(異常)と判定するための判定基準であるルールを更新する必要が生じ得る。また、ルールが固定であると例えば不正なECUが車載ネットワークに接続されてそのルールを回避するメッセージを送信するリスクが高まるため、ルールの変更(更新)が有用となり得る。
【0009】
そこで、本発明は、車載ネットワークシステムにおいて必要に応じて不正なフレームを検知するための基準となるルールの更新を可能にする不正検知ルール更新方法を提供する。また、本発明は、そのルールの更新を可能にする車載ネットワークシステム、及び、その車載ネットワークシステムで不正なフレームを検知する不正検知電子制御ユニット(不正検知ECU)を提供する。
【課題を解決するための手段】
【0010】
上記課題を解決するために本発明の一態様に係る不正検知ルール更新方法は、複数の電子制御ユニットがメッセージの授受を行う通信に用いるネットワークに接続される不正検知電子制御ユニットにおいて用いられる不正検知ルール更新方法であって、車載ネットワークシステムの外部の外部装置から、前記車載ネットワークシステムを搭載する車両が走行しているか否かを示す車両状態の問合せを受信し、前記外部装置へ前記車両状態を送信し、自ユニットが接続された前記ネットワーク上で送信されるメッセージについてのルールへの適合性の判定を、不正検知ルールに基づいて行い、前記外部装置から更新用不正検知ルールと、前記更新用不正検知ルールの適用対象のネットワークの種別を示す種別情報とを含む配信データを受信し、前記車両が走行しているか否かを判定し、前記車両が走行していると判定した場合に、前記種別情報が走行に関連する駆動系のネットワークを示しているか否かを判定し、(i)前記種別情報が走行に関連する駆動系のネットワークを示している場合には、前記更新用不正検知ルールによる更新処理を行わず、(ii)前記種別情報が走行に関連する駆動系のネットワークを示していない場合には、前記不正検知ルールを前記更新用不正検知ルールへと更新する不正検知ルール更新方法である。
【0011】
また、上記課題を解決するために本発明の一態様に係る不正検知電子制御ユニットは、複数の電子制御ユニットが通信に用いるネットワークに接続される不正検知電子制御ユニットであって、車載ネットワークシステムの外部の外部装置から、前記車載ネットワークシステムを搭載する車両が走行しているか否かを示す車両状態の問合せを受信し、前記外部装置へ前記車両状態を送信する通信部と、不正検知ルールを保持する不正検知ルール保持部と、自ユニットが接続された前記ネットワーク上で送信されるメッセージについてのルールへの適合性の判定を、前記不正検知ルールに基づいて行う不正検知処理部と、前記外部装置から更新用不正検知ルールと、前記更新用不正検知ルールの適用対象のネットワークの種別を示す種別情報とを含む配信データを受信して、前記車載ネットワークシステムを搭載する車両が走行しているか否かを判定し、前記車両が走行していると判定した場合に、更に、前記種別情報が走行に関連する駆動系のネットワークを示しているか否かを判定し、(i)前記種別情報が走行に関連する駆動系のネットワークを示している場合には、前記更新用不正検知ルールによる更新処理を行わず、(ii)前記種別情報が走行に関連する駆動系のネットワークを示していない場合には、前記不正検知ルールを前記更新用不正検知ルールへと更新する更新判定部とを備える不正検知電子制御ユニットである。
【0012】
また、上記課題を解決するために本発明の一態様に係る車載ネットワークシステムは、1以上のネットワークを介した通信によりメッセージの授受を行う複数の電子制御ユニット及び前記ネットワークに接続された不正検知電子制御ユニットを備える車載ネットワークシステムであって、前記不正検知電子制御ユニットは、前記車載ネットワークシステムの外部の外部装置から、前記車載ネットワークシステムを搭載する車両が走行しているか否かを示す車両状態の問合せを受信し、前記外部装置へ前記車両状態を送信し、前記不正検知電子制御ユニットが接続された前記ネットワーク上で送信されるメッセージについてのルールへの適合性の判定を、不正検知ルールに基づいて行い、前記電子制御ユニットは、前記外部装置から更新用不正検知ルールと、前記更新用不正検知ルールの適用対象のネットワークの種別を示す種別情報とを含む配信データを受信して、当該更新用不正検知ルールを前記ネットワークを介して送信し、前記不正検知電子制御ユニットは、前記ネットワークから前記更新用不正検知ルールを受信し、前記車両が走行しているか否かを判定し、前記車両が走行していると判定した場合に、更に、前記種別情報が走行に関連する駆動系のネットワークを示しているか否かを判定し、(i)前記種別情報が走行に関連する駆動系のネットワークを示している場合には、前記更新用不正検知ルールによる更新処理を行わず、(ii)前記種別情報が走行に関連する駆動系のネットワークを示していない場合には、前記不正検知ルールを前記更新用不正検知ルールへと更新する車載ネットワークシステムである。
【発明の効果】
【0013】
本発明によれば、車載ネットワークにおいて不正なフレームが送信されたと判定する基準となるルールの更新が可能となり、これにより不正なフレームを検知する機能が更新され得る。従って、車載ネットワークシステムの変更等に対応可能となり、また、車載ネットワークにおいて不正なECUがルールを回避してメッセージを送信するリスクを低減可能となる。
【図面の簡単な説明】
【0014】
【
図1】実施の形態1に係る車載ネットワークシステムの全体構成を示す図である。
【
図2】CANプロトコルで規定されるデータフレームのフォーマットを示す図である。
【
図4】実施の形態1に係るECUが保持する受信IDリストの一例を示す図である。
【
図5】実施の形態1に係るECUが保持する受信IDリストの一例を示す図である。
【
図6】実施の形態1に係るECUが保持する受信IDリストの一例を示す図である。
【
図7】エンジンに接続されたECUから送信されるフレームにおけるメッセージID及びデータの一例を示す図である。
【
図8】ブレーキに接続されたECUから送信されるフレームにおけるメッセージID及びデータの一例を示す図である。
【
図9】ドア開閉センサに接続されたECUから送信されるフレームにおけるメッセージID及びデータの一例を示す図である。
【
図10】窓開閉センサに接続されたECUから送信されるフレームにおけるメッセージID及びデータの一例を示す図である。
【
図11】コーナーセンサに接続されたECUから送信されるフレームにおけるメッセージID及びデータの一例を示す図である。
【
図12】実施の形態1に係るゲートウェイの構成図である。
【
図13】実施の形態1に係るゲートウェイが保持する転送ルールの一例を示す図である。
【
図14】実施の形態1に係る不正検知ECUの構成図である。
【
図15】実施の形態1に係る不正検知ECUが保持する不正検知ルール及びバージョン情報の一例を示す図である。
【
図16】実施の形態1に係る不正検知ECUが保持する不正検知ルール及びバージョン情報の一例を示す図である。
【
図17】実施の形態1に係る不正検知ECUが保持する不正検知ルール及びバージョン情報の一例を示す図である。
【
図18】実施の形態1に係る配信データフォーマットの一例を示す図である。
【
図19】実施の形態1に係る配信データの一例を示す図である。
【
図20】実施の形態1に係る更新結果データフォーマットの一例を示す図である。
【
図21】実施の形態1に係る更新結果データの一例を示す図である。
【
図22】実施の形態1に係るサーバの構成図である。
【
図23】実施の形態1に係る更新結果表の一例を示す図である。
【
図24】実施の形態1における不正なフレームの検知及び実行阻止に係る動作例を示すシーケンス図である。
【
図25】実施の形態1における不正検知ルールの更新に係る動作例を示すシーケンス図である(
図26に続く)。
【
図26】実施の形態1における不正検知ルールの更新に係る動作例を示すシーケンス図である(
図25から続く)。
【
図27】実施の形態1の変形例に係る不正検知ECUの構成図である。
【
図28】実施の形態1の変形例における不正検知ルールの更新に係る動作例を示すシーケンス図である(
図29に続く)。
【
図29】実施の形態1の変形例における不正検知ルールの更新に係る動作例を示すシーケンス図である(
図28から続く)。
【
図30】実施の形態2に係る車載ネットワークシステムの全体構成を示す図である。
【
図31】実施の形態2に係るヘッドユニットの構成図である。
【
図32】実施の形態2に係るヘッドユニットが保持する受信IDリストの一例を示す図である。
【
図33】実施の形態2に係る内部配信データの一例を示す図である。
【
図34】実施の形態2に係る内部更新結果データの一例を示す図である。
【
図35】実施の形態2に係るゲートウェイが保持する転送ルールの一例を示す図である。
【
図36】実施の形態2に係る不正検知ECUの構成図である。
【
図37】実施の形態2に係る不正検知ECUが保持する不正検知ルール及びバージョン情報の一例を示す図である。
【
図38】実施の形態2に係る不正検知ECUが保持する不正検知ルール及びバージョン情報の一例を示す図である。
【
図39】実施の形態2に係る不正検知ECUが保持する不正検知ルール及びバージョン情報の一例を示す図である。
【
図40】実施の形態2に係るサーバの構成図である。
【
図41】実施の形態2に係る内部更新結果表の一例を示す図である。
【
図42】実施の形態2における不正検知ルールの更新に係る動作例を示すシーケンス図である(
図43に続く)。
【
図43】実施の形態2における不正検知ルールの更新に係る動作例を示すシーケンス図である(
図42から続く)。
【発明を実施するための形態】
【0015】
本発明の一態様に係る不正検知ルール更新方法は、1以上のバスを介した通信によりメッセージの授受を行う複数の電子制御ユニット及び前記バスに接続された不正検知電子制御ユニットを備える車載ネットワークシステムにおいて用いられる不正検知ルール更新方法であって、前記不正検知電子制御ユニットにおいて、当該不正検知電子制御ユニットが接続された前記バス上で送信されるメッセージについてのルールへの適合性の判定を、不正検知ルールに基づいて行い、前記車載ネットワークシステムの外部の外部装置から更新用不正検知ルールを含む配信データを受信して、所定更新条件が満たされた場合には前記判定に係る前記不正検知ルールを当該更新用不正検知ルールへと更新する不正検知ルール更新方法である。これにより、車載ネットワークにおいて不正なフレームが送信されたと判定する基準となるルールの更新が可能となる。従って、車載ネットワークシステムの変更等に対応可能となり、また、車載ネットワークにおいて不正なECUがルールを回避してメッセージを送信するリスクを低減可能となる。
【0016】
また、前記配信データは、前記更新用不正検知ルールの適用対象のバスの種別を示すバス種別情報を含み、前記不正検知電子制御ユニットは、当該不正検知電子制御ユニットが接続された前記バスの種別を前記バス種別情報が示す場合に、前記所定更新条件が満たされたとして前記更新を行うこととしても良い。これにより、バスの種別毎に必要な不正検知ルールが異なることに対応し得る。
【0017】
また、前記配信データは、複数の更新用不正検知ルールを含み、当該複数の更新用不正検知ルールそれぞれに対応した、バスの種別を示すバス種別情報を含み、前記不正検知電子制御ユニットが、前記外部装置と通信することにより前記配信データの前記受信を行い、当該不正検知電子制御ユニットが接続された前記バスの種別に該当するバス種別情報に対応する更新用不正検知ルールを前記配信データから抽出して、前記判定に係る前記不正検知ルールを、抽出した当該更新用不正検知ルールへと更新することとしても良い。これにより、不正検知ルールを配信する外部装置側では一括した配信が可能となり処理負担が軽減される。
【0018】
また、前記配信データは、複数の更新用不正検知ルールを含み、当該複数の更新用不正検知ルールそれぞれに対応した、バスの種別を示すバス種別情報を含み、1台の前記電子制御ユニットが前記配信データの前記受信を行い、当該配信データにおける各更新用不正検知ルールを、対応するバス種別情報が示すバスの種別に応じた、不正検知ルール更新用のメッセージIDを付したメッセージに含めて前記バスを介して送信し、前記不正検知電子制御ユニットが、当該不正検知電子制御ユニットが接続された前記バスの種別に応じた、不正検知ルール更新用のメッセージIDのメッセージを当該バスから受信し、前記判定に係る前記不正検知ルールを、当該メッセージに含まれる更新用不正検知ルールへと更新することとしても良い。これにより、1つのECUだけが外部との通信を行うため個々の不正検知ECUの処理負荷が削減され得る。また、この構成により、通信内容についてセキュリティを確保する暗号処理等の実装面では、外部との通信を行うECUでは例えば処理負荷が大きい暗号方式を用いるとしても、外部とは通信しない各不正検知ECUでは処理負荷が小さい暗号方式を選択し得るようになる。また、個々の不正検知ECUが通信する場合と比べて、サーバと車載ネットワークシステムとの間での通信回数を低減させ得る。
【0019】
また、前記配信データは、付属情報を含み、前記所定更新条件は、前記付属情報に関する条件であり、前記不正検知ルールの前記更新を、受信した前記配信データにおける前記付属情報が前記所定更新条件を満たす場合には行い、前記付属情報が前記所定更新条件を満たさない場合には行わないこととしても良い。これにより、更新用不正検知ルールに関する情報に基づいて更新要否を判別できるようになる。
【0020】
また、前記所定更新条件を満たすか否かを、前記付属情報と前記電子制御ユニット又は前記不正検知電子制御ユニットが保持する情報とを比較した結果に応じて判別することとしても良い。これにより、更新用不正検知ルールのバージョンが既存の不正検知ルールのバージョンよりも新しいか否か等といった比較判断が可能になる。
【0021】
また、前記付属情報は、前記更新用不正検知ルールのバージョンを示し、前記不正検知電子制御ユニットは、前記判定の基礎としている前記不正検知ルールのバージョンよりも新しいバージョンを前記付属情報が示す場合に、前記所定更新条件が満たされたと判別して前記更新を行うこととしても良い。これにより、不正検知ルールの内容変更についてバージョンによる管理が可能となる。
【0022】
また、前記付属情報は、前記更新用不正検知ルールの適用対象の車両種別を示し、前記付属情報が、前記車載ネットワークシステムを搭載する車両に係る車両種別を示す場合に、前記所定更新条件が満たされたとして前記更新を行うこととしても良い。これにより、
車種毎に独立して不正検知ルールを規定可能となる。
【0023】
また、前記所定更新条件は、前記車載ネットワークシステムを搭載する車両の状態が所定状態であるという条件であることとしても良い。これにより、例えば比較的安全性が高い状態等を所定状態として定めておくことで、安全に不正検知ルールの更新を行うことが可能になる。
【0024】
また、前記配信データを受信した際に前記車両の状態が前記所定状態でない場合には、前記車両の状態が前記所定状態へと変化した際に、前記判定に係る前記不正検知ルールを、既に受信している当該配信データに含まれる前記更新用不正検知ルールへと更新する、又は、前記外部装置から前記配信データを新たに受信して前記不正検知ルールを、新たに受信した当該配信データに含まれる前記更新用不正検知ルールへと更新することとしても良い。これにより、車両の状態が所定状態に変化した際に適切に不正検知ルールの更新が行える。
【0025】
また、前記不正検知ルール及び前記更新用不正検知ルールは、ルールへの適合性を判定するためのプログラムを含んで構成されることとしても良い。これにより、不正検知のためのプログラムの更新が可能となる。
【0026】
また、前記配信データには、暗号処理が施されており、前記配信データの前記受信に際して前記暗号処理に呼応する処理を施すこととしても良い。これにより、不正検知ルールについてセキュリティを確保し得る。
【0027】
また、前記複数の電子制御ユニットは、CAN(Controller Area Network)プロトコルに従って前記バスを介して通信を行うこととしても良い。これにより、CANに従った車載ネットワークシステムにおいて不正検知ルールの更新が可能となる。
【0028】
また、本発明の一態様に係る不正検知電子制御ユニットは、不正検知電子制御ユニットである。これにより、不正なフレームが送信されたと判定する基準となるルールの更新が可能となる。
【0029】
また、本発明の一態様に係る車載ネットワークシステムは、1以上のバスを介した通信によりメッセージの授受を行う複数の電子制御ユニット及び前記バスに接続された不正検知電子制御ユニットを備える車載ネットワークシステムであって、前記不正検知電子制御ユニットは、当該不正検知電子制御ユニットが接続された前記バス上で送信されるメッセージについてのルールへの適合性の判定を、不正検知ルールに基づいて行い、前記電子制御ユニットは、前記車載ネットワークシステムの外部の外部装置から更新用不正検知ルールを含む配信データを受信して、当該更新用不正検知ルールを前記バスを介して送信し、前記不正検知電子制御ユニットは、前記バスから前記更新用不正検知ルールを受信し、所定更新条件が満たされた場合には前記判定に係る前記不正検知ルールを当該更新用不正検知ルールへと更新する車載ネットワークシステムである。これにより、不正検知ルールの更新が可能となるため、車載ネットワークシステムの構成の変更等に対応可能となり、また、車載ネットワークにおいて不正なECUがルールを回避してメッセージを送信するリスクを低減可能となる。
【0030】
なお、これらの全般的又は具体的な態様は、システム、方法、集積回路、コンピュータプログラム又はコンピュータで読み取り可能なCD-ROM等の記録媒体で実現されても良く、システム、方法、集積回路、コンピュータプログラム又は記録媒体の任意な組み合わせで実現されても良い。
【0031】
以下、実施の形態に係る不正検知ルール更新方法を用いる車載ネットワークシステムについて、図面を参照しながら説明する。ここで示す実施の形態は、いずれも本発明の一具体例を示すものである。従って、以下の実施の形態で示される数値、構成要素、構成要素の配置及び接続形態、並びに、ステップ(工程)及びステップの順序等は、一例であって本発明を限定するものではない。以下の実施の形態における構成要素のうち、独立請求項に記載されていない構成要素については、任意に付加可能な構成要素である。また、各図は、模式図であり、必ずしも厳密に図示されたものではない。
【0032】
(実施の形態1)
以下、本発明の実施の形態として、車両に搭載されて複数のECUがバスを介して通信する車載ネットワークシステム10において、バスに送出された不正なフレーム(メッセージ)を不正検知ECUが検知するために用いる不正検知ルールを更新する不正検知ルール更新方法について、図面を用いて説明する。不正検知ECUは、車載ネットワークシステム10を構成するECU間での通信に用いられるバス上で送信されるフレームについて、不正検知ルールに基づいて検査(つまりルールへの適合性の判定)を行う。不正検知ECUの検査(つまり不正検知)の結果を活用した処理により、例えばバスに不正なECUが接続されてルールに適合しない不正なフレームを送信する等により車両を不適切に制御することを防ぐことが可能になる。本実施の形態では、バス毎に接続された各不正検知ECUが車両の外部のサーバと通信することにより不正検知機能を更新(つまりフレームを不正と判定する基準、基礎等となる不正検知ルールを更新)する例を示す。
【0033】
[1.1 車載ネットワークシステム10の全体構成]
図1は、車載ネットワークシステム10の全体構成を示す図である。車載ネットワークシステム10は、CANプロトコルに従って通信するネットワーク通信システムの一例であり、制御装置、センサ等の各種機器が搭載された自動車におけるネットワーク通信システムである。車載ネットワークシステム10は、バス200a~200cと、不正検知ECU400a~400c、ゲートウェイ300a、300b、及び、各種機器に接続されたECU100a~100e等のECUといったバスに接続された各ノードとを含んで構成される。また
図1では、車載ネットワークシステム10における不正検知ECU400a~400cと無線通信する外部のネットワーク600及びそのネットワーク600と通信可能に接続されたサーバ500とを付記している。なお、
図1では省略しているものの、車載ネットワークシステム10にはECU100a~100e以外にもいくつものECUが含まれ得る。車載ネットワークシステム10においてはCANプロトコルに従って各ECUがフレームの授受を行う。ECUは、例えば、プロセッサ(マイクロプロセッサ)、メモリ等のデジタル回路、アナログ回路、通信回路等を含む装置である。メモリは、ROM、RAM等であり、プロセッサにより実行される制御プログラム(コンピュータプログラム)を記憶することができる。例えばプロセッサが、制御プログラム(コンピュータプログラム)に従って動作することにより、ECUは各種機能を実現することになる。なお、コンピュータプログラムは、所定の機能を達成するために、プロセッサに対する指令を示す命令コードが複数個組み合わされて構成されたものである。バス200a~200cには不正なメッセージを送信する不正なECUが接続されている可能性があり、不正検知ECU400a~400cは、不正検知ルールに基づいてルールに適合しない不正なフレームがバス上に現れるとその不正なフレームを検知する。
【0034】
不正検知ECU400a、400b、400cは、それぞれバス200a、バス200b、バス200cに接続される一種のECUであり、自ECUが接続されたバス上に現れるフレームを監視して不正なフレームを検知した場合には、エラーフレームを送信する機能を有する。
【0035】
ECU100a~100eは、いずれかのバスと接続され、また、それぞれエンジン101、ブレーキ102、ドア開閉センサ103、窓開閉センサ104、コーナーセンサ105に接続されている。ECU100a~100eのそれぞれは、接続されている機器(エンジン101等)の状態を取得し、定期的に状態を表すフレーム(後述するデータフレーム)等をネットワーク(つまりバス)に送信している。
【0036】
ゲートウェイ300aは、不正検知ECU400a、ECU100a及びECU100bがつながるバス200aと、不正検知ECU400b、ECU100c及びECU100dがつながるバス200bとに接続している。ゲートウェイ300bは、不正検知ECU400b、ECU100c及びECU100dがつながるバス200bと、不正検知ECU400c及びECU100eがつながるバス200cとに接続している。ゲートウェイ300a、300bは、あるバスから受信したフレームを他のバスに転送する機能を有する。また受信したフレームを転送するかしないかを接続されたバス間毎に切り替えることも可能である。ゲートウェイ300a、300bも一種のECUである。
【0037】
サーバ500は、不正検知ECU400a~400cの不正検知機能をアップデート(更新)するために配信データを送信する機能を有する。サーバ500と不正検知ECU400a~400cとの間での通信方式はいかなる方式を用いても良く、例えば無線通信の他に有線通信を用いても良い。無線通信においては、WiFi(登録商標)、或いは携帯電話網等に用いられる3G(3rd Generation)回線、4G(LTE:Long Term Evolution)等を用いても良い。
【0038】
[1.2 データフレームフォーマット]
以下、CANプロトコルに従ったネットワークで用いられるフレームの1つであるデータフレームについて説明する。
【0039】
図2は、CANプロトコルで規定されるデータフレームのフォーマットを示す図である。同図には、CANプロトコルで規定される標準IDフォーマットにおけるデータフレームを示している。データフレームは、SOF(Start Of Frame)、IDフィールド、RTR(Remote Transmission Request)、IDE(Identifier Extension)、予約ビット「r」、DLC(Data Length Code)、データフィールド、CRC(Cyclic Redundancy Check)シーケンス、CRCデリミタ「DEL」、ACK(Acknowledgement)スロット、ACKデリミタ「DEL」、及び、EOF(End Of Frame)の各フィールドで構成される。
【0040】
SOFは、1bitのドミナントで構成される。バスがアイドルの状態はレセシブになっており、SOFによりドミナントへ変更することでフレームの送信開始を通知する。
【0041】
IDフィールドは、11bitで構成される、データの種類を示す値であるID(メッセージID)を格納するフィールドである。複数のノードが同時に送信を開始した場合、このIDフィールドで通信調停を行うために、IDが小さい値を持つフレームが高い優先度となるよう設計されている。
【0042】
RTRは、データフレームとリモートフレームとを識別するための値であり、データフレームにおいてはドミナント1bitで構成される。
【0043】
IDEと「r」とは、両方ドミナント1bitで構成される。
【0044】
DLCは、4bitで構成され、データフィールドの長さを示す値である。なお、IDE、r及びDLCを合わせてコントロールフィールドと称する。
【0045】
データフィールドは、最大64bitで構成される送信するデータの内容を示す値である。8bit毎に長さを調整できる。送られるデータの仕様については、CANプロトコルで規定されておらず、車載ネットワークシステム10において定められる。従って、車種、製造者(製造メーカ)等に依存した仕様となる。
【0046】
CRCシーケンスは、15bitで構成される。SOF、IDフィールド、コントロールフィールド及びデータフィールドの送信値より算出される。
【0047】
CRCデリミタは、1bitのレセシブで構成されるCRCシーケンスの終了を表す区切り記号である。なお、CRCシーケンス及びCRCデリミタを合わせてCRCフィールドと称する。
【0048】
ACKスロットは、1bitで構成される。送信ノードはACKスロットをレセシブにして送信を行う。受信ノードはCRCシーケンスまで正常に受信ができていればACKスロットをドミナントとして送信する。レセシブよりドミナントが優先されるため、送信後にACKスロットがドミナントであれば、送信ノードは、いずれかの受信ノードが受信に成功していることを確認できる。
【0049】
ACKデリミタは、1bitのレセシブで構成されるACKの終了を表す区切り記号である。
【0050】
EOFは、7bitのレセシブで構成されており、データフレームの終了を示す。
【0051】
[1.3 ECU100aの構成]
図3は、ECU100aの構成図である。ECU100aは、フレーム送受信部110と、フレーム解釈部120と、受信ID判断部130と、受信IDリスト保持部140と、フレーム処理部150と、フレーム生成部160と、データ取得部170とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、ECU100aにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。
【0052】
フレーム送受信部110は、バス200aに対して、CANプロトコルに従ったフレームを送受信する。バス200aからフレームを1bitずつ受信し、フレーム解釈部120に転送する。また、フレーム生成部160より通知を受けたフレームの内容をバス200aに送信する。
【0053】
フレーム解釈部120は、フレーム送受信部110よりフレームの値を受け取り、CANプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。IDフィールドと判断した値は受信ID判断部130へ転送する。フレーム解釈部120は、受信ID判断部130から通知される判定結果に応じて、IDフィールドの値と、IDフィールド以降に現れるデータフィールドとを、フレーム処理部150へ転送するか、その判定結果を受けた以降においてフレームの受信を中止する(つまりそのフレームとしての解釈を中止する)かを決定する。また、フレーム解釈部120は、CANプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部160へ通知する。また、フレーム解釈部120は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。
【0054】
受信ID判断部130は、フレーム解釈部120から通知されるIDフィールドの値を受け取り、受信IDリスト保持部140が保持しているメッセージIDのリストに従い、そのIDフィールド以降のフレームの各フィールドを受信するかどうかの判定を行う。この判定結果を、受信ID判断部130は、フレーム解釈部120へ通知する。
【0055】
受信IDリスト保持部140は、ECU100aが受信するID(メッセージID)のリストである受信IDリストを保持する。
図4に、受信IDリストの一例を示す。
【0056】
フレーム処理部150は、受信したフレームのデータに応じてECU毎に異なる機能に係る処理を行う。例えば、エンジン101に接続されたECU100aは、時速が30kmを超えた状態でドアが開いている状態だと、アラーム音を鳴らす機能を備える。ECU100aは、例えばアラーム音を鳴らすためのスピーカ等を有している。そして、ECU100aのフレーム処理部150は、他のECUから受信したデータ(例えばドアの状態を示す情報)を管理し、エンジン101から取得された時速に基づいて一定条件下でアラーム音を鳴らす処理等を行う。
【0057】
データ取得部170は、ECUにつながっている機器、センサ等の状態を示すデータを取得し、フレーム生成部160に通知する。
【0058】
フレーム生成部160は、フレーム解釈部120から通知されたエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部110へ通知して送信させる。また、フレーム生成部160は、データ取得部170より通知されたデータの値に対して、予め定められたメッセージIDをつけてフレームを構成し、フレーム送受信部110へ通知する。
【0059】
なお、ECU100b~100eも、上述したECU100aと基本的に同様の構成を備える。受信IDリスト保持部140に保持される受信IDリストはECU毎に異なる内容となり得るが、同じ内容であっても良い。また、フレーム処理部150の処理内容は、ECU毎に異なる。例えば、ECU100cにおけるフレーム処理部150の処理内容は、ブレーキがかかっていない状況でドアが開くとアラーム音を鳴らす機能に係る処理を含む。例えば、ECU100b、ECU100d及びECU100eにおけるフレーム処理部150では特段の処理を行わない。なお、各ECUは、ここで例示した以外の機能を備えていても良い。なお、ECU100a~100eのそれぞれが送信するフレームの内容については後に
図7~
図11を用いて説明する。
【0060】
[1.4 受信IDリスト例1]
図4は、ECU100a及びECU100bのそれぞれにおいて保持される受信IDリストの一例を示す図である。同図に例示する受信IDリストは、ID(メッセージID)の値が「1」、「2」及び「3」のいずれかであるメッセージIDを含むフレームを選択的に受信して処理するために用いられる。
【0061】
[1.5 受信IDリスト例2]
図5は、ECU100c及びECU100dのそれぞれにおいて保持される受信IDリストの一例を示す図である。同図に例示する受信IDリストは、ID(メッセージID)の値が「1」、「2」、「3」及び「4」のいずれかであるメッセージIDを含むフレームを選択的に受信して処理するために用いられる。
【0062】
[1.6 受信IDリスト例3]
図6は、ECU100e、ゲートウェイ300a及びゲートウェイ300bのそれぞれにおいて保持される受信IDリストの一例を示す図である。同図に例示する受信IDリストは、ID(メッセージID)の値が「1」、「2」、「3」、「4」及び「5」のいずれかであるメッセージIDを含むフレームを選択的に受信して処理するために用いられる。
【0063】
[1.7 エンジンに係るECU100aの送信フレーム例]
図7は、エンジン101に接続されたECU100aから送信されるフレームにおけるID(メッセージID)及びデータフィールド(データ)の一例を示す図である。ECU100aが送信するフレームのメッセージIDは「1」である。データは、時速(km/時)を表し、最低0(km/時)~最高180(km/時)までの範囲の値を取り、データ長は1Byteである。
図7の上行から下行へと、ECU100aから逐次送信される各フレームに対応する各メッセージID及びデータを例示しており、0km/時から1km/時ずつ加速されている様子を表している。
【0064】
[1.8 ブレーキに係るECU100bの送信フレーム例]
図8は、ブレーキ102に接続されたECU100bから送信されるフレームにおけるID(メッセージID)及びデータフィールド(データ)の一例を示す図である。ECU100bが送信するフレームのメッセージIDは「2」である。データは、ブレーキのかかり具合を割合(%)で表し、データ長は1Byteである。この割合は、ブレーキを全くかけていない状態を0(%)、ブレーキを最大限かけている状態を100(%)としたものである。
図8の上行から下行へと、ECU100bから逐次送信される各フレームに対応する各メッセージID及びデータを例示しており、100%から徐々にブレーキを弱めている様子を表している。
【0065】
[1.9 ドア開閉センサに係るECU100cの送信フレーム例]
図9は、ドア開閉センサ103に接続されたECU100cから送信されるフレームにおけるID(メッセージID)及びデータフィールド(データ)の一例を示す図である。ECU100cが送信するフレームのメッセージIDは「3」である。データは、ドアの開閉状態を表し、データ長は1Byteである。データの値は、ドアが開いている状態が「1」、ドアが閉まっている状態が「0」である。
図9の上行から下行へと、ECU100cから逐次送信される各フレームに対応する各メッセージID及びデータを例示しており、ドアが開いている状態から次第に閉められた状態へと移った様子を表している。
【0066】
[1.10 窓開閉センサに係るECU100dの送信フレーム例]
図10は、窓開閉センサ104に接続されたECU100dから送信されるフレームにおけるID(メッセージID)及びデータフィールド(データ)の一例を示す図である。ECU100dが送信するフレームのメッセージIDは「4」である。データは、窓の開閉状態を割合(%)で表し、データ長は1Byteである。この割合は、窓が完全に閉まっている状態を0(%)、窓が全開の状態を100(%)としたものである。
図10の上行から下行へと、ECU100dから逐次送信される各フレームに対応する各メッセージID及びデータを例示しており、窓が閉まっている状態から徐々に開いていく様子を表している。
【0067】
[1.11 コーナーセンサに係るECU100eの送信フレーム例]
図11は、コーナーセンサ105に接続されたECU100eから送信されるフレームにおけるID(メッセージID)及びデータフィールド(データ)の一例を示す図である。ECU100eが送信するフレームのメッセージIDは「5」である。データ長は1Byteである。データの値は、コーナーセンサ105が、車両のコーナーから一定距離範囲に障害物が存在することを検知すれば「1」、障害物を検知しなければ「0」である。
図11の上行から下行へと、ECU100eから定期的に送信される各フレームに対応する各メッセージID及びデータを例示しており、車両のコーナーに障害物が検知されない状態から次第に障害物が検知される状態へと移った様子を表している。
【0068】
[1.12 ゲートウェイ300aの構成]
図12は、ゲートウェイ300aの構成図である。ゲートウェイ300aは、フレーム送受信部310と、フレーム解釈部320と、受信ID判断部330と、受信IDリスト保持部340と、転送処理部351と、転送ルール保持部352と、フレーム生成部360とを含んで構成される。なお、ゲートウェイ300bも同様の構成を有する。これらの各構成要素は、機能的な構成要素であり、その各機能は、ゲートウェイ300aにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。
【0069】
フレーム送受信部310は、バス200a、200b、200cそれぞれに対して、CANプロトコルに従ったフレームを送受信する。バスからフレームを1bitずつ受信し、フレーム解釈部320に転送する。また、フレーム生成部360より通知を受けた転送先のバスを示すバス情報及びフレームに基づいて、そのフレームの内容をバス200a、200b、200cに1bitずつ送信する。
【0070】
フレーム解釈部320は、フレーム送受信部310よりフレームの値を受け取り、CANプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。IDフィールドと判断した値は受信ID判断部330へ転送する。フレーム解釈部320は、受信ID判断部330から通知される判定結果に応じて、IDフィールドの値と、IDフィールド以降に現れるデータフィールド(データ)とを、転送処理部351へ転送するか、その判定結果を受けた以降においてフレームの受信を中止する(つまりそのフレームとしての解釈を中止する)かを決定する。また、フレーム解釈部320は、CANプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部360へ通知する。また、フレーム解釈部320は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。
【0071】
受信ID判断部330は、フレーム解釈部320から通知されるIDフィールドの値を受け取り、受信IDリスト保持部340が保持しているメッセージIDのリストに従い、そのIDフィールド以降のフレームの各フィールドを受信するかどうかの判定を行う。この判定結果を、受信ID判断部330は、フレーム解釈部320へ通知する。
【0072】
受信IDリスト保持部340は、ゲートウェイ300aが受信するID(メッセージID)のリストである受信IDリスト(
図6参照)を保持する。
【0073】
転送処理部351は、転送ルール保持部352が保持する転送ルールに従って、受信したフレームのメッセージIDに応じて、転送するバスを決定し、転送するバスを示すバス情報とフレーム解釈部320より通知されたメッセージIDとデータとをフレーム生成部360へ通知する。なお、ゲートウェイ300aは、あるバスから受信されたエラーフレームについては他のバスに転送しない。
【0074】
転送ルール保持部352は、バス毎のフレームの転送についてのルールを表す情報である転送ルールを保持する。
図13は、転送ルールの一例を示した図である。
【0075】
フレーム生成部360は、フレーム解釈部320から通知されたエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部310へ通知して送信させる。また、フレーム生成部360は、転送処理部351より通知されたメッセージIDとデータとを使ってフレームを構成し、フレーム及びバス情報をフレーム送受信部310へ通知する。
【0076】
[1.13 転送ルール例]
図13は、ゲートウェイ300a及びゲートウェイ300bが保持する転送ルールの一例を示す。この転送ルールは、転送元のバスと転送先のバスと転送対象のID(メッセージID)とを対応付けている。
図13中の「*」は、メッセージIDにかかわらずフレームの転送がなされることを表している。また、
図13中の「-」は転送対象のフレームがないことを示す。
図13の例は、バス200aから受信するフレームはメッセージIDにかかわらず、バス200b及びバス200cに転送するように設定されていることを示している。また、バス200bから受信するフレームのうち、バス200cには全てのフレームが転送されるが、バス200aにはメッセージIDが「3」であるフレームのみが転送されるように設定されていることを示している。また、バス200cから受信されるフレームは、バス200bに転送されないように設定されていることを示している。
【0077】
[1.14 不正検知ECU400aの構成]
図14は、不正検知ECU400aの構成図である。不正検知ECU400aは、フレーム送受信部410と、フレーム解釈部420と、フレーム生成部460と、不正検知処理部480と、不正検知ルール保持部481と、外部通信部490と、暗復号処理部491と、MAC処理部492と、鍵保持部493と、更新判定部494と、車両No.保持部495と、バス種別保持部496とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、不正検知ECU400aにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。なお、不正検知ECU400b及び不正検知ECU400cも基本的に同様の構成を備えるが、不正検知ルール保持部481の保持内容(不正検知ルール及びバージョン情報)が互いに異なり得る。
【0078】
フレーム送受信部410は、バス200aに対して、CANプロトコルに従ったフレームを送受信する。即ち、フレーム送受信部410は、バス200aからフレームを1bitずつ受信し、フレーム解釈部420に転送する。また、フレーム生成部460より通知を受けたフレームの内容をバス200aに送信する。
【0079】
フレーム解釈部420は、フレーム送受信部410よりフレームの値を受け取り、CANプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。IDフィールドと判断した値は、不正検知処理部480へ転送する。また、フレーム解釈部420は、CANプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部460へ通知する。また、フレーム解釈部420は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。
【0080】
フレーム生成部460は、フレーム解釈部420から通知されたエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部410へ通知して送信させる。また、フレーム生成部460は、不正検知処理部480から通知されたエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部410へ通知して送信させる。
【0081】
不正検知処理部480は、不正検知ルール保持部481が保持している不正検知ルールに基づいて、バス200aから取得されたフレームが不正か否かについて判定する機能を有する。本実施の形態において不正検知ルールとして、不正でないメッセージIDを列挙した所謂ホワイトリストを用いる。不正検知処理部480は、具体的には、フレーム解釈部420から通知されるIDフィールドの値(ID)を受け取り、そのIDが、不正検知ルールとしてのメッセージIDのリスト(ホワイトリスト)に載っていない場合には、エラーフレームを送信するように、フレーム生成部460へ通知する。この場合に、バス200aにおいて、不正検知ルールとしてのメッセージIDのリストに載っていないIDを含むフレーム(不正なフレーム)のビット値は、レセシブに優先するドミナントが複数連続して構成されるエラーフレームにより、上書きされることになる。
【0082】
不正検知ルール保持部481は、不正検知ルールとして、バス200aを送信されるフレームに含まれるメッセージIDを規定したリストを保持し、その不正検知ルールについてのバージョンを示すバージョン情報を保持する(
図15参照)。また、不正検知ルール保持部481は、更新判定部494からの新たな不正検知ルール(更新用不正検知ルールとも称する。)の通知に応じて、更新用不正検知ルールで先に保持していた不正検知ルールを更新し、更新した結果を更新判定部494へ通知する。
【0083】
外部通信部490は、サーバ500とネットワーク600を介して通信することで、不正検知ルールを更新するための更新用不正検知ルール(新たな不正検知ルール)等を含む配信データを取得する。また、外部通信部490は、ネットワーク600を介して更新結果データをサーバ500へ通知する。外部通信部490は、取得した配信データを暗復号処理部491へ送信し、復号した結果を取得する。また、復号した配信データにおける検証用データとしてのメッセージ認証コード(MAC:Message Authentication Code)をMAC処理部492へ通知し、MACの検証結果を受け取る。外部通信部490は、復号した配信データから更新用不正検知ルールと付属情報(対象車種、バス種別、バージョン情報等)と抽出し、更新判定部494へ通知する。また、更新判定部494から受け取った不正検知ルールの更新結果等に基づき、更新結果データを生成し、MAC処理部492へ通知し、生成したMACを含んだ更新結果データを受け取る。
図18に配信データフォーマットの一例を、
図19に配信データの一例を示す。また、
図20に更新結果データフォーマットの一例を、
図21に更新結果データの一例を示す。サーバ500から配信される配信データには暗号処理が施されている。ここで、サーバ500が施す暗号処理は、例えば、暗号化、検証用データの付加等である。これに対して、暗復号処理部491及びMAC処理部492は、配信データについてサーバ500等で実行された暗号処理に呼応する暗号処理(例えば暗号化に呼応する復号、検証用データの付加に呼応する検証)を実行する。
【0084】
暗復号処理部491は、外部通信部490から通知される暗号化された配信データを、鍵保持部493から取得する鍵を用いて復号し、復号した配信データを外部通信部490へ通知する。
【0085】
MAC処理部492は、外部通信部490から通知される配信データにおけるMACを、鍵保持部493から取得する鍵を用いて検証し、検証結果を外部通信部490へ通知する。またMAC処理部492は、外部通信部490から通知される更新結果データに基づいて、鍵保持部493から取得する鍵を用いてMACを生成してその更新結果データにMACを含ませて外部通信部490へ通知する。
【0086】
鍵保持部493は、暗復号処理部491とMAC処理部492とが暗号処理において利用する鍵を管理する。
【0087】
更新判定部494は、外部通信部490から更新用不正検知ルールと付属情報とを受け取り、バス種別保持部496から取得したバス種別と、車両No.保持部495が保持する車種と、不正検知ルール保持部481が保持する不正検知ルールに対応するバージョン情報とに基づいて、不正検知ルール保持部481が保持する不正検知ルールを更新する必要があるか否かを判別する。更新判定部494は、更新する必要があると判別した場合には、不正検知ルール保持部481へ通知し、不正検知ルールの更新を行う。また、更新結果と車両No.保持部495から取得した車両No.とを外部通信部490へ通知する。
【0088】
車両No.保持部495は、不正検知ECU400aを搭載している車両の識別子を示す車両No.(車両Number)とその車両の車種(車両種別)とを保持する。
【0089】
バス種別保持部496は、不正検知ECU400aが接続されるバスの種別を保持する。バスの種別には、例えば「駆動系」、「ボディ系」、「安全系」等がある。「駆動系」は、例えばエンジン、モータ、燃料、電池、トランスミッション等の制御といった車両の走行に関連する駆動系機能を有するECUが接続されるバスの種別である。「ボディ系」は、例えばドアロック、エアコン、ライト、ウィンカー等といった車両の装備の制御に関連するボディ系機能を有するECUが接続されるバスの種別である。「安全系」は、例えば、自動ブレーキ、車線維持機能、車間距離維持機能、衝突防止機能、エアバッグ等といった自動的に安全で快適な運転を実現するための安全機能を有するECUが接続されるバスの種別である。例えば車両の走行に関連する、エンジンに係るECU100a及びブレーキに係るECU100bが接続されるバス200aは、「駆動系」のバスである。また、車両の装備の制御に関連する、ドア開閉センサに係るECU100c及び窓開閉センサに係るECU100dが接続されるバス200bは、「ボディ系」のバスである。また、衝突防止機能に関連するコーナーセンサに係るECU100eが接続されるバス200cは、「安全系」のバスである。
【0090】
[1.15 不正検知ECU400aにおける不正検知ルール例]
図15は、不正検知ECU400aが保持する不正検知ルール及びバージョン情報の一例を示す。同図に示す不正検知ルール(正規のメッセージIDを列挙したリスト)では、不正検知ECU400aが接続するバス200aで送信されるフレーム(メッセージ)は、メッセージIDが「1」、「2」及び「3」のいずれにも該当しないと不正なフレームであることを示す。また、バージョン情報は、この不正検知ルールのバージョン(Ver.)が1.0であることを示す。
【0091】
[1.16 不正検知ECU400bにおける不正検知ルール例]
図16は、不正検知ECU400bが保持する不正検知ルール及びバージョン情報の一例を示す。同図に示す不正検知ルールでは、不正検知ECU400bが接続するバス200bで送信されるフレームは、メッセージIDが「1」、「2」、「3」及び「4」のいずれにも該当しないと不正なフレームであることを示す。また、バージョン情報は、この不正検知ルールのバージョン(Ver.)が1.0であることを示す。
【0092】
[1.17 不正検知ECU400cにおける不正検知ルール例]
図17は、不正検知ECU400cが保持する不正検知ルール及びバージョン情報の一例を示す。同図に示す不正検知ルールでは、不正検知ECU400cが接続するバス200cで送信されるフレームは、メッセージIDが「1」、「2」、「3」、「4」及び「5」のいずれにも該当しないと不正なフレームであることを示す。また、バージョン情報は、この不正検知ルールのバージョン(Ver.)が1.0であることを示す。
【0093】
[1.18 配信データフォーマット例]
図18は、サーバ500から不正検知ECU400a~400cに対して送信される配信データについてのフォーマット(配信データフォーマット)の一例を示す。同図の配信データフォーマットは、配信データが対象車種、不正検知ルールリスト、MACを含んで構成されることを示す。対象車種は、配信データの不正検知ルールリストに含まれる更新用不正検知ルール(新しい不正検知ルール)を更新すべき不正検知ECUを搭載する車両の車種(車両種別)を示す。不正検知ルールリストは、対象車種の車両における車載ネットワークに含まれるバスの種別毎に対する各不正検知ルール(更新用不正検知ルール)を含む。
【0094】
[1.19 配信データ例]
図19は、配信データの内容についての一例を示す。同図の例では、配信データが、車種Aに対するものであり、対象バス種別(バス種別情報)が示す「駆動系」、「ボディ系」及び「安全系」のそれぞれのバスでの不正なフレームの検知に用いられる不正検知ルール(更新用不正検知ルール)とそのバージョン情報(不正検知ルールVer.)とを表している。このように配信データは、1以上(
図19の例では複数)の更新用不正検知ルールと、付属情報(対象車種、バス種別、バージョン情報等)とを含んで構成される。
【0095】
[1.20 更新結果データフォーマット例]
図20は、不正検知ECU400a~400cからサーバ500へと送信される更新結果データについてのフォーマット(更新結果データフォーマット)の一例を示す。同図の更新結果データフォーマットは、更新結果データが、対象車種、車両No.、バス種別、更新後不正検知ルールVer.(バージョン)、MACを含んで構成されることを示す。更新結果データの対象車種及び車両No.は、更新結果データの送信元の不正検知ECUを搭載している車両の車種とその車両の車両No.とを示す。また、更新結果データのバス種別は、更新結果データの送信元の不正検知ECUが接続されているバスのバス種別(つまりバス種別保持部496が保持しているバス種別)を示す。更新結果データの更新後不正検知ルールVer.は、更新結果データの送信元の不正検知ECUにおいて更新した不正検知ルールに対応するバージョン情報が示すバージョンである。
【0096】
[1.21 更新結果データ例]
図21は、更新結果データの内容についての一例を示す。同図の例は、「車種Aの車両No.00000001における駆動系のバスに接続された不正検知ECUが配信データを受け取った結果として、不正検知ルールをバージョン2.0へと更新した」という旨を示す。もし、不正検知ECUが配信データを受け取った結果として、更新を行わなかった場合には、例えば、更新結果データにおける不正検知ルールVer.を「-」(なし)を示すようにして更新しない旨を表すことができる。
【0097】
[1.22 サーバ500の構成]
図22は、サーバ500の構成図である。サーバ500は、車載ネットワークシステム10が搭載される車両の外部に所在するコンピュータである。サーバ500は、複数の車両それぞれに車載ネットワークシステム10が搭載されていることを前提として、各車両(つまり車載ネットワークシステム)に対して不正検知ルール(更新用不正検知ルール)を含む配信データを送信し、各車両における不正検知ルールの更新の状況を管理する。
【0098】
サーバ500は、
図22に示すように、通信部510と、配信データ管理部520と、不正検知ルール保持部530と、暗復号処理部591と、MAC処理部592と、鍵保持部593と、更新結果管理部540と、更新結果表保持部550とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、サーバ500におけるハードディスク、メモリ等の記憶媒体、メモリに格納された制御プログラムを実行するプロセッサ、通信回路等により実現される。
【0099】
通信部510は、配信データ管理部520から通知された配信データを、ネットワーク600を介して不正検知ECU400a~400cへ送信する。また、不正検知ECU400a~400cからの更新結果データを受信し、更新結果管理部540へ通知する。
【0100】
配信データ管理部520は、不正検知ルール保持部530から、最新バージョンの不正検知ルールとその不正検知ルールに対応する付属情報(対象車種、バス種別、バージョン情報等)とを取得する。配信データ管理部520は、取得した不正検知ルール及び付属情報をMAC処理部592へ通知してMACを取得し、取得した不正検知ルール、付属情報及びMACを暗復号処理部591へ通知して、暗号化した配信データ(
図18、
図19参照)を取得する。これにより、配信データは、検証用のMACの付加、及び、暗号化という暗号処理が施されたものとなる。
【0101】
不正検知ルール保持部530は、最新バージョンの不正検知ルール(つまり各車載ネットワークシステム10において更新のために用いられる更新用不正検知ルール)とその不正検知ルールに対応する付属情報を記録媒体等に保持する。なお、不正検知ルール及び付属情報は、サーバ500の管理者、運用者等の操作により、或いは他のコンピュータから受信することにより、不正検知ルール保持部530の記録媒体等に格納される。なお、不正検知ルールを定める者は、車種別の通信仕様の変更に伴って随時不正検知ルールの更新を行い得る。また、特定の車両やバス種別毎に異なる不正検知ルールを生成し得る。
【0102】
暗復号処理部591は、鍵保持部593から取得した鍵を用いて配信データ管理部520から通知されるデータを暗号化し、配信データ管理部520へ暗号化された配信データを通知する。
【0103】
MAC処理部592は、鍵保持部593から取得した鍵を用いて配信データ管理部520から通知されるデータを用いてMACを生成し、生成したMACを配信データ管理部520へ通知する。また、更新結果管理部540から通知された更新結果データに含まれるMACを鍵保持部593から取得する鍵を用いて検証して、その検証結果を更新結果管理部540へ通知する。
【0104】
鍵保持部593は、暗復号処理部591とMAC処理部592とが暗号処理において利用する鍵を管理する。
【0105】
更新結果管理部540は、通信部510から通知された更新結果データ(
図20、
図21参照)及び通知を受けた日時に基づいて、更新結果表保持部550で保持する更新結果表を更新する。
【0106】
更新結果表保持部550は、不正検知ECU400a~400cの更新結果表を保持する。
図23に、更新結果表の一例を示す。
【0107】
[1.23 更新結果表]
図23は、サーバ500が保持する更新結果表の一例を示す。同図に例示する更新結果表では、車種Aの車両No.00000001の車両における各種のバスに接続された不正検知ECU毎の不正検知ルールの更新後のバージョンと最終更新日時とを記載して管理している。最終更新日時としては例えば、更新結果管理部540が更新結果データの通知を受けた日時を設定し得る。なお、同図に例示する更新結果表では、車種Aの車両No.00000001の車両についての更新結果に係るデータを示したが、サーバ500が複数の車両の不正検知ECUに配信データを送信することにより、更新結果表は、車種或いは車両No.が相異なる複数の車両についての不正検知ルールの更新結果に係るデータを含み得る。
【0108】
[1.24 不正フレームの検知に係るシーケンス]
以下、車載ネットワークシステム10のバス200aに不正なECUが接続された場合における、バス200aに接続された不正検知ECU400a、ECU100a、ECU100b、ゲートウェイ300a等の動作について説明する。
【0109】
図24は、不正検知ECU400aが不正なフレーム(メッセージ)を検知して、他のECUによりその不正なフレームに対応した処理がなされることを阻止する動作例を示すシーケンス図である。同図では、不正なECUが、バス200aにメッセージIDが「4」でデータフィールド(データ)が「255(0xFF)」となるデータフレームを送信する場合の例を示している。各シーケンスは、各種装置における各処理手順(ステップ)を示す。
【0110】
まず、不正なECUは、メッセージIDが「4」、データが「255(0xFF)」となるデータフレームの送信を開始する(ステップS1001)。フレームを構成する各ビットの値は、上述したデータフレームフォーマットに従ってSOF、IDフィールド(メッセージID)といった順に逐次バス200a上に送出される。
【0111】
不正なECUがIDフィールド(メッセージID)までをバス200aに送出し終えたときにおいて、不正検知ECU400a、ECU100a、ECU100b及びゲートウェイ300aはそれぞれメッセージIDを受信する(ステップS1002)。
【0112】
ECU100a、ECU100b及びゲートウェイ300aはそれぞれ、保持している受信IDリストを用いてメッセージIDをチェックする(ステップS1003)。このとき、不正検知ECU400aは、保持している不正検知ルールとしてのメッセージIDのリスト(ホワイトリスト)を用いてメッセージIDをチェックする(ステップS1004)。即ち、不正検知ECU400aは、不正検知ルールを基準として、送信されたフレームにおけるIDフィールドの内容が、ルールに適合しているか否かの判定を行う。この判定では、不正検知ルールとしてのメッセージIDのリストに掲載されていない場合にはルールに適合しない(つまり不正なメッセージIDであり、送信されたフレームが不正なフレームである)と判定する。
【0113】
ステップS1003において、ECU100a及びECU100bは、それぞれが保持している受信IDリストに「4」が含まれていないため(
図4参照)、受信を終了する。つまりこれ以上不正なECUが送信を継続するフレームの解釈をせずフレームに対応した処理を行わない。また、ステップS1003においてゲートウェイ300aは、保持している受信IDリストに「4」が含まれているため(
図6参照)、受信を継続する。また、ステップS1004において不正検知ECU400aは、保持している不正検知ルールとしてのメッセージIDのリスト(
図15参照)に「4」が含まれていないため、不正なメッセージIDであると判断して、続いてエラーフレームの発行準備を開始する(ステップS1005)。
【0114】
ステップS1003に続いて、ゲートウェイ300aはフレームの受信を継続する。例えば、不正検知ECU400aがエラーフレームの発行準備をしている間に、不正なECUからはバス200a上にIDフィールドより後の部分であるRTR、コントロールフィールド(IDE、r、DLC)が逐次送出され、続いてデータフィールドが1ビットずつ逐次送出される。ゲートウェイ300aはこのRTR、コントロールフィールド(IDE、r、DLC)を受信し、続いてデータフィールドの受信を開始する(ステップS1006)。
【0115】
次にエラーフレームの発行準備が終わって、不正検知ECU400aがエラーフレームを送信する(ステップS1007)。このエラーフレームの送信は、不正なフレームの最後尾が送信される前(例えばCRCシーケンスの最後尾が送信される前等)に行われる。この動作例においては、データフィールドの途中で行われる。このエラーフレームの送信が開始されることによりバス200aでは、不正なECUから送信中のフレームのデータフィールドの途中部分がエラーフレーム(優先されるドミナントのビット列)により上書きされることになる。
【0116】
ステップS1007において送信されたエラーフレームを受信したゲートウェイ300aは、データフィールドの受信途中で不正なECUが送信していたフレームの受信を中止する(ステップS1008)。つまり、ゲートウェイ300aは、不正なECUからのデータフィールドがエラーフレームで上書きされており、エラーフレームを検出するので、不正なECUが送信していたフレームの受信を継続しない。
【0117】
[1.25 不正検知ルールの更新に係るシーケンス]
図25及び
図26は、不正検知ルールの更新(アップデート)に係る動作例を示すシーケンス図である。サーバ500は各車両の各車載ネットワークシステム10における各不正検知ECUに対して更新用不正検知ルールを含む配信データを送信し得るが、ここでは、不正検知ECU400aが保持する不正検知ルールの更新に注目して説明する。
【0118】
まず、サーバ500において、最新の不正検知ルール(つまり車載ネットワークシステム10の不正検知ECUでの更新用となる不正検知ルール)及び付属情報を取得する(ステップS1101)。
【0119】
サーバ500は、取得した不正検知ルール及び付属情報について付加するためのMACを生成する(ステップS1102)。
【0120】
サーバ500は、不正検知ルール、付属情報及びMACにより所定の配信データフォーマットに従って配信データを構成し、配信データを暗号化する(ステップS1103)。
【0121】
続いてサーバ500は、暗号化した配信データを不正検知ECU400aに送信する(ステップS1104a)。これに呼応して、不正検知ECU400aは、外部通信部490により配信データ(詳しくは暗号化された配信データ)を受信する(ステップS1104b)。
【0122】
不正検知ECU400aの外部通信部490は、暗号化された配信データを暗復号処理部491に復号させる(ステップS1105)。
【0123】
次に不正検知ECU400aの外部通信部490は、配信データに含まれるMACをMAC処理部492に検証させる(ステップS1106)。このMACの検証に成功した場合には、不正検知ECU400aの外部通信部490は、受信した配信データの内容である不正検知ルール(更新用不正検知ルール)と付属情報(対象車種、バス種別、バージョン情報等)とを更新判定部494に伝える。
【0124】
ステップS1106でのMACの検証が成功した場合に、不正検知ECU400aの更新判定部494は、不正検知ECU400aが接続されているバス200aに係るバス種別をバス種別保持部496から取得する(ステップS1107)。また、更新判定部494は、車両No.保持部495から車種を取得する。
【0125】
次に不正検知ECU400aの更新判定部494は、不正検知ルール保持部481が保持する不正検知ルールに対応するバージョン情報を取得する(ステップS1108)。
【0126】
続いて不正検知ECU400aの更新判定部494は、配信データに応じて不正検知ルールを更新する必要があるか否かについて判別する(ステップS1109)。具体的には、更新判定部494は、この判別を、バス種別保持部496から取得したバス種別、車両No.保持部495から取得した車種、及び、不正検知ルール保持部481から取得したバージョン情報が示すバージョンのそれぞれと、配信データに含まれた付属情報が示すバス種別、車種及びバージョン(つまり
図19の対象車種、バス種別、不正検知ルールVer.)のそれぞれを比較することにより行う。更新判定部494は、車種及びバス種別が一致し、かつ、配信データの内容である更新用不正検知ルールのバージョンが、不正検知ECU400aが既に用いている不正検知ルールのバージョンより新しいバージョンである場合に限って、更新する必要があると判別する。
【0127】
ステップS1109で更新する必要があると判別した場合には、不正検知ECU400aの更新判定部494は、不正検知ルール保持部481に保持されている不正検知ルールを、配信データに含まれる不正検知ルール(更新用不正検知ルール)へと更新する(ステップS1110)。即ち、不正検知ECU400aは、サーバ500から受信した配信データから、接続されているバスの種別に該当するバス種別情報(対象バス種別)に対応する更新用不正検知ルールを抽出して、不正検知ルール保持部481が保持していた不正検知ルールを、抽出した更新用不正検知ルールへと更新する。
【0128】
ステップS1110で更新した場合、ステップS1106でMACの検証に失敗した場合、或いは、ステップS1109で更新する必要がないと判別した場合において、更新判定部494は、車両No.保持部495から車両No.を取得し(ステップS1111)、取得した車両No.と、更新結果を示す更新結果データとを外部通信部490に伝える。更新結果データ(
図21参照)は、例えば、不正検知ルールVer.により、更新をした場合には更新後の不正検知ルールのバージョンを示し、更新しなかった場合には、更新なしの旨を示す。
【0129】
次に外部通信部490では、更新結果に基づいて更新結果データを生成して、その更新結果データに基づきMAC処理部492にMACを生成させて、更新結果データにMACを含める(ステップS1112)。そして外部通信部490は、更新結果データをサーバ500へと送信する(ステップS1113a)。
【0130】
サーバ500では、更新結果データを受信し(ステップS1113b)、更新結果データにおけるMACの検証を行う(ステップS1114)。
【0131】
サーバ500は、MACの検証に成功した場合に、更新結果データに基づいて更新結果表(
図23参照)を更新する(ステップS1115)。ステップS1114でMACの検証に失敗した場合にはサーバ500は、更新結果表の更新を行わない。
【0132】
[1.26 実施の形態1の効果]
実施の形態1に係る車載ネットワークシステム10では、バスで送信されるフレームが不正か否かを不正検知ECUにおいて判定する基準となる不正検知ルールを、更新するか否かを判別するため、必要に応じて不正検知ルールを更新することが可能になる。また、更新するか否かを不正検知ECUが接続されているバスの種別に応じて判別するため、バスの種別毎に独立して不正検知ルールの更新が実現できる。また、更新用となる不正検知ルールを配信するサーバは、一律に各バス種別に対応する最新のバージョンの不正検知ルールを配信できるため、個別に更新内容を選定して送信するよりも、処理負荷が低減され得る。また、更新結果データをサーバに通知するので、サーバにおいて、更新結果を管理
して必要に応じて配信データを再送する等の制御が可能になる。
【0133】
[1.27 実施の形態1の変形例]
以下、上述した車載ネットワークシステム10において、不正検知ECU400a~cを、その不正検知ECU400a~cを一部変形してなる不正検知ECU1400a~cに、置き換えた例について説明する。
【0134】
不正検知ECU400aを一部変形してなる不正検知ECU1400aでは、不正検知ルールを更新するか否かの判別において、更に、不正検知ECU1400aを搭載している車両についての車両状態(例えば走行中、停車中等といった走行状態等)を参照する。これにより、不正検知ECU1400aは、車両状態が例えば安全性の高い所定状態(例えば停車中或いは駐車中等)でなければ不正検知ルールの更新を行わない。
【0135】
[1.28 不正検知ECU1400aの構成]
図27は、不正検知ECU1400aの構成図である。不正検知ECU1400aは、フレーム送受信部410と、フレーム解釈部420と、フレーム生成部460と、不正検知処理部480と、不正検知ルール保持部481と、外部通信部490と、暗復号処理部491と、MAC処理部492と、鍵保持部493と、更新判定部1494と、車両No.保持部495と、バス種別保持部496と、車両状態保持部1497と、車両状態判定部1498とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、不正検知ECU1400aにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。なお、不正検知ECU400bを置き換える不正検知ECU1400b、及び、不正検知ECU400cを置き換える不正検知ECU1400cも基本的に同様の構成を備えるが、不正検知ルール保持部481の保持内容(不正検知ルール及びバージョン情報)が互いに異なり得る。実施の形態1(
図14)と同一の構成要素については、同一の符号を付して、説明を省略する。
【0136】
更新判定部1494は、外部通信部490から更新用不正検知ルールと付属情報とを受け取り、バス種別保持部496から取得したバス種別と、車両No.保持部495が保持する車種と、不正検知ルール保持部481が保持する不正検知ルールに対応するバージョン情報と、車両状態保持部1497が保持する車両状態とに基づいて、不正検知ルール保持部481が保持する不正検知ルールを更新する必要があるか否かを判別する。更新判定部1494は、更新する必要があると判別した場合には、不正検知ルール保持部481へ通知し、不正検知ルールの更新を行う。また、更新結果と車両No.保持部495から取得した車両No.とを外部通信部490へ通知する。
【0137】
車両状態保持部1497は、車両状態判定部1498から車両状態を受け取って保持する。車両状態としては、車両の走行に関連する状態の他、車両において測定等により特定可能な各種状態を用いることができる。ここでは、車両状態は、「走行中」及び「停車中」のいずれかであるものとして説明する。
【0138】
車両状態判定部1498は、車速センサ等のセンサ(不図示)により測定された測定値等を取得することで現在の車両状態を判定して、判定結果としての車両状態を車両状態保持部1497に伝える。なお、車両状態判定部1498は、車速センサ等のセンサを含んで構成されても良いし、外部の車速センサ等のセンサと専用の通信路で通信しても良いし、その外部のセンサに接続されたECUからバス200a経由で測定値等を受信しても良い。
【0139】
[1.29 不正検知ルールの更新に係るシーケンス]
図28及び
図29は、不正検知ルールの更新(アップデート)に係る動作例を示すシーケンス図である。サーバ500は各車両の各車載ネットワークシステム10における各不正検知ECUに対して更新用不正検知ルールを含む配信データを送信し得るが、ここでは、不正検知ECU1400aが保持する不正検知ルールの更新に注目して説明する。また、実施の形態1で示したステップ(
図25、
図26参照)と同じステップについては、同一の符号を付して、ここでの説明を適宜省略する。
【0140】
サーバ500が、配信データを不正検知ECU1400aに送信し(ステップS1101~S1104a)、不正検知ECU1400aは、外部通信部490から、MACの検証に成功した配信データの内容である不正検知ルール(更新用不正検知ルール)と付属情報(対象車種、バス種別、バージョン情報等)とを更新判定部1494に伝える(ステップS1104b~S1106)。
【0141】
次に不正検知ECU1400aの更新判定部1494は、不正検知ECU1400aが接続されているバス200aに係るバス種別をバス種別保持部496から取得し、車両No.保持部495から車種を取得し、不正検知ルール保持部481から不正検知ルールに対応するバージョン情報を取得する(ステップS1107、S1108)。そして、更新判定部1494は、車両状態保持部1497から車両状態を取得する(ステップS1208)。
【0142】
続いて不正検知ECU1400aの更新判定部1494は、配信データに応じて不正検知ルールを更新する必要があるか否かについて判別する(ステップS1209)。具体的には、更新判定部1494は、この判別を、バス種別保持部496から取得したバス種別、車両No.保持部495から取得した車種、及び、不正検知ルール保持部481から取得したバージョン情報が示すバージョンのそれぞれと、配信データに含まれた付属情報が示すバス種別、車種及びバージョンのそれぞれを比較し、更に、車両状態保持部1497から取得した車両状態が所定状態(ここでは停車中とする。)であるかどうかを確認することにより行う。更新判定部1494は、車種及びバス種別が一致し、配信データの内容である更新用不正検知ルールのバージョンが、不正検知ECU1400aが既に用いている不正検知ルールのバージョンより新しいバージョンであり、かつ、車両状態が停車中である場合に限って、更新する必要があると判別する。なお、走行に関連する駆動系のバスに接続された不正検知ECUでは、停車中でないと不正検知ルールの更新を行わないが、駆動系以外のバスに接続された不正検知ECUでは走行中に不正検知ルールの更新を行い得るといったように、バス種別に応じて車両状態についての更新の要件となる所定状態を異ならせても良い。
【0143】
ステップS1209で更新する必要があると判別した場合には、不正検知ECU1400aの更新判定部1494は、不正検知ルール保持部481に保持されている不正検知ルールを、配信データに含まれる不正検知ルール(更新用不正検知ルール)へと更新する(ステップS1110)。
【0144】
[1.30 実施の形態1の変形例の効果]
実施の形態1の変形例1に係る車載ネットワークシステム10では、バスで送信されるフレームが不正か否かを不正検知ECUにおいて判定する基準となる不正検知ルールを更新するか否かを、不正検知ECUが接続されているバスの種別、不正検知ECUを搭載する車両の車両状態等に応じて判別する。このため、車両状態が例えば安全性が高い所定状態である場合に限って不正検知ルールの更新を行うこと等が可能となる。
【0145】
(実施の形態2)
以下、実施の形態1で示した車載ネットワークシステム10を一部変形してなる車載ネットワークシステム20について説明する。
【0146】
実施の形態1に係る車載ネットワークシステム10においては、不正検知ECU400a~400cのそれぞれが、サーバ500と通信することにより更新用不正検知ルール等を取得して、バス上での不正なフレームの検査に用いる不正検知ルールを更新する機能を有する。これに対して、本実施の形態に係る車載ネットワークシステム20では、ヘッドユニットという一種のECUが外部のサーバ500との通信機能を担い、各不正検知ECUは、ヘッドユニットを経由して更新用不正検知ルール等を取得することにより、不正検知機能を更新する。
【0147】
[2.1 車載ネットワークシステム20の全体構成]
図30は、車載ネットワークシステム20の全体構成を示す図である。車載ネットワークシステム20は、CANプロトコルに従って通信するネットワーク通信システムの一例であり、制御装置、センサ等の各種機器が搭載された自動車におけるネットワーク通信システムである。車載ネットワークシステム20は、バス200a~200dと、不正検知ECU2400a~2400c、ゲートウェイ2300a、2300b、ヘッドユニット800、及び、各種機器に接続されたECU100a~100e等のECUといったバスに接続された各ノードとを含んで構成される。また
図30では、車載ネットワークシステム20におけるヘッドユニット800と無線通信する外部のネットワーク600及びそのネットワーク600と通信可能に接続されたサーバ2500とを付記している。実施の形態1に係る車載ネットワークシステム10(
図1参照)と同一の構成要素については、同一の符号を付して、ここでの説明を省略する。また、車載ネットワークシステム20は、ここで特に説明しない点については車載ネットワークシステム10と同様である。
【0148】
ゲートウェイ2300aは、不正検知ECU2400a、ECU100a及びECU100bがつながるバス200aと、不正検知ECU2400b、ECU100c及びECU100dがつながるバス200bと、ヘッドユニット800がつながるバス200dとに接続している。ゲートウェイ2300bは、不正検知ECU2400b、ECU100c及びECU100dがつながるバス200bと、不正検知ECU2400c及びECU100eがつながるバス200cとに接続している。ゲートウェイ2300a、2300bは、あるバスから受信したフレームを他のバスに転送する機能を有する。また受信したフレームを転送するかしないかを接続されたバス間毎に切り替えることも可能である。ゲートウェイ2300a、2300bも一種のECUである。
【0149】
不正検知ECU2400a~2400cは、実施の形態1で示した不正検知ECU400a~400cを一部変形したものであり、自ECUが接続されたバス上に現れるフレームを監視して不正なフレームを検知した場合には、エラーフレームを送信する機能を有する(
図24参照)。従って、不正検知ECU2400a~2400cは、不正検知ECU400a~400cと同様に、バス上で不正なフレームが送信された場合に、他のECUによりその不正なフレームに対応した処理がなされることを阻止する。
【0150】
ヘッドユニット800は、車両用通信装置であり、例えば、自動車のインストルメントパネル(インパネ)等に設けられ、運転者(ユーザ)に視認されるための情報を表示する液晶ディスプレイ(LCD:Liquid Crystal Display)等の表示装置、運転者の操作を受け付ける入力手段等を備える一種のECUである。
【0151】
サーバ2500は、車載ネットワークシステム20における不正検知ECU2400a~2400cの不正検知機能の基礎となる不正検知ルールを更新するために配信データを、ネットワーク600を介してヘッドユニット800へと送信する機能を有する。サーバ2500とヘッドユニット800との間での通信方式はいかなる方式を用いても良い。
【0152】
[2.2 ヘッドユニット800の構成]
図31は、ヘッドユニット800の構成図である。ヘッドユニット800は、フレーム送受信部810と、フレーム解釈部820と、受信ID判断部830と、受信IDリスト保持部840と、フレーム処理部850と、フレーム生成部860と、表示制御部853と、更新管理部854と、更新結果表保持部855、外部通信部890と、暗復号処理部891と、MAC処理部892と、鍵保持部893とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、ヘッドユニット800における通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。
【0153】
フレーム送受信部810は、バス200dに対して、CANのプロトコルに従ったフレームを送受信する。即ち、フレーム送受信部810は、バス200dからフレームを1bitずつ受信し、フレーム解釈部820に転送する。また、フレーム生成部860より通知を受けたフレームの内容をバス200dに送信する。
【0154】
フレーム解釈部820は、フレーム送受信部810よりフレームの値を受け取り、CANプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。IDフィールドと判断した値は、受信ID判断部830へ転送する。また、フレーム解釈部820は、受信ID判断部830から通知される判定結果に応じて、IDフィールドの値と、IDフィールド以降に現れるデータフィールドとを、フレーム処理部850へ転送するか、その判定結果を受けた以降においてフレームの受信を中止する(つまりそのフレームとしての解釈を中止する)かを決定する。また、フレーム解釈部820は、CANプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部860へ通知する。また、フレーム解釈部820は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。
【0155】
受信ID判断部830は、フレーム解釈部820から通知されるIDフィールドの値を受け取り、受信IDリスト保持部840が保持しているメッセージIDのリストに従い、そのIDフィールド以降のフレームの各フィールドを受信するかどうかの判定を行う。この判定結果を、受信ID判断部830は、フレーム解釈部820へ通知する。
【0156】
受信IDリスト保持部840は、ヘッドユニット800が受信するID(メッセージID)のリストである受信IDリストを保持する。
図32に、ヘッドユニット800における受信IDリストの一例を示す。
【0157】
フレーム処理部850は、各ECUから送信され、受信したフレームのデータ(例えばエンジンに係るECU100aから得られた時速等)を表示できる形式に変換し、表示制御部853に通知する。また、フレーム処理部850は、不正検知ECU2400a~2400cから送信されたフレームに含まれる内部更新結果データ(後述)を更新管理部854へ通知する。
【0158】
表示制御部853は、フレーム処理部850から通知されたデータを表示する。
【0159】
フレーム生成部860は、フレーム解釈部820から通知されたエラーフレーム送信の要求に従い、エラーフレームを構成し、フレーム送受信部810へ通知する。また、更新管理部854からの指示に従ってデータフレームを構成し、フレーム送受信部810へ通知する。
【0160】
更新管理部854は、外部通信部890から受信した配信データに含まれる不正検知ルール(更新用不正検知ルール)及び付属情報(バス種別情報、バージョン情報等)をCANプロトコルに従った形式に変換して、フレーム生成部860に渡すことによりデータフレームを生成させる。なお、配信データに含まれる付属情報のうち、対象車種の情報については、例えば更新管理部854が、ヘッドユニット800を搭載している車両の車種と比較し、一致しない場合には配信データを破棄し得る。ここで、ヘッドユニット800が車載ネットワークシステム20におけるバスを介して不正検知ECU2400a~2400cへと配信するデータフレームを内部配信データと称する。内部配信データは、更新用不正検知ルール、バス種別及びバージョン情報を含む(
図33参照)。ここでは、内部配信データとして、「駆動系」のバス種別のバス200aに接続された不正検知ECU2400aが受信可能なように配信するデータフレームには、「0x0E0」という不正検知ルール更新用のメッセージIDを付し、「ボディ系」のバス種別のバス200bに接続された不正検知ECU2400bが受信可能なように配信するデータフレームには、「0x0E1」という不正検知ルール更新用のメッセージIDを付し、「安全系」のバス種別のバス200cに接続された不正検知ECU2400cが受信可能なように配信するデータフレームには、「0x0E2」という不正検知ルール更新用のメッセージIDを付すものとする。なお、不正検知ECU2400a~2400cは、それぞれが対応する不正検知ルール更新用のメッセージIDのデータフレームを受信して、内部配信データを取得することで、不正検知ルールを更新するか否かを判別して必要に応じて更新する。また、更新管理部854は、フレーム処理部850から受信した内部更新結果データに基づいて、更新結果表保持部855で保持する内部更新結果表を更新する。
【0161】
更新結果表保持部855は、不正検知ECU2400a~2400cからの内部更新結果データ(
図34参照)により構成される内部更新結果表を記憶媒体等に保持する。なお、内部更新結果表に基づいて、更新管理部854が、配信データに含まれる各種バス用の各不正検知ルールのうち、バージョン情報の点で更新が必要な不正検知ルールを選択することで、ヘッドユニット800から特定の不正検知ルールに係る内部配信データの送信を行っても良く、また、同様に更新失敗に際しての内部配信データの再送信を行っても良い。
【0162】
外部通信部890は、サーバ2500とネットワーク600を介して通信することで、不正検知ECU2400a~2400cにおける不正検知ルールを更新するための更新用不正検知ルール(新たな不正検知ルール)等を含む配信データを取得する。外部通信部890は、取得した配信データを暗復号処理部891へ送信し、復号した結果を取得する。また、復号した配信データにおける検証用データとしてのMACをMAC処理部892へ通知し、MACの検証結果を受け取る。外部通信部890は、復号した配信データから更新用不正検知ルールと付属情報(対象車種、バス種別情報、バージョン情報等)と抽出し、更新管理部854へ通知する。サーバ2500から配信される配信データには暗号処理が施されている。ここで、サーバ2500が施す暗号処理は、例えば、暗号化、検証用データの付加等である。これに対して、暗復号処理部891及びMAC処理部892は、配信データについてサーバ2500等で実行された暗号処理に呼応する暗号処理(例えば暗号化に呼応する復号、検証用データの付加に呼応する検証)を実行する。
【0163】
暗復号処理部891は、外部通信部890から通知される暗号化された配信データを、鍵保持部893から取得する鍵を用いて復号し、復号した配信データを外部通信部890へ通知する。
【0164】
MAC処理部892は、外部通信部890から通知される配信データにおけるMACを、鍵保持部893から取得する鍵を用いて検証し、検証結果を外部通信部890へ通知する。
【0165】
鍵保持部893は、暗復号処理部891とMAC処理部892とが暗号処理において利用する鍵を管理する。
【0166】
[2.3 ヘッドユニット800における受信IDリスト例]
図32は、ヘッドユニット800の受信IDリスト保持部840が保持する受信IDリストの一例を示す図である。同図に例示する受信IDリストは、ID(メッセージID)の値が「1」、「2」、「3」、「4」及び「5」の他に、「0x0F0」、「0x0F1」及び「0x0F2」のいずれかであるメッセージIDを含むフレームを選択的に受信して処理するために用いられる。ここでは、別々のバスに接続された不正検知ECU2400a~2400cとの通信のため、IDを区別している。例えば「0x0F0」というメッセージIDは、「駆動系」のバス種別のバス200aに接続された不正検知ECU2400aからの内部更新結果データを含むデータフレームを受信するために用いられる。また「0x0F1」というメッセージIDは、「ボディ系」のバス種別のバス200bに接続された不正検知ECU2400bからの内部更新結果データを含むデータフレームを受信するために用いられる。また「0x0F2」というメッセージIDは、「安全系」のバス種別のバス200cに接続された不正検知ECU2400cからの内部更新結果データを含むデータフレームを受信するために用いられる。
【0167】
[2.4 ヘッドユニット800が送信する内部配信データ]
図33は、ヘッドユニット800から不正検知ECU2400aが受信可能なように送信する内部配信データの一例を示す。同図は、データフレームのID(メッセージID)を「0x0E0」にしており、データフィールド内に不正検知ルール(更新用不正検知ルール)とバージョン情報とを含んでいる例を示している。この例では、バージョン情報が示すバージョンは「2.0」を意味し、不正検知ルールは、メッセージIDとして「1」、「2」、「3」及び「4」の4つを掲載したホワイトリストを示し、これらの4つのID以外を含むフレームが不正なフレームと判定されることを表している。
【0168】
[2.5 ヘッドユニット800が受信する内部更新結果データ]
図34は、不正検知ECU2400aからヘッドユニット800に通知する内部更新結果データの一例を示す。同図に例示する内部更新結果データは、駆動系のバスに接続された不正検知ECUが内部配信データを受け取った結果として、不正検知ルールをバージョン2.0へと更新した旨を表している。
【0169】
[2.6 ゲートウェイ2300a、2300bの構成]
ゲートウェイ2300aは、実施の形態1で示したゲートウェイ300a(
図12参照)と基本的に同様の機能を有する他、バス200dが接続され、転送ルール保持部352が保持する転送ルールの内容が異なる。ゲートウェイ2300bは、実施の形態1で示したゲートウェイ300bと基本的に同様の機能を有するが、転送ルール保持部352が保持する転送ルールの内容が異なる。ゲートウェイ2300a、2300bにおける転送ルールは、ヘッドユニット800から送信された内部配信データが、受信されるべき不正検知ECUに伝達されるように定められており、また、各不正検知ECUからの内部更新結果データがヘッドユニット800に伝達されるように定められている。
【0170】
[2.7 転送ルール例]
図35は、ゲートウェイ2300aが保持する転送ルールの一例を示す。この転送ルールは、転送元のバスと転送先のバスと転送対象のID(メッセージID)とを対応付けている。
図35中の「*」は、メッセージIDにかかわらずフレームの転送がなされることを表している。
図35の例は、バス200aから受信するフレームはメッセージIDにかかわらず、バス200b及びバス200dに転送するように設定されていることを示している。また、バス200bから受信するフレームのうち、バス200dには全てのフレームが転送されるが、バス200aにはメッセージIDが「3」であるフレームのみが転送されるように設定されていることを示している。また、バス200dから受信されるフレームは、「駆動系」のバス200aにはメッセージIDが「0xE0」であるフレーム(内部配信データ)が転送され、ゲートウェイ2300bを経由して「安全系」のバス200cへの伝達経路ともなる「ボディ系」のバス200bにはメッセージIDが「0xE1」及び「0xE2」であるフレーム(内部配信データ)が転送されるように設定されていることを示している。
【0171】
[2.8 不正検知ECU2400aの構成]
図36は、不正検知ECU2400aの構成図である。不正検知ECU2400aは、フレーム送受信部410と、フレーム解釈部2420と、フレーム処理部2450と、フレーム生成部2460と、不正検知処理部480と、不正検知ルール保持部481と、更新判定部2494と、バス種別保持部496とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、不正検知ECU2400aにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。なお、不正検知ECU2400b及び不正検知ECU2400cも基本的に同様の構成を備えるが、不正検知ルール保持部481の保持内容(不正検知ルール及びバージョン情報)と、フレーム生成部2460が生成する内部更新結果データとしてのデータフレームに含ませるメッセージIDと、フレーム解釈部2420がフレーム処理部2450に通知する内部配信データを他のデータフレームと区別するためのメッセージIDとが互いに異なり得る。不正検知ECU2400aの構成要素のうち、実施の形態1で示した不正検知ECU400aと同一の構成要素については、同一の符号を付して、説明を省略する。
【0172】
フレーム解釈部2420は、フレーム送受信部410よりフレームの値を受け取り、CANプロトコルにおける各フィールドにマッピングするよう解釈を行う。IDフィールドと判断した値は不正検知処理部480へ転送する。また、内部配信データについての不正検知ルール更新用のメッセージID「0x0E0」を含むフレームのデータの内容についてはフレーム処理部2450へ通知する。また、フレーム解釈部2420は、CANプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するように、フレーム生成部2460へ通知する。また、フレーム解釈部2420は、エラーフレームを受信した場合、受信中のフレームに対し、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。
【0173】
フレーム生成部2460は、フレーム解釈部2420又は不正検知処理部480から通知されたエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部410へ通知して送信させる。また、フレーム生成部2460は、更新判定部2494から不正検知ルールの更新結果が通知された場合は、その更新結果に応じて内部更新結果データとしてのメッセージIDが「0xF0」であるデータフレームを構成し、フレーム送受信部410へ通知して送信させる。
【0174】
フレーム処理部2450は、受信した内部配信データから不正検知ルール(更新用不正検知ルール)と付属情報(バス種別を示すバス種別情報、及び、バージョン情報)とを抽出し、更新判定部2494へ通知する。
【0175】
不正検知ルール保持部481は、不正検知ルールとして、バス200aを送信されるフレームに含まれるメッセージIDを規定したリストを保持し、その不正検知ルールについてのバージョンを示すバージョン情報を保持する(
図37参照)。また、不正検知ルール保持部481は、更新判定部2494からの新たな不正検知ルール(更新用不正検知ルール)の通知に応じて、更新用不正検知ルールで先に保持していた不正検知ルールを更新し、更新した結果を更新判定部2494へ通知する。
【0176】
更新判定部2494は、フレーム処理部2450から更新用不正検知ルール、バス種別を示すバス種別情報及びバージョン情報を受け取り、バス種別保持部496から取得したバス種別と、不正検知ルール保持部481が保持する不正検知ルールに対応するバージョン情報とに基づいて、不正検知ルール保持部481が保持する不正検知ルールを更新する必要があるか否かを判別する。更新判定部2494は、更新する必要があると判別した場合には、不正検知ルール保持部481へ通知し、不正検知ルールの更新を行う。また、更新結果をフレーム生成部2460へ通知する。
【0177】
[2.9 不正検知ECU2400aにおける不正検知ルール例]
図37は、不正検知ECU2400aが保持する不正検知ルール及びバージョン情報の一例を示す。同図に示す不正検知ルール(正規のメッセージIDを列挙したリスト)では、不正検知ECU2400aが接続するバス200aで送信されるフレーム(メッセージ)は、メッセージIDが「1」、「2」、「3」、「0x0E0」及び「0x0F0」のいずれにも該当しないと不正なフレームであることを示す。また、
図37に示すバージョン情報は、この不正検知ルールのバージョン(Ver.)が1.0であることを示す。
【0178】
[2.10 不正検知ECU2400bにおける不正検知ルール例]
図38は、不正検知ECU2400bが保持する不正検知ルール及びバージョン情報の一例を示す。同図に示す不正検知ルールでは、不正検知ECU2400bが接続するバス200bで送信されるフレームは、メッセージIDが「1」、「2」、「3」、「4」、「0x0E1」、「0x0E2」、「0x0F1」及び「0x0F2」のいずれにも該当しないと不正なフレームであることを示す。また、バージョン情報は、この不正検知ルールのバージョン(Ver.)が1.0であることを示す。
【0179】
[2.11 不正検知ECU2400cにおける不正検知ルール例]
図39は、不正検知ECU2400cが保持する不正検知ルール及びバージョン情報の一例を示す。同図に示す不正検知ルールでは、不正検知ECU2400cが接続するバス200cで送信されるフレームは、メッセージIDが「1」、「2」、「3」、「4」、「5」、「0x0E2」及び「0x0F2」のいずれにも該当しないと不正なフレームであることを示す。また、バージョン情報は、この不正検知ルールのバージョン(Ver.)が1.0であることを示す。
【0180】
[2.12 サーバ2500の構成]
図40は、サーバ2500の構成図を示す。サーバ2500は、実施の形態1で示したサーバ500(
図22参照)を一部変形したものであり、車載ネットワークシステム20が搭載される車両の外部に所在するコンピュータである。サーバ2500は、通信部2510と、配信データ管理部520と、不正検知ルール保持部530と、暗復号処理部591と、MAC処理部592と、鍵保持部593とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、サーバ2500におけるハードディスク、メモリ等の記憶媒体、メモリに格納された制御プログラムを実行するプロセッサ、通信回路等により実現される。なお、サーバ2500の構成要素のうち実施の形態1で示したサーバ500と同等の構成要素については、同じ符号を付して、説明を省略する。
【0181】
通信部2510は、配信データ管理部520から通知された配信データ(
図18、
図19参照)を、ネットワーク600を介してヘッドユニット800へ通知する。なお、サーバ2500は1台以上の各車両の各車載ネットワークシステム20におけるヘッドユニット800に対して更新用不正検知ルールを含む配信データを送信し得る。
【0182】
[2.13 内部更新結果表]
図41は、ヘッドユニット800が保持する内部更新結果表の一例を示す。同図に例示する内部更新結果表では、バス種別毎に、最終的な更新後の不正検知ルールについてのバージョンを記載して管理している。
【0183】
[2.14 不正検知ルールの更新に係るシーケンス]
図42及び
図43は、不正検知ルールの更新(アップデート)に係る動作例を示すシーケンス図である。実施の形態1における不正検知ルールの更新に係るシーケンス(
図25、
図26参照)と同様のステップについては、同一の符号を付して適宜説明を省略する。なお、実施の形態1に係るサーバ500による配信データの送信の宛先は不正検知ECU400a~400cであったが、サーバ2500による配信データの送信の宛先はヘッドユニット800であり、車載ネットワークシステム20においてヘッドユニット800が配信データに基づく内部配信データを不正検知ECU2400a~2400cへとバスを介して送信する。ここでは、ヘッドユニット800及び不正検知ECU2400aに注目して説明する。
【0184】
まず、サーバ2500が、配信データを構成して暗号化し(ステップS1101~S1103)、ヘッドユニット800に送信する(ステップS2104a)。これに呼応して、ヘッドユニット800は、外部通信部890により配信データ(詳しくは暗号化された配信データ)を受信する(ステップS2104b)。
【0185】
ヘッドユニット800の外部通信部890は、暗号化された配信データを暗復号処理部891に復号させる(ステップS2105)。
【0186】
次にヘッドユニット800の外部通信部890は、配信データに含まれるMACをMAC処理部892に検証させる(ステップS2106)。このMACの検証に失敗した場合には処理を終え、このMACの検証に成功した場合には、ヘッドユニット800の外部通信部890は、受信した配信データの内容である不正検知ルール(更新用不正検知ルール)と付属情報(対象車種、バス種別、バージョン情報等)とを更新管理部854に伝える。
【0187】
ヘッドユニット800の更新管理部854は、配信データに含まれる不正検知ルール(更新用不正検知ルール)及び付属情報(バス種別、バージョン情報等)をCANプロトコルに従った形式の内部配信データに変換し、これによりヘッドユニット800は、内部配信データを、バス200dを介して送信(ブロードキャスト)する(ステップS2107a)。更新用不正検知ルール、バス種別及びバージョン情報を含む内部配信データはゲートウェイ2300aを経由してバス200aに接続された不正検知ECU2400aに受信される(ステップS2107b)。
【0188】
次に不正検知ECU2400aの更新判定部2494は、不正検知ECU2400aが接続されているバス200aに係るバス種別をバス種別保持部496から取得し、不正検知ルール保持部481から不正検知ルールに対応するバージョン情報を取得する(ステップS1107、S1108)。
【0189】
続いて不正検知ECU2400aの更新判定部2494は、内部配信データに応じて不正検知ルールを更新する必要があるか否かについて判別する(ステップS1109)。具体的には、更新判定部2494は、この判別を、バス種別保持部496から取得したバス種別、及び、不正検知ルール保持部481から取得したバージョン情報のそれぞれと、内部配信データに含まれたバス種別及びバージョン情報のそれぞれを比較することにより行う。更新判定部1494は、バス種別が一致し、内部配信データの内容である更新用不正検知ルールのバージョンが、不正検知ECU2400aが既に用いている不正検知ルールのバージョンより新しいバージョンである場合に限って、更新する必要があると判別する。
【0190】
ステップS1109で更新する必要があると判別した場合には、不正検知ECU2400aの更新判定部2494は、不正検知ルール保持部481に保持されている不正検知ルールを、内部配信データに含まれる不正検知ルール(更新用不正検知ルール)へと更新する(ステップS1110)。
【0191】
ステップS1110で更新した場合、或いは、ステップS1109で更新する必要がないと判別した場合において、更新判定部2494が更新結果をフレーム生成部2460に通知することで、不正検知ECU2400aは、更新結果に応じて内部更新結果データとしてのメッセージIDが「0xF0」であるデータフレームを、バス200aを介して送信(ブロードキャスト)する(ステップS2110a)。内部更新結果データはゲートウェイ2300aを経由してバス200dに接続されたヘッドユニット800に受信される(ステップS2110b)。
【0192】
続いてヘッドユニット800は、受信した内部更新結果データに基づいて内部更新結果表を更新する(ステップS2115)。
【0193】
[2.15 実施の形態2の効果]
実施の形態2に係る車載ネットワークシステム20では、不正検知ECUにおける不正検知ルールをヘッドユニット経由で取得し、不正検知ECUがつながるバスの種別に応じて不正検知ルールの更新を行うかどうかを切り替えているので、更新に失敗した際の不正検知ルールの再送制御等が比較的容易になる。また、実施の形態1の場合に比べて、不正検知ルールの更新状態についてサーバで管理すべきデータが削減される。また、車載ネットワークシステム20において、1つのヘッドユニット800だけが外部との通信及び暗号処理を行うため個々の不正検知ECUの処理負荷が削減されるので、不正検知ECUを比較的少ないリソースで構成することが可能となる。
【0194】
(他の実施の形態)
以上のように、本発明に係る技術の例示として実施の形態1、2を説明した。しかしながら、本発明に係る技術は、これに限定されず、適宜、変更、置き換え、付加、省略等を行った実施の形態にも適用可能である。例えば、以下のような変形例も本発明の一実施態様に含まれる。
【0195】
(1)上記実施の形態では、不正検知機能をアップデート(更新)するための配信データを送信する外部装置としてのサーバを示したが、この配信データに相当する情報を、車載ネットワークにおける、OBD2(On-Board Diagnostics2)と呼ばれる診断ポート(外部ツール接続用のインタフェース)から接続される外部装置である外部ツール(所謂診断ツール等)から送信しても良い。また、外部ツールを個々の不正検知ECUに接続して外部ツールから配信データに相当する情報を入力しても良い。また、実施の形態2で示したヘッドユニット800における内部更新結果表の内容を、診断ポートに接続した外部ツールが取得できるようにしても良い。なお、ヘッドユニット800は、ユーザ操作に応じて内部更新結果表の内容を表示しても良い。
【0196】
(2)上記実施の形態では、不正検知ルールとして正規のIDを列挙したホワイトリストを用いてフレームが不正か否かの判定を行う例を示したが、フレームの検査(不正か否かの判定)には他の判定基準を定めた不正検知ルールを用いても良い。例えば、正規でないIDで構成されたブラックリストを用いて判定を行っても良いし、DLCを用いた判定、送信メッセージの周期時間を用いた判定、一定時間内における送信頻度を用いた判定、或いは、適正なデータを示すデータフィールドを用いた判定を行っても良い。いかなる検査(フレームが不正か否かの判定)の方法を用いても、その判定の基準となるルールを表すものが不正検知ルールである。不正検知ルールは、バス上に現れるフレームが不正か否か(つまりルールに適合するか否か)の判定の基準となるルールとしての情報、そのルールへの適合性を判定するためのプログラム(判定アルゴリズムを実現するプログラム等)、或いは、情報及びプログラムを包含するファームウェア等であり得る。ファームウェアは、例えば、ECU内のプログラム等のソフトウェア、プログラムで用いられるデータを含み、例えば、ECU内のプロセッサにおけるマイクロコード、或いはECUがPLC(Programmable Logic Device)又はFPGA(Field Programmable Gate Array)を含む場合にこれらにおける回路構成用のデータ等を含み得る。なお、例えば不正検知ルールが、判定の基準となるルールとしての情報と、判定を行うためのアルゴリズムを実現するプログラムとに区別できる場合に、配信ルールの送信に際してそれぞれ別個の鍵を用いた暗号処理(暗号化、MACの付加等)を施しても良い。また暗号処理に呼応した処理(復号、MACの検証等)に用いる鍵を、バス種別、不正検知ECU毎に別個になるようにしても良い。
【0197】
(3)上記実施の形態では、CANプロトコルにおけるデータフレームを標準IDフォーマットで記述しているが、拡張IDフォーマットで合っても良い。拡張IDフォーマットの場合には、標準IDフォーマットにおけるID位置のベースIDと、拡張IDとを合わせて29ビットで、データフレームのID(メッセージID)を表す。なお、車載ネットワークシステムは、必ずしもCANプロトコルに完全に準拠したものでなくても良い。
【0198】
(4)上記実施の形態では、配信データを、外部装置であるサーバからプッシュしているが、ヘッドユニット或いは不正検知ECUから不正検知ルールの更新のための配信データがあるかどうかを問い合わせるとしても良い。問い合わせるタイミングとしては、定期的の他に、車両状態の変化のタイミング(例えばエンジン始動時、イグニッションキーがイグニッションキーシリンダに差し込まれた時)等としても良い。
【0199】
(5)上記実施の形態では、配信データの中に、不正検知ルールとバージョン情報とをセットでサーバからプッシュしているが、バージョン情報だけを送信してから必要に応じて配信データを送るとしても良い。また、配信データを送信するタイミングもサーバで車両状態を考慮して送信しても良い。この場合には、サーバは車両状態を不正検知ECU或いはヘッドユニットから取得して判定する。
【0200】
(6)上記実施の形態2ではヘッドユニットから不正検知ECUへの内部配信データの配信を、バス経由でCANプロトコルに従って行うこととしたが、それ以外の方法で配信しても良い。例えば、ヘッドユニットと不正検知ECUとを結ぶ専用通信路を用いても良い。
【0201】
(7)上記実施の形態1の変形例で示した不正検知ECUは、ステップS1209において車両状態が所定状態でないことにより不正検知ルールの更新を行うべきでないと判別した場合には、取得した配信データに含まれる更新用不正検知ルールを一時的に保持して、車両状態が所定状態に変更されるのを待って不正検知ルール保持部481に保持されている不正検知ルールの更新(更新用不正検知ルールへの更新)を行っても良い。また、車両状態が所定状態に変更されるのを待ってからサーバ(外部装置)に配信データの再送を要求して、配信データを新たに受信して不正検知ルールを、新たに受信したその配信データに含まれる更新用不正検知ルールへと更新しても良い。
【0202】
(8)上記実施の形態で示した配信データに付加するMACについては、共通鍵としても良いし、公開鍵で検証可能な署名としても良い。また実施の形態2では、サーバとヘッドユニットのみで暗号処理(暗号化、MAC生成、MAC検証)を行っているが、ヘッドユニットと不正検知ECUとの間の通信においても事前に鍵共有を行い、通信内容に対して暗号処理を行っても良い。なお、暗号化及び復号に使用する鍵と、MACの生成及び検証に使用する鍵は、同一の鍵であっても別々の鍵であっても良い。
【0203】
(9)上記実施の形態2では、不正検知ECUが、外部と接続するヘッドユニット経由で、不正検知ルール等を受信しているが、ヘッドユニットは一例にすぎず、外部と接続する別のECUを介して受信しても良い。外部と接続するECUは、例えば、複数のプロトコルによる通信バスと接続するセントラルゲートウェイ、診断ポートを制御するゲートウェイ等であっても良い。
【0204】
(10)上記実施の形態では、不正検知ECUが接続するバスの種類として「駆動系」、「ボディ系」、「安全系」を例示したが、いかなる体系でバスの種別を区分しても良いし、その区分の数がいくつであっても良い。
【0205】
(11)上記実施の形態では、不正検知ルールを更新する必要があるか否かの判別を、車種、バス種別、バージョン情報、車両状態等に応じて行う例を示したが、この判別の条件となる所定更新条件として、その例示した条件(車種、バス種別、バージョン情報、車両状態等)の一部だけを用いても良いし、また例示した以外の条件を加えても良い。所定更新条件は、不正検知ルールに対応して定められた付属情報(車種、バス種別、バージョン情報等)に関する条件だけであっても良いし、付属情報とは独立した車両状態等に関する条件を含んでいても良い。また、このような所定更新条件が満たされるか否かの判別は、不正検知ECU及びその他のECU(ヘッドユニット等)のいずれが行っても、分担して行っても良い。所定更新条件が満たされると、不正検知ECUが不正フレームの判定に用いる不正検知ルールが、新たな不正検知ルール(更新用不正検知ルール)へ更新されるように構成してれば良い。例えば、所定更新条件が付属情報に関する条件だけである場合においては、不正検知ECUは、不正検知ルールの更新を、不正検知ECUが受信した配信データ或いは内部配信データにおける付属情報が所定更新条件を満たす場合には行い、付属情報が所定更新条件を満たさない場合には行わない。また、付属情報としての車種を含ませる場合には、その付属情報の車種が、車載ネットワークシステムを搭載する車両の車種を示す場合に、その車載ネットワークシステムでは所定更新条件が満たされたとして不正検知ルールの更新を行い得る。
【0206】
(12)上記実施の形態における不正検知ECU及び他のECUは、例えば、プロセッサ、メモリ等のデジタル回路、アナログ回路、通信回路等を含む装置であることとしたが、ハードディスク装置、ディスプレイ、キーボード、マウス等の他のハードウェア構成要素を含んでいても良い。また、メモリに記憶された制御プログラムがプロセッサにより実行されてソフトウェア的に機能を実現する代わりに、専用のハードウェア(デジタル回路等)によりその機能を実現することとしても良い。
【0207】
(13)上記実施の形態における各装置を構成する構成要素の一部又は全部は、1個のシステムLSI(Large Scale Integration:大規模集積回路)から構成されているとしても良い。システムLSIは、複数の構成部を1個のチップ上に集積して製造された超多機能LSIであり、具体的には、マイクロプロセッサ、ROM、RAM等を含んで構成されるコンピュータシステムである。前記RAMには、コンピュータプログラムが記録されている。前記マイクロプロセッサが、前記コンピュータプログラムに従って動作することにより、システムLSIは、その機能を達成する。また、上記各装置を構成する構成要素の各部は、個別に1チップ化されていても良いし、一部又は全部を含むように1チップ化されても良い。また、ここでは、システムLSIとしたが、集積度の違いにより、IC、LSI、スーパーLSI、ウルトラLSIと呼称されることもある。また、集積回路化の手法はLSIに限るものではなく、専用回路又は汎用プロセッサで実現しても良い。LSI製造後に、プログラムすることが可能なFPGAや、LSI内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用しても良い。さらには、半導体技術の進歩又は派生する別技術によりLSIに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行っても良い。バイオ技術の適用等が可能性としてあり得る。
【0208】
(14)上記各装置を構成する構成要素の一部又は全部は、各装置に脱着可能なICカード又は単体のモジュールから構成されているとしても良い。前記ICカード又は前記モジュールは、マイクロプロセッサ、ROM、RAM等から構成されるコンピュータシステムである。前記ICカード又は前記モジュールは、上記の超多機能LSIを含むとしても良い。マイクロプロセッサが、コンピュータプログラムに従って動作することにより、前記ICカード又は前記モジュールは、その機能を達成する。このICカード又はこのモジュールは、耐タンパ性を有するとしても良い。
【0209】
(15)本発明の一態様としては、例えば
図25、
図26、
図28、
図29、
図42、
図43等に示す不正検知ルール更新方法であるとしても良い。また、これらの方法をコンピュータにより実現するコンピュータプログラムであるとしても良いし、前記コンピュータプログラムからなるデジタル信号であるとしても良い。また、本発明の一態様としては、前記コンピュータプログラム又は前記デジタル信号をコンピュータで読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、CD-ROM、MO、DVD、DVD-ROM、DVD-RAM、BD(Blu-ray(登録商標) Disc)、半導体メモリ等に記録したものとしても良い。また、これらの記録媒体に記録されている前記デジタル信号であるとしても良い。また、本発明の一態様としては、前記コンピュータプログラム又は前記デジタル信号を、電気通信回線、無線又は有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしても良い。また、本発明の一態様としては、マイクロプロセッサとメモリを備えたコンピュータシステムであって、前記メモリは、上記コンピュータプログラムを記録しており、前記マイクロプロセッサは、前記コンピュータプログラムに従って動作するとしても良い。また、前記プログラム若しくは前記デジタル信号を前記記録媒体に記録して移送することにより、又は、前記プログラム若しくは前記デジタル信号を前記ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしても良い。
【0210】
(16)上記実施の形態及び上記変形例で示した各構成要素及び機能を任意に組み合わせることで実現される形態も本発明の範囲に含まれる。
【産業上の利用可能性】
【0211】
本発明は、車載ネットワークにおいて、バス上への不正なフレームの送信の検知を行う基準となるルールを更新するために利用可能である。
【符号の説明】
【0212】
10、20 車載ネットワークシステム
100a~100e 電子制御ユニット(ECU)
101 エンジン
102 ブレーキ
103 ドア開閉センサ
104 窓開閉センサ
105 コーナーセンサ
110、310、410、810 フレーム送受信部
120、320、420、820、2420 フレーム解釈部
130、330、830 受信ID判断部
140、340、840 受信IDリスト保持部
150、850、2450 フレーム処理部
160、360、460、860、2460 フレーム生成部
170 データ取得部
200a~200d バス
300a、300b、2300a、2300b ゲートウェイ
351 転送処理部
352 転送ルール保持部
400a~400c、1400a、2400a~2400c 不正検知電子制御ユニット(不正検知ECU)
480 不正検知処理部
481、530 不正検知ルール保持部
490、890 外部通信部
491、591、891 暗復号処理部
492、592、892 MAC処理部
493、593、893 鍵保持部
494、1494、2494 更新判定部
495 車両No.保持部
496 バス種別保持部
500、2500 サーバ
510、2510 通信部
520 配信データ管理部
540 更新結果管理部
550、855 更新結果表保持部
600 ネットワーク
800 ヘッドユニット
853 表示制御部
854 更新管理部
1497 車両状態保持部
1498 車両状態判定部