WO2016072085A1

WO2016072085A1 - 通信システム、１台以上のサーバ、および１台以上のサーバ用のプログラム

Info

Publication number: WO2016072085A1
Application number: PCT/JP2015/005505
Authority: WO
Inventors: 一好西堀
Original assignee: Denso Corp
Current assignee: Denso Corp
Priority date: 2014-11-06
Filing date: 2015-11-02
Publication date: 2016-05-12
Anticipated expiration: 2017-05-06

Abstract

　車載装置と共に車両に搭載され、車載装置を診断するために必要な検査データを取得して送信する制御装置と、車両外に設置され、制御装置が送信した検査データを受信し、受信した検査データを用いて、車両に搭載されるアクチュエータを制御することで車載装置の診断を行う１台以上のサーバと、を備え、当該１台以上のサーバは、制御装置と当該１台以上のサーバとの間の通信に要する時間が所定の基準を超えているか否かを冷媒不足判定の途中の状態（ＳＢ）で判定し、所定の基準を超えていると判定されたことに基づいて、その状態（ＳＢ）から冷媒不足判定が未実施または中止または取り消された状態（ＳＡ）に遷移することで、車載装置の診断を中止する。

Description

通信システム、１台以上のサーバ、および１台以上のサーバ用のプログラム

関連出願の相互参照

　本出願は、２０１４年１１月６日に出願された日本特許出願番号２０１４－２２６０１３号と、２０１５年９月７日に出願された日本出願番号２０１５－１７５８７５号に基づくもので、ここにその記載内容を援用する。

　本開示は、通信システム、１台以上のサーバ、および１台以上のサーバ用のプログラムに関するものである。

　従来、車両用空調装置において冷媒量が不足していることを検出する技術が知られている。例えば、特許文献１に開示された技術では、車両用空調装置を制御する制御装置が、当該空調装置のコンプレッサを制御することで、当該車両用空調装置の冷媒不足を判定する。

ＪＰ　２００９－２４３７８４　Ａ

　発明者の検討によれば、冷媒不足を判定するためのソフトウエアは、コンプレッサという車載のアクチュエータを制御する処理を記述するので、車載のアクチュエータを制御しない診断ソフトウエアに比べれば、データサイズが大きくなりがちである。したがって、特許文献１のように、冷媒不足を判定するためのソフトウエアを制御装置に追加しようとすると、制御装置のメモリ容量が比較的大きく増加してしまい、制御装置の小型化およびコストダウンの妨げになる。

　そこで、発明者は、車両と車外のサーバ（またはサーバ群）との通信が容易になっていることに着目し、車外のサーバ（またはサーバ群）に車両用空調装置の冷媒不足判定を行わせる新技術を着想した。そして、この新技術について更に検討し、車外のサーバ（またはサーバ群）で有効に冷媒不足判定を行うには、リアルタイム性の判定が必要であると考えた。リアルタイム性の判定が必要であるのは、冷媒不足の判定に限らず、車載のアクチュエータを制御することで車載装置を診断する技術全般に当てはまることである。

　リアルタイム性とは、ある時点における車両側の作動状態を示す量が、サーバ（またはサーバ群）に通信で送信され、サーバ（またはサーバ群）での冷媒検査の処理を経て車両内の制御として反映される作動が、予定された時刻までに定期的に行われるという性質をいう。

　車両とサーバ（またはサーバ群）との間の通信による遅延が小さければリアルタイム性は良好である。しかし、当該遅延が大きければ、決められた時刻までの制御の反映は困難になる。即ち、リアルタイム性は不良となり、適切な診断（例えば冷媒不足判定）が行えない可能性が高くなる。ここで上記遅延は、車両側とサーバ側でデータを処理する時間と、通信に関係する時間の総和である。

　本開示は、車外の１台以上のサーバに車載装置の診断（例えば車両用空調装置の冷媒不足判定）を行わせる技術に、リアルタイム性の判定を追加することを目的とする。

　上記目的を達成するための本開示の一つの例によれば、通信システムは、車載装置と共に車両に搭載され、車載装置を診断するために必要な検査データを取得して送信する制御装置と、車両外に設置され、制御装置が送信した検査データを受信し、受信した検査データを用いて、車両に搭載されるアクチュエータを制御することで車載装置の診断を行う１台以上のサーバと、を備えるように提供される。制御装置または１台以上のサーバは、制御装置と１台以上のサーバとの間の通信に要する時間が所定の基準を超えているか否かを判定し、１台以上のサーバは、通信に要する時間が所定の基準を超えていると判定されたことに基づいて、診断を中止する。

　また、本開示の一つの例によれば、一台以上のサーバは、車載装置と共に車両に搭載されて車載装置を診断するために必要な検査データを取得して送信する制御装置と通信し、車両外に設置されるように提供される。更に、サーバは、制御装置が送信した検査データを受信し、受信した検査データを用いて、車両に搭載されるアクチュエータを制御することで車載装置の診断を行う検査部と、制御装置と１台以上のサーバとの間の通信に要する時間が所定の基準を超えているか否かを判定する判定部と、を備える。検査部は、通信に要する時間が所定の基準を超えていると判定部が判定したことに基づいて、診断を中止する。

　また、本開示の一つの例によれば、プログラムは、車載装置と共に車両に搭載されて車載装置を診断するために必要な検査データを取得して送信する制御装置と通信し、車両外に設置される１台以上のサーバ用として提供される。更に、プログラムは、１台以上のサーバを、制御装置が送信した検査データを受信し、受信した検査データを用いて、車両に搭載されるアクチュエータを制御することで車載装置の診断を行う検査部、および制御装置と１台以上のサーバとの間の通信に要する時間が所定の基準を超えているか否かを判定する判定部として機能させる。検査部は、通信に要する時間が所定の基準を超えていると判定部が判定したことに基づいて、診断を中止する。

　このように、制御装置と１台以上のサーバとの間の通信の遅延が所定の基準を超えて大きいときに、車載装置の診断が中止されるという形で、リアルタイム性の判定が実現されている。これにより、リアルタイム性が不良で適切な診断が行えない可能性が高い場合にまで、診断を続けることの無駄を低減できる。

　本開示についての上記目的およびその他の目的、特徴や利点は、添付の図面を参照しながら下記の詳細な記述により、より明確になる。
本開示の第１実施形態に係る通信システムの全体構成図クラウド対応空調パネルの構成図データブロックのデータ構成を示す図空調パネル制御装置が実行する処理の構成図マニュアル状態遷移処理の内容を示す図出力調停処理の内容を示す図冷媒不足判定と冷媒不足表示器の表示内容との対応関係を示す図クラウドおよび複数の車の構成図通信システムの作動例を示す通信シーケンス図空調パネル制御装置が実行するカウント返送処理のフローチャート車両からワーカまでのデータの流れを示す図ワーカから車両までのデータの流れを示す図冷媒検査プログラムの処理内容を示す状態遷移図外気温度と検査圧力との関係を示すグラフ第２判定中＿停車時状態におけるクラウド発オン要求、クラウド発オフ要求の値の制御内容を示すグラフカウントプログラムのフローチャートリアルタイム性判定プログラムのフローチャート車載システムおよびクラウドの機能構成を示す図本開示の第２実施形態に係る通信システムの全体構成図車両側とクラウドのデータのやり取り形態を示す図データブロックの構成を示す図ＥＶ＿ＥＣＵが実行する処理のフローチャートクラウドおよび複数の車の構成図車両からワーカまでのデータの流れを示す図ワーカから車両までのデータの流れを示す図診断プログラムの処理内容を示す状態遷移図診断時における圧力センサ値の変化等を示すグラフカウントプログラムのフローチャートリアルタイム性判定処理のフローチャートリアルタイム性判定プログラムの状態遷移図

　（第１実施形態）
　以下、第１実施形態について説明する。図１に示すように、本実施形態の通信システムは、車両に搭載された車載システム１００、および、車両外の遠隔地に設置されて車載システム１００と通信するクラウド２００（１台以上のサーバの一例に相当する）を備えている。

　車載システム１００は、エンジン１、コンプレッサ２、コンデンサー３、膨張弁４、エバポレータ５、Ａ／Ｃマグネットクラッチ６、水温センサ７、冷媒圧力センサ８、エバポレータフィン温度センサ９、車速センサ１０、空調電子制御ユニット（Ａ／Ｃ＿ＥＣＵ）１１、クラウド対応空調パネル１２、無線変換器１３を含んでいる。

　エンジン１は、車載システム１００の搭載先の車両を走行させる駆動力を発生する周知の機関である。コンプレッサ２、コンデンサー３、膨張弁４、エバポレータ５は、車室内へ送風される送風空気の温度を調整するための周知の冷凍サイクルを構成する。また、コンプレッサ２、コンデンサー３、膨張弁４、エバポレータ５、Ａ／Ｃマグネットクラッチ６、冷媒圧力センサ８、エバポレータフィン温度センサ９、Ａ／Ｃ＿ＥＣＵ１１が、周知の車両用空調装置（車載装置の一例に相当する）を構成する。

　コンプレッサ２は、冷媒を吸入し圧縮して吐出するアクチュエータで、Ａ／Ｃマグネットクラッチ６を介してエンジン１から動力を得て作動する。Ａ／Ｃマグネットクラッチ６によるエンジン１からコンプレッサ２への動力の伝達は、Ａ／Ｃ＿ＥＣＵ１７からＡ／Ｃマグネットクラッチ６に出力されるコンプレッサ駆動要求ＣＭＰによって制御される。

　コンプレッサ２の吐出側には、冷媒を凝縮させるコンデンサー３の冷媒入口側が接続されている。コンデンサー３の冷媒出口側には、冷媒を減圧膨張させる膨張弁４の冷媒入口側が接続されている。

　膨張弁４の冷媒出口側には、エバポレータ５の冷媒入口側が接続されている。エバポレータ５は、室内空調ユニットのケーシング内に配置されて、エバポレータ５の内部を流通する冷媒とケーシング内を通過して送風空気とを熱交換させて送風空気を冷却する。冷却された送風空気は、車室内に流入する。エバポレータ５の冷媒出口側には、コンプレッサ２の冷媒吸入側が接続されている。

　水温センサ７は、エンジン１の冷却水の温度ＴＨＷを検出するセンサである。冷媒圧力センサ８は、コンプレッサ２の冷媒吐出側とコンデンサー３の冷媒入口側の間の冷媒の圧力ＰＲＥを検出するセンサである。エバポレータフィン温度センサ９は、エバポレータ５の外表面（フィン）の温度ＴＥｆｉｎを検出するセンサである。車速センサ１０は、車載システム１００の搭載先の車両の走行速度ＳＰＤを検出するセンサである。

　Ａ／Ｃ＿ＥＣＵ１１は、車両のイグニッション状態ＩＧを取得し、また、上記センサ７～１０から検出信号（ＴＨＷ、ＰＲＥ、ＴＥｆｉｎ、ＳＰＤ）を取得し、またクラウド対応空調パネル１２から後述するデータブロックＸを取得する。そしてＡ／Ｃ＿ＥＣＵ１１は、これら取得した信号およびデータに基づいて、クラウド対応空調パネル１２と通信を行い、コンプレッサ駆動要求ＣＭＰのオン、オフ等を制御する。Ａ／Ｃ＿ＥＣＵ１１は、その他にも、上記冷凍サイクルを利用して車室内の温度等を調整する周知の空調制御を行う。Ａ／Ｃ＿ＥＣＵ１１は、例えば、ＣＰＵと、ＲＯＭ、ＲＡＭ等のメモリと、入出力部等を持つ周知のマイクロコンピュータで実現可能である。

　クラウド対応空調パネル１２は、車両のダッシュボード中央の車室側表面部に配置されており、車両の乗員が操作可能な複数のスイッチ１２１、１２２および車両の乗員が視認可能なインジケータ１２３、１２４を含んでいる。

　図２に示すように、クラウド対応空調パネル１２は、上述のＡ／Ｃスイッチ１２１、ＯＦＦスイッチ１２２、Ａ／Ｃ表示器１２３、冷媒不足表示器１２４に加え、空調パネル制御装置１２５を有している。

　Ａ／Ｃスイッチ１２１およびＯＦＦスイッチ１２２は、車両の乗員によって押下される部材であり、空調パネル制御装置１２５はスイッチ１２１、１２２各々に対する押下の有無を検出することができる。

　Ａ／Ｃ表示器１２３は、コンプレッサ２が作動していることを乗員に通知するためのＬＥＤであり、空調パネル制御装置１２５の制御に従って点灯、消灯が切り替わる。冷媒不足表示器１２４は、車両用空調装置の冷凍サイクルの冷媒が不足していることを乗員に通知するためのＬＥＤであり、空調パネル制御装置１２５の制御に従って点灯、消灯が切り替わる。

　空調パネル制御装置１２５は、表示器１２３、１２４の点灯、消灯等を制御するコンピュータである。空調パネル制御装置１２５は、車内ＬＡＮ１５（例えばＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ　Ａｒｅａ　Ｎｅｔｗｏｒｋ，登録商標））を介してＡ／Ｃ＿ＥＣＵ１１からデータブロックＷを受信すると共にデータブロックＸをＡ／Ｃ＿ＥＣＵ１１に送信する。また空調パネル制御装置１２５は、通信処理１２５ｄを実行することで、車内通信線１６（例えばシリアル通信線）を介して無線変換器１３からデータブロックＺを受信すると共にデータブロックＹを無線変換器１３に送信する。

　図３に示す通り、データブロックＷは、イグニッション状態ＩＧ、車速ＳＰＤ、冷却水温度ＴＨＷ、エバポレータフィン温度ＴＥｆｉｎ、冷媒圧力ＰＲＥを含んでいる。これらデータは、車両用空調装置の冷媒不足を判定するために必要な冷媒検査データを構成する。Ａ／Ｃ＿ＥＣＵ１１は、繰り返し定期的に（具体的には１秒周期で）、イグニッション状態ＩＧ、車速ＳＰＤ、冷却水温度ＴＨＷ、エバポレータフィン温度ＴＥｆｉｎ、冷媒圧力ＰＲＥの最新値を含むデータブロックＷを、車内通信線１６を介して空調パネル制御装置１２５に送信する。

　データブロックＸは、コンプレッサ駆動要求ＣＭＰを含んでいる。空調パネル制御装置１２５は、繰り返し、定期的に（例えば１秒毎に）、最新のコンプレッサ駆動要求ＣＭＰを含むデータブロックＸを、Ａ／Ｃ＿ＥＣＵ１１に送信する。そしてＡ／Ｃ＿ＥＣＵ１１は、受信したコンプレッサ駆動要求ＣＭＰをＡ／Ｃマグネットクラッチ６に出力することで、コンプレッサ２の作動、非作動を制御する。

　データブロックＹは、上述のデータＩＧ、ＳＰＤ、ＴＨＷ、ＴＥｆｉｎ、ＰＲＥに加え、ＯＦＦスイッチ１２２の押下の有無を示すデータＯＦＦ、マニュアルオン要求ＭＯＮ、マニュアルオフ要求ＭＯＦＦ、および、後述する車側カウント値（車側リアルタイム性確認カウント値）を含む。これらは、車両用空調装置の冷媒不足を判定するために必要な冷媒検査データを構成する。空調パネル制御装置１２５は、繰り返し定期的に（具体的には１秒周期で）、上記データＩＧ、ＳＰＤ、ＴＨＷ、ＴＥｆｉｎ、ＰＲＥ、データＯＦＦ、車側カウント値の最新値を含むデータブロックＹを、車内通信線１６を介して無線変換器１３に送信する。また、マニュアルオン要求ＭＯＮおよびマニュアルオフ要求ＭＯＦＦは、特定の条件が満たされたときにのみ空調パネル制御装置１２５によってデータブロックＹに含まれて送信される所謂イベントデータである。

　なお、本実施形態において、イベントデータであると明示するデータ以外は、所謂レベルデータである。レベルデータは毎周期送信されるのに対し、イベントデータは特定の条件が満たされたときにのみ送信される。

