"インターネットプロトコルIPベースのネットワークに接続された外部ツールと、車内のローカルエリアネットワークLANに接続された車載ECUとの間でメッセージの送受信を行うことを可能とすべく、両ネットワーク間に介在して前記メッセージの中継を行う車両用通信制御装置であって、前記外部ツールからメッセージを受信したとき、そのメッセージを受信すべき車載ECUに向けて、当該メッセージを転送する転送手段と、前記転送手段が、前記外部ツールとして、第1の外部ツールからのメッセージを前記車載ECUに転送したとき、前記第1の外部ツールからのメッセージに起因する前記車載ECUとの通信が終了するまで、前記メッセージの種別を記憶しておく記憶手段と、前記第1の外部ツールと通信中の車載ECUに対して、前記第1の外部ツールとは異なる第2の外部ツールからのメッセージを受信したとき、その受信したメッセージの種別と、前記記憶手段に記憶しているメッセージの種別とに基づいて、それぞれのメッセージにより前記車載ECUにおける動作が干渉を生じるか否かを判定する干渉判定手段と、を備え、前記転送手段は、前記干渉判定手段によって干渉が生じないと判定された場合に、前記第2の外部ツールからのメッセージを前記車載ECUに転送することを特徴とする車両用通信制御装置。前記干渉判定手段によって干渉が生じると判定されたとき、前記第2の外部ツールに向けて、前記メッセージの受信を否認する旨の応答メッセージを送信する否認応答手段を備えることを特徴とする請求項1に記載の車両用通信制御装置。前記干渉判定手段によって干渉が生じると判定されたとき、前記第2の外部ツールからのメッセージを保存する保存手段を備え、前記保存手段に保存されたメッセージに対して、前記車載ECUにおける動作が干渉を生じる、前記第1の外部ツールからのメッセージに起因する通信が終了し、前記干渉判定手段における判定結果が干渉を生じないとの判定結果に変化したとき、前記転送手段は、前記保存手段に保存されたメッセージを前記車載ECUに転送することを特徴とする請求項1に記載の車両用通信制御装置。前記車載ECUが前記第1の外部ツールと通信中であって、前記第2の外部ツールからのメッセージが前記保存手段に保存されている状態において、前記第1及び第2の外部ツールとは異なる第3の外部ツールから前記車載ECUへのメッセージを受信したとき、前記第3の外部ツールからのメッセージと、前記車載ECUと通信中の前記第1の外部ツールからのメッセージとは、前記車載ECUにおける動作が干渉を生じるものではないと前記干渉判定手段によって判定されたならば、前記第3の外部ツールからのメッセージと、前記保存手段に保存されている、前記第2の外部ツールからのメッセージとが、前記車載ECUにおける動作が干渉を生じるものであっても、前記転送手段は、前記第3の外部ツールからのメッセージを前記車載ECUに転送することを特徴とする請求項3に記載の車両用通信制御装置。前記記憶手段は、前記第1の外部ツールからのメッセージを前記車載ECUに転送してから、前記第1の外部ツールから新たなメッセージを受信することなく、所定時間経過すると、当該メッセージに起因する通信が終了したとみなして、記憶しているメッセージの種別を消去することを特徴とする請求項1乃至4のいずれかに記載の車両用通信制御装置。前記転送手段は、前記車載ECUへ転送された前記第1の外部ツールからのメッセージに対する、当該車載ECUからの応答メッセージが受信されたとき、その応答メッセージを前記第1の外部ツールへ転送するものであり、前記車載ECUからの応答メッセージの内容を解読する解読手段を備え、前記応答メッセージの内容が、前記第1外部ツールからのメッセージに応答しない旨を示す否定応答であった場合、前記記憶手段は、記憶しているメッセージの種別を消去することを特徴とする請求項5に記載の車両用通信制御装置。前記転送手段は、前記車載ECUへ転送された前記第1の外部ツールからのメッセージに対する、当該車載ECUからの応答メッセージが受信されたとき、その応答メッセージを前記第1の外部ツールへ転送するものであり、前記車載ECUからの応答メッセージの内容を解読する解読手段を備え、前記応答メッセージの内容が、前記第1外部ツールからのメッセージに応答する旨を示す肯定応答であった場合、前記転送手段による応答メッセージの転送から、前記第1の外部ツールから新たなメッセージを受信することなく、所定時間経過すると、前記記憶手段は、当該メッセージに起因する通信が終了したとみなして、記憶しているメッセージの種別を消去することを特徴とする請求項1乃至4のいずれかに記載の車両用通信制御装置。前記記憶手段は、記憶しているメッセージの種別とは異なる種別のメッセージを前記第1の外部ツールから受信したとき、種別を記憶しているメッセージに起因する通信は終了したとみなして、その記憶しているメッセージの種別に代えて、新たに受信したメッセージの種別を記憶することを特徴とする請求項1乃至7のいずれかに記載の車両用通信制御装置。前記車載ECUにおける動作が干渉を生じるメッセージの種別の組み合わせは、予め定義され、その定義情報を記憶した定義情報記憶手段を備え、前記干渉判定手段は、前記定義情報を参照して、前記車載ECUにおける動作が干渉を生じるものであるか否かを判定することを特徴とする請求項1乃至8のいずれかに記載の車両用通信制御装置。近年、車両に搭載される電子制御システムの数が増加していることに加え、それぞれの電子制御システムの機能数の増加や、記憶容量の増大等のため、外部ツールとの間でやり取りされるデータ量も今後飛躍的に増加することが予想される。このため、コンピュータネットワークと同様の通信規格インターネットプロトコル:IPを用いて、車載電子制御システムと外部ツールとの通信をより効率的に行うことが検討されている。具体的には、IPベースのネットワークを利用して、車両に搭載された車載電子制御システムと外部ツールとが通信を行うための規格DiagnosticsoverInternetprotocolDoIPが、ISO13400として検討されている。このDoIPでは、外部ツールが、IPベースのネットワークであるイーサネット登録商標、以下同様を介して、車両内のローカルエリアネットワークLANに存在する車載ECUと通信を行う。車内LANでは、CANやLINなどの通信プロトコルが用いられており、車両内外のネットワークの通信プロトコルが異なる。このため、車両内外の両ネットワーク間に介在してメッセージの中継を行う車両用通信制御装置DoIPゲートウェイが設けられる。ここで、DoIPがサポートされている場合、車両外のネットワークに同時に複数の外部ツールを接続することが可能となる。そのため、複数の外部ツールが、同じ車載ECUに対して、同時期に、それぞれ所定の操作を要求するメッセージを送信することが起こりえる。そして、DoIPゲートウェイが、それぞれのメッセージをそのまま車載ECUにゲートウェイさせてしまうと、それぞれの外部ツールからのメッセージの種別によっては、車載ECUでの動作に干渉を生じてしまう可能性が生じる。例えば、外部ツールAが車載ECUに対して制御プログラム及びデータの書き換えを実行するためのメッセージを送信し、別の外部ツールBが、外部ツールAとは異なるデータの書き込みを要求するメッセージを送信したとする。この場合、車載ECUが、両方のメッセージに応じた操作を同時期に行なってしまうと、外部ツールAにより書き換えられた制御プログラムが、外部ツールBにより書き込まれたデータに基づく制御を行なってしまい、適切な制御を行いえない事態が生じる可能性がある。また、別の例として、外部ツールAが車載ECUに対して制御プログラムやデータの書き換えを実行するためのメッセージを送信しているときに、同じ車載ECUに対して、外部ツールBからリセットを要求するメッセージが送信されたとする。この場合、車載ECUにおいて、外部ツールAによる制御プログラムやデータの書き換え処理途中で、車載ECUがリセットされてしまい、書き換え処理を正常に行いえない事態が生じる可能性がある。さらに、別の例として、外部ツールAが、車載電子制御システムの故障診断を行うため、車載ECUが異常検出時に保存している、データ1とデータ2とを取得するためのメッセージを送信したとする。なお、データ1とデータ2とは、相互に関連するものであって、両データの内容から、車載電子制御システムの故障や不具合が正しく判別できるものである。その際、別の外部ツールBが同じ車載ECUと通信中であり、外部ツールBは、必要なデータを取得後、車載ECUに対して保存しているデータの消去を要求するメッセージを送信したとする。この場合、外部ツールAによる一連のデータの取得処理の途中で、外部ツールBからのメッセージに応じて、データ消去が行われたとすると、外部ツールAは、例えばデータ消去前のデータ1と、データ消去後のデータ2とを取得することが起こりえる。すると、これらのデータ1とデータ2との間には整合性が無くなってしまうので、これらのデータに基づいて、故障診断を正しく行うことができなくなってしまう。さらに、外部ツールAが取得した整合性の無い一連のデータから、車載ECUになんらかの故障が生じていると誤判断されてしまう可能性も生じる。本発明は、上述した点に鑑みてなされたもので、複数の外部ツールが車両外のネットワークに接続された場合であっても、それら複数の外部ツールからのメッセージにより、車載ECUでの動作の干渉を回避することが可能な車両用通信制御装置を提供することを目的とする。上記目的を達成するために、請求項1に記載の車両用通信制御装置は、インターネットプロトコルIPベースのネットワークに接続された外部ツールと、車内のローカルエリアネットワークLANに接続された車載ECUとの間でメッセージの送受信を行うことを可能とすべく、両ネットワーク間に介在してメッセージの中継を行うものであって、外部ツールからメッセージを受信したとき、そのメッセージを受信すべき車載ECUに向けて、当該メッセージを転送する転送手段と、転送手段が、外部ツールとして、第1の外部ツールからのメッセージを車載ECUに転送したとき、第1の外部ツールからのメッセージに起因する車載ECUとの通信が終了するまで、メッセージの種別を記憶しておく記憶手段と、第1の外部ツールと通信中の車載ECUに対して、第1の外部ツールとは異なる第2の外部ツールからのメッセージを受信したとき、その受信したメッセージの種別と、記憶手段に記憶しているメッセージの種別とに基づいて、それぞれのメッセージにより車載ECUにおける動作が干渉を生じるか否かを判定する干渉判定手段と、を備え、転送手段は、干渉判定手段によって干渉が生じないと判定された場合に、第2の外部ツールからのメッセージを車載ECUに転送することを特徴とする。このように、請求項1に記載の通信制御装置は、第1の外部ツールからメッセージを受信し、それを車載ECUに転送することによって通信が開始されると、その転送したメッセージの種別を、通信終了まで記憶する記憶手段を備えている。このため、後に、第2の外部ツールから同じ車載ECUに向けられたメッセージを受信したときに、両メッセージにより車載ECUにおける動作が干渉を生じるか否かを判定手段において判定することができる。そして、転送手段は、車載ECUにおける動作が干渉を生じないとの判定がなされた場合に、第2の外部ツールからのメッセージを車載ECUに転送するので、車載ECUにおける動作の干渉を回避することが可能となる。さらに、例えば、車載ECUがある外部ツールと通信中である場合には、別の外部ツールとの通信を一律に禁止する場合に比較して、車載ECUにおける動作干渉が生じない限り、外部ツールからのメッセージを車載ECUに転送するので、外部ツールとの通信を効率的に行なわせることが可能となる。請求項2に記載したように、干渉判定手段によって干渉が生じると判定されたとき、第2の外部ツールに向けて、メッセージの受信を否認する旨の応答メッセージを送信する否認応答手段を備えるようにしても良い。これにより、第2の外部ツールの作業者は、第2の外部ツールからのメッセージの受信が否認されたことを把握でき、例えば、他の外部ツールとの通信終了を待って、再度、第2の外部ツールから同じメッセージを送信させる等の処置を取ることが可能となる。また、請求項3に記載したように、干渉判定手段によって干渉が生じると判定されたとき、第2の外部ツールからのメッセージを保存する保存手段を備え、保存手段に保存されたメッセージに対して、車載ECUにおける動作が干渉を生じる、第1の外部ツールからのメッセージに起因する通信が終了し、干渉判定手段における判定結果が干渉を生じないとの判定結果に変化したとき、転送手段は、保存手段に保存されたメッセージを車載ECUに転送するようにしても良い。このようにすれば、車載ECUにおける動作の干渉が生じない状態となったとき、自動的に第2の外部ツールからのメッセージが車載ECUに転送される。従って、再度、第2の外部ツールから同じメッセージを送信するための手間を省くことができる。請求項4に記載したように、車載ECUが第1の外部ツールと通信中であって、第2の外部ツールからのメッセージが保存手段に保存されている状態において、第1及び第2の外部ツールとは異なる第3の外部ツールから車載ECUへのメッセージを受信したとき、第3の外部ツールからのメッセージと、車載ECUと通信中の第1の外部ツールからのメッセージとは、車載ECUにおける動作が干渉を生じるものではないと干渉判定手段によって判定されたならば、第3の外部ツールからのメッセージと、保存手段に保存されている、第2の外部ツールからのメッセージとが、車載ECUにおける動作が干渉を生じるものであっても、転送手段は、第3の外部ツールからのメッセージを車載ECUに転送するようにしても良い。この場合、第2の外部ツールからのメッセージは、車載ECUへの転送が保留されており、第3の外部ツールからのメッセージを車載ECUに転送しても、車載ECUにおける動作干渉を生じないためである。請求項5に記載したように、記憶手段は、第1の外部ツールからのメッセージを車載ECUに転送してから、第1の外部ツールから新たなメッセージを受信することなく、所定時間経過すると、当該メッセージに起因する通信が終了したとみなして、記憶しているメッセージの種別を消去するようにしても良い。このように、第1の外部ツールからのメッセージの転送から、新たなメッセージを受信することなく、所定時間が経過した場合には、そのメッセージに起因する通信は終了したとみなすことができる。そして、通信終了と判断したときに、記憶手段に記憶されたメッセージの種別を消去することにより、新たにメッセージを受信した場合に、すみやかに車載ECUへ転送することができる。請求項6に記載したように、転送手段は、車載ECUへ転送された第1の外部ツールからのメッセージに対する、当該車載ECUからの応答メッセージが受信されたとき、その応答メッセージを第1の外部ツールへ転送するものであり、車載ECUからの応答メッセージの内容を解読する解読手段を備え、応答メッセージの内容が、第1外部ツールからのメッセージに応答しない旨を示す否定応答であった場合、記憶手段は、記憶しているメッセージの種別を消去することが好ましい。車載ECUから否定応答メッセージが送信されると、その時点で、車載ECUと第1外部ツールとの通信は終了するとみなすことができるためである。請求項7に記載したように、転送手段は、車載ECUへ転送された第1の外部ツールからのメッセージに対する、当該車載ECUからの応答メッセージが受信されたとき、その応答メッセージを第1の外部ツールへ転送するものであり、車載ECUからの応答メッセージの内容を解読する解読手段を備え、応答メッセージの内容が、第1外部ツールからのメッセージに応答する旨を示す肯定応答であった場合、転送手段による応答メッセージの転送から、第1の外部ツールから新たなメッセージを受信することなく、所定時間経過すると、記憶手段は、当該メッセージに起因する通信が終了したとみなして、記憶しているメッセージの種別を消去するようにしても良い。このように、所定時間の計時開始は、車載ECUから第1の外部ツールへの応答メッセージが送信されたときとしても良い。請求項8に記載したように、記憶手段は、記憶しているメッセージの種別とは異なる種別のメッセージを第1の外部ツールから受信したとき、種別を記憶しているメッセージに起因する通信は終了したとみなして、その記憶しているメッセージの種別に代えて、新たに受信したメッセージの種別を記憶することが好ましい。記憶しているメッセージの種別とは異なる種別のメッセージを第1の外部ツールから受信した場合、その受信した種別のメッセージに起因する通信が開始されるためである。請求項9に記載したように、車載ECUにおける動作が干渉を生じるメッセージの種別の組み合わせは、予め定義され、その定義情報を記憶した定義情報記憶手段を備え、干渉判定手段は、その定義情報を参照して、車載ECUにおける動作が干渉を生じるものであるか否かを判定することが好ましい。外部ツールと車載ECUとの間で送受信されるメッセージの種別は予め判明しており、いずれのメッセージの種別の組み合わせが、車載ECUにおいて動作干渉を生じるかは事前に特定できるためである。第1実施形態以下、本発明の第1実施形態による車両用通信制御装置について、図面を参照しつつ説明する。なお、以下の本実施形態の説明では、車両用通信制御装置が、DoIPゲートウェイとして具現化されている。図1は、DoIPゲートウェイ101を介して通信が行われるシステム全体の構成を示している。本システムにおいて、DoIPゲートウェイ101は、車両内に設置され、車両内のローカルエリアネットワークLANに接続されている。この車内LANには、少なくとも1つの車載ECU102ECU1~mが接続されている。従って、DoIPゲートウェイ101は、車内LANを介して車載ECU102と通信を行うことができる。なお、車内LANの通信プロトコルには、CANやLINなどが用いられる。また、DoIPゲートウェイ101は、IPベースのネットワークとしてのイーサネットを介して、少なくとも1つの車両外部のツール103ツール1~nと接続されている。なお、イーサネットとDoIPゲートウェイ101とを接続する際、その接続は有線にて行なっても良いし、無線にて行なっても良い。イーサネットにおいては、通信プロトコルとして、ISO13400に規定されたDoIPが用いられる。一方、車載LANでは、上述したように、通信プロトコルとしてCANやLINが用いられる。このように車両内外のネットワークにおける通信プロトコルが異なるので、DoIPゲートウェイ101が、外部ツール103から車載ECU102へ、又は車載ECU102から外部ツール103へメッセージを転送する際には、メッセージのプロトコル変換を行う。このようなプロトコル変換を伴うメッセージの転送を、以下、ゲートウェイと呼ぶ。外部ツール103は、車載ECU102との間でのメッセージのやり取りを通じて、車載ECU102からダイアグコードを読み出したり、内部データを読みだしたり、車載ECU102をリセットしたりするものである。また、外部ツール103は、車載ECU102における制御プログラムを更新するために制御プログラムの書き換えを行ったり、データの書き込みや消去を行ったりすることもある。このような外部ツール103は、車載ECU102と、DoIP通信を行い得るハードウェア又はソフトウェアにより構成される。次に、図2を参照して、DoIPゲートウェイ101が有する機能について説明する。なお、図2においては、DoIPゲートウェイ101の各機能を機能ブロックとして表している。図2に示すように、DoIPゲートウェイ101は、イーサネットを介しての通信を実現するために、イーサネット通信部201及びイーサネット通信部201に対する送受信メッセージを格納するためのバッファ203を有している。また、DoIPゲートウェイ101は、車内LANを介しての通信を実現するために、ローカルネットワーク通信部202及び車両内の送受信メッセージを格納するバッファ204を有している。さらに、DoIPゲートウェイ101は、イーサネット用のバッファ203と車内LAN用のバッファ204との間に、ゲートウェイ機能を実現するためのゲートウェイ処理部205を有している。ゲートウェイ処理部205には、DoIPメッセージを受信及び送信するためのIPメッセージ受信処理部206及びIPメッセージ送信処理部207が設けられている。これらIPメッセージ受信処理部206及びIPメッセージ送信処理部207は、イーサネット用のバッファ203との間で、受信メッセージ及び送信メッセージの受け渡しを行う。さらに、ゲートウェイ処理部205には、車内LAN上におけるメッセージを送受信するための車内メッセージ受信処理部208と車内メッセージ送信処理部209とが設けられている。これら車内メッセージ受信処理部208及び車内メッセージ送信処理部209は、車内LAN用のバッファ204との間で、受信メッセージ及び送信メッセージの受け渡しを行う。IPメッセージ受信処理部206と車内メッセージ送信処理部209との間に車外→車内ゲートウェイ処理部210が設けられている。また、IPメッセージ送信処理部207と車内メッセージ受信処理部208との間に車内→車外ゲートウェイ処理部211が設けられている。これらの車外→車内ゲートウェイ処理部210及び車内→車外ゲートウェイ処理部211は、外部ツール103からの要求メッセージを車載ECU102にゲートウェイしたり、車載ECU102からの応答メッセージを外部ツール103にゲートウェイしたりするために必要な、通信プロトコルの変換とアドレスの変換を行うものである。IPメッセージ受信処理部206と車外→車内ゲートウェイ処理部210との間に、さらに干渉判定部212が設けられている。この干渉判定部212は、複数の外部ツール103ツール1~nが、車載ECU102の同じECU1~mに対して、同時期に、要求メッセージを送信してきた場合に、それらの要求メッセージによりECU1~mでの動作が干渉を生じるか否かを判定するものである。その判定の結果、動作干渉が生じないと判定したときには、干渉判定部212は、要求メッセージを車外→車内ゲートウェイ処理部210に渡して、送信先ECU1~mへゲートウェイさせる。一方、干渉が生じると判定したときには、干渉判定部212は、後に受信した要求メッセージを車外→車内ゲートウェイ処理部210に出力せず、送信先ECU1~mへのゲートウェイを行わせない。この場合、図2には示していないが、干渉判定部212は、応答メッセージ出力部に対して、受信を否認する旨の否定応答メッセージの出力指示を行う。この否定応答メッセージがイーサネット通信部201を介して、要求メッセージを送信したツール1~nに送信されることにより、ツール1~nの作業者は、そのツール1~nからの要求メッセージの受信が否認されたことを把握でき、例えば、他のツール1~nとの通信終了を待って、再度、ツール1~nから同じ要求メッセージを送信させる等の処置を取ることが可能となる。なお、干渉判定部212は、送信先ECU1~mにおける動作干渉が生じないと判定した場合、応答メッセージ出力部に対して、要求メッセージの受信を承認した旨を示す肯定応答メッセージの出力指示を行う。干渉判定部212は、上述した干渉判定を行う際、干渉定義情報記憶部213に記憶された干渉定義情報テーブル、及び通信状態管理部214に保存されている、車載ECU102としての各ECU1~mと外部ツール103としての各ツール1~nとの通信状態に関する情報以下、通信状態情報を参照する。干渉定義情報テーブルとは、先に受信した要求メッセージの種別に対する、後に受信した要求メッセージの種別の組み合わせが、送信先ECU1~mでの動作干渉を生じる組み合わせであるかどうかに関する情報をまとめたものである。各ツール1~nから各送信先ECU1~mへ送信される要求メッセージの種別は予め判明しており、いずれの要求メッセージの種別の組み合わせが、送信先ECU1~mでの動作干渉を生じるかは事前に特定できるためである。図3に、干渉定義情報テーブルの一例を示す。この干渉定義情報テーブルには、DoIPゲートウェイ101に接続されている各ECU1~mがサポートする全てのダイアグ要求メッセージの種別が登録されている。干渉定義情報デーブルにおいては、先に受信されて、通信中となっている要求メッセージの種別が前回要求の種別となり、後に受信された要求メッセージの種別が今回要求の種別となる。そして、前回要求の種別に対する今回要求の種別に応じて、許可か禁止の状態が定められている。なお、禁止状態は、後に受信された要求メッセージが、先に受信され通信中の要求メッセージに対して、送信先ECU1~mでの動作干渉を引き起こすものであることを意味する。ここで、干渉とは、典型的には、発明が解決しようとする課題の欄に説明したいくつかのケースのように、ECU1~mが正常な動作を行い得なくなったり、正しいデータをECU1~mから取得できなくなったりする状況の発生を意味するものである。ただし、干渉の定義は、車両の機能及び車内LANのトポロジーにより変わるものであり、車両安全とデータの保全性を考慮して要求メッセージの実行可否を決める必要がある。例えば、ツール1が、セキュリティ関連処理として、ECU1のセキュリティ解除を要求するメッセージを送信し、ECU1がセキュリティを解除したとする。その場合、ツール2が、同じECU1に対してECU内部データの取得を要求するメッセージを送信したとする。ECU1やツール1,2にとっては、この二つの要求は特に問題なく同時に実行できる。しかし、この場合、ツール2が、ツール1によるセキュリティ解除状態に便乗して、本来取得できないECU内部データを取得できてしまう危険性が存在する。そのため、図3に示す干渉定義情報テーブルでは、このようなケースをECU1~mにて動作干渉が生じるものとみなし、あるツール1がECU1とセキュリティ関連の処理を実施するための通信を行なっている場合、他のツール2によるECU内部データ取得処理を禁止している。なお、図3におけるセッション移行とは、ツール1~nが、ECU1~mに対して要求可能なメッセージの種別の範囲を切り替えることを意味する。例えば、あるツール1~nでは、セッション移行を要求するメッセージを送信することができないように設定される。その場合、そのツール1~nは、異常データの取得等、制限された要求メッセージに対する応答メッセージしかECU1~mから取得することができなくなる制限範囲外の要求メッセージに対しては、ECU1~mは応答しない。一方、別のツール1~nでは、セッション移行を要求するメッセージを送信可能に設定される。ECU1~mにセッション移行要求メッセージを送信することにより、ECU1~mは、全ての要求メッセージを受け付けて、応答メッセージを送信する状態に移行する。この際、要求可能なメッセージの範囲を3段階以上に設定することももちろん可能である。このようなセッション移行要求は、セキュリティ解除要求とセットで用いられることが多い。セキュリティ解除要求には、通常、暗証番号による認証が必要である。このため、セキュリティが解除された状態のときにのみ、セッション移行を許可するようにすることで、権限を有する作業者のみに、データの書き込み等の重要な処理の実行を認めることが可能になるためである。次に、通信状態管理部214が管理する通信状態情報について説明する。図1に示すように、イーサネットには、外部ツール103として、複数のツール1~nが接続され、車内LANにも、車載ECU102として、複数のECU1~mが接続される場合がある。このため、DoIPゲートウェイ101は、複数のツール1~nから同時期に、同じECU1~mに向けられた要求メッセージを受信する場合がある。このようなツール1~nとECU1~mとの間のN対M通信における干渉判定のため、通信状態管理部214は、以下に述べる情報を通信状態情報として管理する。まず、通信状態管理部214は、図4の左側に示すように、ECU1~mごとに、送信先ECUの通信状態を持つ。この通信状態は、該当するECU1~mが、少なくとも1つのツール1~nと通信中であるか否かを示すものである。図4に示す例では、ON又はOFFにより、該当するECU1~mが通信中か、通信中ではないかが示されている。そして、ECU1~mの通信状態がONとなっている場合、通信状態管理部214は、図4の右側に示すように、そのECU1~mと通信している全てのツール1~nに関して、ツール1~nごとに送信元情報、受信メッセージの種別情報、及び通信状態カウンタを持つ。受信メッセージ種別情報は、図3において説明したように、干渉有無の判定根拠となる情報である。通信状態カウンタは、ツール1~nからの要求メッセージが送信先ECU1~mに転送されて通信が開始されると、その通信開始からの経過時間をカウントするものである。すなわち、通信状態カウンタは、各ツール1~nとの通信開始からの経過時間を示す情報となる。この通信状態カウンタによってカウントされた経過時間に基づいて、ツール1~nとECU1~mとの通信が進行しているか、通信が終了したかが判定される。そのため、ツール1~nから新たな要求メッセージを受信したとき、対応する通信状態カウンタをリセットした上で、通信状態カウンタによるカウントアップ開始する。そして、所定時間内に同じツール1~nから同じECU1~mへの要求メッセージを受信しない場合、通信状態カウンタはタイムアウトして停止状態になる。そして、通信状態カウンタが停止状態となっているツール1~nの情報送信元情報、受信メッセージ種別情報は、通信状態情報から削除される。通信開始から所定時間が経過した場合、ツール1~nからの要求メッセージに起因する通信は終了したものとみなすことができるためである。次に、DoIPゲートウェイ101において、ツール1~nからの要求メッセージを受信したときに実行される干渉判定処理について、図5のフローチャートに従って詳細に説明する。まず、ステップS501では、いずれかのツール1~nから要求メッセージを受信したとき、その要求メッセージのヘッダ、ペイロード、メッセージ長などが、ISO13400-2に規定されるプロトコルを満足するものであるかが判定される。受信した要求メッセージにプロトコルの異常が存在する場合、ステップS506に進んで、否定応答メッセージを送信する。一方、要求メッセージのチェックが正常に完了した場合には、ステップS502の処理に進む。ステップS502では、要求メッセージの送信先となるECU1~mの通信状態を、上述した送信先ECUの通信状態に基づいて判定する。この判定処理において、要求メッセージの送信先ECU1~mの通信状態がOFFと判定された場合、ステップS509の処理に進み、送信先ECU1~mの通信状態をONに変化させる。そして、続くステップS510において、通信状態情報として、要求メッセージを発したツール1~nを示す送信元情報、及び要求メッセージの種別情報を記憶する。一方、ステップS502の判定処理において、送信先ECU1~mの通信状態がONと判定された場合、ステップS503の処理に進む。この場合、送信先ECU1~mは、少なくとも1つのツール1~nと通信中である。従って、ステップS503~S505において、今回の要求メッセージの種別が、通信中の要求メッセージ前回の要求メッセージの種別に対して、送信先ECU1~mでの動作干渉を生じるものであるか否かを、通信中の全てのツール1~nについて順番に判定していく。そのため、まず、ステップS503では、この動作干渉の判定が、通信中のすべての送信元としてのツール1~nに関してなされたか否かが判定される。この判定処理において、通信中のすべての送信元としてのツール1~nに関して動作干渉の判定が完了していないと判定された場合、ステップS504の処理に進み、完了したと判定された場合、ステップS507の処理に進む。ステップS504では、動作干渉の判定が未完了の1つのツール1~nを対象として、今回、受信した要求メッセージの送信元であるツール1~nが、その判定対象となっているツール1~nと異なるか否かを判定する。ツール1~nが同じであれば、動作干渉を生じるような要求メッセージを発することはない。従って、ステップS504にてNoと判定された場合には、ステップS503の処理に戻る。一方、要求メッセージの送信元が異なる場合、ステップS504の判定結果はYesとなり、ステップS505の処理に進む。ステップS505では、上述した干渉定義情報テーブルを参照して、受信した要求メッセージの種別と、判定対象のツール1~nからの要求メッセージの種別とに基づき、送信先ECU1~mでの動作干渉が生じるか否かを判定する。この判定処理において、動作干渉が生じると判定された場合には、ステップS506に進み、要求メッセージの受信を否認する否定応答メッセージを送信する。つまり、送信先ECU1~mと通信中のツール1~nの中で、今回、受信した要求メッセージと送信先ECU1~mでの動作干渉が生じる要求メッセージを送信したツール1~nが1つでも存在する場合には、今回の要求メッセージの受信が行われず、その要求メッセージを送信したツール1~nに否定応答メッセージが返送される。一方、動作干渉は生じないと判定された場合には、ステップS503の処理に戻り、まだ動作干渉の判定が完了していないツール1~nが残されているかを判定する。ステップS506において否定応答メッセージが送信されることなく、ステップS503において、動作干渉の判定が、通信中のすべてのツール1~nに関してなされたと判定されると、ステップS507の処理に進んで、今回、受信した要求メッセージの送信元であるツール1~nの情報が、送信元情報として記憶済みのものであるか否かが判定される。すなわち、今回の要求メッセージを発したツール1~nが、以前に別の要求メッセージを送信先ECU1~mに送信して、通信状態情報に登録済みのものであるか否かが判定される。このステップS507における判定結果がYesとなった場合、ツール1~nを示す送信元情報は、既に通信状態情報に記憶されているので、ステップS508に進み、受信した要求メッセージの種別に基づき、通信状態情報における要求メッセージの種別情報を更新する。新たに受信した要求メッセージに起因する通信が、送信先ECU1~mとツール1~nとの間で開始されるので、その後に受信される要求メッセージとの間で、動作干渉判定を行うことに備えるためである。一方、ステップS507における判定結果がNoとなった場合には、ステップS510に進んで、通信状態情報に、要求メッセージを発した新たなツール1~nを示す送信元情報、及びその要求メッセージの種別情報を記憶する。続くステップS511では、ステップS508にて更新した、あるいはステップS510において記憶した要求メッセージに対応付けられた通信状態カウンタをリセットし、新たなカウントを開始させる。そして、ステップS512では、要求メッセージを、送信先ECU1~mにゲートウェイし、ステップS513では、要求メッセージを送信したツール1~nに対して、要求メッセージの受信を承認したことを示す肯定応答メッセージを送信する。次に、通信状態情報の更新処理について、図6のフローチャートに基づいて説明する。なお、図6のフローチャートに示す処理は、所定期間が経過するごとに定期的に実行される。まず、ステップS601では、通信状態がONとなっているすべてのECU1~mに関して、ステップS602以降に示す処理が実行されたか否かを判定する。このステップS601において、通信中の全ECU1~mについて処理が完了していないと判定されると、まだ処理が完了していないECU1~mの中の1つを対象として、ステップS602以降の処理が実行される。このように、通信中のECU1~mについて、1つずつ順番にステップS602以降の処理を実行した結果、ステップS601において、通信中の全ECU1~mについて処理が完了したと判定されると、図6のフローチャートに示す処理が終了する。ステップS602では、処理対象となっている1つのECU1~mの通信状態情報に含まれる、すべての通信状態カウンタの判定がまだ完了していないかどうかを判定する。処理対象である送信先ECU1~mの通信状態情報に含まれるすべての通信状態カウンタに関して、まだ判定が完了していないと判定された場合には、ステップS603に進んで、判定未完了の通信状態カウンタを対象として、判定処理を行う。具体的には、ステップS603の判定処理では、通信状態カウンタによってカウントされた通信開始からの経過時間が予め定めた所定時間に達したか否かが判定される。通信状態カウンタは、上述したように、同じツール1~nから別の要求メッセージを受信したときにリセットされ、新たにカウントを開始する図5のフローチャートのステップS511参照。従って、通信状態カウンタがカウントする経過時間が所定時間に達するのは、同じツール1~nから、新たな要求メッセージを受信することなく、前回の要求メッセージを受信してから所定時間が経過した場合である。そして、本実施形態では、所定時間が、ツール1~nからの要求メッセージに起因して、ツール1~nとECU1~mとの間で行われる通信に必要な時間以上の時間に設定されている。このため、ステップS603において、通信状態カウンタがカウントする経過時間が所定時間に達したと判定された場合、その通信状態カウンタに対応するツール1~nとの通信は終了しているとみなすことができる。そのため、ステップS604の処理に進んで、そのツール1~nを示す送信元情報と、要求メッセージの種別情報とを通信状態情報から消去する。さらに、ステップS605において、通信状態カウンタによってカウントされた経過時間を消去するとともに、通信状態カウンタのカウント動作を停止させる。上述したS603~S605の処理を実行することにより、いずれ、ステップS602において、処理対象となっている1つのECU1~mの通信状態情報に含まれる、すべての通信状態カウンタの判定が完了したと判定されるようになる。すると、ステップS606の処理に進み、判定対象のECU1~mの通信状態情報における、すべての通信状態カウンタがカウント動作を停止しているか否かが判定される。すべての通信状態カウンタがカウント動作を停止している場合、処理対象となっているECU1~mはいずれのツール1~nとも通信していないとみなせるので、ステップS607において、そのECU1~mの通信状態をOFFに設定する。その後、通信中のECU1~mで、まだ未処理のECU1~mが残されていないかどうかを確認するために、再びステップS601の処理が実行される。このような図6のフローチャートに示す処理を実行することにより、通信状態情報には、各ECU1~mと実際に通信中のツール1~nに関する情報のみが記憶されるよう、通信状態情報を正しく更新することができる。次に、上述した図5及び図6のフローチャートに示す処理を実行することにより、どのようにしてECU1~mの動作干渉の防止が図り得るかについて、図7に示した例を参照しつつ説明する。なお、図7には、ツール1~3が、同じECU1~mと同時期に通信期間が重複するように通信を行う例が示されている。時刻T1において、ツール1から異常データ取得要求メッセージを受信すると、DoIPゲートウェイ101は、その要求メッセージを送信したツール1の送信元情報と、要求メッセージの種別情報を記憶した上で、送信先ECU対象ECU1~mに要求メッセージをゲートウェイする。同時に、ツール1に対応する通信状態カウンタに、経過時間のカウントを開始させる。その後、時刻T2において、ツール2から異常データ取得要求メッセージを受信すると、DoIPゲートウェイ101は、干渉定義情報テーブルを参照し、ツール2からの要求メッセージが、通信中のツール1からの要求メッセージに対し、送信先ECU1~mでの動作干渉を生じるものであるか否か、両要求メッセージの種別に基づいて判定する。この場合、両要求メッセージの種別は、ともに異常データ取得要求であり、送信先ECU1~mでの動作干渉を発生させるものではない。このため、ツール2の送信元情報と、要求メッセージの種別情報を記憶した上で、送信先ECU対象ECU1~mに要求メッセージをゲートウェイする。同時に、ツール2に対応する通信状態カウンタにより、経過時間のカウントを開始させる。そして、時刻T3において、ツール3からデータクリア要求メッセージを受信すると、DoIPゲートウェイ101は、そのツール3からの要求メッセージが、ツール1及びツール2からの要求メッセージに対し、送信先ECU1~mでの動作干渉を生じるものであるか否かを判定する。干渉定義情報テーブルを参照すると、データクリア要求は、異常データ取得要求に対して、ECU1~mでの動作干渉を生じるものであることが分かる。そのため、DoIPゲートウェイ101は、ツール3からの要求メッセージを送信先ECU1~mにゲートウェイせず、ツール3に対して、要求メッセージの受信を否認する旨の否定応答メッセージを送信する。時刻T4において、再度、ツール1から異常データ取得要求メッセージを受信したとき、通信中のツール2からの異常データ要求メッセージとの間で、ECU1~mでの動作干渉は生じないため、DoIPゲートウェイ101は、通信状態情報の要求メッセージの種別情報を更新した上で、その要求メッセージをECU1~mにゲートウェイする。さらに、通信状態情報の通信状態カウンタをリセットして、新たに経過時間のカウントを開始させる。時刻T5において、ツール2から内部データ取得要求メッセージを受信すると、通信中のツール1からの異常データ取得要求メッセージとの間で、ECU1~mでの動作干渉は生じないため、DoIPゲートウェイ101は、通信状態情報の要求メッセージの種別情報を更新異常データ取得要求→ECU内部データ取得要求した上で、その要求メッセージを送信先ECU1~mにゲートウェイする。さらに、通信状態情報の通信状態カウンタをリセットして、新たに経過時間のカウントを開始させる。そして、時刻T6において、ツール1に対応する通信状態カウンタがカウントする経過時間が所定時間に達したことに応じて、通信状態情報から、ツール1の送信元情報、及び要求メッセージの種別情報を消去する。さらにツール1に対応する通信状態カウンタがカウントした経過時間も消去するとともに、その通信状態カウンタのカウント動作を停止させる。時刻T7において、ツール3からデータクリア要求メッセージを受信すると、その際に、通信中なのはツール2のみである。そのため、DoIPゲートウェイ101は、ツール3からの要求メッセージが、ツール2からの要求メッセージとの間で、ECU1~mでの動作干渉を生じるものであるか否かを判定する。干渉定義情報テーブルを参照すると、データクリア要求は、内部データ取得要求に対して、ECU1~mでの動作干渉を生じるものではないので、DoIPゲートウェイ101は、ツール3の送信元情報及び要求メッセージの種別情報を記憶した上で、ツール3からの要求メッセージを送信先ECU1~mにゲートウェイする。同時に、ツール3に対応する通信状態カウンタにより、経過時間のカウントを開始させる。このように、本実施形態によるDoIPゲートウェイ101では、いずれかのツール1~nから要求メッセージを受信し、それを送信先ECU1~mにゲートウェイして通信が開始されると、そのツール1~nの送信元情報及び要求メッセージの種別情報を、その要求メッセージによる通信が終了するまで、通信状態情報として記憶している。このため、後に、別のツール1~nから同じ送信先ECU1~mに向けられた要求メッセージを受信したときに、両要求メッセージにより送信先ECU1~mでの動作が干渉を生じるか否かを判定することが可能となる。そして、DoIPゲートウェイ101は、送信先ECU1~mにおいて動作干渉が生じないと判定した場合にのみ、その別のツール1~nからの要求メッセージを送信先ECU1~mにゲートウェイするので、送信先ECU1~mでの動作干渉を回避することが可能となる。さらに、例えば、送信先ECU1~mがあるツール1~nと通信中である場合には、別のツール1~nとの通信を一律に禁止する場合に比較して、送信先ECU1~mでの動作干渉が生じない限り、別のツールからの要求メッセージを送信先ECU1~mに転送するので、複数のツール1~nとの通信を効率的に行なわせることが可能となる。第2実施形態次に、本発明の第2実施形態による車両用通信制御装置について、図面を参照しつつ説明する。なお、第2実施形態による車両用通信制御装置も、DoIPゲートウェイとして実現され、そのDoIPゲートウェイが適用されるシステムの構成は、第1実施形態と同様である。また、DoIPゲートウェイ101自体の機能構成も、第1実施例とほぼ共通しているので、説明を省略する。第1実施形態では、後に受信した要求メッセージが、先に受信して通信が開始されている要求メッセージに対し、ECU1~mでの動作干渉が生じると判定された場合、後の要求メッセージの受信を否認し、否定応答メッセージを送信するものであった。それに対して、第2実施形態では、動作干渉が生じると判定された場合に、後に受信した要求メッセージを、DoIPゲートウェイ101が一時的に保存しておき、動作干渉を生じる要求メッセージの通信がすべて終了した後に、その一時的に保存している要求メッセージを送信先ECU1~mにゲートウェイするメッセージ保留機能を備えることを特徴としている。このようなメッセージ保留機能を備えることにより、送信先ECU1~mでの動作干渉が生じない状態となったとき、自動的に要求メッセージを送信先ECU1~mに転送することができる。従って、再度、ツール1~nから同じ要求メッセージを送信するための手間を省くことができる。図8は、本実施形態によるメッセージ保留機能を実現するために必要な、通信状態情報の構成の一例を示す図である。図8に示す通信状態情報は、図4に示す通信状態情報に対して、送信元である各ツール1~nごとに、干渉状態を示す属性が追加されている。後に受信した要求メッセージが、先に受信して通信が開始されている要求メッセージに対して、送信先ECU1~mでの動作干渉が生じないと判定された場合には、その干渉状態には何も設定されない。この場合、第1実施形態の場合と同様に、通信状態情報には、後に受信した要求メッセージに関する送信元情報及び要求メッセージの種別情報が記憶されるとともに、通信状態カウンタによる経時時間のカウントが開始される。一方、送信先ECU1~mでの動作干渉が生じると判定された場合には、通信状態情報に、要求メッセージに関する送信元情報及び種別情報を記憶するが、干渉状態に保留状態を設定する。この際、要求メッセージは、送信先ECU1~mにゲートウェイされず、DoIPゲートウェイ101にて一時的に保存される。そのため、通信状態カウンタによる経過時間のカウントは開始されない。図8に示すような構成の通信状態情報を用いて、メッセージ保留機能がいかにして実現されるかについて、図9のフローチャートに基づいて説明する。なお、図9のフローチャートは、本実施形態における、ツール1~nからの要求メッセージを受信したときに実行される干渉判定処理を示している。図9のフローチャートのステップS901~S905までの処理は、図5のフローチャートのステップS501~S505の処理と同様である。しかし、図9のフローチャートでは、ステップS905において、送信先ECU1~mにて動作干渉が生じると判定された場合、ステップS906の処理に進んで、後に受信された要求メッセージに関して、干渉情報設定処理を実行してから、ステップS914の処理に進み、要求メッセージの受信を承認する旨の肯定応答メッセージを送信する。なお、図9のフローチャートにおけるその他のステップの処理も、図5のフローチャートの処理と同様であるため、説明を省略する。図10は、図9のフローチャートのステップS906における干渉情報設定処理の詳細を示すフローチャートである。まず、ステップS1001では、図9のフローチャートのステップS905において、送信先ECU1~mでの動作干渉が生じるとの判定の根拠となった、通信状態情報に登録済みの要求メッセージを対象とし、その干渉情報を参照して、その要求メッセージの送信が保留状態であるか否かを判定する。動作干渉が生じるとの判定の根拠となった要求メッセージが送信保留中であれば、その要求メッセージによる通信は行われていないので、今回、受信した要求メッセージを送信先ECU1~mにゲートウェイしても、実際に動作干渉が生じることはない。そのため、ステップS1001において、要求メッセージの送信が保留状態にあると判定されると、ステップS1002にて、図9のフローチャートのステップS903からの処理を引き続き実施するようにする。一方、ステップS1001において、要求メッセージの送信が保留されておらず、通信中であると判定されると、ステップS1003の処理に進む。ステップS1003では、受信した要求メッセージに関する送信元情報が、通信状態情報に登録済みであるか否かを判定する。すなわち、受信した要求メッセージが、通信状態情報に送信元情報が記憶されていない、新規のツール1~nから送信されたものであるか否かを判定する。このS1003において、送信元情報が、通信状態情報に登録されていないと判定されると、ステップS1004の処理に進み、送信元情報と要求メッセージの種別情報を通信状態情報に新たに追加記憶する。一方、受信した要求メッセージに関する送信元情報が登録済みであると判定されると、ステップS1005の処理に進む。ステップS1005では、通信状態情報におけるメッセージ種別情報を、今回受信した要求メッセージの種別に更新する。そして、ステップS1006において、対応する通信状態カウンタをクリアするとともに、そのカウント動作を停止したままとする。ステップS1007では、受信した要求メッセージを、DoIPゲートウェイ101内のメモリに一時的に保存しておく。そして、ステップS1008では、通信状態情報の干渉状態に、保留状態を設定する。このようにして、送信先ECU1~mにて動作干渉が生じると判定された要求メッセージに関して、通信状態情報に、送信元情報、要求メッセージの種別情報、さらには、干渉情報が記録されるのである。次に、本実施形態における、通信状態情報の更新処理について、図11のフローチャートに基づいて説明する。なお、図11のフローチャートのステップS1101~S1107までの処理は、図6のフローチャートのステップS601~S607までの処理と同様であるため、説明を省略する。図11のフローチャートでは、ステップS1102からステップS1106に移行するまでの間に、ステップS1108~S1112の処理が挿入されている点が、図6のフローチャートと異なっている。この挿入されたステップS1108~S1112の処理は、送信が保留されている要求メッセージに関して、動作干渉が生じるとの判定の根拠となった要求メッセージによる通信が終了したときに、その保留中の要求メッセージを送信先ECU1~mにゲートウェイさせるためのものである。ここで、ステップS1108~S1112の処理は、ステップS1102において、処理対象となっている1つのECU1~mの通信状態情報に含まれる、すべての通信状態カウンタの判定が完了したと判定されたときに実行される。このタイミングでは、各々のツール1~nに関して、通信状態カウンタによる経過時間に基づき、まだ通信中であるか、通信が終了したかの判定が完了している。従って、動作干渉が発生するとの判定根拠となった要求メッセージによる通信が終了したと判定された場合に、送信を保留している要求メッセージの転送を即座に実施することが可能となる。ステップS1108では、処理対象となっているECU1~mの通信状態情報における干渉状態を参照して、送信が保留されている要求メッセージがあるか否かを判定する。そのような要求メッセージがない場合には、ステップS1109~S1112の処理をスキップして、直接、ステップS1106の処理に移行する。一方、送信が保留されている要求メッセージがある場合には、ステップS1109の処理に進む。ステップS1109では、通信状態情報を参照し、送信を保留している要求メッセージと動作干渉を引き起こす要求メッセージが通信を終了して、もはや動作干渉を生じる虞がなくなったか否かを判定する。この判定処理において、動作干渉を生じる虞があると判定されると、ステップS1108の処理に戻り、他に送信が保留中の要求メッセージがあるか否かが判定され、一方、動作干渉を生じる虞はないと判定されると、ステップS1110の処理に進む。ステップS1110では、送信が保留されている要求メッセージに対応する通信状態カウンタをリセットするとともに、通信状態カウンタによるカウンタ動作を開始させる。続くステップS1111において、通信状態情報の干渉状態に設定されている保留状態をクリアする。そして、ステップS1112において、送信が保留されていた要求メッセージを送信先ECU1~mにゲートウェイさせる。なお、一つのECU1~mに同時に複数のメッセージを送信できないため、送信が保留されていた一つのメッセージの転送を完了した後は、さらに当該ECU1~mに対する要求メッセージの送信保留状態判定を行なうことなく、ステップS1106の処理に移行する。以上、本発明の好ましい実施形態について説明したが、本発明は上述した実施形態になんら制限されることなく、本発明の主旨を逸脱しない範囲において、種々変形して実施することができる。例えば、上述した各実施形態では、通信状態カウンタが、ツール1~nからECU1~mに要求メッセージが転送されてからの経過時間をカウントし、その経過時間が所定時間に達したときに、要求メッセージに起因する通信が終了したものとみなすようにしていた。しかしながら、DoIPゲートウェイ101に、ECU1~mからツール1~nに向けて送信される応答メッセージの解読機能を持たせ、ツール1~nからの要求メッセージに対して、ECU1~mから、その要求メッセージに応答する旨の肯定応答メッセージがDoIPゲートウェイ101にて受信され、その肯定応答メッセージをツール1~nに転送したとき、通信状態カウンタに、その転送した時点からの経過時間をカウントさせるようにしても良い。この場合も、当該ツール1~nから新たなメッセージを受信することなく、通信状態カウンタによりカウントされる経過時間が所定時間に達したときに、要求メッセージに起因する通信が終了したとみなすことができる。また、ECU1~mからの応答メッセージの内容が、ツール1~nからの要求メッセージに対する否定応答であった場合に、DoIPゲートウェイ101は、通信状態情報における、その要求メッセージを送信したツール1~nに関する送信元情報及び要求メッセージの種別情報を消去するとともに、通信状態カウンタによるカウント処理を停止させるようにしても良い。DoIPゲートウェイ101は、ツール1~nからの要求メッセージをECU1~mに転送した時点で、そのツール1~nを示す送信元情報、転送したメッセージの種別情報を記憶しており、さらに、通信状態カウンタにカウント動作を開始させている。しかし、上述したように、要求メッセージを受け取ったECU1~mから否定応答メッセージが送信された場合、その時点で、ツール1~nとECU1~m間の通信は終了する。そのため、ECU1~mからの応答メッセージの内容が否定応答を示すものであった場合には、通信終了とみなして、DoIPゲートウェイが、上述したような処理を行うことが好ましい。これにより、通信状態情報として正しい情報のみが記憶されるようになり、その後の要求メッセージの受信に影響を及ぼさないようにすることができる。なお、ECU1~mは、自身がサポートしていない種別の要求メッセージを受信したとき、要求メッセージの内容に誤り等があり、その内容を認識できないとき、ツール1~nが上述したセッション移行を行うことなく、制限範囲外の要求メッセージを送信してきたときなど、要求メッセージに応答しない旨を否定応答メッセージによりツール1~nに伝える。"