JP2017229076A - 電子制御ユニット、車載ネットワークシステム及び車両用通信方法 - Google Patents

Abstract

【課題】バスを流れる不正なフレームに対応するための電子制御ユニットを提供する。【解決手段】電子制御ユニットは、少なくとも第１制御ユニット１５０と第２制御ユニット１１０とを有し、第１制御ユニット１５０は、第２制御ユニット１１０を介して車載ネットワークに接続され、第２制御ユニット１１０は、受信フレームについて、第１ルールへの適合性に係る第１の判定を行い、第１制御ユニット１５０は、受信フレームについて、第２ルールへの適合性に係る第２の判定を行い、電子制御ユニットは、第１の判定の結果及び第２の判定の結果を示す情報を所定記録媒体に記録し、第２制御ユニット１１０は、第１ルールに適合していると判定した場合に受信フレームを第１制御ユニット１５０へ送信し、第１ルールに不適合であると判定した場合に受信フレームを第１制御ユニット１５０へ送信しない。【選択図】図４

Description

本発明は、車載ネットワークに接続されメッセージ（フレーム）を送受信する車両用通信装置、車両用通信方法等に関する。

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

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

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

従来、異常なメッセージがＣＡＮのバス上に送信された場合に、バス間を接続するゲートウェイ装置が異常メッセージを検出して、他のバスに転送しないことで、バスの負荷の上昇を抑える技術が知られている（「特許文献１」参照）。また、周期的に送られてくるメッセージの周期をチェックし、不正なフレームを判定する技術が知られている（「非特許文献２」参照）。

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

"ＣＡＮ Ｓｐｅｃｉｆｉｃａｔｉｏｎ ２．０ Ｐａｒｔ Ａ"、［ｏｎｌｉｎｅ］、ＣＡＮ ｉｎ Ａｕｔｏｍａｔｉｏｎ（ＣｉＡ）、［平成２６年１１月１４日検索］、インターネット（ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｃａｎ−ｃｉａ．ｏｒｇ／ｆｉｌｅａｄｍｉｎ／ｃｉａ／ｓｐｅｃｉｆｉｃａｔｉｏｎｓ／ＣＡＮ２０Ａ．ｐｄｆ） 大塚敏史、石郷岡 祐、「既存ＥＣＵを変更不要な車載ＬＡＮ向け侵入検知手法」、研究報告組込みシステム（ＥＭＢ）、情報処理学会、２０１３年３月６日、２０１３−ＥＭＢ−２８巻、６号、１−５頁

ところで、ＣＡＮのバスに接続しているＥＣＵのうち、外部ネットワーク、外部装置等から取得したアプリケーションプログラムを実行するＥＣＵがあれば、不正なアプリケーションプログラムにより不正な動作が行われる可能性がある。不正なアプリケーションプログラムは、不正なフレームを生成してバスに送出することで、車両を不正にコントロールする可能性があり、また、バスの負荷を上昇させ得る。そして、バス上のフレーム監視（チェック）負担の増加を招く。

そこで、本発明は、不正なフレームのバスへの送出を低減させるために有用な車載ネットワークシステムを提供する。また、本発明は、その車載ネットワークシステムで用いられるＥＣＵとしての車両用通信装置、及び、不正なフレームのバスへの送出を低減させるために有用な車両用通信方法を提供する。

上記課題を解決するために本発明の一態様に係る電子制御ユニット（ＥＣＵ）は、車載ネットワークを介してフレームに係る通信を行う複数の装置を備える車載ネットワークシステムに接続された電子制御ユニットであって、前記電子制御ユニットは、少なくとも第１制御ユニットと第２制御ユニットとを有し、前記第１制御ユニットは、有線通信又は無線通信により前記第２制御ユニットを介して前記車載ネットワークに接続され、前記第２制御ユニットは、前記車載ネットワークから受信する受信フレームについて、第１ルールへの適合性に係る第１の判定を行い、前記第１制御ユニットは、前記第２制御ユニットを介して受信した前記受信フレームについて、前記第１ルールとは異なる第２ルールへの適合性に係る第２の判定を行い、前記電子制御ユニットは、前記第１の判定の結果及び前記第２の判定の結果を示す情報を、所定記録媒体に記録し、前記第２制御ユニットは、前記第１ルールに適合していると判定した場合には前記受信フレームを前記第１制御ユニットへ送信し、前記第１ルールに不適合であると判定した場合には前記受信フレームを前記第１制御ユニットへ送信しない電子制御ユニットである。

また、上記課題を解決するために本発明の一態様に係る車載ネットワークシステムは、車載ネットワークを介してフレームに係る通信を行う複数の装置を備える車載ネットワークシステムであって、前記複数の装置のうち少なくとも１つは前記車載ネットワークに接続された電子制御ユニットであり、前記電子制御ユニットは、少なくとも第１制御ユニットと第２制御ユニットとを有し、前記第１制御ユニットは、有線通信又は無線通信により前記第２制御ユニットを介して前記車載ネットワークに接続され、前記第２制御ユニットは、前記車載ネットワークから受信する受信フレームについて、第１ルールへの適合性に係る第１の判定を行い、前記第１制御ユニットは、前記第２制御ユニットを介して受信した前記受信フレームについて、前記第１ルールとは異なる第２ルールへの適合性に係る第２の判定を行い、前記電子制御ユニットは、前記第１の判定の結果及び前記第２の判定の結果を示す情報を、所定記録媒体に記録し、前記第２制御ユニットは、前記第１ルールに適合していると判定した場合には前記受信フレームを前記第１制御ユニットへ送信し、前記第１ルールに不適合であると判定した場合には前記受信フレームを前記第１制御ユニットへ送信しない車載ネットワークシステムである。

また、上記課題を解決するために本発明の一態様に係る車両用通信方法は、第１制御ユニットと、前記第１制御ユニットとの間で、有線通信又は無線通信により、フレームに係る情報を授受し得る第２制御ユニットとを有する電子制御ユニットを含む複数の装置が車載ネットワークを介してフレームに係る通信を行うところの車載ネットワークシステムにおいて用いられる車両用通信方法であって、前記第２制御ユニットが、前記車載ネットワークから受信する受信フレームについて、第１ルールへの適合性に係る第１の判定を行い、前記第１制御ユニットが、前記第２制御ユニットを介して受信した前記受信フレームについて、前記第１ルールとは異なる第２ルールへの適合性に係る第２の判定を行い、前記電子制御ユニットが、前記第１の判定の結果及び前記第２の判定の結果を示す情報を、所定記録媒体に記録し、前記第２制御ユニットが、前記第１ルールに適合していると判定した場合には前記受信フレームを前記第１制御ユニットへ送信し、前記第１ルールに不適合であると判定した場合には前記受信フレームを前記第１制御ユニットへ送信しない車両用通信方法である。

本発明によれば、不正なフレームのバスへの送出を低減させることが実現可能となる。

図１は、実施の形態１に係る車載ネットワークシステムの全体構成を示す図である。 図２は、ＣＡＮプロトコルで規定されるデータフレームのフォーマットを示す図である。 図３は、ＣＡＮプロトコルで規定されるエラーフレームのフォーマットを示す図である。 図４は、実施の形態１に係るヘッドユニットの構成図である。 図５は、ヘッドユニットが保持する受信ＩＤリストの一例を示す図である。 図６は、判定ルール保持部が保持する判定ルールの一例を示す図である。 図７は、ＥＣＵの構成図である。 図８は、ＥＣＵの保持する受信ＩＤリストの一例を示す図である。 図９は、エンジンに接続されたＥＣＵから送信されるフレームにおけるＩＤ及びデータフィールドの一例を示す図である。 図１０は、ブレーキに接続されたＥＣＵから送信されるフレームにおけるＩＤ及びデータフィールドの一例を示す図である。 図１１は、ドア開閉センサに接続されたＥＣＵから送信されるフレームにおけるＩＤ及びデータフィールドの一例を示す図である。 図１２は、窓開閉センサに接続されたＥＣＵから送信されるフレームにおけるＩＤ及びデータフィールドの一例を示す図である。 図１３は、実施の形態１に係るヘッドユニットにおけるフレーム受信処理の一例を示すフローチャートである。 図１４は、実施の形態１に係るヘッドユニットにおけるフレーム送信処理の一例を示すフローチャートである。 図１５は、実施の形態１に係るシステム制御ユニットにおけるフレーム判定処理の一例を示すフローチャートである。 図１６は、実施の形態１に係るマルチメディア制御ユニットにおけるフレーム判定処理の一例を示すフローチャートである。 図１７は、実施の形態１に係るフレーム周期判定処理の一例を示すフローチャートである。 図１８は、フレーム頻度判定処理の一例を示すフローチャートである。 図１９は、実施の形態１の変形例１に係るフレーム周期判定処理を示すフローチャートである。 図２０は、実施の形態１の変形例２に係るシステム制御ユニットにおけるフレーム判定処理を示すフローチャートである。 図２１は、実施の形態１の変形例２に係るマルチメディア制御ユニットにおけるフレーム判定処理を示すフローチャートである。 図２２は、実施の形態１の変形例３に係るシステム制御ユニットにおけるフレーム判定処理を示すフローチャートである。 図２３は、実施の形態１の変形例３に係るマルチメディア制御ユニットにおけるフレーム判定処理を示すフローチャートである。 図２４は、実施の形態２に係るヘッドユニットの構成図である。 図２５は、実施の形態２に係るヘッドユニットにおけるフレーム受信処理の一例を示すフローチャートである。 図２６は、実施の形態２に係るヘッドユニットにおけるフレーム送信処理の一例を示すフローチャートである。 図２７は、実施の形態３に係るネットワークシステムの全体構成を示す図である。 図２８は、実施の形態３に係るヘッドユニットの構成図である。 図２９は、実施の形態３に係るヘッドユニットにおけるフレーム受信処理の一例を示すフローチャートである。 図３０は、実施の形態３に係るヘッドユニットにおけるフレーム送信処理の一例を示すフローチャートである。

本発明の一態様に係る車両用通信装置は、バスを介してフレームに係る通信を行う複数の装置を備える車載ネットワークシステムにおける当該バスに接続された車両用通信装置であって、前記バスへの送出用のフレームである送信フレームを特定する第１制御ユニットと、前記第１制御ユニットとの間で、有線通信又は無線通信により、フレームに係る情報を授受し得る第２制御ユニットとを備え、前記第１制御ユニット及び前記第２制御ユニットのうち少なくとも１つが、前記送信フレームについて、ルールへの適合性に係る判定を行う車両用通信装置である。これにより、第１制御ユニットで例えばアプリケーションプログラム等により特定された内容のフレームが、車載ネットワークシステムにおけるルール（例えばデータ値の許容範囲、送信周期、送信頻度等に関する基準等）に照らして不正（不適合）か否か等が判定され得る。そして、この判定は、不正なフレームのバスへの送出の低減のために有用である。

また、更に、前記第１制御ユニット及び前記第２制御ユニットのうち少なくとも１つが、前記車載ネットワークシステムにおける前記複数の装置のうち自装置以外のいずれかの装置により送信され、前記バスを介して取得したフレームである受信フレームについて、ルールへの適合性に係る判定を行うこととしても良い。これにより、バスから受信したフレームが車載ネットワークシステムにおけるルール（例えばデータ値の許容範囲、受信周期、受信頻度等に関する基準等）に照らして不正（不適合）か否か等が判定され得る。この判定は、車載ネットワークシステムのセキュリティ向上に有用である。また、この判定の結果は、不正なフレームの受信に起因して不正なフレームのバスへの送出がなされたか否かの分析に利用可能となり、不正なフレームのバスへの送出の低減のためにも有用となり得る。

