JP2019087176A - 監視システム、監視方法、監視システム用プログラム - Google Patents

Abstract

【課題】監視システムの監視データのセキュリティの向上を図る。【解決手段】各遠方監視装置３Ａ〜３Ｃから監視データを収集・蓄積する収集配信サーバ１０と、収集配信サーバ１０から必要な監視データを取得する操作者の端末４と、を備える。このサーバ１０は、事業主のアカウント毎に監視データを記録するＤＢ２１Ａ〜２１Ｃと、各ＤＢ２１Ａ〜２１Ｃに対応して設けられた配信部１９Ａ〜１９Ｃと、操作者に付与された前記アカウントを記録した認証ＤＢ２０と、認証ＤＢ２０を参照して操作者を認証する認証部１８とを備えている。操作者にはメインアカウントとサブアカウントとが付与され、認証部１８はメインアカウントでのアクセスを許可すれば、サブアカウントでのアクセスを許可する。【選択図】図５

Description

本発明は、対象設備の運転状況や故障確認などの状態を監視する監視システムおよび監視方法並びに監視システム用のプログラムに関する。

例えばポンプ場・排水機場・発電所・工場など各種施設の状態を監視するシステムとしてクラウドコンピューティング技術を応用したシステム、即ちクラウド型監視システムが提案されている。

図１に基づき概略を説明する。ここではクラウド型監視システム８は、排水機場Ａ〜Ｃの運転状況や故障確認などの状態を監視する。このクラウド型監視システム８は、ネットワーク１４，１５経由でデータ送受信自在の接続された収集配信サーバ（親機）２と遠方監視装置（子機）３Ａ〜３Ｃと端末４Ａ〜４Ｃとを備えている。

遠方監視装置３Ａ〜３Ｃは、排水機場Ａ〜Ｃにおける現場の状態（故障を含む）を計測信号として取り込み、監視データとして収集配信サーバ２にインターネット経由で送信する。ここでは遠方監視装置３Ａは排水機場Ａに設置され、遠方監視装置３Ｂは排水機場Ｂに設置され、遠方監視装置３Ｃは排水機場Ｃに設置され、それぞれ各排水機場Ａ〜Ｃの監視データを収集配信サーバに送信している。

収集配信サーバ２は、クラウド型監視システム８の中枢装置であり、遠方監視装置３Ａ〜３Ｃから送信された各排水機場Ａ〜Ｃの監視データを受信し、受信した監視データを集約する。ここで集約された監視データを記録・演算し、インターネット経由で端末４Ａ〜４Ｃに配信する。具体的には収集配信サーバ２は、監視データの記録・演算を実行するデータベースサーバ２ａと、記録・演算された監視データを配信する配信サーバ２ｂとを備えている。

端末４Ａ〜４Ｃは、例えばパーソナルコンピュータ（ＰＣ）やタブレット，スマートフォンなどの端末であって、操作員（ユーザ）Ａ〜Ｃの端末操作に応じてデータベースサーバ２ａに記録・演算された監視データを参照する。このとき操作員Ａ〜Ｃは、それぞれ端末Ａ〜Ｃの操作により排水機場Ａ〜Ｃの運転状況の監視や故障などの故障を確認し、監視データを編集する。

この排水機場ＡはＡ市の管轄であり、排水機場ＢはＢ町の管轄であり、排水機場ＣはＣ市の管轄であり、クラウド型監視システム８によれば管轄の異なる別組織（事業主）の監視データが同一の環境で取り扱われる。

ただし、各排水機場Ａ〜Ｃの監視データは、それぞれＡ〜Ｃ市の管轄下にあるから、操作員Ａ〜Ｃは管轄の異なる他の組織の監視データの参照・編集を行ってはならない。

したがって、クラウド型監視システム８においては、他者による監視データのアクセスを防止すべく、セキュリティ機能が必須となっている。この点につき特許文献１では、受益者単位（事業主単位）で付与されたＩＤと端末単位で付与されたＩＤとを使用することで監視データのセキュリティを図っている。

特開２０１１−１９８２３６

しかしながら、特許文献１では、すべての事業主（図１中ではＡ市，Ｂ町，Ｃ市）の監視データを同一のデータベース（ＤＢ）に記録しているため、セキュリティが脆弱なおそれがある。

例えば監視データの識別子が誤って付与された場合や、アクセス認証処理などに不具合が生じた場合、さらに悪意を持った侵入者などの不正アクセスが起こり易い。

本発明は、このような従来の問題を解決するためになされ、監視システムにおける監視データのセキュリティの向上を図ることを解決課題としている。

（１）本発明の一態様は、
対象設備ごとに設置された遠方監視装置と、
前記監視装置から監視データを収集・蓄積するサーバと、
前記サーバから必要な監視データを取得する操作者の端末と、を備えた簡易システムであって、
前記サーバは、前記監視データを前記対象設備の事業主毎に記録するデータベースと、
前記データベースに記録された前記各監視データを前記端末に事業主単位で配信する配信部と、を備える。