　無線変換器１３は、空調パネル制御装置１２５から受信した上記データブロックＹに自機のアドレス（例えばＭＡＣアドレス）を付加し（図３参照）、自機のアドレスが付加されたデータブロックＹの情報を含む無線信号を、周知の無線通信方式（例えば無線ＬＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標））により、モデム１４に送信する。

　モデム１４は、例えば携帯電話機等の装置であり、車両の乗員に携帯されて車室内に持ち込まれ、無線変換器１３および車外に設置されたサーバ群であるクラウド２００と通信可能になる装置である。モデム１４は、無線変換器１３から受信した上記データブロックＹを、クラウド２００に送信する。モデム１４とクラウド２００は、例えばインターネット等の広域ネットワークを介して通信する。

　またモデム１４は、クラウド２００から繰り返しデータブロックＺを受信する。データブロックＺは、図３に示す通り、冷媒不足判定、クラウド発オン要求、クラウド発オフ要求、クラウド側カウント値という４つのデータを含んでいる。クラウド発オン要求（リモート要求の一例に相当する）は、冷媒不足判定のためにクラウド２００側からコンプレッサ２の作動開始が要求されたことを示すイベントデータである。クラウド発オフ要求（リモート要求の一例に相当する）は、冷媒不足判定のためにクラウド２００側からコンプレッサ２の作動停止が要求されたことを示すイベントデータである。クラウド側カウント値については後述する。

　クラウド２００は、繰り返し、定期的に具体的には１秒周期で、最新の冷媒不足判定、クラウド側カウント値を含むデータブロックＺを、モデム１４に送信する。また、イベントデータであるクラウド発オン要求およびクラウド発オフ要求については、特定の条件が満たされた場合にのみ、上記データブロックＺに含める。モデム１４は、受信したデータブロックＺを無線変換器１３に送信し、無線変換器１３は受信したデータブロックＺを空調パネル制御装置１２５に送信する。

　ここで、空調パネル制御装置１２５の作動について、図４～図７を参照して説明する。図２、４に示すように、空調パネル制御装置１２５は、マニュアル状態遷移処理１２５ａと出力調停処理１２５ｂ、カウント返送処理１２５ｃ、通信処理１２５ｄを同時並行的に実行するようになっている。

　マニュアル状態遷移処理１２５ａは、図３に示すように、出力調停処理１２５ｂから出力されるＡ／Ｃ表示器１２３の点灯時、消灯時の各々においてＡ／Ｃスイッチ１２１が押下された場合の、マニュアルオン要求ＭＯＮおよびマニュアルオフ要求ＭＯＦＦの生成の有無を決定する処理である。マニュアルオン要求ＭＯＮは、乗員が手動でコンプレッサの作動開始を要求したことを示すイベントデータであり、マニュアルオフ要求ＭＯＦＦは、乗員が手動でコンプレッサの作動停止を要求したことを示すイベントデータである。

　具体的には、空調パネル制御装置１２５は、マニュアル状態遷移処理１２５ａにおいて、Ａ／Ｃ表示器１２３が消灯しているときにＡ／Ｃスイッチ１２１が押下された場合にはマニュアルオン要求ＭＯＮを生成する。また、Ａ／Ｃ表示器１２３が点灯しているときにＡ／Ｃスイッチ１２１が押下された場合にはマニュアルオフ要求ＭＯＦＦを生成する。生成されたマニュアルオン要求ＭＯＮまたはマニュアルオフ要求ＭＯＦＦは、生成される度に、マニュアル状態遷移処理１２５ａから出力調停処理１２５ｂに一度だけ渡されると共に、次に送信されるデータブロックＹに含まれる。

　出力調停処理１２５ｂは、Ａ／Ｃ表示器１２３を点灯させるか否か、コンプレッサ駆動要求ＣＭＰを含むデータブロックＸをＡ／Ｃ＿ＥＣＵ１１に出力するか否かを決定する処理である。

　決定は、マニュアルオン要求ＭＯＮ、マニュアルオフ要求ＭＯＦＦの有無に基づいて行われる。また、決定は、最新のデータブロックＺ中のクラウド発オン要求、クラウド発オフ要求の有無に基づいて行われる。クラウド発オン要求およびクラウド発オフ要求もイベントデータである。

　出力調停処理１２５ｂにおける空調パネル制御装置１２５の作動は、具体的には図６の通りである。例えば、Ａ／Ｃ表示器１２３を消灯させており、かつ、最後にＡ／Ｃ＿ＥＣＵ１１に送信したコンプレッサ駆動要求ＣＭＰの値がオフであった場合について説明する。この場合に、マニュアル状態遷移処理１２５ａからマニュアルオン要求ＭＯＮが渡されると、Ａ／Ｃ表示器１２３を点灯すると共に、オンの値のコンプレッサ駆動要求ＣＭＰを含むデータブロックＸをＡ／Ｃ＿ＥＣＵ１１に出力する。

　また例えば、Ａ／Ｃ表示器１２３を点灯させており、かつ、最後にＡ／Ｃ＿ＥＣＵ１１に送信したコンプレッサ駆動要求ＣＭＰの値がオンであった場合について説明する。この場合に、マニュアル状態遷移処理１２５ａからマニュアルオフ要求ＭＯＦＦが渡されると、Ａ／Ｃ表示器１２３を消灯すると共に、オフの値のコンプレッサ駆動要求ＣＭＰを含むデータブロックＸをＡ／Ｃ＿ＥＣＵ１１に出力する。

　また例えば、Ａ／Ｃ表示器１２３を消灯させており、かつ、最後にＡ／Ｃ＿ＥＣＵ１１に送信したコンプレッサ駆動要求ＣＭＰの値がオンであった場合について説明する。この場合に、マニュアル状態遷移処理１２５ａからマニュアルオン要求ＭＯＮが渡されると、Ａ／Ｃ表示器１２３を点灯させると共に、オンの値のコンプレッサ駆動要求ＣＭＰを含むデータブロックＸをＡ／Ｃ＿ＥＣＵ１１に出力する。

　また例えば、Ａ／Ｃ表示器１２３を点灯させており、かつ、最後にＡ／Ｃ＿ＥＣＵ１１に送信したコンプレッサ駆動要求ＣＭＰの値がオフであった場合について説明する。この場合に、マニュアル状態遷移処理１２５ａからマニュアルオン要求ＭＯＮが渡されると、Ａ／Ｃ表示器１２３を消灯させると共に、オンの値のコンプレッサ駆動要求ＣＭＰを含むデータブロックＸをＡ／Ｃ＿ＥＣＵ１１に出力する。

　また例えば、Ａ／Ｃ表示器１２３を消灯させており、かつ、最後にＡ／Ｃ＿ＥＣＵ１１に送信したコンプレッサ駆動要求ＣＭＰの値がオフであった場合について説明する。この場合に、新たに受信したデータブロックＺにクラウド発オン要求が含まれていると、Ａ／Ｃ表示器１２３を消灯のままにすると共に、オンの値のコンプレッサ駆動要求ＣＭＰを含むデータブロックＸをＡ／Ｃ＿ＥＣＵ１１に出力する。これにより、Ａ／Ｃ＿ＥＣＵ１１は直ちにオンの値のコンプレッサ駆動要求ＣＭＰをＡ／Ｃマグネットクラッチ６に出力するので、コンプレッサ２が冷媒不足判定のための作動を開始する。このときにＡ／Ｃ表示器１２３を消灯のままにするのは、冷媒不足判定のために一時的にコンプレッサ２を作動させるのを乗員に知らせる必要は必ずしも無いという観点からである。

　また例えば、Ａ／Ｃ表示器１２３を点灯させており、かつ、最後にＡ／Ｃ＿ＥＣＵ１１に送信したコンプレッサ駆動要求ＣＭＰの値がオンであった場合について説明する。この場合に、新たに受信したデータブロックＺにクラウド発オフ要求が含まれていると、Ａ／Ｃ表示器１２３を点灯のままにすると共に、オフの値のコンプレッサ駆動要求ＣＭＰを含むデータブロックＸをＡ／Ｃ＿ＥＣＵ１１に出力する。これにより、Ａ／Ｃ＿ＥＣＵ１１は直ちにオフの値のコンプレッサ駆動要求ＣＭＰをＡ／Ｃマグネットクラッチ６に出力するので、コンプレッサ２による冷媒不足判定のための作動が停止する。このときにＡ／Ｃ表示器１２３を点灯のままにするのは、冷媒不足判定のために一時的にコンプレッサ２を停止させるのを乗員に知らせる必要は必ずしも無いという観点からである。

　また例えば、Ａ／Ｃ表示器１２３を消灯させており、かつ、最後にＡ／Ｃ＿ＥＣＵ１１に送信したコンプレッサ駆動要求ＣＭＰの値がオンであった場合、すなわち、冷媒不足判定のために一時的にコンプレッサ２が作動している場合について説明する。この場合に、新たに受信したデータブロックＺにクラウド発オン要求が含まれていると、Ａ／Ｃ表示器１２３を消灯のままにすると共に、オンの値のコンプレッサ駆動要求ＣＭＰを含むデータブロックＸをＡ／Ｃ＿ＥＣＵ１１に出力する。これにより、Ａ／Ｃ＿ＥＣＵ１１は直ちにオンの値のコンプレッサ駆動要求ＣＭＰをＡ／Ｃマグネットクラッチ６に出力するので、コンプレッサ２による冷媒不足判定のための作動が継続する。

　また例えば、Ａ／Ｃ表示器１２３を点灯させており、かつ、最後にＡ／Ｃ＿ＥＣＵ１１に送信したコンプレッサ駆動要求ＣＭＰの値がオフであった場合、すなわち、冷媒不足判定のために一時的にコンプレッサ２が停止している場合について説明する。この場合に、新たに受信したデータブロックＺにクラウド発オフ要求が含まれていると、Ａ／Ｃ表示器１２３を点灯のままにすると共に、オフの値のコンプレッサ駆動要求ＣＭＰを含むデータブロックＸをＡ／Ｃ＿ＥＣＵ１１に出力する。これにより、Ａ／Ｃ＿ＥＣＵ１１は直ちにオフの値のコンプレッサ駆動要求ＣＭＰをＡ／Ｃマグネットクラッチ６に出力するので、コンプレッサ２の停止が継続する。

　また、空調パネル制御装置１２５は、出力調停処理１２５ｂにおいて更に、図７に示すように、冷媒不足表示器１２４の点灯、消灯を、データブロックＺに含まれる最新の冷媒不足判定に基づいて制御する。具体的には、最新の冷媒不足判定の値が「未判定」なら、冷媒不足表示器１２４を継続的に点灯状態に維持し、値が「冷媒不足無し」なら、冷媒不足表示器１２４を消灯させ、値が「冷媒不足有り」なら、冷媒不足表示器１２４を点滅させる。

　次に、クラウド２００の構成について説明する。クラウド２００は、図８に示すように、マスタサーバ２１とスレーブサーバ群２２を含んでいる。スレーブサーバ群２２は、複数のジョブスケジューラ２２１、２２２、２２３を含んでいる。スレーブサーバ群２２は更に、ジョブスケジューラ２２１によって管理される複数のワーカ２２１ｐ、２２１ｑ、ジョブスケジューラ２２２によって管理される複数のワーカ２２２ｐ、２２２ｑ、および、ジョブスケジューラ２２３によって管理される複数のワーカ２２３ｐ、２２３ｑを有している。

　また、図１に示した車載システム１００およびモデム１４は、複数の車両Ａ、Ｂ、Ｃの各々に搭載され、それぞれの車載システム１００のクラウド対応空調パネル１２が、同じ車両に搭載された無線変換器１３、モデム１４を介して、マスタサーバ２１と通信する。

　これらサーバ２１、２２１、２２２、２２３、２２１ｐ、２２１ｑ、２２２ｐ、２２２ｑ、２２３ｐ、２２３ｑは、それぞれ、互いに通信可能な別個のパーソナルコンピュータ（またはワークステーション）として実現されていてもよい。あるいは、これらサーバのうち一部の複数個は同じ１つのパーソナルコンピュータ（またはワークステーション）において実現されていてもよい。これらサーバを実現する複数個のパーソナルコンピュータ（またはワークステーション）のハードウェア構成については周知であるから、ここでは説明を省略する。

　マスタサーバ２１は、演算指示処理２１ａを実行するようになっていると共に、図示しない記憶媒体を有し、当該記憶媒体に冷媒検査プログラム２１ｂ、カウントプログラム２１ｃ、リアルタイム性判定プログラム２１ｄが記録されている。

　図９に、図８に示した構成の通信システムにおけるデータのやりとりの手順を例示する。この図を参照して、通信システム全体の作動について説明する。なお、以下に説明するマスタサーバ２１の作動は、すべて、マスタサーバ２１が演算指示処理２１ａを実行することによって実現する作動である。

　まず、車両Ａにおいて車両のイグニッション（または車両の主電源）がオンになると、Ａ／Ｃ＿ＥＣＵ１１は、イグニッション状態ＩＧのデータをオフからオンに更新する。その後、最初に訪れるデータブロックＷの送信タイミングにおいて、Ａ／Ｃ＿ＥＣＵ１１は、イグニッション状態ＩＧ、車速ＳＰＤ、冷却水温度ＴＨＷ、エバポレータフィン温度ＴＥｆｉｎ、冷媒圧力ＰＲＥの最新値を含むデータブロックＷを、車内通信線１６を介して空調パネル制御装置１２５に送信する（通信３０１）。

　空調パネル制御装置１２５は、このデータブロックＷを受信した後に最初に訪れるデータブロックＹの送信タイミングにおいて、当該データブロックＷに含まれるデータＩＧ、ＳＰＤ、ＴＨＷ、ＴＥｆｉｎ、ＰＲＥを、送信用のデータブロックＹに含める。

　また空調パネル制御装置１２５は、マニュアルオン要求ＭＯＮまたはマニュアルオフ要求ＭＯＦＦが生成されていれば、それも今回の送信用のデータブロックＹに含める。しかし、車両のイグニッションがオンになってからマスタサーバ２１から制御準備完了の通知を受信していないので、そのことに基づき、今回のデータブロックＹには、データＯＦＦ、車側カウント値を含めない。そして空調パネル制御装置１２５は、このデータブロックＹを、無線変換器１３、モデム１４を介してマスタサーバ２１に送信する（通信３０３）。この際、無線変換器１３が、データブロックＹに対して自機のアドレスを付加する。なお図９では、このデータブロックＹが車両Ａからのものであることを明示するため、Ｙａと記している。

　このデータブロックＹａを受信したマスタサーバ２１は、受信したデータブロックＹａに含まれるデータＩＧの値がオンであり、かつ、当該データブロックＹａに含まれるアドレスから前回送信されたデータブロックＹに含まれるデータＩＧの値がオフであったことに基づいて、複数のジョブスケジューラから１つのジョブスケジューラ２２１を車両Ａ用として選択し、選択した車両Ａ用のジョブスケジューラ２２１に対し、冷媒検査プログラム２１ｂ、カウントプログラム２１ｃ、リアルタイム性判定プログラム２１ｄを送信する（通信３０５）。

　ジョブスケジューラ２２１は、これらプログラム２１ｂ、２１ｃ、２１ｄを受信すると、制御準備完了の通知を、マスタサーバ２１に送信する（通信３０７）。マスタサーバ２１は、この制御準備完了の通知を、上記アドレス（車両Ａの無線変換器１３のアドレス）に送信する（通信３０９）。車両ＡのＡ／Ｃ＿ＥＣＵ１１は、モデム１４、無線変換器１３を介してこの制御準備完了の通知を受信する。この通知を受信した空調パネル制御装置１２５は、図１０に示すカウント返送処理１２５ｃのフローチャートの実行を開始する。これによって、車両Ａの車両用空調装置の冷凍サイクルにおける冷媒不足判定の準備が完了する。