また、前記第１制御ユニットは、前記送信フレームについて第１所定ルールに適合しているか不適合であるかを判定する第１判定部を有し、前記第２制御ユニットは、前記受信フレームについて第２所定ルールに適合しているか不適合であるかを判定する第２判定部を有することとしても良い。これにより、フレームの判定をそれぞれの制御ユニットに分担させることができる。なお、第１制御ユニットにおいて必ずしも送信フレームに関するあらゆる基準（ルール項目）についての判定を行う必要はなく、第２制御ユニットにおいて必ずしも受信フレームに関するあらゆる基準（ルール項目）についての判定を行う必要はない。

また、前記第１制御ユニットは、特定した前記送信フレームに係る情報を前記第２制御ユニットに送信する機能を有し、前記第２制御ユニットは、前記第１制御ユニットから特定された前記送信フレームに係る情報を受信した場合に、当該送信フレームを前記バスへと送出する機能と、前記受信フレームに係る情報を、前記第１制御ユニットに送信する機能とを有し、前記第１制御ユニットは、前記送信フレームについて前記第１判定部により不適合であると判定された場合に当該送信フレームに係る情報の前記第２制御ユニットへの送信を抑止し、前記第２制御ユニットは、前記受信フレームについて前記第２判定部により不適合であると判定された場合に当該受信フレームに係る情報の前記第１制御ユニットへの送信を抑止することとしても良い。これにより、一方の制御ユニットでルールへ不適合であると判定されたフレームについて、他方の制御ユニットで何らかの処理をすることが抑止され、各制御ユニットの処理負担が軽減され得る。

また、前記第２所定ルールは、受信フレームについての受信周期又は受信頻度に関する条件を規定し、前記第１制御ユニットは、前記受信フレームについて、前記第２所定ルールとは異なる第３所定ルールに適合しているか不適合であるかを判定する第３判定部を有することとしても良い。これにより、第２制御ユニットとバスとの間の第１制御ユニットで、両制御ユニット間での信号伝達の時間（遅延）の影響を受けずに、周期又は頻度に関する判定を精度良く行うことができる。

また、前記第１制御ユニットは、前記受信フレームについて、前記第２所定ルールとは異なる第３所定ルールに適合しているか不適合であるかを判定する第３判定部を有することとしても良い。これにより、受信フレームについてのルール判定を各制御ユニットに分担するため、例えば第１制御ユニットが第２制御ユニットより高性能である場合において適切な処理負荷の分散が実現され得る。

また、前記第１制御ユニットは、第１マイクロプロセッサ及び第１メモリを含む半導体集積回路であり、当該第１メモリに格納されたプログラムを当該第１マイクロプロセッサで実行することにより前記第１判定部及び前記第３判定部としての機能を実現し、前記第２制御ユニットは、前記第１マイクロプロセッサより処理性能が低い第２マイクロプロセッサ及び第２メモリを含む半導体集積回路であり、当該第２メモリに格納されたプログラムを当該第２マイクロプロセッサで実行することにより前記第２判定部としての機能を実現することとしても良い。これにより、各マイクロプロセッサの処理性能に応じた適切な処理分担が実現され得る。

また、前記車両用通信装置は、前記受信フレームについてのルールへの適合性に係る前記判定として、当該受信フレームが当該ルールに適合しているか不適合であるかの判定を行い、適合していると判定した場合には、当該受信フレームの内容に基づく所定の受信フレーム対応処理を実行し、不適合であると判定した場合には、前記所定の受信フレーム対応処理の実行を抑止することとしても良い。これにより、ルールに適合しない不正な受信フレームによって受信フレーム対応処理がなされることが防止される。

また、前記車両用通信装置は、前記送信フレームについてのルールへの適合性に係る前記判定として、当該送信フレームが当該ルールに適合しているか不適合であるかの判定を行い、適合していると判定した場合には、当該送信フレームを前記バス上に送出し、不適合であると判定した場合には、当該送信フレームの前記バス上への送出を抑止することとしても良い。これにより、不正なフレームのバスへの送出が低減され得る。このため、バス上のフレーム監視負担が低減され得る。

また、前記車両用通信装置は、前記送信フレームについてのルールへの適合性に係る前記判定の結果を示す情報を、外部のサーバ装置に送信することとしても良い。これにより、サーバ装置でフレームのルールへの適合性を分析でき、その分析の結果を用いて車載ネットワークシステムのセキュリティ向上を図ることが可能になる。

また、前記車両用通信装置は、前記送信フレームについてのルールへの適合性に係る前記判定の結果を示す情報を、所定記録媒体に記録することとしても良い。これにより、記録媒体に記録された情報を分析でき、その分析の結果を用いて車載ネットワークシステムのセキュリティ向上を図ることが可能になる。

また、前記車両用通信装置を含む前記複数の装置は、ＣＡＮ（Controller Area Network）プロトコルに従って前記フレームに係る通信を行うこととしても良い。これにより、ＣＡＮプロトコルに従って通信する車載ネットワークシステムにおいて不正なフレームのバスへの送出の低減を図ることが可能になる。

また、本発明の一態様に係る車載ネットワークシステムは、バスを介してフレームに係る通信を行う複数の装置を備える車載ネットワークシステムであって、前記複数の装置のうち少なくとも１つは前記バスに接続された車両用通信装置であり、前記車両用通信装置は、前記バスへの送出用のフレームである送信フレームを特定する第１制御ユニットと、前記第１制御ユニットとの間で、有線通信又は無線通信により、フレームに係る情報を授受し得る第２制御ユニットとを備え、前記第１制御ユニット及び前記第２制御ユニットのうち少なくとも１つが、前記送信フレームについて、ルールへの適合性に係る判定を行う車載ネットワークシステムである。これにより、不正なフレームのバスへの送出の低減が可能となる。

また、本発明の一態様に係る車両用通信方法は、バスへの送出用のフレームである送信フレームを特定する第１制御ユニットと、前記第１制御ユニットとの間で、有線通信又は無線通信により、フレームに係る情報を授受し得る第２制御ユニットとを有する車両用通信装置を含む複数の装置が前記バスを介してフレームに係る通信を行うところの車載ネットワークシステムにおいて用いられる車両用通信方法であって、前記第１制御ユニット及び前記第２制御ユニットのうち少なくとも１つが、前記送信フレームについて、ルールへの適合性に係る判定を行う車両用通信方法である。この車両用通信方法における判定は、不正なフレームのバスへの送出の低減に有用である。

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

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

（実施の形態１）
以下、本発明の実施の形態として、バスに送出する送信フレーム等を含むフレームについてルールへの適合性を判定する車両用通信方法を行う車両用通信装置（ヘッドユニット１００）を含む車載ネットワークシステム１０について図面を用いて説明する。

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

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

ヘッドユニット１００は、ＥＣＵ４００ａ〜４００ｄから送信されるフレームを受信し、各種状態をディスプレイ（図示しない）に表示して、ユーザに提示する機能を持つ。また、ヘッドユニット１００が取得する各情報を示すフレームを生成して、そのフレームを、バス２００を介して１台以上のＥＣＵに送信する機能を持つ。また、送受信するフレームについてルールへの適合性を判定することで、不正なフレーム（つまりルールに適合しないフレーム）か否かの判別等を行い、必要に応じてフレームのフィルタリングを行う機能を有する。また、ヘッドユニット１００は、例えばカーナビゲーション、音楽再生、動画再生、ウェブページ表示、スマートフォンとの連携、アプリケーションプログラムのダウンロード及び実行等の機能を有し得る。なお、ヘッドユニット１００も一種のＥＣＵである。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図４は、ヘッドユニット１００の構成図である。ヘッドユニット１００は、マルチメディア制御ユニット１５０（第１制御ユニット）とシステム制御ユニット１１０（第２制御ユニット）とを含んで構成される。

システム制御ユニット１１０及びマルチメディア制御ユニット１５０のそれぞれは、例えばパッケージ化された半導体集積回路であるチップ（マイクロチップ）等であり、これらは、有線又は無線で相互に通信可能となるように構成される。なお、無線での通信は、電磁波により信号を伝送することでなされ、光通信を含む。

システム制御ユニット１１０は、主に他の車載装置（ＥＣＵ４００ａ〜４００ｄ）との連携に係る制御、つまりバス２００での通信の制御を担う。システム制御ユニット１１０は、フレーム送受信部１１１と、受信フレーム解釈部１１２と、受信ＩＤ判断部１１３と、受信ＩＤリスト保持部１１４と、フレーム判定部１１５と、判定ルール保持部１１６と、ユニット間通信処理部１１７と、送信フレーム生成部１１８とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、チップに集積された通信回路、メモリ及びこのメモリに格納された制御プログラムを実行するプロセッサ（マイクロプロセッサ）その他の回路等により実現される。

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

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

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

受信ＩＤリスト保持部１１４は、ヘッドユニット１００が受信するＩＤ（メッセージＩＤ）のリストである受信ＩＤリストを保持する。図５に、受信ＩＤリストの一例を示す。

フレーム判定部１１５は、受信フレーム解釈部１１２から受信したフレームの値、或いは、ユニット間通信処理部１１７より送信すべきフレームの内容となる値を受け取る。そして、判定ルール保持部１１６から判定ルールを取得し、判定ルールに基づいたフレーム判定処理（システム制御ユニットフレーム判定処理）の結果に応じて、送信フレーム生成部１１８、或いは、ユニット間通信処理部１１７へフレームの値を通知するか否かを決定する。このフレーム判定処理（システム制御ユニットフレーム判定処理）は、フレームについて判定ルールへの適合性の判定（例えばフレームが不正であるか否か等の判定）を行うための処理であり、後に図１５を用いて詳しく説明する。

判定ルール保持部１１６は、ヘッドユニット１００が送信或いは受信するフレームについて、フレーム判定処理を行うために用いる判定ルールを保持する。この判定ルールは、車載ネットワークシステム１０においてバス上で授受されるフレームが準拠すべきルールである。図６に、判定ルールの一例を示す。

ユニット間通信処理部１１７は、異なるユニット間の通信処理を行う。即ち、ユニット間通信処理部１１７は、マルチメディア制御ユニット１５０との間で、有線又は無線の通信（送信又は受信）により情報の授受を行う。

送信フレーム生成部１１８は、受信フレーム解釈部１１２からのエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部１１１へ通知して送信させる。また、送信フレーム生成部１１８は、フレーム判定部１１５から通知を受けたＩＤ、データ等を用いて、送信するデータフレームを生成する。

また、マルチメディア制御ユニット１５０は、主に、ヘッドユニット１００で各種機能（例えばカーナビゲーション、音楽再生、動画再生、ウェブページ表示、スマートフォンとの連携等の機能）を実現するためのアプリケーションプログラムの実行制御処理を担う。マルチメディア制御ユニット１５０は、ユニット間通信処理部１５１と、フレーム判定部１５２と、判定ルール保持部１５３と、アプリケーション実行部１５４とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、チップに集積された通信回路、メモリ及びこのメモリに格納された制御プログラムを実行するプロセッサその他の回路等により実現される。

ユニット間通信処理部１５１は、異なるユニット間の通信処理を行う。即ち、ユニット間通信処理部１５１は、システム制御ユニット１１０との間で、有線又は無線の通信（送信又は受信）により情報の授受を行う。

フレーム判定部１５２は、アプリケーション実行部１５４から送信すべきフレームの内容となる値、或いは、ユニット間通信処理部１５１から受信されたフレームの値を受け取る。そして、判定ルール保持部１５３から判定ルールを取得し、判定ルールに基づいたフレーム判定処理（マルチメディア制御ユニットフレーム判定処理）の結果に応じて、アプリケーション実行部１５４、或いは、ユニット間通信処理部１５１へフレームの値を通知するか否かを決定する。このフレーム判定処理（マルチメディア制御ユニットフレーム判定処理）は、フレームについて判定ルールへの適合性の判定（例えばフレームが不正であるか否か等の判定）を行うための処理であり、後に図１６を用いて詳しく説明する。

