JP2014138264A - 車両用通信装置、情報処理装置 - Google Patents

Abstract

【課題】メモリ容量を削減可能な車両用通信装置を提供すること。
【解決手段】車載ネットワーク２７を介してデータを受信する車両用通信装置１００であって、所定範囲のデータ識別番号を有するデータを受信する受信手段１３と、前記受信手段が受信したデータのデータ識別番号から予め定められた基準識別番号を減じることで番号差分を算出する差分算出手段１と、前記差分算出手段が算出した前記番号差分に対応づけられた、前記受信手段が受信したデータを記憶する記憶手段１１，１２と、前記記憶手段から読み出したデータの番号差分に前記基準識別番号を加えてデータ識別番号を復元し、データと共に、データを処理する処理手段に出力するデータ転送手段３と、を有することを特徴とする。
【選択図】図１

Description

本発明は、車載ネットワークを介してデータを受信する車両用通信装置に関する。

車載装置の電子制御化及び高機能化が進行しており、車両に搭載されるマイコンに要求される機能や性能もますます増大している。また、マイコンは例えばISO26262などの機能安全規格に適合することが望まれており、機能安全に対応するための機能をマイコンに搭載する必要が生じる。このため、車両の高機能化が進むと、高度な機能を機能安全規格に適合させるため、相乗的にマイコンの高機能化が必要になってしまう。具体的には、ＲＯＭ及びＲＡＭのサイズアップ・高速化などが必要になる。また、処理能力が高いＣＰＵが必要になる場合もある。

このようなマイコンの高機能化は車両の高コスト化を招くため、車両メーカなどとしては車両の高機能化や機能安全規格への対応を怠ることなく、マイコンのコスト低減を図っている。このため、限られた容量のＲＯＭに記憶できるようにプログラムや、限られた容量のＲＡＭで実行できるプログラムを開発している。

例えば、車載ネットワークでは、複数のマイコン（電子制御装置）間で通信することが従来から行われているが、高度な機能を実現するために、通信するデータ量や頻度が増大している。このような通信データは少なくとも処理のためにＲＡＭを圧迫するおそれがある。

従来から、扱うデータ量を低減する技術が考えられている（例えば、特許文献１参照。）。特許文献１には、データのメッセージＩＤの値を昇順に並べ、隣り合うＩＤの差分値を差分ＩＤとして、差分ＩＤと中継先バスの対応を関係テーブルに記憶するゲートウェイが開示されている。これにより、メモリに記憶するルーティングテーブルの記憶量を小さくすることが可能になる。

特開２００９−４９９４４号公報

しかしながら、特許文献１に記載された技術では、メッセージＩＤを昇順に並べたり差分ＩＤを求めるために、データをＲＡＭに記憶する必要があるためＲＡＭ容量を削減することが困難であるという問題がある。

本発明は、上記課題に鑑み、メモリ容量を削減可能な車両用通信装置を提供することを目的とする。

本発明は、車載ネットワークを介してデータを受信する車両用通信装置であって、所定範囲のデータ識別番号を有するデータを受信する受信手段と、前記受信手段が受信したデータのデータ識別番号から予め定められた基準識別番号を減じることで番号差分を算出する差分算出手段と、前記差分算出手段が算出した前記番号差分に対応づけられた、前記受信手段が受信したデータを記憶する記憶手段と、前記記憶手段から読み出したデータの番号差分に前記基準識別番号を加えてデータ識別番号を復元し、データと共に、データを処理する処理手段に出力するデータ転送手段と、を有することを特徴とする。

メモリ容量を削減可能な車両用通信装置を提供することができる。

マイコン同士が車載ネットワークを介して通信する際に、マイコンがデータを受信する動作とそのデータ保存方法を示す図の一例である。 本実施形態の通信方法が適用されうるマイコンの概略構成図の一例である。 通信プロトコルのメッセージフォーマットの一例を示す図である。 マイコンがメッセージを送受信する場合の基本的な処理手順を示すフローチャート図の一例である。 マスク値テーブルを模式的に説明する図の一例である。 バッファＢＯＸ番号と通信コンポーネントを対応づけるコンポ指定テーブルの一例を示す図である。 マイコンがメッセージを送信する動作とそのデータ保存方法を示す図の一例である。 通信コンポーネント１〜３が生成するメッセージＩＤを模式的に説明する図の一例である。 基準ＩＤの決定方法を説明する図の一例である。 マイコン同士が車載ネットワークを介して通信する際に、マイコンがデータを受信する動作とそのデータ保存方法を示す図の一例である（従来図）。

以下、本発明を実施するための形態について図面を参照しながら説明する。しかしながら、本発明の技術的範囲が、本実施の形態に限定されるものではない。

