(57)【要約】【課題】ＥＣＵ側で優先度を考慮した通信を行わなくても、優先度に従った順序で診断装置との通信を実行することが可能となる車載通信装置、及び車両用通信システムの提供。【解決手段】本発明でいう車載通信装置に相当する代理サーバは、ＥＣＵと車両の外部に設けられる診断装置（高優先ツール及び低優先ツール）との間に介在してデータ通信の中継を行う。高優先ツール及び低優先ツールそれぞれから送信されるＥＣＵ宛の要求を受信する際、代理サーバは、各要求の優先度を判定し、高優先度ツールから送信された高優先度要求であればＥＣＵへと転送する（Ｓ１６→Ｓ１７、又はＳ１９→Ｓ１８）。一方、低優先度ツールから送信された低優先度要求については、高優先度ツールからの要求及び高優先度ツールへの応答に関する処理が完了したことを転送条件として、この転送条件が成立するまで転送時期を遅延させる（Ｓ１７→Ｓ１８、又はＳ１６→Ｓ１９→Ｓ１８）。【選択図】図２
2012240493.tif 000002
【特許請求の範囲】
【請求項１】
車両に搭載された１又は２以上の制御装置に、車両内通信用の通信路を介して接続されることにより、前記制御装置とともに車載ネットワークを構成しており、しかも、前記車両の外部に設けられる複数の外部装置には、車両外通信用の通信路を介して接続可能に構成され、前記外部装置と接続された状態において前記外部装置から送信される前記制御装置宛の要求を受信した場合には、当該要求を前記制御装置へと転送可能で、当該転送した前記要求を受信した前記制御装置から送信される前記外部装置宛の応答を受信した場合には、当該応答を前記外部装置へと転送可能な車載通信装置であって、
複数の前記外部装置それぞれから送信される前記制御装置宛の要求を受信する際に、それら複数の要求それぞれについて優先度を判定する優先度判定手段と、
前記優先度判定手段によって優先度が判定された複数の要求のうち、少なくとも一つの要求が他の要求よりも優先度の高い高優先度要求であり、前記他の要求が前記高優先度要求よりも優先度の低い低優先度要求であると判定された場合に、前記高優先度要求については前記制御装置へと転送する一方、前記低優先度要求については前記制御装置への転送を行わないか所定の転送条件が成立するまで転送時期を遅延させる調停手段と
を備えることを特徴とする車載通信装置。
【請求項２】
前記調停手段は、前記低優先度要求については、当該低優先度要求の要求元に該当する外部装置に対して前記要求を受けられない旨を示す応答を送信して、前記低優先度要求を前記制御装置へ転送しない
ことを特徴とする請求項１に記載の車載通信装置。
【請求項３】
前記調停手段は、前記低優先度要求については、当該低優先度要求の要求元に該当する外部装置に対する応答を送信せず、前記低優先度要求を前記制御装置へ転送しない
ことを特徴とする請求項１に記載の車載通信装置。
【請求項４】
前記調停手段は、前記低優先度要求については、当該低優先度要求の要求元に該当する外部装置に対して前記要求の転送を保留中である旨を示す応答を送信して、前記高優先度要求に応じて前記制御装置から返される応答について、前記外部装置への転送を完了したことを前記転送条件として、前記低優先度要求については前記転送条件が成立するまで転送時期を遅延させる
ことを特徴とする請求項１に記載の車載通信装置。
【請求項５】
前記優先度判定手段は、複数の前記外部装置それぞれに対応付けて設定された優先度に基づいて、高い優先度が設定された前記外部装置からの要求を高優先度要求であると判定し、低い優先度が設定された前記外部装置からの要求を低優先度要求であると判定する
ことを特徴とする請求項１〜請求項４のいずれか一項に記載の車載通信装置。
【請求項６】
さらに、前記制御装置の状態が、所定のしきい値よりも高い負荷がかかっている高負荷状態にあるか、前記しきい値よりも低い負荷しかかかっていない低負荷状態にあるかを判定する負荷状態判定手段
を備え、
前記調停手段は、前記負荷状態判定手段によって前記低負荷状態にあると判定された場合に、前記外部装置からの要求を前記制御装置へと転送する一方、前記負荷状態判定手段によって前記高負荷状態にあると判定された場合には、前記外部装置からの要求を前記制御装置へ転送しないか前記制御装置の状態が前記低負荷状態になるまで転送時期を遅延させる
ことを特徴とする請求項１〜請求項５のいずれか一項に記載の車載通信装置。
【請求項７】
車両に搭載された１又は２以上の制御装置と、車両内通信用の通信路を介して接続されることにより、前記制御装置とともに車載ネットワークを構成する車載通信装置とを備えており、前記車両の外部に設けられる複数の外部装置には、前記車載通信装置経由で、車両外通信用の通信路を介して接続可能に構成され、前記外部装置と接続された状態において前記外部装置から送信される前記制御装置宛の要求を前記車載通信装置が受信した場合には、当該要求を前記車載通信装置が前記制御装置へと転送可能で、当該転送した前記要求を受信した前記制御装置から送信される前記外部装置宛の応答を前記車載通信装置が受信した場合には、当該応答を前記車載通信装置が前記外部装置へと転送可能な車両用通信システムであって、
前記車載通信装置は、
複数の前記外部装置それぞれから送信される前記制御装置宛の要求を受信する際に、それら複数の要求それぞれについて優先度を判定する優先度判定手段と、
前記優先度判定手段によって優先度が判定された複数の要求のうち、少なくとも一つの要求が他の要求よりも優先度の高い高優先度要求であり、前記他の要求が前記高優先度要求よりも優先度の低い低優先度要求であると判定された場合に、前記高優先度要求については前記制御装置へと転送する一方、前記低優先度要求については前記制御装置への転送を行わないか所定の転送条件が成立するまで転送時期を遅延させる調停手段と
を備えることを特徴とする車両用通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車両に搭載された制御装置と車両の外部に設けられる外部装置との間に介在して、それら制御装置と外部装置との間で行われるデータ通信の中継を行う車載通信装置と、その車載通信装置を備えた車両用通信システムに関する。
【背景技術】
【０００２】
従来、車両に搭載された電子制御装置（Electronic Control Unit；以下、ＥＣＵと称する。）の診断を行う際には、修理工場等に用意されている診断装置（以下、この診断装置を第一の診断装置ともいう。）が利用されている。この種の診断装置は、通常、修理工場等に入庫した車両のコネクタに有線接続され、これにより、診断装置が車載ネットワーク経由でＥＣＵと通信可能となり、修理担当者が診断装置を直接操作することで、ＥＣＵから各種情報を取得することができる。
【０００３】
また、車両に関する各種管理を行うセンターで作動する診断装置（以下、この診断装置を第二の診断装置ともいう。）を利用して、ＥＣＵの診断が行われることもある。この場合、診断装置は、無線通信網経由で車載ネットワークに接続して、ＥＣＵとの通信を行うことになる。
【０００４】
ところで、上述のような第一の診断装置でＥＣＵの診断を行っている際、並行して第二の診断装置との通信が発生すると、ＥＣＵから第一の診断装置への応答に遅れが生じることがある。この場合、第一の診断装置では、修理担当者が装置を直接操作してＥＣＵからの応答を見ているので、修理担当者が応答遅れに違和感を覚えるおそれがある、という問題がある。
【０００５】
このような問題に対し、第一の診断装置からの要求と第二の診断装置からの要求、それぞれに優先度を設定し、それら優先度の異なる要求が混在する場合には、高優先度の要求が優先的に処理されるように調停を行う技術は、すでに提案されている（例えば、特許文献１参照。）。
【０００６】
この特許文献１に記載の技術では、高優先度のダイアグ要求メッセージと低優先度のダイアグ要求メッセージを、同時に格納できるバッファを個々のＥＣＵごとに用意して、高優先度のダイアグ要求メッセージが優先的に処理される仕組みになっている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００８−２９０６６６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、上記従来技術では、以下に述べるような点において、いまだ改良の余地が残されていた。
まず、上記従来技術の場合、高優先度のダイアグ要求メッセージと低優先度のダイアグ要求メッセージを同時に格納できるバッファや、調停のためのロジックが、複数のＥＣＵそれぞれに実装されている。そのため、車両全体で見れば、相当な数のバッファやロジックが組み込まれていることになり、それらすべての開発作業には相当なコストがかかる、という問題があった。
【０００９】
また、上述のようなバッファやロジックを、複数のＥＣＵそれぞれに実装すると、各々のＥＣＵでＲＯＭやＲＡＭを消費することになるため、これもコスト増の要因となる、という問題があった。
【００１０】
さらに、上記従来技術の場合、第一、第二の診断装置が存在することを前提にして、優先度の設定、調停を行っているが、現時点では想定されていない第三、第四の診断装置等々への追加対応が必要となった場合には、それらに対応するために、すべてのＥＣＵを修正する必要があり、それに伴うコスト負担も大きくなりやすい、という問題もあった。
【００１１】
本発明は、上記問題を解決するためになされたものであり、その目的は、高優先度の要求が優先的に処理されるように調停を行う車両用通信システムを、従来よりも低コストで構成可能とすることにある。
【課題を解決するための手段】
【００１２】
以下、本発明において採用した構成について説明する。
本発明の車載通信装置は、車両に搭載された１又は２以上の制御装置に、車両内通信用の通信路を介して接続されて、制御装置とともに車載ネットワークを構成する。また、本発明の車載通信装置は、車両の外部に設けられる複数の外部装置に対しては、車両外通信用の通信路を介して接続可能に構成される。これにより、外部装置は、本発明の車載通信装置経由で車載ネットワークに接続でき、車両に搭載された制御装置と通信可能となる。
【００１３】
外部装置から車両外通信用の通信路経由で制御装置宛の要求が送信された場合、その要求は本発明の車載通信装置によって受信されて、車両内通信用の通信路経由で制御装置へと転送される。また、転送した要求を受信した制御装置から車両内通信用の通信路経由で外部装置宛の応答が送信された場合、その応答は本発明の車載通信装置によって受信されて、車両外通信用の通信路経由で外部装置へと転送される。
【００１４】
以上のような要求及び応答の送受信が行われる中、本発明の車載通信装置において、優先度判定手段は、複数の外部装置それぞれから送信される制御装置宛の要求を受信する際に、それら複数の要求それぞれについて優先度を判定する。
【００１５】
そして、優先度判定手段によって優先度が判定された複数の要求のうち、少なくとも一つの要求が他の要求よりも優先度の高い高優先度要求であると判定された場合、調停手段は、高優先度要求については制御装置へと転送する。一方、このような判定がされた場合、上記他の要求については、上述の高優先度要求よりも優先度の低い低優先度要求であると判定され、この低優先度要求については、制御装置への転送を行わないか、所定の転送条件が成立するまで転送時期を遅延させる。
【００１６】
つまり、複数の外部装置それぞれから送信される制御装置宛の要求の中に、優先度の高いもの及び低いものが混在していたとしても、本発明の車載通信装置から制御装置へは、優先度の高い要求が選択的に送信される。
【００１７】
したがって、本発明の車載通信装置を採用すれば、制御装置側では、本発明の車載通信装置経由で送信されてくる要求に対して単に応答を返すだけで、高優先度要求に対する応答を優先的に返すことができるようになる。よって、高優先度の要求が優先的に処理されるように調停を行う車両用通信システムを構成するに当たって、制御装置側の構成を従来よりも簡素化でき、車両用通信システム全体をより低コストで構成することができるようになる。
【００１８】
ところで、本発明の車載通信装置において、調停手段の具体的構成については、様々なものを考え得る。いくつかの具体例を挙げれば、例えば、調停手段は、低優先度要求について、低優先度要求の要求元に該当する外部装置に対し、要求を受けられない旨を示す応答を送信し、低優先度要求を制御装置へ転送しない、という構成を考え得る。
【００１９】
このような車載通信装置を採用すれば、制御装置側へは低優先度要求を転送しないので、制御装置には、低優先度要求に対処させるための処理負荷をかけずに済み、また、外部装置側へは、制御装置が要求を受けられない旨を伝達することができる。
【００２０】
あるいは、調停手段は、低優先度要求について、低優先度要求の要求元に該当する外部装置に対する応答を送信せず、低優先度要求を制御装置へ転送しない、という構成を考え得る。
【００２１】
このような車載通信装置を採用すれば、制御装置側へは低優先度要求を転送しないので、制御装置には、低優先度要求に対処させるための処理負荷をかけずに済む。また、外部装置側へ応答を返すことはできないが、その分、車載通信装置にかかる負荷を軽減することができる。
【００２２】
あるいは、調停手段は、低優先度要求について、低優先度要求の要求元に該当する外部装置に対して要求の転送を保留中である旨を示す応答を送信して、高優先度要求に応じて制御装置から返される応答について、外部装置への転送を完了したことを転送条件として、低優先度要求については転送条件が成立するまで転送時期を遅延させる、という構成を考え得る。
【００２３】
このような車載通信装置を採用すれば、高優先度要求に応じた応答が制御装置から返されるまでは、制御装置側へは低優先度要求を転送しないので、制御装置には、低優先度要求に対処させるための処理負荷をかけずに済み、また、外部装置側へは、制御装置への要求の転送を保留中である旨を伝達することができる。
【００２４】
また、本発明の車載通信装置において、優先度判定手段は、高優先度要求か低優先度要求かを、どのような基準に基づいて判断しても構わないが、一例としては、例えば、複数の外部装置それぞれに対応付けて設定された優先度に基づいて、高い優先度が設定された前記外部装置からの要求を高優先度要求であると判定し、低い優先度が設定された前記外部装置からの要求を低優先度要求であると判定する、といった構成を挙げることができる。
【００２５】
このような構成であれば、外部装置ごとに高優先度か低優先度かが設定される。したがって、例えば、要求ごとに高優先度要求か低優先度要求かが設定されるようなものとは異なり、要求元の外部装置を特定するだけで、高優先度要求か低優先度要求かを判断でき、煩雑な判断を行わなくても済む。
【００２６】
また、本発明の車載通信装置は、さらに、制御装置の状態が、所定のしきい値よりも高い負荷がかかっている高負荷状態にあるか、所定のしきい値よりも低い負荷しかかかっていない低負荷状態にあるかを判定する負荷状態判定手段を備えていてもよい。
【００２７】
この場合、調停手段は、負荷状態判定手段によって低負荷状態にあると判定された場合に、外部装置からの要求を制御装置へと転送する。一方、負荷状態判定手段によって高負荷状態にあると判定された場合には、外部装置からの要求を制御装置へ転送しないか制御装置の状態が低負荷状態になるまで転送時期を遅延させる。
【００２８】
したがって、制御装置の状態が高負荷状態であるにもかかわらず、外部装置からの要求が制御装置へ転送されてしまうことはなく、制御装置には要求に対処するための処理負荷がかからず、制御装置は、高負荷状態となっている原因に対応する処理に専念することができる。
【００２９】
加えて、本発明の車両用通信システムは、上述したとおりの車載通信装置を備えているので、車両用通信システムを構成する制御装置側では、特に優先度を考慮した処理を行わなくても、車載通信装置経由で送信されてくる要求に対して単に応答を返すだけで、高優先度要求に対する応答を優先的に返すことができるようになる。
【図面の簡単な説明】
【００３０】
【図１】本発明の車載通信装置の一例として示す代理サーバと他の装置によって構成されるネットワークシステムの構成図。
【図２】第一実施形態において例示する代理サーバが実行する処理の詳細を示す状態遷移図。
【図３】第一実施形態において例示する代理サーバが実行する処理による通信の一例を示すタイミングチャート。
【図４】第二実施形態において例示する代理サーバが実行する処理の詳細を示す状態遷移図。
【図５】第三実施形態において例示する代理サーバが実行する処理の詳細を示す状態遷移図。
【図６】第四実施形態において例示する代理サーバが実行する処理による通信の一例を示すタイミングチャート。
【発明を実施するための形態】
【００３１】
次に、本発明の実施形態について、いくつかの具体的な例を挙げて説明する。
〔１〕第一実施形態
［車両用通信システム全体の構成］
図１に示すように、本発明の車載通信装置の一例として示す代理サーバ１は、車両１０に搭載されている。また、この車両１０には、代理サーバ１の他に、複数のＥＣＵ＃１〜ＥＣＵ＃ｎ（本発明でいう制御装置の一例に相当。）、無線通信装置１２、コネクタ１３などが搭載され、これらが車両内通信用の通信路１１ａ，１１ｂを介して接続されることにより、車載ネットワークが構成されている。なお、これら代理サーバ１及び複数のＥＣＵ＃１〜ＥＣＵ＃ｎなどを備えてなる車載ネットワークシステムが、本発明でいう車両用通信システムの一例に相当する。
【００３２】
本実施形態において、車載ネットワークの通信プロトコルとしてはＣＡＮ（Controller Area Network）プロトコルが採用されており、上記車載ネットワーク上の各機器は、ＣＡＮに準拠した方式で相互に通信可能に構成されている。なお、ＣＡＮの規格そのものは周知なので、これ以上の説明については省略する。
【００３３】
代理サーバ１は、周知のＣＰＵ，ＲＯＭ，ＲＡＭなどを備えたマイクロコンピュータや、上記車載ネットワーク上の各機器との通信を行うため入出力インターフェース（例えば、ＣＡＮトランシーバ）などを備えてなる。
【００３４】
また、車両１０の外部には、診断装置２０，３０（本発明でいう外部装置の一例に相当。）が設けられている。これら診断装置２０，３０は、双方とも、ＥＣＵ＃１〜ＥＣＵ＃ｎの故障診断などを行うため、ＥＣＵ＃１〜ＥＣＵ＃ｎから各種情報を取得する装置である。
【００３５】
本実施形態において、診断装置２０は、修理工場等に設けられる装置であり、車両１０が修理工場等に入庫した際、車両１０が備えるコネクタ１３を利用して車両１０と有線通信路（本発明でいう車両外通信用の通信路の一例に相当。）を介して接続される。車両１０と診断装置２０が有線接続された場合、代理サーバ１はゲートウェイとして機能し、診断装置２０とＥＣＵ＃１〜ＥＣＵ＃ｎは、代理サーバ１経由で相互に通信可能となる。
【００３６】
一方、診断装置３０は、車両に関する各種管理を行うセンターで作動する装置である。この診断装置３０は、無線通信装置３２に接続されており、車両１０と診断装置３０は、無線通信装置１２及び無線通信装置３２を利用して無線通信網４０（本発明でいう車両外通信用の通信路の一例に相当。）経由で無線接続される。車両１０と診断装置３０が無線接続された場合も、代理サーバ１はゲートウェイとして機能し、診断装置３０とＥＣＵ＃１〜ＥＣＵ＃ｎは、代理サーバ１経由で相互に通信可能となる。
【００３７】
ところで、診断装置２０は、修理工場等において修理担当者によって直接操作され、修理担当者は、診断装置２０によって表示される情報を見て、ＥＣＵ＃１〜＃ｎの点検、故障診断などを行う。そのため、このような状況下では、ＥＣＵ＃１〜＃ｎが、診断装置２０への応答を保留したまま、診断装置３０との通信を行っていると、ＥＣＵ＃１〜ＥＣＵ＃ｎから診断装置２０への応答に遅れが生じ、その結果、修理担当者が応答遅れに違和感を覚えるおそれがある。
【００３８】
そこで、本実施形態では、後述する処理により、診断装置２０への応答が、診断装置３０への応答よりも優先的に返されるように、調停を行っている。以下、そのような調停の具体的手法について説明する。
【００３９】
［代理サーバが実行する処理］
次に、代理サーバ１が実行する処理について、図２を参照しつつ説明する。なお、以下の説明では、診断装置２０，３０の優先度の違いを簡明に説明する都合上、診断装置３０よりも応答を返す優先度が高くされる診断装置２０のことを「高優先ツール２０」と称することにする。また、診断装置２０よりも応答を返す優先度が低くされる診断装置３０のことを「低優先ツール３０」と称することにする。診断装置２０，３０双方を総称する場合には単に「ツール２０，３０」と称することにする。
【００４０】
図２に示す処理は、代理サーバ１の起動に伴って開始され、その後は、代理サーバ１が稼働状態にある限り、継続的に実行される処理である。この処理を開始すると、代理サーバ１は、まず、ツール２０，３０からの要求待ちになる（Ｓ１１）。
【００４１】
この状態において、低優先ツール３０から代理サーバ１へと伝送される要求の受信を、代理サーバ１が開始すると、代理サーバ１は、低優先ツール３０からの要求受信完了待ちになる（Ｓ１２）。
【００４２】
そして、代理サーバ１は、低優先ツール３０からの要求の受信を完了したら、低優先ツール３０からの要求をＥＣＵ＃ｉ（ｉは１〜ｎのいずれか；以下同様。）へと送信して、送信先となったＥＣＵ＃ｉから低優先ツール３０への応答待ちになる（Ｓ１３）。
【００４３】
この状態において、ＥＣＵ＃ｉから低優先ツール３０へと伝送される応答の受信を、代理サーバ１が完了すると、代理サーバ１は、ＥＣＵ＃ｉからの応答を低優先ツール３０へと送信して、先に説明したＳ１１へと戻る。
【００４４】
一方、Ｓ１１において、高優先ツール２０から代理サーバ１へと伝送される要求の受信を、代理サーバ１が開始すると、代理サーバ１は、高優先ツール２０からの要求受信完了待ちになる（Ｓ１４）。
【００４５】
そして、代理サーバ１は、高優先ツール２０からの要求の受信を完了したら、高優先ツール２０からの要求をＥＣＵ＃ｉへと送信して、送信先となったＥＣＵ＃ｉから高優先ツール２０への応答待ちになる（Ｓ１５）。
【００４６】
この状態において、ＥＣＵ＃ｉから高優先ツール２０へと伝送される応答の受信を、代理サーバ１が完了すると、代理サーバ１は、ＥＣＵ＃ｉからの応答を高優先ツール２０へと送信して、先に説明したＳ１１へと戻る。
【００４７】
以上説明したようなＳ１１→Ｓ１２→Ｓ１３→Ｓ１１、あるいはＳ１１→Ｓ１４→Ｓ１５→Ｓ１１、といった状態遷移を伴う処理が、高優先ツール２０又は低優先ツール３０のいずれかから単独で要求が到来した場合に実行される処理である。
【００４８】
一方、上述したＳ１２においては、低優先ツール３０からの要求の受信を完了する前に、高優先ツール２０からの要求の受信を開始することがある。また、上述したＳ１４においては、高優先ツール２０からの要求の受信を完了する前に、低優先ツール３０からの要求の受信を開始することがある。これらの場合、代理サーバ１は、低優先ツール３０からの要求の受信、及び高優先ツール２０からの要求の受信、双方の受信の完了待ちになる（Ｓ１６）。
【００４９】
このＳ１６において、高優先ツール２０からの要求の受信を先に完了した場合、代理サーバ１は、高優先ツール２０からの要求をＥＣＵ＃ｉへと送信して、送信先となったＥＣＵ＃ｉから高優先ツール２０への応答待ちになり、また、Ｓ１６から継続して低優先ツール３０からの要求受信完了待ち状態も維持する（Ｓ１７）。
【００５０】
Ｓ１７では、ＥＣＵ＃ｉから高優先ツール２０への応答の受信を先に完了した場合、代理サーバ１は、ＥＣＵ＃ｉからの応答を高優先ツール２０へと送信し、先に説明したＳ１２へと戻る。
【００５１】
一方、Ｓ１７において、低優先ツール３０からの要求の受信を先に完了した場合、代理サーバ１は、低優先ツール３０へ否定応答（実行保留中）を送信して、低優先ツール３０からの要求を保留し、ＥＣＵ＃ｉから高優先ツール２０への応答待ちになる（Ｓ１８）。すなわち、Ｓ１８では、代理サーバ１は、低優先ツール３０からの要求を保留中とすることで、ＥＣＵ＃ｉから高優先ツール２０への応答の受信を完了させる上で必要となる処理を優先的に実行する状態になる。
【００５２】
そして、Ｓ１８において、ＥＣＵ＃ｉから高優先ツール２０への応答の受信を完了したら、ＥＣＵ＃ｉからの応答を高優先ツール２０へ送信し、さらにＳ１８では保留していた低優先ツール３０からの要求をＥＣＵ＃ｉへ送信して、Ｓ１３へと進む。なお、Ｓ１３以降の状態遷移についてはすでに説明したので、ここでの説明は省略する。
【００５３】
一方、Ｓ１６では、低優先ツール３０からの要求の受信を先に完了することもあり、この場合、代理サーバ１は、低優先ツール３０へ否定応答（実行保留中）を送信して、低優先ツール３０からの要求を保留し、高優先ツール２０からの要求受信完了待ちになる（Ｓ１９）。すなわち、Ｓ１９では、代理サーバ１は、低優先ツール３０からの要求を保留中とすることで、高優先ツール２０からの要求の受信を完了させる上で必要となる処理を優先的に実行する状態になる。
【００５４】
そして、Ｓ１９において、高優先ツール２０からの要求の受信を完了したら、高優先ツール２０からの要求をＥＣＵ＃ｉへ送信し、Ｓ１８へと進む。すなわち、この時点でも、さらに継続して低優先ツール３０からの要求を保留中とすることで、ＥＣＵ＃ｉから高優先ツール２０への応答の受信を完了させる上で必要となる処理を優先的に実行する状態になる。なお、Ｓ１８以降の状態遷移についてはすでに説明したので、ここでの説明は省略する。
【００５５】
以上のような処理を実行する代理サーバ１に対し、例えば、図３に示すような順序で要求が伝送された場合、代理サーバ１は、以下の括弧内に併記するような状態遷移を伴って各要求及び応答に対処することとなる。
【００５６】
すなわち、まず、低優先ツール３０から代理サーバ１へ要求が送信された場合、代理サーバ１は低優先度要求の受信を開始する（図２：Ｓ１１→Ｓ１２）。また、引き続いて高優先ツール２０から代理サーバ１へ要求が送信された場合、代理サーバ１は高優先度要求の受信も開始する（図２：Ｓ１２→Ｓ１６）。
【００５７】
その後、高優先ツール２０からの要求の受信を完了すると、代理サーバ１は、高優先ツール２０からの要求をＥＣＵ＃１へと送信して、ＥＣＵ＃１から高優先ツール２０への応答待ちになり、また、低優先ツール３０からの要求受信完了待ち状態も維持する（図２：Ｓ１６→Ｓ１７）。
【００５８】
続いて、低優先ツール３０からの要求の受信を完了した場合、代理サーバ１は、低優先ツール３０へ否定応答（実行保留中）を送信して、低優先ツール３０からの要求を保留し、ＥＣＵ＃１から高優先ツール２０への応答待ちになる（図２：Ｓ１７→Ｓ１８）。すなわち、代理サーバ１は、低優先ツール３０からの要求を保留し、ＥＣＵ＃１から高優先ツール２０への応答受信を優先させる。
【００５９】
そして、ＥＣＵ＃１から高優先ツール２０への応答の受信を完了したら、代理サーバ１は、ＥＣＵ＃１からの肯定応答を高優先ツール２０へ送信し、さらに保留していた低優先ツール３０からの要求をＥＣＵ＃１へ送信して、ＥＣＵ＃１から低優先ツール３０への応答待ちになる（図２：Ｓ１８→Ｓ１３）。
【００６０】
その後、ＥＣＵ＃１から低優先ツール３０への応答の受信を完了したら、代理サーバ１は、ＥＣＵ＃１からの肯定応答を低優先ツール３０へと送信して、ツール２０，３０からの要求待ち状態に戻る（図２：Ｓ１３→Ｓ１１）。
【００６１】
［第一実施形態の効果］
以上説明したとおり、上記代理サーバ１によれば、高優先ツール２０及び低優先ツール３０の双方に対応した処理が必要な状況となった場合には（Ｓ１６，Ｓ１７）、要求元が高優先ツール２０又は低優先ツール３０のいずれであるかに基づいて、各要求の優先度を判定する（この判定処理を行う代理サーバ１が本発明でいう優先度判定手段の一例に相当。）。そして、低優先ツール３０からの要求については一時的に保留し、高優先ツール２０に対応するための処理を優先的に実行する（Ｓ１８，Ｓ１９；このような調停処理を行う代理サーバ１が本発明でいう調停手段の一例に相当。）。
【００６２】
そのため、高優先ツール２０及び低優先ツール３０それぞれから送信されるＥＣＵ＃１〜＃ｎ宛の要求の中に、高優先ツール２０から伝送された優先度の高い要求、及び低優先ツール３０から伝送された優先度の低い要求が混在する状況になった場合でも、代理サーバ１からＥＣＵ＃１〜＃ｎへは、優先度の高い要求が選択的に送信される。
【００６３】
したがって、ＥＣＵ＃１〜＃ｎ側では、ツール２０，３０の優先度を考慮した処理を行わなくても、代理サーバ１から送信されてくる要求に対して単に応答を返すだけで、高優先度要求に対する応答を優先的に返すことができる。
【００６４】
また、上記代理サーバ１によれば、Ｓ１６→Ｓ１７→Ｓ１８、あるいはＳ１６→Ｓ１９→Ｓ１８、といった状態遷移を伴う処理の際、低優先度要求の要求元である低優先ツール３０に対して要求を保留中である旨の応答を送信し、低優先度要求については、高優先ツール２０への応答送信完了という転送条件が成立して、Ｓ１８→Ｓ１３→Ｓ１３と状態遷移するまでは、転送時期を遅延させる。
【００６５】
したがって、低優先ツール３０へは要求を保留中である旨を示す応答が送信されるので、低優先ツール３０側では、保留が解除されるまで待機するなどの対処が可能となる。また、高優先ツール２０からの高優先度要求に応じた応答がＥＣＵ＃１〜＃ｎから返されるまでは、ＥＣＵ＃１〜＃ｎへは低優先ツール３０からの低優先度要求が送信されないので、ＥＣＵ＃１〜＃ｎには、低優先度要求に対処するための処理負荷がかからず、ＥＣＵ＃１〜＃ｎは、高優先度要求に対応する処理に専念することができる。
【００６６】
さらに、上記代理サーバ１によれば、高優先ツール２０からの要求はすべて高優先度要求、低優先ツール３０からの要求はすべて低優先度要求と設定されているので、単一の診断装置であっても要求ごとに高優先度要求か低優先度要求かが設定されるようなものとは異なり、要求元が高優先ツール２０及び低優先ツール３０のいずれであるのかを特定するだけで、高優先度要求か低優先度要求かを判断でき、煩雑な判断を行わなくても済む。
【００６７】
加えて、上記代理サーバ１を採用すれば、優先度を考慮した通信を行うためのバッファやロジックをＥＣＵ＃１〜＃ｎ側に実装しなくても済むので、これらのバッファやロジックを個々のＥＣＵ＃１〜＃ｎごとに開発していた従来技術に比べ、その開発作業に要するコストを低減することができる。また、上記代理サーバ１を採用することにより、上述のようなバッファやロジックをＥＣＵ＃１〜＃ｎ側に実装しなくても済めば、その分だけＥＣＵ＃１〜＃ｎ側のＲＯＭやＲＡＭの消費を抑えることができるので、この点でもコストの低減を図ることができる。さらに、上記代理サーバ１を採用すれば、現時点では想定されていない診断装置等への追加対応が将来的に必要となった場合には、車両に搭載されたＥＣＵ＃１〜＃ｎすべての修正を行わなくても、上記代理サーバ１を修正するだけで対処することが可能となるので、そのような修正に伴うコスト負担も低減することができる。よって、上記代理サーバ１を採用すれば、高優先度の要求が優先的に処理されるように調停を行う車両用通信システムを、従来よりも低コストで構成することができる。
【００６８】
〔２〕第二実施形態
次に、第二実施形態について説明する。なお、第二実施形態以降の実施形態は、代理サーバ１が実行する処理の内容が、第一実施形態と相違するものの、システム全体を構成するハードウェアには相違点がないので、以下の説明では、相違点を中心に詳述し、すでに説明した共通部分に関しては、その詳細な説明を省略する。
【００６９】
［代理サーバが実行する処理］
第二実施形態として示す代理サーバ１が実行する処理について、図４を参照しつつ説明する。図４に示す処理も、第一実施形態同様、代理サーバ１の起動に伴って開始され、その後は、代理サーバ１が稼働状態にある限り、継続的に実行される処理である。
【００７０】
この処理のうち、Ｓ２１〜Ｓ２６までの状態遷移は、第一実施形態のＳ１１〜Ｓ１６までの状態遷移と同等なので、ここでの説明は省略する。
一方、Ｓ２７へ遷移した状態において、低優先ツール３０からの要求の受信を先に完了した場合は、第一実施形態とは異なる挙動を示す。具体的には、代理サーバ１は、低優先ツール３０へ否定応答（実行不可）を送信して、ＥＣＵ＃ｉから高優先ツール２０への応答待ちになる（Ｓ２５）。すなわち、第一実施形態では、代理サーバ１は、低優先ツール３０からの要求を保留していたが、第二実施形態では、低優先ツール３０からの要求を保留することなく拒否することで、ＥＣＵ＃ｉから高優先ツール２０への応答の受信を完了させる上で必要となる処理を優先的に実行する状態になる。
【００７１】
また、Ｓ２６へ遷移した状態において、低優先ツール３０からの要求の受信を先に完了した場合も、第一実施形態とは異なる挙動を示す。具体的には、代理サーバ１は、低優先ツール３０へ否定応答（実行不可）を送信して、高優先ツール２０からの要求受信完了待ちになる（Ｓ２４）。すなわち、ここでも、代理サーバ１は、低優先ツール３０からの要求を保留することなく拒否することで、高優先ツール２０からの要求の受信を完了させる上で必要となる処理を優先的に実行する状態になる。
【００７２】
［第二実施形態の効果］
このように構成された第二実施形態の代理サーバ１でも、高優先ツール２０及び低優先ツール３０の双方に対応した処理が必要な状況となった場合には（Ｓ２６，Ｓ２７）、両者の優先度を判定して、低優先ツール３０からの要求については拒否し、高優先ツール２０に対応するための処理を優先的に実行する（Ｓ２４，Ｓ２５）。
【００７３】
そのため、高優先ツール２０及び低優先ツール３０それぞれから送信されるＥＣＵ＃１〜＃ｎ宛の要求の中に、高優先ツール２０から伝送された優先度の高い要求、及び低優先ツール３０から伝送された優先度の低い要求が混在する状況になった場合でも、代理サーバ１からＥＣＵ＃１〜＃ｎへは、優先度の高い要求が選択的に送信される。
【００７４】
したがって、ＥＣＵ＃１〜＃ｎ側では、ツール２０，３０の優先度を考慮した処理を行わなくても、代理サーバ１から送信されてくる要求に対して単に応答を返すだけで、高優先度要求に対する応答を優先的に返すことができる。
【００７５】
また、上記代理サーバ１によれば、Ｓ２６→Ｓ２７→Ｓ２５、あるいはＳ２６→Ｓ２４、といった状態遷移を伴う処理の際、低優先度要求の要求元である低優先ツール３０に対して要求を拒否する（実行不可である）旨の応答を送信し、低優先度要求については、ＥＣＵ＃１〜＃ｎへの転送を見合わせる。
【００７６】
したがって、低優先ツール３０へは要求を拒否する旨を示す応答が送信されるので、低優先ツール３０側では、しばらく待機してから再び要求を送信したり、要求をあきらめたりするなどの対処が可能となる。また、ＥＣＵ＃１〜＃ｎへは低優先ツール３０からの低優先度要求が送信されないので、ＥＣＵ＃１〜＃ｎには、低優先度要求に対処するための処理負荷がかからず、ＥＣＵ＃１〜＃ｎは、高優先度要求に対応する処理に専念することができる。
【００７７】
〔３〕第三実施形態
次に、第三実施形態について説明する。
［代理サーバが実行する処理］
第三実施形態として示す代理サーバ１が実行する処理について、図５を参照しつつ説明する。図５に示す処理も、第一、第二実施形態同様、代理サーバ１の起動に伴って開始され、その後は、代理サーバ１が稼働状態にある限り、継続的に実行される処理である。
【００７８】
この処理のうち、Ｓ３１〜Ｓ３６までの状態遷移は、第一実施形態のＳ１１〜Ｓ１６までの状態遷移と同等なので、ここでの説明は省略する。
一方、Ｓ３７へ遷移した状態において、低優先ツール３０からの要求の受信を先に完了した場合は、第一実施形態とは異なる挙動を示す。具体的には、代理サーバ１は、低優先ツール３０へ応答を送信することなく、ＥＣＵ＃ｉから高優先ツール２０への応答待ちになる（Ｓ３５）。すなわち、第一実施形態では、代理サーバ１は、低優先ツール３０からの要求を保留していたが、第二実施形態では、低優先ツール３０からの要求を保留することなく無視することで、ＥＣＵ＃ｉから高優先ツール２０への応答の受信を完了させる上で必要となる処理を優先的に実行する状態になる。なお、代理サーバ１は、低優先ツール３０の要求を無視するものの、低優先ツール３０との通信シーケンスの進行状況については把握（管理）しており、これにより、要求と応答に不整合が生じることは回避している。
【００７９】
また、Ｓ３６へ遷移した状態において、低優先ツール３０からの要求の受信を先に完了した場合も、第一実施形態とは異なる挙動を示す。具体的には、代理サーバ１は、低優先ツール３０へ応答を送信することなく、高優先ツール２０からの要求受信完了待ちになる（Ｓ３４）。すなわち、ここでも、代理サーバ１は、低優先ツール３０からの要求を保留することなく無視することで、高優先ツール２０からの要求の受信を完了させる上で必要となる処理を優先的に実行する状態になる。なお、この場合も、代理サーバ１は、低優先ツール３０との通信シーケンスの進行状況については把握（管理）している。
【００８０】
［第三実施形態の効果］
このように構成された第二実施形態の代理サーバ１でも、高優先ツール２０及び低優先ツール３０の双方に対応した処理が必要な状況となった場合には（Ｓ３６，Ｓ３７）、両者の優先度を判定して、低優先ツール３０からの要求については無視し、高優先ツール２０に対応するための処理を優先的に実行する（Ｓ３４，Ｓ３５）。
【００８１】
そのため、高優先ツール２０及び低優先ツール３０それぞれから送信されるＥＣＵ＃１〜＃ｎ宛の要求の中に、高優先ツール２０から伝送された優先度の高い要求、及び低優先ツール３０から伝送された優先度の低い要求が混在する状況になった場合でも、代理サーバ１からＥＣＵ＃１〜＃ｎへは、優先度の高い要求が選択的に送信される。
【００８２】
したがって、ＥＣＵ＃１〜＃ｎ側では、ツール２０，３０の優先度を考慮した処理を行わなくても、代理サーバ１から送信されてくる要求に対して単に応答を返すだけで、高優先度要求に対する応答を優先的に返すことができる。
【００８３】
また、上記代理サーバ１によれば、Ｓ３６→Ｓ３７→Ｓ３５、あるいはＳ３６→Ｓ３４、といった状態遷移を伴う処理の際、低優先度要求の要求元である低優先ツール３０からの要求については無視し、低優先度要求については、ＥＣＵ＃１〜＃ｎへの転送を見合わせる。
【００８４】
したがって、低優先ツール３０へは応答が送信されないが、低優先ツール３０側では、所定の待機時間が経過してタイムアウトとなった時点で、再び要求を送信したり、要求をあきらめたりするなどの対処が可能である。また、ＥＣＵ＃１〜＃ｎへは低優先ツール３０からの低優先度要求が送信されないので、ＥＣＵ＃１〜＃ｎには、低優先度要求に対処するための処理負荷がかからず、ＥＣＵ＃１〜＃ｎは、高優先度要求に対応する処理に専念することができる。
【００８５】
〔４〕第四実施形態
次に、第四実施形態について説明する。
［代理サーバが実行する処理］
第四実施形態として示す代理サーバ１は、高優先ツール２０及び低優先ツール３０の双方に対応した処理が必要な状況となった場合に、両者の優先度を判定し、低優先ツール３０からの要求については一時的に保留し、高優先ツール２０に対応するための処理を優先的に実行する。この処理は、第一実施形態と同様である。
【００８６】
ただし、第四実施形態では、さらに代理サーバ１が、ＥＣＵ＃１〜＃ｎにかかっている負荷も考慮して、高優先ツール２０からの要求であっても、その要求を一時的に保留する点で、第一実施形態とは相違する。
【００８７】
より具体的には、代理サーバ１では、第一実施形態と同様の処理を実行する中、第一実施形態ではＥＣＵ＃ｉに対して要求を送信する条件が成立するケースであっても、さらに、ＥＣＵ＃ｉから通知された負荷状態を判定する。その判定の結果、高負荷状態にあるＥＣＵ＃ｉに対しては、代理サーバ１は、高優先ツール２０からの要求であっても、低負荷状態となるまでは、要求を一時的に保留する。保留した要求については、その後、低負荷状態となったら、ＥＣＵ＃ｉに対して送信する。
【００８８】
ＥＣＵ＃１〜＃ｎそれぞれの負荷状態が低負荷か高負荷かは、ＥＣＵ＃１〜＃ｎそれぞれが、自身の機能や役割等に応じて設定された所定のしきい値に基づいて自ら判定し、負荷状態がしきい値を超えるほど大幅に変動した際に、代理サーバ１に対して通知する。
【００８９】
以上のような処理を実行する代理サーバ１に対し、例えば、図６に示すような順序で要求が伝送された場合、代理サーバ１は、以下のような手順で各要求及び応答に対処することとなる。
【００９０】
すなわち、まず、ＥＣＵ＃１からは、自身の負荷状態が小さい旨を示す負荷通知が、代理サーバ１に対して送信される。また、ＥＣＵ＃２からは、自身の負荷状態が大きい旨を示す負荷通知が、代理サーバ１に対して送信される。ＥＣＵ＃３以降のも同様の負荷通知を送信するが、すべてを示しても煩雑になるので、本実施形態での例示は省略する。
【００９１】
このような状況下で、高優先ツール２０からＥＣＵ＃１への要求が、代理サーバ１へ送信された場合、代理サーバ１は、ＥＣＵ＃１の負荷状態が負荷小であると判断して、高優先ツール２０からの要求をＥＣＵ＃１へと送信する。そして、ＥＣＵ＃１から高優先ツール２０への応答待ちになり、ＥＣＵ＃１から高優先ツール２０への応答の受信を完了したら、代理サーバ１は、ＥＣＵ＃１からの肯定応答を高優先ツール２０へ送信する。
【００９２】
続いて、高優先ツール２０からＥＣＵ＃２への要求が、代理サーバ１へ送信された場合、代理サーバ１は、ＥＣＵ＃２の負荷状態が負荷大であると判断して、高優先ツール２０へ否定応答（実行保留中）を送信して、高優先ツール２０からの要求を保留する。すなわち、代理サーバ１は、第一実施形態とは異なり、高優先ツール２０からの要求であっても保留中とすることで、ＥＣＵ＃２に対してさらに過大な負荷がかかるのを回避する。
【００９３】
その後、ＥＣＵ＃２の負荷状態が低負荷状態になった場合、ＥＣＵ＃２からは、自身の負荷状態が小さい旨を示す負荷通知が、代理サーバ１に対して送信される。この負荷通知を受けた代理サーバ１は、保留していた高優先ツール２０からの要求をＥＣＵ＃２へ送信して、ＥＣＵ＃２から高優先ツール２０への応答待ちになる。そして、ＥＣＵ＃２から高優先ツール２０への応答の受信を完了したら、代理サーバ１は、ＥＣＵ＃２からの肯定応答を高優先ツール２０へ送信する。
【００９４】
［第四実施形態の効果］
以上説明したとおり、上記代理サーバ１によれば、第一実施形態と同様の処理により、高優先ツール２０及び低優先ツール３０の双方に対応した処理が必要な状況となった場合には、両者の優先度を判定して、低優先ツール３０からの要求については一時的に保留し、高優先ツール２０に対応するための処理を優先的に実行する。
【００９５】
しかも、第一実施形態とは異なり、代理サーバ１は、ＥＣＵ＃１〜＃ｎにかかっている負荷が大きいか小さいかを判定する（この判定処理を行う代理サーバ１が本発明でいう負荷状態判定手段の一例に相当。）。そして、ＥＣＵ＃１〜＃ｎにかかっている負荷が大きい場合には、高優先ツール２０からの要求であっても、その要求を一時的に保留し、負荷の大きいＥＣＵ＃ｉに対し、さらに負荷をかけてしまうのを回避する。
【００９６】
したがって、ＥＣＵ＃１〜＃ｎ側では、ツール２０，３０の優先度を考慮した処理を行わなくても、代理サーバ１から送信されてくる要求に対して単に応答を返すだけで、高優先度要求に対する応答を優先的に返すことができ、且つ、負荷の大きいＥＣＵ＃ｉにおいてさらに負荷が増大するのを抑制することができる。
【００９７】
〔５〕その他の実施形態
以上、本発明の実施形態について説明したが、本発明は上記の具体的な一実施形態に限定されず、この他にも種々の形態で実施することができる。
【００９８】
例えば、上記第四実施形態では、第一実施形態と同様の処理に加え、ＥＣＵ＃１〜＃ｎにかかっている負荷も考慮して、ＥＣＵ＃１〜＃ｎに要求を送信するか保留するかを判断していたが、このようなＥＣＵ＃１〜＃ｎにかかっている負荷を考慮した処理は、第一実施形態と同様の処理と組み合わせる他、第二実施形態や第三実施形態と組み合わせてもよい。
【００９９】
すなわち、第二実施形態のように、高優先ツール２０及び低優先ツール３０の双方に対応した処理が必要な状況となった場合に、低優先ツール３０からの要求については拒否する構成となっているシステムにおいて、ＥＣＵ＃１〜＃ｎにかかっている負荷を考慮し、負荷が大きい場合には、高優先ツール２０からの要求であっても、その要求を拒否する構成としてもよい。
【０１００】
また、第三実施形態のように、高優先ツール２０及び低優先ツール３０の双方に対応した処理が必要な状況となった場合に、低優先ツール３０からの要求については無視する構成となっているシステムにおいて、ＥＣＵ＃１〜＃ｎにかかっている負荷を考慮し、負荷が大きい場合には、高優先ツール２０からの要求であっても、その要求を無視する構成としてもよい。
【０１０１】
さらに、上述の事例は、上記のような低優先度の要求、及び高負荷状態にあるＥＣＵ＃ｉへの要求、これら双方の要求について、双方とも保留する、双方とも拒否する、双方とも無視する、といった事例となるが、一方を保留して他方を拒否する、あるいは、一方を拒否して他方を無視するなど、これらは異なる対処法を任意に組み合わせて採用することも可能である。
【０１０２】
なお、以上の他、高優先度の要求か低優先度の要求かについては判断することなく、単に高負荷状態にあるＥＣＵ＃ｉへの要求か否かだけを判断して、負荷が大きい場合には、その要求を一時的に保留（又は拒否、あるいは無視）する、という構成を採用しても、負荷の大きいＥＣＵ＃ｉに対し、さらに負荷をかけてしまうのを回避することはできるので、これだけでも実用上は十分に有益である。
【符号の説明】
【０１０３】
１・・・代理サーバ、１０・・・車両、１１ａ，１１ｂ・・・通信路、１２・・・無線通信装置、１３・・・コネクタ、２０・・・診断装置（高優先ツール）、３０・・・診断装置（低優先ツール）、３２・・・無線通信装置。
【図１】
2012240493.tif 000003
【図２】
2012240493.tif 000004
【図３】
2012240493.tif 000005
【図４】
2012240493.tif 000006
【図５】
2012240493.tif 000007
【図６】
2012240493.tif 000008