判定ルール保持部１５３は、ヘッドユニット１００が送信或いは受信するフレームについて、フレーム判定処理を行うために用いる判定ルールを保持する。この判定ルールは、車載ネットワークシステム１０においてバス上で授受されるフレームが準拠すべきルールである。なお、マルチメディア制御ユニット１５０の判定ルール保持部１５３が保持する判定ルールと、システム制御ユニット１１０の判定ルール保持部１１６が保持する判定ルールとは、それぞれフレーム判定部１５２、フレーム判定部１１５における判定に必要な基準、条件等の情報を少なくとも含めば十分であり、両者が同一であっても互いに異なっていても良い。

アプリケーション実行部１５４は、ヘッドユニット１００の各種機能（例えばナビゲーション、動画再生、音楽再生、Ｗｅｂブラウジング等の機能）を実現するためのアプリケーションプログラムの実行制御を行う。例えば、入力手段を通じて受け付けた運転者（ユーザ）による操作に応じて、アプリケーションプログラムの実行制御がなされ、アプリケーションプログラムの実行によって例えば表示装置へユーザに提示すべき情報の表示等がなされ得る。アプリケーションプログラムは、例えば、バス２００以外の外部ネットワークを介してダウンロードされ、マルチメディア制御ユニット１５０のプロセッサ上で動作する所定のオペレーティングシステム（ＯＳ）等による実行環境上で、プロセッサにより実行されることで動作する。

［１．５ ヘッドユニット１００の受信ＩＤリスト例］
図５は、ヘッドユニット１００の受信ＩＤリスト保持部１１４において保持される受信ＩＤリストの一例を示す図である。同図に例示する受信ＩＤリストは、ＩＤ（メッセージＩＤ）の値が「１」、「２」、「３」及び「４」のいずれかであるメッセージＩＤを含むフレームを選択的に受信して処理するために用いられる。ヘッドユニット１００は、エンジン３１０に接続されたＥＣＵ４００ａからメッセージＩＤが「１」であるフレーム（メッセージ）を受信し、ブレーキ３２０に接続されたＥＣＵ４００ｂからメッセージＩＤが「２」であるフレームを受信し、ドア開閉センサ３３０に接続されたＥＣＵ４００ｃからメッセージＩＤが「３」であるフレームを受信し、窓開閉センサ３４０に接続されたＥＣＵ４００ｄからメッセージＩＤが「４」であるフレームを受信する。

［１．６ 判定ルール例］
図６は、ヘッドユニット１００の判定ルール保持部１１６及び判定ルール保持部１５３が保持する判定ルールの一例を示す図である。同図に例示する判定ルールは、ＩＤ（メッセージＩＤ）毎に、そのメッセージＩＤのメッセージ（フレーム）が準拠すべきルール（基準）を示す。この判定ルールは、メッセージＩＤ毎に、送受信種別、データ長、データ範囲、周期(ｍｓ)、マージン（ｍｓ）、イベント有無、及び、頻度閾値（回／ｓｅｃ）という項目を含んでいる。

図６の例では、送受信種別は、ヘッドユニット１００が、他のＥＣＵから送信されバス２００を介して取得したフレームである受信フレームを１の値で示し、ヘッドユニット１００からバス２００への送信用のフレームである送信フレームを０の値で示し、両者を区別している。

データ長は、フレーム（データフレーム）に含まれるデータフィールドの長さ（Ｂｙｔｅ数）についての基準を示す。

データ範囲は、データフィールドの１Ｂｙｔｅ〜８Ｂｙｔｅについて１Ｂｙｔｅ毎に、データが取り得る値の範囲についての基準を示す。データが取り得る値の範囲として、図６の記号「＊＊」は、どんな値でも取り得ることを示す。また、記号「，」で連結する値はいずれかの値を取り得ることを示し、「〜」で連結する値は、それぞれを上限、下限とする範囲内のいずれかの値を取り得ることを示す。

周期は、フレームが繰り返し送信又は受信される場合におけるその送信又は受信の周期についての基準を示し、図６では周期をミリ秒単位の値で表している。なお、周期として図６の記号「−」は、対応するメッセージＩＤのフレームとして、周期的に送信又は受信されるフレームが無いことを表している。

マージンは、周期の基準についての適合性の判定において許容される周期とのズレ量（誤差の許容範囲）を示し、図６ではマージンをミリ秒単位の値で表している。

イベント有無は、対応するメッセージＩＤのフレームとして、周期とは別に送信又は受信されるイベントフレームが有り得るか否かについての基準を示し、図６では、１の値でイベントフレームが有り得ることを示し、０の値でイベントフレームが無いことを示す。

頻度周期は、対応するメッセージＩＤのフレームとして送信又は受信されるイベントフレームが有り得る場合において、フレームの送信又は受信の頻度についての基準を示す。図６では頻度周期を１秒当たりの送信又は受信の回数で表している。

なお、図６の例は、判定ルールの一例にすぎず、判定ルールは、フレームの要件として定めた基準等であればいかなる内容でも良い。例えば、図６では、データ範囲のルール（基準）をＢｙｔｅ単位で表現しているが、必ずしもＢｙｔｅ単位で表現する必要はない。また、送信フレームについてのルール項目（基準）と受信フレームについてのルール項目（基準）とを、必ずしも一致させる必要はない。また判定ルールをテーブルとして表しても、数式、プログラム（命令列）等で表しても良い。

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

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

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

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

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

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

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

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

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

［１．８ ＥＣＵ４００ａ〜４００ｄの受信ＩＤリスト例］
図８は、ＥＣＵ４００ａ、ＥＣＵ４００ｂ、ＥＣＵ４００ｃ及びＥＣＵ４００ｄのそれぞれにおいて保持される受信ＩＤリストの一例を示す図である。同図に例示する受信ＩＤリストは、ＩＤ（メッセージＩＤ）の値が「１」、「２」、「３」、「４」、「５」、「６」及び「７」のいずれかであるメッセージＩＤを含むフレームを選択的に受信して処理するために用いられる。

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

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

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

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

［１．１３ ヘッドユニット１００によるフレーム受信の動作］
図１３は、ヘッドユニット１００におけるフレーム受信処理の一例を示すフローチャートである。以下、同図に即して、ヘッドユニット１００におけるデータフレームの受信時の動作を説明する。

ヘッドユニット１００は、システム制御ユニット１１０のフレーム送受信部１１１により、バス２００上に現れるフレームを受信する（ステップＳ１１００）。

フレーム送受信部１１１がフレームにおけるＩＤの部分を受信すると、受信フレーム解釈部１１２及び受信ＩＤ判断部１１３により、受信ＩＤリスト保持部１１４が保持する受信ＩＤリストを参照して、受信すべきＩＤを含むフレームか否かを判別することで、そのフレームを引き続き受信すべきかどうかを判定する（ステップＳ１２００）。受信したフレームが受信ＩＤリストに記載の無いＩＤを含む場合は、フレーム受信処理を終了する。

ステップＳ１２００において受信したフレームのＩＤが受信ＩＤリストに含まれている場合に、フレームを受信して、フレーム判定部１１５においてシステム制御ユニットフレーム判定処理を行う（ステップＳ１３００）。システム制御ユニットフレーム判定処理Ｓ１３００については後に図１５を用いて説明する。

システム制御ユニットフレーム判定処理の判定結果がＯＫ（正常）の場合（つまり受信フレームが判定ルールに適合していると判定された場合）には（ステップＳ１４００）、ユニット間の通信処理により、システム制御ユニット１１０はマルチメディア制御ユニット１５０にフレーム（受信フレーム）の内容を通知する（ステップＳ１５００）。なお、ステップＳ１４００においてシステム制御ユニットフレーム判定処理の判定結果がＯＫでない場合には、システム制御ユニット１１０は、フレームをマルチメディア制御ユニット１５０へ通知せず、フレーム受信処理を終える。

次にマルチメディア制御ユニット１５０では、受信フレームの通知を受けるとフレーム判定部１５２においてマルチメディア制御ユニットフレーム判定処理を行う（ステップＳ１６００）。マルチメディア制御ユニットフレーム判定処理Ｓ１６００については、後に図１６を用いて説明する。

マルチメディア制御ユニットフレーム判定処理において、判定結果がＯＫの場合（つまり受信フレームが判定ルールに適合していると判定された場合）には（ステップＳ１７００）、フレーム判定部１５２は、アプリケーション実行部１５４に受信フレームの内容を通知する。そして、アプリケーション実行部１５４は、ヘッドユニット１００における各種機能を実現するためのアプリケーションプログラムを実行して、受信フレームの内容に応じた処理を行う（ステップＳ１８００）。受信フレームの内容に応じた処理（受信フレーム対応処理）は、例えば受信したフレームのデータフィールドの内容に基づく演算、その演算結果に基づく制御信号の出力（例えば表示装置へ情報を表示させるための制御信号の出力）等である。なお、ステップＳ１７００においてマルチメディア制御ユニットフレーム判定処理の判定結果がＯＫでない場合には、マルチメディア制御ユニット１５０は、アプリケーションプログラムによる受信フレームの内容に応じた処理を行わない。

［１．１４ ヘッドユニット１００によるフレーム送信の動作］
図１４は、ヘッドユニット１００におけるフレーム送信処理の一例を示すフローチャートである。以下、同図に即して、ヘッドユニット１００におけるデータフレームの送信のための動作を説明する。ここで、アプリケーション実行部１５４により実行されるアプリケーションプログラムは、一定期間毎に或いは機能実現上の必要に応じて、送信されるべきフレーム（送信フレーム）の内容（例えばＩＤ及びデータフィールドの内容）を特定して送信指示を行う内容（命令列）を含むものとする。

アプリケーション実行部１５４により、アプリケーションプログラムが実行され、アプリケーションプログラムによりデータフレームの送信指示がなされる（ステップＳ２１００）。

送信フレームの内容を特定して送信指示がなされた場合に、アプリケーション実行部１５４から特定された送信フレームの内容の通知を受けてフレーム判定部１５２は、マルチメディア制御ユニットフレーム判定処理を行う（ステップＳ１６００）。この例では、フレーム送信処理において上述したフレーム受信処理（図１３）と同じマルチメディア制御ユニットフレーム判定処理Ｓ１６００を行うものとする。

マルチメディア制御ユニットフレーム判定処理において、判定結果がＯＫの場合（つまり送信フレームについて判定ルールに適合していると判定された場合）には（ステップＳ２２００）、ユニット間の通信処理により、マルチメディア制御ユニット１５０はシステム制御ユニット１１０にフレーム（送信フレーム）の内容を通知する（ステップＳ２３００）。なお、ステップＳ２２００においてマルチメディア制御ユニットフレーム判定処理の判定結果がＯＫでない場合には、マルチメディア制御ユニット１５０は、送信フレームの内容をシステム制御ユニット１１０へ通知せず、フレーム送信処理を終える。

次にシステム制御ユニット１１０では、送信フレームの内容の通知を受けるとフレーム判定部１１５においてシステム制御ユニットフレーム判定処理を行う（ステップＳ１３００）。この例では、フレーム送信処理において上述したフレーム受信処理（図１３）と同じシステム制御ユニットフレーム判定処理Ｓ１３００を行うものとする。