（２）本発明の他の態様は、
対象設備ごとに設置された監視装置と、
前記監視装置から監視データを収集・蓄積するサーバと、
前記サーバから必要な監視データを取得する操作者の端末と、を備えたシステムの実行する監視方法であって、
前記サーバのデータベースに前記監視データを前記対象設備の事業主毎に記録する記録ステップと、
前記データベースに記録された前記各監視データを前記端末に事業主単位で配信する配信ステップと、を有する。

（３）本発明のさらに他の態様は、前記サーバとして、コンピュータを機能させることを特徴とする監視システム用のプログラムに関する。

本発明によれば、監視システムにおける監視データのセキュリティを向上させることができる。

クラウド型監視システムを示す全体構成図。 同 事業主毎にＤＢを分割した構成図。 同 アカウントとユーザとの実例図。 同 認証データのＤＢスキーマ図。 本発明の実施形態に係るクラウド型監視システムの構成図。 同 認証データのＤＢスキーマ図。 実施例１の認証データ図。 同 認証手順のシーケンス図。 同 Ａ市ホーム画面図。 図９の詳細画面図。 アカウント切替手順のシーケンス図。 Ｂ町ホーム画面図。 実施例２のＡ市・Ｂ町を集約したホーム画面図。 同 データ集約手順のシーケンス図。 実施例３のアカウントグループ図。 同 グループ管理者データテーブルの記録データ例を示す図。 同 アカウントグループの管理手順のシーケンス図。 同 ユーザ管理画面図。 同 サブアカウントのユーザ管理画面への追加を示す説明図。

以下、本発明の実施形態に係るクラウド型監視システムを説明する。まず、図２〜図４に基づき前記クラウド型監視システムの主目的を説明する。ここでは図１の符号を用いて説明するものとする。

すなわち、前記クラウド型監視システムは、図２に示すように、データベースサーバ２ａ内のデータベースを事業主（Ａ市〜Ｃ市）毎のデータベース（ＤＢ）５〜７として分割し、セキュリティを強化している。

この場合に各事業主が管轄する排水機場Ａ〜Ｃの監視データは、それぞれ独立したデータベース５〜７に記録される。また、各事業主にはアカウントと呼ばれるアクセス権限が１つ割り当てられ、アカウント毎にアクセス可能なデータベース５〜７が定まる。このとき図３に示すように、各事業主には複数の操作員が存在する。

ここでは各操作員Ａ−１〜Ａ−ｎ（以下、操作員Ａ群とする。），Ｂ−１〜Ｂ−ｎ（以下、操作員Ｂ群とする。），Ｃ−１〜Ｃ−ｎ（以下、操作員Ｃ群とする。）は、ログイン操作を行い、予め登録されているユーザ名とパスワードによる認証を受ける。この認証をうければ、図４に示すように、認証トークンが渡されて認証済みであることが識別され、該認証トークンにはアクセス可能なデータベース５〜７が示されている。

ここでログインした操作員は、以降アカウントにより定められたデータベース５〜７にアクセス可能となり、管轄するいずれかの排水機場Ａ〜Ｃの運転操作を行うことができる。これにより権限の無いデータベース５〜７へのアクセスが防止でき、セキュリティを特許文献１よりも強固とすることができる。

ところが、近年の市町村合併などにより事業主が統合される場合が少なくない。例えばＡ市とＢ町とが合併した場合には、それぞれが管轄する排水機場Ａ〜Ｃの統合が求められる。そうすると操作員Ａ，Ｂ群の各員は、これまでは排水機場Ａ，Ｂの一方を監視していたものの、統合以降は双方を監視しなければならないおそれがある。

このとき排水機場Ａ〜Ｃに応じてデータベース５〜７が分割されていると、監視の対象設備の切り替えを頻繁に行わなければならず、操作員Ａ，Ｂ群の各員は事業主毎に登録されているユーザ名およびパスワードでの再ログインが必要となってしまう。

この再ログインの作業は非常に面倒であり、時間もかかるため、操作員Ａ，Ｂ群の各員に煩雑な作業を強いることとなり、同各員の負担が増加してしまう。その結果、故障発生時などは迅速な対応が求められるものの、その対応が遅れて復旧作業などに影響を与えるおそれがある。

この場合に事業主Ａ，Ｂのデータベース５，６を１つに統合すれば、再ログインの作業は必要なくなるものの、それにはデータベース５，６の内容を大規模に書き換える必要が生じ、大きな手間と時間とコストがかかってしまう。

そこで、前記クラウド型監視システムにおいては、データベースを分割してセキュリティ強化を実現したうえで、操作員に対する可用性が高く、対象設備の事業主統合などに伴うメンテナンス性の容易な監視技術を図っている。

≪システム構成例≫
（１）図５に基づき前記クラウド型監視システムの好ましい構成例を説明する。図５中の９は前記クラウド型監視システムを示し、背景技術のクラウド型監視システム８と同様にＡ市の管理する排水機場ＡとＢ町の管理する排水機場ＢとＣ市の管理する排水機場Ｃとを監視の対象設備とし、排水機場Ａ〜Ｃの運転状況や故障確認などの状態を監視している。

