特開 2024-57916 空気圧管理装置および空気圧管理方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024057916

(43)【公開日】2024-04-25

(54)【発明の名称】空気圧管理装置および空気圧管理方法

(51)【国際特許分類】

   B60C 23/04 20060101AFI20240418BHJP

【ＦＩ】

B60C23/04 160B

B60C23/04 160A

B60C23/04 220Z

【審査請求】未請求

【請求項の数】9

【出願形態】ＯＬ

(21)【出願番号】P 2022164903

(22)【出願日】2022-10-13

【新規性喪失の例外の表示】特許法第３０条第２項適用申請有り ｈｔｔｐｓ：／／ｗｗｗ．ｙ－ｙｏｋｏｈａｍａ．ｃｏｍ／ｒｅｌｅａｓｅ／？ｉｄ＝３８２５＆ｌａｎｇ＝ｊａ＆ｓｐ＝２０ ニュースリリース１．ｐｄｆ 掲載日 令和４年６月２０日

(71)【出願人】

【識別番号】000006714

【氏名又は名称】横浜ゴム株式会社

(74)【代理人】

【識別番号】110002147

【氏名又は名称】弁理士法人酒井国際特許事務所

(72)【発明者】

【氏名】野田 耕平

(72)【発明者】

【氏名】貞森 巧

(72)【発明者】

【氏名】岡崎 大起

(72)【発明者】

【氏名】白井 顕一

(72)【発明者】

【氏名】松田 淳

(72)【発明者】

【氏名】飯塚 洋

(72)【発明者】

【氏名】多田 成明

(57)【要約】

【課題】タイヤの空気圧の異常の有無および異常種別を精度良く判定できる空気圧管理装置および空気圧管理方法を提供すること。
【解決手段】本実施形態に係るクラウドサーバ３０は、車両１に装着されたタイヤ２の空気圧および温度を含むセンサ情報を所定のタイミングで取得する空気圧情報取得部３２と、タイヤ２の基準空気圧および基準温度を含む基準情報を設定する基準情報設定部３３と、センサ情報および基準情報に基づいて、基準温度におけるタイヤ２の温度換算空気圧を算出する温度換算空気圧算出部３４と、基準空気圧と温度換算空気圧との比較結果に基づいて、タイヤ２の異常の有無および該異常の種別を判定する異常判定部３６とを備える。
【選択図】図１

【特許請求の範囲】

【請求項1】

車両に装着されたタイヤの空気圧および温度を含むセンサ情報を所定のタイミングで取得する情報取得部と、
前記タイヤの基準空気圧および基準温度を含む基準情報を設定する基準情報設定部と、
前記センサ情報および前記基準情報に基づいて、前記基準温度における前記タイヤの温度換算空気圧を算出する温度換算空気圧算出部と、
前記基準空気圧と前記温度換算空気圧との比較結果に基づいて、前記タイヤの異常の有無および該異常の種別を判定する異常判定部と、
を備える空気圧管理装置。

【請求項2】

前記異常判定部は、前記基準空気圧と前記温度換算空気圧との差分値が第１閾値以上の場合に、前記タイヤに異常有りと判定し、かつ、前記差分値が前記第１閾値よりも大きい第２閾値以上の場合に、前記異常の種別を前記タイヤのパンクと判定し、前記差分値が前記第２閾値より小さい場合に、前記異常の種別を前記タイヤのスローリークと判定する請求項１に記載の空気圧管理装置。

【請求項3】

前記異常判定部は、前記スローリークと判定された回数を計測し、連続して該スローリークと判定された回数が所定回数を超えた場合、前記異常の種別として前記スローリークであることを出力する請求項２に記載の空気圧管理装置。

【請求項4】

前記温度換算空気圧の１日分の低下量を算出する空気圧低下量算出部を備え、
連続して該スローリークと判定された回数が所定回数を超えた場合、前記異常判定部は、前記基準空気圧と前記温度換算空気圧との差分値と、前記温度換算空気圧の１日分の低下量との比較結果に基づき、スローリークの異常を出力する請求項３に記載の空気圧管理装置。

【請求項5】

前記タイヤの前記温度換算空気圧と前記温度との対応関係を示すデータ群を記憶する記憶部を備え、
前記異常判定部は、前記温度換算空気圧と前記温度との組データを、前記データ群と比較したクラスタリング結果により、前記タイヤの異常の有無を判定し、かつ、前記基準空気圧と前記温度換算空気圧との差分値が所定閾値以上であるか否かにより、前記異常の種別を前記タイヤのスローリークか前記タイヤのパンクかを判定する請求項１に記載の空気圧管理装置。

【請求項6】

所定期間における前記温度換算空気圧の平均値を算出する平均値算出部を備え、
前記基準情報設定部は、前記温度換算空気圧の平均値を前記基準情報として設定する請求項１に記載の空気圧管理装置。

【請求項7】

前記情報取得部、前記温度換算空気圧算出部および前記異常判定部は、前記車両が規定の駐車地に駐車され、該車両の運行が終了して所定時間が経過した後に、動作を実行する請求項１に記載の空気圧管理装置。

【請求項8】

前記車両は、不特定のユーザに共用される共用車両である請求項７に記載の空気圧管理装置。

【請求項9】

車両に装着されたタイヤの空気圧および温度を含むセンサ情報を所定のタイミングで取得するステップと、
前記タイヤの基準空気圧および基準温度を含む基準情報を設定するステップと、
前記センサ情報および前記基準情報に基づいて、前記基準温度における前記タイヤの温度換算空気圧を算出するステップと、
前記温度換算空気圧と前記基準空気圧との比較結果に基づいて、前記タイヤの異常の有無および該異常の種別を判定するステップと、
を備える空気圧管理方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、タイヤの空気圧を管理する空気圧管理装置および空気圧管理方法に関する。

【背景技術】

【0002】

車両に装着されたタイヤの空気圧を適正に管理することにより、車両の走行安定性が確保されている。近年、タイヤにＴＰＭＳ(Tire Pressure Monitoring System)センサを設け、ＴＰＭＳセンサから得られた空気圧情報をクラウドで管理しようとする試みが進められている（例えば、特許文献１参照）。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２０２１－０４６１６０号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

この種のＴＰＭＳセンサでは、ある一定時間内に、任意の閾値まで空気圧が低下した場合、この空気圧異常がドライバーや車両管理者に通知されるようになっている。しかしながら、数時間～数日程度の期間でゆっくりと空気圧が低下する、いわゆるスローリーク（スローパンクチャー）においては、空気圧異常を精度よく判定することが困難という課題があった。

【0005】

本発明は、上記に鑑みてなされたものであって、タイヤの空気圧異常の有無および異常の種別を精度良く判定できる空気圧管理装置および空気圧管理方法を提供することを目的とする。

【課題を解決するための手段】

【0006】

