JP2017021567A - 保守管理システム - Google Patents

Abstract

【課題】駐車場等の各種設備や当該設備を構成する要素の特性に応じて、より的確な保守管理の運営を行うことができる保守管理システムを提供すること。【解決手段】保守管理システム１００において、駐車場の管理等を行うための各部に関するデータを保守管理サーバ５０が取得し、保守管理サーバ５０の判定部５３において、取得したデータの属性に応じた重み付け設定に基づき予測判定を行うことで、例えば通常設定されるメンテナンスの周期よりも短い周期で故障が発生したり、消耗品がなくなってしまったりするような場合であっても的確に保守管理の要否に関する予測判定をし、管理者等に連絡することができる。【選択図】図１

Description

本発明は、駐車場等の各種設備について保守管理を行うための保守管理システムに関する。

駐車場等の各種設備の運営において、設備の保守管理を行うために、例えば故障等の異常が発生した時に、設備の制御装置から管理装置に対して通知がなされている。また、保守管理の方法として、例えばメンテナンスの周期を予め定めておき、定期的に保守点検を行うことで、設備の構成部品のメンテナンスや消耗品の交換等が行われている。しかしながら、例えば駐車場等のように設備が屋外に設置され外部環境によって劣化具合が著しく異なるといった場合や、設備の利用頻度が予測よりも高くなった場合には、メンテナンスの周期よりも短い周期で故障が発生したり、消耗品がなくなってしまったりする可能性がある。駐車場の設備の故障等に対応するための技術として、駐車場における緊急情報等の各種情報を駐車場外に設置された管理コンピュータへ通知するもの（特許文献１）や、気象要因による故障診断・予測をするもの（特許文献２）が知られている。なお、設備の故障等に対応するための技術として、駐車場に関するものではないが、画像形成装置について障害の発生を予測するもの（特許文献３）や、複写機について異常を起こした原因となる部品を特定するもの（特許文献４）が知られている。

特開２００３−２５６５８９号公報 特開２００２−３１２０２９号公報 特開２０１３−１５６９６９号公報 特開２０１３−２５７４５９号公報

本発明は上記した点に鑑みてなされたものであり、駐車場等の各種設備や当該設備を構成する要素の特性に応じて、より的確な保守管理の運営を行うことができる保守管理システムを提供することを目的とする。

上記目的を達成するため、本発明に係る保守管理システムは、保守管理対象に関するデータを取得するデータ取得部と、データ取得部で取得されたデータの属性に応じた重み付け設定をし、当該重み付け設定に基づき保守管理の要否に関する予測判定を行う判定部と、予測判定の結果を通知する通知部とを備える。

上記保守管理システムによれば、保守管理対象に関するデータに基づき保守管理の要否に関する予測判定を行って結果を通知することで、より的確な保守管理の運営を行うことができる。この際、特に、取得したデータの属性に応じた重み付け設定に基づき予測判定を行うことで、例えば保守管理対象が、例えば塩害や雪害等の影響が大きく場所や時期によって通常設定されるメンテナンスの周期よりも短い周期で故障が発生したり、突発的な大量利用があって消耗品がなくなってしまったりするような場合であっても的確にメンテナンス時期を予測・判断し、管理者等に連絡することができる。なお、ここでの通知部については、無線通信や通信回線等により遠隔にある端末に通知を行うものに限らず、例えば、直接または間接的に接続される表示部に対して予測判定の結果を表示させるものも含むものとする。

本発明の具体的な側面では、データ取得部は、保守管理対象としての駐車場の設備に関するデータを取得する。この場合、駐車場の設備について、各部の属性に応じてより的確な保守管理の運営を行うことができる。

本発明の別の側面では、データ取得部は、保守管理対象の異常に関する異常関連情報のほか、保守管理対象の通常動作に関わる稼働情報と保守管理対象が設置された場所の外部環境に関わる環境情報とのうち少なくとも一方を含む保守管理対象情報を、保守管理対象に関するデータとして取得する。ここで、異常関連情報とは、保守管理対象の異常に関連する種々の情報を意味し、機器停止に及ぶような文字通り異常が発生していることを示す情報だけでなく、予告通知や警告といった異常の発生ではないがそのまま放置しておくといずれ異常となる可能性があることを示す情報といった広く異常に関連する情報全般を含む。この場合、異常関連情報に加え、稼働情報や環境情報についてのデータを取得し、これらに基づいて重み付け設定し、予測を行うことができる。

本発明のさらに別の側面では、判定部は、データ取得部において取得されるデータのうち異種の情報を組み合わせた重み付けに基づき予測判定を行う。この場合、異種の情報として例えば異常関連情報と稼働情報とを組み合わせて重み付けを行うことで、個々の保守管理対象の特性により対応した保守管理の要否に関する予測判定を行うことが可能になる。

本発明のさらに別の側面では、判定部は、データ取得部により保守管理対象に関するデータを定期的に取得して蓄積された履歴情報に基づいて重み付け設定をする。この場合、例えば定期的に取得して蓄積された履歴情報の変化度合に応じて重み付け設定をすることで、保守管理に関して、部品交換のタイミング等のメンテナンス時期をより的確に予測することができる。

本発明のさらに別の側面では、判定部は、重み付け設定で設定された重み付けの数値を保守管理対象に応じて設定される設定係数に乗算して得た数値と、予め設定された閾値とを比較して予測判定を行う。この場合、重み付けの数値、設定係数及び閾値に基づいて、簡易かつ迅速にメンテナンス時期を予測・判断できる。

本発明のさらに別の側面では、データ取得部は、同一構造を有しかつ互いに異なる位置に設置されることにより保守管理対象を構成する複数の構成要素について個別にデータを取得し、判定部は、複数の構成要素について個別に予測判定を行う。この場合、複数の構成要素のそれぞれの状況に応じた予測・判断ができる。

本発明のさらに別の側面では、データ取得部に保守管理対象に関するデータを送信するデータ送信端末と、通知部から予測判定の結果の通知を受けるデータ受信端末とをさらに備える。この場合、データの送受信において種々の方法を利用することで、例えば遠隔地にある駐車場等の保守管理対象についての保守管理を行うことが容易となる。

本実施形態に係る保守管理システムの一構成例について概念的に示す図である。 保守管理システムを構成する保守管理サーバについて説明するブロック図である。 保守管理対象の一例としての駐車場の各部について説明するブロック図である。 （Ａ）は、駐車場の精算機の構成について説明するブロック図であり、（Ｂ）は、精算機の正面図である。 （Ａ）は、保守管理サーバ内のデータベースに格納されるデータの一例について説明するブロック図であり、（Ｂ）は、（Ａ）の一部について説明するブロック図である。 （Ａ）は、異常関連情報発生に伴う重み付け設定のためのテーブルデータの一例を示す図であり、（Ｂ）は、環境情報発生に伴う重み付け設定のためのテーブルデータの一例を示す図であり、（Ｃ）は、稼働情報発生に伴う重み付け設定のためのテーブルデータの一例を示す図であり、（Ｄ）は、緊急度及び重要度のポイントについてのテーブルデータの一例を示す図である。 保守管理システムの各種処理の一例を示すフローチャートである。 保守管理システムの各種処理の一例を示すフローチャートである。 保守管理システムの各種処理の一例を示すフローチャートである。 図５の保守管理サーバ内のデータベースに格納されるデータの一例のうち他の一部について説明するブロック図である。 保守管理システムの他の一構成例について概念的に示す図である。 保守管理システムのさらに他の一構成例について概念的に示す図である。

