本開示の一態様に係る不正対処方法は、CAN(Controller Area Network)プロトコルに従ってバスを介して通信する複数の電子制御ユニットを備えるネットワーク通信システムにおいて用いられる不正対処方法であって、送信が開始されたフレームにおける所定フィールドの内容が、不正を示す所定条件に該当するか否かを判定する判定ステップと、前記判定ステップにおいて前記フレームの所定フィールドの内容が前記所定条件に該当すると判定された場合に、当該フレームの最後尾が送信される前にエラーフレームを送信する送信ステップとを含む不正対処方法である。なお、不正を示す所定条件の一例としては、例えば所定フィールドの内容が、正当値群を示すリストに含まれていないこと、不正値群を示すリストに含まれていること、一定範囲内又は一定特徴を有する値(例えば偶数等)であること、内容値に所定演算を施した結果が所定値となること等が挙げられる。これにより、CANプロトコルに従って通信するネットワーク通信システムにおいて、バスに不正なノードが接続され不正なフレームが送信されたとしても、不正なフレームに基づく処理が各ノード(ECU)により実行されるのを阻止できる。
また、前記送信ステップでは、前記フレームにおけるCRCシーケンスの最後尾が送信される前に、前記エラーフレームの前記送信を行うこととしても良い。これにより、例えば、CRCシーケンスを確認してフレームを処理するECUが、不正なフレームに基づく処理を実行できなくなる。
また、前記所定フィールドは、IDを表すフィールドであり、前記判定ステップでは、前記所定フィールドの内容により表されるIDを、予め定められたIDリスト情報が示す1以上のIDと比較することにより、前記所定条件に該当するか否かの前記判定を行うこととしても良い。これにより、例えば、データフレーム或いはリモートフレームにおけるIDフィールドで不正を判断可能となり、各ECUでの不正なフレームについての処理の実行を阻止できる。
また、前記所定フィールドは、コントロールフィールドであり、前記判定ステップでは、前記所定フィールドの内容により表されるデータ長が予め定められた範囲に含まれるか否かを判別することにより、前記内容が前記所定条件に該当するか否かの前記判定を行うこととしても良い。これにより、例えば、データフレーム或いはリモートフレームにおけるコントロールフィールドで不正を判断可能となり、各ECUでの不正なフレームについての処理の実行を阻止できる。
また、前記判定ステップでは、送信された前記フレームがデータフレームである場合に前記判定を行い、前記所定フィールドは、データフィールドであることとしても良い。これにより、不正なデータフレームのデータに従って各ECUがそのデータに対応した処理を実行してしまうことを阻止できる。
また、前記判定ステップでは、前記所定フィールドの内容であるデータ値が予め定められた範囲に含まれるか否かを判別することにより、前記内容が前記所定条件に該当するか否かの前記判定を行うこととしても良い。これにより、例えば不正な範囲のデータ値を含ませた不正なデータフレームが送信されても、各ECUがそのデータに対応した処理を実行してしまうことを阻止できる。
また、前記判定ステップでは、前記所定フィールドの内容におけるメッセージ認証コードを予め定められた検証処理手順により検証し、当該検証に失敗した場合には、前記内容が前記所定条件に該当すると判定することとしても良い。これにより、正規なメッセージ認証コードを付加していない不正なフレームが送信された場合に各ECUでの不正なフレームについての処理の実行を阻止できる。
また、正当な電子制御ユニットにより送信されるデータフレームは、データフィールド内に、データフレームが送信される度に変化する変数に応じて算定されたメッセージ認証コードを含み、前記判定ステップでは、データフレームが送信される度に変化する前記変数を、前記所定フィールドの内容における前記メッセージ認証コードが反映していない場合に、前記内容が前記所定条件に該当すると判定することとしても良い。これにより、例えばメッセージ認証コードについての不正な解読を困難化できる。
また、メッセージ認証コード鍵を有する正当な電子制御ユニットにより送信されるデータフレームは、データフィールド内に前記メッセージ認証コード鍵を用いて生成されたメッセージ認証コードを含み、前記判定ステップでは、前記メッセージ認証コード鍵に呼応する鍵を用いて前記所定フィールドの内容における前記メッセージ認証コードの前記検証を行うこととしても良い。これにより、例えば正規な複数のECUについて、メッセージ認証コード鍵を除くメッセージ認証コード生成のための構成を共通化できる。
また、前記不正対処方法は更に、前記送信ステップにおいてエラーフレームを送信した回数を記録する記録ステップと、前記記録ステップにより記録された回数が所定回数を超えた場合に報知を行う報知ステップとを含むこととしても良い。これにより、不正なフレームが繰り返して送信された場合にユーザ等に報知することができる。
また、本開示の一態様に係る不正検知電子制御ユニット(不正検知ECU)は、CAN(Controller Area Network)プロトコルに従って通信する複数の電子制御ユニットが通信に用いるバスに接続される不正検知電子制御ユニットであって、送信が開始されたフレームを受信する受信部と、前記受信部により受信されたフレームにおける所定フィールドの内容が、不正を示す所定条件に該当するか否かを判定する判定部と、前記判定部において前記フレームの所定フィールドの内容が前記所定条件に該当すると判定された場合に、当該フレームの最後尾が送信される前にエラーフレームを送信する送信部とを備える不正検知電子制御ユニットである。これにより、CANプロトコルに従って通信する複数のECUを接続するバスに不正なノードが接続され不正なフレームが送信されたとしても、不正なフレームに基づく処理が各ECUにより実行されるのを阻止できる。
また、本開示の一態様に係るネットワーク通信システムは、CAN(Controller Area Network)プロトコルに従ってバスを介して通信する複数の電子制御ユニットと当該バスに接続された不正検知電子制御ユニットとを備えるネットワーク通信システムであって、前記不正検知電子制御ユニットは、送信が開始されたフレームを受信する受信部と、前記受信部により受信されたフレームにおける所定フィールドの内容が、不正を示す所定条件に該当するか否かを判定する判定部と、前記判定部において前記フレームの所定フィールドの内容が前記所定条件に該当すると判定された場合に、当該フレームの最後尾が送信される前にエラーフレームを送信する送信部とを備えるネットワーク通信システムである。これにより、バスに不正なノードが接続され不正なフレームが送信されたとしても、不正なフレームに基づく処理がECUにより実行されるのを阻止できる。
なお、これらの全般的又は具体的な態様は、システム、方法、集積回路、コンピュータプログラム又はコンピュータ読み取り可能なCD−ROM等の記録媒体で実現されても良く、システム、方法、集積回路、コンピュータプログラム又は記録媒体の任意な組み合わせで実現されても良い。
以下、実施の形態に係る不正検知ECUについて、図面を参照しながら説明する。ここで示す実施の形態は、いずれも本開示の一具体例を示すものである。従って、以下の実施の形態で示される数値、構成要素、構成要素の配置及び接続形態、並びに、ステップ(工程)及びステップの順序等は、一例であって本開示を限定するものではない。以下の実施の形態における構成要素のうち、独立請求項に記載されていない構成要素については、任意に付加可能な構成要素である。また、各図は、模式図であり、必ずしも厳密に図示されたものではない。
(実施の形態1)
以下、本開示の実施の形態として、メッセージIDを用いて他のノード(ECU)において不正なフレームに基づく処理が実行されることを阻止するための不正対処方法を実現する不正検知ECUを含む車載ネットワークシステム10について図面を用いて説明する。
[1.1 車載ネットワークシステム10の全体構成]
図1は、実施の形態1に係る車載ネットワークシステム10の全体構成を示す図である。車載ネットワークシステム10は、CANプロトコルに従って通信するネットワーク通信システムの一例であり、制御装置、センサ等の各種機器が搭載された自動車におけるネットワーク通信システムである。車載ネットワークシステム10は、バス500a、500bと、不正検知ECU100a、100b、ヘッドユニット200、ゲートウェイ300、及び、各種機器に接続されたECU400a〜400d等のECUといったバスに接続された各ノードとを含んで構成される。なお、図1では省略しているものの、車載ネットワークシステム10にはECU400a〜400d以外にもいくつものECUが含まれ得るが、ここでは、便宜上ECU400a〜400dに注目して説明を行う。ECUは、例えば、プロセッサ(マイクロプロセッサ)、メモリ等のデジタル回路、アナログ回路、通信回路等を含む装置である。メモリは、ROM、RAM等であり、プロセッサにより実行される制御プログラム(コンピュータプログラム)を記憶することができる。例えばプロセッサが、制御プログラム(コンピュータプログラム)に従って動作することにより、ECUは各種機能を実現することになる。なお、コンピュータプログラムは、所定の機能を達成するために、プロセッサに対する指令を示す命令コードが複数個組み合わされて構成されたものである。ここでは、バス500a、500bには不正なフレームを送信する不正ECUが接続されている可能性があることを前提として説明する。
不正検知ECU100a、100bは、それぞれバス500a、バス500bに接続され、ECU400a〜400d等により送信されたフレームが不正であるかどうかを判定し、不正であればエラーフレームを送信する機能を有するECUである。
ECU400a〜400dは、いずれかのバスと接続され、また、それぞれエンジン401、ブレーキ402、ドア開閉センサ403、窓開閉センサ404に接続されている。ECU400a〜400dのそれぞれは、接続されている機器(エンジン401等)の状態を取得し、定期的に状態を表すフレーム(後述するデータフレーム)等をネットワーク(つまりバス)に送信している。
ゲートウェイ300は、不正検知ECU100a、ECU400a及びECU400bがつながるバス500aと、不正検知ECU100b、ECU400c及びECU400dがつながるバス500bと、ヘッドユニット200がつながるバス500cとに接続しており、それぞれのバスから受信したフレームを他のバスに転送する機能を有する。また受信したフレームを転送するかしないかを接続されたバス間毎に切り替えることも可能である。ゲートウェイ300も一種のECUである。
ヘッドユニット200は、フレームを受信する機能を持ち、ECU400a〜400dから送信されるフレームを受信し、各種状態をディスプレイ(図示しない)に表示して、ユーザに提示する機能を持つ。ヘッドユニット200も一種のECUである。
この車載ネットワークシステム10においてはCANプロトコルに従って各ECUがフレームの授受を行う。CANプロトコルにおけるフレームには、データフレーム、リモートフレーム、オーバーロードフレーム及びエラーフレームがある。説明の便宜上、まずはデータフレーム及びエラーフレームを中心に説明する。
[1.2 データフレームフォーマット]
以下、CANプロトコルに従ったネットワークで用いられるフレームの1つであるデータフレームについて説明する。
図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)の各フィールドで構成される。
SOFは、1bitのドミナントで構成される。バスがアイドルの状態はレセシブになっており、SOFによりドミナントへ変更することでフレームの送信開始を通知する。
IDフィールドは、11bitで構成される、データの種類を示す値であるID(メッセージID)を格納するフィールドである。複数のノードが同時に送信を開始した場合、このIDフィールドで通信調停を行うために、IDが小さい値を持つフレームが高い優先度となるよう設計されている。
RTRは、データフレームとリモートフレームとを識別するための値であり、データフレームにおいてはドミナント1bitで構成される。
IDEと「r」とは、両方ドミナント1bitで構成される。
DLCは、4bitで構成され、データフィールドの長さを示す値である。なお、IDE、「r」及びDLCを合わせてコントロールフィールドと称する。
データフィールドは、最大64bitで構成される送信するデータの内容を示す値である。8bit毎に長さを調整できる。送られるデータの仕様については、CANプロトコルで規定されておらず、車載ネットワークシステム10において定められる。従って、車種、製造者(製造メーカ)等に依存した仕様となる。
CRCシーケンスは、15bitで構成される。SOF、IDフィールド、コントロールフィールド及びデータフィールドの送信値より算出される。
CRCデリミタは、1bitのレセシブで構成されるCRCシーケンスの終了を表す区切り記号である。なお、CRCシーケンス及びCRCデリミタを合わせてCRCフィールドと称する。
ACKスロットは、1bitで構成される。送信ノードはACKスロットをレセシブにして送信を行う。受信ノードはCRCシーケンスまで正常に受信ができていればACKスロットをドミナントとして送信する。レセシブよりドミナントが優先されるため、送信後にACKスロットがドミナントであれば、送信ノードは、いずれかの受信ノードが受信に成功していること確認できる。
ACKデリミタは、1bitのレセシブで構成されるACKの終了を表す区切り記号である。
EOFは、7bitのレセシブで構成されており、データフレームの終了を示す。
[1.3 エラーフレームフォーマット]
図3は、CANプロトコルで規定されるエラーフレームのフォーマットを示す図である。エラーフレームは、エラーフラグ(プライマリ)と、エラーフラグ(セカンダリ)と、エラーデリミタとから構成される。
エラーフラグ(プライマリ)は、エラーの発生を他のノードに知らせるために使用される。エラーを検知したノードはエラーの発生を他のノードに知らせるために6bitのドミナントを連続で送信する。この送信は、CANプロトコルにおけるビットスタッフィングルール(連続して同じ値を6bit以上送信しない)に違反し、他のノードからのエラーフレーム(セカンダリ)の送信を引き起こす。
エラーフラグ(セカンダリ)は、エラーの発生を他のノードに知らせるために使用される連続した6ビットのドミナントで構成される。エラーフラグ(プライマリ)を受信してビットスタッフィングルール違反を検知した全てのノードがエラーフラグ(セカンダリ)を送信することになる。
エラーデリミタ「DEL」は、8bitの連続したレセシブであり、エラーフレームの終了を示す。
[1.4 ヘッドユニット200の構成]
ヘッドユニット200は、例えば、自動車のインパネ等に設けられ、運転者に視認されるための情報を表示する液晶ディスプレイ(LCD:liquid crystal display)等の表示装置、運転者の操作を受け付ける入力手段等を備える一種のECUである。
図4は、ヘッドユニット200の構成図である。ヘッドユニット200は、フレーム送受信部270と、フレーム解釈部260と、受信ID判断部240と、受信IDリスト保持部250と、フレーム処理部220と、表示制御部210と、フレーム生成部230とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、ヘッドユニット200における通信回路、LCD、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。
フレーム送受信部270は、バス500cに対して、CANプロトコルに従ったフレームを送受信する。バス500cからフレームを1bitずつ受信し、フレーム解釈部260に転送する。また、フレーム生成部230より通知を受けたフレームの内容をバス500cに1bitずつ送信する。
フレーム解釈部260は、フレーム送受信部270よりフレームの値を受け取り、CANプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。フレーム解釈部260は、IDフィールドと判断した値は受信ID判断部240へ転送する。フレーム解釈部260は、受信ID判断部240から通知される判定結果に応じて、IDフィールドの値と、IDフィールド以降に現れるデータフィールドとを、フレーム処理部220へ転送するか、その判定結果を受けた以降においてフレームの受信を中止する(つまりそのフレームとしての解釈を中止する)かを決定する。また、フレーム解釈部260は、例えば、CRCの値が合わなかったり、ドミナント固定とされている項目がレセシブだったりする等、CANプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部230へ通知する。また、フレーム解釈部260は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。例えばデータフレームの途中からエラーフレームと解釈された場合においては、そのデータフレームの解釈は中止され、そのデータフレームに応じて特段の処理を行うことがなくなる。
受信ID判断部240は、フレーム解釈部260から通知されるIDフィールドの値を受け取り、受信IDリスト保持部250が保持しているメッセージIDのリストに従い、そのIDフィールド以降のフレームの各フィールドを受信するかどうかの判定を行う。この判定結果を、受信ID判断部240は、フレーム解釈部260へ通知する。
受信IDリスト保持部250は、ヘッドユニット200が受信するID(メッセージID)のリストである受信IDリストを保持する。図5は、受信IDリストの一例を示した図である。ヘッドユニット200は、エンジン401に接続されたECU400aからメッセージIDが「1」であるフレーム(メッセージ)を受信し、ブレーキ402に接続されたECU400bからメッセージIDが「2」であるフレームを受信し、ドア開閉センサ403に接続されたECU400cからメッセージIDが「3」であるフレームを受信し、窓開閉センサ404に接続されたECU400dからメッセージIDが「4」であるフレームを受信する。
フレーム処理部220は、受信したフレームの内容(例えばメッセージID及びデータフィールドの内容)に基づいて、例えばLCDに表示されるべき画像を形成して、表示制御部210に通知する。なお、フレーム処理部220は、受信したデータフィールドの内容を保持し、入力手段を通じて受け付けた運転者による操作に応じて、LCDに表示されるべき画像(例えば車速表示用の画像、窓開閉状態表示用の画像等)を選択して通知しても良い。
表示制御部210は、フレーム処理部220より通知を受けた内容をLCD等に表示する。
フレーム生成部230は、フレーム解釈部260からのエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部270へ通知して送信させる。
[1.5 受信IDリスト例1]
上述した図5は、ヘッドユニット200、ゲートウェイ300、ECU400c及びECU400dのそれぞれにおいて保持される受信IDリストの一例を示す図である。同図に例示する受信IDリストは、ID(メッセージID)の値が「1」、「2」、「3」及び「4」のいずれかであるメッセージIDを含むフレームを選択的に受信して処理するために用いられる。例えば、ヘッドユニット200の受信IDリスト保持部250に図5の受信IDリストが保持されていると、メッセージIDが「1」、「2」、「3」及び「4」のいずれでもないフレームについては、フレーム解釈部260でのIDフィールド以後のフレームの解釈が中止される。
[1.6 ゲートウェイ300の構成]
図6は、ゲートウェイ300の構成図である。ゲートウェイ300は、フレーム送受信部360と、フレーム解釈部350と、受信ID判断部330と、受信IDリスト保持部340と、フレーム生成部320と、転送処理部310と、転送ルール保持部370とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、ゲートウェイ300における通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。
フレーム送受信部360は、バス500a、500b、500cそれぞれに対して、CANプロトコルに従ったフレームを送受信する。バスからフレームを1bitずつ受信し、フレーム解釈部350に転送する。また、フレーム生成部320より通知を受けた転送先のバスを示すバス情報及びフレームに基づいて、そのフレームの内容をバス500a、500b、500cに1bitずつ送信する。
フレーム解釈部350は、フレーム送受信部360よりフレームの値を受け取り、CANプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。IDフィールドと判断した値は受信ID判断部330へ転送する。フレーム解釈部350は、受信ID判断部330から通知される判定結果に応じて、IDフィールドの値と、IDフィールド以降に現れるデータフィールド(データ)とを、転送処理部310へ転送するか、その判定結果を受けた以降においてフレームの受信を中止する(つまりそのフレームとしての解釈を中止する)かを決定する。また、フレーム解釈部350は、CANプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部320へ通知する。また、フレーム解釈部350は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。
受信ID判断部330は、フレーム解釈部350から通知されるIDフィールドの値を受け取り、受信IDリスト保持部340が保持しているメッセージIDのリストに従い、そのIDフィールド以降のフレームの各フィールドを受信するかどうかの判定を行う。この判定結果を、受信ID判断部330は、フレーム解釈部350へ通知する。
受信IDリスト保持部340は、ゲートウェイ300が受信するID(メッセージID)のリストである受信IDリスト(図5参照)を保持する。
転送処理部310は、転送ルール保持部370が保持する転送ルールに従って、受信したフレームのメッセージIDに応じて、転送するバスを決定し、転送するバスを示すバス情報とフレーム解釈部350より通知されたメッセージIDとデータとをフレーム生成部320へ通知する。なお、ゲートウェイ300は、あるバスから受信されたエラーフレームについては他のバスに転送しない。
転送ルール保持部370は、バス毎のフレームの転送についてのルールを表す情報である転送ルールを保持する。図7は、転送ルールの一例を示した図である。
フレーム生成部320は、フレーム解釈部350から通知されたエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部360へ通知して送信させる。また、フレーム生成部320は、転送処理部310より通知されたメッセージIDとデータとを使ってフレームを構成し、フレーム及びバス情報をフレーム送受信部360へ通知する。
[1.7 転送ルール例]
図7は、上述したようにゲートウェイ300が保有する転送ルールの一例を示す。この転送ルールは、転送元のバスと転送先のバスと転送対象のID(メッセージID)とを対応付けている。図7中のメッセージIDにかかわらずフレームの転送がなされることを表している。また、同図中の「−」は転送対象のフレームがないことを示す。同図の例は、バス500aから受信するフレームはメッセージIDにかかわらず、バス500b及びバス500cに転送するように設定されていることを示している。また、バス500bから受信するフレームのうち、バス500cには全てのフレームが転送されるが、バス500aにはメッセージIDが「3」であるフレームのみが転送されるように設定されていることを示している。また、バス500cから受信されるフレームは、バス500aにもバス500bにも転送されないように設定されていることを示している。
[1.8 ECU400aの構成]
図8は、ECU400aの構成図である。ECU400aは、フレーム送受信部460と、フレーム解釈部450と、受信ID判断部430と、受信IDリスト保持部440と、フレーム処理部410と、フレーム生成部420と、データ取得部470とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、ECU400aにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。
フレーム送受信部460は、バス500aに対して、CANプロトコルに従ったフレームを送受信する。バス500aからフレームを1bitずつ受信し、フレーム解釈部450に転送する。また、フレーム生成部420より通知を受けたフレームの内容をバス500aに送信する。
フレーム解釈部450は、フレーム送受信部460よりフレームの値を受け取り、CANプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。IDフィールドと判断した値は受信ID判断部430へ転送する。フレーム解釈部450は、受信ID判断部430から通知される判定結果に応じて、IDフィールドの値と、IDフィールド以降に現れるデータフィールドとを、フレーム処理部410へ転送するか、その判定結果を受けた以降においてフレームの受信を中止する(つまりそのフレームとしての解釈を中止する)かを決定する。また、フレーム解釈部450は、CANプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部420へ通知する。また、フレーム解釈部450は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。
受信ID判断部430は、フレーム解釈部450から通知されるIDフィールドの値を受け取り、受信IDリスト保持部440が保持しているメッセージIDのリストに従い、そのIDフィールド以降のフレームの各フィールドを受信するかどうかの判定を行う。この判定結果を、受信ID判断部430は、フレーム解釈部450へ通知する。
受信IDリスト保持部440は、ECU400aが受信するID(メッセージID)のリストである受信IDリストを保持する。図9は、受信IDリストの一例を示した図である。
フレーム処理部410は、受信したフレームのデータに応じてECU毎に異なる機能に係る処理を行う。例えば、エンジン401に接続されたECU400aは、時速が30kmを超えた状態でドアが開いている状態だと、アラーム音を鳴らす機能を備える。ECU400aは、例えばアラーム音を鳴らすためのスピーカ等を有している。そして、ECU400aのフレーム処理部410は、他のECUから受信したデータ(例えばドアの状態を示す情報)を管理し、エンジン401から取得された時速に基づいて一定条件下でアラーム音を鳴らす処理等を行う。
データ取得部470は、ECUにつながっている機器、センサ等の状態を示すデータを取得し、フレーム生成部420に通知する。
フレーム生成部420は、フレーム解釈部450から通知されたエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部460へ通知して送信させる。また、フレーム生成部420は、データ取得部470より通知されたデータの値に対して、予め定められたメッセージIDをつけてフレームを構成し、フレーム送受信部460へ通知する。
なお、ECU400b〜400dも、上述したECU400aと基本的に同様の構成を備える。但し、受信IDリスト保持部440に保持される受信IDリストはECU毎に異なる内容となり得る。ECU400bは図9に例示する受信IDリストを保持し、ECU400c及びECU400dは図5に例示する受信IDリストを保持する。また、フレーム処理部410の処理内容は、ECU毎に異なる。例えば、ECU400cにおけるフレーム処理部410の処理内容は、ブレーキがかかっていない状況でドアが開くとアラーム音を鳴らす機能に係る処理を含む。例えば、ECU400b及びECU400dにおけるフレーム処理部410では特段の処理を行わない。なお、各ECUは、ここで例示した以外の機能を備えていても良い。なお、ECU400a〜400dのそれぞれが送信するフレームの内容については後に図10〜図13を用いて説明する。
[1.9 受信IDリスト例2]
上述した図9は、ECU400a及びECU400bのそれぞれにおいて保持される受信IDリストの一例を示す図である。同図に例示する受信IDリストは、ID(メッセージID)の値が「1」、「2」及び「3」のいずれかであるメッセージIDを含むフレームを選択的に受信して処理するために用いられる。例えば、ECU400aの受信IDリスト保持部440に図9の受信IDリストが保持されていると、メッセージIDが「1」、「2」及び「3」のいずれでもないフレームについては、フレーム解釈部450でのIDフィールド以後のフレームの解釈が中止される。
[1.10 エンジンに係るECU400aの送信フレーム例]
図10は、エンジン401に接続されたECU400aから送信されるフレームにおけるID(メッセージID)及びデータフィールド(データ)の一例を示す図である。ECU400aが送信するフレームのメッセージIDは「1」である。データは、時速(km/時)を表し、最低0(km/時)〜最高180(km/時)までの範囲の値を取り、データ長は1Byteである。図10の上行から下行へと、ECU400aから逐次送信される各フレームに対応する各メッセージID及びデータを例示しており、0km/時から1km/時ずつ加速されている様子を表している。
[1.11 ブレーキに係るECU400bの送信フレーム例]
図11は、ブレーキ402に接続されたECU400bから送信されるフレームにおけるID(メッセージID)及びデータフィールド(データ)の一例を示す図である。ECU400bが送信するフレームのメッセージIDは「2」である。データは、ブレーキのかかり具合を割合(%)で表し、データ長は1Byteである。この割合は、ブレーキを全くかけていない状態を0(%)、ブレーキを最大限かけている状態を100(%)としたものである。図11の上行から下行へと、ECU400bから逐次送信される各フレームに対応する各メッセージID及びデータを例示しており、100%から徐々にブレーキを弱めている様子を表している。
[1.12 ドア開閉センサに係るECU400cの送信フレーム例]
図12は、ドア開閉センサ403に接続されたECU400cから送信されるフレームにおけるID(メッセージID)及びデータフィールド(データ)の一例を示す図である。ECU400cが送信するフレームのメッセージIDは「3」である。データは、ドアの開閉状態を表し、データ長は1Byteである。データの値は、ドアが開いている状態が「1」、ドアが閉まっている状態が「0」である。図12の上行から下行へと、ECU400cから逐次送信される各フレームに対応する各メッセージID及びデータを例示しており、ドアが開いている状態から次第に閉められた状態へと移った様子を表している。
[1.13 窓開閉センサに係るECU400dの送信フレーム例]
図13は、窓開閉センサ404に接続されたECU400dから送信されるフレームにおけるID(メッセージID)及びデータフィールド(データ)の一例を示す図である。ECU400dが送信するフレームのメッセージIDは「4」である。データは、窓の開閉状態を割合(%)で表し、データ長は1Byteである。この割合は、窓が完全に閉まっている状態を0(%)、窓が全開の状態を100(%)としたものである。図13の上行から下行へと、ECU400dから逐次送信される各フレームに対応する各メッセージID及びデータを例示しており、窓が閉まっている状態から徐々に開いていく様子を表している。
[1.14 不正検知ECU100aの構成]
図14は、不正検知ECU100aの構成図である。不正検知ECU100aは、フレーム送受信部160と、フレーム解釈部150と、不正フレーム検知部130と、正規IDリスト保持部120と、不正検知カウンタ保持部110と、フレーム生成部140とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、不正検知ECU100aにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。なお、不正検知ECU100bも基本的に同様の構成を備えるが、正規IDリスト保持部120が保持するリスト情報(正規IDリスト)の内容が不正検知ECU100aと不正検知ECU100bとでは異なる。
フレーム送受信部160は、バス500aに対して、CANプロトコルに従ったフレームを送受信する。即ち、フレーム送受信部160は、バス上でのフレームの送信が開始された場合においてフレームを受信する言わば受信部として働き、また、バスにエラーフレーム等を送信する言わば送信部として働く。即ち、フレーム送受信部160は、バス500aからフレームを1bitずつ受信し、フレーム解釈部150に転送する。また、フレーム生成部140より通知を受けたフレームの内容をバス500aに送信する。
フレーム解釈部150は、フレーム送受信部160よりフレームの値を受け取り、CANプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。IDフィールドと判断した値は、不正フレーム検知部130へ転送する。また、フレーム解釈部150は、CANプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部140へ通知する。また、フレーム解釈部150は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。
不正フレーム検知部130は、フレーム解釈部150から通知されるIDフィールドの値を受け取り、IDフィールドの値が不正を示す所定条件に該当するか否かを判定する。即ち不正フレーム検知部130は、受信されたフレームにおける所定フィールドの内容が不正を示す所定条件に該当するか否かを判定する言わば判定部として機能する。この不正を示す所定条件は、IDフィールドの値が、正規IDリスト保持部120が保持しているメッセージIDのリストに載っていないという条件である。即ち、正規IDリスト保持部120が保持しているメッセージIDのリストに従い、通知されたIDフィールドの値(メッセージID)が不正かどうかの判定を行う。このリスト(つまり後述する正規IDリスト)に載っていないメッセージIDを受信した場合は、不正の検知回数をインクリメントするために、受信したメッセージIDを不正検知カウンタ保持部110へ通知する。また、正規IDリストに載っていないメッセージIDを受信した場合は、エラーフレームを送信するように、フレーム生成部140へ通知する。また、不正の検知回数が一定回数以上に達した場合に、不正検知カウンタ保持部110より通知を受け、該当するメッセージIDを発行する不正なECUが存在することを示すエラー表示メッセージ(フレーム)を送信するようフレーム生成部140へ通知する。エラー表示メッセージのメッセージIDは予め定められており、このメッセージIDのメッセージ(フレーム)をヘッドユニット200が受信してエラー表示を行うようになっている。このエラー表示メッセージについては便宜上説明を省略していたが、エラー表示メッセージのメッセージIDは、ゲートウェイ300及びヘッドユニット200が保持する受信IDリスト、及び、後述する正規IDリストに掲載される。但し、図15、図16ではエラー表示メッセージについてのメッセージIDを省略している。
正規IDリスト保持部120は、車載ネットワークシステム10においてバス500a上を送信されることとなるフレームに含まれるメッセージIDを予め規定したリストである正規IDリストを保持する(図15、図16参照)。
不正検知カウンタ保持部110は、メッセージID毎に検知回数をカウントするための不正検知カウンタを保持しており、不正フレーム検知部130からメッセージIDが通知されると、該当する不正検知カウンタをインクリメント(増加)する。不正検知カウンタが一定数(所定回数)以上に達した場合、不正フレーム検知部130に一定数を超えたことを通知する。ここでいう一定数(所定回数)の一例は、CANプロトコルにおける送信エラーカウンタの取り扱い規則に対応して定められた値である。CANプロトコルでは、ECUがエラーフレームによって送信を阻止する度に送信エラーカウンタが8カウントアップする。そして、この結果として送信ノードにおける送信エラーカウンタが128迄カウントアップすれば送信ノードはパッシブ状態に遷移してフレーム送信をしなくなるように規定されている。従って、128/8(=16)より大きな17をこの一定数として定めておけば、CANプロトコルにおける送信エラーカウンタに係る規則を無視した送信ノード(不正なECU)の存在が推定される場合に不正検知ECU100aからエラー表示メッセージが送信されるようになる。なお、不正なフレームを送信する、不正なECUが、CANプロトコルにおける送信エラーカウンタに係る規則に従うものであった場合には、不正検知ECU100aによるエラーフレームの送信によって、不正なECUの送信エラーカウンタは8インクリメントされる。この場合、不正なフレームの送信を繰り返すことで不正なECUの送信エラーカウンタが128まで上昇すると、不正なECUがパッシブ状態に遷移し、不正なECUによる不正なフレームの送信が停止することになる。
フレーム生成部140は、フレーム解釈部150から通知されたエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部160へ通知して送信させる。また、フレーム生成部140は、不正フレーム検知部130から通知されたエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部160へ通知して送信させる。更にフレーム生成部140は、不正フレーム検知部130から通知されたエラー表示メッセージの送信を指示する通知に従い、エラー表示メッセージをフレーム送受信部160へ通知して送信させる。
[1.15 不正検知ECU100aの正規IDリスト例]
図15は、不正検知ECU100aの正規IDリスト保持部120に保持される正規IDリストの一例を示した図である。同図に例示する正規IDリストは、ID(メッセージID)の値が「1」、「2」及び「3」のいずれかであるメッセージIDを含むフレームがバス500aに流れ得ることを示している。
[1.16 不正検知ECU100bの正規IDリスト例]
図16は、不正検知ECU100bの正規IDリスト保持部120に保持される正規IDリストの一例を示した図である。同図に例示する正規IDリストは、ID(メッセージID)の値が「1」、「2」、「3」及び「4」のいずれかであるメッセージIDを含むフレームがバス500bに流れ得ることを示している。
[1.17 不正検知カウンタ保存リスト例]
図17は、メッセージID毎の不正検知カウンタの状態の一例を示す図である。同図の例は、メッセージIDが「4」の不正検知カウンタだけが、不正を一度検知しており、その他のメッセージIDでは一度も検知していないことを示す。即ち、この例はバス500aに本来流れるはずがないメッセージID「4」のメッセージ(フレーム)が一度送信されたことを不正検知ECU100aが検知し、該当するメッセージID「4」に対応する不正検知カウンタを1インクリメントした場合を示している。
[1.18 不正フレームの検知に係るシーケンス]
以下、上述の構成を備える車載ネットワークシステム10のバス500aに不正なECUが接続された場合について、バス500aに接続された不正検知ECU100a、ECU400a、ECU400b、ゲートウェイ300等の動作について説明する。
図18は、不正検知ECU100aが不正なフレーム(メッセージ)を検知して、他のECUによりその不正なフレームに対応した処理がなされることを阻止する動作例を示すシーケンス図である。同図では、不正なECUが、バス500aにメッセージIDが「4」でデータフィールド(データ)が「255(0xFF)」となるデータフレームを送信する場合の例を示している。ここでの各シーケンスは、各種装置における各処理手順(ステップ)を意味する。
まず、不正なECUは、メッセージIDが「4」、データが「255(0xFF)」となるデータフレームの送信を開始する(シーケンスS1001)。フレームを構成する各ビットの値は、上述したデータフレームフォーマットに従ってSOF、IDフィールド(メッセージID)といった順に逐次バス500a上に送出される。
不正なECUがIDフィールド(メッセージID)までをバス500aに送出し終えたときにおいて、不正検知ECU100a、ECU400a、ECU400b及びゲートウェイ300はそれぞれメッセージIDを受信する(シーケンスS1002)。
ECU400a、ECU400b及びゲートウェイ300はそれぞれ、保持している受信IDリストを用いてメッセージIDをチェックする(シーケンスS1003)。このとき、不正検知ECU100aは、保持している正規IDリストを用いてメッセージIDをチェックする(シーケンスS1004)。即ち、不正検知ECU100aは、送信されたフレームにおけるIDフィールドの内容が、不正を示す所定条件(正規IDリストに掲載されていないこと)に該当するか否かを判定する。
シーケンスS1003において、ECU400a及びECU400bは、それぞれが保持している受信IDリストに「4」が含まれていないため(図9参照)、受信を終了する。つまりこれ以上不正なECUが送信を継続するフレームの解釈をせずフレームに対応した処理を行わない。また、シーケンスS1003においてゲートウェイ300は、保持している受信IDリストに「4」が含まれているため(図5参照)、受信を継続する。また、シーケンスS1004において不正検知ECU100aは、保持している正規IDリストに「4」が含まれていないため、不正なメッセージIDであると判断して、続いてエラーフレームの発行準備を開始する(シーケンスS1005)。
シーケンスS1003に続いて、ゲートウェイ300はフレームの受信を継続する。例えば、不正検知ECU100aがエラーフレームの発行準備をしている間に、不正なECUからはバス500a上にIDフィールドより後の部分であるRTR、コントロールフィールド(IDE、r、DLC)が逐次送出され、続いてデータフィールドが1ビットずつ逐次送出される。ゲートウェイ300はこのRTR、コントロールフィールド(IDE、r、DLC)を受信し、続いてデータフィールドの受信を開始する(シーケンスS1006)。
次にエラーフレームの発行準備が終わって、不正検知ECU100aがエラーフレームを送信する(シーケンスS1007)。このエラーフレームの送信は、不正なフレームの最後尾が送信される前(例えばCRCシーケンスの最後尾が送信される前等)に行われる。この動作例においては、データフィールドの途中で行われる。このエラーフレームの送信が開始されることによりバス500aでは、不正なECUから送信中のフレームのデータフィールドの途中部分がエラーフレーム(優先されるドミナントのビット列)により上書きされることになる。
シーケンスS1007において送信されたエラーフレームを受信したゲートウェイ300は、データフィールドの受信途中で不正なECUが送信していたフレームの受信を中止する(シーケンスS1008)。つまり、ゲートウェイ300は、不正なECUからのデータフィールドがエラーフレームで上書きされており、エラーフレームを検出するので、不正なECUが送信していたフレームの受信を継続しない。
不正検知ECU100aは、エラーフレームを送信する対象となったデータフレームのメッセージID「4」に対応する不正検知カウンタをインクリメントする(シーケンスS1009)。
インクリメントした結果としてメッセージID「4」に対応する不正検知カウンタが17以上となった場合、不正検知ECU100aは、ヘッドユニット200に受信されるようにエラー表示を通知するフレーム(エラー表示メッセージ)を送信する(シーケンスS1010)。この結果としてヘッドユニット200のフレーム処理部220によってエラー表示のための処理がなされLCD等を介してエラーが報知される。なお、エラーの報知は、LCD等への表示の他、音声出力、発光等によるものでも良い。
[1.19 実施の形態1の効果]
実施の形態1で示した不正検知ECUは、送信されたフレーム(データフレーム)が不正なフレームか否かを、フレームのIDフィールドについて正規IDリストを用いて判定する。これにより、データフレームにおけるIDフィールドによって不正を判定できるため、既存のノード(つまり不正検知ECU及び不正なECU以外のECU)において不正なフレームが解釈されてそのフレームに対応する処理が実行されることを阻止できる。また、データフレームの先頭のSOFに続くIDフィールドまで受信するだけで判定ができるため、データフレームの後部等を受信して判定を行う場合よりも、バスのトラフィックを抑えることが可能となる。
また、不正検知ECUが、不正検知カウンタを用いてエラーフレームを送信した回数をカウントすることで、エラーフレームの受信により不正なメッセージIDを送信するノードにおける送信エラーカウンタがCANプロトコルに従えばパッシブ状態に遷移すべき上限値まで到達していることを検出することができる。これにより、不正なメッセージIDを送信するノードが、CANプロトコルのエラーカウンタの仕様に準拠しているか否かを判定することが可能となる。
また、不正なフレームの判定を行うノードを不正検知ECUのみとすることで、既存のネットワーク構成への影響を最小限に抑えることができ、システム全体として処理量、消費電力量を抑えることができる。
(実施の形態2)
以下、本開示の実施の形態として、メッセージID毎に許容されるデータ範囲に基づいて、他のノード(ECU)において不正なフレームに基づく処理が実行されることを阻止するための不正対処方法を実現する不正検知ECUを含む車載ネットワークシステム11について説明する。
[2.1 車載ネットワークシステム11の全体構成]
図19は、実施の形態2に係る車載ネットワークシステム11の全体構成を示す図である。車載ネットワークシステム11は、実施の形態1で示した車載ネットワークシステム10の一部を変形したものである。車載ネットワークシステム11は、バス500a、500bと、不正検知ECU2100a、2100b、ヘッドユニット200、ゲートウェイ300、及び、各種機器に接続されたECU400a〜400d等のECUといったバスに接続された各ノードとを含んで構成される。車載ネットワークシステム11の構成要素のうち、実施の形態1と同様の機能を有する構成要素は、同じ符号を付して説明を省略する。
不正検知ECU2100a、2100bは、それぞれバス500a、バス500bに接続され、ECU400a〜400d等により送信されたフレームが不正であるかどうかを判定し、不正であればエラーフレームを送信する機能を有するECUである。
[2.2 不正検知ECU2100aの構成]
図20は、不正検知ECU2100aの構成図である。不正検知ECU2100aは、フレーム送受信部160と、フレーム解釈部2150と、不正フレーム検知部2130と、データ範囲リスト保持部2120と、不正検知カウンタ保持部110と、フレーム生成部140とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、不正検知ECU2100aにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。不正検知ECU2100aは、実施の形態1で示した不正検知ECU100aの一部を変形したものであり、実施の形態1と同様の機能を有する構成要素は、同じ符号を付して説明を省略する。なお、不正検知ECU2100bも不正検知ECU2100aと同様の構成を備える。
フレーム解釈部2150は、実施の形態1で示したフレーム解釈部150を変形したものであり、フレーム送受信部160よりフレームの値を受け取り、CANプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。フレームがデータフレームであると判断した場合においてデータフィールドと判断した値(データ)は、IDフィールドのID(メッセージID)と共に、不正フレーム検知部2130へ転送する。また、フレーム解釈部2150は、CANプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部140へ通知する。また、フレーム解釈部2150は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。
不正フレーム検知部2130は、実施の形態1で示した不正フレーム検知部130を変形したものであり、フレーム解釈部2150から通知されるメッセージIDと、データフィールドの値(データ)を受け取り、これらの値が不正を示す所定条件に該当するか否かを判定する。即ち不正フレーム検知部2130は、受信されたフレームにおける所定フィールドの内容が不正を示す所定条件に該当するか否かを判定する言わば判定部として機能する。この不正を示す所定条件は、データが、データ範囲リスト保持部2120が保持しているデータ範囲リストにメッセージIDと対応付けて載っているデータ範囲に入らないという条件である。不正フレーム検知部2130は、データ範囲リスト保持部2120に保持しているメッセージID毎のデータ範囲を定めたリストであるデータ範囲リストに従い、不正かどうかの判定を行う。不正フレーム検知部2130は、データ範囲リストで示される範囲以外のデータを受信した場合は、不正の検知回数をインクリメントするために、受信したメッセージIDを不正検知カウンタ保持部110へ通知する。この不正の検知回数が一定回数以上に達した場合において、ヘッドユニット200で受信されるようにエラー表示メッセージを送信するための制御については実施の形態1で説明した通りであるため、ここでの説明を省略する。また、データ範囲リストで示される範囲以外のデータを受信した場合は、エラーフレームを送信するように、フレーム生成部140へ通知する。
データ範囲リスト保持部2120は、車載ネットワークシステム11においてバス上を送信されるデータフレームに含まれるデータ(データフィールドの値)について許容される範囲を予め規定したリストであるデータ範囲リストを保持する(図21参照)。
[2.3 データ範囲リスト例]
図21は、不正検知ECU2100aのデータ範囲リスト保持部2120に保持されるデータ範囲リストの一例を示した図である。このデータ範囲リストは、各ID(メッセージID)と、そのメッセージIDのデータフレームにおけるデータフィールドの値(データ)として許容されるデータ範囲とを対応付けたものである。図21の例では、メッセージIDが「1」のデータフレームについては、データ範囲「0〜180」、メッセージIDが「2」又は「4」のデータフレームについては、データ範囲「0〜100」、メッセージIDが「3」のデータフレームについて、データ範囲「0、1」をそれぞれ正常としている。
[2.4 不正フレームの検知に係るシーケンス]
以下、上述の構成を備える車載ネットワークシステム11のバス500aに不正なECUが接続された場合について、バス500aに接続された不正検知ECU2100a、ECU400a、ECU400b、ゲートウェイ300等の動作について説明する。
図22及び図23は、不正検知ECU2100aが不正なフレーム(メッセージ)を検知して、他のECUによりその不正なフレームに対応した処理がなされることを阻止する動作例を示すシーケンス図である。図22及び図23では、実施の形態1で示した図18の場合と同様に、不正なECUが、バス500aにメッセージIDが「4」でデータフィールド(データ)が「255(0xFF)」となるデータフレームを送信する場合の例を示している。実施の形態1で示したシーケンスと同じシーケンスには同じ符号を付しており、ここでは説明を簡略化する。
まず、不正なECUは、不正なデータフレームの送信を開始する(シーケンスS1001)。不正検知ECU2100a、ECU400a、ECU400b及びゲートウェイ300はそれぞれメッセージIDを受信する(シーケンスS1002)。ECU400a、ECU400b及びゲートウェイ300はそれぞれ、保持している受信IDリストを用いてメッセージIDをチェックする(シーケンスS1003)。ECU400a及びECU400bは、それぞれが保持している受信IDリストに「4」が含まれていないため(図9参照)、受信を終了する。ゲートウェイ300は、保持している受信IDリストに「4」が含まれているため(図5参照)、受信を継続しデータフィールドの受信を行う(シーケンスS1006a)。同様に不正検知ECU2100aもデータフィールドの受信を行う(シーケンスS1006a)。
シーケンスS1006aに続いて、不正検知ECU2100aは、データ範囲リスト(図21参照)を用いて、データフィールドのデータをチェックする(シーケンスS2001)。即ち、不正検知ECU2100aは、送信されたフレームにおけるIDフィールドの内容が、不正を示す所定条件(データ範囲リストに記載されているデータの範囲に入らないこと)に該当するか否かを判定する。不正検知ECU2100aは、データ範囲リストにおいてID「4」に対応する「255(0xFF)」の値が記載されていないため、不正なデータフレームであると判断し、続いてエラーフレームの発行準備を開始する(シーケンスS1005)。
不正検知ECU2100aがエラーフレームの発行準備をしている間に、不正なECUからはバス500a上にデータフィールドより後の部分であるCRCフィールド(CRCシーケンス及びCRCデリミタ)が1ビットずつ逐次送出される。ゲートウェイ300はこのCRCフィールドの受信を開始する(シーケンスS2002)。
次にエラーフレームの発行準備が終わって、不正検知ECU2100aがエラーフレームを送信する(シーケンスS1007)。このエラーフレームの送信が開始されることによりバス500aでは、不正なECUから送信中のフレームのCRCシーケンスの途中部分がエラーフレーム(優先されるドミナントのビット列)により上書きされることになる。
シーケンスS1007において送信されたエラーフレームを受信したゲートウェイ300は、CRCシーケンスを含むCRCフィールドの受信途中で、不正なECUが送信していたデータフレームの受信を中止する(シーケンスS2003)。つまり、ゲートウェイ300は、不正なECUからのCRCシーケンスがエラーフレームで上書きされており、エラーフレームを検出するので、不正なECUが送信していたデータフレームの受信を継続しない。
不正検知ECU2100aは、エラーフレームを送信する対象となったデータフレームのID「4」に対応する不正検知カウンタをインクリメントする(シーケンスS1009)。インクリメントした結果としてID「4」に対応する不正検知カウンタが17以上となった場合、不正検知ECU2100aは、エラー表示メッセージを送信する(シーケンスS1010)。
[2.5 実施の形態2の効果]
実施の形態2で示した不正検知ECUは、送信されたフレームが不正なフレームか否かを、フレーム(データフレーム)のIDフィールド及びデータフィールドについてデータ範囲リストを用いて判定する。これにより、データフレームにおけるIDフィールドとデータフィールドとの組み合わせによって不正を判定できるため、既存のECU(つまり不正検知ECU及び不正なECU以外のECU)において不正なフレームが解釈されてそのフレームに対応する処理が実行されることを阻止することができる。また、データフレームのデータフィールドまで受信するだけで判定ができるため、データフレームの後部を受信して判定を行う場合よりも、バスのトラフィックを抑えることが可能となる。
また、不正検知ECUが、不正検知カウンタを用いてエラーフレームを送信した回数をカウントすることで、エラーフレームの受信により不正なメッセージIDを送信するノードにおける送信エラーカウンタがCANプロトコルに従えばパッシブ状態に遷移すべき上限値まで到達していることを検出することができる。これにより、不正なメッセージIDを送信するノードが、CANプロトコルのエラーカウンタの仕様に準拠しているか否かを判定することが可能となる。
また、不正なフレームの判定を行うノードを不正検知ECUのみとすることで、既存のネットワーク構成への影響を最小限に抑えることができ、システム全体として処理量、消費電力量を抑えることができる。
(実施の形態3)
以下、本開示の実施の形態として、メッセージID、データ及びカウンタ値から算出されるメッセージ認証コード(MAC:Message Authentication Code)を用いて、他のノード(ECU)において不正なフレームに基づく処理が実行されることを阻止するための不正対処方法を実現する不正検知ECUを含む車載ネットワークシステム12について説明する。
[3.1 車載ネットワークシステム12の全体構成]
図24は、実施の形態3に係る車載ネットワークシステム12の全体構成を示す図である。車載ネットワークシステム12は、実施の形態1で示した車載ネットワークシステム10の一部を変形したものである。車載ネットワークシステム12は、バス500a、500bと、不正検知ECU3100a、3100b、ヘッドユニット200、ゲートウェイ300、及び、各種機器に接続されたECU3400a〜3400d等のECUといったバスに接続された各ノードとを含んで構成される。車載ネットワークシステム12の構成要素のうち、実施の形態1と同様の機能を有する構成要素は、同じ符号を付して説明を省略する。
不正検知ECU3100a、3100bは、それぞれバス500a、バス500bに接続され、ECU3400a〜3400d等により送信されたフレームが不正であるかどうかを判定し、不正であればエラーフレームを送信する機能を有するECUである。
ECU3400a〜3400dは、いずれかのバスと接続され、また、それぞれエンジン401、ブレーキ402、ドア開閉センサ403、窓開閉センサ404に接続されている。ECU3400a〜3400dのそれぞれは、接続されている機器(エンジン401等)の状態を取得し、定期的に状態を表すデータフレームをネットワーク(つまりバス)に送信している。送信されるデータフレームのデータフィールドには、メッセージIDとデータ値と送信毎にインクリメントされるカウンタ値とから計算により導出されるメッセージ認証コード(MAC)が付与される。
[3.2 ECU3400aの構成]
図25は、ECU3400aの構成図である。ECU3400aは、フレーム送受信部460と、フレーム解釈部450と、受信ID判断部430と、受信IDリスト保持部440と、フレーム処理部410と、フレーム生成部3420と、データ取得部470と、MAC生成部3410と、MAC鍵保持部3430と、カウンタ保持部3440とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、ECU3400aにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。ECU3400aは、実施の形態1で示したECU400aの一部を変形したものであり、実施の形態1と同様の機能を有する構成要素は、同じ符号を付して説明を省略する。
フレーム生成部3420は、実施の形態1で示したフレーム生成部420の一部を変形したものである。フレーム生成部3420は、フレーム解釈部450から通知されたエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部460へ通知して送信させる。また、フレーム生成部3420は、データ取得部470より通知されたデータの値と予め定められたメッセージIDとをMAC生成部3410へ通知して、算出されたMACを受け取る。フレーム生成部3420は、予め定められたメッセージIDとデータ取得部470より通知されたデータの値とMAC生成部3410から受け取ったMACとを含むようにフレームを構成し(図26参照)、フレーム送受信部460へ通知する。
MAC生成部3410は、フレーム生成部3420より通知されるメッセージIDとデータの値と、カウンタ保持部3440で保持するカウンタ値とを結合した値(結合値)に対し、MAC鍵保持部3430で保持するMAC鍵を用いて、MACを算出(計算により導出)して、この算出した結果であるMACをフレーム生成部3420へと通知する。ここではMACの計算方法として、HMAC(Hash-based Message Authentication Code)(非特許文献2参照)を採用し、上述した結合値に対し、所定のブロック分(例えば4Bytes)までパディングした値でMAC鍵を使って計算し、出てきた計算結果の先頭4bytesをMACとする。なお、ここでは、MACを算出するために用いる結合値は、メッセージIDとデータの値とカウンタ保持部3440で保持するカウンタ値とを使用しているが、これらの3つのうち、いずれか1つ又は2つの組み合わせを用いてMACを算出しても良い。
MAC鍵保持部3430は、MACを計算するため必要となるMAC鍵を保持する。
カウンタ保持部3440は、MACを計算するために必要となるカウンタ値を保持する。なお、このカウンタ値は、フレーム送受信部460においてデータフレームが正常に送信された度にインクリメントされる。
なお、ECU3400b〜3400dは、それぞれ実施の形態1で示したECU400b〜400dの一部を変形したものであり、上述したECU3400と基本的に同様の構成を備える。但し、受信IDリスト保持部440に保持される受信IDリストはECU毎に異なる内容となり得る。例えばECU3400a及びECU3400bは図9に例示する受信IDリストを保持し、ECU3400c及びECU3400dは図5に例示する受信IDリストを保持する。また、フレーム処理部410の処理内容は、実施の形態1で示したようにECU毎に異なる。以下、ECU3400a〜3400dのそれぞれが送信するフレームの内容について図26〜図29を用いて説明する。
[3.3 エンジンに係るECU3400aの送信フレーム例]
図26は、エンジン401に接続されたECU3400aから送信されるデータフレームにおけるID(メッセージID)及びデータフィールド(データ)の一例を示す図である。ECU3400aが送信するフレームのメッセージIDは「1」である。データは、同図において1バイト毎に空白で区分して表しており、先頭の1byteが時速(km/時)を表し、次の1byteはカウンタ値を表し、次の4bytesがMACを表す。なお、図26の例においてMACは16進数で表記している。先頭1byteの時速(km/時)は、最低0(km/時)〜最高180(km/時)までの範囲の値を取る。図26の上行から下行へと、ECU3400aから逐次送信される各フレームに対応する各メッセージID及びデータを例示しており、カウンタ値が次第に増加し、時速が0km/時から1km/時ずつ加速されている様子を表している。
[3.4 ブレーキに係るECU3400bの送信フレーム例]
図27は、ブレーキ402に接続されたECU3400bから送信されるデータフレームにおけるID(メッセージID)及びデータフィールド(データ)の一例を示す図である。ECU3400bが送信するフレームのメッセージIDは「2」である。データは、同図において1バイト毎に空白で区分して表しており、先頭の1byteがブレーキのかかり具合を割合(%)で表し、次の1byteはカウンタ値を表し、次の4bytesがMACを表す。なお、図27の例においてMACは16進数で表記している。先頭1byteのブレーキのかかり具合は、ブレーキを全くかけていない状態を0(%)、ブレーキを最大限かけている状態を100(%)としたものである。図27の上行から下行へと、ECU3400bから逐次送信される各フレームに対応する各メッセージID及びデータを例示しており、カウンタ値が次第に増加し、ブレーキについては100%から徐々にブレーキを弱めている様子を表している。
[3.5 ドア開閉センサに係るECU3400cの送信フレーム例]
図28は、ドア開閉センサ403に接続されたECU3400cから送信されるデータフレームにおけるID(メッセージID)及びデータフィールド(データ)の一例を示す図である。ECU3400cが送信するフレームのメッセージIDは「3」である。データは、同図において1バイト毎に空白で区分して表しており、先頭の1Byteがドアの開閉状態を表し、次の1byteはカウンタ値を表し、次の4bytesがMACを表す。なお、図28の例においてMACは16進数で表記している。先頭1byteのドアの開閉状態は、ドアが開いている状態を「1」、ドアが閉まっている状態を「0」としたものである。図28の上行から下行へと、ECU3400cから逐次送信される各フレームに対応する各メッセージID及びデータを例示しており、カウンタ値が次第に増加し、ドアが開いている状態から次第に閉められた状態へと移った様子を表している。
[3.6 窓開閉センサに係るECU3400dの送信フレーム例]
図29は、窓開閉センサ404に接続されたECU3400dから送信されるデータフレームにおけるID(メッセージID)及びデータフィールド(データ)の一例を示す図である。ECU3400dが送信するフレームのメッセージIDは「4」である。データは、同図において1バイト毎に空白で区分して表しており、先頭の1Byteが窓の開閉状態を割合(%)で表し、次の1byteはカウンタ値を表し、次の4bytesがMACを表す。なお、図29の例においてMACは16進数で表記している。先頭1byteの窓の開閉状態は、窓が完全に閉まっている状態を0(%)、窓が全開の状態を100(%)としたものである。図29の上行から下行へと、ECU3400dから逐次送信される各フレームに対応する各メッセージID及びデータを例示しており、カウンタ値が次第に増加し、窓が閉まっている状態から徐々に開いていく様子を表している。
[3.7 不正検知ECU3100aの構成]
図30は、不正検知ECU3100aの構成図である。不正検知ECU3100aは、フレーム送受信部160と、フレーム解釈部3150と、不正MAC検知部3130と、MAC鍵保持部3180と、カウンタ保持部3190と、フレーム生成部140と、MAC生成部3170と、不正検知カウンタ保持部110から構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、不正検知ECU3100aにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。不正検知ECU3100aは、実施の形態1で示した不正検知ECU100aの一部を変形したものであり、実施の形態1と同様の機能を有する構成要素は、同じ符号を付して説明を省略する。なお、不正検知ECU3100bも同様の構成である。
フレーム解釈部3150は、実施の形態1で示したフレーム解釈部150を変形したものであり、フレーム送受信部160よりフレームの値を受け取り、CANプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。フレームがデータフレームであると判断した場合においてデータフィールドと判断した値(データ)は、IDフィールドのID(メッセージID)と共に、不正MAC検知部3130へ転送する。また、フレーム解釈部3150は、CANプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部140へ通知する。また、フレーム解釈部3150は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。
不正MAC検知部3130は、フレーム解釈部3150から通知されるメッセージIDと、データフィールドの値(データ)を受け取ってデータフィールド中のMACを検証する機能を有する。不正MAC検知部3130は、通知されたメッセージID及びデータフィールドの値を、MAC生成部3170へと通知し、MAC生成部3170により生成されたMACを取得する。不正MAC検知部3130は、データフィールドのデータが不正を示す所定条件に該当するか否かを判定する。即ち不正MAC検知部3130は、受信されたフレームにおける所定フィールドの内容が不正を示す所定条件に該当するか否かを判定する言わば判定部として機能する。この不正を示す所定条件は、定められた検証処理手順(MACの生成、MACの比較等を含む手順)での検証に失敗することであり、つまり、データに含まれるMACが、MAC生成部3170により生成されたMACと相違するという条件である。不正MAC検知部3130は、MAC生成部3170から取得したMACと、データフィールド中のMACとを比較することで、不正かどうかの判定(即ちMACの検証)を行う。両MACの値の比較の結果、不一致の場合は、不正の検知回数をインクリメントするために、受信したメッセージIDを不正検知カウンタ保持部110へ通知する。この不正の検知回数が一定回数以上に達した場合において、ヘッドユニット200で受信されるようにエラー表示メッセージを送信するための制御については実施の形態1で説明した通りであるため、ここでの説明を省略する。また、両MACの値の比較の結果、不一致の場合は、エラーフレームを送信するように、フレーム生成部140へ通知する。MAC値の比較の結果、一致する場合は、カウンタ保持部3190が保持する、メッセージIDに対応するカウンタ値をインクリメントするようにMAC生成部3170へ通知する。
MAC生成部3170は、不正MAC検知部3130より通知されたメッセージIDを使って、MAC鍵保持部3180より、対応するMAC鍵を取得し、カウンタ保持部3190より対応するカウンタをそれぞれ取得する。MAC生成部3170は、不正MAC検知部3130より通知されたデータフィールドの値(先頭1Byteの値)と、カウンタ保持部3190より取得したカウンタ値に対して、MAC鍵保持部3180より取得したMAC鍵を使ってMACを算出(計算により導出)し、算出したMACを不正MAC検知部3130へ通知する。なお、不正検知ECU3100a、3100b及びECU3400a〜3400dのいずれにおいても、MAC鍵を用いてMACを算出するアルゴリズムは同一のものを用いる。
MAC鍵保持部3180は、MACを計算するため必要となるMAC鍵をメッセージID毎に対応付けて保持する。このMAC鍵保持部3180が保持するMAC鍵は、対応付けられたメッセージID毎に異なる値である。なお、ECU及び不正検知ECUにおいて用いられるMAC鍵は、1つの送信ノードが複数のメッセージIDそれぞれのフレームを送信する場合を想定すると、送信ノード毎に異なる鍵であることとしても良い。また、MAC鍵は、例えば同一のバス上で送信されるフレームに同一の値が用いられるようにしても良いし、異なるバス上であっても同一の鍵(値)としても良いし、車一台あたり同一の鍵としても良く、同一車種で同一の鍵としても良く、同一製造メーカ毎に同一の鍵としても良く、異なる製造メーカであっても同一の鍵としても良い。
カウンタ保持部3190は、MAC値を計算するために必要となるカウンタ値をメッセージID毎に保持する。このカウンタ値は、フレームを正常に受信した場合(つまり不正MAC検知部3130において比較した両MACが一致する場合)には、インクリメントされる。
[3.8 カウンタ値の例]
図31は、カウンタ保持部3190に保持されているメッセージID毎のカウンタ値の一例を示す図である。同図では、メッセージIDが「1」のカウンタが1回、メッセージIDが「2」のカウンタが10回、メッセージIDが「3」のカウンタが15回、メッセージIDが「4」のカウンタが100回をそれぞれ示している。この各メッセージIDに対応するカウンタ値は、そのメッセージIDを含むフレームが正常に受信されている回数を表している。
[3.9 不正フレームの検知に係るシーケンス]
以下、上述の構成を備える車載ネットワークシステム12のバス500aに不正なECUが接続された場合について、バス500aに接続された不正検知ECU3100a、ECU3400a、ECU3400b、ゲートウェイ300等の動作について説明する。
図32及び図33は、不正検知ECU3100aが不正なフレーム(メッセージ)を検知して、他のECUによりその不正なフレームに対応した処理がなされることを阻止する動作例を示すシーケンス図である。図32及び図33では、実施の形態1で示した図18並びに実施の形態2で示した図22及び図23の場合と同様に、不正なECUが、バス500aに接続された例を示している。この不正なECUは、メッセージIDが「4」でデータフィールド(データ)が「0xFF FF FFFFFFFF」(6Byte)となるデータフレームを送信する。実施の形態1又は2で示したシーケンスと同じシーケンスには同じ符号を付しており、ここでは説明を簡略化する。
まず、不正なECUは、上述した不正なデータフレームの送信を開始する(シーケンスS1001a)。不正検知ECU3100a、ECU3400a、ECU3400b及びゲートウェイ300はそれぞれメッセージIDを受信する(シーケンスS1002)。ECU3400a、ECU3400b及びゲートウェイ300はそれぞれ、保持している受信IDリストを用いてメッセージIDをチェックする(シーケンスS1003)。ECU3400a及びECU3400bは、それぞれが保持している受信IDリストに「4」が含まれていないため(図9参照)、受信を終了する。ゲートウェイ300は、保持している受信IDリストに「4」が含まれているため(図5参照)、受信を継続しデータフィールドの受信を行う(シーケンスS1006a)。同様に不正検知ECU3100aもデータフィールドの受信を行う(シーケンスS1006a)。
シーケンスS1006aに続いて、不正検知ECU3100aは、データフィールドにおけるデータに含まれるMACを検証(チェック)する(シーケンスS3001)。即ち、不正検知ECU3100aは、送信されたフレームにおけるIDフィールドの内容が、不正を示す所定条件(MACの検証に失敗すること)に該当するか否かを判定する。不正検知ECU3100aは、不正なECUにより送信されたデータフレームにおけるデータフィールドの6Byteのデータ「0xFFFFFFFF」について、後半4ByteのMACと、メッセージID「4」に対応するMAC鍵とカウンタを用いて算定したMACとを比較することでMACの検証を行う。この比較の結果は不一致になり検証が失敗するので、不正検知ECU3100aでは、不正なデータフレームであると判断し、続いてエラーフレームの発行準備を開始する(シーケンスS1005)。
不正検知ECU3100aがエラーフレームの発行準備をしている間に、ゲートウェイ300はCRCフィールドの受信を開始する(シーケンスS2002)。
次にエラーフレームの発行準備が終わって、不正検知ECU3100aがエラーフレームを送信する(シーケンスS1007)。このエラーフレームの送信が開始されることによりバス500aでは、不正なECUから送信中のフレームのCRCシーケンスの途中部分がエラーフレームにより上書きされることになる。
シーケンスS1007において送信されたエラーフレームを受信したゲートウェイ300は、CRCシーケンスを含むCRCフィールドの受信途中で、不正なECUが送信していたデータフレームの受信を中止する(シーケンスS2003)。
不正検知ECU3100aは、エラーフレームを送信する対象となったデータフレームのID「4」に対応する不正検知カウンタをインクリメントする(シーケンスS1009)。インクリメントした結果としてID「4」に対応する不正検知カウンタが17以上となった場合、不正検知ECU3100aは、エラー表示メッセージを送信する(シーケンスS1010)。
[3.10 実施の形態3の効果]
実施の形態3で示した不正検知ECUは、送信されたフレームが不正なフレームか否かを、フレーム(データフレーム)のデータフィールドに含ませたMACを検証することによって判定する。これにより、既存のECU(つまり不正検知ECU及び不正なECU以外のECU)において不正なフレームが解釈されてそのフレームに対応する処理が実行されることを阻止することができる。また、データフレームのデータフィールドまで受信するだけで判定ができるため、データフレームの後部を受信して判定を行う場合よりも、バスのトラフィックを抑えることが可能となる。
また、不正検知ECUが、不正検知カウンタを用いてエラーフレームを送信した回数をカウントすることで、エラーフレームの受信により不正なメッセージIDを送信するノードにおける送信エラーカウンタがCANプロトコルに従えばパッシブ状態に遷移すべき上限値まで到達していることを検出することができる。これにより、不正なメッセージIDを送信するノードが、CANプロトコルのエラーカウンタの仕様に準拠しているか否かを判定することが可能となる。
また、MACの検証を行うノードを不正検知ECUのみとすることで、不正検知ECU以外のECUで検証する必要がなく、システム全体として処理量、消費電力量を抑えることができる。
(他の実施の形態)
以上のように、本開示に係る技術の例示として実施の形態1〜3を説明した。しかしながら、本開示に係る技術は、これに限定されず、適宜、変更、置き換え、付加、省略等を行った実施の形態にも適用可能である。例えば、以下のような変形例も本開示の一実施態様に含まれる。
(1)上記実施の形態では、ECU400a〜400d或いはECU3400a〜3400dによりフレームが定期的に送信される例を示したが、フレームは、状態変化を通知するイベントとして送信されることとしても良い。例えば、ECUは、ドアの開閉状態を定期的に送信するのではなく、ドアの開閉状態が変化した場合にのみ、フレームを送信するとしても良い。また、ECUがフレームを、定期的に送信、かつ、状態変化が発生した時に送信することとしても良い。
(2)実施の形態3では、データ値とカウンタ値からMACを算出する例を示したが、データ値のみからMACを算出することとしても良い。またカウンタ値のみからMACを算出することとしても良い。また、フレームに含まれるMACのサイズは4bytesに制限されるものではなく、送信毎に異なるサイズであっても良い。同様に時速等のデータ値のサイズ及びカウンタ値のサイズも1byteに制限されるものではない。また、必ずしもフレームにカウンタ値が含まれていなくても良い。
(3)実施の形態3では、カウンタ値を送信毎にインクリメントする例を示したが、カウンタ値が時刻に応じて自動的にインクリメントされる値であっても良い。また、時刻そのものの値をカウンタの代わりに使用しても良い。即ち、データフレームが送信される度に変化する変数(カウンタ、時刻等)に基づいてMACが生成されるようにすると、MACの不正な解読を困難化することが可能となる。また、実施の形態3では、不正検知ECUにおけるMAC生成部3170が、メッセージIDとデータフィールドの先頭1Byteと、カウンタ保持部3190のカウンタ値とからMAC値を算出することとした。この代わりに、メッセージIDとデータフィールドの先頭1Byteと、データフィールドの次の1Byteであるカウンタ値とからMAC値を算出することとしても良い。また、不正ではないと判定されたデータフィールドにおけるカウンタ値に合わせるように、カウンタ保持部3190のカウンタ値を更新することとしても良い。
(4)上記実施の形態では、CANプロトコルにおけるデータフレームを標準IDフォーマットで記述しているが、拡張IDフォーマットで合っても良い。拡張IDフォーマットの場合には、標準IDフォーマットにおけるID位置のベースIDと、拡張IDとを合わせて29ビットでID(メッセージID)を表すので、この29ビットのIDを上述の実施の形態におけるID(メッセージID)と扱えば良い。
(5)上記実施の形態では、MAC算出のアルゴリズムをHMACとしているが、これCBC−MAC(Cipher Block Chaining Message Authentication Code)、CMAC((Cipher-based MAC)であっても良い。また、MAC計算に用いられるパディングについては、ゼロパディング、ISO10126、PKCS#1、PKCS#5、PKCS#7、その他、ブロックのデータサイズが計算に必要となるパディングの方式であれば何でも良い。また4bytes等のブロックへのサイズの変更方法についても、先頭、最後尾、中間のいずれの部分にパディングを行っても良い。また、MAC算出に用いるデータは、連続しているデータ(例えば4bytes分の連続データ)でなくても、特定のルールに従って1bitずつ収集して結合したものでも良い。
(6)上記実施の形態では、CANプロトコルに従って通信するネットワーク通信システムの例として車載ネットワークを示した。本開示に係る技術は、車載ネットワークに限定されるものではなく、ロボット、産業機器等のネットワークその他、車載ネットワーク以外のCANプロトコルに従って通信するネットワーク通信システムにも適用可能である。また、CANプロトコルは、オートメーションシステム内の組み込みシステム等に用いられるCANOpen、或いは、TTCAN(Time-Triggered CAN)、CANFD(CAN with Flexible Data Rate)等の派生的なプロトコルも包含する広義の意味のものと扱われるべきである。
(7)上記実施の形態では、不正なECUがバスに接続される例を示したが、ECU400a〜400d或いはECU3400a〜3400dのような既存のECUが何らかの要因によって不正なECUとして働く可能性もある。その場合であっても、上記実施の形態で示したように不正検知ECUが適切に不正なフレームを検知してエラーフレームを送信することで、他のECUが不正なフレームを処理してしまうことを阻止できる。
(8)実施の形態2では、メッセージIDと許容されているデータ範囲とが対応付けられたデータ範囲リストを用いて、受信されたデータフレームのデータが、メッセージID毎に許容されているデータ範囲に含まれているか否かによって、不正か否かの判定を行うこととしたが、データ範囲リストにメッセージIDを含ませず、全てのメッセージIDに共通して許容されているデータ範囲(例えば「0〜180」)を定めておき、メッセージIDにかかわらず不正か否かの判定を行うこととしても良い。また、不正検知ECUが保持するデータ範囲リストは、その不正検知ECUが接続されたバスにおいて送信され得るメッセージIDとデータ範囲とを対応付けたものとしても良い。これにより、データ範囲リストが、実施の形態1で示した正規IDリストとしても用いることができるようになる。これを利用して実施の形態2に示した不正検知ECUにおいても実施の形態1で示したメッセージIDのチェック(シーケンスS1004)を行うようにしても良い。
(9)実施の形態2で示したメッセージIDと許容されているデータ範囲とが対応付けられたデータ範囲リストの代わりに、不正検知ECUが、メッセージIDと、許容されているデータ長とを対応付けたデータ長リストを用いることとしても良い。この場合には、不正検知ECUは、受信されたデータフレームのコントロールフィールドの値が不正を示す所定条件に該当するか否かを判定する。この不正を示す所定条件は、コントロールフィールドにおけるデータ長(DLC)が、データ長リストにおいてメッセージIDに対応付けられているデータ長ではないという条件である。不正検知ECUは、受信されたDCLが、データ長リストにおいてメッセージID毎に許容されているデータ長であるか否かによって、不正か否かの判定を行う。
(10)上記実施の形態では、特にデータフレームに注目して説明したが、リモートフレームについても不正検知ECUが一定の不正を検知することが可能である。例えば、不正検知ECUが、実施の形態1で示した正規IDリストを用いて受信したリモートフレームにおけるメッセージIDが不正か否かを判定しても良い。また、不正検知ECUが、上述したデータ長リストを用いて受信したリモートフレームにおけるコントロールフィールドにおけるデータ長(DLC)が、メッセージID毎に許容されているデータ長であるか否かにより不正か否かを判定しても良い。また、上記実施の形態で示した不正検知ECUが不正なフレームを受信することで不正の検知を行った場合に送信するエラーフレームは、不正の検知後に迅速に送信されると良い。なお、不正検知ECUは、不正の検知後、その不正なフレームのCRCシーケンスの最後尾が送信される前までにエラーフレームを送信することは有用である。これにより他のECUは、エラーフレームの検出或いはCRCのチェックでのエラー検出により、その不正なフレームの処理を中止することになる。なお、リモートフレームもデータフレームと同様にメッセージID、コントロールフィールド及びCRCシーケンスを含む。
(11)上記実施の形態では、不正検知ECUが一定条件下でエラー表示メッセージを送信することを示したが、エラー表示メッセージを送信しないこととしても良い。この場合には、ゲートウェイ及びヘッドユニット等のECUは特に不正検知ECUに対応した構成(エラー表示メッセージを受信するための受信IDリスト等)を保持する必要がなくなる。なお、不正検知ECUは、エラー表示メッセージの送信の代わりに自らスピーカ或いはディスプレイ等を備える場合においてエラーを自ら報知しても良いし、エラーのログを記憶媒体等に記録しても良い。
(12)上記実施の形態で示した不正フレーム検知部及び不正MAC検知部はCANコントローラと呼ばれるハードウェア、または、CANコントローラと接続して動作するプロセッサ上で動作するファームウェアに実装しても良い。また、MAC鍵保持部、カウンタ保持部、正規IDリスト保持部、データ範囲リスト保持部は、CANコントローラと呼ばれるハードウェアのレジスタ、または、CANコントローラと接続して動作するプロセッサ上で動作するファームウェアに格納されていても良い。
(13)上記実施の形態における各ECU(ゲートウェイ及びヘッドユニットを含む)は、例えば、プロセッサ、メモリ等のデジタル回路、アナログ回路、通信回路等を含む装置であることとしたが、ハードディスク装置、ディスプレイ、キーボード、マウス等の他のハードウェア構成要素を含んでいても良い。また、メモリに記憶された制御プログラムがプロセッサにより実行されてソフトウェア的に機能を実現する代わりに、専用のハードウェア(デジタル回路等)によりその機能を実現することとしても良い。
(14)上記実施の形態における各装置を構成する構成要素の一部または全部は、1個のシステムLSI(Large Scale Integration:大規模集積回路)から構成されているとしても良い。システムLSIは、複数の構成部を1個のチップ上に集積して製造された超多機能LSIであり、具体的には、マイクロプロセッサ、ROM、RAM等を含んで構成されるコンピュータシステムである。前記RAMには、コンピュータプログラムが記録されている。前記マイクロプロセッサが、前記コンピュータプログラムに従って動作することにより、システムLSIは、その機能を達成する。
また、上記各装置を構成する構成要素の各部は、個別に1チップ化されていても良いし、一部又はすべてを含むように1チップ化されても良い。
また、ここでは、システムLSIとしたが、集積度の違いにより、IC、LSI、スーパーLSI、ウルトラLSIと呼称されることもある。また、集積回路化の手法はLSIに限るものではなく、専用回路又は汎用プロセッサで実現しても良い。LSI製造後に、プログラムすることが可能なFPGA(Field Programmable Gate Array)や、LSI内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用しても良い。
さらには、半導体技術の進歩又は派生する別技術によりLSIに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行っても良い。バイオ技術の適用等が可能性としてあり得る。
(15)上記各装置を構成する構成要素の一部または全部は、各装置に脱着可能なICカードまたは単体のモジュールから構成されているとしても良い。前記ICカードまたは前記モジュールは、マイクロプロセッサ、ROM、RAM等から構成されるコンピュータシステムである。前記ICカードまたは前記モジュールは、上記の超多機能LSIを含むとしても良い。マイクロプロセッサが、コンピュータプログラムに従って動作することにより、前記ICカードまたは前記モジュールは、その機能を達成する。このICカードまたはこのモジュールは、耐タンパ性を有するとしても良い。
(16)本開示の一態様としては、上記に示す不正対処方法等の方法であるとしても良い。また、これらの方法をコンピュータにより実現するコンピュータプログラムであるとしても良いし、前記コンピュータプログラムからなるデジタル信号であるとしても良い。
また、本開示の一態様としては、前記コンピュータプログラムまたは前記デジタル信号をコンピュータ読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、CD−ROM、MO、DVD、DVD−ROM、DVD−RAM、BD(Blu−ray(登録商標) Disc)、半導体メモリ等に記録したものとしても良い。また、これらの記録媒体に記録されている前記デジタル信号であるとしても良い。
また、本開示の一態様としては、前記コンピュータプログラムまたは前記デジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしても良い。
また、本開示の一態様としては、マイクロプロセッサとメモリを備えたコンピュータシステムであって、前記メモリは、上記コンピュータプログラムを記録しており、前記マイクロプロセッサは、前記コンピュータプログラムに従って動作するとしても良い。
また、前記プログラムまたは前記デジタル信号を前記記録媒体に記録して移送することにより、または前記プログラムまたは前記デジタル信号を、前記ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしても良い。
(17)上記実施の形態及び上記変形例で示した各構成要素及び機能を任意に組み合わせることで実現される形態も本開示の範囲に含まれる。