システム制御ユニットフレーム判定処理において、判定結果がＯＫの場合（つまり送信フレームについて判定ルールに適合していると判定された場合）には（ステップＳ２４００）、送信フレーム生成部１１８は、送信フレームの内容（マルチメディア制御ユニット１５０においてアプリケーションプログラムにより特定された内容）に基づいて送信フレーム（データフレーム）を生成する（ステップＳ２５００）。そして、送信フレーム生成部１１８により生成された送信フレームをフレーム送受信部１１１がバス２００上に送出することでデータフレームの送信を行う（ステップＳ２６００）。なお、ステップＳ２４００においてシステム制御ユニットフレーム判定処理の判定結果がＯＫでない場合には、システム制御ユニット１１０は、送信フレームのバス２００上への送出を行わない。即ち、送信フレームがルールに適合している場合には、送信フレームはヘッドユニット１００によりバス上に送出され、ルールに適合していない（不適合である）場合には、送信フレームのバス上への送出が抑止される。

［１．１５ システム制御ユニットフレーム判定処理］
図１５は、システム制御ユニット１１０におけるフレーム判定処理（システム制御ユニットフレーム判定処理）の一例を示すフローチャートである。以下、同図に即して、システム制御ユニット１１０のフレーム判定部１１５によるシステム制御ユニットフレーム判定処理Ｓ１３００について説明する。システム制御ユニットフレーム判定処理Ｓ１３００では、判定ルール保持部１１６が保持する判定ルール（図６参照）を参照して、フレームについて判定ルールへの適合性が判定され、判定ルールに適合していれば判定結果はＯＫ（正常）、適合していなければ判定結果はＮＧ（不正）となる。ここでは、判定ルールには、ヘッドユニット１００が送信又は受信する各フレームのＩＤが記載されているものとする。

フレーム判定部１１５は、判定対象が送信フレームか、受信フレームかを判別し（ステップＳ１３０１）、送信フレームの場合は、判定結果をＯＫとしてシステム制御ユニットフレーム判定処理を終え（ステップＳ１３０２）、受信フレームの場合には、ステップＳ１３０３へと進む。なお、フレーム判定部１１５は、受信フレーム解釈部１１２からデータ（受信フレーム）を通知された場合に、判定対象が受信フレームであると判別し、ユニット間通信処理部１１７からデータ（送信フレームの内容）を通知された場合に、判定対象が送信フレームであると判別する。

ステップＳ１３０３では、フレーム判定部１１５は、判定対象のフレームのＩＤと一致するＩＤが判定ルールに記載されているかを確認し（ステップＳ１３０３）、記載されていればそのＩＤに関する判定ルールの各項目を取得する（ステップＳ１３０４）。判定対象のフレームのＩＤと一致するＩＤが判定ルールに記載されていなければ、判定結果をＮＧとして（ステップＳ１３０６）、システム制御ユニットフレーム判定処理を終える。

フレーム判定部１１５は、ステップＳ１３０４で取得した判定ルールのデータ長及びデータ範囲という項目の基準に判定対象のフレームが適合しているか否かを判定する（ステップＳ１３０５）。判定対象のフレームが、データ長の基準及びデータ範囲の基準のいずれかに適合しなければ、フレーム判定部１１５は、判定結果をＮＧとして（ステップＳ１３０６）、システム制御ユニットフレーム判定処理を終える。

ステップＳ１３０５で、判定対象のフレームが、データ長の基準及びデータ範囲の基準の両方に適合していると判定した場合には、フレーム判定部１１５は、判定対象のフレームが周期的に送信又は受信されるフレームであるか否かを判別する（ステップＳ１３０７）。具体的には、判定ルールの周期の項目が、周期的に送信又は受信されるフレームが無いことを表しておらず、かつ、イベント有無の項目が、イベントフレームが無いことを表している場合に周期的に送信又は受信されるフレームであると判別され、その他の場合には周期的に送信又は受信されるフレームでないと判別される。フレーム判定部１１５は、周期的に送信又は受信されるフレームであると判別した場合に、フレーム周期判定処理を行い（ステップＳ１３３０）、周期的に送信又は受信されるフレームでないと判別した場合に、フレーム頻度判定処理を行う（ステップＳ１３５０）。フレーム周期判定処理Ｓ１３３０及びフレーム頻度判定処理Ｓ１３５０については後述する。

［１．１６ マルチメディア制御ユニットフレーム判定処理］
図１６は、マルチメディア制御ユニット１５０におけるフレーム判定処理（マルチメディア制御ユニットフレーム判定処理）の一例を示すフローチャートである。以下、同図に即して、マルチメディア制御ユニット１５０のフレーム判定部１５２によるマルチメディア制御ユニットフレーム判定処理Ｓ１６００について説明する。マルチメディア制御ユニットフレーム判定処理Ｓ１６００では、判定ルール保持部１５３が保持する判定ルール（図６参照）を参照して、フレームについて判定ルールへの適合性が判定され、判定ルールに適合していれば判定結果はＯＫ（正常）、適合していなければ判定結果はＮＧ（不正）となる。

フレーム判定部１５２は、判定対象が送信フレームか、受信フレームかを判別し（ステップＳ１６０１）、受信フレームの場合は、判定結果をＯＫとしてマルチメディア制御ユニットフレーム判定処理を終え（ステップＳ１６０２）、送信フレームの場合には、ステップＳ１３０３へと進む。なお、フレーム判定部１５２は、ユニット間通信処理部１５１からデータ（受信フレーム）を通知された場合に、判定対象が受信フレームであると判別し、アプリケーション実行部１５４からデータ（送信フレームの内容）を通知された場合に、判定対象が送信フレームであると判別する。

なお、マルチメディア制御ユニットフレーム判定処理Ｓ１６００におけるステップＳ１３０３、Ｓ１３０４、Ｓ１３０５、Ｓ１３０６、Ｓ１３０７、Ｓ１３３０及びＳ１３５０は上述したシステム制御ユニットフレーム判定処理Ｓ１３００（図１５）と同一内容であり、ここでは説明を省略する。

［１．１７ フレーム周期判定処理］
図１７は、フレーム周期判定処理Ｓ１３３０の一例を示すフローチャートである。フレーム判定部（つまりフレーム判定部１１５或いはフレーム判定部１５２）は、フレーム周期判定処理Ｓ１３３０を実行する。フレーム周期判定処理Ｓ１３３０は、判定対象のフレームが周期性に関連する基準に適合するか否か、つまり正しい周期で送信又は受信されているか否かを判定するための処理である。

フレーム周期判定処理Ｓ１３３０として、フレーム判定部は、まず現在時刻を取得する（ステップＳ１３３１）。例えば、フレーム判定部１１５はシステム制御ユニット１１０内の計時機構（タイマ等）を用いて現在時刻を取得し、フレーム判定部１５２はマルチメディア制御ユニット１５０内の計時機構（タイマ等）を用いて現在時刻を取得する。或いは各フレーム判定部は、ヘッドユニット１００におけるシステム制御ユニット１１０及びマルチメディア制御ユニット１５０とは別の回路である計時機構（タイマ等）から現在時刻を取得しても良い。

次にフレーム判定部は、取得した現在時刻と、保存しておいた基準時刻との差分を計算する（ステップＳ１３３２）。なお、フレーム周期判定処理Ｓ１３３０の初回の実行時においては、基準時刻を保存していないので、例えば、例外的に判定結果をＯＫとして、現在時刻を基準時刻として保存する。

ステップＳ１３３２に続いて、フレーム判定部は、現在時刻と基準時刻との差分（差分時刻と称する）が、周期±マージンの範囲内であるか否かを判別する（ステップＳ１３３３）。この判別には、判定ルール（図６参照）において、フレーム判定部の判定対象となるフレームのＩＤに対応した周期及びマージンが用いられる。

ステップＳ１３３３において、差分時刻が周期±マージンの範囲内であると判別した場合には、フレーム判定部は、判定結果をＯＫ（正常）とし（ステップＳ１３３４）、ステップＳ１３３１で取得した現在時刻を用いて基準時刻を更新し（ステップＳ１３３７）、フレーム周期判定処理Ｓ１３３０を終える。

ステップＳ１３３３において、差分時刻が周期±マージンの範囲内でないと判別した場合には、フレーム判定部は、判定結果をＮＧ（不正）とし（ステップＳ１３３５）、差分時刻が周期＋マージンより大きいか否かを判別する（ステップＳ１３３６）。このステップＳ１３３６で、差分時刻が周期＋マージンより大きくないと判別した場合には、フレーム判定部は、フレーム周期判定処理Ｓ１３３０を終える。また、差分時刻が周期＋マージンより大きいと判別した場合には、フレーム判定部は、ステップＳ１３３１で取得した現在時刻を用いて基準時刻を更新し（ステップＳ１３３７）、フレーム周期判定処理Ｓ１３３０を終える。

［１．１８ フレーム頻度判定処理］
図１８は、フレーム頻度判定処理Ｓ１３５０の一例を示すフローチャートである。フレーム判定部（つまりフレーム判定部１１５或いはフレーム判定部１５２）は、フレーム頻度判定処理Ｓ１３５０を実行する。フレーム頻度判定処理Ｓ１３５０は、判定対象のフレームが頻度に関連する基準に適合するか否か、つまり正しい頻度（頻度閾値未満の頻度）で送信又は受信されているか否かを判定するための処理である。

フレーム頻度判定処理Ｓ１３５０として、フレーム判定部は、まず頻度確認タイマーが設定時間（ここでは１秒とする）を超えたか否かを判別する（ステップＳ１３５１）。例えば、フレーム判定部１１５はシステム制御ユニット１１０内の計時機構（タイマ等）を用いて頻度確認タイマーとして機能させ、フレーム判定部１５２はマルチメディア制御ユニット１５０内の計時機構（タイマ等）を用いて頻度確認タイマーとして機能させる。或いは各フレーム判定部は、ヘッドユニット１００におけるシステム制御ユニット１１０及びマルチメディア制御ユニット１５０とは別の回路である計時機構（タイマ等）を用いて頻度確認タイマーの機能を実現しても良い。

次にフレーム判定部は、頻度確認タイマーが設定時間を超えた場合には、頻度確認タイマーをクリア（リセット）し、頻度を計数するための変数としての頻度カウンタをクリアする（ステップＳ１３５２）。

フレーム判定部は、ステップＳ１３５１で頻度確認タイマーが設定時間を超えていない場合、及び、ステップＳ１３５２で頻度確認タイマーをリセットした場合には、頻度カウンタをインクリメント（１増加）する（ステップＳ１３５３）。そして、フレーム判定部は、判定ルール（図６参照）において、フレーム判定部の判定対象となるフレームのＩＤに対応した頻度閾値より、頻度カウンタが小さいか否かを判別する（ステップＳ１３５４）。

ステップＳ１３５４において、頻度カウンタが頻度閾値より小さいと判別した場合には、フレーム判定部は、判定結果をＯＫ（正常）とし（ステップＳ１３５５）、フレーム頻度判定処理Ｓ１３５０を終える。

ステップＳ１３５４において、頻度カウンタが頻度閾値より小さいと判別した場合には、フレーム判定部は、判定結果をＮＧ（不正）とし（ステップＳ１３５６）、フレーム頻度判定処理Ｓ１３５０を終える。

［１．１９ 実施の形態１の効果］
実施の形態１に係る車載ネットワークシステム１０では、送受信するフレームの頻度や周期等といった複数のルール項目（基準）を用いて、定められたルールに適合するフレームか否かを判定して不適合の場合にその後の処理をフィルタリング（抑止）する。このため、不正なアプリケーションプログラムによるバス２００への不正なフレームの送出が低減される。また、主にバス２００を用いた通信を担当するチップであるシステム制御ユニット１１０と、主にアプリケーションプログラムの実行制御等を担当するチップであるマルチメディア制御ユニット１５０とのそれぞれのフレーム判定部により送信フレームと受信フレームとの判定を分担して、フレームがルールに適合するか否かを判定している。これにより、ルールに適合しないフレームをチップ間で伝送しないため、処理負荷が軽減される。