以下、図１等を参照して、本発明の実施形態に係る保守管理システムの概要について説明する。

本実施形態に係る保守管理システム１００は、保守管理の現場である複数の駐車場Ｐａ，Ｐｂ，ＰＣ…の場内にそれぞれ設置されている駐車場システム５００と、保守管理対象に関するデータを取得して保守管理を行う保守管理装置によって構成される保守管理サーバ５０と、管理者が携帯し保守管理に関する種々の通知を受けるデータ受信端末である管理者端末７００とを備える。各駐車場システム５００は、保守管理対象に関するデータを送信するデータ送信端末である現場端末ＴＥをそれぞれ有し、各駐車場Ｐａ，Ｐｂ，ＰＣ…の現場端末ＴＥ，ＴＥ…と保守管理サーバ５０とは、例えばインターネット回線等の公衆回線ＩＮで通信する。特に、本実施形態では、保守管理サーバ５０は、現場端末ＴＥから取得したデータに基づき保守管理の要否に関する予測判定を行うものとなっている。また、保守管理サーバ５０と管理者端末７００とは、公衆回線ＩＮで通信し、例えば保守管理サーバ５０において各種情報処理の結果から緊急に保守管理が必要であると判断された場合、直ちに管理者端末７００に対して必要な情報が送信される。なお、本実施形態における保守管理システム１００は、主に一時利用をする車両（例えば四輪車）のための有料駐車場を管理対象として想定したものとなっている。すなわち、各駐車場システム５００は、発券装置や精算装置、ゲートやフラップ制御板等の種々の設備で構成されており、これらの各部や構成部品等が保守管理システム１００における保守管理の対象となっている。

以下、図２を参照して、保守管理サーバ５０の各部の構成について詳しく説明する。保守管理サーバ５０は、例えばＣＰＵや記憶装置等で構成される保守管理装置を適用するものであり、データ取得部５１と、登録部５２と、データベース部ＤＢと、判定部５３と、通知部５４とを備え、複数の駐車場Ｐａ，Ｐｂ，ＰＣ…（図１参照）の情報を一括管理している。

データ取得部５１は、公衆回線ＩＮ（図１参照）等の外部から入力される情報を受け付ける入力部として機能し、ここでは特に保守管理対象である駐車場システム５００を構成する各部に関する種々のデータを現場端末ＴＥから取得する。

登録部５２は、データ取得部５１において受け付けた情報を一時格納するメモリとして機能するとともに、取得した各種データを駐車場ごとに、かつ、各駐車場を構成する各部ごとに分類してデータベース部ＤＢ内に設けられた各領域に記憶させる。なお、データベース部ＤＢは、例えばハードディスクその他の記憶装置等により構成される大容量記憶部である。

判定部５３は、例えばＣＰＵや演算回路等で構成されており、登録部５２を介してデータベース部ＤＢ内に格納された各種情報を必要に応じて呼び出して、保守管理の要否に関する予測判定を行うとともに予測判定の結果を通知部５４に通知する。特に、本実施形態では、データ取得部５１で取得された駐車場システム５００の各構成部分のデータについて各データの属性に応じた重み付け設定をし、当該重み付け設定に基づき保守管理の要否に関する予測判定を行うことで、より的確な事前予測・判断を可能にしている。

通知部５４は、公衆回線ＩＮ（図１参照）等により外部へ情報を出力する出力部であり、ここでは特に上記予測判定の結果を含む駐車場システム５００における保守管理に関する情報を、例えば各駐車場Ｐａ，Ｐｂ，Ｐｃ…から離れた遠隔地にいる管理者が携帯する管理者端末７００に対して送信する。

以下、図３に示すブロック図を参照して、各駐車場（例えば駐車場Ｐａ）をそれぞれ管理・制御する駐車場システム５００の各部の構成について説明する。駐車場システム５００は、入場部ＥＮと、出場部ＥＸと、事前精算装置ＰＳと、複数のフラップ板ＦＰ，ＦＰ…とを備える。

駐車場システム５００のうち、入場部ＥＮは、発券機１１と、ゲート装置１２と、第１読取装置１３とを備える。発券機１１は、矢印Ａ１の方向から入場しようとする車両に対して駐車券排出口１１ａから駐車券を発券する駐車券発行機である。ゲート装置１２は、例えばゲート装置１２からの指令信号に従ってゲートバー１２ａを昇降させて車両の入場の許否を示す装置である。第１読取装置１３は、ＣＭＯＳ等で構成されるカメラ部を有する撮像装置であり、図示のように、ゲートバー１２ａの前方に配置されることで、入場しようとする車両の前方側のうち、特にナンバープレートを撮像可能な配置となっており、撮像画像は、例えば駐車場管理や不正防止等に利用可能となる。

駐車場システム５００のうち、出場部ＥＸは、精算装置３１と、ゲート装置３２と、第２読取装置３３とを備える。精算装置３１は、矢印Ａ２の方向から出場しようとする車両に対して駐車券挿入口３０から駐車券を挿入排出するとともに駐車料金精算に必要な各種処理を行う。ゲート装置３２は、例えば精算装置３１からの指令信号に従ってゲートバー３２ａを昇降させて車両の入場の許否を示す装置である。第２読取装置３３は、ＣＭＯＳ等で構成されるカメラ部を有する撮像装置であり、図示のように、ゲートバー３２ａの前方に配置されることで、第１読取装置１３の場合と同様に、出場しようとする車両の前方側のうち、特にナンバープレートを撮像可能な配置となっている。

駐車場システム５００のうち、事前精算装置ＰＳは、出場するために必要となる駐車料金の精算処理を事前に可能とするための装置であり、受付口に駐車券が挿入されると駐車料金精算に必要な各種処理を行うものとなっている。駐車場の利用者は、事前精算装置ＰＳを利用することで、出場部ＥＸにおいて精算処理を要することなく迅速に自己の車両を出場させることができる。

駐車場システム５００のうち、複数のフラップ板ＦＰ，ＦＰ…は、駐車場内の複数の車室ＶＩ，ＶＩ…にそれぞれ対して設けられ昇降動作により各車室に駐車した車両について個別ロックを行う。

