JP2022128435A - 検出デバイスの監視方法及びサーバ - Google Patents

Abstract

【課題】本発明は、自動車検知装置を監視するためのサーバ及びその方法を提供する。【解決手段】本サーバは、第１のリンクを通じて通信装置と通信するための送受信部と、送受信部に連結された制御部と、を備え、制御部は、第２のリンクを通じて検出デバイスと通信する通信装置から第１のリンクを通じて、検出デバイスによって検出された対象装置の状態データを受信することと、通信装置に制御命令を送信して、検出デバイスを、制御命令に従って動作するように制御することと、を行う。【選択図】図２

Description

本発明は、自動車電子部品の監視、特に自動車、例えば空調フィルタエレメントの能動的な監視に関する。

背景技術
車両の普及に伴い、運転手又は同乗者は、職場への通勤又は業務上の移動にかかわらず、運転中に車内において長い時間を過ごす必要がある。運転室内のスペースが狭く空気の循環が悪いことから、人々は、車内の空気中の微生物によるアレルギーや大気汚染の影響を受け易くなっている。このため、空調を正しく使用し、空調の最良の動作状態を保持することは、乗員の健康にとって非常に重要である。空調システムにおいては、空調フィルタエレメントを使用して空気中の微生物やほこりなどの汚染物質を濾過するため、その動作状態の良し悪しは、空気の質に非常に大きな影響を与える。しかし、フィルタエレメントは、車内の手の届きにくい場所に設けられることが多いため、フィルタエレメントを検査する負担が大きくなっている。

従来技術においては、フィルタエレメントの動作状態を検査し易くするために、通常、フィルタエレメントの上又はフィルタエレメントの近傍に検出デバイスが設けられている。この検出デバイスは、センサモジュールを備えており、センサモジュールは、１つ又は複数のセンサ、例えば、温度センサ、湿度センサ、ＲＧＢセンサ、飛行時間（ＴＯＦ）センサなどであり得る。検出デバイスは、センサモジュールを通じてフィルタエレメントの動作状態／環境に関する状態データを収集し、バックグラウンド、例えば、車両コンソールに送信する。これにより、コンソールは、検出デバイスから取得されたフィルタエレメントの動作状態データに基づいて、フィルタエレメントの健康状態を特定する。

しかし、従来技術における方法によると、車両コンソールは、検出デバイスからフィルタエレメントの状態に関するデータを受動的に収集することしかできず、情報を収集する役割としてのみ機能している。また、車両コンソールは、検出デバイスを逆の方向に制御すること、例えば、データアップロード頻度を制御することができず、さらに、アップロードされた状態データを選択的に受信することができない。さらに、検出デバイスと車両コンソールとの間のリンクが遮断された状況においては、検出デバイスは接続を失い、また、検出デバイスに動作故障が発生していても効果的に診断することができない場合もある。

発明の概要
本発明は、リモートサーバを利用して自動車の空調フィルタエレメントの検出デバイスの監視及び警報を行うための方法を提案するものであり、検出デバイスからアップロードされた検出された状態データを収集することができるだけでなく、検出自体の動作パラメータの制御及びアップロードされた状態データのカスタマイズなどを含む、検出デバイスの動作状態を制御することもできる。さらに、リモートサーバを利用することにより、異なる対象物に対して柔軟に警報信号を送信することもできる。

本発明の１つの態様によれば、自動車用の検出デバイスを監視する方法が提供され、本方法は、第２のリンクを通じて検出デバイスと通信する通信装置と第１のリンクを通じて通信して、検出デバイスによって検出された対象装置の状態データを受信することと、通信装置に制御命令を送信して、検出デバイスを、制御命令に従って動作するように制御することと、を含む。一例として、本明細書における対象装置は、自動車空調フィルタエレメントなどであり得る。

好ましくは、制御命令は、検出デバイスをデバッグするためのデバッグ命令であり、デバッグ命令は、動作パラメータを含み、動作パラメータは、検出デバイスが対象装置の状態データをアップロードするアップロード頻度と、状態データをアップロードするための信号強度と、状態データに含まれる検知データタイプに対するカスタマイズと、のうちの少なくとも１つである。

好ましくは、通信装置から、検出デバイスのデバッグ命令に対する応答信号を受信し、応答信号に基づいて、検出デバイスの動作状態を判断することをさらに含み、応答信号は、検出デバイスの状態データを含み、状態データは、異なるタイプの検知データを含む。応答信号に基づいて、検出デバイスの動作状態を判断することは、続けて受信した応答信号がアップロード頻度と一致するかどうかを特定し、アップロード頻度と一致しない場合に、検出デバイスが故障したことを特定する。他の例においては、応答信号に基づいて、検出デバイスの動作状態を判断することは、応答信号中の状態データにエラーが存在するかどうかを特定することを含み、エラーが存在する場合に、本方法は、通信装置に他のデバッグ命令を発行して、検出デバイスを、信号強度を増強するように制御し、及び／又は、状態データに含まれる検知データのタイプ及び数量を調整するように制御する。

好ましくは、本発明に係る方法によれば、増強された信号強度で、検出デバイスによって送信された応答信号中の状態データに誤差が存在するかどうかを検出することをさらに含み、誤差が存在しない場合に、増強された信号強度を検出デバイスの最適送信信号強度に設定し、誤差が続けて存在する場合に、検出デバイス内の誤差が存在する検知データに対応するセンサに故障が発生したことを判定する。

本発明の一例による検出デバイスのための監視システムを示す図である。 本発明の一例による検出デバイスをリセットする方法フローを示す図である。 本発明の一例による検出デバイスをデバッグする方法フローを示す図である。 本発明の一例によるサーバ３００の概略図である。

発明を実施するための形態
本発明の実施例によって提供される方法及び装置を、添付の図面と併せて以下に詳細に説明する。本開示の好ましい実施例が添付図面に示されているが、本開示は、種々の形態において具現化することができ、本明細書に記載された実施形態に限定されるべきではないことを理解されたい。むしろ、これらの実施形態は、本開示をより一貫した完全なものにし、本開示の完全な範囲を当業者に伝えることができるようにするために提供されている。

図１は、本発明の一例による検出デバイスのための監視システムを示している。このシステムは、対象装置、例えば、車両付属デバイスの動作状態に対する監視を実施することができる。このような付属デバイスは、例えば、空調フィルタエレメントであり得る。この監視により、運転室内の空気の質の状況を特定し、事前に登録された対象監視ユーザに、フィルタエレメントを交換する必要があるかどうかに関する警告情報を送信することができる。本明細書の対象監視ユーザは、車両のユーザ、空調フィルタエレメントの所有者であるものとしてよく、また、検出デバイスと接続を確立する移動端末のユーザであるものとしてよく、移動端末は、ユーザスマートフォンであるものとしてよい。この監視システムは、検出デバイス１００を監視するための通信装置２００と、リモートサーバ３００と、を備える。本発明の一実装においては、検出デバイス１００は、センサモジュール１０１と情報送受信モジュール１０２とにより構成されており、センサモジュール１０１は、１つ以上のセンサ１０１－１、１０１－２、…１０１－Ｎを含み得る。これらは、例えば、温度センサ、湿度センサ、ＲＧＢセンサなどであり得る。これらのセンサは、フィルタエレメントの上又は周囲に設けられ、フィルタエレメントに関連付けられている複数の濾過パラメータＰ１、Ｐ２、…ＰＮ、例えば、温度パラメータ、湿度パラメータなどを検出するように構成されている。情報送受信モジュール１０２とセンサモジュール１０１とは、センサモジュール１０１からフィルタエレメントに関する状態パラメータＰ１、Ｐ２、…ＰＮを受信するために、共通して又は他の方法により接続されている。本実施例によれば、情報送受信モジュール１０２は、無線通信機能、例えば、内蔵型Ｂｌｕｅｔｏｏｔｈモジュール、ＬｏＲＡモジュール、ＮＢ－ＩｏＴモジュール、セルラ通信モジュール又はＳｉｇｆｏｘモジュールなどを備え、このモジュールは、収集したフィルタエレメントの状態パラメータＰ１、Ｐ２、…ＰＮのうちの１つ又は複数を、設定された要件に従って通信装置２００に送信するために、通信装置２００と通信する。また、一例として、情報送受信モジュール１０２は、通信装置２００から制御指令を受信し、この指令に基づいて動作状態又は条件、例えば、アップロード状態パラメータの頻度、又は、任意選択により、アップロード状態パラメータを変更するようにさらに構成されるものとしてもよい。