［１．２０ 実施の形態１の変形例１］
以下、上述したフレーム周期判定処理Ｓ１３３０（図１７参照）を一部変形したフレーム周期判定処理Ｓ３３３０について説明する。

図１９は、フレーム周期判定処理Ｓ３３３０のフローチャートを示す。フレーム判定部（つまりフレーム判定部１１５或いはフレーム判定部１５２）は、上述したフレーム周期判定処理Ｓ１３３０の代わりにフレーム周期判定処理Ｓ３３３０を実行する。

なお、フレーム周期判定処理Ｓ３３３０におけるステップＳ１３３１〜Ｓ１３３６は上述したフレーム周期判定処理Ｓ１３３０（図１７）と同一内容であり、ここでは適宜説明を省略する。

ステップＳ１３３３において、差分時刻が周期±マージンの範囲内であると判別した場合には、フレーム判定部は、判定結果をＯＫ（正常）とし（ステップＳ１３３４）、判定対象のフレームを受信した時刻を最新受信時刻として保存する（ステップＳ３３３１）。

ステップＳ１３３５又はステップＳ３３３１の後に、フレーム判定部は、差分時刻が周期＋マージンより大きいか否かを判別する（ステップＳ１３３６）。このステップＳ１３３６で、差分時刻が周期＋マージンより大きくないと判別した場合には、フレーム判定部は、フレーム周期判定処理Ｓ３３３０を終える。また、差分時刻が周期＋マージンより大きいと判別した場合には、フレーム判定部は、ステップＳ３３３１で保存した最新受信時刻を用いて基準時刻を更新する（ステップＳ３３３２）。なお、ステップＳ３３３２では、判定結果がＯＫとなる時刻の範囲において複数のフレームを受信した場合における最新（最後）の受信時刻を用いて基準時刻を更新するが、この代わりに、例えば、判定結果がＯＫとなる時刻の範囲において複数のフレームを受信した場合における最初の受信時刻を用いて基準時刻を更新しても良い。また、その複数のフレームの受信時刻のうち、更新前の基準時刻に周期を加えた時刻に最も近い受信時刻を用いて基準時刻を更新しても良い。

ステップＳ３３３２に続いて、フレーム判定部は、基準時刻＋周期を最新受信時刻として保存し（ステップＳ３３３３）、フレーム周期判定処理Ｓ３３３０を終える。なお、ステップＳ３３３３で、基準時刻＋周期の代わりに、基準時刻＋周期−マージン〜基準時刻＋周期＋マージンの範囲内のいずれかの時刻を、最新受信時刻として保存することとしても良い。

実施の形態１の変形例１によれば、基準時刻＋周期±マージンの範囲内の全てのフレームの判定結果をＯＫとするので、ルールに適合したフレームを不正と誤判定してしまうことを抑制し得る。

［１．２１ 実施の形態１の変形例２］
上述したシステム制御ユニット１１０のフレーム判定部１１５とマルチメディア制御ユニット１５０のフレーム判定部１５２とにおけるフレーム判定処理（判定ルールへの適合性の判定）の分担（図１５、図１６参照）を、変更しても良い。実施の形態１の変形例２として、図２０及び図２１に、別の分担の例を示す。

図２０は、システム制御ユニットフレーム判定処理Ｓ１３００の変形例としてのシステム制御ユニットフレーム判定処理Ｓ４３００を示すフローチャートである。なお、システム制御ユニットフレーム判定処理Ｓ４３００におけるステップＳ１３０１〜Ｓ１３０６は上述したシステム制御ユニットフレーム判定処理Ｓ１３００（図１５）と同一内容であり、ここでは説明を省略する。

ステップＳ１３０５で、判定対象のフレームが、データ長の基準及びデータ範囲の基準の両方に適合していると判定した場合には、フレーム判定部１１５は、判定結果をＯＫ（正常）とし（ステップＳ４３０１）、システム制御ユニットフレーム判定処理を終える。

システム制御ユニットフレーム判定処理Ｓ４３００では、システム制御ユニットフレーム判定処理Ｓ１３００（図１５）におけるフレーム周期判定処理Ｓ１３３０及びフレーム頻度判定処理Ｓ１３５０を含んでいない。

図２１は、マルチメディア制御ユニットフレーム判定処理Ｓ１６００の変形例としてのマルチメディア制御ユニットフレーム判定処理Ｓ４６００を示すフローチャートである。なお、マルチメディア制御ユニットフレーム判定処理Ｓ４６００におけるステップＳ１３０３〜Ｓ１３０７、Ｓ１６０１、Ｓ１６０２、Ｓ１３３０及びＳ１３５０は上述したマルチメディア制御ユニットフレーム判定処理Ｓ１６００（図１６）と同一内容であり、ここでは適宜説明を省略する。

フレーム判定部１５２は、判定対象のフレームのＩＤと一致するＩＤが判定ルール（図６参照）に記載されているかを確認し（ステップＳ１３０３）、記載されていればそのＩＤに関する判定ルールの各項目を取得する（ステップＳ１３０４）。判定対象のフレームのＩＤと一致するＩＤが判定ルールに記載されていなければ、判定結果をＮＧとして（ステップＳ１３０６）、マルチメディア制御ユニットフレーム判定処理を終える。

フレーム判定部１５２は、判定対象が送信フレームか、受信フレームかを判別し（ステップＳ１６０１）、送信フレームの場合は、ステップＳ１３０４で取得した判定ルールのデータ長及びデータ範囲という項目の基準に判定対象のフレームが適合しているか否かを判定する（ステップＳ１３０５）。なお、フレーム判定部１５２は、ユニット間通信処理部１５１からデータ（受信フレーム）を通知された場合に、判定対象が受信フレームであると判別し、アプリケーション実行部１５４からデータ（送信フレームの内容）を通知された場合に、判定対象が送信フレームであると判別する。ステップＳ１３０５において、判定対象のフレームがデータ長の基準及びデータ範囲の基準のいずれかに適合しなければ、フレーム判定部１５２は、判定結果をＮＧとして（ステップＳ１３０６）、マルチメディア制御ユニットフレーム判定処理を終える。

ステップＳ１３０５で判定対象のフレームがデータ長の基準及びデータ範囲の基準の両方に適合していると判定した場合、又は、ステップＳ１６０１で受信フレームと判別された場合には、フレーム判定部１５２は、判定対象のフレームが周期的に送信又は受信されるフレームであるか否かを判別する（ステップＳ１３０７）。フレーム判定部１５２は、周期的に送信又は受信されるフレームであると判別した場合に、フレーム周期判定処理を行い（ステップＳ１３３０）、周期的に送信又は受信されるフレームでないと判別した場合に、フレーム頻度判定処理を行う（ステップＳ１３５０）。

このように、実施の形態１の変形例２では、マルチメディア制御ユニットフレーム判定処理Ｓ４６００において、送信フレームのみならず受信フレームも対象として、フレーム周期判定処理Ｓ１３３０及びフレーム頻度判定処理Ｓ１３５０のいずれかが実行される。即ち、実施の形態１と比較すると変形例２では、受信フレームについての一部の処理（フレーム周期判定処理Ｓ１３３０、フレーム頻度判定処理Ｓ１３５０等）の分担がシステム制御ユニット１１０からマルチメディア制御ユニット１５０へと移っている。この変形例２は、例えばマルチメディア制御ユニットがシステム制御ユニットよりも高性能な場合等において効果的である。このように、各制御ユニットの処理能力に応じて、フレームのルールへの適合性の判定処理の負荷分散を行うことが有用である。

［１．２２ 実施の形態１の変形例３］
以下、更に別の例として、システム制御ユニット１１０のフレーム判定部１１５とマルチメディア制御ユニット１５０のフレーム判定部１５２とにおけるフレーム判定処理（判定ルールへの適合性の判定）の分担（図１５、図１６参照）を変更した変形例３を示す。

図２２は、システム制御ユニットフレーム判定処理Ｓ１３００の別の変形例としてのシステム制御ユニットフレーム判定処理Ｓ５３００を示すフローチャートである。なお、システム制御ユニットフレーム判定処理Ｓ５３００におけるステップＳ１３０１〜Ｓ１３０４、Ｓ１３０６、Ｓ１３０７、Ｓ１３３０及びＳ１３５０は、上述したシステム制御ユニットフレーム判定処理Ｓ１３００（図１５）と同一内容であり、ここでは説明を適宜省略する。

ステップＳ１３０４の後に、フレーム判定部１１５は、判定対象のフレームが周期的に送信又は受信されるフレームであるか否かを判別する（ステップＳ１３０７）。

システム制御ユニットフレーム判定処理Ｓ５３００では、システム制御ユニットフレーム判定処理Ｓ１３００（図１５）における、判定ルールのデータ長及びデータ範囲の基準に判定対象のフレームが適合しているか否かを判定するステップＳ１３０５を含んでいない。

図２３は、マルチメディア制御ユニットフレーム判定処理Ｓ１６００の別の変形例としてのマルチメディア制御ユニットフレーム判定処理Ｓ５６００を示すフローチャートである。なお、マルチメディア制御ユニットフレーム判定処理Ｓ５６００におけるステップＳ１３０３〜Ｓ１３０７、Ｓ１６０１、Ｓ１６０２、Ｓ１３３０及びＳ１３５０は上述したマルチメディア制御ユニットフレーム判定処理Ｓ１６００（図１６）と同一内容であり、ここでは適宜説明を省略する。

フレーム判定部１５２は、判定対象のフレームのＩＤと一致するＩＤが判定ルール（図６参照）に記載されているかを確認し（ステップＳ１３０３）、記載されていればそのＩＤに関する判定ルールの各項目を取得する（ステップＳ１３０４）。判定対象のフレームのＩＤと一致するＩＤが判定ルールに記載されていなければ、判定結果をＮＧとして（ステップＳ１３０６）、マルチメディア制御ユニットフレーム判定処理を終える。

ステップＳ１３０４に続いて、フレーム判定部１５２は、判定ルールのデータ長及びデータ範囲という項目の基準に判定対象のフレームが適合しているか否かを判定する（ステップＳ１３０５）。ステップＳ１３０５において、判定対象のフレームがデータ長の基準及びデータ範囲の基準のいずれかに適合しなければ、フレーム判定部１５２は、判定結果をＮＧとして（ステップＳ１３０６）、マルチメディア制御ユニットフレーム判定処理を終える。

ステップＳ１３０５で判定対象のフレームがデータ長の基準及びデータ範囲の基準の両方に適合していると判定した場合には、フレーム判定部１５２は、判定対象が送信フレームか、受信フレームかを判別する（ステップＳ１６０１）。送信フレームでなく受信フレームの場合は、フレーム判定部１５２は判定結果をＯＫとしてマルチメディア制御ユニットフレーム判定処理を終え（ステップＳ１６０２）、送信フレームの場合には、ステップＳ１３０７へと進む。

このように、実施の形態１の変形例３では、マルチメディア制御ユニットフレーム判定処理Ｓ５６００において、送信フレームのみならず受信フレームも対象として、判定ルールのデータ長及びデータ範囲の基準に判定対象のフレームが適合しているか否かを判定するステップＳ１３０５が実行される。即ち、実施の形態１と比較すると変形例３では、受信フレームについての一部の処理（ステップＳ１３０５）の分担がシステム制御ユニット１１０からマルチメディア制御ユニット１５０へと移っている。この変形例３は、例えばマルチメディア制御ユニットがシステム制御ユニットよりも高性能な場合等において効果的である。また、システム制御ユニット１１０及びマルチメディア制御ユニット１５０のうち、バス２００からの受信フレームを先に処理するシステム制御ユニット１１０で受信フレームの周期又は頻度に係るルール項目（基準）への適合性の判定を行う。このため、両ユニット間での伝達による遅延等の影響を受けることなく、精度良くその判定が行える。このように、各制御ユニットのバス２００との位置関係及び処理能力に応じて、フレームのルールへの適合性の判定処理の負荷分散を適切に行うことが有用である。