ここで、本実施形態においては、一例として、上記駐車場システム５００のうち出場部ＥＸを構成する精算装置３１が、図示のように駐車場システム５００の各部（事前精算装置ＰＳを除く）と接続されており、駐車料金の精算処理のみならず駐車場システム５００の全体の動作制御を統括する主要部分として機能する。また、駐車場Ｐａで取得される種々の情報が、精算装置３１で集約され、現場端末ＴＥから保守管理サーバ５０に対して送信される。なお、本実施形態では、事前精算装置ＰＳについては、精算装置３１等とは分離して管理されている。例えば事前精算装置ＰＳは、精算装置３１とは別個に現場端末ＴＥを有し、事前精算装置ＰＳの各部に関する種々のデータを送信している。すなわち、精算装置３１と事前精算装置ＰＳとは、上位機構である保守管理サーバ５０に対してそれぞれ個別にデータ送信を行っている。

以下、図４等を参照して、精算装置３１の構造等について詳しく説明する。まず、図４（Ａ）及び４（Ｂ）に示すように、精算装置３１は、駐車料金の精算処理を行うための装置として、現金投入口１０と、リーダライタ部２０と、駐車券挿入口３０と、プリンター４０と、磁気カード読取部６０と、タッチパネル部ＴＯと、スピーカーＳＰと、呼出ボタンＢＴと、粉塵計ＤＭと、温度センサ部ＴＳと、現場端末ＴＥと、これらを統括制御する制御部９０とを備える。ここで、現金投入口１０、リーダライタ部２０、駐車券挿入口３０、プリンター４０、磁気カード読取部６０、タッチパネル部ＴＯ、スピーカーＳＰ及び呼出ボタンＢＴの各部には、それぞれ現金センサ部１０ａ、電子マネーセンサ部２０ａ、駐車券センサ部３０ａ、ロール紙センサ部４０ａ、磁気カードセンサ部６０ａ、スピーカーセンサ部ＳＰａ、タッチパネルセンサ部ＴＯａ及びボタンセンサ部ＢＴａがそれぞれ設けられており、各部の属性に応じた固有の事項についてそれぞれ検知し、検知結果を制御部９０に送信する。また、粉塵計ＤＭや温度センサ部ＴＳは、精算装置３１の内部に設置され、設置された各場所での粉塵量、温度をそれぞれ測定するための装置であり、センサの一種である。なお、制御部９０は、ＣＰＵ等で構成され各種動作を行う主制御部９０ａと、各種動作を行うためのプログラムやデータを格納するとともに各部について取得した各種情報を格納するデータ記憶部９０ｂとを備える。また、精算装置３１では、上記のように駐車場システム５００の全体動作を統括すべく制御部９０が、駐車場システム５００の各部と接続されている。すなわち、制御部９０には、上記精算装置３１を構成する現金投入口１０等の各部と同様に、発券装置１１等（図３参照）の精算装置３１以外の装置等の各構成要素にそれぞれ設けられたセンサ類から各構成要素の稼働状況や環境に関する情報、異常に関する情報等を含めた各種情報が送信可能となっている。

図４（Ｂ）に示すように、精算装置３１のうち、現金投入口１０は、貨幣用の投入口である貨幣投入口１１や紙幣用の投入口である紙幣投入口１２のほか、例えば貨幣受け口２３等を有し、駐車料金支払いのための現金投入や、お釣りの支払い、払戻し等、現金の授受を行うための窓口である。なお、現金センサ部１０ａは、例えば投入された貨幣、紙幣の種類や枚数のほか、紙幣の受付時のリトライ回数（紙幣の受付を拒否した回数）や、つり銭切れ等を検知し、検知結果を制御部９０に送信する。

リーダライタ部２０は、精算装置３１の正面部に取り付けられ、電子マネーカードをタッチすることで、当該電子マネーカードの情報を読み書きするための端末である。なお、電子マネーセンサ部２０ａは、例えば電子マネーカードとの送受信回数等のほか、データ読取り時のエラー回数等を検知し、検知結果を制御部９０に送信する。

駐車券挿入口３０は、駐車場への入場時に各車両に配布された駐車券を挿入させる、すなわち精算を開始させるための駐車券の受入口である。なお、駐車券センサ部３０ａは、例えば駐車券の受付回数等のほか、駐車券の読取り時のエラー回数等を検知し、検知結果を制御部９０に送信する。

プリンター４０は、制御部９０の制御下で動作する印刷部であり、精算完了に際して印刷媒体としてのロール紙に領収書の印刷を行う。なお、ロール紙センサ部４０ａは、例えば印刷回数やロール紙の残量（ロールの厚さ、予備のロール紙の本数）等のほか、ジャム発生回数や印刷用ヘッド部の状況等を検知し、検知結果を制御部９０に送信する。

磁気カード読取部６０は、クレジットカードその他の磁気で読み取り可能なカードであって精算において使用される種々のものについての情報の読取りを行う装置である。なお、磁気カードセンサ部６０ａは、カードの読取回数のほか、リトライ回数、すなわち１回で読み取れず２回以上カード読取の動作がなされたか否か等の情報を制御部９０に送信する。また、磁気カード読取部６０には、カードと接触または近接して読み取る箇所における粉塵の量を測定するための粉塵計ＤＭが設けられており、磁気カードセンサ部６０ａは、粉塵計ＤＭで検知された結果についても制御部９０に送信する。

タッチパネル部ＴＯは、例えば液晶パネル上に透明のセンサ部を設けて構成される装置であり、料金精算における各種情報伝達や各種指示等を表示動作により利用者に対して案内するモニター部（表示部）であるとともに、利用者のタッチ操作により入力指示を受け付ける入力装置として機能する。なお、タッチパネルセンサ部ＴＯａは、モニター部の表示時間の情報等のほか、表示の状態や透明のセンサ部の状態等の異常の有無等の情報について制御部９０に送信する。

スピーカーＳＰは、例えばタッチパネル部ＴＯでの表示案内に対応する音声案内を行う。すなわち、タッチパネル部ＴＯとスピーカーＳＰとは、利用者に対して精算のための各種情報を報知する。なお、スピーカーセンサ部ＳＰａは、スピーカーの使用時間の情報等のほか、音声の状態等の異常の有無等の情報について制御部９０に送信する。

呼出ボタンＢＴは、精算が完了できないといった各種不具合が発生した場合に利用者が駐車場の保守管理者を呼び出すために使用するボタンである。典型的には、例えば、磁気カード読取部６０においてカードを何回か読み取らせても（リトライしても）読出しができず、利用者が呼出ボタンＢＴを押して保守管理者が呼び出される、といったことが想定される。なお、ボタンセンサ部ＢＴａは、押された回数に関する情報等を制御部９０に送信する。

現場端末ＴＥは、既述のように、インターネット等の公衆回線ＩＮ（図１参照）を通じて、精算装置３１の制御部９０に集約された駐車場システム５００に関する各種情報（保守管理対象に関するデータ）を保守管理サーバ５０に送信する。送信された各種情報は、図２を参照して説明したように、保守管理サーバのデータ取得部５１及び登録部５２を経てデータベース部ＤＢの各領域に格納される。なお、現場端末ＴＥについては、駐車場の情報について通信可能な現場側通信部として機能できるものであれば種々の態様のもの（スマートフォンや携帯電話、Ｍ２Ｍ等）が適用可能である。