本例においては、通信装置２００は、情報受信及び送信機能を有し、１つ又は複数の通信プロトコルをサポートすることができ、また、任意の形態で存在することができ、例えば、通信装置２００は、移動端末、例えば、対象監視ユーザのスマートフォンであるものとしてもよく、その内部には、プログラム（例えば、アプリケーション又はその他のアプレットの形態により表される）及び通信モジュール（例えば、Ｂｌｕｅｔｏｏｔｈ通信モジュール、又は、ＮＢ－ＩｏＴモジュール、ＬｏＲＡモジュール、Ｓｉｇｆｏｘモジュール、セルラ通信モジュール、例えば４Ｇ若しくは５Ｇ無線線通信モジュール）が事前にインストールされている。通信装置２００はまた、Ｂｌｕｅｔｏｏｔｈ、ＮＢ－ＩｏＴ、ＬｏＲＡ、Ｓｉｇｆｏｘ、セルラ通信、例えば、４Ｇ又は５Ｇなどの通信をサポートする他の無線通信装置であるものとしてもよい。本発明によれば、通信装置２００は、検出デバイス１００と、第１の通信プロトコル、例えば、Ｂｌｕｅｔｏｏｔｈプロトコルを通じて通信すると共に、第２の通信プロトコル、例えば、ＳｉｇＦｏｘ、ＬｏＲＡ、ＮＢ－ＩｏＴ、４Ｇ／５Ｇに従って、リモートサーバ３００と通信し、また、同様のプロトコルを用いて検出デバイス１００及びリモートサーバ３００と通信することもできる。本発明の実施例の以下の説明においては、対象監視ユーザの携帯電話によって実装される通信装置２００を例に説明する。本開示の内容において、表記２００は、携帯電話も示しており、また、通信装置も示している。

携帯電話２００のユーザは、携帯電話２００と検索された検出デバイス１００との通信を（例えば、Ｂｌｕｅｔｏｏｔｈプロトコルに従って、検出デバイス１００内の情報送受信モジュール１０２とペアリングすることによって）確立すると、検出デバイス１００と通信して、検出デバイス１００によって取得された空調フィルタエレメントに関する状態データＳｔａｔｕｓＤａｔａ（検出デバイス１００内部のセンサモジュール１０１によってそれぞれ取得された検知データＰ１、Ｐ２、…ＰＮのうちの１つ又は複数）を受信することができる。一例として、検出デバイス１００を特定の空調フィルタエレメントに又は特定のユーザに対応するものとして識別し易くするために、検出デバイス１００の標識情報はＤｅｖｉｃｅＩＤにより示され、これは、通常、例えばＢｌｕｅｔｏｏｔｈデバイス識別情報に構成され、例えばＩＣＦｘｘｘの形式でＢｌｕｅｔｏｏｔｈ識別情報が構成され、この識別情報ＤｅｖｉｃｅＩＤは、デフォルトで車両の一意の識別情報、例えば、車両のフレーム番号若しくはエンジン番号、又は、車両フィルタエレメントの識別番号などであるものとしてよい。ユーザは、ユーザ識別情報ＵｓｅｒＩＤにより示され、このＩＤは、通常、例えば、ユーザ名、郵便番号、電話番号などであるものとしてよい。

なお、ここでは、上記の説明及び以下の実施例の説明において、検出デバイス１００がアップロードするデータについては、空調フィルタエレメントを対象として検出された検知データであるということに留意されたい。しかし、本発明は、これに限定されるものではなく、検出デバイスを対象として検出されたデータであると考えることができ、車両を対象として検出されたデータとすることもできる。具体的に対象とするものを事前に決定するものとしてもよい。

本発明の例によれば、内蔵型のアプリケーションを通じて、携帯電話２００は、無線通信リンク（例えば、セルラ通信（４Ｇ又は５Ｇ）、リモート通信（例えば、Ｓｉｇｆｏｘ通信など））を介してサーバ３００と通信し、検出デバイス１００から受信した状態データＳｔａｔｕｓＤａｔａをサーバ３００にアップロードする。ここにおけるアプリケーションは、ユーザが指定されたウェブサイトから携帯電話２００にダウンロードすることができる。さらに、サーバ３００はまた、携帯電話２００を通じて検出デバイス１００に制御命令を送信して、サーバ３００に情報を報告するように検出デバイス１００を制御することもできる。本発明の任意選択の他の実施例においては、検出デバイス１００がリモート通信機能を有する場合、サーバ３００の命令を検出デバイス１００に直接送信することにより、中間通信装置又は携帯電話２００の必要性をなくすこともできる。

本発明の実施例によれば、サーバ３００は、検出デバイス１００のアップロード通信を制御することができ、このような制御は、下記のうちの少なくとも１つを含み得る：
－状態データＳｔａｔｕｓＤａｔａ中の検知データタイプを選択的にアップロードするように、制御検出デバイス１００を制御すること。例えば、Ｎ個のタイプのセンサが取得した検知データ（Ｐ１、Ｐ２、…ＰＮ）のうちのＭ個のタイプのデータ（Ｍは、Ｎ以下である）をアップロードし又はＭ個のセンサを動作させ、残余のＮ－Ｍ個のセンサは動作させないように、検出デバイス１００を制御する。
－状態データＳｔａｔｕｓＤａｔａの頻度Ｆをアップロードするように検出デバイス１００を制御する、例えば、検出デバイス１００がＳｔａｔｕｓＤａｔａをアップロードする時間間隔を設定すること。一例として、検出デバイス１００は、センサモジュール１００内のいくつかのセンサの頻度を変更することによってこれを実施する。

