次に図面を参照してこの発明の実施の形態を説明する。図1は、この発明の一実施形態に従う、車載ゲートウェイ装置が接続される車両のネットワーク構成図の概略を示す。車両には、複数の電子制御装置(ECU)が搭載されており、たとえば、これらのECUには、エンジン制御用のECU、ドア制御用のECU、エアバック制御用のECU、ナビゲーションシステム用のECU等が含まれることができる。これらのECUは、中央処理装置(CPU)およびメモリを備えるコンピュータとして実現されている。
図の例の場合、ネットワークN1では、バスB1にECU1aが接続され、ネットワークN2では、バスB2にECU1bおよび1cが接続され、ネットワークN3では、バスB3にECU1dおよび1eが接続され、ネットワークN4では、バスB4にECU1fおよび1gが接続されている。この実施例では、バスB1〜B4は、バス型のネットワーク・トポロジによって車内LANを構成している。
さらに、バスB1〜B4は、ゲートウェイ装置10に接続されている。ネットワークN1〜N4は、ゲートウェイ装置10を介して互いに通信可能なように接続されており、したがって、ECU1a〜1gは、該ゲートウェイ装置10を介して、所定の通信プロトコルに従って互いに通信することができる。この実施例では、通信プロトコルとして、周知のCAN(controller area network)プロトコルを用いる。
各ECU1a〜1gは、「フレーム」と呼ばれるデータの単位で、データの送受信を行う。CANプロトコルに従うフレームは、図2に示されるような所定のフォーマットを有しており、フレームの開始を表すSOFフィールド、フレームを識別するためのIDなどを格納する調停(アービトレーション)フィールド、データ長などを格納する制御フィールド、転送すべきデータを格納するデータフィールド、エラーチェック用のCRCフィールド、ECUがデータを受信したことを伝えるために使用されるACKフィールド、およびフレームの終了を表すEOFフィールドから構成されている。
ここで、フレーム中の調停フィールドに格納される上記のID(識別子)は、フレームの種類毎に設定され、データの内容や送信ECUを識別するために用いられるが、さらに、通信における調停において優先順位(優先度)を決めるための番号をも表している。この実施例では、IDの値が小さいデータほど、高い優先順位のデータであることを表す。
ゲートウェイ装置10は、一のネットワークからフレームデータを受信すると、この受信したフレームデータのIDを確認し、予め設定されたルーティングマップに従って、そのフレームデータを、他のネットワークに送信するよう構成されている。
図3は、ゲートウェイ装置10の構成のブロック図を示す。なお、以下の図およびその説明において、構成要素を総称する場合には、aおよびbのような添え字を用いない符号で表記することとする。
ゲートウェイ装置10は、CANモジュール11、ルート検索部12、および送信制御部13を備え、この例では、該ゲートウェイ装置10に、バスB1およびB2の入力バスと、バスB3およびB4の出力バスとが接続されている。この実施例では、CANモジュール11およびルート検索部12による処理は、ハードウェアで実現されており、送信制御部13による処理は、ソフトウェアで、すなわちゲートウェイ装置10に備えられるCPU(中央処理装置)がメモリ等に記憶されたコンピュータプログラムを実行することによって実現される。
CANモジュール11は、CANプロトコルに従ってバスに対するフレームデータの送受信制御を行うよう構成されている。CANモジュール11には、入力バスのチャネル毎に受信メッセージボックス(MB)21が、出力バスのチャネル毎に送信メッセージボックス(MB)31が、たとえばレジスタの形態で予め設けられている。CANモジュール11は、入力バスから受け取ったフレームデータを受信MB21に一時的に格納すると共に、送信MB31に一時的に格納されたデータを、その優先度の高い順に出力バスに送信する機能を有する。この例では、入力バスのチャネル毎に使用する受信MB21の数は、1個である。また、出力バスのチャネル毎に使用する送信MB31は、IDの数(すなわち、優先度の数)よりも少なく、この実施例では、送信MB1、送信MB2および送信MB3から成る3個である。したがって、一時に3つのフレームデータを格納することができる。
図の例では、ゲートウェイ装置10がバスB1から受信するフレームデータを一時的に格納する受信MB21aと、ゲートウェイ装置10がバスB2から受信するフレームデータを一時的に格納する受信MB21bと、ゲートウェイ装置10がバスB3に送信するフレームデータを一時的に格納する送信MB31a(MB1〜MB3の3個の送信MBを有する)と、ゲートウェイ装置10がバスB4に送信するフレームデータを一時的に格納する送信MB31b(MB1〜MB3の3個の送信MBを有する)とが示されている。
CANモジュール11は、前述したように、ハードウェア構成を用いて実現されることができるが(たとえば、CAN通信を行うモジュールとして市販されているCANモジュールを利用することができる)、代替的に、ソフトウェアを用いて構成されるようにしてもよい。本願発明は、後述するように、既知のCANモジュールの機能を利用して、優先度の高い順にデータがバスに出力されるよう、送信制御部13によって送信メッセージボックスに対するデータの送信を制御するものである。
ルート検索部12は、検索エンジン部23およびFIFOバッファ25を備えている。具体的には、検索エンジン部23は、各入力バスに対応するよう設けられ、ルーティングマップ24は、各検索エンジン部23に関連づけられて、RAM等のメモリに予め記憶されている。また、FIFOバッファ25は、各出力バスに対応するよう設けられており、所定数の段数(たとえば、32個)から構成され、一段につき1個のフレームデータを格納することができる。
この例では、検索エンジン部23aが、入力バスB1に対応するよう設けられ、検索エンジン部23bが、入力バスB2に対応するよう設けられている。検索エンジン部23aには、ルーティングマップ24aが対応づけられ、検索エンジン部23bには、ルーティングマップ24bが対応づけられており、両者のルーティングマップ24aおよび24bは、同じものでもよい。FIFOバッファ25aは、出力バスB3に対応するよう設けられ、FIFOバッファ25bは、出力バスB4に対応するよう設けられている。
受信MB21には、順次、対応するバスからのフレームデータが格納される。検索エンジン部23は、所定のタイミングで、該受信MB21からフレームデータを読み出し、該フレームデータのIDに基づいて、RAM等のメモリに予め記憶されたルーティングマップ24を参照し、フレームデータの転送先のバス(チャネル)を求める。
ここで、図4を参照すると、ルーティングマップ24の一例が概略的に示されている。ルーティングマップ24は、IDを規定するIDフィールド、受信バス(入力バス)のチャネル番号を規定する受信バスフィールド、および送信バス(出力バス)のチャネル番号を規定する送信バスフィールドを有しており、ID毎に、どのバスから受信してどのバスに送信するのかを規定している。好ましくは、ルーティングマップ24は、図に示すように、IDの昇順に従って、すなわち高い優先度から低い優先度に向けて配列される。
さらに、この実施例では、ルーティングマップ24は、ラベルフィールドを有している。ラベルとIDは、1対1に対応づけられており、ラベルの値からIDの値は一義的に導き出され、その逆も同様である。
ラベルは、IDのビット数よりも少ないビット数から構成される。CANプロトコルの標準フレームの場合には、IDは11ビットで構成されるので、ラベルは、11ビットよりも少ないビット数で構成される。また、ID値の昇順に従って、ラベル値も昇順になるように、両者は対応づけられている。前述したように、この実施例では、ID値の昇順に従って優先度が低くなるので、ラベル値の昇順に従って優先度が低くなる。IDは、その連番に従って優先度が示され、結果として、実際に使用する優先度の数は211より少ない。したがって、ラベル値のビット数を、実際に使用する優先度(ID)の数に対応するよう設定することができる。また、ラベル値は、後述するように、配列構造を有する優先順格納領域27のエントリ番号として用いられるので、連続した値を持つよう設定される。
検索エンジン部23は、受け取ったフレームデータのIDと、ルーティングマップ24に記憶されたIDとを比較し、該フレームデータのIDと一致するIDを検索し、該検索したIDについて設定されたラベルと、送信バス(複数でもよい)のチャネル番号とを取得する。ルーティングマップ24がIDの昇順に従って配列されているので、比較は、IDの昇順に従って行われるのがよい。こうすることにより、受け取ったフレームデータの優先度が高いほど、より早期に、一致するIDを見つけることができ、検索処理の時間を短縮することができる。
検索エンジン部23は、受け取ったフレームデータに、取得したラベルを付加し、該ラベル付きフレームデータを、取得した送信バスのチャネル番号に対応するFIFOバッファ25に格納する。
この実施例では、検索エンジン部23が、各入力バスに対応するよう設けられているため、各入力バスからのフレームデータのルート検索処理を並列に実行することができる。代替的に、検索エンジン部23を、複数のバスチャネルに対して1個だけ設けるようにしてもよい。この場合、検索エンジン部23は、受信MB21aおよび21bの両方からのフレームデータについてルート検索を行う。この際、受信MB21aおよび21bと、検索エンジン部23との間に、検索エンジン23へのフレームデータの送信を制御するセレクタ部のようなものを設けてもよく、そのような形態は、たとえば特開2006−333438号公報に記載されている。なお、検索エンジン部23は、前述したように、たとえば当該公報に記載のようなハードウェアで実現されることができるが、代替的に、ソフトウェアによって実現してもよい。
図3に戻り、送信制御部13には、出力バスのチャネル毎に、優先順格納領域(バッファ手段)27および送信MBテーブル29が設けられており、これらは、RAM等のメモリに実現される。
この例では、出力バスB3について、優先順格納領域27aおよび送信MBテーブル29aが設けられ、出力バスB4について、優先順格納領域27bおよび送信MBテーブル29bが設けられている。
ここで、図5(a)を参照すると、優先順格納領域27の構成が示されている。優先順格納領域27は、優先度の数分(すなわち、ラベル値(ID値)の数分)のエントリを有する配列構造となっている。各エントリの番号は、ラベル値に対応しており、これらのエントリは、優先度の高い順に、すなわちラベル値の昇順に従って配列されている。たとえば、ラベル値が、1〜10の値を取るとすると、1〜10の番号のエントリ領域が、優先順格納領域27には予め設定されている。
さらに、優先順格納領域27は、各エントリ(ラベル値)について、データフィールド、受信フラグフィールド、送信MBフィールドを有する。データフィールドは、対応するFIFOバッファ25から受け取ったフレームデータを格納する領域である。受信フラグフィールドは、受信フラグが設定されるフィールドである。受信フラグフィールドの初期値(デフォルト値)はゼロであり、FIFOバッファ25から優先順格納領域27にフレームデータを格納した時に、値1が設定される。送信MBフィールドは、送信MBの番号が設定されるフィールドである。送信MBフィールドの初期値(デフォルト値)はゼロであり、対応するフレームデータが送信MB1〜MB3のいずれかに格納(複製)されたときに、該格納された先の送信MBの番号が設定される。この実施例では、送信MB31の数は3個であるので、送信MB1に格納されれば値1が設定され、送信MB2に格納されれば値2が設定され、送信MB3に格納されれば値3が設定される。
図5(b)には、送信MBテーブル29の構成が示されている。送信MBテーブル29は、送信MBの数分のフィールドを持つ。この実施例では、MB1〜MB3の3個の送信MBが存在するので、MB1フィールド、MB2フィールドおよびMB3フィールドを持つ。MB1フィールドには、送信MB1に現在格納されているフレームデータのラベル値が設定される。MB2およびMB3フィールドについても同様である。送信MBテーブル29を参照することにより、各送信MBに設定されているフレームデータのラベル値を特定することができる。
送信制御部13は、FIFOバッファ25aに格納されたフレームデータを、優先順格納領域27aの、該フレームデータのラベル値に対応するエントリ領域に一時的に格納する。送信制御部13は、送信MBテーブル29aを用い、優先度の高い順にデータが出力バスに送信されるよう、優先順格納領域27aから送信MB31aにデータを転送する優先順送信制御を実施する。CANモジュール11は、送信MB31aのMB1〜MB3に格納されたフレームデータを、優先度の高い順に、対応するバスB3に送信する。これらの制御は出力バス間で並列に実行され、よって図の例では、上記出力バスB3に対する制御と並列に、優先順格納領域27b、送信MBテーブル29bおよび送信MB31bを用いた出力バスB4に対する制御が実行される。
以下では、
1)優先順格納領域27に受信したデータのIDの優先度が、送信MB31のいずれかの送信MBに格納されたデータのIDよりも高い場合、および、
2)優先順格納領域27に受信したデータのIDの優先度が、送信MB31のいずれかの送信MBに格納されたデータのIDと同じである場合、
について、優先順送信制御の具体的な内容を説明する。前者の1)については、図6〜図9を参照して説明し、後者の2)については、図10および図11を参照して説明する。
図6〜図9を参照して、送信制御部13による、上記1)の場合の優先順送信制御の動作を説明する。ここで、ラベル値が1〜4に対応するID値は、それぞれ、100、110、200および300であるとする。また、フレームデータは、わかりやすいように、そのID値のみで図に示している。
図6は、所与の時間における一状態を示しており、FIFOバッファ25には、ラベル値2が付与されたID値が110(ID110と呼び、以下同様)のフレームデータが格納されていることを示す(前述したように、FIFOバッファ25は所定の段数を備えているが、図では、簡略化して、ID110のフレームデータの段のみを示している)。
優先順格納領域(以下、単に格納領域と呼ぶことがある)27には、ID100のフレームデータが、ラベル値が1のエントリ領域に格納され、ID200のフレームデータが、ラベル値が3のエントリ領域に格納され、ID300のフレームデータが、ラベル値が4のエントリ領域に格納されている。これらは、既に、対応するFIFOバッファ25から優先順格納領域27に転送されたものであるから、受信フラグフィールドの値は1となっている。
送信メッセージボックス31において、送信MB1には、ID100のフレームデータが既に設定(格納)されており、送信MB2には、ID200のフレームデータが既に設定されており、送信MB3には、ID300のフレームデータが既に設定されている。したがって、優先順格納領域27の送信MBフィールドにおいて、ラベル値が1のエントリ領域では、送信MB1を表す値1が設定され、ラベル値が3のエントリ領域では、送信MB2を表す値2が設定され、ラベル値が4のエントリ領域では、送信MB3を表す値3が設定されている。
優先順格納領域27のラベル値が2のエントリ領域のデータフィールドは空であり、よって、受信フラグフィールドの値はゼロである。この例では、送信MBフィールドの値はゼロ(初期値)であるが、以前に受信したデータのバスへの送信が完了している場合には、ゼロ以外の値が設定されていることがある。
また、送信MBテーブル29のMB1フィールドには、送信MB1に設定されているフレームデータのラベル値1が設定されている。同様に、MB2フィールドには値3が設定され、MB3フィールドには値4が設定されている。
図7は、図6よりも時間が進んだ状態を示している。送信制御部13は、FIFOバッファ25から、フレームデータと、対応するラベル値を読み出し、該フレームデータを、優先順格納領域27の、該読み出したラベル値に対応するエントリ領域に格納する。この例では、FIFOバッファ25から読み出したフレームデータのラベル値は2であるので、ラベル値が2のエントリ領域に、ID110のフレームデータが格納される。この格納動作と共に、該エントリの受信フラグフィールドの値は1に更新され、送信MBフィールドの値はゼロに維持される(ゼロ以外の値であれば、ゼロにクリアされることとなる)。
なお、FIFOバッファ25からフレームデータを読み出すタイミングは、FIFOバッファ25のオーバーフローを回避するよう、任意の適切な手法で設定されることができる。たとえば、検索エンジン部23によってFIFOバッファ25に所定数のデータを書き込んだことに応じて、割り込み信号を送信制御部13に発行し、これに応じて、送信制御部13は、FIFOバッファ25から順番にデータを読み出すことができる。このような手法の一例は、特開2006−333438号公報に記載されている。
図8は、図7よりも時間が進んだ状態を表している。ラベル値2の新たなフレームデータが優先順格納領域27に既に受信されたので、図では、FIFOバッファ25を空として示している。
送信制御部13は、送信MBテーブル29に、ゼロが設定されたフィールドが存在するかどうかを調べることにより、送信MB31に空きがあるかどうかを判断すると共に、新たなフレームデータのラベル値2と、送信MBテーブル29のラベル値1,3,4とを比較する。このラベル値の比較により、新たなフレームデータのIDと、送信MB31に存在するフレームデータのIDとの間で、優先度を比較することができる。
送信MB31に空きがあり、同じID(優先度)のフレームデータが送信MB31に存在しなければ、新たなフレームデータを、該空いている送信MBに送信すればよい。しかしながら、この例では、送信MB31に空きは無い。したがって、上記ラベル値の比較に基づいて、新たなフレームデータのIDが、送信MB31のいずれかのフレームデータのIDよりも優先度が高いかどうかを判定し、高いと判定したならば、送信MB1〜MB3のうち、最も優先度の低いフレームデータが格納されている送信MBを選択する。
この例では、新たなフレームデータのラベル値2は、送信MBテーブル29のMB2およびMB3フィールドに設定されているラベル値3および4よりも値が小さく、MB3フィールドに設定されているラベル値4は、MB2フィールドのラベル値3よりも大きい。したがって、送信MB3が、新たなフレームデータよりも優先度が低く、かつ最も優先度の低いフレームデータを格納した送信MBとして選択される。
送信制御部13は、こうして選択された送信MB3に既に設定されているID300のフレームデータのバスへの送信処理の停止を要求する信号を、CANモジュール11に発行する。この送信停止要求信号に応じて、CANモジュール11は、肯定応答を返すと共に、送信MB3のフレームデータの送信停止処理を実行し(図には、取消線によって停止を表している)、停止が完了したならば、停止完了信号を送信制御部13に返す。
送信制御部13は、停止完了信号を受けたならば、優先順格納領域27のラベル値4のエントリの送信MBフィールドの値を、3からゼロに更新する。これにより、バスへの送信が未完了であることが示され、該ラベル値4のフレームデータは、再び、送信MB31に送信されるのを待機する。
さらに、送信制御部13は、送信MBテーブル29のMB3フィールドの値を、4からゼロに更新する。これにより、送信MB3には、フレームデータが設定されておらず、空きであることが示される。こうして、優先度の高いデータが受信されたときには、優先度の低いデータの送信を停止して、強制的に空きの送信MBを作る。
なお、送信制御部13は、送信MBからフレームデータが実際にバスに送信されている最中なのか、それとも送信MBにおいてフレームデータがバスへの送信待ちの状態にあるのかについては、判断することができない。送信MBからバスへの送信は、CANモジュール11によって制御されているからである。CANモジュール11は、送信停止要求信号を受け取ったとき、送信停止要求の対象となる送信MBが送信待ちの状態にあれば、送信停止処理を実行するが、送信中の状態にあれば、送信停止処理を実行しない。この場合、CANモジュール11は、送信停止要求信号に対し、否定応答を示す信号を返信する。上記の新たなフレームデータは、優先順格納領域27に維持されたまま、いずれかの送信MBが空きになるのを待つ。
図9は、図8よりも時間が進んだ状態を表している。送信MBテーブル29のMB3フィールドがゼロに設定されたことにより、送信制御部13は、送信MB3に空きが生じたと判断し、優先順格納領域27のラベル値2のエントリのデータフィールドに格納されているフレームデータを、送信MB3に複製することにより設定する(上書き)。送信制御部13は、優先順格納領域27のラベル値2のエントリの送信MBフィールドの値を、ゼロから3に更新する。これにより、ラベル値2のフレームデータが、送信MB3に転送されたことが示される。また、送信制御部13は、送信MBテーブル29のMB3フィールドの値をゼロから2に更新する。これにより、送信MB3には、ラベル値2のフレームデータが設定されたことが示される。
なお、図7〜図9のような送信制御部13による処理が行われている間も、CANモジュール11は、送信MB31のMB1〜MB3に設定されたフレームデータのIDを互いに比較し、IDの優先度の高い順に、対応するバスにデータを送信(出力)する。バスへの出力が完了したならば、送信完了信号を、送信制御部13に発行する。送信制御部13は、送信完了となった送信MBに設定されていたフレームデータを、優先順格納領域27から削除すると共に、受信フラグフィールドの値をゼロにクリアする。また、送信MBテーブル29の、該送信完了となった送信MBに対応するMBフィールドの値をゼロにクリアする。たとえば、送信MB1のID100のフレームデータの出力バスへの送信が完了したならば、ラベル1のエントリ領域のデータフィールドから、ID100のフレームデータを削除し、受信フラグフィールドの値をゼロにクリアし、さらに、送信MBテーブル29のMB1フィールドの値をゼロにクリアする。こうして、ラベル値1のエントリ領域は空となり、送信MB1も空であることが示される。
このように、送信MBに格納されているデータよりも高い優先度のデータが新たに受信された場合には、送信MBに既に格納されている、より優先度の低いデータが、該受信された新たなデータによって置き換えられる。したがって、低い優先度のデータによって送信MBが占領されているがために高い優先度のデータが待ちになるのを防止し、より早期にバスに出力することができる。結果として、より忠実に優先度に従ったバスへの転送を実現することができる。
また、優先順格納領域27から送信MB31へのフレームデータの転送は複製によって行われ、優先順格納領域27には、該データが、バスへの出力が完了するまで保持される。したがって、送信MBに対する送信停止処理によって送信停止されたデータは、再度、送信MBに設定されるのを待つことができる。
また、送信制御部13による優先順送信制御では、優先度の判断を、ラベルを用いて行っており、IDを何ら用いていないため、処理負荷を軽減することができる。従来は、新たに受信したデータのIDと、ゲートウェイ装置に既に受信されたデータのIDとを比較することにより、いずれのデータの優先度が高いかの判断を行っていた。しかしながら、IDはビット数が多く、比較回数が増えるほど処理負荷が増大するおそれがある。それに対し、ラベルは、IDよりもビット数が少ないので、ラベル値同士の比較処理は、ID同士の比較に比べて処理負荷が軽い。
また、優先順格納領域27は、ラベル値の昇順に対応したエントリ番号を持つ配列構造をなしている。したがって、FIFOバッファ25からのデータに付与されたラベル値に基づいて、データを格納すべき領域を、優先順格納領域27において高速に見極めることができる。仮に、このようなラベル値のエントリ番号を持つ配列構造を用いないとすると、受信したデータのIDと、該格納領域27中に存在するデータのIDとを比較しながら、同じIDのデータ領域を検索する必要がある。上記のようなラベル値のエントリ番号を持つ配列構造を用いれば、このようなIDの比較および検索は不要である。
さらに、優先順格納領域27から送信MB31へのデータの送信は、該優先順格納領域27に格納されたデータの優先度の高い順に行われるが、該格納領域27では、ラベル値の昇順に、すなわち優先度の高い順にデータが配列されているので、より高速に、送信すべきデータを見つけることができる。
このように、ラベルを用いることにより、バスへの送信までの時間をより短縮することができる。しかしながら、他の実施形態では、ラベルを用いずに、IDを用いることによって、本願発明の優先順送信制御を実行してもよい。
次に、図10および図11を参照して、送信制御部13による、上記2)の場合の優先順送信制御の動作を説明する。上記2)は、受信したデータのIDの優先度と、送信MB31のいずれかの送信MBに設定されているデータのIDの優先度が、同じである場合を示す。
この例では、FIFOバッファ25に、ラベル値2のフレームデータが受信されている。他方、優先順格納領域27には、同じラベル値2のフレームデータが既に格納されており、これは、送信MBフィールドの値が3であるように、送信MB3に現在設定されているデータである。優先順格納領域27の当該フレームデータは、未だ、バスへの送信が完了していない。送信MBテーブル29のMB3フィールドの値は2である。
このような場合、送信制御部13は、FIFOバッファ25から、ラベル値2のフレームデータを読み出して、優先順格納領域27のラベル値2のエントリ領域を上書きして格納する。これに応じて、該エントリ領域の受信フラグフィールドは値1に維持されるが、送信MBフィールドの値は、ゼロにクリアされる。
さらに、送信制御部13は、前述したように、送信MBテーブル29を参照することにより、新たなフレームデータのラベル値2と、送信MBに既に設定されているフレームデータのラベル値1,0,2とを比較することにより、該新たなフレームデータのIDと同じIDのフレームデータが、送信MB3に設定されていることを判定する。この判定に応じて、送信制御部13は、送信MB3のバスへの送信を停止させる。前述したように、送信MB3に対して送信停止要求信号を発行し、CANモジュール11は、肯定応答を返すと共に、送信停止処理を実行する。CANモジュール11は、送信停止処理が完了したならば、停止完了信号を送信制御部13に送る。送信制御部13は、この停止完了信号を受信したことに応じて、ラベル値2のエントリ領域の送信MBフィールドの値をゼロに更新すると共に、送信MBテーブル29のMB3フィールドの値をゼロに更新する。
その後、送信制御部13は、ラベル値2のフレームデータを、優先格納領域27から送信MB3に複製して設定(上書き)すると共に、ラベル値2のエントリ領域の送信MBフィールドの値をゼロから3に更新し、また、送信MBテーブル29のMB3フィールドの値をゼロから2に更新する。
図示していないが、送信MB3に設定されたラベル値2のフレームデータのバスへの送信が完了したならば、優先順格納領域27から当該フレームデータを削除すると共に、受信フラグフィールドをゼロにクリアする。送信MBテーブル29のMB3フィールドもゼロにクリアされる。
このように、送信MBに格納されたのと同じIDのフレームデータを受信した場合には、優先順格納領域27の対応するエントリ領域は上書きされ、該送信MBも、たとえ他に空きの送信MBがあっても(図では、送信MB2が空きとなっている)、上書きされる。
なお、送信制御部13からの送信停止要求信号に応じて、CANモジュール11が否定応答を返した場合には、該ラベル値2のフレームデータは、図6〜図9を参照して説明した制御プロセスに従って、いずれかの送信MBに転送されるのを、優先順格納領域27において待機する。
上記のような上書きを許容する理由について述べると、IDが同じということは、同じ種類のデータを表している。たとえば、エンジン回転数データは、所定の時間間隔で求められるが、これらのデータには、同じIDが割り振られる。他方、ECUによって実施される車両の制御は、よりリアルタイムな制御を実現するため、車両の現在の運転状態に基づいて行われるのが好ましく、そのため、車両の運転状態を表すデータとして、最新のデータを用いて制御を行うのが好ましい。たとえば、エンジン回転数データに基づく何らかの制御を実行するとき、最新のエンジン回転数データを用いるのが好ましい。したがって、古いデータが転送されている間に、新しいデータが該古いデータに追いついた場合には、該新しいデータで古いデータを上書きする。こうすることにより、古いデータの無駄な転送を防止することができると共に、より新しいデータを、ECUの制御処理に供することができる。
なお、データの種類によっては、このような上書きを許容すべきでないものが存在しうるが、その場合、該上書きを許容しない種類のデータに対しては、上で述べた優先順送信制御とは別の任意の適切な手法によって、バスへの転送を行えばよい。
図11は、図10の代替形態を示す図である。図10と異なる点は、送信MBに空きがある場合には、同じIDのフレームデータの送信MBの送信停止の完了を待つことなく、該空きの送信MBにフレームデータを設定する点である。
具体的には、FIFOバッファ25から優先順格納領域27への格納は、図10と同様に行われる。その後、送信制御部13は、前述したように、送信MBテーブル29を参照することにより、ゼロが設定されたフィールドが存在するかどうか調べると共に、新たなフレームデータのラベル値2と、送信MB31に既に設定されているフレームデータのラベル値1,0,2とを比較する。これにより、該新たなフレームデータのIDと同じIDのフレームデータが、送信MB3に設定されていると共に、送信MB2に空きがあることを判定する。これに応じて、送信制御部13は、同じIDのフレームデータを有する送信MB3に対し、前述したのと同様の手法で、送信停止要求信号を発行する。CANモジュール11は、肯定応答を返すと共に、送信停止処理を実行する。他方、送信制御部13は、CANモジュール11からの停止完了信号の受信を待つことなく、優先順格納領域27から、空いている送信MB2に、ラベル値2のフレームデータを複製して設定すると共に、ラベル値2のエントリ領域の送信MBフィールドを3から2に更新し、送信MBテーブル29のMB2フィールドを、ゼロから2に更新する。
CANモジュール11は、送信MB3の送信停止処理が完了したならば、停止完了信号を送信制御部13に送る。送信制御部13は、この停止完了信号に応じて、送信MBテーブル29のMB3フィールドの値を2からゼロに更新する。なお、ラベル値2のエントリ領域の送信MBフィールドの値は、該ラベル値2のフレームデータが送信MB2に設定されているので、そのまま維持される(ゼロにクリアされない)。
図示していないが、送信MB2のフレームデータのバスへの送信が完了した時に、ラベル値2のエントリ内のデータは削除されると共に、受信フラグフィールドはゼロにクリアされ、送信MBテーブル29のMB2フィールドもゼロにクリアされる。
なお、送信MB3に対する送信停止要求に応じて、否定応答が返された場合には、送信MB3のデータは、送信停止されることなくそのまま送信され、送信完了に応じて、送信MBテーブル29のMB3フィールドの値がゼロにクリアされることとなる。その後、送信MB2に設定されたラベル値2のフレームデータのバスへの送信が完了したならば、優先順格納領域27から当該フレームデータを削除すると共に、受信フラグフィールドをゼロにクリアする。送信MBテーブル29のMB2フィールドもゼロにクリアされる。
図10の形態では、同じIDのフレームデータの送信MBへの転送を、CANモジュール11による送信MBの送信停止処理の完了を待ってから、すなわちCANモジュール11から停止完了信号を受けた後に行っていたが、図11の形態では、該送信停止処理の完了を待つ必要がない。CANモジュール11による送信停止処理には所定の時間を要するので、図11の形態によれば、該フレームデータの送信MBへの転送時間を短縮することができる。
次に、送信制御部13による、フレームデータがゲートウェイ装置10内に滞留している時間(滞留時間)を算出する機能について説明する。滞留時間の算出は、上記の優先順送信制御によって、優先度の低いフレームデータが、長期にわたってバスに送信されない状態を防止するために行われる。
一実施例では、タイマ(図示せず)を設け、フレームデータ毎に、該データがゲートウェイ装置10に滞留している時間を計時する。滞留時間は、フレームデータが、バスに出力されることなくゲートウェイ装置にどの程度留まっているかどうかを判断する指標として計時されるものであるから、このような指標の役割を果たすのであれば、計時を任意の時点から開始することができる。
たとえば、フレームデータがFIFOバッファ25から優先順格納領域27に格納された時点、または、フレームデータが、最初にいずれかの送信MBに設定された時点等を、計時の開始時点とすることができる。タイマは、ソフトウェア(プログラム)によって実現されてもよいし、ハードウェアで実現されてもよい。
こうして計時された滞留時間が所定値を超えても、該フレームデータが優先順格納領域27から削除されない(すなわち、バスへの送信が完了されない)場合、送信制御部13は、該フレームデータが設定された送信MBに対しては、送信停止要求信号を発行しない。この場合、受信した新たなフレームデータよりも優先度が低く、かつ、該送信停止したフレームデータの次に優先度の低いフレームデータがいずれかの送信MBに格納されているならば、該送信MBに対して送信停止要求信号を発行する。
たとえば、図8には、前述したように、送信MB3に対して送信停止要求信号を発行することが示されている。送信制御部13は、新たなデータのラベル値2と、送信MBテーブル29に設定されたラベル値1,3,4とを比較し、新たなデータよりも優先度が低く、かつ最も優先度の低いフレームデータを格納する送信MB3を判定している。滞留時間を用いるこの実施形態では、送信制御部13は、該判定した送信MB3に格納されているラベル値4のフレームデータの滞留時間が所定値を超えているかどうかを判断し、超えていなければ、前述したように送信MB3に対する送信停止要求信号を発行するが、超えているならば、送信MB3に対する送信停止要求信号の発行を禁止する。送信制御部13は、上記ラベル値の比較に基づき、新たなデータよりも優先度が低く、かつ送信停止したデータの次に優先度の低い送信MB(この例では、送信MB2)を判定し、該次に優先度の低い送信MB2に対して送信停止要求信号を発行する。こうすることにより、送信MB3のID300のフレームデータを、過渡の遅延を生じさせることなく、出力バスに送信することができる。
代替的に、タイマによる計時を、ラベル値(ID値)毎に行ってもよい。この場合、フレームデータにラベルが付された時点、フレームデータがFIFOバッファ25に受信された時点、FIFOバッファ25から優先順格納領域27に受信された時点、または、最初に送信MB31に設定された時点等を、計時の開始時点とすることができる。なお、この場合、図10や図11の形態のように同じIDのフレームデータを受信した場合には、同じタイマによって計時されることとなるので、該タイマをリセットして新たに計時を開始するのが好ましい。
他の実施例では、タイマを設ける代わりに、ゲートウェイ装置10内において何らかの時点でフレームデータに付与されるタイムスタンプを利用して、上記の滞留時間を算出してもよい。たとえば、受信メッセージボックス21にデータが受信された時点やFIFOバッファ25に受信された時点等においてフレームデータにタイムスタンプが付与される場合には、該タイムスタンプを利用することができる。代替的に、送信制御部13が、フレームデータをFIFOバッファ25から優先順格納領域27に格納した時点や、最初に送信MBに設定された時点において、タイムスタンプを該フレームデータに付与するようにしてもよい。
この場合、たとえば図8の場合には、送信制御部13は、前述したように、判定した送信MB3に格納されているラベル値4のフレームデータに付与されたタイムスタンプを参照し、現在の時刻と該タイムスタンプとの間の差を、滞留時間として算出し、該滞留時間が所定値を超えているかどうかを判断する。超えていなければ、前述したように送信MB3に対する送信停止要求信号を発行するが、超えているならば、送信MB3に対する送信停止要求信号の発行を禁止する。この場合も同様に、送信制御部13は、上記ラベル値の比較に基づき、新たなデータよりも優先度が低く、かつ送信停止したデータの次に優先度の低いデータの送信MB(この例では、送信MB2)を判定し、該次に優先度の低いデータの送信MB2に対して送信停止要求信号を発行する。
この実施例における、バスのチャネル毎に設けられる送信MB(メッセージボックス)の数は、MB1〜MB3の3個であり、これは、好ましい個数として選択されている。この理由を、図12および図13を参照して説明する。
図12は、チャネル毎に送信MBを2個(MB1とMB2)使用する場合の、送信MBからバスへのフレームデータの送信(出力)の一形態を示す図である。
時点t1において、送信MB1には、ID100のフレームデータが既に設定され、送信MB2には、ID200のフレームデータが既に設定されている。
1つのバスには、一時に1つのフレームデータのみを出力することができる。ID100は、ID200よりも優先度が高いので、時点t1においては、送信MB1からID100のフレームデータのバスへの送信が開始され、送信MB2のID200のフレームデータは、送信待ちの状態にある。
ここで、時点t2において、前述したような送信制御部13による優先順送信制御によって、送信制御部13から、送信停止要求信号が送信MB2に対して発行されたとする。これに応じて、CANモジュール11は、肯定応答を送信制御部13に返すと共に、送信MB2の送信待ち状態を解消して、所定の停止処理を実行する。停止処理が完了したならば、CANモジュール11は、停止完了信号を送信制御部13に返す。送信制御部13は、該停止完了信号に応じて、時点t3において、ID110のフレームデータの優先順格納領域27から送信MB2への送信を開始する。これにより、送信MB2のID200のフレームデータは、上書きされていく。この上書き動作は、時点t5まで継続する。なお、同じビット数のデータについて、上書き動作(設定時間)は、バスへの送信時間よりも短い。
他方、時点t4において、ID100のフレームデータのバスへの送信が完了する。送信完了信号が送信制御部13に送られ、これに応じて、送信制御部13は、新たなID200のフレームデータの送信MB1への送信を開始する。ID200のフレームデータの送信MB2への設定(上書き)は、時点t6まで継続する。
図から明らかなように、ID100のフレームデータのバスへの送信が完了した時点t4では、どちらの送信MBにおいてもデータを設定中であり、バスに送信可能なデータが存在しない。バスへの送信が開始されるのは、送信MB2にID110のフレームデータの設定を終えた時点t5である。該設定を終えたことに応じて、CANモジュール11は、送信MB2からバスへのID110のフレームデータの送信を開始する。
時点t6において、ID200のフレームデータの送信MB1への設定が完了する。ID110のフレームデータがバスへ送信されている最中であるので、ID200のフレームデータは送信待ちの状態に入る。時点t7において、ID110のフレームデータの送信が完了したことに応じて、ID200のフレームデータの送信が開始される。
図の時点t4〜t5に示すように、使用する送信MBが2個の場合には、送信制御部13による優先順送信制御によって、両方のMBにデータを設定している最中という状態が生じるおそれがあり、よって、バスにデータを連続して送信することができない状態が生じうる。バスは解放状態となり、これは、処理効率の低下につながる。
図13は、送信メッセージボックスを3個(MB1〜MB3)使用する場合の、送信MBからバスへのフレームデータの送信(出力)の一形態を示す図である。
時点t1において、送信MB1には、ID100のフレームデータが既に格納され、送信MB2には、ID200のフレームデータが既に格納され、送信MB3には、ID300のフレームデータが既に格納されている。
ID100は、ID200およびID300よりも優先度が高いので、時点t1においては、送信MB1からID100のフレームデータのバスへの送信が開始され、送信MB2のID200のフレームデータおよび送信MB3のID300のフレームデータは、送信待ちの状態にある。
ここで、時点t2において、前述したような送信制御部13による優先順送信制御によって、送信制御部13から、送信停止要求信号が送信MB3に対して発行されたとする。これに応じて、CANモジュール11は、この送信停止要求に対して肯定応答を送信制御部13に返すと共に、送信MB3の送信待ち状態を解消して、所定の停止処理を実行する。停止処理が完了したならば、CANモジュール11は、停止完了信号を送信制御部13に返す。送信制御部13は、該停止完了信号に応じて、時点t3において、ID110のフレームデータの優先順格納領域27から送信MB3への送信を開始する。これにより、送信MB3のID300のフレームデータは、上書きされていく。この上書き動作は、時点t5まで継続する。
他方、時点t4において、ID100のフレームデータのバスへの送信が完了する。CANモジュール11は、送信完了に応じて、送信MB2のID200のフレームデータのバスへの送信を速やかに開始する。また、ID100のフレームデータの送信完了信号が送信制御部13に送られ、これに応じて、送信制御部13は、新たなID300のフレームデータの送信MB1への送信を開始する。ID300のフレームデータの送信MB1への設定(上書き)は、時点t6まで継続する。
図から明らかなように、ID100のフレームデータのバスへの送信が完了した時点t4では、送信MB3は、優先順送信制御によって新たなフレームデータの設定中であるが、送信MB2のフレームデータのバスへの送信は、直ちに開始することができる。したがって、優先順送信制御によっていずれかの送信MBが設定中になっても、残りの1つの送信MBからのバスへの送信を連続して実行することができる。
時点t5において、送信MB3のID110のフレームデータの設定が完了すると、ID200のフレームデータが送信中であるので、送信待ちの状態に入る。また、時点t6において、送信MB1のID300のフレームデータの設定が完了すると、ID200のフレームデータがまだ送信中であるので、送信待ちの状態に入る。ID200のフレームデータの送信は、時点t7において完了する。送信待ちになっているのは、ID300とID110のフレームデータである。CANモジュール11は、IDを比較し、優先度の高い方のフレームデータ、すなわちID110のフレームデータを選択して、これを、バスに送信する。ID300のフレームデータの送信待ち状態は、継続される。
このように、使用する送信MBの数が3個である場合には、いずれかの送信MBが優先順送信制御によって送信待ちの状態から設定中の状態に移行しても、送信待ちとなっている他の送信MBからのフレームデータをバスに送信することができる。したがって、図12を参照して説明したような、バスが解放された状態が生じず、連続送信を行うことが可能である。このように、送信MBの数は、少なくとも3個設けるのが好ましい。
他方、使用する送信MBの数を4個以上にしても、上記のような連続送信は可能であるが、この場合、優先順送信制御において、どの送信MBに格納されたデータを置き換えるかを判断するための比較対象が増大するので処理負荷が増大するおそれがある。このような処理負荷は、使用する送信MBの数を増やすほど、増大する。また、CANモジュール11も、バスにデータの送信を開始する際に、最も優先度の高いIDのフレームデータを選択するが、この際も、比較対象となるIDの数が増大するので、処理負荷が増えるおそれがある。したがって、使用する送信MBの数を3個にとどめるのが、連続送信を可能にしつつ、処理負荷を抑制する観点から好ましい。
次に、図14は、送信制御部13によって実行される、FIFOバッファ25から優先順格納領域27にフレームデータを受信する制御プロセスのフローチャートである。このプロセスは、たとえば前述したように検索エンジン部23から割り込み信号を受けたことに応じて開始される。
ステップS11において、FIFOバッファ25からフレームデータを取得する。前述したように、フレームデータには、ルーティングマップ24の検索によって取得された、該フレームデータのIDに対応するラベルが付与されている。
ステップS12において、該取得したフレームデータに付与されたラベルを取得する(読む)。ステップS13において、優先順格納領域27の、取得したラベルに対応するエントリ領域に、該フレームデータを格納する。前述したように、該エントリ領域に既にフレームデータが存在する場合には、該取得したフレームデータで上書きされる。
ステップS14において、該エントリ領域の受信フラグフィールドの値を1に設定する。ステップS15において、該エントリ領域の送信MBフィールドの値を、ゼロにクリアする。こうして、図7に示すように、新たなフレームデータが格納領域27に格納される。
図15は、送信制御部13によって実行される、優先順格納領域27から送信MB31にフレームデータを送信する制御プロセスのフローチャートである。該プロセスは、たとえば所定時間間隔で、繰り返し実行される。
説明をわかりやすくするため、優先順格納領域27および送信MB31のいずれにもデータが格納されていない状況から、該プロセスを辿る。このような状況では、送信MBのいずれにもまだデータが格納されていないので、ステップS21およびS22の判断はNoとなり、ステップS25の判断もNoとなり、このプロセスを抜ける。
その後、図14の受信制御プロセスによって、優先順格納領域27に新たなフレームデータが格納されたとする。この場合、ステップS25の判断はYesとなり、ステップS26の判断はNoとなる。ステップS41に進むこととなり、ここで、いずれの送信MB1〜MB3にも設定されていないデータが格納領域27に存在するかどうかを判断する。これは、格納領域27の受信フラグフィールドの値が1であって、送信MBフィールドの値がゼロであるフレームデータが存在するかどうかによって判断されることができる。このようなデータが存在しないときには、送信MBに転送すべきデータが存在しないことを示すので、当該プロセスを抜ける。他方、上のように新たなフレームデータが格納領域27に格納されたときには、この判断はYesとなる。
ステップS42において、格納領域27に格納されているが、いずれの送信MB1〜MB3にも設定されていないフレームデータのうち、最も優先度の高いフレームデータ、すなわち最も小さいラベル値を持つフレームデータを選択して、それを、いずれかの送信MBに設定する(S26の判断がNoであるので、すべての送信MB1〜MB3が空いているため、どの送信MBでもよいが、通常、送信MB1から使用する)。こうして、上記の新たなフレームデータは、いずれかの送信MBに設定される。
ステップS43において、フレームデータが設定された送信MBの番号(MB1に設定されたならば、値1)を、格納領域27の該フレームデータに対応する送信MBフィールドに設定する(更新)。ステップS44において、送信MBテーブル29の、該設定された送信MB番号のフィールドの値を、該設定されたフレームデータのラベル値に更新する。こうして、優先度の高い順に、優先順格納領域27から送信MB31にデータが転送される。前述したように、送信MBに設定されたフレームデータは、CANモジュール11の制御によって、優先度の高い順にバスに出力される。
その後、いずれかの送信MB1〜MB3にデータが格納されている状態で、新たなフレームデータが格納領域27に受信されると、ステップS25およびS26の判断はYesとなる。ステップS27において、送信MB1〜MB3に設定されたフレームデータのIDと同じIDのフレームデータが、格納領域27に存在しているかどうかを判断する。これは、送信MBテーブル29のMB1〜MB3フィールドに設定されたラベル値と、格納領域27の受信フラグの値が1のラベル値とを比較することにより判断することができる。また、存在している場合には、ステップS28において、該存在している判断されたIDのフレームデータが、送信MBに未だ設定されていないかどうかを判断する。これは、当該IDの送信MBフィールドの値がゼロかどうかで判断することができる。
ステップS27またはステップS28の判断がNoであれば、送信MB1〜MB3に未だ設定されていないIDのフレームデータが新たに格納領域27に存在することを示す。ステップS35において、送信MBテーブル29のいずれかのフィールドにゼロが設定されているかどうかを判断することにより、3つの送信MB1〜MB3のいずれかに空きがあるかどうかを判断する。空きがあれば、ステップS41以下を実行する。すなわち、格納領域27に受信されているが、送信MBに未だ設定されていないフレームデータを、優先度の高い順に、空いている送信MBに設定する。
ステップS35において、送信MB1〜MB3のいずれにも空きが無ければ、ステップS36〜S38において、図8を参照して説明したように、強制的に空きの送信MBを作るための動作を実行する。すなわち、ステップS36において、送信MB1〜3のいずれかに設定されたフレームデータよりも、優先度の高いフレームデータが格納領域27に存在するかどうかを調べる。これは、送信MBテーブル29のラベル値と、格納領域27の受信フィールドの値が1のラベル値とを比較することにより行うことができる。存在していなければ(S36がNo)、送信MB1〜MB3に設定されたフレームデータの優先度の方が高いということなので、強制的に空きの送信MBを作ることは行わず、当該プロセスを抜ける。
存在していれば、ステップS37において、その存在している優先度の高いフレームデータの送信MBフィールドの値がゼロかどうかを調べることにより、そのフレームデータが、いずれの送信MBにも未だ設定されていないかどうかを判断する。設定されていれば(S37がNo)、強制的に空きの送信MBを作る必要はないので、当該プロセスを抜ける。
ステップS36およびS37の判断が両方ともYesであれば、送信MB1〜MB3に設定されているフレームデータよりも優先度の高いフレームデータが、格納領域27に存在していることを示す。ステップS38において、送信MBテーブル29を参照し、最も優先度の低い、すなわち最もラベル値の大きい送信MBを選択し、選択した送信MBに対して送信停止要求信号を発行し、その後、当該プロセスを抜ける。
再び当該プロセスを実行したとき、上記のように送信停止要求信号が発行されているので、ステップS21の判断がYesとなる。ステップS31において、送信停止が完了したかどうかを判断する。前述したように、CANモジュール11は、送信停止要求信号に応じて肯定応答を返した場合には停止処理を開始し、停止処理が完了したならば、停止完了信号を送信制御部13に発行する。
この停止完了信号を受け取るまで、または送信停止要求信号に対して否定応答を受けた場合には、ステップS31の判断はNoとなり、よって、ステップS25以下の処理が通常通り行われる。停止完了信号を受信したならば、ステップS31の判断はYesとなる。
ステップS32において、前述したように、送信停止の対象となった送信MBのフレームデータについて、格納領域27における送信MBフィールドの値をゼロにクリアにし、ステップS33において、送信MBテーブル29の、送信停止が行われた送信MBのラベルの値をゼロにクリアする。こうして、当該フレームデータのバスへの送信が未完了であることを示しつつ、該フレームデータは格納領域27にそのまま維持される。
送信停止によって、その送信MBは空きとなるので、ステップS35の判断がYesとなり、ステップS41以下の処理において、上記の新たなフレームデータは、空きとなった送信MBに設定されることとなる。
その後、CANモジュール11によって、この送信MBに設定されたフレームデータのバスへの送信が完了したならば、ステップS22の判断がYesとなり、ステップS23において、送信完了したフレームデータを、格納領域27から削除すると共に、対応する受信フラグフィールドの値を、1からゼロに更新する。ステップS24において、送信MBテーブル29の、送信完了した送信MBのラベル値をゼロにクリアする。
他方、ステップS27およびS28の両方の判断がYesの場合、すなわち、いずれかの送信MB1〜MB3に設定されたIDと同じIDのフレームデータが格納領域27に存在し、かつそのフレームデータが未だ送信MB1〜MB3に設定されていない場合には、このフローでは、図10に従って処理される。すなわち、ステップS29において、格納領域27の当該フレームデータを、同じIDのフレームデータが格納されている送信MBに上書き設定するため、その送信MBに対し、送信停止要求信号を発行する。送信停止要求信号を発行した後は、ステップS21、S31〜S33の処理により、その送信MBが空きにされ、ステップS41以下の処理で、格納領域27の当該フレームデータで、その空きにされた送信MBが上書きされる。
前述した滞留時間を用いる実施形態にも、図14および図15のプロセスは、同様に適用されることができる。この場合、図15において、ステップS38において送信停止要求を発行する対象となる、最も優先度の低いフレームデータが格納された送信MBを選択する際に、該データの滞留時間を参照し、これが所定値を超えている場合には、次に優先度の低いフレームデータの送信MBを選択する。こうして選択した送信MBに対し、送信停止要求信号を発行する。
また、図11を参照して説明した、同じIDのフレームデータを受信した場合の図10の代替形態についても、図14および図15のプロセスは同様に適用されることができる。この場合、空きの送信MBへのデータの設定が、同じIDの送信MBの送信停止処理の完了を待つことなく行われる。そのため、ステップS28の判断がYesになったとき、ステップS29を実行して、同じIDのフレームデータが格納されている送信MBの送信停止要求を発行すると共に、いずれかの送信MB1〜MB3に空きがあるかどうかを判断する。空きがあれば、ステップS41以下を実行して、その空いている送信MBに、格納領域27から、当該IDのフレームデータを送信する。その後、該送信停止要求を発行した送信MBについては、ステップS31の判断がYesになるが、該送信停止した送信MBに格納されていたフレームデータについては、ステップS32は実行されない。前述したように、優先順格納領域27の該当エントリ領域には、上書きにより新しいデータが既に格納されて該空きの送信MBに設定されており、該エントリ領域の送信MBフィールドには、ステップS43によって該送信MBの番号が既に設定されているからである。
上記の実施形態は、通信プロトコルとしてCANを用いているが、本願発明はこれに限定されず、他の通信プロトコルを用いた場合にも適用可能である。
以上のように、この発明の特定の実施形態について説明したが、本願発明は、これら実施形態に限定されるものではない。