特開2020-48226(P2020-48226A)IP Force 特許公報掲載プロジェクト 2015.5.11 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカの特許一覧
特開2020-48226電子制御ユニット、車載ネットワークシステム及び車両用通信方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】特開2020-48226(P2020-48226A)
(43)【公開日】2020年3月26日
(54)【発明の名称】電子制御ユニット、車載ネットワークシステム及び車両用通信方法
(51)【国際特許分類】
   H04L 12/40 20060101AFI20200303BHJP
   H04L 12/28 20060101ALI20200303BHJP
【FI】
   H04L12/40 M
   H04L12/28 100A
【審査請求】有
【請求項の数】13
【出願形態】OL
【全頁数】42
(21)【出願番号】特願2019-232695(P2019-232695)
(22)【出願日】2019年12月24日
(62)【分割の表示】特願2017-11726(P2017-11726)の分割
【原出願日】2015年8月25日
(31)【優先権主張番号】62/049,668
(32)【優先日】2014年9月12日
(33)【優先権主張国】US
(31)【優先権主張番号】特願2015-150050(P2015-150050)
(32)【優先日】2015年7月29日
(33)【優先権主張国】JP
(71)【出願人】
【識別番号】514136668
【氏名又は名称】パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
【氏名又は名称原語表記】Panasonic Intellectual Property Corporation of America
(74)【代理人】
【識別番号】100109210
【弁理士】
【氏名又は名称】新居 広守
(74)【代理人】
【識別番号】100137235
【弁理士】
【氏名又は名称】寺谷 英作
(74)【代理人】
【識別番号】100131417
【弁理士】
【氏名又は名称】道坂 伸一
(72)【発明者】
【氏名】氏家 良浩
(72)【発明者】
【氏名】安齋 潤
(72)【発明者】
【氏名】北村 嘉彦
(72)【発明者】
【氏名】田邉 正人
(72)【発明者】
【氏名】松島 秀樹
(72)【発明者】
【氏名】芳賀 智之
(72)【発明者】
【氏名】岸川 剛
(72)【発明者】
【氏名】杉山 良太
【テーマコード(参考)】
5K032
5K033
【Fターム(参考)】
5K032AA05
5K032AA06
5K032AA08
5K032CC01
5K032DA01
5K032EA02
5K032EA06
5K033AA08
5K033BA06
5K033DA01
5K033DB20
5K033EA06
5K033EB02
(57)【要約】
【課題】車載ネットワークを流れる不正なフレームに対応するための電子制御ユニットを提供する。
【解決手段】車載ネットワークを介して通信を行う複数の装置を備える車載ネットワークシステムに接続された電子制御ユニットは、マルチメディア制御ユニット150とシステム制御ユニット110を有する。マルチメディア制御ユニット150は、システム制御ユニット110を介して接続され、車載ネットワークへ送信する送信フレームについて、第1ルールに適合していると判定した場合には、当該送信フレームをシステム制御ユニット110に送信し、第1ルールに不適合であると判定した場合には、当該送信フレームをシステム制御ユニット110へ送信しない。システム制御ユニット110は、マルチメディア制御ユニット150から受信した送信フレームについて、第2ルールに適合していると判定した場合、車載ネットワークへ当該送信フレームを送信する。
【選択図】図4
【特許請求の範囲】
【請求項1】
車載ネットワークを介してフレームに係る通信を行う複数の装置を備える車載ネットワークシステムに接続された電子制御ユニットであって、
前記電子制御ユニットは、少なくとも第1制御ユニットと第2制御ユニットとを有し、
前記第1制御ユニットは、有線通信又は無線通信により前記第2制御ユニットを介して前記車載ネットワークと接続され、
前記第1制御ユニットは、前記車載ネットワークへ送信する送信フレームについて、第1ルールへの適合性に係る第1の判定を行い、前記第1ルールに適合していると判定した場合には、前記送信フレームを前記第2制御ユニットに送信し、前記第1ルールに不適合であると判定した場合には、前記送信フレームを前記第2制御ユニットへ送信せず、
前記第2制御ユニットは、前記第1制御ユニットから受信した前記送信フレームについて、第2ルールへの適合性に係る第2の判定を行い、前記第2ルールに適合していると判定した場合、前記車載ネットワークへ前記送信フレームを送信する
電子制御ユニット。
【請求項2】
前記第1ルールは、前記送信フレームについての送信周期又は送信頻度に関する条件を規定する
請求項1記載の電子制御ユニット。
【請求項3】
前記第1ルールは更に、前記送信フレームに含まれるデータの種類に関する条件を規定する
請求項2記載の電子制御ユニット。
【請求項4】
前記第2ルールは、前記送信フレームに含まれるデータの種類に関する条件を規定する
請求項2記載の電子制御ユニット。
【請求項5】
前記第2ルールは、前記送信フレームについての送信周期又は送信頻度に関する条件を規定する
請求項2又は3記載の電子制御ユニット。
【請求項6】
前記第2ルールは更に、前記送信フレームについての送信周期又は送信頻度に関する条件を規定する
請求項4記載の電子制御ユニット。
【請求項7】
前記第1制御ユニットは、第1マイクロプロセッサ及び第1メモリを含む半導体集積回路であり、当該第1メモリに格納されたプログラムを当該第1マイクロプロセッサで実行することにより、前記第1の判定を実行し、
前記第2制御ユニットは、前記第1マイクロプロセッサより処理性能が低い第2マイクロプロセッサ及び第2メモリを含む半導体集積回路であり、当該第2メモリに格納されたプログラムを当該第2マイクロプロセッサで実行することにより、前記第2の判定を実行する
請求項1記載の電子制御ユニット。
【請求項8】
前記第1の判定の結果及び前記第2の判定の結果を示す情報を、外部のサーバ装置に送信する
請求項1記載の電子制御ユニット。
【請求項9】
前記第1の判定の結果及び前記第2の判定の結果を示す情報を、所定記録媒体に記録する
請求項1記載の電子制御ユニット。
【請求項10】
前記電子制御ユニットを含む前記複数の装置は、CAN(Controller Area Network)プロトコルに従って前記フレームに係る通信を行う
請求項1記載の電子制御ユニット。
【請求項11】
前記第1制御ユニットは、アプリケーションプログラムの実行制御を行うマルチメディア制御ユニットであり、
前記第2制御ユニットは、前記車載ネットワークでの通信の制御を行うシステム制御ユニットである
請求項1記載の電子制御ユニット。
【請求項12】
車載ネットワークを介してフレームに係る通信を行う複数の装置を備える車載ネットワークシステムであって、
前記複数の装置のうち少なくとも1つは前記車載ネットワークに接続された電子制御ユニットであり、
前記電子制御ユニットは、少なくとも第1制御ユニットと第2制御ユニットとを有し、
前記第1制御ユニットは、有線通信又は無線通信により前記第2制御ユニットを介して前記車載ネットワークと接続され、
前記第1制御ユニットは、前記車載ネットワークへ送信する送信フレームについて、第1ルールへの適合性に係る第1の判定を行い、前記第1ルールに適合していると判定した場合には、前記送信フレームを前記第2制御ユニットに送信し、前記第1ルールに不適合であると判定した場合には、前記送信フレームを前記第2制御ユニットへ送信せず、
前記第2制御ユニットは、前記第1制御ユニットから受信した前記送信フレームについて、第2ルールへの適合性に係る第2の判定を行い、前記第2ルールに適合していると判定した場合、前記車載ネットワークへ前記送信フレームを送信する
車載ネットワークシステム。
【請求項13】
第1制御ユニットと、前記第1制御ユニットとの間で、有線通信又は無線通信により、フレームに係る情報を授受し得る第2制御ユニットとを有する電子制御ユニットを含む複数の装置が車載ネットワークを介してフレームに係る通信を行うところの車載ネットワークシステムにおいて用いられる車両用通信方法であって、
前記第1制御ユニットが、前記車載ネットワークへ送信する送信フレームについて、第1ルールへの適合性に係る第1の判定を行い、前記第1ルールに適合していると判定した場合には、前記送信フレームを前記第2制御ユニットに送信し、前記第1ルールに不適合であると判定した場合には、前記送信フレームを前記第2制御ユニットへ送信せず、
前記第2制御ユニットが、前記第1制御ユニットから受信した前記送信フレームについて、第2ルールへの適合性に係る第2の判定を行い、前記第2ルールに適合していると判定した場合、前記車載ネットワークへ前記送信フレームを送信する
車両用通信方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、車載ネットワークに接続されメッセージ(フレーム)を送受信する車両用通信装置、車両用通信方法等に関する。
【背景技術】
【0002】
近年、自動車の中のシステムには、電子制御ユニット(ECU:Electronic Control Unit)と呼ばれる装置が多数配置されている。これらのECUをつなぐネットワークは車載ネットワークと呼ばれる。車載ネットワークには、多数の規格が存在する。その中でも最も主流な車載ネットワークの一つに、ISO11898−1で規定されているCAN(Controller Area Network)という規格が存在する(「非特許文献1」参照)。
【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」参照)。また、周期的に送られてくるメッセージの周期をチェックし、不正なフレームを判定する技術が知られている(「非特許文献2」参照)。
【先行技術文献】
【特許文献】
【0006】
【特許文献1】特開2007−38904号公報
【非特許文献】
【0007】
【非特許文献1】“CAN Specification 2.0 Part A”、[online]、CAN in Automation(CiA)、[平成26年11月14日検索]、インターネット(URL:http://www.can−cia.org/fileadmin/cia/specifications/CAN20A.pdf)
【非特許文献2】大塚敏史、石郷岡 祐、「既存ECUを変更不要な車載LAN向け侵入検知手法」、研究報告組込みシステム(EMB)、情報処理学会、2013年3月6日、2013−EMB−28巻、6号、1−5頁
【発明の概要】
【発明が解決しようとする課題】
【0008】
ところで、CANのバスに接続しているECUのうち、外部ネットワーク、外部装置等から取得したアプリケーションプログラムを実行するECUがあれば、不正なアプリケーションプログラムにより不正な動作が行われる可能性がある。不正なアプリケーションプログラムは、不正なフレームを生成してバスに送出することで、車両を不正にコントロールする可能性があり、また、バスの負荷を上昇させ得る。そして、バス上のフレーム監視(チェック)負担の増加を招く。
【0009】
そこで、本発明は、不正なフレームのバスへの送出を低減させるために有用な車載ネットワークシステムを提供する。また、本発明は、その車載ネットワークシステムで用いられるECUとしての車両用通信装置、及び、不正なフレームのバスへの送出を低減させるために有用な車両用通信方法を提供する。
【課題を解決するための手段】
【0010】
上記課題を解決するために本発明の一態様に係る電子制御ユニット(ECU)は、車載ネットワークを介してフレームに係る通信を行う複数の装置を備える車載ネットワークシステムに接続された電子制御ユニットであって、前記電子制御ユニットは、少なくとも第1制御ユニットと第2制御ユニットとを有し、前記第1制御ユニットは、有線通信又は無線通信により前記第2制御ユニットを介して前記車載ネットワークと接続され、前記第1制御ユニットは、前記車載ネットワークへ送信する送信フレームについて、第1ルールへの適合性に係る第1の判定を行い、前記第1ルールに適合していると判定した場合には、前記送信フレームを前記第2制御ユニットに送信し、前記第1ルールに不適合であると判定した場合には、前記送信フレームを前記第2制御ユニットへ送信せず、前記第2制御ユニットは、前記第1制御ユニットから受信した前記送信フレームについて、第2ルールへの適合性に係る第2の判定を行い、前記第2ルールに適合していると判定した場合、前記車載ネットワークへ前記送信フレームを送信する電子制御ユニットである。
【0011】
また、上記課題を解決するために本発明の一態様に係る車載ネットワークシステムは、車載ネットワークを介してフレームに係る通信を行う複数の装置を備える車載ネットワークシステムであって、前記複数の装置のうち少なくとも1つは前記車載ネットワークに接続された電子制御ユニットであり、前記電子制御ユニットは、少なくとも第1制御ユニットと第2制御ユニットとを有し、前記第1制御ユニットは、有線通信又は無線通信により前記第2制御ユニットを介して前記車載ネットワークと接続され、前記第1制御ユニットは、前記車載ネットワークへ送信する送信フレームについて、第1ルールへの適合性に係る第1の判定を行い、前記第1ルールに適合していると判定した場合には、前記送信フレームを前記第2制御ユニットに送信し、前記第1ルールに不適合であると判定した場合には、前記送信フレームを前記第2制御ユニットへ送信せず、前記第2制御ユニットは、前記第1制御ユニットから受信した前記送信フレームについて、第2ルールへの適合性に係る第2の判定を行い、前記第2ルールに適合していると判定した場合、前記車載ネットワークへ前記送信フレームを送信する車載ネットワークシステムである。
【0012】
また、上記課題を解決するために本発明の一態様に係る車両用通信方法は、第1制御ユニットと、前記第1制御ユニットとの間で、有線通信又は無線通信により、フレームに係る情報を授受し得る第2制御ユニットとを有する電子制御ユニットを含む複数の装置が車載ネットワークを介してフレームに係る通信を行うところの車載ネットワークシステムにおいて用いられる車両用通信方法であって、前記第1制御ユニットが、前記車載ネットワークへ送信する送信フレームについて、第1ルールへの適合性に係る第1の判定を行い、前記第1ルールに適合していると判定した場合には、前記送信フレームを前記第2制御ユニットに送信し、前記第1ルールに不適合であると判定した場合には、前記送信フレームを前記第2制御ユニットへ送信せず、前記第2制御ユニットが、前記第1制御ユニットから受信した前記送信フレームについて、第2ルールへの適合性に係る第2の判定を行い、前記第2ルールに適合していると判定した場合、前記車載ネットワークへ前記送信フレームを送信する車両用通信方法である。
【発明の効果】
【0013】
本発明によれば、不正なフレームのバスへの送出を低減させることが実現可能となる。
【図面の簡単な説明】
【0014】
図1図1は、実施の形態1に係る車載ネットワークシステムの全体構成を示す図である。
図2図2は、CANプロトコルで規定されるデータフレームのフォーマットを示す図である。
図3図3は、CANプロトコルで規定されるエラーフレームのフォーマットを示す図である。
図4図4は、実施の形態1に係るヘッドユニットの構成図である。
図5図5は、ヘッドユニットが保持する受信IDリストの一例を示す図である。
図6図6は、判定ルール保持部が保持する判定ルールの一例を示す図である。
図7図7は、ECUの構成図である。
図8図8は、ECUの保持する受信IDリストの一例を示す図である。
図9図9は、エンジンに接続されたECUから送信されるフレームにおけるID及びデータフィールドの一例を示す図である。
図10図10は、ブレーキに接続されたECUから送信されるフレームにおけるID及びデータフィールドの一例を示す図である。
図11図11は、ドア開閉センサに接続されたECUから送信されるフレームにおけるID及びデータフィールドの一例を示す図である。
図12図12は、窓開閉センサに接続されたECUから送信されるフレームにおけるID及びデータフィールドの一例を示す図である。
図13図13は、実施の形態1に係るヘッドユニットにおけるフレーム受信処理の一例を示すフローチャートである。
図14図14は、実施の形態1に係るヘッドユニットにおけるフレーム送信処理の一例を示すフローチャートである。
図15図15は、実施の形態1に係るシステム制御ユニットにおけるフレーム判定処理の一例を示すフローチャートである。
図16図16は、実施の形態1に係るマルチメディア制御ユニットにおけるフレーム判定処理の一例を示すフローチャートである。
図17図17は、実施の形態1に係るフレーム周期判定処理の一例を示すフローチャートである。
図18図18は、フレーム頻度判定処理の一例を示すフローチャートである。
図19図19は、実施の形態1の変形例1に係るフレーム周期判定処理を示すフローチャートである。
図20図20は、実施の形態1の変形例2に係るシステム制御ユニットにおけるフレーム判定処理を示すフローチャートである。
図21図21は、実施の形態1の変形例2に係るマルチメディア制御ユニットにおけるフレーム判定処理を示すフローチャートである。
図22図22は、実施の形態1の変形例3に係るシステム制御ユニットにおけるフレーム判定処理を示すフローチャートである。
図23図23は、実施の形態1の変形例3に係るマルチメディア制御ユニットにおけるフレーム判定処理を示すフローチャートである。
図24図24は、実施の形態2に係るヘッドユニットの構成図である。
図25図25は、実施の形態2に係るヘッドユニットにおけるフレーム受信処理の一例を示すフローチャートである。
図26図26は、実施の形態2に係るヘッドユニットにおけるフレーム送信処理の一例を示すフローチャートである。
図27図27は、実施の形態3に係るネットワークシステムの全体構成を示す図である。
図28図28は、実施の形態3に係るヘッドユニットの構成図である。
図29図29は、実施の形態3に係るヘッドユニットにおけるフレーム受信処理の一例を示すフローチャートである。
図30図30は、実施の形態3に係るヘッドユニットにおけるフレーム送信処理の一例を示すフローチャートである。
【発明を実施するための形態】
【0015】
本発明の一態様に係る車両用通信装置は、バスを介してフレームに係る通信を行う複数の装置を備える車載ネットワークシステムにおける当該バスに接続された車両用通信装置であって、前記バスへの送出用のフレームである送信フレームを特定する第1制御ユニットと、前記第1制御ユニットとの間で、有線通信又は無線通信により、フレームに係る情報を授受し得る第2制御ユニットとを備え、前記第1制御ユニット及び前記第2制御ユニットのうち少なくとも1つが、前記送信フレームについて、ルールへの適合性に係る判定を行う車両用通信装置である。これにより、第1制御ユニットで例えばアプリケーションプログラム等により特定された内容のフレームが、車載ネットワークシステムにおけるルール(例えばデータ値の許容範囲、送信周期、送信頻度等に関する基準等)に照らして不正(不適合)か否か等が判定され得る。そして、この判定は、不正なフレームのバスへの送出の低減のために有用である。
【0016】
また、更に、前記第1制御ユニット及び前記第2制御ユニットのうち少なくとも1つが、前記車載ネットワークシステムにおける前記複数の装置のうち自装置以外のいずれかの装置により送信され、前記バスを介して取得したフレームである受信フレームについて、ルールへの適合性に係る判定を行うこととしても良い。これにより、バスから受信したフレームが車載ネットワークシステムにおけるルール(例えばデータ値の許容範囲、受信周期、受信頻度等に関する基準等)に照らして不正(不適合)か否か等が判定され得る。この判定は、車載ネットワークシステムのセキュリティ向上に有用である。また、この判定の結果は、不正なフレームの受信に起因して不正なフレームのバスへの送出がなされたか否かの分析に利用可能となり、不正なフレームのバスへの送出の低減のためにも有用となり得る。
【0017】
また、前記第1制御ユニットは、前記送信フレームについて第1所定ルールに適合しているか不適合であるかを判定する第1判定部を有し、前記第2制御ユニットは、前記受信フレームについて第2所定ルールに適合しているか不適合であるかを判定する第2判定部を有することとしても良い。これにより、フレームの判定をそれぞれの制御ユニットに分担させることができる。なお、第1制御ユニットにおいて必ずしも送信フレームに関するあらゆる基準(ルール項目)についての判定を行う必要はなく、第2制御ユニットにおいて必ずしも受信フレームに関するあらゆる基準(ルール項目)についての判定を行う必要はない。
【0018】
また、前記第1制御ユニットは、特定した前記送信フレームに係る情報を前記第2制御ユニットに送信する機能を有し、前記第2制御ユニットは、前記第1制御ユニットから特定された前記送信フレームに係る情報を受信した場合に、当該送信フレームを前記バスへと送出する機能と、前記受信フレームに係る情報を、前記第1制御ユニットに送信する機能とを有し、前記第1制御ユニットは、前記送信フレームについて前記第1判定部により不適合であると判定された場合に当該送信フレームに係る情報の前記第2制御ユニットへの送信を抑止し、前記第2制御ユニットは、前記受信フレームについて前記第2判定部により不適合であると判定された場合に当該受信フレームに係る情報の前記第1制御ユニットへの送信を抑止することとしても良い。これにより、一方の制御ユニットでルールへ不適合であると判定されたフレームについて、他方の制御ユニットで何らかの処理をすることが抑止され、各制御ユニットの処理負担が軽減され得る。
【0019】
また、前記第2所定ルールは、受信フレームについての受信周期又は受信頻度に関する条件を規定し、前記第1制御ユニットは、前記受信フレームについて、前記第2所定ルールとは異なる第3所定ルールに適合しているか不適合であるかを判定する第3判定部を有することとしても良い。これにより、第2制御ユニットとバスとの間の第1制御ユニットで、両制御ユニット間での信号伝達の時間(遅延)の影響を受けずに、周期又は頻度に関する判定を精度良く行うことができる。
【0020】
また、前記第1制御ユニットは、前記受信フレームについて、前記第2所定ルールとは異なる第3所定ルールに適合しているか不適合であるかを判定する第3判定部を有することとしても良い。これにより、受信フレームについてのルール判定を各制御ユニットに分担するため、例えば第1制御ユニットが第2制御ユニットより高性能である場合において適切な処理負荷の分散が実現され得る。
【0021】
また、前記第1制御ユニットは、第1マイクロプロセッサ及び第1メモリを含む半導体集積回路であり、当該第1メモリに格納されたプログラムを当該第1マイクロプロセッサで実行することにより前記第1判定部及び前記第3判定部としての機能を実現し、前記第2制御ユニットは、前記第1マイクロプロセッサより処理性能が低い第2マイクロプロセッサ及び第2メモリを含む半導体集積回路であり、当該第2メモリに格納されたプログラムを当該第2マイクロプロセッサで実行することにより前記第2判定部としての機能を実現することとしても良い。これにより、各マイクロプロセッサの処理性能に応じた適切な処理分担が実現され得る。
【0022】
また、前記車両用通信装置は、前記受信フレームについてのルールへの適合性に係る前記判定として、当該受信フレームが当該ルールに適合しているか不適合であるかの判定を行い、適合していると判定した場合には、当該受信フレームの内容に基づく所定の受信フレーム対応処理を実行し、不適合であると判定した場合には、前記所定の受信フレーム対応処理の実行を抑止することとしても良い。これにより、ルールに適合しない不正な受信フレームによって受信フレーム対応処理がなされることが防止される。
【0023】
また、前記車両用通信装置は、前記送信フレームについてのルールへの適合性に係る前記判定として、当該送信フレームが当該ルールに適合しているか不適合であるかの判定を行い、適合していると判定した場合には、当該送信フレームを前記バス上に送出し、不適合であると判定した場合には、当該送信フレームの前記バス上への送出を抑止することとしても良い。これにより、不正なフレームのバスへの送出が低減され得る。このため、バス上のフレーム監視負担が低減され得る。
【0024】
また、前記車両用通信装置は、前記送信フレームについてのルールへの適合性に係る前記判定の結果を示す情報を、外部のサーバ装置に送信することとしても良い。これにより、サーバ装置でフレームのルールへの適合性を分析でき、その分析の結果を用いて車載ネットワークシステムのセキュリティ向上を図ることが可能になる。
【0025】
また、前記車両用通信装置は、前記送信フレームについてのルールへの適合性に係る前記判定の結果を示す情報を、所定記録媒体に記録することとしても良い。これにより、記録媒体に記録された情報を分析でき、その分析の結果を用いて車載ネットワークシステムのセキュリティ向上を図ることが可能になる。
【0026】
また、前記車両用通信装置を含む前記複数の装置は、CAN(Controller Area Network)プロトコルに従って前記フレームに係る通信を行うこととしても良い。これにより、CANプロトコルに従って通信する車載ネットワークシステムにおいて不正なフレームのバスへの送出の低減を図ることが可能になる。
【0027】
また、本発明の一態様に係る車載ネットワークシステムは、バスを介してフレームに係る通信を行う複数の装置を備える車載ネットワークシステムであって、前記複数の装置のうち少なくとも1つは前記バスに接続された車両用通信装置であり、前記車両用通信装置は、前記バスへの送出用のフレームである送信フレームを特定する第1制御ユニットと、前記第1制御ユニットとの間で、有線通信又は無線通信により、フレームに係る情報を授受し得る第2制御ユニットとを備え、前記第1制御ユニット及び前記第2制御ユニットのうち少なくとも1つが、前記送信フレームについて、ルールへの適合性に係る判定を行う車載ネットワークシステムである。これにより、不正なフレームのバスへの送出の低減が可能となる。
【0028】
また、本発明の一態様に係る車両用通信方法は、バスへの送出用のフレームである送信フレームを特定する第1制御ユニットと、前記第1制御ユニットとの間で、有線通信又は無線通信により、フレームに係る情報を授受し得る第2制御ユニットとを有する車両用通信装置を含む複数の装置が前記バスを介してフレームに係る通信を行うところの車載ネットワークシステムにおいて用いられる車両用通信方法であって、前記第1制御ユニット及び前記第2制御ユニットのうち少なくとも1つが、前記送信フレームについて、ルールへの適合性に係る判定を行う車両用通信方法である。この車両用通信方法における判定は、不正なフレームのバスへの送出の低減に有用である。
【0029】
なお、これらの全般的又は具体的な態様は、システム、方法、集積回路、コンピュータプログラム又はコンピュータで読み取り可能なCD−ROM等の記録媒体で実現されても良く、システム、方法、集積回路、コンピュータプログラム又は記録媒体の任意な組み合わせで実現されても良い。
【0030】
以下、実施の形態に係る車両用通信装置を含む車載ネットワークシステムについて、図面を参照しながら説明する。ここで示す実施の形態は、いずれも本発明の一具体例を示すものである。従って、以下の実施の形態で示される数値、構成要素、構成要素の配置及び接続形態、並びに、ステップ(工程)及びステップの順序等は、一例であって本発明を限定するものではない。以下の実施の形態における構成要素のうち、独立請求項に記載されていない構成要素については、任意に付加可能な構成要素である。また、各図は、模式図であり、必ずしも厳密に図示されたものではない。
【0031】
(実施の形態1)
以下、本発明の実施の形態として、バスに送出する送信フレーム等を含むフレームについてルールへの適合性を判定する車両用通信方法を行う車両用通信装置(ヘッドユニット100)を含む車載ネットワークシステム10について図面を用いて説明する。
【0032】
[1.1 車載ネットワークシステム10の全体構成]
図1は、実施の形態1に係る車載ネットワークシステム10の全体構成を示す図である。車載ネットワークシステム10は、CANプロトコルに従って通信するネットワーク通信システムの一例であり、制御装置、センサ等の各種機器が搭載された自動車におけるネットワーク通信システムである。車載ネットワークシステム10は、バスを介してフレームに係る通信を行う複数の装置を備え、車両用通信方法を用いる。具体的には図1に示すように車載ネットワークシステム10は、バス200と、ヘッドユニット100、各種機器に接続されたECU400a〜400d等のECUといったバスに接続された各ノードとを含んで構成される。なお、車載ネットワークシステム10には、ヘッドユニット100及びECU400a〜400d以外にもいくつものECUが含まれ得るが、ここでは、便宜上ヘッドユニット100及びECU400a〜400dに注目して説明を行う。ECUは、例えば、プロセッサ(マイクロプロセッサ)、メモリ等のデジタル回路、アナログ回路、通信回路等を含む装置である。メモリは、ROM、RAM等であり、プロセッサにより実行される制御プログラム(コンピュータプログラム)を記憶することができる。例えばプロセッサが、制御プログラム(コンピュータプログラム)に従って動作することにより、ECUは各種機能を実現することになる。なお、コンピュータプログラムは、所定の機能を達成するために、プロセッサに対する指令を示す命令コードが複数個組み合わされて構成されたものである。
【0033】
ECU400a〜400dは、バス200と接続され、それぞれエンジン310、ブレーキ320、ドア開閉センサ330、窓開閉センサ340に接続されている。ECU400a〜400dのそれぞれは、接続されている機器(エンジン310等)の状態を取得し、定期的に状態を表すフレーム(後述するデータフレーム)等をネットワーク(つまりバス)に送信している。
【0034】
ヘッドユニット100は、ECU400a〜400dから送信されるフレームを受信し、各種状態をディスプレイ(図示しない)に表示して、ユーザに提示する機能を持つ。また、ヘッドユニット100が取得する各情報を示すフレームを生成して、そのフレームを、バス200を介して1台以上のECUに送信する機能を持つ。また、送受信するフレームについてルールへの適合性を判定することで、不正なフレーム(つまりルールに適合しないフレーム)か否かの判別等を行い、必要に応じてフレームのフィルタリングを行う機能を有する。また、ヘッドユニット100は、例えばカーナビゲーション、音楽再生、動画再生、ウェブページ表示、スマートフォンとの連携、アプリケーションプログラムのダウンロード及び実行等の機能を有し得る。なお、ヘッドユニット100も一種のECUである。
【0035】
車載ネットワークシステム10においてはCANプロトコルに従って、ヘッドユニット100を含む各ECUがフレームの授受を行う。CANプロトコルにおけるフレームには、データフレーム、リモートフレーム、オーバーロードフレーム及びエラーフレームがある。説明の便宜上、ここではデータフレーム及びエラーフレームを中心に説明する。
【0036】
[1.2 データフレームフォーマット]
以下、CANプロトコルに従ったネットワークで用いられるフレームの1つであるデータフレームについて説明する。
【0037】
図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)の各フィールドで構成される。
【0038】
SOFは、1bitのドミナントで構成される。バスがアイドルの状態はレセシブになっており、SOFによりドミナントへ変更することでフレームの送信開始を通知する。
【0039】
IDフィールドは、11bitで構成される、データの種類を示す値であるID(メッセージID)を格納するフィールドである。複数のノードが同時に送信を開始した場合、このIDフィールドで通信調停を行うために、IDが小さい値を持つフレームが高い優先度となるよう設計されている。
【0040】
RTRは、データフレームとリモートフレームとを識別するための値であり、データフレームにおいてはドミナント1bitで構成される。
【0041】
IDEと「r」とは、両方ドミナント1bitで構成される。
【0042】
DLCは、4bitで構成され、データフィールドの長さを示す値である。なお、IDE、「r」及びDLCを合わせてコントロールフィールドと称する。
【0043】
データフィールドは、最大64bitで構成される送信するデータの内容を示す値である。8bit毎に長さを調整できる。送られるデータの仕様については、CANプロトコルで規定されておらず、車載ネットワークシステム10において定められる。従って、車種、製造者(製造メーカ)等に依存した仕様となる。
【0044】
CRCシーケンスは、15bitで構成される。SOF、IDフィールド、コントロールフィールド及びデータフィールドの送信値より算出される。
【0045】
CRCデリミタは、1bitのレセシブで構成されるCRCシーケンスの終了を表す区切り記号である。なお、CRCシーケンス及びCRCデリミタを合わせてCRCフィールドと称する。
【0046】
ACKスロットは、1bitで構成される。送信ノードはACKスロットをレセシブにして送信を行う。受信ノードはCRCシーケンスまで正常に受信ができていればACKスロットをドミナントとして送信する。レセシブよりドミナントが優先されるため、送信後にACKスロットがドミナントであれば、送信ノードは、いずれかの受信ノードが受信に成功していることを確認できる。
【0047】
ACKデリミタは、1bitのレセシブで構成されるACKの終了を表す区切り記号である。
【0048】
EOFは、7bitのレセシブで構成されており、データフレームの終了を示す。
【0049】
[1.3 エラーフレームフォーマット]
図3は、CANプロトコルで規定されるエラーフレームのフォーマットを示す図である。エラーフレームは、エラーフラグ(プライマリ)と、エラーフラグ(セカンダリ)と、エラーデリミタとから構成される。
【0050】
エラーフラグ(プライマリ)は、エラーの発生を他のノードに知らせるために使用される。エラーを検知したノードはエラーの発生を他のノードに知らせるために6bitのドミナントを連続で送信する。この送信は、CANプロトコルにおけるビットスタッフィングルール(連続して同じ値を6bit以上送信しない)に違反し、他のノードからのエラーフレーム(セカンダリ)の送信を引き起こす。
【0051】
エラーフラグ(セカンダリ)は、エラーの発生を他のノードに知らせるために使用される連続した6ビットのドミナントで構成される。エラーフラグ(プライマリ)を受信してビットスタッフィングルール違反を検知した全てのノードがエラーフラグ(セカンダリ)を送信することになる。
【0052】
エラーデリミタ「DEL」は、8bitの連続したレセシブであり、エラーフレームの終了を示す。
【0053】
[1.4 ヘッドユニット100の構成]
ヘッドユニット100は、車両用通信装置であり、例えば、自動車のインストルメントパネル(インパネ)等に設けられ、運転者に視認されるための情報を表示する液晶ディスプレイ(LCD:Liquid Crystal Display)等の表示装置、運転者の操作を受け付ける入力手段等を備える一種のECUである。
【0054】
図4は、ヘッドユニット100の構成図である。ヘッドユニット100は、マルチメディア制御ユニット150(第1制御ユニット)とシステム制御ユニット110(第2制御ユニット)とを含んで構成される。
【0055】
システム制御ユニット110及びマルチメディア制御ユニット150のそれぞれは、例えばパッケージ化された半導体集積回路であるチップ(マイクロチップ)等であり、これらは、有線又は無線で相互に通信可能となるように構成される。なお、無線での通信は、電磁波により信号を伝送することでなされ、光通信を含む。
【0056】
システム制御ユニット110は、主に他の車載装置(ECU400a〜400d)との連携に係る制御、つまりバス200での通信の制御を担う。システム制御ユニット110は、フレーム送受信部111と、受信フレーム解釈部112と、受信ID判断部113と、受信IDリスト保持部114と、フレーム判定部115と、判定ルール保持部116と、ユニット間通信処理部117と、送信フレーム生成部118とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、チップに集積された通信回路、メモリ及びこのメモリに格納された制御プログラムを実行するプロセッサ(マイクロプロセッサ)その他の回路等により実現される。
【0057】
フレーム送受信部111は、バス200に対して、CANプロトコルに従ったフレームを送受信する。バス200からフレームを1bitずつ受信し、受信フレーム解釈部112に転送する。また、送信フレーム生成部118より通知を受けたフレームの内容をバス200に1bitずつ送信する。
【0058】
受信フレーム解釈部112は、フレーム送受信部111よりフレームの値を受け取り、CANプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。受信フレーム解釈部112は、IDフィールドと判断した値は受信ID判断部113へ転送する。受信フレーム解釈部112は、受信ID判断部113から通知される判定結果に応じて、IDフィールドの値と、IDフィールド以降に現れるデータフィールドとを、フレーム判定部115へ転送するか、その判定結果を受けた以降においてフレームの受信を中止する(つまりそのフレームとしての解釈を中止する)かを決定する。また、受信フレーム解釈部112は、例えば、CRCの値が合わなかったり、ドミナント固定とされている項目がレセシブだったりする等、CANプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するように送信フレーム生成部118へ通知する。また、受信フレーム解釈部112は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。例えばデータフレームの途中からエラーフレームと解釈された場合においては、そのデータフレームの解釈は中止され、そのデータフレームに応じて特段の処理を行うことがなくなる。
【0059】
受信ID判断部113は、受信フレーム解釈部112から通知されるIDフィールドの値を受け取り、受信IDリスト保持部114が保持しているメッセージIDのリストに従い、そのIDフィールド以降のフレームの各フィールドを受信するかどうかの判定を行う。この判定結果を、受信ID判断部113は、受信フレーム解釈部112へ通知する。
【0060】
受信IDリスト保持部114は、ヘッドユニット100が受信するID(メッセージID)のリストである受信IDリストを保持する。図5に、受信IDリストの一例を示す。
【0061】
フレーム判定部115は、受信フレーム解釈部112から受信したフレームの値、或いは、ユニット間通信処理部117より送信すべきフレームの内容となる値を受け取る。そして、判定ルール保持部116から判定ルールを取得し、判定ルールに基づいたフレーム判定処理(システム制御ユニットフレーム判定処理)の結果に応じて、送信フレーム生成部118、或いは、ユニット間通信処理部117へフレームの値を通知するか否かを決定する。このフレーム判定処理(システム制御ユニットフレーム判定処理)は、フレームについて判定ルールへの適合性の判定(例えばフレームが不正であるか否か等の判定)を行うための処理であり、後に図15を用いて詳しく説明する。
【0062】
判定ルール保持部116は、ヘッドユニット100が送信或いは受信するフレームについて、フレーム判定処理を行うために用いる判定ルールを保持する。この判定ルールは、車載ネットワークシステム10においてバス上で授受されるフレームが準拠すべきルールである。図6に、判定ルールの一例を示す。
【0063】
ユニット間通信処理部117は、異なるユニット間の通信処理を行う。即ち、ユニット間通信処理部117は、マルチメディア制御ユニット150との間で、有線又は無線の通信(送信又は受信)により情報の授受を行う。
【0064】
送信フレーム生成部118は、受信フレーム解釈部112からのエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部111へ通知して送信させる。また、送信フレーム生成部118は、フレーム判定部115から通知を受けたID、データ等を用いて、送信するデータフレームを生成する。
【0065】
また、マルチメディア制御ユニット150は、主に、ヘッドユニット100で各種機能(例えばカーナビゲーション、音楽再生、動画再生、ウェブページ表示、スマートフォンとの連携等の機能)を実現するためのアプリケーションプログラムの実行制御処理を担う。マルチメディア制御ユニット150は、ユニット間通信処理部151と、フレーム判定部152と、判定ルール保持部153と、アプリケーション実行部154とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、チップに集積された通信回路、メモリ及びこのメモリに格納された制御プログラムを実行するプロセッサその他の回路等により実現される。
【0066】
ユニット間通信処理部151は、異なるユニット間の通信処理を行う。即ち、ユニット間通信処理部151は、システム制御ユニット110との間で、有線又は無線の通信(送信又は受信)により情報の授受を行う。
【0067】
フレーム判定部152は、アプリケーション実行部154から送信すべきフレームの内容となる値、或いは、ユニット間通信処理部151から受信されたフレームの値を受け取る。そして、判定ルール保持部153から判定ルールを取得し、判定ルールに基づいたフレーム判定処理(マルチメディア制御ユニットフレーム判定処理)の結果に応じて、アプリケーション実行部154、或いは、ユニット間通信処理部151へフレームの値を通知するか否かを決定する。このフレーム判定処理(マルチメディア制御ユニットフレーム判定処理)は、フレームについて判定ルールへの適合性の判定(例えばフレームが不正であるか否か等の判定)を行うための処理であり、後に図16を用いて詳しく説明する。
【0068】
判定ルール保持部153は、ヘッドユニット100が送信或いは受信するフレームについて、フレーム判定処理を行うために用いる判定ルールを保持する。この判定ルールは、車載ネットワークシステム10においてバス上で授受されるフレームが準拠すべきルールである。なお、マルチメディア制御ユニット150の判定ルール保持部153が保持する判定ルールと、システム制御ユニット110の判定ルール保持部116が保持する判定ルールとは、それぞれフレーム判定部152、フレーム判定部115における判定に必要な基準、条件等の情報を少なくとも含めば十分であり、両者が同一であっても互いに異なっていても良い。
【0069】
アプリケーション実行部154は、ヘッドユニット100の各種機能(例えばナビゲーション、動画再生、音楽再生、Webブラウジング等の機能)を実現するためのアプリケーションプログラムの実行制御を行う。例えば、入力手段を通じて受け付けた運転者(ユーザ)による操作に応じて、アプリケーションプログラムの実行制御がなされ、アプリケーションプログラムの実行によって例えば表示装置へユーザに提示すべき情報の表示等がなされ得る。アプリケーションプログラムは、例えば、バス200以外の外部ネットワークを介してダウンロードされ、マルチメディア制御ユニット150のプロセッサ上で動作する所定のオペレーティングシステム(OS)等による実行環境上で、プロセッサにより実行されることで動作する。
【0070】
[1.5 ヘッドユニット100の受信IDリスト例]
図5は、ヘッドユニット100の受信IDリスト保持部114において保持される受信IDリストの一例を示す図である。同図に例示する受信IDリストは、ID(メッセージID)の値が「1」、「2」、「3」及び「4」のいずれかであるメッセージIDを含むフレームを選択的に受信して処理するために用いられる。ヘッドユニット100は、エンジン310に接続されたECU400aからメッセージIDが「1」であるフレーム(メッセージ)を受信し、ブレーキ320に接続されたECU400bからメッセージIDが「2」であるフレームを受信し、ドア開閉センサ330に接続されたECU400cからメッセージIDが「3」であるフレームを受信し、窓開閉センサ340に接続されたECU400dからメッセージIDが「4」であるフレームを受信する。
【0071】
[1.6 判定ルール例]
図6は、ヘッドユニット100の判定ルール保持部116及び判定ルール保持部153が保持する判定ルールの一例を示す図である。同図に例示する判定ルールは、ID(メッセージID)毎に、そのメッセージIDのメッセージ(フレーム)が準拠すべきルール(基準)を示す。この判定ルールは、メッセージID毎に、送受信種別、データ長、データ範囲、周期(ms)、マージン(ms)、イベント有無、及び、頻度閾値(回/sec)という項目を含んでいる。
【0072】
図6の例では、送受信種別は、ヘッドユニット100が、他のECUから送信されバス200を介して取得したフレームである受信フレームを1の値で示し、ヘッドユニット100からバス200への送信用のフレームである送信フレームを0の値で示し、両者を区別している。
【0073】
データ長は、フレーム(データフレーム)に含まれるデータフィールドの長さ(Byte数)についての基準を示す。
【0074】
データ範囲は、データフィールドの1Byte〜8Byteについて1Byte毎に、データが取り得る値の範囲についての基準を示す。データが取り得る値の範囲として、図6の記号「**」は、どんな値でも取り得ることを示す。また、記号「,」で連結する値はいずれかの値を取り得ることを示し、「〜」で連結する値は、それぞれを上限、下限とする範囲内のいずれかの値を取り得ることを示す。
【0075】
周期は、フレームが繰り返し送信又は受信される場合におけるその送信又は受信の周期についての基準を示し、図6では周期をミリ秒単位の値で表している。なお、周期として図6の記号「−」は、対応するメッセージIDのフレームとして、周期的に送信又は受信されるフレームが無いことを表している。
【0076】
マージンは、周期の基準についての適合性の判定において許容される周期とのズレ量(誤差の許容範囲)を示し、図6ではマージンをミリ秒単位の値で表している。
【0077】
イベント有無は、対応するメッセージIDのフレームとして、周期とは別に送信又は受信されるイベントフレームが有り得るか否かについての基準を示し、図6では、1の値でイベントフレームが有り得ることを示し、0の値でイベントフレームが無いことを示す。
【0078】
頻度周期は、対応するメッセージIDのフレームとして送信又は受信されるイベントフレームが有り得る場合において、フレームの送信又は受信の頻度についての基準を示す。図6では頻度周期を1秒当たりの送信又は受信の回数で表している。
【0079】
なお、図6の例は、判定ルールの一例にすぎず、判定ルールは、フレームの要件として定めた基準等であればいかなる内容でも良い。例えば、図6では、データ範囲のルール(基準)をByte単位で表現しているが、必ずしもByte単位で表現する必要はない。また、送信フレームについてのルール項目(基準)と受信フレームについてのルール項目(基準)とを、必ずしも一致させる必要はない。また判定ルールをテーブルとして表しても、数式、プログラム(命令列)等で表しても良い。
【0080】
[1.7 ECU400aの構成]
図7は、ECU400aの構成図である。ECU400aは、フレーム送受信部460と、受信フレーム解釈部450と、受信ID判断部430と、受信IDリスト保持部440と、フレーム処理部410と、送信フレーム生成部420と、データ取得部470とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、ECU400aにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。
【0081】
フレーム送受信部460は、バス200に対して、CANプロトコルに従ったフレームを送受信する。バス200からフレームを1bitずつ受信し、受信フレーム解釈部450に転送する。また、送信フレーム生成部420より通知を受けたフレームの内容をバス200に送信する。
【0082】
受信フレーム解釈部450は、フレーム送受信部460よりフレームの値を受け取り、CANプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。IDフィールドと判断した値は受信ID判断部430へ転送する。受信フレーム解釈部450は、受信ID判断部430から通知される判定結果に応じて、IDフィールドの値と、IDフィールド以降に現れるデータフィールドとを、フレーム処理部410へ転送するか、その判定結果を受けた以降においてフレームの受信を中止する(つまりそのフレームとしての解釈を中止する)かを決定する。また、受信フレーム解釈部450は、CANプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するように送信フレーム生成部420へ通知する。また、受信フレーム解釈部450は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。
【0083】
受信ID判断部430は、受信フレーム解釈部450から通知されるIDフィールドの値を受け取り、受信IDリスト保持部440が保持しているメッセージIDのリストに従い、そのIDフィールド以降のフレームの各フィールドを受信するかどうかの判定を行う。この判定結果を、受信ID判断部430は、受信フレーム解釈部450へ通知する。
【0084】
受信IDリスト保持部440は、ECU400aが受信するID(メッセージID)のリストである受信IDリストを保持する。図8に、受信IDリストの一例を示す。
【0085】
フレーム処理部410は、受信したフレームのデータに応じてECU毎に異なる機能に係る処理を行う。例えば、エンジン310に接続されたECU400aは、時速が30kmを超えた状態でドアが開いている状態だと、アラーム音を鳴らす機能を備える。ECU400aは、例えばアラーム音を鳴らすためのスピーカ等を有している。そして、ECU400aのフレーム処理部410は、他のECUから受信したデータ(例えばドアの状態を示す情報)を管理し、エンジン310から取得された時速に基づいて一定条件下でアラーム音を鳴らす処理等を行う。
【0086】
データ取得部470は、ECU400aにつながっている機器、センサ等の状態を示すデータを取得し、送信フレーム生成部420に通知する。
【0087】
送信フレーム生成部420は、受信フレーム解釈部450から通知されたエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部460へ通知して送信させる。また、送信フレーム生成部420は、データ取得部470より通知されたデータの値に対して、予め定められたメッセージIDをつけてフレームを構成し、フレーム送受信部460へ通知する。
【0088】
なお、ECU400b〜400dも、上述したECU400aと基本的に同様の構成を備える。受信IDリスト保持部440に保持される受信IDリストはECU毎に異なる内容となり得るが、同じ内容であっても良い。また、フレーム処理部410の処理内容は、ECU毎に異なる。例えば、ECU400cにおけるフレーム処理部410の処理内容は、ブレーキがかかっていない状況でドアが開くとアラーム音を鳴らす機能に係る処理を含む。例えば、ECU400b及びECU400dにおけるフレーム処理部410では特段の処理を行わない。なお、各ECUは、ここで例示した以外の機能を備えていても良い。なお、ECU400a〜400dのそれぞれが送信するフレームの内容については後に図9図12を用いて説明する。
【0089】
[1.8 ECU400a〜400dの受信IDリスト例]
図8は、ECU400a、ECU400b、ECU400c及びECU400dのそれぞれにおいて保持される受信IDリストの一例を示す図である。同図に例示する受信IDリストは、ID(メッセージID)の値が「1」、「2」、「3」、「4」、「5」、「6」及び「7」のいずれかであるメッセージIDを含むフレームを選択的に受信して処理するために用いられる。
【0090】
[1.9 エンジンに係るECU400aの送信フレーム例]
図9は、エンジン310に接続されたECU400aから送信されるフレームにおけるID(メッセージID)及びデータフィールド(データ)の一例を示す図である。ECU400aが送信するフレームのメッセージIDは「1」である。データは、時速(km/時)を表し、最低0(km/時)〜最高180(km/時)までの範囲の値を取り、データ長は1Byteである。図9の上行から下行へと、ECU400aから逐次送信される各フレームに対応する各メッセージID及びデータを例示しており、0km/時から1km/時ずつ加速されている様子を表している。
【0091】
[1.10 ブレーキに係るECU400bの送信フレーム例]
図10は、ブレーキ320に接続されたECU400bから送信されるフレームにおけるID(メッセージID)及びデータフィールド(データ)の一例を示す図である。ECU400bが送信するフレームのメッセージIDは「2」である。データは、ブレーキのかかり具合を割合(%)で表し、データ長は1Byteである。この割合は、ブレーキを全くかけていない状態を0(%)、ブレーキを最大限かけている状態を100(%)としたものである。図10の上行から下行へと、ECU400bから逐次送信される各フレームに対応する各メッセージID及びデータを例示しており、100%から徐々にブレーキを弱めている様子を表している。
【0092】
[1.11 ドア開閉センサに係るECU400cの送信フレーム例]
図11は、ドア開閉センサ330に接続されたECU400cから送信されるフレームにおけるID(メッセージID)及びデータフィールド(データ)の一例を示す図である。ECU400cが送信するフレームのメッセージIDは「3」である。データは、ドアの開閉状態を表し、データ長は1Byteである。データの値は、ドアが開いている状態が「1」、ドアが閉まっている状態が「0」である。図11の上行から下行へと、ECU400cから逐次送信される各フレームに対応する各メッセージID及びデータを例示しており、ドアが開いている状態から次第に閉められた状態へと移った様子を表している。
【0093】
[1.12 窓開閉センサに係るECU400dの送信フレーム例]
図12は、窓開閉センサ340に接続されたECU400dから送信されるフレームにおけるID(メッセージID)及びデータフィールド(データ)の一例を示す図である。ECU400dが送信するフレームのメッセージIDは「4」である。データは、窓の開閉状態を割合(%)で表し、データ長は1Byteである。この割合は、窓が完全に閉まっている状態を0(%)、窓が全開の状態を100(%)としたものである。図12の上行から下行へと、ECU400dから逐次送信される各フレームに対応する各メッセージID及びデータを例示しており、窓が閉まっている状態から徐々に開いていく様子を表している。
【0094】
[1.13 ヘッドユニット100によるフレーム受信の動作]
図13は、ヘッドユニット100におけるフレーム受信処理の一例を示すフローチャートである。以下、同図に即して、ヘッドユニット100におけるデータフレームの受信時の動作を説明する。
【0095】
ヘッドユニット100は、システム制御ユニット110のフレーム送受信部111により、バス200上に現れるフレームを受信する(ステップS1100)。
【0096】
フレーム送受信部111がフレームにおけるIDの部分を受信すると、受信フレーム解釈部112及び受信ID判断部113により、受信IDリスト保持部114が保持する受信IDリストを参照して、受信すべきIDを含むフレームか否かを判別することで、そのフレームを引き続き受信すべきかどうかを判定する(ステップS1200)。受信したフレームが受信IDリストに記載の無いIDを含む場合は、フレーム受信処理を終了する。
【0097】
ステップS1200において受信したフレームのIDが受信IDリストに含まれている場合に、フレームを受信して、フレーム判定部115においてシステム制御ユニットフレーム判定処理を行う(ステップS1300)。システム制御ユニットフレーム判定処理S1300については後に図15を用いて説明する。
【0098】
システム制御ユニットフレーム判定処理の判定結果がOK(正常)の場合(つまり受信フレームが判定ルールに適合していると判定された場合)には(ステップS1400)、ユニット間の通信処理により、システム制御ユニット110はマルチメディア制御ユニット150にフレーム(受信フレーム)の内容を通知する(ステップS1500)。なお、ステップS1400においてシステム制御ユニットフレーム判定処理の判定結果がOKでない場合には、システム制御ユニット110は、フレームをマルチメディア制御ユニット150へ通知せず、フレーム受信処理を終える。
【0099】
次にマルチメディア制御ユニット150では、受信フレームの通知を受けるとフレーム判定部152においてマルチメディア制御ユニットフレーム判定処理を行う(ステップS1600)。マルチメディア制御ユニットフレーム判定処理S1600については、後に図16を用いて説明する。
【0100】
マルチメディア制御ユニットフレーム判定処理において、判定結果がOKの場合(つまり受信フレームが判定ルールに適合していると判定された場合)には(ステップS1700)、フレーム判定部152は、アプリケーション実行部154に受信フレームの内容を通知する。そして、アプリケーション実行部154は、ヘッドユニット100における各種機能を実現するためのアプリケーションプログラムを実行して、受信フレームの内容に応じた処理を行う(ステップS1800)。受信フレームの内容に応じた処理(受信フレーム対応処理)は、例えば受信したフレームのデータフィールドの内容に基づく演算、その演算結果に基づく制御信号の出力(例えば表示装置へ情報を表示させるための制御信号の出力)等である。なお、ステップS1700においてマルチメディア制御ユニットフレーム判定処理の判定結果がOKでない場合には、マルチメディア制御ユニット150は、アプリケーションプログラムによる受信フレームの内容に応じた処理を行わない。
【0101】
[1.14 ヘッドユニット100によるフレーム送信の動作]
図14は、ヘッドユニット100におけるフレーム送信処理の一例を示すフローチャートである。以下、同図に即して、ヘッドユニット100におけるデータフレームの送信のための動作を説明する。ここで、アプリケーション実行部154により実行されるアプリケーションプログラムは、一定期間毎に或いは機能実現上の必要に応じて、送信されるべきフレーム(送信フレーム)の内容(例えばID及びデータフィールドの内容)を特定して送信指示を行う内容(命令列)を含むものとする。
【0102】
アプリケーション実行部154により、アプリケーションプログラムが実行され、アプリケーションプログラムによりデータフレームの送信指示がなされる(ステップS2100)。
【0103】
送信フレームの内容を特定して送信指示がなされた場合に、アプリケーション実行部154から特定された送信フレームの内容の通知を受けてフレーム判定部152は、マルチメディア制御ユニットフレーム判定処理を行う(ステップS1600)。この例では、フレーム送信処理において上述したフレーム受信処理(図13)と同じマルチメディア制御ユニットフレーム判定処理S1600を行うものとする。
【0104】
マルチメディア制御ユニットフレーム判定処理において、判定結果がOKの場合(つまり送信フレームについて判定ルールに適合していると判定された場合)には(ステップS2200)、ユニット間の通信処理により、マルチメディア制御ユニット150はシステム制御ユニット110にフレーム(送信フレーム)の内容を通知する(ステップS2300)。なお、ステップS2200においてマルチメディア制御ユニットフレーム判定処理の判定結果がOKでない場合には、マルチメディア制御ユニット150は、送信フレームの内容をシステム制御ユニット110へ通知せず、フレーム送信処理を終える。
【0105】
次にシステム制御ユニット110では、送信フレームの内容の通知を受けるとフレーム判定部115においてシステム制御ユニットフレーム判定処理を行う(ステップS1300)。この例では、フレーム送信処理において上述したフレーム受信処理(図13)と同じシステム制御ユニットフレーム判定処理S1300を行うものとする。
【0106】
システム制御ユニットフレーム判定処理において、判定結果がOKの場合(つまり送信フレームについて判定ルールに適合していると判定された場合)には(ステップS2400)、送信フレーム生成部118は、送信フレームの内容(マルチメディア制御ユニット150においてアプリケーションプログラムにより特定された内容)に基づいて送信フレーム(データフレーム)を生成する(ステップS2500)。そして、送信フレーム生成部118により生成された送信フレームをフレーム送受信部111がバス200上に送出することでデータフレームの送信を行う(ステップS2600)。なお、ステップS2400においてシステム制御ユニットフレーム判定処理の判定結果がOKでない場合には、システム制御ユニット110は、送信フレームのバス200上への送出を行わない。即ち、送信フレームがルールに適合している場合には、送信フレームはヘッドユニット100によりバス上に送出され、ルールに適合していない(不適合である)場合には、送信フレームのバス上への送出が抑止される。
【0107】
[1.15 システム制御ユニットフレーム判定処理]
図15は、システム制御ユニット110におけるフレーム判定処理(システム制御ユニットフレーム判定処理)の一例を示すフローチャートである。以下、同図に即して、システム制御ユニット110のフレーム判定部115によるシステム制御ユニットフレーム判定処理S1300について説明する。システム制御ユニットフレーム判定処理S1300では、判定ルール保持部116が保持する判定ルール(図6参照)を参照して、フレームについて判定ルールへの適合性が判定され、判定ルールに適合していれば判定結果はOK(正常)、適合していなければ判定結果はNG(不正)となる。ここでは、判定ルールには、ヘッドユニット100が送信又は受信する各フレームのIDが記載されているものとする。
【0108】
フレーム判定部115は、判定対象が送信フレームか、受信フレームかを判別し(ステップS1301)、送信フレームの場合は、判定結果をOKとしてシステム制御ユニットフレーム判定処理を終え(ステップS1302)、受信フレームの場合には、ステップS1303へと進む。なお、フレーム判定部115は、受信フレーム解釈部112からデータ(受信フレーム)を通知された場合に、判定対象が受信フレームであると判別し、ユニット間通信処理部117からデータ(送信フレームの内容)を通知された場合に、判定対象が送信フレームであると判別する。
【0109】
ステップS1303では、フレーム判定部115は、判定対象のフレームのIDと一致するIDが判定ルールに記載されているかを確認し(ステップS1303)、記載されていればそのIDに関する判定ルールの各項目を取得する(ステップS1304)。判定対象のフレームのIDと一致するIDが判定ルールに記載されていなければ、判定結果をNGとして(ステップS1306)、システム制御ユニットフレーム判定処理を終える。
【0110】
フレーム判定部115は、ステップS1304で取得した判定ルールのデータ長及びデータ範囲という項目の基準に判定対象のフレームが適合しているか否かを判定する(ステップS1305)。判定対象のフレームが、データ長の基準及びデータ範囲の基準のいずれかに適合しなければ、フレーム判定部115は、判定結果をNGとして(ステップS1306)、システム制御ユニットフレーム判定処理を終える。
【0111】
ステップS1305で、判定対象のフレームが、データ長の基準及びデータ範囲の基準の両方に適合していると判定した場合には、フレーム判定部115は、判定対象のフレームが周期的に送信又は受信されるフレームであるか否かを判別する(ステップS1307)。具体的には、判定ルールの周期の項目が、周期的に送信又は受信されるフレームが無いことを表しておらず、かつ、イベント有無の項目が、イベントフレームが無いことを表している場合に周期的に送信又は受信されるフレームであると判別され、その他の場合には周期的に送信又は受信されるフレームでないと判別される。フレーム判定部115は、周期的に送信又は受信されるフレームであると判別した場合に、フレーム周期判定処理を行い(ステップS1330)、周期的に送信又は受信されるフレームでないと判別した場合に、フレーム頻度判定処理を行う(ステップS1350)。フレーム周期判定処理S1330及びフレーム頻度判定処理S1350については後述する。
【0112】
[1.16 マルチメディア制御ユニットフレーム判定処理]
図16は、マルチメディア制御ユニット150におけるフレーム判定処理(マルチメディア制御ユニットフレーム判定処理)の一例を示すフローチャートである。以下、同図に即して、マルチメディア制御ユニット150のフレーム判定部152によるマルチメディア制御ユニットフレーム判定処理S1600について説明する。マルチメディア制御ユニットフレーム判定処理S1600では、判定ルール保持部153が保持する判定ルール(図6参照)を参照して、フレームについて判定ルールへの適合性が判定され、判定ルールに適合していれば判定結果はOK(正常)、適合していなければ判定結果はNG(不正)となる。
【0113】
フレーム判定部152は、判定対象が送信フレームか、受信フレームかを判別し(ステップS1601)、受信フレームの場合は、判定結果をOKとしてマルチメディア制御ユニットフレーム判定処理を終え(ステップS1602)、送信フレームの場合には、ステップS1303へと進む。なお、フレーム判定部152は、ユニット間通信処理部151からデータ(受信フレーム)を通知された場合に、判定対象が受信フレームであると判別し、アプリケーション実行部154からデータ(送信フレームの内容)を通知された場合に、判定対象が送信フレームであると判別する。
【0114】
なお、マルチメディア制御ユニットフレーム判定処理S1600におけるステップS1303、S1304、S1305、S1306、S1307、S1330及びS1350は上述したシステム制御ユニットフレーム判定処理S1300(図15)と同一内容であり、ここでは説明を省略する。
【0115】
[1.17 フレーム周期判定処理]
図17は、フレーム周期判定処理S1330の一例を示すフローチャートである。フレーム判定部(つまりフレーム判定部115或いはフレーム判定部152)は、フレーム周期判定処理S1330を実行する。フレーム周期判定処理S1330は、判定対象のフレームが周期性に関連する基準に適合するか否か、つまり正しい周期で送信又は受信されているか否かを判定するための処理である。
【0116】
フレーム周期判定処理S1330として、フレーム判定部は、まず現在時刻を取得する(ステップS1331)。例えば、フレーム判定部115はシステム制御ユニット110内の計時機構(タイマ等)を用いて現在時刻を取得し、フレーム判定部152はマルチメディア制御ユニット150内の計時機構(タイマ等)を用いて現在時刻を取得する。或いは各フレーム判定部は、ヘッドユニット100におけるシステム制御ユニット110及びマルチメディア制御ユニット150とは別の回路である計時機構(タイマ等)から現在時刻を取得しても良い。
【0117】
次にフレーム判定部は、取得した現在時刻と、保存しておいた基準時刻との差分を計算する(ステップS1332)。なお、フレーム周期判定処理S1330の初回の実行時においては、基準時刻を保存していないので、例えば、例外的に判定結果をOKとして、現在時刻を基準時刻として保存する。
【0118】
ステップS1332に続いて、フレーム判定部は、現在時刻と基準時刻との差分(差分時刻と称する)が、周期±マージンの範囲内であるか否かを判別する(ステップS1333)。この判別には、判定ルール(図6参照)において、フレーム判定部の判定対象となるフレームのIDに対応した周期及びマージンが用いられる。
【0119】
ステップS1333において、差分時刻が周期±マージンの範囲内であると判別した場合には、フレーム判定部は、判定結果をOK(正常)とし(ステップS1334)、ステップS1331で取得した現在時刻を用いて基準時刻を更新し(ステップS1337)、フレーム周期判定処理S1330を終える。
【0120】
ステップS1333において、差分時刻が周期±マージンの範囲内でないと判別した場合には、フレーム判定部は、判定結果をNG(不正)とし(ステップS1335)、差分時刻が周期+マージンより大きいか否かを判別する(ステップS1336)。このステップS1336で、差分時刻が周期+マージンより大きくないと判別した場合には、フレーム判定部は、フレーム周期判定処理S1330を終える。また、差分時刻が周期+マージンより大きいと判別した場合には、フレーム判定部は、ステップS1331で取得した現在時刻を用いて基準時刻を更新し(ステップS1337)、フレーム周期判定処理S1330を終える。
【0121】
[1.18 フレーム頻度判定処理]
図18は、フレーム頻度判定処理S1350の一例を示すフローチャートである。フレーム判定部(つまりフレーム判定部115或いはフレーム判定部152)は、フレーム頻度判定処理S1350を実行する。フレーム頻度判定処理S1350は、判定対象のフレームが頻度に関連する基準に適合するか否か、つまり正しい頻度(頻度閾値未満の頻度)で送信又は受信されているか否かを判定するための処理である。
【0122】
フレーム頻度判定処理S1350として、フレーム判定部は、まず頻度確認タイマーが設定時間(ここでは1秒とする)を超えたか否かを判別する(ステップS1351)。例えば、フレーム判定部115はシステム制御ユニット110内の計時機構(タイマ等)を用いて頻度確認タイマーとして機能させ、フレーム判定部152はマルチメディア制御ユニット150内の計時機構(タイマ等)を用いて頻度確認タイマーとして機能させる。或いは各フレーム判定部は、ヘッドユニット100におけるシステム制御ユニット110及びマルチメディア制御ユニット150とは別の回路である計時機構(タイマ等)を用いて頻度確認タイマーの機能を実現しても良い。
【0123】
次にフレーム判定部は、頻度確認タイマーが設定時間を超えた場合には、頻度確認タイマーをクリア(リセット)し、頻度を計数するための変数としての頻度カウンタをクリアする(ステップS1352)。
【0124】
フレーム判定部は、ステップS1351で頻度確認タイマーが設定時間を超えていない場合、及び、ステップS1352で頻度確認タイマーをリセットした場合には、頻度カウンタをインクリメント(1増加)する(ステップS1353)。そして、フレーム判定部は、判定ルール(図6参照)において、フレーム判定部の判定対象となるフレームのIDに対応した頻度閾値より、頻度カウンタが小さいか否かを判別する(ステップS1354)。
【0125】
ステップS1354において、頻度カウンタが頻度閾値より小さいと判別した場合には、フレーム判定部は、判定結果をOK(正常)とし(ステップS1355)、フレーム頻度判定処理S1350を終える。
【0126】
ステップS1354において、頻度カウンタが頻度閾値より小さいと判別した場合には、フレーム判定部は、判定結果をNG(不正)とし(ステップS1356)、フレーム頻度判定処理S1350を終える。
【0127】
[1.19 実施の形態1の効果]
実施の形態1に係る車載ネットワークシステム10では、送受信するフレームの頻度や周期等といった複数のルール項目(基準)を用いて、定められたルールに適合するフレームか否かを判定して不適合の場合にその後の処理をフィルタリング(抑止)する。このため、不正なアプリケーションプログラムによるバス200への不正なフレームの送出が低減される。また、主にバス200を用いた通信を担当するチップであるシステム制御ユニット110と、主にアプリケーションプログラムの実行制御等を担当するチップであるマルチメディア制御ユニット150とのそれぞれのフレーム判定部により送信フレームと受信フレームとの判定を分担して、フレームがルールに適合するか否かを判定している。これにより、ルールに適合しないフレームをチップ間で伝送しないため、処理負荷が軽減される。
【0128】
[1.20 実施の形態1の変形例1]
以下、上述したフレーム周期判定処理S1330(図17参照)を一部変形したフレーム周期判定処理S3330について説明する。
【0129】
図19は、フレーム周期判定処理S3330のフローチャートを示す。フレーム判定部(つまりフレーム判定部115或いはフレーム判定部152)は、上述したフレーム周期判定処理S1330の代わりにフレーム周期判定処理S3330を実行する。
【0130】
なお、フレーム周期判定処理S3330におけるステップS1331〜S1336は上述したフレーム周期判定処理S1330(図17)と同一内容であり、ここでは適宜説明を省略する。
【0131】
ステップS1333において、差分時刻が周期±マージンの範囲内であると判別した場合には、フレーム判定部は、判定結果をOK(正常)とし(ステップS1334)、判定対象のフレームを受信した時刻を最新受信時刻として保存する(ステップS3331)。
【0132】
ステップS1335又はステップS3331の後に、フレーム判定部は、差分時刻が周期+マージンより大きいか否かを判別する(ステップS1336)。このステップS1336で、差分時刻が周期+マージンより大きくないと判別した場合には、フレーム判定部は、フレーム周期判定処理S3330を終える。また、差分時刻が周期+マージンより大きいと判別した場合には、フレーム判定部は、ステップS3331で保存した最新受信時刻を用いて基準時刻を更新する(ステップS3332)。なお、ステップS3332では、判定結果がOKとなる時刻の範囲において複数のフレームを受信した場合における最新(最後)の受信時刻を用いて基準時刻を更新するが、この代わりに、例えば、判定結果がOKとなる時刻の範囲において複数のフレームを受信した場合における最初の受信時刻を用いて基準時刻を更新しても良い。また、その複数のフレームの受信時刻のうち、更新前の基準時刻に周期を加えた時刻に最も近い受信時刻を用いて基準時刻を更新しても良い。
【0133】
ステップS3332に続いて、フレーム判定部は、基準時刻+周期を最新受信時刻として保存し(ステップS3333)、フレーム周期判定処理S3330を終える。なお、ステップS3333で、基準時刻+周期の代わりに、基準時刻+周期−マージン〜基準時刻+周期+マージンの範囲内のいずれかの時刻を、最新受信時刻として保存することとしても良い。
【0134】
実施の形態1の変形例1によれば、基準時刻+周期±マージンの範囲内の全てのフレームの判定結果をOKとするので、ルールに適合したフレームを不正と誤判定してしまうことを抑制し得る。
【0135】
[1.21 実施の形態1の変形例2]
上述したシステム制御ユニット110のフレーム判定部115とマルチメディア制御ユニット150のフレーム判定部152とにおけるフレーム判定処理(判定ルールへの適合性の判定)の分担(図15図16参照)を、変更しても良い。実施の形態1の変形例2として、図20及び図21に、別の分担の例を示す。
【0136】
図20は、システム制御ユニットフレーム判定処理S1300の変形例としてのシステム制御ユニットフレーム判定処理S4300を示すフローチャートである。なお、システム制御ユニットフレーム判定処理S4300におけるステップS1301〜S1306は上述したシステム制御ユニットフレーム判定処理S1300(図15)と同一内容であり、ここでは説明を省略する。
【0137】
ステップS1305で、判定対象のフレームが、データ長の基準及びデータ範囲の基準の両方に適合していると判定した場合には、フレーム判定部115は、判定結果をOK(正常)とし(ステップS4301)、システム制御ユニットフレーム判定処理を終える。
【0138】
システム制御ユニットフレーム判定処理S4300では、システム制御ユニットフレーム判定処理S1300(図15)におけるフレーム周期判定処理S1330及びフレーム頻度判定処理S1350を含んでいない。
【0139】
図21は、マルチメディア制御ユニットフレーム判定処理S1600の変形例としてのマルチメディア制御ユニットフレーム判定処理S4600を示すフローチャートである。なお、マルチメディア制御ユニットフレーム判定処理S4600におけるステップS1303〜S1307、S1601、S1602、S1330及びS1350は上述したマルチメディア制御ユニットフレーム判定処理S1600(図16)と同一内容であり、ここでは適宜説明を省略する。
【0140】
フレーム判定部152は、判定対象のフレームのIDと一致するIDが判定ルール(図6参照)に記載されているかを確認し(ステップS1303)、記載されていればそのIDに関する判定ルールの各項目を取得する(ステップS1304)。判定対象のフレームのIDと一致するIDが判定ルールに記載されていなければ、判定結果をNGとして(ステップS1306)、マルチメディア制御ユニットフレーム判定処理を終える。
【0141】
フレーム判定部152は、判定対象が送信フレームか、受信フレームかを判別し(ステップS1601)、送信フレームの場合は、ステップS1304で取得した判定ルールのデータ長及びデータ範囲という項目の基準に判定対象のフレームが適合しているか否かを判定する(ステップS1305)。なお、フレーム判定部152は、ユニット間通信処理部151からデータ(受信フレーム)を通知された場合に、判定対象が受信フレームであると判別し、アプリケーション実行部154からデータ(送信フレームの内容)を通知された場合に、判定対象が送信フレームであると判別する。ステップS1305において、判定対象のフレームがデータ長の基準及びデータ範囲の基準のいずれかに適合しなければ、フレーム判定部152は、判定結果をNGとして(ステップS1306)、マルチメディア制御ユニットフレーム判定処理を終える。
【0142】
ステップS1305で判定対象のフレームがデータ長の基準及びデータ範囲の基準の両方に適合していると判定した場合、又は、ステップS1601で受信フレームと判別された場合には、フレーム判定部152は、判定対象のフレームが周期的に送信又は受信されるフレームであるか否かを判別する(ステップS1307)。フレーム判定部152は、周期的に送信又は受信されるフレームであると判別した場合に、フレーム周期判定処理を行い(ステップS1330)、周期的に送信又は受信されるフレームでないと判別した場合に、フレーム頻度判定処理を行う(ステップS1350)。
【0143】
このように、実施の形態1の変形例2では、マルチメディア制御ユニットフレーム判定処理S4600において、送信フレームのみならず受信フレームも対象として、フレーム周期判定処理S1330及びフレーム頻度判定処理S1350のいずれかが実行される。即ち、実施の形態1と比較すると変形例2では、受信フレームについての一部の処理(フレーム周期判定処理S1330、フレーム頻度判定処理S1350等)の分担がシステム制御ユニット110からマルチメディア制御ユニット150へと移っている。この変形例2は、例えばマルチメディア制御ユニットがシステム制御ユニットよりも高性能な場合等において効果的である。このように、各制御ユニットの処理能力に応じて、フレームのルールへの適合性の判定処理の負荷分散を行うことが有用である。
【0144】
[1.22 実施の形態1の変形例3]
以下、更に別の例として、システム制御ユニット110のフレーム判定部115とマルチメディア制御ユニット150のフレーム判定部152とにおけるフレーム判定処理(判定ルールへの適合性の判定)の分担(図15図16参照)を変更した変形例3を示す。
【0145】
図22は、システム制御ユニットフレーム判定処理S1300の別の変形例としてのシステム制御ユニットフレーム判定処理S5300を示すフローチャートである。なお、システム制御ユニットフレーム判定処理S5300におけるステップS1301〜S1304、S1306、S1307、S1330及びS1350は、上述したシステム制御ユニットフレーム判定処理S1300(図15)と同一内容であり、ここでは説明を適宜省略する。
【0146】
ステップS1304の後に、フレーム判定部115は、判定対象のフレームが周期的に送信又は受信されるフレームであるか否かを判別する(ステップS1307)。
【0147】
システム制御ユニットフレーム判定処理S5300では、システム制御ユニットフレーム判定処理S1300(図15)における、判定ルールのデータ長及びデータ範囲の基準に判定対象のフレームが適合しているか否かを判定するステップS1305を含んでいない。
【0148】
図23は、マルチメディア制御ユニットフレーム判定処理S1600の別の変形例としてのマルチメディア制御ユニットフレーム判定処理S5600を示すフローチャートである。なお、マルチメディア制御ユニットフレーム判定処理S5600におけるステップS1303〜S1307、S1601、S1602、S1330及びS1350は上述したマルチメディア制御ユニットフレーム判定処理S1600(図16)と同一内容であり、ここでは適宜説明を省略する。
【0149】
フレーム判定部152は、判定対象のフレームのIDと一致するIDが判定ルール(図6参照)に記載されているかを確認し(ステップS1303)、記載されていればそのIDに関する判定ルールの各項目を取得する(ステップS1304)。判定対象のフレームのIDと一致するIDが判定ルールに記載されていなければ、判定結果をNGとして(ステップS1306)、マルチメディア制御ユニットフレーム判定処理を終える。
【0150】
ステップS1304に続いて、フレーム判定部152は、判定ルールのデータ長及びデータ範囲という項目の基準に判定対象のフレームが適合しているか否かを判定する(ステップS1305)。ステップS1305において、判定対象のフレームがデータ長の基準及びデータ範囲の基準のいずれかに適合しなければ、フレーム判定部152は、判定結果をNGとして(ステップS1306)、マルチメディア制御ユニットフレーム判定処理を終える。
【0151】
ステップS1305で判定対象のフレームがデータ長の基準及びデータ範囲の基準の両方に適合していると判定した場合には、フレーム判定部152は、判定対象が送信フレームか、受信フレームかを判別する(ステップS1601)。送信フレームでなく受信フレームの場合は、フレーム判定部152は判定結果をOKとしてマルチメディア制御ユニットフレーム判定処理を終え(ステップS1602)、送信フレームの場合には、ステップS1307へと進む。
【0152】
このように、実施の形態1の変形例3では、マルチメディア制御ユニットフレーム判定処理S5600において、送信フレームのみならず受信フレームも対象として、判定ルールのデータ長及びデータ範囲の基準に判定対象のフレームが適合しているか否かを判定するステップS1305が実行される。即ち、実施の形態1と比較すると変形例3では、受信フレームについての一部の処理(ステップS1305)の分担がシステム制御ユニット110からマルチメディア制御ユニット150へと移っている。この変形例3は、例えばマルチメディア制御ユニットがシステム制御ユニットよりも高性能な場合等において効果的である。また、システム制御ユニット110及びマルチメディア制御ユニット150のうち、バス200からの受信フレームを先に処理するシステム制御ユニット110で受信フレームの周期又は頻度に係るルール項目(基準)への適合性の判定を行う。このため、両ユニット間での伝達による遅延等の影響を受けることなく、精度良くその判定が行える。このように、各制御ユニットのバス200との位置関係及び処理能力に応じて、フレームのルールへの適合性の判定処理の負荷分散を適切に行うことが有用である。
【0153】
この変形例3では、例えば、ヘッドユニット100のマルチメディア制御ユニット150(第1制御ユニット)であるチップにおいてメモリに格納されたプログラムをプロセッサで実行することにより、送信フレームについて第1所定ルール(例えばデータ長、データ範囲等、或いは、周期、頻度等)に適合しているか不適合であるかを判定する第1判定部としての機能を実現している。送信フレームについては、第1判定部により不適合であると判定された場合に、その送信フレームに係る情報の第1制御ユニットからシステム制御ユニット110(第2制御ユニット)への送信は抑止される。また、ヘッドユニット100のシステム制御ユニット110(第2制御ユニット)であるチップにおいてメモリに格納されたプログラムをプロセッサで実行することにより、受信フレームについて第2所定ルール(例えば周期、頻度等)に適合しているか不適合であるかを判定する第2判定部としての機能を実現している。また、マルチメディア制御ユニット150であるチップにおいてメモリに格納されたプログラムをプロセッサで実行することにより、受信フレームについて第3所定ルール(例えばデータ長、データ範囲等)に適合しているか不適合であるかを判定する第3判定部としての機能を実現している。なお、第1判定部及び第3判定部は、フレーム判定部152の構成要素であり、第2判定部は、フレーム判定部115の構成要素である。
【0154】
(実施の形態2)
以下、本発明の実施の形態として、バスに送出する送信フレーム等を含むフレームについてルールへの適合性を判定して、その判定結果をログとして保存する車両用通信方法を行う車両用通信装置(ヘッドユニット2100)を含む車載ネットワークシステムについて図面を用いて説明する。本実施の形態に係る車載ネットワークシステムは、実施の形態1で示した車載ネットワークシステム10のヘッドユニット100をヘッドユニット2100に置き換えたものである。
【0155】
[2.1 ヘッドユニット2100の構成]
ヘッドユニット2100は、ヘッドユニット100と同様に車両用通信装置であり、例えば、自動車のインパネ等に設けられ、運転者に視認されるための情報を表示する表示装置、運転者の操作を受け付ける入力手段等を備える一種のECUである。
【0156】
図24は、ヘッドユニット2100の構成図である。同図に示すようにヘッドユニット2100は、システム制御ユニット2110と、マルチメディア制御ユニット2150とを含んで構成される。なお、実施の形態1で示した構成要素と同一のものには同じ符号を付しており、これらについては説明を省略する。
【0157】
システム制御ユニット2110は、実施の形態1で示したシステム制御ユニット110を一部変形したものであり、マルチメディア制御ユニット2150は、実施の形態1で示したマルチメディア制御ユニット150を一部変形したものである。
【0158】
システム制御ユニット2110は、主にバス200での通信の制御を担い、フレーム送受信部111と、受信フレーム解釈部112と、受信ID判断部113と、受信IDリスト保持部114と、フレーム判定部2115と、判定ルール保持部116と、ユニット間通信処理部117と、送信フレーム生成部118と、判定結果保持部2119とを含んで構成される。
【0159】
フレーム判定部2115は、受信フレーム解釈部112から受信したフレームの値、或いは、ユニット間通信処理部117より送信すべきフレームの内容となる値を受け取る。そして、判定ルール保持部116から判定ルールを取得し、判定ルールに基づいたフレーム判定処理(システム制御ユニットフレーム判定処理)の結果に関する情報を判定結果保持部2119に通知する。システム制御ユニットフレーム判定処理の内容は実施の形態1で示したものと同じである(図15参照)。また、フレーム判定部2115は、システム制御ユニットフレーム判定処理の結果に拘らず、送信フレーム生成部118、或いは、ユニット間通信処理部117へフレームの値を通知する。
【0160】
判定結果保持部2119は、メモリ等の記憶媒体を含んで実現され、フレーム判定部2115からフレーム判定処理の結果に関する情報を通知され、その情報をログとして記憶媒体に保存する。フレーム判定処理の結果に関する情報は、判定対象のフレームの内容と判定結果とを含む情報である。
【0161】
また、マルチメディア制御ユニット2150は、主にアプリケーションプログラムの実行制御処理を担い、ユニット間通信処理部151と、フレーム判定部2152と、判定ルール保持部153と、アプリケーション実行部154と、判定結果保持部2155を含んで構成される。
【0162】
フレーム判定部2152は、アプリケーション実行部154から送信すべきフレームの内容となる値、或いは、ユニット間通信処理部151から受信されたフレームの値を受け取る。そして、判定ルール保持部153から判定ルールを取得し、判定ルールに基づいたフレーム判定処理(マルチメディア制御ユニットフレーム判定処理)の結果に関する情報を判定結果保持部2155に通知する。マルチメディア制御ユニットフレーム判定処理の内容は実施の形態1で示したものと同じである(図16参照)。また、フレーム判定部2152は、マルチメディア制御ユニットフレーム判定処理の結果に拘らず、アプリケーション実行部154、或いは、ユニット間通信処理部151へフレームの値を通知する。
【0163】
判定結果保持部2155は、メモリ等の記憶媒体を含んで実現され、フレーム判定部2152からフレーム判定処理の結果に関する情報(判定対象のフレームの内容と判定結果とを含む情報)を通知され、その情報をログとして記憶媒体に保存する。
【0164】
[2.2 ヘッドユニット2100によるフレーム受信の動作]
図25は、ヘッドユニット2100におけるフレーム受信処理の一例を示すフローチャートである。同図に示すように、ヘッドユニット2100におけるフレーム受信処理は、ヘッドユニット100におけるフレーム受信処理(図13参照)のステップS1100、S1200、S1300、S1500、S1600及びS1800と同一の処理を含む。この同一の処理については説明を適宜省略する。
【0165】
システム制御ユニットフレーム判定処理S1300に続いて、ヘッドユニット2100のシステム制御ユニット2110におけるフレーム判定部2115は、判定結果保持部2119に判定結果に関する情報(判定対象のフレームに内容と判定結果とを含む情報)を通知してログとして保存させる(ステップS11001)。続いて、ユニット間の通信処理により、システム制御ユニット2110はマルチメディア制御ユニット2150にフレーム(受信フレーム)の内容を通知する(ステップS1500)。
【0166】
また、マルチメディア制御ユニットフレーム判定処理S1600に続いて、ヘッドユニット2100のマルチメディア制御ユニット2150におけるフレーム判定部2152は、判定結果保持部2155に判定結果に関する情報(判定対象のフレームの内容と判定結果とを含む情報)を通知してログとして保存させる(ステップS11002)。続いて、フレーム判定部2152は、アプリケーション実行部154に受信フレームの内容を通知する。
【0167】
[2.3 ヘッドユニット2100によるフレーム送信の動作]
図26は、ヘッドユニット2100におけるフレーム送信処理の一例を示すフローチャートである。同図に示すように、ヘッドユニット2100におけるフレーム送信処理は、ヘッドユニット100におけるフレーム送信処理(図14参照)のステップS2100、S1600、S2300、S1300、S2500及びS2600と同一の処理を含む。この同一の処理については説明を適宜省略する。
【0168】
マルチメディア制御ユニットフレーム判定処理S1600に続いて、ヘッドユニット2100のマルチメディア制御ユニット2150におけるフレーム判定部2152は、判定結果保持部2155に判定結果に関する情報(判定対象のフレームの内容と判定結果とを含む情報)をログとして保存させる(ステップS11003)。続いて、ユニット間の通信処理により、マルチメディア制御ユニット2150はシステム制御ユニット2110にフレーム(送信フレーム)の内容を通知する(ステップS2300)。
【0169】
また、システム制御ユニットフレーム判定処理S1300に続いて、ヘッドユニット2100のシステム制御ユニット2110におけるフレーム判定部2115は、判定結果保持部2119に判定結果に関する情報(判定結果のフレームの内容と判定結果とを含む情報)をログとして保存させる(ステップS11004)。続いて、送信フレーム生成部118は、送信フレームの内容(マルチメディア制御ユニット2150においてアプリケーションプログラムにより特定された内容)に基づいて送信フレーム(データフレーム)を生成する(ステップS2500)。
【0170】
[2.4 実施の形態2の効果]
実施の形態2に係る車載ネットワークシステムのヘッドユニット2100では、送受信するフレームについて、頻度や周期等、複数のルール項目(基準)への適合性を判定して、判定の結果をログとして保存しておく。この保存したログを収集し、分析することにより、例えば、判定ルールの各基準の見直しを行うことができ、フレーム判定の精度の向上等を図ることができる。なお、判定ルールの各基準の見直しの結果は、車載ネットワークシステムを構成する装置等の製造、或いは、その装置で使用されるデータ、プログラム等の更新等に活用され得る。
【0171】
(実施の形態3)
以下、本発明の実施の形態として、バスに送出する送信フレーム等を含むフレームについてルールへの適合性を判定して、その判定結果を車両外部に所在するサーバ(コンピュータ)に通知(送信)する車両用通信方法を行う車両用通信装置(ヘッドユニット3100)を含む車載ネットワークシステムについて図面を用いて説明する。本実施の形態に係る車載ネットワークシステム10aは、実施の形態1で示した車載ネットワークシステム10のヘッドユニット100をヘッドユニット3100に置き換えたものである。
【0172】
[3.1 ネットワークシステム30の全体構成]
図27は、本発明に係るネットワークシステム30の全体構成を示す図である。ネットワークシステム30は、車両に搭載された車載ネットワークシステム10aと、車両外部に所在するサーバ3500とを含んで構成される。
【0173】
車載ネットワークシステム10aは、車載ネットワークシステム10を一部変形したものであり、バス200と、ヘッドユニット3100、各種機器に接続されたECU400a〜400d等のECUといったバスに接続された各ノードとを含んで構成される。車載ネットワークシステム10aの構成要素のうち車載ネットワークシステム10(図1参照)の構成要素と同一のものには同じ符号を付しており、これらについては説明を省略する。車載ネットワークシステム10aにおいてはCANプロトコルに従って、ヘッドユニット3100を含む各ECUがフレームの授受を行う。
【0174】
ヘッドユニット3100は、ヘッドユニット100と同様に車両用通信装置であり、例えば、自動車のインパネ等に設けられ、運転者に視認されるための情報を表示する表示装置、運転者の操作を受け付ける入力手段等を備える一種のECUである。ヘッドユニット3100は、ECU400a〜400dから送信されるフレームを受信し、各種状態をディスプレイ(図示しない)に表示して、ユーザに提示する機能を持つ。また、ヘッドユニット3100が取得する各情報を示すフレームを生成して、そのフレームを、バス200を介して1台以上のECUに送信する機能を持つ。また、送受信するフレームについてルールへの適合性を判定することで、不正なフレーム(つまりルールに適合しないフレーム)か否かの判別等を行い、その判定結果に関する情報をサーバ3500に通知(送信)する機能を有する。なお、ヘッドユニット3100も一種のECUである。
【0175】
サーバ3500は、ヘッドユニット3100と通信可能な装置(サーバ装置)であり、フレームの判定結果に関する情報をヘッドユニット3100から受信して、収集する機能を有するコンピュータである。
【0176】
[3.2 ヘッドユニット3100の構成]
図28は、ヘッドユニット3100の構成図である。ヘッドユニット3100は、システム制御ユニット3110と、マルチメディア制御ユニット3150と、外部通信制御ユニット3170とを含んで構成される。なお、実施の形態1で示した構成要素と同一のものには同じ符号を付しており、これらについては説明を省略する。
【0177】
システム制御ユニット3110は、実施の形態1で示したシステム制御ユニット110を一部変形したものであり、マルチメディア制御ユニット3150は、実施の形態1で示したマルチメディア制御ユニット150を一部変形したものである。
【0178】
システム制御ユニット3110は、主にバス200での通信の制御を担い、フレーム送受信部111と、受信フレーム解釈部112と、受信ID判断部113と、受信IDリスト保持部114と、フレーム判定部3115と、判定ルール保持部116と、ユニット間通信処理部117と、送信フレーム生成部118とを含んで構成される。
【0179】
フレーム判定部3115は、受信フレーム解釈部112から受信したフレームの値、或いは、ユニット間通信処理部117より送信すべきフレームの内容となる値を受け取る。そして、判定ルール保持部116から判定ルールを取得し、判定ルールに基づいたフレーム判定処理(システム制御ユニットフレーム判定処理)の結果に関する情報をユニット間通信処理部117に通知して外部通信制御ユニット3170へと通知させる。システム制御ユニットフレーム判定処理の内容は実施の形態1で示したものと同じである(図15参照)。また、フレーム判定部3115は、システム制御ユニットフレーム判定処理の結果に拘らず、送信フレーム生成部118、或いは、ユニット間通信処理部117へフレームの値を通知する。
【0180】
また、マルチメディア制御ユニット3150は、主にアプリケーションプログラムの実行制御処理を担い、ユニット間通信処理部151と、フレーム判定部3152と、判定ルール保持部153と、アプリケーション実行部154とを含んで構成される。
【0181】
フレーム判定部3152は、アプリケーション実行部154から送信すべきフレームの内容となる値、或いは、ユニット間通信処理部151から受信されたフレームの値を受け取る。そして、判定ルール保持部153から判定ルールを取得し、判定ルールに基づいたフレーム判定処理(マルチメディア制御ユニットフレーム判定処理)の結果に関する情報をユニット間通信処理部151に通知して外部通信制御ユニット3170へと通知させる。マルチメディア制御ユニットフレーム判定処理の内容は実施の形態1で示したものと同じである(図16参照)。また、フレーム判定部3152は、マルチメディア制御ユニットフレーム判定処理の結果に拘らず、アプリケーション実行部154、或いは、ユニット間通信処理部151へフレームの値を通知する。
【0182】
外部通信制御ユニット3170は、例えばシステム制御ユニット3110及びマルチメディア制御ユニット3150とは異なるチップであり、機能構成要素としてユニット間通信処理部3171と、外部通信処理部3172とを含んで構成される。これらの各機能構成要素は、チップに集積された通信回路、メモリ及びこのメモリに格納された制御プログラムを実行するプロセッサその他の回路等により実現される。
【0183】
ユニット間通信処理部3171は、異なるユニット間の通信処理を行う。即ち、ユニット間通信処理部117は、システム制御ユニット3110或いはマルチメディア制御ユニット3150との間で、有線又は無線の通信により情報の授受を行う。
【0184】
外部通信処理部3172は、車両外部のサーバ3500と無線通信するための機能を有し、ユニット間通信処理部3171より、フレームの判定結果に関する情報を通知されるとサーバ3500へ通知(送信)する。
【0185】
[3.3 ヘッドユニット3100によるフレーム受信の動作]
図29は、ヘッドユニット3100におけるフレーム受信処理の一例を示すフローチャートである。同図に示すように、ヘッドユニット3100におけるフレーム受信処理は、ヘッドユニット100におけるフレーム受信処理(図13参照)のステップS1100、S1200、S1300、S1500、S1600及びS1800と同一の処理を含む。この同一の処理については説明を適宜省略する。
【0186】
システム制御ユニットフレーム判定処理S1300に続いて、ヘッドユニット3100のシステム制御ユニット3110におけるフレーム判定部3115は、判定結果に関する情報(判定対象のフレームに内容と判定結果とを含む情報)を、ユニット間通信処理部117を介して外部通信制御ユニット3170へ通知する(ステップS21001)。これに対応して、外部通信制御ユニット3170は外部通信処理部3172により、判定結果に関する情報をサーバへ通知する(ステップS21002)。続いて、ユニット間の通信処理により、システム制御ユニット3110はマルチメディア制御ユニット3150にフレーム(受信フレーム)の内容を通知する(ステップS1500)。
【0187】
また、マルチメディア制御ユニットフレーム判定処理S1600に続いて、ヘッドユニット3100のマルチメディア制御ユニット3150におけるフレーム判定部3152は、判定結果に関する情報(判定対象のフレームの内容と判定結果とを含む情報)を、ユニット間通信処理部151を介して外部通信制御ユニット3170へ通知する(ステップS21003)。これに対応して、外部通信制御ユニット3170は外部通信処理部3172により、判定結果に関する情報をサーバへ通知する(ステップS21004)。続いて、フレーム判定部3152は、アプリケーション実行部154に受信フレームの内容を通知する。
【0188】
[3.4 ヘッドユニット3100によるフレーム送信の動作]
図30は、ヘッドユニット3100におけるフレーム送信処理の一例を示すフローチャートである。同図に示すように、ヘッドユニット3100におけるフレーム送信処理は、ヘッドユニット100におけるフレーム送信処理(図14参照)のステップS2100、S1600、S2300、S1300、S2500及びS2600と同一の処理を含む。この同一の処理については説明を適宜省略する。
【0189】
マルチメディア制御ユニットフレーム判定処理S1600に続いて、ヘッドユニット3100のマルチメディア制御ユニット3150におけるフレーム判定部3152は、判定結果に関する情報(判定対象のフレームの内容と判定結果とを含む情報)を、ユニット間通信処理部151を介して外部通信制御ユニット3170へと通知する(ステップS21003)。これに対応して、外部通信制御ユニット3170は外部通信処理部3172により、判定結果に関する情報をサーバへ通知する(ステップS21004)。続いて、ユニット間の通信処理により、マルチメディア制御ユニット3150はシステム制御ユニット3110にフレーム(送信フレーム)の内容を通知する(ステップS2300)。
【0190】
また、システム制御ユニットフレーム判定処理S1300に続いて、ヘッドユニット3100のシステム制御ユニット3110におけるフレーム判定部3115は、判定結果に関する情報(判定結果のフレームの内容と判定結果とを含む情報)を、ユニット間通信処理部117を介して外部通信制御ユニット3170へと通知する(ステップS21001)。これに対応して、外部通信制御ユニット3170は外部通信処理部3172により、判定結果に関する情報をサーバへ通知する(ステップS21002)。続いて、送信フレーム生成部118は、送信フレームの内容(マルチメディア制御ユニット3150においてアプリケーションプログラムにより特定された内容)に基づいて送信フレーム(データフレーム)を生成する(ステップS2500)。
【0191】
[3.5 実施の形態3の効果]
実施の形態3に係る車載ネットワークシステム10aのヘッドユニット3100は、送受信するフレームについて、頻度や周期等、複数のルール項目(基準)への適合性を判定して、判定の結果に関する情報をサーバ3500に送信する。サーバ3500が、この判定の結果に関する情報を収集して分析することにより、例えば、判定ルールの各基準の見直しを行うことができ、フレーム判定の精度の向上等を図ることができる。なお、判定ルールの各基準の見直しの結果は、車載ネットワークシステムを構成する装置等の製造、或いは、その装置で使用されるデータ、プログラム等の更新等に活用され得る。
【0192】
(他の実施の形態)
以上のように、本発明に係る技術の例示として実施の形態1〜3を説明した。しかしながら、本発明に係る技術は、これに限定されず、適宜、変更、置き換え、付加、省略等を行った実施の形態にも適用可能である。例えば、以下のような変形例も本発明の一実施態様に含まれる。
【0193】
(1)上記実施の形態では、CANプロトコルにおけるデータフレームを標準IDフォーマットで記述しているが、拡張IDフォーマットで合っても良い。拡張IDフォーマットの場合には、標準IDフォーマットにおけるID位置のベースIDと、拡張IDとを合わせて29ビットでID(メッセージID)を表すので、この29ビットのIDを上述の実施の形態におけるID(メッセージID)と扱えば良い。
【0194】
(2)上記実施の形態では、フレーム周期判定処理で利用するマージンを1つに定めているが、複数持っても良い。また、各マージンを用いた判定結果を同一の扱いとしても良いし、各マージンを用いた判定結果に重み付けを行っても良い。また、マージン毎に判定結果後の処理を変更しても良い。例えば、第一のマージンの範囲に当てはまるフレームの判定結果はログを残すだけにし、第二のマージンの範囲に当てはまるフレームの判定結果はフィルタリングに用い、不正と判定した場合にフレームの送受信処理を抑止しても良い。また、判定ルールにおけるマージンの値は固定値に限定されず、計算式であっても良い。また、全てのIDのフレーム処理総数に応じて、マージンの値を動的に変更しても良い。
【0195】
(3)上記実施の形態では、フレーム頻度判定処理で利用する閾値(頻度閾値)を1つに定めているが、複数持っても良い。また、各閾値を用いた判定結果を同一の扱いとしても良いし、各閾値を用いた判定結果に重み付けを行っても良い。また、閾値毎に判定結果後の処理を変更しても良い。例えば、第一の閾値を使ったフレームの判定結果はログを残すだけにし、第二の閾値に当てはまるフレームの判定結果はフィルタリングに用い、不正と判定した場合にフレームの送受信処理を抑止しても良い。また、判定ルールにおける頻度閾値は固定値に限定されず、計算式であっても良い。また、全てのIDのフレーム処理総数に応じて、頻度閾値を動的に変更しても良い。
【0196】
(4)上記実施の形態では、フレームの周期についての基準への適合性の判定結果をOK(正常)及びNG(不正)の2種類としているが、複数種類としても良い。例えば、実施の形態1の変形例1のように、一定のマージン範囲内に複数のフレームの受信を許容するような場合において、複数受信である旨を判定結果に含めるようにしても良い。また、判定ルールの各項目(基準)への適合性について、一定の評価基準で適合度合い(例えば100%適合、80%適合等)を表して、その適合度合いを判定結果としても良い。
【0197】
(5)上記実施の形態では、フレーム判定処理をシステム制御ユニットとマルチメディア制御ユニットとに分割して実施しているが、どちらか一方のみで行うようにしても良い。また、ヘッドユニット等のECUである車両用通信装置においては、送信フレームについてルールへの適合性の判定を行えば必ずしも受信フレームについてルールの適合性の判定を行わなくてもよい。また、上述の実施の形態では、受信フレームと送信フレームとの区別に基づいて、フレーム判定処理を実施するユニットを分離する例を示したが、ID毎、タイミング毎等の区別により分離しても良い。また、フレーム判定(フレームのルールへの適合性の判定)を行う部分を同一ユニット内の複数箇所に分離しても良い。例えば、アプリケーションプログラム毎に分離しても良く、また、同一チップ内において複数のオペレーティングシステム(OS)が稼働する場合においてはOS毎に分離しても良い。また、フレーム判定を実行可能な箇所を複数設けておき、システム全体の処理負荷や、フレーム処理の頻度等に応じて動的に、フレーム判定を実際に行う箇所を選定することとしても良い。また、受信フレーム或いは送信フレームについてのルールへの適合性の判定を、マルチメディア制御ユニットとシステム制御ユニットとの間でどのように分担しても良い。つまり、ユニットそれぞれがどのルール項目(基準)の判定を分担しても良い。車載ネットワークシステムのバスに接続されたヘッドユニット等のECUである車両用通信装置は、バスへの送出用のフレームである送信フレームを特定するマルチメディア制御ユニット(第1制御ユニット)と、この第1制御ユニットと有線又は無線により通信してフレームに係る情報を授受し得るシステム制御ユニット(第2制御ユニット)とを備え、これら第1制御ユニット及び第2制御ユニットのうち少なくとも1つが、送信フレーム等について、ルールへの適合性に係る判定を行うものであれば良い。また、第1制御ユニットは、送信フレームについて第1所定ルール(例えば図6の判定ルールのいずれかの項目の基準)に適合しているか不適合であるかを判定する第1判定部を有し、第2制御ユニットは、受信フレームについて第2所定ルール(例えば図6の判定ルールのいずれかの項目の基準)に適合しているか不適合であるかを判定する第2判定部を有してもよい。
【0198】
(6)上記実施の形態では、フレーム周期判定処理で利用する判定ルールにおける周期とマージンとを、ID毎に1つに定めているが、複数のIDをまとめたグループ単位毎に定めても良い。また、フレーム周期判定処理は1フレームの送信又は受信毎に1回ずつ行うようにしている。しかし、これに限定するものではなく、全てのIDにまたがったフレーム周期判定処理、グループ単位のフレーム周期判定処理等といった、判定内容の異なるフレーム周期判定処理を複数組み合わせて行うこととしても良い。
【0199】
(7)上記実施の形態では、フレーム頻度判定処理で利用する判定ルールにおける閾値(頻度閾値)を、ID毎に1つに定めているが、複数のIDをまとめたグループ単位毎に定めても良い。また、フレーム頻度判定処理は1フレームの送信又は受信毎に1回ずつ行うようにしている。しかし、これに限定するものではなく、全てのIDにまたがったフレーム頻度判定処理、グループ単位のフレーム頻度判定処理等といった、判定内容の異なるフレーム頻度判定処理を複数組み合わせて行うこととしても良い。
【0200】
(8)上記実施の形態2では、判定結果保持部を、各ユニット(システム制御ユニット及びマルチメディア制御ユニットのそれぞれ)が有している。しかし、この構成に限定するものではなく、どちらか一方だけが有しても良いし、どちらとも異なるヘッドユニット内の別の独立したユニット(チップ等)だけが有しても良い。また、判定結果保持部がログを保存する記憶媒体(記録媒体)は、判定結果保持部の内部のメモリ等の他、外部の回路、装置等で実現されたメモリ、ハードディスク等であっても良い。
【0201】
(9)上記実施の形態2では、フレームの判定結果に応じて、判定結果をログに保存するかしないかを切り替えても良い。また、全てのIDの判定結果を保存しても良いし、特定のIDに対する判定結果のみを保存しても良い。また、ユニット毎に判定結果を保存するかしないかを切り替えても良い。
【0202】
(10)上記実施の形態3では、サーバとの通信のために外部通信制御ユニット3170を有している。しかし、この構成に限定するものではなく、システム制御ユニット3110及びマルチメディア制御ユニット3150のどちらか一方、或いは、両方に、サーバとの通信のための構成(集積回路等)を含ませても良い。また、システム制御ユニット3110から外部通信制御ユニット3170への、フレームの判定結果に関する情報の伝達は、直接ではなく、マルチメディア制御ユニット3150(ユニット間通信処理部151)を介して行われるようにしても良い。
【0203】
(11)上記実施の形態3では、フレームの判定結果に応じて、判定結果をサーバに通知するかしないかを切り替えても良い。また、全てのIDの判定結果をサーバに通知しても良いし、特定のIDに対する判定結果のみをサーバに通知しても良い。また、ユニット毎に判定結果をサーバに通知するかしないかを切り替えても良い。
【0204】
(12)上記実施の形態3では、ユニット毎に一回のフレーム判定処理を行う度に判定結果をサーバに通知しているが、ある一定数のフレーム判定処理の判定結果が溜まった時点で、まとめてサーバに通知しても良い。また、一定時間間隔で定期的にフレームの判定結果をサーバに通知しても良い。
【0205】
(13)上記実施の形態で示した判定ルール(図6参照)は一例であり、例示したルール項目以外の項目を含めても良いし、例示した値と異なる値にしても良い。また、判定ルールは、車両用通信装置(例えばヘッドユニット)の製造時、出荷時等に設定されても良いし、車載ネットワークシステムが搭載される車両の出荷時に設定されても良い。判定ルールは、車載ネットワークシステムの稼働中に更新されても良い。また、判定ルールは、外部との通信に基づいて設定及び更新されても、各種記録媒体等を用いて設定されても、ツール類等によって設定されても良い。
【0206】
(14)上記実施の形態で示したCANプロトコルは、TTCAN(Time-Triggered CAN)、CANFD(CAN with Flexible Data Rate)等の派生的なプロトコルをも包含する広義の意味を有するものであっても良い。
【0207】
(15)上記実施の形態における車両用通信装置の一例としてのヘッドユニットは、例えば、通信回路、メモリ、プロセッサその他の回路等を含む半導体集積回路のチップを含むこととしたが、ハードディスク装置、ディスプレイ、キーボード、マウス等の他のハードウェア構成要素を含んでいても良い。また、メモリに記憶された制御プログラムをプロセッサが実行することでソフトウェア的に機能を実現する代わりに、制御プログラムを用いない集積回路でその機能を実現することとしても良い。なお、チップは、必ずしもパッケージ化されている必要はない。
【0208】
(16)上記実施の形態における各装置を構成する構成要素の一部または全部は、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に置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行っても良い。バイオ技術の適用等が可能性としてあり得る。
【0209】
(17)上記各装置を構成する構成要素の一部または全部は、各装置に脱着可能なICカードまたは単体のモジュールから構成されているとしても良い。前記ICカードまたは前記モジュールは、マイクロプロセッサ、ROM、RAM等から構成されるコンピュータシステムである。前記ICカードまたは前記モジュールは、上記の超多機能LSIを含むとしても良い。マイクロプロセッサが、コンピュータプログラムに従って動作することにより、前記ICカードまたは前記モジュールは、その機能を達成する。このICカードまたはこのモジュールは、耐タンパ性を有するとしても良い。
【0210】
(18)本発明の一態様としては、上記に示す車両用通信方法であるとしても良い。また、この方法をコンピュータにより実現するコンピュータプログラムであるとしても良いし、前記コンピュータプログラムからなるデジタル信号であるとしても良い。また、本発明の一態様としては、前記コンピュータプログラムまたは前記デジタル信号をコンピュータで読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、CD−ROM、MO、DVD、DVD−ROM、DVD−RAM、BD(Blu-ray(登録商標) Disc)、半導体メモリ等に記録したものとしても良い。また、これらの記録媒体に記録されている前記デジタル信号であるとしても良い。また、本発明の一態様としては、前記コンピュータプログラムまたは前記デジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしても良い。また、本発明の一態様としては、マイクロプロセッサとメモリを備えたコンピュータシステムであって、前記メモリは、上記コンピュータプログラムを記録しており、前記マイクロプロセッサは、前記コンピュータプログラムに従って動作するとしても良い。また、前記プログラムまたは前記デジタル信号を前記記録媒体に記録して移送することにより、または前記プログラムまたは前記デジタル信号を、前記ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしても良い。
【0211】
(19)上記実施の形態及び上記変形例で示した各構成要素及び機能を任意に組み合わせることで実現される形態も本発明の範囲に含まれる。
【産業上の利用可能性】
【0212】
本発明は、車載ネットワークシステムにおいて不正なフレームのバスへの送出を低減させるために利用可能である。
【符号の説明】
【0213】
10,10a 車載ネットワークシステム
30 ネットワークシステム
100,2100,3100 ヘッドユニット
110,2110,3110 システム制御ユニット(第2制御ユニット)
111,410 フレーム送受信部
112,450 受信フレーム解釈部
113,430 受信ID判断部
114,440 受信IDリスト保持部
115,152,2115,2152,3115,3152 フレーム判定部
116,153 判定ルール保持部
117,151,3171 ユニット間通信処理部
118,420 送信フレーム生成部
150,2150,3150 マルチメディア制御ユニット(第1制御ユニット)
154 アプリケーション実行部
200 バス
310 エンジン
320 ブレーキ
330 ドア開閉センサ
340 窓開閉センサ
400a〜400d 電子制御ユニット(ECU)
410 フレーム処理部
470 データ取得部
2119,2155 判定結果保持部
3170 外部通信制御ユニット
3172 外部通信処理部
3500 サーバ
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20
図21
図22
図23
図24
図25
図26
図27
図28
図29
図30