　記載されるフローチャートは、複数のセクション（あるいはステップと言及される）を含み、各セクションは、たとえば、Ｓ１１０と表現される。さらに、各セクションは、複数のサブセクションに分割されることができる、一方、複数のセクションが合わさって一つのセクションとして機能することも可能であり、フローチャート全体を一つのセクションとして機能させることも可能である。各セクションは、デバイス、モジュールとして言及されることができる。また、セクションは、(i)ハードウエアユニット（例えば、コンピュータ）と組み合わさったソフトウエアのセクションのみならず、(ii)ハードウエア（例えば、集積回路、配線論理回路）のセクションとして、関連する装置の機能を含みあるいは含まずに実現できる。さらに、ハードウエアのセクションは、マイクロコンピュータの内部に含まれることもできる。

　その後は、車両ＡのＡ／Ｃ＿ＥＣＵ１１が、次に訪れる定期的なデータブロックＷの送信タイミングにおいて、データＩＧ、ＳＰＤ、ＴＨＷ、ＴＥｆｉｎ、ＰＲＥの最新値を含むデータブロックＷを車両Ａの空調パネル制御装置１２５に送信する（通信３１１）。

　すると当該空調パネル制御装置１２５は、このデータブロックＷを受信し、その後に最初に訪れるデータブロックＹの送信タイミングにおいて、当該データブロックＷに含まれるデータＩＧ、ＳＰＤ、ＴＨＷ、ＴＥｆｉｎ、ＰＲＥを、送信用のデータブロックＹに含める。

　また空調パネル制御装置１２５は、前回のデータブロックＹを送信して以降にマニュアルオン要求ＭＯＮまたはマニュアルオフ要求ＭＯＦＦが生成されていれば、それも今回の送信用のデータブロックＹに含める。

　また空調パネル制御装置１２５は、制御準備完了の通知を既に受けていることに基づいて、ＯＦＦスイッチ１２２の押下の有無を示すデータＯＦＦをデータブロックＹに含める。また空調パネル制御装置１２５は、図１０の処理において、Ｓ１１０で、クラウド側カウント値を新たに受信していないと判定することで、Ｓ１２０を実行せずＳ１１０を繰り返す。したがって、車側カウント値はデータブロックＹに含まれない。

　空調パネル制御装置１２５は、このようなデータブロックＹ（図９ではＹａと記す）を、無線変換器１３、モデム１４を介してマスタサーバ２１に送信する（通信３１３）。この際、無線変換器１３が、データブロックＹに対して自機のアドレスを付加する。

　なお、ＩＧが既にオンとなっている車両Ｂ、Ｃにおいても、マスタサーバ２１に対して同様の構成のデータブロックＹ（図９中ではＹｂ、Ｙｃと記す）をマスタサーバ２１に送信する（通信３１５、３１７）ただし、データブロックＹｂ、Ｙｃには、車側カウント値が含まれている場合もある。なお、図示していないが、マスタサーバ２１は、複数のジョブスケジューラからョブスケジューラ２２２、２２３をそれぞれ車両Ｂ用、車両Ｃ用として選択し、選択したジョブスケジューラ２２２、２２３に対し、冷媒検査プログラム２１ｂ、カウントプログラム２１ｃ、リアルタイム性判定プログラム２１ｄを送信している。

　上記のデータブロックＹａを受信したマスタサーバ２１は、データブロックＹａを含むジョブ要求通信をジョブスケジューラ２２１に送信する（通信３１９）。このジョブ要求通信を受信したジョブスケジューラ２２１は、このジョブ要求通信に含まれるデータブロックＹａの内容と、プログラム２１ｂ、２１ｃ、２１ｄの処理内容に基づいて、プログラム２１ｂ、２１ｃ、２１ｄが規定する処理を、自機が管理する複数のワーカ２２１ｐ、２２１ｑに分散して実行させる。このため、ジョブスケジューラ２２１は、自機が管理する複数のワーカ２２１ｐ、２２１ｑの各々に対して、必要な演算要求Ｙａｐ、Ｙａｑを送信する（通信３２１）。この演算要求Ｙａｐ、Ｙａｑには、ワーカ２２１ｐ、２２１ｑの各々で行うべき処理の内容およびその処理に必要なデータ（最新のデータブロックＹａの内容等）が含まれている。

　このように、車両Ａに関して行うべきプログラム２１ｂ、２１ｃ、２１ｄの処理が、ジョブスケジューラ２２１によって適宜複数のワーカ２２１ｐ、２２１ｑに分散して割り当てられるので、個々のワーカの処理負荷が軽減される。このような分散処理の技術は周知であるが、例えば、マイクロソフト（登録商標）社のＷｉｎｄｏｗｓ＿ＨＰＣ＿Ｓｅｒｖｅｒ（Ｗｉｎｄｏｗｓは登録商標）の技術を用いてもよいし、あるいは、Ｍａｔｈｗｏｒｋｓ（登録商標）社のＰａｒａｌｌｅｌ　Ｃｏｍｐｕｔｉｎｇ　Ｔｏｏｌｂｏｘの技術を用いてもよい。

　図１１に、上記のような車両Ａからワーカ２２１ｐ、２２１ｑまでのデータの流れを示す。車両Ｂおよびクラウド２００については、車両Ａおよびクラウド２００と同様の作動で、マスタサーバ２１、ジョブスケジューラ２２２、ワーカ２２２ｐ、ワーカ２２２ｑと通信を行う。車両Ｃおよびクラウド２００についても、車両Ａおよびクラウド２００と同様の作動で、マスタサーバ２１、ジョブスケジューラ２２３、ワーカ２２３ｐ、ワーカ２２３ｑと通信を行う。

　また、ワーカ２２１ｐ、２２１ｑは、それぞれ、ジョブスケジューラ２２１からの演算要求Ｙａｐ、Ｙａｑに従った作動を行い、その作動の結果得た、演算結果Ｚａｐ、Ｚａｑをジョブスケジューラ２２１に送信する（通信３２３）。冷媒不足判定、クラウド発オン要求、クラウド発オフ要求、クラウド側カウント値は、演算結果Ｚａｐ、Ｚａｑのいずれかに含まれている。その他にも、リアルタイム性の値（ＮＧ、ＯＫ）、および演算時に使用する各種変数が、演算結果Ｚａｐ、Ｚａｑに含まれている。

　演算結果Ｚａｐ、Ｚａｑを受信したジョブスケジューラ２２１は、直ちに（すなわち、１秒よりも十分短い遅延で）、これら演算結果を、自機が管理する複数のワーカ２２１ｐ、２２１ｑの各々に送信する。このようにすることで、同じジョブスケジューラ２２１に管理される複数のワーカ２２１ｐ、２２１ｑ間で、各種データの値が整合する。

　また、ジョブスケジューラ２２１は、受信済みの最新の演算結果Ｚａｐ、Ｚａｑから冷媒不足判定、（あれば）クラウド発オン要求、（あれば）クラウド発オフ要求、クラウド側カウント値を抽出してデータブロックＺ（図９中ではＺａと記載）を生成し、このデータブロックＺａを含むジョブ結果通信を、繰り返し定期的に（具体的には１秒周期で）マスタサーバ２１に送信する（通信３２５）。

　このジョブ結果通信を受信したマスタサーバ２１は、直ちに当該ジョブ結果通信中に含まれるデータブロックＺａを車両Ａに送信する（通信３２７）。したがって、マスタサーバ２１から車両ＡへのデータブロックＺａの送信も、繰り返し定期的に（具体的にはＴ１＝１秒周期で）行われる。

　車両Ａでは、クラウド対応空調パネル１２が、モデム１４および無線変換器１３を介してこのデータブロックＺａを受信する。そして空調パネル制御装置１２５は、出力調停処理１２５ｂにおいて、受信したデータブロックＺａに含まれる冷媒不足判定の値に基づいて、図７に示したように、冷媒不足表示器１２４の点灯、消灯、点滅を制御する。

　また空調パネル制御装置１２５は、出力調停処理１２５ｂにおいて、クラウド発オン要求およびクラウド発オフ要求の各々が受信したデータブロックＺａに含まれているか否かに基づいて、図６に示したように、Ａ／Ｃ表示器１２３の点灯、消灯を制御し、コンプレッサ駆動要求ＣＭＰの値（オン、オフ）を決定する。そして決定したコンプレッサ駆動要求ＣＭＰの値を、データブロックＸに含めてＡ／Ｃ＿ＥＣＵ１１に送信する（通信３２９）。Ａ／Ｃ＿ＥＣＵ１１は、クラウド対応空調パネル１２から受信したこのデータブロックＸ中のコンプレッサ駆動要求ＣＭＰを、Ａ／Ｃマグネットクラッチ６に出力することで、コンプレッサ２の作動を制御する。

　また、ジョブスケジューラ２２２、ワーカ２２２ｐ、ワーカ２２２ｑも同様の処理を行うので、マスタサーバ２１から車両ＢへのデータブロックＺｂの送信（通信３３１）も、繰り返し定期的に（具体的にはＴ１＝１秒周期で）行われる。また、ジョブスケジューラ２２３、ワーカ２２３ｐ、ワーカ２２３ｑも同様の処理を行うので、マスタサーバ２１から車両ＣへのデータブロックＺｃの送信（通信３３３）も、繰り返し定期的に（具体的にはＴ１＝１秒周期で）行われる。

　図１２に、上記のようなワーカ２２１ｐ、２２１ｑから車両Ａまでのデータの流れを示す。車両Ｂおよびクラウド２００については、車両Ａおよびクラウド２００と同様の作動で、マスタサーバ２１、ジョブスケジューラ２２２、ワーカ２２２ｐ、ワーカ２２２ｑと通信を行う。車両Ｃおよびクラウド２００についても、車両Ａおよびクラウド２００と同様の作動で、マスタサーバ２１、ジョブスケジューラ２２３、ワーカ２２３ｐ、ワーカ２２３ｑと通信を行う。

　これ以降は、上述の車両Ａのイグニッションオンの後からＡ／Ｃ＿ＥＣＵ１１にコンプレッサ２の作動の制御までの処理と同様の処理（図９の一点鎖線３００で囲んだ部分に関する処理）が、基本的には繰り返し定期的に（具体的には１秒周期で）、繰り返される。

　ただし、Ａ／Ｃ＿ＥＣＵ１１がデータブロックＷをクラウド対応空調パネル１２に送信した後（通信３３５）、クラウド対応空調パネル１２は、図１０のＳ１１０で、クラウド側カウント値を新たに受信していると判定し、Ｓ１２０に進む。Ｓ１２０では、当該新たに受信したクラウド側カウント値と同じ値を車側カウント値とし、データブロックＹに含める。したがって、このときクラウド対応空調パネル１２から無線変換器１３、モデム１４を介してマスタサーバ２１に送信されるデータブロックＹ（通信３３７）には、直前に受信したクラウド側カウント値と同じ値の車側カウント値が含まれている。

　また、その後の通信３３７、３３９、３４１、３４３、３４５、３４７、３４９、３５１、３５３、３５５、３５７の手順は、通信３１３、３１５、３１７、３１９、３２１、３２３、３２５、３２７、３２９、３３１、３３３の手順と同じであり、送信されるデータの種類も同じである。ただし、データの値自体はワーカおよび車載システム１００の処理結果に応じて変化する。

　ここで、プログラム２１ｂ、２１ｃ、２１ｄが規定する処理の内容について説明する。これらの処理は、ワーカが、ジョブスケジューラからの演算要求ＲＴａに従って、分散処理で実現する。冷媒検査プログラム２１ｂは、車両の冷凍サイクルの冷媒が不足しているか否かを判定する冷媒検査処理のためのプログラムである。

　図１３に示すように、冷媒検査プログラム２１ｂでは、４つの状態ＳＸ、ＳＡ、ＳＢ、ＳＣが規定されている。状態ＳＸは、プログラムの実行開始時の状態、すなわち、始状態である。状態ＳＡは、冷媒不足判定が未実施または中止または取り消された状態である。状態ＳＢは、冷媒不足判定の途中の状態である。状態ＳＣは、冷媒不足判定が完了した状態である。

　また、状態ＳＡは下位階層として未実施状態ＳＡ１および中止状態ＳＡ２を含んでいる。また、状態ＳＢは下位階層として第１判定中＿停車状態ＳＢ１、および第２判定中＿停車状態ＳＢ２を含んでいる。また、状態ＳＣは下位階層として冷媒不足なし状態ＳＣ１および冷媒不足有り状態ＳＣ２を含んでいる。

　冷媒検査プログラム２１ｂでは、判定に用いるデータＩＧ、ＳＰＤ、ＴＨＷ、ＴＥｆｉｎ、ＰＲＥ、ＯＦＦ、ＭＯＮ、ＭＯＦＦの値は、ジョブスケジューラ２２１がマスタサーバ２１から受信する最新のジョブ要求通信中のデータブロックＹａを参照して決定する。

　冷媒検査プログラム２１ｂの実行開始時には、この冷媒検査プログラム２１ｂの実行主体（本事例ではワーカ２２１ｐ、２２１ｑ）の状態は始状態ＳＺである。実行主体は、始状態ＳＺにいるとき、ＩＧがオフからオンに変化したことを検出すると、状態ＳＡの未実施状態ＳＡ１に遷移する。この遷移の際、実行主体は、作動Ｇ３を行う。すなわち、カウンタＪ、Ｋをゼロにクリアし、冷媒不足判定の値を「未判定」にセットする。

　そして、状態ＳＡ（未実施状態ＳＡ１、中止状態ＳＡ２を含む）においては、リアルタイム性がＮＧ（不良）であると判定されている場合、状態ＳＡに留まり続ける。なお、リアルタイム性は、後述するリアルタイム性判定プログラム２１ｄの処理において判定される。

　また、状態ＳＡにおいては、条件Ｓ１が満たされると、状態ＳＢ中の状態ＳＢ１に遷移する。条件Ｓ１は、リアルタイム性がＮＧからＯＫ（良好）に変化し、かつ、以下の条件（１）～（３）すべてが３００秒以上成立しているという条件である。
（１）最後にマニュアルオン要求ＭＯＮが受信されて以降マニュアルオフ要求ＭＯＦＦが一度も受信されていない。
（２）ＳＰＤが０ｋｍ／ｈである。
（３）ＴＨＷが４５度Ｃを超えている。

　上記の（１）の条件は、ユーザによってＡ／Ｃスイッチ１２１が操作された後に、コンプレッサ２が３００秒以上作動している場合に満たされる。

　また、状態ＳＢ１にいる間は、１秒周期で、冷媒不足判定の値を「未判定」にセットし、カウンタＪの値を１だけカウントアップし、マスタサーバ２１から次回送信されるデータブロックＺａに含めるためのクラウド発オン要求を生成する。したがって、状態ＳＢ１の間は、クラウド発オン要求がデータブロックＺに含まれて空調パネル制御装置１２５に送信される。これにより、空調パネル制御装置１２５は、出力調停処理１２５ｂにおいて図６に示したようにコンプレッサ駆動要求ＣＭＰをオンにするので、状態ＳＢ１の間は、Ａ／Ｃ＿ＥＣＵ１１によってコンプレッサ２が駆動され続ける。

　また、状態ＳＢ１において、カウンタＪの値が１６を超えると、状態ＳＢ２に遷移する。また、状態ＳＢ１において、ＰＲＥの値が冷媒不足５０％検査圧力を超えると、状態ＳＣ中の状態ＳＣ１に遷移する。

　冷媒不足５０％検査圧力は、あらかじめ定められた定数値（例えば１．２ＭＰａ）であってもよいが、図１４に示すように、外気温度が高くなるほど高くなるように設定してもよい。なお、ここで用いる外気温度は、車両Ａの外気温度であるので、車両Ａから取得する必要がある。具体的には、Ａ／Ｃ＿ＥＣＵ１１が車両Ａに搭載された外気温センサ（図示せず）から取得した外気温ＴｏｕｔのデータをデータブロックＷに含め、クラウド対応空調パネル１２もデータブロックＹにその外気温Ｔｏｕｔのデータを含めるようになっていればよい。