前記クラウド型監視システム９は、操作員（ユーザ）の端末４とインターネット１４経由でデータ送受信自在に接続された収集配信サーバ（親機）１０と、収集配信サーバ１０と閉域ＩＰ網１５経由でデータ送受信自在に接続された遠方監視装置（子機）３Ａ〜３Ｃとを備えている。

この端末４および遠方監視装置３Ａ〜３Ｃは、クラウド型監視システム８と同様なため説明を省略する。また、事業主Ａ（Ａ市），事業主Ｂ（Ｂ町），事業主Ｃ（Ｃ市）には、それぞれアカウントＡ〜Ｃが割り当てられているものとする。ここで図５中は、一人の操作員が表されているが、図３と同様にアカウントＡ〜Ｃ毎に複数の操作員が存在しているものとする。

一方、収集配信サーバ１０は、収集配信サーバ２と同様に遠方監視装置３Ａ〜３Ｃの監視データの記録・演算を実行するデータベースサーバ１１と、データベースサーバ１１に記録・演算された監視データを端末４に配信する配信サーバ１２とを備えている。この配信サーバ１２はアカウント毎に分割されて独立した配信部１９Ａ〜１９Ｃを備えている一方、データベースサーバ１１はアカウント毎に分割されて独立したＤＢ２１Ａ〜２１Ｃを備えている。このＤＢ２１Ａ〜２１Ｃは図２中のＤＢ５〜７に相当し、ＤＢ２１Ａ〜２１Ｃと配信部１９Ａ〜１９Ｃとが対応して設けられている。

ここではアカウントＡの事業主Ａ（Ａ市）が管轄する排水機場Ａの運転状況や故障状態などの状態は、遠方監視装置３Ａにより収集され、ＤＢ２１Ａに監視データとして記録される。また、アカウントＢの事業主Ｂ（Ｂ町）が管轄する排水機場Ｂの同状態は、遠方監視装置３Ｂにより収集され、ＤＢ２１Ｂに監視データとして記録される。さらにアカウントＣの事業主Ｃ（Ｃ市）が管轄する排水機場Ｃの同状態は、遠方監視装置３Ｃにより収集され、ＤＢ２１Ｃに監視データとして記録される。

このような前記クラウド型監視システム９によれば、予めいずれかのアカウントＡ〜Ｃが付与された操作員は、端末４の操作により配信サーバ１２を介して同じアカウントのＤＢ２１Ａ〜２１Ｃに記録された監視データにアクセスすることができる。

このとき操作員は、配信サーバ１２にログインして認証部１８による認証を受けることにより、同じアカウントのＤＢ２１Ａ〜２１Ｃへのアクセス権限を取得する。この認証部１８は、認証ＤＢ（データベース）２０を参照して操作員に認証を与える。

この認証ＤＢ２０には、操作員毎にアカウント（Ａ〜Ｃ）名とユーザ名とパスワードとが記録されている。ここでは各ＤＢ２０，２１Ａ〜２１Ｃは、それぞれコンピュータの記録装置（ＲＡＭ，ＲＯＭなどの主記憶装置・ＳＳＤ,ＨＤＤなどの補助記憶）に構築されている。

また、データベースサーバ１１および配信サーバ１２の認証部１８，配信部１９Ａ〜１９Ｃ，認証ＤＢ２０，ＤＢ２１Ａ〜２１Ｃは、それぞれ論理的または物理的に独立した実行環境で実行され、単一のサーバ上で複数実行可能な仮想マシンとして構築してもよく、それぞれを専用のサーバで実行してもよい。

（２）図６に基づき認証ＤＢ２０に登録される認証データのスキーマを説明する。ここでは操作員（ユーザ）は、メインのアカウント（以下、メインアカウントとする。）を一つ持つことができる。

また、操作員は、メインアカウントに加えてサブのアカウント（以下、サブアカウントとする。）を複数持つことができる。このサブアカウントは、必要に応じて追加される（必要が無い場合には設定しない。）。

具体的には排水機場Ａ〜Ｃを管轄する事業主Ａ〜Ｃが統合された場合には、ユーザにサブアカウントとして統合された事業主のアカウントが追加される。例えばＡ市とＢ町とが統合された場合、Ａ市のユーザにＢ町のカウントＢをサブアカウントとして追加することができる。

これによりメインアカウントに加えてサブアカウントに対応するＤＢ２１へのアクセスを可能にすることができる。ここではメインアカウントとサブアカウントとでユーザ名・パスワードが同じとなっているが、相違していてもよいものとする。

統合された事業主のアカウントは、アカウントグループとして集約される。例えばＡ市とＢ町とが統合された場合にはメインアカウントとサブアカウントとが一つのアカウントグループとして集約される。

このアカウントグループには一人以上のグループ管理者が割り当てられる。このグループ管理者に設定された特別なユーザは、アカウントグループ内の各ユーザ、即ちアカウントグループに所属するアカウントに関連付けられたユーザに対して、サブアカウントの追加・削除などの編集を行う権限を持つ。