この変形例３では、例えば、ヘッドユニット１００のマルチメディア制御ユニット１５０（第１制御ユニット）であるチップにおいてメモリに格納されたプログラムをプロセッサで実行することにより、送信フレームについて第１所定ルール（例えばデータ長、データ範囲等、或いは、周期、頻度等）に適合しているか不適合であるかを判定する第１判定部としての機能を実現している。送信フレームについては、第１判定部により不適合であると判定された場合に、その送信フレームに係る情報の第１制御ユニットからシステム制御ユニット１１０（第２制御ユニット）への送信は抑止される。また、ヘッドユニット１００のシステム制御ユニット１１０（第２制御ユニット）であるチップにおいてメモリに格納されたプログラムをプロセッサで実行することにより、受信フレームについて第２所定ルール（例えば周期、頻度等）に適合しているか不適合であるかを判定する第２判定部としての機能を実現している。また、マルチメディア制御ユニット１５０であるチップにおいてメモリに格納されたプログラムをプロセッサで実行することにより、受信フレームについて第３所定ルール（例えばデータ長、データ範囲等）に適合しているか不適合であるかを判定する第３判定部としての機能を実現している。なお、第１判定部及び第３判定部は、フレーム判定部１５２の構成要素であり、第２判定部は、フレーム判定部１１５の構成要素である。

（実施の形態２）
以下、本発明の実施の形態として、バスに送出する送信フレーム等を含むフレームについてルールへの適合性を判定して、その判定結果をログとして保存する車両用通信方法を行う車両用通信装置（ヘッドユニット２１００）を含む車載ネットワークシステムについて図面を用いて説明する。本実施の形態に係る車載ネットワークシステムは、実施の形態１で示した車載ネットワークシステム１０のヘッドユニット１００をヘッドユニット２１００に置き換えたものである。

［２．１ ヘッドユニット２１００の構成］
ヘッドユニット２１００は、ヘッドユニット１００と同様に車両用通信装置であり、例えば、自動車のインパネ等に設けられ、運転者に視認されるための情報を表示する表示装置、運転者の操作を受け付ける入力手段等を備える一種のＥＣＵである。

図２４は、ヘッドユニット２１００の構成図である。同図に示すようにヘッドユニット２１００は、システム制御ユニット２１１０と、マルチメディア制御ユニット２１５０とを含んで構成される。なお、実施の形態１で示した構成要素と同一のものには同じ符号を付しており、これらについては説明を省略する。

システム制御ユニット２１１０は、実施の形態１で示したシステム制御ユニット１１０を一部変形したものであり、マルチメディア制御ユニット２１５０は、実施の形態１で示したマルチメディア制御ユニット１５０を一部変形したものである。

システム制御ユニット２１１０は、主にバス２００での通信の制御を担い、フレーム送受信部１１１と、受信フレーム解釈部１１２と、受信ＩＤ判断部１１３と、受信ＩＤリスト保持部１１４と、フレーム判定部２１１５と、判定ルール保持部１１６と、ユニット間通信処理部１１７と、送信フレーム生成部１１８と、判定結果保持部２１１９とを含んで構成される。

フレーム判定部２１１５は、受信フレーム解釈部１１２から受信したフレームの値、或いは、ユニット間通信処理部１１７より送信すべきフレームの内容となる値を受け取る。そして、判定ルール保持部１１６から判定ルールを取得し、判定ルールに基づいたフレーム判定処理（システム制御ユニットフレーム判定処理）の結果に関する情報を判定結果保持部２１１９に通知する。システム制御ユニットフレーム判定処理の内容は実施の形態１で示したものと同じである（図１５参照）。また、フレーム判定部２１１５は、システム制御ユニットフレーム判定処理の結果に拘らず、送信フレーム生成部１１８、或いは、ユニット間通信処理部１１７へフレームの値を通知する。

判定結果保持部２１１９は、メモリ等の記憶媒体を含んで実現され、フレーム判定部２１１５からフレーム判定処理の結果に関する情報を通知され、その情報をログとして記憶媒体に保存する。フレーム判定処理の結果に関する情報は、判定対象のフレームの内容と判定結果とを含む情報である。

また、マルチメディア制御ユニット２１５０は、主にアプリケーションプログラムの実行制御処理を担い、ユニット間通信処理部１５１と、フレーム判定部２１５２と、判定ルール保持部１５３と、アプリケーション実行部１５４と、判定結果保持部２１５５を含んで構成される。

フレーム判定部２１５２は、アプリケーション実行部１５４から送信すべきフレームの内容となる値、或いは、ユニット間通信処理部１５１から受信されたフレームの値を受け取る。そして、判定ルール保持部１５３から判定ルールを取得し、判定ルールに基づいたフレーム判定処理（マルチメディア制御ユニットフレーム判定処理）の結果に関する情報を判定結果保持部２１５５に通知する。マルチメディア制御ユニットフレーム判定処理の内容は実施の形態１で示したものと同じである（図１６参照）。また、フレーム判定部２１５２は、マルチメディア制御ユニットフレーム判定処理の結果に拘らず、アプリケーション実行部１５４、或いは、ユニット間通信処理部１５１へフレームの値を通知する。

判定結果保持部２１５５は、メモリ等の記憶媒体を含んで実現され、フレーム判定部２１５２からフレーム判定処理の結果に関する情報（判定対象のフレームの内容と判定結果とを含む情報）を通知され、その情報をログとして記憶媒体に保存する。

［２．２ ヘッドユニット２１００によるフレーム受信の動作］
図２５は、ヘッドユニット２１００におけるフレーム受信処理の一例を示すフローチャートである。同図に示すように、ヘッドユニット２１００におけるフレーム受信処理は、ヘッドユニット１００におけるフレーム受信処理（図１３参照）のステップＳ１１００、Ｓ１２００、Ｓ１３００、Ｓ１５００、Ｓ１６００及びＳ１８００と同一の処理を含む。この同一の処理については説明を適宜省略する。

システム制御ユニットフレーム判定処理Ｓ１３００に続いて、ヘッドユニット２１００のシステム制御ユニット２１１０におけるフレーム判定部２１１５は、判定結果保持部２１１９に判定結果に関する情報（判定対象のフレームに内容と判定結果とを含む情報）を通知してログとして保存させる（ステップＳ１１００１）。続いて、ユニット間の通信処理により、システム制御ユニット２１１０はマルチメディア制御ユニット２１５０にフレーム（受信フレーム）の内容を通知する（ステップＳ１５００）。

また、マルチメディア制御ユニットフレーム判定処理Ｓ１６００に続いて、ヘッドユニット２１００のマルチメディア制御ユニット２１５０におけるフレーム判定部２１５２は、判定結果保持部２１５５に判定結果に関する情報（判定対象のフレームの内容と判定結果とを含む情報）を通知してログとして保存させる（ステップＳ１１００２）。続いて、フレーム判定部２１５２は、アプリケーション実行部１５４に受信フレームの内容を通知する。

［２．３ ヘッドユニット２１００によるフレーム送信の動作］
図２６は、ヘッドユニット２１００におけるフレーム送信処理の一例を示すフローチャートである。同図に示すように、ヘッドユニット２１００におけるフレーム送信処理は、ヘッドユニット１００におけるフレーム送信処理（図１４参照）のステップＳ２１００、Ｓ１６００、Ｓ２３００、Ｓ１３００、Ｓ２５００及びＳ２６００と同一の処理を含む。この同一の処理については説明を適宜省略する。

マルチメディア制御ユニットフレーム判定処理Ｓ１６００に続いて、ヘッドユニット２１００のマルチメディア制御ユニット２１５０におけるフレーム判定部２１５２は、判定結果保持部２１５５に判定結果に関する情報（判定対象のフレームの内容と判定結果とを含む情報）をログとして保存させる（ステップＳ１１００３）。続いて、ユニット間の通信処理により、マルチメディア制御ユニット２１５０はシステム制御ユニット２１１０にフレーム（送信フレーム）の内容を通知する（ステップＳ２３００）。

また、システム制御ユニットフレーム判定処理Ｓ１３００に続いて、ヘッドユニット２１００のシステム制御ユニット２１１０におけるフレーム判定部２１１５は、判定結果保持部２１１９に判定結果に関する情報（判定結果のフレームの内容と判定結果とを含む情報）をログとして保存させる（ステップＳ１１００４）。続いて、送信フレーム生成部１１８は、送信フレームの内容（マルチメディア制御ユニット２１５０においてアプリケーションプログラムにより特定された内容）に基づいて送信フレーム（データフレーム）を生成する（ステップＳ２５００）。

［２．４ 実施の形態２の効果］
実施の形態２に係る車載ネットワークシステムのヘッドユニット２１００では、送受信するフレームについて、頻度や周期等、複数のルール項目（基準）への適合性を判定して、判定の結果をログとして保存しておく。この保存したログを収集し、分析することにより、例えば、判定ルールの各基準の見直しを行うことができ、フレーム判定の精度の向上等を図ることができる。なお、判定ルールの各基準の見直しの結果は、車載ネットワークシステムを構成する装置等の製造、或いは、その装置で使用されるデータ、プログラム等の更新等に活用され得る。

（実施の形態３）
以下、本発明の実施の形態として、バスに送出する送信フレーム等を含むフレームについてルールへの適合性を判定して、その判定結果を車両外部に所在するサーバ（コンピュータ）に通知（送信）する車両用通信方法を行う車両用通信装置（ヘッドユニット３１００）を含む車載ネットワークシステムについて図面を用いて説明する。本実施の形態に係る車載ネットワークシステム１０ａは、実施の形態１で示した車載ネットワークシステム１０のヘッドユニット１００をヘッドユニット３１００に置き換えたものである。

［３．１ ネットワークシステム３０の全体構成］
図２７は、本発明に係るネットワークシステム３０の全体構成を示す図である。ネットワークシステム３０は、車両に搭載された車載ネットワークシステム１０ａと、車両外部に所在するサーバ３５００とを含んで構成される。

車載ネットワークシステム１０ａは、車載ネットワークシステム１０を一部変形したものであり、バス２００と、ヘッドユニット３１００、各種機器に接続されたＥＣＵ４００ａ〜４００ｄ等のＥＣＵといったバスに接続された各ノードとを含んで構成される。車載ネットワークシステム１０ａの構成要素のうち車載ネットワークシステム１０（図１参照）の構成要素と同一のものには同じ符号を付しており、これらについては説明を省略する。車載ネットワークシステム１０ａにおいてはＣＡＮプロトコルに従って、ヘッドユニット３１００を含む各ＥＣＵがフレームの授受を行う。

ヘッドユニット３１００は、ヘッドユニット１００と同様に車両用通信装置であり、例えば、自動車のインパネ等に設けられ、運転者に視認されるための情報を表示する表示装置、運転者の操作を受け付ける入力手段等を備える一種のＥＣＵである。ヘッドユニット３１００は、ＥＣＵ４００ａ〜４００ｄから送信されるフレームを受信し、各種状態をディスプレイ（図示しない）に表示して、ユーザに提示する機能を持つ。また、ヘッドユニット３１００が取得する各情報を示すフレームを生成して、そのフレームを、バス２００を介して１台以上のＥＣＵに送信する機能を持つ。また、送受信するフレームについてルールへの適合性を判定することで、不正なフレーム（つまりルールに適合しないフレーム）か否かの判別等を行い、その判定結果に関する情報をサーバ３５００に通知（送信）する機能を有する。なお、ヘッドユニット３１００も一種のＥＣＵである。

サーバ３５００は、ヘッドユニット３１００と通信可能な装置（サーバ装置）であり、フレームの判定結果に関する情報をヘッドユニット３１００から受信して、収集する機能を有するコンピュータである。

