(57)【特許請求の範囲】
【請求項１】
車載装置と共に車両に搭載され、前記車載装置を診断するために必要な検査データ（Ｗ、Ｙ、Ｔ、Ｓ）を取得して送信する制御装置（１２５、４４）と、
前記車両外に設置され、前記制御装置が送信した前記検査データを受信し、受信した前記検査データを用いて、前記車両に搭載されるアクチュエータ（２、３５、３９、４０、４２）を制御することで前記車載装置の診断を行う１台以上のサーバ（２００、４００）と、を備え、
前記制御装置または前記１台以上のサーバは、前記制御装置と前記１台以上のサーバとの間の通信に要する時間が所定の基準を超えているか否かを判定し、
前記１台以上のサーバは、前記通信に要する時間が前記所定の基準を超えていると判定されたことに基づいて、前記診断を中止することを特徴とする通信システム。
【請求項２】
前記１台以上のサーバは、確認用のデータを送信してから、当該確認用のデータに対する応答を前記制御装置から受信するまでの時間に基づいて、前記通信に要する時間が前記所定の基準を超えているか否かを判定することを特徴とする請求項１に記載の通信システム。
【請求項３】
前記車載装置は、車両用空調装置であり、
前記診断は、前記車両用空調装置の冷媒不足の判定であり、
前記アクチュエータは、前記車両用空調装置のコンプレッサ（２）であることを特徴とする請求項１または２に記載の通信システム。
【請求項４】
前記１台以上のサーバは、前記車両用空調装置の冷媒不足を判定するため、前記コンプレッサを一時的に停止するためのオフ要求を前記制御装置に送信し、
前記１台以上のサーバは、前記通信に要する時間が前記所定の基準を超えたことにより前記車両用空調装置の冷媒不足の判定を中止することに基づいて、前記車両用空調装置のコンプレッサを駆動するためのオン要求を前記制御装置に送信することを特徴とする請求項３に記載の通信システム。
【請求項５】
前記１台以上のサーバは、前記通信に要する時間が前記所定の基準を超えたことにより前記診断を中止した後、前記通信に要する時間が前記所定の基準を超えてないと判定されたことに基づいて、前記診断を行うことを特徴とする請求項１ないし４のいずれか１つに記載の通信システム。
【請求項６】
前記制御装置は、確認用のデータを送信してから、当該確認用のデータに対する応答を前記１台以上のサーバから受信するまでの時間に基づいて、前記通信に要する時間が前記所定の基準を超えているか否かを判定することを特徴とする請求項１に記載の通信システム。
【請求項７】
車載装置と共に車両に搭載されて前記車載装置を診断するために必要な検査データ（Ｗ、Ｙ、Ｔ、Ｓ）を取得して送信する制御装置と通信し、前記車両外に設置される１台以上のサーバであって、
前記制御装置が送信した前記検査データを受信し、受信した前記検査データを用いて、前記車両に搭載されるアクチュエータを制御することで前記車載装置の診断を行う検査手段（２１ｂ、２１ｅ）と、
前記制御装置と前記１台以上のサーバとの間の通信に要する時間が所定の基準を超えているか否かを判定する判定手段（２１ｄ、２１ｇ）と、を備え、
前記検査手段は、前記通信に要する時間が前記所定の基準を超えていると前記判定手段が判定したことに基づいて、前記診断を中止することを特徴とする１台以上のサーバ。
【請求項８】
車載装置と共に車両に搭載されて前記車載装置を診断するために必要な検査データ（Ｗ、Ｙ、Ｔ、Ｓ）を取得して送信する制御装置と通信し、前記車両外に設置される１台以上のサーバ用のプログラムであって、前記１台以上のサーバを、
前記制御装置が送信した前記検査データを受信し、受信した前記検査データを用いて、前記車両に搭載されるアクチュエータを制御することで前記車載装置の診断を行う検査手段（２１ｂ）、および
前記制御装置と前記１台以上のサーバとの間の通信に要する時間が所定の基準を超えているか否かを判定する判定手段（２１ｄ、２１ｇ）として機能させ、
前記検査手段は、前記通信に要する時間が前記所定の基準を超えていると前記判定手段が判定したことに基づいて、前記診断を中止することを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信システム、１台以上のサーバ、および１台以上のサーバ用のプログラムに関するものである。
【背景技術】
【０００２】
従来、車両用空調装置において冷媒量が不足していることを検出する技術が知られている。例えば、特許文献１に開示された技術では、車両用空調装置を制御する制御装置が、当該空調装置のコンプレッサを制御することで、当該車両用空調装置の冷媒不足を判定する。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００９−２４３７８４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかし、発明者の検討によれば、冷媒不足を判定するためのソフトウエアは、コンプレッサという車載のアクチュエータを制御する処理を記述するので、車載のアクチュエータを制御しない診断ソフトウエアに比べれば、データサイズが大きくなりがちである。したがって、特許文献１のように、冷媒不足を判定するためのソフトウエアを制御装置に追加しようとすると、制御装置のメモリ容量が比較的大きく増加してしまい、制御装置の小型化およびコストダウンの妨げになる。
【０００５】
そこで、発明者は、車両と車外のサーバ（またはサーバ群）との通信が容易になっていることに着目し、車外のサーバ（またはサーバ群）に車両用空調装置の冷媒不足判定を行わせる新技術を着想した。そして、この新技術について更に検討し、車外のサーバ（またはサーバ群）で有効に冷媒不足判定を行うには、リアルタイム性の判定が必要であると考えた。リアルタイム性の判定が必要であるのは、冷媒不足の判定に限らず、車載のアクチュエータを制御することで車載装置を診断する技術全般に当てはまることである。
【０００６】
リアルタイム性とは、ある時点における車両側の作動状態を示す量が、サーバ（またはサーバ群）に通信で送信され、サーバ（またはサーバ群）での冷媒検査の処理を経て車両内の制御として反映される作動が、予定された時刻までに定期的に行われるという性質をいう。
【０００７】
車両とサーバ（またはサーバ群）との間の通信による遅延が小さければリアルタイム性は良好である。しかし、当該遅延が大きければ、決められた時刻までの制御の反映は困難になる。即ち、リアルタイム性は不良となり、適切な診断（例えば冷媒不足判定）が行えない可能性が高くなる。ここで上記遅延は、車両側とサーバ側でデータを処理する時間と、通信に関係する時間の総和である。
【０００８】
本発明は上記点に鑑み、車外の１台以上のサーバに車載装置の診断（例えば車両用空調装置の冷媒不足判定）を行わせる技術に、リアルタイム性の判定を追加することを目的とする。
【課題を解決するための手段】
【０００９】
上記目的を達成するための請求項１に記載の発明は、車載装置と共に車両に搭載され、前記車載装置を診断するために必要な検査データ（Ｗ、Ｙ、Ｔ、Ｓ）を取得して送信する制御装置（１２５、４４）と、前記車両外に設置され、前記制御装置が送信した前記検査データを受信し、受信した前記検査データを用いて、前記車両に搭載されるアクチュエータ（２、３５、３９、４０、４２）を制御することで前記車載装置の診断を行う１台以上のサーバ（２００、４００）と、を備え、前記制御装置または前記１台以上のサーバは、前記制御装置と前記１台以上のサーバとの間の通信に要する時間が所定の基準を超えているか否かを判定し、前記１台以上のサーバは、前記通信に要する時間が前記所定の基準を超えていると判定されたことに基づいて、前記診断を中止することを特徴とする通信システムである。
【００１０】
また、請求項７に記載の発明は、車載装置と共に車両に搭載されて前記車載装置を診断するために必要な検査データ（Ｗ、Ｙ、Ｔ、Ｓ）を取得して送信する制御装置と通信し、前記車両外に設置される１台以上のサーバであって、前記制御装置が送信した前記検査データを受信し、受信した前記検査データを用いて、前記車両に搭載されるアクチュエータを制御することで前記車載装置の診断を行う検査手段（２１ｂ、２１ｅ）と、前記制御装置と前記１台以上のサーバとの間の通信に要する時間が所定の基準を超えているか否かを判定する判定手段（２１ｄ、２１ｇ）と、を備え、前記検査手段は、前記通信に要する時間が前記所定の基準を超えていると前記判定手段が判定したことに基づいて、前記診断を中止することを特徴とする１台以上のサーバである。
【００１１】
また、請求項８に記載の発明は、車載装置と共に車両に搭載されて前記車載装置を診断するために必要な検査データ（Ｗ、Ｙ、Ｔ、Ｓ）を取得して送信する制御装置と通信し、前記車両外に設置される１台以上のサーバ用のプログラムであって、前記１台以上のサーバを、前記制御装置が送信した前記検査データを受信し、受信した前記検査データを用いて、前記車両に搭載されるアクチュエータを制御することで前記車載装置の診断を行う検査手段（２１ｂ）、および前記制御装置と前記１台以上のサーバとの間の通信に要する時間が所定の基準を超えているか否かを判定する判定手段（２１ｄ、２１ｇ）として機能させ、前記検査手段は、前記通信に要する時間が前記所定の基準を超えていると前記判定手段が判定したことに基づいて、前記診断を中止することを特徴とするプログラムである。
【００１２】
このように、制御装置と１台以上のサーバとの間の通信の遅延が所定の基準を超えて大きいときに、車載装置の診断が中止されるという形で、リアルタイム性の判定が実現されている。これにより、リアルタイム性が不良で適切な診断が行えない可能性が高い場合にまで、診断を続けることの無駄を低減できる。
【００１３】
なお、上記および特許請求の範囲における括弧内の符号は、特許請求の範囲に記載された用語と後述の実施形態に記載される当該用語を例示する具体物等との対応関係を示すものである。
【図面の簡単な説明】
【００１４】
【図１】本発明の実施形態に係る通信システムの全体構成図である。
【図２】クラウド対応空調パネル１２の構成図である。
【図３】データブロックＷ、Ｘ、Ｙ、Ｚのデータ構成を示す図である。
【図４】空調パネル制御装置１２５が実行する処理の構成図である。
【図５】マニュアル状態遷移処理の内容を示す図である。
【図６】出力調停処理の内容を示す図である。
【図７】冷媒不足判定と冷媒不足表示器の表示内容との対応関係を示す図である。
【図８】クラウド２００および複数の車Ａ、Ｂ、Ｃの構成図である。
【図９】通信システムの作動例を示す通信シーケンス図である。
【図１０】空調パネル制御部が実行するカウント返送処理のフローチャートである。
【図１１】車両からワーカまでのデータの流れを示す図である。
【図１２】ワーカから車両までのデータの流れを示す図である。
【図１３】冷媒検査プログラム２１ｂの処理内容を示す状態遷移図である。
【図１４】外気温度と冷媒不足５０％検査圧力との関係を示すグラフである。
【図１５】第２判定中＿停車時状態におけるクラウド発オン要求、クラウド発オフ要求の値の制御内容を示すグラフである。
【図１６】カウントプログラム２１ｃのフローチャートである。
【図１７】リアルタイム性判定プログラム２１ｄのフローチャートである。
【図１８】車載システム１００およびクラウド２００の機能構成を示す図である。
【図１９】車載システム１００およびクラウド２００の機能構成を示す図である。
【図２０】車両側とクラウド４００のデータのやり取り形態を示す図である。
【図２１】データブロックＴ、Ｓの構成を示す図である。
【図２２】ＥＶ＿ＥＣＵが実行する処理のフローチャートである。
【図２３】クラウド４００および複数の車Ｄ、Ｅ、Ｆの構成図である。
【図２４】車両からワーカまでのデータの流れを示す図である。
【図２５】ワーカから車両までのデータの流れを示す図である。
【図２６】診断プログラム２１ｅの処理内容を示す状態遷移図である。
【図２７】診断時における圧力センサ値Ｐの変化等を示すグラフである。
【図２８】カウントプログラム２１ｆのフローチャートである。
【図２９】リアルタイム性判定処理のフローチャートである。
【図３０】リアルタイム性判定プログラム２１ｇの状態遷移図である。
【発明を実施するための形態】
【００１５】
（第１実施形態）
以下、第１実施形態について説明する。図１に示すように、本実施形態の通信システムは、車両に搭載された車載システム１００、および、車両外の遠隔地に設置されて車載システム１００と通信するクラウド２００（１台以上のサーバの一例に相当する）を備えている。
【００１６】
車載システム１００は、エンジン１、コンプレッサ２、コンデンサー３、膨張弁４、エバポレータ５、Ａ／Ｃマグネットクラッチ６、水温センサ７、冷媒圧力センサ８、エバポレータフィン温度センサ９、車速センサ１０、Ａ／Ｃ＿ＥＣＵ１１、クラウド対応空調パネル１２、無線変換器１３を含んでいる。
【００１７】
エンジン１は、車載システム１００の搭載先の車両を走行させる駆動力を発生する周知の機関である。コンプレッサ２、コンデンサー３、膨張弁４、エバポレータ５は、車室内へ送風される送風空気の温度を調整するための周知の冷凍サイクルを構成する。また、コンプレッサ２、コンデンサー３、膨張弁４、エバポレータ５、Ａ／Ｃマグネットクラッチ６、冷媒圧力センサ８、エバポレータフィン温度センサ９、Ａ／Ｃ＿ＥＣＵ１１が、周知の車両用空調装置（車載装置の一例に相当する）を構成する。
【００１８】
コンプレッサ２は、冷媒を吸入し圧縮して吐出するアクチュエータで、Ａ／Ｃマグネットクラッチ６を介してエンジン１から動力を得て作動する。Ａ／Ｃマグネットクラッチ６によるエンジン１からコンプレッサ２への動力の伝達は、Ａ／Ｃ＿ＥＣＵ１７からＡ／Ｃマグネットクラッチ６に７出力されるコンプレッサ駆動要求ＣＭＰによって制御される。
【００１９】
コンプレッサ２の吐出側には、冷媒を凝縮させるコンデンサー３の冷媒入口側が接続されている。コンデンサー３の冷媒出口側には、冷媒を減圧膨張させる膨張弁４の冷媒入口側が接続されている。
【００２０】
膨張弁４の冷媒出口側には、エバポレータ５の冷媒入口側が接続されている。エバポレータ５は、室内空調ユニットのケーシング内に配置されて、エバポレータ５の内部を流通する冷媒とケーシング内を通過して送風空気とを熱交換させて送風空気を冷却する。冷却された送風空気は、車室内に流入する。エバポレータ５の冷媒出口側には、コンプレッサ２の冷媒吸入側が接続されている。
【００２１】
水温センサ７は、エンジン１の冷却水の温度ＴＨＷを検出するセンサである。冷媒圧力センサ８は、コンプレッサ２の冷媒吐出側とコンデンサー３の冷媒入口側の間の冷媒の圧力ＰＲＥを検出するセンサである。エバポレータフィン温度センサ９は、エバポレータ５の外表面（フィン）の温度ＴＥｆｉｎを検出するセンサである。車速センサ１０は、車載システム１００の搭載先の車両の走行速度ＳＰＤを検出するセンサである。
【００２２】
Ａ／Ｃ＿ＥＣＵ１１は、車両のイグニッション状態ＩＧを取得し、また、上記センサ７〜１０から検出信号（ＴＨＷ、ＰＲＥ、ＴＥｆｉｎ、ＳＰＤ）を取得し、またクラウド対応空調パネル１２から後述するデータブロックＸを取得する。そしてＡ／Ｃ＿ＥＣＵ１１は、これら取得した信号およびデータに基づいて、クラウド対応空調パネル１２と通信を行い、コンプレッサ駆動要求ＣＭＰのオン、オフ等を制御する。Ａ／Ｃ＿ＥＣＵ１１は、その他にも、上記冷凍サイクルを利用して車室内の温度等を調整する周知の空調制御を行う。Ａ／Ｃ＿ＥＣＵ１１は、例えば周知のマイクロコンピュータで実現可能である。
【００２３】
クラウド対応空調パネル１２は、車両のダッシュボード中央の車室側表面部に配置されており、車両の乗員が操作可能な複数のスイッチ１２１、１２２および車両の乗員が視認可能なインジケータ１２３、１２４を含んでいる。
【００２４】
図２に示すように、クラウド対応空調パネル１２は、上述のＡ／Ｃスイッチ１２１、ＯＦＦスイッチ１２２、Ａ／Ｃ表示器１２３、冷媒不足表示器１２４に加え、空調パネル制御装置１２５を有している。
【００２５】
Ａ／Ｃスイッチ１２１およびＯＦＦスイッチ１２２は、車両の乗員によって押下される部材であり、空調パネル制御装置１２５はスイッチ１２１、１２２各々に対する押下の有無を検出することができる。
【００２６】
Ａ／Ｃ表示器１２３は、コンプレッサ２が作動していることを乗員に通知するためのＬＥＤであり、空調パネル制御装置１２５の制御に従って点灯、消灯が切り替わる。冷媒不足表示器１２４は、車両用空調装置の冷凍サイクルの冷媒が不足していることを乗員に通知するためのＬＥＤであり、空調パネル制御装置１２５の制御に従って点灯、消灯が切り替わる。
【００２７】
空調パネル制御装置１２５は、表示器１２３、１２４の点灯、消灯等を制御するコンピュータである。空調パネル制御装置１２５は、車内ＬＡＮ１５（例えばＣＡＮ）を介してＡ／Ｃ＿ＥＣＵ１１からデータブロックＷを受信すると共にデータブロックＸをＡ／Ｃ＿ＥＣＵ１１に送信する。また空調パネル制御装置１２５は、通信処理１２５ｄを実行することで、車内通信線１６（例えばシリアル通信線）を介して無線変換器１３からデータブロックＺを受信すると共にデータブロックＹを無線変換器１３に送信する。
【００２８】
図３に示す通り、データブロックＷは、イグニッション状態ＩＧ、車速ＳＰＤ、冷却水温度ＴＨＷ、エバポレータフィン温度ＴＥｆｉｎ、冷媒圧力ＰＲＥを含んでいる。これらデータは、車両用空調装置の冷媒不足を判定するために必要な冷媒検査データを構成する。Ａ／Ｃ＿ＥＣＵ１１は、繰り返し定期的に（具体的には１秒周期で）、イグニッション状態ＩＧ、車速ＳＰＤ、冷却水温度ＴＨＷ、エバポレータフィン温度ＴＥｆｉｎ、冷媒圧力ＰＲＥの最新値を含むデータブロックＷを、車内通信線１６を介して空調パネル制御装置１２５に送信する。
【００２９】
データブロックＸは、コンプレッサ駆動要求ＣＭＰを含んでいる。空調パネル制御装置１２５は、繰り返し、定期的に（例えば１秒毎に）、最新のコンプレッサ駆動要求ＣＭＰ
を含むデータブロックＸを、Ａ／Ｃ＿ＥＣＵ１１に送信する。そしてＡ／Ｃ＿ＥＣＵ１１は、受信したコンプレッサ駆動要求ＣＭＰをＡ／Ｃマグネットクラッチ６に出力することで、コンプレッサ２の作動、非作動を制御する。
【００３０】
データブロックＹは、上述のデータＩＧ、ＳＰＤ、ＴＨＷ、ＴＥｆｉｎ、ＰＲＥに加え、ＯＦＦスイッチ１２２の押下の有無を示すデータＯＦＦ、マニュアルオン要求ＭＯＮ、マニュアルオフ要求ＭＯＦＦ、および、後述する車側カウント値（車側リアルタイム性確認カウント値）を含む。これらは、車両用空調装置の冷媒不足を判定するために必要な冷媒検査データを構成する。空調パネル制御装置１２５は、繰り返し定期的に（具体的には１秒周期で）、上記データＩＧ、ＳＰＤ、ＴＨＷ、ＴＥｆｉｎ、ＰＲＥ、データＯＦＦ、車側カウント値の最新値を含むデータブロックＹを、車内通信線１６を介して無線変換器１３に送信する。また、マニュアルオン要求ＭＯＮおよびマニュアルオフ要求ＭＯＦＦは、特定の条件が満たされたときにのみ空調パネル制御装置１２５によってデータブロックＹに含まれて送信される所謂イベントデータである。
【００３１】
なお、本実施形態において、イベントデータであると明示するデータ以外は、所謂レベルデータである。レベルデータは毎周期送信されるのに対し、イベントデータは特定の条件が満たされたときにのみ送信される。
【００３２】
無線変換器１３は、空調パネル制御装置１２５から受信した上記データブロックＹに自機のアドレス（例えばＭＡＣアドレス）を付加し（図３参照）、自機のアドレスが付加されたデータブロックＹの情報を含む無線信号を、周知の無線通信方式（例えば無線ＬＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標））により、モデム１４に送信する。
【００３３】
モデム１４は、例えば携帯電話機等の装置であり、車両の乗員に携帯されて車室内に持ち込まれ、無線変換器１３および車外に設置されたサーバ群であるクラウド２００と通信可能になる装置である。モデム１４は、無線変換器１３から受信した上記データブロックＹを、クラウド２００に送信する。モデム１４とクラウド２００は、例えばインターネット等の広域ネットワークを介して通信する。
【００３４】
またモデム１４は、クラウド２００から繰り返しデータブロックＺを受信する。データブロックＺは、図３に示す通り、冷媒不足判定、クラウド発オン要求、クラウド発オフ要求、クラウド側カウント値という４つのデータを含んでいる。クラウド発オン要求（リモート要求の一例に相当する）は、冷媒不足判定のためにクラウド２００側からコンプレッサ２の作動開始が要求されたことを示すイベントデータである。クラウド発オフ要求（リモート要求の一例に相当する）は、冷媒不足判定のためにクラウド２００側からコンプレッサ２の作動停止が要求されたことを示すイベントデータである。クラウド側カウント値については後述する。
【００３５】
クラウド２００は、繰り返し、定期的に具体的には１秒周期で、最新の冷媒不足判定、クラウド側カウント値を含むデータブロックＺを、モデム１４に送信する。また、イベントデータであるクラウド発オン要求およびクラウド発オフ要求については、特定の条件が満たされた場合にのみ、上記データブロックＺに含める。モデム１４は、受信したデータブロックＺを無線変換器１３に送信し、無線変換器１３は受信したデータブロックＺを空調パネル制御装置１２５に送信する。
【００３６】
ここで、空調パネル制御装置１２５の作動について、図４〜図７を参照して説明する。図２、４に示すように、空調パネル制御装置１２５は、マニュアル状態遷移処理１２５ａと出力調停処理１２５ｂ、カウント返送処理１２５ｃ、通信処理１２５ｄを同時並行的に実行するようになっている。
【００３７】
マニュアル状態遷移処理１２５ａは、図３に示すように、出力調停処理１２５ｂから出力されるＡ／Ｃ表示器１２３の点灯時、消灯時の各々においてＡ／Ｃスイッチ１２１が押下された場合の、マニュアルオン要求ＭＯＮおよびマニュアルオフ要求ＭＯＦＦの生成の有無を決定する処理である。マニュアルオン要求ＭＯＮは、乗員が手動でコンプレッサの作動開始を要求したことを示すイベントデータであり、マニュアルオフ要求ＭＯＦＦは、乗員が手動でコンプレッサの作動停止を要求したことを示すイベントデータである。
【００３８】
具体的には、空調パネル制御装置１２５は、マニュアル状態遷移処理１２５ａにおいて、Ａ／Ｃ表示器１２３が消灯しているときにＡ／Ｃスイッチ１２１が押下された場合にはマニュアルオン要求ＭＯＮを生成する。また、Ａ／Ｃ表示器１２３が点灯しているときにＡ／Ｃスイッチ１２１が押下された場合にはマニュアルオフ要求ＭＯＦＦを生成する。生成されたマニュアルオン要求ＭＯＮまたはマニュアルオフ要求ＭＯＦＦは、生成される度に、マニュアル状態遷移処理１２５ａから出力調停処理１２５ｂに一度だけ渡されると共に、次に送信されるデータブロックＹに含まれる。
【００３９】
出力調停処理１２５ｂは、Ａ／Ｃ表示器１２３を点灯させるか否か、コンプレッサ駆動要求ＣＭＰを含むデータブロックＸをＡ／Ｃ＿ＥＣＵ１１に出力するか否かを決定する処理である。
【００４０】
決定は、マニュアルオン要求ＭＯＮ、マニュアルオフ要求ＭＯＦＦの有無に基づいて行われる。また、決定は、最新のデータブロックＺ中のクラウド発オン要求、クラウド発オフ要求の有無に基づいて行われる。クラウド発オン要求およびクラウド発オフ要求もイベントデータである。
【００４１】
出力調停処理１２５ｂにおける空調パネル制御装置１２５の作動は、具体的には図６の通りである。例えば、Ａ／Ｃ表示器１２３を消灯させており、かつ、最後にＡ／Ｃ＿ＥＣＵ１１に送信したコンプレッサ駆動要求ＣＭＰの値がオフであった場合について説明する。この場合に、マニュアル状態遷移処理１２５ａからマニュアルオン要求ＭＯＮが渡されると、Ａ／Ｃ表示器１２３を点灯すると共に、オンの値のコンプレッサ駆動要求ＣＭＰを含むデータブロックＸをＡ／Ｃ＿ＥＣＵ１１に出力する。
【００４２】
また例えば、Ａ／Ｃ表示器１２３を点灯させており、かつ、最後にＡ／Ｃ＿ＥＣＵ１１に送信したコンプレッサ駆動要求ＣＭＰの値がオンであった場合について説明する。この場合に、マニュアル状態遷移処理１２５ａからマニュアルオフ要求ＭＯＦＦが渡されると、Ａ／Ｃ表示器１２３を消灯すると共に、オフの値のコンプレッサ駆動要求ＣＭＰを含むデータブロックＸをＡ／Ｃ＿ＥＣＵ１１に出力する。
【００４３】
また例えば、Ａ／Ｃ表示器１２３を消灯させており、かつ、最後にＡ／Ｃ＿ＥＣＵ１１に送信したコンプレッサ駆動要求ＣＭＰの値がオンであった場合について説明する。この場合に、マニュアル状態遷移処理１２５ａからマニュアルオン要求ＭＯＮが渡されると、Ａ／Ｃ表示器１２３を点灯させると共に、オンの値のコンプレッサ駆動要求ＣＭＰを含むデータブロックＸをＡ／Ｃ＿ＥＣＵ１１に出力する。
【００４４】
また例えば、Ａ／Ｃ表示器１２３を点灯させており、かつ、最後にＡ／Ｃ＿ＥＣＵ１１に送信したコンプレッサ駆動要求ＣＭＰの値がオフであった場合について説明する。この場合に、マニュアル状態遷移処理１２５ａからマニュアルオン要求ＭＯＮが渡されると、Ａ／Ｃ表示器１２３を消灯させると共に、オンの値のコンプレッサ駆動要求ＣＭＰを含むデータブロックＸをＡ／Ｃ＿ＥＣＵ１１に出力する。
【００４５】
また例えば、Ａ／Ｃ表示器１２３を消灯させており、かつ、最後にＡ／Ｃ＿ＥＣＵ１１に送信したコンプレッサ駆動要求ＣＭＰの値がオフであった場合について説明する。この場合に、新たに受信したデータブロックＺにクラウド発オン要求が含まれていると、Ａ／Ｃ表示器１２３を消灯のままにすると共に、オンの値のコンプレッサ駆動要求ＣＭＰを含むデータブロックＸをＡ／Ｃ＿ＥＣＵ１１に出力する。これにより、Ａ／Ｃ＿ＥＣＵ１１は直ちにオンの値のコンプレッサ駆動要求ＣＭＰをＡ／Ｃマグネットクラッチ６に出力するので、コンプレッサ２が冷媒不足判定のための作動を開始する。このときにＡ／Ｃ表示器１２３を消灯のままにするのは、冷媒不足判定のために一時的にコンプレッサ２を作動させるのを乗員に知らせる必要は必ずしも無いという観点からである。
【００４６】
また例えば、Ａ／Ｃ表示器１２３を点灯させており、かつ、最後にＡ／Ｃ＿ＥＣＵ１１に送信したコンプレッサ駆動要求ＣＭＰの値がオンであった場合について説明する。この場合に、新たに受信したデータブロックＺにクラウド発オフ要求が含まれていると、Ａ／Ｃ表示器１２３を点灯のままにすると共に、オフの値のコンプレッサ駆動要求ＣＭＰを含むデータブロックＸをＡ／Ｃ＿ＥＣＵ１１に出力する。これにより、Ａ／Ｃ＿ＥＣＵ１１は直ちにオフの値のコンプレッサ駆動要求ＣＭＰをＡ／Ｃマグネットクラッチ６に出力するので、コンプレッサ２による冷媒不足判定のための作動が停止する。このときにＡ／Ｃ表示器１２３を点灯のままにするのは、冷媒不足判定のために一時的にコンプレッサ２を停止させるのを乗員に知らせる必要は必ずしも無いという観点からである。
【００４７】
また例えば、Ａ／Ｃ表示器１２３を消灯させており、かつ、最後にＡ／Ｃ＿ＥＣＵ１１に送信したコンプレッサ駆動要求ＣＭＰの値がオンであった場合、すなわち、冷媒不足判定のために一時的にコンプレッサ２が作動している場合について説明する。この場合に、新たに受信したデータブロックＺにクラウド発オン要求が含まれていると、Ａ／Ｃ表示器１２３を消灯のままにすると共に、オンの値のコンプレッサ駆動要求ＣＭＰを含むデータブロックＸをＡ／Ｃ＿ＥＣＵ１１に出力する。これにより、Ａ／Ｃ＿ＥＣＵ１１は直ちにオンの値のコンプレッサ駆動要求ＣＭＰをＡ／Ｃマグネットクラッチ６に出力するので、コンプレッサ２による冷媒不足判定のための作動が継続する。
【００４８】
また例えば、Ａ／Ｃ表示器１２３を点灯させており、かつ、最後にＡ／Ｃ＿ＥＣＵ１１に送信したコンプレッサ駆動要求ＣＭＰの値がオフであった場合、すなわち、冷媒不足判定のために一時的にコンプレッサ２が停止している場合について説明する。この場合に、新たに受信したデータブロックＺにクラウド発オフ要求が含まれていると、Ａ／Ｃ表示器１２３を点灯のままにすると共に、オフの値のコンプレッサ駆動要求ＣＭＰを含むデータブロックＸをＡ／Ｃ＿ＥＣＵ１１に出力する。これにより、Ａ／Ｃ＿ＥＣＵ１１は直ちにオフの値のコンプレッサ駆動要求ＣＭＰをＡ／Ｃマグネットクラッチ６に出力するので、コンプレッサ２の停止が継続する。
【００４９】
また、空調パネル制御装置１２５は、出力調停処理１２５ｂにおいて更に、図７に示すように、冷媒不足表示器１２４の点灯、消灯を、データブロックＺに含まれる最新の冷媒不足判定に基づいて制御する。具体的には、最新の冷媒不足判定の値が「未判定」なら、冷媒不足表示器１２４を継続的に点灯状態に維持し、値が「冷媒不足無し」なら、冷媒不足表示器１２４を消灯させ、値が「冷媒不足有り」なら、冷媒不足表示器１２４を点滅させる。
【００５０】
次に、クラウド２００の構成について説明する。クラウド２００は、図８に示すように、マスタサーバ２１とスレーブサーバ群２２を含んでいる。スレーブサーバ群２２は、複数のジョブスケジューラ２２１、２２２、２２３を含んでいる。スレーブサーバ群２２は更に、ジョブスケジューラ２２１によって管理される複数のワーカ２２１ｐ、２２１ｑ、ジョブスケジューラ２２２によって管理される複数のワーカ２２２ｐ、２２２ｑ、および、ジョブスケジューラ２２３によって管理される複数のワーカ２２３ｐ、２２３ｑを有している。
【００５１】
また、図１に示した車載システム１００およびモデム１４は、複数の車両Ａ、Ｂ、Ｃの各々に搭載され、それぞれの車載システム１００のクラウド対応空調パネル１２が、同じ車両に搭載された無線変換器１３、モデム１４を介して、マスタサーバ２１と通信する。
【００５２】
これらサーバ２１、２２１、２２２、２２３、２２１ｐ、２２１ｑ、２２２ｐ、２２２ｑ、２２３ｐ、２２３ｑは、それぞれ、互いに通信可能な別個のパーソナルコンピュータ（またはワークステーション）として実現されていてもよい。あるいは、これらサーバのうち一部の複数個は同じ１つのパーソナルコンピュータ（またはワークステーション）において実現されていてもよい。これらサーバを実現する複数個のパーソナルコンピュータ（またはワークステーション）のハードウェア構成については周知であるから、ここでは説明を省略する。
【００５３】
マスタサーバ２１は、演算指示処理２１ａを実行するようになっていると共に、図示しない記憶媒体を有し、当該記憶媒体に冷媒検査プログラム２１ｂ、カウントプログラム２１ｃ、リアルタイム性判定プログラム２１ｄが記録されている。
【００５４】
図９に、図８に示した構成の通信システムにおけるデータのやりとりの手順を例示する。この図を参照して、通信システム全体の作動について説明する。なお、以下に説明するマスタサーバ２１の作動は、すべて、マスタサーバ２１が演算指示処理２１ａを実行することによって実現する作動である。
【００５５】
まず、車両Ａにおいて車両のイグニッション（または車両の主電源）がオンになると、Ａ／Ｃ＿ＥＣＵ１１は、イグニッション状態ＩＧのデータをオフからオンに更新する。その後、最初に訪れるデータブロックＷの送信タイミングにおいて、Ａ／Ｃ＿ＥＣＵ１１は、イグニッション状態ＩＧ、車速ＳＰＤ、冷却水温度ＴＨＷ、エバポレータフィン温度ＴＥｆｉｎ、冷媒圧力ＰＲＥの最新値を含むデータブロックＷを、車内通信線１６を介して空調パネル制御装置１２５に送信する（通信３０１）。
【００５６】
空調パネル制御装置１２５は、このデータブロックＷを受信した後に最初に訪れるデータブロックＹの送信タイミングにおいて、当該データブロックＷに含まれるデータＩＧ、ＳＰＤ、ＴＨＷ、ＴＥｆｉｎ、ＰＲＥを、送信用のデータブロックＹに含める。
【００５７】
また空調パネル制御装置１２５は、マニュアルオン要求ＭＯＮまたはマニュアルオフ要求ＭＯＦＦが生成されていれば、それも今回の送信用のデータブロックＹに含める。し
かし、車両のイグニッションがオンになってからマスタサーバ２１から制御準備完了の通知を受信していないので、そのことに基づき、今回のデータブロックＹには、データＯＦＦ、車側カウント値を含めない。そして空調パネル制御装置１２５は、このデータブロックＹを、無線変換器１３、モデム１４を介してマスタサーバ２１に送信する（通信３０３）。この際、無線変換器１３が、データブロックＹに対して自機のアドレスを付加する。なお図９では、このデータブロックＹが車両Ａからのものであることを明示するため、Ｙａと記している。
【００５８】
このデータブロックＹａを受信したマスタサーバ２１は、受信したデータブロックＹａに含まれるデータＩＧの値がオンであり、かつ、当該データブロックＹａに含まれるアドレスから前回送信されたデータブロックＹに含まれるデータＩＧの値がオフであったことに基づいて、複数のジョブスケジューラから１つのジョブスケジューラ２２１を車両Ａ用として選択し、選択した車両Ａ用のジョブスケジューラ２２１に対し、冷媒検査プログラム２１ｂ、カウントプログラム２１ｃ、リアルタイム性判定プログラム２１ｄを送信する（通信３０５）。
【００５９】
ジョブスケジューラ２２１は、これらプログラム２１ｂ、２１ｃ、２１ｄを受信すると、制御準備完了の通知を、マスタサーバ２１に送信する（通信３０７）。マスタサーバ２１は、この制御準備完了の通知を、上記アドレス（車両Ａの無線変換器１３のアドレス）に送信する（通信３０９）。車両ＡのＡ／Ｃ＿ＥＣＵ１１は、モデム１４、無線変換器１３を介してこの制御準備完了の通知を受信する。この通知を受信した空調パネル制御装置１２５は、図１０に示すカウント返送処理１２５ｃの実行を開始する。これによって、車両Ａの車両用空調装置の冷凍サイクルにおける冷媒不足判定の準備が完了する。
【００６０】
その後は、車両ＡのＡ／Ｃ＿ＥＣＵ１１が、次に訪れる定期的なデータブロックＷの送信タイミングにおいて、データＩＧ、ＳＰＤ、ＴＨＷ、ＴＥｆｉｎ、ＰＲＥの最新値を含むデータブロックＷを車両Ａの空調パネル制御装置１２５に送信する（通信３１１）。
【００６１】
すると当該空調パネル制御装置１２５は、このデータブロックＷを受信し、その後に最初に訪れるデータブロックＹの送信タイミングにおいて、当該データブロックＷに含まれるデータＩＧ、ＳＰＤ、ＴＨＷ、ＴＥｆｉｎ、ＰＲＥを、送信用のデータブロックＹに含める。
【００６２】
また空調パネル制御装置１２５は、前回のデータブロックＹを送信して以降にマニュアルオン要求ＭＯＮまたはマニュアルオフ要求ＭＯＦＦが生成されていれば、それも今回の送信用のデータブロックＹに含める。
【００６３】
また空調パネル制御装置１２５は、制御準備完了の通知を既に受けていることに基づいて、ＯＦＦスイッチ１２２の押下の有無を示すデータＯＦＦをデータブロックＹに含める。また空調パネル制御装置１２５は、図１０の処理において、ステップＳ１１０で、クラウド側カウント値を新たに受信していないと判定することで、ステップＳ１２０を実行せずステップＳ１１０を繰り返す。したがって、車側カウント値はデータブロックＹに含まれない。
【００６４】
空調パネル制御装置１２５は、このようなデータブロックＹ（図９ではＹａと記す）を、無線変換器１３、モデム１４を介してマスタサーバ２１に送信する（通信３１３）。この際、無線変換器１３が、データブロックＹに対して自機のアドレスを付加する。
【００６５】
なお、ＩＧが既にオンとなっている車両Ｂ、Ｃにおいても、マスタサーバ２１に対して同様の構成のデータブロックＹ（図９中ではＹｂ、Ｙｃと記す）をマスタサーバ２１に送信する（通信３１５、３１７）ただし、データブロックＹｂ、Ｙｃには、車側カウント値が含まれている場合もある。なお、図示していないが、マスタサーバ２１は、複数のジョブスケジューラからョブスケジューラ２２２、２２３をそれぞれ車両Ｂ用、車両Ｃ用として選択し、選択したジョブスケジューラ２２２、２２３に対し、冷媒検査プログラム２１ｂ、カウントプログラム２１ｃ、リアルタイム性判定プログラム２１ｄを送信している。
【００６６】
上記のデータブロックＹａを受信したマスタサーバ２１は、データブロックＹａを含むジョブ要求通信をジョブスケジューラ２２１に送信する（通信３１９）。このジョブ要求通信を受信したジョブスケジューラ２２１は、このジョブ要求通信に含まれるデータブロックＹａの内容と、プログラム２１ｂ、２１ｃ、２１ｄの処理内容に基づいて、プログラム２１ｂ、２１ｃ、２１ｄが規定する処理を、自機が管理する複数のワーカ２２１ｐ、２２１ｑに分散して実行させる。このため、ジョブスケジューラ２２１は、自機が管理する複数のワーカ２２１ｐ、２２１ｑの各々に対して、必要な演算要求Ｙａｐ、Ｙａｑを送信する（通信３２１）。この演算要求Ｙａｐ、Ｙａｑには、ワーカ２２１ｐ、２２１ｑの各々で行うべき処理の内容およびその処理に必要なデータ（最新のデータブロックＹａの内容等）が含まれている。
【００６７】
このように、車両Ａに関して行うべきプログラム２１ｂ、２１ｃ、２１ｄの処理が、ジョブスケジューラ２２１によって適宜複数のワーカ２２１ｐ、２２１ｑに分散して割り当てられるので、個々のワーカの処理負荷が軽減される。このような分散処理の技術は周知であるが、例えば、マイクロソフト（登録商標）社のＷｉｎｄｏｗｓ＿ＨＰＣ＿Ｓｅｒｖｅｒ（Ｗｉｎｄｏｗｓは登録商標）の技術を用いてもよいし、あるいは、Ｍａｔｈｗｏｒｋｓ（登録商標）社のＰａｒａｌｌｅｌ  Ｃｏｍｐｕｔｉｎｇ  Ｔｏｏｌｂｏｘの技術を用いてもよい。
【００６８】
図１１に、上記のような車両Ａからワーカ２２１ｐ、２２１ｑまでのデータの流れを示す。車両Ｂおよびクラウド２００については、車両Ａおよびクラウド２００と同様の作動で、マスタサーバ２１、ジョブスケジューラ２２２、ワーカ２２２ｐ、ワーカ２２２ｑと通信を行う。車両Ｃおよびクラウド２００についても、車両Ａおよびクラウド２００と同様の作動で、マスタサーバ２１、ジョブスケジューラ２２３、ワーカ２２３ｐ、ワーカ２２３ｑと通信を行う。
【００６９】
また、ワーカ２２１ｐ、２２１ｑは、それぞれ、ジョブスケジューラ２２１からの演算要求Ｙａｐ、Ｙａｑに従った作動を行い、その作動の結果得た、演算結果Ｚａｐ、Ｚａｑをジョブスケジューラ２２１に送信する（通信３２３）。冷媒不足判定、クラウド発オン要求、クラウド発オフ要求、クラウド側カウント値は、演算結果Ｚａｐ、Ｚａｑのいずれかに含まれている。その他にも、リアルタイム性の値（ＮＧ、ＯＫ）、および演算時に使用する各種変数が、演算結果Ｚａｐ、Ｚａｑに含まれている。
【００７０】
演算結果Ｚａｐ、Ｚａｑを受信したジョブスケジューラ２２１は、直ちに（すなわち、１秒よりも十分短い遅延で）、これら演算結果を、自機が管理する複数のワーカ２２１ｐ、２２１ｑの各々に送信する。このようにすることで、同じジョブスケジューラ２２１に管理される複数のワーカ２２１ｐ、２２１ｑ間で、各種データの値が整合する。
【００７１】
また、ジョブスケジューラ２２１は、受信済みの最新の演算結果Ｚａｐ、Ｚａｑから冷媒不足判定、（あれば）クラウド発オン要求、（あれば）クラウド発オフ要求、クラウド側カウント値を抽出してデータブロックＺ（図９中ではＺａと記載）を生成し、このデータブロックＺａを含むジョブ結果通信を、繰り返し定期的に（具体的には１秒周期で）マスタサーバ２１に送信する（通信３２５）。
【００７２】
このジョブ結果通信を受信したマスタサーバ２１は、直ちに当該ジョブ結果通信中に含まれるデータブロックＺａを車両Ａに送信する（通信３２７）。したがって、マスタサーバ２１から車両ＡへのデータブロックＺａの送信も、繰り返し定期的に（具体的にはＴ１＝１秒周期で）行われる。
【００７３】
車両Ａでは、クラウド対応空調パネル１２が、モデム１４および無線変換器１３を介してこのデータブロックＺａを受信する。そして空調パネル制御装置１２５は、出力調停処理１２５ｂにおいて、受信したデータブロックＺａに含まれる冷媒不足判定の値に基づいて、図７に示したように、冷媒不足表示器１２４の点灯、消灯、点滅を制御する。
【００７４】
また空調パネル制御装置１２５は、出力調停処理１２５ｂにおいて、クラウド発オン要求およびクラウド発オフ要求の各々が受信したデータブロックＺａに含まれているか否かに基づいて、図６に示したように、Ａ／Ｃ表示器１２３の点灯、消灯を制御し、コンプレッサ駆動要求ＣＭＰの値（オン、オフ）を決定する。そして決定したコンプレッサ駆動要求ＣＭＰの値を、データブロックＸに含めてＡ／Ｃ＿ＥＣＵ１１に送信する（通信３２９）。Ａ／Ｃ＿ＥＣＵ１１は、クラウド対応空調パネル１２から受信したこのデータブロックＸ中のコンプレッサ駆動要求ＣＭＰを、Ａ／Ｃマグネットクラッチ６に出力することで、コンプレッサ２の作動を制御する。
【００７５】
また、ジョブスケジューラ２２２、ワーカ２２２ｐ、ワーカ２２２ｑも同様の処理を行うので、マスタサーバ２１から車両ＢへのデータブロックＺｂの送信（通信３３１）も、繰り返し定期的に（具体的にはＴ１＝１秒周期で）行われる。また、ジョブスケジューラ２２３、ワーカ２２３ｐ、ワーカ２２３ｑも同様の処理を行うので、マスタサーバ２１から車両ＣへのデータブロックＺｃの送信（通信３３３）も、繰り返し定期的に（具体的にはＴ１＝１秒周期で）行われる。
【００７６】
図１２に、上記のようなワーカ２２１ｐ、２２１ｑから車両Ａまでのデータの流れを示す。車両Ｂおよびクラウド２００については、車両Ａおよびクラウド２００と同様の作動で、マスタサーバ２１、ジョブスケジューラ２２２、ワーカ２２２ｐ、ワーカ２２２ｑと通信を行う。車両Ｃおよびクラウド２００についても、車両Ａおよびクラウド２００と同様の作動で、マスタサーバ２１、ジョブスケジューラ２２３、ワーカ２２３ｐ、ワーカ２２３ｑと通信を行う。
【００７７】
これ以降は、上述の車両Ａのイグニッションオンの後からＡ／Ｃ＿ＥＣＵ１１にコンプレッサ２の作動の制御までの処理と同様の処理（図９の一点鎖線３００で囲んだ部分に関する処理）が、基本的には繰り返し定期的に（具体的には１秒周期で）、繰り返される。
【００７８】
ただし、Ａ／Ｃ＿ＥＣＵ１１がデータブロックＷをクラウド対応空調パネル１２に送信した後（通信３３５）、クラウド対応空調パネル１２は、図１０のステップＳ１１０で、クラウド側カウント値を新たに受信していると判定し、ステップＳ１２０に進む。ステップＳ１２０では、当該新たに受信したクラウド側カウント値と同じ値を車側カウント値とし、データブロックＹに含める。したがって、このときクラウド対応空調パネル１２から無線変換器１３、モデム１４を介してマスタサーバ２１に送信されるデータブロックＹ（通信３３７）には、直前に受信したクラウド側カウント値と同じ値の車側カウント値が含まれている。
【００７９】
また、その後の通信３３７、３３９、３４１、３４３、３４５、３４７、３４９、３５１、３５３、３５５、３５７の手順は、通信３１３、３１５、３１７、３１９、３２１、３２３、３２５、３２７、３２９、３３１、３３３の手順と同じであり、送信されるデータの種類も同じである。ただし、データの値自体はワーカおよび車載システム１００の処理結果に応じて変化する。
【００８０】
ここで、プログラム２１ｂ、２１ｃ、２１ｄが規定する処理の内容について説明する。これらの処理は、ワーカが、ジョブスケジューラからの演算要求ＲＴａに従って、分散処理で実現する。冷媒検査プログラム２１ｂは、車両の冷凍サイクルの冷媒が不足しているか否かを判定する冷媒検査処理のためのプログラムである。
【００８１】
図１３に示すように、冷媒検査プログラム２１ｂでは、４つの状態ＳＸ、ＳＡ、ＳＢ、ＳＣが規定されている。状態ＳＸは、プログラムの実行開始時の状態、すなわち、始状態である。状態ＳＡは、冷媒不足判定が未実施または中止または取り消された状態である。状態ＳＢは、冷媒不足判定の途中の状態である。状態ＳＣは、冷媒不足判定が完了した状態である。
【００８２】
また、状態ＳＡは下位階層として未実施状態ＳＡ１および中止状態ＳＡ２を含んでいる。また、状態ＳＢは下位階層として第１判定中＿停車状態ＳＢ１、および第２判定中＿停車状態ＳＢ２を含んでいる。また、状態ＳＣは下位階層として冷媒不足なし状態ＳＣ１および冷媒不足有り状態ＳＣ２を含んでいる。
【００８３】
冷媒検査プログラム２１ｂでは、判定に用いるデータＩＧ、ＳＰＤ、ＴＨＷ、ＴＥｆｉｎ、ＰＲＥ、ＯＦＦ、ＭＯＮ、ＭＯＦＦの値は、ジョブスケジューラ２２１がマスタサーバ２１から受信する最新のジョブ要求通信中のデータブロックＹａを参照して決定する。
【００８４】
冷媒検査プログラム２１ｂの実行開始時には、この冷媒検査プログラム２１ｂの実行主体（本事例ではワーカ２２１ｐ、２２１ｑ）の状態は始状態ＳＺである。実行主体は、始状態ＳＺにいるとき、ＩＧがオフからオンに変化したことを検出すると、状態ＳＡの未実施状態ＳＡ１に遷移する。この遷移の際、実行主体は、作動Ｇ３を行う。すなわち、カウンタＪ、Ｋをゼロにクリアし、冷媒不足判定の値を「未判定」にセットする。
【００８５】
そして、状態ＳＡ（未実施状態ＳＡ１、中止状態ＳＡ２を含む）においては、リアルタイム性がＮＧ（不良）であると判定されている場合、状態ＳＡに留まり続ける。なお、リアルタイム性は、後述するリアルタイム性判定プログラム２１ｄの処理において判定される。
【００８６】
また、状態ＳＡにおいては、条件Ｓ１が満たされると、状態ＳＢ中の状態ＳＢ１に遷移する。条件Ｓ１は、リアルタイム性がＮＧからＯＫ（良好）に変化し、かつ、以下の条件（１）〜（３）すべてが３００秒以上成立しているという条件である。
（１）最後にマニュアルオン要求ＭＯＮが受信されて以降マニュアルオフ要求ＭＯＦＦが一度も受信されていない。
（２）ＳＰＤが０ｋｍ／ｈである。
（３）ＴＨＷが４５度Ｃを超えている。
【００８７】
上記の（１）の条件は、ユーザによってＡ／Ｃスイッチ１２１が操作された後に、コンプレッサ２が３００秒以上作動している場合に満たされる。
【００８８】
また、状態ＳＢ１にいる間は、１秒周期で、冷媒不足判定の値を「未判定」にセットし、カウンタＪの値を１だけカウントアップし、マスタサーバ２１から次回送信されるデータブロックＺａに含めるためのクラウド発オン要求を生成する。したがって、状態ＳＢ１の間は、クラウド発オン要求がデータブロックＺに含まれて空調パネル制御装置１２５に送信される。これにより、空調パネル制御装置１２５は、出力調停処理１２５ｂにおいて図６に示したようにコンプレッサ駆動要求ＣＭＰをオンにするので、状態ＳＢ１の間は、Ａ／Ｃ＿ＥＣＵ１１によってコンプレッサ２が駆動され続ける。
【００８９】
また、状態ＳＢ１において、カウンタＪの値が１６を超えると、状態ＳＢ２に遷移する。また、状態ＳＢ１において、ＰＲＥの値が冷媒不足５０％検査圧力を超えると、状態ＳＣ中の状態ＳＣ１に遷移する。
【００９０】
冷媒不足５０％検査圧力は、あらかじめ定められた定数値（例えば１．２ＭＰａ）であってもよいが、図１４に示すように、外気温度が高くなるほど高くなるように設定してもよい。なお、ここで用いる外気温度は、車両Ａの外気温度であるので、車両Ａから取得する必要がある。具体的には、Ａ／Ｃ＿ＥＣＵ１１が車両Ａに搭載された外気温センサ（図示せず）から取得した外気温ＴｏｕｔのデータをデータブロックＷに含め、クラウド対応空調パネル１２もデータブロックＹにその外気温Ｔｏｕｔのデータを含めるようになっていればよい。
【００９１】
また、状態ＳＢ２にいる間は、１秒周期で、冷媒不足判定の値を「未判定」にセットし、カウンタＫの値を１だけカウントアップする。また、状態ＳＢ２にいる間は、図１５に示すように、クラウド発オン要求とクラウド発オフ要求を切り替える。具体的には、クラウド発オフ要求を次回のデータブロックＺａに含めるために生成する処理を１４秒間繰り返す。そしてその後は、クラウド発オン要求を次回のデータブロックＺａに含めるために生成する処理を１６秒間繰り返す。そしてその後は、クラウド発オフ要求を次回のデータブロックＺａに含めるために生成する処理を１４秒間繰り返す。れは、冷媒不足判定のために、一時的に、車両Ａのコンプレッサ２を１４秒間停止させ、続いて１６秒作動させ、続いて１４秒停止させるための処理である。
【００９２】
より具体的には、状態ＳＢ１から状態ＳＢ２に遷移した時点ｔ１において、クラウド発オフ要求の繰り返し生成を開始する。この時点ｔ１においては、カウンタＫの値は０である。その後、カウンタ値が１４になった時点ｔ２において、クラウド発オフ要求の繰り返し生成を止めてクラウド発オン要求の繰り返し生成を開始する。その後、カウンタ値が３０になった時点ｔ３において、クラウド発オン要求の繰り返し生成を止めてクラウド発オフ要求の繰り返し生成を開始する。この作動は、実行主体が状態ＳＢ２にいる限り、少なくともカウンタ値が４４になる時点ｔ４まで続く。
【００９３】
したがって、状態ＳＢ２の時点ｔ１から時点ｔ２の間および時点ｔ３から時点ｔ４の間は、クラウド発オフ要求がデータブロックＺａに含まれて空調パネル制御装置１２５に送信される。これにより、空調パネル制御装置１２５は、出力調停処理１２５ｂにおいて図６に示したようにコンプレッサ駆動要求ＣＭＰを一時的にオフにするので、Ａ／Ｃ＿ＥＣＵ１１によってコンプレッサ２が一時的に停止され続ける。
【００９４】
また、状態ＳＢ２の時点ｔ２から時点ｔ３の間は、クラウド発オン要求がデータブロックＺａに含まれて空調パネル制御装置１２５に送信される。これにより、空調パネル制御装置１２５は、出力調停処理１２５ｂにおいて図６に示したようにコンプレッサ駆動要求ＣＭＰを一時的にオンにするので、Ａ／Ｃ＿ＥＣＵ１１によってコンプレッサ２が一時的に駆動され続ける。
【００９５】
また、状態ＳＢ２において、ΔＴｅｆｉｎが６度Ｃ以下のままカウンタＫの値が４４を超えると、状態ＳＣ中の状態ＳＣ２に遷移する。状態ＳＣ２に遷移するとき、クラウド発オン要求を次回のデータブロックＺａに含めるために生成してもよいし、生成しなくてもよい。
【００９６】
ただし、状態ＳＢ２において、カウンタＫの値が４４になる前にΔＴｅｆｉｎが６度Ｃを超えると、状態ＳＣ１に遷移する。ここで、ΔＴｅｆｉｎは、最後に第２判定中＿停車状態ＳＢ２に遷移して以降におけるＴｅｆｉｎの最大値と最小値の差分である。
【００９７】
状態ＳＢ２から状態ＳＣ１に遷移するタイミングで、クラウド発オン要求を次回のデータブロックＺａに含めるために生成してもよい。あるいは、状態ＳＢ２から状態ＳＣ１に遷移した後、所定の時間経過後（例えば、状態ＳＢ２の開始から４４秒後）のタイミングで、クラウド発オン要求を次回のデータブロックＺａに含めるために生成してもよい。これにより、空調パネル制御装置１２５は、出力調停処理１２５ｂにおいて図６に示したようにコンプレッサ駆動要求ＣＭＰをオンにするので、Ａ／Ｃ＿ＥＣＵ１１によってコンプレッサ２が駆動される。したがって、状態ＳＢ２の時点ｔ１から時点ｔ２の間および時点ｔ３から時点ｔ４の間に状態ＳＢ２から状態ＳＣ１への遷移が発生しても、その後コンプレッサ２はユーザの意図通りに作動し始める。また、状態ＳＢ２の時点ｔ２から時点ｔ３の間に状態ＳＢ２から状態ＳＣ１への遷移が発生しても、その後コンプレッサ２はユーザの意図通りに作動し続ける。
【００９８】
また、状態ＳＢ（状態ＳＢ１、ＳＢ２を含む）においては、リアルタイム性がＮＧ（不良）であると判定されると、状態ＳＡ（より具体的には状態ＳＡ２）に遷移する。この遷移の際、作動Ｇ３を行う。すなわち、カウンタＪ、Ｋをゼロにクリアし、冷媒不足判定の値を「未判定」にセットする。
【００９９】
状態ＳＢから状態ＳＡに遷移するタイミングで、クラウド発オン要求を次回のデータブロックＺａに含めるために生成してもよい。あるいは、状態ＳＢから状態ＳＡに遷移した後、所定の時間経過後（例えば、状態ＳＢ１の開始から６０秒後）のタイミングでクラウド発オン要求を次回のデータブロックＺａに含めるために生成してもよい。これにより、空調パネル制御装置１２５は、出力調停処理１２５ｂにおいて図６に示したようにコンプレッサ駆動要求ＣＭＰをオンにするので、Ａ／Ｃ＿ＥＣＵ１１によってコンプレッサ２が駆動される。したがって、状態ＳＢ２の時点ｔ１から時点ｔ２の間および時点ｔ３から時点ｔ４の間に状態ＳＢ２から状態ＳＡへの遷移が発生しても、その後コンプレッサ２はユーザの意図通りに作動し始める。また、状態ＳＢ１の間または状態ＳＢ２の時点ｔ２から時点ｔ３の間に状態ＳＢから状態ＳＡへの遷移が発生しても、その後コンプレッサ２はユーザの意図通りに作動し続ける。
【０１００】
また、状態ＳＢにおいては、条件Ｓ２が成立する場合、すなわち、
（４）新たに受信されたデータブロックＹａにマニュアルオフ要求ＭＯＦＦが含まれている
（５）上記条件（２）が不成立になる
（６）上記条件（３）が不成立になる
のいずれかの条件成立する場合、状態ＳＡ（より具体的には状態ＳＡ２）に遷移する。この遷移の際、作動Ｇ３を行う。すなわち、カウンタＪ、Ｋをゼロにクリアし、冷媒不足判定の値を「未判定」にセットする。
【０１０１】
また、状態ＳＣ１にいる間は、１秒周期で冷媒不足判定の値を「冷媒不足無し」にセットする。また、状態ＳＣ２にいる間は、冷媒が必要量の５０％以下である可能性が高いので、１秒周期で冷媒不足判定の値を「冷媒不足有り」にセットする。
【０１０２】
また、状態ＳＣ２において、条件Ｓ３が成立する場合、状態ＳＡ２に遷移する。条件Ｓ３が成立する場合とは、データＯＦＦの値が「押下」であるか、または、新たに受信されたデータブロックＹａにマニュアルオン要求ＭＯＮが含まれている場合である。この遷移の際、作動Ｇ３を行う。すなわち、カウンタＪ、Ｋをゼロにクリアし、冷媒不足判定の値を「未判定」にセットする。以上が、冷媒検査プログラム２１ｂが規定する処理の内容である。
【０１０３】
ここで、冷媒検査プログラム２１ｂがパラメータとして用いるリアルタイム性について説明する。
リアルタイム性とは、タイムラグＬが基準時間よりも短いことをいう。タイムラグＬは、第１処理時間、第１通信時間、第２処理時間、第２通信時間、第３処理時間の総和である。第１処理時間は、車載システム１００内の作動状態を示す状態量（例えば、ＩＧ、ＳＰＤ）が車載システム１００で検出されてから送信されるまでの時間である。第２処理時間は、上記状態量が車載システム１００から送信されて冷媒検査プログラム２１ｂの実行主体で受信されるまでの時間である。第２処理時間は、当該実行主体が当該状態量を受信してから、冷媒検査プログラム２１ｂの実行において当該状態量を利用して利用結果のデータ（例えば、冷媒不足判定、クラウド発オン要求）を生成して送信するまでの時間である。第２通信時間は、当該実行主体が当該利用結果のデータを送信してから車載システム１００が受信するまでの時間である。第３処理時間は、車載システム１００が当該当該利用結果のデータを受信してから、当該データを制御に反映するまでの時間である。
【０１０４】
上述の通り、車両用空調装置の診断（すなわち、冷媒量の判定）にはクラウド２００クラウド４００がアクチュエータ（すなわち、コンプレッサ２）を遠隔制御するので、リアルタイム性が無いときにこのような診断を実行するのは困難である。また、冷媒検査プログラム２１ｂは、コンプレッサ２を制御するための複雑な制御を記述する必要があるので、データサイズが大きくなりがちである。したがって、このような冷媒検査プログラム２１ｂを車両側（Ａ／Ｃ＿ＥＣＵ１１または空調パネル制御装置１２５）で実行するよりもクラウド２００側で実行することで、車両側の処理負荷の低減効果およびメモリ容量の節約効果が大きい。
【０１０５】
本実施形態では、上記総和の時間が所定時間より短いか否かで、リアルタイム性の有無が判断される。ここで、車載システム１００内の作動状態を示す状態量は、具体的には、ＩＧ、ＳＰＤ、ＴＨＷ、ＴＥｆｉｎ、ＰＲＥ、ＯＦＦ、ＭＯＮ、ＭＯＦＦである。また、車載システム１００内の制御は、具体的には、コンプレッサ２、Ａ／Ｃ表示器１２３、冷媒不足表示器１２４の制御である。
【０１０６】
本実施形態では、冷媒検査プログラム２１ｂの処理は、基本的に複数のワーカ２２１ｐ、２２１ｑに分散されて実行されるので、処理自体に遅延が発生することはあまりない。したがって、車載システム１００からクラウド２００へのデータブロックＹの送信、および、クラウド２００から車載システム１００へのデータブロックＺの送信による遅延が共に小さければ（例えば各々０．５秒未満なら）リアルタイム性はＯＫ（良好）である。しかし、車載システム１００からクラウド２００へのデータブロックＹの送信、および、クラウド２００から車載システム１００へのデータブロックＺの送信いずれかに大きな遅延（例えば４秒）があれば、リアルタイム性はＮＧ（不良）であり、適切な冷媒不足判定が行えない可能性が高くなる。
【０１０７】
そこで、本実施形態では、冷媒検査プログラム２１ｂにおいては、リアルタイム性の判定結果に基づいて、上述のような作動が規定されている。すなわち、冷媒不足の判定を行っていない状態ＳＡにおいてリアルタイム性がＮＧならば、状態ＳＡに留まって状態ＳＢに遷移しないことで、冷媒不足の判定を開始しない。そして、状態ＳＡにおいてリアルタイム性がＮＧからＯＫになって初めて、状態ＳＢに遷移して冷媒不足の判定を開始する。
【０１０８】
また、冷媒不足の判定の最中である状態ＳＢにおいては、リアルタイム性がＮＧになれば、冷媒不足の判定を中止して状態ＳＡに戻る。また、冷媒不足の判定を中止して状態ＳＡに戻った後も、リアルタイム性がＮＧからＯＫに戻れば、状態ＳＢ１に遷移して冷媒不足の判定を最初から実行し直す。なお、中止した冷媒不足の判定を途中から再開してもよい。
【０１０９】
また、既にリアルタイム性の判定が完了している状態ＳＣにおいては、リアルタイム性がＮＧになっても特に問題はないので、状態ＳＣを維持する。
【０１１０】
次に、カウントプログラム２１ｃの規定する作動について、図１６を参照して説明する。カウントプログラム２１ｃの実行主体（ワーカ２２１ｐ、２２１ｑ）は、ジョブスケジューラ２２１が制御準備完了の通知（通信３０７）を送信した後最初に演算要求（通信３２１）を受信したときに、このカウントプログラム２１ｃの実行を開始し、その後継続的に実行する。
【０１１１】
そして当該実行主体は、カウントプログラム２１ｃの実行において、まずステップＳ２１０で、クラウド側カウント値を初期値（例えばゼロ）にクリアすると共に、リアルタイム性の値を初期値（例えば、ＯＫ）にクリアする。
【０１１２】
続いてステップＳ２２０では、前回のクラウド側カウント値のカウントアップ（初めてのステップＳ２２０ではカウントプログラム２１ｃの実行開始）から１秒間経過するまで待ち、経過するとクラウド側カウント値を１だけカウントアップする。この１秒間は、例えば、カウントプログラム２１ｃの実行主体のワーカに内蔵されているクロックに基づいて計測してもよいし、時刻情報を提供する外部のタイムサーバから送信される時刻情報に基づいて計測してもよい。カウントアップされた値は、直ちに演算結果としてジョブスケジューラ２２１に送信され、ジョブスケジューラ２２１から他のワーカに送信される。
【０１１３】
このようになっているので、上述のようにワーカ２２１ｐまたは２２１ｑから送信される演算結果ＺａｐまたはＺａｑに含まれるクラウド側カウント値は、１秒毎に１ずつ上昇する。また同様に、ジョブスケジューラ２２１からマスタサーバ２１を経て車両Ａの車載システム１００まで送信されるデータブロックＺａ中のクラウド側カウント値も、１秒毎に１ずつ上昇する。
【０１１４】
次に、リアルタイム性判定プログラム２１ｄの規定する作動について、図１７を参照して説明する。リアルタイム性判定プログラム２１ｄの実行主体（ワーカ２２１ｐ、２２１ｑ）は、ジョブスケジューラ２２１が制御準備完了の通知（通信３０７）を送信した後最初に演算要求（通信３２１）を受信したときに、このリアルタイム性判定プログラム２１ｄの実行を開始し、その後継続的に実行する。
【０１１５】
そして当該実行主体は、リアルタイム性判定プログラム２１ｄの実行において、まずステップＳ２４０で、車側カウント値を新たに受信したか否かを判定し、新たに受信したと判定するまでこの判定を繰り返す。例えば図９の通信３３７で送信されるデータブロックＹａ（およびそれ以降に送信されるデータブロックＹａ）には、既に説明した通り、車側カウント値が含まれる。
【０１１６】
受信する車側カウント値は、図１０を参照して説明した通り、カウントプログラム２１ｃの実行主体から演算結果ＺａｐまたはＺａｑとして前回送信されたクラウド側カウント値と値が同じである。
【０１１７】
車側カウント値を新たに受信したと判定した場合、ステップＳ２５０に進み、受信した車側カウント値と現在のクラウド側カウント値との差（クラウド側カウント値−車側カウント値）を算出する。車載システム１００側の送信周期Ｔ１もクラウド２００側の送信周期Ｔ１も同じく１秒なので、車両Ａの車載システム１００とクラウド２００との間の双方向の通信に大きな遅延がなければ、この差は２以下になるはずである。この差が３以上なら、車両Ａの車載システム１００からクラウド２００への送信およびクラウド２００から車載システム１００への通信のうちいずれか一方または両方に大きな遅延があるということになる。
【０１１８】
続いてステップＳ２６０では、直前のステップＳ２５０で算出したカウント値の差が２を超えているか否か判定する。超えていなければ、ステップＳ２７０でリアルタイム性の値を「ＯＫ」にセットし、ステップＳ２４０に戻る。超えていれば、ステップＳ２８０でリアルタイム性の値を「ＮＧ」にセットし、ステップＳ２４０に戻る。ステップＳ２７０、Ｓ２８０で設定されたリアルタイム性の値は、直ちに演算結果としてジョブスケジューラ２２１に送信され、ジョブスケジューラ２２１から他のワーカに送信される。したがって、当該リアルタイム性の値は遅延無くリアルタイム性判定プログラム２１ｄの処理において使用される。
【０１１９】
このように、本実施形態の通信システムでは、ジョブスケジューラ２２１に管理されるワーカがクラウド側カウント値を１秒毎にカウントアップする。そして当該ワーカからジョブスケジューラ２２１およびマスタサーバ２１を介して空調パネル制御装置１２５へクラウド側カウント値がデータブロックＺに含まれて送信される。そして、空調パネル制御装置１２５は、受信したクラウド側カウント値と同じ値の車側カウント値をデータブロックＹに含めて送信し、当該車側カウント値はマスタサーバ２１およびジョブスケジューラ２２１を介してワーカに届く。したがって、ワーカは、自機がクラウド側カウント値を送信してから、当該クラウド側カウント値に対する応答を空調パネル制御装置１２５から受信するまでの時間（すなわち、両者の通信に要する時間）に基づいて、リアルタイム性の判定を行っている。つまり、クラウド側カウント値は、リアルタイム性の確認用のタイムデータであり、車側カウント値は、当該タイムデータに対する応答である。
【０１２０】
そして、リアルタイム性は、この両者の通信に要する時間が、所定の範囲を、つまり、受信した車側カウント値と現在のクラウド側カウント値との差が２以下となるような範囲を超えて大きいか否かで判定される。
【０１２１】
なお、車両Ａのイグニッションがオンからオフになった場合、Ａ／Ｃ＿ＥＣＵ１１は、イグニッション状態ＩＧのデータをオンからオフに更新する。その後、最初に訪れるデータブロックＷの送信タイミングにおいて、Ａ／Ｃ＿ＥＣＵ１１は、既に説明した通り、イグニッション状態ＩＧを含むデータブロックＷを、空調パネル制御装置１２５に送信する（通信３８１）。
【０１２２】
空調パネル制御装置１２５は、このデータブロックＷを受信した後に最初に訪れるデータブロックＹの送信タイミングにおいて、既に説明した通り、当該データブロックＷに含まれるデータＩＧ等を、送信用のデータブロックＹａに含める。そして空調パネル制御装置１２５は、このデータブロックＹを、無線変換器１３、モデム１４を介してマスタサーバ２１に送信する（通信３８３）。この際、無線変換器１３が、データブロックＹａに対して自機のアドレスを付加する。
【０１２３】
このデータブロックＹａを受信したマスタサーバ２１は、受信したデータブロックＹａに含まれるデータＩＧの値がオフであることに基づいて、ジョブスケジューラ２２１に対してワーカ消滅要求を送信する（通信３８５）。
【０１２４】
このワーカ消滅要求を受信したジョブスケジューラ２２１は、ワーカ２２１ｐ、２２１ｑと通信することで、冷媒検査プログラム２１ｂ、カウントプログラム２１ｃ、リアルタイム性判定プログラム２１ｄの処理を終了させる（通信３８７）。その後ジョブスケジューラ２２１は、ワーカ消滅終了の通知をマスタサーバ２１に送信する（通信３８９）。このワーカ消滅終了の通知を受信したマスタサーバ２１は、制御受付ＮＧの通知を車両Ａに送信する。車両Ａでは、この制御受付ＮＧの通知を空調パネル制御装置１２５が受信し、その後、空調パネル制御装置１２５が作動を停止する。
【０１２５】
ここで、本実施形態における車載システム１００側およびクラウド２００側の機能構成について、図１８を参照して説明する。車載システム１００側の機能は、ハードウェア層Ｖ１としてクラウド対応空調パネル１２を有し、ハードウェア層Ｖ１の上位の階層として通信部Ｖ２（無線変換器１３、モデム１４）を有している。そして更に、通信部Ｖ２の上位の階層として通信監視部Ｖ３を有しており、通信監視部Ｖ３には図１０のカウント返送処理１２５ｃの機能が含まれている。また、通信部Ｖ２および通信監視部Ｖ３の上位の階層としてアプリケーション層Ｖ４を有しており、このアプリケーション層Ｖ４にはマニュアル状態遷移処理１２５ａと出力調停処理１２５ｂの機能が含まれている。
【０１２６】
クラウド２００側の機能は、クラウドインフラ層Ｃ１としてマスタサーバ２１およびスレーブサーバ群２２を有し、クラウドインフラ層Ｃ１の上位の階層として通信部Ｃ２を有している。そして更に、通信部Ｃ２の上位の階層として通信監視部Ｃ３を有しており、通信監視部Ｃ３にはカウントプログラム２１ｃ、リアルタイム性判定プログラム２１ｄの機能が含まれている。また、通信部Ｃ２および通信監視部Ｃ３の上位の階層としてアプリケーション層Ｃ４を有しており、このアプリケーション層Ｖ４には冷媒検査プログラム２１ｂの機能が含まれている。
【０１２７】
このように、通信監視部Ｖ３のカウント返送処理１２５ｃの機能を、アプリケーション層Ｖ４のマニュアル状態遷移処理１２５ａと出力調停処理１２５ｂの機能から独立させる（すなわち、異なるソフトウェアモジュールとして実現する）ことにより、マニュアル状態遷移処理１２５ａと出力調停処理１２５ｂの開発が見通しのよいものになる。
【０１２８】
また、通信監視部Ｃ３のカウントプログラム２１ｃ、リアルタイム性判定プログラム２１ｄの機能を、アプリケーション層Ｃ４の冷媒検査プログラム２１ｂの機能から独立させる（すなわち、異なるソフトウェアモジュールとして実現する）ことにより、冷媒検査プログラム２１ｂの開発が見通しのよいものになる。つまり、クラウド２００を利用せず車内でスタンドアローンに用いる冷媒検査プログラムと冷媒検査プログラム２１ｂとの違いが少なくなるので、冷媒検査プログラム２１ｂの開発においてスタンドアローンに用いる冷媒検査プログラムを流用し易い。
【０１２９】
以上説明した通り、本実施形態においては、クラウド２００は、空調パネル制御装置１２５と１台以上のサーバとの間の通信に要する時間が所定の基準を超えているか否かを状態ＳＢで判定し、所定の基準を超えていると判定されたことに基づいて、状態ＳＢから状態ＳＡに遷移することで、車両用空調装置の冷媒不足の判定を中止する。
【０１３０】
このように、空調パネル制御装置１２５とクラウド２００との間の通信の遅延が所定の基準を超えて大きいときに、車両用空調装置の冷媒不足の判定が中止されるという形で、リアルタイム性の判定が実現されている。これにより、リアルタイム性が不良で適切な冷媒不足の判定が行えない可能性が高い場合にまで、冷媒不足の判定を続けることの無駄を低減できる。
【０１３１】
なお、本実施形態では、ワーカ２２１ｐ、２２１ｑが、冷媒検査プログラム２１ｂを実行することで、冷媒検査手段の一例として機能し、リアルタイム性判定プログラム２１ｄを実行することで判定手段の一例として機能する。
【０１３２】
（第２実施形態）
次に第２実施形態について説明する。図１９に示すように、本実施形態の通信システムは、車両に搭載された車載システム３０、および、車両外の遠隔地に設置されて車載システム３０と通信するクラウド４００（１台以上のサーバの一例に相当する）を備えている。
【０１３３】
車載システム３０は、蒸発燃料のリークを検出するためのシステムであり、燃料タンク３１、連通管３２、キャニスタ３３、パージ管３４、第１バルブ３５、吸気通路３６、スロットルバルブ３７、管３８ａ、３８ｂ、３８ｃ、３８ｄを含んでいる。更に車載システム３０は、第２バルブ３９、第３バルブ４０、基準オリフィス４１、減圧ポンプ４２、圧力センサ４３、ＥＶ＿ＥＣＵ４４、バッテリ４５、ＩＧスイッチ４６、リレー４７、無線変換器４８を含んでいる。第１バルブ３５、第２バルブ３９、第３バルブ４０、減圧ポンプ４２の各々が、アクチュエータの一例に相当する。
【０１３４】
燃料タンク３１は、車載システム３０の搭載先の車両のエンジンに供給するための燃料を貯留する。この燃料は、主に燃料噴射弁から噴射されてエンジン内に入る。連通管３２は、燃料タンク３１内とキャニスタ３３内とに連通する配管である。
【０１３５】
キャニスタ３３は、燃料タンク３１内で発生して連通管３２を通ってキャニスタ３３内に入った蒸発燃料を、回収する。パージ管３４は、一端がキャニスタ３３内に連通して他端が吸気通路３６に連通する配管である。
【０１３６】
第１バルブ３５は、パージ管３４の途中に配置されている。この第１バルブ３５は、パージ管３４を通ってキャニスタ３３から吸気通路３６にパージされる蒸発燃料の量をエンジン運転中等において調整する弁である。吸気通路３６は、エンジンに空気を送る通路である。この吸気通路３６の内部に、スロットルバルブ３７が配置されている。スロットルバルブ３７は、スロットル開度を変化させることで吸気通路３６からエンジンに流入する空気量を調整する弁である。
【０１３７】
キャニスタ接続管３８ａは、一端がキャニスタ３３内に連通し、他端が第１大気管３８ｂ、第２大気管３８ｃ、およびバイパス管３８ｄに連通する配管である。第１大気管３８ｂは、一端がキャニスタ接続管３８ａ、第２大気管３８ｃ、バイパス管３８ｄに連通し、他端が車両の外部の空間に連通する配管である。第２大気管３８ｃは、一端がキャニスタ接続管３８ａ、第１大気管３８ｂ、バイパス管３８ｄに連通し、他端が車両外部の空間に連通する配管である。バイパス管３８ｄは、一端がキャニスタ接続管３８ａ、第１大気管３８ｂ、および、大気管３８ｃの上記一端に連通する。また、バイパス管３８ｄは、他端が第２大気管３８ｃの途中に連通する。
【０１３８】
第１大気管３８ｂの途中には、第２バルブ３９が配置されている。第２バルブ３９は、第１大気管３８ｂの内部の通路を開閉する弁である。バイパス管３８ｄの途中には、第３バルブ４０が配置されている。第３バルブ４０は、バイパス管３８ｄの内部の通路を開閉する弁である。
【０１３９】
第２大気管３８ｃの途中には、基準オリフィス４１が配置されている。基準オリフィス４１の通路内径は、燃料タンク３１からの蒸発燃料を含む気体の漏れの許容量の上限値となる基準径（例えば０．５ｍｍ）となっている。
【０１４０】
減圧ポンプ４２は、第２大気管３８ｃの基準オリフィス４１の下流側（すなわち第２大気管３８ｃの上記他端側）に配置され、第２大気管３８ｃ内の減圧ポンプ４２よりも上流側（すなわち第２大気管３８ｃの上記一端側）から気体を吸引して下流側に吐出する。
【０１４１】
圧力センサ４２は、第２大気管３８ｃ内の基準オリフィス４１の下流側かつ減圧ポンプ４２よりも上流側の検出位置における圧力を検出する。なお、バイパス管３８ｄの上記他端は、第２大気管３８ｃ内の上記検出位置よりも下流かつ減圧ポンプ４２よりも上流側に連通する。
【０１４２】
バッテリ４５は、車両に搭載された二次電池であり、車両の各種機器に電力を供給する。ＩＧスイッチ４６は、バッテリ４５からＩＧ線を介してＥＶ＿ＥＣＵ４４を含む上記各種装置に電力を供給する、しないを切り替えるスイッチである。
【０１４３】
リレー４７は、ＩＧスイッチ４６のオン、オフとは無関係に、バッテリ４５からＥＶ＿ＥＣＵ４４への電力供給をオンオフするスイッチ回路である。
【０１４４】
ＥＶ＿ＥＣＵ４４は、後述するように、クラウド４００からの指令に従って、第１バルブ３５、第２バルブ３９、第３バルブ４０、減圧ポンプ４２等を制御する。ＥＶ＿ＥＣＵ４４が第１バルブ３５、第２バルブ３９、第３バルブ４０、減圧ポンプ４２等を制御するのは、エバポ系の診断、より詳しくは、エバポ系における蒸発燃料のリーク有無の判定のためである。エバポ系は、燃料タンク３１全体、連通管３２全体、キャニスタ３３全体、および、パージ管３４のキャニスタ３３側端から第１バルブ３５まで、を有する装置であり、車載装置の一例に相当する。このエバポ系は、第１バルブ３５、第２バルブ３９、第３バルブ４０、減圧ポンプ４２の作動内容によって状態が変化する。
【０１４５】
また、ＥＶ＿ＥＣＵ４４は、データブロックＴを１秒毎に無線変換器４８に送信する。データブロックＴの内容については後述する。
【０１４６】
無線変換器４８は、ＥＶ＿ＥＣＵ４４とモデム１４との中継を行う装置である。具体的には、無線変換器４８は、ＥＶ＿ＥＣＵ４４から送信されたデータブロックＴに無線変換器４８のアドレス（例えばＭＡＣアドレス）を含めてモデム１４に送信する。
【０１４７】
モデム１４は、例えば携帯電話機等の装置であり、車両の乗員に携帯されて車室内に持ち込まれ、無線変換器４８および車外に設置されたサーバ群であるクラウド４００と通信可能な装置である。モデム１４は、図２０に示すように、無線変換器４８から受信した上記データブロックＴを、１秒毎にクラウド４００に送信する。モデム１４とクラウド４００は、例えばインターネット等の広域ネットワークを介して通信する。
【０１４８】
ここで、図２１に示す通り、データブロックＴは、圧力センサデータＰ、イグニッション状態ＩＧ、車側カウント値、リアルタイム有効データ、ＭＡＣアドレス（無線変換器４８のアドレス）を含んでいる。これらデータのうち、ＭＡＣアドレス以外は、ＥＶ＿ＥＣＵ４４がデータブロックＴとして無線変換器４８に送信する。また、圧力センサデータＰ、イグニッション状態ＩＧ、車側カウント値、リアルタイム有効データは、エバポ系を診断して蒸発燃料のリークを判定するために必要な検査データを構成する。リアルタイム有効データは、リアルタイム性ありとＥＶ＿ＥＣＵ４４が判定したときにのみ送信されるイベントデータである。
【０１４９】
なお、本実施形態において、イベントデータであると明示するデータ以外は、所謂レベルデータである。レベルデータは毎周期送信されるのに対し、イベントデータは特定の条件が満たされたときにのみ送信される。
【０１５０】
またモデム１４は、図２０に示す通り、クラウド４００から繰り返しデータブロックＳを受信する。データブロックＳは、図２１に示す通り、エバポリーク判定、ポンプオン要求、ポンプオフ要求、リレーオン要求、リレーオフ要求、Ｖ１オン要求、Ｖ１オフ要求、Ｖ２オン要求、Ｖ２オフ要求、Ｖ３オン要求、Ｖ３オフ要求、クラウド側カウント値という１１個のデータを含んでいる。
【０１５１】
エバポリーク判定は、エバポ系における蒸発燃料のリーク有無の判定結果を示すイベントデータである。ポンプオン要求は、エバポ系の診断のためにクラウド４００側から減圧ポンプ４２の作動開始が要求されたことを示すイベントデータである。ポンプオフ要求は、エバポ系の診断のためにクラウド４００側から減圧ポンプ４２の作動停止が要求されたことを示すイベントデータである。
リレーオン要求は、エバポ系の診断のためにクラウド４００側からリレー４７のオン動作が要求されたことを示すイベントデータである。リレーオフ要求は、エバポ系の診断が終わった際にクラウド４００側からリレー４７のオフ動作が要求されたことを示すイベントデータである。
【０１５２】
Ｖ１オン要求は、クラウド４００側から第１バルブ３５の開動作が要求されたことを示すイベントデータである。Ｖ１オフ要求は、エバポ系の診断のためにクラウド４００側から第１バルブ３５の閉動作が要求されたことを示すイベントデータである。
【０１５３】
Ｖ２オン要求は、エバポ系の診断のためにクラウド４００側から第２バルブ３９の開動作が要求されたことを示すイベントデータである。Ｖ２オフ要求は、エバポ系の診断のためにクラウド４００側から第２バルブ３９の閉動作が要求されたことを示すイベントデータである。
【０１５４】
Ｖ３オン要求は、エバポ系の診断のためにクラウド４００側から第３バルブ４０の開動作が要求されたことを示すイベントデータである。Ｖ３オフ要求は、エバポ系の診断のためにクラウド４００側から第３バルブ４０の閉動作が要求されたことを示すイベントデータである。クラウド側カウント値については後述する。
【０１５５】
クラウド４００は、繰り返し、定期的に具体的には１秒周期で、上記クラウド側カウント値を含むデータブロックＳを、モデム１４に送信する。また、データブロックＳに含まれる場合があるデータのうちイベントデータの各々については、特定の条件が満たされた場合にのみ、上記データブロックＳに含める。モデム１４は、受信したデータブロックＳを無線変換器４８に送信し、無線変換器４８は受信したデータブロックＳをＥＶ＿ＥＣＵ４４に送信する。
【０１５６】
ここで、ＥＶ＿ＥＣＵ４４の作動について説明する。ＥＶ＿ＥＣＵ４４は、図２２に示す処理を実行するようになっている。まずステップＳ４１０では、モデム１４、無線変換器４８を介してクラウド４００から最後に受信したデータブロックＳを、ＲＡＭに読み出す。
【０１５７】
続いてステップＳ４２０では、直前のステップＳ４１０で読み出したデータブロックＳにポンプオン要求、ポンプオフ要求、リレーオン要求、リレーオフ要求、Ｖ１オン要求、Ｖ１オフ要求、Ｖ２オン要求、Ｖ２オフ要求、Ｖ３オン要求、Ｖ３オフ要求のいずれか１つ以上が含まれている場合、含まれている要求を実現するよう、必要に応じて、第１バルブ３５、第２バルブ３９、第３バルブ４０、減圧ポンプ４２、リレー４７を制御する。上記要求がデータブロックＳに１つも含まれていない場合は、制御を行わずステップＳ４３０に進む。
【０１５８】
続いてステップＳ４３０では、直前のステップＳ４１０で読み出したデータブロックＳにエバポリーク判定のデータが含まれている場合、そのデータを記憶媒体（例えばＥＶ＿ＥＣＵ４４のフラッシュメモリ）に記録する。このように記録されたエバポリーク判定のデータは、後に読み出して車両の解析、故障判定等に使用される。データブロックＳにエバポリーク判定のデータが含まれている場合、何もせずステップＳ４４０に進む。
【０１５９】
続いてステップＳ４４０では、センサ値を取得する。具体的には、圧力センサ４３の検出結果に基づいて圧力センサ値Ｐを取得する。この圧力センサ値Ｐは、第２大気管３８ｃ内における基準オリフィス４１の下流かつ減圧ポンプ４２の上流の圧力である。
【０１６０】
続いてステップＳ４５０では、車両のイグニッション状態ＩＧを取得する。ＩＧスイッチ４６がオンならばイグニッション状態ＩＧはオンとなり、ＩＧスイッチ４６がオフならばイグニッション状態ＩＧはオフとなる。
【０１６１】
続いてステップＳ４６０では、リアルタイム性有無について判定を行う。この判定の詳細については後述する。続いてステップＳ４７０では、ＲＡＭ中の車側カウント値（車側リアルタイム性確認カウント値）の値を１だけカウントアップする。これにより、クラウド側カウント値は１秒に１だけ増加する。
【０１６２】
続いてステップＳ４８０では、データブロックＴを作成して送信する。具体的には、直前のステップＳ４４０で取得済みの圧力センサ値Ｐ、直前のステップＳ４５０で取得済みのイグニッション状態ＩＧ、直前のステップＳ４７０で更新済みの車側カウント値を含むデータブロックＴを作成する。そして、直前のステップＳ４６０の判定結果が、「リアルタイム性あり」である場合は、当該データブロックＴにリアルタイム有効データを含める。しかし、直前のステップＳ４６０の判定結果が、「リアルタイム性なし」である場合は、当該データブロックＴにリアルタイム有効データを含めない。
【０１６３】
ステップＳ４８０では更に、このようにして作成したデータブロックＴを、無線変換器４８に送信する。これにより、無線変換器４８が当該データブロックＴにアドレスを追加してモデム１４に送信し、モデム１４は当該アドレスが追加されたデータブロックＴをクラウド４００に送信する。
【０１６４】
ＥＶ＿ＥＣＵ４４は、続いてステップＳ４９０で、所定時間、具体的には１秒間、待機し、その後、ステップＳ４１０に戻る。ＥＶ＿ＥＣＵ４４は、このようにステップＳ４１０〜４９０のループを１秒周期で実行する。
【０１６５】
このようにすることで、ＥＶ＿ＥＣＵ４４は、１秒周期で、その時点において受信している最新のデータブロックＳに基づいて制御、診断結果記録を行う。また、ＥＶ＿ＥＣＵ４４は、１秒周期で、その時点における最新の圧力センサ値、イグニッション状態ＩＧ、車側カウント値を含むデータブロックＴを、無線変換器４８、モデム１４を介して、クラウド４００に送信する。したがって、車側カウント値は、データブロックＴを送信する度に１だけ増加する。また、ＥＶ＿ＥＣＵ４４は、ＥＶ＿ＥＣＵ４４とクラウド４００の間の通信にリアルタイム性があれば、データブロックＴにリアルタイム有効データを含める。
【０１６６】
次に、クラウド４００の構成について説明する。クラウド４００は、図２３に示すように、第１実施形態と同じハードウェア構成のマスタサーバ２１と、第１実施形態と同じハードウェア構成のスレーブサーバ群２２を含んでいる。
【０１６７】
また、図１に示した車載システム３０およびモデム１４は、複数の車両Ｄ、Ｅ、Ｆの各々に搭載され、それぞれの車載システム３０のＥＶ＿ＥＣＵ４４が、同じ車両に搭載された無線変換器４８、モデム１４を介して、マスタサーバ２１と通信する。
【０１６８】
マスタサーバ２１は、第１実施形態と同様、演算指示処理２１ａを実行するようになっていると共に、図示しない記憶媒体を有し、当該記憶媒体に診断プログラム２１ｅ、カウントプログラム２１ｆ、リアルタイム性判定プログラム２１ｇが記録されている。このように、本実施形態においてマスタサーバ２１の記憶媒体に記録されているソフトウエアは、第１実施形態とは異なる。
【０１６９】
マスタサーバ２１が、車両Ｄ、Ｅ、Ｆのそれぞれ専用に１つジョブスケジューラを割り当ててプログラム２１ｅ、２１ｆ、２１ｇを送付する手順は、第１実施形態と同様であってもよいし、周知の他の分散処理技術を使用して実現してもよい。また、更に各ジョブスケジューラ２２１、２２２、２２３が、自機が管理する複数のワーカ２２１ｐ、２２１ｑ、２２２ｐ、２２２ｑ、２２３ｐ、２２３ｑにプログラム２１ｅ、２１ｆ、２１ｇの処理を分散させる手順も、第１実施形態と同様であってもよいし、周知の他の分散処理技術を使用して実現してもよい。
【０１７０】
このように、車両Ｄに関して行うべきプログラム２１ｅ、２１ｆ、２１ｇの処理が、ジョブスケジューラ２２１によって適宜複数のワーカ２２１ｐ、２２１ｑに分散して割り当てられるので、個々のワーカの処理負荷が軽減される。
【０１７１】
図２４に、上記のような車両Ｄからワーカ２２１ｐ、２２１ｑまでのデータの流れを示す。図２４では、車両Ｄ、Ｅ、Ｆから送信されたデータブロックＴを、それぞれＴｄ、Ｔｅ、Ｔｆと標記する。
【０１７２】
クラウド４００における分散処理では、車両Ｄのモデム１４からデータブロックＴｄを受信したマスタサーバ２１は、データブロックＴｄを含むジョブ要求通信ＲＴｄをジョブスケジューラ２２１に送信する。このジョブ要求通信ＲＴｄを受信したジョブスケジューラ２２１は、このジョブ要求通信ＲＴｄに含まれるデータブロックＴｄの内容と、プログラム２１ｅ、２１ｆ、２１ｇの処理内容に基づいて、プログラム２１ｅ、２１ｆ、２１ｇが規定する処理を、自機が管理する複数のワーカ２２１ｐ、２２１ｑに分散して実行させる。このため、ジョブスケジューラ２２１は、自機が管理する複数のワーカ２２１ｐ、２２１ｑの各々に対して、必要な演算要求Ｔｄｐ、Ｔｄｑを送信する。この演算要求Ｔｄｐ、Ｔｄｑには、ワーカ２２１ｐ、２２１ｑの各々で行うべき処理の内容およびその処理に必要なデータ（最新のデータブロックＴａの内容等）が含まれている。
【０１７３】
また、ワーカ２２１ｐ、２２１ｑは、それぞれ、ジョブスケジューラ２２１からの演算要求Ｔｄｐ、Ｔｄｑに従った作動を行い、図２５に示すように、その作動の結果得た、演算結果Ｓｄｐ、Ｓｄｑをジョブスケジューラ２２１に送信する。エバポリーク判定、ポンプオン要求、ポンプオフ要求、リレーオン要求、リレーオフ要求、Ｖ１オン要求、Ｖ１オフ要求、Ｖ２オン要求、Ｖ２オフ要求、Ｖ３オン要求、Ｖ３オフ要求、クラウド側カウント値は、演算結果Ｓｄｐ、Ｓｄｑのいずれかに含まれている。その他にも、演算時に使用する各種変数が、演算結果Ｓｄｐ、Ｓｄｑに含まれている。
【０１７４】
演算結果Ｓｄｐ、Ｓｄｑを受信したジョブスケジューラ２２１は、直ちに（すなわち、１秒よりも十分短い遅延で）、これら演算結果を、自機が管理する複数のワーカ２２１ｐ、２２１ｑの各々に送信する。このようにすることで、同じジョブスケジューラ２２１に管理される複数のワーカ２２１ｐ、２２１ｑ間で、各種データの値が整合する。
【０１７５】
また、ジョブスケジューラ２２１は、受信した最新の演算結果Ｓｄｐ、Ｓｄｑから（あれば）エバポリーク判定、（あれば）ポンプオン要求、（あれば）ポンプオフ要求、（あれば）リレーオン要求、（あれば）リレーオフ要求、（あれば）Ｖ１オン要求、（あれば）Ｖ１オフ要求、（あれば）Ｖ２オン要求、（あれば）Ｖ２オフ要求、（あれば）Ｖ３オン要求、（あれば）Ｖ３オフ要求、およびクラウド側カウント値を抽出してデータブロックＳｄを生成し、このデータブロックＳｄを含むジョブ結果通信を、繰り返し定期的に（具体的には１秒周期で）マスタサーバ２１に送信する。なお、図２５では、車両Ｄ、Ｅ、Ｆに送信するためのデータブロックＳを、それぞれＳｄ、Ｓｅ、Ｓｆと標記する。
【０１７６】
このジョブ結果通信を受信したマスタサーバ２１は、直ちに当該ジョブ結果通信中に含まれるデータブロックＳｄを車両Ｄに送信する。したがって、マスタサーバ２１から車両ＤへのデータブロックＳｄの送信も、繰り返し定期的に（具体的には１秒周期で）行われる。
【０１７７】
車両Ｄでは、ＥＶ＿ＥＣＵ４４が、モデム１４および無線変換器４８を介してこのデータブロックＳｄを受信する。そしてＥＶ＿ＥＣＵ４４は、図２２の処理において、データブロックＳｄ受信直後の図２２のループのステップＳ４１０で、このデータブロックＳｄをＲＡＭに読み出し、続くステップＳ４２０で、読み出したデータブロックＳｄ中のデータに基づいて、必要に応じて第１バルブ３５、第２バルブ３９、第３バルブ４０、減圧ポンプ４２、リレー４７を制御する。そして続くステップＳ４３０で、データブロックＳｄ中のエバポリーク判定のデータが含まれている場合、そのデータを記憶媒体に記録する。また、その直後のステップＳ４６０では、データブロックＳｄ中のクラウド側カウント値および現在の車側カウント値に基づいて、リアルタイム性判定を行う。
【０１７８】
車両Ｅおよびクラウド４００については、車両Ｄおよびクラウド４００と同様の作動で、マスタサーバ２１、ジョブスケジューラ２２２、ワーカ２２２ｐ、ワーカ２２２ｑと通信を行う。この作動については、上記の説明の車両Ｄ、データブロックＴｄ、ジョブ要求通信ＲＴｄ、演算要求Ｔｄｐ、演算要求Ｔｄｑ、演算結果Ｓｄｐ、演算結果Ｓｄｑ、データブロックＳｄ、ジョブスケジューラ２２１、ワーカ２２１ｐ、ワーカ２２１ｑを、それぞれ、車両Ｅ、データブロックＴｅ、ジョブ要求通信ＲＴｅ、演算要求Ｔｅｐ、演算要求Ｔｅｑ、演算結果Ｓｅｐ、演算結果Ｓｅｑ、データブロックＳｅ、ジョブスケジューラ２２２、ワーカ２２２ｐ、ワーカ２２２ｑと読み替える。なお、この読み替えは、以下の説明についても有効である。
【０１７９】
車両Ｆおよびクラウド４００についても、車両Ｄおよびクラウド４００と同様の作動で、マスタサーバ２１、ジョブスケジューラ２２３、ワーカ２２３ｐ、ワーカ２２３ｑと通信を行う。この作動については、上記の説明の車両Ｄ、データブロックＴｄ、ジョブ要求通信ＲＴｄ、演算要求Ｔｄｐ、演算要求Ｔｄｑ、演算結果Ｓｄｐ、演算結果Ｓｄｑ、データブロックＳｄ、ジョブスケジューラ２２１、ワーカ２２１ｐ、ワーカ２２１ｑを、それぞれ、車両Ｆ、データブロックＴｆ、ジョブ要求通信ＲＴｆ、演算要求Ｔｆｐ、演算要求Ｔｆｑ、演算結果Ｓｆｐ、演算結果Ｓｆｑ、データブロックＳｆ、ジョブスケジューラ２２３、ワーカ２２３ｐ、ワーカ２２３ｑと読み替える。なお、この読み替えは、以下の説明についても有効である。
【０１８０】
ここで、プログラム２１ｅ、２１ｆ、２１ｇが規定する処理の内容について説明する。これらの処理は、ワーカが、ジョブスケジューラ２２１からの演算要求ＲＴａに従って、分散処理で実現する。
【０１８１】
診断プログラム２１ｅは、車両のエバポ系における蒸発燃料のリーク有無を判定するためのプログラムである。図２６に示すように、診断プログラム２１ｅでは、６個の状態ＳＤ、ＳＥ、ＳＦ、ＳＧ、ＳＨ、ＳＩが規定されている。また、状態ＳＦは、子状態ＳＦ１、ＳＦ２、ＳＦ３を有している。
【０１８２】
診断プログラム２１ｅで使用するイグニッション状態ＩＧ、圧力センサ値Ｐの値は、ジョブスケジューラ２２１がマスタサーバ２１から受信する最新のジョブ要求通信ＲＹａ中のデータブロックＹａを参照して決定する。
【０１８３】
診断プログラム２１ｅの実行開始時には、この診断プログラム２１ｅの実行主体（本事例ではワーカ２２１ｐ、２２１ｑ）の状態は＋Ｂオフ状態ＳＩにある。例えばこのとき、車両Ｄにおいて、ＩＧスイッチ４６、リレー４７はオフであり、ＥＶ＿ＥＣＵ４４は停止中となっているとする。
【０１８４】
そしてその後、ＩＧスイッチ４６がオンになり、ＥＶ＿ＥＣＵ４４が起動すると、ＥＶ＿ＥＣＵ４４は、図２２の処理によって上述の通りデータブロックＴａを送信し始めるが、そのデータブロックＴａ中のイグニッション状態ＩＧの値はオンになっている。
【０１８５】
このイグニッション状態ＩＧの値は、マスタサーバ２１、ジョブスケジューラ２２１を介して演算要求として診断プログラム２１ｅの実行主体のワーカに送信される。すると、当該実行主体は、状態ＳＩにいるとき、イグニッション状態ＩＧがオンであることを検出し、リレーオン要求を演算結果（ＳｄｐまたはＳｄｑ）としてジョブスケジューラ２２１に送信すると共に、＋Ｂオン状態ＳＤに遷移する。
【０１８６】
ジョブスケジューラ２２１は、当該リレーオン要求を受信すると、その後の最初のデータブロックＳｄの送信タイミングにおいて、リレーオン要求を含むデータブロックＳｄを作成し、マスタサーバ２１に送信する。マスタサーバ２１は、このリレーオン要求を含むデータブロックＳｄを車両Ｄに送信する。車両ＤのＥＶ＿ＥＣＵ４４は、このデータブロックＳｄをモデム１４、無線変換器４８を介して受信する。更にＥＶ＿ＥＣＵ４４は、その直後の図２２のループのＳ４２０で、このリレーオン要求に従って、リレー４７をオンにする。これにより、ＥＶ＿ＥＣＵ４４は、ＩＧスイッチ４６がオフになってもバッテリ４５から電力供給を受けて作動し続けられる状態になる。
【０１８７】
その後、イグニッション状態ＩＧがオンである場合、当該実行主体は、状態ＳＤに留まっている。車両Ｄにおいては、ＩＧスイッチ４６がオンの間、エンジンが作動して車両Ｄの走行が実現する。
【０１８８】
図２７の実線５１に示すように、車両Ｄにおいてエンジンが停止した後ＩＧスイッチ４６がオフになると、ＥＶ＿ＥＣＵ４４は、リレー４７を介して電力供給を受けながら作動を継続する。そしてＥＶ＿ＥＣＵ４４は、ＩＧスイッチ４６がオフになった直後の図２２のループのＳ４５０において、イグニッション状態ＩＧをオフにする。ＥＶ＿ＥＣＵ４４は更にその直後のステップＳ４８０で、オフの値となっているイグニッション状態ＩＧのデータを含むブロックＴａを送信する。
【０１８９】
このイグニッション状態ＩＧの値は、マスタサーバ２１、ジョブスケジューラ２２１を介して演算要求として診断プログラム２１ｅの実行主体のワーカに送信される。すると、当該実行主体は、状態ＳＤにいるとき、イグニッション状態ＩＧがオンからオフになったことを検出し、リークテスト未実施状態ＳＤに遷移する。リークテスト未実施状態ＳＤは、リークテストを開始する直前の状態である。このように、車両Ｄにおいてエンジンが停止してイグニッション状態ＩＧがオフになった後で、リークテストが実施される。なお、状態ＳＤから状態ＳＥに遷移した後も、ＥＶ＿ＥＣＵ４４ではリレー４７はオンのままである。
【０１９０】
リークテストが実施されていない状況では、第１バルブ３５は、エンジン制御に起因する要因によって開度が決まる。また、リークテストが実施されていない状況では、第２バルブ３９、第３バルブ４０は、それぞれ、全開状態、全閉状態、全閉状態である。また、リークテストが実施されていない状況では、減圧ポンプ４２は非作動状態である。
【０１９１】
診断プログラム２１ｅの実行主体は、状態ＳＥでは、状態ＳＥに遷移してからの経過時間が所定の時間Ｔ１１になるまで待機する。そして、経過時間が所定の時間Ｔ１１になると、Ｖ１オフ要求、Ｖ２オン要求、Ｖ３オフ要求、ポンプオン要求を演算結果としてジョブスケジューラ２２１に送信すると共に、リークテスト実施中状態ＳＦの子状態ＳＦ１に遷移する。状態ＳＦは、診断実施中の状態であり、子状態ＳＦ１が診断の第１段階の状態、子状態ＳＦ２が診断の第２段階の状態、子状態ＳＦ３が診断の第３段階の状態に相当する。
【０１９２】
ジョブスケジューラ２２１は、当該Ｖ１オフ要求、Ｖ２オン要求、Ｖ３オフ要求、ポンプオン要求を受信すると、その後の最初のデータブロックＳｄの送信タイミングにおいて、Ｖ１オフ要求、Ｖ２オン要求、Ｖ３オフ要求、ポンプオン要求を含むデータブロックＳｄを作成し、マスタサーバ２１に送信する。マスタサーバ２１は、このデータブロックＳｄを車両Ｄに送信する。
【０１９３】
車両ＤのＥＶ＿ＥＣＵ４４は、このデータブロックＳｄをモデム１４、無線変換器４８を介して受信する。更にＥＶ＿ＥＣＵ４４は、その直後の図２２のループのＳ４２０で、このデータブロックＳｄ中のＶ１オフ要求、Ｖ２オン要求、Ｖ３オフ要求、ポンプオン要求に従って、第１バルブ３５を全閉状態にし、第２バルブ３９を全開状態にし、第３バルブ４０を全開状態にし、減圧ポンプ４２を作動させる。この結果、大気圧の外気が第１大気管３８ｂ、第２大気管３８ｃを通って減圧ポンプ４２に吸引されるようになる。
【０１９４】
そして、診断プログラム２１ｅの実行主体は、状態ＳＦ１では、状態ＳＦ１に遷移してからの経過時間が所定の時間Ｔ１２になるまで待機する。実行主体の待機中、図２７の実線５２に示すように、圧力センサ値Ｐが低下して基準オリフィス４１の通路内径に対応した圧力付近で安定する。このとき、ＥＶ＿ＥＣＵ４４は、図２２の処理において、１秒毎に、その時点における圧力センサ値Ｐを、データブロックＴに含めて送信する。そして、この圧力センサ値Ｐの値は、マスタサーバ２１、ジョブスケジューラ２２１を介して演算要求として診断プログラム２１ｅの実行主体に送信される。
【０１９５】
診断プログラム２１ｅの実行主体は、状態ＳＦ１において、経過時間が所定の時間Ｔ１２になると、その時点において車両Ｄから受信した最新の圧力センサ値Ｐを、基準圧力ＰｒｅｆとしてＲＡＭに記録する。そして更に、処理Ｇ５を実行して状態ＳＦ２に遷移する。
【０１９６】
処理Ｇ５では、診断プログラム２１ｅの実行主体は、Ｖ３オフ要求およびポンプオフ要求を演算結果としてジョブスケジューラ２２１に送信する。
【０１９７】
ジョブスケジューラ２２１は、当該Ｖ３オフ要求およびポンプオフ要求を受信すると、その後の最初のデータブロックＳｄの送信タイミングにおいて、Ｖ３オフ要求およびポンプオフ要求を含むデータブロックＳｄを作成し、マスタサーバ２１に送信する。マスタサーバ２１は、このデータブロックＳｄを車両Ｄに送信する。
【０１９８】
車両ＤのＥＶ＿ＥＣＵ４４は、このデータブロックＳｄをモデム１４、無線変換器４８を介して受信する。更にＥＶ＿ＥＣＵ４４は、その直後の図２２のループのＳ４２０で、このデータブロックＳｄ中のＶ３オフ要求およびポンプオフ要求に従って、第３バルブ４０を全閉状態に切り替え、減圧ポンプ４２を停止させる。これにより、図２７の実線５２に示すように、圧力センサ４３が検出する圧力センサ値Ｐが大気圧の値にまで上昇する。
【０１９９】
処理Ｇ５では、診断プログラム２１ｅの実行主体は更に、Ｖ１オフ要求、Ｖ２オフ要求、Ｖ３オン要求、およびポンプオン要求を演算結果としてジョブスケジューラ２２１に送信する。
【０２００】
ジョブスケジューラ２２１は、当該Ｖ１オフ要求、Ｖ２オフ要求、Ｖ３オン要求、ポンプオン要求を受信すると、その後の最初のデータブロックＳｄの送信タイミングにおいて、Ｖ１オフ要求、Ｖ２オフ要求、Ｖ３オン要求、ポンプオン要求を含むデータブロックＳｄを作成し、マスタサーバ２１に送信する。マスタサーバ２１は、このデータブロックＳｄを車両Ｄに送信する。
【０２０１】
車両ＤのＥＶ＿ＥＣＵ４４は、このデータブロックＳｄをモデム１４、無線変換器４８を介して受信する。更にＥＶ＿ＥＣＵ４４は、その直後の図２２のループのＳ４２０で、このデータブロックＳｄ中のＶ１オフ要求、Ｖ２オフ要求、Ｖ３オン要求、ポンプオン要求に従って、第１バルブ３５を全閉に維持し、第２バルブ３９を全閉に切り替え、第３バルブ４０を全開に維持する。これにより、エバポ系の内部の気体が減圧ポンプ４２によって吸引される状態になる。
【０２０２】
そして、診断プログラム２１ｅの実行主体は、状態ＳＦ２では、状態ＳＦ２に遷移してからの経過時間が所定の時間Ｔ１３になるまで待機する。もし、基準オリフィス４１の通路内径よりも大きい径のリーク穴がエバポ系にあれば、実行主体の待機中、圧力センサ値Ｐは低下するものの、図２７の実線５３のように、基準圧力Ｐｒｅｆより大きい値に留まる。もし、基準オリフィス４１の通路内径よりも小さい径のリーク穴がエバポ系にあるか、あるいはリーク穴がエバポ系に存在しないならば、実行主体の待機中、圧力センサ値Ｐは、図２７の実線５４のように、基準圧力Ｐｒｅｆより低い値にまで低下する。この待機中も、ＥＶ＿ＥＣＵ４４は、図２２の処理において、１秒毎に、その時点における圧力センサ値Ｐを、データブロックＴに含めて送信する。そして圧力センサ値Ｐの値は、ＥＶ＿ＥＣＵ４４からマスタサーバ２１、ジョブスケジューラ２２１を介して演算要求として診断プログラム２１ｅの実行主体に送信される。
【０２０３】
診断プログラム２１ｅの実行主体は、状態ＳＦ２において、経過時間が所定の時間Ｔ１３になると、その時点において車両Ｄから受信済みの最新の圧力センサ値Ｐを、圧力ＰｌｅａｋとしてＲＡＭに記録する。そして更に、状態ＳＦ３に遷移する。図２７の実線５３が実現している場合、圧力Ｐｌｅａｋ２が圧力ＰｌｅａｋとしてＲＡＭに記録される。図２７の実線５４が実現している場合、圧力Ｐｌｅａｋ１が圧力ＰｌｅａｋとしてＲＡＭに記録される。
【０２０４】
状態ＳＦ３では、診断プログラム２１ｅの実行主体は、ＲＡＭ中のＰｌｅａｋの値がＰｒｅｆの値よりも大きい場合、オンの値を有するエバポリーク判定を演算結果としてジョブスケジューラ２２１に送信する。そして当該実行主体は更に、リーク有り状態ＳＧに遷移する。
【０２０５】
また状態ＳＦ３では、診断プログラム２１ｅの実行主体は、ＲＡＭ中のＰｌｅａｋの値がＰｒｅｆの値よりも小さい場合、オフの値を有するエバポリーク判定を演算結果としてジョブスケジューラ２２１に送信する。そして当該実行主体は更に、リーク無し状態ＳＨに遷移する。
【０２０６】
ジョブスケジューラ２２１は、当該エバポリーク判定を受信すると、その後の最初のデータブロックＳｄの送信タイミングにおいて、当該エバポリーク判定を含むデータブロックＳｄを作成し、マスタサーバ２１に送信する。マスタサーバ２１は、このデータブロックＳｄを車両Ｄに送信する。
【０２０７】
車両ＤのＥＶ＿ＥＣＵ４４は、このデータブロックＳｄをモデム１４、無線変換器４８を介して受信する。更にＥＶ＿ＥＣＵ４４は、その直後の図２２のループのＳ４３０で、このデータブロックＳｄ中のエバポリーク判定の値を、フラッシュメモリに記録する。図２７の実線５３が実現した場合は、オンの値のエバポリーク判定が記録され、実線５４が実現した場合は、オフの値のエバポリーク判定が記録される。
【０２０８】
リーク有り状態ＳＧにおいて、診断プログラム２１ｅの実行主体は、リーク有り状態ＳＧに遷移してから所定期間が経過したことに基づいて、車両Ｄで診断結果（すなわちエバポリーク判定）が記録されたと判定し、リレーオフ要求を演算結果としてジョブスケジューラ２２１に送信すると共に、＋Ｂオフ状態ＳＩに遷移する。これにより、車両Ｄのエバポ系の診断が終了する。
【０２０９】
また、リーク無し状態ＳＨにおいて、診断プログラム２１ｅの実行主体は、リーク無し状態ＳＨに遷移してから所定期間が経過したことに基づいて、車両Ｄで診断結果（すなわちエバポリーク判定）が記録されたと判定し、リレーオフ要求を演算結果としてジョブスケジューラ２２１に送信すると共に、＋Ｂオフ状態ＳＩに遷移する。これにより、車両Ｄのエバポ系の診断が終了する。
【０２１０】
ジョブスケジューラ２２１は、リレーオフ要求を受信すると、その後の最初のデータブロックＳｄの送信タイミングにおいて、リレーオフ要求を含むデータブロックＳｄを作成し、マスタサーバ２１に送信する。マスタサーバ２１は、このデータブロックＳｄを車両Ｄに送信する。
【０２１１】
車両ＤのＥＶ＿ＥＣＵ４４は、このデータブロックＳｄをモデム１４、無線変換器４８を介して受信する。更にＥＶ＿ＥＣＵ４４は、その直後の図２２のループのＳ４２０で、このデータブロックＳｄ中のリレーオフ要求に従って、リレー４７をオフにする。図２７に示すように、この時点で、既にＩＧスイッチ４６はオフである。したがって、この時点でＥＶ＿ＥＣＵ４４は電力供給を受けられなくなり、停止する。
【０２１２】
なお、診断プログラム２１ｅの実行主体は、状態ＳＦ（すなわち、状態ＳＦ１、ＳＦ２、ＳＦ３）において、サーバ側リアルタイム性の値がＮＧである場合、状態ＳＥに遷移する。つまり、エバポ系の診断中にリアルタイム性が損なわれた場合は、診断を中止する。状態ＳＥに遷移した後は、状態ＳＥに遷移してからの経過時間が所定の時間Ｔ１１になれば、上述の通りの処理で状態ＳＦ１に遷移する。
【０２１３】
このように、診断プログラム２１ｅの実行主体が診断プログラム２１ｅを実行して各状態間を遷移している間も、上述の通り、１秒周期で車両Ｄからクラウド４００にデータブロックＴが送信され、１秒周期でクラウド４００から車両Ｄにデータブロックが送信される。ただし、通信の遅延等の要因により、送信されたデータがすぐに宛先に届かない場合がある。
【０２１４】
ここで、診断プログラム２１ｅがパラメータとして用いるサーバ側リアルタイム性について説明する。リアルタイム性とは、タイムラグＬが基準時間よりも短いことをいう。タイムラグＬは、第１処理時間、第１通信時間、第２処理時間、第２通信時間、第３処理時間の総和である。第１処理時間は、車載システム３０内の作動状態を示す状態量（例えば、圧力センサ値Ｐ、イグニッション状態ＩＧ）が車載システム３０で検出されてから送信されるまでの時間である。第２処理時間は、上記状態量が車載システム３０から送信されて診断プログラム２１ｅの実行主体で受信されるまでの時間である。第２処理時間は、当該実行主体が当該状態量を受信してから、診断プログラム２１ｅの実行において当該状態量を利用して利用結果のデータ（例えば、エバポリーク判定、リレーオン要求、Ｖ２オン要求）を生成して送信するまでの時間である。第２通信時間は、当該実行主体が当該利用結果のデータを送信してから車載システム３０が受信するまでの時間である。第３処理時間は、車載システム３０が当該当該利用結果のデータを受信してから、当該データを制御に反映するまでの時間である。
【０２１５】
上述の通り、エバポ系の診断にはクラウド４００がこれらアクチュエータ３５、３９、４０、４２を遠隔制御するので、リアルタイム性が無いときにこのような診断を実行するのは困難である。また、診断プログラム２１ｅは、アクチュエータ３５、３９、４０、４２を制御するための複雑な制御を記述する必要があるので、データサイズが大きくなりがちである。したがって、このような診断プログラム２１ｅをＥＶ＿ＥＣＵ４４側で実行するよりもクラウド４００側で実行することで、ＥＶ＿ＥＣＵ４４の処理負荷の低減効果およびメモリ容量の節約効果が大きい。
【０２１６】
本実施形態では、上記総和の時間が所定時間より短いか否かで、リアルタイム性の有無が判断される。ここで、車載システム３０内の作動状態を示す状態量は、なお、車載システム３０内の制御は、具体的には、第１バルブ３５、第２バルブ３９、第３バルブ４０、減圧ポンプ４２の制御、記憶媒体への記録等である。
【０２１７】
本実施形態では、診断プログラム２１ｅの処理は、基本的に複数のワーカ２２１ｐ、２２１ｑに分散されて実行されるので、処理自体に遅延が発生することはあまりない。したがって、車載システム３０からクラウド４００へのデータブロックＴの送信、および、クラウド４００から車載システム３０へのデータブロックＳの送信による遅延が共に小さければ（例えば各々０．５秒未満なら）リアルタイム性はＯＫ（良好）である。しかし、車載システム３０からクラウド４００へのデータブロックＴの送信、および、クラウド４００から車載システム３０へのデータブロックＳの送信いずれかに大きな遅延（例えば４秒）があれば、リアルタイム性はＮＧ（不良）であり、適切なエバポ系の診断が行えない可能性が高くなる。
【０２１８】
そこで、本実施形態では、診断プログラム２１ｅにおいては、リアルタイム性の判定結果に基づいて、上述のような作動が規定されている。すなわち、エバポ系の診断を行っている状態ＳＦにおいてリアルタイム性がＮＧならば、状態ＳＥに戻ることで、エバポ系の診断を中止する。
【０２１９】
次に、このようなリアルタイム性を判定するための量である車側カウント値およびクラウド側カウント値について説明する。車両ＤのＥＶ＿ＥＣＵ４４は、既に説明した通り、図２２の処理において、１秒毎に、ステップＳ４７０で、車側カウント値の値を１だけ増加させ、ステップＳ４８０で、当該車側カウント値を含むデータブロックＴａを送信する。そして、この車側カウント値は、マスタサーバ２１、ジョブスケジューラ２２１を介して演算要求としてカウントプログラム２１ｆの実行主体に送信される。
【０２２０】
カウントプログラム２１ｆの実行主体（ワーカ２２１ｐ、２２１ｑ）は、ジョブスケジューラ２２１からこのカウントプログラム２１ｆの演算要求を受信したときに、このカウントプログラム２１ｆの実行を開始し、その後継続的に実行する。
【０２２１】
そしてカウントプログラム２１ｆの実行主体は、カウントプログラム２１ｆの実行において、図２８に示すように、まずステップ５１０で、車側カウント値を受信するまで待ち、受信すると、ステップＳ５２０に進み、直前のステップ５１０で受信した車側カウント値と同じ値をクラウド側カウント値とする。そして、当該クラウド側カウント値を演算結果としてジョブスケジューラ２２１に送信する。
【０２２２】
ジョブスケジューラ２２１は、当該クラウド側カウント値を受信すると、その後の最初のデータブロックＳｄの送信タイミングにおいて、当該クラウド側カウント値を含むデータブロックＳｄを作成し、マスタサーバ２１に送信する。マスタサーバ２１は、このデータブロックＳｄを車両Ｄに送信する。
【０２２３】
車両ＤのＥＶ＿ＥＣＵ４４は、このデータブロックＳｄをモデム１４、無線変換器４８を介して受信する。更にＥＶ＿ＥＣＵ４４は、その直後の図２２のループのＳ４６０で、このデータブロックＳｄ中のクラウド側カウント値を用いて、リアルタイム性判定を行う。
【０２２４】
ＥＶ＿ＥＣＵ４４は、リアルタイム性判定においては、図２９に示すように、まずステップ６１０にて、直前のステップＳ４１０で受信したクラウド側カウント値を現在の車側カウント値から減算した値が２未満（すなわち１または０）であるか否かを判定する。
【０２２５】
そして、２未満であると判定した場合ステップ６２０に進み、２以上であると判定した場合ステップ６３０に進む。ステップ６２０では、リアルタイム有効であると判定してステップＳ４６０の処理を終了する。ステップ６３０では、リアルタイム無効であると判定してステップＳ４６０の処理を終了する。
【０２２６】
ステップＳ４６０でリアルタイム無効であると判定した場合は、続いてステップＳ４８０において、リアルタイム有効のデータをデータブロックＴに含めて送信しない。ステップＳ４６０でリアルタイム有効であると判定した場合は、続いてステップＳ４８０において、リアルタイム有効のデータをデータブロックＴａに含めて送信する。そして、このリアルタイム有効のデータは、マスタサーバ２１、ジョブスケジューラ２２１を介して演算要求としてリアルタイム性判定プログラム２１ｇの実行主体に送信される。
【０２２７】
ここで、リアルタイム性判定プログラム２１ｇの規定する作動について、図３０を参照して説明する。リアルタイム性判定プログラム２１ｇの実行主体（ワーカ２２１ｐ、２２１ｑ）は、ジョブスケジューラ２２１からこのリアルタイム性判定プログラム２１ｇの演算要求を受信したときに、このリアルタイム性判定プログラム２１ｇの実行を開始し、その後継続的に実行する。
【０２２８】
リアルタイム性判定プログラム２１ｇでは、サーバ側リアルタイム性ＮＧ状態ＳＲ、サーバ側リアルタイム性ＯＫ状態ＳＳという、２つの状態が規定されている。状態ＳＲは始状態である。
【０２２９】
当該実行主体は、状態ＳＲにおいて、上記リアルタイム有効のデータを受信すると、ＲＡＭ中のサーバ側リアルタイム性の値を「ＯＫ」に設定し、状態ＳＳに遷移する。また、当該実行主体は、状態ＳＳにおいて、上記リアルタイム有効のデータを２秒以上受信しないと、ＲＡＭ中のサーバ側リアルタイム性の値を「ＮＧ」に設定し、状態ＳＲに遷移する。このようにリアルタイム性判定プログラム２１ｄの実行によって設定されたサーバ側リアルタイム性の値は、上述の通り、診断プログラム２１ｅにて使用される。
【０２３０】
このように、本実施形態の通信システムでは、車両ＤのＥＶ＿ＥＣＵ４４が車側カウント値を１秒毎にカウントアップする。そして当該ＥＶ＿ＥＣＵ４４からマスタサーバ２１およびジョブスケジューラ２２１を介してワーカへ車側カウント値がデータブロックＴに含まれて送信される。そして、ワーカは、受信した車側カウント値と同じ値のクラウド側カウント値をデータブロックＳに含めて送信し、当該クラウド側カウント値はジョブスケジューラ２２１およびマスタサーバ２１を介して当該ＥＶ＿ＥＣＵ４４に届く。したがって、当該ＥＶ＿ＥＣＵ４４は、自機が車側カウント値を送信してから、当該車側カウント値に対する応答をクラウド４００から受信するまでの時間（すなわち、両者の通信に要する時間）に基づいて、リアルタイム性の判定を行っている。つまり、車側カウント値は、リアルタイム性の確認用のタイムデータであり、クラウド側カウント値は、当該タイムデータに対する応答である。
【０２３１】
そして、リアルタイム性は、この両者の通信に要する時間が、所定の範囲を、つまり、受信したクラウド側カウント値と現在の車側カウント値との差が２未満となる範囲を、超えているか否かで判定される。
【０２３２】
以上説明した通り、本実施形態においては、ＥＶ＿ＥＣＵ４４（制御装置の一例に相当する）は、ＥＶ＿ＥＣＵ４４と１台以上のサーバとの間の通信に要する時間が所定の基準を超えているか否か判定し、超えていない場合にのみリアルタイム有効のデータをクラウド４００に送信する。そして、クラウド４００は、リアルタイム有効のデータを過去２秒以内に受けているか否かに基づいて、リアルタイム性の有無を判定する。そしてクラウド４００は、リアルタイム性が無い場合は、状態ＳＦから状態ＳＥに遷移することで、エバポ系の診断、より具体的には、蒸発燃料のリークの有無の判定を、中止する。
【０２３３】
このように、ＥＶ＿ＥＣＵ４４とクラウド４００との間の通信の遅延が所定の基準を超えて大きいときに、エバポ系の診断が中止されるという形で、リアルタイム性の判定が実現されている。これにより、リアルタイム性が不良で適切なエバポ系の診断が行えない可能性が高い場合にまで、エバポ系の診断を続けることの無駄を低減できる。
【０２３４】
なお、本実施形態では、ワーカ２２１ｐ、２２１ｑが、診断プログラム２１ｅを実行することで、検査手段の一例として機能し、リアルタイム性判定プログラム２１ｇを実行することで判定手段の一例として機能する。
【０２３５】
（他の実施形態）
なお、本発明は上記した実施形態に限定されるものではなく、特許請求の範囲に記載した範囲内において適宜変更が可能である。また、また、上記実施形態において、実施形態を構成する要素は、特に必須であると明示した場合および原理的に明らかに必須であると考えられる場合等を除き、必ずしも必須のものではないことは言うまでもない。また、上記実施形態において、実施形態の構成要素の個数、数値、量、範囲等の数値が言及されている場合、特に必須であると明示した場合および原理的に明らかに特定の数に限定される場合等を除き、その特定の数に限定されるものではない。また、上記実施形態において、構成要素等の形状、位置関係等に言及するときは、特に明示した場合および原理的に特定の形状、位置関係等に限定される場合等を除き、その形状、位置関係等に限定されるものではない。また、本発明は、上記実施形態に対する以下のような変形例も許容される。なお、以下の変形例は、それぞれ独立に、上記実施形態に適用および不適用を選択できる。すなわち、以下の変形例のうち任意の組み合わせを、上記実施形態に適用することができる。
【０２３６】
（変形例１）
上記実施形態では、空調パネル制御装置１２５が送信する車側カウント値は、直前に受信したクラウド側カウント値と値が同じになっている。しかし、必ずしもこのようにする必要はなく、車側カウント値は、直前に受信したクラウド側カウント値に対応する値であることがわかるような値であればよい。例えば、車側カウント値は、直前に受信したクラウド側カウント値に対して予め定められた演算を施した後の値であってもよい。この場合クラウド２００のワーカ２２１ｐ、２２１ｑは、リアルタイム性判定プログラム２１ｄのステップＳ２６０で、車側カウント値を受信した時刻とクラウド側カウント値を受信した時刻との差が２秒を超えているか否かを判定することで、リアルタイム性を判定できる。
【０２３７】
（変形例２）
また、クラウド２００は、必ずしもクラウド側カウント値を送信する必要はなく、空調パネル制御装置１２５がクラウド２００に一方的に送信時刻を含む車側カウント値を送信し、クラウド２００のワーカ２２１ｐ、２２１ｑは、この車側カウント値を受信した時刻から、当該車側カウント値に含まれる送信時刻を減算した値が２秒を超えているか否かを判定することで、リアルタイム性を判定できる。
【０２３８】
（変形例３）
また、クラウド２００は、クラウド側カウント値に代えて、現在時刻情報を送信するようになっていてもよい。その場合、その後のクラウド２００も車載システム１００も、クラウド側カウント値と同様に現在時刻情報を用いれば、上記実施形態と同様の効果を得ることができる。なお、クラウド２００内のカウントプログラム２１ｃの実行主体は、現在時刻情報を、自機内のカウントプログラム２１ｃ以外の処理で計測してもよいが、他の装置（例えばネットワーク上のタイムサーバ）から取得してもよい。
【０２３９】
（変形例４）
上記実施形態では、クラウド２００（より具体的にはワーカ２２１ｐ、２２１ｑ。以下同じ。）が、カウントプログラム２１ｃ、リアルタイム性判定プログラム２１ｄを実行し、空調パネル制御装置１２５がカウント返送処理１２５ｃを実行するようになっている。つまり、クラウド２００から空調パネル制御装置１２５へカウント値（クラウド側カウント値）か送信され、それと同じ値のカウント値（車側カウント値）が空調パネル制御装置１２５からクラウド２００に返送され、２つのカウント値の差に基づいてクラウド２００がリアルタイム性の判定を行っている。
【０２４０】
しかし、必ずしもこのようになっておらずともよく、リアルタイム性の判定は空調パネル制御装置１２５で行われるようになっていてもよい。つまり、空調パネル制御装置１２５からクラウド２００へカウント値か送信され、それと同じ値のカウント値がクラウド２００から空調パネル制御装置１２５に返送され、２つのカウント値の差に基づいて空調パネル制御装置１２５がリアルタイム性の判定を行ってもよい。
【０２４１】
このようにするためには、例えば、クラウド２００がカウント返送処理１２５ｃを実行し、空調パネル制御装置１２５がカウントプログラム２１ｃ、リアルタイム性判定プログラム２１ｄの処理を実行するようになっていてもよい。ただしその際、各処理中でデータの送信先等については適宜修正する。また、これら処理に必要な情報は、クラウド２００と空調パネル制御装置１２５の間の通信によって互いに授受できるようにする。
【０２４２】
（変形例５）
また、Ａ／Ｃ＿ＥＣＵ１１が空調パネル制御装置１２５の代わりに空調パネル制御装置１２５の機能を実現するようになっていてもよい。逆に、空調パネル制御装置１２５がＡ／Ｃ＿ＥＣＵ１１の代わりにＡ／Ｃ＿ＥＣＵ１１の機能を実現するようになっていてもよい。
【０２４３】
（変形例６）
上記実施形態では、クラウド２００は複数台のサーバ２１、２２１、２２２、２２３、２２１ｐ、２２１ｑ、２２２ｐ、２２２ｑ、２２３ｐ、２２３ｑで実現されているが、１台のサーバで実現されていてもよい。つまり、クラウド２００は、どのような台数のサーバで実現されていてもよい。
【符号の説明】
【０２４４】
２                    コンプレッサ
１２                  クラウド対応空調パネル
２１ｂ                冷媒検査プログラム
２１ｄ                リアルタイム性判定プログラム
１００                車載システム
１２５                空調パネル制御装置
２００                クラウド
Ｗ、Ｘ、Ｙ、Ｚ        データブロック
【図１】
0006507950.tif 000002
【図２】
0006507950.tif 000003
【図３】
0006507950.tif 000004
【図４】
0006507950.tif 000005
【図５】
0006507950.tif 000006
【図６】
0006507950.tif 000007
【図７】
0006507950.tif 000008
【図８】
0006507950.tif 000009
【図９】
0006507950.tif 000010
【図１０】
0006507950.tif 000011
【図１１】
0006507950.tif 000012
【図１２】
0006507950.tif 000013
【図１３】
0006507950.tif 000014
【図１４】
0006507950.tif 000015
【図１５】
0006507950.tif 000016
【図１６】
0006507950.tif 000017
【図１７】
0006507950.tif 000018
【図１８】
0006507950.tif 000019
【図１９】
0006507950.tif 000020
【図２０】
0006507950.tif 000021
【図２１】
0006507950.tif 000022
【図２２】
0006507950.tif 000023
【図２３】
0006507950.tif 000024
【図２４】
0006507950.tif 000025
【図２５】
0006507950.tif 000026
【図２６】
0006507950.tif 000027
【図２７】
0006507950.tif 000028
【図２８】
0006507950.tif 000029
【図２９】
0006507950.tif 000030
【図３０】
0006507950.tif 000031