≪実施例１≫
図７〜図１２に基づき前記クラウド型監視システム９の実施例１を説明する。ここでは図７の操作員（ユーザ）Ａ−１を一例に実施例を説明する。

（１）認証手順
まず、図８および図９に基づき操作員Ａ−１の認証手順（認証ステップＳ０１〜Ｓ０８）を説明する。

この操作員Ａ−１は、メインアカウントとしてＡ市のアカウントＡを所持し、さらにＡ市とＢ町の合併によりＢ町の排水機Ｂも管轄となったため、Ｂ町のアカウントＢをサブアカウントとして追加所持する。以下、各実施例中では、メインアカウントＡ，サブアカウントＢと示すものとする。

Ｓ０１〜Ｓ０３：操作員Ａ−１が端末４の操作によりログインページ（例えばhttps://cloudservice.jp/login）を指定して認証部１８にアクセスすることにより処理が開始される。

すなわち、認証部１８は、端末４の操作により入力されたアカウント名（メインアカウントＡの名称）・ユーザ名・パスワードを受け付ける（Ｓ０１）。この受け付け後に認証部１８は、認証ＤＢ２０を参照して予め登録されたアカウント名・ユーザ名・パスワードと照合し、操作員Ａ−１の認証を開始する（Ｓ０２）。

照合の結果、入力されたアカウント名・ユーザ名・パスワードと、登録されたアカウント名・ユーザ名・パスワードとが一致すれば、ユーザ認証が成功して認証ＤＢ２０から認証トークンが発行される（Ｓ０３）。

ここで操作員Ａ−１は、メインアカウントＡとサブアカウントＢとを所有するため、各アカウントに応じて２つの認証トークンＡ，Ｂが発行される。すなわち、メインアカウントＡに応じてＤＢ２１Ａの認証トークンＡが発行され、サブアカウントＢに応じてＤＢ２１Ｂの認証トークンＢが発行され、各認証トークンＡ，Ｂが認証部１８に通知される。この認証トークンにはＡ市のＤＢ２１Ａへのアクセス許可が示され、認証トークンにはＢ町のＤＢ２１Ｂへのアクセス許可が示されている。なお、Ｓ０２の照合の結果、一致しなければユーザ認証が不成功として処理を終了する。

Ｓ０４：認証部１８は、操作員Ａ−１のメインアカウントＡであるＡ市のホーム画面のアドレス（例えばhttps://accountA.cloudservice.jp）と併せて両認証トークンＡ，Ｂを端末４に通知する。

Ｓ０５：操作員Ａ−１の操作に応じて端末４が、前記アドレス（例えばhttps://accountA.cloudservice.jp）を用いて、Ａ市の配信部１９Ａに前記ホーム画面の表示を依頼する。その際、端末４が配信部１９ＡにＤＢ２１Ａへの認証トークンＡを渡すことにより、配信部１９Ａは前記ホーム画面の表示依頼を受け付ける。

Ｓ０６，Ｓ０７：配信部１９Ａは、受け取った認証トークンＡをＤＢ２１Ａに送り、アクセス許可を求める（Ｓ０６）。このとき認証トークンＡには、ＤＢ２１Ａへのアクセス許可が示されているため、同アクセスは許可される（Ｓ０７）。

Ｓ０８〜Ｓ１０：配信部１９Ａは、前記ホーム画面の編集に必要なデータを取得するため、ＤＢ２１Ａにアクセスする（Ｓ０８）。

これにより配信部１９Ａは、Ａ市のポンプ場一覧（ポンプ場リスト）・各ポンプ場の名称・各ポンプ場の詳細画面のアドレスなどのデータをＤＢ２１Ａから取得する（Ｓ０９）。取得したデータに基づき前記ホーム画面を編集して端末４に送信し（Ｓ１０）、端末４は送信されたホーム画面のデータを受信して表示する。

ここで表示される前記ホーム画面には、図９に示すように、Ａ市が管轄するポンプ場の一覧表Ｌ１が表示されている。この一覧表Ｌ１のポンプ場名（Ａ市ポンプ場１〜Ａ市ポンプ場３）には、該ポンプ場の詳細画面のアドレスがリンクされている。例えば一覧表Ｌ１中の「Ａ市ポンプ場１」を端末４にてクリックすれば、図１０の詳細画面Ｌ２を呼び出すことができる。

（２）アカウントの切替手順
つぎに図１１に基づきＡ市のメインアカウントＡからＢ町のサブアカウントＢへの切替手順（切替ステップ）を説明する。このアカウントの切替は、図９に示すＡ市のホーム画面から行う。

Ｓ１１：まず、図９のホーム画面中に表示された「Ｂ町」のボタンＬ３をクリックする。このボタンＬ３には、Ｂ町のホーム画面のアドレス（例えばhttps://accountB.cloudservice.jp）が埋め込まれている。

したがって、ボタンＬ３をクリックすれば、配信部１９ＢにＢ町のホーム画面の表示を依頼することとなる。その際、認証トークンＢを配信部１９Ｂに渡すことで配信部１９ＢがＢ町のホーム画面の表示依頼を受け付ける。