　また、状態ＳＢ２にいる間は、１秒周期で、冷媒不足判定の値を「未判定」にセットし、カウンタＫの値を１だけカウントアップする。また、状態ＳＢ２にいる間は、図１５に示すように、クラウド発オン要求とクラウド発オフ要求を切り替える。具体的には、クラウド発オフ要求を次回のデータブロックＺａに含めるために生成する処理を１４秒間繰り返す。そしてその後は、クラウド発オン要求を次回のデータブロックＺａに含めるために生成する処理を１６秒間繰り返す。そしてその後は、クラウド発オフ要求を次回のデータブロックＺａに含めるために生成する処理を１４秒間繰り返す。れは、冷媒不足判定のために、一時的に、車両Ａのコンプレッサ２を１４秒間停止させ、続いて１６秒作動させ、続いて１４秒停止させるための処理である。

　より具体的には、状態ＳＢ１から状態ＳＢ２に遷移した時点ｔ１において、クラウド発オフ要求の繰り返し生成を開始する。この時点ｔ１においては、カウンタＫの値は０である。その後、カウンタ値が１４になった時点ｔ２において、クラウド発オフ要求の繰り返し生成を止めてクラウド発オン要求の繰り返し生成を開始する。その後、カウンタ値が３０になった時点ｔ３において、クラウド発オン要求の繰り返し生成を止めてクラウド発オフ要求の繰り返し生成を開始する。この作動は、実行主体が状態ＳＢ２にいる限り、少なくともカウンタ値が４４になる時点ｔ４まで続く。

　したがって、状態ＳＢ２の時点ｔ１から時点ｔ２の間および時点ｔ３から時点ｔ４の間は、クラウド発オフ要求がデータブロックＺａに含まれて空調パネル制御装置１２５に送信される。これにより、空調パネル制御装置１２５は、出力調停処理１２５ｂにおいて図６に示したようにコンプレッサ駆動要求ＣＭＰを一時的にオフにするので、Ａ／Ｃ＿ＥＣＵ１１によってコンプレッサ２が一時的に停止され続ける。

　また、状態ＳＢ２の時点ｔ２から時点ｔ３の間は、クラウド発オン要求がデータブロックＺａに含まれて空調パネル制御装置１２５に送信される。これにより、空調パネル制御装置１２５は、出力調停処理１２５ｂにおいて図６に示したようにコンプレッサ駆動要求ＣＭＰを一時的にオンにするので、Ａ／Ｃ＿ＥＣＵ１１によってコンプレッサ２が一時的に駆動され続ける。

　また、状態ＳＢ２において、ΔＴｅｆｉｎが６度Ｃ以下のままカウンタＫの値が４４を超えると、状態ＳＣ中の状態ＳＣ２に遷移する。状態ＳＣ２に遷移するとき、クラウド発オン要求を次回のデータブロックＺａに含めるために生成してもよいし、生成しなくてもよい。

　ただし、状態ＳＢ２において、カウンタＫの値が４４になる前にΔＴｅｆｉｎが６度Ｃを超えると、状態ＳＣ１に遷移する。ここで、ΔＴｅｆｉｎは、最後に第２判定中＿停車状態ＳＢ２に遷移して以降におけるＴｅｆｉｎの最大値と最小値の差分である。

　状態ＳＢ２から状態ＳＣ１に遷移するタイミングで、クラウド発オン要求を次回のデータブロックＺａに含めるために生成してもよい。あるいは、状態ＳＢ２から状態ＳＣ１に遷移した後、所定の時間経過後（例えば、状態ＳＢ２の開始から４４秒後）のタイミングで、クラウド発オン要求を次回のデータブロックＺａに含めるために生成してもよい。これにより、空調パネル制御装置１２５は、出力調停処理１２５ｂにおいて図６に示したようにコンプレッサ駆動要求ＣＭＰをオンにするので、Ａ／Ｃ＿ＥＣＵ１１によってコンプレッサ２が駆動される。したがって、状態ＳＢ２の時点ｔ１から時点ｔ２の間および時点ｔ３から時点ｔ４の間に状態ＳＢ２から状態ＳＣ１への遷移が発生しても、その後コンプレッサ２はユーザの意図通りに作動し始める。また、状態ＳＢ２の時点ｔ２から時点ｔ３の間に状態ＳＢ２から状態ＳＣ１への遷移が発生しても、その後コンプレッサ２はユーザの意図通りに作動し続ける。

　また、状態ＳＢ（状態ＳＢ１、ＳＢ２を含む）においては、リアルタイム性がＮＧ（不良）であると判定されると、状態ＳＡ（より具体的には状態ＳＡ２）に遷移する。この遷移の際、作動Ｇ３を行う。すなわち、カウンタＪ、Ｋをゼロにクリアし、冷媒不足判定の値を「未判定」にセットする。

　状態ＳＢから状態ＳＡに遷移するタイミングで、クラウド発オン要求を次回のデータブロックＺａに含めるために生成してもよい。あるいは、状態ＳＢから状態ＳＡに遷移した後、所定の時間経過後（例えば、状態ＳＢ１の開始から６０秒後）のタイミングでクラウド発オン要求を次回のデータブロックＺａに含めるために生成してもよい。これにより、空調パネル制御装置１２５は、出力調停処理１２５ｂにおいて図６に示したようにコンプレッサ駆動要求ＣＭＰをオンにするので、Ａ／Ｃ＿ＥＣＵ１１によってコンプレッサ２が駆動される。したがって、状態ＳＢ２の時点ｔ１から時点ｔ２の間および時点ｔ３から時点ｔ４の間に状態ＳＢ２から状態ＳＡへの遷移が発生しても、その後コンプレッサ２はユーザの意図通りに作動し始める。また、状態ＳＢ１の間または状態ＳＢ２の時点ｔ２から時点ｔ３の間に状態ＳＢから状態ＳＡへの遷移が発生しても、その後コンプレッサ２はユーザの意図通りに作動し続ける。

　また、状態ＳＢにおいては、条件Ｓ２が成立する場合、すなわち、
（４）新たに受信されたデータブロックＹａにマニュアルオフ要求ＭＯＦＦが含まれている
（５）上記条件（２）が不成立になる
（６）上記条件（３）が不成立になる
のいずれかの条件成立する場合、状態ＳＡ（より具体的には状態ＳＡ２）に遷移する。この遷移の際、作動Ｇ３を行う。すなわち、カウンタＪ、Ｋをゼロにクリアし、冷媒不足判定の値を「未判定」にセットする。

　また、状態ＳＣ１にいる間は、１秒周期で冷媒不足判定の値を「冷媒不足無し」にセットする。また、状態ＳＣ２にいる間は、冷媒が必要量の５０％以下である可能性が高いので、１秒周期で冷媒不足判定の値を「冷媒不足有り」にセットする。

　また、状態ＳＣ２において、条件Ｓ３が成立する場合、状態ＳＡ２に遷移する。条件Ｓ３が成立する場合とは、データＯＦＦの値が「押下」であるか、または、新たに受信されたデータブロックＹａにマニュアルオン要求ＭＯＮが含まれている場合である。この遷移の際、作動Ｇ３を行う。すなわち、カウンタＪ、Ｋをゼロにクリアし、冷媒不足判定の値を「未判定」にセットする。以上が、冷媒検査プログラム２１ｂが規定する処理の内容である。

　ここで、冷媒検査プログラム２１ｂがパラメータとして用いるリアルタイム性について説明する。
リアルタイム性とは、タイムラグＬが基準時間よりも短いことをいう。タイムラグＬは、第１処理時間、第１通信時間、第２処理時間、第２通信時間、第３処理時間の総和である。第１処理時間は、車載システム１００内の作動状態を示す状態量（例えば、ＩＧ、ＳＰＤ）が車載システム１００で検出されてから送信されるまでの時間である。第２処理時間は、上記状態量が車載システム１００から送信されて冷媒検査プログラム２１ｂの実行主体で受信されるまでの時間である。第２処理時間は、当該実行主体が当該状態量を受信してから、冷媒検査プログラム２１ｂの実行において当該状態量を利用して利用結果のデータ（例えば、冷媒不足判定、クラウド発オン要求）を生成して送信するまでの時間である。第２通信時間は、当該実行主体が当該利用結果のデータを送信してから車載システム１００が受信するまでの時間である。第３処理時間は、車載システム１００が当該当該利用結果のデータを受信してから、当該データを制御に反映するまでの時間である。

　上述の通り、車両用空調装置の診断（すなわち、冷媒量の判定）にはクラウド２００クラウド４００がアクチュエータ（すなわち、コンプレッサ２）を遠隔制御するので、リアルタイム性が無いときにこのような診断を実行するのは困難である。また、冷媒検査プログラム２１ｂは、コンプレッサ２を制御するための複雑な制御を記述する必要があるので、データサイズが大きくなりがちである。したがって、このような冷媒検査プログラム２１ｂを車両側（Ａ／Ｃ＿ＥＣＵ１１または空調パネル制御装置１２５）で実行するよりもクラウド２００側で実行することで、車両側の処理負荷の低減効果およびメモリ容量の節約効果が大きい。

　本実施形態では、上記総和の時間が所定時間より短いか否かで、リアルタイム性の有無が判断される。ここで、車載システム１００内の作動状態を示す状態量は、具体的には、ＩＧ、ＳＰＤ、ＴＨＷ、ＴＥｆｉｎ、ＰＲＥ、ＯＦＦ、ＭＯＮ、ＭＯＦＦである。また、車載システム１００内の制御は、具体的には、コンプレッサ２、Ａ／Ｃ表示器１２３、冷媒不足表示器１２４の制御である。

　本実施形態では、冷媒検査プログラム２１ｂの処理は、基本的に複数のワーカ２２１ｐ、２２１ｑに分散されて実行されるので、処理自体に遅延が発生することはあまりない。したがって、車載システム１００からクラウド２００へのデータブロックＹの送信、および、クラウド２００から車載システム１００へのデータブロックＺの送信による遅延が共に小さければ（例えば各々０．５秒未満なら）リアルタイム性はＯＫ（良好）である。しかし、車載システム１００からクラウド２００へのデータブロックＹの送信、および、クラウド２００から車載システム１００へのデータブロックＺの送信いずれかに大きな遅延（例えば４秒）があれば、リアルタイム性はＮＧ（不良）であり、適切な冷媒不足判定が行えない可能性が高くなる。

　そこで、本実施形態では、冷媒検査プログラム２１ｂにおいては、リアルタイム性の判定結果に基づいて、上述のような作動が規定されている。すなわち、冷媒不足の判定を行っていない状態ＳＡにおいてリアルタイム性がＮＧならば、状態ＳＡに留まって状態ＳＢに遷移しないことで、冷媒不足の判定を開始しない。そして、状態ＳＡにおいてリアルタイム性がＮＧからＯＫになって初めて、状態ＳＢに遷移して冷媒不足の判定を開始する。

　また、冷媒不足の判定の最中である状態ＳＢにおいては、リアルタイム性がＮＧになれば、冷媒不足の判定を中止して状態ＳＡに戻る。また、冷媒不足の判定を中止して状態ＳＡに戻った後も、リアルタイム性がＮＧからＯＫに戻れば、状態ＳＢ１に遷移して冷媒不足の判定を最初から実行し直す。なお、中止した冷媒不足の判定を途中から再開してもよい。

　また、既にリアルタイム性の判定が完了している状態ＳＣにおいては、リアルタイム性がＮＧになっても特に問題はないので、状態ＳＣを維持する。

　次に、カウントプログラム２１ｃの規定する作動について、図１６を参照して説明する
。カウントプログラム２１ｃの実行主体（ワーカ２２１ｐ、２２１ｑ）は、ジョブスケジューラ２２１が制御準備完了の通知（通信３０７）を送信した後最初に演算要求（通信３２１）を受信したときに、このカウントプログラム２１ｃの実行を開始し、その後継続的に実行する。

　そして当該実行主体は、カウントプログラム２１ｃの実行において、まずＳ２１０で、クラウド側カウント値を初期値（例えばゼロ）にクリアすると共に、リアルタイム性の値を初期値（例えば、ＯＫ）にクリアする。

　Ｓ２２０では、前回のクラウド側カウント値のカウントアップ（初めてのＳ２２０ではカウントプログラム２１ｃの実行開始）から１秒間経過するまで待ち、経過するとクラウド側カウント値を１だけカウントアップする。この１秒間は、例えば、カウントプログラム２１ｃの実行主体のワーカに内蔵されているクロックに基づいて計測してもよいし、時刻情報を提供する外部のタイムサーバから送信される時刻情報に基づいて計測してもよい。カウントアップされた値は、直ちに演算結果としてジョブスケジューラ２２１に送信され、ジョブスケジューラ２２１から他のワーカに送信される。

　このようになっているので、上述のようにワーカ２２１ｐまたは２２１ｑから送信される演算結果ＺａｐまたはＺａｑに含まれるクラウド側カウント値は、１秒毎に１ずつ上昇する。また同様に、ジョブスケジューラ２２１からマスタサーバ２１を経て車両Ａの車載システム１００まで送信されるデータブロックＺａ中のクラウド側カウント値も、１秒毎に１ずつ上昇する。

　次に、リアルタイム性判定プログラム２１ｄの規定する作動について、図１７を参照して説明する。リアルタイム性判定プログラム２１ｄの実行主体（ワーカ２２１ｐ、２２１ｑ）は、ジョブスケジューラ２２１が制御準備完了の通知（通信３０７）を送信した後最初に演算要求（通信３２１）を受信したときに、このリアルタイム性判定プログラム２１ｄの実行を開始し、その後継続的に実行する。

　そして当該実行主体は、リアルタイム性判定プログラム２１ｄの実行において、まずＳ２４０で、車側カウント値を新たに受信したか否かを判定し、新たに受信したと判定するまでこの判定を繰り返す。例えば図９の通信３３７で送信されるデータブロックＹａ（およびそれ以降に送信されるデータブロックＹａ）には、既に説明した通り、車側カウント値が含まれる。

　受信する車側カウント値は、図１０を参照して説明した通り、カウントプログラム２１ｃの実行主体から演算結果ＺａｐまたはＺａｑとして前回送信されたクラウド側カウント値と値が同じである。

　車側カウント値を新たに受信したと判定した場合、Ｓ２５０に進み、受信した車側カウント値と現在のクラウド側カウント値との差（クラウド側カウント値－車側カウント値）を算出する。車載システム１００側の送信周期Ｔ１もクラウド２００側の送信周期Ｔ１も同じく１秒なので、車両Ａの車載システム１００とクラウド２００との間の双方向の通信に大きな遅延がなければ、この差は２以下になるはずである。この差が３以上なら、車両Ａの車載システム１００からクラウド２００への送信およびクラウド２００から車載システム１００への通信のうちいずれか一方または両方に大きな遅延があるということになる。

　Ｓ２６０では、直前のＳ２５０で算出したカウント値の差が２を超えているか否か判定する。超えていなければ、Ｓ２７０でリアルタイム性の値を「ＯＫ」にセットし、Ｓ２４０に戻る。超えていれば、Ｓ２８０でリアルタイム性の値を「ＮＧ」にセットし、Ｓ２４０に戻る。Ｓ２７０、Ｓ２８０で設定されたリアルタイム性の値は、直ちに演算結果としてジョブスケジューラ２２１に送信され、ジョブスケジューラ２２１から他のワーカに送信される。したがって、当該リアルタイム性の値は遅延無くリアルタイム性判定プログラム２１ｄの処理において使用される。