サーバ３００は、空調エアフィルタの使用状況の監視を実施するために、自動車メーカ若しくは自動車ディーラ又はクラウド上において運営される。サーバ３００には、携帯電話２００と通信するための無線通信モジュール、例えば、４Ｇ又は５Ｇモジュール、Ｓｉｇｆｏｘモジュール、ＮＢ－ＬｏＴモジュールなどが設けられている。携帯電話２００からダウンロードしたアプリケーションを利用して、検出デバイス１００をサーバ３００側に登録することができる。携帯電話アプリケーションは、検出デバイス１００の識別情報ＤｅｖｉｃｅＩＤとユーザ識別情報ＵｓｅｒＩＤとを紐付けし、識別情報ＤｅｖｉｃｅＩＤ、ユーザ識別情報ＵｓｅｒＩＤ及びその紐付け関係情報をサーバ３００側に登録することができる。サーバ３００は、この登録情報をサーバ３００内部又はサーバ３００がアクセスし得るデータベースＤＢに記憶する。紐付けが成功すると、データベースＤＢ内において、この車両若しくはこの空調フィルタエレメント又はこの検出デバイスの１つの記録が生成され、例として、各記録は、例えば、下記のフィールドを含み得る：
ＤｅｖｉｃｅＩＤ：検出デバイスの識別情報を記憶する
ＵｓｅｒＩＤ：対象監視ユーザの識別情報を記憶する
Ｃｏｎｎｅｃｔｉｖｉｔｙ：サーバ３００と検出デバイス１００との接続確立時間を記憶する。この接続確立時間は、検出デバイス１００がサーバ３００に登録された時間又は再接続時間である
ＩｎｓｔａｌｌａｔｉｏｎＤａｔｅ：フィルタエレメントの取り付け／交換日を記憶する
ＯｐｅｒａｔｉｏｎＰａｒａ：検出デバイス１００の動作パラメータ、例えば、アップロード頻度Ｆ、及び、検出デバイス１００にアップロードされるデータの信号強度Ｓｔｒｅｎｇｔｈを記憶するために使用される
ＤａｔａＴｙｐｅＲｅｐｏｒｔ：検出デバイス１００にアップロードされる検知データのタイプを指定する、例えば、Ｎ個のセンサ中のＭ個のデータをアップロードするように指定するために使用される
ＦｉｌｔｅｒＬｉｆｅ：フィルタエレメントの耐用年数を記憶する
ＢｉｎｄｉｎｇＳｅｔ：検出デバイス１００と対象監視ユーザとの関連性を記憶するために使用される。例えば、このフィールドを通じて、１つの検出デバイスＤｅｖｉｃｅＩＤで対象監視ユーザＵｓｅｒＩＤがいくつ紐付けられているかを特定することができ、また、１つの対象監視ユーザＵｓｅｒＩＤで検出デバイスＤｅｖｉｃｅＩＤがいくつ紐付けられているかも特定することができる
Ｈｉｓｔｏｒｙ：検出デバイスがアップロードする履歴状態データＳｔａｔｕｓＤａｔａを記憶するために使用され、このデータは、検出デバイス１００によってアップロードされるフィルタエレメントに関する各回の状態検出結果ＳｔａｔｕｓＤａｔａを含み、この検出結果は、検出デバイス１００中の複数のセンサの検知データ（Ｐ１、Ｐ２、…ＰＮ）のうちの少なくとも一部を含む。

サーバ３００は、各回の検出されたＳｔａｔｕｓＤａｔａに基づいて、フィルタエレメントの現在の状況を判断し、また、例えば、ライフサイクルを算出して、寿命フィールドであるＦｉｌｔｅｒＬｉｆｅフィールド内に記憶する。耐用年数が規定された上限値を下回ると、サーバ３００は、ＵｓｅｒＩＤが示す対象監視ユーザに警報指示を発行する。リモートサーバ３００を設けることの利点は、従来技術のように、専用の検出装置を使用して車両センサ又は検出デバイスを直接読み取ることによりデータを得る必要がなく、車両情報を一元的に維持及び処理することができることである。

本発明の実施例によれば、サーバ３００は、通信装置２００を通じて検出デバイス１００がアップロードしたフィルタエレメント状態データＳｔａｔｕｓＤａｔａを受信することができること、即ち、アップリンク方式で状態データＳｔａｔｕｓＤａｔａを受信することができることに加えて、ダウンリンク方式で検出デバイス１００を制御することができる。これは、紐付け関係を更新することにより検出デバイス１００の検出を実施することと、状態データＳｔａｔｕｓＤａｔａ中の検知データタイプを選択的にアップロードすること、即ち、検知データ（Ｐ１、Ｐ２、…ＰＮ）のうちのどのデータをサーバ３００にアップロードするかを決定するために検出デバイス１００に命令するために、検出デバイス１００を構成することと、をさらに含む。検出デバイス１００の制御は、検出デバイス１００に制御命令ＣＭＤを送信することにより実施される。以下の実施例においては、検出装置１００の２つの制御方法について説明する。

『方法１』：リセットモード

リセットモードにおいては、検出デバイス１００と対象監視ユーザとの紐付け関係を解除することができる。このために、サーバ３００は、以下の動作方法を通じてリセットモードに入る：
－１．サーバ３００は、データベースに維持されている検出デバイス１００と対象監視ユーザとの紐付け関係の削除を、例えば、ＢｉｎｄｉｎｇＳｅｔフィールドにある内容を削除することにより実施し、及び／又は、
－２．リセットモードにおいて、サーバ３００は、ＯｐｅｒａｔｉｏｎＰａｒａで検出デバイス１００に関連付けられている動作パラメータ、例えば、現在のアップロード頻度ＦとＤａｔａＴｙｐｅＲｅｐｏｒｔで記憶されている検知データタイプとを削除することができ、及び／又は、
－３．リセットモードにおいて、サーバ３００は、Ｈｉｓｔｏｒｙフィールドのデータをクリアすることによりエアフィルタの履歴状態データを削除することができる。

なお、ここでは、リセットモードに入ると、サーバ３００は、具体的にどの動作を用いるのかを事前に決定することができ、例えば、アクティブリセットモードにおいては、サーバ３００は、検出デバイスとユーザとの紐付け情報を削除することができ、さらに、検出デバイスの動作パラメータを同期的に削除することもできる。

リセットモードにおいては、サーバ３００は、検出デバイス１００の識別情報ＤｅｖｉｃｅＩＤを保持することができ、また、ユーザの身分識別情報ＵｓｅｒＩＤも保持することができ、ただし、両者の紐付けの関連性はもはや存在しない。

本発明の一実施例によれば、リセットモード命令は、サーバ３００側から発行されるものとしてもよい。例えば、サーバ３００内において、リセットモード起動キーが設定され、ＲｅｓｅｔＵｓｅｒにより示されている。サーバ側のオペレータは、ＲｅｓｅｔＵｓｅｒ起動キーをクリックすることにより「リセット」命令ＣＭＤを発行し、リセットモードに入り、上記の動作１．，２．，３．のうちの少なくとも１つを実行することにより、検出デバイス１００とユーザとの紐付けを解除する。

一例においては、リセット命令に命令パラメータを設定することにより、具体的なリセット動作アクションを指定することもでき、このアクションは、「ＢｉｎｄｉｎｇＳｅｔを消去する」、「ＯｐｅｒａｔｉｏｎＰａｒａ／ＤａｔａＴｙｐｅＲｅｐｏｒｔを消去する」、及び、「Ｈｉｓｔｏｒｙを消去する」を含む。本発明の一実施例によれば、リセットモードは、特定の検出デバイスのみに対するものであってもよく、例えば、サーバ３００は、検出デバイスＩＣＦ０００００１に対してのみ、データベースＤＢにリセット命令ＣＭＤを発行することができ、この命令は、ＩＣＦ０００００１デバイス及びユーザ識別情報ＵｓｅｒＩＤ「ｔｅｓｔ」との紐付け関係を削除し、また、デバイスＩＣＦ０００００１の動作パラメータ及び収集された履歴記録データを削除する。リセット動作が完全に実行されると、サーバ側ＩＣＦ０００００１でデバイスに対応するユーザは空になる（又はＮＵＬＬと示される）はずであり、即ち、紐付けされたユーザは存在しない。なお、リセット動作の１つの結果として、検出デバイス及びユーザ自身の情報は、なおもサーバに記憶され得るが、両者の紐付け関係は、データベースＤＢから削除される。