図５は、保守管理サーバ５０内のデータベース部ＤＢに格納されるデータの一例について概念的に示す図であり、図５（Ａ）は、格納される各種データの様子を示し、図５（Ｂ）は、データの一部について抽出して示すブロック図である。すなわち、データベース部ＤＢは、精算装置３１や発券装置１１等の駐車場システム５００の各構成要素に対応してこれらの情報を保存すべく、精算装置関連データ格納部ＳＤｄや、発券装置関連データ格納部ＴＳｄ、事前精算装置関連データ格納部ＰＳｄ、フラップ板関連データ格納部ＦＰｄ等を有する。さらに、各関連データ格納部内は、各装置等に固有の部材等に応じて格納されるデータが分類されており、例えば、精算装置３１に対応する精算装置関連データ格納部ＳＤｄは、精算装置３１を構成する磁気カード読取部６０や現金投入口１０等に対応するデータを取得するために、磁気カード読取部データ格納部ＭＣｄや、現金投入口データ格納部ＣＩｄ、リーダライタ部データ格納部ＲＷｄ、駐車券挿入口データ格納部ＰＩｄ、プリンターデータ格納部ＰＲｄ等で構成されている。

ここでは、上記のようにして各現場端末ＴＥから送信されデータベース部ＤＢに格納される各駐車場における保守管理対象に関するデータについて、３種類に分類するものとする。具体的には、保守管理対象に関するデータを、保守管理対象の異常に関する異常関連情報、保守管理対象の通常動作に関わる稼働情報及び保守管理対象が設置された場所の外部環境に関わる環境情報の３種類とする。このため、図５（Ｂ）において磁気カード読取部データ格納部ＭＣｄを抽出して例示するように、各格納部には、異常関連情報格納部ＡＲと、稼働情報格納部ＯＰと環境情報格納部ＥＶとが設けられている。

上記３つのうち、まず、異常関連情報については、保守管理対象の異常に関連する種々の情報を意味し、機器停止に及ぶような文字通り異常が発生していることを示す情報はもちろんのことこのような情報だけでなく、予告通知や警告といった異常の発生ではないがそのまま放置しておくといずれ異常となる可能性があることを示す情報といった広く異常に関連する情報全般を含むものとする。例えば、上記の例で言えば、呼出ボタンＢＴが押された場合に関する情報のように明らかに異常が発生していると考えられる情報や、カード読取におけるリトライ回数又はその頻度、通常動作として行われている駐車券の挿入回数や各種カードの読取回数があらかじめ定めた規定値（閾値）以上に達したことを伝える情報（すなわちいずれ異常となる予告通知や警告に相当する情報）等を含み、突発的に送信される場合もあれば、ある特定のタイミングで送信される場合もある情報である。

これに対して、稼働情報は、上記のような異常関連情報に含まれない通常動作に関わる情報を意味するものとする。例えば、上記の例で言えば、通常の動作における駐車券の挿入回数や各種カードの読取回数各種読取の回数の情報等を意味し、例えば１日１回まとめて各駐車場から送信される、といった具合に、通常定期的に送信される情報である。

また、環境情報とは、温度や湿度等のように、保守管理対象が設置された場所に影響を受ける情報を意味する。例えば、上記の例で言えば、粉塵計ＤＭによって検知される磁気カード読取部６０付近での粉塵量の情報や、温度センサ部ＴＳによって検知される精算装置３１の内部温度の情報等を意味し、定期的に送信される情報であることもあれば、ある特定の条件を満たした場合に送信されることもある情報である。

以上の異常関連情報、稼働情報及び環境情報については、逐次取得され、データベース部ＤＢの各格納部において履歴情報として累積されていく。

本実施形態では、上記のような保守管理対象に関するデータについての種々の情報（各部からの情報について検出された累積的回数（総回数）や一定期間内での回数（頻度）といった情報を含む）について、保守管理サーバ５０の判定部５３において上記各データの属性に応じた重み付け設定をし、当該重み付け設定に基づき保守管理の要否に関する予測判定を行うことで、より的確な事前予測・判断を可能にしている。従来の方法としては、例えば呼出ボタンが押されたといった単純に異常の発生が認められた場合に保守管理をするものや、これから発展した方法として、上記した稼働情報に基づいて利用回数等について閾値を定め、この閾値から部品交換や各種整備・点検といったメンテナンスの周期を予め定めておき、当該周期に従って定期的に保守点検や消耗品の交換等を行うこと等がなされてきた。しかしながら、例えば駐車場のように設備が屋外に設置され外部環境によって設備の劣化具合が著しく異なるといった場合や、設備の利用頻度が突発的に予測よりも高くなったといった場合にまで柔軟に適応できるとは限らなかった。これに対して、本実施形態では、例えば上記３つの情報のような異種の情報を組み合わせた重み付けに基づき予測判定を行うことで、例えば通常設定されるメンテナンスの周期よりも短い周期で故障が発生したり、消耗品がなくなってしまったりするような場合であっても判定部５３での予測判定（事前判断）に基づき的確に部品交換のタイミング等のメンテナンス時期を予測・判断できるものとなっている。

以下、図６に示すテーブルデータ等を参照して、保守管理サーバ５０によるメンテナンス時期や部品交換のタイミング等の予測・判断、すなわち判定部５３における重み付け設定に基づく保守管理の要否に関する予測判定（事前判断）の方法について説明する。ここでは、メンテナンスに関する一例として、精算装置３１の磁気カード読取部６０における故障発生の典型の一つとしてカード読取機能の劣化による当該部品の交換時期に関する事前判断を行うものとする。

まず、ここでは、通常の部品の交換タイミングを総使用回数により規定し、この規定値（通常の総使用回数）を判断基準となる閾値ＴＨとする。例えばＴＨ＝１００００（回）とする。すなわち、通常の使用態様であれば１００００回ごとに磁気カードの読取機構の部品交換を行うものとする。これに対して、本実施形態では、精算装置３１の磁気カード読取部６０での磁気カードの読取機構について初期（または交換直後）からの総使用回数に相当する設定係数ｙ（回）に対して、磁気カード読取部６０に関する各データの属性に応じて、異常関連情報、環境情報及び稼働情報の３種類についてそれぞれ設定される重み付けＷ_１，Ｗ_２，Ｗ_３（Ｗ_ｉ≧１．０、図６（Ａ）〜６（Ｃ）参照）に基づいて以下の式で定まる換算値ｆを算出し、
ｆ＝ｙ×Ｗ_１×Ｗ_２×Ｗ_３…（１）
上式（１）の重み付け設定に基づく換算値ｆ（以下、ｆを新たな設定係数とも言う）が閾値ＴＨ以上となるか否かによって交換時期であるか否かを事前判断する。すなわち、ｆ≧ＴＨであれば、部品の交換時期になっていると判断する（ｆ＜ＴＨであれば、まだ部品の交換時期になっていないと判断する）。