〔概略的な特徴〕
本願を説明するため、まず、図１０を参照して従来のＲＡＭの使用例について説明する。図１０はマイコン同士が車載ネットワークを介して通信する際に、マイコンがデータを受信する動作とそのデータ保存方法を示す図の一例である。

通信コントローラ１３には、メッセージボックス（以下、ＭＢＯＸという）毎にマイコンが受信すべきメッセージＩＤが設定されている。本実施形態では最小のメッセージＩＤをMIN_ADDR、最大のメッセージＩＤをMIN_ADDRとする。通信コントローラ１３の各ＭＢＯＸはMIN_ADDR〜MAN_ADDRの範囲内のメッセージＩＤのデータのみを受信する。ＭＢＯＸの数は、通信コントローラ１３によって異なるが、例えば最大で256個である。以下、ＭＢＯＸの番号をＭＢＯＸ[i]で表す。

通信コントローラ１３がＭＢＯＸにメッセージを受信すると、通信処理部１４はＭＢＯＸ[i]のメッセージを一次バッファ１２に記憶する。一次バッファ１２はＲＡＭに配置されている。一次バッファ１２には例えば最大256個のバッファＢＯＸが用意されている。バッファＢＯＸの番号をバッファＢＯＸ[i]で表す。

通信処理部１４は、機能ごとに分けて作成されており、以下では、通信処理部１〜３という場合がある。通信処理部１４は複数のマイコンに共通に搭載されるソフトウェアであり、そのうちの通信処理を行うソフトウェア（ミドルウェアやデバイスドライバなどと呼ばれる場合がある）である。同様に、受信されたメッセージを処理する通信コンポーネント１５も機能ごとに分けて作成されており、以下では、通信コンポーネント１〜３という場合がある。
各メッセージを処理する通信コンポーネント１５は予め決まっており、バッファＢＯＸ[i]と通信コンポーネント１〜３の対応も定められている。通信処理部１はメッセージのメッセージＩＤに基づき通信コンポーネント１〜３を特定し、通信コンポーネントに対応したバッファＢＯＸに記憶する。よって、ＭＢＯＸ[i]とバッファＢＯＸ[i]は同じとは限らず、複数のＭＢＯＸが１つのバッファＢＯＸと対応する場合がある。

バッファＢＯＸのメッセージは、二次バッファ１１に登録される。二次バッファ１１はＲＡＭに配置されている。二次バッファは先入れ先出し方式のＱｕｅ構造になっている。以下、単にＱｕｅという。通信処理部２は、バッファＢＯＸに格納された順番に、又は、バッファＢＯＸ（メッセージ）の優先度を考慮して、バッファＢＯＸのメッセージをＱｕｅに登録する。Ｑｕｅの段数は例えば１２８個である。

通信処理部２は、メッセージ（メッセージＩＤ、ＤＬＣ、ＤＡＴＡ）及びコンポ指定をＱｕｅ[i][j]に格納する。Ｑｕｅ[i][j]の[i]がバッファＢＯＸの番号であり、[j]がＱｕｅの番号である。コンポ指定は、通信コンポーネント１５を指定する情報であり、通信処理部２はバッファＢＯＸ番号に基づきコンポ指定を決定する。

通信処理部３は、Ｑｕｅに先に登録されたものからメッセージを読み出して、コンポ指定に基づき通信コンポーネント１〜３に分配する。通信コンポーネント１〜３は例えば診断用のプログラム、通信処理用のプログラム、ネットワーク上のＥＣＵの起動を管理するプログラムなどである。

このように、多くのバッファＢＯＸと多段のＱｕｅを有することで、受信漏れを低減できるので、通信の安全性／信頼性を向上させることができる。しかし、安全性を高めようとするとより冗長になるためＲＡＭのサイズも増大してしまう。そこで、本願では以下のようにメッセージＩＤの容量を低減することで通信の安全性／信頼性を維持したまま、ＲＡＭサイズの増大を抑制する。

図１は、マイコン同士が車載ネットワークを介して通信する際に、本実施形態のマイコン１００がデータを受信する動作とそのデータ保存方法を示す図の一例である。図１０と比較すると、バッファＢＯＸの数及びＱｕｅの段数は同じだが、バッファＢＯＸ及びＱｕｅのサイズが異なっている。

具体的には、バッファＢＯＸ及びＱｕｅはメッセージＩＤの代わりに、「ＭＢＯＸ番号」と「ＩＤ差分」を有する。ＭＢＯＸの数が全部で２５６だとすると、８bitあればビット数として足りることになる。ＩＤ差分は、例えばMIN_ADDRと各メッセージＩＤの差である。例えば、MIN_ADDRと同じメッセージＩＤのメッセージのＩＤ差分はゼロになる。また、MAX_ADDRと同じメッセージＩＤのメッセージのＩＤ差分は「MAX_ADDR−MIN_ADDR」になる。

