(57)【要約】【課題】  通信フレームの中継量が多い状況においても限られた時間内に効率よく通信フレームを中継することが可能なゲートウェイ装置を提供する。【解決手段】  複数の制御ユニットが通信線により接続されたネットワークが複数形成され、複数のネットワーク間を接続して通信フレームの受信処理および送信処理を行なう車載ゲートウェイ装置において、通信フレームを受信して通信フレームバッファに格納する受信手段と、受信手段による通信フレームの受信および格納の実処理時間を計測する実受信処理時間計測手段と、実受信処理時間に基づいて送信処理が実行可能である送信処理可能時間を算出する送信処理可能時間算出手段と、を備えることを特徴とするゲートウェイ装置として提供可能である。【選択図】        図４
2006319759.tif 000002
【特許請求の範囲】
【請求項１】
複数の制御ユニットが通信線により接続されたネットワークが複数形成され、前記複数のネットワーク間を接続して通信フレームの受信処理および送信処理を行なうゲートウェイ装置において、
前記通信フレームを受信して通信フレームバッファに格納する受信手段と、
前記受信手段による前記通信フレームの受信および格納の実受信処理時間を計測する実受信処理時間計測手段と、
前記実受信処理時間に基づいて前記送信処理が実行可能である送信処理可能時間を算出する送信処理可能時間算出手段と、
を備えることを特徴とするゲートウェイ装置。
【請求項２】
前記受信処理および前記送信処理は所定の周期で繰り返し実行される請求項１に記載のゲートウェイ装置。
【請求項３】
前記受信処理および前記送信処理は所定制約時間内で行なわれる請求項１または２に記載のゲートウェイ装置。
【請求項４】
前記実受信処理時間計測手段は、前記通信フレームの１フレームあたりの受信および格納の処理時間を基に前記実受信処理時間を算出する請求項１ないし３のいずれか１項に記載のゲートウェイ装置。
【請求項５】
前記送信処理可能時間算出手段は前記所定制約時間から前記実受信処理時間を差し引いたものを前記送信処理可能時間とする請求項１ないし４のいずれか１項に記載のゲートウェイ装置。
【請求項６】
前記実受信処理時間と前記送信処理可能時間との関係を定義したマップデータを有し、
前記送信処理可能時間算出手段は前記マップデータから前記送信処理可能時間を算出する請求項１ないし４のいずれか１項に記載のゲートウェイ装置。
【請求項７】
前記マップデータは前記受信した通信フレーム数と送信可能な通信フレーム数との関係が定義される請求項６に記載のゲートウェイ装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の制御ユニットが通信線により接続されたネットワークが複数形成され、前記複数のネットワーク間を接続して通信フレームの受信処理および送信処理を行なうゲートウェイ装置に関するものである。
【背景技術】
【０００２】
例えば車両において搭載機器を電子的に制御する制御ユニットが多数採用されるにしたがい、その制御ユニット間においてデータを共有化し、各制御ユニットにおいて分散制御や協調制御を行なう要求が高まっている。例えば、車両において、シートやドア等のボディ系、エンジン，電子スロットル等のパワートレイン系、さらにナビゲーション装置，ＶＩＣＳ，ＥＴＣ等のマルチメディア系といった区分けでそれぞれの制御ユニットをネットワーク化し、さらに各ネットワーク間をデータである通信フレームの中継が可能なゲートウェイ装置を介して接続することが検討されている。
【０００３】
このゲートウェイ装置を介して通信フレームを中継する場合、ゲートウェイ装置では通信フレーム中継処理が一定時間ごとに動作し、かつ処理時間に規定がある場合、単位時間内の通信フレームの最大受信量による処理時間を算出し、通信フレーム処理時間から受信処理時間を減算した時間内で、中継する通信フレームの送信可能時間を算出し、通信フレーム中継量を決定している。
【０００４】
【特許文献１】特開２０００−１２４９４１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
図５のように、従来の通信フレーム中継処理では、通信フレーム中継処理が例えば５ｍｓｅｃ周期で動作し、通信フレーム送受信処理時間が例えば０．５ｍｓｅｃと規定されるとすると、データの受信漏れを防ぐためにネットワークの通信量を基に、まず通信フレーム受信処理時間ＴＲｎ，ＴＲｎ＋１が例えば０．３ｍｓｅｃと規定される。そして、通信フレーム送信処理時間ＴＳｎ，ＴＳｎ＋１は通信フレーム送受信処理時間の０．５ｍｓｅｃから通信フレーム受信処理時間ＴＲｎ，ＴＲｎ＋１を差し引いた０．２ｍｓｅｃというように、通信フレームの受信処理送信処理にそれぞれ固定時間枠を割り付けている。
【０００６】
この場合、ｎ回目の周回の通信フレーム送受信処理において、通信フレーム受信量が少なく実際の通信フレーム受信処理時間が０．１ｍｓｅｃ程度と短くても、データ送信処理時間ＴＳｎは０．２ｍｓｅｃのままであるため、送信すべきデータが０．２ｍｓｅｃ分以上あっても、ｎ回目の周回の通信フレーム送受信処理内では送信すべき通信フレームを全て送信することはできない。送信できなかった通信フレームは次のｎ＋１回目の周回の通信フレーム送受信処理で送信しなければならなくなる。
【０００７】
しかし、ｎ＋１回目の周回の通信フレーム送受信処理においても、送信すべき通信フレームが０．２ｍｓｅｃ分以上あると、さらに通信フレーム送信の積み残しが発生してしまう。
【０００８】
このように通信フレームの中継量が少ない状況では、通信フレーム受信から送信までにかかる時間が長くなることはないが、中継通信フレーム量が多い状況では、通信フレームを受信した次の周期の通信フレーム中継処理で、前回の処理で送信できなかった通信フレームを送信しなくてはならず、通信フレーム受信から送信までにかかる時間が延び、その結果、ゲートウェイ装置およびゲートウェイ装置に接続されるネットワークの動作に影響を及ぼすこともあり得る。
【０００９】
上記問題を背景として、本発明の課題は、通信フレームの中継量が多い状況においても限られた時間内に効率よく通信フレームを中継することが可能なゲートウェイ装置を提供することにある。
【課題を解決するための手段および発明の効果】
【００１０】
本発明は、上記課題を解決するためのゲートウェイ装置を提供するものである。即ち、請求項１によれば、複数の制御ユニットが通信線により接続されたネットワークが複数形成され、複数のネットワーク間を接続して通信フレームの受信処理および送信処理を行なうゲートウェイ装置において、通信フレームを受信して通信フレームバッファに格納する受信手段と、受信手段による通信フレームの受信および格納の実受信処理時間を計測する実受信処理時間計測手段と、実受信処理時間に基づいて送信処理が実行可能である送信処理可能時間を算出する送信処理可能時間算出手段と、を備えることを特徴とするゲートウェイ装置として構成される。
【００１１】
図５の従来技術では、受信処理に割り当てられた０．３ｍｓｅｃの処理時間のうち実受信処理時間が０．２ｍｓｅｃであっても残りの０．１ｍｓｅｃは送信処理に転用することはできない。しかし、本発明の構成では、通信フレーム受信量が少ない場合は通信フレーム送信量を増やし、通信フレーム受信量が多い場合は通信フレーム送信量を減らすことができ、効率よく通信フレームを中継することが可能となる。
【００１２】
請求項２によれば、本発明のゲートウェイ装置における受信処理および送信処理は所定の周期で繰り返し実行される構成をとることができる。
【００１３】
一般的に、ゲートウェイ装置の処理は様々な処理が周期的に行なわれることが多く、全体の処理負荷を低減するために、これらの処理の処理時間は短いことが望ましい。本発明は実受信処理時間に基づいて送信処理が実行可能である送信処理可能時間を算出する構成であるため、効率よくデータを中継することができ、所定の周期で繰り返し実行されても全体の処理負荷の増大を抑制することが可能となる。
【００１４】
請求項３によれば、本発明のゲートウェイ装置における受信処理および送信処理は所定制約時間内で繰り返し行なわれる構成をとることができる。
【００１５】
ゲートウェイ装置の処理負荷の面から、通信フレームの中継を行なうための受信処理および送信処理は所定制約時間内で行なわなければならない場合がある。本発明の構成では限られた時間内に効率よく通信フレームを中継することが可能であるため、所定の周期で繰り返し実行されても全体の処理負荷の増大を抑制することが可能となる。
【００１６】
請求項４によれば、本発明のゲートウェイ装置における実受信処理時間計測手段は、通信フレームの１フレームあたりの受信および格納の処理時間を基に実受信処理時間を算出する構成をとることができる。
【００１７】
通信フレームの１フレームあたりの受信処理時間は、フレーム長によって変動はあるものの一定の範囲内にある。上記構成によって、受信処理における全ての通信フレームの受信処理時間を測定する必要がないので、受信処理の処理負荷を低減することが可能となる。
【００１８】
請求項５によれば、本発明のゲートウェイ装置における送信処理可能時間算出手段は所定制約時間から実受信処理時間を差し引いたものを送信処理可能時間とする構成をとることができる。
【００１９】
上記構成によって、通信フレーム受信量が少ない場合は通信フレーム送信量を増やし、通信フレーム受信量が多い場合は通信フレーム送信量を減らすことができ、所定制約時間内に効率よく通信フレームを中継することが可能となる。
【００２０】
請求項６によれば、本発明のゲートウェイ装置は、実受信処理時間と送信処理可能時間との関係を定義したマップデータを有し、送信処理可能時間算出手段はマップデータから送信処理可能時間を算出する構成をとることができる。
【００２１】
上記構成によって、マップデータ参照処理のみによって送信処理可能時間を算出することが可能となり、計算式を用いた演算処理を行なう必要はなくなるので、送信処理可能時間算出処理の処理負荷を低減することが可能となる。
【００２２】
請求項７によれば、本発明のゲートウェイ装置におけるマップデータは受信した通信フレーム数と送信可能な通信フレーム数との関係が定義される構成をとることができる。
【００２３】
通信フレームの１フレームあたりの受信処理時間および送信処理時間はフレーム長によって変動はあるものの一定の範囲内にある。よって、受信処理における全てのフレームの実受信処理時間を時間ではなく受信フレーム数として計測することができる。上記構成によって、通信フレーム受信処理時間を実測あるいは換算する必要もなく、通信フレーム受信処理の処理負荷を低減することが可能となる。さらに、送信処理可能時間もマップデータから送信処理可能フレーム数として算出できるので、計算式を用いた演算処理を行なう必要はなくなるので、送信処理可能時間算出処理の処理負荷を低減することが可能となる。
【００２４】
図４は、本発明の構成の受信処理および送信処理を例えば５ｍｓｅｃの所定の周期で繰り返し実行され、例えば０．５ｍｓｅｃのような一定時間すなわち所定制約時間内で行なう例である。ｎ回目の周回の処理では受信処理の実受信処理時間ＴＲｎは約０．２２ｍｓｅｃである。図５の従来技術では受信処理は０．３ｍｓｅｃの固定時間枠が設定されているため、送信処理は０．２ｍｓｅｃしか割り当てることができないが、図４の本発明の構成では０．２８ｍｓｅｃを送信処理ＴＳｎに割り当てることができるため、従来よりも多くの通信フレームを送信することが可能となる。つまり、従来は０．２ｍｓｅｃを超える分の通信フレームが送信できず、次のｎ＋１回目の周回の処理で送信しなければならなかったが、本発明では０．０８ｍｓｅｃ分の通信フレームを当ｎ回目の周回の処理で送信できるので、ゲートウェイ装置およびゲートウェイ装置に接続されるネットワークの処理効率の向上につながる。
【００２５】
ｎ回目の周回の処理の５ｍｓｅｃ後に実行されるｎ＋１回目の周回の処理では、受信処理の実受信処理時間ＴＲｎ＋１は約０．２５ｍｓｅｃであるため、通信フレーム送信処理時間ＴＳｎ＋１として従来よりもさらに０．０５ｍｓｅｃを使用することができ、より多くのフレームを送信することができる。
【００２６】
同様に、ｎ＋１回目の周回の処理の５ｍｓｅｃ後に実行されるｎ＋２回目の周回の処理では、受信処理の実受信処理時間ＴＲｎ＋２は約０．１７ｍｓｅｃであるため、通信フレーム送信処理時間ＴＳｎ＋２として０．３３ｍｓｅｃを使用でき、従来よりも約１．５倍のフレームを送信することができる。
【００２７】
なお、通信バスの通信速度や通信フレームの最小／最大長といった物理的制約と、ゲートウェイ装置の処理構成によって決められる例えば５ｍｓ周期の処理タイミングといった時間的制約とから、最大実受信処理時間を例えば０．３ｍｓｅｃのように設定することができる。そして、送受信処理の合計時間は、理論上最大時間の受信処理が連続して発生した場合でも、その周回の処理で少なくとも1フレームの通信フレームを送信できるように、例えば０．５ｍｓのように設定されている。
【発明を実施するための最良の形態】
【００２８】
中継データ量が多い状況においても限られた時間内に効率よくデータを中継することが可能なゲートウェイ装置を提供するという目的を、データ受信量が少ないタイミングではデータ送信量を増やし、データ受信量が多いタイミングではデータ送信量を減らすといった動的に処理量を可変とする構成により実現した。
【実施例】
【００２９】
以下、本発明の実施の形態を、本発明のゲートウェイ装置を車両に適用した一例をもとに説明する。なお、本発明のゲートウェイ装置の適用範囲を車両に限定するものではなく、例えばネットワーク通信機器にも適用可能である。
【００３０】
図１は、本発明のゲートウェイ装置および周辺ネットワークの構成の全体構成を示すブロック図である。車両の搭載機器を電子的に制御する各種の制御ユニットがネットワークを形成し、通信バス、さらにはゲートウェイ装置を介して相互に接続されている。
【００３１】
図１の例では、通信バス−１にボディ系のネットワークが構成され、ドアロックを制御するＥＣＵ−Ａ，シートの位置を調整するＥＣＵ−Ｂが接続されている。また、通信バス−２にパワートレイン系のネットワークが構成され、エンジンを制御するＥＣＵ−Ｃ，変速機を制御するＥＣＵ−Ｄ，ブレーキを制御するＥＣＵ−Ｅが接続されている。
【００３２】
図２のように、ゲートウェイ装置１０は、通信バス−１，通信バス−２がそれぞれ接続される本発明の受信手段である第１通信Ｉ／Ｆ１６，第２通信Ｉ／Ｆ１７と、通信バス−１および通信バス−２間のデータ伝送を制御するＭＰＵ１１とを備え、ゲートウェイ装置１０で行なう各種処理をＭＰＵ１１で実行する。本発明の受信処理時間計測手段，送信処理可能時間算出手段であるＭＰＵ１１には、データ伝送処理を含む各種処理の実行時に使用するデータまたはプログラムなどが記憶されるＲＡＭ１２、フラッシュメモリ１３およびＲＯＭ１４が接続されている。
【００３３】
ＲＯＭ１４には、例えば、ゲートウェイ装置１０で行なう各種処理を実行するためのメインプログラム１４ｐ、およびゲートウェイ装置１０の機器番号などの機器識別情報１４ｂが記憶されている。フラッシュメモリ１３には、例えば、ゲートウェイ装置１０で行なう各種処理を実行するための処理プログラム１３ｐが記憶されている。ＭＰＵ１１は、ＲＯＭ１４に記憶されているメインプログラム１４ｐを実行すると共に、フラッシュメモリ１３から必要な処理プログラム１３ｐを読出して実行する。フラッシュメモリ１３に記憶されている処理プログラムは、ＭＰＵ１１により、更新することが可能である。更新処理は、例えばインストルメントパネルに設けられたスイッチ等の入力操作部（図示せず）によって実施する。
【００３４】
各種処理の実行に必要なデータは、ＭＰＵ１１により、ＲＡＭ１２、フラッシュメモリ１３、およびＲＯＭ１４から読み出される。また、処理結果は、ＭＰＵ１１により、ＲＡＭ１２またはフラッシュメモリ１３に記憶される。例えば、ＥＣＵ−Ａ〜ＥＣＵ−Ｅのアドレスを含むアドレステーブルがＲＡＭ１２に記憶され、データの転送をブロックする送信元および／または送信先などのフィルタリングポリシがフラッシュメモリ１３に記憶される。ＭＰＵ１１は、前記アドレステーブルおよびフィルタリングポリシを参照して、通信フレーム中継処理を行なう。なお、ＲＡＭ１２を使用せずにフラッシュメモリ１３のみを使用することも可能である。
【００３５】
通信バス−１，通信バス−２で用いる通信プロトコルは、公知のトークンパッシング方式，ＣＳＭＡ／ＣＤ（Carrier  Sense  Multiple  Access  with  Collision  Detection：衝突検出型搬送波検知多重アクセス）方式やＴＤＭＡ（Time  Division  Multiple  Access：時分割多元接続）方式等、公知の各種プロトコルを採用してもよい。また、各ネットワークで異なる通信プロトコルを採用することも可能である。第１通信Ｉ／Ｆ１６，第２通信Ｉ／Ｆ１７は、それぞれのネットワークの通信プロトコルに対応した周知の通信ＬＳＩ１６ａ，１７ａ等を含む回路構成となっている。
【００３６】
通信バス１あるいは２からの通信フレームの受信は以下の（１）あるいは（２）の少なくとも一方を用いて行なう。
（１）通信バス１あるいは２から受信した通信フレームを、通信Ｉ／Ｆ１６，第２通信Ｉ／Ｆ１７に含まれてＲＡＭ等で構成されるバッファ１６ｂ，１７ｂに蓄積する。受信した通信フレームを各バッファに蓄積する方法は、通信ＬＳＩ１６ａ，１７ａから通信フレームを各バッファに直接転送する方法、通信Ｉ／Ｆ１６，１７の全体制御を行なう図示しないＣＰＵにより動作する制御プログラムにより通信ＬＳＩ１６ａ，１７ａから通信フレームをバッファ１６ｂ，１７ｂに転送する方法のいずれを用いてもよい。
（２）通信バス１あるいは２から受信した通信フレームを、メインプログラム１４ｐに含まれる通信ドライバプログラムにより、通信Ｉ／Ｆ１６あるいは第２通信Ｉ／Ｆ１７から取り込んでＲＡＭ１２に領域が確保されるバッファ１２ａに蓄積する。
なお、通信バス１あるいは２から通信フレームを受信した場合には、通信フレームを受信した旨を示す通信フレーム受信フラグをセットする。通信フレーム受信フラグは通信フレーム毎に領域が確保される。
【００３７】
なお、接続される通信バスの数には制約はなく、パワートレイン系，ボディ系のネットワークの他に、マルチメディア系、およびエアバック等のセイフティ系のネットワークを構成に含めてもよい。この場合、これら追加されるネットワークの通信プロトコルに対応した通信Ｉ／Ｆも追加される。
【００３８】
図６のように、通信フレームは、ヘッダーフィールドとデータフィールドを有し、データフィールドにはデータ本体が書き込まれている。ヘッダーフィールドには、ＥＣＵ−Ａ〜ＥＣＵ−Ｅの機器識別情報であったり、車両速度やエンジン回転数といった通信フレームの意味合いを示したりするＩＤと、データ本体の長さを示すデータレングスコード（ＤＬＣ）とが含まれる。
【００３９】
上記のような構成により、ゲートウェイ装置１０は、通信バス−１から第１通信Ｉ／Ｆ１６により受信した通信フレームをフレームバッファに格納し、第２通信Ｉ／Ｆ１７を介して通信バス−２へ送信すなわち中継する。例えば、ＥＣＵ−Ａからの通信フレームをＥＣＵ−Ｃ〜ＥＣＵ−Ｅに中継する。また、ＥＣＵ−Ａからの通信フレームを同じ通信バス−１に接続されるＥＣＵ−Ｂに中継してもよい。逆に、通信バス−２に接続されるＥＣＵ−Ｅからの通信フレームを通信バス−１に接続されるＥＣＵ−Ａ，ＥＣＵ−Ｂに中継する。同様に、ＥＣＵ−Ｅからの通信フレームを同じ通信バス−１に接続されるＥＣＵ−Ｃに中継してもよい。
【００４０】
図３にゲートウェイ装置１０のＲＯＭ１４に記憶され、ＭＰＵ１１で実行されるメインプログラム１４ｐに含まれるメイン処理のフロー図を示す。メイン処理は例えば５ｍｓｅｃ周期のような一定周期で実行される。タイマ等によりメイン処理の起動タイミングを生成し、メイン処理の起動タイミングとなった場合（Ｓ１：Ｙｅｓ）には、メイン処理として、例えば通信フレーム送受信処理以外の他処理（Ｓ２），通信フレーム受信処理（Ｓ３），通信フレーム送信処理（Ｓ４）の順に実行される。
【００４１】
図８に、図３のステップＳ３で示される通信フレーム受信処理の詳細を説明するフロー図を示す。まず、今回のデータ受信処理で受信する通信フレームのフレーム数を計数する受信フレームカウンタを初期化すなわちゼロクリアする（Ｓ１１）。
【００４２】
通信フレームを受信した場合、すなわちバッファ１６ｂ，１７ｂあるいはバッファ１２ａに通信フレームが蓄積されている場合（Ｓ１２：Ｙｅｓ）、受信した通信フレームを通信フレームのＩＤ毎にＲＡＭ１２に領域が確保されるフレームバッファに格納する（Ｓ１３）。そして、該当する通信フレーム受信フラグをクリアする。このとき、バッファ１６ｂ，１７ｂあるいはバッファ１２ａの内容をゼロクリアしてもよい。
【００４３】
図７にフレームバッファの一例を示す。フレームバッファの構成は、以下の（１）〜（４）のうちのいずれを用いてもよい。
（１）データ領域の領域番号が通信フレームのＩＤに対応する。すなわち、ＤＡＴＡ０には通信フレームのＩＤが０のデータ本体の内容が、ＤＡＴＡｎには通信フレームのＩＤがｎのデータ本体の内容が全て格納される。
（２）受信した通信フレームを例えば１バイト毎に分割してデータ領域に格納する。例えば、通信フレームのデータ本体が８バイトならば、図７のデータ領域のｍは７となり、データ領域の０から７に１バイトずつ格納される。この場合フラグ領域は一つでもよい。つまり、フレームバッファはＩＤ毎に領域が確保される。
（３）受信した通信フレームを送信先の通信フレームの書式に変換してデータ領域に格納する。送信する通信フレームのＩＤ毎に一括して格納しても１バイトずつ分割して格納してもよい。
（４）通信フレームのＩＤ毎にフレームバッファを確保するのではなく、通信フレームの受信順に中継処理を行なうのに適した周知のＦＩＦＯ（First-In,First-Out：先入れ・先出し方式）バッファ、あるいは通信フレームの受信順とは逆の順序で中継処理を行なうのに適した周知のＬＩＦＯ（Last-In,First-Out：後入れ・先出し方式）バッファを用いてもよい。この場合、通信フレームのＩＤとデータの両方を格納する。
【００４４】
受信した通信フレームをフレームバッファに格納したら、該当するフラグ領域の内容を受信データ有すなわち送信要求有を示す１とするとともに、受信フレームカウンタをインクリメントする（Ｓ１４）。そして、バッファ１６ｂ，１７ｂあるいはバッファ１２ａに蓄積されている全ての通信フレームを取り出したら（Ｓ１５：Ｎｏ）、送信可能な通信フレーム数を算出する（Ｓ１６）。
【００４５】
なお、受信した通信フレームを全てフレームバッファに格納したかどうかの判定は、バッファ１６ｂ，１７ｂあるいはバッファ１２ａに内に蓄積されている全ての通信フレームを取り込んだ場合、すなわち上述の通信フレーム受信フラグが全てクリアされた状態であれば、受信した通信フレームを全てフレームバッファに格納したと判定する。なお、フレームバッファに格納時にバッファ１６ｂ，１７ｂあるいはバッファ１２ａの内容をゼロクリアする場合は、バッファ１６ｂ，１７ｂあるいはバッファ１２ａの内容が全てゼロクリアされた状態であれば通信フレームを全てフレームバッファに格納したと判定してもよい。
【００４６】
受信した通信フレーム数と送信可能な通信フレーム数には所定の関係があり、ＲＯＭ１４，ＲＡＭ１２あるいはフラッシュメモリ１３に図１０のようなマップデータとして記憶されている。通信フレームの１フレームあたりの受信処理時間はＭＰＵ１１および通信Ｉ／Ｆ１６，１７等の周辺回路の性能によって予め求めることができる。その通信フレームの１フレームあたりの受信処理時間に受信した通信フレーム数を乗じたものが実受信処理時間とすることができる。よって、通信フレームの送信処理が可能な時間は、図４のように０．５ｍｓｅｃのような所定制約時間から実受信処理時間を減じたものとなる。ここで、１フレームあたりの送信処理時間もＭＰＵ１１の性能によって予め求めることができるので、通信フレームの送信処理可能時間を通信フレームの送信可能個数に置き換えることができる。また、受信した通信フレーム数と送信可能な通信フレーム数をマップデータとして記憶することで、演算処理時間を短縮することが可能となる。よって、マップデータを参照して受信した通信フレーム数から送信可能な通信フレーム数を求めることができる。
【００４７】
図９に、図３のステップＳ４で示される通信フレーム送信処理の詳細を説明するフロー図を示す。ポインタの内容が示すフレームバッファのフラグ領域すなわち送信要求フラグを参照し、送信要求があるかどうかを調べる。フラグ領域の内容が１で送信要求がある場合（Ｓ２１：Ｙｅｓ）、当該データ領域に記憶されている通信フレームを送信する（Ｓ２２）。そして、フラグ領域の内容をゼロクリアして（Ｓ２３）、送信可能フレーム数をデクリメントする（Ｓ２４）。
【００４８】
次いで、ポインタの内容をインクリメントして次のフレームバッファの位置とし（Ｓ２５）、送信可能フレーム数がゼロなるまで、ステップＳ２１〜Ｓ２５までの処理を繰り返す。一方、送信要求がない場合（Ｓ２１：Ｎｏ）は、ポインタの内容をインクリメントして次のフレームバッファの送信要求の有無を調べる（Ｓ２５→Ｓ２１）。
【００４９】
ポインタは、フレームバッファに格納されるデータＩＤの示すデータ本体あるいは個別のデータのうちで、送信待ちのフレームバッファの位置すなわちアドレスを示している。ポインタの初期値はフレームバッファの先頭アドレスで、ポインタの内容がフレームバッファの末尾アドレスのときにインクリメントされる場合はフレームバッファの先頭アドレスに戻る。
【００５０】
フレームバッファとしてＦＩＦＯあるいはＬＩＦＯを用いる場合は、ポインタが示すフレームバッファに送信要求がないときは、以降のフレームバッファにデータが格納されていないので、ポインタの内容をフレームバッファの先頭アドレスに戻してもよい。
【００５１】
送信要求の有無を判別する方法として、上述のポインタを用いる方法の他に、以下に説明する送信キューを用いてもよい。通信フレームをフレームバッファに格納する際、受信データ有すなわち送信要求有のフラグをセットする代わりに、そのＩＤによって示されるフレームバッファの位置（１，２，・・・，ｎ，・・・ｍ）情報を、ＲＡＭ１２に領域が確保されるＦＩＦＯ方式の送信キューに格納するとともに、送信キューカウンタをインクリメントする。送信キューカウンタの最大値はｍである。例えば、送信キューカウンタ値が１の場合は、既に送信キューが１個格納されているので、送信キューの２番目の領域にフレームバッファの位置情報が格納され、送信キューカウンタ値は２に更新される。
【００５２】
通信フレーム送信処理の際には、まず送信キューカウンタの値を参照し、値がゼロでなければ送信キュー領域の先頭の内容を参照し、格納されているフレームバッファの位置情報に基づいて通信フレームを送信する。そして、送信キューカウンタをデクリメントし、送信キューの内容を送信キュー領域の先頭方向へ１個分シフトする。例えば、送信キューカウンタ値が３すなわち送信キューが３個ある場合は、送信キューの１番目の領域の内容に対応する通信フレームを送信した後、送信キューカウンタ値を２とし、送信キューの２番目の領域の内容を送信キューの１番目の領域に移動し、送信キューの３番目の領域の内容を送信キューの２番目の領域に移動する。このとき、送信キューの３番目の領域をゼロクリアしてもよい。送信キューを用いると、フレームバッファ全体について送信要求の有無を調べる必要がなく、フレーム送信を効率よく行なうことが可能となる。
【００５３】
また、送信キューとして静的に１番目，２番目といった上記のような送信順ＦＩＦＯのデータ構造ではなく、周知のリングバッファ構造やリスト構造を用いてもよい。この場合、次に送信すべきフレームバッファの位置情報が格納される送信キューの位置の情報を、送信キューとは別領域に確保されるポインタとして持つ。そして、送信キューカウンタがゼロでない、すなわち未中継の通信フレームがある場合には、そのポインタに対応する送信キューに格納されたフレームバッファの位置情報に基づいて通信フレームを送信した後、ポインタを更新する。この際、リングバッファ構成であればポインタをインクリメントして次のる送信キューの位置とする。なお、ポインタ値が送信キューすなわちリングバッファの末尾まで達したら、先頭のバッファ位置にセットする。リスト構造であればポインタ値はそのデータ構造内で次の送信キューが含まれるリスト位置となる。いずれの構造であっても、フェールセーフとして、送信キューがない場合には、ポインタをバッファあるいはリストの先頭位置である初期値にすることもある。
【００５４】
送信要求のないフレームバッファが連続すると、送信要求の有無の判定のみで通信フレーム送信処理の時間の限度を超えてしまうことがある。この場合は、ＭＰＵ１１の性能からステップＳ２１：Ｎｏ→Ｓ２５→Ｓ２６までの送信要求なし時の処理時間を予め求めることができ、例えば「送信要求なし時の処理時間×３＝送信要求あり時の処理時間」というような関係を定義できるので、ステップＳ２１：ＮｏとＳ２５との間に、以下のような処理を追加すればよい。
（１）送信要求なし発生カウンタをインクリメント。
（２）送信要求なし発生カウンタが例えば３のような所定値となった場合は、送信可能フレーム数をデクリメントして、送信要求なし発生カウンタをゼロクリア。
【００５５】
ＲＯＭ１４，ＲＡＭ１２あるいはフラッシュメモリ１３に通信フレームの１フレームあたりの受信処理時間を予め記憶しておき、全通信フレームを受信した後に受信フレームカウンタと１フレームあたりの受信処理時間との積を実受信処理時間とし、所定制約時間の０．５ｍｓｅｃから実受信処理時間を差し引いたものを送信処理可能時間としてもよい。そして、通信フレーム送信処理において、通信フレームを１個送る毎に、送信処理可能時間から１フレームあたりの送信処理時間を減じ、減じた値が１フレームあたりの送信処理時間の値よりも大きい場合は次の通信フレームを送信する。
【００５６】
また、実受信処理時間と送信処理可能時間の関係をマップデータとして記憶し、上記のように算出した実受信処理時間を基にマップデータから送信処理可能時間を求めてもよい。
【００５７】
また、ＭＰＵ１１にはＭＰＵ１１内部の基準時間を生成するためのフリーランカウンタが内蔵されているので、通信フレームの受信処理終了時（Ｓ１６）のフリーランカウンタ値から通信フレームの受信処理開始時（Ｓ１１）のフリーランカウンタ値を差し引いたものを、実受信処理時間としてもよい。そして、所定制約時間の０．５ｍｓｅｃから実受信処理時間を差し引いたものを送信処理可能時間としてもよい。そして、通信フレーム送信処理において、通信フレームを送信したときのフリーランカウンタ値から、通信フレーム送信処理開始時のフリーランカウンタ値を差し引いた値が、１フレームあたりの送信処理時間に相当するフリーランカウンタ値よりも大きい場合は次の通信フレームの送信を行なう。
【００５８】
以上、本発明の実施の形態を説明したが、これらはあくまで例示にすぎず、本発明はこれらに限定されるものではなく、特許請求の範囲の趣旨を逸脱しない限りにおいて、当業者の知識に基づく種々の変更が可能である。
【図面の簡単な説明】
【００５９】
【図１】ゲートウェイ装置および周辺ネットワークの構成を示すブロック図。
【図２】ゲートウェイ装置の構成を示すブロック図。
【図３】メイン処理の概略を説明するフロー図。
【図４】本発明による通信フレーム受信処理と通信フレーム送信処理の時間配分を示す図。
【図５】従来技術によるによる通信フレーム受信処理と通信フレーム送信処理の時間配分を示す図。
【図６】通信フレームのデータ構成の一例を示す図。
【図７】フレームバッファの構成の一例を示す図。
【図８】通信フレーム受信処理を説明するフロー図。
【図９】通信フレーム送信処理を説明するフロー図。
【図１０】マップデータの構成の一例を示す図。
【符号の説明】
【００６０】
１０  ゲートウェイ装置
１１  ＭＰＵ（受信処理時間計測手段，送信処理可能時間算出手段）
１２  ＲＡＭ
１３  フラッシュメモリ
１４  ＲＯＭ
１６  第１通信Ｉ／Ｆ（受信手段）
１７  第２通信Ｉ／Ｆ（受信手段）
【図１】
2006319759.tif 000003
【図２】
2006319759.tif 000004
【図３】
2006319759.tif 000005
【図４】
2006319759.tif 000006
【図５】
2006319759.tif 000007
【図６】
2006319759.tif 000008
【図７】
2006319759.tif 000009
【図８】
2006319759.tif 000010
【図９】
2006319759.tif 000011
【図１０】
2006319759.tif 000012