　このように、本実施形態の通信システムでは、ジョブスケジューラ２２１に管理されるワーカがクラウド側カウント値を１秒毎にカウントアップする。そして当該ワーカからジョブスケジューラ２２１およびマスタサーバ２１を介して空調パネル制御装置１２５へクラウド側カウント値がデータブロックＺに含まれて送信される。そして、空調パネル制御装置１２５は、受信したクラウド側カウント値と同じ値の車側カウント値をデータブロックＹに含めて送信し、当該車側カウント値はマスタサーバ２１およびジョブスケジューラ２２１を介してワーカに届く。したがって、ワーカは、自機がクラウド側カウント値を送信してから、当該クラウド側カウント値に対する応答を空調パネル制御装置１２５から受信するまでの時間（すなわち、両者の通信に要する時間）に基づいて、リアルタイム性の判定を行っている。つまり、クラウド側カウント値は、リアルタイム性の確認用のタイムデータであり、車側カウント値は、当該タイムデータに対する応答である。

　そして、リアルタイム性は、この両者の通信に要する時間が、所定の範囲を、つまり、受信した車側カウント値と現在のクラウド側カウント値との差が２以下となるような範囲を超えて大きいか否かで判定される。

　なお、車両Ａのイグニッションがオンからオフになった場合、Ａ／Ｃ＿ＥＣＵ１１は、イグニッション状態ＩＧのデータをオンからオフに更新する。その後、最初に訪れるデータブロックＷの送信タイミングにおいて、Ａ／Ｃ＿ＥＣＵ１１は、既に説明した通り、イグニッション状態ＩＧを含むデータブロックＷを、空調パネル制御装置１２５に送信する（通信３８１）。

　空調パネル制御装置１２５は、このデータブロックＷを受信した後に最初に訪れるデータブロックＹの送信タイミングにおいて、既に説明した通り、当該データブロックＷに含まれるデータＩＧ等を、送信用のデータブロックＹａに含める。そして空調パネル制御装置１２５は、このデータブロックＹを、無線変換器１３、モデム１４を介してマスタサーバ２１に送信する（通信３８３）。この際、無線変換器１３が、データブロックＹａに対して自機のアドレスを付加する。

　このデータブロックＹａを受信したマスタサーバ２１は、受信したデータブロックＹａに含まれるデータＩＧの値がオフであることに基づいて、ジョブスケジューラ２２１に対してワーカ消滅要求を送信する（通信３８５）。

　このワーカ消滅要求を受信したジョブスケジューラ２２１は、ワーカ２２１ｐ、２２１ｑと通信することで、冷媒検査プログラム２１ｂ、カウントプログラム２１ｃ、リアルタイム性判定プログラム２１ｄの処理を終了させる（通信３８７）。その後ジョブスケジューラ２２１は、ワーカ消滅終了の通知をマスタサーバ２１に送信する（通信３８９）。このワーカ消滅終了の通知を受信したマスタサーバ２１は、制御受付ＮＧの通知を車両Ａに送信する。車両Ａでは、この制御受付ＮＧの通知を空調パネル制御装置１２５が受信し、その後、空調パネル制御装置１２５が作動を停止する。

　ここで、本実施形態における車載システム１００側およびクラウド２００側の機能構成について、図１８を参照して説明する。車載システム１００側の機能は、ハードウェア層Ｖ１としてクラウド対応空調パネル１２を有し、ハードウェア層Ｖ１の上位の階層として通信部Ｖ２（無線変換器１３、モデム１４）を有している。そして更に、通信部Ｖ２の上位の階層として通信監視部Ｖ３を有しており、通信監視部Ｖ３には図１０のカウント返送処理１２５ｃの機能が含まれている。また、通信部Ｖ２および通信監視部Ｖ３の上位の階層としてアプリケーション層Ｖ４を有しており、このアプリケーション層Ｖ４にはマニュアル状態遷移処理１２５ａと出力調停処理１２５ｂの機能が含まれている。

　クラウド２００側の機能は、クラウドインフラ層Ｃ１としてマスタサーバ２１およびスレーブサーバ群２２を有し、クラウドインフラ層Ｃ１の上位の階層として通信部Ｃ２を有している。そして更に、通信部Ｃ２の上位の階層として通信監視部Ｃ３を有しており、通信監視部Ｃ３にはカウントプログラム２１ｃ、リアルタイム性判定プログラム２１ｄの機能が含まれている。また、通信部Ｃ２および通信監視部Ｃ３の上位の階層としてアプリケーション層Ｃ４を有しており、このアプリケーション層Ｖ４には冷媒検査プログラム２１ｂの機能が含まれている。

　このように、通信監視部Ｖ３のカウント返送処理１２５ｃの機能を、アプリケーション層Ｖ４のマニュアル状態遷移処理１２５ａと出力調停処理１２５ｂの機能から独立させる（すなわち、異なるソフトウェアモジュールとして実現する）ことにより、マニュアル状態遷移処理１２５ａと出力調停処理１２５ｂの開発が見通しのよいものになる。

　また、通信監視部Ｃ３のカウントプログラム２１ｃ、リアルタイム性判定プログラム２１ｄの機能を、アプリケーション層Ｃ４の冷媒検査プログラム２１ｂの機能から独立させる（すなわち、異なるソフトウェアモジュールとして実現する）ことにより、冷媒検査プログラム２１ｂの開発が見通しのよいものになる。つまり、クラウド２００を利用せず車内でスタンドアローンに用いる冷媒検査プログラムと冷媒検査プログラム２１ｂとの違いが少なくなるので、冷媒検査プログラム２１ｂの開発においてスタンドアローンに用いる冷媒検査プログラムを流用し易い。

　以上説明した通り、本実施形態においては、クラウド２００は、空調パネル制御装置１２５と１台以上のサーバとの間の通信に要する時間が所定の基準を超えているか否かを状態ＳＢで判定し、所定の基準を超えていると判定されたことに基づいて、状態ＳＢから状態ＳＡに遷移することで、車両用空調装置の冷媒不足の判定を中止する。

　このように、空調パネル制御装置１２５とクラウド２００との間の通信の遅延が所定の基準を超えて大きいときに、車両用空調装置の冷媒不足の判定が中止されるという形で、リアルタイム性の判定が実現されている。これにより、リアルタイム性が不良で適切な冷媒不足の判定が行えない可能性が高い場合にまで、冷媒不足の判定を続けることの無駄を低減できる。

　なお、本実施形態では、ワーカ２２１ｐ、２２１ｑが、冷媒検査プログラム２１ｂを実行することで、冷媒の検査部あるいはデバイスの一例として機能し、リアルタイム性判定プログラム２１ｄを実行することで判定部あるいはデバイスの一例として機能する。言い換えれば、これらのプログラムは、検査部、判定部としてコンピュータ（サーバを含む）を機能させるインストラクションを含み、コンピュータ読取可能な、非遷移の記憶媒体に記録された、プログラム製品としても提供されることも可能である。

　（第２実施形態）
　次に第２実施形態について説明する。図１９に示すように、本実施形態の通信システムは、車両に搭載された車載システム３０、および、車両外の遠隔地に設置されて車載システム３０と通信するクラウド４００（１台以上のサーバの一例に相当する）を備えている。

　車載システム３０は、蒸発燃料のリークを検出するためのシステムであり、燃料タンク３１、連通管３２、キャニスタ３３、パージ管３４、第１バルブ３５、吸気通路３６、スロットルバルブ３７、管３８ａ、３８ｂ、３８ｃ、３８ｄを含んでいる。更に車載システム３０は、第２バルブ３９、第３バルブ４０、基準オリフィス４１、減圧ポンプ４２、圧力センサ４３、蒸発器電子制御ユニット（ＥＶ＿ＥＣＵ）４４、バッテリ４５、ＩＧスイッチ４６、リレー４７、無線変換器４８を含んでいる。第１バルブ３５、第２バルブ３９、第３バルブ４０、減圧ポンプ４２の各々が、アクチュエータの一例に相当する。

　燃料タンク３１は、車載システム３０の搭載先の車両のエンジンに供給するための燃料を貯留する。この燃料は、主に燃料噴射弁から噴射されてエンジン内に入る。連通管３２は、燃料タンク３１内とキャニスタ３３内とに連通する配管である。

　キャニスタ３３は、燃料タンク３１内で発生して連通管３２を通ってキャニスタ３３内に入った蒸発燃料を、回収する。パージ管３４は、一端がキャニスタ３３内に連通して他端が吸気通路３６に連通する配管である。

　第１バルブ３５は、パージ管３４の途中に配置されている。この第１バルブ３５は、パージ管３４を通ってキャニスタ３３から吸気通路３６にパージされる蒸発燃料の量をエンジン運転中等において調整する弁である。吸気通路３６は、エンジンに空気を送る通路である。この吸気通路３６の内部に、スロットルバルブ３７が配置されている。スロットルバルブ３７は、スロットル開度を変化させることで吸気通路３６からエンジンに流入する空気量を調整する弁である。

　キャニスタ接続管３８ａは、一端がキャニスタ３３内に連通し、他端が第１大気管３８ｂ、第２大気管３８ｃ、およびバイパス管３８ｄに連通する配管である。第１大気管３８ｂは、一端がキャニスタ接続管３８ａ、第２大気管３８ｃ、バイパス管３８ｄに連通し、他端が車両の外部の空間に連通する配管である。第２大気管３８ｃは、一端がキャニスタ接続管３８ａ、第１大気管３８ｂ、バイパス管３８ｄに連通し、他端が車両外部の空間に連通する配管である。バイパス管３８ｄは、一端がキャニスタ接続管３８ａ、第１大気管３８ｂ、および、大気管３８ｃの上記一端に連通する。また、バイパス管３８ｄは、他端が第２大気管３８ｃの途中に連通する。

　第１大気管３８ｂの途中には、第２バルブ３９が配置されている。第２バルブ３９は、第１大気管３８ｂの内部の通路を開閉する弁である。バイパス管３８ｄの途中には、第３バルブ４０が配置されている。第３バルブ４０は、バイパス管３８ｄの内部の通路を開閉する弁である。

　第２大気管３８ｃの途中には、基準オリフィス４１が配置されている。基準オリフィス４１の通路内径は、燃料タンク３１からの蒸発燃料を含む気体の漏れの許容量の上限値となる基準径（例えば０．５ｍｍ）となっている。

　減圧ポンプ４２は、第２大気管３８ｃの基準オリフィス４１の下流側（すなわち第２大気管３８ｃの上記他端側）に配置され、第２大気管３８ｃ内の減圧ポンプ４２よりも上流側（すなわち第２大気管３８ｃの上記一端側）から気体を吸引して下流側に吐出する。

　圧力センサ４２は、第２大気管３８ｃ内の基準オリフィス４１の下流側かつ減圧ポンプ４２よりも上流側の検出位置における圧力を検出する。なお、バイパス管３８ｄの上記他端は、第２大気管３８ｃ内の上記検出位置よりも下流かつ減圧ポンプ４２よりも上流側に連通する。

　バッテリ４５は、車両に搭載された二次電池であり、車両の各種機器に電力を供給する。ＩＧスイッチ４６は、バッテリ４５からＩＧ線を介してＥＶ＿ＥＣＵ４４を含む上記各種装置に電力を供給する、しないを切り替えるスイッチである。

　リレー４７は、ＩＧスイッチ４６のオン、オフとは無関係に、バッテリ４５からＥＶ＿ＥＣＵ４４への電力供給をオンオフするスイッチ回路である。

　ＥＶ＿ＥＣＵ４４は、後述するように、クラウド４００からの指令に従って、第１バルブ３５、第２バルブ３９、第３バルブ４０、減圧ポンプ４２等を制御する。ＥＶ＿ＥＣＵ４４は、例えば、ＣＰＵと、ＲＯＭ、ＲＡＭ等のメモリと、入出力部等を持つ周知のマイクロコンピュータで実現可能である。ＥＶ＿ＥＣＵ４４が第１バルブ３５、第２バルブ３９、第３バルブ４０、減圧ポンプ４２等を制御するのは、エバポ系の診断、より詳しくは、エバポ系における蒸発燃料のリーク有無の判定のためである。エバポ系は、燃料タンク３１全体、連通管３２全体、キャニスタ３３全体、および、パージ管３４のキャニスタ３３側端から第１バルブ３５まで、を有する装置であり、車載装置の一例に相当する。このエバポ系は、第１バルブ３５、第２バルブ３９、第３バルブ４０、減圧ポンプ４２の作動内容によって状態が変化する。

　また、ＥＶ＿ＥＣＵ４４は、データブロックＴを１秒毎に無線変換器４８に送信する。データブロックＴの内容については後述する。

　無線変換器４８は、ＥＶ＿ＥＣＵ４４とモデム１４との中継を行う装置である。具体的には、無線変換器４８は、ＥＶ＿ＥＣＵ４４から送信されたデータブロックＴに無線変換器４８のアドレス（例えばＭＡＣアドレス）を含めてモデム１４に送信する。

　モデム１４は、例えば携帯電話機等の装置であり、車両の乗員に携帯されて車室内に持ち込まれ、無線変換器４８および車外に設置されたサーバ群であるクラウド４００と通信可能な装置である。モデム１４は、図２０に示すように、無線変換器４８から受信した上記データブロックＴを、１秒毎にクラウド４００に送信する。モデム１４とクラウド４００は、例えばインターネット等の広域ネットワークを介して通信する。

　ここで、図２１に示す通り、データブロックＴは、圧力センサデータＰ、イグニッション状態ＩＧ、車側カウント値、リアルタイム有効データ、ＭＡＣアドレス（無線変換器４８のアドレス）を含んでいる。これらデータのうち、ＭＡＣアドレス以外は、ＥＶ＿ＥＣＵ４４がデータブロックＴとして無線変換器４８に送信する。また、圧力センサデータＰ、イグニッション状態ＩＧ、車側カウント値、リアルタイム有効データは、エバポ系を診断して蒸発燃料のリークを判定するために必要な検査データを構成する。リアルタイム有効データは、リアルタイム性ありとＥＶ＿ＥＣＵ４４が判定したときにのみ送信されるイベントデータである。

　またモデム１４は、図２０に示す通り、クラウド４００から繰り返しデータブロックＳを受信する。データブロックＳは、図２１に示す通り、エバポリーク判定、ポンプオン要求、ポンプオフ要求、リレーオン要求、リレーオフ要求、Ｖ１オン要求、Ｖ１オフ要求、Ｖ２オン要求、Ｖ２オフ要求、Ｖ３オン要求、Ｖ３オフ要求、クラウド側カウント値という１１個のデータを含んでいる。

　エバポリーク判定は、エバポ系における蒸発燃料のリーク有無の判定結果を示すイベントデータである。ポンプオン要求は、エバポ系の診断のためにクラウド４００側から減圧ポンプ４２の作動開始が要求されたことを示すイベントデータである。ポンプオフ要求は、エバポ系の診断のためにクラウド４００側から減圧ポンプ４２の作動停止が要求されたことを示すイベントデータである。
リレーオン要求は、エバポ系の診断のためにクラウド４００側からリレー４７のオン動作が要求されたことを示すイベントデータである。リレーオフ要求は、エバポ系の診断が終わった際にクラウド４００側からリレー４７のオフ動作が要求されたことを示すイベントデータである。

　Ｖ１オン要求は、クラウド４００側から第１バルブ３５の開動作が要求されたことを示すイベントデータである。Ｖ１オフ要求は、エバポ系の診断のためにクラウド４００側から第１バルブ３５の閉動作が要求されたことを示すイベントデータである。

　Ｖ２オン要求は、エバポ系の診断のためにクラウド４００側から第２バルブ３９の開動作が要求されたことを示すイベントデータである。Ｖ２オフ要求は、エバポ系の診断のためにクラウド４００側から第２バルブ３９の閉動作が要求されたことを示すイベントデータである。

　Ｖ３オン要求は、エバポ系の診断のためにクラウド４００側から第３バルブ４０の開動作が要求されたことを示すイベントデータである。Ｖ３オフ要求は、エバポ系の診断のためにクラウド４００側から第３バルブ４０の閉動作が要求されたことを示すイベントデータである。クラウド側カウント値については後述する。