他の場合には、リセットモードにおいては、特定のユーザの総ての検出デバイスに対するリセットが可能であり、これは、このユーザ名で複数の検出デバイス１００、例えば、空気エアフィルタを検出する検出デバイス、タイヤを検出する検出デバイスなどが紐付けられている場合に適用される。このようなリセットモードにおいては、このユーザに紐付けられている総ての検出デバイスは、総て紐付け解除される。例えば、ユーザ「ｔｅｓｔ２」が検出デバイスＩＣＦ０００００２及びＩＣＦ０００００３に紐付けされていると仮定すると、ユーザ「ｔｅｓｔ２」がリセット命令を発行してから、ＩＣＦ０００００２及びＩＣＦ０００００３デバイスとユーザ「ｔｅｓｔ２」との紐付け関係を解除することができる。

本発明の実施例によれば、リセット命令ＣＭＤは、サーバ３００から周期的に発行することもでき、さらに、通信に異常がある場合（例えば、サーバ３００が検出デバイス１００から状態データを受信することができない場合、又は、受信した状態データが正しくない場合）に発行することもできる。

本発明の一実施例によれば、通信に異常がある場合に、サーバ３００が、内部で検出デバイス１００と対象監視ユーザとの紐付け関係を解除し、通信装置２００に制御命令ＣＭＤを発行すると、対象監視ユーザに警報情報を直接発行して、フィルタエレメント又は検出デバイスを交換し、検査に送り又は修理するようにユーザに指示する。

本発明の他の一実施例によれば、リセットモードに入り、紐付け関係を解除した後、検出された携帯電話２００がなおもサーバ３００とネットワーク接続を保持していることが検出された場合、ＵｓｅｒＩＤに対応する携帯電話２００に、身分識別情報ＤｅｖｉｃｅＩＤ、例えば、ＩＣＦ０００００１で特定された検出デバイス１００と、ＵｓｅｒＩＤで特定されたユーザの再紐付けをリクエストする命令ＣＭＤを送信する。携帯電話２００は、この命令ＣＭＤを受信し、現在ペアリングされているＢｌｕｅｔｏｏｔｈデバイス中にＩＣＦ０００００１で識別されるデバイスが存在するかどうかを特定する。対象ＢｌｕｅｔｏｏｔｈデバイスＩＣＦ０００００１の存在が検出されない場合、サーバ３００のデバイス再紐付けをリクエストする命令の存在を提示する１つのリマインドメッセージを表示する。ユーザの携帯電話がちょうど車内又はその近傍にある場合、かつ、対象ＢｌｕｅｔｏｏｔｈデバイスＩＣＦ０００００１とのペアリングに成功した場合、検出デバイス１００は、再紐付けのための命令ＣＭＤを転送する。命令信号ＣＭＤを受信すると、検出デバイス１００は、１つの応答メッセージＲＥＳを送信することができ、この応答メッセージＲＥＳは、サーバ３００に再紐付けするための要求メッセージとして携帯電話２００に送信されて、サーバ３００との再接続を回復する。この応答メッセージＲＥＳは、固定された符号、例えば、身分識別情報ＩＣＦ０００００１又は他の特定の符号を含み得る。

携帯電話２００は、検出デバイス１００から応答メッセージＲＥＳを受信すると、それを再紐付け要求メッセージＲｅ－ＲＥＱとしてサーバ３００に送信し、Ｒｅ－ＲＥＱには、デバイス識別情報ＤｅｖｉｃｅＩＤ、例えば車両識別番号ＩＣＦ０００００１、及び、紐付けされるユーザ識別情報ＵｓｅｒＩＤ、例えば「ｔｅｓｔ１」が含まれる。サーバ３００は、Ｒｅ－ＲＥＱを受信すると、それに含まれる識別番号ＩＣＦ０００００１に基づいて、この車両のデータベース記録を再生成し、現在のユーザ、例えば、ｔｅｓｔ１とＩＣＦ０００００１との紐付け関係、例えば、ＢｉｎｄｉｎｇＳｅｔフィールドに記録されている検出デバイス１００とユーザｔｅｓｔ１との紐付け関係を確立する。

一例によれば、１つのタイマＴＩＭＥＲを設け、携帯電話２００が所定の期限までに検出デバイス１００から応答メッセージＲＥＳを受信することができなかった場合、又は、検出デバイス１００を検索することができなかった場合、サーバ３００に、検出デバイス１００に故障が発生している可能性があるという警報メッセージを発行する。又は、サーバ３００側でタイマを通じて所定の期限内に検出デバイス１００の報告データを受信することができなかったことが分かった場合、サーバ３００は、検出デバイス１００に故障が発生している可能性があることを特定する。このため、サーバ３００は、警報メッセージを生成し、対象監視ユーザに送信することができる。

一例によれば、現在携帯電話２００とサーバ３００とのネットワーク接続が中断されていることが検出された場合、サーバ３００は、携帯電話番号に、身分識別情報ＩＣＦ０００００１で識別された検出デバイス１００の再紐付けをリクエストするショートメッセージＲＥ－ＭＳＧを送信することができる。ユーザは、このＲＥ－ＭＳＧリマインドを受信すると、現在ペアリングされているＢｌｕｅｔｏｏｔｈデバイス中にＩＣＦ０００００１識別情報で識別されたデバイスが存在するかどうかを特定し、前述の紐付け工程を繰り返すことができる。さらに、携帯電話２００は、ショートメッセージＲＥ－ＭＳＧを受信すると、携帯電話２００とサーバ３００とのネットワーク接続が正常であるかどうかを特定し、接続が正常でない場合は、故障を解消して接続を回復することができる。従って、この例によれば、サーバを通じて対応する記録を削除し、ユーザと車両検出デバイス１００との再紐付けをリクエストし、サーバ３００は、検出デバイス１００とユーザとの紐付け関係を更新して、これにより、検出デバイス１００の制御を実施することができる。

他の実施例においては、リセットモードはまた、携帯電話側においても設定することができ、例えば、ユーザは、アプリケーションを動作させてリセット要求を提出することができ、この要求には、ユーザ情報、例えばＵｓｅｒＩＤと、デバイス情報、例えばＤｅｖｉｃｅＩＤとが含まれる。サーバ３００は、リセット要求を受信すると、上述したような動作に基づいて、サーバ側で記憶されている検出デバイス１００と対象監視ユーザとの紐付け関係を解除し、再紐付けするための命令ＣＭＤを送信することにより再紐付けを実施する。

『デバッグモード』
検出デバイス１００の動作が正常であるかどうかを特定するために、又は、異常発生時に故障診断を行うために、サーバ３００はさらに、検出デバイス１００と対話するデバッグモードを用いてテストすることができる。具体的には、ここでも検出デバイスＩＣＦ０００００１を例にとると、サーバ３００は、デバイス識別番号ＩＣＦ０００００１で識別された検出デバイス１００にデバッグ命令ＤＥＢＵＧを送信することができ、本例においては、携帯電話２００を用いて通信状況を転送する場合に、携帯電話２００によってデバッグ命令ＤＥＢＵＧをサーバ３００から検出デバイス１００に転送することができる。具体的には、ユーザの携帯電話がデバッグ命令ＤＥＢＵＧを受信すると、携帯電話がデバッグ命令ＤＥＢＵＧ中に含まれるデバイス識別号ＩＣＦ０００００１で特定された検出デバイス１００とペアリングされているかどうかを特定する。ペアリングの際に、例えば、ユーザが車両に乗り込み又は運転するときに、携帯電話２００は、デバッグ命令ＤＥＢＵＧを検出デバイス１００に送信する。