［３．２ ヘッドユニット３１００の構成］
図２８は、ヘッドユニット３１００の構成図である。ヘッドユニット３１００は、システム制御ユニット３１１０と、マルチメディア制御ユニット３１５０と、外部通信制御ユニット３１７０とを含んで構成される。なお、実施の形態１で示した構成要素と同一のものには同じ符号を付しており、これらについては説明を省略する。

システム制御ユニット３１１０は、実施の形態１で示したシステム制御ユニット１１０を一部変形したものであり、マルチメディア制御ユニット３１５０は、実施の形態１で示したマルチメディア制御ユニット１５０を一部変形したものである。

システム制御ユニット３１１０は、主にバス２００での通信の制御を担い、フレーム送受信部１１１と、受信フレーム解釈部１１２と、受信ＩＤ判断部１１３と、受信ＩＤリスト保持部１１４と、フレーム判定部３１１５と、判定ルール保持部１１６と、ユニット間通信処理部１１７と、送信フレーム生成部１１８とを含んで構成される。

フレーム判定部３１１５は、受信フレーム解釈部１１２から受信したフレームの値、或いは、ユニット間通信処理部１１７より送信すべきフレームの内容となる値を受け取る。そして、判定ルール保持部１１６から判定ルールを取得し、判定ルールに基づいたフレーム判定処理（システム制御ユニットフレーム判定処理）の結果に関する情報をユニット間通信処理部１１７に通知して外部通信制御ユニット３１７０へと通知させる。システム制御ユニットフレーム判定処理の内容は実施の形態１で示したものと同じである（図１５参照）。また、フレーム判定部３１１５は、システム制御ユニットフレーム判定処理の結果に拘らず、送信フレーム生成部１１８、或いは、ユニット間通信処理部１１７へフレームの値を通知する。

また、マルチメディア制御ユニット３１５０は、主にアプリケーションプログラムの実行制御処理を担い、ユニット間通信処理部１５１と、フレーム判定部３１５２と、判定ルール保持部１５３と、アプリケーション実行部１５４とを含んで構成される。

フレーム判定部３１５２は、アプリケーション実行部１５４から送信すべきフレームの内容となる値、或いは、ユニット間通信処理部１５１から受信されたフレームの値を受け取る。そして、判定ルール保持部１５３から判定ルールを取得し、判定ルールに基づいたフレーム判定処理（マルチメディア制御ユニットフレーム判定処理）の結果に関する情報をユニット間通信処理部１５１に通知して外部通信制御ユニット３１７０へと通知させる。マルチメディア制御ユニットフレーム判定処理の内容は実施の形態１で示したものと同じである（図１６参照）。また、フレーム判定部３１５２は、マルチメディア制御ユニットフレーム判定処理の結果に拘らず、アプリケーション実行部１５４、或いは、ユニット間通信処理部１５１へフレームの値を通知する。

外部通信制御ユニット３１７０は、例えばシステム制御ユニット３１１０及びマルチメディア制御ユニット３１５０とは異なるチップであり、機能構成要素としてユニット間通信処理部３１７１と、外部通信処理部３１７２とを含んで構成される。これらの各機能構成要素は、チップに集積された通信回路、メモリ及びこのメモリに格納された制御プログラムを実行するプロセッサその他の回路等により実現される。

ユニット間通信処理部３１７１は、異なるユニット間の通信処理を行う。即ち、ユニット間通信処理部１１７は、システム制御ユニット３１１０或いはマルチメディア制御ユニット３１５０との間で、有線又は無線の通信により情報の授受を行う。

外部通信処理部３１７２は、車両外部のサーバ３５００と無線通信するための機能を有し、ユニット間通信処理部３１７１より、フレームの判定結果に関する情報を通知されるとサーバ３５００へ通知（送信）する。

［３．３ ヘッドユニット３１００によるフレーム受信の動作］
図２９は、ヘッドユニット３１００におけるフレーム受信処理の一例を示すフローチャートである。同図に示すように、ヘッドユニット３１００におけるフレーム受信処理は、ヘッドユニット１００におけるフレーム受信処理（図１３参照）のステップＳ１１００、Ｓ１２００、Ｓ１３００、Ｓ１５００、Ｓ１６００及びＳ１８００と同一の処理を含む。この同一の処理については説明を適宜省略する。

システム制御ユニットフレーム判定処理Ｓ１３００に続いて、ヘッドユニット３１００のシステム制御ユニット３１１０におけるフレーム判定部３１１５は、判定結果に関する情報（判定対象のフレームに内容と判定結果とを含む情報）を、ユニット間通信処理部１１７を介して外部通信制御ユニット３１７０へ通知する（ステップＳ２１００１）。これに対応して、外部通信制御ユニット３１７０は外部通信処理部３１７２により、判定結果に関する情報をサーバへ通知する（ステップＳ２１００２）。続いて、ユニット間の通信処理により、システム制御ユニット３１１０はマルチメディア制御ユニット３１５０にフレーム（受信フレーム）の内容を通知する（ステップＳ１５００）。

また、マルチメディア制御ユニットフレーム判定処理Ｓ１６００に続いて、ヘッドユニット３１００のマルチメディア制御ユニット３１５０におけるフレーム判定部３１５２は、判定結果に関する情報（判定対象のフレームの内容と判定結果とを含む情報）を、ユニット間通信処理部１５１を介して外部通信制御ユニット３１７０へ通知する（ステップＳ２１００３）。これに対応して、外部通信制御ユニット３１７０は外部通信処理部３１７２により、判定結果に関する情報をサーバへ通知する（ステップＳ２１００４）。続いて、フレーム判定部３１５２は、アプリケーション実行部１５４に受信フレームの内容を通知する。

［３．４ ヘッドユニット３１００によるフレーム送信の動作］
図３０は、ヘッドユニット３１００におけるフレーム送信処理の一例を示すフローチャートである。同図に示すように、ヘッドユニット３１００におけるフレーム送信処理は、ヘッドユニット１００におけるフレーム送信処理（図１４参照）のステップＳ２１００、Ｓ１６００、Ｓ２３００、Ｓ１３００、Ｓ２５００及びＳ２６００と同一の処理を含む。この同一の処理については説明を適宜省略する。

マルチメディア制御ユニットフレーム判定処理Ｓ１６００に続いて、ヘッドユニット３１００のマルチメディア制御ユニット３１５０におけるフレーム判定部３１５２は、判定結果に関する情報（判定対象のフレームの内容と判定結果とを含む情報）を、ユニット間通信処理部１５１を介して外部通信制御ユニット３１７０へと通知する（ステップＳ２１００３）。これに対応して、外部通信制御ユニット３１７０は外部通信処理部３１７２により、判定結果に関する情報をサーバへ通知する（ステップＳ２１００４）。続いて、ユニット間の通信処理により、マルチメディア制御ユニット３１５０はシステム制御ユニット３１１０にフレーム（送信フレーム）の内容を通知する（ステップＳ２３００）。

また、システム制御ユニットフレーム判定処理Ｓ１３００に続いて、ヘッドユニット３１００のシステム制御ユニット３１１０におけるフレーム判定部３１１５は、判定結果に関する情報（判定結果のフレームの内容と判定結果とを含む情報）を、ユニット間通信処理部１１７を介して外部通信制御ユニット３１７０へと通知する（ステップＳ２１００１）。これに対応して、外部通信制御ユニット３１７０は外部通信処理部３１７２により、判定結果に関する情報をサーバへ通知する（ステップＳ２１００２）。続いて、送信フレーム生成部１１８は、送信フレームの内容（マルチメディア制御ユニット３１５０においてアプリケーションプログラムにより特定された内容）に基づいて送信フレーム（データフレーム）を生成する（ステップＳ２５００）。

［３．５ 実施の形態３の効果］
実施の形態３に係る車載ネットワークシステム１０ａのヘッドユニット３１００は、送受信するフレームについて、頻度や周期等、複数のルール項目（基準）への適合性を判定して、判定の結果に関する情報をサーバ３５００に送信する。サーバ３５００が、この判定の結果に関する情報を収集して分析することにより、例えば、判定ルールの各基準の見直しを行うことができ、フレーム判定の精度の向上等を図ることができる。なお、判定ルールの各基準の見直しの結果は、車載ネットワークシステムを構成する装置等の製造、或いは、その装置で使用されるデータ、プログラム等の更新等に活用され得る。

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

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

（２）上記実施の形態では、フレーム周期判定処理で利用するマージンを１つに定めているが、複数持っても良い。また、各マージンを用いた判定結果を同一の扱いとしても良いし、各マージンを用いた判定結果に重み付けを行っても良い。また、マージン毎に判定結果後の処理を変更しても良い。例えば、第一のマージンの範囲に当てはまるフレームの判定結果はログを残すだけにし、第二のマージンの範囲に当てはまるフレームの判定結果はフィルタリングに用い、不正と判定した場合にフレームの送受信処理を抑止しても良い。また、判定ルールにおけるマージンの値は固定値に限定されず、計算式であっても良い。また、全てのＩＤのフレーム処理総数に応じて、マージンの値を動的に変更しても良い。

（３）上記実施の形態では、フレーム頻度判定処理で利用する閾値（頻度閾値）を１つに定めているが、複数持っても良い。また、各閾値を用いた判定結果を同一の扱いとしても良いし、各閾値を用いた判定結果に重み付けを行っても良い。また、閾値毎に判定結果後の処理を変更しても良い。例えば、第一の閾値を使ったフレームの判定結果はログを残すだけにし、第二の閾値に当てはまるフレームの判定結果はフィルタリングに用い、不正と判定した場合にフレームの送受信処理を抑止しても良い。また、判定ルールにおける頻度閾値は固定値に限定されず、計算式であっても良い。また、全てのＩＤのフレーム処理総数に応じて、頻度閾値を動的に変更しても良い。

（４）上記実施の形態では、フレームの周期についての基準への適合性の判定結果をＯＫ（正常）及びＮＧ（不正）の２種類としているが、複数種類としても良い。例えば、実施の形態１の変形例１のように、一定のマージン範囲内に複数のフレームの受信を許容するような場合において、複数受信である旨を判定結果に含めるようにしても良い。また、判定ルールの各項目（基準）への適合性について、一定の評価基準で適合度合い（例えば１００％適合、８０％適合等）を表して、その適合度合いを判定結果としても良い。

（５）上記実施の形態では、フレーム判定処理をシステム制御ユニットとマルチメディア制御ユニットとに分割して実施しているが、どちらか一方のみで行うようにしても良い。また、ヘッドユニット等のＥＣＵである車両用通信装置においては、送信フレームについてルールへの適合性の判定を行えば必ずしも受信フレームについてルールの適合性の判定を行わなくてもよい。また、上述の実施の形態では、受信フレームと送信フレームとの区別に基づいて、フレーム判定処理を実施するユニットを分離する例を示したが、ＩＤ毎、タイミング毎等の区別により分離しても良い。また、フレーム判定（フレームのルールへの適合性の判定）を行う部分を同一ユニット内の複数箇所に分離しても良い。例えば、アプリケーションプログラム毎に分離しても良く、また、同一チップ内において複数のオペレーティングシステム（ＯＳ）が稼働する場合においてはＯＳ毎に分離しても良い。また、フレーム判定を実行可能な箇所を複数設けておき、システム全体の処理負荷や、フレーム処理の頻度等に応じて動的に、フレーム判定を実際に行う箇所を選定することとしても良い。また、受信フレーム或いは送信フレームについてのルールへの適合性の判定を、マルチメディア制御ユニットとシステム制御ユニットとの間でどのように分担しても良い。つまり、ユニットそれぞれがどのルール項目（基準）の判定を分担しても良い。車載ネットワークシステムのバスに接続されたヘッドユニット等のＥＣＵである車両用通信装置は、バスへの送出用のフレームである送信フレームを特定するマルチメディア制御ユニット（第１制御ユニット）と、この第１制御ユニットと有線又は無線により通信してフレームに係る情報を授受し得るシステム制御ユニット（第２制御ユニット）とを備え、これら第１制御ユニット及び第２制御ユニットのうち少なくとも１つが、送信フレーム等について、ルールへの適合性に係る判定を行うものであれば良い。また、第１制御ユニットは、送信フレームについて第１所定ルール（例えば図６の判定ルールのいずれかの項目の基準）に適合しているか不適合であるかを判定する第１判定部を有し、第２制御ユニットは、受信フレームについて第２所定ルール（例えば図６の判定ルールのいずれかの項目の基準）に適合しているか不適合であるかを判定する第２判定部を有してもよい。