以下、図６（Ａ）〜６（Ｃ）を参照して、重み付けＷ_１，Ｗ_２，Ｗ_３についてより具体的に説明する。

まず、図６（Ａ）は、重み付けＷ_１について設定するためのテーブルデータであり、異常関連情報に関する重み付け設定の一例を示している。図示の場合、３段階で重み設定がなされる態様となっている。具体的には、異常関連情報として、磁気カード読取について読取不能であり利用者が呼出ボタンＢＴを押した呼出通報の回数（通報履歴）が、例えば直近１か月で１０回以上発生していることが送信されている場合には、設定１のＷ_１＝２．０とする。すなわち、通常の２倍の重み付けを行う。この場合、例えば総使用回数が規定回数（閾値ＴＨ＝１００００回）の半分である５０００回であったとしても、部品交換すべき時期になったと判断されることになる。また、設定１ほどの状態ではないが、例えば直近１か月でリトライ回数（２回以上続けて読取動作を行って初めて読取が完了している回数）が１５回以上発生していることが送信されている場合には、設定２のＷ_１＝１．５とする。すなわち、通常の１．５倍の重み付けを行う。この場合、例えば総使用回数が７０００回であったとしても、１．５×７０００＝１０５００＞１００００となり、部品交換すべき時期になったと判断されることになる。上記設定１や設定２以外の場合には、設定３のＷ_１＝１．０とする。すなわち、重み付けＷ_１の対象項目については、通常の使用態様の場合と同等と判断し、特段の重み付けを行わないことに相当するものとする。

図６（Ｂ）は、環境情報に関する重み付けＷ_２について設定するためのテーブルデータの一例である。磁気カード読取部６０に近接して設けられた粉塵計ＤＭによって検知される粉塵量（単位：ｃｐｍ）について予め２段階の規定値（閾値）Ｃ１，Ｃ２ｃｐｍ（Ｃ１＞Ｃ２）と計測回数についての規定回数とを定めておき、例えば直近１か月で第１規定値Ｃ１ｃｐｍ以上の値が粉塵計ＤＭにおいて規定回数以上発生している場合には、設定１のＷ_２＝２．０とする。すなわち、通常の２倍の重み付けを行う。また、設定１ほどの状態ではないが、例えば直近１か月で第１規定値Ｃ１ｃｐｍ以下だが第２規定値Ｃ２ｃｐｍ以上の値が粉塵計ＤＭにおいて規定回数以上発生している場合には、設定２のＷ_２＝１．５とする。すなわち、通常の１．５倍の重み付けを行う。上記設定１や設定２以外の場合には、設定３のＷ_２＝１．０とする。すなわち、重み付けＷ_２の対象項目については、通常の使用態様の場合と同等と判断し、特段の重み付けを行わないものとする。

図６（Ｃ）は、稼働情報に関する重み付けＷ_３について設定するためのテーブルデータの一例である。総使用回数に相当する設定係数ｙの値に関わらず、例えば直近１か月で３０００回以上の読取がなされた場合（つまり急激に利用回数が増加したと考えられる場合）には、設定１のＷ_３＝１．２とする。すなわち、通常の１．２倍の重み付けを行う。また、設定１ほどの状態ではないが、例えば直近１か月で２０００回以上３０００回未満の読取がなされた場合、設定２のＷ_３＝１．１とする。すなわち、通常の１．１倍の重み付けを行う。上記設定１や設定２以外の場合（すなわち直近１か月での読取回数が２０００回未満）には、設定３のＷ_３＝１．０とする。すなわち、重み付けＷ_３の対象項目については、通常の使用態様の場合と同等と判断し、特段の重み付けを行わないものとする。

また、上式（１）から明らかなように、各重み付け設定が重畳して行われる場合も生じ得る。例えば図６（Ａ）及び図６（Ｂ）のテーブルデータにおいてともに設定１となるような場合には、総使用回数が規定回数（１００００回）の１／４である２５００回であったとしても、部品の劣化が著しく進み部品交換すべき時期になったと判断されることになる。以上のように、判定部５３は、重み付けを行うに際して、異常関連情報や稼働情報、さらには環境情報といった異種の情報を組み合わせて、また、重み付けの数値Ｗ_１等を保守管理対象に応じて設定される設定係数ｙに乗算して得た数値（換算値ｆ）を算出し、算出した換算値ｆと予め設定された閾値ＴＨとを比較して予測判定を行っている。この場合、異種の情報を利用して個々の保守管理対象（上記の場合、磁気カード読取部６０）の特性により対応した保守管理の要否に関する予測判定を行うことが可能になり、また、各数値に基づいて、簡易かつ迅速に予測・判断できる。さらに、上記の例では、例えば直近１か月間でのデータといった定期的に取得して蓄積された履歴情報を利用することで、履歴情報の変化度合に応じた重み付け設定が可能となっている。

上記に加え、さらに、本実施形態では、図６（Ａ）〜６（Ｄ）に示すように、重み付け設定の対象となる異常関連情報、環境情報及び稼働情報の３種類について、緊急度（Ｅ_１，Ｅ_２，Ｅ_３）及び重要度（Ｓ_１，Ｓ_２，Ｓ_３）が、図６（Ｄ）に示すように、度合に応じてポイント制でそれぞれ設定されている。すなわち、緊急度及び重要度は、各テーブルデータの対象項目に応じて定めておき、例えば各項目の緊急度（Ｅ_１，Ｅ_２，Ｅ_３）や重要度（Ｓ_１，Ｓ_２，Ｓ_３）についてこれらを足し合わせた合計が予め定めた閾値以上となるか否かによって（すなわち、緊急度や重要度が高いに場合とそうでない場合とで）、管理者端末７００に対する通知（すなわち保守管理者に対する通知）の仕方を変えるようにすることができる。

なお、上記図６（Ａ）〜６（Ｄ）は、あくまで一例であり、まず、重み付け設定については、上記以外の種々の態様が可能である。例えば図６（Ａ）では、設定１において、１０回以上の通報履歴が発生したら交換としているが、例えば１回でも通報履歴が発生したら無条件に交換するものとし（例えば重み付けを無限大とする）、設定２においてリトライ回数が１回でも発生したら保守管理者に清掃等のメンテナンスを行う旨通知し、２回以上発生したら交換時期が近付いていることを警告するとともにリトライ回数の頻度に応じて段階的に重み付けを大きくする、といった設定としてもよい。