このＤＥＢＵＧ命令は、以下の少なくとも１つの制御パラメータを含む：
－検出デバイス１００がアップロードする検知データＰのタイプＤａｔａＴｙｐｅＲｅｐｏｒｔ、即ち、検知データ（Ｐ１、Ｐ２、…ＰＮ）のうちのどの１つ又はどの複数、例えば、湿度のみ又は温度を含む、湿度及び色温度などをアップロードするかを指定すること。
－検出デバイス１００が報告する空調フィルタエレメントの動作状態の頻度Ｆ。これは、検出デバイス１００が読み取る検知データの時間周期を変更することにより実施することができ、例えば、検出デバイス１００は、センサのサンプリング周期を調整することができる。また、検出デバイス１００のアップロード頻度Ｆを直接変更することにより、変更することもできる。
－検出デバイス１００がアップロードするデータの信号強度Ｓｔｒｅｎｇｔｈ。この強度は、例えば、デバッグ命令中の指定された強度構成に従って、デバッグモードにおいて増強することができる。デバッグ命令中において構成された強度は、信号強度又は信号強度増強値であるものとしてよい。

検出デバイス１００は、デバッグ命令ＤＥＢＵＧから制御パラメータ、例えば、指定された検出デバイス１００のアップロード頻度Ｆ（５秒に１回）、指定されたアップロード検知データタイプＤａｔａＴｙｐｅＲｅｐｏｒｔパラメータ、及び、所望の信号強度Ｓｔｒｅｎｇｔｈなどを解析する。例えば、温度及び湿度データＰ１、Ｐ２のみをアップロードすることをリクエストする場合、検出デバイス１００は、制御パラメータにおいて設定された報告頻度Ｆに基づいて、指定された状態パラメータ項目Ｐ１、Ｐ２に対応するセンサ１０１－１、１０１－２から、空調フィルタエレメント湿度及び温度データ（以下、ＳｔａｔｕｓＤａｔａと総称する）を収集し、制御パラメータにおいて設定された信号強度Ｓｔｒｅｎｇｔｈに基づいて、状態データＳｔａｔｕｓＤａｔａを、Ｂｌｕｅｔｏｏｔｈインタフェースを通じて携帯電話２００に送信し、携帯電話２００は、状態データＳｔａｔｕｓＤａｔａを受信すると、サーバ３００に転送する。デバッグモードにおいて、サーバ３００は、状態データＳｔａｔｕｓＤａｔａを分析する。サーバ３００は、受信された状態データＳｔａｔｕｓＤａｔａの内容及び頻度が送信されたデバッグ命令の規定と一致するかどうかを分析するだけでなく、例えば、状態データＳｔａｔｕｓＤａｔａに温度及び湿度が含まれているかどうか、及び、５秒ごとに１回アップロードされているかどうかを特定する。それと共に、サーバ３００は、状態データＳｔａｔｕｓＤａｔａがエラーを含むかどうかを検査する。総てが一致しており、かつ、エラーが発生していない場合、検出デバイス１００は、現在の動作が正常であることを確認する。状態データＳｔａｔｕｓＤａｔａにエラーがある場合、サーバ３００は、デバッグ命令を再発行し、命令検出デバイス１００は、増強された信号強度で状態データＳｔａｔｕｓＤａｔａを送信し、サーバ３００は、データの精度を再評価し、これにより、検出デバイスの最適動作パラメータを決定する。所定の頻度に従って検出デバイス１００が状態データＳｔａｔｕｓＤａｔａを受信することができていない場合、又は、状態データＳｔａｔｕｓＤａｔａに含まれるデータタイプがデバッグ命令と一致しない場合は、検出デバイス１００の動作が異常であることが分かる。このためサーバ３００は、対象監視ユーザに故障警報を送信して、検出デバイス１００に異常が存在する可能性を指示する。他の可能な実装形態においては、サーバ３００がデバッグ命令を調整することにより、アップロードされるＳｔａｔｕｓＤａｔａにより多くのタイプの状態パラメータを含めるように検出デバイス１００に命令して、異常が発生しているのが検出デバイス１００であるのか又は特定のセンサであるのかを具体的に判断する。調整されたデバッグ命令に従って、検出デバイス１００がアップロードした状態データＳｔａｔｕｓＤａｔａの頻度Ｆが規定と一致しない場合、又は、アップロードされた総ての状態パラメータデータが異常であることが明らかな場合、検出デバイス１００の通信が異常であることを確実に判定することができる。他は正常であるが、特定の１つ又は複数のセンサが、検知データＰに異常が発生していることを検出した場合、初期判断として、この１つ又はこれらの複数のセンサに故障が発生している可能性があるということになり得る。本例においては、より多くのタイプの検知データをアップロードすることにより、デフォルトで構成されたアップロードパラメータ（例えば、３週間に１回アップロードすること、信号強度は正常であること、データはセンサ１の数値であること）に起因するアップロードデータが少な過ぎることによる判断誤差を回避することができる。

なお、ここでは、デバッグを目的として、サーバ３００が発行するデバッグ命令ＤＥＢＵＧにより、検出デバイス１００が１つ又は複数の検知データタイプのみを送ることをリクエストすることによって、検出デバイス１００の負荷を軽減することもできることに留意されたい。検出デバイスの動作が正常であることを特定すると、サーバ３００は、フィルタエレメントの動作状態を特定するために必要な状態パラメータ（Ｐ１、Ｐ２、…ＰＮ）の全部又は一部をアップロードするように、検出デバイス１００に命令するための制御命令を再発行することができる。

本発明に係る方法によれば、特定のサーバ３００を使用することによりフィルタエレメントの動作を監視し、警報信号を対象監視ユーザに容易に送信することができるだけでなく、検出デバイス１００に強制的な調整及び／又はデバッグを能動的かつ定期的に行うことにより、検出デバイス１００の故障をリアルタイムで発見することができる。本発明に係る方法を利用すると、デバッグ命令ＤＥＢＵＧの内容をカスタマイズすることにより、特定のタイプのセンサ及び検出デバイスの診断も実施することができる。例えば、ＤＥＢＵＧ命令で温度データのみをアップロードする必要がある場合、アップロードデータが明らかに異常であり、検出デバイス１００と携帯電話２００との間の信号強度を調整してもこの異常を修正することができない場合、初期判断として、温度センサに異常が出現しているということになり得る。

このように、本発明に係るサーバ３００を、検出デバイス１００とは逆の方向に制御するように構成することにより、検出側の異常を能動的に特定することができ、警報メッセージを各関連装置に柔軟に送信することができる。

本発明の前述の実施例においては、検出デバイス１００は、通信装置としての携帯電話２００を通じてサーバ３００と通信するが、本発明によれば、通信装置２００は、双向通信機能を有する任意のタイプのモジュールであるものとしてもよい。また、本発明の他の変形例によれば、通信装置２００を省略する（又は通信装置２００を検出デバイス１００と共に一体化する）こともでき、代わりに検出デバイス１００は、サーバ３００と直接通信を確立し、例えば、内蔵型の４Ｇ又は５Ｇ通信モジュールは、ＳｉｇＦｏｘ、ＬｏＲａ、ＮＢ－ＬｏＴ通信プロトコルを通じて直接通信を実施する。本発明に記載される検出デバイス１００に対する能動的リセットは、デバッグ方法と同様に、このような直接通信のケースに適用され、サーバ３００は、なおも警報信号を登録されている対象監視ユーザに送信することができる。