Ｓ１２，Ｓ１３：配信部１９Ｂは、受け取った認証トークンＢをＤＢ２１Ｂに送り、アクセス許可を求める（Ｓ１２）。このとき認証トークンＢには、ＤＢ２１Ｂへのアクセス許可が示されているため、同アクセスは許可される（Ｓ１３）。

Ｓ１４〜Ｓ１６：配信部１９Ｂは、Ｂ町のホーム画面の編集に必要なデータの取得するため、ＤＢ２１Ｂにアクセスする（Ｓ１４）。

これにより配信部１９Ｂは、Ｂ町のポンプ場一覧（ポンプ場リスト）・各ポンプ場の名称・各ポンプ場の詳細画面のアドレスなどのデータをＤＢ２１Ｂから取得する（Ｓ１５）。ここで取得したデータに基づきＢ町のホーム画面を編集して端末４に送信し、端末４は送信されたホーム画面のデータを受信して表示する。

表示されるＢ町のホーム画面には、図１２に示すように、Ｂ町が管轄するポンプ場の一覧表Ｌ４が表示されている（Ｓ１６）。この一覧表Ｌ４のポンプ場名（Ｂ町ポンプ場１，２）には、該ポンプ場の詳細画面のアドレスがリンクされている。

例えば一覧表Ｌ１中の「Ｂ町ポンプ場１」を端末４にてクリックすれば、図示省略の詳細画面を呼び出すことができる。このとき詳細画面は、図１０に示す詳細画面に相当する内容を表示することができる。なお、図１２中の「Ａ市」のボタンをクリックすれば、Ｂ町のサブアカウントＢからＡ市のメインアカウントＡに切り替えられ、端末４に図９のホーム画面を表示することができる。

このような実施例１の前記クラウド型監視システム９によれば、複数事業主の監視データを同一実行環境で取り扱う際にセキュリティと可用性とを両立したユーザ認証を実現することができ、以下の効果を得ることできる。

（Ａ）前記クラウド型監視システム９は、データベースサーバ１１と配信サーバ１２とを事業主毎に分割し、事業主のアカウント毎にＤＢ２１Ａ〜２１Ｃおよび配信部１９Ａ〜１９Ｃを備える。これによりシステムのセキュリティが向上し、権限なきユーザ（操作員）によるＤＢ２１Ａ〜２１Ｃの監視データの参照や更新、あるいは悪意の侵入などの不正アクセスを抑制することができる。

（Ｂ）前記クラウド型監視システム９によれば、ユーザ（操作員）に対して１つのメインアカウントに加えて、複数のサブアカウントを追加することができる。したがって、サブアカウントをユーザに追加するだけで、ユーザのアクセス可能な事業主のＤＢ２１を追加させることができる。すなわち、アクセス可能な事業主のＤＢ２１を追加させるためにはユーザにサブアカウントを付与するだけでよく、該追加に伴うデータの更新が容易である。

（Ｃ）前記クラウド型監視システム９によれば、市町村合併により管轄する監視対象の施設の追加が必要となっても、メインアカウントでログインできるため、操作員はログインの操作方法を合併前と変えることなく、認証を受けて事業主のＤＢ２１にアクセスすることができる。

このときメインアカウントで認証されれば、サブアカウントに応じた事業主のＤＢ２１にもアクセスが可能となるため、事業主のＤＢ毎にログインする必要は無い。したがって、操作員は、ログインにあたって事業主のＤＢ２１が分割されていることを特に意識する必要なく、従前の通りに端末４を操作するだけでよい。この点でログイン操作を簡素化でき、また操作員の負担も軽減することができ、故障発生時などに迅速な対応が可能となる。

≪実施例２≫
図１３および図１４に基づき前記クラウド型監視システム９の実施例２を説明する。この実施例では、Ａ市の配信部１９ＡにおいてＤＢ２１Ａ，２１Ｂのデータを集約して表示する。

図１３は、Ａ市のホーム画面にＡ市のポンプ場とＢ町のポンプ場とを集約した一覧表Ｌ６を示している。この一覧表Ｌ６にはポンプ場毎の状態表示、即ち故障発生の有無が表示され、ポンプ場の設備に故障が発生した場合には「発生」と表示される。これにより操作員は、管轄するポンプ場全体の故障の有無を一目で把握することが可能となる。以下、図１４に基づき図１３のホーム画面の表示手順を説明する。ここでは実施例１と同様に操作員Ａ−１を一例に説明する。

Ｓ２１〜Ｓ２７：実施例１のＳ０１〜Ｓ０７と同様な処理を実行する。

Ｓ２８，Ｓ２９：配信部１９Ａは、受け取った認証トークンＢをＤＢ２１Ｂに送り、アクセス許可を求める（２８）。このとき認証トークンＢには、ＤＢ２１Ｂへのアクセス許可が示されているため、同アクセスは許可される（Ｓ２９）。