したがって、ＩＤ差分として確保すべきビット数は「MAX_ADDR−MIN_ADDR」により決定される。例えば、１つのＭＢＯＸが１６種類のメッセージを受信し、各メッセージＩＤが１ずつ異なっている場合、「MAX_ADDR−MIN_ADDR＝１６」なので、ＩＤ差分に必要なビット数は４となる。したがって、一例として、バッファＢＯＸ及びＱｕｅのそれぞれで、「ＭＢＯＸ番号」と「ＩＤ差分」のために「８＋４＝１２」ビット確保すればよい。

メッセージＩＤのビット数は従来のＣＡＮ（Controller Area Network）通信では１１ビットであるが、図１０に示したように、メッセージＩＤのビット数を増やすことが考えられている。メッセージＩＤを増やすことで、ネットワーク上を流れるメッセージの種類を増やしたり、送受信の高度な制御が可能になる。例えば、メッセージＩＤが３２ビットに拡張された場合と比較すると、「３２−１２＝２０」ビットとなるので、本実施形態のマイコン１００はバッファＢＯＸ及びＱｕｅの１つのメッセージにつき１９ビットのデータ量を削減することが可能になる。バッファＢＯＸ及びＱｕｅはＲＡＭに配置されているので、メッセージＩＤを拡張してもＲＡＭのサイズが増大することを抑制できる。

〔構成例〕
図２は、本実施形態の通信方法が適用されうるマイコン１００の概略構成図の一例を示す。マイコン１００はシステムバスＢ１に接続された、ＣＰＵ２１、ＲＡＭ２２、ＲＯＭ２３、ＩＮＴＣ２４、ＷＤＴ２５、ＤＭＡＣ２６及び通信コントローラ１３を有している。この他、マイコン１００はタイマ、ＵＡＲＴなどの各種のＩ／Ｏ、電源回路、他のマイコンと通信するためのＣＡＮ（Controller Area Network）コントローラなどの通信装置など、マイコンに一般的な構成を有している。

マイコン１００は、ＥＣＵ（Electronic Control Unit）に搭載されることが想定されているがその用途は車両に限定されない。車載されるＥＣＵには、その主要な機能により、エンジンＥＣＵ、ブレーキＥＣＵ、ハイブリッドＥＣＵ、パワーマネージメントＥＣＵ、ボディＥＣＵ、ナビゲーションＥＣＵ（ＡＶ・情報処理ＥＣＵ）、ゲートウェイＥＣＵ等の種類がある。本実施例のマイコン１００はＥＣＵの機能の違いに影響されず搭載されることが可能である。また、複数の機能が１つに統合されたＥＣＵにマイコン１００を搭載してもよい。また、１つのＥＣＵが複数のマイコンを搭載していてもよい。

ＣＰＵ２１は、ＲＯＭ２３に記憶されたプログラムを実行することでマイコン全体を制御する。ＲＡＭ２２にはプログラムやデータが展開され、ＲＡＭ２２はＣＰＵ２１がアクセスする作業メモリになる。ＲＡＭ２２は後述する一次バッファや二次バッファが配置される。但し、一次バッファや二次バッファは不揮発メモリ又は揮発メモリのどちらに記憶されてもよい。また、ＲＯＭ２３にはプログラムの他、プラットホームが記憶されている。プラットホームは、例えばＯＳやデバイスドライバなどである。ＯＳとしては、ＯＳＥＫ（Open system together with interfaces for automotive electronics）、ＡＵＴＯＳＡＲ（AUTomotive Open System Architecture） ＯＳなどのリアルタイムＯＳがあるが、これらに限定されるものではない。

ＩＮＴＣ２４は割込みマスク・マスクの解除などの設定が可能なレジスタと割込み要求が設定されるレジスタなどを有し、レジスタを監視して、周辺機器からの割り込み要求を割込みの優先順位に基づき調停してＣＰＵ２１に通知する。これによりＣＰＵ２１は、例えばＩＳＲを実行して、割込みした周辺機器に応じて定められている処理を行う。本実施例では例外発生も割り込みの一態様として説明する。

ＷＤＴ２５は、動作クロックをカウントして計測した時間が予め定められたリセット時間に達すると（オーバーフローすると）、異常を検出する回路である。ＷＤＴ２５がオーバーフローすると、例えばマイコン１００がリセットされるなどのフェールセーフが行われる。ＤＭＡＣ２６は、ＲＡＭ２２と周辺回路の間やＲＡＭ２２内で、ＣＰＵ２１を介することなくデータを転送する。