図２は、サーバ３００が実施するリセット検出デバイスの例示的な方法フロー図を示しており、これを例にとって、サーバ３００側でリセットモードを開始することを説明する。図２に示すように、ステップ２０１において、サーバ３００においてリセットモードがアクティブ化される、例えば、オペレータがリセットモード起動キーＲｅｓｅｔＵｓｅｒをクリックする。リセットモードがアクティブ化されると、サーバ３００は、データベースＤＢに維持されている検出デバイス１００とユーザＵｓｅｒＩＤとの紐付け関係を解除する。一例においては、アクティブモードにおいて、サーバ３００は、ＢｉｎｄｉｎｇＳｅｔフィールドの情報を消去することにより、データベースＤＢに維持されている検出デバイス１００と対象監視ユーザＵｓｅｒＩＤとの紐付けに関する情報を削除する。他の例においては、サーバ３００は、検出デバイス１００に関する動作パラメータ、例えば、状態パラメータのアップロード頻度Ｆ及び取得された検知データタイプをさらに削除することもできる。さらに、サーバ３００は、Ｈｉｓｔｏｒｙフィールドのデータをクリアすることにより、エアフィルタに関する履歴状態データを削除することもできる。

ステップ２０３において、データベースに記憶されているユーザ登録情報に基づいて、検出された現在の携帯電話２００は、まだサーバ３００とネットワーク接続を保持している状況で、このユーザ、例えばｔｅｓｔ１の携帯電話２００に「リセット」命令ＣＭＤを発行し、この命令において１つの対象検出デバイス、例えば、識別情報ＩＣＦ０００００１で識別される検出デバイスを指定することができ、また、このユーザに関連付けられている総ての検出デバイスを指定することもできる。以下に、検出デバイスＩＣＦ０００００１を１つのみ指定する例を説明する。この命令は、サーバが、現在のユーザｔｅｓｔ１とリセット命令で指定された検出デバイス１００とのサーバ側における紐付けを既に解除しており、それに関連付けられている検出デバイスを再紐付けするように、ユーザにリクエストしていることを示す。リセット命令により、命令パラメータＣＰを設定することによって、既に実行された具体的なリセット動作、例えば、ＣＰ１：「ＢｉｎｄｉｎｇＳｅｔを消去する」、ＣＰ２：「ＯｐｅｒａｔｉｏｎＰａｒａ／ＤａｔａＴｙｐｅＲｅｐｏｒｔを消去する」、及び、ＣＰ３：「Ｈｉｓｔｏｒｙを消去する」のうちの１つ又は複数を指示することができる。また、リセット命令により、リセットの対象とする対象物、即ち、単一の検出デバイス又はユーザに紐付けられた総ての検出デバイスを指定することもできる。

ステップ２０５において、サーバ３００は、携帯電話２００から、この「リセット」命令への応答として、再紐付けリクエストＲｅ－ＲＥＱを受信する。本発明の一例においては、リセット命令において単一の検出デバイス、例えば、ＩＣＦ０００００１を指定する場合、携帯電話は、リセット命令ＣＭＤを受信すると、現在のペアリングされているＢｌｕｅｔｏｏｔｈデバイスにＩＣＦ０００００１で識別されるデバイスが存在するかどうかを特定する。対象ＢｌｕｅｔｏｏｔｈデバイスＩＣＦ０００００１の存在が検出されない場合、１つのリマインドメッセージが表示され、サーバ側においてユーザＵｓｅｒＩＤが検出デバイスＩＣＦ０００００１との紐付けが解除されたことをユーザに提示し、ＩＣＦ０００００１で識別されるデバイスと、Ｂｌｕｅｔｏｏｔｈ接続を確立するために確立を試みる。ユーザ携帯電話２００と対象ＢｌｕｅｔｏｏｔｈデバイスＩＣＦ０００００１とのペアリングが成功すると、検出デバイス１００に探索信号Ｐｒｏｂｅ＿Ｓｉｇｎａｌを送信し、このＰｒｏｂｅ＿Ｓｉｇｎａｌは、命令ＣＭＤに基づいて既に生成されたものであってもよく、また、携帯電話２００から直接転送されたＣＭＤ自体であってもよい。この探索信号Ｐｒｏｂｅ＿ｓｉｇｎａｌを受信すると、検出デバイス１００は、１つの応答メッセージＲＥＳを送信し、この応答メッセージＲＥＳは、この再紐付けリクエストＲｅ－ＲＥＱとして携帯電話２００によってサーバ３００に転送される。本発明の一例においては、この応答メッセージＲＥＳの内容は、リセット命令ＣＭＤの命令パラメータＣＰによって決定される。例えば、ＣＭＤがＣＰ１のみを含む場合、この応答メッセージＲＥＳは、固定された符号、例えば、身分識別情報ＩＣＦ０００００１又は他の特定の符号を含み得る。ＣＭＤがＣＰ２をさらに含む場合、検出デバイス１００は、現在のデフォルトの動作パラメータ、例えば、アップロード頻度Ｆ情報を応答メッセージＲＥＳにさらに含める。ＣＭＤがＣＰ３をさらに含む場合、検出デバイス１００は、現在のデフォルトの取得する必要がある検知データタイプＤａｔａＴｙｐｅＲｅｐｏｒｔに基づいて、対応するセンサから状態データをリアルタイムで取得し、ＲＥＳに含める。

ステップ２０７において、サーバ３００は、Ｒｅ－ＲＥＱを受信すると、そこに含まれる識別番号ＩＣＦ０００００１に基づいて、この車両のデータベース記録を再生成し、検出デバイス１００とユーザＵｓｅｒＩＤとの紐付け関係、例えば、データベースＢｉｎｄｉｎｇＳｅｔフィールドで紐付け関係データを再確立する。また、Ｒｅ－ＲＥＱに他の応答情報、例えば、アップロード頻度Ｆ及び状態データが含まれている場合、サーバ３００は、検出デバイス１００のアップロード頻度Ｆ及び検知データタイプなどもデータベース記録にさらに書き込む。

本例によれば、サーバ３００が所定の期限内に検出デバイス１００又は携帯電話２００から応答メッセージＲＥＳを受信することができなかった場合、サーバ３００は、警報メッセージを生成し、対象監視ユーザに送信することができる。

本発明の他の例によれば、サーバ３００が、解除されるユーザの総ての検出デバイスの紐付けを解除した場合、携帯電話２００がリセット命令ＣＭＤを受信すると、総ての検出デバイスに探索信号Ｐｒｏｂｅ＿Ｓｉｇｎａｌを生成し、対応する検出デバイスに送信し、各検出デバイスはＲｅ－ＲＥＱを受信し、その中に含まれる情報に基づいてこのユーザ名において、各検出デバイスは、再紐付け関係を確立する。

図３は、本発明の一実施例による検出デバイスをデバッグする方法のフローを示している。以下の説明においては、デバイスＩＣＦ０００００１に対するデバッグを例に説明する。

ステップ３０１において、サーバ３００は、デバイス識別番号ＩＣＦ０００００１で識別される検出デバイス１００にデバッグ命令ＤＥＢＵＧを送信し、本例に通信装置２００が存在する場合、通信装置２００からこのデバッグ命令を受信するものとしてもよい。このデバッグ命令には、検出デバイス１００がアップロードした空調フィルタエレメントの動作状態データＳｔａｔｕｓＤａｔａの頻度Ｆ、検出デバイス１００がアップロードした検知データタイプＤａｔａＴｙｐｅＲｅｐｏｒｔ、及び、データをアップロードするときに使用される信号強度Ｓｔｒｅｎｇｔｈを含めることができる。

通信装置２００は、デバッグ命令ＤＥＢＵＧを受信した後、携帯電話が、デバッグ命令ＤＥＢＵＧにデバイス識別号ＩＣＦ０００００１で特定された検出デバイス１００とペアリングされているかどうかを特定する。通信接続が保持されているとき、通信装置２００は、デバッグ命令ＤＥＢＵＧを検出デバイス１００に送信する。

