"予め定められた機能を実行する1以上のサーバと、前記サーバとの通信の確立を要求するための要求信号を送信する1以上のクライアントと、前記サーバと前記クライアントとの間に介在し、前記サーバと前記クライアントとの通信を調停する1つの調停部と、が、ネットワーク上に配置され、前記調停部は、前記サーバの通信状態を取得する通信状態取得部を含み、前記要求信号を受信したとき、該要求信号の対象となるサーバの通信状態に基づいて、該クライアントと該サーバとの通信の確立を許可するか否かを決定することを特徴とする車両用電子制御装置。前記調停部は、前記要求信号の対象となるサーバが他のクライアントと通信中のとき、前記要求信号の送信元のクライアントと前記他のクライアントの通信の優先順位に基づいて、前記要求信号の送信元のクライアントと該要求信号の対象となるサーバとの通信と、該サーバと前記他のクライアントとの通信とのうち、いずれを優先させるかの調停を行う請求項1に記載の車両用電子制御装置。前記要求信号は、複数の通信フレームにより構成され、前記調停部と前記クライアントとの間の通信は1フレーム単位で行われ、前記調停部は、前記要求信号の最初の通信フレームを受信したときに前記調停を行う請求項2に記載の車両用電子制御装置。前記調停部は、前記要求信号に含まれるデータ内容に基づいて、前記要求信号の送信元のクライアントと該要求信号の対象となるサーバとの通信と、該サーバと前記他のクライアントとの通信とのうち、いずれを優先させるかの調停を行う請求項2または請求項3に記載の車両用電子制御装置。前記クライアントは、それぞれ通信の優先順位が予め定められ、前記調停部は、前記要求信号に含まれる前記優先順位に基づいて、前記要求信号の送信元のクライアントと前記要求信号の対象となるサーバとの通信と、該サーバと前記他のクライアントとの通信とのうち、いずれを優先させるかを決定する請求項2ないし請求項4のいずれか1項に記載の車両用電子制御装置。前記調停部は、前記要求信号の送信元のクライアントの前記優先順位が、前記他のクライアントの前記優先順位よりも低いとき、該クライアントに対し、前記サーバとの通信が可能になるまで待機する旨の応答、あるいは、該サーバとの通信を不許可とする旨の応答のいずれかを行う請求項2ないし請求項5のいずれか1項に記載の車両用電子制御装置。前記調停部は、前記要求信号の送信元のクライアントの前記優先順位が、前記他のクライアントの前記優先順位よりも高いとき、前記サーバと前記他のクライアントとの通信を中断あるいは中止させて、前記要求信号の送信元のクライアントと前記要求信号の対象となるサーバとの通信を許可する請求項2ないし請求項6のいずれか1項に記載の車両用電子制御装置。前記要求信号は、前記ネットワーク上に備えられる全ての前記サーバに対するもので、前記調停部は、全ての前記サーバの通信状態に基づいて、該クライアントと該全てのサーバとの通信を許可するか否かを決定する請求項1ないし請求項7のいずれか1項に記載の車両用電子制御装置。前記調停部は、前記サーバあるいは前記クライアントのいずれか1つに備えられる請求項1ないし請求項8のいずれか1項に記載の車両用電子制御装置。前記サーバあるいは前記クライアントを含む通信ネットワークは複数あり、その通信ネットワーク毎に前記調停部と接続する請求項1ないし請求項9のいずれか1項に記載の車両用電子制御装置。前記調停部は、前記ネットワーク上に複数備えられる請求項1ないし請求項10のいずれか1項に記載の車両用電子制御装置。図22に、従来技術によるダイアグ通信の概要を示す。図22では、ECUを、故障診断結果を記憶し、クライアントの要求にしたがって通信出力する機能を含むため、サーバと称している。ダイアグ通信による故障診断は、上述のように、主として修理工場やディーラ等で、ダイアグテストツールクライアント1により車内LAN40に接続してアクセスするといった限られた範囲から、遠隔地からパソコンクライアント2等でインターネット等を経由し車内LAN40に接続してリモート診断したり、車内LAN40上の車両用ナビゲーション装置ナビ:クライアント3等の車載装置を用いる等、通信形態が変化しつつある。このように、サーバにアクセス可能なクライアントが増加すると、複数のクライアントから1つのサーバに同時にアクセスする状況も生ずる。しかし、サーバが1台のクライアントとしか通信できない構成のとき、あるいはサーバの処理能力が高くないときには、同時に複数のクライアントから要求信号が送られてくると、サーバ側で通信調停を行う必要がある。サーバ1~3はECUであるため、周知のマイクロコンピュータマイコンともいう,メモリ,センサ信号を取り込む入力回路,アクチュエータを動作させるためのドライバ回路,他のECUとのデータ通信を行う通信回路を含んでいる。但し、図22においては、後述する本発明の構成に関連する各クライアント1~3との通信機能クライアント1通信機能101等および調停機能104等を示すにとどめ、ECU自体の機能の詳細な説明は割愛する。クライアント通信機能は、例えば周知のLAN通信インターフェース回路として構成され、マイコンの制御に基づいて動作する。また、調停機能は、例えば上述のメモリに記憶された、マイコンが実行するプログラムとして構成される。クライアント1~3は、上述のように、それぞれ、ダイアグテストツール,パソコン,ナビに相当しているが、サーバと同様に、後述する本発明の構成に関連する、他のクライアントとの調停機能11,12等および通信機能13等を示すにとどめ、各装置が有する本来の機能の詳細な説明は割愛する。他のクライアントとの調停機能は、例えば、それぞれの装置で実行されるプログラムとして構成され、通信機能は、LAN通信インターフェース回路,無線通信回路として構成される。そして、各サーバと各クライアントとは、車内LAN40によりネットワーク接続されている。無論、リモート端末となるクライアント2も、例えば、車内LAN40に接続された無線通信機図示せずを介して、車内LAN40に接続している。以下、従来技術による通信調停の概要を述べる。通信調停にはクライアント同士で調停する方法と、サーバ内で調停する方法とがある。クライアント同士で調停する方法は、例えばトークンのような送信権を設定し、この送信権をクライアントが例えば予め定められた順序で獲得し、通信が終了したら通信を行う必要がないときも送信権を開放し、次のクライアントが獲得する。クライアント1が送信権を獲得すると、クライアント2との調停機能11およびクライアント3との調停機能12を用いて、クライアント2およびクライアント3にサーバとの通信を行わないよう、データを送信する。そして、クライアント1がサーバ1に要求信号を送信すると、サーバ1がそれに応じて応答信号を返送する。このとき、クライアント2がサーバ1に要求信号を送信しても、サーバ1は通信を行うことができない旨の否定応答信号を返送するか、クライアント1以外からの要求信号に対しては全く応答しない。上述の構成では、クライアントが増加すると、他の全てのクライアントに、新しいクライアントとの調停機能ハード,ソフトのうちの少なくとも一方を組み込む必要があり、そのためにROMやRAMの容量に余裕を持たせておかなければならず、コストアップにつながるという課題を生ずる。また、サーバ内で調停する方法は、例えば、サーバ1がクライアント1との通信中に、クライアント2からの通信要求を受信したときには、サーバ1自身が調停機能104を用いて調停を行い、その要求に応答できない旨否定応答をクライアント2に送信する。上述の構成では、クライアントが増加すると、全てのサーバに新しいクライアントとの通信機能ハード,ソフトを追加するとともに、調停機能の対象に新しいクライアントを含めるための改造ソフトの修正等を行う必要があり、いずれもコストアップにつながるという課題を生ずる。上記のような背景に基づいて、本発明の課題は、車両に搭載されたサーバに接続するためのクライアントを追加する際の改造範囲をより小さくし、低コストで改造を行うことが可能な車両用電子制御装置を提供することにある。以下、本発明の車両用電子制御装置について、図面を用いて説明する。図1に、車両用電子制御装置の構成を示す。なお、本構成は、図22の構成において機能を追加削除したものであるため、図22と同様の構成のものについては同一の符号を付与し、ここでの詳細な説明は割愛する。クライアント1~3は、図22の構成から、他のクライアントとの調停機能11,12等:破線枠で表記したものが削除されている。また、通信機能13等は、主に調停ECU1を介してサーバ1~3との通信を行うための通信インターフェースである。サーバ1~3は、図22の構成から、各クライアントとの通信機能のうちの一つがクライアント通信機能111等に置き換わり、残り破線枠で表記したものは削除されている。クライアント通信機能は、主に調停ECU1を介してクライアント1~3との通信を行うための通信インターフェースである。調停ECU1は、図22の構成では各サーバに含まれていた、各クライアントとの通信機能101等および調停機能104等を1か所クライアント1通信機能51,クライアント2通信機能52,クライアント3通信機能53,調停機能54に集約したものである。上述のように、従来はクライアント同士、あるいは、サーバ内で調停していたものを、本発明では、調停ECU1で調停するようにしている。これにより、各クライアント内の、各クライアントとの調整機能、およびサーバ内の調整機能とクライアント毎の通信機能が不要となる。なお、調停ECU1が本発明の調停部に相当する。また、調停機能54が本発明の通信状態取得部に相当する。調停ECUを複数設けてもよい。図1では、調停ECU2が設けられている。構成は調停ECU1と同様である。そして、例えば、調停ECU1は、各クライアントからのサーバ2およびサーバ3に対する要求本発明の要求信号、以下も同様を調停し、調停ECU2は、各クライアントからのサーバ1に対する要求を調停する。但し、通信効率やコストの面を考慮すると、特にクライアント数が少ないときには、調停ECUは1台であることが望ましい。また、サーバ5を車内LAN40とは別のネットワークである車内LAN41を介して調停ECU1に接続する構成としてもよい。これにより、他の通信系に接続されているサーバへの要求も調停することが可能となる。また、従来構成の、各クライアントとの通信機能401~403および調停機能404を備えるサーバ4を車内LAN40に接続する構成としてもよい。この場合、調停ECU1,調停ECU2は、サーバ4に対する要求の調停は行わず、通信データの中継のみ行う。このように、新旧のサーバが混在する環境下でも、調停ECU1は柔軟に対応できる。無論、サーバ4の調停機能も調停ECU1に集約することが望ましい。また、調停ECU1の、クライアント通信機能51~53および調停機能54をサーバ1~3,クライアント1~3のいずれかに含めてもよい。特に、エンジンECUは、内燃機関を有する車両ハイブリッド車両を含むには必ず搭載されているので、調停部として適している。また、電気自動車ハイブリッド車両を含むでは、調停部を、駆動用モータを制御するモータ制御ECUに含めることが適している。図2に、ダイアグ通信を例に挙げて、サーバ~クライアント間の通信について説明する。図2の左側は、送信するデータが1つのフレームにより構成されるシングルフレームSingleFrame:SFによる通信を示したもので、右側は、送信するデータが複数のフレームにより構成されるマルチフレームMultiFrame:MFによる通信を示したものである。シングルフレーム通信の場合は、クライアントがサーバに対して何らかの要求例えば、故障診断用のデータであるダイアグデータの送信要求を送信すると、サーバでその要求を解析し、解析結果に応じたサービスデータ読み出し等を実行し、その結果読み出したデータ等をクライアントに送信する。シングルフレーム通信では、1フレーム=1メッセージであるため、フレームレベルでの調停ができないので、メッセージ単位での調停を行う。マルチフレーム通信の場合は、クライアントがサーバに対して何らかの要求データ要求を行う要求を送信する際、まず、マルチフレームMFで構成される要求の先頭フレームFirstFrame:FFを送信する。サーバは、先頭フレームFFを受信すると、受信可能な旨を含むFCFlowControlをクライアントに送信する。クライアントは、該FCを受信すると、要求の残りのフレームConsecutiveFrame:CFを順次送信する。サーバは、全フレームを受信すると、その要求を解析し、解析結果に応じたサービスを行い、その結果をマルチフレームでクライアントに送信する。すなわち、まず、サーバは、応答の先頭フレームFFを送信し、クライアントからの受信可能な旨を含むFCを受信した後、応答の残りのフレームCFを順次送信する。マルチフレーム通信では、複数フレーム=1メッセージであるため、フレーム単位での調停が必要となる。なお、CANベースの診断インターフェースは、ISO15765-2フレームに関するもの,ISO14229-1メッセージの構築に関するものの規定に基づいている。以下、調停ECU1におけるメッセージ単位およびフレーム単位での調停の詳細について説明する。なお、調停の優先順位は、以下のうちの一つ、あるいは複数の組み合わせを用いる。先に要求信号を受信したクライアントを優先する。後から要求信号を受信したクライアントを優先する。予めクライアントに優先順位を設定し、要求信号を受信したクライアントの優先順位を比較する。例えば、ダイアグテストツール優先順位:高>車載装置ナビ等>リモート端末優先順位:低。要求信号の内容に応じて優先順位が予め定められる。例えば、要求信号に含まれるSID:サービスIDに優先順位を含ませる。優先順位は調停ECU1に記憶する。図3~図7を用いて、調停の詳細の第1実施例について説明する。本実施例では、以下のように調停を行う。メッセージ単位の調停:現在サーバと通信中のクライアントよりも優先順位の低いクライアントからの要求は受け付けない。フレーム単位の調停:現在サーバと通信中のクライアントよりも優先順位の低いクライアントからの要求があったときには、その要求を受け付け、現在サーバと通信中のクライアントの処理終了後に、サーバとの通信を許可する。図3を用いて、本実施例における車両用電子制御装置の構成の概要を説明する。本実施例では、クライアント2とクライアント3からのサーバ3に対する要求を調停ECU1が調停する。調停ECU1は、図1の構成に加え、クライアント2通信機能52に含まれるクライアント2用受信部52a、クライアント3通信機能53に含まれるクライアント3用受信部53a、クライアント2,3にデータを送信する送信部55対象クライアント毎にクライアント2通信機能52,クライアント3通信機能53に送信部を含む構成でもよい、図示しないメモリの一部に確保される要求退避用バッファ56を備えている。図4を用いて、先にサーバ3とクライアント3とが通信中のときに、クライアント3よりも優先順位の低いマルチフレーム通信を行うクライアント2からの要求が送信されときの調停のうち、フレーム単位の調停の詳細について説明する。クライアント3からの要求31SFを受信した調停ECU1は、要求先のサーバ3がアイドル状態であるとき、その要求を要求11SFとしてサーバ3に送信する。サーバ3は、受信した要求11に基づいて図2で説明したような処理を実行し処理中1、処理結果を応答11SFとして調停ECU1に送信する。調停ECU1は、受信した応答11を応答31SFとしてクライアント3に送信する。調停ECU1がクライアント3からの要求31を受信して、サーバ3に要求11SFを送信し、サーバ3と通信中のときに、クライアント2からの要求21の先頭フレームFFを受信したとき、クライアント2に対し、受信可能な旨を含むFCを送信する。クライアント2は、該FCを受信すると、要求の残りのフレームCFを、調停ECU1に順次送信する。クライアント2からの要求は、要求退避用バッファ56に記憶する。調停ECU1は、サーバ3がクライアント3からの要求に対する処理処理中1が終了するのを待つ。すなわち、サーバ3から応答11SFが送信されてくるのを待つ。そして、サーバ3からの応答11SFを受信すると、クライアント3にその旨を応答31SFとして送信する。その後、クライアント2からの要求データが要求退避用バッファ56に記憶されているとき、これを読み出して要求12SFとしてサーバ3に送信する。サーバ3は、受信した要求12に基づいて図2で説明したような処理を実行し処理中2、処理結果を応答12SFとして調停ECU1に送信する。調停ECU1は、受信した応答12を応答22FFとしてクライアント2に送信する。以降、図2と同様に、クライアント2からの受信可能な旨を含むFCデータを受信した後、応答の残りのフレームCFを順次送信する。図5を用いて、メッセージ単位の調停のうち、先にサーバ3と通信中のクライアント3よりも優先順位の低いクライアント2からの要求が送信されたときの調停の詳細について説明する。サーバ3は、クライアント3からの要求に基づく処理のみを実行する。クライアント2からの要求は拒否する。調停ECU1がクライアント3からの要求31を受信して、サーバ3に要求11SFを送信し、サーバ3と通信中のときに、クライアント2からの要求21SFを受信したとき、調停ECU1はクライアント2に対し、要求を受け入れない旨を含む否定応答コードSFを送信する。否定応答は、例えば21十六進数の21で示される。クライアント2は、該否定応答を受信すると、要求に関する処理を終了する。また、調停ECU1がクライアント2からの要求21を受信したとき、調停ECU1はその要求に対し無応答としてもよい。クライアント2では、要求21を送信してからの経過時間を測定し、予め定められた時間が経過したすなわち、応答待ちタイムアウトしたときに、調停ECU1では要求が受け入れられなかったと判断し、要求に関する処理を終了する。すなわち、クライアントは、要求信号を送信後、予め定められた時間内に調停部からの応答を受信しないときには、該要求信号に基づくサーバとの通信が許可されたかったと判定する構成となる。なお、図5におけるクライアント3とサーバ3との通信シーケンスは、図4と同様である。図6を用いて、メッセージ単位の調停のうち、先にサーバ3と通信中のクライアント3よりも優先順位の高いクライアント2からの要求が送信されてきたときの調停の詳細について説明する。サーバ3は、クライアント3からの要求に基づく処理を中止し、以降、クライアント2からの要求に基づく処理のみを実行する。調停ECU1がクライアント3からの要求31SFを受信して、サーバ3に要求11SFを送信し、サーバ3と通信中処理中1のときに、クライアント2からの要求21SFを受信したとき、調停ECU1はクライアント3に対し、処理を中止し要求を受け入れない旨を含む否定応答SFを送信する。否定応答は、例えば21十六進数の21で示される。クライアント3は、該否定応答を受信すると、要求に関する処理を終了する。次に、調停ECU1は、クライアント2からの要求を受け入れ、クライアント2からの要求を要求12SFとしてサーバ3へ送信する。サーバ3は、要求12を受信すると、クライアント3からの要求に基づく処理処理中1を中止し、要求12に基づく処理を実行する処理中2の状態となる。そして、処理が終了すると、処理結果を応答12SFとして調停ECU1に送信する。調停ECU1は、応答12を受信すると、応答22SFとしてクライアント2に送信する。図7に、図3~図6における、調停ECU1で実行されるプログラムに含まれる調停処理のフローを示す。クライアント図3~図6では、クライアント2に相当からダイアグ要求図3~図6では、要求と略記を受信したとき、その要求がシングルフレームSF通信によるものか否かを判定するS11。シングルフレーム通信によるものではないときS12:No、図4のように、マルチフレームMFの残りのフレームを受信するS15。そして、ステップS13へ進む。一方、シングルフレーム通信によるものであるときS12:Yes、ステップS13へ進む。ステップS13では、要求先のサーバ図3~図6では、サーバ3に相当が他のクライアント図3~図6では、クライアント3に相当と通信中図7では、ダイアグ通信中と表記であるか否かを判定する。ダイアグ通信中、つまり他のクライアントの要求に基づく処理を実行中のときS13:Yes、クライアント2,3の優先度を比較する。クライアント2の優先度が低いときS16:No、クライアント2へ否定応答21を送信するS17,図5に相当。一方、ダイアグ通信中でないときS13:No、あるいは、クライアント2の優先度が高いときS16:Yes、クライアント2からの要求をサーバ3へ送信するS14,図4の後半部あるいは図6に相当。なお、クライアント2の優先度が高いときS16:Yes、先にサーバ3と通信中のクライアント3に否定応答21を送信してもよい図6に相当。サーバ3は、クライアント3の要求に基づく処理を中止し、クライアント2の要求に基づく処理を実行する。また、クライアント3では、調停ECU1へ要求31を送信してから所定時間以内に調停ECU1からの応答31を受信しないときには、要求が受け入れられなかったと判断して、該要求に関する処理を終了してもよい。図8~図13を用いて、調停の詳細の第2実施例について説明する。本実施例では、以下のように調停を行う。メッセージ単位の調停:優先順位の低いクライアントからの要求信号を待たせて、優先順位の高いクライアントの処理実行後に、優先順位の低いクライアントの処理を実行する。フレーム単位の調停:優先順位の低いクライアントからの要求信号を待たせて、優先順位の高いクライアントの処理実行後に、優先順位の低いクライアントの処理を実行する。すなわち、現在サーバと通信中のクライアントよりも優先順位の高いクライアントからの要求信号があったときには、その要求信号を受け付け、現在サーバと通信中のクライアントの通信を中断して、サーバと優先順位の高いとの通信を行い、該通信終了後に、中断していたサーバとクライアントとの通信を再開する構成である。本実施例では、クライアント2とクライアント3からのサーバ3に対する要求を調停ECU1が調停する。図8の調停ECU1等の構成は、図3と同様である。なお、クライアント2用受信部52a,クライアント3用受信部53aは、一括して受信部として表記してある。図9を用いて、先にサーバ3とクライアント3とが通信中のときに、クライアント3よりも優先順位の低いシングルフレーム通信を行うクライアント2からの要求が送信されたときの、メッセージ単位の調停の詳細について説明する。調停ECU1がクライアント3からの要求31を受信して、サーバ3に要求11SFを送信し、サーバ3と通信中すなわち、クライアント3からの要求に基づく処理を実行中のときに、クライアント2からの要求21SFを受信したとき、調停ECU1はクライアント2に対し、要求は受け入れたが直ちに処理を行うことができない旨の否定応答コードSFを送信する。否定応答は、例えば78十六進数の78で示される。クライアント2は、該否定応答を受信すると、調停ECU1からの応答を受信するまで待機する。クライアント2からの要求21は、要求退避用バッファ56に記憶する。なお、否定応答は、1回のみ送信してもよいし、予め定められたタイミング例えば、クライアント2で通信のタイムアウトを判定しないような周期で送信してもよい。サーバ3での処理処理中1が終了し、サーバ3が調停ECU1に処理結果を応答11SFとして送信すると、調停ECU1は、これを応答31SFとしてクライアント3に送信する。その後、クライアント2からの要求21を要求退避用バッファ56に記憶してあるとき、これを読み出して要求12としてサーバ3に送信する。サーバは要求12を受信すると、その要求に応じた処理を実行する図4の処理中2のシーケンスに準ずる。図10を用いて、先にサーバ3とクライアント3とが通信中のときに、クライアント3よりも優先順位の低いマルチフレーム通信を行うクライアント2からの要求が送信されたときの、フレーム単位の調停の詳細について説明する。調停ECU1がクライアント3からの要求31を受信して、サーバ3に要求11SFを送信し、サーバ3と通信中すなわち、処理中1のときに、クライアント2からの要求21FFを受信したとき、調停ECU1はクライアント2に対し、要求は受け入れたが直ちに処理を行うことができないため待機を指示する旨のFCを送信する。クライアント2は、該FCを受信すると、調停ECU1からの応答を受信するまで待機する。クライアント2からの要求21は、要求退避用バッファ56に記憶する。なお、FCは、1回のみ送信してもよいし、予め定められたタイミング例えば、クライアント2で通信のタイムアウトを判定しないような周期で送信してもよい。サーバ3での処理が終了し、サーバ3が調停ECU1に処理結果を応答11SFとして送信すると、調停ECU1は、これを応答31SFとしてクライアント3に送信する。その後、クライアント2からの要求21を要求退避用バッファ56に記憶してあるとき、データを受信可能な旨を含むFCをクライアント2に送信する。クライアント2は、該FCを受信すると、要求データの残りのフレームCFを順次送信する。調停ECU1は、CFを全フレーム受信すると、要求12としてサーバ3に送信する。サーバは要求12を受信すると、その要求に応じた処理を実行する図4の処理中2のシーケンスに準ずる。なお、図10の構成で、クライアント2からの要求を受け入れないときには、ECU1はクライアント2に最初のFCを送信するタイミングで、図5のような否定応答21:SFを送信する。図11を用いて、先にサーバ3と通信中のクライアント3よりも優先順位の高いクライアント2からの要求が送信されてきたときの、メッセージ単位の調停の詳細について説明する。調停ECU1がクライアント3からの要求31を受信して、サーバ3に要求11SFを送信し、サーバ3と通信中すなわち、処理中1のときに、クライアント2からの要求21SFを受信したとき、調停ECU1はサーバ3にクライアント2からの要求21を要求12として送信する。このとき、クライアント3に対して、要求は受け入れたが直ちに処理を行うことができない旨の否定応答コードSFを送信してもよい。否定応答は、例えば78十六進数の78で示される。また、クライアント3からの要求31に基づく処理が終了していないことを、要求退避用バッファ56に記憶する。なお、否定応答は、1回のみ送信してもよいし、予め定められたタイミング例えば、クライアント3で通信のタイムアウトを判定しないような周期で送信してもよい。サーバ3は調停ECU1からの要求12を受信すると、クライアント3に対応する処理処理中1を一時停止し、必要なデータを退避する。そして、調停ECU1からの要求12に基づくクライアント2に対応する処理処理中2を実行する。サーバ3でのクライアント2に対応する処理が終了し、サーバ3が調停ECU1に、処理結果を応答12SFとして送信すると、調停ECU1は、これを応答21SFとしてクライアント2に送信する。サーバ3は、要求退避用バッファ56に、クライアント3からの要求31に基づく処理が終了していないことを記憶してある場合には、クライアント3に対応する処理を再開し処理中11、該処理が終了すると、処理結果を調停ECU1に応答11SFとして送信する。調停ECU1は、これを応答31SFとしてクライアント3に送信する。調停ECU1は、サーバ3からの応答12SFを受信したときに、要求退避用バッファ56に、クライアント3からの要求31に基づく処理が終了していないことを記憶してある場合には、サーバ3に対し、クライアント3からの要求31に基づく処理を再開する旨のメッセージを送信してもよい。図12を用いて、先にサーバ3と通信中のクライアント3よりも優先順位の高いクライアント2からの要求信号が送信されてきたときの、フレーム単位の調停の詳細について説明する。調停ECU1がクライアント3からの要求31を受信して、サーバ3に要求11SFを送信し、サーバ3と通信中すなわち、処理中1のときに、クライアント2からの要求21FFを受信したとき、調停ECU1は、データを受信可能な旨を含むFCをクライアント2に送信する。クライアント2は、該FCを受信すると、要求データの残りのフレームCFを順次送信する。調停ECU1はクライアント2からのフレームを全て受信すると要求21FFを受信したときでもよい、調停ECU1はサーバ3にクライアント2からの要求21を要求12として送信する。このとき、クライアント3に対して、要求は受け入れたが直ちに処理を行うことができない旨の否定応答コードSFを送信してもよい。否定応答は、例えば78十六進数の78で示される。また、クライアント3からの要求31に基づく処理が終了していないことを、要求退避用バッファ56に記憶する。なお、否定応答は、1回のみ送信してもよいし、予め定められたタイミング例えば、クライアント3で通信のタイムアウトを判定しないような周期で送信してもよい。サーバ3は調停ECU1からの要求12を受信すると、調停ECU1からの要求11に基づくクライアント3に対応する処理処理中1を一時停止し、必要なデータを退避する。そして、調停ECU1からの要求12に基づくクライアント2に対応する処理処理中2を実行する。サーバ3でのクライアント2に対応する処理が終了し、サーバ3が調停ECU1に処理結果を応答12SFとして送信すると、調停ECU1は、これを応答21SFとしてクライアント2に送信する。その後、サーバ3は、要求退避用バッファ56に、クライアント3からの要求31に基づく処理が終了していないことを記憶してある場合には、クライアント3に対応する処理を再開し処理中11、該処理が終了すると、調停ECU1に処理結果を応答11SFとして送信する。調停ECU1は、これを応答31SFとしてクライアント3に送信する。調停ECU1は、サーバ3から応答12SFを受信したときに、要求退避用バッファ56に、クライアント3からの要求31に基づく処理が終了していないことを記憶してある場合には、サーバ3に対し、クライアント3からの要求31に基づく処理を再開する旨のメッセージを送信してもよい。図13に、図8~図12における、調停ECU1で実行されるプログラムに含まれる調停処理のフローを示す。クライアント図8~図12では、クライアント2に相当からダイアグ要求図8~図12では、要求と略記を受信したとき、その要求がシングルフレームSF通信によるものか否かを判定するS31。要求がシングルフレーム通信によるものでないときS32:No、クライアント2,3の優先度を比較する。クライアント2の優先度が低いときS35:No、クライアント2へ待機を指示する旨のFCを送信するS36。そして、クライアント3と要求先サーバサーバ3のダイアグ通信が終了するのを待つ。この間、予め定められたタイミングでクライアント2へFCを送信するS36。クライアント3と要求先サーバサーバ3のダイアグ通信が終了したときS37:Yes、クライアント2からの残りの要求データCFを受信しS38、ステップS33へ進む。一方、要求がシングルフレーム通信によるものであるときS32:Yes、あるいは、クライアント2の優先度が高いときS35:Yes、ステップS33へ進む、ステップS33では、クライアント3と要求先サーバサーバ3との間でダイアグ通信中であるか否かを判定する。ダイアグ通信中であるときS33:Yes、クライアント2,3の優先度を比較する。クライアント2の優先度が低いときS39:No、クライアント2へ直ちに処理を実行できないため待機を指示する旨の否定応答78SFを送信するS40。そして、クライアント3と要求先サーバサーバ3のダイアグ通信が終了するのを待つ。この間、予め定められたタイミングでクライアント2へ否定応答78を送信するS40。クライアント3と要求先サーバサーバ3のダイアグ通信が終了したときS41:Yes、ステップS34へ進む。一方、ダイアグ通信中でないときS33:No、あるいは、クライアント2の優先度が高いときS39:Yes、ステップS34へ進む、ステップS34では、クライアント2からの要求ダイアグ要求をサーバ3へ送信する。また、他のクライアント3とダイアグ通信中のとき、該クライアント3へ否定応答78を送信する。以下、1台のクライアントから複数のサーバに一斉に要求以下、一斉通信要求というを送信したときの、調停ECU1における調停の詳細について説明する。まず、図14図22に準ずる,図15を用いて、従来の構成による調停方法について説明する。クライアント間で調停を行う場合には、クライアント1が、クライアント2およびクライアント3との調停機能11,12を用いて通信権を獲得した後に、全サーバ1~3に要求1を送信する。これは、サーバ毎に要求を送信するのではなく、1個のデータに全サーバに対する要求を行う意味を持たせる。要求を受信した各サーバは、それぞれ応答3~5を送信する。また、サーバ側で調停を行う場合には、クライアント1からの要求1を受信したときに、それぞれの調停機能104,204,304を用いて調停を行った後、それぞれ応答3~5を送信する。この場合、調停の結果、クライアント1からの要求1が優先されないこともありうる。クライアント1が、全サーバからの応答の全てを用いて何らかの解析を行う場合、データが揃わないため解析を実行できないこともある。また、優先されたクライアントの処理が終わった後に、サーバから遅れて応答が送信されたときも、応答データ間の同期がとれないという課題が生ずる。図16~図18を用いて、クライアントから一斉通信要求を受信したときの、調停ECU1における調停の詳細の第1実施例について説明する。本実施例では、1台でも他のクライアントとの通信を行っているサーバがあるときには、一斉通信要求を拒否する構成となっている。図16の構成は、図3の構成に、サーバ1,サーバ2を追加し、調停ECU1の要求退避用バッファ56を含まないものであるため、ここでの詳細な説明は割愛する。なお、クライアント2用受信部52a,クライアント3用受信部53aは、一括して受信部として表記してある。図17のように、調停ECU1がクライアント3からの要求31を受信して、サーバ3に要求11SFを送信し、サーバ3と通信中すなわち、処理中のときに、クライアント2からの要求21一斉通信要求:SF,MFのいずれでもよいを受信したとき、調停ECU1はクライアント2に対し、要求は受け入れることができない旨の否定応答コードSFを送信する応答21。否定応答は、例えば21十六進数の21で示される。否定応答コードは、図17のように、調停ECU1が各サーバを代行する形でクライアント2に送信してもよいし、1つのメッセージにすべてのサーバを代行する内容を含む形で送信してもよい。この間、サーバ3は、クライアント3からの要求に基づく処理を継続し、処理が終了すると、調停ECU1に処理結果を応答11SFとして送信する。調停ECU1は、これを応答31SFとしてクライアント3に送信する。図18に、図16,図17における、調停ECU1で実行されるプログラムに含まれる調停処理のフローを示す。まず、クライアント図16,図17では、クライアント2に相当からダイアグ要求図16,図17では、要求21と表記を受信したとき、その要求がシングルフレームSF通信によるものか否かを判定するS51。要求がシングルフレーム通信によるものであるときS52:Yes、要求先サーバサーバ1~3の全てについてダイアグ通信中であるか、すなわち他のクライアントからの要求に基づく処理を行っているか否かを調べる。一方、マルチフレームMF通信によるものであるときS52:No、例えば図4のように、残りのフレームを受信しS55、要求先サーバサーバ1~3の全てについてダイアグ通信中であるか否かを調べる。マルチフレームMF通信のとき、先頭フレームFFを受信したら、要求先サーバの全てについてダイアグ通信中であるか否かを調べてもよい。そして、要求先サーバのうちの全てがダイアグ通信中でないときS53:No、全サーバへ要求を送信するS54。この後、各サーバで要求に対応する処理を実行し、調停ECU1でその結果を受信すると、例えば、サーバからの受信順にクライアント2へ送信する図15の応答3,4,5に相当。一方、要求先サーバの一つでもダイアグ通信中であるときS53:Yes、クライアント2へ、要求に応じない旨を示す否定応答コード21を含む応答21を送信するS56。上述の構成で、サーバ3が、クライアント3からの要求に基づく処理を終了した後に、調停ECU1が全サーバに対して、クライアント2からの要求を送信するようにしてもよい。図19~図21を用いて、クライアントから一斉通信要求を受信したときの、調停の詳細の第2実施例について説明する。本実施例では他のクライアントとの通信を行っていないサーバについては、該要求に対応する処理を実行する。一方、他のクライアントとの通信を行っているサーバについては、否定応答コード21を送信して要求を拒否するか、否定応答コード78を送信して他のクライアントとの通信終了後に処理を行うかのいずれかとする。図19の構成は、図3の構成に、サーバ1,サーバ2を追加したものであるため、ここでの詳細な説明は割愛する。図20のように、調停ECU1がクライアント3からの要求31を受信して、サーバ3に要求11SFを送信し、サーバ3と通信中すなわち、クライアント3からの要求に基づく処理を実行中のときに、クライアント2からの要求21一斉通信要求:SF,MFのいずれでもよいを受信したとき、調停ECU1は、サーバ1,サーバ2に対し、クライアント2からの要求21に対応する要求12を送信する。サーバ1,サーバ2は、他のクライアントからの要求に基づく処理を行っていないので、この要求12に基づく処理を実行し、その結果を応答12として調停ECU1に送信する。サーバ1,サーバ2から処理結果を受信した調停ECU1は、それらを受信次第、応答21としてクライアント2に送信する。サーバ3は、クライアント3からの要求に基づく処理を実行中であるため、調停ECU1は、以下のうちのいずれかの処理を行う。クライアント3からの要求に基づく処理を優先し、クライアント2からの要求は受け付けない。すなわち、調停ECU1は、クライアント2に、要求は受け入れることができない旨の否定応答コードSFを送信する応答21。否定応答は、例えば21十六進数の21で示される。クライアント3からの要求に基づく処理を優先し、クライアント2からの要求を待たせる。このとき、調停ECU1は、クライアント2に、要求は受け入れたが直ちに処理を行うことができない旨の否定応答コードSFを送信する。否定応答は、例えば78十六進数の78で示される。そして、クライアント3からの要求に基づく処理が終了した後に、サーバ3に、クライアント2からの要求21を要求12として送信する。サーバ3は、クライアント2からの要求に基づく処理を実行して、その結果を調停ECU1に送信する。クライアント2からの要求を優先し、サーバ3に要求12を送信する。サーバ3は、要求12を受信したら、クライアント3からの要求に基づく処理を中断し、クライアント2からの要求に基づく処理を実行して、その結果を調停ECU1に送信する。調停ECU1はサーバ3から受信した結果を応答21としてクライアント3に送信する。その後、サーバ3は、クライアント3からの要求に基づく処理を再開し、処理終了後、応答11を調停ECU1に送信する。そして、調停ECU1は応答11を応答31としてクライアント3に送信する。クライアント3の処理の中断再開に関するシーケンスは、図11に準ずる。図21に、図19,図20における、調停ECU1で実行されるプログラムに含まれる調停処理のフローを示す。まず、クライアント図19,図20では、クライアント2に相当からダイアグ要求図19,図20では、要求21と表記を受信したとき、その要求がシングルフレームSF通信によるものか否かを判定するS71。要求がシングルフレーム通信によるものであるときS72:Yes、上述のいずれかの方法により調停を行うS73。一方、マルチフレームMF通信によるものであるときS72:No、例えば図4のように、残りのフレームを受信しS74、上述のいずれかの方法により調停を行うS73。以上、本発明の実施の形態を説明したが、これらはあくまで例示にすぎず、本発明はこれらに限定されるものではなく、特許請求の範囲の趣旨を逸脱しない限りにおいて、当業者の知識に基づく種々の変更が可能である。"