通信コントローラ１３は、マイコン１００が通信バス２７に接続された他のＥＣＵと通信するための通信回路である。通信コントローラ１３はメッセージを受信するとＩＮＴＣ２４を介してＣＰＵ２１に通知する。これにより、通信処理部１４が受信処理を開始する。また、ＣＰＵ２１がメッセージを送信する際は、アプリケーションにより指定された通信コンポーネント１５がメッセージを作成し、通信処理部１４に送信を要求する。この後は、受信時と逆の手順で通信処理部１〜３が送信処理を行う。

なお、通信コントローラ１３のレジスタには、ＭＢＯＸ毎に受信すべきメッセージＩＤ（MIN_ADDR〜MAX_ADDR）が登録されている。通信コントローラ１３は通信バス２７を流れるメッセージのメッセージＩＤを監視し、それが登録されたメッセージＩＤの範囲である場合に対応するＭＢＯＸに受信する。

〔メッセージのフォーマット〕
図３（ａ）は、ＣＡＮ通信におけるメッセージのフォーマットの一例を示す図である。ＳＯＦはＣＡＮフレームの先頭を示す。メッセージＩＤ（ＣＡＮの場合はＣＡＮＩＤ）はデータを識別するための識別子であり、通信バス２７の使用権を調停する際にも使用される。ＲＩ，ＴＤｒ、ＲＥ０は制御用bitで固定値である。ＤＬＣはＤＡＴＡフレームが格納するデータの長さを示す。ＤＡＴＡには送信対象のデータが格納される。ＣＲＣはエラー検出用の巡回冗長符号である。ＣＲＣの次の１bitはＣＲＣデリミタと呼ばれ、区切り用のbitである。ＡＣＫスロットは、受信側のＥＣＵが正常受信を伝えるための１bitである。ＡＣＫデリミタは区切り用の１bitである。ＥＯＦは送信の完了を示す。

ＳＯＦ、ＲＩ，ＴＤｒ、ＲＥ０、ＣＲＣデリミタ、ＡＣＫスロット、ＡＣＫデリミタ、ＥＯＦは、通信コントローラ１３が通信制御に利用した後は不要なので、ＲＡＭ２２には格納されない。ＣＲＣについてはどの段階でエラー検出するかによるが、通信コントローラ１３がＭＢＯＸに受信した際に行えば、ＲＡＭ２２に格納する必要はない。このため、ＲＡＭ２２には、図１に示したメッセージＩＤ、ＤＬＣ、及び、ＤＡＴＡが１つのメッセージとして格納される。なお、ＣＲＣをメッセージの一部として格納してもよい。

図３（ｂ）はFlexRay通信におけるメッセージのフォーマットの一例を示す図である。Reserved bitは予備ビットである。Payload preamble indicatorは次述するペイロード・セグメント内に特定のデータが含まれるか否かを示す。Null frame indicatorは、ペイロード・セグメント内のデータフレームがNullか否かを示す。Sync frame indicatorは、メッセージが同期フレームか否かを示す。Startup frame indicatorはメッセージがスタートアップフレーム（起動したことを示す）かどうかを示す。Frame IDは、フレームＩＤを定義する。Lengthは、ペイロードセグメントのデータ長を示す。Header CRCはヘッダー部のCRC値が格納されている。サイクルカウンタはデータを転送しているノードのサイクル・カウンタを示す。ペイロード・セグメントには、最大で254 バイトのデータが格納される。トレイラ・セグメントは、ヘッダー全体とペイロードのCRC値が格納される。

ＣＡＮと同様に先頭の５bit、ヘッダーＣＲＣ、サイクルカウント、及び、トレーラセグメントは不要になるので、ＭＢＯＸにはFrame ID、Length及びペイロードセグメントが格納される。Frame IDがメッセージＩＤに対応する。

このように、本願は通信プロトコルが変化しても適用可能であり、これらの他、ＬＩＮ（Local Interconnect Network）やイーサネット（登録商標）等の通信プロトコルにおいても、本実施形態のメッセージＩＤの圧縮方法を適用できる。

〔処理の詳細〕
図４は、マイコン１００がメッセージを送受信する場合の基本的な処理手順を示すフローチャート図の一例である。図４の手順はメッセージの受信時と送信時に共通であるが、受信時から説明する。適宜、図１を参照されたい。

＜ＳＴＥＰ１ メッセージＩＤの変換＞
通信処理部１は、ＭＢＯＸに記憶されたメッセージのメッセージＩＤをＩＤ差分に変換する。
ＩＤ差分＝メッセージＩＤ−基準ＩＤ
基準ＩＤは、例えばMIN_ADDRである。マイコン１００の起動時、初期設定を行うプログラムが通信コントローラ１３のＭＢＯＸにメッセージＩＤの範囲を設定する。この範囲の最小のメッセージＩＤがMIN_ADDR、最大のメッセージＩＤがMAX_ADDRである。通信コントローラ１３の各ＭＢＯＸは、メッセージＩＤがMIN_ADDRからMAX_ADDRの範囲内のメッセージのみを受信する。このような受信方法をメッセージのマスク処理という。例えば、ＭＢＯＸ[0]のMIN_ADDRが１００ｈ、MAX_ADDRが１２０ｈの場合、ＭＢＯＸ[0]は１００ｈ〜１２０ｈのメッセージＩＤのメッセージのみを受信する。