ステップ３０３において、サーバ３００は、通信装置２００からデバッグ命令ＤＥＢＵＧへの応答としての状態データＳｔａｔｕｓＤａｔａを受信する。本発明の実施例によれば、検出デバイス１００は、通信装置２００がデバッグ命令ＤＥＢＵＧを受信すると、デバッグ命令ＤＥＢＵＧから制御パラメータ、例えば、指定された検出デバイス１００のアップロード頻度、指定されたアップロードされた検知データタイプ、及び、所望の信号強度を解析する。検出デバイス１００は、制御パラメータＣＰにおいて設定された報告頻度Ｆに基づいて、指定された検知データタイプに対応するセンサからフィルタエレメント状態データＳｔａｔｕｓＤａｔａを収集し、制御パラメータＣＰにおいて設定された信号強度に応じて状態データＳｔａｔｕｓＤａｔａを通信装置２００に送信し、通信装置２００は、状態データＳｔａｔｕｓＤａｔａを受信すると、サーバ３００に転送する。

ステップ３０５において、サーバ３００は、状態データＳｔａｔｕｓＤａｔａを分析して、状態データがデバッグ命令と一致するかどうかを特定する。一例として、サーバ３００は、受信された状態データＳｔａｔｕｓＤａｔａ中の検知データタイプ及びアップロード頻度が、送信されたデバッグ命令中の規定されたタイプ及び頻度と一致するかどうかを分析する。それと共に、サーバ３００は、状態データＳｔａｔｕｓＤａｔａ中のフィルタエレメント検知データＰがエラーを含むかどうかをさらに検査する。総て一致しており、かつ、エラーが発生していない場合、検出デバイス１００の現在の動作は正常であると確認され、従って、ステップ３０７に進み、デバッグを終了する。そうではなく、状態データＳｔａｔｕｓＤａｔａにエラーがある場合、ステップ３０９に進む。

ステップ３０９において、サーバ３００は、デバッグ命令を再発行し、増強された信号強度Ｓｔｒｅｎｇｔｈで状態データＳｔａｔｕｓＤａｔａを送信するように検出デバイス１００に命令し、ステップ３１１において、サーバ３００は、状態データＳｔａｔｕｓＤａｔａを受信し、これにエラーが存在するかどうかを再評価する。データの精度が向上している場合、又は、エラーが存在しない場合、現在の強度Ｓｔｒｅｎｇｔｈが検出デバイス１００の最適な動作パラメータであることを決定することができ、ステップ３０７に進み、デバッグを終了する。

ステップ３１１において、信号強度を変更した状況で受信されたデータになおもエラーが存在する場合、ステップ３１３に進み、サーバ３００は、デバッグ命令を変更し、検出デバイス１００は、アップロードするＳｔａｔｕｓＤａｔａにより多くのタイプの検知データを含める。ステップ３１５において、サーバ３００は、デバッグ命令を変更した後に検出デバイス１００によって送信される状態データＳｔａｔｕｓＤａｔａを受信し、異常が発生しているのが、検出デバイス１００であるか、又は、特定の１つ又は複数のセンサであるかを具体的に判断する。明らかに、検出デバイス１００がアップロードした状態データＳｔａｔｕｓＤａｔａの頻度Ｆが規定と一致しない場合、又は、アップロードされた総ての状態パラメータデータが異常である場合、検出デバイス１００が異常であることを確実に判定することができる。他は正常であるが、特定の１つ又は複数のセンサが、検知データに異常が発生していることを検出した場合、初期判断として、この１つ又はこれらの複数のセンサに故障が発生している可能性があるということになり得る。

ステップ３０５において、デバッグ命令における所定の頻度Ｆに従って検出デバイス１００から状態データＳｔａｔｕｓＤａｔａを受信することができていない場合、又は、状態データＳｔａｔｕｓＤａｔａに含まれる検知データタイプＤａｔａＴｙｐｅＲｅｐｏｒｔがデバッグ命令と一致していない場合、検出デバイス１００の動作は異常であることが分かる。このためステップ３１６に進み、サーバ３００は、対象監視ユーザに故障警報を送信して、検出デバイス１００に異常が存在する可能性を指示する。

本発明に係る方法によれば、中央処理装置のＣＰＵ又はプロセッサがメモリに記憶されたプログラム又は命令を実行することによって実施することができる。図４は、本発明の一例によるサーバ３００の概略図を示している。このサーバ３００は、送受信部４０１と、記憶媒体４０２と、制御部４０３と、を備える。送受信部４０１は、本発明に係る方法又は処理若しくはフローを実施するための指令を、通信装置２００から又は直接内部に記憶するために使用され、制御部４０３は、メモリ内の指令を実行することにより本発明に係る方法を実施する。本発明の他の実施例が提供する機械可読媒体は、機械可読指令を記憶し、機械可読指令がプロセッサによって実行されるときに、プロセッサに前述の方法のいずれかを実施させるためのものである。具体的には、機械可読媒体を備えたシステム又は装置が提供されるものとしてもよく、この機械可読媒体に、上記の実施例のいずれか１つの機能を実装するためのソフトウェアプログラムコードが記憶され、このシステム又はデバイスのコンピュータ又はプロセッサに、機械可読媒体に記憶されている機械可読指令を読み取らせて実行させる。この場合、機械可読媒体から読み取られたプログラムコード自体は、上記の実施例のいずれか１つの実施例の機能を実装することができ、従って、機械可読コード及び機械可読コードを記憶する機械可読媒体は、本発明の一部を構成する。機械可読媒体の実施例には、フレキシブルディスク、ハードディスク、磁気光学ディスク、光ディスク（例えば、ＣＤ－ＲＯＭ、ＣＤ－Ｒ、ＣＤ－ＲＷ、ＤＶＤ－ＲＯＭ、ＤＶＤ－ＲＡＭ、ＤＶＤ－ＲＷ、ＤＶＤ＋ＲＷ）、磁気テープ、不揮発性メモリカード、及び、ＲＯＭが含まれる。選択可能に、通信ネットワークによってサーバコンピュータ又はクラウドからプログラムコードをダウンロードすることができる。

なお、上記のプロセスの総てのステップが必要であるわけではなく、実際のニーズに応じて一部のステップを無視することができることに留意されたい。さらに、本発明においてはまた、各ステップの実行順序は一定ではなく、必要に応じて調整することもできる。

以上、本発明を添付図面及び好ましい実施形態によって詳細に示し説明したが、本発明は、これらの開示された実施例に限定されるものではなく、上記の複数の実施形態に基づいて、当業者は、上記の異なる実施例におけるコードレビュー手段を組み合わせて、本発明のより多くの実施例を得ることができ、これらの実施例はまた、本発明の保護範囲内にある。

Claims (26)

1. 自動車用の検出デバイスを監視するためのサーバであって、
   第１のリンクを通じて通信装置と通信するための送受信部と、
   制御部であって、前記送受信部に連結され、かつ、
   第２のリンクを通じて前記検出デバイスと通信する前記通信装置から前記第１のリンクを通じて、前記検出デバイスによって検出された対象装置の状態データを受信することと、
   前記通信装置に制御命令を送信して、前記検出デバイスを、前記制御命令に従って動作するように制御することと、
   を行う動作を実行するように構成されている制御部と、
   を備えるサーバ。
