(57)【要約】【課題】      ゲートウエイ装置で接続されるネットワーク間のメッセージの混雑状況を把握することを可能にするゲートウエイ装置を提供する。【解決手段】  複数のデバイスＥＣＵがそれぞれ接続される複数のネットワークＢＵＳ−１，２間に設けられ，ネットワーク間のメッセージＭＥＳを転送するゲートウエイ装置において，送信元ネットワークＢＵＳ−１から受信したメッセージＭＥＳを順次送信先ネットワークＢＵＳ−２に送信する転送制御手段ＴＣＯＮと，メッセージの受信と送信に関する転送履歴情報を記憶する転送履歴記憶手段ＬＯＧとを有する。そして，転送履歴記憶手段ＬＯＧに記憶された転送履歴情報が外部から読み出し可能である。ゲートウエイ装置がメッセージの転送履歴情報を記憶し，外部から読み出し可能に構成されているので，ネットワーク間のメッセージの混雑状況を把握することができ，混雑度を緩和する改良に役立てることができる。【選択図】    図２
2006191339.tif 000002
【特許請求の範囲】
【請求項１】
複数のデバイスがそれぞれ接続される複数のネットワーク間に設けられ，前記ネットワーク間のメッセージを転送するゲートウエイ装置において，
送信元ネットワークから受信したメッセージを順次送信先ネットワークに送信する転送制御手段と，
前記メッセージの受信と送信に関する転送履歴情報を記憶する転送履歴記憶手段とを有し，
当該転送履歴記憶手段に記憶された転送履歴情報が外部から読み出し可能であることを特徴とするゲートウエイ装置。
【請求項２】
請求項１において，
前記メッセージには，前記ネットワーク内の送信権の優先順位を規定した識別子が付加され，前記転送制御手段は，前記識別子に対応する送信周期で受信したメッセージを前記送信先ネットワークに送信し，前記転送履歴記憶手段は，前記識別子毎に前記転送履歴情報を記憶し，当該識別子に対応する前記転送履歴情報が外部に読み出し可能であることを特徴とするゲートウエイ装置。
【請求項３】
請求項１または２において，
前記転送履歴情報は，前記メッセージの受信時間と送信時間，受信から送信までの時間，受信後送信待ちメッセージ数，受信後送信待ちメッセージ数が所定数を超えたか否かの滞留情報，または受信後複数回送信されたか否かの送信異常情報のうち，少なくとも一つを含むことを特徴とするゲートウエイ装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、バス間のメッセージ転送を行うゲートウエイ装置に関し、特に、ＣＡＮ（Controller Area Network）バス間のメッセージ転送の遅延履歴を記憶することができるゲ
ートウエイ装置に関する。
【背景技術】
【０００２】
ＣＡＮは，ＩＳＯで国際的に標準化されたシリアル通信プロトコルであり，主に，自動車のハードウエアを制御するＥＣＵ（Electric Control Unit）間を接続する車内ＬＡＮ
の通信プロトコルとして広く使用されている。また，最近においては，ＣＡＮの高い性能と信頼性から，用途は自動車からファクトリ・オートメーション，船舶，医療機器，産業機器など多方面に拡がっている。ＣＡＮについて，例えば，以下の非特許文献１，２に記載されている。また，車内ＬＡＮによる車両用制御システムについて，例えば，以下の特許文献１，２に記載されている。
【非特許文献１】「ＣＡＮ入門書」www.renesas.com
【非特許文献２】「ＣＡＮとは？」www.toyo.co.jp/car/CAN/CAN_General.htm
【特許文献１】特開２００４−１３６８１６
【特許文献２】特開２００４−１７６７６  上記非特許文献１には，複数のＥＣＵがＣＡＮにより接続され，更に，複数のＣＡＮがゲートウエイ装置を介して接続された車内ネットワークシステムが記載されている。例えば，エンジンやトランスミッションを制御するＥＣＵを接続するエンジン系のＣＡＮと，ＶＩＣＳナビなどを制御するＥＣＵを接続する情報系のＣＡＮとが，ゲートウエイ装置を介して接続され，情報系からのメッセージに応じて，エンジン系の制御に反映させることが考えられる。また，上記非特許文献１には，故障診断系のＣＡＮとエンジン系のＣＡＮとがゲートウエイ装置を介して接続され，例えば，故障診断系のＣＡＮの診断ツールから，エンジン系ＣＡＮのエンジン制御ＥＣＵに対して，診断のための制御を可能にすることが考えられる。
【０００３】
このように，ゲートウエイ装置は，異なるＣＡＮバス間のプロトコルの翻訳を行うと共に，一方のＣＡＮバス内のＥＣＵから送信されたメッセージを他方のＣＡＮバス内のＥＣＵに転送する。ＣＡＮの仕様によれば，後述するとおり，メッセージにはバス内の送信権の優先順位を示す識別子が付加され，同時に送信されたメッセージ間の送信権の調停は，この識別子により行われる。一方，ゲートウエイ装置は，一方のバスから受信したメッセージを他方のバスに送信する場合，原則として受信した順番に送信先バスに送信する。また，優先順位を規定する識別子に対応する送信周期で，受信したメッセージを送信先バスに送信する。このように，重要で緊急性を要するメッセージとそれ以外のメッセージとを識別子で区別して，それぞれのメッセージに対応した緊急度でメッセージが転送されるようにされている。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
近年における複数のＣＡＮバスをゲートウエイ装置で中継するネットワークシステムは，より多くのメッセージを転送することにより，より高度の制御を可能にすることが行われる傾向にある。このように，より多くのメッセージがゲートウエイ装置を介してバス間を転送されることに伴い，ゲートウエイ装置での転送遅延がネットワークシステムのパフォーマンスに深刻な影響を与えるようになることが予想される。ゲートウエイ装置での転送遅延の解析は，ネットワーク内のメッセージの混雑状況の把握には欠かせない事項であるが，従来のゲートウエイ装置には，そのような混雑状況を把握する機能が設けられていない。
【０００５】
そこで，本発明の目的は，ゲートウエイ装置で接続されるネットワーク間のメッセージの混雑状況を把握することを可能にするゲートウエイ装置を提供することにある。
【課題を解決するための手段】
【０００６】
上記の目的を達成するために，本発明の第１の側面では，複数のデバイスがそれぞれ接続される複数のネットワーク間に設けられ，前記ネットワーク間のメッセージを転送するゲートウエイ装置において，送信元ネットワークから受信したメッセージを順次送信先ネットワークに送信する転送制御手段と，前記メッセージの受信と送信に関する転送履歴情報を記憶する転送履歴記憶手段とを有し，当該転送履歴記憶手段に記憶された転送履歴情報が外部から読み出し可能であることを特徴とする。
【０００７】
上記の第１の側面において，好ましい実施例によれば，前記メッセージには，前記ネットワーク内の送信権の優先順位を規定した識別子が付加され，前記転送制御手段は，前記識別子に対応する送信周期で受信したメッセージを前記送信先ネットワークに送信し，前記転送履歴記憶手段は，前記識別子毎に前記転送履歴情報を記憶し，当該識別子に対応する前記転送履歴情報が外部に読み出し可能であることを特徴とする。
【０００８】
上記の第１の側面において，更に好ましい実施例によれば，前記転送履歴情報は，前記メッセージの受信時間と送信時間，受信から送信までの時間，受信後送信待ちメッセージ数，受信後送信待ちメッセージ数が所定数を超えたか否かの滞留情報，または受信後複数回送信されたか否かの送信異常情報のうち，少なくとも一つを含むことを特徴とする。
【発明の効果】
【０００９】
上記の第１の側面によれば，ゲートウエイ装置がメッセージの転送履歴情報を記憶し，外部から読み出し可能に構成されているので，ネットワーク間のメッセージの混雑状況を把握することができ，混雑度を緩和する改良に役立てることができる。
【００１０】
更に，好ましい実施例によれば，識別子毎に転送履歴情報を記憶するので，どの識別子のメッセージに転送時の滞留が生じているかを容易に把握することができ，メッセージの混雑状況の把握に役立てることができる。
【発明を実施するための最良の形態】
【００１１】
以下、図面にしたがって本発明の実施の形態について説明する。但し、本発明の技術的範囲はこれらの実施の形態に限定されず、特許請求の範囲に記載された事項とその均等物まで及ぶものである。
【００１２】
図１は，本実施の形態におけるゲートウエイ装置の構成とメッセージの転送動作を示す図である。図１には，ＣＡＮである第１のバスＢＵＳ−１と第２のバスＢＵＳ−２との間に，バス間でメッセージ転送を行うゲートウエイユニット１０が設けられている。第１のバスＢＵＳ−１には，２つのデバイスＥＣＵ−１，ＥＣＵ−２と，ゲートウエイユニット１０が接続され，第２のバスＢＵＳ−２には，２つのデバイスＥＣＵ−３，ＥＣＯＵ−４と，ゲートウエイユニット１０が接続される。第１及び第２のバスＢＵＳ−１，２は，それぞれ個別のネットワークを構成し，それぞれのプロトコルでネットワーク内のデバイス間でメッセージがやりとりされる。また，各デバイスＥＣＵは，図示しないハードウエアの状態を監視し制御する。そして，ゲートウエイユニット１０は，異なるネットワーク間でプロトコルの翻訳とメッセージの転送を行う。
【００１３】
ゲートウエイユニット１０には，第１のバスＢＵＳ−１から第２のバスＢＵＳ−２にメッセージを転送するための，受信バッファＲ−ＢＵＦと，転送コントローラＴＣＯＮと，
転送すべき受信メッセージを格納する転送キューバッファＴ−ＱＵＥとを有する。この転送キューバッファＴ−ＱＵＥは，転送すべき受信メッセージ群を転送順に格納する待ち行列である。同様に，逆方向にメッセージを転送するための同様の構成も有する。そして，一方のバスに接続されているデバイスＥＣＵから送信されたメッセージＭＥＳ１が，ゲートウエイユニット１０により他方のバスに接続されているデバイスＥＣＵに転送される。
【００１４】
ＣＡＮプロトコルの特徴は，（１）バスが空いていれば全てのデバイス（ＥＣＵ）がメッセージを送信することができるマルチマスタ方式と，（２）全てのデバイスはメッセージを同時に受信し，受信すべきデバイスがメッセージを受信するマルチキャスト方式と，（３）ネットワーク内のデバイスにはアドレスは割り付けられず，メッセージの内容若しくは種類は，メッセージに対応付けられたネットワーク内で固有の識別子（ＩＤ）により定義され，送信メッセージにはこのＩＤが付加され，受信デバイスが受信すべきＩＤのメッセージを自発的に受信するネットワークのフレキシブル性（したがって，このＩＤにより送信元と受信先のデバイスが特定される）と，（４）メッセージに付加されるＩＤがネットワーク上での送信権の優先順位も定義し，複数のデバイスが同時にメッセージを送信しようとすると，優先順位の高いＩＤのメッセージが優先され送信権を取得し，優先順位の低いＩＤのメッセージは送信を中止する衝突回避方法である。
【００１５】
そこで，以下，第１のバスＢＵＳ−１のデバイスＥＣＵ−１が第２のバスＢＵＳ−２のデバイスＥＣＵ−３にメッセージＭＥＳ１を送信する場合を例にして，その送信動作を説明する。まず，デバイスＥＣＵ−１は，第１のバスＢＵＳ−１がアイドル状態の時にメッセージＭＥＳ１をバスに送信する。メッセージＭＥＳ１は，簡単にいえば，メッセージの種類を示す識別子ＩＤが付加され，数バイトのデータＤＡＴＡを含むフレームで構成される。そして，第１のバスＢＵＳ−１での送信権は，第１に，アイドル中のバスにメッセージフレームを先に出力したデバイスに与えられ，第２に，同時にメッセージフレームが出力された時は，メッセージに付加される識別子ＩＤに固有に与えられている優先順位が高いほうのメッセージを出力したデバイスに与えられる。つまり，全ての識別子ＩＤは異なる優先順位を有し，デバイスＥＣＵ−１，ＥＣＵ−２が同時にメッセージＭＥＳ１，ＭＥＳ２をバスに出力した場合は，その識別子ＩＤの優先順位により送信権が決定され，優先順位の高い識別子ＩＤを有するメッセージＭＥＳ１の送信が継続され，優先順位の低い識別子ＩＤを有するメッセージＭＥＳ２の送信が停止される。
【００１６】
この識別子ＩＤによる送信権の決定アルゴリズムは，ＣＡＮバスでは，識別子ＩＤを出力したときのバスの状態を監視することにより行われる。すなわち，バスのレベルには，ドミナントレベル（優先的なレベル）とレセシブレベル（受容的なレベル）とを有し，論理的にワイヤードアンドされたバスの場合は，ドミナントレベルの論理値は「０」，レセシブレベルの論理値は「１」となる。そして，１つのデバイスでもドミナントレベル「０」を出力するとバスはドミナントレベル「０」になり，全てのデバイスがレセシブレベル「１」を出力しないとバスはレセシブレベル「１」にならない。さらに，識別子ＩＤは，例えば１６進法で「０００」〜「ＦＦＦ」が割り当てられる。その結果，識別子「０００」が最も優先順位が高く，「ＦＦＦ」が最も優先順位が低くなる。
【００１７】
つまり，複数のデバイスが同時にメッセージフレームを出力すると，フレームの先頭に位置するアービトレーションフィールドの識別子ＩＤのデータ列が同時にバスに出力される。そのため，最も優先順位の高い識別子ＩＤのデータ列のレベルにバスのレベルが制御される。そこで，各デバイスはアービトレーションフィールドの各ビットにおけるバスのレベルを監視することにより，送信権を取得できなかったか否かを検出することができる。例えば，最も優先順位が高い識別子「０００」の場合は，１６ビット全てにおいてバスをドミナントレベル（論理「０」）にすることができ，それ以外の識別子のメッセージを出力しようとするデバイスは，バスの状態が自らが出力した識別子の状態とは異なること
を検出する。その結果，デバイスは，送信権を取得できなかったことを検出することができ，そのメッセージの送信を停止することができる。一方，１６ビット全てにおいて送信権が取得できなかったことを検出する場合は，そのデバイスは，通信権を取得したことになり，そのメッセージの送信を継続する。これにより，複数のメッセージフレームのデータフィールドが同時にバスに出力されることが防止され，衝突を回避することができる。
【００１８】
図１に戻り，デバイスＥＣＵ−１がメッセージＭＥＳ１を出力しようとする時に，同時にデバイスＥＣＵ−２がメッセージＭＥＳ２を出力しても，メッセージＭＥＳ１の識別子ＩＤがより高い優先順位を有していれば，デバイスＥＣＵ−２はメッセージＭＥＳ２の出力を停止し，結局，デバイスＥＣＵ−１だけがメッセージＭＥＳ１をバスＢＵＳ−１に出力することができる。もちろん，デバイスＥＣＵ−１が先にメッセージＭＥＳ１の出力を開始した場合は，他のデバイスＥＣＵ−２はメッセージの出力を開始しない。
【００１９】
そして，バスＢＵＳ−１に出力されたメッセージＭＥＳ１は，ゲートウエイユニット１０の受信バッファＲ−ＢＵＦに格納される。ゲートウエイユニット１０には，第２のバスＢＵＳ−２に転送すべき識別子があらかじめ設定されており，その設定された識別子のメッセージのみを受信バッファＲ−ＢＵＦに格納する。
【００２０】
ゲートウエイユニット１０内の転送コントローラＴＣＯＮは，受信したメッセージＭＥＳ１を，転送キューバッファＴ−ＱＵＥの最後尾に格納すると共に，所定の送信周期毎に転送キューバッファＴ−ＱＵＥ内に格納された受信済みメッセージを，受信順に，第２のバスＢＵＳ−２に出力する。第２のバスＢＵＳ−２においても，第１のバスＢＵＳ−１内でのアービトレーション方法と同様の方法で，送信権のアービトレーションが行われる。そして，第２のバスＢＵＳ−２に送信されたメッセージＭＥＳ１は，そのメッセージを受信すべきデバイスＥＣＵ−３が受信する。すなわち，第２のバスＢＵＳ−２に接続されるデバイスＥＣＵ−３，ＥＣＵ−４は，どの識別子のメッセージを受信すべきかがあらかじめ設定されており，その設定された識別子のメッセージＭＥＳ１を，バス上に出力されるメッセージから判別し，該当する場合にはそれを受信する。
【００２１】
第２のバスＢＵＳ−２に接続されたデバイスから第１のバスＢＵＳ−１に接続されたデバイスへのメッセージの送信も，上記と同様に，バス上でのアービトレーションと，ゲートウエイユニット１０での転送制御とにより行われる。
【００２２】
このように，通常メッセージは，ゲートウエイユニット１０において，受信順に転送キューバッファＴ−ＱＵＥに格納され，受信順に送信先ネットワークのバスに転送される。
【００２３】
図２は，本実施の形態におけるゲートウエイユニットとの詳細構成を示す図である。図３には，一例として，デバイスＥＣＵ−１，ＥＣＵ−２が送信するメッセージの識別子リストＬ１，Ｌ２と，デバイスＥＣＵ−３，ＥＣＵ−４が受信するメッセージの識別子リストＬ３，Ｌ４とが示される。このように，各デバイスは，送信する識別リストと受信する識別リストとがあらかじめ設定されている。例えば，デバイスＥＣＵ−１が，識別子「００１」を付加したメッセージを送信すると，ゲートウエイユニット１０を介してデバイスＥＣＵ−３が受信する。同様に，デバイスＥＣＵ−２が，識別子「００２」を付加したメッセージを送信すると，ゲートウエイユニット１０を介してデバイスＥＣＵ−３が受信する。このように，送信されるメッセージには，送信先アドレスではなく，送信元と送信先が特定され且つバス内の送信権の優先順位を示す識別子が付与される。
【００２４】
更に，ゲートウエイユニット１０には，受信バッファＲ−Ｂｕｆに受信すべきメッセージの識別子があらかじめ設定され，第１のバスＢＵＳ−１に送出されたメッセージの識別子を監視し，受信すべきメッセージを受信バッファＲ−Ｂｕｆに受信する。受信バッファ
Ｒ−Ｂｕｆに受信されたメッセージは一旦共有メモリ１２内のメッセージ格納領域に格納される。転送コントローラＴＣＯＮは，受信したメッセージの識別子ＩＤをチェックし，送信キューバッファＴ−ＱＵＥ内に識別子ＩＤ毎に個別に設けられている送信キューバッファＱ１〜Ｑｎのうち，対応する送信キューバッファＱ１〜Ｑｎの最後尾に，受信メッセージを格納する。
【００２５】
図２に示された例では，デバイスＥＣＵ−１が送信したメッセージＭＥＳ１（識別子「００１」，転送経路は破線）は，第１のバスＢＵＳ−１に送出され，ゲートウエイユニット１０の受信バッファＲ−Ｂｕｆに取り込まれ，共有メモリ１２のメッセージ領域に一時的に格納された後，識別子ＩＤに対応する送信キューバッファＱ１の最後尾に格納される。同様に，デバイスＥＣＵ−２が送信したメッセージＭＥＳ２（識別子「００４」，転送経路は一点鎖線）も，第１のバスＢＵＳ−１に送出され，ゲートウエイユニット１０の受信バッファＲ−Ｂｕｆに取り込まれ，共有メモリ１２のメッセージ領域に一時的に格納され，その後，転送コントローラＴＣＯＮにより，識別子「００４」に対応する送信キューバッファＱｎの最後尾に格納される。
【００２６】
そして，転送コントローラＴＣＯＮは，それぞれの識別子に対応する送信周期で，送信キューバッファ内の先頭のメッセージを，送信先ネットワークである第２のバスＢＵＳ−２に送出する。また，送信先ネットワークである第２のバスＢＵＳ−２での送信権の調停は，メッセージに付加されている識別子の優先順位に応じて決定される。更に，第２のバスＢＵＳ−２に送信されたメッセージは，そのバス内のデバイスＥＣＵ３，４により，受信すべきメッセージを検出され，取り込まれる。
【００２７】
このように，各バス内では，識別子の優先順位により，優先順位の高いメッセージが優先して送出され，ゲートウエイユニット１０では，識別子に対応する送信周期毎に，各識別子に対応する送信キューバッファＱ１〜Ｑｎの先頭のメッセージが送信先バスに送出される。したがって，優先順位のより高いメッセージが優先してバス内またはバス間を転送されるようになっている。そのために，ゲートウエイユニット１０では，識別子毎に送信キューバッファＱ１〜Ｑｎを別々に設け，それぞれの送信キューバッファＱ１〜Ｑｎに受信したメッセージを格納する。そして，識別子に対応する送信周期で，その識別子に対応する送信キューバッファの先頭のメッセージが送信先バスに送信される。
【００２８】
本実施の形態では，ゲートウエイユニット１０の共有メモリ１２内には，メッセージ領域に加えて，メッセージの転送履歴を格納する転送履歴領域ＬＯＧが設けられている。そして，転送コントローラＴＣＯＮは，受信バッファＲ−Ｂｕｆにメッセージが受信されると，その受信時間を転送履歴領域ＬＯＧに格納し，送信キューバッファから送信先のバスにメッセージが送信されると，その送信時間を転送ログ領域ＬＯＧに格納する。または，転送コントローラＴＣＯＮは，受信から送信までの転送時間をメッセージ毎に識別子ＩＤ別に転送ログ領域ＬＯＧに格納する。もしくは，後述するとおり，転送コントローラＴＣＯＮは，転送履歴領域ＬＯＧに，受信済みで且つ未送信のメッセージの数を格納しても良い。または，転送コントローラＴＣＯＮは，転送履歴領域ＬＯＧに，受信済み且つ未送信のメッセージの数が所定の数以上になったときに滞留フラグを格納してもよい。さらに，転送コントローラＴＣＯＮは，受信済みメッセージが不必要に複数回送信先バスに送出された場合に，転送履歴領域ＬＯＧに転送異常フラグを格納しても良い。このように，転送履歴情報として，最も単純には，全てのメッセージの受信時間と送信時間の情報や転送に要した時間の情報が，あるいは，ゲートウエイユニット１０内に滞留しているメッセージの数の情報が，または，滞留時間の情報が，更に，必要以上に受信メッセージを送信した場合の転送異常の情報が，転送履歴領域ＬＯＧに格納される。
【００２９】
そして，この転送履歴領域ＬＯＧ内の転送履歴情報が，ログインターフェース手段ＬＯ
Ｇ−ＩＦを介して，ゲートウエイユニット１０の外部から読み出し可能に構成されている。つまり，複数のネットワークであるバスをゲートウエイ装置で転送するネットワークシステムにおいて，何らかの故障が発生した場合に，ネットワーク間のメッセージの転送状況をゲートウエイユニット１０内の転送履歴を読み出して，ゲートウエイユニット内でのメッセージの滞留状況を分析することで，故障の原因を見出すことが容易にできるようになる。
【００３０】
更に，この転送履歴をチェックすることにより，特定の識別子のメッセージがゲートウエイユニット１０内で著しい滞留を生じていることが判明した場合は，当該識別子のメッセージの送信先バスへの転送周期をより短く再設定するなどの手段を講じることで，故障の再発生を回避することができる。
【００３１】
転送履歴領域ＬＯＧ内の転送履歴情報の外部からの読み出しは，図２に示したログインターフェースＬＯＧ−ＩＦを介して行われるが，具体的には，例えば，外部の故障診断ツールなどからログインターフェースＬＯＧ−ＩＦを介して転送コントローラＴＣＯＮに割り込み命令を入力し，転送コントローラＴＣＯＮから転送履歴領域ＬＯＧ内の転送履歴情報を読み出させ，外部のツールに出力させることで実現することができる。つまり，マイクロコンピュータのデバッグツールと同様の構成により，外部から読み出し可能な構成にすることができる。
【００３２】
図３は，本実施の形態における転送履歴領域の一例を示す図である。この例では，転送履歴領域ＬＯＧには，識別子ＩＤに対応して，その識別子を付加されたメッセージがゲートウエイユニット１０に受信された時間と，送信先バスに送信された時間とが転送履歴として記録される。図３には，識別子ＩＤ＝０００とＩＤ＝ＮＮＮの受信時間及び送信時間からなる転送履歴情報が記録されている。識別子ＩＤ＝０００のメッセージについて，３つのメッセージが受信され，そのうち１つのメッセージのみが送信されたことが記録されている。また，識別子ＩＤ＝ＮＮＮのメッセージについては，４つのメッセージが受信され，全て送信されたことが記録されている。したがって，この転送履歴を外部から読み出して分析することにより，各識別子ＩＤに対応して，メッセージがどのように転送され，ゲートウエイユニット内でどのように滞留していたかを知ることができる。単純には，受信時間と送信時間との差を計算すればメッセージのゲートウエイユニット内での滞留時間を知ることができる。また，受信時間と送信時間とから，ゲートウエイユニット内でのメッセージの滞留の様子を詳細に知ることができる。
【００３３】
図４は，図３の転送履歴を利用して得られたゲートウエイユニット内でのメッセージの滞留の様子を示す図である。横軸に時間ｔ，縦軸に滞留メッセージ数（破線が滞留メッセージ数＝０）を示し，（１）は識別子ＩＤ＝０００の場合，（２）は識別子ＩＤ＝ＮＮＮの場合の滞留の様子を示す。図４（１）によれば，受信時間LL:LL:LL:LLに受信したメッ
セージ（受信１）は，送信時間MM:MM:MM:MMに送信され（送信１），受信時間NN:NN:NN:NNとPP:PP:PP:PPとに受信したメッセージ（受信２，３）は，未だ送信されていない。つま
り，受信３の時点でゲートウエイユニット内には２つのメッセージが滞留していたことと，最初のメッセージの転送時間を知ることができる。また，図４（２）によれば，受信時間LL:LL:LL:LLに受信したメッセージ（受信１）は，その後送信時間MM：MM;MM:MMに送信
され（送信１），受信時間NN:NN:NN:NN，PP:PP:PP:PPに連続して受信した２つのメッセージ（受信２，３）は，送信時間OO:OO:OO:OOにその一方が送信され（送信２），受信時間RR:RR:RR:RRに更にメッセージを受信した後（受信４），送信時間QQ:QQ:QQ:QQとSS:SS:SS:SSとに連続してメッセージが送信された（送信３，４）ことが分析できる。図４（２）の例では，識別子ID=NNNのメッセージ群は，最大で２個のメッセージがゲートウエイユニット内に滞留したこと，各メッセージの転送時間などを知ることができる。
【００３４】
このように，図３に示したように，各識別子に対応して全てのメッセージの受信時間と送信時間の履歴を記録することにより，その転送履歴を外部から読み出して分析することで，その識別子のメッセージがゲートウエイユニット内で滞留しがちであり，その識別子のメッセージがスムーズに転送されているかを分析することができる。
【００３５】
なお，それぞれの時間は，年月日と時間・分・秒・マイクロ秒とが含まれることが好ましい。但し，転送履歴領域ＬＯＧの容量には一定の限界があるので，転送履歴として保持されるメッセージの数は所定数に限定される必要があり，その場合は，古い転送履歴は消去される。
【００３６】
図５は，本実施の形態における転送履歴領域の他の例を示す図である。図３に示した転送履歴情報は，全てのメッセージの受信時間と送信時間を有するものであり，ゲートウエイユニット１０内の共有メモリ１２に所定の大容量の記憶領域を必要とする。ゲートウエイユニット１０は，転送コントローラＴＣＯＮを構成するＣＰＵやプログラムＲＯＭと，共有メモリ１２や送信キューバッファＴ−ＱＵＥなどを有するマイクロコンピュータで構成される。したがって，共有メモリ１２の記憶容量をそれほど大きくすることができない場合がある。そこで，図５の例では，ゲートウエイユニット内に滞留しているメッセージの数を監視するための滞留カウンタを設け，転送履歴情報として，滞留フラグと転送異常フラグとが転送履歴領域ＬＯＧ内に格納される。
【００３７】
図５に示されるとおり，識別子ＩＤ（０００〜ＦＦＦ）それぞれに対して，滞留カウンタが設けられる。この滞留カウンタは，メッセージを受信すると＋１され，メッセージを送信すると−１される。したがって，滞留カウンタ内には現在ゲートウエイユニットの送信キューバッファ内に滞留しているメッセージの数が維持される。そこで，この滞留カウンタが所定の限界値を超えた場合は過剰に滞留が生じていることを示す滞留フラグが「１」に変更される。また，滞留カウンタが負の値になった場合は送信以上が生じていることを示す転送異常フラグが「１」に変更される。
【００３８】
図６は，ある識別子のメッセージの滞留の様子を示す図である。図４と同様に，横軸に時間を縦軸に滞留メッセージ数，つまり滞留カウンタ値を示す。この例には，ある識別子のメッセージの受信と送信とに対応して，滞留メッセージ数を示す滞留カウンタのカウント値の変化の推移が示されている。つまり，滞留カウンタは，受信があれば＋１され，送信があれば−１されるので，受信頻度に対して送信頻度が追いつかない場合は，受信４以降に示されるとおりカウント値が＋２〜＋７と増大する。そこで，このカウント値が所定の基準値Ｖｔｈ（カウント値＋５）を超えた時に転送コントローラ１２が滞留フラグを「１」にするようにする。
【００３９】
逆に，受信頻度に対して送信頻度が高くなり，受信数を送信数が超えることになると，不必要なメッセージの送信を行っていることになる。その場合は，図示しないが滞留カウンタが負のカウント値をとることになるので，滞留カウンタが負のカウント値になった時に転送コントローラ１２が転送異常フラグを「１」にするようにする。
【００４０】
このように，ゲートウエイユニット内で転送するメッセージの滞留数を監視し，基準値を超えたときは滞留フラグをオンにし，負になったときは転送異常フラグをオンにし，そのフラグ情報のみを記録するようにする。そして，外部から転送コントローラ１２を介して滞留フラグや転送異常フラグを読み出し可能にすることで，その識別子のメッセージに滞留が発生したかや，転送異常が発生したかを検出することができる。また，記憶すべき情報は，識別子ＩＤ毎のフラグ情報のみであるので，転送履歴領域ＬＯＧのメモリ容量を小さく抑えることができる。
【００４１】
図５の例では，滞留カウンタを設けて，メッセージの滞留数を監視するようにした。しかし，滞留数の監視は，例えば，ＦＩＦＯ構成の送信キューバッファＴ−ＱＵＥの書き込みポインタと読み出しポインタの差を逐次演算することでも実現可能である。つまり，メッセージの受信や送信のイベントが発生するたびに，ＦＩＦＯ制御のために上記ポインタの制御が行われる。その時に，ポインタの差分を演算することで，その時の滞留メッセージの数を求めることができる。そして，その数が所定の閾値Ｖｔｈを超えている場合に，滞留フラグをオンさせるようにしても良い。
【００４２】
転送コントローラＴＣＯＮは，転送履歴に対応して，ゲートウエイユニット内でのメッセージの滞留状態を改善するように制御することができるのが望ましい。そのために，転送コントローラＴＣＯＮは，例えば，滞留フラグがオンになった識別子を監視し，その識別子に対応する送信キューバッファの送信周期を短くするよう変更制御する。または，滞留フラグがオンになった識別子のメッセージ群については，先頭の所定数のメッセージを強制的に破棄するような制御をすることでもよい。
【００４３】
以上説明したとおり，本実施の形態によれば，ゲートウエイ装置１０内でのメッセージの転送履歴情報を記憶するようにしたので，何らかの故障が発生した時の故障診断に利用することができ，故障診断の質を高めることができる。
【図面の簡単な説明】
【００４４】
【図１】本実施の形態におけるゲートウエイ装置の構成とメッセージの転送動作を示す図である。
【図２】本実施の形態におけるゲートウエイユニットの詳細構成を示す図である。
【図３】本実施の形態における転送履歴領域の一例を示す図である。
【図４】図３の転送履歴を利用して得られたゲートウエイユニット内でのメッセージの滞留の様子を示す図である。
【図５】本実施の形態における転送履歴領域の他の例を示す図である。
【図６】ある識別子のメッセージの滞留の様子を示す図である。
【符号の説明】
【００４５】
ＥＣＵ１〜４：デバイス，    ＢＵＳ−１，２：ＣＡＮバス（ネットワーク）
１０：ゲートウエイ装置（ゲートウエイユニット）
１２：共有メモリ（メッセージ格納領域ＭＥＳ，転送履歴領域ＬＯＧ）
ＴＣＯＮ：転送コントローラ（転送制御手段）
Ｔ−ＱＵＥ：送信キューバッファ    ＭＥＳ１，２：メッセージ
【図１】
2006191339.tif 000003
【図２】
2006191339.tif 000004
【図３】
2006191339.tif 000005
【図４】
2006191339.tif 000006
【図５】
2006191339.tif 000007
【図６】
2006191339.tif 000008