Ｓ３０〜Ｓ３４: 配信部１９Ａは、図１３のホーム画面の編集に必要なデータの取得するため、ＤＢ２１Ａ，ＤＢ２１Ｂにアクセスする（Ｓ３０，Ｓ３２）。これにより配信部１９Ａは、Ａ市のポンプ場一覧（ポンプ場リスト）・各ポンプ場の名称・各ポンプ場の詳細画面のアドレス・各ポンプ場の故障の有無などのデータをＤＢ２１Ａから取得する（Ｓ３１）
また、配信部１９Ｂは、Ｂ町のポンプ場一覧・各ポンプ場の名称・各ポンプ場の詳細画面のアドレス・各ポンプ場の故障の有無などのデータをＤＢ２１Ｂから取得する（Ｓ３３）。

その後、配信部１９Ａは、Ｓ３１,Ｓ３３で取得した各データを図１３のホーム画面に編集し、端末４に送信する（Ｓ３４）。このとき端末４では送信されたホーム画面のデータを受信して表示する。

Ｓ３５，Ｓ３６：端末４は、定期的に図１３のホーム画面についての更新を配信部１９Ａに依頼する（Ｓ３５）。この更新依頼があれば配信部１９Ａは、Ｓ３０〜Ｓ３４と同様の処理を実行して最新のＤＢ２１Ａ,２１Ｂのデータに基づき図１３のホーム画面を更新して端末４に送信し（Ｓ２６）、該ホーム画面のデータを端末４で受信して表示する。

ここで前記更新依頼は、Ｓ２３の認証トークンＡ，Ｂの有効期限内であれば、何度でも可能である。この有効期限後は、Ｓ２１〜Ｓ３４の処理を繰り返して図１３のホーム画面を端末４に表示させればよい。

このような実施例２の前記クラウド型監視システム９によれば、実施例１の効果に加えて、複数の事業主のＤＢ２１の監視情報（故障の有無など）を１つのホーム画面に集約して表示し、シームレスに取り扱うことができる。この点で操作員は集約されたホーム画面のみを見ればよく、利便性が向上する。

≪実施例３≫
図１５〜図１９に基づきの実施例３を説明する。この実施例ではアカウントグループの管理を説明する。図１５はＡ市とＢ町との合併後のアカウントグループＧａｂを示し、アカウントグループＧａｂにはＡ市のアカウントＡとＢ町のアカウントＢとが集約されている。

ここで図１５中の管理者Ｇは、メインアカウントとしてＡ市のアカウントＡを持ち、アカウントグループＧａｂの管理権限が与えられた管理ユーザであり、アカウントグループＧａｂへのユーザの追加・削除・更新が可能であり、グループ管理者データテーブルＤに登録されている。

図１６に基づきグループ管理者データテーブルＤの一例を説明する。ここではグループを管理するユーザを示す管理者と、該管理者が管理するアカウントグループとの対応関係が示されている。このグループの管理者は、管理対象のアカウントグループとともにグループ管理者データテーブルＤに登録される。

このグループ管理者データテーブルＤは、前記クラウド型監視システム９全体の管理者により更新される。例えばアカウントグループの管理者は、前記クラウド型監視システム９全体の管理者により任命され、グループ管理者データテーブルＤに登録されることにより、アカウントグループの管理権限が与えられる。

なお、グループ管理者データテーブルＤは、認証ＤＢ２０内に構築されているものとする。以下、図１７に基づき管理者Ｇが、操作員Ａ−１にＢ町のアカウントＢをサブアカウントとして設定する手順（ステップ）を説明する。

Ｓ４１〜Ｓ４６:管理者Ｇが、端末４の操作により管理者ログインページ（例えばhttps://cloudservice.jp/login/administrator）を指定して認証部１８にアクセスすることにより処理が開始される。

ここでは認証部１８は、管理者Ｇの端末操作により入力されたアカウント名（メインアカウントの名称）・ユーザ名・パスワードを受け付ける（Ｓ４１）。この受け付け後に認証部１８は、認証ＤＢ２０を参照して予め登録されたアカウント名・ユーザ名・パスワードと照合し、管理者Ｇの認証を開始する（Ｓ４２）。この照合の結果、入力されたアカウント名（メインアカウントＡの名称）・ユーザ名・パスワードと、登録されたアカウント名・ユーザ名・パスワードとが一致すれば認証が成功する。

この認証後に管理者Ｇの管理対象、即ちアカウントグループＧａｂの特定を実行する。具体的には管理者Ｇのユーザ名をキーにグループ管理者データテーブルＤを検索し、レコード「Ｎｏ．１０８」から管理対象のアカウントグループＧａｂを特定する（Ｓ４３）。

ここで特定された管理対象のアカウントグループＧａｂからグループ管理用の認証トークンＫが認証部１８に発行される（Ｓ４４）。この認証トークンＫには、認証ＤＢ２０の認証データのうちアカウントグループＧａｂに集約されるユーザデータグループＵの更新権限が示されている。