2. 前記対象装置は、自動車空調フィルタエレメントであり、前記検出デバイスは、前記空調フィルタエレメントの動作状態を検出するために使用される、請求項１に記載のサーバ。
3. 前記サーバに前記検出デバイスと対象監視ユーザとの紐付け関係情報が登録されており、前記サーバは、前記検出デバイスと前記対象監視ユーザとの紐付け関係を解除するようにさらに構成されている、請求項１に記載のサーバ。
4. 前記制御命令は、前記サーバが前記紐付け関係を既に解除したことを示す、請求項３に記載のサーバ。
5. 前記サーバは、
   前記通信装置に、紐付け関係を再確立するための前記制御命令を送信することと、
   前記通信装置を介して、前記検出デバイスの再紐付け要求を受信することと、
   を行うようにさらに構成されている、請求項３に記載のサーバ。
6. 前記検出デバイスと前記対象監視ユーザとの紐付け関係情報を前記解除することは、リセット動作を含み、前記リセット動作は、
   前記サーバに登録されている前記検出デバイスと前記通信装置との紐付け関係情報を削除することと、
   前記サーバに記憶されている前記検出デバイスの動作パラメータを削除することと、
   前記サーバに記憶されている前記対象装置に関する履歴記録を消去することと、
   のうちの少なくとも１つである、請求項４又は５に記載のサーバ。
7. 前記検出デバイスと前記対象監視ユーザとの紐付け関係情報を前記解除することは、
   前記通信装置から前記紐付け関係を解除するための要求を受信することと、
   前記要求に対する応答として、リセット動作を実行することであって、前記リセット動作は、
   前記サーバに登録されている前記検出デバイスと前記ユーザとの紐付け関係情報を削除することと、
   前記サーバに記憶されている前記検出デバイスの動作パラメータを削除することと、
   前記サーバに記憶されている前記検出デバイスに関する履歴記録を消去することと、
   のうちの少なくとも１つである、前記リセット動作を実行することと、
   を含む、請求項４又は５に記載のサーバ。
8. 前記制御命令は、前記リセット動作を示す命令パラメータを含む、請求項６又は７に記載のサーバ。
9. 前記制御命令は、前記検出デバイスをデバッグするためのデバッグ命令であり、前記デバッグ命令は、動作パラメータを含み、前記動作パラメータは、
   前記検出デバイスが前記対象装置の状態データをアップロードするアップロード頻度と、
   前記状態データをアップロードするための信号強度と、
   前記状態データに含まれる検知データタイプに対するカスタマイズと、
   のうちの少なくとも１つである、請求項１に記載のサーバ。
10. 前記サーバは、前記通信装置から、前記検出デバイスの前記デバッグ命令に対する応答信号を受信し、前記応答信号に基づいて、前記検出デバイスの動作状態を判断し、前記応答信号は、前記検出デバイスの状態データを含み、前記状態データは、異なるタイプの検知データを含む、請求項９に記載のサーバ。
11. 前記応答信号に基づいて、前記検出デバイスの動作状態を判断することは、
    続けて受信した前記応答信号が、前記アップロード頻度と一致するかどうかを特定し、前記アップロード頻度と一致しない場合に、前記検出デバイスが故障したことを特定することを含む、請求項１０に記載のサーバ。
12. 前記応答信号に基づいて、前記検出デバイスの動作状態を判断することは、前記応答信号中の状態データにエラーが存在するかどうかを特定することを含み、エラーが存在する場合に、前記サーバは、
    前記通信装置に他のデバッグ命令を発行して、前記検出デバイスを、前記信号強度を増強するように制御し、及び／又は、前記状態データに含まれる検知データのタイプ及び数量を調整するように制御する、
    請求項１０に記載のサーバ。
13. 前記サーバは、前記増強された信号強度で、前記検出デバイスによって送信された応答信号中の状態データに誤差が存在するかどうかを検出するように構成されており、
    誤差が存在しない場合に、前記増強された信号強度を前記検出デバイスの最適送信信号強度に設定し、
    誤差が続けて存在する場合に、前記検出デバイス内の誤差が存在する検知データに対応するセンサに故障が発生したことを判定する、
    請求項１２に記載のサーバ。
14. 前記サーバは、前記検出デバイスに故障が発生したことを判定したときに、前記サーバに登録されている前記対象監視ユーザに警報情報を送信するようにさらに構成されている、請求項１１乃至１３のいずれか一項に記載のサーバ。
15. 前記通信装置は、移動端末であり、前記対象監視ユーザは、前記移動端末のユーザ、自動車のユーザ、又は、外部サービスプロバイダのうちのいずれか１つを含む、請求項１４に記載のサーバ。
16. 自動車用の検出デバイスを監視するための方法であって、
    第２のリンクを通じて前記検出デバイスと通信する通信装置と第１のリンクを通じて通信して、前記検出デバイスによって検出された対象装置の状態データを受信することと、
    前記通信装置に制御命令を送信して、前記検出デバイスを、前記制御命令に従って動作するように制御することと、
    を含む方法。
17. 前記対象装置は、自動車空調フィルタエレメントであり、前記検出デバイスは、前記空調フィルタエレメントの動作状態を検出するために使用される、請求項１６に記載の方法。
18. 前記サーバに前記検出デバイスと対象監視ユーザとの紐付け関係情報が登録されており、
    前記方法は、
    前記検出デバイスと前記対象監視ユーザとの紐付け関係を解除することをさらに含む、
    請求項１６に記載の方法。
19. 前記制御命令は、前記サーバが前記紐付け関係を既に解除したことを示す、請求項１８に記載の方法。
20. 前記通信装置に前記紐付け関係を再確立するための前記制御命令を送信することと、
    前記通信装置を介して、前記検出デバイスの再紐付け要求を受信することと、
    をさらに含む、請求項１９に記載の方法。
21. 前記検出デバイスと前記対象監視ユーザとの紐付け関係情報を前記解除することは、リセット動作を含み、前記リセット動作は、
    前記検出デバイスと前記ユーザとの紐付け関係情報を削除することと、
    前記検出デバイスの動作パラメータを削除することと、
    前記検出デバイスに関する履歴記録を消去することと、
    のうちの少なくとも１つである、請求項１９又は２０に記載の方法。
22. 前記検出デバイスと前記対象監視ユーザとの紐付け関係情報を前記解除することは、
    前記通信装置から前記紐付け関係を解除するための要求を受信することと、
    前記要求に対する応答として、リセット動作を実行することであって、前記リセット動作は、
    前記検出デバイスと前記ユーザとの紐付け関係情報を削除することと、
    前記検出デバイスの動作パラメータを削除することと、
    前記対象装置に関する履歴記録を消去することと、
    のうちの少なくとも１つである、前記リセット動作を実行することと、
    を含む、請求項１９又は２０に記載の方法。
23. 前記制御命令は、前記検出デバイスをデバッグするためのデバッグ命令であり、前記デバッグ命令は、動作パラメータを含み、前記動作パラメータは、
    前記検出デバイスが前記対象装置の状態データをアップロードするアップロード頻度と、
    前記状態データをアップロードするための信号強度と、
    前記状態データに含まれる検知データタイプに対するカスタマイズと、
    のうちの少なくとも１つである、請求項１６に記載の方法。
24. 前記通信装置から、前記検出デバイスの前記デバッグ命令に対する応答信号を受信し、前記応答信号に基づいて、前記検出デバイスの動作状態を判断することをさらに含み、前記応答信号は、前記検出デバイスの状態データを含み、前記状態データは、異なるタイプの検知データを含む、請求項２３に記載の方法。
25. 前記検出デバイスに故障が発生したことを判断したときに、前記対象監視ユーザに警報情報を送信することをさらに含む、請求項２４に記載の方法。
26. 機械可読指令が内部に記憶された機械可読記憶媒体であって、前記指令は、制御部によって実行されたときに、前記制御部に、請求項１６乃至２５のいずれか一項に記載の方法を実行させるためのものである、機械可読記憶媒体。

Images