そして、本実施例では基準ＩＤを例えばMIN_ADDRとする。通信処理部１は少なくともMIN_ADDRを予め保持しているか、初期設定を行うプログラムが参照するマスク値テーブルのMIN_ADDRを読み出す。

図５はマスク値テーブルのうちMIN_ADDRを模式的に説明する図の一例である。各ＭＢＯＸ毎にMIN_ADDRが登録されている。MIN_ADDR[0]はＭＢＯＸ[0]の基準ＩＤであり、以下、MIN_ADDR[1]〜MIN_ADDR[255]が各ＭＢＯＸの基準ＩＤである。通信処理部１はＭＢＯＸ番号に基づき基準ＩＤを読み出す。

・ＩＤ差分の算出例
受信したメッセージＩＤが１１０ｈの場合、ＩＤ差分は以下のように算出される。
ＩＤ差分＝１１０ｈ−１００ｈ（基準ＩＤ）＝１０ｈ
なお、基準ＩＤは、例えばMAX_ADDRでもよい。この場合は、以下のようにＩＤ差分を算出する。
ＩＤ差分＝｜メッセージＩＤ−基準ＩＤ（MAX_ADDR）｜
すなわち、メッセージＩＤと基準ＩＤの差の絶対値を求めれば、MAX_ADDRからでもＩＤ差分を算出できる。また、「ＩＤ差分＝基準ＩＤ（MAX_ADDR）−メッセージＩＤ」としてもよい。

続いて、バッファＢＯＸとＱｕｅにおいて確保すべきＩＤ差分のビット数について説明する。
ＩＤ差分のビット数＝MAX_ADDR−MIN_ADDRの算出結果のビット幅
例えば、MAX_ADDR＝１２０ｈ、MIN_ADDR＝１００ｈの場合、
１２０ｈ−１００ｈ＝２０ｈ となる。
したがって、ＩＤ差分のビット数は6ビットである。

＜ＳＴＥＰ２ バッファ・Ｑｕｅへの格納＞
通信処理部１は、メッセージが格納されたＭＢＯＸの番号を取得する。ＩＤ差分は算出済である。そして、通信処理部１はメッセージのメッセージＩＤに基づき通信コンポーネント１〜３を特定し、通信コンポーネント１〜３に対応したバッファＢＯＸに記憶する。

図６は、バッファＢＯＸ番号と通信コンポーネントを対応づけるコンポ指定テーブルの一例を示す図である。コンポ指定テーブルによりバッファＢＯＸを決定できる。バッファＢＯＸに、ＭＢＯＸ番号、ＩＤ差分、ＤＬＣ及びＤＡＴＡが格納される。

この後、通信処理部２は、通信処理部１からの通知により、又は、通信処理部１に定期的に問い合わせるなどして、バッファＢＯＸのメッセージをＱｕｅに格納する。格納時にはコンポ指定というフィールドを加える。コンポ指定は、コンポ（本実施例では３つだが、最大２５６個のコンポを指定できる）を指定する１バイトの情報である。

通信処理部２は、コンポ指定テーブルを参照して、バッファＢＯＸの番号に対応づけられた通信コンポーネントのコンポ指定をＱｕｅに設定する。

＜ＳＴＥＰ３ メッセージＩＤの復元＞
通信処理部３は、Ｑｕｅに格納されたメッセージのＩＤ差分をメッセージＩＤに復元する。
メッセージＩＤ＝基準ＩＤ＋ＩＤ差分
基準ＩＤはＳＴＥＰ１の基準ＩＤと同じである。通信処理部３と通信処理部１は別のモジュールでも、互いに通信することや、通信処理部３がマスク値テーブルを参照することが可能なので、同じ基準ＩＤを使用できる。通信処理部３はＭＢＯＸ番号に基づきＭＢＯＸに専用の基準ＩＤを特定する。

例えば、MIN_ADDR＝１００ｈ、ＩＤ差分＝１０ｈの場合、
メッセージＩＤ＝１００ｈ＋１０ｈ＝１１０ｈ となる。

メッセージＩＤを復元すると、通信処理部３は、コンポ指定により特定した通信コンポーネント１５を呼び出して、例えば引数としてメッセージＩＤ、ＤＬＣ及びＤＡＴＡを通信コンポーネント１５に出力する。