上述した課題を解決し、目的を達成するために、本発明に係る空気圧管理装置は、車両に装着されたタイヤの空気圧および温度を含むセンサ情報を所定のタイミングで取得する情報取得部と、タイヤの基準空気圧および基準温度を含む基準情報を設定する基準情報設定部と、センサ情報および基準情報に基づいて、基準温度におけるタイヤの温度換算空気圧を算出する温度換算空気圧算出部と、基準空気圧と温度換算空気圧との比較結果に基づいて、タイヤの異常の有無および該異常の種別を判定する異常判定部と、を備える。

【0007】

上記した空気圧管理装置において、異常判定部は、基準空気圧と温度換算空気圧との差分値が第１閾値以上の場合に、タイヤに異常有りと判定し、かつ、差分値が第１閾値よりも大きい第２閾値以上の場合に、異常の種別をタイヤのパンクと判定し、差分値が第２閾値より小さい場合に、異常の種別をタイヤのスローリークと判定する。

【0008】

上記した空気圧管理装置において、異常判定部は、スローリークと判定された回数を計測し、連続して該スローリークと判定された回数が所定回数を超えた場合、異常の種別としてスローリークであることを出力する。

【0009】

上記した空気圧管理装置において、温度換算空気圧の１日分の低下量を算出する空気圧低下量算出部を備え、連続して該スローリークと判定された回数が所定回数を超えた場合、異常判定部は、基準空気圧と温度換算空気圧との差分値と、温度換算空気圧の１日分の低下量との比較結果に基づき、スローリークの異常を出力する。

【0010】

上記した空気圧管理装置において、タイヤの温度換算空気圧と温度との対応関係を示すデータ群を記憶する記憶部を備え、異常判定部は、温度換算空気圧と温度との組データを、データ群と比較したクラスタリング結果により、タイヤの異常の有無を判定し、かつ、基準空気圧と温度換算空気圧との差分値が所定閾値以上であるか否かにより、異常の種別をタイヤのスローリークかタイヤのパンクかを判定する。

【0011】

上記した空気圧管理装置において、所定期間における温度換算空気圧の平均値を算出する平均値算出部を備え、基準情報設定部は、温度換算空気圧の平均値を基準空気圧として設定する。

【0012】

上記した空気圧管理装置において、情報取得部、温度換算空気圧算出部および異常判定部は、車両が規定の駐車地に駐車され、該車両の運行が終了して所定時間が経過した後に、動作を実行する。

【0013】

上記した空気圧管理装置において、車両は、不特定のユーザに共用される共用車両である。

【0014】

本発明に係る空気圧管理方法は、車両に装着されたタイヤの空気圧および温度を含むセンサ情報を所定のタイミングで取得するステップと、タイヤの基準空気圧および基準温度を含む基準情報を設定するステップと、センサ情報および基準情報に基づいて、基準温度におけるタイヤの温度換算空気圧を算出するステップと、温度換算空気圧と基準空気圧との比較結果に基づいて、タイヤの異常の有無および該異常の種別を判定するステップと、を備える。

【発明の効果】

【0015】

本発明によれば、タイヤの空気圧異常の有無および異常の種別を精度良く判定することができる。

【図面の簡単な説明】

【0016】

【図1】図１は、本実施形態に係る空気圧管理装置を備えた空気圧管理システムの全体構成を示すブロック図である。

【図2】図２は、空気圧管理システムの動作手順を示すフローチャートである。

【図3】図３は、パンク判定処理の動作手順を示すフローチャートである。

【図4】図４は、空気圧管理装置がスローリーク判定を出力する際の動作手順を示すフローチャートである。

【図5】図５は、別の実施形態のパンク判定処理の動作手順を示すフローチャートである。

【図6】図６は、タイヤの温度換算空気圧と温度との対応関係を示すマップデータの一例を示す図である。

【発明を実施するための形態】

【0017】

以下に、本発明に係る空気圧管理装置の実施形態を図面に基づいて説明する。なお、本実施形態により本発明が限定されるものではない。また、本実施形態における構成要素には、当業者が置換可能、且つ、容易に想到できるもの、或いは実質的に同一のものが含まれる。

【0018】

本実施形態に係る空気圧管理装置は、複数の車両に装着されたタイヤ（空気入りタイヤ）の空気圧を一元的に管理する。具体的には、空気圧管理装置は、タクシーのような事業体が保有する多数の車両、もしくはカーシェアリングやレンタカーのように、事業体が保有して多数のユーザが共同利用する多数の共用車両に装着されるタイヤの空気圧を一元的に管理する場合に好適である。本実施形態では、空気圧管理装置がカーシェアリング事業に用いられる場合を例示して説明する。

【0019】

カーシェアリング事業は、事前に登録されたユーザに共用車両を貸し出して、これら共用車両をユーザ間で共同利用するサービスをいう。カーシェアリング事業では、複数の共用車両はそれぞれステーションと呼ばれる駐車地に駐車されている。このステーションに駐車される共用車両の数や、所定領域範囲内に点在するステーションの数は、事業規模などに応じて適宜決められる。ユーザが共用車両を利用するときには、ステーションが共用車両の出発地および返却地となる。本実施形態では、例えば、共用車両がステーションに返却されると、空気圧管理装置の管理の下、該共用車両の空気圧異常の有無および異常の種別が判定される。空気圧異常が発生した場合、空気圧管理装置は、該当する共用車両もしくはステーションを管理する車両管理者に通知する。

【0020】

図１は、本実施形態に係る空気圧管理装置を備えたタイヤ空気圧管理システムの全体構成を示すブロック図である。図１に示すように、タイヤ空気圧管理システム１００は、複数の共用車両（車両）１のタイヤ２にそれぞれ設けられたセンサ３と、複数の共用車両１が駐車されるステーションに設置されるセンサ受信端末１０と、このステーションを管理する管理者端末２０と、クラウドサーバ（空気圧管理装置）３０とを備える。

【0021】

センサ受信端末１０、管理者端末２０およびクラウドサーバ３０は、インターネット回線などの通信ネットワーク４０を介して通信可能に接続されている。また、クラウドサーバ３０は、カーシェアリング事業体が有するカーシェアリング管理サーバ（不図示）と通信ネットワーク４０を介して通信可能に接続されている。このカーシェアリング管理サーバは、複数の共用車両に対するユーザの利用予約を受け付け、予約された共有車用の利用予定情報を作成する。この利用予定情報には、共用車両１の車両情報、利用開始時刻、利用終了時刻、並びに、出発地および返却地となるステーションに関する情報を含む。図１の例では、共用車両１、センサ受信端末１０および管理者端末２０は、便宜上、それぞれ１つずつ示しているが、これら共用車両１、センサ受信端末１０および管理者端末２０は、実際にはそれぞれ複数設けられている。

【0022】