このユーザデータグループＵには、Ａ市のアカウントＡ，Ｂ町のアカウントＢ，Ａ市のアカウントＡを持つユーザ（操作員Ａ−１〜Ａ−ｎ），Ｂ町のアカウントＢを持つユーザ（操作員Ｂ−１〜Ｂ−ｎ）のデータが含まれる。ここでは認証トークンＫにより、ユーザデータグループＵに対して、新規ユーザ追加、ユーザ削除、既存ユーザへのサブアカウントの追加・削除が許可される。

そして、認証部１８は管理者Ｇの管理対象、即ちアカウントグループＧａｂのユーザ管理画面のアドレス（例えばhttps://cloudservice.jp/accountGroupGab）と併せて認証トークンＫを管理者Ｇの端末４に通知する（Ｓ４５）。なお、Ｓ４２の照合時に一致しなければ認証不成功として処理を終了し、またＳ４３の検索時にキーに該当する結果が得られなければ管理対象無しとして処理を終了する。

Ｓ４６：管理者Ｇは、端末４を操作することにより前記アドレス（例えばhttps://cloudservice.jp/accountGroupGab）を指定し、認証部１８にユーザ管理画面の表示を依頼する。その際、端末４が認証部１８にグループ管理用の認証トークンＫを渡すことにより、認証部１８はユーザ管理画面の表示依頼を受け付ける。

Ｓ４７，Ｓ４８：認証部１８は、受け取った認証トークンＫを認証ＤＢ２０に送り、グループ管理者データテーブルＤへのアクセス許可を求める（Ｓ４７）。このとき認証トークンＫにはユーザデータグループＵへのアクセス許可が示されているため、同アクセスは許可される（Ｓ４８）。

Ｓ４９〜Ｓ５１：認証部１８は、アカウントグループＧａｂのユーザ管理画面の編集に必要なデータを取得するため、ユーザデータグループＵにアクセスする（Ｓ４９）。

これによりユーザデータグループＵからユーザ一覧（Ａ市のアカウントＡを持つ操作員Ａ−１〜Ａ−ｎ，Ｂ町のアカウントＢを持つ操作員Ｂ−１〜Ｂ−ｎ）と、各ユーザの属性（ユーザ名，メインアカウント，サブアカウント）を取得する（Ｓ５０）。取得したデータに基づきアカウントグループＧａｂのユーザ管理画面、即ち図１８の画面を編集して管理者Ｇの端末４に送信する（Ｓ５１）。

Ｓ５２〜Ｓ５４：端末４に図１８の画面を表示させて操作員Ａ−１にサブアカウントを設定する（Ｓ５２）。ここで図１８中の太枠Ｐ２は、管理者Ｇが図１８の画面のユーザ一覧Ｐ１から操作員Ａ−１の行を選択した状態を示している。

このとき図１８中の画面の右欄Ｑに操作員Ａ−１の属性を示す各欄、即ちユーザ名の欄・メインアカウントの欄・サブアカウントの欄が表示され、管理者Ｇはサブアカウントの欄に選択候補リストを表示させるものとする。

この選択候補リストには、アカウントグループＧａｂのアカウント（Ａ市，Ｂ町）のうち、操作員Ａ−１のメインアカウントＡを除いたアカウントが表示される。この場合にはＢ町のアカウントＢが選択候補として表示され、図１９に示すように、管理者ＧはＢ町のアカウントＢをサブアカウントとして指定する。

この指定後に図１８中の「更新」Ｂ３をクリックすれば、指定された内容が認証部１８に送信される。なお、図１８中の「追加」Ｂ１は操作員（ユーザ）を追加設定するボタンを示し、同「削除」Ｂ２は操作員（ユーザ）の設定を削除するボタンを示し、同「キャンセル」は指定をキャンセルするボタンを示している。

そして、認証部１８は、前記サブアカウントの指定を受け付ければ、認証ＤＢ２０にユーザデータグループＵの更新を依頼する（Ｓ５３）。この更新依頼によりユーザデータグループＵが更新され（Ｓ５４）、操作員Ａ−１にＢ町のアカウントＢがサブアカウントとして設定される。

これにより認証部１８は、Ｓ５３，Ｓ５４で更新された内容を取得してユーザ管理画面を編集する（Ｓ５５）。ここで編集されたユーザ管理画面が端末４に表示されるため（Ｓ５６）、操作員Ａ−１について更新後の内容、即ちサブアカウントの欄にＢ町のアカウントＢが表示される。

このように実施例３の前記クラウド型監視システム９によれば、実施例１，２の効果に加えて、次の効果も得ることができる。

（１）実施例３では、アカウントグループにより複数のアカウントをグルーピングし、該アカウントグループの管理者を割り当てている。この管理者はアカウントグループ毎に設定されるため、特定の管理者にシステム全体の管理業務が集中することが防止できる。

また、前記クラウド型監視システム９全体の管理者にとっても、アカウントグループ内の管理をアカウントグループの管理者に権限移譲しているため、管理に費やす負担が軽減されている。

（２）アカウントグループの管理者の権限は、アカウントグループに所属するユーザの管理に限定されている。したがって、錯誤などにより他のアカウントグループのデータを変更・削除・追加するおそれがない。