〔送信時〕
図７は、本実施形態のマイコン１００がメッセージを送信する動作とそのデータ保存方法を示す図の一例である。

＜ＳＴＥＰ１ メッセージＩＤの変換＞
まず、通信コンポーネント１〜３はメッセージＩＤ、ＤＬＣ及びＤＡＴＡを生成して通信処理部３に送信を要求する。通信処理部３は基準ＩＤに基づきＩＤ差分を算出する。送信時の基準ＩＤも受信時とほぼ同様に、送信メッセージの最小メッセージＩＤとする。

図８は、通信コンポーネント１〜３が生成するメッセージＩＤを模式的に説明する図の一例である。多くの場合、設計者はＥＣＵ（マイコン）毎にメッセージＩＤをまとめる（ある範囲に入るように設定される）ので、まとめられたメッセージＩＤの最小値を基準ＩＤに決定することが可能になる。例えば、通信コンポーネント１はMessageA, MessageB, MessageC,…を送信する。通信コンポーネント２はMessage１, Message２, Message３,…を送信する。このように、各通信コンポーネントにより、送信するメッセージＩＤは決定されている。別のＥＣＵにおいても同様であり、通信コンポーネント１〜３が送信するメッセージＩＤはある範囲内に決まっている。

したがって、マイコン１００が送信するメッセージのメッセージＩＤの最小値MIN_SENDと最大値MAX_SENDは、ＥＣＵ（マイコン）と通信コンポーネント１５によって定まる。通信処理部３はこの送信時の基準ＩＤ（例えばMIN_SEND）を予め保持している。

・ＩＤ差分の算出例
MIN_SENDが２００ｈ、MAX_SENDが２５０ｈ、メッセージＩＤが２３０ｈの場合、ＩＤ差分は以下のようになる。
ＩＤ差分＝メッセージＩＤ−基準ＩＤ
＝２３０ｈ−２００ｈ（基準ＩＤ）＝３０ｈ
バッファＢＯＸとＱｕｅにおいて確保すべきＩＤ差分のビット数について説明する。
ＩＤ差分のビット数＝MAX_SEND−MIN_SENDの算出結果のビット幅
例えば、MAX_SEND＝２５０ｈ、MIN_SEND＝２００ｈの場合、
２５０ｈ−２００ｈ＝５０ｈ となる。
したがって、ＩＤ差分のビット数は７ビットであればよい。

＜ＳＴＥＰ２ バッファ・Ｑｕｅへの格納＞
通信処理部３は、通信コンポーネント１〜３が作成したメッセージをＱｕｅに格納する。Ｑｕｅに格納される情報のうち、ＩＤ差分、ＤＬＣ、ＤＡＴＡ、はすでに作成されている。ＭＢＯＸ番号は、受信時にメッセージＩＤによりＭＢＯＸ番号が決まったのと同様に、通信処理部３がメッセージＩＤに基づき作成する。さらにメッセージを作成した通信コンポーネントを考慮してもよい。コンポ指定は、メッセージを作成した通信コンポーネント１〜３の識別情報である。

なお、ＳＴＥＰ３で通信処理部１がメッセージＩＤを復元できるように、通信処理部３は、ＭＢＯＸ番号と基準ＩＤの対応を保持しておく。

この後、通信処理部２は、Ｑｕｅに格納されたメッセージを古いものから先に、バッファＢＯＸに格納する。通信処理部２は、図６のようなコンポ指定テーブルを参照して、コンポ指定に基づき特定したバッファＢＯＸに、ＭＢＯＸ番号、ＩＤ差分、ＤＬＣ及びＤＡＴＡを格納する。

＜ＳＴＥＰ３ メッセージＩＤの復元＞
通信処理部１は、バッファＢＯＸに格納されたメッセージのＩＤ差分をメッセージＩＤに復元して、通信コントローラ１３のＭＢＯＸに記憶する。メッセージＩＤは、受信時と同様に以下のようにして復元される。
メッセージＩＤ＝基準ＩＤ＋ＩＤ差分
基準ＩＤはＳＴＥＰ１の基準ＩＤと同じである。通信処理部１は、通信処理部３からＭＢＯＸ番号に紐づけられた送信時の基準ＩＤ（例えばMIN_SEND）を取得する。基準ＩＤにＩＤ差分を加えることでメッセージＩＤを復元できる。
例えば、MIN_SEND＝２００ｈ、ID差分が３０ｈの場合、
メッセージＩＤ＝２００ｈ＋３０ｈ＝２３０ｈ となる。

