複数のネットワーク間のデータ中継を行うゲートウェイ装置であって、前記ネットワークの少なくとも1つは、当該ネットワークに接続された送信元装置から異なるネットワークに接続された送信先装置に対して要求メッセージが送信された場合、当該要求メッセージを送信してから規定時間以内に前記要求メッセージに応答する応答メッセージが受信されないと前記送信元装置がタイムアウトするように規定されており、前記送信元装置から前記送信先装置への要求メッセージを受信すると、当該要求メッセージを前記送信先装置へ中継するとともに、前記規定時間を延長して待機するように指示する待機要求コードを前記要求メッセージの送信元装置へ送信する待機要求送信手段を備えたことを特徴とするゲートウェイ装置。前記データ中継に異常があったか否かを判定する異常判定手段と、前記異常判定手段により前記データ中継に異常があったと判定された場合、前記データ中継に異常があったことを前記送信元装置へ通知する通知手段と、を備えたことを特徴とする請求項1に記載のゲートウェイ装置。前記要求メッセージ、前記応答メッセージおよび前記待機要求コードの少なくとも1つの中継履歴を学習し、当該中継履歴の学習結果を記憶媒体に記憶させる中継履歴学習手段と、前記記憶媒体に記憶された中継履歴の学習結果に基づいて前記待機要求コードを送信する必要があるか否かを判定する待機要求コード送信判定手段と、を備え、前記待機要求送信手段は、前記待機要求コード送信判定手段により前記待機要求コードを送信する必要があると判定された場合に、前記待機要求コードを前記要求メッセージの送信元装置へ送信することを特徴とする請求項1または2に記載のゲートウェイ装置。前記要求メッセージを中継してから前記応答メッセージを受信するまでの時間を計測する計測手段を備え、前記中継履歴学習手段は、前記要求メッセージを中継してから前記応答メッセージを受信するまでの時間を前記応答メッセージの中継履歴として学習することを特徴とする請求項3に記載のゲートウェイ装置。上記したようなネットワークに接続された装置間のデータの授受においては、データの送信要求を行ってから規格時間が経過しても応答が得られない場合、タイムアウトして処理を終了するように通信プロトコルで規定されている。例えば、CAN通信プロトコルにおけるダイアグ通信では、診断ツールからゲートウェイ装置を介して診断対象の制御装置に対して要求メッセージを送信してから、この診断対象の制御装置から規定時間100ミリ秒以内に要求メッセージに応答する応答メッセージが受信されないと、診断ツールは診断対象の制御装置が要求メッセージを受信できなかったものと判断するようになっている。しかし、近年、通信プロトコルの多様化に伴ってプロトコル変換を行うゲートウェイの数が増加し、ネットワーク構成が複雑化してきており、例えば、複数のゲートウェイを介して要求メッセージおよび応答メッセージが中継されるようになってきている。このようにネットワーク構成が複雑になると、通信プロトコルに規定されているタイムアウトの期間内に応答メッセージを受信することが困難になってしまう。そこで、従来、診断ツールでは、タイムアウトの期間を超過しないように、各車両のネットワーク構成を考慮した上で、診断装置側で、診断対象の制御装置毎、車両毎に必要に応じてタイムアウトの期間を個別に延長するようにしている。しかし、このような構成では、ネットワークに接続される機器のバリエーションが多くなってしまうといった問題が生じる。また、診断対象の制御装置についても、高い処理能力が要求されるといった問題もある。本発明は上記問題に鑑みたもので、ネットワークに接続される機器でタイムアウトの期間を個別に延長することなく、タイムアウトによる応答メッセージの取りこぼしを防止することを目的とする。上記目的を達成するため、請求項1に記載の発明は、複数のネットワーク間のデータ中継を行うゲートウェイ装置であって、前記ネットワークの少なくとも1つは、当該ネットワークに接続された送信元装置から異なるネットワークに接続された送信先装置に対して要求メッセージが送信された場合、当該要求メッセージを送信してから規定時間以内に前記要求メッセージに応答する応答メッセージが受信されないと送信元装置がタイムアウトするように規定されており、前記送信元装置から前記送信先装置への要求メッセージを受信すると、当該要求メッセージを前記送信先装置へ中継するとともに、前記規定時間を延長して待機するように指示する待機要求コードを前記要求メッセージの送信元装置へ送信する待機要求送信手段を備えたことを特徴としている。このような構成によれば、送信元装置から前記送信先装置への要求メッセージを受信すると、当該要求メッセージを前記送信先装置へ中継するとともに、前記規定時間を延長して待機するように指示する待機要求コードが前記要求メッセージの送信元装置へ送信されるので、ネットワークに接続される機器でタイムアウトの期間を個別に延長することなく、タイムアウトによる応答メッセージの取りこぼしを防止することができる。また、請求項2に記載の発明は、データ中継に異常があったか否かを判定する異常判定手段と、前記異常判定手段により前記データ中継に異常があったと判定された場合、前記データ中継に異常があったことを前記送信元装置へ通知する通知手段と、を備えたことを特徴としている。このような構成によれば、データ中継に異常があったと判定された場合、前記データ中継に異常があったことが前記送信元装置へ通知されるので、送信元装置はデータ中継に異常があったことを認識することができる。また、請求項3に記載の発明は、前記要求メッセージ、前記応答メッセージおよび前記待機要求コードの少なくとも1つの中継履歴を学習し、当該中継履歴の学習結果を記憶媒体に記憶させる中継履歴学習手段と、前記記憶媒体に記憶された中継履歴の学習結果に基づいて前記待機要求コードを送信する必要があるか否かを判定する待機要求コード送信判定手段と、を備え、前記待機要求送信手段は、前記待機要求コード送信判定手段により前記待機要求コードを送信する必要があると判定された場合に、前記待機要求コードを前記要求メッセージの送信元装置へ送信することを特徴としている。このような構成によれば、要求メッセージ、前記応答メッセージおよび前記待機要求コードの少なくとも1つの中継履歴を学習し、当該中継履歴の学習結果を記憶媒体に記憶させ、記憶媒体に記憶された中継履歴の学習結果に基づいて前記待機要求コードを送信する必要があるか否かを判定し、待機要求コードを送信する必要があると判定された場合に、前記待機要求コードを前記要求メッセージの送信元装置へ送信するので、例えば、待機要求コードを送信する必要もないのに待機要求コードを送信元装置へ送信して応答性を低下させてしまうといったことを防止することができる。また、請求項4に記載の発明のように、要求メッセージを中継してから前記応答メッセージを受信するまでの時間を計測し、要求メッセージを中継してから前記応答メッセージを受信するまでの時間を前記応答メッセージの中継履歴として学習することもできる。本発明の一実施形態に係るゲートウェイ装置を用いて構成された車載用LANシステムの例を図1に示す。車載用LANシステムは、ゲートウェイ装置1a、1b、ECU3a、3b、4a、4b、5a、5cおよびバスA、B、Cにより構成されている。バスAには、ECU3a、3bおよび診断ツール2が接続され、バスBには、ECU4a、4bが接続され、バスCには、ECU5a、5bが接続されている。また、バスAに接続されたネットワーク、バスBに接続されたネットワーク、バスCに接続されたネットワークとで、通信プロトコルが異なっている。本実施形態では、バスAの通信プロトコルはCAN通信プロトコル、バスBの通信プロトコルはCAN通信プロトコル、バスCの通信プロトコルはFlexRay通信プロトコルとなっている。ゲートウェイ装置1a、1bは、それぞれ、CPU、ROM、RAM、LANコントローラいずれも図示せずを備えている。CPUは、ROMに記憶されたプログラムに従って各種処理を実施する。ゲートウェイ装置1aとゲートウェイ装置1bは同一構成となっている。LANコントローラは、各バスA~Cの各通信プロトコルに規定されたデータフォーマットに従ってデータの送受信を行う。ゲートウェイ装置1aは、バスAの通信プロトコルとバスBの通信プロトコルのプロトコル変換を行ってデータの中継を行い、ゲートウェイ装置1bは、バスBの通信プロトコルとバスCの通信プロトコルのプロトコル変換を行ってデータの中継を行う。また、バスAには、各ECUから故障診断等のための各種情報を収集する診断ツール2が接続されている。CAN通信プロトコルでは、ネットワークに接続された送信元装置、例えば、診断ツール2から異なるネットワークに接続された送信先装置、例えば、ECU4aに対して要求メッセージが送信された場合、当該要求メッセージを送信してから規定時間100ミリ秒以内に要求メッセージに応答する応答メッセージが受信されないと送信元装置がタイムアウトするように規定されている。したがって、送信元装置は、要求メッセージを送信してから規定時間以内に要求メッセージに応答する応答メッセージが受信されない場合、要求メッセージが送信先装置により受理されなかったものとして処理を行うようになっている。本実施形態におけるゲートウェイ1aは、例えば、診断ツール2からECU4aに対して要求メッセージを中継する際に、上記規定時間100ミリ秒を延長して、5秒間待機するように指示する待機要求コードを診断ツール2へ送信する処理を行う。図2に、診断ツール2からECU4aへ要求メッセージが送信された場合の診断ツール2、ゲートウェイ1a、ECU4a間の信号の流れを示す。次に、図2を参照して、要求メッセージが送信された場合の診断ツール2、ゲートウェイ1a、ECU4a間の信号の流れについて説明する。まず、診断ツール2からゲートウェイ1aへファーストフレームFFが送信されると、ゲートウェイ1aから診断ツール2へフローコントロールFCが送信される。診断ツール2は、このフローコントロールFCを受信すると、コンゼクティブフレームCF1、2、3を順次送信する。そして、コンゼクティブフレームCF3の送信が完了すると、要求メッセージの送信が終了する。ゲートウェイ1aは、診断ツール2からの要求メッセージの受信を完了すると、受信した要求メッセージをECU4aへ中継するとともに、規定時間100ミリ秒を延長して、5秒間待機するように指示する待機要求コードを診断ツール2へ送信する。具体的には、診断ツール2からの要求メッセージの受信を完了すると、直ちにCAN通信プロトコルのダイアグ通信で規定されているNRC0x78コードを待機要求コードとして診断ツール2へ送信するとともに、ゲートウェイ1aからECU4aへファーストフレームFFが送信され、ECU4aからゲートウェイ1aへフローコントロールFCが送信されると、ゲートウェイ1aからECU4aへコンゼクティブフレームCF1、2、3が順次送信される。このように、診断ツール2とゲートウェイ1aとの間で各種フレームの送受信が行われ、要求メッセージの中継が完了する。ECU4aは、要求メッセージの受信が完了すると、この要求メッセージに応答する応答メッセージを診断ツール2へ送信する。具体的には、ECU4aからゲートウェイ1aへファーストフレームFFが送信され、ゲートウェイ1aからECU4aへフローコントロールFCが送信されると、ECU4aからゲートウェイ1aへコンゼクティブフレームCF1、2、3が順次送信される。このように、ECU4aとゲートウェイ1aとの間で各種フレームの送受信が行われ、応答メッセージの送信が終了する。ゲートウェイ1aは、ECU4aからの応答メッセージの受信を完了すると、受信した応答メッセージを診断ツール2へ中継する。具体的には、ゲートウェイ1aから診断ツール2へファーストフレームFFが送信され、診断ツール2からゲートウェイ1aへフローコントロールFCが送信されると、ゲートウェイ1aから診断ツール2へコンゼクティブフレームCF1、2、3が順次送信される。このように、診断ツール2とゲートウェイ1aとの間で各種フレームの送受信が行われ、応答メッセージの中継が完了する。なお、診断ツール2は、タイマを用いて要求メッセージの送信開始時から応答メッセージを受信するまでの時間を計測し、通常、100ミリ秒が経過しても応答メッセージが受信されない場合は、タイムアウトする。ただし、待機要求コードを受信した場合は、タイマをリセットするとともに、規定時間タイムアウト時間を100ミリ秒から5秒に変更する。したがって、多数のゲートウェイを介して接続されたECUにデータを中継し、診断ツール2が規定時間タイムアウト時間内に応答メッセージを受信できないような状況でも、ゲートウェイ1aから診断ツール2へ待機要求コードが送信され、診断ツール2側で規定時間タイムアウト時間が延長された場合、診断ツール2はタイムアウトすることなく、応答メッセージを受信することが可能となる。図3に、NRC0x78コードのフレームフォーマットを示す。本実施形態においては、図に示すフレームフォーマットのNRC0x78コードを待機要求コードとして送信元装置へ送信する。次に、診断ツール2とECU5aとの間のデータ中継を行う場合のゲートウェイ1aの処理について説明する。図4に、この場合のゲートウェイ1aのフローチャートを示す。ゲートウェイ1aは、定期的に図4に示す処理を実施する。まず、要求メッセージを受信したか否かを判定するS100。要求メッセージが受信されない場合、S100の判定はNOとなり、S100の判定処理を繰り返し実施する。ここで、診断ツール2からECU5aへ送信される要求メッセージを受信すると、S100の判定はYESとなり、この要求メッセージをECU5aへと中継するS102。具体的には、バスAのCAN通信プロトコルからバスBのLIN通信プロトコルへとプロトコル変換してゲートウェイ1bを介してECU5aへと要求メッセージを中継する。次に、時間計測を開始するS104。具体的には、タイマをリセットして時間計測を開始する。次に、後述する中継履歴に基づいて待機要求コードを送信する必要があるか否かを判定するS106。ここでは、待機要求コードを送信する必要があるものとする。この場合、S106の判定はYESとなり、次に、待機要求コードを送信するS108。具体的には、CAN通信プロトコルのダイアグ通信で規定されているNRC0x78コードを待機要求コードとして診断ツール2へ送信する。次に、一定期間内に待機要求コードを受信したか否かを判定するS110。ここで、S102にて中継した要求メッセージがゲートウェイ1bによりECU5aへ中継され、このとき、ゲートウェイ1bから診断ツール2へ待機要求コードが送信され、この待機要求コードを受信すると、S110の判定はYESとなり、計測時間をメモリに記憶するS112。具体的には、待機要求コードを受信した時点のタイマの値をメモリに記憶させる。次に、待機要求コードを診断ツール2へ中継しS114、S110の判定へ戻り、再度、待機要求コードを受信したか否かの判定ステップへ戻る。また、一定期間が経過しても待機要求コードが受信されない場合、S110の判定はNOとなり、次に、ECUから応答メッセージを受信したか否かを判定するS116。ここで、要求メッセージを受信したECU5aから応答メッセージが送信され、この応答メッセージを受信すると、S116の判定はYESとなり、次に、計測時間を記憶させるS118。具体的には、応答メッセージを受信した時点のタイマの値をメモリに記憶させる。次に、応答メッセージを診断ツール2へ中継するS120。具体的には、バスBのLIN通信プロトコルからバスAのCAN通信プロトコルへとプロトコル変換してゲートウェイ1bを介して診断ツール2へと応答メッセージを中継する。次に、中継履歴を学習しS122、本処理を終了する。また、ECU5aから応答メッセージが受信されない場合、S116の判定はNOとなり、次に、診断ツール2へエラーを通知するS124。具体的には、CAN通信プロトコルのダイアグ通信で規定されているエラーコードを診断ツール2へ送信し、中継履歴を学習しS122、本処理を終了する。図5に、中継履歴の学習結果の例を示す。図に示すように、送信先ECU毎に、ゲートウェイの数、応答時間および正常または異常を表す情報正常/異常が中継履歴としてメモリに記憶されている。ゲートウェイの数は、待機要求コードを受信した数として特定することができる。また、応答時間は、要求メッセージを中継してから応答メッセージを受信するまでの時間である。また、本実施形態では、応答時間が規定時間100ミリ秒と比較して短い場合、S106の判定において、待機要求コードを送信する必要がないと判定し、応答時間が規定時間100ミリ秒よりも長い場合は、待機要求コードを送信する必要があると判定する。また、要求メッセージの中継先が異常と判定されたECUの場合、S106の判定において、待機要求コードを送信する必要がないと判定し、要求メッセージの中継先が正常と判定されたECUの場合、待機要求コードを送信する必要があると判定する。上記した構成によれば、送信元装置から前記送信先装置への要求メッセージを受信すると、当該要求メッセージを前記送信先装置へ中継するとともに、前記規定時間を延長して待機するように指示する待機要求コードが前記要求メッセージの送信元装置へ送信されるので、ネットワークに接続される機器でタイムアウトの期間を個別に延長することなく、タイムアウトによる応答メッセージの取りこぼしを防止することができる。また、データ中継に異常があったと判定された場合、前記データ中継に異常があったことが前記送信元装置へ通知されるので、送信元装置はデータ中継に異常があったことを認識することができる。また、要求メッセージ、前記応答メッセージおよび前記待機要求コードの少なくとも1つの中継履歴を学習し、当該中継履歴の学習結果を記憶媒体に記憶させ、記憶媒体に記憶された中継履歴の学習結果に基づいて前記待機要求コードを送信する必要があるか否かを判定し、待機要求コードを送信する必要があると判定された場合に、前記待機要求コードを前記要求メッセージの送信元装置へ送信するので、例えば、待機要求コードを送信する必要もないのに待機要求コードを送信元装置へ送信して応答性を低下させてしまうといったことを防止することができる。また、診断ツールは、ゲートウェイから中継履歴を取得して、ゲートウェイから各ECUまでの応答時間を認識したり、あるいは、ゲートウェイと各ECUとの間のゲートウェイの数等を認識したりすることが可能である。なお、本発明は上記実施形態に限定されるものではなく、本発明の趣旨に基づいて種々なる形態で実施することができる。例えば、上記実施形態では、要求メッセージ、応答メッセージおよび待機要求コードの中継履歴を学習したが、必ずしも要求メッセージ、応答メッセージおよび待機要求コードの中継履歴を学習する必要はなく、要求メッセージ、応答メッセージおよび待機要求コードの少なくとも1つの中継履歴を学習するようにしてもよい。また、上記実施形態では、診断ツール2を送信元装置とし、ECUを送信先装置をとしてデータを中継する例を示したが、診断ツール2、ECU以外の装置を送信元装置、送信先装置とすることもできる。なお、上記実施形態における構成と特許請求の範囲の構成との対応関係について説明すると、S108が待機要求送信手段に相当し、116が異常判定手段に相当し、S124が通知手段に相当し、S122が中継履歴学習手段に相当し、S106が待機要求コード送信判定手段に相当し、S104、S118が計測手段に相当する。