また、上記では、設定係数ｙとして稼働情報の一種である総使用回数を適用し、重み付けを行っているが、これに代えて１日あたりの使用回数に１日あたりの稼働時間を掛けた値を設定係数ｙとするといった情報の組み合わせで規定することも可能である。また、例えば、上記した重み付けＷ_１，Ｗ_２，Ｗ_３のうち、重み付けＷ_１のみを利用するものとしてもよい。すなわち、ｆ＝ｙ×Ｗ_１とし、稼働情報である設定係数ｙに異常関連情報に関する重み付け設定を行うのみとするものであってもよい。また、保守管理対象の属性に応じて他の種類の情報について設定係数ｙとして対象項目を設けて重み付けを行うものとしてもよい。例えば保守管理対象がプリンター４０である場合において、印刷媒体であるロール紙の補充時期に関するメンテナンスを行うものとすると、ロール紙センサ部４０ａにおいて検知されたロール紙の残量（ロールの厚さ、予備のロール紙の本数）に関する情報を利用することが考えられる。すなわち、ｆ＝ｙ×Ｗ_１について、設定係数ｙを（初期のロール紙の厚み）／（ロール紙の残量厚み）とし、重み付けＷ_１を適宜行うものとしてもよい。また、重み付けによる換算値の算出（あるいは新たな設定係数の算出）についても、上記のような重み付けを掛け合わせる以外に種々の計算手法（足し合わせる、べき乗）で定義できる。また、事前精算装置ＰＳにおいてカードによる精算を受け付けるものとした場合に、上記した精算装置３１の場合と同様の保守管理を行うことができる。事前精算装置ＰＳに関するデータ送信について、上記の説明では、精算装置３１からのデータ送信とは別個独立に行うものとしているが、例えば事前精算装置ＰＳに関するデータまでも含んだデータ全てを精算装置３１に集約して一括して行う態様とすることも可能である。

また、緊急度や重要度についても、上記に限らず種々の態様が可能である。例えば上記において、ｆ≧ＴＨとなり部品の交換時期になったことが判定された場合にのみ緊急性・重要性有り、と判断し、それ以外すなわちｆ＜ＴＨであれば緊急性・重要性無し、と判断するものとしてもよい。あるいは、換算値ｆが閾値ＴＨにどの程度近づいたかによって緊急度や重要度を変更し通知の仕方を変える（例えば換算値ｆが閾値ＴＨの８０％以上になったら交換時期が近づいたことを知らせる）ものとしてもよい。また、例えば図６（Ａ）〜６（Ｃ）のテーブルデータにそれぞれ示す設定１のいずれか１つでも該当すれば直ちに緊急性・重要性ありと判断するものとしてもよい。また、重み付け設定とは無関係に別途緊急性・重要性の基準を定める、すなわち通報の仕方を定めるものとしてもよい。例えば、直近１か月でリトライ回数が１０回発生すると、清掃点検の必要があると判断し、その旨送信するものとしてもよい。

以下、図７〜９のフローチャート等を参照して、本実施形態に係る保守管理システム１００の判定部５３における重み付け設定に基づく予測判定（事前判断）のための一連の処理について一例を説明する。なお、この予測判定を行うタイミングについては種々のものとすることが可能であり、ここでは、判定部５３により必要な程度、随時行われているものとする。

まず、図７に示すように、保守管理システム１００での重み付け設定に基づく予測判定（事前判断）における主制御部である判定部５３は、登録部５２を介してデータベース部ＤＢにおいて異常関連情報について重み付けの設定に影響する情報が新規に送信されたか否かを判断する（ステップＳ１０１）。ステップＳ１０１において、新たな異常関連情報有り、と判断すると（ステップＳ１０１：Ｙｅｓ）、判定部５３は、当該異常関連情報を取得し（ステップＳ１０２）、取得した情報に基づく重み付け設定（第１重み付け判定）を行う（ステップＳ１０３）。具体的には、例えば図６（Ａ）に示したテーブルデータに基づく重み付けＷ_１の設定がなされ、次の処理をする（ステップＳ１０４）。一方、ステップＳ１０１において、新たな異常関連情報無し、と判断すると（ステップＳ１０１：Ｎｏ）、特段の処理を行うことなく（又は重み付けを１．０と判断し）、次の処理をする（ステップＳ１０４）。

次に、判定部５３は、登録部５２を介してデータベース部ＤＢにおいて環境情報について重み付けに影響する情報が新規に送信されたか否かを判断する（ステップＳ１０４）。ステップＳ１０４において、新たな環境情報有り、と判断すると（ステップＳ１０４：Ｙｅｓ）、判定部５３は、当該環境情報を取得し（ステップＳ１０５）、取得した情報に基づく重み付け設定（第２重み付け判定）を行う（ステップＳ１０６）。具体的には、例えば図６（Ｂ）に示したテーブルデータに基づく重み付けＷ_２の設定がなされ、次の処理をする（ステップＳ１０７）。一方、ステップＳ１０４において、新たな環境情報無し、と判断すると（ステップＳ１０４：Ｎｏ）、特段の処理を行うことなく（又は重み付けを１．０と判断し）、次の処理をする（ステップＳ１０７）。

次に、判定部５３は、登録部５２を介してデータベース部ＤＢにおいて稼働情報について重み付けに影響する情報が新規に送信されたか否かを判断する（ステップＳ１０７）。ステップＳ１０７において、新たな稼働情報有り、と判断すると（ステップＳ１０４：Ｙｅｓ）、判定部５３は、当該稼働情報を取得し（ステップＳ１０８）、取得した情報に基づく重み付け設定（第３重み付け判定）を行う（ステップＳ１０９）。具体的には、例えば図６（Ｃ）に示したテーブルデータに基づく重み付けＷ_３の設定がなされ、次の処理をする（ステップＳ１１０）。一方、ステップＳ１０７において、新たな稼働情報無し、と判断すると（ステップＳ１０７：Ｎｏ）、特段の処理を行うことなく（又は重み付けを１．０と判断し）、次の処理をする（ステップＳ１１０）。

続けて、図８に示すように、判定部５３は、登録部５２を介してデータベース部ＤＢにある情報に基づいて判断のための基準値である設定係数を取得する（ステップＳ１１０）。具体的には、例えば図６等を参照して上述した例のように、設定係数ｙとして磁気カード読取部６０の総使用回数の情報を取得する。次に、判定部５３は、ステップＳ１０１〜Ｓ１０９の過程において第１〜第３重み付け判定を行ったか否かを確認し（ステップＳ１１１）、ステップＳ１１１において重み付け判定有り、と判断すると（ステップＳ１１１：Ｙｅｓ）、判定部５３は、ステップＳ１１０で取得した設定係数に重み付けをして得た換算値を判断基準のための新たな設定係数とする（すなわち設定係数を変更する）処理を行う（ステップＳ１１２）。一方、ステップＳ１１１において、重み付け判定無し、と判断すると（ステップＳ１１２：Ｎｏ）、テップＳ１１０で取得した設定係数をそのまま維持する処理を行う（ステップＳ１１３）。ステップＳ１１２又はステップＳ１１３において設定係数（あるいは新たな設定係数に相当する換算値）が定まると、判定部５３は、当該設定係数と予め定めた閾値（閾値ＴＨ）とを比較し（ステップＳ１１４）、ステップＳ１１４における比較結果を取得する（ステップＳ１１５）。すなわち、判定部５３は、ステップＳ１１４の比較結果に基づいて事前判断（予測判定）を行い（ステップＳ１１５）、併せて、例えば図６（Ａ）〜６（Ｄ）に示したように、事前判断の結果について緊急度等を要するものであるか否かについての分類をする（ステップＳ１１６）。次に、ステップＳ１１５及びステップＳ１１６の結果に基づき、判定部５３は、通知部５４を介して保守管理者を携帯する管理者端末７００に対する通知処理を行う（ステップＳ１１７）とともに、事前判断の結果をデータベース部ＤＢに登録し（ステップＳ１１８）、処理を終了する。