〔ＲＡＭサイズの削減例〕
メッセージＩＤ：３２ビット、ＤＬＣ：３ビット、ＤＡＴＡ：８バイト、コンポ指定：１バイト、Ｑｕｅの段数：１２８、バッファＢＯＸの数：２５６、
の場合、ＱｕｅとバッファＢＯＸのサイズは以下のようになる。
・従来
Ｑｕｅ：（３２＋３＋６４＋８）×１２８＝１０７ビット×１２８＝１７１２バイト
バッファＢＯＸ：（３２＋３＋６４）×２５６＝９９ビット×２５６＝３１６８バイト
・本実施例（ｎ＝４）
Ｑｕｅ：（８＋４＋３＋６４＋８）×１２８＝８７ビット×１２８＝１３９２バイト
バッファＢＯＸ：（８＋４＋３＋６４）×２５６＝７９ビット×２５６＝２５２８バイト
よって、使用されるＲＡＭ容量を、従来の４８８０バイトから、本実施例では３９０２バイトに低減できる。差としては９６０バイトであり、比率としては約２０％、小さくできる。組み込み系のマイコンではこのような差は大変、大きい。また、車両に搭載されるマイコンの多くでこの効果を得られるので、車両全体としての効果はさらに大きくなる。なお、メッセージＩＤは３２ビットでなければならないのではなく、３２ビット未満（例えば２９ビット）や３２ビットより大きくてもよい。

以上説明したように、本実施形態の送受信方法は、通信コントローラ１３の標準機能（メッセージＩＤがある範囲のメッセージのみを受信する）を利用して、ＩＤ差分を算出するので、通信コントローラ１３にはほとんど変更なしに実現できる。また、通信の安全性／信頼性を維持したまま、ＲＡＭサイズの増大を抑制することができる。

本実施例では基準ＩＤの設定例について説明する。
Ａ．ＭＢＯＸ毎にマスクできない場合
マイコンによっては、例えば、ＭＢＯＸ[0]〜ＭＢＯＸ[100]、ＭＢＯＸ[101]〜ＭＢＯＸ[200]、ＭＢＯＸ[201]〜ＭＢＯＸ[255]のように、グループ毎にしかマスクを設定することしかできない。このようなマイコンでは、通信処理部１、３がＭＢＯＸ毎にMIN_ADDRとMIN_SENDを自動的に判別する。

図９（ａ）は、MIN_ADDRの設定方法を模式的に説明する図の一例である。上下方向の矢印１〜３はＭＢＯＸ[0]、ＭＢＯＸ[1]、ＭＢＯＸ[2]が受信するメッセージＩＤの範囲を示す。一定時間（例えば、１０分、１時間、数時間、１日など）、通信コントローラ１３がメッセージＩＤを受信すれば全てのメッセージを受信できるとしてよいので、各ＭＢＯＸで一定時間に受信した全てのメッセージにおいて最小のメッセージＩＤを基準ＩＤに決定する。

したがって、メッセージＩＤを監視することでＭＢＯＸ毎に基準ＩＤが設定される。以降は、実施例１と同様に、ＩＤ差分を算出し、メッセージＩＤを復元する。

Ｂ．全てのＭＢＯＸの基準ＩＤを一律に同じ値とする
実施例１ではＭＢＯＸ毎に基準ＩＤが定められていたが、全てのＭＢＯＸに対し基準ＩＤを一定値とすることもできる。例えば、ＭＢＯＸの数が少ないマイコンなどでは、マスク値テーブルのサイズを削減できるという効果がある。

Ｃ．送受信頻度により基準ＩＤを動的に変化させる
図９（ｂ）は送受信頻度と基準ＩＤの関係を模式的に示す図の一例である。上記のように、一定時間、通信コントローラ１３がメッセージＩＤを受信すれば、メッセージＩＤの送受信頻度を求めることができる。図示するように、頻度が高いメッセージＩＤとメッセージＩＤの大きさに相関があれば、送受信頻度が閾値以上のメッセージＩＤと閾値未満のメッセージＩＤとに区分できる。そして、通信処理部１、３はこの閾値を基準ＩＤに決定する。

通信コントローラ１３が、頻度が高いメッセージＩＤを受信した場合、通信処理部１は次のようにしてＩＤ差分を算出する。
ＩＤ差分＝メッセージＩＤ−基準ＩＤ（実施例１と同じ）
通信コントローラ１３が、頻度が低いメッセージＩＤを受信した場合、通信処理部１はＩＤ差分を算出しない。この場合、予め確保してあるバッファＢＯＸとＱｕｅにメッセージを記憶する。メッセージＩＤは例えば３２ビットのままなので、バッファＢＯＸやＱｕｅのサイズを削減できないが、送受信の頻度が少ないので確保する容量は、少なくてよい。例えば、以下のように確保する。
頻度高：Ｑｕｅ１２８段、バッファＢＯＸ１２８個
頻度低：Ｑｕｅ １段、バッファＢＯＸ １個
したがって、実施例１より増えたとしても従来よりは、はるかにＲＡＭ２２のサイズを抑制できる。

