(57)【要約】      （修正有）【課題】送信メッセージボックスの数を抑制しつつ、より忠実に優先度に従ったネットワーク間のデータ転送を可能とする車載ゲートウェイ装置を提供する。【解決手段】複数の送信メッセージボックスを、データに付される識別子の個数よりも少ない個数で構成し、転送すべき新たなデータを受信したとき、該新たなデータと識別子が同じであるデータが該複数の送信メッセージボックスのいずれかに格納されている場合には、該識別子が同じであるデータの他のネットワークへの送信を停止すると共に、該識別子が同じであるデータを、該新たなデータで上書きして格納し、該新たなデータと識別子が同じであるデータが該送信メッセージボックスのいずれにも格納されていない場合には、複数の送信メッセージボックスに格納されているデータのうち、該新たなデータよりも低い優先度を持ち、かつ最も優先度の低い識別子のデータを、該新たなデータで上書きして格納する。【選択図】図３
2010245793.tif 000002
【特許請求の範囲】
【請求項１】
複数のネットワークが接続され、一のネットワークから受信したデータを他のネットワークに転送する際に、該受信したデータを順次格納するバッファ手段と、該バッファ手段に格納したデータを、送信待ちデータとして該バッファ手段から複製して一時的に格納する複数の送信メッセージボックスと、該複数の送信メッセージボックスに格納されたデータを、該データに付された識別子（ＩＤ）の優先度に応じて、順次、前記他のネットワークに送信する制御手段と、を備えた車載ゲートウェイ装置であって、
前記複数の送信メッセージボックスは、前記識別子よりも少ない数で構成され、
前記制御手段は、転送すべき新たなデータを受信したとき、該新たなデータの識別子と、前記複数の送信メッセージボックスに格納されている各データの識別子とを比較し、
該新たなデータと識別子が同じであるデータが該複数の送信メッセージボックスのいずれかに格納されている場合には、該識別子が同じであるデータの前記他のネットワークへの送信を停止すると共に、該識別子が同じであるデータを、該新たなデータで上書きして格納し、
該新たなデータと識別子が同じであるデータが該送信メッセージボックスのいずれにも格納されていない場合には、前記複数の送信メッセージボックスに格納されているデータのうち、該新たなデータよりも低い優先度を持ち、かつ最も優先度の低い識別子のデータを、該新たなデータで上書きして格納する、
車載ゲートウェイ装置。
【請求項２】
前記他のネットワークに転送されずに前記車載ゲートウェイ装置内に滞留しているデータの滞留時間を求める手段を備え、
前記制御手段は、前記複数の送信メッセージボックスに格納されているデータのうち、最も優先度の低い識別子のデータの該滞留時間が所定値を超えている場合には、該新たなデータよりも低い優先度を持ち、かつ該滞留時間が所定値を超えている該データの次に優先度が低い識別子のデータの前記他のネットワークへの送信を停止すると共に、該送信停止したデータを、前記新たなデータで上書きして格納する、
請求項１に記載の車載ゲートウェイ装置。
【請求項３】
前記制御手段は、前記新たなデータを受信したとき、前記複数の送信メッセージボックスのうち、データが格納されていない送信メッセージボックスの有無を確認し、該データが格納されていない送信メッセージボックスが存在する場合には、前記新たなデータと識別子が同じであるデータが格納されていた場合でも、該識別子が同じであるデータを前記新たなデータで上書きすることなく、該新たなデータを、前記データが格納されていない送信メッセージボックスに格納すると共に、該識別子が同じであるデータの前記他のネットワークへの送信を停止する、
請求項１または２に記載の車載ゲートウェイ装置。
【請求項４】
前記制御手段は、前記データに付された識別子に対応し、かつ該識別子よりもビット数の少ないラベルを、前記データに付与し、前記新たなデータの識別子と前記複数の送信メッセージボックスに格納されている各データの識別子との前記比較を、該ラベルの値に基づいて行う、
請求項１から３のいずれかに記載の車載ゲートウェイ装置。
【請求項５】
前記送信メッセージボックスは、３個で構成される、
請求項１から４のいずれかに記載の車載ゲートウェイ装置。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、車両に搭載されるゲートウェイ装置に関する。
【背景技術】
【０００２】
近年の車両には、複数の電子制御装置（ＥＣＵと呼ぶ）が搭載されており、たとえばエンジン制御用のＥＣＵ、ドア制御用のＥＣＵ、エアバック用のＥＣＵ、ナビゲーション用のＥＣＵ等が搭載されている。これらのＥＣＵ間を、複数のネットワークで接続して互いに通信可能なようにするために、ゲートウェイ装置が提案されている。
【０００３】
下記の特許文献１には、受信データを複数の通信チャネル間で振り分ける検索エンジン部と、振り分けられたデータを一時的に蓄積する送信ＦＩＦＯとを備える車載ゲートウェイ装置が開示されている。また、このゲートウェイ装置では、検索エンジンを複数設けた場合に、該複数の検索エンジンから複数のデータが同時に出力されたときには、設定された優先順位に従って送信ＦＩＦＯにデータを出力する構成が開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００６−３３３４３８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
車両に搭載された複数の電子制御装置（ＥＣＵ）は、車両の様々な部位についての制御を実施している。制御内容も様々であり、様々な種類のデータが車内ネットワーク間で送受信される。これらの様々な種類のデータ間に優先順位を設定することにより、優先度の高いデータを、優先度の低いデータよりも優先して転送することが可能となる。
【０００６】
上記の特許文献１のゲートウェイ装置の構成では、バスを介して受信したデータを格納する受信メッセージボックスと、バスを介して出力するデータを格納する送信メッセージボックスとの間に、検索エンジンと送信ＦＩＦＯを有するゲートウェイハードマクロ部が設けられる。該ゲートウェイハードマクロ部の内部においては、優先度（ＩＤによって設定される）に従ったデータ転送が行われる。しかしながら、一旦データが送信メッセージボックスに格納された後は、そのデータよりも優先度の高いデータが受信されたとしても、バスへの送信の順番は変更されない。したがって、優先度の低いデータが、優先度の高いデータよりも先にバスへ送信されることが生じうる。特に、送信メッセージボックスに空きが無い場合には、メッセージボックスに既に格納されているデータのバスへの送信が完了するまで待たなければならず、結果として、優先度の低いデータがバスに送信された後に、優先度の高いデータが送信メッセージボックスに格納されるおそれがある。
【０００７】
このような送信メッセージボックスの空きを待つ時間をなくすためには、優先度の数分の送信メッセージボックスを設ければよい。これにより、バスへの連続的なデータ送信も可能になる。しかしながら、優先度（ＩＤ）の数が多いほど、送信メッセージボックスの数を増やす必要が生じ、これは、バスへの送信に際して優先度を比較する処理負荷を増大させるおそれがある。また、送信メッセージボックスが設けられる場所によっては、ハードウェア的な制約を受けるおそれがあるため、いたずらに該メッセージボックスの数を増やすことができないおそれがある。
【０００８】
したがって、送信メッセージボックスの数を抑制しつつ、ネットワーク間のデータ転送が、より忠実に優先度に従って実現されることを可能にする車載ゲートウェイ装置が所望されている。
【課題を解決するための手段】
【０００９】
この発明の一つの側面によると、複数のネットワークが接続され、一のネットワークから受信したデータを他のネットワークに転送する際に、該受信したデータを順次格納するバッファ手段と、該バッファ手段に格納したデータを、送信待ちデータとして該バッファ手段から複製して一時的に格納する複数の送信メッセージボックスと、該複数の送信メッセージボックスに格納されたデータを、該データに付された識別子（ＩＤ）の優先度に応じて、順次、前記他のネットワークに送信する制御手段と、を備えた車載ゲートウェイ装置が提供される。ここで、前記複数の送信メッセージボックスは、前記識別子よりも少ない数で構成される。前記制御手段は、転送すべき新たなデータを受信したとき、該新たなデータの識別子と、前記複数の送信メッセージボックスに格納されている各データの識別子とを比較する。該新たなデータと識別子が同じであるデータが該複数の送信メッセージボックスのいずれかに格納されている場合には、該識別子が同じであるデータの前記他のネットワークへの送信を停止すると共に、該識別子が同じであるデータを、該新たなデータで上書きして格納する。該新たなデータと識別子が同じであるデータが該送信メッセージボックスのいずれにも格納されていない場合には、前記複数の送信メッセージボックスに格納されているデータのうち、該新たなデータよりも低い優先度を持ち、かつ最も優先度の低い識別子のデータを、該新たなデータで上書きして格納する。
【００１０】
この発明のゲートウェイ装置によれば、優先度の高いデータが受信された場合には、送信メッセージボックスに既に格納された優先度の低いデータを、該優先度の高いデータで置き換える構成となっている。したがって、送信メッセージボックスの数は、識別子（ＩＤ）の数すなわち優先度として設定された数よりも少ないにもかかわらず、優先度により忠実に従うように転送先ネットワークへのデータ送信を実現することができる。結果として、優先度の高いデータの転送が遅延されるのを、より確実に防止することができる。
【００１１】
また、車両に関する制御では、データの種類が同じであれば、時間的に古いデータを、より新しいデータで置き換えるのが好ましい場合がある。これにより、より最新の車両の運転状態を反映した制御を実行することができるからである。この発明では、ゲートウェイ装置において、受信したデータと同じＩＤのデータが送信メッセージボックス内に存在している場合には、該受信された新たなデータで、該メッセージボックス内の古いデータが上書きされる。したがって、古いデータの送信は停止されるので、バスの無駄な消費を回避しつつ、より最新のデータを用いて車両に関する制御を行うことができる。
【００１２】
この発明の一実施形態によると、車載ゲートウェイ装置は、前記他のネットワークに転送されずに前記車載ゲートウェイ装置内に滞留しているデータの滞留時間を求める手段を備え、前記制御手段は、前記複数の送信メッセージボックスに格納されているデータのうち、最も優先度の低い識別子のデータの該滞留時間が所定値を超えている場合には、該新たなデータよりも低い優先度を持ち、かつ該滞留時間が所定値を超えている該データの次に優先度が低い識別子のデータの前記他のネットワークへの送信を停止すると共に、該送信停止したデータを、前記新たなデータで上書きして格納する。この発明によれば、優先度の高いデータの優先的な送信を維持しつつ、優先度の低いデータの送信が過度に遅延するのを防止することができる。
【００１３】
この発明の一実施形態によると、上記の制御手段は、前記新たなデータを受信したとき、前記複数の送信メッセージボックスのうち、データが格納されていない送信メッセージボックスの有無を確認し、該データが格納されていない送信メッセージボックスが存在する場合には、前記新たなデータと識別子が同じデータが格納されていた場合でも、該識別子が同じであるデータを、前記新たなデータで上書きすることなく、該新たなデータを、前記データが格納されていない送信メッセージボックスに格納すると共に、該識別子が同じであるデータの前記他のネットワークへの送信を停止する。この発明によれば、送信メッセージボックスに既に格納されているデータの送信停止の完了を待つことなく、新たなデータを送信メッセージボックスに格納することができるので、該新たなデータについて、送信メッセージボックスへの格納までの処理時間を、すなわちゲートウェイ装置を通過する時間を、より短縮することができる。
【００１４】
この発明の一実施形態によると、上記の制御手段は、前記データに付された識別子に対応し、かつ該識別子よりもビット数の少ないラベルを、前記データに付与し、前記新たなデータの識別子と前記複数の送信メッセージボックスに格納されている各データの識別子との前記比較を、該ラベルの値に基づいて行う。この発明によれば、識別子よりもデータ長（ビット数）が短いラベルの値に基づいて、受信したデータと送信メッセージボックスに格納されているデータとの間の識別子の比較すなわち優先度の比較を行うので、送信メッセージボックスへの格納までの処理時間を、すなわちゲートウェイ装置を通過する時間を、より短縮することができる。
【００１５】
この発明の一実施形態によると、前記送信メッセージボックスは、３個で構成される。送信メッセージボックスが２個であると、上記のような優先度に応じたデータの置き換えが生じた場合に、他のネットワークへの連続した送信が困難であるが、３個であれば、このような連続送信を行うことができる。他方、送信メッセージボックスの数を増やすほど、上記制御手段による処理負荷が増えるおそれがある。この発明では、送信メッセージボックスの数を３個にすることにより、連続送信を可能にしつつ、処理負荷の増大を抑制するこができる。
【００１６】
本発明のその他の特徴及び利点については、以下の詳細な説明から明らかである。
【図面の簡単な説明】
【００１７】
【図１】この発明の一実施例に従う、車内ネットワークの概略的な構成を示す図。
【図２】この発明の一実施例に従う、フレームデータの構成を示す図。
【図３】この発明の一実施例に従う、車載ゲートウェイ装置の概略的な構成を示すブロック図。
【図４】この発明の一実施例に従う、ルーティングマップの構成を示す図。
【図５】この発明の一実施例に従う、優先順格納領域および送信ＭＢテーブルの構成を示す図。
【図６】この発明の一実施例に従う、優先順送信制御の動作を説明するための図。
【図７】この発明の一実施例に従う、優先順送信制御の動作を説明するための図。
【図８】この発明の一実施例に従う、優先順送信制御の動作を説明するための図。
【図９】この発明の一実施例に従う、優先順送信制御の動作を説明するための図。
【図１０】この発明の一実施例に従う、優先順送信制御の動作を説明するための図。
【図１１】この発明の一実施例に従う、優先順送信制御の動作を説明するための図。
【図１２】この発明の一実施例に従う、送信メッセージボックスが２個の場合のバスへの送信形態を説明するための図。
【図１３】この発明の一実施例に従う、送信メッセージボックスが３個の場合のバスへの送信形態を説明するための図。
【図１４】この発明の一実施例に従う、受信制御プロセスのフローチャート。
【図１５】この発明の一実施例に従う、送信制御プロセスのフローチャート。
【発明を実施するための形態】
【００１８】
次に図面を参照してこの発明の実施の形態を説明する。図１は、この発明の一実施形態に従う、車載ゲートウェイ装置が接続される車両のネットワーク構成図の概略を示す。車両には、複数の電子制御装置（ＥＣＵ）が搭載されており、たとえば、これらのＥＣＵには、エンジン制御用のＥＣＵ、ドア制御用のＥＣＵ、エアバック制御用のＥＣＵ、ナビゲーションシステム用のＥＣＵ等が含まれることができる。これらのＥＣＵは、中央処理装置（ＣＰＵ）およびメモリを備えるコンピュータとして実現されている。
【００１９】
図の例の場合、ネットワークＮ１では、バスＢ１にＥＣＵ１ａが接続され、ネットワークＮ２では、バスＢ２にＥＣＵ１ｂおよび１ｃが接続され、ネットワークＮ３では、バスＢ３にＥＣＵ１ｄおよび１ｅが接続され、ネットワークＮ４では、バスＢ４にＥＣＵ１ｆおよび１ｇが接続されている。この実施例では、バスＢ１〜Ｂ４は、バス型のネットワーク・トポロジによって車内ＬＡＮを構成している。
【００２０】
さらに、バスＢ１〜Ｂ４は、ゲートウェイ装置１０に接続されている。ネットワークＮ１〜Ｎ４は、ゲートウェイ装置１０を介して互いに通信可能なように接続されており、したがって、ＥＣＵ１ａ〜１ｇは、該ゲートウェイ装置１０を介して、所定の通信プロトコルに従って互いに通信することができる。この実施例では、通信プロトコルとして、周知のＣＡＮ（controller area network）プロトコルを用いる。
【００２１】
各ＥＣＵ１ａ〜１ｇは、「フレーム」と呼ばれるデータの単位で、データの送受信を行う。ＣＡＮプロトコルに従うフレームは、図２に示されるような所定のフォーマットを有しており、フレームの開始を表すＳＯＦフィールド、フレームを識別するためのＩＤなどを格納する調停（アービトレーション）フィールド、データ長などを格納する制御フィールド、転送すべきデータを格納するデータフィールド、エラーチェック用のＣＲＣフィールド、ＥＣＵがデータを受信したことを伝えるために使用されるＡＣＫフィールド、およびフレームの終了を表すＥＯＦフィールドから構成されている。
【００２２】
ここで、フレーム中の調停フィールドに格納される上記のＩＤ（識別子）は、フレームの種類毎に設定され、データの内容や送信ＥＣＵを識別するために用いられるが、さらに、通信における調停において優先順位（優先度）を決めるための番号をも表している。この実施例では、ＩＤの値が小さいデータほど、高い優先順位のデータであることを表す。
【００２３】
ゲートウェイ装置１０は、一のネットワークからフレームデータを受信すると、この受信したフレームデータのＩＤを確認し、予め設定されたルーティングマップに従って、そのフレームデータを、他のネットワークに送信するよう構成されている。
【００２４】
図３は、ゲートウェイ装置１０の構成のブロック図を示す。なお、以下の図およびその説明において、構成要素を総称する場合には、ａおよびｂのような添え字を用いない符号で表記することとする。
【００２５】
ゲートウェイ装置１０は、ＣＡＮモジュール１１、ルート検索部１２、および送信制御部１３を備え、この例では、該ゲートウェイ装置１０に、バスＢ１およびＢ２の入力バスと、バスＢ３およびＢ４の出力バスとが接続されている。この実施例では、ＣＡＮモジュール１１およびルート検索部１２による処理は、ハードウェアで実現されており、送信制御部１３による処理は、ソフトウェアで、すなわちゲートウェイ装置１０に備えられるＣＰＵ（中央処理装置）がメモリ等に記憶されたコンピュータプログラムを実行することによって実現される。
【００２６】
ＣＡＮモジュール１１は、ＣＡＮプロトコルに従ってバスに対するフレームデータの送受信制御を行うよう構成されている。ＣＡＮモジュール１１には、入力バスのチャネル毎に受信メッセージボックス（ＭＢ）２１が、出力バスのチャネル毎に送信メッセージボックス（ＭＢ）３１が、たとえばレジスタの形態で予め設けられている。ＣＡＮモジュール１１は、入力バスから受け取ったフレームデータを受信ＭＢ２１に一時的に格納すると共に、送信ＭＢ３１に一時的に格納されたデータを、その優先度の高い順に出力バスに送信する機能を有する。この例では、入力バスのチャネル毎に使用する受信ＭＢ２１の数は、１個である。また、出力バスのチャネル毎に使用する送信ＭＢ３１は、ＩＤの数（すなわち、優先度の数）よりも少なく、この実施例では、送信ＭＢ１、送信ＭＢ２および送信ＭＢ３から成る３個である。したがって、一時に３つのフレームデータを格納することができる。
【００２７】
図の例では、ゲートウェイ装置１０がバスＢ１から受信するフレームデータを一時的に格納する受信ＭＢ２１ａと、ゲートウェイ装置１０がバスＢ２から受信するフレームデータを一時的に格納する受信ＭＢ２１ｂと、ゲートウェイ装置１０がバスＢ３に送信するフレームデータを一時的に格納する送信ＭＢ３１ａ（ＭＢ１〜ＭＢ３の３個の送信ＭＢを有する）と、ゲートウェイ装置１０がバスＢ４に送信するフレームデータを一時的に格納する送信ＭＢ３１ｂ（ＭＢ１〜ＭＢ３の３個の送信ＭＢを有する）とが示されている。
【００２８】
ＣＡＮモジュール１１は、前述したように、ハードウェア構成を用いて実現されることができるが（たとえば、ＣＡＮ通信を行うモジュールとして市販されているＣＡＮモジュールを利用することができる）、代替的に、ソフトウェアを用いて構成されるようにしてもよい。本願発明は、後述するように、既知のＣＡＮモジュールの機能を利用して、優先度の高い順にデータがバスに出力されるよう、送信制御部１３によって送信メッセージボックスに対するデータの送信を制御するものである。
【００２９】
ルート検索部１２は、検索エンジン部２３およびＦＩＦＯバッファ２５を備えている。具体的には、検索エンジン部２３は、各入力バスに対応するよう設けられ、ルーティングマップ２４は、各検索エンジン部２３に関連づけられて、ＲＡＭ等のメモリに予め記憶されている。また、ＦＩＦＯバッファ２５は、各出力バスに対応するよう設けられており、所定数の段数（たとえば、３２個）から構成され、一段につき１個のフレームデータを格納することができる。
【００３０】
この例では、検索エンジン部２３ａが、入力バスＢ１に対応するよう設けられ、検索エンジン部２３ｂが、入力バスＢ２に対応するよう設けられている。検索エンジン部２３ａには、ルーティングマップ２４ａが対応づけられ、検索エンジン部２３ｂには、ルーティングマップ２４ｂが対応づけられており、両者のルーティングマップ２４ａおよび２４ｂは、同じものでもよい。ＦＩＦＯバッファ２５ａは、出力バスＢ３に対応するよう設けられ、ＦＩＦＯバッファ２５ｂは、出力バスＢ４に対応するよう設けられている。
【００３１】
受信ＭＢ２１には、順次、対応するバスからのフレームデータが格納される。検索エンジン部２３は、所定のタイミングで、該受信ＭＢ２１からフレームデータを読み出し、該フレームデータのＩＤに基づいて、ＲＡＭ等のメモリに予め記憶されたルーティングマップ２４を参照し、フレームデータの転送先のバス（チャネル）を求める。
【００３２】
ここで、図４を参照すると、ルーティングマップ２４の一例が概略的に示されている。ルーティングマップ２４は、ＩＤを規定するＩＤフィールド、受信バス（入力バス）のチャネル番号を規定する受信バスフィールド、および送信バス（出力バス）のチャネル番号を規定する送信バスフィールドを有しており、ＩＤ毎に、どのバスから受信してどのバスに送信するのかを規定している。好ましくは、ルーティングマップ２４は、図に示すように、ＩＤの昇順に従って、すなわち高い優先度から低い優先度に向けて配列される。
【００３３】
さらに、この実施例では、ルーティングマップ２４は、ラベルフィールドを有している。ラベルとＩＤは、１対１に対応づけられており、ラベルの値からＩＤの値は一義的に導き出され、その逆も同様である。
【００３４】
ラベルは、ＩＤのビット数よりも少ないビット数から構成される。ＣＡＮプロトコルの標準フレームの場合には、ＩＤは１１ビットで構成されるので、ラベルは、１１ビットよりも少ないビット数で構成される。また、ＩＤ値の昇順に従って、ラベル値も昇順になるように、両者は対応づけられている。前述したように、この実施例では、ＩＤ値の昇順に従って優先度が低くなるので、ラベル値の昇順に従って優先度が低くなる。ＩＤは、その連番に従って優先度が示され、結果として、実際に使用する優先度の数は２１１より少ない。したがって、ラベル値のビット数を、実際に使用する優先度（ＩＤ）の数に対応するよう設定することができる。また、ラベル値は、後述するように、配列構造を有する優先順格納領域２７のエントリ番号として用いられるので、連続した値を持つよう設定される。
【００３５】
検索エンジン部２３は、受け取ったフレームデータのＩＤと、ルーティングマップ２４に記憶されたＩＤとを比較し、該フレームデータのＩＤと一致するＩＤを検索し、該検索したＩＤについて設定されたラベルと、送信バス（複数でもよい）のチャネル番号とを取得する。ルーティングマップ２４がＩＤの昇順に従って配列されているので、比較は、ＩＤの昇順に従って行われるのがよい。こうすることにより、受け取ったフレームデータの優先度が高いほど、より早期に、一致するＩＤを見つけることができ、検索処理の時間を短縮することができる。
【００３６】
検索エンジン部２３は、受け取ったフレームデータに、取得したラベルを付加し、該ラベル付きフレームデータを、取得した送信バスのチャネル番号に対応するＦＩＦＯバッファ２５に格納する。
【００３７】
この実施例では、検索エンジン部２３が、各入力バスに対応するよう設けられているため、各入力バスからのフレームデータのルート検索処理を並列に実行することができる。代替的に、検索エンジン部２３を、複数のバスチャネルに対して１個だけ設けるようにしてもよい。この場合、検索エンジン部２３は、受信ＭＢ２１ａおよび２１ｂの両方からのフレームデータについてルート検索を行う。この際、受信ＭＢ２１ａおよび２１ｂと、検索エンジン部２３との間に、検索エンジン２３へのフレームデータの送信を制御するセレクタ部のようなものを設けてもよく、そのような形態は、たとえば特開２００６−３３３４３８号公報に記載されている。なお、検索エンジン部２３は、前述したように、たとえば当該公報に記載のようなハードウェアで実現されることができるが、代替的に、ソフトウェアによって実現してもよい。
【００３８】
図３に戻り、送信制御部１３には、出力バスのチャネル毎に、優先順格納領域（バッファ手段）２７および送信ＭＢテーブル２９が設けられており、これらは、ＲＡＭ等のメモリに実現される。
【００３９】
この例では、出力バスＢ３について、優先順格納領域２７ａおよび送信ＭＢテーブル２９ａが設けられ、出力バスＢ４について、優先順格納領域２７ｂおよび送信ＭＢテーブル２９ｂが設けられている。
【００４０】
ここで、図５（ａ）を参照すると、優先順格納領域２７の構成が示されている。優先順格納領域２７は、優先度の数分（すなわち、ラベル値（ＩＤ値）の数分）のエントリを有する配列構造となっている。各エントリの番号は、ラベル値に対応しており、これらのエントリは、優先度の高い順に、すなわちラベル値の昇順に従って配列されている。たとえば、ラベル値が、１〜１０の値を取るとすると、１〜１０の番号のエントリ領域が、優先順格納領域２７には予め設定されている。
【００４１】
さらに、優先順格納領域２７は、各エントリ（ラベル値）について、データフィールド、受信フラグフィールド、送信ＭＢフィールドを有する。データフィールドは、対応するＦＩＦＯバッファ２５から受け取ったフレームデータを格納する領域である。受信フラグフィールドは、受信フラグが設定されるフィールドである。受信フラグフィールドの初期値（デフォルト値）はゼロであり、ＦＩＦＯバッファ２５から優先順格納領域２７にフレームデータを格納した時に、値１が設定される。送信ＭＢフィールドは、送信ＭＢの番号が設定されるフィールドである。送信ＭＢフィールドの初期値（デフォルト値）はゼロであり、対応するフレームデータが送信ＭＢ１〜ＭＢ３のいずれかに格納（複製）されたときに、該格納された先の送信ＭＢの番号が設定される。この実施例では、送信ＭＢ３１の数は３個であるので、送信ＭＢ１に格納されれば値１が設定され、送信ＭＢ２に格納されれば値２が設定され、送信ＭＢ３に格納されれば値３が設定される。
【００４２】
図５（ｂ）には、送信ＭＢテーブル２９の構成が示されている。送信ＭＢテーブル２９は、送信ＭＢの数分のフィールドを持つ。この実施例では、ＭＢ１〜ＭＢ３の３個の送信ＭＢが存在するので、ＭＢ１フィールド、ＭＢ２フィールドおよびＭＢ３フィールドを持つ。ＭＢ１フィールドには、送信ＭＢ１に現在格納されているフレームデータのラベル値が設定される。ＭＢ２およびＭＢ３フィールドについても同様である。送信ＭＢテーブル２９を参照することにより、各送信ＭＢに設定されているフレームデータのラベル値を特定することができる。
【００４３】
送信制御部１３は、ＦＩＦＯバッファ２５ａに格納されたフレームデータを、優先順格納領域２７ａの、該フレームデータのラベル値に対応するエントリ領域に一時的に格納する。送信制御部１３は、送信ＭＢテーブル２９ａを用い、優先度の高い順にデータが出力バスに送信されるよう、優先順格納領域２７ａから送信ＭＢ３１ａにデータを転送する優先順送信制御を実施する。ＣＡＮモジュール１１は、送信ＭＢ３１ａのＭＢ１〜ＭＢ３に格納されたフレームデータを、優先度の高い順に、対応するバスＢ３に送信する。これらの制御は出力バス間で並列に実行され、よって図の例では、上記出力バスＢ３に対する制御と並列に、優先順格納領域２７ｂ、送信ＭＢテーブル２９ｂおよび送信ＭＢ３１ｂを用いた出力バスＢ４に対する制御が実行される。
【００４４】
以下では、
１）優先順格納領域２７に受信したデータのＩＤの優先度が、送信ＭＢ３１のいずれかの送信ＭＢに格納されたデータのＩＤよりも高い場合、および、
２）優先順格納領域２７に受信したデータのＩＤの優先度が、送信ＭＢ３１のいずれかの送信ＭＢに格納されたデータのＩＤと同じである場合、
について、優先順送信制御の具体的な内容を説明する。前者の１）については、図６〜図９を参照して説明し、後者の２）については、図１０および図１１を参照して説明する。
【００４５】
図６〜図９を参照して、送信制御部１３による、上記１）の場合の優先順送信制御の動作を説明する。ここで、ラベル値が１〜４に対応するＩＤ値は、それぞれ、１００、１１０、２００および３００であるとする。また、フレームデータは、わかりやすいように、そのＩＤ値のみで図に示している。
【００４６】
図６は、所与の時間における一状態を示しており、ＦＩＦＯバッファ２５には、ラベル値２が付与されたＩＤ値が１１０（ＩＤ１１０と呼び、以下同様）のフレームデータが格納されていることを示す（前述したように、ＦＩＦＯバッファ２５は所定の段数を備えているが、図では、簡略化して、ＩＤ１１０のフレームデータの段のみを示している）。
【００４７】
優先順格納領域（以下、単に格納領域と呼ぶことがある）２７には、ＩＤ１００のフレームデータが、ラベル値が１のエントリ領域に格納され、ＩＤ２００のフレームデータが、ラベル値が３のエントリ領域に格納され、ＩＤ３００のフレームデータが、ラベル値が４のエントリ領域に格納されている。これらは、既に、対応するＦＩＦＯバッファ２５から優先順格納領域２７に転送されたものであるから、受信フラグフィールドの値は１となっている。
【００４８】
送信メッセージボックス３１において、送信ＭＢ１には、ＩＤ１００のフレームデータが既に設定（格納）されており、送信ＭＢ２には、ＩＤ２００のフレームデータが既に設定されており、送信ＭＢ３には、ＩＤ３００のフレームデータが既に設定されている。したがって、優先順格納領域２７の送信ＭＢフィールドにおいて、ラベル値が１のエントリ領域では、送信ＭＢ１を表す値１が設定され、ラベル値が３のエントリ領域では、送信ＭＢ２を表す値２が設定され、ラベル値が４のエントリ領域では、送信ＭＢ３を表す値３が設定されている。
【００４９】
優先順格納領域２７のラベル値が２のエントリ領域のデータフィールドは空であり、よって、受信フラグフィールドの値はゼロである。この例では、送信ＭＢフィールドの値はゼロ（初期値）であるが、以前に受信したデータのバスへの送信が完了している場合には、ゼロ以外の値が設定されていることがある。
【００５０】
また、送信ＭＢテーブル２９のＭＢ１フィールドには、送信ＭＢ１に設定されているフレームデータのラベル値１が設定されている。同様に、ＭＢ２フィールドには値３が設定され、ＭＢ３フィールドには値４が設定されている。
【００５１】
図７は、図６よりも時間が進んだ状態を示している。送信制御部１３は、ＦＩＦＯバッファ２５から、フレームデータと、対応するラベル値を読み出し、該フレームデータを、優先順格納領域２７の、該読み出したラベル値に対応するエントリ領域に格納する。この例では、ＦＩＦＯバッファ２５から読み出したフレームデータのラベル値は２であるので、ラベル値が２のエントリ領域に、ＩＤ１１０のフレームデータが格納される。この格納動作と共に、該エントリの受信フラグフィールドの値は１に更新され、送信ＭＢフィールドの値はゼロに維持される（ゼロ以外の値であれば、ゼロにクリアされることとなる）。
【００５２】
なお、ＦＩＦＯバッファ２５からフレームデータを読み出すタイミングは、ＦＩＦＯバッファ２５のオーバーフローを回避するよう、任意の適切な手法で設定されることができる。たとえば、検索エンジン部２３によってＦＩＦＯバッファ２５に所定数のデータを書き込んだことに応じて、割り込み信号を送信制御部１３に発行し、これに応じて、送信制御部１３は、ＦＩＦＯバッファ２５から順番にデータを読み出すことができる。このような手法の一例は、特開２００６−３３３４３８号公報に記載されている。
【００５３】
図８は、図７よりも時間が進んだ状態を表している。ラベル値２の新たなフレームデータが優先順格納領域２７に既に受信されたので、図では、ＦＩＦＯバッファ２５を空として示している。
【００５４】
送信制御部１３は、送信ＭＢテーブル２９に、ゼロが設定されたフィールドが存在するかどうかを調べることにより、送信ＭＢ３１に空きがあるかどうかを判断すると共に、新たなフレームデータのラベル値２と、送信ＭＢテーブル２９のラベル値１，３，４とを比較する。このラベル値の比較により、新たなフレームデータのＩＤと、送信ＭＢ３１に存在するフレームデータのＩＤとの間で、優先度を比較することができる。
【００５５】
送信ＭＢ３１に空きがあり、同じＩＤ（優先度）のフレームデータが送信ＭＢ３１に存在しなければ、新たなフレームデータを、該空いている送信ＭＢに送信すればよい。しかしながら、この例では、送信ＭＢ３１に空きは無い。したがって、上記ラベル値の比較に基づいて、新たなフレームデータのＩＤが、送信ＭＢ３１のいずれかのフレームデータのＩＤよりも優先度が高いかどうかを判定し、高いと判定したならば、送信ＭＢ１〜ＭＢ３のうち、最も優先度の低いフレームデータが格納されている送信ＭＢを選択する。
【００５６】
この例では、新たなフレームデータのラベル値２は、送信ＭＢテーブル２９のＭＢ２およびＭＢ３フィールドに設定されているラベル値３および４よりも値が小さく、ＭＢ３フィールドに設定されているラベル値４は、ＭＢ２フィールドのラベル値３よりも大きい。したがって、送信ＭＢ３が、新たなフレームデータよりも優先度が低く、かつ最も優先度の低いフレームデータを格納した送信ＭＢとして選択される。
【００５７】
送信制御部１３は、こうして選択された送信ＭＢ３に既に設定されているＩＤ３００のフレームデータのバスへの送信処理の停止を要求する信号を、ＣＡＮモジュール１１に発行する。この送信停止要求信号に応じて、ＣＡＮモジュール１１は、肯定応答を返すと共に、送信ＭＢ３のフレームデータの送信停止処理を実行し（図には、取消線によって停止を表している）、停止が完了したならば、停止完了信号を送信制御部１３に返す。
【００５８】
送信制御部１３は、停止完了信号を受けたならば、優先順格納領域２７のラベル値４のエントリの送信ＭＢフィールドの値を、３からゼロに更新する。これにより、バスへの送信が未完了であることが示され、該ラベル値４のフレームデータは、再び、送信ＭＢ３１に送信されるのを待機する。
【００５９】
さらに、送信制御部１３は、送信ＭＢテーブル２９のＭＢ３フィールドの値を、４からゼロに更新する。これにより、送信ＭＢ３には、フレームデータが設定されておらず、空きであることが示される。こうして、優先度の高いデータが受信されたときには、優先度の低いデータの送信を停止して、強制的に空きの送信ＭＢを作る。
【００６０】
なお、送信制御部１３は、送信ＭＢからフレームデータが実際にバスに送信されている最中なのか、それとも送信ＭＢにおいてフレームデータがバスへの送信待ちの状態にあるのかについては、判断することができない。送信ＭＢからバスへの送信は、ＣＡＮモジュール１１によって制御されているからである。ＣＡＮモジュール１１は、送信停止要求信号を受け取ったとき、送信停止要求の対象となる送信ＭＢが送信待ちの状態にあれば、送信停止処理を実行するが、送信中の状態にあれば、送信停止処理を実行しない。この場合、ＣＡＮモジュール１１は、送信停止要求信号に対し、否定応答を示す信号を返信する。上記の新たなフレームデータは、優先順格納領域２７に維持されたまま、いずれかの送信ＭＢが空きになるのを待つ。
【００６１】
図９は、図８よりも時間が進んだ状態を表している。送信ＭＢテーブル２９のＭＢ３フィールドがゼロに設定されたことにより、送信制御部１３は、送信ＭＢ３に空きが生じたと判断し、優先順格納領域２７のラベル値２のエントリのデータフィールドに格納されているフレームデータを、送信ＭＢ３に複製することにより設定する（上書き）。送信制御部１３は、優先順格納領域２７のラベル値２のエントリの送信ＭＢフィールドの値を、ゼロから３に更新する。これにより、ラベル値２のフレームデータが、送信ＭＢ３に転送されたことが示される。また、送信制御部１３は、送信ＭＢテーブル２９のＭＢ３フィールドの値をゼロから２に更新する。これにより、送信ＭＢ３には、ラベル値２のフレームデータが設定されたことが示される。
【００６２】
なお、図７〜図９のような送信制御部１３による処理が行われている間も、ＣＡＮモジュール１１は、送信ＭＢ３１のＭＢ１〜ＭＢ３に設定されたフレームデータのＩＤを互いに比較し、ＩＤの優先度の高い順に、対応するバスにデータを送信（出力）する。バスへの出力が完了したならば、送信完了信号を、送信制御部１３に発行する。送信制御部１３は、送信完了となった送信ＭＢに設定されていたフレームデータを、優先順格納領域２７から削除すると共に、受信フラグフィールドの値をゼロにクリアする。また、送信ＭＢテーブル２９の、該送信完了となった送信ＭＢに対応するＭＢフィールドの値をゼロにクリアする。たとえば、送信ＭＢ１のＩＤ１００のフレームデータの出力バスへの送信が完了したならば、ラベル１のエントリ領域のデータフィールドから、ＩＤ１００のフレームデータを削除し、受信フラグフィールドの値をゼロにクリアし、さらに、送信ＭＢテーブル２９のＭＢ１フィールドの値をゼロにクリアする。こうして、ラベル値１のエントリ領域は空となり、送信ＭＢ１も空であることが示される。
【００６３】
このように、送信ＭＢに格納されているデータよりも高い優先度のデータが新たに受信された場合には、送信ＭＢに既に格納されている、より優先度の低いデータが、該受信された新たなデータによって置き換えられる。したがって、低い優先度のデータによって送信ＭＢが占領されているがために高い優先度のデータが待ちになるのを防止し、より早期にバスに出力することができる。結果として、より忠実に優先度に従ったバスへの転送を実現することができる。
【００６４】
また、優先順格納領域２７から送信ＭＢ３１へのフレームデータの転送は複製によって行われ、優先順格納領域２７には、該データが、バスへの出力が完了するまで保持される。したがって、送信ＭＢに対する送信停止処理によって送信停止されたデータは、再度、送信ＭＢに設定されるのを待つことができる。
【００６５】
また、送信制御部１３による優先順送信制御では、優先度の判断を、ラベルを用いて行っており、ＩＤを何ら用いていないため、処理負荷を軽減することができる。従来は、新たに受信したデータのＩＤと、ゲートウェイ装置に既に受信されたデータのＩＤとを比較することにより、いずれのデータの優先度が高いかの判断を行っていた。しかしながら、ＩＤはビット数が多く、比較回数が増えるほど処理負荷が増大するおそれがある。それに対し、ラベルは、ＩＤよりもビット数が少ないので、ラベル値同士の比較処理は、ＩＤ同士の比較に比べて処理負荷が軽い。
【００６６】
また、優先順格納領域２７は、ラベル値の昇順に対応したエントリ番号を持つ配列構造をなしている。したがって、ＦＩＦＯバッファ２５からのデータに付与されたラベル値に基づいて、データを格納すべき領域を、優先順格納領域２７において高速に見極めることができる。仮に、このようなラベル値のエントリ番号を持つ配列構造を用いないとすると、受信したデータのＩＤと、該格納領域２７中に存在するデータのＩＤとを比較しながら、同じＩＤのデータ領域を検索する必要がある。上記のようなラベル値のエントリ番号を持つ配列構造を用いれば、このようなＩＤの比較および検索は不要である。
【００６７】
さらに、優先順格納領域２７から送信ＭＢ３１へのデータの送信は、該優先順格納領域２７に格納されたデータの優先度の高い順に行われるが、該格納領域２７では、ラベル値の昇順に、すなわち優先度の高い順にデータが配列されているので、より高速に、送信すべきデータを見つけることができる。
【００６８】
このように、ラベルを用いることにより、バスへの送信までの時間をより短縮することができる。しかしながら、他の実施形態では、ラベルを用いずに、ＩＤを用いることによって、本願発明の優先順送信制御を実行してもよい。
【００６９】
次に、図１０および図１１を参照して、送信制御部１３による、上記２）の場合の優先順送信制御の動作を説明する。上記２）は、受信したデータのＩＤの優先度と、送信ＭＢ３１のいずれかの送信ＭＢに設定されているデータのＩＤの優先度が、同じである場合を示す。
【００７０】
この例では、ＦＩＦＯバッファ２５に、ラベル値２のフレームデータが受信されている。他方、優先順格納領域２７には、同じラベル値２のフレームデータが既に格納されており、これは、送信ＭＢフィールドの値が３であるように、送信ＭＢ３に現在設定されているデータである。優先順格納領域２７の当該フレームデータは、未だ、バスへの送信が完了していない。送信ＭＢテーブル２９のＭＢ３フィールドの値は２である。
【００７１】
このような場合、送信制御部１３は、ＦＩＦＯバッファ２５から、ラベル値２のフレームデータを読み出して、優先順格納領域２７のラベル値２のエントリ領域を上書きして格納する。これに応じて、該エントリ領域の受信フラグフィールドは値１に維持されるが、送信ＭＢフィールドの値は、ゼロにクリアされる。
【００７２】
さらに、送信制御部１３は、前述したように、送信ＭＢテーブル２９を参照することにより、新たなフレームデータのラベル値２と、送信ＭＢに既に設定されているフレームデータのラベル値１，０，２とを比較することにより、該新たなフレームデータのＩＤと同じＩＤのフレームデータが、送信ＭＢ３に設定されていることを判定する。この判定に応じて、送信制御部１３は、送信ＭＢ３のバスへの送信を停止させる。前述したように、送信ＭＢ３に対して送信停止要求信号を発行し、ＣＡＮモジュール１１は、肯定応答を返すと共に、送信停止処理を実行する。ＣＡＮモジュール１１は、送信停止処理が完了したならば、停止完了信号を送信制御部１３に送る。送信制御部１３は、この停止完了信号を受信したことに応じて、ラベル値２のエントリ領域の送信ＭＢフィールドの値をゼロに更新すると共に、送信ＭＢテーブル２９のＭＢ３フィールドの値をゼロに更新する。
【００７３】
その後、送信制御部１３は、ラベル値２のフレームデータを、優先格納領域２７から送信ＭＢ３に複製して設定（上書き）すると共に、ラベル値２のエントリ領域の送信ＭＢフィールドの値をゼロから３に更新し、また、送信ＭＢテーブル２９のＭＢ３フィールドの値をゼロから２に更新する。
【００７４】
図示していないが、送信ＭＢ３に設定されたラベル値２のフレームデータのバスへの送信が完了したならば、優先順格納領域２７から当該フレームデータを削除すると共に、受信フラグフィールドをゼロにクリアする。送信ＭＢテーブル２９のＭＢ３フィールドもゼロにクリアされる。
【００７５】
このように、送信ＭＢに格納されたのと同じＩＤのフレームデータを受信した場合には、優先順格納領域２７の対応するエントリ領域は上書きされ、該送信ＭＢも、たとえ他に空きの送信ＭＢがあっても（図では、送信ＭＢ２が空きとなっている）、上書きされる。
【００７６】
なお、送信制御部１３からの送信停止要求信号に応じて、ＣＡＮモジュール１１が否定応答を返した場合には、該ラベル値２のフレームデータは、図６〜図９を参照して説明した制御プロセスに従って、いずれかの送信ＭＢに転送されるのを、優先順格納領域２７において待機する。
【００７７】
上記のような上書きを許容する理由について述べると、ＩＤが同じということは、同じ種類のデータを表している。たとえば、エンジン回転数データは、所定の時間間隔で求められるが、これらのデータには、同じＩＤが割り振られる。他方、ＥＣＵによって実施される車両の制御は、よりリアルタイムな制御を実現するため、車両の現在の運転状態に基づいて行われるのが好ましく、そのため、車両の運転状態を表すデータとして、最新のデータを用いて制御を行うのが好ましい。たとえば、エンジン回転数データに基づく何らかの制御を実行するとき、最新のエンジン回転数データを用いるのが好ましい。したがって、古いデータが転送されている間に、新しいデータが該古いデータに追いついた場合には、該新しいデータで古いデータを上書きする。こうすることにより、古いデータの無駄な転送を防止することができると共に、より新しいデータを、ＥＣＵの制御処理に供することができる。
【００７８】
なお、データの種類によっては、このような上書きを許容すべきでないものが存在しうるが、その場合、該上書きを許容しない種類のデータに対しては、上で述べた優先順送信制御とは別の任意の適切な手法によって、バスへの転送を行えばよい。
【００７９】
図１１は、図１０の代替形態を示す図である。図１０と異なる点は、送信ＭＢに空きがある場合には、同じＩＤのフレームデータの送信ＭＢの送信停止の完了を待つことなく、該空きの送信ＭＢにフレームデータを設定する点である。
【００８０】
具体的には、ＦＩＦＯバッファ２５から優先順格納領域２７への格納は、図１０と同様に行われる。その後、送信制御部１３は、前述したように、送信ＭＢテーブル２９を参照することにより、ゼロが設定されたフィールドが存在するかどうか調べると共に、新たなフレームデータのラベル値２と、送信ＭＢ３１に既に設定されているフレームデータのラベル値１，０，２とを比較する。これにより、該新たなフレームデータのＩＤと同じＩＤのフレームデータが、送信ＭＢ３に設定されていると共に、送信ＭＢ２に空きがあることを判定する。これに応じて、送信制御部１３は、同じＩＤのフレームデータを有する送信ＭＢ３に対し、前述したのと同様の手法で、送信停止要求信号を発行する。ＣＡＮモジュール１１は、肯定応答を返すと共に、送信停止処理を実行する。他方、送信制御部１３は、ＣＡＮモジュール１１からの停止完了信号の受信を待つことなく、優先順格納領域２７から、空いている送信ＭＢ２に、ラベル値２のフレームデータを複製して設定すると共に、ラベル値２のエントリ領域の送信ＭＢフィールドを３から２に更新し、送信ＭＢテーブル２９のＭＢ２フィールドを、ゼロから２に更新する。
【００８１】
ＣＡＮモジュール１１は、送信ＭＢ３の送信停止処理が完了したならば、停止完了信号を送信制御部１３に送る。送信制御部１３は、この停止完了信号に応じて、送信ＭＢテーブル２９のＭＢ３フィールドの値を２からゼロに更新する。なお、ラベル値２のエントリ領域の送信ＭＢフィールドの値は、該ラベル値２のフレームデータが送信ＭＢ２に設定されているので、そのまま維持される（ゼロにクリアされない）。
【００８２】
図示していないが、送信ＭＢ２のフレームデータのバスへの送信が完了した時に、ラベル値２のエントリ内のデータは削除されると共に、受信フラグフィールドはゼロにクリアされ、送信ＭＢテーブル２９のＭＢ２フィールドもゼロにクリアされる。
【００８３】
なお、送信ＭＢ３に対する送信停止要求に応じて、否定応答が返された場合には、送信ＭＢ３のデータは、送信停止されることなくそのまま送信され、送信完了に応じて、送信ＭＢテーブル２９のＭＢ３フィールドの値がゼロにクリアされることとなる。その後、送信ＭＢ２に設定されたラベル値２のフレームデータのバスへの送信が完了したならば、優先順格納領域２７から当該フレームデータを削除すると共に、受信フラグフィールドをゼロにクリアする。送信ＭＢテーブル２９のＭＢ２フィールドもゼロにクリアされる。
【００８４】
図１０の形態では、同じＩＤのフレームデータの送信ＭＢへの転送を、ＣＡＮモジュール１１による送信ＭＢの送信停止処理の完了を待ってから、すなわちＣＡＮモジュール１１から停止完了信号を受けた後に行っていたが、図１１の形態では、該送信停止処理の完了を待つ必要がない。ＣＡＮモジュール１１による送信停止処理には所定の時間を要するので、図１１の形態によれば、該フレームデータの送信ＭＢへの転送時間を短縮することができる。
【００８５】
次に、送信制御部１３による、フレームデータがゲートウェイ装置１０内に滞留している時間（滞留時間）を算出する機能について説明する。滞留時間の算出は、上記の優先順送信制御によって、優先度の低いフレームデータが、長期にわたってバスに送信されない状態を防止するために行われる。
【００８６】
一実施例では、タイマ（図示せず）を設け、フレームデータ毎に、該データがゲートウェイ装置１０に滞留している時間を計時する。滞留時間は、フレームデータが、バスに出力されることなくゲートウェイ装置にどの程度留まっているかどうかを判断する指標として計時されるものであるから、このような指標の役割を果たすのであれば、計時を任意の時点から開始することができる。
【００８７】
たとえば、フレームデータがＦＩＦＯバッファ２５から優先順格納領域２７に格納された時点、または、フレームデータが、最初にいずれかの送信ＭＢに設定された時点等を、計時の開始時点とすることができる。タイマは、ソフトウェア（プログラム）によって実現されてもよいし、ハードウェアで実現されてもよい。
【００８８】
こうして計時された滞留時間が所定値を超えても、該フレームデータが優先順格納領域２７から削除されない（すなわち、バスへの送信が完了されない）場合、送信制御部１３は、該フレームデータが設定された送信ＭＢに対しては、送信停止要求信号を発行しない。この場合、受信した新たなフレームデータよりも優先度が低く、かつ、該送信停止したフレームデータの次に優先度の低いフレームデータがいずれかの送信ＭＢに格納されているならば、該送信ＭＢに対して送信停止要求信号を発行する。
【００８９】
たとえば、図８には、前述したように、送信ＭＢ３に対して送信停止要求信号を発行することが示されている。送信制御部１３は、新たなデータのラベル値２と、送信ＭＢテーブル２９に設定されたラベル値１，３，４とを比較し、新たなデータよりも優先度が低く、かつ最も優先度の低いフレームデータを格納する送信ＭＢ３を判定している。滞留時間を用いるこの実施形態では、送信制御部１３は、該判定した送信ＭＢ３に格納されているラベル値４のフレームデータの滞留時間が所定値を超えているかどうかを判断し、超えていなければ、前述したように送信ＭＢ３に対する送信停止要求信号を発行するが、超えているならば、送信ＭＢ３に対する送信停止要求信号の発行を禁止する。送信制御部１３は、上記ラベル値の比較に基づき、新たなデータよりも優先度が低く、かつ送信停止したデータの次に優先度の低い送信ＭＢ（この例では、送信ＭＢ２）を判定し、該次に優先度の低い送信ＭＢ２に対して送信停止要求信号を発行する。こうすることにより、送信ＭＢ３のＩＤ３００のフレームデータを、過渡の遅延を生じさせることなく、出力バスに送信することができる。
【００９０】
代替的に、タイマによる計時を、ラベル値（ＩＤ値）毎に行ってもよい。この場合、フレームデータにラベルが付された時点、フレームデータがＦＩＦＯバッファ２５に受信された時点、ＦＩＦＯバッファ２５から優先順格納領域２７に受信された時点、または、最初に送信ＭＢ３１に設定された時点等を、計時の開始時点とすることができる。なお、この場合、図１０や図１１の形態のように同じＩＤのフレームデータを受信した場合には、同じタイマによって計時されることとなるので、該タイマをリセットして新たに計時を開始するのが好ましい。
【００９１】
他の実施例では、タイマを設ける代わりに、ゲートウェイ装置１０内において何らかの時点でフレームデータに付与されるタイムスタンプを利用して、上記の滞留時間を算出してもよい。たとえば、受信メッセージボックス２１にデータが受信された時点やＦＩＦＯバッファ２５に受信された時点等においてフレームデータにタイムスタンプが付与される場合には、該タイムスタンプを利用することができる。代替的に、送信制御部１３が、フレームデータをＦＩＦＯバッファ２５から優先順格納領域２７に格納した時点や、最初に送信ＭＢに設定された時点において、タイムスタンプを該フレームデータに付与するようにしてもよい。
【００９２】
この場合、たとえば図８の場合には、送信制御部１３は、前述したように、判定した送信ＭＢ３に格納されているラベル値４のフレームデータに付与されたタイムスタンプを参照し、現在の時刻と該タイムスタンプとの間の差を、滞留時間として算出し、該滞留時間が所定値を超えているかどうかを判断する。超えていなければ、前述したように送信ＭＢ３に対する送信停止要求信号を発行するが、超えているならば、送信ＭＢ３に対する送信停止要求信号の発行を禁止する。この場合も同様に、送信制御部１３は、上記ラベル値の比較に基づき、新たなデータよりも優先度が低く、かつ送信停止したデータの次に優先度の低いデータの送信ＭＢ（この例では、送信ＭＢ２）を判定し、該次に優先度の低いデータの送信ＭＢ２に対して送信停止要求信号を発行する。
【００９３】
この実施例における、バスのチャネル毎に設けられる送信ＭＢ（メッセージボックス）の数は、ＭＢ１〜ＭＢ３の３個であり、これは、好ましい個数として選択されている。この理由を、図１２および図１３を参照して説明する。
【００９４】
図１２は、チャネル毎に送信ＭＢを２個（ＭＢ１とＭＢ２）使用する場合の、送信ＭＢからバスへのフレームデータの送信（出力）の一形態を示す図である。
【００９５】
時点ｔ１において、送信ＭＢ１には、ＩＤ１００のフレームデータが既に設定され、送信ＭＢ２には、ＩＤ２００のフレームデータが既に設定されている。
【００９６】
１つのバスには、一時に１つのフレームデータのみを出力することができる。ＩＤ１００は、ＩＤ２００よりも優先度が高いので、時点ｔ１においては、送信ＭＢ１からＩＤ１００のフレームデータのバスへの送信が開始され、送信ＭＢ２のＩＤ２００のフレームデータは、送信待ちの状態にある。
【００９７】
ここで、時点ｔ２において、前述したような送信制御部１３による優先順送信制御によって、送信制御部１３から、送信停止要求信号が送信ＭＢ２に対して発行されたとする。これに応じて、ＣＡＮモジュール１１は、肯定応答を送信制御部１３に返すと共に、送信ＭＢ２の送信待ち状態を解消して、所定の停止処理を実行する。停止処理が完了したならば、ＣＡＮモジュール１１は、停止完了信号を送信制御部１３に返す。送信制御部１３は、該停止完了信号に応じて、時点ｔ３において、ＩＤ１１０のフレームデータの優先順格納領域２７から送信ＭＢ２への送信を開始する。これにより、送信ＭＢ２のＩＤ２００のフレームデータは、上書きされていく。この上書き動作は、時点ｔ５まで継続する。なお、同じビット数のデータについて、上書き動作（設定時間）は、バスへの送信時間よりも短い。
【００９８】
他方、時点ｔ４において、ＩＤ１００のフレームデータのバスへの送信が完了する。送信完了信号が送信制御部１３に送られ、これに応じて、送信制御部１３は、新たなＩＤ２００のフレームデータの送信ＭＢ１への送信を開始する。ＩＤ２００のフレームデータの送信ＭＢ２への設定（上書き）は、時点ｔ６まで継続する。
【００９９】
図から明らかなように、ＩＤ１００のフレームデータのバスへの送信が完了した時点ｔ４では、どちらの送信ＭＢにおいてもデータを設定中であり、バスに送信可能なデータが存在しない。バスへの送信が開始されるのは、送信ＭＢ２にＩＤ１１０のフレームデータの設定を終えた時点ｔ５である。該設定を終えたことに応じて、ＣＡＮモジュール１１は、送信ＭＢ２からバスへのＩＤ１１０のフレームデータの送信を開始する。
【０１００】
時点ｔ６において、ＩＤ２００のフレームデータの送信ＭＢ１への設定が完了する。ＩＤ１１０のフレームデータがバスへ送信されている最中であるので、ＩＤ２００のフレームデータは送信待ちの状態に入る。時点ｔ７において、ＩＤ１１０のフレームデータの送信が完了したことに応じて、ＩＤ２００のフレームデータの送信が開始される。
【０１０１】
図の時点ｔ４〜ｔ５に示すように、使用する送信ＭＢが２個の場合には、送信制御部１３による優先順送信制御によって、両方のＭＢにデータを設定している最中という状態が生じるおそれがあり、よって、バスにデータを連続して送信することができない状態が生じうる。バスは解放状態となり、これは、処理効率の低下につながる。
【０１０２】
図１３は、送信メッセージボックスを３個（ＭＢ１〜ＭＢ３）使用する場合の、送信ＭＢからバスへのフレームデータの送信（出力）の一形態を示す図である。
【０１０３】
時点ｔ１において、送信ＭＢ１には、ＩＤ１００のフレームデータが既に格納され、送信ＭＢ２には、ＩＤ２００のフレームデータが既に格納され、送信ＭＢ３には、ＩＤ３００のフレームデータが既に格納されている。
【０１０４】
ＩＤ１００は、ＩＤ２００およびＩＤ３００よりも優先度が高いので、時点ｔ１においては、送信ＭＢ１からＩＤ１００のフレームデータのバスへの送信が開始され、送信ＭＢ２のＩＤ２００のフレームデータおよび送信ＭＢ３のＩＤ３００のフレームデータは、送信待ちの状態にある。
【０１０５】
ここで、時点ｔ２において、前述したような送信制御部１３による優先順送信制御によって、送信制御部１３から、送信停止要求信号が送信ＭＢ３に対して発行されたとする。これに応じて、ＣＡＮモジュール１１は、この送信停止要求に対して肯定応答を送信制御部１３に返すと共に、送信ＭＢ３の送信待ち状態を解消して、所定の停止処理を実行する。停止処理が完了したならば、ＣＡＮモジュール１１は、停止完了信号を送信制御部１３に返す。送信制御部１３は、該停止完了信号に応じて、時点ｔ３において、ＩＤ１１０のフレームデータの優先順格納領域２７から送信ＭＢ３への送信を開始する。これにより、送信ＭＢ３のＩＤ３００のフレームデータは、上書きされていく。この上書き動作は、時点ｔ５まで継続する。
【０１０６】
他方、時点ｔ４において、ＩＤ１００のフレームデータのバスへの送信が完了する。ＣＡＮモジュール１１は、送信完了に応じて、送信ＭＢ２のＩＤ２００のフレームデータのバスへの送信を速やかに開始する。また、ＩＤ１００のフレームデータの送信完了信号が送信制御部１３に送られ、これに応じて、送信制御部１３は、新たなＩＤ３００のフレームデータの送信ＭＢ１への送信を開始する。ＩＤ３００のフレームデータの送信ＭＢ１への設定（上書き）は、時点ｔ６まで継続する。
【０１０７】
図から明らかなように、ＩＤ１００のフレームデータのバスへの送信が完了した時点ｔ４では、送信ＭＢ３は、優先順送信制御によって新たなフレームデータの設定中であるが、送信ＭＢ２のフレームデータのバスへの送信は、直ちに開始することができる。したがって、優先順送信制御によっていずれかの送信ＭＢが設定中になっても、残りの１つの送信ＭＢからのバスへの送信を連続して実行することができる。
【０１０８】
時点ｔ５において、送信ＭＢ３のＩＤ１１０のフレームデータの設定が完了すると、ＩＤ２００のフレームデータが送信中であるので、送信待ちの状態に入る。また、時点ｔ６において、送信ＭＢ１のＩＤ３００のフレームデータの設定が完了すると、ＩＤ２００のフレームデータがまだ送信中であるので、送信待ちの状態に入る。ＩＤ２００のフレームデータの送信は、時点ｔ７において完了する。送信待ちになっているのは、ＩＤ３００とＩＤ１１０のフレームデータである。ＣＡＮモジュール１１は、ＩＤを比較し、優先度の高い方のフレームデータ、すなわちＩＤ１１０のフレームデータを選択して、これを、バスに送信する。ＩＤ３００のフレームデータの送信待ち状態は、継続される。
【０１０９】
このように、使用する送信ＭＢの数が３個である場合には、いずれかの送信ＭＢが優先順送信制御によって送信待ちの状態から設定中の状態に移行しても、送信待ちとなっている他の送信ＭＢからのフレームデータをバスに送信することができる。したがって、図１２を参照して説明したような、バスが解放された状態が生じず、連続送信を行うことが可能である。このように、送信ＭＢの数は、少なくとも３個設けるのが好ましい。
【０１１０】
他方、使用する送信ＭＢの数を４個以上にしても、上記のような連続送信は可能であるが、この場合、優先順送信制御において、どの送信ＭＢに格納されたデータを置き換えるかを判断するための比較対象が増大するので処理負荷が増大するおそれがある。このような処理負荷は、使用する送信ＭＢの数を増やすほど、増大する。また、ＣＡＮモジュール１１も、バスにデータの送信を開始する際に、最も優先度の高いＩＤのフレームデータを選択するが、この際も、比較対象となるＩＤの数が増大するので、処理負荷が増えるおそれがある。したがって、使用する送信ＭＢの数を３個にとどめるのが、連続送信を可能にしつつ、処理負荷を抑制する観点から好ましい。
【０１１１】
次に、図１４は、送信制御部１３によって実行される、ＦＩＦＯバッファ２５から優先順格納領域２７にフレームデータを受信する制御プロセスのフローチャートである。このプロセスは、たとえば前述したように検索エンジン部２３から割り込み信号を受けたことに応じて開始される。
【０１１２】
ステップＳ１１において、ＦＩＦＯバッファ２５からフレームデータを取得する。前述したように、フレームデータには、ルーティングマップ２４の検索によって取得された、該フレームデータのＩＤに対応するラベルが付与されている。
【０１１３】
ステップＳ１２において、該取得したフレームデータに付与されたラベルを取得する（読む）。ステップＳ１３において、優先順格納領域２７の、取得したラベルに対応するエントリ領域に、該フレームデータを格納する。前述したように、該エントリ領域に既にフレームデータが存在する場合には、該取得したフレームデータで上書きされる。
【０１１４】
ステップＳ１４において、該エントリ領域の受信フラグフィールドの値を１に設定する。ステップＳ１５において、該エントリ領域の送信ＭＢフィールドの値を、ゼロにクリアする。こうして、図７に示すように、新たなフレームデータが格納領域２７に格納される。
【０１１５】
図１５は、送信制御部１３によって実行される、優先順格納領域２７から送信ＭＢ３１にフレームデータを送信する制御プロセスのフローチャートである。該プロセスは、たとえば所定時間間隔で、繰り返し実行される。
【０１１６】
説明をわかりやすくするため、優先順格納領域２７および送信ＭＢ３１のいずれにもデータが格納されていない状況から、該プロセスを辿る。このような状況では、送信ＭＢのいずれにもまだデータが格納されていないので、ステップＳ２１およびＳ２２の判断はＮｏとなり、ステップＳ２５の判断もＮｏとなり、このプロセスを抜ける。
【０１１７】
その後、図１４の受信制御プロセスによって、優先順格納領域２７に新たなフレームデータが格納されたとする。この場合、ステップＳ２５の判断はＹｅｓとなり、ステップＳ２６の判断はＮｏとなる。ステップＳ４１に進むこととなり、ここで、いずれの送信ＭＢ１〜ＭＢ３にも設定されていないデータが格納領域２７に存在するかどうかを判断する。これは、格納領域２７の受信フラグフィールドの値が１であって、送信ＭＢフィールドの値がゼロであるフレームデータが存在するかどうかによって判断されることができる。このようなデータが存在しないときには、送信ＭＢに転送すべきデータが存在しないことを示すので、当該プロセスを抜ける。他方、上のように新たなフレームデータが格納領域２７に格納されたときには、この判断はＹｅｓとなる。
【０１１８】
ステップＳ４２において、格納領域２７に格納されているが、いずれの送信ＭＢ１〜ＭＢ３にも設定されていないフレームデータのうち、最も優先度の高いフレームデータ、すなわち最も小さいラベル値を持つフレームデータを選択して、それを、いずれかの送信ＭＢに設定する（Ｓ２６の判断がＮｏであるので、すべての送信ＭＢ１〜ＭＢ３が空いているため、どの送信ＭＢでもよいが、通常、送信ＭＢ１から使用する）。こうして、上記の新たなフレームデータは、いずれかの送信ＭＢに設定される。
【０１１９】
ステップＳ４３において、フレームデータが設定された送信ＭＢの番号（ＭＢ１に設定されたならば、値１）を、格納領域２７の該フレームデータに対応する送信ＭＢフィールドに設定する（更新）。ステップＳ４４において、送信ＭＢテーブル２９の、該設定された送信ＭＢ番号のフィールドの値を、該設定されたフレームデータのラベル値に更新する。こうして、優先度の高い順に、優先順格納領域２７から送信ＭＢ３１にデータが転送される。前述したように、送信ＭＢに設定されたフレームデータは、ＣＡＮモジュール１１の制御によって、優先度の高い順にバスに出力される。
【０１２０】
その後、いずれかの送信ＭＢ１〜ＭＢ３にデータが格納されている状態で、新たなフレームデータが格納領域２７に受信されると、ステップＳ２５およびＳ２６の判断はＹｅｓとなる。ステップＳ２７において、送信ＭＢ１〜ＭＢ３に設定されたフレームデータのＩＤと同じＩＤのフレームデータが、格納領域２７に存在しているかどうかを判断する。これは、送信ＭＢテーブル２９のＭＢ１〜ＭＢ３フィールドに設定されたラベル値と、格納領域２７の受信フラグの値が１のラベル値とを比較することにより判断することができる。また、存在している場合には、ステップＳ２８において、該存在している判断されたＩＤのフレームデータが、送信ＭＢに未だ設定されていないかどうかを判断する。これは、当該ＩＤの送信ＭＢフィールドの値がゼロかどうかで判断することができる。
【０１２１】
ステップＳ２７またはステップＳ２８の判断がＮｏであれば、送信ＭＢ１〜ＭＢ３に未だ設定されていないＩＤのフレームデータが新たに格納領域２７に存在することを示す。ステップＳ３５において、送信ＭＢテーブル２９のいずれかのフィールドにゼロが設定されているかどうかを判断することにより、３つの送信ＭＢ１〜ＭＢ３のいずれかに空きがあるかどうかを判断する。空きがあれば、ステップＳ４１以下を実行する。すなわち、格納領域２７に受信されているが、送信ＭＢに未だ設定されていないフレームデータを、優先度の高い順に、空いている送信ＭＢに設定する。
【０１２２】
ステップＳ３５において、送信ＭＢ１〜ＭＢ３のいずれにも空きが無ければ、ステップＳ３６〜Ｓ３８において、図８を参照して説明したように、強制的に空きの送信ＭＢを作るための動作を実行する。すなわち、ステップＳ３６において、送信ＭＢ１〜３のいずれかに設定されたフレームデータよりも、優先度の高いフレームデータが格納領域２７に存在するかどうかを調べる。これは、送信ＭＢテーブル２９のラベル値と、格納領域２７の受信フィールドの値が１のラベル値とを比較することにより行うことができる。存在していなければ（Ｓ３６がＮｏ）、送信ＭＢ１〜ＭＢ３に設定されたフレームデータの優先度の方が高いということなので、強制的に空きの送信ＭＢを作ることは行わず、当該プロセスを抜ける。
【０１２３】
存在していれば、ステップＳ３７において、その存在している優先度の高いフレームデータの送信ＭＢフィールドの値がゼロかどうかを調べることにより、そのフレームデータが、いずれの送信ＭＢにも未だ設定されていないかどうかを判断する。設定されていれば（Ｓ３７がＮｏ）、強制的に空きの送信ＭＢを作る必要はないので、当該プロセスを抜ける。
【０１２４】
ステップＳ３６およびＳ３７の判断が両方ともＹｅｓであれば、送信ＭＢ１〜ＭＢ３に設定されているフレームデータよりも優先度の高いフレームデータが、格納領域２７に存在していることを示す。ステップＳ３８において、送信ＭＢテーブル２９を参照し、最も優先度の低い、すなわち最もラベル値の大きい送信ＭＢを選択し、選択した送信ＭＢに対して送信停止要求信号を発行し、その後、当該プロセスを抜ける。
【０１２５】
再び当該プロセスを実行したとき、上記のように送信停止要求信号が発行されているので、ステップＳ２１の判断がＹｅｓとなる。ステップＳ３１において、送信停止が完了したかどうかを判断する。前述したように、ＣＡＮモジュール１１は、送信停止要求信号に応じて肯定応答を返した場合には停止処理を開始し、停止処理が完了したならば、停止完了信号を送信制御部１３に発行する。
【０１２６】
この停止完了信号を受け取るまで、または送信停止要求信号に対して否定応答を受けた場合には、ステップＳ３１の判断はＮｏとなり、よって、ステップＳ２５以下の処理が通常通り行われる。停止完了信号を受信したならば、ステップＳ３１の判断はＹｅｓとなる。
【０１２７】
ステップＳ３２において、前述したように、送信停止の対象となった送信ＭＢのフレームデータについて、格納領域２７における送信ＭＢフィールドの値をゼロにクリアにし、ステップＳ３３において、送信ＭＢテーブル２９の、送信停止が行われた送信ＭＢのラベルの値をゼロにクリアする。こうして、当該フレームデータのバスへの送信が未完了であることを示しつつ、該フレームデータは格納領域２７にそのまま維持される。
【０１２８】
送信停止によって、その送信ＭＢは空きとなるので、ステップＳ３５の判断がＹｅｓとなり、ステップＳ４１以下の処理において、上記の新たなフレームデータは、空きとなった送信ＭＢに設定されることとなる。
【０１２９】
その後、ＣＡＮモジュール１１によって、この送信ＭＢに設定されたフレームデータのバスへの送信が完了したならば、ステップＳ２２の判断がＹｅｓとなり、ステップＳ２３において、送信完了したフレームデータを、格納領域２７から削除すると共に、対応する受信フラグフィールドの値を、１からゼロに更新する。ステップＳ２４において、送信ＭＢテーブル２９の、送信完了した送信ＭＢのラベル値をゼロにクリアする。
【０１３０】
他方、ステップＳ２７およびＳ２８の両方の判断がＹｅｓの場合、すなわち、いずれかの送信ＭＢ１〜ＭＢ３に設定されたＩＤと同じＩＤのフレームデータが格納領域２７に存在し、かつそのフレームデータが未だ送信ＭＢ１〜ＭＢ３に設定されていない場合には、このフローでは、図１０に従って処理される。すなわち、ステップＳ２９において、格納領域２７の当該フレームデータを、同じＩＤのフレームデータが格納されている送信ＭＢに上書き設定するため、その送信ＭＢに対し、送信停止要求信号を発行する。送信停止要求信号を発行した後は、ステップＳ２１、Ｓ３１〜Ｓ３３の処理により、その送信ＭＢが空きにされ、ステップＳ４１以下の処理で、格納領域２７の当該フレームデータで、その空きにされた送信ＭＢが上書きされる。
【０１３１】
前述した滞留時間を用いる実施形態にも、図１４および図１５のプロセスは、同様に適用されることができる。この場合、図１５において、ステップＳ３８において送信停止要求を発行する対象となる、最も優先度の低いフレームデータが格納された送信ＭＢを選択する際に、該データの滞留時間を参照し、これが所定値を超えている場合には、次に優先度の低いフレームデータの送信ＭＢを選択する。こうして選択した送信ＭＢに対し、送信停止要求信号を発行する。
【０１３２】
また、図１１を参照して説明した、同じＩＤのフレームデータを受信した場合の図１０の代替形態についても、図１４および図１５のプロセスは同様に適用されることができる。この場合、空きの送信ＭＢへのデータの設定が、同じＩＤの送信ＭＢの送信停止処理の完了を待つことなく行われる。そのため、ステップＳ２８の判断がＹｅｓになったとき、ステップＳ２９を実行して、同じＩＤのフレームデータが格納されている送信ＭＢの送信停止要求を発行すると共に、いずれかの送信ＭＢ１〜ＭＢ３に空きがあるかどうかを判断する。空きがあれば、ステップＳ４１以下を実行して、その空いている送信ＭＢに、格納領域２７から、当該ＩＤのフレームデータを送信する。その後、該送信停止要求を発行した送信ＭＢについては、ステップＳ３１の判断がＹｅｓになるが、該送信停止した送信ＭＢに格納されていたフレームデータについては、ステップＳ３２は実行されない。前述したように、優先順格納領域２７の該当エントリ領域には、上書きにより新しいデータが既に格納されて該空きの送信ＭＢに設定されており、該エントリ領域の送信ＭＢフィールドには、ステップＳ４３によって該送信ＭＢの番号が既に設定されているからである。
【０１３３】
上記の実施形態は、通信プロトコルとしてＣＡＮを用いているが、本願発明はこれに限定されず、他の通信プロトコルを用いた場合にも適用可能である。
【０１３４】
以上のように、この発明の特定の実施形態について説明したが、本願発明は、これら実施形態に限定されるものではない。
【符号の説明】
【０１３５】
１ａ〜１ｇ  ＥＣＵ
１０  車載ゲートウェイ装置
１１  ＣＡＮモジュール
１２  ルート検索部
１３  送信制御部
２７  優先順格納領域
２９  送信ＭＢテーブル
３１  送信メッセージボックス
【図１】
2010245793.tif 000003
【図２】
2010245793.tif 000004
【図３】
2010245793.tif 000005
【図４】
2010245793.tif 000006
【図５】
2010245793.tif 000007
【図６】
2010245793.tif 000008
【図７】
2010245793.tif 000009
【図８】
2010245793.tif 000010
【図９】
2010245793.tif 000011
【図１０】
2010245793.tif 000012
【図１１】
2010245793.tif 000013
【図１２】
2010245793.tif 000014
【図１３】
2010245793.tif 000015
【図１４】
2010245793.tif 000016
【図１５】
2010245793.tif 000017