センサ３は、少なくともＴＰＭＳ(Tire Pressure Monitoring System)機能を備えており、タイヤ２の空気圧を検知する空気圧センサ３ａと、タイヤ２内の空気の温度を検知する温度センサ３ｂとを備えて構成される。また、センサ３は、タイヤ２に作用する遠心方向加速度を検知する加速度センサを更に備えた構成としてもよく、摩耗検知、路面検知、故障検知、取付けボルトの緩み検知などの付加的な検知機能を実現するために、圧電センサや静電容量センサ、磁気センサ、MEMSマイクセンサなどを適宜、追加した構成とすることもできる。センサ３は、それぞれタイヤ２内の内面に取り付けられている。このため、センサ３は、タイヤ２の外側空間の環境の影響を受け難くなっているとともに、センサ３付きのタイヤ２に交換するといった簡易な構成で、タイヤ２の空気圧や温度を容易に検知することが可能となる。センサ３には、それぞれセンサＩＤ（識別情報）が設定されており、センサ３のセンサＩＤと、該センサ３を備えるタイヤ２の車輪位置（左前輪、右前輪、左後輪または右後輪）との対応関係がセンサ受信端末１０に登録されている。センサ３は、駆動電源となる電池と備えており、例えば、共用車両１がステーションに駐車されている間、所定時間（例えば３分間）ごとに空気圧および温度のデータ（センサ情報）を検知して、この検知したデータをセンサＩＤ（識別情報）とともにセンサ受信端末１０に送信する。この構成により、共用車両１が所定のステーションに返却された後（例えば夜間時間帯）におけるタイヤ２の空気圧の変化（低減）を検知することができる。センサ３の電池の寿命は、一般的なタイヤ２の耐用年数よりも長く設定されている。センサ３からセンサ受信端末１０へのデータの送信は、例えば、ＲＦ(Radio Frequency)通信のような近距離無線通信を用いることができる。

【0023】

センサ受信端末１０は、共用車両１が駐車されるステーションに設置される。センサ受信端末１０は、図１に示すように、センサ受信部１１と、記憶部１２と、通信部１３と、制御部１４とを備える。センサ受信部１１は、各共用車両１における４つのタイヤ２のセンサ３からそれぞれ送信されたデータを受信する。記憶部１２は、揮発性または不揮発性のメモリやＨＤＤなどの記憶手段を備えて構成される。記憶部１２には、制御部１４が実施する各種のプログラムや、各種のデータが記憶される。本実施形態では、記憶部１２は、センサ受信部１１が所定時間毎に受信したデータのセンサＩＤから対応する共用車両１および車輪位置を判定し、受信したデータに含まれる各タイヤ２の空気圧および温度を対応する共用車両１の各車輪位置のタイヤの空気圧および温度の履歴情報として記憶する。なお、記憶部１２には、所定期間（例えば直近６カ月）の各タイヤ２の空気圧および温度を更新しつつ記憶してもよい。また、共用車両１において、タイヤ２をローテーションした際には、センサ受信端末１０に登録されたセンサＩＤと車輪位置との対応関係を修正するものとする。

【0024】

通信部１３は、通信ネットワーク４０を介してクラウドサーバ３０と無線通信可能に構成される。通信部１３は、共用車両１の車両ＩＤとともに、共用車両１に装着されたタイヤ２の空気圧情報を所定時間毎にクラウドサーバ３０に送信する。具体的には、通信部１３は、センサＩＤに対応する各共用車両１のタイヤ２の空気圧および温度を含む空気圧情報をクラウドサーバ３０に送信する。

【0025】

制御部１４はＣＰＵを有し、受信した各共用車両１の各タイヤ２の空気圧情報、または記憶部１２に記憶されたデータに基づいて所定の処理を実施する。

【0026】

クラウドサーバ３０は、複数の共用車両１のタイヤ２の空気圧を一元的に管理する。クラウドサーバ３０は、センサ受信端末１０から送信された共用車両１の各タイヤ２の空気圧情報を取得して記憶するとともに、各タイヤ２の空気圧異常の有無および異常の種別を判定する。また、クラウドサーバ３０は、タイヤ２の空気圧異常が判定された場合、該空気圧異常が生じた点、および異常の種別を、このタイヤ２が装着された共用車両１のステーションを管理する管理者端末２０に送信する。

【0027】

クラウドサーバ３０は、例えば、クラウドに設置されたコンピュータなどによって構成される。クラウドサーバ３０は、図１に示すように、通信部３１と、空気圧情報取得部（情報取得部）３２と、基準情報設定部３３と、温度換算空気圧算出部３４と、平均値算出部３５と、異常判定部３６と、空気圧低下量算出部３７と、記憶部３８と、制御部３９とを備える。

【0028】

通信部３１は、通信ネットワーク４０を介してセンサ受信端末１０および管理者端末２０と無線通信可能に構成される。通信部３１は、センサ受信端末１０から送信される各タイヤ２のデータ（センサ情報）を受信する。また、タイヤ２の空気圧異常が生じた場合には、該当する共用車両１が駐車されるステーションを管理する管理者端末２０に空気圧異常が生じた点、および空気圧異常の種別等の情報を送信する。

【0029】

空気圧情報取得部３２は、通信部３１を介して、センサ受信端末１０から受信した共用車両１の各タイヤ２の空気圧情報（センサ情報）を所定のタイミングで取得する。この所定のタイミングは適宜設定することができるが、各タイヤ２の空気圧異常の有無等を精度良く判定するために、所定時間（例えば３時間など）ごとにセンサ受信端末１０が集めた各タイヤ２の空気圧情報を取得してもよい。この空気圧情報には、共用車両１の車両ＩＤと、各センサ３のセンサＩＤと、センサＩＤと車輪位置との対応関係と、各センサ３が検知した各タイヤ２の空気圧および温度とを含む。

【0030】

基準情報設定部３３は、タイヤ２の基準空気圧および基準温度を含む基準情報を設定する。この基準情報は、タイヤ２の空気圧異常の有無、および異常の種別を判断する際の基準となる。基準情報は、例えば固定値でもよいし、あるパラメータに応じて変動する値であってもよい。本実施形態では、基準情報設定部３３は、基準空気圧としての初期値を、後述する温度換算空気圧の所定期間の平均値により随時更新して設定する。

【0031】

温度換算空気圧算出部３４は、制御部３９の制御下、取得した空気圧情報（センサ情報）および設定された基準情報に基づいて、基準温度における空気圧に換算した温度換算空気圧を算出する。一般に、タイヤ２の空気圧は、空気温度に応じて変化する傾向にあるため、車両運転中と停止中では空気圧が異なることもあり、空気圧の変動状態を正確に管理することが難しい。このため、温度換算空気圧算出部３４は、例えばボイル＝シャルルの法則などに基づき、タイヤ２の空気圧を上記した基準温度（例えば２０℃など）における空気圧に換算する。これによれば、タイヤ２の温度変化に伴う空気圧の変動を考慮することができるため、空気圧の変化をより正確に管理することができる。

【0032】

平均値算出部３５は、所定期間における温度換算空気圧の平均値を算出する。具体的には、同一のタイヤ２における過去の所定期間（例えば直近１０日間）の温度換算空気圧の平均値を算出する。共用車両１の重量変化（搭乗人数や荷物）や季節変動などによる外気温の変化などもタイヤ２の空気圧を変化させる外部変動要因となるが、この構成によれば、基準空気圧を温度換算空気圧の平均値で更新することにより、前記外部変動要因の影響を抑制した適正な基準空気圧を設定できるため、タイヤ２の空気圧異常の有無を精度良く判定することができる。

