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