　クラウド４００は、繰り返し、定期的に具体的には１秒周期で、上記クラウド側カウント値を含むデータブロックＳを、モデム１４に送信する。また、データブロックＳに含まれる場合があるデータのうちイベントデータの各々については、特定の条件が満たされた場合にのみ、上記データブロックＳに含める。モデム１４は、受信したデータブロックＳを無線変換器４８に送信し、無線変換器４８は受信したデータブロックＳをＥＶ＿ＥＣＵ４４に送信する。

　ここで、ＥＶ＿ＥＣＵ４４の作動について説明する。ＥＶ＿ＥＣＵ４４は、図２２に示す処理を実行するようになっている。まずＳ４１０では、モデム１４、無線変換器４８を介してクラウド４００から最後に受信したデータブロックＳを、ＲＡＭに読み出す。

　Ｓ４２０では、直前のＳ４１０で読み出したデータブロックＳにポンプオン要求、ポンプオフ要求、リレーオン要求、リレーオフ要求、Ｖ１オン要求、Ｖ１オフ要求、Ｖ２オン要求、Ｖ２オフ要求、Ｖ３オン要求、Ｖ３オフ要求のいずれか１つ以上が含まれている場合、含まれている要求を実現するよう、必要に応じて、第１バルブ３５、第２バルブ３９、第３バルブ４０、減圧ポンプ４２、リレー４７を制御する。上記要求がデータブロックＳに１つも含まれていない場合は、制御を行わずＳ４３０に進む。

　Ｓ４３０では、直前のＳ４１０で読み出したデータブロックＳにエバポリーク判定のデータが含まれている場合、そのデータを記憶媒体（例えばＥＶ＿ＥＣＵ４４のフラッシュメモリ）に記録する。このように記録されたエバポリーク判定のデータは、後に読み出して車両の解析、故障判定等に使用される。データブロックＳにエバポリーク判定のデータが含まれている場合、何もせずＳ４４０に進む。

　Ｓ４４０では、センサ値を取得する。具体的には、圧力センサ４３の検出結果に基づいて圧力センサ値Ｐを取得する。この圧力センサ値Ｐは、第２大気管３８ｃ内における基準オリフィス４１の下流かつ減圧ポンプ４２の上流の圧力である。

　Ｓ４５０では、車両のイグニッション状態ＩＧを取得する。ＩＧスイッチ４６がオンならばイグニッション状態ＩＧはオンとなり、ＩＧスイッチ４６がオフならばイグニッション状態ＩＧはオフとなる。

　Ｓ４６０では、リアルタイム性有無について判定を行う。この判定の詳細については後述する。Ｓ４７０では、ＲＡＭ中の車側カウント値（車側リアルタイム性確認カウント値）の値を１だけカウントアップする。これにより、クラウド側カウント値は１秒に１だけ増加する。

　Ｓ４８０では、データブロックＴを作成して送信する。具体的には、直前のＳ４４０で取得済みの圧力センサ値Ｐ、直前のＳ４５０で取得済みのイグニッション状態ＩＧ、直前のＳ４７０で更新済みの車側カウント値を含むデータブロックＴを作成する。そして、直前のＳ４６０の判定結果が、「リアルタイム性あり」である場合は、当該データブロックＴにリアルタイム有効データを含める。しかし、直前のＳ４６０の判定結果が、「リアルタイム性なし」である場合は、当該データブロックＴにリアルタイム有効データを含めない。

　Ｓ４８０では更に、このようにして作成したデータブロックＴを、無線変換器４８に送信する。これにより、無線変換器４８が当該データブロックＴにアドレスを追加してモデム１４に送信し、モデム１４は当該アドレスが追加されたデータブロックＴをクラウド４００に送信する。

　ＥＶ＿ＥＣＵ４４は、Ｓ４９０で、所定時間、具体的には１秒間、待機し、その後、Ｓ４１０に戻る。ＥＶ＿ＥＣＵ４４は、このようにＳ４１０～４９０のループを１秒周期で実行する。

　このようにすることで、ＥＶ＿ＥＣＵ４４は、１秒周期で、その時点において受信している最新のデータブロックＳに基づいて制御、診断結果記録を行う。また、ＥＶ＿ＥＣＵ４４は、１秒周期で、その時点における最新の圧力センサ値、イグニッション状態ＩＧ、車側カウント値を含むデータブロックＴを、無線変換器４８、モデム１４を介して、クラウド４００に送信する。したがって、車側カウント値は、データブロックＴを送信する度に１だけ増加する。また、ＥＶ＿ＥＣＵ４４は、ＥＶ＿ＥＣＵ４４とクラウド４００の間の通信にリアルタイム性があれば、データブロックＴにリアルタイム有効データを含める。

　次に、クラウド４００の構成について説明する。クラウド４００は、図２３に示すように、第１実施形態と同じハードウェア構成のマスタサーバ２１と、第１実施形態と同じハードウェア構成のスレーブサーバ群２２を含んでいる。

　また、図１に示した車載システム３０およびモデム１４は、複数の車両Ｄ、Ｅ、Ｆの各々に搭載され、それぞれの車載システム３０のＥＶ＿ＥＣＵ４４が、同じ車両に搭載された無線変換器４８、モデム１４を介して、マスタサーバ２１と通信する。

　マスタサーバ２１は、第１実施形態と同様、演算指示処理２１ａを実行するようになっていると共に、図示しない記憶媒体を有し、当該記憶媒体に診断プログラム２１ｅ、カウントプログラム２１ｆ、リアルタイム性判定プログラム２１ｇが記録されている。このように、本実施形態においてマスタサーバ２１の記憶媒体に記録されているソフトウエアは、第１実施形態とは異なる。

　マスタサーバ２１が、車両Ｄ、Ｅ、Ｆのそれぞれ専用に１つジョブスケジューラを割り当ててプログラム２１ｅ、２１ｆ、２１ｇを送付する手順は、第１実施形態と同様であってもよいし、周知の他の分散処理技術を使用して実現してもよい。また、更に各ジョブスケジューラ２２１、２２２、２２３が、自機が管理する複数のワーカ２２１ｐ、２２１ｑ、２２２ｐ、２２２ｑ、２２３ｐ、２２３ｑにプログラム２１ｅ、２１ｆ、２１ｇの処理を分散させる手順も、第１実施形態と同様であってもよいし、周知の他の分散処理技術を使用して実現してもよい。

　このように、車両Ｄに関して行うべきプログラム２１ｅ、２１ｆ、２１ｇの処理が、ジョブスケジューラ２２１によって適宜複数のワーカ２２１ｐ、２２１ｑに分散して割り当てられるので、個々のワーカの処理負荷が軽減される。

　図２４に、上記のような車両Ｄからワーカ２２１ｐ、２２１ｑまでのデータの流れを示す。図２４では、車両Ｄ、Ｅ、Ｆから送信されたデータブロックＴを、それぞれＴｄ、Ｔｅ、Ｔｆと標記する。

　クラウド４００における分散処理では、車両Ｄのモデム１４からデータブロックＴｄを受信したマスタサーバ２１は、データブロックＴｄを含むジョブ要求通信ＲＴｄをジョブスケジューラ２２１に送信する。このジョブ要求通信ＲＴｄを受信したジョブスケジューラ２２１は、このジョブ要求通信ＲＴｄに含まれるデータブロックＴｄの内容と、プログラム２１ｅ、２１ｆ、２１ｇの処理内容に基づいて、プログラム２１ｅ、２１ｆ、２１ｇが規定する処理を、自機が管理する複数のワーカ２２１ｐ、２２１ｑに分散して実行させる。このため、ジョブスケジューラ２２１は、自機が管理する複数のワーカ２２１ｐ、２２１ｑの各々に対して、必要な演算要求Ｔｄｐ、Ｔｄｑを送信する。この演算要求Ｔｄｐ、Ｔｄｑには、ワーカ２２１ｐ、２２１ｑの各々で行うべき処理の内容およびその処理に必要なデータ（最新のデータブロックＴａの内容等）が含まれている。

　また、ワーカ２２１ｐ、２２１ｑは、それぞれ、ジョブスケジューラ２２１からの演算要求Ｔｄｐ、Ｔｄｑに従った作動を行い、図２５に示すように、その作動の結果得た、演算結果Ｓｄｐ、Ｓｄｑをジョブスケジューラ２２１に送信する。エバポリーク判定、ポンプオン要求、ポンプオフ要求、リレーオン要求、リレーオフ要求、Ｖ１オン要求、Ｖ１オフ要求、Ｖ２オン要求、Ｖ２オフ要求、Ｖ３オン要求、Ｖ３オフ要求、クラウド側カウント値は、演算結果Ｓｄｐ、Ｓｄｑのいずれかに含まれている。その他にも、演算時に使用する各種変数が、演算結果Ｓｄｐ、Ｓｄｑに含まれている。

　演算結果Ｓｄｐ、Ｓｄｑを受信したジョブスケジューラ２２１は、直ちに（すなわち、１秒よりも十分短い遅延で）、これら演算結果を、自機が管理する複数のワーカ２２１ｐ、２２１ｑの各々に送信する。このようにすることで、同じジョブスケジューラ２２１に管理される複数のワーカ２２１ｐ、２２１ｑ間で、各種データの値が整合する。

　また、ジョブスケジューラ２２１は、受信した最新の演算結果Ｓｄｐ、Ｓｄｑから（あれば）エバポリーク判定、（あれば）ポンプオン要求、（あれば）ポンプオフ要求、（あれば）リレーオン要求、（あれば）リレーオフ要求、（あれば）Ｖ１オン要求、（あれば）Ｖ１オフ要求、（あれば）Ｖ２オン要求、（あれば）Ｖ２オフ要求、（あれば）Ｖ３オン要求、（あれば）Ｖ３オフ要求、およびクラウド側カウント値を抽出してデータブロックＳｄを生成し、このデータブロックＳｄを含むジョブ結果通信を、繰り返し定期的に（具体的には１秒周期で）マスタサーバ２１に送信する。なお、図２５では、車両Ｄ、Ｅ、Ｆに送信するためのデータブロックＳを、それぞれＳｄ、Ｓｅ、Ｓｆと標記する。

　このジョブ結果通信を受信したマスタサーバ２１は、直ちに当該ジョブ結果通信中に含まれるデータブロックＳｄを車両Ｄに送信する。したがって、マスタサーバ２１から車両ＤへのデータブロックＳｄの送信も、繰り返し定期的に（具体的には１秒周期で）行われる。

　車両Ｄでは、ＥＶ＿ＥＣＵ４４が、モデム１４および無線変換器４８を介してこのデータブロックＳｄを受信する。そしてＥＶ＿ＥＣＵ４４は、図２２の処理において、データブロックＳｄ受信直後の図２２のループのＳ４１０で、このデータブロックＳｄをＲＡＭに読み出し、Ｓ４２０で、読み出したデータブロックＳｄ中のデータに基づいて、必要に応じて第１バルブ３５、第２バルブ３９、第３バルブ４０、減圧ポンプ４２、リレー４７を制御する。そしてＳ４３０で、データブロックＳｄ中のエバポリーク判定のデータが含まれている場合、そのデータを記憶媒体に記録する。また、その直後のＳ４６０では、データブロックＳｄ中のクラウド側カウント値および現在の車側カウント値に基づいて、リアルタイム性判定を行う。

　車両Ｅおよびクラウド４００については、車両Ｄおよびクラウド４００と同様の作動で、マスタサーバ２１、ジョブスケジューラ２２２、ワーカ２２２ｐ、ワーカ２２２ｑと通信を行う。この作動については、上記の説明の車両Ｄ、データブロックＴｄ、ジョブ要求通信ＲＴｄ、演算要求Ｔｄｐ、演算要求Ｔｄｑ、演算結果Ｓｄｐ、演算結果Ｓｄｑ、データブロックＳｄ、ジョブスケジューラ２２１、ワーカ２２１ｐ、ワーカ２２１ｑを、それぞれ、車両Ｅ、データブロックＴｅ、ジョブ要求通信ＲＴｅ、演算要求Ｔｅｐ、演算要求Ｔｅｑ、演算結果Ｓｅｐ、演算結果Ｓｅｑ、データブロックＳｅ、ジョブスケジューラ２２２、ワーカ２２２ｐ、ワーカ２２２ｑと読み替える。なお、この読み替えは、以下の説明についても有効である。

　車両Ｆおよびクラウド４００についても、車両Ｄおよびクラウド４００と同様の作動で、マスタサーバ２１、ジョブスケジューラ２２３、ワーカ２２３ｐ、ワーカ２２３ｑと通信を行う。この作動については、上記の説明の車両Ｄ、データブロックＴｄ、ジョブ要求通信ＲＴｄ、演算要求Ｔｄｐ、演算要求Ｔｄｑ、演算結果Ｓｄｐ、演算結果Ｓｄｑ、データブロックＳｄ、ジョブスケジューラ２２１、ワーカ２２１ｐ、ワーカ２２１ｑを、それぞれ、車両Ｆ、データブロックＴｆ、ジョブ要求通信ＲＴｆ、演算要求Ｔｆｐ、演算要求Ｔｆｑ、演算結果Ｓｆｐ、演算結果Ｓｆｑ、データブロックＳｆ、ジョブスケジューラ２２３、ワーカ２２３ｐ、ワーカ２２３ｑと読み替える。なお、この読み替えは、以下の説明についても有効である。

　ここで、プログラム２１ｅ、２１ｆ、２１ｇが規定する処理の内容について説明する。これらの処理は、ワーカが、ジョブスケジューラ２２１からの演算要求ＲＴａに従って、分散処理で実現する。

　診断プログラム２１ｅは、車両のエバポ系における蒸発燃料のリーク有無を判定するためのプログラムである。図２６に示すように、診断プログラム２１ｅでは、６個の状態ＳＤ、ＳＥ、ＳＦ、ＳＧ、ＳＨ、ＳＩが規定されている。また、状態ＳＦは、子状態ＳＦ１、ＳＦ２、ＳＦ３を有している。

　診断プログラム２１ｅで使用するイグニッション状態ＩＧ、圧力センサ値Ｐの値は、ジョブスケジューラ２２１がマスタサーバ２１から受信する最新のジョブ要求通信ＲＹａ中のデータブロックＹａを参照して決定する。

　診断プログラム２１ｅの実行開始時には、この診断プログラム２１ｅの実行主体（本事例ではワーカ２２１ｐ、２２１ｑ）の状態は＋Ｂオフ状態ＳＩにある。例えばこのとき、車両Ｄにおいて、ＩＧスイッチ４６、リレー４７はオフであり、ＥＶ＿ＥＣＵ４４は停止中となっているとする。

　そしてその後、ＩＧスイッチ４６がオンになり、ＥＶ＿ＥＣＵ４４が起動すると、ＥＶ＿ＥＣＵ４４は、図２２の処理によって上述の通りデータブロックＴａを送信し始めるが、そのデータブロックＴａ中のイグニッション状態ＩＧの値はオンになっている。

　このイグニッション状態ＩＧの値は、マスタサーバ２１、ジョブスケジューラ２２１を介して演算要求として診断プログラム２１ｅの実行主体のワーカに送信される。すると、当該実行主体は、状態ＳＩにいるとき、イグニッション状態ＩＧがオンであることを検出し、リレーオン要求を演算結果（ＳｄｐまたはＳｄｑ）としてジョブスケジューラ２２１に送信すると共に、＋Ｂオン状態ＳＤに遷移する。

　ジョブスケジューラ２２１は、当該リレーオン要求を受信すると、その後の最初のデータブロックＳｄの送信タイミングにおいて、リレーオン要求を含むデータブロックＳｄを作成し、マスタサーバ２１に送信する。マスタサーバ２１は、このリレーオン要求を含むデータブロックＳｄを車両Ｄに送信する。車両ＤのＥＶ＿ＥＣＵ４４は、このデータブロックＳｄをモデム１４、無線変換器４８を介して受信する。更にＥＶ＿ＥＣＵ４４は、その直後の図２２のループのＳ４２０で、このリレーオン要求に従って、リレー４７をオンにする。これにより、ＥＶ＿ＥＣＵ４４は、ＩＧスイッチ４６がオフになってもバッテリ４５から電力供給を受けて作動し続けられる状態になる。