【0033】

異常判定部３６は、算出された温度換算空気圧と設定された基準空気圧との比較結果に基づいて、タイヤ２の異常の有無および該異常の種別を判定する。この場合、タイヤ２の異常とは主に空気圧異常である。また、タイヤ２の異常の種別とは、主に空気圧低下の状況をいい、例えば、１分間に５０ｋＰａ以上の空気圧低下を生じるパンクや、１日に５～２０ｋＰａ程度の空気圧低下を生じるスローリークなどがある。一般に、スローリークは、自然漏洩（温度一定条件で１ケ月に数ｋＰａ～２０ｋＰａ程度）よりも空気圧の低下速度が速く、通常のパンクよりも空気圧の低下速度が遅い。このため、スローリークの発生に運転者が気付きにくい点がある。特に、カーシェアリングの共用車両１では、ユーザ（運転者）は共用車両１を日常的に運転していないため、空気圧の低下傾向にある場合でもスローリークに気付きにくい。一方、スローリークが進んで空気圧が所定の基準値を下回ると、走行安全性が損なわれるため、スローリークを早急に判定することが要望されている。本実施形態では、異常判定部３６は、タイヤ２の空気圧異常が発生した場合、この異常種別をパンクであるかスローリークであるかを判定することにより、空気圧異常を適切に判定できる。

【0034】

具体的には、異常判定部３６は、基準空気圧と温度換算空気圧との差分値が第１閾値Ｋ１以上の場合に、タイヤ２に異常有りと判定する。また、異常判定部３６は、基準空気圧と温度換算空気圧との差分値が第１閾値Ｋ１よりも大きい第２閾値Ｋ２以上の場合に、異常の種別をタイヤ２の通常のパンクと判定し、差分値が第１閾値Ｋ１以上で第２閾値より小さい場合に、異常の種別をタイヤ２のスローリークと判定する。この第１閾値Ｋ１は、少なくともタイヤ２のスローリークが推定される閾値であり、第２閾値Ｋ２は、タイヤ２のパンクが推定される閾値である。これら閾値Ｋ１，Ｋ２は、例えば、ＪＡＴＭＡに規定される「最大空気圧」などに応じて定められる数値である。本実施形態では、タイヤ２の最大空気圧を２４０ｋＰａとした場合、第１閾値Ｋ１は、最大空気圧の約６％（１５ｋＰａ）に設定されている。この第１閾値Ｋ１は、最大空気圧の３～１２％に設定されることが好ましく、５～１０％に設定されることがより好ましい。また、第２閾値Ｋ２は、最大空気圧の約２０％（５０ｋＰａ）に設定されている。この第２閾値Ｋ２は、最大空気圧の１５～２５％に設定されることが好ましい。このように、異常判定部３６は、２段階の閾値を用いて、空気圧異常の種別を判定することにより、タイヤ２のスローリークを適切に判定することができる。

【0035】

また、異常判定部３６は、基準空気圧と温度換算空気圧との差分値が第１閾値Ｋ１以上で第２閾値より小さい場合、すなわち、空気圧異常の種別がタイヤ２のスローリークと判定された場合、この判定の正確性を担保する構成となっている。具体的には、異常判定部３６は、タイヤ２のスローリークと連続して判定された回数を計測し、この回数が所定回数（例えば１０回）を超えた場合に、スローリーク異常を出力してもよい。本実施形態では、毎日、温度換算空気圧の１日分の低下量を算出しておき、基準空気圧と温度換算空気圧との差分値が、例えば共用車両１の直近運行日１日分の上記低下量以上となった場合に、スローリークの異常を出力している。この構成では、タイヤ２の空気漏れが、直近運行日の１日分の温度換算空気圧の低下量以上生じていると判定されるため、該タイヤ２のスローリークを精度良く判定することができる。

【0036】

空気圧低下量算出部３７は、温度換算空気圧の１日分の低下量を算出する。上記したように、タイヤ２の空気圧は、パンクやスローリークなどの異常でなくても自然に漏洩する。このため、空気圧低下量算出部３７は、１日に１回、温度換算空気圧の１日分の低下量を算出し、この低下量を記憶部３８に記憶する。この低下量の算出は定時（例えば０時）に行うことが好ましく、定時の温度換算空気圧からその前日１日分（２４時間分）の低下量を算出することができる。本実施形態では、基準空気圧と温度換算空気圧との差分値が、共用車両１の前日（好ましくは直近運行日）１日分の温度換算空気圧低下量以上となった場合に、スローリークの異常を出力することで、該タイヤ２のスローリークを精度良く判定することができる。タイヤ２は、静的（止まっている）な状態よりも動的（運行している）な状態の方が、空気漏れが多く、空気圧の低下量が大きい。このため、本構成では、共用車両１が直近に運行された日の１日分の温度換算空気圧の低下量を基準とすることで、タイヤ２のスローリークを精度良く判定することができる。

【0037】

記憶部３８は、揮発性または不揮発性のメモリやＨＤＤなどの記憶手段を備えて構成される。記憶部３８には、制御部３９が実施する各種のプログラムや、算出された各種データが記憶される。記憶部３８は、所定時間ごとに空気圧情報取得部３２が取得した空気圧情報を、車両ＩＤ（共用車両１）毎に、センサＩＤに対応する車輪位置のタイヤ２の空気圧および温度を履歴情報として記憶する。また、記憶部３８は、対象の共用車両１に対して空気圧のメンテナンスが実施された場合、このメンテナンス履歴情報を記録する。

【0038】

また、記憶部３８は、タイヤ２の温度換算空気圧と温度との対応関係を示すデータ群（学習モデル）を記憶してもよい。このデータ群は、タイヤ２の温度とその温度で換算された温度換算空気圧との組データを多数集計し、例えば機械学習のアルゴリズムであるＫ－ｍｅａｎｓ法、ＳＶＭ、ＬＯＦ等を用いたクラスタリング手法を用いることで、これら多数の組データ（学習データ）に基づいた学習モデルとして生成される。タイヤ２の温度換算空気圧と温度とは、空気圧の正常時に、走行時の発熱や外気温の上昇により、いずれも上昇する。また、走行した後に一定時間以上停車したり、外気温が低下すると、タイヤ２の温度換算空気圧と温度とはいずれも下降する。このように相対的に同様な変化を起こす現象を利用して、少なくともこれら２つの組データを学習データとして用いることで、精度の高い群データ（学習モデル）を生成できる。

【0039】