なお、ステップＳ１１７の通知処理の内容については、図９に示すように、まず、事前判断の結果から通知について緊急性又は重要性があるかを判断する（ステップＳ１１７ａ）。具体的には、例えば、図６（Ａ）〜６（Ｄ）に示した倍のような判断基準に基づいて緊急性又は重要性について判断を行う。判断結果から、ステップＳ１１７ａにおいて緊急性又は重要性があると判断すれば（ステップＳ１１７ａ：Ｙｅｓ）、ステップＳ１１５の事前判断結果に該当する交換部材や工具の種類をデータベース部ＤＢから取得するといった通知に必要な情報取得を行って（ステップＳ１１７ｂ）、緊急態様の通知を行う（ステップＳ１１７ｃ）。一方、ステップＳ１１７ａにおいて緊急性又は重要性がないと判断すれば（ステップＳ１１７ａ：Ｎｏ）、ステップＳ１１５の事前判断結果に該当する交換部材（図６の例では、磁気カード読取部６０におけるカード読取機能部分）や工具の種類をデータベース部ＤＢから取得するといった通知に必要な情報取得を行って（ステップＳ１１７ｄ）、通常態様の通知を行う（ステップＳ１１７ｅ）。なお、ステップＳ１１７ｃの緊急態様の通知については、例えば、メール等で保守管理者や管理会社等に対して態様の駐車場と必要な交換部材や工具の種類を示し直ちに保守管理の人材を送るように連絡することが考えられる。一方、ステップＳ１１７ｅの通常態様の通知については、例えば、次にメンテナンスを行う時期やその際に必要となると考えられる交換部材や工具の種類を示すように連絡することが考えられる。

以上のように、本実施形態の保守管理システム１００では、保守管理対象である駐車場の管理等を行うための各部に関するデータに基づき保守管理の要否に関する予測判定を行って結果を通知することで、より的確な保守管理の運営を行うことができる。この際、特に、判定部５３において、取得したデータの属性に応じた重み付け設定に基づき予測判定を行うことで、例えば保守管理対象が、例えば通常設定されるメンテナンスの周期よりも短い周期で故障が発生したり、消耗品がなくなってしまったりするような場合であっても的確にメンテナンス時期を予測・判断し、管理者等に連絡することができる。

この発明は、上記の実施形態に限られるものではなく、その要旨を逸脱しない範囲において種々の態様で実施することが可能である。

まず、上記各実施形態では、一例として、判定部５３は、精算装置３１の磁気カード読取部６０の部品の交換時期について事前判断を行うものとしているが、これに限らず、種々の構成要素について事前判断を行うことが可能であり、例えばフラップ板やゲート装置、撮像装置といった同一構造を有しかつ互いに異なる位置に設置される複数の構成要素となり得るものについて、個々に区別することなくまとめてデータを取得することも考えられるが、これらについて個別にデータを取得するものとし、判定部５３は、これらの複数の構成要素について１つ１つ個別に予測判定を行うものとしてもよい。すなわち、例えば図１０に示すように、データベース部ＤＢにおけるフラップ板関連データ格納部ＦＰｄにおいて各フラップ板ＦＰ，ＦＰ…にそれぞれ対応して、第１フラップ板データ格納部ＦＰ１、第２フラップ板データ格納部ＦＰ２、第３フラップ板データ格納部ＦＰ３…を設けるものとし、各種データをそれぞれ取得するものとしてもよい。例えば各フラップ板ＦＰ，ＦＰ…の場合、設置される箇所（すなわち車室ＶＩの位置）によって利用頻度が著しく異なる場合があり得る。この場合、フラップ板ＦＰごとに摩耗度合等も異なってくると考えられ、同一構造・機能を有するものであっても個別に予測判定を行うことでより的確な判定が可能となる。これは、ゲート装置や、撮像装置等においても同様であり、例えば風の吹き方や日光の入り方等によって入り口側と出口側とで故障等の頻度や性質等が異なる場合が考えられる。一方で、例えば車室ごとの利用頻度にあまり差がないような駐車場では、フラップ板が異なる位置に設置されていても一括してデータを管理し、予測判定を行うものとすることもできる。

また、上記実施形態では、１つの保守管理サーバ５０で複数の駐車場すなわち複数の駐車場システム５００を管理するものとしているが、例えば図１１に示すように、保守管理システム２００において、１つの保守管理装置としての保守管理サーバ５０で１つの駐車場システム５００を管理するものとしてもよい。この場合、例えば現場端末ＴＥと保守管理サーバ５０とを直接的に有線で接続したり、近距離無線で通信を行うようにしたりするものとしてもよい。さらに、この場合、例えば保守管理サーバ５０に表示装置ＣＴを設けて表示装置ＣＴによる表示をもって保守管理者に通知を行う通知とするものとしてもよい。また、図１２に示すように、保守管理システム３００において、１つの駐車場システム５００の内部に保守管理サーバ５０まで設けるものとし、公衆回線ＩＮを通じて管理者端末７００に駐車場側から直接送信するものとしてもよい。

また、上記では、車両の入出庫を個別に管理するものとして、フラップ制御により個別ロックを行う態様を示したが、これは例示であり、車両の入出庫についての個別の管理が可能な種々の態様の個車管理装置が適用できる。例えば、フラップ板に代えて、車番カメラポールを用いロックレスとするタイプのものや車室の床がせり上がるタイプのものを適用してもよい。

また、上記では、車両として、特に四輪車を念頭において説明しているが、これに限らず、バイクや自転車等の二輪車のためのいわゆる駐輪場においても本件を適用することができる。さらには、車両に限らず、画像形成装置その他の種々の装置において、本願発明の保守管理システムを適用することも可能である。

また、上記では、精算装置３１が、駐車場システム５００の全体の動作制御を統括する主要部分として機能するものとし、駐車場Ｐａで取得される種々の情報を集約して現場端末ＴＥから保守管理サーバ５０に対して送信するものとしているが、駐車場システム５００の全体の動作制御のための機構が別途構成されるものとし、当該別の機構から保守管理サーバ５０に対して送信がなされるものとしてもよい。