（６）上記実施の形態では、フレーム周期判定処理で利用する判定ルールにおける周期とマージンとを、ＩＤ毎に１つに定めているが、複数のＩＤをまとめたグループ単位毎に定めても良い。また、フレーム周期判定処理は１フレームの送信又は受信毎に１回ずつ行うようにしている。しかし、これに限定するものではなく、全てのＩＤにまたがったフレーム周期判定処理、グループ単位のフレーム周期判定処理等といった、判定内容の異なるフレーム周期判定処理を複数組み合わせて行うこととしても良い。

（７）上記実施の形態では、フレーム頻度判定処理で利用する判定ルールにおける閾値（頻度閾値）を、ＩＤ毎に１つに定めているが、複数のＩＤをまとめたグループ単位毎に定めても良い。また、フレーム頻度判定処理は１フレームの送信又は受信毎に１回ずつ行うようにしている。しかし、これに限定するものではなく、全てのＩＤにまたがったフレーム頻度判定処理、グループ単位のフレーム頻度判定処理等といった、判定内容の異なるフレーム頻度判定処理を複数組み合わせて行うこととしても良い。

（８）上記実施の形態２では、判定結果保持部を、各ユニット（システム制御ユニット及びマルチメディア制御ユニットのそれぞれ）が有している。しかし、この構成に限定するものではなく、どちらか一方だけが有しても良いし、どちらとも異なるヘッドユニット内の別の独立したユニット（チップ等）だけが有しても良い。また、判定結果保持部がログを保存する記憶媒体（記録媒体）は、判定結果保持部の内部のメモリ等の他、外部の回路、装置等で実現されたメモリ、ハードディスク等であっても良い。

（９）上記実施の形態２では、フレームの判定結果に応じて、判定結果をログに保存するかしないかを切り替えても良い。また、全てのＩＤの判定結果を保存しても良いし、特定のＩＤに対する判定結果のみを保存しても良い。また、ユニット毎に判定結果を保存するかしないかを切り替えても良い。

（１０）上記実施の形態３では、サーバとの通信のために外部通信制御ユニット３１７０を有している。しかし、この構成に限定するものではなく、システム制御ユニット３１１０及びマルチメディア制御ユニット３１５０のどちらか一方、或いは、両方に、サーバとの通信のための構成（集積回路等）を含ませても良い。また、システム制御ユニット３１１０から外部通信制御ユニット３１７０への、フレームの判定結果に関する情報の伝達は、直接ではなく、マルチメディア制御ユニット３１５０（ユニット間通信処理部１５１）を介して行われるようにしても良い。

（１１）上記実施の形態３では、フレームの判定結果に応じて、判定結果をサーバに通知するかしないかを切り替えても良い。また、全てのＩＤの判定結果をサーバに通知しても良いし、特定のＩＤに対する判定結果のみをサーバに通知しても良い。また、ユニット毎に判定結果をサーバに通知するかしないかを切り替えても良い。

（１２）上記実施の形態３では、ユニット毎に一回のフレーム判定処理を行う度に判定結果をサーバに通知しているが、ある一定数のフレーム判定処理の判定結果が溜まった時点で、まとめてサーバに通知しても良い。また、一定時間間隔で定期的にフレームの判定結果をサーバに通知しても良い。

（１３）上記実施の形態で示した判定ルール（図６参照）は一例であり、例示したルール項目以外の項目を含めても良いし、例示した値と異なる値にしても良い。また、判定ルールは、車両用通信装置（例えばヘッドユニット）の製造時、出荷時等に設定されても良いし、車載ネットワークシステムが搭載される車両の出荷時に設定されても良い。判定ルールは、車載ネットワークシステムの稼働中に更新されても良い。また、判定ルールは、外部との通信に基づいて設定及び更新されても、各種記録媒体等を用いて設定されても、ツール類等によって設定されても良い。

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

（１５）上記実施の形態における車両用通信装置の一例としてのヘッドユニットは、例えば、通信回路、メモリ、プロセッサその他の回路等を含む半導体集積回路のチップを含むこととしたが、ハードディスク装置、ディスプレイ、キーボード、マウス等の他のハードウェア構成要素を含んでいても良い。また、メモリに記憶された制御プログラムをプロセッサが実行することでソフトウェア的に機能を実現する代わりに、制御プログラムを用いない集積回路でその機能を実現することとしても良い。なお、チップは、必ずしもパッケージ化されている必要はない。

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

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

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

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

本発明は、車載ネットワークシステムにおいて不正なフレームのバスへの送出を低減させるために利用可能である。

１０，１０ａ 車載ネットワークシステム
３０ ネットワークシステム
１００，２１００，３１００ ヘッドユニット
１１０，２１１０，３１１０ システム制御ユニット（第２制御ユニット）
１１１，４１０ フレーム送受信部
１１２，４５０ 受信フレーム解釈部
１１３，４３０ 受信ＩＤ判断部
１１４，４４０ 受信ＩＤリスト保持部
１１５，１５２，２１１５，２１５２，３１１５，３１５２ フレーム判定部
１１６，１５３ 判定ルール保持部
１１７，１５１，３１７１ ユニット間通信処理部
１１８，４２０ 送信フレーム生成部
１５０，２１５０，３１５０ マルチメディア制御ユニット（第１制御ユニット）
１５４ アプリケーション実行部
２００ バス
３１０ エンジン
３２０ ブレーキ
３３０ ドア開閉センサ
３４０ 窓開閉センサ
４００ａ〜４００ｄ 電子制御ユニット（ＥＣＵ）
４１０ フレーム処理部
４７０ データ取得部
２１１９，２１５５ 判定結果保持部
３１７０ 外部通信制御ユニット
３１７２ 外部通信処理部
３５００ サーバ

Claims (6)

1. 車載ネットワークを介してフレームに係る通信を行う複数の装置を備える車載ネットワークシステムに接続された電子制御ユニットであって、
   前記電子制御ユニットは、少なくとも第１制御ユニットと第２制御ユニットとを有し、
   前記第１制御ユニットは、有線通信又は無線通信により前記第２制御ユニットを介して前記車載ネットワークに接続され、
   前記第２制御ユニットは、前記車載ネットワークから受信する受信フレームについて、第１ルールへの適合性に係る第１の判定を行い、
   前記第１制御ユニットは、前記第２制御ユニットを介して受信した前記受信フレームについて、前記第１ルールとは異なる第２ルールへの適合性に係る第２の判定を行い、
   前記電子制御ユニットは、前記第１の判定の結果及び前記第２の判定の結果を示す情報を、所定記録媒体に記録し、
   前記第２制御ユニットは、前記第１ルールに適合していると判定した場合には前記受信フレームを前記第１制御ユニットへ送信し、前記第１ルールに不適合であると判定した場合には前記受信フレームを前記第１制御ユニットへ送信しない
   電子制御ユニット。
2. 前記第１制御ユニットは、第１マイクロプロセッサ及び第１メモリを含む半導体集積回路であり、当該第１メモリに格納されたプログラムを当該第１マイクロプロセッサで実行することにより、前記第２の判定を実行し、
   前記第２制御ユニットは、前記第１マイクロプロセッサより処理性能が低い第２マイクロプロセッサ及び第２メモリを含む半導体集積回路であり、当該第２メモリに格納されたプログラムを当該第２マイクロプロセッサで実行することにより、前記第１の判定を実行する
   請求項１記載の電子制御ユニット。
3. 前記電子制御ユニットは、
   前記第１の判定の結果及び前記第２の判定の結果を示す情報を、外部のサーバ装置に送信する
   請求項１記載の電子制御ユニット。
4. 車載ネットワークを介してフレームに係る通信を行う複数の装置を備える車載ネットワークシステムに接続された電子制御ユニットであって、
   前記電子制御ユニットは、少なくとも第１制御ユニットと第２制御ユニットとを有し、
   前記第１制御ユニットは、有線通信又は無線通信により前記第２制御ユニットを介して前記車載ネットワークに接続され、
   前記第２制御ユニットは、前記車載ネットワークから受信する受信フレームについて、第１ルールへの適合性に係る第１の判定を行い、
   前記第１制御ユニットは、前記第２制御ユニットを介して受信した前記受信フレームについて、前記第１ルールとは異なる第２ルールへの適合性に係る第２の判定を行い、
   前記電子制御ユニットは、前記第１の判定の結果及び前記第２の判定の結果を示す情報を、所定記録媒体に記録し、
   前記第１制御ユニットは、アプリケーションプログラムの実行制御を行うマルチメディア制御ユニットであり、
   前記第２制御ユニットは、前記車載ネットワークでの通信の制御を行うシステム制御ユニットである
   電子制御ユニット。
5. 車載ネットワークを介してフレームに係る通信を行う複数の装置を備える車載ネットワークシステムであって、
   前記複数の装置のうち少なくとも１つは前記車載ネットワークに接続された電子制御ユニットであり、
   前記電子制御ユニットは、少なくとも第１制御ユニットと第２制御ユニットとを有し、
   前記第１制御ユニットは、有線通信又は無線通信により前記第２制御ユニットを介して前記車載ネットワークに接続され、
   前記第２制御ユニットは、前記車載ネットワークから受信する受信フレームについて、第１ルールへの適合性に係る第１の判定を行い、
   前記第１制御ユニットは、前記第２制御ユニットを介して受信した前記受信フレームについて、前記第１ルールとは異なる第２ルールへの適合性に係る第２の判定を行い、
   前記電子制御ユニットは、前記第１の判定の結果及び前記第２の判定の結果を示す情報を、所定記録媒体に記録し、
   前記第２制御ユニットは、前記第１ルールに適合していると判定した場合には前記受信フレームを前記第１制御ユニットへ送信し、前記第１ルールに不適合であると判定した場合には前記受信フレームを前記第１制御ユニットへ送信しない
   車載ネットワークシステム。
6. 第１制御ユニットと、前記第１制御ユニットとの間で、有線通信又は無線通信により、フレームに係る情報を授受し得る第２制御ユニットとを有する電子制御ユニットを含む複数の装置が車載ネットワークを介してフレームに係る通信を行うところの車載ネットワークシステムにおいて用いられる車両用通信方法であって、
   前記第２制御ユニットが、前記車載ネットワークから受信する受信フレームについて、第１ルールへの適合性に係る第１の判定を行い、
   前記第１制御ユニットが、前記第２制御ユニットを介して受信した前記受信フレームについて、前記第１ルールとは異なる第２ルールへの適合性に係る第２の判定を行い、
   前記電子制御ユニットが、前記第１の判定の結果及び前記第２の判定の結果を示す情報を、所定記録媒体に記録し、
   前記第２制御ユニットが、前記第１ルールに適合していると判定した場合には前記受信フレームを前記第１制御ユニットへ送信し、前記第１ルールに不適合であると判定した場合には前記受信フレームを前記第１制御ユニットへ送信しない
   車両用通信方法。

Images