送信時は、通信処理部３が、通信コンポーネント１〜３が作成するデータのメッセージＩＤに対し、送信頻度が閾値以上のメッセージＩＤと閾値未満のメッセージＩＤとに区分する。そして、頻度が高いメッセージＩＤの場合にだけＩＤ差分を算出する。

以上説明したように、本実施形態のマイコンは、メッセージＩＤよりデータ量が少ないＩＤ差分に対応づけてバッファに記憶されるため、バッファ容量（ＲＡＭ）のサイズを低減できる。このため、メッセージＩＤが長くなったり、メッセージの送受信量が増えても、安定性／信頼性を維持したままコスト増を抑制できる。

１１ 二次バッファ（Ｑｕｅ）
１２ 一次バッファ
１３ 通信コントローラ
１４ 通信処理部
１５ 通信コンポーネント
２１ ＣＰＵ
２２ ＲＡＭ
１００ マイコン

Claims (9)

1. 車載ネットワークを介してデータを受信する車両用通信装置であって、
   所定範囲のデータ識別番号を有するデータを受信する受信手段と、
   前記受信手段が受信したデータのデータ識別番号から予め定められた基準識別番号を減じることで番号差分を算出する差分算出手段と、
   前記番号差分に対応づけて、前記受信手段が受信したデータを記憶する記憶手段と、
   前記記憶手段から読み出したデータの前記番号差分に前記基準識別番号を加えてデータ識別番号を復元し、データと共にデータを処理する処理手段に出力するデータ転送手段と、
   を有することを特徴とする車両用通信装置。
2. 前記基準識別番号は、前記受信手段が受信する前記所定範囲のデータ識別番号の上限又は下限である、
   ことを特徴とする請求項１記載の車両用通信装置。
3. 前記差分算出手段は、前記受信手段が受信したデータのデータ識別番号を監視して、閾値以上の受信頻度のデータ識別番号を前記基準識別番号に決定し、
   前記基準識別番号以上のデータを前記受信手段が受信した場合、前記基準識別番号を減じることで前記番号差分を算出し、データと対応づけて前記記憶手段に記憶し、
   前記基準識別番号未満のデータを前記受信手段が受信した場合、前記番号差分を算出することなく、データ識別番号にデータを対応づけて前記記憶手段に記憶する、
   ことを特徴とする請求項１記載の車両用通信装置。
4. 前記差分算出手段は、前記受信手段が受信したデータのデータ識別番号を監視して、前記所定範囲のデータ識別番号の上限又は下限を決定し、前記上限又は前記下限のデータ識別番号を前記基準識別番号に決定する、
   ことを特徴とする請求項１記載の車両用通信装置。
5. 車載ネットワークを介してデータを送信する車両用通信装置であって、
   所定範囲のデータ識別番号のデータを作成するデータ作成手段からデータを取得し、データ識別番号から予め定められた基準識別番号を減じることで番号差分を算出する差分算出手段と、
   前記番号差分に対応づけて、前記データ作成手段か作成したデータを記憶する記憶手段と、
   前記記憶手段から読み出したデータの前記番号差分に前記基準識別番号を加えてデータ識別番号を復元し、データと共に送信手段に記憶するデータ転送手段と、
   記憶されたデータ識別番号とデータをネットワークに送信する送信手段と、
   を有することを特徴とする車両用通信装置。
6. 前記基準識別番号は、前記データ作成手段が作成する前記所定範囲のデータ識別番号の上限又は下限である、
   ことを特徴とする請求項５記載の車両用通信装置。
7. 前記差分算出手段は、前記データ作成手段が作成したデータのデータ識別番号を監視して、閾値以上の作成頻度のデータ識別番号を前記基準識別番号に決定し、
   前記基準識別番号以上のデータを前記データ作成手段が作成した場合、前記基準識別番号を減じることで前記番号差分を算出し、データと対応づけて前記記憶手段に記憶し、
   前記基準識別番号未満のデータを前記データ作成手段が作成した場合、前記番号差分を算出することなく、データ識別番号にデータを対応づけて前記記憶手段に記憶する、
   ことを特徴とする請求項５記載の車両用通信装置。
8. 前記差分算出手段は、前記データ作成手段が作成したデータのデータ識別番号を監視して、前記所定範囲のデータ識別番号の上限又は下限を決定し、前記上限又は前記下限のデータ識別番号を前記基準識別番号に決定する、
   ことを特徴とする請求項５記載の車両用通信装置。
9. 請求項１〜８いずれか１項記載の車両用通信装置と、
   データを処理するＣＰＵと、
   前記記憶手段と、
   プログラムを記憶したプログラム記憶手段と、
   を有する情報処理装置。

Images