≪プログラムなど≫
本発明は、上記実施形態に限定されるものではなく、各請求項に記載された範囲内で変形して実施することができる。例えばＤＢサーバ２１は、必ずしも事業主のアカウント毎にＤＢ２１Ａ〜２１Ｃに物理的に分割されて構成されている必要は無く、事業主のアカウント毎に監視データが別個に記録されるデータベース構造でもよい。

また、本発明は、収集配信サーバ１０としてコンピュータを機能させるクラウド型監視システム用のプログラムとして構成することもできる。このプログラムによれば、コンピュータによりＳ０１〜Ｓ１０，Ｓ１１〜Ｓ１６，Ｓ２１〜Ｓ３６，Ｓ４１〜Ｓ５６の処理が実行される。このプログラムは、ネットワークを通じて配布することができ、また記録媒体に格納して配布することもできる。

３Ａ〜３Ｃ…遠方監視装置（監視装置）
４…端末
９…クラウド型監視システム
１０…収集配信サーバ（サーバ）
１１…データベースサーバ
１２…配信サーバ
１８…認証部
１９Ａ〜１９Ｃ…配信部
２０…認証ＤＢ
２１Ａ〜２１Ｃ…ＤＢ（データベース）

Claims (13)

1. 対象設備ごとに設置された遠方監視装置と、
   前記監視装置から監視データを収集・蓄積するサーバと、
   前記サーバから必要な監視データを取得する操作者の端末と、を備えた監視システムであって、
   前記サーバは、前記監視データを前記対象設備の事業主毎に記録するデータベースと、
   前記データベースに記録された前記各監視データを前記端末に事業主単位で配信する配信部と、
   を備えることを特徴とする監視システム。
2. 前記サーバは、前記データベースと前記配信部とを前記事業主のアカウント毎に備え、
   前記配信部は、前記アカウントの同じ前記データベースに記録された前記監視データを、予め前記アカウントの付与された前記操作者の前記端末に配信する
   ことを特徴とする請求項１記載の監視システム。
3. 前記サーバは、前記アカウントを記録した認証データベースと、
   前記端末が前記データベースにアクセスする際に前記認証データベースを参照して認証を与え、前記アカウントに応じた前記データベースへのアクセスを許可する認証部と、
   を備えることを特徴とする請求項２記載の監視システム。
4. 前記操作者にはメインとサブの前記アカウントがそれぞれ付与され、
   前記認証部において、前記メインのアカウントに対応する前記データベースへのアクセスが許可されれば、
   前記サブのアカウントに対応する前記データベースへのアクセスが許可されることを特徴とする請求項３記載の監視システム。
5. 前記サブのアカウントは、増加・減少が可能なことを特徴とする請求項４記載の監視システム。
6. 前記操作者に付与された前記各アカウントは、前記認証デーベースにおいてアカウントグループとして集約されている
   ことを特徴とする請求項４または５記載の監視システム。
7. 前記アカウントグループ毎に管理者が割り当てられ、
   前記管理者は、前記アカウントグループに属する前記操作者のアカウントの編集が可能なことを特徴とする請求項６記載の監視システム。
8. 対象設備ごとに設置された監視装置と、
   前記監視装置から監視データを収集・蓄積するサーバと、
   前記サーバから必要な監視データを取得する操作者の端末と、を備えたシステムの実行する監視方法であって、
   前記サーバのデータベースに前記監視データを前記対象設備の事業主毎に記録する記録ステップと、
   前記データベースに記録された前記各監視データを前記端末に事業主単位で配信する配信ステップと、
   を有することを特徴とする監視方法。
9. 前記記録ステップは、前記事業主のアカウント毎に設けられた複数のデータベースに前記監視データを前記アカウント毎に記録し、
   前記配信ステップは、前記アカウントの同じ前記データベースに記録された前記監視データを、予め前記アカウントの付与された前記操作者の前記端末に配信する
   ことを特徴とする請求項８記載の監視方法。
10. 前記サーバが、前記端末の前記データベースへのアクセスに対して前記認証データベースを参照して認証を与え、前記アカウントに応じた前記データベースへのアクセスを許可する認証ステップを、
    さらに有することを特徴とする請求項９記載の監視方法。
11. 前記認証ステップは、前記操作者にメインとサブの前記アカウントがそれぞれ付与されている場合において、
    前記メインのアカウントについてアクセスが許可されれば、前記サブのアカウントのアクセスが許可されることを特徴とする請求項１０記載の監視方法。
12. 前記サブのアカウントは、増加・減少が可能である一方、
    前記操作者に付与された前記各アカウントは、前記認証デーベースにおいてアカウントグループとして集約され、
    前記アカウントグループ毎に管理者が割り当てられ、
    前記管理者は、前記アカウントグループに属する前記操作者のアカウントの編集が可能なことを特徴とする請求項８〜１１のいずれか１項に記載の監視方法。
13. 請求項１〜７に記載された監視システムの前記サーバとして、コンピュータを機能させることを特徴とする監視システム用のプログラム。

Images