また、組データには、タイヤサイズパラメータ、例えばタイヤ２の寸法値（タイヤ幅、外径、断面高さなど）や種類（トレッドラジアルなど）を更に含み、これらタイヤ２の寸法値や種類ごとに、データ群（学習モデル）が作成されてもよい。この構成によれば、タイヤサイズパラメータを学習データに追加することで、学習データが無い／不足しているタイヤサイズにおいて、異常判定の精度低下を抑制することができる。また、組データには、タイヤ２の温度換算空気圧と温度を計測した際の時間を、時系列情報として用いることもできる。この時系列情報も学習データに追加することで、自然空気漏れの影響をも考慮することが可能となる。クラウドサーバ３０は、定期的に多数の共用車両１から空気圧情報（センサ情報）を取得するため、この取得した空気圧情報から得られるタイヤ２の温度と温度換算空気圧との組データを、定期的に追加することで、データ群（学習モデル）を更新してもよい。

【0040】

この構成では、異常判定部３６は、生成されたデータ群（学習モデル）に、温度換算空気圧と温度との組データを入力したクラスタリング結果により、タイヤの異常の有無および異常の種別を判定することができる。

【0041】

制御部３９はＣＰＵを有し、通信部３１を介してセンサ受信端末１０、管理者端末２０およびカーシェアリング管理サーバから受信した情報、または記憶部３８に記憶されたデータに基づいて所定の処理を実施する。また、制御部３９は、対象の共用車両１の空気圧異常がパンクと判定された場合、この共用車両１のステーションの管理者端末２０およびカーシェアリング管理サーバに対して、該共用車両１のタイヤ２にパンクが生じた点を出力する。この場合、カーシェアリング管理サーバは、その当日に該共用車両１の利用予約が入っているかを確認し、利用予約が入っている場合には、同クラスの別の共用車両１に利用予約を振り替えるとともに、その旨をユーザに通知する。一方、管理者端末２０を通じて、パンクが生じた点が通知されたステーション側では、該共用車両１のタイヤ２のメンテナンス（パンク修理）を行う。

【0042】

また、制御部３９は、対象の共用車両１の空気圧異常がスローリークと判定された場合、この共用車両１のステーションの管理者端末２０およびカーシェアリング管理サーバに対して、該共用車両１のタイヤ２にスローリークが生じている点を出力する。一般に、スローリークは、その段階で即座に共用車両１の利用を停止する程度のものではない。このため、カーシェアリング管理サーバは、その当日に該共用車両１の利用予約が入っている場合には、ユーザに対して、利用する共用車両１の空気補充の依頼を通知する。そして、ユーザが空気補充を実行した場合には、例えば利用料金の割引クーポンなどを送ってもよい。一方、管理者端末２０を通じて、スローリークが生じた点が通知されたステーション側では、該共用車両１の利用予約がない場合に、タイヤ２のメンテナンス（空気補充、あるいは、タイヤやエアバルブ、ホイールなどの損傷確認等）を行う。

【0043】

管理者端末２０は、共用車両１が駐車されるステーションに設けられる端末装置である。管理者端末２０は、図１に示すように、通信部２１と、記憶部２２と、表示部２３と、入力部２４と、報知部２５と、制御部２６とを備える。通信部２１は、通信ネットワーク４０を介してクラウドサーバ３０と無線通信可能に構成される。通信部２１は、クラウドサーバ３０から対象の共用車両１の空気圧異常の有無、および空気圧異常の種別に関する情報を受信する。また、通信部２１は、ステーションの作業員によって、共用車両１に対するパンク修理の実行が入力されると、該共用車両１の車両ＩＤとともにメンテナンス終了情報をクラウドサーバ３０に送信する。ここで、クラウドサーバ３０はメンテナンス終了情報を受信すると、メンテナンスの終了報告をカーシェアリング管理サーバに送信する。これにより、メンテナンスが終了した共用車両１から順次、新たな利用予約を受け付けることが可能となる。

【0044】

記憶部２２は、揮発性または不揮発性のメモリやＨＤＤなどの記憶手段を備えて構成される。記憶部２２には、制御部２６が実施する各種のプログラムや、各種のデータが記憶される。

【0045】

表示部２３は、端末の略中央部に配置され、各種情報を表示してステーションの作業員に提供する表示画面である。表示部２３には、作業員の操作に基づき、対象の共用車両１の各種情報を表示することができる。

【0046】

入力部２４は、例えば、表示部２３上に重ねて形成されたタッチパネルであり、管理者端末２０に対する各種情報の入力を実施する。報知部２５は、クラウドサーバ３０から対象の共用車両１の空気圧異常に関する情報を受信すると、その旨を報知する。報知部２５は、例えば表示部２３に空気圧異常が発生した共用車両１とタイヤ２の位置情報を表示してもよいし、これに加えて表示灯の点灯や報知音の発報といった構成としてもよい。制御部２６はＣＰＵを有し、通信部２１を介してクラウドサーバ３０から受信した情報、または記憶部２２に記憶されたデータに基づいて所定の処理を実施する。

【0047】

次に、本実施形態に係るクラウドサーバ３０の動作について説明する。図２は、空気圧管理システムの動作手順を示すフローチャートである。図３は、図２における空気圧管理装置のパンク判定処理の動作手順を示すフローチャートである。

【0048】

図２に示すように、共用車両１がステーションに返却される（ステップＳＴ１）と、管理者端末２０の制御部２６は、返却されてから任意の所定時間が経過するか否かを判定する（ステップＳＴ２）。この所定時間は、共用車両１のタイヤ２が冷間されるまでの期間に相当しており、制御部２６は、返却されてから例えば１５分が経過したか否かを判定する。この判定において、所定時間の経過前の場合（ステップＳＴ２；Ｎｏ）、タイヤ２の温度の変動（低下）が大きい場合があり、その場合は空気圧も変動（低下）することになるため、所定時間か経過するまで待機することで、精度良い判定をすることができる。

【0049】

一方、所定時間が経過している場合（ステップＳＴ２；Ｙｅｓ）には、クラウドサーバ３０の制御部３９は、パンク判定処理を実行する（ステップＳＴ３）。そして、クラウドサーバ３０の制御部３９は、共用車両１のタイヤ２に通常パンク判定があったか否かを判定し（ステップＳＴ４）、通常パンク判定があった場合（ステップＳＴ４；Ｙｅｓ）には、処理をステップＳＴ６に移行する。また、通常パンク判定がなかった場合（ステップＳＴ４；Ｎｏ）、クラウドサーバ３０の制御部３９は、共用車両１のタイヤ２にスローリーク判定があったか否かを判定する（ステップＳＴ５）。この判定において、スローリーク判定があった場合（ステップＳＴ５；Ｙｅｓ）には、処理をステップＳＴ６に移行し、スローリーク判定がなかった場合（ステップＳＴ５；Ｎｏ）には、処理を終了する。

【0050】

通常パンク判定、またはスローリーク判定があった場合、クラウドサーバ３０の制御部３９は、通信部３１を介して、対象の共用車両１が駐車されたステーションを管理する管理者端末２０に空気圧異常の種別を報知する（ステップＳＴ６）。具体的には、制御部３９は、対象の共用車両１の空気圧異常の種別がパンク（通常パンク）と判定された場合、この共用車両１のステーションの管理者端末２０およびカーシェアリング管理サーバに対して、該共用車両１のタイヤ２にパンクが生じた点を通知する。この場合、カーシェアリング管理サーバは、その当日に該共用車両１の利用予約が入っているかを確認し、利用予約が入っている場合には、同クラスの別の共用車両１に利用予約を振り替えるとともに、その旨をユーザに通知する。また、管理者端末２０にパンクが生じた点が通知されると、ステーション側では、該共用車両１のタイヤ２のパンク修理を行う。