　その後、イグニッション状態ＩＧがオンである場合、当該実行主体は、状態ＳＤに留まっている。車両Ｄにおいては、ＩＧスイッチ４６がオンの間、エンジンが作動して車両Ｄの走行が実現する。

　図２７の実線５１に示すように、車両Ｄにおいてエンジンが停止した後ＩＧスイッチ４６がオフになると、ＥＶ＿ＥＣＵ４４は、リレー４７を介して電力供給を受けながら作動を継続する。そしてＥＶ＿ＥＣＵ４４は、ＩＧスイッチ４６がオフになった直後の図２２のループのＳ４５０において、イグニッション状態ＩＧをオフにする。ＥＶ＿ＥＣＵ４４は更にその直後のＳ４８０で、オフの値となっているイグニッション状態ＩＧのデータを含むブロックＴａを送信する。

　このイグニッション状態ＩＧの値は、マスタサーバ２１、ジョブスケジューラ２２１を介して演算要求として診断プログラム２１ｅの実行主体のワーカに送信される。すると、当該実行主体は、状態ＳＤにいるとき、イグニッション状態ＩＧがオンからオフになったことを検出し、リークテスト未実施状態ＳＤに遷移する。リークテスト未実施状態ＳＤは、リークテストを開始する直前の状態である。このように、車両Ｄにおいてエンジンが停止してイグニッション状態ＩＧがオフになった後で、リークテストが実施される。なお、状態ＳＤから状態ＳＥに遷移した後も、ＥＶ＿ＥＣＵ４４ではリレー４７はオンのままである。

　リークテストが実施されていない状況では、第１バルブ３５は、エンジン制御に起因する要因によって開度が決まる。また、リークテストが実施されていない状況では、第２バルブ３９、第３バルブ４０は、それぞれ、全開状態、全閉状態、全閉状態である。また、リークテストが実施されていない状況では、減圧ポンプ４２は非作動状態である。

　診断プログラム２１ｅの実行主体は、状態ＳＥでは、状態ＳＥに遷移してからの経過時間が所定の時間Ｔ１１になるまで待機する。そして、経過時間が所定の時間Ｔ１１になると、Ｖ１オフ要求、Ｖ２オン要求、Ｖ３オフ要求、ポンプオン要求を演算結果としてジョブスケジューラ２２１に送信すると共に、リークテスト実施中状態ＳＦの子状態ＳＦ１に遷移する。状態ＳＦは、診断実施中の状態であり、子状態ＳＦ１が診断の第１段階の状態、子状態ＳＦ２が診断の第２段階の状態、子状態ＳＦ３が診断の第３段階の状態に相当する。

　ジョブスケジューラ２２１は、当該Ｖ１オフ要求、Ｖ２オン要求、Ｖ３オフ要求、ポンプオン要求を受信すると、その後の最初のデータブロックＳｄの送信タイミングにおいて、Ｖ１オフ要求、Ｖ２オン要求、Ｖ３オフ要求、ポンプオン要求を含むデータブロックＳｄを作成し、マスタサーバ２１に送信する。マスタサーバ２１は、このデータブロックＳｄを車両Ｄに送信する。

　車両ＤのＥＶ＿ＥＣＵ４４は、このデータブロックＳｄをモデム１４、無線変換器４８を介して受信する。更にＥＶ＿ＥＣＵ４４は、その直後の図２２のループのＳ４２０で、このデータブロックＳｄ中のＶ１オフ要求、Ｖ２オン要求、Ｖ３オフ要求、ポンプオン要求に従って、第１バルブ３５を全閉状態にし、第２バルブ３９を全開状態にし、第３バルブ４０を全開状態にし、減圧ポンプ４２を作動させる。この結果、大気圧の外気が第１大気管３８ｂ、第２大気管３８ｃを通って減圧ポンプ４２に吸引されるようになる。

　そして、診断プログラム２１ｅの実行主体は、状態ＳＦ１では、状態ＳＦ１に遷移してからの経過時間が所定の時間Ｔ１２になるまで待機する。実行主体の待機中、図２７の実線５２に示すように、圧力センサ値Ｐが低下して基準オリフィス４１の通路内径に対応した圧力付近で安定する。このとき、ＥＶ＿ＥＣＵ４４は、図２２の処理において、１秒毎に、その時点における圧力センサ値Ｐを、データブロックＴに含めて送信する。そして、この圧力センサ値Ｐの値は、マスタサーバ２１、ジョブスケジューラ２２１を介して演算要求として診断プログラム２１ｅの実行主体に送信される。

　診断プログラム２１ｅの実行主体は、状態ＳＦ１において、経過時間が所定の時間Ｔ１２になると、その時点において車両Ｄから受信した最新の圧力センサ値Ｐを、基準圧力ＰｒｅｆとしてＲＡＭに記録する。そして更に、処理Ｇ５を実行して状態ＳＦ２に遷移する。

　処理Ｇ５では、診断プログラム２１ｅの実行主体は、Ｖ３オフ要求およびポンプオフ要求を演算結果としてジョブスケジューラ２２１に送信する。

　ジョブスケジューラ２２１は、当該Ｖ３オフ要求およびポンプオフ要求を受信すると、その後の最初のデータブロックＳｄの送信タイミングにおいて、Ｖ３オフ要求およびポンプオフ要求を含むデータブロックＳｄを作成し、マスタサーバ２１に送信する。マスタサーバ２１は、このデータブロックＳｄを車両Ｄに送信する。

　車両ＤのＥＶ＿ＥＣＵ４４は、このデータブロックＳｄをモデム１４、無線変換器４８を介して受信する。更にＥＶ＿ＥＣＵ４４は、その直後の図２２のループのＳ４２０で、このデータブロックＳｄ中のＶ３オフ要求およびポンプオフ要求に従って、第３バルブ４０を全閉状態に切り替え、減圧ポンプ４２を停止させる。これにより、図２７の実線５２に示すように、圧力センサ４３が検出する圧力センサ値Ｐが大気圧の値にまで上昇する。

　処理Ｇ５では、診断プログラム２１ｅの実行主体は更に、Ｖ１オフ要求、Ｖ２オフ要求、Ｖ３オン要求、およびポンプオン要求を演算結果としてジョブスケジューラ２２１に送信する。

　ジョブスケジューラ２２１は、当該Ｖ１オフ要求、Ｖ２オフ要求、Ｖ３オン要求、ポンプオン要求を受信すると、その後の最初のデータブロックＳｄの送信タイミングにおいて、Ｖ１オフ要求、Ｖ２オフ要求、Ｖ３オン要求、ポンプオン要求を含むデータブロックＳｄを作成し、マスタサーバ２１に送信する。マスタサーバ２１は、このデータブロックＳｄを車両Ｄに送信する。

　車両ＤのＥＶ＿ＥＣＵ４４は、このデータブロックＳｄをモデム１４、無線変換器４８を介して受信する。更にＥＶ＿ＥＣＵ４４は、その直後の図２２のループのＳ４２０で、このデータブロックＳｄ中のＶ１オフ要求、Ｖ２オフ要求、Ｖ３オン要求、ポンプオン要求に従って、第１バルブ３５を全閉に維持し、第２バルブ３９を全閉に切り替え、第３バルブ４０を全開に維持する。これにより、エバポ系の内部の気体が減圧ポンプ４２によって吸引される状態になる。

　そして、診断プログラム２１ｅの実行主体は、状態ＳＦ２では、状態ＳＦ２に遷移してからの経過時間が所定の時間Ｔ１３になるまで待機する。もし、基準オリフィス４１の通路内径よりも大きい径のリーク穴がエバポ系にあれば、実行主体の待機中、圧力センサ値Ｐは低下するものの、図２７の実線５３のように、基準圧力Ｐｒｅｆより大きい値に留まる。もし、基準オリフィス４１の通路内径よりも小さい径のリーク穴がエバポ系にあるか、あるいはリーク穴がエバポ系に存在しないならば、実行主体の待機中、圧力センサ値Ｐは、図２７の実線５４のように、基準圧力Ｐｒｅｆより低い値にまで低下する。この待機中も、ＥＶ＿ＥＣＵ４４は、図２２の処理において、１秒毎に、その時点における圧力センサ値Ｐを、データブロックＴに含めて送信する。そして圧力センサ値Ｐの値は、ＥＶ＿ＥＣＵ４４からマスタサーバ２１、ジョブスケジューラ２２１を介して演算要求として診断プログラム２１ｅの実行主体に送信される。

　診断プログラム２１ｅの実行主体は、状態ＳＦ２において、経過時間が所定の時間Ｔ１３になると、その時点において車両Ｄから受信済みの最新の圧力センサ値Ｐを、圧力ＰｌｅａｋとしてＲＡＭに記録する。そして更に、状態ＳＦ３に遷移する。図２７の実線５３が実現している場合、圧力Ｐｌｅａｋ２が圧力ＰｌｅａｋとしてＲＡＭに記録される。図２７の実線５４が実現している場合、圧力Ｐｌｅａｋ１が圧力ＰｌｅａｋとしてＲＡＭに記録される。

　状態ＳＦ３では、診断プログラム２１ｅの実行主体は、ＲＡＭ中のＰｌｅａｋの値がＰｒｅｆの値よりも大きい場合、オンの値を有するエバポリーク判定を演算結果としてジョブスケジューラ２２１に送信する。そして当該実行主体は更に、リーク有り状態ＳＧに遷移する。

　また状態ＳＦ３では、診断プログラム２１ｅの実行主体は、ＲＡＭ中のＰｌｅａｋの値がＰｒｅｆの値よりも小さい場合、オフの値を有するエバポリーク判定を演算結果としてジョブスケジューラ２２１に送信する。そして当該実行主体は更に、リーク無し状態ＳＨに遷移する。

　ジョブスケジューラ２２１は、当該エバポリーク判定を受信すると、その後の最初のデータブロックＳｄの送信タイミングにおいて、当該エバポリーク判定を含むデータブロックＳｄを作成し、マスタサーバ２１に送信する。マスタサーバ２１は、このデータブロックＳｄを車両Ｄに送信する。

　車両ＤのＥＶ＿ＥＣＵ４４は、このデータブロックＳｄをモデム１４、無線変換器４８を介して受信する。更にＥＶ＿ＥＣＵ４４は、その直後の図２２のループのＳ４３０で、このデータブロックＳｄ中のエバポリーク判定の値を、フラッシュメモリに記録する。図２７の実線５３が実現した場合は、オンの値のエバポリーク判定が記録され、実線５４が実現した場合は、オフの値のエバポリーク判定が記録される。

　リーク有り状態ＳＧにおいて、診断プログラム２１ｅの実行主体は、リーク有り状態ＳＧに遷移してから所定期間が経過したことに基づいて、車両Ｄで診断結果（すなわちエバポリーク判定）が記録されたと判定し、リレーオフ要求を演算結果としてジョブスケジューラ２２１に送信すると共に、＋Ｂオフ状態ＳＩに遷移する。これにより、車両Ｄのエバポ系の診断が終了する。

　また、リーク無し状態ＳＨにおいて、診断プログラム２１ｅの実行主体は、リーク無し状態ＳＨに遷移してから所定期間が経過したことに基づいて、車両Ｄで診断結果（すなわちエバポリーク判定）が記録されたと判定し、リレーオフ要求を演算結果としてジョブスケジューラ２２１に送信すると共に、＋Ｂオフ状態ＳＩに遷移する。これにより、車両Ｄのエバポ系の診断が終了する。

　ジョブスケジューラ２２１は、リレーオフ要求を受信すると、その後の最初のデータブロックＳｄの送信タイミングにおいて、リレーオフ要求を含むデータブロックＳｄを作成し、マスタサーバ２１に送信する。マスタサーバ２１は、このデータブロックＳｄを車両Ｄに送信する。

　車両ＤのＥＶ＿ＥＣＵ４４は、このデータブロックＳｄをモデム１４、無線変換器４８を介して受信する。更にＥＶ＿ＥＣＵ４４は、その直後の図２２のループのＳ４２０で、このデータブロックＳｄ中のリレーオフ要求に従って、リレー４７をオフにする。図２７に示すように、この時点で、既にＩＧスイッチ４６はオフである。したがって、この時点でＥＶ＿ＥＣＵ４４は電力供給を受けられなくなり、停止する。

　なお、診断プログラム２１ｅの実行主体は、状態ＳＦ（すなわち、状態ＳＦ１、ＳＦ２、ＳＦ３）において、サーバ側リアルタイム性の値がＮＧである場合、状態ＳＥに遷移する。つまり、エバポ系の診断中にリアルタイム性が損なわれた場合は、診断を中止する。状態ＳＥに遷移した後は、状態ＳＥに遷移してからの経過時間が所定の時間Ｔ１１になれば、上述の通りの処理で状態ＳＦ１に遷移する。

　このように、診断プログラム２１ｅの実行主体が診断プログラム２１ｅを実行して各状態間を遷移している間も、上述の通り、１秒周期で車両Ｄからクラウド４００にデータブロックＴが送信され、１秒周期でクラウド４００から車両Ｄにデータブロックが送信される。ただし、通信の遅延等の要因により、送信されたデータがすぐに宛先に届かない場合がある。

　ここで、診断プログラム２１ｅがパラメータとして用いるサーバ側リアルタイム性について説明する。リアルタイム性とは、タイムラグＬが基準時間よりも短いことをいう。タイムラグＬは、第１処理時間、第１通信時間、第２処理時間、第２通信時間、第３処理時間の総和である。第１処理時間は、車載システム３０内の作動状態を示す状態量（例えば、圧力センサ値Ｐ、イグニッション状態ＩＧ）が車載システム３０で検出されてから送信されるまでの時間である。第２処理時間は、上記状態量が車載システム３０から送信されて診断プログラム２１ｅの実行主体で受信されるまでの時間である。第２処理時間は、当該実行主体が当該状態量を受信してから、診断プログラム２１ｅの実行において当該状態量を利用して利用結果のデータ（例えば、エバポリーク判定、リレーオン要求、Ｖ２オン要求）を生成して送信するまでの時間である。第２通信時間は、当該実行主体が当該利用結果のデータを送信してから車載システム３０が受信するまでの時間である。第３処理時間は、車載システム３０が当該当該利用結果のデータを受信してから、当該データを制御に反映するまでの時間である。

　上述の通り、エバポ系の診断にはクラウド４００がこれらアクチュエータ３５、３９、４０、４２を遠隔制御するので、リアルタイム性が無いときにこのような診断を実行するのは困難である。また、診断プログラム２１ｅは、アクチュエータ３５、３９、４０、４２を制御するための複雑な制御を記述する必要があるので、データサイズが大きくなりがちである。したがって、このような診断プログラム２１ｅをＥＶ＿ＥＣＵ４４側で実行するよりもクラウド４００側で実行することで、ＥＶ＿ＥＣＵ４４の処理負荷の低減効果およびメモリ容量の節約効果が大きい。

　本実施形態では、上記総和の時間が所定時間より短いか否かで、リアルタイム性の有無が判断される。ここで、車載システム３０内の作動状態を示す状態量は、なお、車載システム３０内の制御は、具体的には、第１バルブ３５、第２バルブ３９、第３バルブ４０、減圧ポンプ４２の制御、記憶媒体への記録等である。

　本実施形態では、診断プログラム２１ｅの処理は、基本的に複数のワーカ２２１ｐ、２２１ｑに分散されて実行されるので、処理自体に遅延が発生することはあまりない。したがって、車載システム３０からクラウド４００へのデータブロックＴの送信、および、クラウド４００から車載システム３０へのデータブロックＳの送信による遅延が共に小さければ（例えば各々０．５秒未満なら）リアルタイム性はＯＫ（良好）である。しかし、車載システム３０からクラウド４００へのデータブロックＴの送信、および、クラウド４００から車載システム３０へのデータブロックＳの送信いずれかに大きな遅延（例えば４秒）があれば、リアルタイム性はＮＧ（不良）であり、適切なエバポ系の診断が行えない可能性が高くなる。

