JP4258125B2 - Sewer management system and management device used in this system - Google Patents

Sewer management system and management device used in this system Download PDF

Info

Publication number
JP4258125B2
JP4258125B2 JP2001029152A JP2001029152A JP4258125B2 JP 4258125 B2 JP4258125 B2 JP 4258125B2 JP 2001029152 A JP2001029152 A JP 2001029152A JP 2001029152 A JP2001029152 A JP 2001029152A JP 4258125 B2 JP4258125 B2 JP 4258125B2
Authority
JP
Japan
Prior art keywords
report
data
notification
management
communication
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2001029152A
Other languages
Japanese (ja)
Other versions
JP2002230670A (en
Inventor
武史 芝
裕二 冨澤
智史 野田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Omron Corp
Original Assignee
Omron Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Omron Corp filed Critical Omron Corp
Priority to JP2001029152A priority Critical patent/JP4258125B2/en
Publication of JP2002230670A publication Critical patent/JP2002230670A/en
Application granted granted Critical
Publication of JP4258125B2 publication Critical patent/JP4258125B2/en
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Landscapes

  • Sewage (AREA)
  • Selective Calling Equipment (AREA)
  • Telephonic Communication Services (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Alarm Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Description

【０００１】
【発明の属する技術分野】
この発明は、下水処理などを遠隔で監視するためのシステムであって、特に、下水道内において下水を流すための機構を保守・管理するためのシステムに関連する。
【０００２】
【従来の技術】
この種の遠隔の監視システムとして、たとえば水道管，下水道の監視システムや、交通信号機の電球切れのための監視システムなど、さまざまなものがある。これらのシステムの多くは、異常発生時の通報または定期的な通報を行っている。代表例として下水道について説明すると、低い地点から高い地点に向けて下水を流す必要がある場合は、図１２に示すように、これらの地点間の複数位置にマンホール５１を設置して、その内部にポンプ５２を配備するようにしている。（このマンホール５１内に配備されたポンプ５２は「マンホールポンプ」と呼ばれている。）
隣接するマンホール５１、５１間には、上流側から下流側に向けて斜め下方に傾斜する配水管５３が設けられており、上流側からの下水は、マンホールポンプ５２により汲み上げられた後、配水管５３を介して下流側のマンホール５１に流される。複数の地点でこの処理を行うことにより、登り坂の斜面下においても下水をスムーズに流していくことが可能となる。
【０００３】
しかしながらマンホールポンプ５２が故障すると、マンホール５１内の水位が上がって下水が路上に溢れ、周囲環境が著しく悪化する虞がある。このため近年では、マンホール５１毎に監視装置を設けてマンホールポンプ５２の動作状態やマンホール５１内の水位を監視し、異常の発生が検知されると、監視装置から市町村役場，メンテナンス業者，マンホールポンプの製造業者などに通報を行うことで、異常の発生に速やかに対応するようにしている。
【０００４】
上記の監視装置は、マンホール５１の近傍に配備された制御ボックス内に、前処理用の回路や通信用のモデムなどとともに組み込まれる。監視装置は、モデムから公衆回線を介して電話，ファクシミリ，携帯電話，ページャー（携帯用の無線呼び出し機、いわゆるポケットベル）などの通信端末機器に接続されるように設定されている。これら接続先の通信端末機器は、役所や業者などにより電話番号，ファクシミリ番号などのアドレスを指定されることにより予め決められている。そしてマンホールポンプの動作状態や水位に異常が生じた場合は、監視装置から各通信端末機器に直接通信を行って、異常発生を知らせる音声情報や文字情報を送信する。
【０００５】
上記構成のシステムによれば、役所や業者の指定した複数の通報先に対し、それぞれその部署で使用される通信端末機器に応じた通報処理を行うことができる。しかも複数の通報先に自動的に通報処理を行うことができるので、役場や業者の担当者は、マンホール内で発生した異常の状態を速やかに認識して対応することができる。
【０００６】
【発明が解決しようとする課題】
しかしながら上記構成のシステムでは、はじめに異常発生の通報先を監視装置毎に設定する必要があるので、システム設定作業に多大な労力を要し、ひいては管理システムの構築作業が非効率であるという問題があった。さらに電話を対象としていた通報をファクシミリ対応の通報に変更したり、通報先を増やすなど、通報先の設定を変更するように指示される場合には、監視装置毎に通報先を再設定する必要が生じ、メンテナンスの担当者が監視装置の設置現場を巡回して煩雑な設定作業を行わなければならないため、システム設定の変更作業に多大な労力を要するという問題もあった。
【０００７】
この発明は上記問題点に着目してなされたもので、マンホールポンプなどの管理システムを構築する際のシステム設定にかかる労力を削減することを目的とし、また異常が発生したときに、関係者が異常発生後の経過を確認する処理を効率良く行えるようにすることを目的とする。
【０００８】
【課題を解決するための手段】
この発明にかかる下水道管理システムは、マンホールポンプの設置場所毎に配備され前記マンホールポンプの動作状態を監視する複数台の監視装置と、各監視装置と通信可能に設定された管理装置とから成る。
監視装置は、マンホールポンプの設置されるマンホールの近傍位置に配備されるもので、マンホールポンプの動作異常を検知したとき、その異常状態を通信により前記管理装置に報知する通報手段を具備する。
【０００９】
この監視装置では、マンホールポンプ内の回転子の回転を検出するセンサからの検知出力など、マンホールポンプの動作状態を示す外部信号を入力するとともに、この入力信号に基づき、たとえば所定期間毎のマンホールポンプの作動回数をチェックすることにより、マンホールポンプが正常に動作しているか否かを判断することができる。またマンホールポンプの動作そのものに限らず、水位検知センサによりマンホールポンプの水位が異常レベルに達していないかどうかをチェックすることにより、マンホールポンプの動作状態を判断することもできる。前記通報手段は、たとえば異常が生じたマンホールポンプを特定するデータ（ＩＤ番号など）を含む通報データを送信することによって、管理装置にマンホールポンプの「異常状態」を報知するように設定される。
なお、「異常状態」として、単に異常が発生した旨を報知するだけでも良いが、監視装置において、ポンプの動作停止，動作不良などの異常の詳細な内容を前記入力信号に基づいて判別できるのであれば、その内容を示すデータを異常状態として送信してもよい。
【００１０】
好ましい態様によれば、前記通報手段には、前記管理装置と通信を行うための通信手段と、マンホールポンプの動作異常が検知されたとき、その異常状態を示す通報データを作成した後、前記通信手段により管理装置に前記通報データを送信する処理を実行させる制御手段とが含まれる。通信手段は、たとえばモデムを作動させるためのインターフェース回路であり、また制御手段は、このインターフェース回路を介してＴＣＰ／ＩＰのような通信規約（プロトコル）に基づく形式の通報データをモデムに与え、管理装置に送信させる制御を行うプロセッサである。
なお、前記モデムは外付けに限らず、必要に応じて監視装置の装置本体内に組み込んでもよい。
【００１１】
さらに監視装置については、装置への電源供給状態も合わせて監視するとともに、停電状態などの異常が発生したときにも、その異常状態を示す通報データを送信するように構成するのが望ましい。
【００１２】
上記構成の監視装置から管理装置への通報処理は、たとえばパケット通信方式の無線通信網を介した情報伝送処理として実施される。
管理装置は、各マンホールポンプ毎にそのポンプの動作に異常が発生したときの通報先および通報動作に関する定義が格納された通報定義データベースと、異常が発生したマンホールポンプについて、メンテナンス処理の進行状態を示すステータス情報を格納するためのステータス管理データベースと、複数種の通信端末機器に対し、それぞれその通信端末機器に対応する通信規約による通信が可能に設定された通信手段と、所定の監視装置から前記異常状態を示す通報データを受信したとき、前記通報定義データベースの定義に基づき前記通報データに対応する通報先および通報動作を決定して、その決定された通報処理を前記通信手段に実行させる通報制御手段と、前記通報制御手段および通信手段により異常が通報されたマンホールポンプのメンテナンス処理について、前記通信手段が現場担当者の通信端末機器からの通報を受け付ける都度、その通報内容に基づくステータス情報を作成して前記ステータス管理データベースに保存するステータス管理手段と、前記通信手段が接続された通信端末機器から異常が発生したマンホールに関するステータス情報の閲覧要求を受け付けたとき、要求されたステータス情報を前記ステータス管理データベースから読み出し、読み出したステータス情報を前記通信手段を用いて閲覧要求を送信した通信端末機器に返送する閲覧要求応答手段とを具備する。なお、この管理装置は、複数台のコンピュータや周辺機器によるコンピュータネットワークとして構成するのが望ましい。
【００１３】
通報定義データベースには、たとえば異常発生時の通報先として、通報先の通信端末機器の種類（電話，ファクシミリ，パーソナルコンピュータなど）およびアドレス（電話番号，電子メールアドレスなど）が設定される。また通報動作としては、通報データのデータ形式（音声データ、テキストデータ、画像など）や送信に用いる通信規約（プロトコル）などのデータが、各通報端末機器の種類にリンクさせて設定されるほか、必要に応じて、各通報先毎に通報内容に含ませるデータの種類やこれらデータの配列順序（フォーマット）などが設定される。
なお通報定義データベースにおける通報先の設定は、マンホールポンプ毎に行われるが、いずれのポンプについても、複数種の通報先を設定できるようにするのが望ましい。さらに通報先については、時間帯，曜日などに応じて複数とおりの通報先を設定するようにしてもよい。
【００１４】
通信手段は、モデム，ルータなどの通信機器およびこれら機器とＣＰＵとの間に配備されるインターフェース回路により構成される。なお、この通信手段は、対象とする通信機器の種類や接続に使用される通信回線に応じて複数台の通信機器を含む構成とするのが望ましい。
通報制御手段は、この通信手段に通報先の通信端末機器のアドレスを与えて接続させた後、前記通信端末機器に応じた形式の通報データを与えてデータの送信を行わせる。
【００１５】
上記構成の下水道管理システムによれば、マンホールポンプに異常が発生すると、役場やメンテナンス業者などへの通報処理が管理装置により一括して行われるので、監視装置側には管理装置への通報を行うための設定を行うだけで良くなり、システムの導入時や通報先の変更時の設定を大幅に簡易化することができる。またこの種の設定にかかる労力を削減できるので、システムのコストを大幅に削減でき、かつ導入後のシステムを速やかに稼働させることができる。
さらに、管理装置において、異常が発生したマンホールについて、現場担当者の通信端末機器からの通報に基づき、メンテナンス処理の進行状態を示すステータス情報を作成してステータス管理データベースに保存するとともに、関係者の通信端末機器からのステータス情報の閲覧要求を受け付けて、当該通信端末機器に請求されたステータス情報を返送するので、関係者は、一括通報により異常の発生を把握した後に、必要に応じて管理装置にアクセスして閲覧要求を行うことによって、異常発生後のメンテナンス作業の進行状態を把握することができる。
【００１６】
上記下水道管理システムの好ましい態様では、監視装置は、所定時間毎にマンホールポンプの動作状態を示す定期通報データを作成して前記管理装置に送信する定期通報手段を、さらに具備する。また管理装置には、通報定義データベースに、各マンホールポンプ毎に通常報告のための通報先および通報動作に関する定義がさらに格納されるとともに、各監視装置から受信した定期通報データを蓄積する受信履歴データベースと、あらかじめ設定された時刻に、受信履歴データベースに蓄積された定期通報データを用いてマンホールポンプ毎に定期報告データを作成し、作成された各定期報告データを、それぞれ通報定義データベースの定義に基づき通常報告用の通報先に送信する定期通報手段とが、さらに設けられる。このようにすれば、各マンホールポンプの動作状態を定期的に関係者に報告する処理も容易に行うことができる。
【００２１】
他の好ましい態様では、通信手段は、インターネットのような通信ネットワークシステムを介して通信端末機器との通信を行う手段を含んでおり、前記ステータス通報データの受付およびステータス情報の閲覧要求ならびに請求されたステータス情報の返送を、前記通信ネットワークシステムを介した通信により実行する。この態様によれば、パーソナルコンピュータ，携帯電話など通信ネットワークシステムへの接続が可能な機器を用いて、ステータス通報データの送信やステータス情報の閲覧を行うことができる。
【００２３】
他の好ましい態様では、管理装置には、通報定義データベースの定義を設定または変更するためのデータ入力を受け付ける入力手段と、入力されたデータに基づき通報定義データベースの設定内容を更新する更新手段とを具備させることができる。
前記入力手段は、たとえばキーボードなど、管理装置に直接接続される入力装置として構成される。また前記した通信ネットワークを介して接続される通信端末機器を入力手段として機能させることもできる。（ただし、この種の外部機器は、パスワードなどによる認証システムにより許可された機器のみを対象とするのが望ましい。）
【００２４】
上記構成によれば、新たな通報先を設定したり、既存の通報先や通報動作を変更する場合も、管理装置にデータを入力することにより、簡単に設定や変更を行うことができる。特に、通信ネットワークを介してデータの入力を受け付けるようにすれば、役所や業者などの担当者により直接設定作業を行うことが可能となる。
【００２７】
【発明の実施の形態】
図１は、この発明の一実施例にかかる下水道管理システムの構成を示す。
この下水道管理システムは、複数の市町村の下水道を対象として、マンホ−ル内の水位やマンホールポンプの動作を２４時間体制で監視するとともに、各市町村の役場やマンホールポンプのメンテナンス業者などに監視結果を報知するためのもので、主要構成として、マンホール毎に設置された監視装置１と管理用サーバー２とを具備する。
【００２８】
各監視装置１は、詳細は後記するが、マンホールの設置現場（図中、Ｐ，Ｑ，Ｒで示す。）の近傍位置において、マンホールポンプの動作状態や水位を常時監視している。また各監視装置１には、パケット通信方式の無線通信網６に対応するプロトコルが設定されており、管理用サーバー２に定期的に現在の監視状態を通報する（以下、この通報データを「定期通報データ」という。）。さらに監視装置１は、マンホールポンプの動作や水位に異常が生じたことを検知すると、その異常の状態を示す通報データ（以下、「異常時通報データ」という。）を作成して前記管理用サーバー２に送信する。
【００２９】
管理用サーバー２（以下、単に「サーバー２」という。）は、１台のコンピュータにより構成してもよいが、ここでは、複数台のコンピュータ３（図１では２台のみ示す。）を組み合わせたコンピュータネットワークシステムの形態をとる。このサーバー２は、前記無線通信網対応のルータ４ａのほか、公衆回線用のルータ４ｂ、インターネット７への専用線に接続されたルータ４ｃによって、市町村役場やメンテナンス業者の指定する電話８ａ，ファクシミリ８ｂ，携帯電話８ｃ，ページャー８ｄ，パーソナルコンピュータ８ｅなど、種々の通信端末機器８と通信できるように設定されている。
【００３０】
前記サーバー２は、無線通信網対応のルータ４ａなどを介して各監視装置１からの通報データを逐次受け付けられるようになっており、受け付けた通報データをデータベース化する。さらにサーバー２は、これらの通報データを用いて日報、月報などの定期報告データを作成し、これを予め指定された通報先に送信する。またサーバー２は、所定の監視装置１から異常時通報データを受信すると、このデータ内容に応じた緊急通報データを作成して、予め定められた通報先に送信する。
【００３１】
なお、上記の緊急通報先の中に、以後、異常に対するメンテナンス作業の進行状態を報告する必要のある通報先があれば、サーバー２は、異常現場に派遣されたメンテナンス業者の作業員やメンテナンス業者の事業所などからの通報データを受け付けて、メンテナンス作業の進行状態を管理する。（以後、この管理を「ステータス管理」、作業員などからサーバー２への通報データを「ステータス通報データ」という。）
前記ステータス通報データは、インターネット７を介してなされるもので、たとえば、作業員自身が通報処理を行う場合、作業員が所有する文字情報サービス受信機能や電子メール送受信機能付きの携帯電話８ｃをインターネット７上のサーバー２のホームページにアクセスさせ、指示に応じたデータ入力を行って作業の進行状態をサーバー２側へ通報する。また事業所を経由してサーバー２側へ通報する場合は、作業員が事業所に電話や電子メールによる連絡を行った後、事業所にあるパーソナルコンピュータ８ｅをインターネット７に接続して、作業員からの通報内容に基づく情報送信を行う。
【００３２】
図２は、前記監視装置１の構成をマンホール（図中、符号９で示す。）との関係とともに示す。
マンホール９内には、通常、故障に備えて２台のマンホールポンプ１０ａ，１０ｂが設置されるほか、水位計測用のセンサヘッド１１が設置されている。なお、以下の説明では、各マンホールポンプ１０ａ，１０ｂを単に「ポンプ１０ａ，１０ｂ」と呼び、また各ポンプに個別に言及する場合は、「第１ポンプ１０ａ」，「第２ポンプ１０ｂ」ということにする。
【００３３】
監視装置１は、水位検出部１２，各ポンプ毎の作動検出部１３ａ，１３ｂ，通信用のモデム１４などとともに、制御盤１５上に搭載された状態で配備される。なお制御盤１５は、図示しない保護用のボックス内に収容されており、道路側方などマンホールの近傍位置に配備される。
【００３４】
前記センサヘッド１１は、圧力センサが組み込まれた投込式の機器であって、マンホール９内の水圧を示す信号を出力する。水位検出部１２は、この出力信号を水位を示すアナログ信号に変換し、これを監視装置１に出力する。
各ポンプ１０ａ，１０ｂには、ポンプ内の回転子の回転を検出するためのセンサ（図示せず）が取り付けられており、各ポンプ作動検出部１３ａ，１３ｂは、このセンサからの検出信号を用いてポンプ１０ａ，１０ｂの作動を検出する。この検出結果は、ポンプが作動している間にＨレベルとなるディジタル信号として出力され、監視装置１に与えられる。
【００３５】
監視装置１は、ＣＰＵ１５にメモリ１６および時計１７が接続された制御部１８を具備するほか、水位信号入力部１９，作動信号入力部２０，電源回路２１，バッテリー２２，切替回路２３，通信インターフェース２４などが組み込まれた構成をとる。
【００３６】
水位信号入力部１９は、前記水位検出部１２からのアナログ信号をディジタル変換するためのＡ／Ｄ変換回路や検出された水位を所定のしきい値と比較するための比較回路などを含むもので、これらの回路により水位を示すディジタル信号および水位異常時にＨレベルとなる異常信号を生成して、ＣＰＵ１５に出力する。一方、作動信号入力部２０は、各ポンプ作動検出部１３ａ，１３ｂからのディジタル出力信号をＣＰＵ１５に中継するためのものである。
【００３７】
電源回路２１は、外部電源からの電流を監視装置１内の各部に供給する。またこの電源回路２１からＣＰＵ１５には、常時Ｈレベルとなる信号が出力されており、ＣＰＵ１５は、この信号を用いて停電状態の検知を行っている。（以下、この電源回路２１からの信号を「停電検知信号」という。）
なお、停電時には、前記切替回路２３により、ＣＰＵ１５への電源供給がバッテリー側に切り替えられるので、ＣＰＵ１５は、停電時においても、所定期間の間は、異常の発生を判別したり、異常時通報データを送信する処理を、支障なく実行することができる。
【００３８】
前記メモリ１６には、フラッシュメモリなどの不揮発性メモリが用いられる。このメモリ１６には、ＣＰＵ１５に各種処理を行わせるためのプログラムや無線通信のためのプロトコルなどが記憶されるほか、入力信号の履歴や通報処理の履歴を示すデータベース（それぞれ「信号履歴データベース」「通報履歴データベース」という。）が設定される。
【００３９】
なお、信号履歴データベース内の履歴を任意の時間毎にまとめたものが定期通報データとなる。任意の時間は時計１７により計時される。
また定期通報データとして送信されたデータは、信号履歴データベースから自動的に消去してもよいが、これに限らず、データベースが満杯になるまで残しておいてもよい。
【００４０】
ＣＰＵ１５には、メモリ１６内に設定されたプログラムに基づき、主制御部２５，信号判別部２６，通信制御部２７などの処理部が設定される。信号判別部２６は、前記水位信号入力部１９や作動信号入力部からの信号、ならびに前記停電検知信号を入力して、水位，各ポンプ１０ａ，１０ｂの稼働状態を判別するとともに、水位やポンプ１０ａ，１０ｂに異常が生じたり、停電状態となったときに、その異常を検知する。
【００４１】
主制御部２５は、各入力部１９，２０からの信号を信号判別部２６を介して逐次取り込んでメモリ１６内の信号履歴データベースに蓄積するとともに、信号判別部２６の判別処理結果に基づき定期通報や異常時通報を行うタイミングを判別して通信制御部２７を作動させる。通信制御部２７は、主制御部２５の指示に基づき、前記サーバー２宛に定期通報データまたは異常時通報データを作成した後、この通報データを通信インターフェース２４を介してモデム１４に与え、前記サーバー２に向けて送信させる。なお、送信された通報データは、メモリ１６内の通報履歴データベースに記憶される。
【００４２】
図３は、前記サーバー２の構成を機能ブロック図の形で示す。
前記したようにサーバー２は、複数のコンピュータやルーターによるネットワークシステムであり、各コンピュータにプログラムを組み込むことにより、通報動作制御部３０，通報データ受付部３１，通報データ認識処理部３２，緊急通報処理部３３，定期報告処理部３４，ステータス管理部３５，報告データ作成部３６，Ｗｅｂページ管理部３７などの処理部が設定される。またハードディスク装置などのメモリや、このメモリを管理するコンピュータによって、受信履歴データベース３８，通報定義データベース３９，緊急通報テンプレート４０，日報・月報テンプレート４１，通報履歴データベース４２，ステータス管理データベース４３，Ｗｅｂページデータベース４４などのデータベースが設定される。
【００４３】
各種データベースのうち、受信履歴データベース３８は、各監視装置１からの通報データを装置毎に時系列に記憶するためのものである。通報履歴データベース４２は、サーバー２から他の通信端末機器８に送信した緊急通報や定期報告を蓄積するためのデータベースであり、日報・月報テンプレート４１や緊急通報テンプレート４０には、各種通信端末機器８に送る定期報告データや緊急通報データの雛形ファイルが格納される。
【００４４】
通報定義データベース３９には、詳細は後記するが、各監視装置１に対応する現場毎に、通報先や通報の方法、定期報告データの様式、ステータス管理が必要か否かなどについての定義が格納される。またステータス管理データベース４３には、発生した異常毎に前記ステータス通報データに基づく管理情報（以下、「ステータス情報」という。）が格納される。さらにＷｅｂページデータベース４４には、前記インターネット７上に各種のＷｅｂページを提示するための画像情報やプログラムなどが格納される。
【００４５】
通報動作制御部３０は、緊急通報処理部３３や定期報告処理部３４により作成された各種通報データにつき、それぞれその通報先の通信端末機器８に応じた通信経路およびプロトコルを選択して送信するためのものである。
通報データ受付部３１は、各監視装置１からの通報データをシステム内に取り込むためのもので、取り込まれた通報データは通報データ認識処理部３２に与えられる。
【００４６】
通報データ認識処理部３２は、通報データの通報元のほか、データ種別や具体的な通報内容などを認識した後、この認識結果を現在時刻などに対応づけた受信履歴データを作成し、これを前記受信履歴データベース３８に格納する。
また前記通報データが異常時通報データである場合には、通報データ認識処理部３２は、その通報元や通報内容に関する情報を緊急通報処理部３３に渡す。緊急通報処理部３３は、前記通報定義データベース３９や緊急通報テンプレート４０を参照しつつ、与えられたデータに対応する緊急通報データを作成して、これを通報動作制御部３０に与え、各通報先に送信させる。
【００４７】
ステータス管理部３５は、上記の緊急通報処理により通報された異常状態を新たな管理対象としてステータス管理データベース４３に登録する。そして以後、この管理対象について、Ｗｅｂページ管理部３７を介してステータス通報データを取り込み、その通報データからメンテナンス状態を示すステータス情報を切り出して、ステータス管理データベース４３に格納する。
【００４８】
定期報告処理部３４は、あらかじめ設定された時刻になると、受信履歴データベース３８から各現場毎の受信履歴を読み出すとともに、通報定義データベース３９より定期報告データの通報先、データの形式などを読み出す。さらに定期報告処理部３４は、日報・月報テンプレート４１より通報定義データベースに設定された形式に応じた雛形ファイルを読み出した後、この雛型に前記受信履歴をあてはめて定期報告データを作成する。作成された定期報告データは、緊急通報データと同様に通報動作制御部３０に与えられて、前記通報先に送信される。
なお、通報定義データベース３９において、この定期報告にステータス情報を含むように設定されている場合は、定期報告処理部４０は、ステータス管理データベースデータ４３より必要なステータス情報を読み出して報告用データの作成に使用する。
【００４９】
Ｗｅｂページ管理部３７は、インターネット接続された通信端末機器８ｃ，８ｅに対し、Ｗｅｂページデータベース４４内のデータやプログラムに基づき所定のメニューページを送信するとともに、このメニューページを介してのデータ入力やデータ提示要求を受け付ける。
特に、前記ステータス通報データを受け付けたとき、Ｗｅｂページ管理部３７は、このステータス通報データをステータス管理部３５に渡し、前記したステータス管理データベース４３へのステータス情報の格納処理を要請する。
【００５０】
またメニューページ上で異常の発生している現場についての情報の閲覧要求を受けると、Ｗｅｂページ管理部３７は、この閲覧要求を報告データ作成部３６に渡す。報告データ作成部３６は、受信履歴データベース３８やステータス管理データベース４３より閲覧要求に対応するデータを読み出して所定形式の報告データを作成する。さらに作成された報告データは、Ｗｅｂページ管理部３７によってＷｅｂページ形式に編集され、閲覧要求を出した通信端末機器８ｃ，８ｅに送信される。
【００５１】
図４は、前記通報定義データベース３９の構成例を示す。
この通報定義データベースは、マンホール９の設置場所毎または監視装置１毎に緊急通報時の通報先と定期報告時の通報先とを設定したもので、通報定義テーブル３９Ａ，通報先テーブル３９Ｂ，ならびに図示しない通報動作の定義を示すテーブルなどをリンクさせたリレーショナルデータベースとして設定されている。
【００５２】
通報定義テーブル３９Ａには、マンホール９毎に、そのマンホール９の設置されている現場名，通報元ＩＤ，ならびに複数の通報先ＩＤを対応づけたデータが記憶されている。
通報元ＩＤは、マンホールを識別する情報で、具体的には、監視装置１の識別ＩＤである。この通報元ＩＤは、前記監視装置１が通報データをサーバー２に送信する際に、通報元の識別のために通報データに含められるコードであって、マンホール９を管理する市町村のＩＤ番号とマンホールのＩＤ番号とをハイフンで繋いだ構成をとる。
【００５３】
一方、通報先ＩＤは、通報先となる個々の通信端末機器８毎に設定されるもので、通信端末機器８の所有者（市町村，業者など）のＩＤ番号と通信端末機器のＩＤ番号とをハイフンで繋いだ構成をとる。
図示例の通報定義テーブル３９Ａには、緊急通報処理について、異常発生現場および発生した異常の種類の組合せ毎にそれぞれ役場や業者により指定された通報先を示す通報先ＩＤが設定されている。また定期報告処理については、日報の送信先、月報の通報先の通報先ＩＤがそれぞれ個別に設定されている。なお、通報先は、現場、異常の種類、定期報告の種別などに応じてそれぞれ任意の数だけ設定することができる。
【００５４】
通報先テーブル３９Ｂは、各通報先ＩＤの示す具体的な内容を記憶したテーブルであり、ＩＤ毎に、通報先の通信端末機器８の種類，アドレス（電話番号，電子メールアドレスなど）が格納される。さらに定期報告先として指定されている通報先のＩＤについては、前記ステータス管理の有無、日報，月報の様式なども設定される。なお、日報，月報のフォーマットについては、複数種類を設定する場合、単一種類のみ設定する場合のいずれであってもかまわない。
【００５５】
さらに通報先テーブル３９Ｂには、通報先アドレスへの通信エラーが発生したときの第２通報先としての通報先第２アドレスも格納される。また通常勤務時間や仕事日，休業日などを考慮した通報ができるように、通報可能な時間帯や日にちを示す時間定義やカレンダ定義も含まれている。
また通報先によっては、時間、カレンダで非定義の場合の定義外通報先が設定される。この定義外通報先は、予備の第３の通報先として使用することができる。
【００５６】
なお図示のように、同じ現場に設置されるポンプに同一の通報先を割り当てたり、近接する複数の現場に同一の通報先を割り当てたい場合には、通報定義テーブル３９Ａに共通のＩＤを設定すれば良いので、データ数を削減することができ、通報先が一部変更される場合にも、迅速に対応することができる。
【００５７】
前記サーバー２は、通報処理を行う際には、まず通報定義テーブル３９Ａを参照して通報先ＩＤを特定した後、この通報先ＩＤにより通報先テーブル３９Ｂを参照して具体的な通報先の端末機器やアドレスを特定する。そしてサーバー２は、前記特定された通報先の通信端末機器８について前記通報動作の定義を示すテーブルを参照して、通報データのデータ種別やプロトコルなどを特定した後、その定義に応じた通報データを作成して送信する処理を行う。
【００５８】
前記通報定義テーブル３９Ａや通報先テーブル３９Ｂに設定する内容は、各役場や業者の要望に応じて設定でき、また適宜変更することができる。このデータの設定や変更は、サーバー２側の管理者によるデータ入力によって行うことができるほか、役場や業者内の特定のユーザーにアクセス権限を与えて、これらユーザーの使用するパーソナルコンピュータ８ｅからインターネット７を介してのデータ入力を受け付けることも可能である。
【００５９】
このように現場の状況や管轄部門の規模、メンテナンス業者の変更などに応じて通報先の場所，数，通信端末機器８の種類など、通報定義データベース３９の定義内容を自由に設定または変更することができる。従来のシステムでは、各現場の監視装置毎に通報先の設定を行っていたので、設定作業や変更作業に多大な労力がかかっていたが、この実施例のシステムでは、上記のようにサーバー側で設定や変更を一括に行うことによって、作業に要する労力やコストを大幅に削減することができる。
【００６０】
また従来のシステムでは、監視装置側で種々の通信端末機器への通報処理に対応する必要上、監視装置側に通信端末機器の種類毎にプロトコルや通報データの雛形を設定していたが、この設定のために監視装置に大きなメモリ資源を組み込む必要が生じ、コスト高を招いていた。しかも監視装置の稼働時には、前記プロトコルや通報データの雛形から必要なものを選択して使用することになるので、必ずしも設定されたすべてのプロトコルや雛形が使用されるとは限らず、メモリ資源が無駄になる場合があった。
これに対し、この実施例のシステムでは、各監視装置には、サーバー２を対象としたプロトコルや通信データを設定するだけで良いので、通信環境設定のために余分なメモリを組み込む必要がなくなり、前記信号履歴データベースや通報履歴データベースのためにメモリ資源を有効に使用することができる。
【００６１】
さらにこの実施例のシステムでは、各監視装置１において信号をモニタリングする間隔や定期通報の時間間隔などの動作環境についても、サーバー２側からの指令に応じて設定することができる。（設定内容は、サーバー管理者により入力されたデータに基づく。）また信号履歴データベースや通信履歴データベース内の蓄積データを、サーバー２からの指令によって適宜消去することも可能であるなど、各監視装置１に対する各種設定や管理を、サーバー２側で一括して行うことができる。
【００６２】
以下、監視装置１およびサーバー２における通報処理の手順について順を追って説明する。
図５は、監視装置１における監視ならびに通報処理の手順を示す。なお、図中、各ステップは、「ｓｔ○○」と示す。
【００６３】
監視装置１のＣＰＵ１５は、所定時間（たとえば１分）単位で、前記作動信号入力部２０から各ポンプ１０ａ，１０ｂ毎の作動検出信号を、水位信号入力部１９から水位データおよび異常信号を、電源回路２１から停電検知信号を、それぞれモニタリングしつつ前記メモリ１６内の信号履歴データベースに蓄積し、さらにモニタリングされた各信号を前回のモニタリング結果と比較している。図中のｓｔ１はこの信号を入力して蓄積する処理を、ｓｔ２は信号を比較する処理を、それぞれ示す。
【００６４】
ｓｔ２において信号の状態に変化が認められた場合、ｓｔ３〜１７の処理により異常時通報データを作成し、これをサーバー２に送信する。
この実施例では、異常の種類に合わせて４種類の異常フラグを設定することで異常状態を管理するようにしている。まずｓｔ３では、第１ポンプ１０Ａについての最新の作動検出信号のモニタリング結果からポンプの作動回数を抽出し、これを所定のしきい値と比較する。ここで第１ポンプ１０ａが作動しなくなったり、作動回数がきわめて少なくなるなどの異常が発生していると、作動回数はしきい値を下回るから、この場合は「異常あり」と判定してｓｔ４に進み、前記第１ポンプ１０ａ用の異常フラグをオン設定する。反対に最新の作動回数がしきい値以上であれば、「異常なし」と判断してｓｔ５に進み、前記第１ポンプ１０ａ用の異常フラグをオフ設定する。
【００６５】
つぎのｓｔ６〜８では、第２ポンプ１０ｂについて上記と同様の判別処理を行って、第２ポンプ１０ｂ用の異常フラグをオンまたはオフに設定する。
つぎにｓｔ９では、水位異常信号をチェックする。この水位異常信号は、前記したように、しきい値を越えるとＨレベルになるが、この場合はｓｔ９からｓｔ１０に進んで水位異常フラグをオンに設定する。反対に、水位異常信号がＬレベルであれば、ｓｔ９からｓｔ１１に進み、前記水位異常フラグをオフに設定する。
さらにｓｔ１２〜１４では停電検知信号をチェックし、停電と判別したときは停電フラグをオンに、停電ではないと判別した場合は停電フラグをオフに、それぞれ設定する。
【００６６】
このようにして各異常フラグの設定が完了すると、つぎのｓｔ１５では、異常時通報データを作成する。なお、この実施例では、異常時通報データとして、データ種別を示す識別符号の後に前記４種類の異常フラグを順に並べ、さらに前記通報元ＩＤや現在時刻を付加した構成のデータを作成するものとする。
続くｓｔ１６では、作成した通報データをメモリ１６内の通報履歴データベースに保存し、さらにｓｔ１７で前記通報データをサーバー２に向けて送信する。送信が終了すると、ｓｔ１に戻って、再び信号をモニタリングする。
【００６７】
一方、ｓｔ２において信号状態に変化が認められない場合は、ｓｔ１，２の処理を繰り返すことにより、一定時間（たとえば１０分）が経過するまでモニタリングを繰り返しつつ待機する。この状態下で一定時間が経過すると、ｓｔ１８が「ＹＥＳ」となってｓｔ１９に進み、定期通報データを作成する。
【００６８】
この実施例では、定期通報データとして、データ種別を示す識別符号の後に、前記信号履歴データベース内の未送信のデータを時系列に並べ、さらに前記通報元ＩＤや現在時刻を付加した構成のデータを作成するものとする。このデータ作成後は、ｓｔ１６、１７の処理を行うことにより、前記定期通報データを通報履歴データベースに保存した上で、これをサーバー２に向けて送信する。データ送信後はｓｔ１に戻り、以下も信号状態に変化がなければ、信号履歴を蓄積しつつ、所定の期間毎に定期報告データを作成してサーバー２に送信する。
【００６９】
上記の処理の流れによれば、最初に異常が発生したときのみならず、新たな異常が発生したり、異常状態が解除されるなど、信号状態に変化がある都度、異常時通報データを作成してサーバー２に送信するので、異常状態の詳細な変化を迅速に通報することができる。また異常状態時の信号も逐次保存されて、後で定期通報データに含めてサーバー２に送信されるので、サーバー２において、たとえばポンプの異常がポンプの停止、作動不良のいずれを意味するのか、水位の異常がどの程度の異常レベルを示すのかなど、詳細な異常状態を分析することができる。
【００７０】
つぎにサーバー２側における主要な処理について説明する。なお、以下の説明では、前記監視装置１との手順と区別するために、各ステップを「ＳＴ○○」として示す。
図６は、監視装置１からの通報データを受け付ける処理の流れを示す。同図において、所定の監視装置１からの通報データが届くまでＳＴ１，２のループを繰り返すことで着信に待機する。所定の時点で着信を確認すると、ＳＴ３に進み、通報データを受信してその内容を解析し、さらにつぎのＳＴ４で前記受信データを受信履歴データベース３８に保存する。
なお、ＳＴ３における解析処理には、通報データの種類を認識する処理と、通報内容を個々のデータ毎に切り分けて認識する処理とが含まれる。たとえば受信したデータが異常時通報データであれば、前記先頭の識別符号からデータ種別を認識した後、前記通報元ＩＤ，各種異常フラグ，現在時刻などのデータを個別に切り分けることになる。
【００７１】
さらに通報データが異常時通報データである場合は、ＳＴ５からＳＴ６に進んで緊急通報処理を行う。
図７は、前記ＳＴ６の緊急通報処理の詳細な手順を示す。（この図における各ステップは、「ＳＴ６−××」と示す。）
【００７２】
まずＳＴ６−１では、前記通報定義データベース３９を参照して、前記異常時通報データの通報元ＩＤや異常フラグの内容に対応する通報先を特定する。つぎにＳＴ６−２では、最初の通報先について、前記通報先の通信端末機器に応じたデータ種別ならびにプロトコルを決定する。さらにつぎのＳＴ６−３では、前記緊急通報テンプレート４０より前記異常フラグの内容とＳＴ６−２で決定されたデータ種別とに対応するテンプレートを読み出して緊急通報データを作成し、これを決められたプロトコルによって送信する。
【００７３】
他の通報先についても同様に、ＳＴ６−２，６−３の処理を実行することにより、順次緊急通報処理を実行する。
なお、フローチャートには表していないが、この実施例では、通報先への通信エラーが発生すると、何度か再送処理を行い、なお通信エラーとなったときは、予備の第２通報先への通報を行うようにしている。さらに第２通報先に対しても通信エラーが生じた場合は、通信先を定義外通報先に切り替えたり、再度、第１通報先や第２通報先への通信を試みるようにしている。
【００７４】
すべての通報先についての通報処理が終了すると、ＳＴ６−４が「ＹＥＳ」となってＳＴ６−５に進む。このＳＴ６−５では、前記通報先の中にステータス管理を行うように定義づけられた通報先があるか否かをチェックする。ここでステータス管理を行うように設定された通報先があれば、ＳＴ６−５が「ＹＥＳ」となってＳＴ６−６に進む。このＳＴ６−６では、ステータス管理の対象として、前記緊急通報の対象となった異常発生現場の通報元ＩＤ，異常の種類，ステータス管理が定義づけられた通報先のＩＤなどを設定し、これら管理対象をステータス管理データベース４３に新規登録する。なお、この新規登録時に、管理通番やＷｅｂ上での参照ページのＵＲＬが設定され、ステータス管理データベース４３内にともに登録される。
【００７５】
図８は、通信端末機器８側に届いた緊急通報データの出力例として、ファクシミリまたは電子メールによって送信された通報データの印字出力を示す。なお、図中の(1)〜(9)の数字は実際のレポートに出力されるものではなく、以下の説明のための参照番号である。
図中、(1)は、前記通報先テーブル３９Ｂの宛先欄に設定された宛先である。また(2)は、異常時通報データの通信元ＩＤにより通報定義テーブル３９Ａを参照して割り出した現場名であり、(3)は異常時通報データ内に組み込まれていた現在時刻を異常発生時刻として置き換えたものである。(4)は、前記異常時通報データの異常フラグのうち、オン設定された異常フラグに対応する異常名である。さらに(5)は、異常時通報データの受信前後の定期通報データより割り出された異常状態の詳細な内容を表すもので、必要に応じて緊急通報に組み入れられる。
【００７６】
つぎの(6)は、発生した異常に対応するメンテナンスの内容であるが、これについてはあらかじめテンプレートに設定されたデータをそのまま使用してもよい。(7)は、同様の緊急通報の送信対象となる他の通報先であって、前記通報定義テーブルに設定された通報先ＩＤを通報先テーブルに基づき具体的な内容に置き換えたデータが示されている。さらに(8)(9)は、前記ステータス管理データベース３５への登録処理に伴い設定されたＷｅｂ参照ページ（ステータス情報を閲覧するためのページ）のＵＲＬ，管理通番である。
【００７７】
このような緊急通報データによれば、関係者は、異常発生後、速やかにかつ正確に異常発生現場や異常の状態を知ることができる。また (8)(9)の情報により、発生した異常に対するメンテナンスの進行状態をＷｅｂブラウザを利用して自由に閲覧することができ、異常状態に効率良く対応することができる。
なお電話を対象とする音声データによる緊急通報データも、同様に、異常発生現場、異常発生時刻、異常内容などのデータを音声データのテンプレートにあてはめて作成される。ただし音声による緊急通報データは、一度きりの出力では内容を把握しきれない場合があるので、相手方の通信端末機器が回線を切断するまで繰り返し送信を行うように定義づけるのが望ましい。
【００７８】
図９は、定期報告処理の詳細な手順（ＳＴ１１〜１６）を示す。
まず定期報告の時刻になると、ＳＴ１１が「ＹＥＳ」となってＳＴ１２に進み、各現場毎に、前記通報定義データベース３９から通報先の通信端末機器８の種別，アドレス，および使用するプロトコルを特定するとともに、前記通報先テーブル３９Ｂに設定された日報または月報のフォーマットから定期報告データに使用するテンプレートを特定する。
【００７９】
つぎのＳＴ１３では、第１番目の現場について、前記日報・月報テンプレート４１より前記特定された様式のテンプレートを読み出す。つぎにＳＴ１４では、着目中の現場について、受信履歴データベース３８，通報履歴データベース４２，ステータス管理データベース４３などから定期報告データの作成に必要なデータを読み出す。ついでＳＴ１５では、読み出したデータにより各種集計処理や他の参照テーブルによるデータの置き換え処理などを行いつつ、テンプレートに応じた定期報告データを作成し、前記決められたプロトコルを用いて送信する。
【００８０】
以下、同様にして各現場毎にＳＴ１３〜１５の処理によって定期報告用データを作成し、送信する。なお、一つの現場につき、複数の通報先がある場合は、通報先毎にＳＴ１３〜１５の処理を行うことになる。
こうしてすべての通報先への定期報告データの送信が終了すると、ＳＴ１６が「ＹＥＳ」となってＳＴ１１に戻り、つぎの定期報告時刻がくるまで待機する。
【００８１】
図１０は、月報形式の定期報告データの一例を示す。なお、図中の×や○は、任意の数字を意味する。
この例も、前記図８と同様に、ファクシミリ装置または電子メールで送信されたデータを印字出力したものである。図中、参照番号(11)で示す部分は、前記受信履歴データベース３８に保存されていた各ポンプ１０ａ，１０ｂの作動状態を示す履歴データを集計して得られたもので、各ポンプ１０ａ，１０ｂ毎の運転時間，運転回数，および２台のポンプ１０ａ，１０ｂによる積算流量を日毎に集計した結果と、これらデータの月平均、最大値、最小値、合計値などが示されている。
【００８２】
(12)は、受信履歴データベース３８ならびに通報履歴データベース４２の各履歴データに基づき、異常が発生した日の異常内容の詳細を示している。さらに(13)では、ステータス管理データベース４３に基づき、緊急通報を行った通報先やメンテナンスの完了の有無を示すステータス情報、復旧時刻などを示している。
【００８３】
図１１は、インターネット７を介して携帯電話８ｃ，パーソナルコンピュータ８ｅなどの通信端末機器８に対する送受信を行う場合の手順（ＳＴ２１〜３５）を示す。なお、通信端末機器８との信号のやりとりについての手順は、一般的なインターネット対応のサーバー２と同様であるので、ここでは特に、ステータス通報データを受信した場合とステータス情報の閲覧要求を受けた場合とに限定して、詳細な処理を説明する。
【００８４】
まずＳＴ２１，２２では、前記インターネット用のルータ４ｃにおける着信処理に待機している。
通信端末機器８において、インターネットに接続した後に、サーバー２のホームページのＵＲＬを送信する処理が行われると、ＳＴ２２が「ＹＥＳ」となり、ＳＴ２３に進む。
【００８５】
ＳＴ２３では、前記通信端末機器８に対し、メニューページを送信する。通信端末機器８側のユーザーは、このメニューページ上で所望のメニューを選択する。ここで前記ステータス通報データの送信が指定されると、ＳＴ２４からＳＴ２７に進み、ステータス情報入力用のページを送信する。つぎにユーザーがこのページ上で、管理対象の現場名や異常状態などとともに所定のステータス情報を入力すると、ＳＴ２８が「ＹＥＳ」となる。この判定を受けてサーバー２は、ＳＴ２９において入力されたステータス情報が前記ステータス管理データベース４３に管理対象として登録されている案件に対応することを確認した上で、ＳＴ３０でこの情報を現在時刻に対応づけてステータス管理データベース４３内に格納する。
【００８６】
一方、メニューページ上で選択された情報が、所定の現場の異常状態についてのステータス情報の参照を要求するものであれば、ＳＴ２５が「ＹＥＳ」となってＳＴ３１に進む。このＳＴ３１では、参照要求された案件がステータス管理データベース４３に登録されているか否かをチェックする。登録されている場合は、ＳＴ３１からＳＴ３２に進んで、前記ステータス管理データベース４３および受信履歴データベース３８より必要なデータを読み出して、異常内容やステータス情報を示す報告ページを作成し、これを通信端末機器８側に送信する。
なお、ＳＴ２９，ＳＴ３１において、入力や参照を要求された案件がステータス管理データベース４３に登録されていない場合は、ＳＴ３３に進んで、エラーメッセージの表示ページを送信する。
【００８７】
このような処理の後、ユーザーが戻り操作を行うと、ＳＴ３４からＳＴ２３に戻って、再びメニューページを送信する。またユーザーが接続を切るか、他のページに移動する操作を行うと、ＳＴ３５が「ＹＥＳ」となって着信処理を終了し、ＳＴ２１に戻ってつぎの着信に待機する。
【００８８】
なお、メニューページにおいて、上記２つの処理以外のメニューが選択された場合は、ＳＴ２６からＳＴ３６に進み、そのメニューに応じた処理を実行する。たとえば、所定の現場について、前日の報告データの提示が要求されると、前記定期報告処理と同様に、各種データベースを参照して所定の様式に基づく報告データのページを作成し、これを通信端末機器８側に送信することになる。
【００８９】
このようなインターネットを介した情報送信によれば、役所や業者側では、必要に応じて所望の情報を取り込むことができるので、異常発生時にその異常に対するメンテナンスの進行状態をこまめにチェックすることができ、復旧処理を効率よく管理することができる。
【００９０】
なお上記実施例では、マンホール毎に緊急通報や定期通報を行う例を示したが、この下水道管理システムでは、さらに必要に応じて、１または近接する複数の市町村について、各マンホール内のポンプや水位の状態を一覧表示したり、異常の発生したマンホールの位置を示す地図を作成し、通報処理を行うこともできる。したがって、たとえば大雨時のように異常の発生する可能性が高い状態下での管理を充実させることができ、システムの利便性は大幅に向上する。
またこの下水道管理システムでは、各役所の管轄を越えて必要な情報を取り込んだり、複数の管轄下にある下水道網の情報をまとめて取り込むことができるので、たとえば上流の市町村で発生した水位異常を下流の市町村でいち早く認識して対応策をとるなど、管轄の枠を越えたシステム運用を実現できる。
【００９１】
【発明の効果】
上記したようにこの発明では、マンホールポンプに異常が生じたときは、その異常を検知した監視装置から管理装置に通報を行った後に、管理装置において、前記異常の発生したマンホールポンプについてあらかじめ設定された通報先に一括で通報処理を行うようにしたので、監視装置毎に通報先の設定を行う必要がなくなり、設定作業や設定の変更作業に要する時間や労力を大幅に削減することができる。さらに、異常が生じたマンホールポンプのメンテナンス処理について、現場担当者からの通報がある都度、その通報に基づくステータス情報を作成してステータス管理データベースに保存し、この情報を関係者が必要に応じて確認できるようにしたので、各関係者にメンテナンス処理の進行状態を効率良く伝えることができ、システムの利便性をさらに向上することができる。
【図面の簡単な説明】
【図１】この発明にかかる下水道管理システムの概要を示す説明図である。
【図２】監視装置の構成を示すブロック図である。
【図３】管理用サーバーの構成を示す機能ブロック図である。
【図４】通報定義データベースのデータ構成例を示す説明図である。
【図５】監視装置における監視ならびに通報処理の手順を示すフローチャートである。
【図６】サーバーが通報データの受付処理を行う場合の手順を示すフローチャートである。
【図７】緊急通報処理の詳細な手順を示すフローチャートである。
【図８】通信端末機器に届いた緊急通報データの例を示す説明図である。
【図９】サーバーが定期報告処理を行う場合の手順を示すフローチャートである。
【図１０】通信端末機器に届いた月報データの例を示す説明図である。
【図１１】サーバーがインターネットを介してデータを送受信する場合の手順を示すフローチャートである。
【図１２】マンホールポンプの役割を示す説明図である。
【符号の説明】
１ 監視装置
２ 管理用サーバー
３ コンピュータ
４ａ，４ｂ，４ｃ ルーター
６ 無線通信網
７ インターネット
８ 通信端末機器
１０ａ，１０ｂ マンホールポンプ
１４ モデム
１５ ＣＰＵ
２４ 通信インターフェース
３０ 通報動作制御部
３１ 通報データ受付部
３３ 緊急通報処理部
３４ 定期報告処理部
３６ 報告データ作成部
３７ Ｗｅｂページ管理部
３８ 受信履歴データベース
３９ 通報定義データベース[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a system for remotely monitoring sewage treatment and the like, and particularly to a system for maintaining and managing a mechanism for flowing sewage in a sewer.
[0002]
[Prior art]
There are various types of remote monitoring systems of this type, such as monitoring systems for water pipes and sewers, and monitoring systems for running out of traffic light bulbs. Many of these systems report when an abnormality occurs or regularly. As a representative example, the sewer will be explained. When it is necessary to flow sewage from a low point to a high point, manholes 51 are installed at a plurality of positions between these points as shown in FIG. A pump 52 is provided. (The pump 52 provided in the manhole 51 is called a “manhole pump”.)
Between adjacent manholes 51, 51, a water distribution pipe 53 that is inclined obliquely downward from the upstream side toward the downstream side is provided. After the sewage from the upstream side is pumped up by the manhole pump 52, the water distribution pipe It flows through the manhole 51 on the downstream side through 53. By performing this process at a plurality of points, it is possible to smoothly flow sewage even under an uphill slope.
[0003]
However, if the manhole pump 52 breaks down, the water level in the manhole 51 rises and the sewage overflows on the road, which may significantly deteriorate the surrounding environment. For this reason, in recent years, a monitoring device is provided for each manhole 51 to monitor the operating state of the manhole pump 52 and the water level in the manhole 51, and when an abnormality is detected, the monitoring device detects the occurrence of an abnormality from the municipal office, maintenance contractor, manhole pump. By making a report to other manufacturers, etc., we respond promptly to the occurrence of abnormalities.
[0004]
The above monitoring device is incorporated in a control box provided in the vicinity of the manhole 51 together with a preprocessing circuit and a communication modem. The monitoring device is set to be connected from a modem to a communication terminal device such as a telephone, a facsimile, a mobile phone, and a pager (portable wireless caller, so-called pager) through a public line. These connection destination communication terminal devices are determined in advance by designating addresses such as telephone numbers and facsimile numbers by government offices or traders. When an abnormality occurs in the operating state or the water level of the manhole pump, the monitoring device directly communicates with each communication terminal device, and transmits voice information and character information notifying the occurrence of the abnormality.
[0005]
According to the system configured as described above, it is possible to perform notification processing corresponding to the communication terminal device used in each department for a plurality of notification destinations designated by a government office or a trader. Moreover, since the reporting process can be automatically performed for a plurality of reporting destinations, the person in charge at the government office or the trader can quickly recognize and respond to the abnormal state occurring in the manhole.
[0006]
[Problems to be solved by the invention]
However, in the system having the above configuration, since it is necessary to first set the report destination of the occurrence of an abnormality for each monitoring device, a great amount of labor is required for the system setting work, and as a result, the construction work of the management system is inefficient. there were. Furthermore, if you are instructed to change the notification destination settings, such as changing the notifications for telephone calls to fax-compatible reports or increasing the number of notification destinations, you must reset the notification destination for each monitoring device. As a result, a maintenance person has to go around the installation site of the monitoring device and perform complicated setting work, and there is also a problem that a great deal of labor is required for changing the system settings.
[0007]
  This invention was made paying attention to the above problems, and aims to reduce the labor required for system setting when constructing a management system such as a manhole pump,In addition, when an abnormality occurs, the related parties can efficiently check the process after the abnormality has occurred.It aims to be able to do it.
[0008]
[Means for Solving the Problems]
The sewerage management system according to the present invention includes a plurality of monitoring devices that are provided for each installation location of the manhole pump and monitor the operating state of the manhole pump, and a management device that is set to be communicable with each monitoring device.
The monitoring device is provided in the vicinity of the manhole where the manhole pump is installed, and includes a reporting means for notifying the management device of the abnormal state by communication when an abnormal operation of the manhole pump is detected.
[0009]
In this monitoring device, an external signal indicating the operation state of the manhole pump, such as a detection output from a sensor that detects the rotation of the rotor in the manhole pump, is input, and based on this input signal, for example, a manhole pump every predetermined period It is possible to determine whether or not the manhole pump is operating normally by checking the number of times of operation. Further, not only the operation of the manhole pump itself but also the operation state of the manhole pump can be determined by checking whether the water level of the manhole pump has reached an abnormal level by a water level detection sensor. The notification means is set to notify the management device of an “abnormal state” of the manhole pump by transmitting notification data including data (ID number or the like) specifying the manhole pump in which an abnormality has occurred, for example.
As an “abnormal state”, it may be simply notified that an abnormality has occurred. However, in the monitoring device, detailed contents of abnormality such as pump operation stop and malfunction can be determined based on the input signal. If there is, data indicating the contents may be transmitted as an abnormal state.
[0010]
According to a preferred aspect, the notification means includes a communication means for communicating with the management device, and when an abnormal operation of a manhole pump is detected, notification data indicating the abnormal state is created, and then the communication Control means for causing the management apparatus to execute processing for transmitting the notification data. The communication means is, for example, an interface circuit for operating a modem, and the control means provides the modem with report data in a format based on a communication protocol (protocol) such as TCP / IP via this interface circuit for management. It is a processor that performs control to be transmitted to the apparatus.
Note that the modem is not limited to being externally attached, and may be incorporated into the main body of the monitoring device as necessary.
[0011]
Further, it is desirable that the monitoring device is configured to monitor the power supply state to the device together and to transmit notification data indicating the abnormal state when an abnormality such as a power failure occurs.
[0012]
  The notification process from the monitoring apparatus configured as described above to the management apparatus is implemented as an information transmission process via a packet communication wireless communication network, for example.
  For each manhole pump, the management device displays a report definition database that stores definitions related to the report destination and report operation when an abnormality occurs in the operation of the pump, and the maintenance process progress status for the manhole pump in which an error has occurred. A status management database for storing status information to indicate, communication means set to be able to communicate with a plurality of types of communication terminal devices according to the communication protocol corresponding to each communication terminal device, and a predetermined monitoring device Report control that, when receiving report data indicating an abnormal state, determines a report destination and report operation corresponding to the report data based on the definition of the report definition database, and causes the communication means to execute the determined report processing Means, and the manhole report where the abnormality was reported by the report control means and the communication means. Status management means for creating status information based on the contents of the report and storing it in the status management database each time the communication means accepts a report from the communication terminal device of the person in charge of the site, and the communication means ButConnectedWhen receiving a request for browsing status information regarding a manhole in which an abnormality has occurred from a communication terminal device, the requested status information is read from the status management database, and the read status information is read using the communication means.sentBrowsing request response means for returning to the communication terminal device. The management apparatus is preferably configured as a computer network including a plurality of computers and peripheral devices.
[0013]
In the report definition database, for example, the type of communication terminal device (telephone, facsimile, personal computer, etc.) and address (phone number, e-mail address, etc.) of the report destination are set as a report destination when an abnormality occurs. In addition, the report operation includes data such as the data format of the report data (voice data, text data, images, etc.) and communication protocol (protocol) used for transmission linked to the type of each reporting terminal device, As necessary, the type of data to be included in the contents of the report and the arrangement order (format) of these data are set for each report destination.
In addition, although the setting of the report destination in the report definition database is performed for each manhole pump, it is desirable that a plurality of types of report destinations can be set for any pump. Furthermore, regarding the report destination, a plurality of report destinations may be set according to the time zone, day of the week, and the like.
[0014]
  communicationThe means includes a communication device such as a modem and a router, and an interface circuit provided between these devices and the CPU. In addition, thiscommunicationThe means is preferably configured to include a plurality of communication devices according to the type of communication device to be used and the communication line used for connection.
  The notification control meanscommunicationAfter the means is connected by giving the address of the communication terminal device to be notified, the notification data in a format corresponding to the communication terminal device is given to transmit the data.
[0015]
  According to the sewerage management system with the above configuration,If an abnormality occurs in the manhole pump,Since the notification processing to the government office and maintenance contractor is performed in a batch by the management device, it is only necessary to set the monitoring device to make a notification to the management device. Setting at the time of change can be greatly simplified. Moreover, since the labor required for this type of setting can be reduced, the cost of the system can be greatly reduced, and the system after introduction can be operated quickly.
  Furthermore, in the management device, the status information indicating the progress of the maintenance process is created and stored in the status management database based on the notification from the communication terminal device of the person in charge for the manhole in which an abnormality has occurred. Since the status information requested by the communication terminal device is received and the status information requested by the communication terminal device is returned, the related person grasps the occurrence of the abnormality by collective notification and then manages the device as necessary. By accessing and making a browsing request, it is possible to grasp the progress of maintenance work after the occurrence of an abnormality.
[0016]
  In a preferred aspect of the above sewer management system, the monitoring device is:Shows the operating state of the manhole pump at every predetermined timeRegularPeriodic reporting means for creating report data and sending it to the management deviceAnd further. AlsoIn the management device,The report definition database further stores definitions for the report destination and report operation for normal reports for each manhole pump,Received from each monitoring deviceRegularA reception history database for accumulating report data;Regular report data is created for each manhole pump using the regular report data stored in the reception history database at a preset time, and each regular report data created is normally reported based on the definition of the report definition database. And a periodic notification means for transmitting to a notification destination for use. If it does in this way, the process which reports the operation state of each manhole pump regularly to an interested person can also be performed easily.
[0021]
  In another preferred aspect, the communication means comprisesMeans for communicating with a communication terminal device via a communication network system such as the InternetIncluding receiving status report data, requesting status information viewing, and returning requested status information., The communication network systemExecute by communication via According to this aspect,Devices that can be connected to communication network systems such as personal computers and mobile phonesCan be used to transmit status report data and view status information.
[0023]
  In another preferred embodiment,The management apparatus can be provided with an input means for receiving data input for setting or changing the definition of the report definition database and an update means for updating the setting contents of the report definition database based on the input data.
  The input means is configured as an input device directly connected to the management device, such as a keyboard. In addition, a communication terminal device connected via the communication network described above can function as an input unit. (However, this type of external device is preferably only for devices that are permitted by a password authentication system.)
[0024]
According to the above configuration, even when a new report destination is set or an existing report destination or report operation is changed, the setting or change can be easily performed by inputting data into the management apparatus. In particular, if data input is accepted via a communication network, a person in charge such as a government office or a contractor can directly perform setting work.
[0027]
DETAILED DESCRIPTION OF THE INVENTION
FIG. 1 shows the configuration of a sewer management system according to an embodiment of the present invention.
This sewerage management system monitors the water level in the manhole and the operation of the manhole pump for the sewerage system of multiple municipalities around the clock, and reports the monitoring results to the municipal offices and manhole pump maintenance contractors. It is for alerting | reporting, and comprises the monitoring apparatus 1 and the management server 2 which were installed for every manhole as a main structure.
[0028]
Although the details will be described later, each monitoring device 1 constantly monitors the operating state and water level of the manhole pump in the vicinity of the manhole installation site (indicated by P, Q, and R in the figure). Each monitoring device 1 is set with a protocol corresponding to the wireless communication network 6 of the packet communication system, and periodically reports the current monitoring state to the management server 2 (hereinafter, this report data is referred to as “periodic”. Report data ”). Further, when the monitoring device 1 detects that an abnormality has occurred in the operation of the manhole pump or the water level, it creates notification data indicating the state of the abnormality (hereinafter referred to as “abnormality notification data”), and the management server. 2 to send.
[0029]
The management server 2 (hereinafter simply referred to as “server 2”) may be composed of one computer, but here, a plurality of computers 3 (only two are shown in FIG. 1) are combined. Takes the form of a computer network system. In addition to the router 4a corresponding to the wireless communication network, the server 2 includes a telephone 4a and a facsimile 8b designated by a municipal office or a maintenance company by a router 4b for a public line and a router 4c connected to a dedicated line to the Internet 7. , Mobile phone 8c, pager 8d, personal computer 8e, and the like.
[0030]
The server 2 can sequentially receive report data from each monitoring device 1 via a router 4a or the like compatible with a wireless communication network, and creates a database of the received report data. Further, the server 2 creates periodic report data such as daily reports and monthly reports using these report data, and transmits them to a report destination designated in advance. In addition, when the server 2 receives the abnormality report data from the predetermined monitoring device 1, the server 2 creates emergency report data corresponding to the data content and transmits it to a predetermined report destination.
[0031]
If any of the above emergency call destinations is required to report the progress of the maintenance work for the abnormality thereafter, the server 2 is a maintenance company worker or maintenance company dispatched to the site of the abnormality. Receives report data from other offices and manages the progress of maintenance work. (Hereinafter, this management is referred to as “status management”, and the report data from the worker to the server 2 is referred to as “status report data”.)
The status report data is made via the Internet 7. For example, when the worker himself / herself performs a report process, the worker's own character information service reception function or mobile phone 8 c with an e-mail transmission / reception function is transmitted to the Internet 7. Access the home page of the server 2 on the server 7, enter data according to the instructions, and report the work progress to the server 2 side. Also, when reporting to the server 2 via the office, after the worker contacts the office by telephone or e-mail, the personal computer 8e at the office is connected to the Internet 7 and the worker is informed. Information transmission based on the contents of reports from.
[0032]
FIG. 2 shows the configuration of the monitoring device 1 together with the relationship with the manhole (indicated by reference numeral 9 in the figure).
In the manhole 9, two manhole pumps 10a and 10b are usually installed in preparation for a failure, and a sensor head 11 for measuring the water level is installed. In the following description, the manhole pumps 10a and 10b are simply referred to as “pumps 10a and 10b”, and when referring to the pumps individually, they are referred to as “first pump 10a” and “second pump 10b”. To.
[0033]
The monitoring device 1 is deployed in a state of being mounted on a control panel 15 together with a water level detection unit 12, operation detection units 13a and 13b for each pump, a communication modem 14, and the like. The control panel 15 is accommodated in a protective box (not shown), and is provided near the manhole such as on the side of the road.
[0034]
The sensor head 11 is a throw-in type device in which a pressure sensor is incorporated, and outputs a signal indicating the water pressure in the manhole 9. The water level detection unit 12 converts this output signal into an analog signal indicating the water level and outputs it to the monitoring device 1.
Each pump 10a, 10b is provided with a sensor (not shown) for detecting the rotation of the rotor in the pump, and each pump operation detection unit 13a, 13b uses a detection signal from this sensor. Then, the operation of the pumps 10a and 10b is detected. This detection result is output as a digital signal that becomes H level while the pump is operating, and is provided to the monitoring device 1.
[0035]
The monitoring device 1 includes a control unit 18 in which a memory 16 and a clock 17 are connected to a CPU 15, a water level signal input unit 19, an operation signal input unit 20, a power supply circuit 21, a battery 22, a switching circuit 23, and a communication interface 24. Etc. are incorporated.
[0036]
The water level signal input unit 19 includes an A / D conversion circuit for digitally converting the analog signal from the water level detection unit 12, a comparison circuit for comparing the detected water level with a predetermined threshold value, and the like. These circuits generate a digital signal indicating the water level and an abnormal signal that becomes H level when the water level is abnormal, and outputs the signal to the CPU 15. On the other hand, the operation signal input unit 20 is for relaying digital output signals from the pump operation detection units 13 a and 13 b to the CPU 15.
[0037]
The power supply circuit 21 supplies current from an external power supply to each unit in the monitoring device 1. Further, a signal that is constantly at the H level is output from the power supply circuit 21 to the CPU 15, and the CPU 15 detects a power failure using this signal. (Hereinafter, the signal from the power supply circuit 21 is referred to as a “power failure detection signal”.)
At the time of a power failure, the power supply to the CPU 15 is switched to the battery side by the switching circuit 23, so that the CPU 15 can determine whether an abnormality has occurred for a predetermined period even during a power failure, Can be executed without any problem.
[0038]
The memory 16 is a non-volatile memory such as a flash memory. The memory 16 stores a program for causing the CPU 15 to perform various processes, a protocol for wireless communication, and the like, as well as databases indicating the history of input signals and the history of notification processing (respectively “signal history database” and “respectively”). "Report history database") is set.
[0039]
In addition, what gathered the log | history in a signal log | history database for every arbitrary time becomes regular report data. The arbitrary time is measured by the clock 17.
The data transmitted as the periodic report data may be automatically deleted from the signal history database, but is not limited to this, and may be left until the database is full.
[0040]
In the CPU 15, processing units such as a main control unit 25, a signal determination unit 26, and a communication control unit 27 are set based on a program set in the memory 16. The signal discriminating unit 26 inputs the signal from the water level signal input unit 19 and the operation signal input unit and the power failure detection signal to discriminate the water level and the operating state of each pump 10a, 10b, as well as the water level and the pump 10a. , 10b is detected or when a power failure occurs, the abnormality is detected.
[0041]
The main control unit 25 sequentially captures signals from the input units 19 and 20 via the signal determination unit 26 and accumulates them in the signal history database in the memory 16, and periodically reports based on the determination processing result of the signal determination unit 26. The communication control unit 27 is actuated by determining the timing at which a notification is made when an error occurs. Based on an instruction from the main control unit 25, the communication control unit 27 creates regular report data or abnormality report data addressed to the server 2, and then provides the report data to the modem 14 via the communication interface 24. Send to 2 The transmitted report data is stored in a report history database in the memory 16.
[0042]
FIG. 3 shows the configuration of the server 2 in the form of a functional block diagram.
As described above, the server 2 is a network system including a plurality of computers and routers. By incorporating a program into each computer, the notification operation control unit 30, the notification data reception unit 31, the notification data recognition processing unit 32, and the emergency notification processing Processing units such as a unit 33, a periodic report processing unit 34, a status management unit 35, a report data creation unit 36, and a Web page management unit 37 are set. In addition, a reception history database 38, a report definition database 39, an emergency report template 40, a daily report / monthly report template 41, a report history database 42, a status management database 43, a Web page database are stored in a memory such as a hard disk device or a computer that manages the memory. A database such as 44 is set.
[0043]
Of the various databases, the reception history database 38 is for storing report data from each monitoring device 1 in time series for each device. The report history database 42 is a database for accumulating emergency reports and periodic reports transmitted from the server 2 to other communication terminal devices 8. The daily report / monthly report template 41 and the emergency report template 40 include various communication terminal devices 8. A template file of periodic report data and emergency call data to be sent to is stored.
[0044]
  Although details will be described later, the report definition database 39 stores definitions for each site corresponding to each monitoring device 1, such as a report destination, a report method, a format of periodic report data, and whether status management is necessary. Is done. In the status management database 43, management information based on the status report data (hereinafter referred to as “status information”) for each abnormality that has occurred.Is stored. Further, the web page database 44 stores image information and programs for presenting various web pages on the Internet 7.
[0045]
The notification operation control unit 30 selects and transmits a communication path and a protocol corresponding to the communication terminal device 8 of the report destination for each type of notification data created by the emergency notification processing unit 33 and the regular report processing unit 34. belongs to.
The report data receiving unit 31 is used for capturing the report data from each monitoring device 1 into the system, and the captured report data is given to the report data recognition processing unit 32.
[0046]
The report data recognition processing unit 32 recognizes not only the report data report source, but also the data type and specific report contents, etc., and then creates reception history data in which the recognition result is associated with the current time. Store in the reception history database 38.
Further, when the report data is anomaly report data, the report data recognition processing unit 32 passes information related to the report source and the report content to the emergency call processing unit 33. The emergency call processing unit 33 creates emergency call data corresponding to the given data while referring to the call definition database 39 and the emergency call template 40, and gives this to the call operation control unit 30 for each call destination. To send to.
[0047]
The status management unit 35 registers the abnormal state notified by the emergency notification process in the status management database 43 as a new management target. Thereafter, status report data is fetched for the management target via the web page management unit 37, status information indicating a maintenance state is extracted from the report data, and stored in the status management database 43.
[0048]
The regular report processing unit 34 reads the reception history for each site from the reception history database 38 at the preset time, and also reads the report destination and data format of the regular report data from the report definition database 39. Furthermore, after reading the template file corresponding to the format set in the report definition database from the daily / monthly report template 41, the regular report processing unit 34 assigns the reception history to this template and creates regular report data. The created regular report data is given to the notification operation control unit 30 in the same manner as the emergency notification data, and is transmitted to the notification destination.
In the report definition database 39, when the periodic report is set to include status information, the periodic report processing unit 40 reads the necessary status information from the status management database data 43 and creates report data. Used for.
[0049]
The Web page management unit 37 transmits a predetermined menu page based on data and programs in the Web page database 44 to the communication terminal devices 8c and 8e connected to the Internet, and inputs data and presents data via the menu page. Accept the request.
In particular, when the status report data is received, the web page management unit 37 passes the status report data to the status management unit 35 and requests the status management database 43 to store status information.
[0050]
When receiving a request for browsing information on the site where an abnormality has occurred on the menu page, the Web page management unit 37 passes this browsing request to the report data creation unit 36. The report data creation unit 36 reads data corresponding to the browsing request from the reception history database 38 and the status management database 43 and creates report data in a predetermined format. Further, the generated report data is edited into a Web page format by the Web page management unit 37 and transmitted to the communication terminal devices 8c and 8e that have issued a browsing request.
[0051]
FIG. 4 shows a configuration example of the notification definition database 39.
This report definition database is set with a report destination for emergency reports and a report destination for periodic reports for each installation location of the manhole 9 or for each monitoring device 1, and includes a report definition table 39A, a report destination table 39B, and an illustration. It is set as a relational database linked with a table showing the definition of the report action not to be performed.
[0052]
The report definition table 39A stores, for each manhole 9, data that associates the name of the site where the manhole 9 is installed, a report source ID, and a plurality of report destination IDs.
The report source ID is information for identifying the manhole, and specifically, the identification ID of the monitoring device 1. This notification source ID is a code included in the notification data for identifying the notification source when the monitoring device 1 transmits the notification data to the server 2, and is the ID number and manhole of the municipality that manages the manhole 9 The ID number is connected with a hyphen.
[0053]
On the other hand, the report destination ID is set for each individual communication terminal device 8 that is the report destination, and the ID number of the owner (city, village, trader, etc.) of the communication terminal device 8 and the ID number of the communication terminal device. It takes a configuration connected with a hyphen.
In the notification definition table 39A of the illustrated example, for the emergency call processing, a report destination ID indicating a report destination designated by a government office or a contractor is set for each combination of an abnormality occurrence site and the type of abnormality that has occurred. In addition, regarding the regular report processing, the daily report transmission destination and the monthly report report destination ID are set individually. Note that any number of report destinations can be set according to the site, the type of abnormality, the type of periodic report, and the like.
[0054]
The report destination table 39B is a table that stores specific contents indicated by each report destination ID, and stores the type and address (telephone number, e-mail address, etc.) of the communication terminal device 8 that is the report destination for each ID. The Further, for the ID of the report destination designated as the regular report destination, the status management presence / absence, daily report, monthly report format, etc. are also set. As for the format of the daily report and the monthly report, either the case of setting a plurality of types or the case of setting only a single type may be used.
[0055]
Further, the report destination table 39B also stores a report destination second address as a second report destination when a communication error to the report destination address occurs. Also included are time definitions and calendar definitions that indicate the time zones and dates that can be reported, so that normal working hours, work days, holidays, etc. can be reported.
Depending on the report destination, a non-defined report destination is set when the time and calendar are not defined. This non-definition report destination can be used as a spare third report destination.
[0056]
As shown in the figure, if you want to assign the same report destination to pumps installed at the same site, or assign the same report destination to multiple nearby sites, set a common ID in the report definition table 39A. Therefore, the number of data can be reduced, and even when the report destination is partially changed, it is possible to respond quickly.
[0057]
When performing the reporting process, the server 2 first identifies the reporting destination ID by referring to the reporting definition table 39A, and then refers to the reporting destination table 39B by the reporting destination ID to specify a specific reporting destination terminal. Identify devices and addresses. Then, the server 2 refers to the table indicating the definition of the notification operation for the specified communication terminal device 8 of the specified notification destination, specifies the data type, protocol, etc. of the notification data, and then reports data corresponding to the definition Process to create and send.
[0058]
The contents to be set in the report definition table 39A and the report destination table 39B can be set according to the demands of each government office or supplier, and can be changed as appropriate. The data can be set or changed by data input by an administrator on the server 2 side, or access authority is given to a specific user in a government office or a contractor, and the personal computer 8e used by these users can access the Internet 7 It is also possible to accept data input via.
[0059]
In this way, the definition contents of the report definition database 39, such as the location and number of report destinations and the type of communication terminal device 8, can be freely set or changed according to the situation of the site, the scale of the department in charge, the change of the maintenance company, etc. Can do. In the conventional system, since the report destination is set for each monitoring device at each site, a large amount of labor is required for the setting work and the change work. In the system of this embodiment, the server side is as described above. By making settings and changes at once, the labor and cost required for the work can be greatly reduced.
[0060]
In addition, in the conventional system, because the monitoring device side needs to handle the notification processing to various communication terminal devices, the monitoring device side sets the protocol and report data template for each type of communication terminal device. For the setting, it is necessary to incorporate a large memory resource in the monitoring device, resulting in high costs. Moreover, when the monitoring device is in operation, the necessary protocol and report data are selected and used, so not all set protocols and templates are necessarily used, and the memory resources are limited. In some cases, it was wasted.
On the other hand, in the system of this embodiment, it is only necessary to set the protocol and communication data targeted for the server 2 in each monitoring device, so there is no need to incorporate extra memory for setting the communication environment. Memory resources can be effectively used for the signal history database and the report history database.
[0061]
Furthermore, in the system of this embodiment, the operation environment such as the signal monitoring interval and the periodic notification time interval in each monitoring device 1 can also be set according to the command from the server 2 side. (The setting contents are based on data input by the server administrator.) Also, each monitoring device such as the stored data in the signal history database and the communication history database can be appropriately deleted by a command from the server 2. Various settings and management for 1 can be performed collectively on the server 2 side.
[0062]
Hereinafter, the procedure of the notification process in the monitoring device 1 and the server 2 will be described in order.
FIG. 5 shows the procedure of monitoring and notification processing in the monitoring device 1. In the figure, each step is indicated as “stOO”.
[0063]
The CPU 15 of the monitoring device 1 supplies the operation detection signal for each pump 10a, 10b from the operation signal input unit 20 and the water level data and the abnormal signal from the water level signal input unit 19 in units of a predetermined time (for example, 1 minute). The power failure detection signal from the circuit 21 is accumulated in the signal history database in the memory 16 while being monitored, and each monitored signal is compared with the previous monitoring result. In the figure, st1 represents a process for inputting and storing the signal, and st2 represents a process for comparing the signals.
[0064]
When a change is recognized in the signal state in st2, the abnormality report data is created by the processing of st3 to 17, and is transmitted to the server 2.
In this embodiment, the abnormal state is managed by setting four types of abnormality flags according to the type of abnormality. First, in st3, the number of pump operations is extracted from the monitoring result of the latest operation detection signal for the first pump 10A, and this is compared with a predetermined threshold value. Here, if an abnormality such as the first pump 10a not operating or the number of operations is extremely small has occurred, the number of operations falls below the threshold value. In this case, it is determined that there is an abnormality and st4 Then, the abnormality flag for the first pump 10a is turned on. On the other hand, if the latest number of operations is greater than or equal to the threshold value, it is determined that there is no abnormality and the process proceeds to st5, where the abnormality flag for the first pump 10a is set off.
[0065]
In the next st6-8, the same determination process as described above is performed for the second pump 10b, and the abnormality flag for the second pump 10b is set to ON or OFF.
Next, in st9, the water level abnormality signal is checked. As described above, the water level abnormality signal becomes H level when the threshold value is exceeded. In this case, the process proceeds from st9 to st10, and the water level abnormality flag is set to ON. On the contrary, if the water level abnormality signal is L level, the process proceeds from st9 to st11, and the water level abnormality flag is set to OFF.
Further, in st12 to 14, the power failure detection signal is checked, and when it is determined that there is a power failure, the power failure flag is turned on, and when it is determined that it is not a power failure, the power failure flag is turned off.
[0066]
When the setting of each abnormality flag is completed in this way, in the next st15, abnormality notification data is created. In this embodiment, as the abnormal-time notification data, the four types of abnormality flags are arranged in order after the identification code indicating the data type, and the data with the notification source ID and the current time are added. To do.
In the subsequent st16, the created report data is stored in the report history database in the memory 16, and the report data is transmitted to the server 2 in st17. When the transmission is completed, the process returns to st1 and the signal is monitored again.
[0067]
On the other hand, if no change is recognized in the signal state at st2, the process of st1 and 2 is repeated, and the process waits while repeating monitoring until a predetermined time (for example, 10 minutes) elapses. When a certain period of time elapses in this state, st18 becomes “YES”, the process proceeds to st19, and periodic report data is created.
[0068]
In this embodiment, as the periodic notification data, after the identification code indicating the data type, untransmitted data in the signal history database is arranged in time series, and the data with the notification source ID and the current time are added. Shall be created. After the creation of this data, the processes of st16 and 17 are performed, so that the periodic report data is stored in the report history database and then transmitted to the server 2. After the data transmission, the process returns to st1. If there is no change in the signal state, the periodic report data is created and transmitted to the server 2 every predetermined period while accumulating the signal history.
[0069]
According to the above processing flow, not only when the first abnormality occurs, but also when a new abnormality occurs or when the abnormal state is released, the error notification data is created Then, since it is transmitted to the server 2, it is possible to promptly report a detailed change in the abnormal state. In addition, since the signal in the abnormal state is also sequentially stored and later included in the periodic report data and transmitted to the server 2, in the server 2, for example, whether the pump abnormality means a pump stop or malfunction, It is possible to analyze detailed abnormal conditions such as the level of abnormalities in water level.
[0070]
Next, main processing on the server 2 side will be described. In the following description, each step is indicated as “STOO” in order to distinguish it from the procedure with the monitoring device 1.
FIG. 6 shows a flow of processing for receiving report data from the monitoring device 1. In the figure, the loop of ST1 and ST2 is repeated until the notification data from the predetermined monitoring device 1 arrives, and the incoming call is waited. If the incoming call is confirmed at a predetermined time, the process proceeds to ST3, where the report data is received and analyzed, and the received data is stored in the reception history database 38 in the next ST4.
Note that the analysis process in ST3 includes a process for recognizing the type of report data and a process for recognizing the contents of the report separately for each data. For example, if the received data is anomaly notification data, after identifying the data type from the head identification code, data such as the notification source ID, various abnormality flags, and the current time are individually separated.
[0071]
Further, if the report data is abnormal report data, the process proceeds from ST5 to ST6 to perform emergency call processing.
FIG. 7 shows the detailed procedure of the emergency call process of ST6. (Each step in this figure is indicated as “ST6-xx”.)
[0072]
First, in ST6-1, the report definition database 39 is referred to, and the report destination corresponding to the report source ID of the report data at the time of abnormality and the contents of the abnormality flag is specified. Next, in ST6-2, the data type and protocol corresponding to the communication terminal device of the report destination are determined for the first report destination. Further, in the next ST6-3, a template corresponding to the content of the abnormality flag and the data type determined in ST6-2 is read out from the emergency notification template 40 to create emergency notification data, and the determined protocol is used. Send by.
[0073]
Similarly, the emergency call process is sequentially executed for other report destinations by executing the processes of ST6-2 and 6-3.
Although not shown in the flowchart, in this embodiment, when a communication error to the report destination occurs, the retransmission process is performed several times. I am trying to make a report. Furthermore, when a communication error occurs to the second report destination, the communication destination is switched to a non-defined report destination, or communication with the first report destination or the second report destination is attempted again.
[0074]
When the reporting process for all reporting destinations is completed, ST6-4 becomes “YES” and the process proceeds to ST6-5. In ST6-5, it is checked whether or not there is a report destination defined to perform status management among the report destinations. If there is a report destination set to perform status management here, ST6-5 becomes “YES” and the process proceeds to ST6-6. In ST6-6, as the status management target, the report source ID of the site where the abnormality has occurred as the target of the emergency call, the type of the abnormality, the ID of the report destination in which status management is defined, and the like are set. The target is newly registered in the status management database 43. At the time of this new registration, the management serial number and the URL of the reference page on the Web are set and registered together in the status management database 43.
[0075]
FIG. 8 shows printout of report data transmitted by facsimile or electronic mail as an output example of emergency report data that has arrived at the communication terminal device 8 side. The numbers (1) to (9) in the figure are not output in the actual report, but are reference numbers for the following explanation.
In the figure, (1) is a destination set in the destination column of the report destination table 39B. (2) is the name of the site determined by referring to the report definition table 39A based on the communication source ID of the error notification data. (3) is the current time incorporated in the error notification data. Is replaced. (4) is an abnormality name corresponding to the abnormality flag set to ON among the abnormality flags of the abnormality notification data. Furthermore, (5) represents the detailed contents of the abnormal state determined from the periodic notification data before and after receiving the abnormal notification data, and is incorporated into the emergency notification as necessary.
[0076]
The next (6) is the contents of maintenance corresponding to the abnormality that has occurred. For this, data set in the template in advance may be used as it is. (7) is another report destination that is the target of the same emergency call transmission, and shows data that replaces the report destination ID set in the report definition table with specific contents based on the report destination table. ing. Further, (8) and (9) are the URL and management serial number of the Web reference page (page for browsing status information) set in accordance with the registration processing in the status management database 35.
[0077]
According to such emergency call data, the concerned person can quickly and accurately know the site where the abnormality has occurred and the state of the abnormality after the occurrence of the abnormality. In addition, with the information (8) and (9), it is possible to freely view the progress of the maintenance for the abnormality that has occurred using a Web browser, and to efficiently deal with the abnormality.
Similarly, emergency call data based on voice data for a telephone is created by applying data such as an abnormality occurrence site, abnormality occurrence time, and abnormality content to a voice data template. However, since the emergency call data by voice may not be able to be grasped by a single output, it is desirable to define that the transmission is repeated until the partner communication terminal device disconnects the line.
[0078]
FIG. 9 shows a detailed procedure (ST11 to 16) of the regular report processing.
First, at the time of the regular report, ST11 becomes “YES” and the process proceeds to ST12, and for each site, the type, address, and protocol to be used of the destination communication terminal device 8 are specified from the notification definition database 39. At the same time, the template used for the periodic report data is specified from the format of the daily report or monthly report set in the report destination table 39B.
[0079]
In the next ST13, the template of the specified format is read from the daily / monthly report template 41 for the first site. Next, in ST14, data necessary for creating the regular report data is read from the reception history database 38, the report history database 42, the status management database 43, etc. for the site of interest. In ST15, the periodic report data corresponding to the template is created and transmitted using the determined protocol while performing various tabulation processes and data replacement processes using other reference tables based on the read data.
[0080]
In the same manner, the periodic report data is created and transmitted by the processes of ST13 to 15 for each site. In addition, when there are a plurality of report destinations for one site, the processing of ST13 to 15 is performed for each report destination.
When the transmission of the regular report data to all the report destinations is completed in this way, ST16 becomes “YES” and the process returns to ST11 and waits until the next regular report time comes.
[0081]
FIG. 10 shows an example of the periodic report data in the monthly report format. In the figure, “X” and “O” mean arbitrary numbers.
In this example as well, the data transmitted by facsimile apparatus or e-mail is printed out as in FIG. In the figure, the portion indicated by reference number (11) is obtained by aggregating history data indicating the operating state of each pump 10a, 10b stored in the reception history database 38, and each pump 10a, 10b. The operation time for each operation, the number of operations, and the result of totalizing the integrated flow rate by the two pumps 10a and 10b every day, and the monthly average, maximum value, minimum value, total value, etc. of these data are shown.
[0082]
(12) shows the details of the abnormal content of the day when the abnormality occurred based on the history data of the reception history database 38 and the report history database 42. Further, (13) shows a report destination that made an emergency report, status information indicating whether maintenance has been completed, a recovery time, and the like based on the status management database 43.
[0083]
FIG. 11 shows a procedure (ST21 to ST35) in the case of performing transmission / reception with respect to the communication terminal device 8 such as the mobile phone 8c and the personal computer 8e via the Internet 7. Note that the procedure for exchanging signals with the communication terminal device 8 is the same as that of a general Internet-compatible server 2, and therefore, here, in particular, when receiving status report data and receiving a request for browsing status information Detailed processing will be described only in cases.
[0084]
First, in ST21 and 22, it waits for the incoming call processing in the router 4c for the Internet.
When the communication terminal device 8 performs processing for transmitting the URL of the home page of the server 2 after connecting to the Internet, ST22 becomes “YES” and the process proceeds to ST23.
[0085]
In ST23, a menu page is transmitted to the communication terminal device 8. The user on the communication terminal device 8 side selects a desired menu on this menu page. If transmission of the status notification data is designated here, the process proceeds from ST24 to ST27, and a page for inputting status information is transmitted. Next, when the user inputs predetermined status information together with the name of the site to be managed, an abnormal state, etc. on this page, ST28 becomes “YES”. Upon receiving this determination, the server 2 confirms that the status information input in ST29 corresponds to a case registered as a management target in the status management database 43, and then corresponds this information to the current time in ST30. Then, it is stored in the status management database 43.
[0086]
On the other hand, if the information selected on the menu page is a request for referring to status information regarding an abnormal condition at a predetermined site, ST25 becomes “YES” and the process proceeds to ST31. In ST31, it is checked whether or not the case requested for reference is registered in the status management database 43. If registered, the process proceeds from ST31 to ST32, the necessary data is read from the status management database 43 and the reception history database 38, and a report page indicating the contents of abnormality and status information is created. Send to 8 side.
In ST29 and ST31, if the case for which input or reference is requested is not registered in the status management database 43, the process proceeds to ST33, and an error message display page is transmitted.
[0087]
After such processing, when the user performs a return operation, the process returns from ST34 to ST23 and transmits the menu page again. When the user disconnects or performs an operation to move to another page, ST35 is “YES”, the incoming call processing is terminated, and the process returns to ST21 to wait for the next incoming call.
[0088]
If a menu other than the above two processes is selected on the menu page, the process proceeds from ST26 to ST36, and a process corresponding to the menu is executed. For example, when presentation of report data for the previous day is requested for a predetermined site, a report data page based on a predetermined format is created by referring to various databases in the same manner as the regular report processing, and this is used as a communication terminal. It is transmitted to the device 8 side.
[0089]
According to such information transmission via the Internet, the government office or the contractor side can take in desired information as needed, so that when an abnormality occurs, it is possible to check the progress of maintenance for the abnormality frequently. The recovery process can be managed efficiently.
[0090]
In the above embodiment, an example is shown in which an emergency call or a periodic report is made for each manhole. However, in this sewerage management system, the pumps and water levels in each manhole are set as necessary for one or a plurality of adjacent municipalities. It is possible to display a list of the statuses, create a map showing the location of the manhole where the abnormality occurred, and perform the notification process. Therefore, for example, management under conditions where there is a high possibility of abnormality such as during heavy rain can be enhanced, and the convenience of the system is greatly improved.
In addition, this sewerage management system can capture necessary information beyond the jurisdiction of each government office, and can collect information on sewerage networks under multiple jurisdictions. It is possible to realize system operation beyond the jurisdiction, such as early recognition in the municipalities downstream and taking countermeasures.
[0091]
【The invention's effect】
  As described above, in the present invention,When an abnormality occurs in the manhole pump, after reporting to the management device from the monitoring device that detected the abnormality, in the management device,To the notification destination set in advance for the manhole pump where the abnormality occurredIn bulkReport processingI did so,It is not necessary to set a report destination for each monitoring device, and the time and labor required for setting work and setting change work can be greatly reduced.In addition, every time there is a report from the person in charge of the maintenance process of the manhole pump in which an abnormality has occurred, status information based on the report is created and stored in the status management database. Since it can be confirmed, the progress of the maintenance process can be efficiently communicated to each person concerned, and the convenience of the system can be further improved.
[Brief description of the drawings]
FIG. 1 is an explanatory diagram showing an outline of a sewer management system according to the present invention.
FIG. 2 is a block diagram illustrating a configuration of a monitoring device.
FIG. 3 is a functional block diagram showing a configuration of a management server.
FIG. 4 is an explanatory diagram showing a data configuration example of a report definition database.
FIG. 5 is a flowchart showing a procedure of monitoring and notification processing in the monitoring apparatus.
FIG. 6 is a flowchart showing a procedure when the server performs notification data reception processing;
FIG. 7 is a flowchart showing a detailed procedure of emergency call processing.
FIG. 8 is an explanatory diagram showing an example of emergency call data delivered to a communication terminal device.
FIG. 9 is a flowchart illustrating a procedure when the server performs a periodic report process.
FIG. 10 is an explanatory diagram showing an example of monthly report data delivered to a communication terminal device.
FIG. 11 is a flowchart illustrating a procedure when the server transmits and receives data via the Internet.
FIG. 12 is an explanatory diagram showing the role of a manhole pump.
[Explanation of symbols]
1 Monitoring device
2 Management server
3 Computer
4a, 4b, 4c router
6 Wireless communication network
7 Internet
8 Communication terminal equipment
10a, 10b Manhole pump
14 Modem
15 CPU
24 Communication interface
30 Report Operation Control Unit
31 Report data reception
33 Emergency call processing department
34 Periodic Report Processing Department
36 Report Data Creation Department
37 Web Page Management Department
38 Reception history database
39 Report definition database

Claims (5)

マンホールポンプの設置場所毎に配備され前記マンホールポンプの動作状態を監視する複数台の監視装置と、各監視装置と通信可能に設定された管理装置とから成るシステムであって、
前記監視装置は、マンホールポンプの動作異常を検知したとき、その異常状態を通信により前記管理装置に報知する通報手段を具備し、
前記管理装置は、
各マンホールポンプ毎にそのポンプの動作に異常が発生したときの通報先および通報動作に関する定義が格納された通報定義データベースと、
異常が発生したマンホールポンプについて、メンテナンス処理の進行状態を示すステータス情報を格納するためのステータス管理データベースと、
複数種の通信端末機器に対し、それぞれその通信端末機器に対応する通信規約による通信が可能に設定された通信手段と、
所定の監視装置から前記異常状態を示す通報データを受信したとき、前記通報定義データベースの定義に基づき前記通報データに対応する通報先および通報動作を決定して、その決定された通報処理を前記通信手段に実行させる通報制御手段と、
前記通報制御手段および通信手段により異常が通報されたマンホールポンプのメンテナンス処理について、前記通信手段が現場担当者の通信端末機器からの通報を受け付ける都度、その通報内容に基づくステータス情報を作成して前記ステータス管理データベースに保存するステータス管理手段と、
前記通信手段が接続された通信端末機器から異常が発生したマンホールに関するステータス情報の閲覧要求を受け付けたとき、要求されたステータス情報を前記ステータス管理データベースから読み出し、読み出したステータス情報を前記通信手段を用いて閲覧要求を送信した通信端末機器に返送する閲覧要求応答手段とを、具備して成る下水道管理システム。A system comprising a plurality of monitoring devices that are installed at each installation location of the manhole pump and monitors the operating state of the manhole pump, and a management device that is set to be communicable with each monitoring device,
When the monitoring device detects an abnormal operation of the manhole pump, the monitoring device comprises a reporting means for notifying the management device of the abnormal state by communication,
The management device
A report definition database that stores definitions for report destinations and report actions when an abnormality occurs in the operation of each manhole pump;
A status management database for storing status information indicating the progress of maintenance processing for the manhole pump in which an abnormality has occurred;
Communication means set to be able to communicate according to the communication protocol corresponding to each communication terminal device for a plurality of types of communication terminal devices,
When notification data indicating the abnormal state is received from a predetermined monitoring device, a notification destination and a notification operation corresponding to the notification data are determined based on the definition of the notification definition database, and the determined notification processing is performed in the communication Reporting control means to be executed by the means;
About the maintenance process of the manhole pump in which the abnormality is reported by the notification control means and the communication means, each time the communication means accepts a report from the communication terminal device of the person in charge of the field, create status information based on the contents of the report and Status management means for storing in the status management database;
When receiving a request for viewing status information regarding a manhole in which an abnormality has occurred from a communication terminal device to which the communication means is connected, the requested status information is read from the status management database, and the read status information is used using the communication means. A sewerage management system comprising browsing request response means for returning the browsing request to the communication terminal device that has transmitted the browsing request. 前記監視装置は、所定時間毎にマンホールポンプの動作状態を示す定期通報データを作成して前記管理装置に送信する定期通報手段を、さらに具備し、
前記管理装置の通報定義データベースには、各マンホール毎に通常報告のための通報先および通報動作に関する定義がさらに格納され、
前記管理装置は、各監視装置から受信した定期通報データを蓄積する受信履歴データベースと、あらかじめ設定された時刻に、前記受信履歴データベースに蓄積された定期通報データを用いてマンホールポンプ毎に定期報告データを作成し、作成された各定期報告データを、それぞれ前記通報定義データベースの定義に基づき通常報告用の通報先に送信する定期通報手段とを、さらに具備する、請求項１に記載された下水道管理システム。The monitoring device further comprises periodic notification means for creating periodic notification data indicating the operating state of the manhole pump every predetermined time and transmitting it to the management device,
The management device's report definition database further stores definitions for the report destination and report operation for normal reporting for each manhole,
The management device uses a reception history database that accumulates periodic notification data received from each monitoring device, and periodic report data for each manhole pump using the periodic notification data stored in the reception history database at a preset time. The sewerage management according to claim 1, further comprising: periodic reporting means for transmitting each created periodic report data to a report destination for normal reporting based on the definition of the report definition database. system. 前記通信手段は、通信ネットワークシステムを介して通信端末機器との通信を行う手段を含んでおり、前記ステータス通報データの受付およびステータス情報の閲覧要求ならびに請求されたステータス情報の返送を、前記ネットワークシステムを介した通信により実行する、請求項１に記載された下水道管理システム。  The communication means includes means for communicating with a communication terminal device via a communication network system, and accepts the status notification data, requests for viewing status information, and returns the requested status information. The sewerage management system according to claim 1, wherein the sewerage management system is executed by communication via 前記管理装置は、前記通報定義データベースの定義を設定または変更するためのデータ入力を受け付ける入力手段と、入力されたデータに基づき通報定義データベースの設定内容を更新する更新手段とを、さらに具備する請求項１または２に記載された下水道管理システム。  The management device further includes an input unit that receives data input for setting or changing the definition of the report definition database, and an update unit that updates the setting contents of the report definition database based on the input data. Item 3. A sewer management system according to item 1 or 2. マンホールポンプの監視装置からマンホールポンプの動作状態を示す通報データを受信するための受信手段と、
複数種の通信端末機器に対し、それぞれその通信端末機器に対応する通信規約による通信が可能に設定された通信手段と、
各マンホールポンプ毎にそのポンプの動作に異常が発生したときの通報先および通報動作に関する定義が格納された通報定義データベースと、
異常が発生したマンホールポンプについて、メンテナンス処理の進行状態を示すステータス情報を格納するためのステータス管理データベースと、
所定の監視装置から前記異常状態を示す通報データを受信したとき、前記通報定義データベースの定義に基づき前記通報データに対応する通報先および通報動作を決定して、その決定された通報処理を前記通信手段に実行させる通報制御手段と、
前記通報制御手段および通信手段により異常が通報されたマンホールポンプのメンテナンス処理について、前記通信手段が現場担当者の通信端末機器からの通報を受け付ける都度、その通報内容に基づくステータス情報を作成して前記ステータス管理データベースに保存するステータス管理手段と、
前記通信手段が関係者の通信端末機器から異常が発生したマンホールに関するステータス情報の閲覧要求を受け付けたとき、要求されたステータス情報を前記ステータス管理データベースから読み出し、読み出したステータス情報を前記通信手段を用いて閲覧要求を送信した通信端末機器に返送する閲覧要求応答手段とを、具備して成る下水道管理用の管理装置。Receiving means for receiving report data indicating the operating state of the manhole pump from the manhole pump monitoring device;
Communication means set to be able to communicate according to the communication protocol corresponding to each communication terminal device for a plurality of types of communication terminal devices,
A report definition database that stores definitions for report destinations and report actions when an abnormality occurs in the operation of each manhole pump;
A status management database for storing status information indicating the progress of maintenance processing for the manhole pump in which an abnormality has occurred;
When notification data indicating the abnormal state is received from a predetermined monitoring device, a notification destination and a notification operation corresponding to the notification data are determined based on the definition of the notification definition database, and the determined notification processing is performed in the communication Reporting control means to be executed by the means;
About the maintenance process of the manhole pump in which the abnormality is reported by the notification control means and the communication means, each time the communication means accepts a report from the communication terminal device of the person in charge of the field, create status information based on the contents of the report and Status management means for storing in the status management database;
When the communication means receives a request to view status information regarding a manhole in which an abnormality has occurred from a communication terminal device of a related party, the requested status information is read from the status management database, and the read status information is used by the communication means. A management device for sewer management, comprising browsing request response means for returning the browsing request to the communication terminal device that has transmitted the browsing request.
JP2001029152A 2001-02-06 2001-02-06 Sewer management system and management device used in this system Expired - Fee Related JP4258125B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2001029152A JP4258125B2 (en) 2001-02-06 2001-02-06 Sewer management system and management device used in this system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2001029152A JP4258125B2 (en) 2001-02-06 2001-02-06 Sewer management system and management device used in this system

Publications (2)

Publication Number Publication Date
JP2002230670A JP2002230670A (en) 2002-08-16
JP4258125B2 true JP4258125B2 (en) 2009-04-30

Family

ID=18893531

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2001029152A Expired - Fee Related JP4258125B2 (en) 2001-02-06 2001-02-06 Sewer management system and management device used in this system

Country Status (1)

Country Link
JP (1) JP4258125B2 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110948808A (en) * 2018-09-26 2020-04-03 住友重机械工业株式会社 Injection molding system and injection molding machine

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7126472B2 (en) * 2003-07-22 2006-10-24 Mark W Kraus System and method of providing emergency response to a user carrying a user device
JP2005215932A (en) * 2004-01-29 2005-08-11 Secom Co Ltd Security system and signal processing method for security system
MX2009000392A (en) 2006-07-12 2009-06-17 Imprenditore Pty Ltd Monitoring apparatus and system.
US20100115093A1 (en) * 2007-05-04 2010-05-06 Patrick Jeremy Rice Monitoring apparatus and system
JP2009110480A (en) * 2007-11-01 2009-05-21 Chugoku Electric Power Co Inc:The Standing water management method in manholes of electric wire utility tunnels
JP2009164738A (en) * 2007-12-28 2009-07-23 Omron Corp Remote monitoring system, remote monitoring terminal, and remote monitoring terminal control program
JP5399692B2 (en) * 2008-12-02 2014-01-29 株式会社クボタ Manhole pump device control device, manhole pump device, and manhole pump device operation method
JP6454459B2 (en) * 2013-10-02 2019-01-16 綜合警備保障株式会社 Security system and security method
JP5640130B1 (en) * 2013-10-04 2014-12-10 株式会社京三製作所 Electronic interlocking system
JP6289967B2 (en) * 2014-03-28 2018-03-07 株式会社クボタ Equipment update method and equipment update notification device
JP2016115989A (en) * 2014-12-11 2016-06-23 三菱電機株式会社 Wireless adapter and apparatus controller
JP6318192B2 (en) * 2016-05-13 2018-04-25 愛瑪麗歐股▲ふん▼有限公司 Emergency call device and system
JP2018055150A (en) * 2016-09-26 2018-04-05 株式会社クボタ Notification device, monitoring system and notification method
JP6937105B2 (en) * 2016-10-28 2021-09-22 株式会社東芝 Road abnormality response support device, road abnormality response support method, and program
CN109336199B (en) * 2018-11-20 2024-02-06 中冶京诚工程技术有限公司 Sewage treatment real-time monitoring method and system
JP7418282B2 (en) 2020-05-19 2024-01-19 クボタ環境エンジニアリング株式会社 Signal relay device for manhole equipment

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110948808A (en) * 2018-09-26 2020-04-03 住友重机械工业株式会社 Injection molding system and injection molding machine

Also Published As

Publication number Publication date
JP2002230670A (en) 2002-08-16

Similar Documents

Publication Publication Date Title
JP4258125B2 (en) Sewer management system and management device used in this system
US8138940B2 (en) Municipal operations monitoring and alert system
JP2001077965A (en) Image-forming apparatus management system and management method
US8040231B2 (en) Method for processing alarm data to generate security reports
CN102412998A (en) Operation service system and maintenance method and device thereof
JP2011008627A (en) Facility information management system
KR20070080965A (en) Unified control system for ubiquitous city
JP2006352387A (en) Travel ticket service system, monitor device, and travel ticket service method used therefor
JP2001202298A (en) Monitoring manager, field monitoring device and computer-readable recording medium with program recorded thereon
JP2002132335A (en) Monitor and control network system for water treating facilities
JP3914039B2 (en) Electronic device remote monitoring system
US6727813B2 (en) Alarm notifying device and computer program
JP2003005827A (en) Remote monitoring system
JP2004030113A (en) Informing device
JP7226670B2 (en) Elevator suspension information provision system
JP2003204542A (en) Remote supervisory system
JP2002133044A (en) Plant facility management service system
JP3813064B2 (en) Equipment operating status monitoring system for water supply facilities
CN102843258B (en) Business operation fault determination method and business operation fault determination device
JP2003346269A (en) Monitoring data collection and distribution method and system
WO2004061792A1 (en) Remote building monitoring system and monitoring method
JP3459902B2 (en) Remote monitoring system
JPH1030271A (en) Sewage monitoring device for manhole type pump site
JP2006338372A (en) Event management device and management system for plant
US6700485B2 (en) Alarm notifying device

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20050810

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20080327

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080401

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080527

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080902

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20081017

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20090113

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20090126

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120220

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120220

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130220

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140220

Year of fee payment: 5

LAPS Cancellation because of no payment of annual fees