【0051】

また、制御部３９は、対象の共用車両１の空気圧異常の種別がスローリークと判定された場合、この共用車両１のステーションの管理者端末２０およびカーシェアリング管理サーバに対して、該共用車両１のタイヤ２にスローリークが生じている点を報知する。この場合、カーシェアリング管理サーバは、その当日に該共用車両１の利用予約が入っている場合には、ユーザに対して、利用する共用車両１の空気補充の依頼を通知することが好ましい。そして、ユーザが空気補充を実行した場合には、例えば利用料金の割引クーポンなどを送る。一方、管理者端末２０を通じて、スローリークが生じた点が通知されたステーション側では、該共用車両１の利用予約がない場合に、タイヤ２のメンテナンス（空気補充）を行う。

【0052】

次に、クラウドサーバ３０のパンク判定処理について説明する。図３に示すように、クラウドサーバ３０は、空気圧情報取得部３２により、センサ受信端末１０から受信した共用車両１の各タイヤ２の空気圧情報（センサ情報（Ｐｉ、Ｔｉ））を所定のタイミングで取得する（ステップＳＴ１１）。この空気圧情報には、共用車両１の車両ＩＤと、各センサ３のセンサＩＤと、センサＩＤと車輪位置との対応関係と、各センサ３が検知した各タイヤ２の空気圧および温度とを含む。

【0053】

次に、クラウドサーバ３０は、基準情報設定部３３により、タイヤ２の基準空気圧および基準温度を含む基準情報（Ｐｏ、Ｔｏ）を設定する（ステップＳＴ１２）。本実施形態では、基準情報設定部３３は、同一のタイヤ２における過去の所定期間（例えば直近１０日間）の温度換算空気圧の平均値を基準温度として設定する。

【0054】

次に、クラウドサーバ３０は、温度換算空気圧算出部３４により、空気圧情報（センサ情報（Ｐｉ、Ｔｉ））および設定された基準情報（Ｐｏ、Ｔｏ）に基づいて、基準温度における空気圧に換算した温度換算空気圧（Ｐｉ´）を算出する（ステップＳＴ１３）。温度換算空気圧算出部３４は、例えばボイル＝シャルルの法則などに基づき、タイヤ２の空気圧（Ｐｉ）を基準温度（Ｔｏ）における空気圧に換算する。

【0055】

次に、クラウドサーバ３０は、異常判定部３６により、基準空気圧（Ｐｏ）と温度換算空気圧（Ｐｉ´）との差分値が第１閾値Ｋ１以上であるか否かを判定する（ステップＳＴ１４）。この第１閾値Ｋ１は、空気圧異常の有無を判定するための閾値であり、少なくともタイヤ２のスローリークが推定される閾値である。本実施形態では、ＪＡＴＭＡに規定されるタイヤ２の最大空気圧を２４０ｋＰａとした場合、第１閾値Ｋ１は、最大空気圧の約８％（２０ｋＰａ）に設定されている。この判定において、基準空気圧（Ｐｏ）と温度換算空気圧（Ｐｉ´）との差分値が第１閾値Ｋ１以上である場合（ステップＳＴ１４；Ｙｅｓ）、クラウドサーバ３０は、処理をステップＳＴ１５に移行する。

【0056】

また、基準空気圧（Ｐｏ）と温度換算空気圧（Ｐｉ´）との差分値が第１閾値Ｋ１以上でない場合（ステップＳＴ１４；Ｎｏ）、異常判定部３６は、共用車両１のタイヤ２には空気圧異常はないと判定して（ステップＳＴ１６）処理を終了する。

【0057】

次に、クラウドサーバ３０は、異常判定部３６により、基準空気圧（Ｐｏ）と温度換算空気圧（Ｐｉ´）との差分値が第２閾値Ｋ２以上であるか否かを判定する（ステップＳＴ１５）。この第２閾値Ｋ２は、空気圧異常の種別をタイヤ２のパンクかスローリークかを判定する基準となり、タイヤ２のパンクが推定される閾値である。第２閾値Ｋ２は、第１閾値Ｋ１よりも大きな値である。本実施形態では、ＪＡＴＭＡに規定されるタイヤ２の最大空気圧を２４０ｋＰａとした場合、第２閾値Ｋ２は、最大空気圧の約２０％（５０ｋＰａ）に設定されている。この判定において、基準空気圧（Ｐｏ）と温度換算空気圧（Ｐｉ´）との差分値が第２閾値Ｋ２以上でない場合（ステップＳＴ１５；Ｎｏ）、クラウドサーバ３０は、処理をステップＳＴ１７に移行する。この場合、異常判定部３６は、共用車両１のタイヤ２は、異常種別がスローリークの異常であると判定し（ステップＳＴ１７）、処理を終了する。

【0058】

この判定において、基準空気圧（Ｐｏ）と温度換算空気圧（Ｐｉ´）との差分値が第２閾値Ｋ２以上である場合（ステップＳＴ１５；Ｙｅｓ）、クラウドサーバ３０は、処理をステップＳＴ１８に移行する。この場合、異常判定部３６は、共用車両１のタイヤ２は、異常種別がパンクの異常であると判定し（ステップＳＴ１８）、処理を終了する。このように、本実施形態では、異常判定部３６は、２段階の閾値Ｋ１、Ｋ２を用いて、空気圧異常の種別を判定することにより、タイヤ２のスローリークを適切に判定することができる。

【0059】

本実施形態では、異常判定部３６が空気圧異常の種別をタイヤ２のスローリークと判定した場合、異常判定部３６は、この判定の正確性を担保するための動作を実行する。図４は、空気圧管理装置がスローリーク判定を出力する際の動作手順を示すフローチャートである。このフローチャートでは、ステップＳＴ１０１からステップＳＴ１０７に処理を繰り返し実行する。また、このフローチャートでは、図３におけるフローチャートでスローリークの異常があると判定される（ステップＳＴ１７）と、判定フラグを立てるようになっている。

【0060】

図４に示すように、クラウドサーバ３０は、異常判定部３６により、スローリークの判定フラグ数Ｎが１以上であるか否かを判定する（ステップＳＴ１０１）。この判定において、スローリークの判定フラグ数Ｎが１以上でなければ（ステップＳＴ１０１；Ｎｏ）、処理を終了して、再度ステップＳＴ１０１を開始する。また、スローリークの判定フラグ数Ｎが１以上であれば（ステップＳＴ１０１；Ｙｅｓ）、クラウドサーバ３０は、処理をステップＳＴ１０２に移行する。

【0061】