また、上記では、各種データについてその特性に応じて３種類の情報（異常関連情報、稼働情報及び環境情報）に分類しているが、情報の分類の仕方については、これ以外に種々の態様とするものとしてもよい。

また、異常関連情報、稼働情報及び環境情報についても予測判定の対象に応じて種々のデータを取得の対象とすることができ、例えば環境情報については、上述した温度や粉塵量のほか、湿度や、風力、日射量、降雨量や積雪量等種々の値を取得対象とすることができる。例えば撮像装置であれば湿度や日射量等を利用することが考えられ、ゲートバーであれば風力、降雨量や積雪量等を利用することが考えられる。

また、上記各実施形態において、管理者端末７００について特に限定はしていないが、例えば保守管理者が携帯するスマートフォン等通知を受けられる種々の装置を適用できる。

さらに、上記のステップＳ１１８において、事前判断（予測判定）の結果をデータベース部ＤＢに登録しているが、この情報を蓄積し、実際の現場状況に沿うものであるか否かを検証するものとしてもよい。すなわち、事前判断（予測判定）によるメンテナンス時期の予測判断が現実に即した妥当なものとなっているか確認するものとしてもよい。仮に、予測判定が妥当でなかった場合には、例えば手動又は自動で閾値ＴＨの設定や重み付けＷ_１，Ｗ_２，Ｗ_３の設定を変更し（数値の変更）、より的確なものとなるようにしてもよい。自動で数値の変更を行う場合については、例えば判定部５３での事前判断（予測判定）によるメンテナンス報告よりも前に人間の判断によりメンテナンスがなされた場合（予測判定に基づく警告通知等が遅過ぎる）や、事前判断（予測判定）によるメンテナンス報告をしたにもかかわらず人間の判断によりメンテナンスがなされなかった場合（予測判定に基づく警告通知等が早過ぎる）に、人間の判断によりなされたメンテナンスの回数やタイミングのデータを蓄積し、当該データに基づき閾値ＴＨや重み付けＷ_１，Ｗ_２，Ｗ_３の数値変更をすることが考えられる。

Ａ１，Ａ２…矢印、 ＡＲ…異常関連情報格納部、 ＢＴ…呼出ボタン、 ＢＴａ…ボタンセンサ部、 Ｃ１，Ｃ２…規定値、 ＣＩｄ…現金投入口データ格納部、 ＣＴ…表示装置、 ＤＢ…データベース部、 ＤＭ…粉塵計、 ＥＮ…入場部、 ＥＶ…環境情報格納部、 ＥＸ…出場部、 ＦＰ…フラップ板、 ＦＰ１，ＦＰ２，ＦＰ３…フラップ板データ格納部、 ＦＰｄ…フラップ板関連データ格納部、 ＩＮ…公衆回線、 ＭＣｄ…磁気カード読取部データ格納部、 ＯＰ…稼働情報格納部、 ＰＩｄ…駐車券挿入口データ格納部、 ＰＲｄ…プリンターデータ格納部、 ＰＳ…事前精算装置、 ＰＳｄ…事前精算装置関連データ格納部、 Ｐａ，Ｐｂ，ＰＣ…駐車場、 ＲＷｄ…リーダライタ部データ格納部、 ＳＤｄ…精算装置関連データ格納部、 ＳＤｄ…精算装置関連精算装置関連データ格納部、 ＳＰ…スピーカー、 ＳＰａ…スピーカーセンサ部、 ＴＥ…現場端末、 ＴＨ…閾値、 ＴＯ…タッチパネル部、 ＴＯａ…タッチパネルセンサ部、 ＴＳ…温度センサ部、 ＴＳｄ…発券装置関連データ格納部、 ＶＩ…車室、 Ｗ１，Ｗ２，Ｗ３…重み付け、 ｆ…換算値、 ｙ…設定係数、 １０…現金投入口、 １０ａ…現金センサ部、 １１…発券機、 １１…発券装置、 １１…貨幣投入口、 １１…発券装置、 １１ａ…駐車券排出口、 １２…ゲート装置、 １２…紙幣投入口、 １２ａ…ゲートバー、 １３…第１読取装置、 ２０…リーダライタ部、 ２０ａ…電子マネーセンサ部、 ２３…貨幣受け口、 ３０…駐車券挿入口、 ３０ａ…駐車券センサ部、 ３１…精算装置、 ３２…ゲート装置、 ３２ａ…ゲートバー、 ３３…第２読取装置、 ４０…プリンター、 ４０ａ…ロール紙センサ部、 ５０…保守管理サーバ、 ５１…データ取得部、 ５２…登録部、 ５３…判定部、 ５４…通知部、 ６０…磁気カード読取部、 ６０ａ…磁気カードセンサ部、 ９０…制御部、 ９０ａ…主制御部、 ９０ｂ…データ記憶部、 １００，２００，３００…保守管理システム、 ５００…駐車場システム、 ７００…管理者端末

Claims (8)

1. 保守管理対象に関するデータを取得するデータ取得部と、
   前記データ取得部で取得されたデータの属性に応じた重み付け設定をし、当該重み付け設定に基づき保守管理の要否に関する予測判定を行う判定部と、
   前記予測判定の結果を通知する通知部と
   を備える保守管理システム。
2. 前記データ取得部は、前記保守管理対象としての駐車場の設備に関するデータを取得する、請求項１に記載の保守管理システム。
3. 前記データ取得部は、前記保守管理対象の異常に関する異常関連情報のほか、前記保守管理対象の通常動作に関わる稼働情報と前記保守管理対象が設置された場所の外部環境に関わる環境情報とのうち少なくとも一方を含む保守管理対象情報を、前記保守管理対象に関するデータとして取得する、請求項１及び２のいずれか一項に記載の保守管理システム。
4. 前記判定部は、前記データ取得部において取得されるデータのうち異種の情報を組み合わせた重み付けに基づき前記予測判定を行う、請求項３に記載の保守管理システム。
5. 前記判定部は、前記データ取得部により前記保守管理対象に関するデータを定期的に取得して蓄積された履歴情報に基づいて重み付け設定をする、請求項１から４までのいずれか一項に記載の保守管理システム。
6. 前記判定部は、重み付け設定で設定された重み付けの数値を前記保守管理対象に応じて設定される設定係数に乗算して得た数値と、予め設定された閾値とを比較して前記予測判定を行う、請求項１から５までのいずれか一項に記載の保守管理システム。
7. 前記データ取得部は、同一構造を有しかつ互いに異なる位置に設置されることにより前記保守管理対象を構成する複数の構成要素について個別にデータを取得し、
   前記判定部は、前記複数の構成要素について個別に前記予測判定を行う、請求項１から６までのいずれか一項に記載の保守管理システム。
8. 前記データ取得部に前記保守管理対象に関するデータを送信するデータ送信端末と、
   前記通知部から予測判定の結果の通知を受けるデータ受信端末と
   をさらに備える、請求項１から７までのいずれか一項に記載の保守管理システム。

Images