車両用電子制御装置
【課題】車両に搭載されたサーバに接続するためのクライアントを追加する際の改造範囲をより小さくし、低コストで改造を行うことが可能な車両用電子制御装置を提供する。
【解決手段】予め定められた機能を実行する１以上のサーバと、サーバとの通信の確立を要求するための要求信号を送信する１以上のクライアントと、サーバとクライアントとの間に介在し、サーバとクライアントとの通信を調停する１つの調停部と、が、ネットワーク上に配置され、調停部は、サーバの通信状態を取得する通信状態取得部を含み、要求信号を受信したとき、該要求信号の対象となるサーバの通信状態に基づいて、該クライアントと該サーバとの通信の確立を許可するか否かを決定する。
【解決手段】予め定められた機能を実行する１以上のサーバと、サーバとの通信の確立を要求するための要求信号を送信する１以上のクライアントと、サーバとクライアントとの間に介在し、サーバとクライアントとの通信を調停する１つの調停部と、が、ネットワーク上に配置され、調停部は、サーバの通信状態を取得する通信状態取得部を含み、要求信号を受信したとき、該要求信号の対象となるサーバの通信状態に基づいて、該クライアントと該サーバとの通信の確立を許可するか否かを決定する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車両に搭載された各種装置と、ダイアグテストツールのようなデータ読み出し用端末との通信を効率よく行うための車両用電子制御装置に関する。
【背景技術】
【０００２】
車両には電子制御装置（「ＥＣＵ」ともいう）が多数、例えば、エンジンＥＣＵ、エンジンの駆動と停止を行いながら車両を走行させるエコランＥＣＵ、ドアやロックの制御を行うボデーＥＣＵ、自動変速（ＡＴ）制御ＥＣＵ、エアバッグＥＣＵ、盗難が発生した場合や盗難が発生する可能性がある事象を検知した場合に警報を発生するセキュリティＥＣＵ等のような電子制御装置（ＥＣＵ）が多数搭載されており、各ＥＣＵは、担当する制御対象について、単体で独自に制御しているが、他のＥＣＵとの情報の授受が必要な場合もある。
【０００３】
このため、車両に搭載する複数のＥＣＵを関連付けして各種制御を行うために、その複数のＥＣＵを共通のバスラインに接続するとともに、代表的標準ネットワーク・プロトコルであるコントロールエリアネットワーク（Controller Area Network、以下ＣＡＮという）プロトコル等を使用して相互通信制御を行っている。
【０００４】
また、各ＥＣＵは自己診断機能を備え、信頼性の向上が図られている。すなわち、各ＥＣＵはＣＰＵやセンサ類の動作状態を適当な周期で自動的にチェックし、故障時には異常ランプを点灯したり、その故障内容が修理業者に分かるように異常コードを記憶したりするダイアグノーシス（以下、ダイアグという）処理を行っている。そして、このような診断情報（「ダイアグ情報」ともいう）は、修理工場等において、ダイアグテストツール（故障診断用端末）のようなデータ読み出し用端末を診断コネクタ経由でＥＣＵに接続することにより読み出すことができ、修理工場では読み出した故障コードに応じた修理が可能となる。
【０００５】
ダイアグ通信はＣＡＮ通信を用いることが主流になりつつある。ダイアグ通信では、例えば、ＥＣＵがその要求を受けてから応答データの送信を開始するまでの時間等、その要求に対するＥＣＵの応答特性が法規で定められている。そこで、ダイアグテストツールの要求から車載ＥＣＵが最初の応答を行うまでの時間的な制約を満足することができるとともに、従来の車両も規格統一を図ることが可能な通信変換制御装置が考案されている（特許文献１参照）。
【０００６】
また、第１ＥＣＵにおいて、第２ＥＣＵからのアクセス要求を受けたとき、第３ＥＣＵからのアクセス要求に応じた処理を実行している最中であれば、その第３ＥＣＵからのアクセス要求に応じた処理を開始してからの経過時間と予め定められた一定時間とを比較し、経過時間が一定時間より短ければ、第３ＥＣＵからのアクセス要求に応じた処理を中止して第２ＥＣＵからのアクセス要求に応じた処理を開始し、経過時間が一定時間より長ければ、第３ＥＣＵからのアクセス要求に応じた処理が終了した後に第２ＥＣＵからのアクセス要求に応じた処理を開始する通信調停システムが考案されている（特許文献２参照）。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００６−３５２２０１号公報
【特許文献２】特開２００１−１１１５５９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
図２２に、従来技術によるダイアグ通信の概要を示す。図２２では、ＥＣＵを、故障診断結果を記憶し、クライアントの要求にしたがって通信出力する機能を含むため、サーバと称している。ダイアグ通信による故障診断は、上述のように、主として修理工場やディーラ等で、ダイアグテストツール（クライアント１）により車内ＬＡＮ４０に接続してアクセスするといった限られた範囲から、遠隔地からパソコン（クライアント２）等でインターネット等を経由し車内ＬＡＮ４０に接続してリモート診断したり、車内ＬＡＮ４０上の車両用ナビゲーション装置（ナビ：クライアント３）等の車載装置を用いる等、通信形態が変化しつつある。
【０００９】
このように、サーバにアクセス可能なクライアントが増加すると、複数のクライアントから１つのサーバに同時にアクセスする状況も生ずる。しかし、サーバが１台のクライアントとしか通信できない構成のとき、あるいはサーバの処理能力が高くないときには、同時に複数のクライアントから要求信号が送られてくると、サーバ側で通信調停を行う必要がある。
【００１０】
サーバ１〜３はＥＣＵであるため、周知のマイクロコンピュータ（マイコンともいう），メモリ，センサ信号を取り込む入力回路，アクチュエータを動作させるためのドライバ回路，他のＥＣＵとのデータ通信を行う通信回路を含んでいる。但し、図２２においては、後述する本発明の構成に関連する各クライアント（１〜３）との通信機能（クライアント１通信機能１０１等）および調停機能（１０４等）を示すにとどめ、ＥＣＵ自体の機能の詳細な説明は割愛する。クライアント通信機能は、例えば周知のＬＡＮ通信インターフェース回路として構成され、マイコンの制御に基づいて動作する。また、調停機能は、例えば上述のメモリに記憶された、マイコンが実行するプログラムとして構成される。
【００１１】
クライアント（１〜３）は、上述のように、それぞれ、ダイアグテストツール，パソコン，ナビに相当しているが、サーバと同様に、後述する本発明の構成に関連する、他のクライアントとの調停機能（１１，１２等）および通信機能（１３等）を示すにとどめ、各装置が有する本来の機能の詳細な説明は割愛する。他のクライアントとの調停機能は、例えば、それぞれの装置で実行されるプログラムとして構成され、通信機能は、ＬＡＮ通信インターフェース回路，無線通信回路として構成される。
【００１２】
そして、各サーバと各クライアントとは、車内ＬＡＮ４０によりネットワーク接続されている。無論、リモート端末となるクライアント２も、例えば、車内ＬＡＮ４０に接続された無線通信機（図示せず）を介して、車内ＬＡＮ４０に接続している。
【００１３】
以下、従来技術による通信調停の概要を述べる。通信調停にはクライアント同士で調停する方法と、サーバ内で調停する方法とがある。クライアント同士で調停する方法は、例えばトークンのような送信権を設定し、この送信権をクライアントが例えば予め定められた順序で獲得し、通信が終了したら（通信を行う必要がないときも）送信権を開放し、次のクライアントが獲得する。クライアント１が送信権を獲得すると、クライアント２との調停機能１１およびクライアント３との調停機能１２を用いて、クライアント２およびクライアント３にサーバとの通信を行わないよう、データを送信する。そして、クライアント１がサーバ１に要求信号を送信すると、サーバ１がそれに応じて応答信号を返送する。このとき、クライアント２がサーバ１に要求信号を送信しても、サーバ１は通信を行うことができない旨の否定応答信号を返送するか、クライアント１以外からの要求信号に対しては全く応答しない。
【００１４】
上述の構成では、クライアントが増加すると、他の全てのクライアントに、新しいクライアントとの調停機能（ハード，ソフトのうちの少なくとも一方）を組み込む必要があり、そのためにＲＯＭやＲＡＭの容量に余裕を持たせておかなければならず、コストアップにつながるという課題を生ずる。
【００１５】
また、サーバ内で調停する方法は、例えば、サーバ１がクライアント１との通信中に、クライアント２からの通信要求を受信したときには、サーバ１自身が調停機能１０４を用いて調停を行い、その要求に応答できない旨（否定応答）をクライアント２に送信する。
【００１６】
上述の構成では、クライアントが増加すると、全てのサーバに新しいクライアントとの通信機能（ハード，ソフト）を追加するとともに、調停機能の対象に新しいクライアントを含めるための改造（ソフトの修正等）を行う必要があり、いずれもコストアップにつながるという課題を生ずる。
【００１７】
上記のような背景に基づいて、本発明の課題は、車両に搭載されたサーバに接続するためのクライアントを追加する際の改造範囲をより小さくし、低コストで改造を行うことが可能な車両用電子制御装置を提供することにある。
【課題を解決するための手段および発明の効果】
【００１８】
上記課題を解決するための車両用電子制御装置は、予め定められた機能を実行する１以上のサーバと、サーバとの通信の確立を要求するための要求信号を送信する１以上のクライアントと、サーバとクライアントとの間に介在し、サーバとクライアントとの通信を調停する１つの調停部と、が、ネットワーク上に配置され、調停部は、サーバの通信状態を取得する通信状態取得部を含み、要求信号を受信したとき、該要求信号の対象となるサーバの通信状態に基づいて、該クライアントと該サーバとの通信の確立を許可するか否かを決定することを特徴とする。
【００１９】
上記構成によって、従来の構成（例えば、図２２）のように、クライアント間で調停したり、サーバ内で調停する必要がなくなり、クライアントおよびサーバの調停機能を調停部に集約できるため、クライアントおよびサーバのハードウェア構成およびソフトウェア構成を簡略化でき、処理負荷を低減できるとともにクライアントおよびサーバのコストダウンも可能となる。
【００２０】
また、本発明の車両用電子制御装置における調停部は、要求信号の対象となるサーバが他のクライアントと通信中のとき、要求信号の送信元のクライアントと他のクライアントの通信の優先順位に基づいて、要求信号の送信元のクライアントと該要求信号の対象となるサーバとの通信と、該サーバと他のクライアントとの通信とのうち、いずれを優先させるかの調停を行う。
【００２１】
上記構成によって、適切な調停（どのクライアントを優先させるか）を行うことで、ユーザの利便性を確保できる。
【００２２】
また、本発明の車両用電子制御装置における要求信号は、複数の通信フレームにより構成され、調停部とクライアントとの間の通信は１フレーム単位で行われ、調停部は、要求信号の最初の通信フレームを受信したときに調停を行う。
【００２３】
上記構成によって、要求信号が複数の通信フレームにより構成されるときには、全フレームを受信することなく調停を行うことができるので、要求信号を受信してから調停を行うまでの時間を短縮できる。
【００２４】
また、本発明の車両用電子制御装置における調停部は、要求信号に含まれるデータ内容に基づいて、要求信号の送信元のクライアントと該要求信号の対象となるサーバとの通信と、該サーバと他のクライアントとの通信とのうち、いずれを優先させるかの調停を行う。
【００２５】
上記構成によって、適切な調停を行うことができるとともに、新たなクライアントを追加しても、調停部で対応する設定操作を行う必要はなく、ユーザの操作負荷を低減することができる。
【００２６】
また、本発明の車両用電子制御装置は、クライアント毎に、通信の優先順位が予め定められ、調停部は、要求信号に含まれる優先順位に基づいて、要求信号の送信元のクライアントと要求信号の対象となるサーバとの通信と、該サーバと他のクライアントとの通信とのうち、いずれを優先させるかを決定する。
【００２７】
上記構成によっても、適切な調停を行うことができるとともに、新たなクライアントを追加しても、調停部で対応する設定操作を行う必要はなく、ユーザの操作負荷を低減することができる。
【００２８】
また、本発明の車両用電子制御装置における調停部は、要求信号の送信元のクライアントの優先順位が、他のクライアントの優先順位よりも低いとき、該クライアントに対し、サーバとの通信が可能になるまで待機する旨の応答、あるいは、該サーバとの通信を不許可とする旨の応答のいずれかを行う。
【００２９】
上記構成によって、要求信号の送信元のクライアントの優先順位が、他のクライアントの優先順位よりも低いときに、適切な調停を行うことができる。また、要求信号の送信元のクライアントを、サーバとの通信が可能になるまで待機させる構成のときには、該クライアントの要求にも応じることができる。
【００３０】
また、本発明の車両用電子制御装置における調停部は、要求信号の送信元のクライアントの優先順位が、他のクライアントの優先順位よりも高いとき、サーバと他のクライアントとの通信を中断あるいは中止させて、要求信号の送信元のクライアントと要求信号の対象となるサーバとの通信を許可する。また、要求信号の送信元のクライアントを、サーバとの通信が可能になるまで中断させる構成のときには、該クライアントの要求にも応じることができる。
【００３１】
上記構成によって、要求信号の送信元のクライアントの優先順位が、他のクライアントの優先順位よりも高いときに、要求信号の送信元のクライアントを優先させることができる。
【００３２】
また、本発明の車両用電子制御装置における要求信号は、ネットワーク上に備えられる全てのサーバに対するもので、調停部は、全てのサーバの通信状態に基づいて、該クライアントと該全てのサーバとの通信を許可するか否かを決定する。
【００３３】
上記構成によって、クライアントが一度に全てのサーバとの通信を確立したいときにも、適切な調停を行うことができる。
【００３４】
また、本発明の車両用電子制御装置における調停部は、サーバあるいはクライアントのいずれか１つに備えられる。
【００３５】
上記構成によって、サーバあるいはクライアントと、ハードウェアあるいはソフトウェアの少なくとも一部を共用できるので、調停部の製造コストを低減することができる。
【００３６】
また、本発明の車両用電子制御装置は、サーバあるいはクライアントを含む通信ネットワークは複数あり、その通信ネットワーク毎に前記調停部と接続する。
【００３７】
上記構成によって、通信ネットワーク系が複数あるときにも、調停部をネットワークのゲートウェイのような位置づけとし、１台の調停部により調停を行うことができる。
【００３８】
また、本発明の車両用電子制御装置における調停部は、ネットワーク上に複数備えられる。
【００３９】
上記構成によって、クライアントあるいはサーバの数が増加して、調停部１台あたりの調停能力を超えたときにも、調停部を複数配置することで適切な調停を行うことができる。
【図面の簡単な説明】
【００４０】
【図１】本発明の車両用電子制御装置の構成を示す図。
【図２】サーバ〜クライアント間の通信について説明する図。
【図３】調停の詳細を説明する図（実施例１）。
【図４】フレーム単位の調停について説明する図（実施例１）。
【図５】メッセージ単位の調停について説明する図（実施例１）。
【図６】メッセージ単位の調停の別例について説明する図（実施例１）。
【図７】調停処理を説明するフロー図（実施例１）。
【図８】調停の詳細を説明する図（実施例２）。
【図９】メッセージ単位の調停について説明する図（実施例２）。
【図１０】フレーム単位の調停について説明する図（実施例２）。
【図１１】メッセージ単位の調停の別例について説明する図（実施例２）。
【図１２】フレーム単位の調停の別例について説明する図（実施例２）。
【図１３】調停処理を説明するフロー図（実施例２）。
【図１４】従来の構成による一斉通信要求における調停方法を示す構成図。
【図１５】従来の構成による一斉通信要求における調停方法を示す図。
【図１６】一斉通信要求における調停方法を示す構成図（実施例３）。
【図１７】一斉通信要求における調停方法を示す図（実施例３）。
【図１８】一斉通信要求における調停処理を説明するフロー図（実施例３）。
【図１９】一斉通信要求における調停方法の別例を示す構成図（実施例４）。
【図２０】一斉通信要求における調停方法の別例を示す図（実施例４）。
【図２１】一斉通信要求における調停処理の別例を説明するフロー図（実施例４）。
【図２２】従来技術による車両用電子制御装置の構成を示す図。
【発明を実施するための形態】
【００４１】
以下、本発明の車両用電子制御装置について、図面を用いて説明する。図１に、車両用電子制御装置の構成を示す。なお、本構成は、図２２の構成において機能を追加・削除したものであるため、図２２と同様の構成のものについては同一の符号を付与し、ここでの詳細な説明は割愛する。
【００４２】
クライアント１〜３は、図２２の構成から、他のクライアントとの調停機能（１１，１２等：破線枠で表記したもの）が削除されている。また、通信機能（１３等）は、主に調停ＥＣＵ１を介してサーバ１〜３との通信を行うための通信インターフェースである。
【００４３】
サーバ１〜３は、図２２の構成から、各クライアントとの通信機能のうちの一つがクライアント通信機能（１１１等）に置き換わり、残り（破線枠で表記したもの）は削除されている。クライアント通信機能は、主に調停ＥＣＵ１を介してクライアント１〜３との通信を行うための通信インターフェースである。
【００４４】
調停ＥＣＵ１は、図２２の構成では各サーバに含まれていた、各クライアントとの通信機能（１０１等）および調停機能（１０４等）を１か所（クライアント１通信機能５１，クライアント２通信機能５２，クライアント３通信機能５３，調停機能５４）に集約したものである。上述のように、従来はクライアント同士、あるいは、サーバ内で調停していたものを、本発明では、調停ＥＣＵ１で調停するようにしている。これにより、各クライアント内の、各クライアントとの調整機能、およびサーバ内の調整機能とクライアント毎の通信機能が不要となる。なお、調停ＥＣＵ１が本発明の調停部に相当する。また、調停機能５４が本発明の通信状態取得部に相当する。
【００４５】
調停ＥＣＵを複数設けてもよい。図１では、調停ＥＣＵ２が設けられている。構成は調停ＥＣＵ１と同様である。そして、例えば、調停ＥＣＵ１は、各クライアントからのサーバ２およびサーバ３に対する要求（本発明の「要求信号」、以下も同様）を調停し、調停ＥＣＵ２は、各クライアントからのサーバ１に対する要求を調停する。但し、通信効率やコストの面を考慮すると、特にクライアント数が少ないときには、調停ＥＣＵは１台であることが望ましい。
【００４６】
また、サーバ５を車内ＬＡＮ４０とは別のネットワークである車内ＬＡＮ４１を介して調停ＥＣＵ１に接続する構成としてもよい。これにより、他の通信系に接続されているサーバへの要求も調停することが可能となる。
【００４７】
また、従来構成の、各クライアントとの通信機能４０１〜４０３および調停機能４０４を備えるサーバ４を車内ＬＡＮ４０に接続する構成としてもよい。この場合、調停ＥＣＵ１，調停ＥＣＵ２は、サーバ４に対する要求の調停は行わず、通信データの中継のみ行う。このように、新旧のサーバが混在する環境下でも、調停ＥＣＵ１は柔軟に対応できる。無論、サーバ４の調停機能も調停ＥＣＵ１に集約することが望ましい。
【００４８】
また、調停ＥＣＵ１の、クライアント通信機能（５１〜５３）および調停機能５４をサーバ１〜３，クライアント１〜３のいずれかに含めてもよい。特に、エンジンＥＣＵは、内燃機関を有する車両（ハイブリッド車両を含む）には必ず搭載されているので、調停部として適している。また、電気自動車（ハイブリッド車両を含む）では、調停部を、駆動用モータを制御するモータ制御ＥＣＵに含めることが適している。
【００４９】
図２に、ダイアグ通信を例に挙げて、サーバ〜クライアント間の通信について説明する。図２の左側は、送信するデータが１つのフレームにより構成されるシングルフレーム（Single Frame：ＳＦ）による通信を示したもので、右側は、送信するデータが複数のフレームにより構成されるマルチフレーム（Multi Frame：ＭＦ）による通信を示したものである。
【００５０】
シングルフレーム通信の場合は、クライアントがサーバに対して何らかの要求（例えば、故障診断用のデータであるダイアグデータの送信要求）を送信すると、サーバでその要求を解析し、解析結果に応じたサービス（データ読み出し等）を実行し、その結果（読み出したデータ等）をクライアントに送信する。シングルフレーム通信では、１フレーム＝１メッセージであるため、フレームレベルでの調停ができないので、メッセージ単位での調停を行う。
【００５１】
マルチフレーム通信の場合は、クライアントがサーバに対して何らかの要求（データ要求）を行う要求を送信する際、まず、マルチフレーム（ＭＦ）で構成される要求の先頭フレーム（First Frame：ＦＦ）を送信する。サーバは、先頭フレーム（ＦＦ）を受信すると、受信可能な旨を含むＦＣ（Flow Control）をクライアントに送信する。クライアントは、該ＦＣを受信すると、要求の残りのフレーム（Consecutive Frame：ＣＦ）を順次送信する。
【００５２】
サーバは、全フレームを受信すると、その要求を解析し、解析結果に応じたサービスを行い、その結果をマルチフレームでクライアントに送信する。すなわち、まず、サーバは、応答の先頭フレーム（ＦＦ）を送信し、クライアントからの受信可能な旨を含むＦＣを受信した後、応答の残りのフレーム（ＣＦ）を順次送信する。マルチフレーム通信では、複数フレーム＝１メッセージであるため、フレーム単位での調停が必要となる。
【００５３】
なお、ＣＡＮベースの診断インターフェースは、ＩＳＯ１５７６５−２（フレームに関するもの），ＩＳＯ１４２２９−１（メッセージの構築に関するもの）の規定に基づいている。
【００５４】
以下、調停ＥＣＵ１におけるメッセージ単位およびフレーム単位での調停の詳細について説明する。なお、調停の優先順位は、以下のうちの一つ、あるいは複数の組み合わせを用いる。
・先に要求信号を受信したクライアントを優先する。
・後から要求信号を受信したクライアントを優先する。
・予めクライアントに優先順位を設定し、要求信号を受信したクライアントの優先順位を比較する。例えば、ダイアグテストツール（優先順位：高）＞車載装置（ナビ等）＞リモート端末（優先順位：低）。
・要求信号の内容に応じて優先順位が予め定められる。例えば、要求信号に含まれるＳＩＤ：サービスＩＤに優先順位を含ませる。優先順位は調停ＥＣＵ１に記憶する。
【実施例１】
【００５５】
図３〜図７を用いて、調停の詳細の第1実施例について説明する。本実施例では、以下のように調停を行う。
・メッセージ単位の調停：現在サーバと通信中のクライアントよりも優先順位の低いクライアントからの要求は受け付けない。
・フレーム単位の調停：現在サーバと通信中のクライアントよりも優先順位の低いクライアントからの要求があったときには、その要求を受け付け、現在サーバと通信中のクライアントの処理終了後に、サーバとの通信を許可する。
【００５６】
図３を用いて、本実施例における車両用電子制御装置の構成の概要を説明する。本実施例では、クライアント２とクライアント３からのサーバ３に対する要求を調停ＥＣＵ１が調停する。調停ＥＣＵ１は、図１の構成に加え、クライアント２通信機能５２に含まれるクライアント２用受信部５２ａ、クライアント３通信機能５３に含まれるクライアント３用受信部５３ａ、クライアント２，３にデータを送信する送信部５５（対象クライアント毎にクライアント２通信機能５２，クライアント３通信機能５３に送信部を含む構成でもよい）、図示しないメモリの一部に確保される要求退避用バッファ５６を備えている。
【００５７】
図４を用いて、先にサーバ３とクライアント３とが通信中のときに、クライアント３よりも優先順位の低いマルチフレーム通信を行うクライアント２からの要求が送信されときの調停のうち、フレーム単位の調停の詳細について説明する。
【００５８】
クライアント３からの要求３１（ＳＦ）を受信した調停ＥＣＵ１は、要求先のサーバ３がアイドル状態であるとき、その要求を要求１１（ＳＦ）としてサーバ３に送信する。サーバ３は、受信した要求１１に基づいて図２で説明したような処理を実行し（処理中１）、処理結果を応答１１（ＳＦ）として調停ＥＣＵ１に送信する。調停ＥＣＵ１は、受信した応答１１を応答３１（ＳＦ）としてクライアント３に送信する。
【００５９】
調停ＥＣＵ１がクライアント３からの要求３１を受信して、サーバ３に要求１１（ＳＦ）を送信し、サーバ３と通信中のときに、クライアント２からの要求２１の先頭フレーム（ＦＦ）を受信したとき、クライアント２に対し、受信可能な旨を含むＦＣを送信する。クライアント２は、該ＦＣを受信すると、要求の残りのフレームＣＦを、調停ＥＣＵ１に順次送信する。クライアント２からの要求は、要求退避用バッファ５６に記憶する。
【００６０】
調停ＥＣＵ１は、サーバ３がクライアント３からの要求に対する処理（処理中１）が終了するのを待つ。すなわち、サーバ３から応答１１（ＳＦ）が送信されてくるのを待つ。そして、サーバ３からの応答１１（ＳＦ）を受信すると、クライアント３にその旨を応答３１（ＳＦ）として送信する。その後、クライアント２からの要求データが要求退避用バッファ５６に記憶されているとき、これを読み出して要求１２（ＳＦ）としてサーバ３に送信する。サーバ３は、受信した要求１２に基づいて図２で説明したような処理を実行し（処理中２）、処理結果を応答１２（ＳＦ）として調停ＥＣＵ１に送信する。調停ＥＣＵ１は、受信した応答１２を応答２２（ＦＦ）としてクライアント２に送信する。以降、図２と同様に、クライアント２からの受信可能な旨を含むＦＣデータを受信した後、応答の残りのフレーム（ＣＦ）を順次送信する。
【００６１】
図５を用いて、メッセージ単位の調停のうち、先にサーバ３と通信中のクライアント３よりも優先順位の低いクライアント２からの要求が送信されたときの調停の詳細について説明する。サーバ３は、クライアント３からの要求に基づく処理のみを実行する。クライアント２からの要求は拒否する。
【００６２】
調停ＥＣＵ１がクライアント３からの要求３１を受信して、サーバ３に要求１１（ＳＦ）を送信し、サーバ３と通信中のときに、クライアント２からの要求２１（ＳＦ）を受信したとき、調停ＥＣＵ１はクライアント２に対し、要求を受け入れない旨を含む否定応答コード（ＳＦ）を送信する。否定応答は、例えば＄２１（十六進数の２１）で示される。クライアント２は、該否定応答を受信すると、要求に関する処理を終了する。
【００６３】
また、調停ＥＣＵ１がクライアント２からの要求２１を受信したとき、調停ＥＣＵ１はその要求に対し無応答としてもよい。クライアント２では、要求２１を送信してからの経過時間を測定し、予め定められた時間が経過した（すなわち、応答待ちタイムアウトした）ときに、調停ＥＣＵ１では要求が受け入れられなかったと判断し、要求に関する処理を終了する。すなわち、クライアントは、要求信号を送信後、予め定められた時間内に調停部からの応答を受信しないときには、該要求信号に基づくサーバとの通信が許可されたかったと判定する構成となる。
【００６４】
なお、図５におけるクライアント３とサーバ３との通信シーケンスは、図４と同様である。
【００６５】
図６を用いて、メッセージ単位の調停のうち、先にサーバ３と通信中のクライアント３よりも優先順位の高いクライアント２からの要求が送信されてきたときの調停の詳細について説明する。サーバ３は、クライアント３からの要求に基づく処理を中止し、以降、クライアント２からの要求に基づく処理のみを実行する。
【００６６】
調停ＥＣＵ１がクライアント３からの要求３１（ＳＦ）を受信して、サーバ３に要求１１（ＳＦ）を送信し、サーバ３と通信中（処理中１）のときに、クライアント２からの要求２１（ＳＦ）を受信したとき、調停ＥＣＵ１はクライアント３に対し、処理を中止し要求を受け入れない旨を含む否定応答（ＳＦ）を送信する。否定応答は、例えば＄２１（十六進数の２１）で示される。クライアント３は、該否定応答を受信すると、要求に関する処理を終了する。
【００６７】
次に、調停ＥＣＵ１は、クライアント２からの要求を受け入れ、クライアント２からの要求を要求１２（ＳＦ）としてサーバ３へ送信する。サーバ３は、要求１２を受信すると、クライアント３からの要求に基づく処理（処理中１）を中止し、要求１２に基づく処理を実行する処理中２の状態となる。そして、処理が終了すると、処理結果を応答１２（ＳＦ）として調停ＥＣＵ１に送信する。調停ＥＣＵ１は、応答１２を受信すると、応答２２（ＳＦ）としてクライアント２に送信する。
【００６８】
図７に、図３〜図６における、調停ＥＣＵ１で実行されるプログラムに含まれる調停処理のフローを示す。クライアント（図３〜図６では、クライアント２に相当）からダイアグ要求（図３〜図６では、「要求」と略記）を受信したとき、その要求がシングルフレーム（ＳＦ）通信によるものか否かを判定する（Ｓ１１）。シングルフレーム通信によるものではないとき（Ｓ１２：Ｎｏ）、図４のように、マルチフレーム（ＭＦ）の残りのフレームを受信する（Ｓ１５）。そして、ステップＳ１３へ進む。
【００６９】
一方、シングルフレーム通信によるものであるとき（Ｓ１２：Ｙｅｓ）、ステップＳ１３へ進む。ステップＳ１３では、要求先のサーバ（図３〜図６では、サーバ３に相当）が他のクライアント（図３〜図６では、クライアント３に相当）と通信中（図７では、「ダイアグ通信中」と表記）であるか否かを判定する。ダイアグ通信中、つまり他のクライアントの要求に基づく処理を実行中のとき（Ｓ１３：Ｙｅｓ）、クライアント（２，３）の優先度を比較する。クライアント（２）の優先度が低いとき（Ｓ１６：Ｎｏ）、クライアント（２）へ否定応答＄２１を送信する（Ｓ１７，図５に相当）。
【００７０】
一方、ダイアグ通信中でないとき（Ｓ１３：Ｎｏ）、あるいは、クライアント（２）の優先度が高いとき（Ｓ１６：Ｙｅｓ）、クライアント（２）からの要求をサーバ（３）へ送信する（Ｓ１４，図４の後半部あるいは図６に相当）。なお、クライアント（２）の優先度が高いとき（Ｓ１６：Ｙｅｓ）、先にサーバ（３）と通信中のクライアント（３）に否定応答＄２１を送信してもよい（図６に相当）。サーバ（３）は、クライアント（３）の要求に基づく処理を中止し、クライアント（２）の要求に基づく処理を実行する。
【００７１】
また、クライアント３では、調停ＥＣＵ１へ要求３１を送信してから所定時間以内に調停ＥＣＵ１からの応答（３１）を受信しないときには、要求が受け入れられなかったと判断して、該要求に関する処理を終了してもよい。
【実施例２】
【００７２】
図８〜図１３を用いて、調停の詳細の第２実施例について説明する。本実施例では、以下のように調停を行う。
・メッセージ単位の調停：優先順位の低いクライアントからの要求信号を待たせて、優先順位の高いクライアントの処理実行後に、優先順位の低いクライアントの処理を実行する。
・フレーム単位の調停：優先順位の低いクライアントからの要求信号を待たせて、優先順位の高いクライアントの処理実行後に、優先順位の低いクライアントの処理を実行する。
すなわち、現在サーバと通信中のクライアントよりも優先順位の高いクライアントからの要求信号があったときには、その要求信号を受け付け、現在サーバと通信中のクライアントの通信を中断して、サーバと優先順位の高いとの通信を行い、該通信終了後に、中断していたサーバとクライアントとの通信を再開する構成である。
【００７３】
本実施例では、クライアント２とクライアント３からのサーバ３に対する要求を調停ＥＣＵ１が調停する。図８の調停ＥＣＵ１等の構成は、図３と同様である。なお、クライアント２用受信部５２ａ，クライアント３用受信部５３ａは、一括して受信部として表記してある。
【００７４】
図９を用いて、先にサーバ３とクライアント３とが通信中のときに、クライアント３よりも優先順位の低いシングルフレーム通信を行うクライアント２からの要求が送信されたときの、メッセージ単位の調停の詳細について説明する。
【００７５】
調停ＥＣＵ１がクライアント３からの要求３１を受信して、サーバ３に要求１１（ＳＦ）を送信し、サーバ３と通信中（すなわち、クライアント３からの要求に基づく処理を実行中）のときに、クライアント２からの要求２１（ＳＦ）を受信したとき、調停ＥＣＵ１はクライアント２に対し、要求は受け入れたが直ちに処理を行うことができない旨の否定応答コード（ＳＦ）を送信する。否定応答は、例えば＄７８（十六進数の７８）で示される。クライアント２は、該否定応答を受信すると、調停ＥＣＵ１からの応答を受信するまで待機する。クライアント２からの要求２１は、要求退避用バッファ５６に記憶する。
【００７６】
なお、否定応答は、１回のみ送信してもよいし、予め定められたタイミング（例えば、クライアント２で通信のタイムアウトを判定しないような周期）で送信してもよい。
【００７７】
サーバ３での処理（処理中１）が終了し、サーバ３が調停ＥＣＵ１に処理結果を応答１１（ＳＦ）として送信すると、調停ＥＣＵ１は、これを応答３１（ＳＦ）としてクライアント３に送信する。その後、クライアント２からの要求２１を要求退避用バッファ５６に記憶してあるとき、これを読み出して要求１２としてサーバ３に送信する。サーバは要求１２を受信すると、その要求に応じた処理を実行する（図４の処理中２のシーケンスに準ずる）。
【００７８】
図１０を用いて、先にサーバ３とクライアント３とが通信中のときに、クライアント３よりも優先順位の低いマルチフレーム通信を行うクライアント２からの要求が送信されたときの、フレーム単位の調停の詳細について説明する。
【００７９】
調停ＥＣＵ１がクライアント３からの要求３１を受信して、サーバ３に要求１１（ＳＦ）を送信し、サーバ３と通信中（すなわち、処理中１）のときに、クライアント２からの要求２１（ＦＦ）を受信したとき、調停ＥＣＵ１はクライアント２に対し、要求は受け入れたが直ちに処理を行うことができないため待機を指示する旨のＦＣを送信する。クライアント２は、該ＦＣを受信すると、調停ＥＣＵ１からの応答を受信するまで待機する。クライアント２からの要求２１は、要求退避用バッファ５６に記憶する。
【００８０】
なお、ＦＣは、１回のみ送信してもよいし、予め定められたタイミング（例えば、クライアント２で通信のタイムアウトを判定しないような周期）で送信してもよい。
【００８１】
サーバ３での処理が終了し、サーバ３が調停ＥＣＵ１に処理結果を応答１１（ＳＦ）として送信すると、調停ＥＣＵ１は、これを応答３１（ＳＦ）としてクライアント３に送信する。その後、クライアント２からの要求２１を要求退避用バッファ５６に記憶してあるとき、データを受信可能な旨を含むＦＣをクライアント２に送信する。クライアント２は、該ＦＣを受信すると、要求データの残りのフレームＣＦを順次送信する。
【００８２】
調停ＥＣＵ１は、ＣＦを全フレーム受信すると、要求１２としてサーバ３に送信する。サーバは要求１２を受信すると、その要求に応じた処理を実行する（図４の処理中２のシーケンスに準ずる）。
【００８３】
なお、図１０の構成で、クライアント２からの要求を受け入れないときには、ＥＣＵ１はクライアント２に最初のＦＣを送信するタイミングで、図５のような否定応答（＄２１：ＳＦ）を送信する。
【００８４】
図１１を用いて、先にサーバ３と通信中のクライアント３よりも優先順位の高いクライアント２からの要求が送信されてきたときの、メッセージ単位の調停の詳細について説明する。
【００８５】
調停ＥＣＵ１がクライアント３からの要求３１を受信して、サーバ３に要求１１（ＳＦ）を送信し、サーバ３と通信中（すなわち、処理中１）のときに、クライアント２からの要求２１（ＳＦ）を受信したとき、調停ＥＣＵ１はサーバ３にクライアント２からの要求２１を要求１２として送信する。このとき、クライアント３に対して、要求は受け入れたが直ちに処理を行うことができない旨の否定応答コード（ＳＦ）を送信してもよい。否定応答は、例えば＄７８（十六進数の７８）で示される。また、クライアント３からの要求３１に基づく処理が終了していないことを、要求退避用バッファ５６に記憶する。
【００８６】
なお、否定応答は、１回のみ送信してもよいし、予め定められたタイミング（例えば、クライアント３で通信のタイムアウトを判定しないような周期）で送信してもよい。
【００８７】
サーバ３は調停ＥＣＵ１からの要求１２を受信すると、クライアント３に対応する処理（処理中１）を一時停止し、必要なデータを退避する。そして、調停ＥＣＵ１からの要求１２に基づくクライアント２に対応する処理（処理中２）を実行する。
【００８８】
サーバ３でのクライアント２に対応する処理が終了し、サーバ３が調停ＥＣＵ１に、処理結果を応答１２（ＳＦ）として送信すると、調停ＥＣＵ１は、これを応答２１（ＳＦ）としてクライアント２に送信する。サーバ３は、要求退避用バッファ５６に、クライアント３からの要求３１に基づく処理が終了していないことを記憶してある場合には、クライアント３に対応する処理を再開し（処理中１１）、該処理が終了すると、処理結果を調停ＥＣＵ１に応答１１（ＳＦ）として送信する。調停ＥＣＵ１は、これを応答３１（ＳＦ）としてクライアント３に送信する。
【００８９】
調停ＥＣＵ１は、サーバ３からの応答１２（ＳＦ）を受信したときに、要求退避用バッファ５６に、クライアント３からの要求３１に基づく処理が終了していないことを記憶してある場合には、サーバ３に対し、クライアント３からの要求３１に基づく処理を再開する旨のメッセージを送信してもよい。
【００９０】
図１２を用いて、先にサーバ３と通信中のクライアント３よりも優先順位の高いクライアント２からの要求信号が送信されてきたときの、フレーム単位の調停の詳細について説明する。
【００９１】
調停ＥＣＵ１がクライアント３からの要求３１を受信して、サーバ３に要求１１（ＳＦ）を送信し、サーバ３と通信中（すなわち、処理中１）のときに、クライアント２からの要求２１（ＦＦ）を受信したとき、調停ＥＣＵ１は、データを受信可能な旨を含むＦＣをクライアント２に送信する。クライアント２は、該ＦＣを受信すると、要求データの残りのフレームＣＦを順次送信する。
【００９２】
調停ＥＣＵ１はクライアント２からのフレームを全て受信すると（要求２１（ＦＦ）を受信したときでもよい）、調停ＥＣＵ１はサーバ３にクライアント２からの要求２１を要求１２として送信する。このとき、クライアント３に対して、要求は受け入れたが直ちに処理を行うことができない旨の否定応答コード（ＳＦ）を送信してもよい。否定応答は、例えば＄７８（十六進数の７８）で示される。また、クライアント３からの要求３１に基づく処理が終了していないことを、要求退避用バッファ５６に記憶する。
【００９３】
なお、否定応答は、１回のみ送信してもよいし、予め定められたタイミング（例えば、クライアント３で通信のタイムアウトを判定しないような周期）で送信してもよい。
【００９４】
サーバ３は調停ＥＣＵ１からの要求１２を受信すると、調停ＥＣＵ１からの要求１１に基づくクライアント３に対応する処理（処理中１）を一時停止し、必要なデータを退避する。そして、調停ＥＣＵ１からの要求１２に基づくクライアント２に対応する処理（処理中２）を実行する。
【００９５】
サーバ３でのクライアント２に対応する処理が終了し、サーバ３が調停ＥＣＵ１に処理結果を応答１２（ＳＦ）として送信すると、調停ＥＣＵ１は、これを応答２１（ＳＦ）としてクライアント２に送信する。その後、サーバ３は、要求退避用バッファ５６に、クライアント３からの要求３１に基づく処理が終了していないことを記憶してある場合には、クライアント３に対応する処理を再開し（処理中１１）、該処理が終了すると、調停ＥＣＵ１に処理結果を応答１１（ＳＦ）として送信する。調停ＥＣＵ１は、これを応答３１（ＳＦ）としてクライアント３に送信する。
【００９６】
調停ＥＣＵ１は、サーバ３から応答１２（ＳＦ）を受信したときに、要求退避用バッファ５６に、クライアント３からの要求３１に基づく処理が終了していないことを記憶してある場合には、サーバ３に対し、クライアント３からの要求３１に基づく処理を再開する旨のメッセージを送信してもよい。
【００９７】
図１３に、図８〜図１２における、調停ＥＣＵ１で実行されるプログラムに含まれる調停処理のフローを示す。クライアント（図８〜図１２では、クライアント２に相当）からダイアグ要求（図８〜図１２では、「要求」と略記）を受信したとき、その要求がシングルフレーム（ＳＦ）通信によるものか否かを判定する（Ｓ３１）。
【００９８】
要求がシングルフレーム通信によるものでないとき（Ｓ３２：Ｎｏ）、クライアント（２，３）の優先度を比較する。クライアント（２）の優先度が低いとき（Ｓ３５：Ｎｏ）、クライアント（２）へ待機を指示する旨のＦＣを送信する（Ｓ３６）。そして、クライアント（３）と要求先サーバ（サーバ３）のダイアグ通信が終了するのを待つ。この間、予め定められたタイミングでクライアント（２）へＦＣを送信する（Ｓ３６）。
【００９９】
クライアント（３）と要求先サーバ（サーバ３）のダイアグ通信が終了したとき（Ｓ３７：Ｙｅｓ）、クライアント（２）からの残りの要求データ（ＣＦ）を受信し（Ｓ３８）、ステップＳ３３へ進む。
【０１００】
一方、要求がシングルフレーム通信によるものであるとき（Ｓ３２：Ｙｅｓ）、あるいは、クライアント（２）の優先度が高いとき（Ｓ３５：Ｙｅｓ）、ステップＳ３３へ進む、ステップＳ３３では、クライアント（３）と要求先サーバ（サーバ３）との間でダイアグ通信中であるか否かを判定する。
【０１０１】
ダイアグ通信中であるとき（Ｓ３３：Ｙｅｓ）、クライアント（２，３）の優先度を比較する。クライアント（２）の優先度が低いとき（Ｓ３９：Ｎｏ）、クライアント（２）へ直ちに処理を実行できないため待機を指示する旨の否定応答＄７８（ＳＦ）を送信する（Ｓ４０）。そして、クライアント（３）と要求先サーバ（サーバ３）のダイアグ通信が終了するのを待つ。この間、予め定められたタイミングでクライアント（２）へ否定応答＄７８を送信する（Ｓ４０）。
【０１０２】
クライアント（３）と要求先サーバ（サーバ３）のダイアグ通信が終了したとき（Ｓ４１：Ｙｅｓ）、ステップＳ３４へ進む。
【０１０３】
一方、ダイアグ通信中でないとき（Ｓ３３：Ｎｏ）、あるいは、クライアント（２）の優先度が高いとき（Ｓ３９：Ｙｅｓ）、ステップＳ３４へ進む、ステップＳ３４では、クライアント（２）からの要求（ダイアグ要求）をサーバ（３）へ送信する。また、他のクライアント（３）とダイアグ通信中のとき、該クライアント（３）へ否定応答＄７８を送信する。
【０１０４】
以下、１台のクライアントから複数のサーバに一斉に要求（以下、「一斉通信要求」という）を送信したときの、調停ＥＣＵ１における調停の詳細について説明する。まず、図１４（図２２に準ずる），図１５を用いて、従来の構成による調停方法について説明する。クライアント間で調停を行う場合には、クライアント１が、クライアント２およびクライアント３との調停機能（１１，１２）を用いて通信権を獲得した後に、全サーバ（１〜３）に要求１を送信する。これは、サーバ毎に要求を送信するのではなく、１個のデータに全サーバに対する要求を行う意味を持たせる。要求を受信した各サーバは、それぞれ応答（３〜５）を送信する。
【０１０５】
また、サーバ側で調停を行う場合には、クライアント１からの要求１を受信したときに、それぞれの調停機能（１０４，２０４，３０４）を用いて調停を行った後、それぞれ応答（３〜５）を送信する。この場合、調停の結果、クライアント１からの要求１が優先されないこともありうる。クライアント１が、全サーバからの応答の全てを用いて何らかの解析を行う場合、データが揃わないため解析を実行できないこともある。また、優先されたクライアントの処理が終わった後に、サーバから遅れて応答が送信されたときも、応答データ間の同期がとれないという課題が生ずる。
【実施例３】
【０１０６】
図１６〜図１８を用いて、クライアントから一斉通信要求を受信したときの、調停ＥＣＵ１における調停の詳細の第１実施例について説明する。本実施例では、１台でも他のクライアントとの通信を行っているサーバがあるときには、一斉通信要求を拒否する構成となっている。
【０１０７】
図１６の構成は、図３の構成に、サーバ１，サーバ２を追加し、調停ＥＣＵ１の要求退避用バッファ５６を含まないものであるため、ここでの詳細な説明は割愛する。なお、クライアント２用受信部５２ａ，クライアント３用受信部５３ａは、一括して受信部として表記してある。
【０１０８】
図１７のように、調停ＥＣＵ１がクライアント３からの要求３１を受信して、サーバ３に要求１１（ＳＦ）を送信し、サーバ３と通信中（すなわち、処理中）のときに、クライアント２からの要求２１（一斉通信要求：ＳＦ，ＭＦのいずれでもよい）を受信したとき、調停ＥＣＵ１はクライアント２に対し、要求は受け入れることができない旨の否定応答コード（ＳＦ）を送信する（応答２１）。否定応答は、例えば＄２１（十六進数の２１）で示される。否定応答コードは、図１７のように、調停ＥＣＵ１が各サーバを代行する形でクライアント２に送信してもよいし、１つのメッセージにすべてのサーバを代行する内容を含む形で送信してもよい。
【０１０９】
この間、サーバ３は、クライアント（３）からの要求に基づく処理を継続し、処理が終了すると、調停ＥＣＵ１に処理結果を応答１１（ＳＦ）として送信する。調停ＥＣＵ１は、これを応答３１（ＳＦ）としてクライアント３に送信する。
【０１１０】
図１８に、図１６，図１７における、調停ＥＣＵ１で実行されるプログラムに含まれる調停処理のフローを示す。まず、クライアント（図１６，図１７では、クライアント２に相当）からダイアグ要求（図１６，図１７では、「要求２１」と表記）を受信したとき、その要求がシングルフレーム（ＳＦ）通信によるものか否かを判定する（Ｓ５１）。
【０１１１】
要求がシングルフレーム通信によるものであるとき（Ｓ５２：Ｙｅｓ）、要求先サーバ（サーバ１〜３）の全てについてダイアグ通信中であるか、すなわち他のクライアントからの要求に基づく処理を行っているか否かを調べる。一方、マルチフレーム（ＭＦ）通信によるものであるとき（Ｓ５２：Ｎｏ）、例えば図４のように、残りのフレームを受信し（Ｓ５５）、要求先サーバ（サーバ１〜３）の全てについてダイアグ通信中であるか否かを調べる。マルチフレーム（ＭＦ）通信のとき、先頭フレーム（ＦＦ）を受信したら、要求先サーバの全てについてダイアグ通信中であるか否かを調べてもよい。
【０１１２】
そして、要求先サーバのうちの全てがダイアグ通信中でないとき（Ｓ５３：Ｎｏ）、全サーバへ要求を送信する（Ｓ５４）。この後、各サーバで要求に対応する処理を実行し、調停ＥＣＵ１でその結果を受信すると、例えば、サーバからの受信順にクライアント（２）へ送信する（図１５の応答３，４，５に相当）。
【０１１３】
一方、要求先サーバの一つでもダイアグ通信中であるとき（Ｓ５３：Ｙｅｓ）、クライアント（２）へ、要求に応じない旨を示す否定応答コード＄２１を含む応答２１を送信する（Ｓ５６）。
【０１１４】
上述の構成で、サーバ３が、クライアント（３）からの要求に基づく処理を終了した後に、調停ＥＣＵ１が全サーバに対して、クライアント２からの要求を送信するようにしてもよい。
【実施例４】
【０１１５】
図１９〜図２１を用いて、クライアントから一斉通信要求を受信したときの、調停の詳細の第２実施例について説明する。本実施例では他のクライアントとの通信を行っていないサーバについては、該要求に対応する処理を実行する。一方、他のクライアントとの通信を行っているサーバについては、否定応答コード＄２１を送信して要求を拒否するか、否定応答コード＄７８を送信して他のクライアントとの通信終了後に処理を行うかのいずれかとする。
【０１１６】
図１９の構成は、図３の構成に、サーバ１，サーバ２を追加したものであるため、ここでの詳細な説明は割愛する。
【０１１７】
図２０のように、調停ＥＣＵ１がクライアント３からの要求３１を受信して、サーバ３に要求１１（ＳＦ）を送信し、サーバ３と通信中（すなわち、クライアント３からの要求に基づく処理を実行中）のときに、クライアント２からの要求２１（一斉通信要求：ＳＦ，ＭＦのいずれでもよい）を受信したとき、調停ＥＣＵ１は、サーバ１，サーバ２に対し、クライアント２からの要求２１に対応する要求１２を送信する。サーバ１，サーバ２は、他のクライアントからの要求に基づく処理を行っていないので、この要求１２に基づく処理を実行し、その結果を応答（１２）として調停ＥＣＵ１に送信する。サーバ１，サーバ２から処理結果を受信した調停ＥＣＵ１は、それらを受信次第、応答（２１）としてクライアント２に送信する。
【０１１８】
サーバ３は、クライアント３からの要求に基づく処理を実行中であるため、調停ＥＣＵ１は、以下のうちのいずれかの処理を行う。
・クライアント３からの要求に基づく処理を優先し、クライアント２からの要求は受け付けない。すなわち、調停ＥＣＵ１は、クライアント２に、要求は受け入れることができない旨の否定応答コード（ＳＦ）を送信する（応答２１）。否定応答は、例えば＄２１（十六進数の２１）で示される。
【０１１９】
・クライアント３からの要求に基づく処理を優先し、クライアント２からの要求を待たせる。このとき、調停ＥＣＵ１は、クライアント２に、要求は受け入れたが直ちに処理を行うことができない旨の否定応答コード（ＳＦ）を送信する。否定応答は、例えば＄７８（十六進数の７８）で示される。そして、クライアント３からの要求に基づく処理が終了した後に、サーバ３に、クライアント２からの要求２１を要求１２として送信する。サーバ３は、クライアント２からの要求に基づく処理を実行して、その結果を調停ＥＣＵ１に送信する。
【０１２０】
・クライアント２からの要求を優先し、サーバ３に要求１２を送信する。サーバ３は、要求１２を受信したら、クライアント３からの要求に基づく処理を中断し、クライアント２からの要求に基づく処理を実行して、その結果を調停ＥＣＵ１に送信する。調停ＥＣＵ１はサーバ３から受信した結果を応答２１としてクライアント３に送信する。その後、サーバ３は、クライアント３からの要求に基づく処理を再開し、処理終了後、応答１１を調停ＥＣＵ１に送信する。そして、調停ＥＣＵ１は応答１１を応答３１としてクライアント３に送信する。クライアント３の処理の中断・再開に関するシーケンスは、図１１に準ずる。
【０１２１】
図２１に、図１９，図２０における、調停ＥＣＵ１で実行されるプログラムに含まれる調停処理のフローを示す。まず、クライアント（図１９，図２０では、クライアント２に相当）からダイアグ要求（図１９，図２０では、「要求２１」と表記）を受信したとき、その要求がシングルフレーム（ＳＦ）通信によるものか否かを判定する（Ｓ７１）。
【０１２２】
要求がシングルフレーム通信によるものであるとき（Ｓ７２：Ｙｅｓ）、上述のいずれかの方法により調停を行う（Ｓ７３）。一方、マルチフレーム（ＭＦ）通信によるものであるとき（Ｓ７２：Ｎｏ）、例えば図４のように、残りのフレームを受信し（Ｓ７４）、上述のいずれかの方法により調停を行う（Ｓ７３）。
【０１２３】
以上、本発明の実施の形態を説明したが、これらはあくまで例示にすぎず、本発明はこれらに限定されるものではなく、特許請求の範囲の趣旨を逸脱しない限りにおいて、当業者の知識に基づく種々の変更が可能である。
【符号の説明】
【０１２４】
サーバ１〜３ サーバ
クライアント１〜３ クライアント
調停ＥＣＵ１ 調停部
５４ 調停機能（通信状態取得部）
【技術分野】
【０００１】
本発明は、車両に搭載された各種装置と、ダイアグテストツールのようなデータ読み出し用端末との通信を効率よく行うための車両用電子制御装置に関する。
【背景技術】
【０００２】
車両には電子制御装置（「ＥＣＵ」ともいう）が多数、例えば、エンジンＥＣＵ、エンジンの駆動と停止を行いながら車両を走行させるエコランＥＣＵ、ドアやロックの制御を行うボデーＥＣＵ、自動変速（ＡＴ）制御ＥＣＵ、エアバッグＥＣＵ、盗難が発生した場合や盗難が発生する可能性がある事象を検知した場合に警報を発生するセキュリティＥＣＵ等のような電子制御装置（ＥＣＵ）が多数搭載されており、各ＥＣＵは、担当する制御対象について、単体で独自に制御しているが、他のＥＣＵとの情報の授受が必要な場合もある。
【０００３】
このため、車両に搭載する複数のＥＣＵを関連付けして各種制御を行うために、その複数のＥＣＵを共通のバスラインに接続するとともに、代表的標準ネットワーク・プロトコルであるコントロールエリアネットワーク（Controller Area Network、以下ＣＡＮという）プロトコル等を使用して相互通信制御を行っている。
【０００４】
また、各ＥＣＵは自己診断機能を備え、信頼性の向上が図られている。すなわち、各ＥＣＵはＣＰＵやセンサ類の動作状態を適当な周期で自動的にチェックし、故障時には異常ランプを点灯したり、その故障内容が修理業者に分かるように異常コードを記憶したりするダイアグノーシス（以下、ダイアグという）処理を行っている。そして、このような診断情報（「ダイアグ情報」ともいう）は、修理工場等において、ダイアグテストツール（故障診断用端末）のようなデータ読み出し用端末を診断コネクタ経由でＥＣＵに接続することにより読み出すことができ、修理工場では読み出した故障コードに応じた修理が可能となる。
【０００５】
ダイアグ通信はＣＡＮ通信を用いることが主流になりつつある。ダイアグ通信では、例えば、ＥＣＵがその要求を受けてから応答データの送信を開始するまでの時間等、その要求に対するＥＣＵの応答特性が法規で定められている。そこで、ダイアグテストツールの要求から車載ＥＣＵが最初の応答を行うまでの時間的な制約を満足することができるとともに、従来の車両も規格統一を図ることが可能な通信変換制御装置が考案されている（特許文献１参照）。
【０００６】
また、第１ＥＣＵにおいて、第２ＥＣＵからのアクセス要求を受けたとき、第３ＥＣＵからのアクセス要求に応じた処理を実行している最中であれば、その第３ＥＣＵからのアクセス要求に応じた処理を開始してからの経過時間と予め定められた一定時間とを比較し、経過時間が一定時間より短ければ、第３ＥＣＵからのアクセス要求に応じた処理を中止して第２ＥＣＵからのアクセス要求に応じた処理を開始し、経過時間が一定時間より長ければ、第３ＥＣＵからのアクセス要求に応じた処理が終了した後に第２ＥＣＵからのアクセス要求に応じた処理を開始する通信調停システムが考案されている（特許文献２参照）。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００６−３５２２０１号公報
【特許文献２】特開２００１−１１１５５９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
図２２に、従来技術によるダイアグ通信の概要を示す。図２２では、ＥＣＵを、故障診断結果を記憶し、クライアントの要求にしたがって通信出力する機能を含むため、サーバと称している。ダイアグ通信による故障診断は、上述のように、主として修理工場やディーラ等で、ダイアグテストツール（クライアント１）により車内ＬＡＮ４０に接続してアクセスするといった限られた範囲から、遠隔地からパソコン（クライアント２）等でインターネット等を経由し車内ＬＡＮ４０に接続してリモート診断したり、車内ＬＡＮ４０上の車両用ナビゲーション装置（ナビ：クライアント３）等の車載装置を用いる等、通信形態が変化しつつある。
【０００９】
このように、サーバにアクセス可能なクライアントが増加すると、複数のクライアントから１つのサーバに同時にアクセスする状況も生ずる。しかし、サーバが１台のクライアントとしか通信できない構成のとき、あるいはサーバの処理能力が高くないときには、同時に複数のクライアントから要求信号が送られてくると、サーバ側で通信調停を行う必要がある。
【００１０】
サーバ１〜３はＥＣＵであるため、周知のマイクロコンピュータ（マイコンともいう），メモリ，センサ信号を取り込む入力回路，アクチュエータを動作させるためのドライバ回路，他のＥＣＵとのデータ通信を行う通信回路を含んでいる。但し、図２２においては、後述する本発明の構成に関連する各クライアント（１〜３）との通信機能（クライアント１通信機能１０１等）および調停機能（１０４等）を示すにとどめ、ＥＣＵ自体の機能の詳細な説明は割愛する。クライアント通信機能は、例えば周知のＬＡＮ通信インターフェース回路として構成され、マイコンの制御に基づいて動作する。また、調停機能は、例えば上述のメモリに記憶された、マイコンが実行するプログラムとして構成される。
【００１１】
クライアント（１〜３）は、上述のように、それぞれ、ダイアグテストツール，パソコン，ナビに相当しているが、サーバと同様に、後述する本発明の構成に関連する、他のクライアントとの調停機能（１１，１２等）および通信機能（１３等）を示すにとどめ、各装置が有する本来の機能の詳細な説明は割愛する。他のクライアントとの調停機能は、例えば、それぞれの装置で実行されるプログラムとして構成され、通信機能は、ＬＡＮ通信インターフェース回路，無線通信回路として構成される。
【００１２】
そして、各サーバと各クライアントとは、車内ＬＡＮ４０によりネットワーク接続されている。無論、リモート端末となるクライアント２も、例えば、車内ＬＡＮ４０に接続された無線通信機（図示せず）を介して、車内ＬＡＮ４０に接続している。
【００１３】
以下、従来技術による通信調停の概要を述べる。通信調停にはクライアント同士で調停する方法と、サーバ内で調停する方法とがある。クライアント同士で調停する方法は、例えばトークンのような送信権を設定し、この送信権をクライアントが例えば予め定められた順序で獲得し、通信が終了したら（通信を行う必要がないときも）送信権を開放し、次のクライアントが獲得する。クライアント１が送信権を獲得すると、クライアント２との調停機能１１およびクライアント３との調停機能１２を用いて、クライアント２およびクライアント３にサーバとの通信を行わないよう、データを送信する。そして、クライアント１がサーバ１に要求信号を送信すると、サーバ１がそれに応じて応答信号を返送する。このとき、クライアント２がサーバ１に要求信号を送信しても、サーバ１は通信を行うことができない旨の否定応答信号を返送するか、クライアント１以外からの要求信号に対しては全く応答しない。
【００１４】
上述の構成では、クライアントが増加すると、他の全てのクライアントに、新しいクライアントとの調停機能（ハード，ソフトのうちの少なくとも一方）を組み込む必要があり、そのためにＲＯＭやＲＡＭの容量に余裕を持たせておかなければならず、コストアップにつながるという課題を生ずる。
【００１５】
また、サーバ内で調停する方法は、例えば、サーバ１がクライアント１との通信中に、クライアント２からの通信要求を受信したときには、サーバ１自身が調停機能１０４を用いて調停を行い、その要求に応答できない旨（否定応答）をクライアント２に送信する。
【００１６】
上述の構成では、クライアントが増加すると、全てのサーバに新しいクライアントとの通信機能（ハード，ソフト）を追加するとともに、調停機能の対象に新しいクライアントを含めるための改造（ソフトの修正等）を行う必要があり、いずれもコストアップにつながるという課題を生ずる。
【００１７】
上記のような背景に基づいて、本発明の課題は、車両に搭載されたサーバに接続するためのクライアントを追加する際の改造範囲をより小さくし、低コストで改造を行うことが可能な車両用電子制御装置を提供することにある。
【課題を解決するための手段および発明の効果】
【００１８】
上記課題を解決するための車両用電子制御装置は、予め定められた機能を実行する１以上のサーバと、サーバとの通信の確立を要求するための要求信号を送信する１以上のクライアントと、サーバとクライアントとの間に介在し、サーバとクライアントとの通信を調停する１つの調停部と、が、ネットワーク上に配置され、調停部は、サーバの通信状態を取得する通信状態取得部を含み、要求信号を受信したとき、該要求信号の対象となるサーバの通信状態に基づいて、該クライアントと該サーバとの通信の確立を許可するか否かを決定することを特徴とする。
【００１９】
上記構成によって、従来の構成（例えば、図２２）のように、クライアント間で調停したり、サーバ内で調停する必要がなくなり、クライアントおよびサーバの調停機能を調停部に集約できるため、クライアントおよびサーバのハードウェア構成およびソフトウェア構成を簡略化でき、処理負荷を低減できるとともにクライアントおよびサーバのコストダウンも可能となる。
【００２０】
また、本発明の車両用電子制御装置における調停部は、要求信号の対象となるサーバが他のクライアントと通信中のとき、要求信号の送信元のクライアントと他のクライアントの通信の優先順位に基づいて、要求信号の送信元のクライアントと該要求信号の対象となるサーバとの通信と、該サーバと他のクライアントとの通信とのうち、いずれを優先させるかの調停を行う。
【００２１】
上記構成によって、適切な調停（どのクライアントを優先させるか）を行うことで、ユーザの利便性を確保できる。
【００２２】
また、本発明の車両用電子制御装置における要求信号は、複数の通信フレームにより構成され、調停部とクライアントとの間の通信は１フレーム単位で行われ、調停部は、要求信号の最初の通信フレームを受信したときに調停を行う。
【００２３】
上記構成によって、要求信号が複数の通信フレームにより構成されるときには、全フレームを受信することなく調停を行うことができるので、要求信号を受信してから調停を行うまでの時間を短縮できる。
【００２４】
また、本発明の車両用電子制御装置における調停部は、要求信号に含まれるデータ内容に基づいて、要求信号の送信元のクライアントと該要求信号の対象となるサーバとの通信と、該サーバと他のクライアントとの通信とのうち、いずれを優先させるかの調停を行う。
【００２５】
上記構成によって、適切な調停を行うことができるとともに、新たなクライアントを追加しても、調停部で対応する設定操作を行う必要はなく、ユーザの操作負荷を低減することができる。
【００２６】
また、本発明の車両用電子制御装置は、クライアント毎に、通信の優先順位が予め定められ、調停部は、要求信号に含まれる優先順位に基づいて、要求信号の送信元のクライアントと要求信号の対象となるサーバとの通信と、該サーバと他のクライアントとの通信とのうち、いずれを優先させるかを決定する。
【００２７】
上記構成によっても、適切な調停を行うことができるとともに、新たなクライアントを追加しても、調停部で対応する設定操作を行う必要はなく、ユーザの操作負荷を低減することができる。
【００２８】
また、本発明の車両用電子制御装置における調停部は、要求信号の送信元のクライアントの優先順位が、他のクライアントの優先順位よりも低いとき、該クライアントに対し、サーバとの通信が可能になるまで待機する旨の応答、あるいは、該サーバとの通信を不許可とする旨の応答のいずれかを行う。
【００２９】
上記構成によって、要求信号の送信元のクライアントの優先順位が、他のクライアントの優先順位よりも低いときに、適切な調停を行うことができる。また、要求信号の送信元のクライアントを、サーバとの通信が可能になるまで待機させる構成のときには、該クライアントの要求にも応じることができる。
【００３０】
また、本発明の車両用電子制御装置における調停部は、要求信号の送信元のクライアントの優先順位が、他のクライアントの優先順位よりも高いとき、サーバと他のクライアントとの通信を中断あるいは中止させて、要求信号の送信元のクライアントと要求信号の対象となるサーバとの通信を許可する。また、要求信号の送信元のクライアントを、サーバとの通信が可能になるまで中断させる構成のときには、該クライアントの要求にも応じることができる。
【００３１】
上記構成によって、要求信号の送信元のクライアントの優先順位が、他のクライアントの優先順位よりも高いときに、要求信号の送信元のクライアントを優先させることができる。
【００３２】
また、本発明の車両用電子制御装置における要求信号は、ネットワーク上に備えられる全てのサーバに対するもので、調停部は、全てのサーバの通信状態に基づいて、該クライアントと該全てのサーバとの通信を許可するか否かを決定する。
【００３３】
上記構成によって、クライアントが一度に全てのサーバとの通信を確立したいときにも、適切な調停を行うことができる。
【００３４】
また、本発明の車両用電子制御装置における調停部は、サーバあるいはクライアントのいずれか１つに備えられる。
【００３５】
上記構成によって、サーバあるいはクライアントと、ハードウェアあるいはソフトウェアの少なくとも一部を共用できるので、調停部の製造コストを低減することができる。
【００３６】
また、本発明の車両用電子制御装置は、サーバあるいはクライアントを含む通信ネットワークは複数あり、その通信ネットワーク毎に前記調停部と接続する。
【００３７】
上記構成によって、通信ネットワーク系が複数あるときにも、調停部をネットワークのゲートウェイのような位置づけとし、１台の調停部により調停を行うことができる。
【００３８】
また、本発明の車両用電子制御装置における調停部は、ネットワーク上に複数備えられる。
【００３９】
上記構成によって、クライアントあるいはサーバの数が増加して、調停部１台あたりの調停能力を超えたときにも、調停部を複数配置することで適切な調停を行うことができる。
【図面の簡単な説明】
【００４０】
【図１】本発明の車両用電子制御装置の構成を示す図。
【図２】サーバ〜クライアント間の通信について説明する図。
【図３】調停の詳細を説明する図（実施例１）。
【図４】フレーム単位の調停について説明する図（実施例１）。
【図５】メッセージ単位の調停について説明する図（実施例１）。
【図６】メッセージ単位の調停の別例について説明する図（実施例１）。
【図７】調停処理を説明するフロー図（実施例１）。
【図８】調停の詳細を説明する図（実施例２）。
【図９】メッセージ単位の調停について説明する図（実施例２）。
【図１０】フレーム単位の調停について説明する図（実施例２）。
【図１１】メッセージ単位の調停の別例について説明する図（実施例２）。
【図１２】フレーム単位の調停の別例について説明する図（実施例２）。
【図１３】調停処理を説明するフロー図（実施例２）。
【図１４】従来の構成による一斉通信要求における調停方法を示す構成図。
【図１５】従来の構成による一斉通信要求における調停方法を示す図。
【図１６】一斉通信要求における調停方法を示す構成図（実施例３）。
【図１７】一斉通信要求における調停方法を示す図（実施例３）。
【図１８】一斉通信要求における調停処理を説明するフロー図（実施例３）。
【図１９】一斉通信要求における調停方法の別例を示す構成図（実施例４）。
【図２０】一斉通信要求における調停方法の別例を示す図（実施例４）。
【図２１】一斉通信要求における調停処理の別例を説明するフロー図（実施例４）。
【図２２】従来技術による車両用電子制御装置の構成を示す図。
【発明を実施するための形態】
【００４１】
以下、本発明の車両用電子制御装置について、図面を用いて説明する。図１に、車両用電子制御装置の構成を示す。なお、本構成は、図２２の構成において機能を追加・削除したものであるため、図２２と同様の構成のものについては同一の符号を付与し、ここでの詳細な説明は割愛する。
【００４２】
クライアント１〜３は、図２２の構成から、他のクライアントとの調停機能（１１，１２等：破線枠で表記したもの）が削除されている。また、通信機能（１３等）は、主に調停ＥＣＵ１を介してサーバ１〜３との通信を行うための通信インターフェースである。
【００４３】
サーバ１〜３は、図２２の構成から、各クライアントとの通信機能のうちの一つがクライアント通信機能（１１１等）に置き換わり、残り（破線枠で表記したもの）は削除されている。クライアント通信機能は、主に調停ＥＣＵ１を介してクライアント１〜３との通信を行うための通信インターフェースである。
【００４４】
調停ＥＣＵ１は、図２２の構成では各サーバに含まれていた、各クライアントとの通信機能（１０１等）および調停機能（１０４等）を１か所（クライアント１通信機能５１，クライアント２通信機能５２，クライアント３通信機能５３，調停機能５４）に集約したものである。上述のように、従来はクライアント同士、あるいは、サーバ内で調停していたものを、本発明では、調停ＥＣＵ１で調停するようにしている。これにより、各クライアント内の、各クライアントとの調整機能、およびサーバ内の調整機能とクライアント毎の通信機能が不要となる。なお、調停ＥＣＵ１が本発明の調停部に相当する。また、調停機能５４が本発明の通信状態取得部に相当する。
【００４５】
調停ＥＣＵを複数設けてもよい。図１では、調停ＥＣＵ２が設けられている。構成は調停ＥＣＵ１と同様である。そして、例えば、調停ＥＣＵ１は、各クライアントからのサーバ２およびサーバ３に対する要求（本発明の「要求信号」、以下も同様）を調停し、調停ＥＣＵ２は、各クライアントからのサーバ１に対する要求を調停する。但し、通信効率やコストの面を考慮すると、特にクライアント数が少ないときには、調停ＥＣＵは１台であることが望ましい。
【００４６】
また、サーバ５を車内ＬＡＮ４０とは別のネットワークである車内ＬＡＮ４１を介して調停ＥＣＵ１に接続する構成としてもよい。これにより、他の通信系に接続されているサーバへの要求も調停することが可能となる。
【００４７】
また、従来構成の、各クライアントとの通信機能４０１〜４０３および調停機能４０４を備えるサーバ４を車内ＬＡＮ４０に接続する構成としてもよい。この場合、調停ＥＣＵ１，調停ＥＣＵ２は、サーバ４に対する要求の調停は行わず、通信データの中継のみ行う。このように、新旧のサーバが混在する環境下でも、調停ＥＣＵ１は柔軟に対応できる。無論、サーバ４の調停機能も調停ＥＣＵ１に集約することが望ましい。
【００４８】
また、調停ＥＣＵ１の、クライアント通信機能（５１〜５３）および調停機能５４をサーバ１〜３，クライアント１〜３のいずれかに含めてもよい。特に、エンジンＥＣＵは、内燃機関を有する車両（ハイブリッド車両を含む）には必ず搭載されているので、調停部として適している。また、電気自動車（ハイブリッド車両を含む）では、調停部を、駆動用モータを制御するモータ制御ＥＣＵに含めることが適している。
【００４９】
図２に、ダイアグ通信を例に挙げて、サーバ〜クライアント間の通信について説明する。図２の左側は、送信するデータが１つのフレームにより構成されるシングルフレーム（Single Frame：ＳＦ）による通信を示したもので、右側は、送信するデータが複数のフレームにより構成されるマルチフレーム（Multi Frame：ＭＦ）による通信を示したものである。
【００５０】
シングルフレーム通信の場合は、クライアントがサーバに対して何らかの要求（例えば、故障診断用のデータであるダイアグデータの送信要求）を送信すると、サーバでその要求を解析し、解析結果に応じたサービス（データ読み出し等）を実行し、その結果（読み出したデータ等）をクライアントに送信する。シングルフレーム通信では、１フレーム＝１メッセージであるため、フレームレベルでの調停ができないので、メッセージ単位での調停を行う。
【００５１】
マルチフレーム通信の場合は、クライアントがサーバに対して何らかの要求（データ要求）を行う要求を送信する際、まず、マルチフレーム（ＭＦ）で構成される要求の先頭フレーム（First Frame：ＦＦ）を送信する。サーバは、先頭フレーム（ＦＦ）を受信すると、受信可能な旨を含むＦＣ（Flow Control）をクライアントに送信する。クライアントは、該ＦＣを受信すると、要求の残りのフレーム（Consecutive Frame：ＣＦ）を順次送信する。
【００５２】
サーバは、全フレームを受信すると、その要求を解析し、解析結果に応じたサービスを行い、その結果をマルチフレームでクライアントに送信する。すなわち、まず、サーバは、応答の先頭フレーム（ＦＦ）を送信し、クライアントからの受信可能な旨を含むＦＣを受信した後、応答の残りのフレーム（ＣＦ）を順次送信する。マルチフレーム通信では、複数フレーム＝１メッセージであるため、フレーム単位での調停が必要となる。
【００５３】
なお、ＣＡＮベースの診断インターフェースは、ＩＳＯ１５７６５−２（フレームに関するもの），ＩＳＯ１４２２９−１（メッセージの構築に関するもの）の規定に基づいている。
【００５４】
以下、調停ＥＣＵ１におけるメッセージ単位およびフレーム単位での調停の詳細について説明する。なお、調停の優先順位は、以下のうちの一つ、あるいは複数の組み合わせを用いる。
・先に要求信号を受信したクライアントを優先する。
・後から要求信号を受信したクライアントを優先する。
・予めクライアントに優先順位を設定し、要求信号を受信したクライアントの優先順位を比較する。例えば、ダイアグテストツール（優先順位：高）＞車載装置（ナビ等）＞リモート端末（優先順位：低）。
・要求信号の内容に応じて優先順位が予め定められる。例えば、要求信号に含まれるＳＩＤ：サービスＩＤに優先順位を含ませる。優先順位は調停ＥＣＵ１に記憶する。
【実施例１】
【００５５】
図３〜図７を用いて、調停の詳細の第1実施例について説明する。本実施例では、以下のように調停を行う。
・メッセージ単位の調停：現在サーバと通信中のクライアントよりも優先順位の低いクライアントからの要求は受け付けない。
・フレーム単位の調停：現在サーバと通信中のクライアントよりも優先順位の低いクライアントからの要求があったときには、その要求を受け付け、現在サーバと通信中のクライアントの処理終了後に、サーバとの通信を許可する。
【００５６】
図３を用いて、本実施例における車両用電子制御装置の構成の概要を説明する。本実施例では、クライアント２とクライアント３からのサーバ３に対する要求を調停ＥＣＵ１が調停する。調停ＥＣＵ１は、図１の構成に加え、クライアント２通信機能５２に含まれるクライアント２用受信部５２ａ、クライアント３通信機能５３に含まれるクライアント３用受信部５３ａ、クライアント２，３にデータを送信する送信部５５（対象クライアント毎にクライアント２通信機能５２，クライアント３通信機能５３に送信部を含む構成でもよい）、図示しないメモリの一部に確保される要求退避用バッファ５６を備えている。
【００５７】
図４を用いて、先にサーバ３とクライアント３とが通信中のときに、クライアント３よりも優先順位の低いマルチフレーム通信を行うクライアント２からの要求が送信されときの調停のうち、フレーム単位の調停の詳細について説明する。
【００５８】
クライアント３からの要求３１（ＳＦ）を受信した調停ＥＣＵ１は、要求先のサーバ３がアイドル状態であるとき、その要求を要求１１（ＳＦ）としてサーバ３に送信する。サーバ３は、受信した要求１１に基づいて図２で説明したような処理を実行し（処理中１）、処理結果を応答１１（ＳＦ）として調停ＥＣＵ１に送信する。調停ＥＣＵ１は、受信した応答１１を応答３１（ＳＦ）としてクライアント３に送信する。
【００５９】
調停ＥＣＵ１がクライアント３からの要求３１を受信して、サーバ３に要求１１（ＳＦ）を送信し、サーバ３と通信中のときに、クライアント２からの要求２１の先頭フレーム（ＦＦ）を受信したとき、クライアント２に対し、受信可能な旨を含むＦＣを送信する。クライアント２は、該ＦＣを受信すると、要求の残りのフレームＣＦを、調停ＥＣＵ１に順次送信する。クライアント２からの要求は、要求退避用バッファ５６に記憶する。
【００６０】
調停ＥＣＵ１は、サーバ３がクライアント３からの要求に対する処理（処理中１）が終了するのを待つ。すなわち、サーバ３から応答１１（ＳＦ）が送信されてくるのを待つ。そして、サーバ３からの応答１１（ＳＦ）を受信すると、クライアント３にその旨を応答３１（ＳＦ）として送信する。その後、クライアント２からの要求データが要求退避用バッファ５６に記憶されているとき、これを読み出して要求１２（ＳＦ）としてサーバ３に送信する。サーバ３は、受信した要求１２に基づいて図２で説明したような処理を実行し（処理中２）、処理結果を応答１２（ＳＦ）として調停ＥＣＵ１に送信する。調停ＥＣＵ１は、受信した応答１２を応答２２（ＦＦ）としてクライアント２に送信する。以降、図２と同様に、クライアント２からの受信可能な旨を含むＦＣデータを受信した後、応答の残りのフレーム（ＣＦ）を順次送信する。
【００６１】
図５を用いて、メッセージ単位の調停のうち、先にサーバ３と通信中のクライアント３よりも優先順位の低いクライアント２からの要求が送信されたときの調停の詳細について説明する。サーバ３は、クライアント３からの要求に基づく処理のみを実行する。クライアント２からの要求は拒否する。
【００６２】
調停ＥＣＵ１がクライアント３からの要求３１を受信して、サーバ３に要求１１（ＳＦ）を送信し、サーバ３と通信中のときに、クライアント２からの要求２１（ＳＦ）を受信したとき、調停ＥＣＵ１はクライアント２に対し、要求を受け入れない旨を含む否定応答コード（ＳＦ）を送信する。否定応答は、例えば＄２１（十六進数の２１）で示される。クライアント２は、該否定応答を受信すると、要求に関する処理を終了する。
【００６３】
また、調停ＥＣＵ１がクライアント２からの要求２１を受信したとき、調停ＥＣＵ１はその要求に対し無応答としてもよい。クライアント２では、要求２１を送信してからの経過時間を測定し、予め定められた時間が経過した（すなわち、応答待ちタイムアウトした）ときに、調停ＥＣＵ１では要求が受け入れられなかったと判断し、要求に関する処理を終了する。すなわち、クライアントは、要求信号を送信後、予め定められた時間内に調停部からの応答を受信しないときには、該要求信号に基づくサーバとの通信が許可されたかったと判定する構成となる。
【００６４】
なお、図５におけるクライアント３とサーバ３との通信シーケンスは、図４と同様である。
【００６５】
図６を用いて、メッセージ単位の調停のうち、先にサーバ３と通信中のクライアント３よりも優先順位の高いクライアント２からの要求が送信されてきたときの調停の詳細について説明する。サーバ３は、クライアント３からの要求に基づく処理を中止し、以降、クライアント２からの要求に基づく処理のみを実行する。
【００６６】
調停ＥＣＵ１がクライアント３からの要求３１（ＳＦ）を受信して、サーバ３に要求１１（ＳＦ）を送信し、サーバ３と通信中（処理中１）のときに、クライアント２からの要求２１（ＳＦ）を受信したとき、調停ＥＣＵ１はクライアント３に対し、処理を中止し要求を受け入れない旨を含む否定応答（ＳＦ）を送信する。否定応答は、例えば＄２１（十六進数の２１）で示される。クライアント３は、該否定応答を受信すると、要求に関する処理を終了する。
【００６７】
次に、調停ＥＣＵ１は、クライアント２からの要求を受け入れ、クライアント２からの要求を要求１２（ＳＦ）としてサーバ３へ送信する。サーバ３は、要求１２を受信すると、クライアント３からの要求に基づく処理（処理中１）を中止し、要求１２に基づく処理を実行する処理中２の状態となる。そして、処理が終了すると、処理結果を応答１２（ＳＦ）として調停ＥＣＵ１に送信する。調停ＥＣＵ１は、応答１２を受信すると、応答２２（ＳＦ）としてクライアント２に送信する。
【００６８】
図７に、図３〜図６における、調停ＥＣＵ１で実行されるプログラムに含まれる調停処理のフローを示す。クライアント（図３〜図６では、クライアント２に相当）からダイアグ要求（図３〜図６では、「要求」と略記）を受信したとき、その要求がシングルフレーム（ＳＦ）通信によるものか否かを判定する（Ｓ１１）。シングルフレーム通信によるものではないとき（Ｓ１２：Ｎｏ）、図４のように、マルチフレーム（ＭＦ）の残りのフレームを受信する（Ｓ１５）。そして、ステップＳ１３へ進む。
【００６９】
一方、シングルフレーム通信によるものであるとき（Ｓ１２：Ｙｅｓ）、ステップＳ１３へ進む。ステップＳ１３では、要求先のサーバ（図３〜図６では、サーバ３に相当）が他のクライアント（図３〜図６では、クライアント３に相当）と通信中（図７では、「ダイアグ通信中」と表記）であるか否かを判定する。ダイアグ通信中、つまり他のクライアントの要求に基づく処理を実行中のとき（Ｓ１３：Ｙｅｓ）、クライアント（２，３）の優先度を比較する。クライアント（２）の優先度が低いとき（Ｓ１６：Ｎｏ）、クライアント（２）へ否定応答＄２１を送信する（Ｓ１７，図５に相当）。
【００７０】
一方、ダイアグ通信中でないとき（Ｓ１３：Ｎｏ）、あるいは、クライアント（２）の優先度が高いとき（Ｓ１６：Ｙｅｓ）、クライアント（２）からの要求をサーバ（３）へ送信する（Ｓ１４，図４の後半部あるいは図６に相当）。なお、クライアント（２）の優先度が高いとき（Ｓ１６：Ｙｅｓ）、先にサーバ（３）と通信中のクライアント（３）に否定応答＄２１を送信してもよい（図６に相当）。サーバ（３）は、クライアント（３）の要求に基づく処理を中止し、クライアント（２）の要求に基づく処理を実行する。
【００７１】
また、クライアント３では、調停ＥＣＵ１へ要求３１を送信してから所定時間以内に調停ＥＣＵ１からの応答（３１）を受信しないときには、要求が受け入れられなかったと判断して、該要求に関する処理を終了してもよい。
【実施例２】
【００７２】
図８〜図１３を用いて、調停の詳細の第２実施例について説明する。本実施例では、以下のように調停を行う。
・メッセージ単位の調停：優先順位の低いクライアントからの要求信号を待たせて、優先順位の高いクライアントの処理実行後に、優先順位の低いクライアントの処理を実行する。
・フレーム単位の調停：優先順位の低いクライアントからの要求信号を待たせて、優先順位の高いクライアントの処理実行後に、優先順位の低いクライアントの処理を実行する。
すなわち、現在サーバと通信中のクライアントよりも優先順位の高いクライアントからの要求信号があったときには、その要求信号を受け付け、現在サーバと通信中のクライアントの通信を中断して、サーバと優先順位の高いとの通信を行い、該通信終了後に、中断していたサーバとクライアントとの通信を再開する構成である。
【００７３】
本実施例では、クライアント２とクライアント３からのサーバ３に対する要求を調停ＥＣＵ１が調停する。図８の調停ＥＣＵ１等の構成は、図３と同様である。なお、クライアント２用受信部５２ａ，クライアント３用受信部５３ａは、一括して受信部として表記してある。
【００７４】
図９を用いて、先にサーバ３とクライアント３とが通信中のときに、クライアント３よりも優先順位の低いシングルフレーム通信を行うクライアント２からの要求が送信されたときの、メッセージ単位の調停の詳細について説明する。
【００７５】
調停ＥＣＵ１がクライアント３からの要求３１を受信して、サーバ３に要求１１（ＳＦ）を送信し、サーバ３と通信中（すなわち、クライアント３からの要求に基づく処理を実行中）のときに、クライアント２からの要求２１（ＳＦ）を受信したとき、調停ＥＣＵ１はクライアント２に対し、要求は受け入れたが直ちに処理を行うことができない旨の否定応答コード（ＳＦ）を送信する。否定応答は、例えば＄７８（十六進数の７８）で示される。クライアント２は、該否定応答を受信すると、調停ＥＣＵ１からの応答を受信するまで待機する。クライアント２からの要求２１は、要求退避用バッファ５６に記憶する。
【００７６】
なお、否定応答は、１回のみ送信してもよいし、予め定められたタイミング（例えば、クライアント２で通信のタイムアウトを判定しないような周期）で送信してもよい。
【００７７】
サーバ３での処理（処理中１）が終了し、サーバ３が調停ＥＣＵ１に処理結果を応答１１（ＳＦ）として送信すると、調停ＥＣＵ１は、これを応答３１（ＳＦ）としてクライアント３に送信する。その後、クライアント２からの要求２１を要求退避用バッファ５６に記憶してあるとき、これを読み出して要求１２としてサーバ３に送信する。サーバは要求１２を受信すると、その要求に応じた処理を実行する（図４の処理中２のシーケンスに準ずる）。
【００７８】
図１０を用いて、先にサーバ３とクライアント３とが通信中のときに、クライアント３よりも優先順位の低いマルチフレーム通信を行うクライアント２からの要求が送信されたときの、フレーム単位の調停の詳細について説明する。
【００７９】
調停ＥＣＵ１がクライアント３からの要求３１を受信して、サーバ３に要求１１（ＳＦ）を送信し、サーバ３と通信中（すなわち、処理中１）のときに、クライアント２からの要求２１（ＦＦ）を受信したとき、調停ＥＣＵ１はクライアント２に対し、要求は受け入れたが直ちに処理を行うことができないため待機を指示する旨のＦＣを送信する。クライアント２は、該ＦＣを受信すると、調停ＥＣＵ１からの応答を受信するまで待機する。クライアント２からの要求２１は、要求退避用バッファ５６に記憶する。
【００８０】
なお、ＦＣは、１回のみ送信してもよいし、予め定められたタイミング（例えば、クライアント２で通信のタイムアウトを判定しないような周期）で送信してもよい。
【００８１】
サーバ３での処理が終了し、サーバ３が調停ＥＣＵ１に処理結果を応答１１（ＳＦ）として送信すると、調停ＥＣＵ１は、これを応答３１（ＳＦ）としてクライアント３に送信する。その後、クライアント２からの要求２１を要求退避用バッファ５６に記憶してあるとき、データを受信可能な旨を含むＦＣをクライアント２に送信する。クライアント２は、該ＦＣを受信すると、要求データの残りのフレームＣＦを順次送信する。
【００８２】
調停ＥＣＵ１は、ＣＦを全フレーム受信すると、要求１２としてサーバ３に送信する。サーバは要求１２を受信すると、その要求に応じた処理を実行する（図４の処理中２のシーケンスに準ずる）。
【００８３】
なお、図１０の構成で、クライアント２からの要求を受け入れないときには、ＥＣＵ１はクライアント２に最初のＦＣを送信するタイミングで、図５のような否定応答（＄２１：ＳＦ）を送信する。
【００８４】
図１１を用いて、先にサーバ３と通信中のクライアント３よりも優先順位の高いクライアント２からの要求が送信されてきたときの、メッセージ単位の調停の詳細について説明する。
【００８５】
調停ＥＣＵ１がクライアント３からの要求３１を受信して、サーバ３に要求１１（ＳＦ）を送信し、サーバ３と通信中（すなわち、処理中１）のときに、クライアント２からの要求２１（ＳＦ）を受信したとき、調停ＥＣＵ１はサーバ３にクライアント２からの要求２１を要求１２として送信する。このとき、クライアント３に対して、要求は受け入れたが直ちに処理を行うことができない旨の否定応答コード（ＳＦ）を送信してもよい。否定応答は、例えば＄７８（十六進数の７８）で示される。また、クライアント３からの要求３１に基づく処理が終了していないことを、要求退避用バッファ５６に記憶する。
【００８６】
なお、否定応答は、１回のみ送信してもよいし、予め定められたタイミング（例えば、クライアント３で通信のタイムアウトを判定しないような周期）で送信してもよい。
【００８７】
サーバ３は調停ＥＣＵ１からの要求１２を受信すると、クライアント３に対応する処理（処理中１）を一時停止し、必要なデータを退避する。そして、調停ＥＣＵ１からの要求１２に基づくクライアント２に対応する処理（処理中２）を実行する。
【００８８】
サーバ３でのクライアント２に対応する処理が終了し、サーバ３が調停ＥＣＵ１に、処理結果を応答１２（ＳＦ）として送信すると、調停ＥＣＵ１は、これを応答２１（ＳＦ）としてクライアント２に送信する。サーバ３は、要求退避用バッファ５６に、クライアント３からの要求３１に基づく処理が終了していないことを記憶してある場合には、クライアント３に対応する処理を再開し（処理中１１）、該処理が終了すると、処理結果を調停ＥＣＵ１に応答１１（ＳＦ）として送信する。調停ＥＣＵ１は、これを応答３１（ＳＦ）としてクライアント３に送信する。
【００８９】
調停ＥＣＵ１は、サーバ３からの応答１２（ＳＦ）を受信したときに、要求退避用バッファ５６に、クライアント３からの要求３１に基づく処理が終了していないことを記憶してある場合には、サーバ３に対し、クライアント３からの要求３１に基づく処理を再開する旨のメッセージを送信してもよい。
【００９０】
図１２を用いて、先にサーバ３と通信中のクライアント３よりも優先順位の高いクライアント２からの要求信号が送信されてきたときの、フレーム単位の調停の詳細について説明する。
【００９１】
調停ＥＣＵ１がクライアント３からの要求３１を受信して、サーバ３に要求１１（ＳＦ）を送信し、サーバ３と通信中（すなわち、処理中１）のときに、クライアント２からの要求２１（ＦＦ）を受信したとき、調停ＥＣＵ１は、データを受信可能な旨を含むＦＣをクライアント２に送信する。クライアント２は、該ＦＣを受信すると、要求データの残りのフレームＣＦを順次送信する。
【００９２】
調停ＥＣＵ１はクライアント２からのフレームを全て受信すると（要求２１（ＦＦ）を受信したときでもよい）、調停ＥＣＵ１はサーバ３にクライアント２からの要求２１を要求１２として送信する。このとき、クライアント３に対して、要求は受け入れたが直ちに処理を行うことができない旨の否定応答コード（ＳＦ）を送信してもよい。否定応答は、例えば＄７８（十六進数の７８）で示される。また、クライアント３からの要求３１に基づく処理が終了していないことを、要求退避用バッファ５６に記憶する。
【００９３】
なお、否定応答は、１回のみ送信してもよいし、予め定められたタイミング（例えば、クライアント３で通信のタイムアウトを判定しないような周期）で送信してもよい。
【００９４】
サーバ３は調停ＥＣＵ１からの要求１２を受信すると、調停ＥＣＵ１からの要求１１に基づくクライアント３に対応する処理（処理中１）を一時停止し、必要なデータを退避する。そして、調停ＥＣＵ１からの要求１２に基づくクライアント２に対応する処理（処理中２）を実行する。
【００９５】
サーバ３でのクライアント２に対応する処理が終了し、サーバ３が調停ＥＣＵ１に処理結果を応答１２（ＳＦ）として送信すると、調停ＥＣＵ１は、これを応答２１（ＳＦ）としてクライアント２に送信する。その後、サーバ３は、要求退避用バッファ５６に、クライアント３からの要求３１に基づく処理が終了していないことを記憶してある場合には、クライアント３に対応する処理を再開し（処理中１１）、該処理が終了すると、調停ＥＣＵ１に処理結果を応答１１（ＳＦ）として送信する。調停ＥＣＵ１は、これを応答３１（ＳＦ）としてクライアント３に送信する。
【００９６】
調停ＥＣＵ１は、サーバ３から応答１２（ＳＦ）を受信したときに、要求退避用バッファ５６に、クライアント３からの要求３１に基づく処理が終了していないことを記憶してある場合には、サーバ３に対し、クライアント３からの要求３１に基づく処理を再開する旨のメッセージを送信してもよい。
【００９７】
図１３に、図８〜図１２における、調停ＥＣＵ１で実行されるプログラムに含まれる調停処理のフローを示す。クライアント（図８〜図１２では、クライアント２に相当）からダイアグ要求（図８〜図１２では、「要求」と略記）を受信したとき、その要求がシングルフレーム（ＳＦ）通信によるものか否かを判定する（Ｓ３１）。
【００９８】
要求がシングルフレーム通信によるものでないとき（Ｓ３２：Ｎｏ）、クライアント（２，３）の優先度を比較する。クライアント（２）の優先度が低いとき（Ｓ３５：Ｎｏ）、クライアント（２）へ待機を指示する旨のＦＣを送信する（Ｓ３６）。そして、クライアント（３）と要求先サーバ（サーバ３）のダイアグ通信が終了するのを待つ。この間、予め定められたタイミングでクライアント（２）へＦＣを送信する（Ｓ３６）。
【００９９】
クライアント（３）と要求先サーバ（サーバ３）のダイアグ通信が終了したとき（Ｓ３７：Ｙｅｓ）、クライアント（２）からの残りの要求データ（ＣＦ）を受信し（Ｓ３８）、ステップＳ３３へ進む。
【０１００】
一方、要求がシングルフレーム通信によるものであるとき（Ｓ３２：Ｙｅｓ）、あるいは、クライアント（２）の優先度が高いとき（Ｓ３５：Ｙｅｓ）、ステップＳ３３へ進む、ステップＳ３３では、クライアント（３）と要求先サーバ（サーバ３）との間でダイアグ通信中であるか否かを判定する。
【０１０１】
ダイアグ通信中であるとき（Ｓ３３：Ｙｅｓ）、クライアント（２，３）の優先度を比較する。クライアント（２）の優先度が低いとき（Ｓ３９：Ｎｏ）、クライアント（２）へ直ちに処理を実行できないため待機を指示する旨の否定応答＄７８（ＳＦ）を送信する（Ｓ４０）。そして、クライアント（３）と要求先サーバ（サーバ３）のダイアグ通信が終了するのを待つ。この間、予め定められたタイミングでクライアント（２）へ否定応答＄７８を送信する（Ｓ４０）。
【０１０２】
クライアント（３）と要求先サーバ（サーバ３）のダイアグ通信が終了したとき（Ｓ４１：Ｙｅｓ）、ステップＳ３４へ進む。
【０１０３】
一方、ダイアグ通信中でないとき（Ｓ３３：Ｎｏ）、あるいは、クライアント（２）の優先度が高いとき（Ｓ３９：Ｙｅｓ）、ステップＳ３４へ進む、ステップＳ３４では、クライアント（２）からの要求（ダイアグ要求）をサーバ（３）へ送信する。また、他のクライアント（３）とダイアグ通信中のとき、該クライアント（３）へ否定応答＄７８を送信する。
【０１０４】
以下、１台のクライアントから複数のサーバに一斉に要求（以下、「一斉通信要求」という）を送信したときの、調停ＥＣＵ１における調停の詳細について説明する。まず、図１４（図２２に準ずる），図１５を用いて、従来の構成による調停方法について説明する。クライアント間で調停を行う場合には、クライアント１が、クライアント２およびクライアント３との調停機能（１１，１２）を用いて通信権を獲得した後に、全サーバ（１〜３）に要求１を送信する。これは、サーバ毎に要求を送信するのではなく、１個のデータに全サーバに対する要求を行う意味を持たせる。要求を受信した各サーバは、それぞれ応答（３〜５）を送信する。
【０１０５】
また、サーバ側で調停を行う場合には、クライアント１からの要求１を受信したときに、それぞれの調停機能（１０４，２０４，３０４）を用いて調停を行った後、それぞれ応答（３〜５）を送信する。この場合、調停の結果、クライアント１からの要求１が優先されないこともありうる。クライアント１が、全サーバからの応答の全てを用いて何らかの解析を行う場合、データが揃わないため解析を実行できないこともある。また、優先されたクライアントの処理が終わった後に、サーバから遅れて応答が送信されたときも、応答データ間の同期がとれないという課題が生ずる。
【実施例３】
【０１０６】
図１６〜図１８を用いて、クライアントから一斉通信要求を受信したときの、調停ＥＣＵ１における調停の詳細の第１実施例について説明する。本実施例では、１台でも他のクライアントとの通信を行っているサーバがあるときには、一斉通信要求を拒否する構成となっている。
【０１０７】
図１６の構成は、図３の構成に、サーバ１，サーバ２を追加し、調停ＥＣＵ１の要求退避用バッファ５６を含まないものであるため、ここでの詳細な説明は割愛する。なお、クライアント２用受信部５２ａ，クライアント３用受信部５３ａは、一括して受信部として表記してある。
【０１０８】
図１７のように、調停ＥＣＵ１がクライアント３からの要求３１を受信して、サーバ３に要求１１（ＳＦ）を送信し、サーバ３と通信中（すなわち、処理中）のときに、クライアント２からの要求２１（一斉通信要求：ＳＦ，ＭＦのいずれでもよい）を受信したとき、調停ＥＣＵ１はクライアント２に対し、要求は受け入れることができない旨の否定応答コード（ＳＦ）を送信する（応答２１）。否定応答は、例えば＄２１（十六進数の２１）で示される。否定応答コードは、図１７のように、調停ＥＣＵ１が各サーバを代行する形でクライアント２に送信してもよいし、１つのメッセージにすべてのサーバを代行する内容を含む形で送信してもよい。
【０１０９】
この間、サーバ３は、クライアント（３）からの要求に基づく処理を継続し、処理が終了すると、調停ＥＣＵ１に処理結果を応答１１（ＳＦ）として送信する。調停ＥＣＵ１は、これを応答３１（ＳＦ）としてクライアント３に送信する。
【０１１０】
図１８に、図１６，図１７における、調停ＥＣＵ１で実行されるプログラムに含まれる調停処理のフローを示す。まず、クライアント（図１６，図１７では、クライアント２に相当）からダイアグ要求（図１６，図１７では、「要求２１」と表記）を受信したとき、その要求がシングルフレーム（ＳＦ）通信によるものか否かを判定する（Ｓ５１）。
【０１１１】
要求がシングルフレーム通信によるものであるとき（Ｓ５２：Ｙｅｓ）、要求先サーバ（サーバ１〜３）の全てについてダイアグ通信中であるか、すなわち他のクライアントからの要求に基づく処理を行っているか否かを調べる。一方、マルチフレーム（ＭＦ）通信によるものであるとき（Ｓ５２：Ｎｏ）、例えば図４のように、残りのフレームを受信し（Ｓ５５）、要求先サーバ（サーバ１〜３）の全てについてダイアグ通信中であるか否かを調べる。マルチフレーム（ＭＦ）通信のとき、先頭フレーム（ＦＦ）を受信したら、要求先サーバの全てについてダイアグ通信中であるか否かを調べてもよい。
【０１１２】
そして、要求先サーバのうちの全てがダイアグ通信中でないとき（Ｓ５３：Ｎｏ）、全サーバへ要求を送信する（Ｓ５４）。この後、各サーバで要求に対応する処理を実行し、調停ＥＣＵ１でその結果を受信すると、例えば、サーバからの受信順にクライアント（２）へ送信する（図１５の応答３，４，５に相当）。
【０１１３】
一方、要求先サーバの一つでもダイアグ通信中であるとき（Ｓ５３：Ｙｅｓ）、クライアント（２）へ、要求に応じない旨を示す否定応答コード＄２１を含む応答２１を送信する（Ｓ５６）。
【０１１４】
上述の構成で、サーバ３が、クライアント（３）からの要求に基づく処理を終了した後に、調停ＥＣＵ１が全サーバに対して、クライアント２からの要求を送信するようにしてもよい。
【実施例４】
【０１１５】
図１９〜図２１を用いて、クライアントから一斉通信要求を受信したときの、調停の詳細の第２実施例について説明する。本実施例では他のクライアントとの通信を行っていないサーバについては、該要求に対応する処理を実行する。一方、他のクライアントとの通信を行っているサーバについては、否定応答コード＄２１を送信して要求を拒否するか、否定応答コード＄７８を送信して他のクライアントとの通信終了後に処理を行うかのいずれかとする。
【０１１６】
図１９の構成は、図３の構成に、サーバ１，サーバ２を追加したものであるため、ここでの詳細な説明は割愛する。
【０１１７】
図２０のように、調停ＥＣＵ１がクライアント３からの要求３１を受信して、サーバ３に要求１１（ＳＦ）を送信し、サーバ３と通信中（すなわち、クライアント３からの要求に基づく処理を実行中）のときに、クライアント２からの要求２１（一斉通信要求：ＳＦ，ＭＦのいずれでもよい）を受信したとき、調停ＥＣＵ１は、サーバ１，サーバ２に対し、クライアント２からの要求２１に対応する要求１２を送信する。サーバ１，サーバ２は、他のクライアントからの要求に基づく処理を行っていないので、この要求１２に基づく処理を実行し、その結果を応答（１２）として調停ＥＣＵ１に送信する。サーバ１，サーバ２から処理結果を受信した調停ＥＣＵ１は、それらを受信次第、応答（２１）としてクライアント２に送信する。
【０１１８】
サーバ３は、クライアント３からの要求に基づく処理を実行中であるため、調停ＥＣＵ１は、以下のうちのいずれかの処理を行う。
・クライアント３からの要求に基づく処理を優先し、クライアント２からの要求は受け付けない。すなわち、調停ＥＣＵ１は、クライアント２に、要求は受け入れることができない旨の否定応答コード（ＳＦ）を送信する（応答２１）。否定応答は、例えば＄２１（十六進数の２１）で示される。
【０１１９】
・クライアント３からの要求に基づく処理を優先し、クライアント２からの要求を待たせる。このとき、調停ＥＣＵ１は、クライアント２に、要求は受け入れたが直ちに処理を行うことができない旨の否定応答コード（ＳＦ）を送信する。否定応答は、例えば＄７８（十六進数の７８）で示される。そして、クライアント３からの要求に基づく処理が終了した後に、サーバ３に、クライアント２からの要求２１を要求１２として送信する。サーバ３は、クライアント２からの要求に基づく処理を実行して、その結果を調停ＥＣＵ１に送信する。
【０１２０】
・クライアント２からの要求を優先し、サーバ３に要求１２を送信する。サーバ３は、要求１２を受信したら、クライアント３からの要求に基づく処理を中断し、クライアント２からの要求に基づく処理を実行して、その結果を調停ＥＣＵ１に送信する。調停ＥＣＵ１はサーバ３から受信した結果を応答２１としてクライアント３に送信する。その後、サーバ３は、クライアント３からの要求に基づく処理を再開し、処理終了後、応答１１を調停ＥＣＵ１に送信する。そして、調停ＥＣＵ１は応答１１を応答３１としてクライアント３に送信する。クライアント３の処理の中断・再開に関するシーケンスは、図１１に準ずる。
【０１２１】
図２１に、図１９，図２０における、調停ＥＣＵ１で実行されるプログラムに含まれる調停処理のフローを示す。まず、クライアント（図１９，図２０では、クライアント２に相当）からダイアグ要求（図１９，図２０では、「要求２１」と表記）を受信したとき、その要求がシングルフレーム（ＳＦ）通信によるものか否かを判定する（Ｓ７１）。
【０１２２】
要求がシングルフレーム通信によるものであるとき（Ｓ７２：Ｙｅｓ）、上述のいずれかの方法により調停を行う（Ｓ７３）。一方、マルチフレーム（ＭＦ）通信によるものであるとき（Ｓ７２：Ｎｏ）、例えば図４のように、残りのフレームを受信し（Ｓ７４）、上述のいずれかの方法により調停を行う（Ｓ７３）。
【０１２３】
以上、本発明の実施の形態を説明したが、これらはあくまで例示にすぎず、本発明はこれらに限定されるものではなく、特許請求の範囲の趣旨を逸脱しない限りにおいて、当業者の知識に基づく種々の変更が可能である。
【符号の説明】
【０１２４】
サーバ１〜３ サーバ
クライアント１〜３ クライアント
調停ＥＣＵ１ 調停部
５４ 調停機能（通信状態取得部）
【特許請求の範囲】
【請求項１】
予め定められた機能を実行する１以上のサーバと、
前記サーバとの通信の確立を要求するための要求信号を送信する１以上のクライアントと、
前記サーバと前記クライアントとの間に介在し、前記サーバと前記クライアントとの通信を調停する１つの調停部と、
が、ネットワーク上に配置され、
前記調停部は、
前記サーバの通信状態を取得する通信状態取得部を含み、
前記要求信号を受信したとき、該要求信号の対象となるサーバの通信状態に基づいて、該クライアントと該サーバとの通信の確立を許可するか否かを決定することを特徴とする車両用電子制御装置。
【請求項２】
前記調停部は、前記要求信号の対象となるサーバが他のクライアントと通信中のとき、前記要求信号の送信元のクライアントと前記他のクライアントの通信の優先順位に基づいて、前記要求信号の送信元のクライアントと該要求信号の対象となるサーバとの通信と、該サーバと前記他のクライアントとの通信とのうち、いずれを優先させるかの調停を行う請求項１に記載の車両用電子制御装置。
【請求項３】
前記要求信号は、複数の通信フレームにより構成され、
前記調停部と前記クライアントとの間の通信は１フレーム単位で行われ、
前記調停部は、前記要求信号の最初の通信フレームを受信したときに前記調停を行う請求項２に記載の車両用電子制御装置。
【請求項４】
前記調停部は、前記要求信号に含まれるデータ内容に基づいて、前記要求信号の送信元のクライアントと該要求信号の対象となるサーバとの通信と、該サーバと前記他のクライアントとの通信とのうち、いずれを優先させるかの調停を行う請求項２または請求項３に記載の車両用電子制御装置。
【請求項５】
前記クライアントは、それぞれ通信の優先順位が予め定められ、
前記調停部は、前記要求信号に含まれる前記優先順位に基づいて、前記要求信号の送信元のクライアントと前記要求信号の対象となるサーバとの通信と、該サーバと前記他のクライアントとの通信とのうち、いずれを優先させるかを決定する請求項２ないし請求項４のいずれか１項に記載の車両用電子制御装置。
【請求項６】
前記調停部は、前記要求信号の送信元のクライアントの前記優先順位が、前記他のクライアントの前記優先順位よりも低いとき、該クライアントに対し、前記サーバとの通信が可能になるまで待機する旨の応答、あるいは、該サーバとの通信を不許可とする旨の応答のいずれかを行う請求項２ないし請求項５のいずれか１項に記載の車両用電子制御装置。
【請求項７】
前記調停部は、前記要求信号の送信元のクライアントの前記優先順位が、前記他のクライアントの前記優先順位よりも高いとき、前記サーバと前記他のクライアントとの通信を中断あるいは中止させて、前記要求信号の送信元のクライアントと前記要求信号の対象となるサーバとの通信を許可する請求項２ないし請求項６のいずれか１項に記載の車両用電子制御装置。
【請求項８】
前記要求信号は、前記ネットワーク上に備えられる全ての前記サーバに対するもので、
前記調停部は、全ての前記サーバの通信状態に基づいて、該クライアントと該全てのサーバとの通信を許可するか否かを決定する請求項１ないし請求項７のいずれか１項に記載の車両用電子制御装置。
【請求項９】
前記調停部は、前記サーバあるいは前記クライアントのいずれか１つに備えられる請求項１ないし請求項８のいずれか１項に記載の車両用電子制御装置。
【請求項１０】
前記サーバあるいは前記クライアントを含む通信ネットワークは複数あり、その通信ネットワーク毎に前記調停部と接続する請求項１ないし請求項９のいずれか１項に記載の車両用電子制御装置。
【請求項１１】
前記調停部は、前記ネットワーク上に複数備えられる請求項１ないし請求項１０のいずれか１項に記載の車両用電子制御装置。
【請求項１】
予め定められた機能を実行する１以上のサーバと、
前記サーバとの通信の確立を要求するための要求信号を送信する１以上のクライアントと、
前記サーバと前記クライアントとの間に介在し、前記サーバと前記クライアントとの通信を調停する１つの調停部と、
が、ネットワーク上に配置され、
前記調停部は、
前記サーバの通信状態を取得する通信状態取得部を含み、
前記要求信号を受信したとき、該要求信号の対象となるサーバの通信状態に基づいて、該クライアントと該サーバとの通信の確立を許可するか否かを決定することを特徴とする車両用電子制御装置。
【請求項２】
前記調停部は、前記要求信号の対象となるサーバが他のクライアントと通信中のとき、前記要求信号の送信元のクライアントと前記他のクライアントの通信の優先順位に基づいて、前記要求信号の送信元のクライアントと該要求信号の対象となるサーバとの通信と、該サーバと前記他のクライアントとの通信とのうち、いずれを優先させるかの調停を行う請求項１に記載の車両用電子制御装置。
【請求項３】
前記要求信号は、複数の通信フレームにより構成され、
前記調停部と前記クライアントとの間の通信は１フレーム単位で行われ、
前記調停部は、前記要求信号の最初の通信フレームを受信したときに前記調停を行う請求項２に記載の車両用電子制御装置。
【請求項４】
前記調停部は、前記要求信号に含まれるデータ内容に基づいて、前記要求信号の送信元のクライアントと該要求信号の対象となるサーバとの通信と、該サーバと前記他のクライアントとの通信とのうち、いずれを優先させるかの調停を行う請求項２または請求項３に記載の車両用電子制御装置。
【請求項５】
前記クライアントは、それぞれ通信の優先順位が予め定められ、
前記調停部は、前記要求信号に含まれる前記優先順位に基づいて、前記要求信号の送信元のクライアントと前記要求信号の対象となるサーバとの通信と、該サーバと前記他のクライアントとの通信とのうち、いずれを優先させるかを決定する請求項２ないし請求項４のいずれか１項に記載の車両用電子制御装置。
【請求項６】
前記調停部は、前記要求信号の送信元のクライアントの前記優先順位が、前記他のクライアントの前記優先順位よりも低いとき、該クライアントに対し、前記サーバとの通信が可能になるまで待機する旨の応答、あるいは、該サーバとの通信を不許可とする旨の応答のいずれかを行う請求項２ないし請求項５のいずれか１項に記載の車両用電子制御装置。
【請求項７】
前記調停部は、前記要求信号の送信元のクライアントの前記優先順位が、前記他のクライアントの前記優先順位よりも高いとき、前記サーバと前記他のクライアントとの通信を中断あるいは中止させて、前記要求信号の送信元のクライアントと前記要求信号の対象となるサーバとの通信を許可する請求項２ないし請求項６のいずれか１項に記載の車両用電子制御装置。
【請求項８】
前記要求信号は、前記ネットワーク上に備えられる全ての前記サーバに対するもので、
前記調停部は、全ての前記サーバの通信状態に基づいて、該クライアントと該全てのサーバとの通信を許可するか否かを決定する請求項１ないし請求項７のいずれか１項に記載の車両用電子制御装置。
【請求項９】
前記調停部は、前記サーバあるいは前記クライアントのいずれか１つに備えられる請求項１ないし請求項８のいずれか１項に記載の車両用電子制御装置。
【請求項１０】
前記サーバあるいは前記クライアントを含む通信ネットワークは複数あり、その通信ネットワーク毎に前記調停部と接続する請求項１ないし請求項９のいずれか１項に記載の車両用電子制御装置。
【請求項１１】
前記調停部は、前記ネットワーク上に複数備えられる請求項１ないし請求項１０のいずれか１項に記載の車両用電子制御装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【公開番号】特開２０１３−７４３７７（Ｐ２０１３−７４３７７Ａ）
【公開日】平成２５年４月２２日（２０１３．４．２２）
【国際特許分類】
【出願番号】特願２０１１−２１０４９５（Ｐ２０１１−２１０４９５）
【出願日】平成２３年９月２７日（２０１１．９．２７）
【出願人】（０００００４２６０）株式会社デンソー (27,639)
【Ｆターム（参考）】
【公開日】平成２５年４月２２日（２０１３．４．２２）
【国際特許分類】
【出願日】平成２３年９月２７日（２０１１．９．２７）
【出願人】（０００００４２６０）株式会社デンソー (27,639)
【Ｆターム（参考）】
[ Back to top ]