次に、クラウドサーバ３０は、異常判定部３６により、新たなスローリークの異常判定があるか否かを判定する（ステップＳＴ１０２）。具体的には、図３のフローチャートにおけるステップＳＴ１７の処理が新たになされた場合には、新たなスローリークの異常判定があると判定される。一方、図３のフローチャートにおいて、例えば、空気圧異常がないと判定されたり、パンクの異常が判定されたりした場合には、新たなスローリークの異常判定がないと判定される。この判定において、新たなスローリークの異常判定がある場合（ステップＳＴ１０２；Ｙｅｓ）には、クラウドサーバ３０は、異常判定部３６により、スローリークの判定フラグ数Ｎに１を加える（ステップＳＴ１０３）。すなわち、異常判定部３６は、スローリークの判定フラグ数（判定された回数）を積算する。一方、新たなスローリークの異常判定がない場合（ステップＳＴ１０２；Ｎｏ）には、クラウドサーバ３０は、処理をステップＳＴ１０７に移行する。

【0062】

次に、クラウドサーバ３０は、異常判定部３６により、スローリークの判定フラグ数Ｎが所定値ａ（例えば１０）よりも大きいか否かを判定する（ステップＳＴ１０４）。この判定では、積算されたスローリークの判定フラグ数（判定された回数）が所定値ａ（例えば１０）を超えたか否かを判定する。この判定において、スローリークの判定フラグ数Ｎが所定値ａよりも大きい場合（ステップＳＴ１０４；Ｙｅｓ）には、クラウドサーバ３０は、処理をステップＳＴ１０５に移行する。また、スローリークの判定フラグ数Ｎが所定値ａよりも大きくない場合（ステップＳＴ１０４；Ｎｏ）には、クラウドサーバ３０は、処理を終了して、再度ステップＳＴ１０１を開始する。

【0063】

次に、クラウドサーバ３０は、異常判定部３６により、基準空気圧（Ｐｏ）と温度換算空気圧（Ｐｉ´）との差分値が第３閾値Ｋ３以上であるか否かを判定する（ステップＳＴ１０５）。この第３閾値Ｋ３は、毎日算出される１日分（０時から翌日の０時まで）の温度換算空気圧の低下量である。この構成では、１日の空気圧の低下量（第３閾値Ｋ３）以上に、温度換算空気圧が該温度換算空気圧の平均値から低下していることとなる。このため、基準空気圧（Ｐｏ）と温度換算空気圧（Ｐｉ´）との差分値が第３閾値Ｋ３以上であるか否かを判定することで、該タイヤ２のスローリークの判定精度を高めることができる。ここで、タイヤ２は、静的（止まっている）な状態よりも動的（運行している）な状態の方が、空気漏れが多く、空気圧の低下量が大きい。このため、本構成では、共用車両１が直近に運行された日の温度換算空気圧の低下量を基準とするが好ましい。この構成によれば、タイヤ２のスローリークをさらに精度良く判定することができる。

【0064】

この判定において、基準空気圧（Ｐｏ）と温度換算空気圧（Ｐｉ´）との差分値が第３閾値Ｋ３以上である場合（ステップＳＴ１０５；Ｙｅｓ）には、クラウドサーバ３０は、異常判定部３６により、スローリーク判定を出力する（ステップＳＴ１０６）。この構成では、スローリークの判定精度を高めることができる。

【0065】

一方、基準空気圧（Ｐｏ）と温度換算空気圧（Ｐｉ´）との差分値が第３閾値Ｋ３以上でない場合（ステップＳＴ１０５；Ｎｏ）には、クラウドサーバ３０は、異常判定部３６により、スローリークの判定フラグ数Ｎを０にして（ステップＳＴ１０７）、処理を終了する。

【0066】

上記した実施形態では、異常判定部３６は、２段階の閾値Ｋ１、Ｋ２を用いて、空気圧異常の種別を判定するパンク判定処理を説明したが、この判定手法に限るものではない。次に、異常判定部３６がタイヤ２の温度換算空気圧と温度との対応関係を示すデータ群を用いて、空気圧異常の種別を判定するパンク判定処理について説明する。図５は、別のパンク判定処理の動作手順を示すフローチャートであり、図６は、タイヤの温度換算空気圧と温度との対応関係を示すデータ群の一例を示す図である。

【0067】

図５において、クラウドサーバ３０は、空気圧情報取得部３２により、センサ受信端末１０から受信した共用車両１の各タイヤ２の空気圧情報（センサ情報（Ｐｉ、Ｔｉ））を所定のタイミングで取得する（ステップＳＴ１１１）。この空気圧情報には、共用車両１の車両ＩＤと、各センサ３のセンサＩＤと、センサＩＤと車輪位置との対応関係と、各センサ３が検知した各タイヤ２の空気圧および温度とを含む。

【0068】

次に、クラウドサーバ３０は、基準情報設定部３３により、タイヤ２の基準空気圧および基準温度を含む基準情報（Ｐｏ、Ｔｏ）を設定する（ステップＳＴ１１２）。本実施形態では、基準情報設定部３３は、同一のタイヤ２における過去の所定期間（例えば直近１０日間）の温度換算空気圧の平均値を基準温度として設定する。

【0069】

次に、クラウドサーバ３０は、温度換算空気圧算出部３４により、空気圧情報（センサ情報（Ｐｉ、Ｔｉ））および設定された基準情報（Ｐｏ、Ｔｏ）に基づいて、基準温度における空気圧に換算した温度換算空気圧（Ｐｉ´）を算出する（ステップＳＴ１１３）。温度換算空気圧算出部３４は、例えばボイル＝シャルルの法則などに基づき、タイヤ２の空気圧（Ｐｉ）を基準温度（Ｔｏ）における空気圧に換算する。

【0070】

次に、クラウドサーバ３０は、異常判定部３６により、基準空気圧（Ｐｏ）と温度換算空気圧（Ｐｉ´）との差分値が第４閾値Ｋ４（所定閾値）以上であるか否かを判定する（ステップＳＴ１１４）。この第４閾値Ｋ４は、空気圧異常の種別をタイヤ２のパンクかスローリークかを判定する基準となり、タイヤ２のパンクが推定される閾値であり、上記した第２閾値Ｋ２とほぼ同一の値を用いることができる。本実施形態では、ＪＡＴＭＡに規定されるタイヤ２の最大空気圧を２４０ｋＰａとした場合、第４閾値Ｋ４は、最大空気圧の約２０％（５０ｋＰａ）に設定されている。この判定において、基準空気圧（Ｐｏ）と温度換算空気圧（Ｐｉ´）との差分値が第４閾値Ｋ４以上である場合（ステップＳＴ１１４；Ｙｅｓ）、クラウドサーバ３０は、処理をステップＳＴ１１９に移行する。この場合、異常判定部３６は、共用車両１のタイヤ２は、異常種別がパンクの異常であると判定し（ステップＳＴ１９）、処理を終了する。

【0071】