　そこで、本実施形態では、診断プログラム２１ｅにおいては、リアルタイム性の判定結果に基づいて、上述のような作動が規定されている。すなわち、エバポ系の診断を行っている状態ＳＦにおいてリアルタイム性がＮＧならば、状態ＳＥに戻ることで、エバポ系の診断を中止する。

　次に、このようなリアルタイム性を判定するための量である車側カウント値およびクラウド側カウント値について説明する。車両ＤのＥＶ＿ＥＣＵ４４は、既に説明した通り、図２２の処理において、１秒毎に、Ｓ４７０で、車側カウント値の値を１だけ増加させ、Ｓ４８０で、当該車側カウント値を含むデータブロックＴａを送信する。そして、この車側カウント値は、マスタサーバ２１、ジョブスケジューラ２２１を介して演算要求としてカウントプログラム２１ｆの実行主体に送信される。

　カウントプログラム２１ｆの実行主体（ワーカ２２１ｐ、２２１ｑ）は、ジョブスケジューラ２２１からこのカウントプログラム２１ｆの演算要求を受信したときに、このカウントプログラム２１ｆの実行を開始し、その後継続的に実行する。

　そしてカウントプログラム２１ｆの実行主体は、カウントプログラム２１ｆの実行において、図２８に示すように、まずＳ５１０で、車側カウント値を受信するまで待ち、受信すると、Ｓ５２０に進み、直前のＳ５１０で受信した車側カウント値と同じ値をクラウド側カウント値とする。そして、当該クラウド側カウント値を演算結果としてジョブスケジューラ２２１に送信する。

　ジョブスケジューラ２２１は、当該クラウド側カウント値を受信すると、その後の最初のデータブロックＳｄの送信タイミングにおいて、当該クラウド側カウント値を含むデータブロックＳｄを作成し、マスタサーバ２１に送信する。マスタサーバ２１は、このデータブロックＳｄを車両Ｄに送信する。

　車両ＤのＥＶ＿ＥＣＵ４４は、このデータブロックＳｄをモデム１４、無線変換器４８を介して受信する。更にＥＶ＿ＥＣＵ４４は、その直後の図２２のループのＳ４６０で、このデータブロックＳｄ中のクラウド側カウント値を用いて、リアルタイム性判定を行う。

　ＥＶ＿ＥＣＵ４４は、リアルタイム性判定においては、図２９に示すように、まずＳ６１０にて、直前のＳ４１０で受信したクラウド側カウント値を現在の車側カウント値から減算した値が２未満（すなわち１または０）であるか否かを判定する。

　そして、２未満であると判定した場合６２０に進み、２以上であると判定した場合Ｓ６３０に進む。Ｓ６２０では、リアルタイム有効であると判定してＳ４６０の処理を終了する。Ｓ６３０では、リアルタイム無効であると判定してＳ４６０の処理を終了する。

　Ｓ４６０でリアルタイム無効であると判定した場合は、Ｓ４８０において、リアルタイム有効のデータをデータブロックＴに含めて送信しない。Ｓ４６０でリアルタイム有効であると判定した場合は、Ｓ４８０において、リアルタイム有効のデータをデータブロックＴａに含めて送信する。そして、このリアルタイム有効のデータは、マスタサーバ２１、ジョブスケジューラ２２１を介して演算要求としてリアルタイム性判定プログラム２１ｇの実行主体に送信される。

　ここで、リアルタイム性判定プログラム２１ｇの規定する作動について、図３０を参照して説明する。リアルタイム性判定プログラム２１ｇの実行主体（ワーカ２２１ｐ、２２１ｑ）は、ジョブスケジューラ２２１からこのリアルタイム性判定プログラム２１ｇの演算要求を受信したときに、このリアルタイム性判定プログラム２１ｇの実行を開始し、その後継続的に実行する。

　リアルタイム性判定プログラム２１ｇでは、サーバ側リアルタイム性ＮＧ状態ＳＲ、サーバ側リアルタイム性ＯＫ状態ＳＳという、２つの状態が規定されている。状態ＳＲは始状態である。

　当該実行主体は、状態ＳＲにおいて、上記リアルタイム有効のデータを受信すると、ＲＡＭ中のサーバ側リアルタイム性の値を「ＯＫ」に設定し、状態ＳＳに遷移する。また、当該実行主体は、状態ＳＳにおいて、上記リアルタイム有効のデータを２秒以上受信しないと、ＲＡＭ中のサーバ側リアルタイム性の値を「ＮＧ」に設定し、状態ＳＲに遷移する。このようにリアルタイム性判定プログラム２１ｄの実行によって設定されたサーバ側リアルタイム性の値は、上述の通り、診断プログラム２１ｅにて使用される。

　このように、本実施形態の通信システムでは、車両ＤのＥＶ＿ＥＣＵ４４が車側カウント値を１秒毎にカウントアップする。そして当該ＥＶ＿ＥＣＵ４４からマスタサーバ２１およびジョブスケジューラ２２１を介してワーカへ車側カウント値がデータブロックＴに含まれて送信される。そして、ワーカは、受信した車側カウント値と同じ値のクラウド側カウント値をデータブロックＳに含めて送信し、当該クラウド側カウント値はジョブスケジューラ２２１およびマスタサーバ２１を介して当該ＥＶ＿ＥＣＵ４４に届く。したがって、当該ＥＶ＿ＥＣＵ４４は、自機が車側カウント値を送信してから、当該車側カウント値に対する応答をクラウド４００から受信するまでの時間（すなわち、両者の通信に要する時間）に基づいて、リアルタイム性の判定を行っている。つまり、車側カウント値は、リアルタイム性の確認用のタイムデータであり、クラウド側カウント値は、当該タイムデータに対する応答である。

　そして、リアルタイム性は、この両者の通信に要する時間が、所定の範囲を、つまり、受信したクラウド側カウント値と現在の車側カウント値との差が２未満となる範囲を、超えているか否かで判定される。

　以上説明した通り、本実施形態においては、ＥＶ＿ＥＣＵ４４（制御装置の一例に相当する）は、ＥＶ＿ＥＣＵ４４と１台以上のサーバとの間の通信に要する時間が所定の基準を超えているか否か判定し、超えていない場合にのみリアルタイム有効のデータをクラウド４００に送信する。そして、クラウド４００は、リアルタイム有効のデータを過去２秒以内に受けているか否かに基づいて、リアルタイム性の有無を判定する。そしてクラウド４００は、リアルタイム性が無い場合は、状態ＳＦから状態ＳＥに遷移することで、エバポ系の診断、より具体的には、蒸発燃料のリークの有無の判定を、中止する。

　このように、ＥＶ＿ＥＣＵ４４とクラウド４００との間の通信の遅延が所定の基準を超えて大きいときに、エバポ系の診断が中止されるという形で、リアルタイム性の判定が実現されている。これにより、リアルタイム性が不良で適切なエバポ系の診断が行えない可能性が高い場合にまで、エバポ系の診断を続けることの無駄を低減できる。

　なお、本実施形態では、ワーカ２２１ｐ、２２１ｑが、診断プログラム２１ｅを実行することで、検査部あるいはデバイスの一例として機能し、リアルタイム性判定プログラム２１ｇを実行することで判定部あるいはデバイスの一例として機能する。言い換えれば、これらのプログラムは、検査部、判定部としてコンピュータ（サーバを含む）を機能させるインストラクションを含み、コンピュータ読取可能な、非遷移の記憶媒体に記録された、プログラム製品としても提供されることも可能である。

　（他の実施形態）
　（変形例１）
　上記実施形態では、空調パネル制御装置１２５が送信する車側カウント値は、直前に受信したクラウド側カウント値と値が同じになっている。しかし、必ずしもこのようにする必要はなく、車側カウント値は、直前に受信したクラウド側カウント値に対応する値であることがわかるような値であればよい。例えば、車側カウント値は、直前に受信したクラウド側カウント値に対して予め定められた演算を施した後の値であってもよい。この場合クラウド２００のワーカ２２１ｐ、２２１ｑは、リアルタイム性判定プログラム２１ｄのＳ２６０で、車側カウント値を受信した時刻とクラウド側カウント値を受信した時刻との差が２秒を超えているか否かを判定することで、リアルタイム性を判定できる。

　（変形例２）
　また、クラウド２００は、必ずしもクラウド側カウント値を送信する必要はなく、空調パネル制御装置１２５がクラウド２００に一方的に送信時刻を含む車側カウント値を送信し、クラウド２００のワーカ２２１ｐ、２２１ｑは、この車側カウント値を受信した時刻から、当該車側カウント値に含まれる送信時刻を減算した値が２秒を超えているか否かを判定することで、リアルタイム性を判定できる。

　（変形例３）
　また、クラウド２００は、クラウド側カウント値に代えて、現在時刻情報を送信するようになっていてもよい。その場合、その後のクラウド２００も車載システム１００も、クラウド側カウント値と同様に現在時刻情報を用いれば、上記実施形態と同様の効果を得ることができる。なお、クラウド２００内のカウントプログラム２１ｃの実行主体は、現在時刻情報を、自機内のカウントプログラム２１ｃ以外の処理で計測してもよいが、他の装置（例えばネットワーク上のタイムサーバ）から取得してもよい。

　（変形例４）
　上記実施形態では、クラウド２００（より具体的にはワーカ２２１ｐ、２２１ｑ。以下同じ。）が、カウントプログラム２１ｃ、リアルタイム性判定プログラム２１ｄを実行し、空調パネル制御装置１２５がカウント返送処理１２５ｃを実行するようになっている。つまり、クラウド２００から空調パネル制御装置１２５へカウント値（クラウド側カウント値）か送信され、それと同じ値のカウント値（車側カウント値）が空調パネル制御装置１２５からクラウド２００に返送され、２つのカウント値の差に基づいてクラウド２００がリアルタイム性の判定を行っている。

　しかし、必ずしもこのようになっておらずともよく、リアルタイム性の判定は空調パネル制御装置１２５で行われるようになっていてもよい。つまり、空調パネル制御装置１２５からクラウド２００へカウント値か送信され、それと同じ値のカウント値がクラウド２００から空調パネル制御装置１２５に返送され、２つのカウント値の差に基づいて空調パネル制御装置１２５がリアルタイム性の判定を行ってもよい。

　このようにするためには、例えば、クラウド２００がカウント返送処理１２５ｃを実行し、空調パネル制御装置１２５がカウントプログラム２１ｃ、リアルタイム性判定プログラム２１ｄの処理を実行するようになっていてもよい。ただしその際、各処理中でデータの送信先等については適宜修正する。また、これら処理に必要な情報は、クラウド２００と空調パネル制御装置１２５の間の通信によって互いに授受できるようにする。

　（変形例５）
　また、Ａ／Ｃ＿ＥＣＵ１１が空調パネル制御装置１２５の代わりに空調パネル制御装置１２５の機能を実現するようになっていてもよい。逆に、空調パネル制御装置１２５がＡ／Ｃ＿ＥＣＵ１１の代わりにＡ／Ｃ＿ＥＣＵ１１の機能を実現するようになっていてもよい。

　（変形例６）
　上記実施形態では、クラウド２００は複数台のサーバ２１、２２１、２２２、２２３、２２１ｐ、２２１ｑ、２２２ｐ、２２２ｑ、２２３ｐ、２２３ｑで実現されているが、１台のサーバで実現されていてもよい。つまり、クラウド２００は、どのような台数のサーバで実現されていてもよい。

　本開示は、実施例に準拠して記述されたが、本開示は当該実施例や構造に限定されるものではないと理解される。本開示は、様々な変形例や均等範囲内の変形をも包含する。加えて、様々な組み合わせや形態、さらには、それらに一要素のみ、それ以上、あるいはそれ以下、を含む他の組み合わせや形態をも、本開示の範疇や思想範囲に入るものである。

Claims

　車載装置と共に車両に搭載され、前記車載装置を診断するために必要な検査データ（Ｗ、Ｙ、Ｔ、Ｓ）を取得して送信する制御装置（１２５、４４）と、
　前記車両外に設置され、前記制御装置が送信した前記検査データを受信し、受信した前記検査データを用いて、前記車両に搭載されるアクチュエータ（２、３５、３９、４０、４２）を制御することで前記車載装置の診断を行う１台以上のサーバ（２００、４００）と、を備え、
　前記制御装置または前記１台以上のサーバは、前記制御装置と前記１台以上のサーバとの間の通信に要する時間が所定の基準を超えているか否かを判定し、
　前記１台以上のサーバは、前記通信に要する時間が前記所定の基準を超えていると判定されたことに基づいて、前記診断を中止する
　通信システム。
　前記１台以上のサーバは、確認用のデータを送信してから、当該確認用のデータに対する応答を前記制御装置から受信するまでの時間に基づいて、前記通信に要する時間が前記所定の基準を超えているか否かを判定する
　請求項１に記載の通信システム。
　前記車載装置は、車両用空調装置であり、
　前記診断は、前記車両用空調装置の冷媒不足の判定であり、
　前記アクチュエータは、前記車両用空調装置のコンプレッサ（２）である
　請求項１または２に記載の通信システム。
　前記１台以上のサーバは、前記車両用空調装置の冷媒不足を判定するため、前記コンプレッサを一時的に停止するためのオフ要求を前記制御装置に送信し、
　前記１台以上のサーバは、前記通信に要する時間が前記所定の基準を超えたことにより前記車両用空調装置の冷媒不足の判定を中止することに基づいて、前記車両用空調装置のコンプレッサを駆動するためのオン要求を前記制御装置に送信する
　請求項３に記載の通信システム。
　前記１台以上のサーバは、前記通信に要する時間が前記所定の基準を超えたことにより前記診断を中止した後、前記通信に要する時間が前記所定の基準を超えてないと判定されたことに基づいて、前記診断を行う
　請求項１ないし４のいずれか１つに記載の通信システム。
　前記制御装置は、確認用のデータを送信してから、当該確認用のデータに対する応答を前記１台以上のサーバから受信するまでの時間に基づいて、前記通信に要する時間が前記所定の基準を超えているか否かを判定する
　請求項１に記載の通信システム。
　車載装置と共に車両に搭載されて前記車載装置を診断するために必要な検査データ（Ｗ、Ｙ、Ｔ、Ｓ）を取得して送信する制御装置と通信し、前記車両外に設置される１台以上のサーバであって、
　前記制御装置が送信した前記検査データを受信し、受信した前記検査データを用いて、前記車両に搭載されるアクチュエータを制御することで前記車載装置の診断を行う検査部（２１ｂ、２１ｅ）と、
　前記制御装置と前記１台以上のサーバとの間の通信に要する時間が所定の基準を超えているか否かを判定する判定部（２１ｄ、２１ｇ）と、を備え、
　前記検査部は、前記通信に要する時間が前記所定の基準を超えていると前記判定部が判定したことに基づいて、前記診断を中止する
　１台以上のサーバ。
　車載装置と共に車両に搭載されて前記車載装置を診断するために必要な検査データ（Ｗ、Ｙ、Ｔ、Ｓ）を取得して送信する制御装置と通信し、前記車両外に設置される１台以上のサーバ用のプログラムであって、前記１台以上のサーバを、
　前記制御装置が送信した前記検査データを受信し、受信した前記検査データを用いて、前記車両に搭載されるアクチュエータを制御することで前記車載装置の診断を行う検査部（２１ｂ）、および
　前記制御装置と前記１台以上のサーバとの間の通信に要する時間が所定の基準を超えているか否かを判定する判定部（２１ｄ、２１ｇ）として機能させ、
　前記検査部は、前記通信に要する時間が前記所定の基準を超えていると前記判定部が判定したことに基づいて、前記診断を中止する
　プログラム。