この判定において、基準空気圧（Ｐｏ）と温度換算空気圧（Ｐｉ´）との差分値が第４閾値Ｋ４以上でない場合（ステップＳＴ１１４；Ｎｏ）、クラウドサーバ３０は、処理をステップＳＴ１１５に移行する。この場合、異常判定部３６は、温度換算空気圧（Ｐｉ´）と温度（Ｔｉ）と組データを、記憶部３８に記憶されたデータ群（学習モデル）に入力（比較）する（ステップＳＴ１１５）。そして、異常判定部３６は、クラスタリング結果により、タイヤの異常の有無を判定する（ステップＳＴ１１６）。具体的には、図６に示すように、データ群（学習モデル）は、タイヤ２の温度とその温度で換算された温度換算空気圧との組データを多数集計し、例えば機械学習のアルゴリズムであるＫ－ｍｅａｎｓ法、ＳＶＭ、ＬＯＦ等を用いてクラスタリングすることで、異常なしのクラスタと異常あり（スローリーク）のクラスタとに分類されている。異常判定部３６は、データ群（学習モデル）に、温度換算空気圧（Ｐｉ´）と温度（Ｔｉ）と組データをその都度、入力することにより、そのクラスタリング結果によって、共用車両１のタイヤ２に異常があるか否かを判定することができる。

【0072】

この判定において、異常がない場合（ステップＳＴ１１６；Ｎｏ）、クラウドサーバ３０は、処理をステップＳＴ１１７に移行する。この場合、異常判定部３６は、共用車両１のタイヤ２には空気圧異常はないと判定して（ステップＳＴ１１７）処理を終了する。

【0073】

また、この判定において、異常がある場合（ステップＳＴ１１６；Ｙｅｓ）、クラウドサーバ３０は、処理をステップＳＴ１１８に移行する。この場合、異常判定部３６は、共用車両１のタイヤ２は、異常種別がスローリークの異常であると判定し（ステップＳＴ１１８）、処理を終了する。このように、この別の手法では、１つの閾値Ｋ４と、データ群（学習モデル）とを用いて、空気圧異常の種別を判定することにより、タイヤ２のスローリークを適切に判定することができる。なお、図５のフローチャートにおいて、ステップＳＴ１１４と、ステップＳＴ１１５およびステップＳＴ１１６との順番を入れ替えて実行してもよい。

【0074】

以上、説明したように、本実施形態に係るクラウドサーバ３０は、共用車両１に装着されたタイヤ２の空気圧および温度を含むセンサ情報を所定のタイミングで取得する空気圧情報取得部３２と、タイヤ２の基準空気圧および基準温度を含む基準情報を設定する基準情報設定部３３と、センサ情報および基準情報に基づいて、基準温度におけるタイヤ２の温度換算空気圧を算出する温度換算空気圧算出部３４と、基準空気圧と温度換算空気圧との比較結果に基づいて、タイヤ２の異常の有無および該異常の種別を判定する異常判定部３６とを備える。この構成によれば、タイヤ２の空気圧異常の有無および異常の種別を精度良く判定できる。

【0075】

また、本実施形態に係るクラウドサーバ３０において、異常判定部３６は、基準空気圧と温度換算空気圧との差分値が第１閾値Ｋ１以上の場合に、タイヤ２に異常有りと判定し、かつ、差分値が第１閾値Ｋ１よりも大きい第２閾値Ｋ２以上の場合に、異常の種別をタイヤ２のパンクと判定し、差分値が第２閾値Ｋ２より小さい場合に、異常の種別をタイヤのスローリークと判定する。この構成によれば、２段階の閾値Ｋ１、Ｋ２を用いて、空気圧異常の種別を判定することにより、タイヤ２のスローリークを適切に判定することができる。

【0076】

本実施形態に係るクラウドサーバ３０において、異常判定部３６は、スローリークと判定された回数を計測し、連続して該スローリークと判定された回数が所定回数を超えた場合、スローリークの異常を出力する。この構成によれば、タイヤ２のスローリークを精度良く判定することができる。

【0077】

本実施形態に係るクラウドサーバ３０において、温度換算空気圧の１日分の低下量を算出する空気圧低下量算出部３７を備え、連続して該スローリークと判定された回数が所定回数を超えた場合、異常判定部３６は、基準空気圧と温度換算空気圧との差分値と、温度換算空気圧の１日分の低下量との比較結果に基づき、スローリークの異常を出力する。この構成によれば、温度換算空気圧の１日分の低下量を加味して、タイヤ２のスローリークを精度良く判定することができる。

【0078】

本実施形態に係るクラウドサーバ３０において、タイヤ２の温度換算空気圧と温度との対応関係を示すデータ群を記憶する記憶部３８を備え、異常判定部３６は、温度換算空気圧と温度との組データを、データ群と比較したクラスタリング結果により、タイヤ２の異常の有無を判定し、かつ、基準空気圧と温度換算空気圧との差分値が第４閾値Ｋ４以上であるか否かにより、異常の種別をタイヤ２のスローリークかタイヤ２のパンクかを判定する。この構成によれば、１つの閾値Ｋ４と、データ群（学習モデル）とを用いて、空気圧異常の種別を判定することにより、タイヤ２のスローリークを適切に判定することができる。

【0079】

本実施形態に係るクラウドサーバ３０において、所定期間における温度換算空気圧の平均値を算出する平均値算出部３５を備え、基準情報設定部３３は、温度換算空気圧の平均値を基準空気圧として設定する。この構成によれば、基準空気圧を温度換算空気圧の平均値で定期的に更新するため、適正な基準空気圧を用いることができ、タイヤ２の空気圧異常の有無を精度良く判定することができる。

【0080】

本実施形態に係るクラウドサーバ３０において、空気圧情報取得部３２、温度換算空気圧算出部３４および異常判定部３６は、共用車両１が規定の駐車地に駐車され、該共用車両１の運行が終了して所定時間が経過した後に、動作を実行する。この構成によれば、タイヤ２がある程度冷えているため、異常判定部３６によるパンク判定処理を精度良く実行することができる。

【0081】

本実施形態に係るクラウドサーバ３０において、車両１は、不特定のユーザに共用される共用車両であるため、例えば、カーシェアリングで利用される共用車両１のタイヤ２の空気圧異常の有無および異常の種別を適切に判定することができる。

【0082】

以上、本発明の実施形態について説明したが、本発明は、上記実施形態に限定されるものではない。本実施形態では、クラウドサーバ３０は、カーシェアリング事業で利用される共用車両１に装着されたタイヤ２の空気圧を管理するものであったが、例えば、予め登録されたユーザの車両に装着されたタイヤ２の空気圧を管理するものであってもよい。

【符号の説明】

【0083】

１ 共用車両（車両）
２ タイヤ
３ センサ
３ａ 空気圧センサ
３ｂ 温度センサ
１０ センサ受信端末
２０ 管理者端末
３０ クラウドサーバ
３１ 通信部
３２ 空気圧情報取得部（情報取得部）
３３ 基準情報設定部
３４ 温度換算空気圧算出部
３５ 平均値算出部
３６ 異常判定部
３７ 空気圧低下量算出部
３８ 記憶部
３９ 制御部
１００ タイヤ空気圧管理システム

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】