JP5975396B2 - 機器管理システム、それに用いられる管理装置および機器 - Google Patents

Description

本発明は、機器を管理する機能を持つ管理装置を備えた機器管理システム、それに用いられる管理装置および機器に関する。

従来から、複数の管理装置と、管理装置により管理される家電製品やコンピュータ等の機器（エージェント）とからなる機器管理システム（管理システム）が提案されている（たとえば特許文献１参照）。

ところで、この種の機器管理システムにおいては、異なるベンダの管理装置が用いられることがあり、このような場合に、異なるベンダの管理装置間でも通信可能となる相互接続用の標準プロトコルが用いられる。ただし、相互接続用の標準プロトコルはベンダ間で合意した約束事であるから、このような標準プロトコルを利用した通信からは最大公約数的なデータしか得られず、ベンダ独自のデータ形式や通信方式にまで完全に対応することはできない。

そこで、特許文献１では、第１の管理装置−機器間の通信プロトコルと、第２の管理装置−機器間の通信プロトコルとが異なっている場合でも、第１の管理装置−第２管理装置間で管理情報を送受信できるように、第１の管理装置が通信プロトコルの変換を行う。具体的には、第１の管理装置は、第２の管理装置との通信プロトコルを決定するように、試験用コマンドを第２の管理装置に送信し、第２の管理装置から正常な応答があればその通信プロトコルを使用することを決定する。このように、第１の管理装置は、第２の管理装置−機器間の通信プロトコルを割り出した後に、この通信プロトコルを自身の使用する通信プロトコルの形式に変換することで第２の管理装置と管理情報の送受信を行う。

特開平１１−２３４２７７号公報

ところで、近年では、機器にＷｅｂサーバとしての機能を付加することにより、Ｗｅｂブラウザ機能を有する汎用のコンピュータ等を管理装置として使用できるようにした機器管理システムが提供されている。しかし、特許文献１に記載の構成では、第１の管理装置は、異なる通信プロトコル間でコマンドや伝送方式などを変換するための変換形式を予め複数記憶し、且つこの変換形式に従って通信プロトコルの変換を行うプロトコル変換部を有している。すなわち、第１の管理装置にてプロトコル変換を行うためには、第１の管理装置に変換形式を記憶した記憶部やプロトコル変換部が必要であるから、Ｗｅｂブラウザ機能を有する汎用のコンピュータ等をそのまま第１の管理装置として使用することはできない。

また、管理装置ではなく機器でプロトコル変換を行わせることも考えられるが、そうすると、プロトコル変換の分だけ機器側の処理負荷が大きくなり、限られたリソースを持つ組み込み機器などでは対応できない可能性がある。

本発明は上記事由に鑑みて為されており、管理装置でプロトコル変換を行いながらも、汎用のコンピュータ等を管理装置として使用可能な機器管理システム、それに用いられる管理装置および機器を提供することを目的とする。

本発明の機器管理システムは、管理装置と、前記管理装置との間で第１のプロトコルで通信する第１の機器と、前記第１のプロトコルとは異なる第２のプロトコルで通信する第２の機器とを備え、前記第１の機器は、プロトコル変換用の関数群からなる変換モジュールと、前記変換モジュールを用いて前記第１のプロトコルと前記第２のプロトコルとの間でプロトコル変換を行うための変換情報を記憶した記憶部とを有し、前記管理装置は、前記第１の機器から前記変換モジュールおよび前記変換情報を取得する取得部と、前記第２の機器との通信時に、前記変換情報に従い前記変換モジュールを用いて、前記第１のプロトコルと前記第２のプロトコルとの間でプロトコル変換を行うように機能する処理部とを有し、前記変換モジュールを取得するためのスクリプトを含むファイルを前記第２の機器が保持しており、前記管理装置は、前記ファイルを前記第２の機器から読み込み、前記ファイル内の前記スクリプトに従って、前記取得部にて前記第１の機器から前記変換モジュールを取得することを特徴とする。

この機器管理システムにおいて、前記第１の機器および前記第２の機器は、Ｗｅｂページを提供するＷｅｂサーバとしての機能を有しており、前記管理装置は、前記第１の機器および前記第２の機器から提供されるＷｅｂページを表示するＷｅｂブラウザとしての機能を有することが望ましい。

この機器管理システムにおいて、前記第１の機器は、前記第２の機器と直接通信するための通信路を構築するトンネル機能を有し、前記管理装置は、前記トンネル機能にて構築される通信路を用いて、前記第１の機器を経由して前記第２の機器と通信するように構成されていることがより望ましい。
また、本発明の管理装置は、前記機器管理システムにおいて前記管理装置として用いられることを特徴とする。
また、本発明の機器は、前記機器管理システムにおいて前記第１の機器または前記第２の機器として用いられることを特徴とする。

本発明の構成によれば、第１の機器と第２の機器との一方は、変換モジュールと、変換情報を記憶した記憶部とを有し、管理装置は、変換モジュールおよび変換情報を取得する取得部と、処理部とを有し、処理部が、第２の機器との通信時にプロトコル変換を行うように機能する。したがって、本発明は、管理装置でプロトコル変換を行いながらも、汎用のコンピュータ等を管理装置として使用可能であるという利点がある。

実施形態１に係る機器管理システムを示すシステム構成図である。 実施形態１に係る機器管理システムの動作の説明図である。 実施形態１に係る機器管理システムの動作の説明図である。 実施形態１に係る機器管理システムの動作の説明図である。 実施形態１に係る機器管理システムの他の構成例の動作の説明図である。 実施形態１に係る機器管理システムの他の構成例の動作の説明図である。 実施形態２に係る機器管理システムの動作の説明図である。

（実施形態１）
本実施形態の機器管理システムは、図１に示すように、共通の伝送路３に接続された第１の管理装置１１と、第１の管理装置１１との間で第１のプロトコルで通信する第１の機器２１とを備えている。さらに、本実施形態では、機器管理システムは、第１のプロトコルとは異なる第２のプロトコルに対応した第２の機器２２と、第２の機器２２との間で第２のプロトコルで通信する第２の管理装置１２とを備えている。言い換えれば、第１の管理装置１１と第１のプロトコルで直接通信可能な機器が第１の機器２１であり、第１の管理装置１１と第１のプロトコルで通信することができない機器が第２の機器２２である。

以下、第１の管理装置１１のことを単に「管理装置１」ともいい、第１の機器２１と第２の機器２２とを特に区別しない場合には単に「機器２」という。なお、図１の例では、管理装置と機器２とは２台ずつ設けられているが、管理装置および機器２の台数をこの例に限定する趣旨ではない。

機器２は、被制御対象の端末４と接続されており、これらの端末４と共に、たとえばオフィスビルのような建物内の空間において種々のサブシステムを構築するサブシステムユニットである。つまり、各機器２にはそれぞれ複数台の端末４が接続されており、各機器２は、それら複数台の端末４を集中監視制御するサブシステムユニットを構築する。ここで、機器２は限られたリソースを持つ組み込み機器である。

より具体的には、機器２は、たとえば各種センサなどの監視端末、および照明機器や空調機器などの動作を制御する制御端末が端末４として接続されており、これらの端末４と共に照明制御システムや空調制御システムなどのサブシステムを構築する。したがって、各サブシステムにおいては、機器２が複数台の端末４を集中的に監視および制御することが可能である。

ここで、第１の機器２１および第２の機器２２は、Ｗｅｂページを提供するＷｅｂサーバとしての機能を有している。機器２は、サブシステム内の電力消費量や動作状況、センサ出力などの様々な情報を、Ｗｅｂページとして提供する。

なお、機器２は、それ自身がたとえば各種センサなどの監視端末、および照明機器や空調機器などの動作を制御する制御端末であってもよい。図１の例では、第２の機器２２にのみ端末４が接続されており、第１の機器２１には端末４は接続されていない。

管理装置１は、Ｗｅｂブラウザの機能が搭載された汎用のパーソナルコンピュータからなり、これにより、建物内の各所に散在する複数のサブシステムを上位レベルで連携、連動することで全体最適化が可能な通信ネットワークを構築する。管理装置１は、第１の機器２１および第２の機器２２から提供されるＷｅｂページをＷｅｂブラウザにより表示する。ここで、本実施形態の機器管理システムは、オープンプロトコルに準拠しており、管理装置１は、様々なベンダの機器２と通信可能に構成されている。つまり、管理装置１は、建物内の複数のサブシステムを相互に接続することで建物全体の監視と制御を可能とする。ただし、管理装置１は、Ｗｅｂブラウザの機能を有する汎用のコンピュータ等であればよいので、パーソナルコンピュータに限らない。

なお、管理装置１は、イーサネット（登録商標）に準拠した伝送路３により機器２と有線接続されていてもよいし、機器２との間で無線通信する構成であってもよい。また、管理装置１は、インターネットなどの公衆網を介して、機器２と通信する構成であってもよい。第２の管理装置１２も、基本的な構成は第１の管理装置１１と同様である。

ところで、相互接続用の標準プロトコルはベンダ間で合意した約束事であるから、このような標準プロトコルを利用した通信からは最大公約数的なデータしか得られず、ベンダ独自のデータ形式や通信方式にまで完全に対応することはできない。たとえば、機器２がサブシステム内の電力消費量を系統別に管理している場合でも、ベンダの異なる管理装置１は、標準プロトコルを利用した通信でサブシステム全体の電力消費量を表示することはできても、系統別の電力消費量までは表示できないことがある。

そこで、本実施形態では、管理装置１は、プロトコル変換を行って異なるプロトコルの機器２とも通信を行うことによって、ベンダ独自のデータ形式や通信方式にまで対応するように構成されている。以下では、第１の機器２１から収集した電力消費量をグラフ化して表示する機能を有する管理装置１が、本来、この機能に対応していない第２の機器２２から収集した電力消費量についてもグラフ化して表示する場合を例として説明する。つまり、以下に例示する管理装置１は、第２の機器２２から収集した電力消費量についても、第１の機器２１から収集した電力消費量と同じように扱うことができ、両方の電力消費量を１つのグラフ内に並べて表示する。

具体的には、図１に示すように、第１の機器２１は、プロトコル変換用の関数群からなる変換モジュール２１１と、変換モジュールを用いて第１のプロトコル−第２のプロトコル間でプロトコル変換を行うための変換情報を記憶した記憶部２１２とを有している。また、管理装置１は、ＣＰＵ（Central Processing Unit）を主構成とする処理部１１１と、第１の機器２１から変換モジュール２１１および変換情報を取得する取得部１１２とを有している。

変換モジュール２１１は、少なくとも第１のプロトコル−第２のプロトコル間でのプロトコル変換に必要な関数群からなり、第１の機器２１に予め設定されている。

記憶部２１２は、通信先となる第２の機器２２のアドレスおよび第２の機器２２との通信方式が定められた情報を変換情報として予め記憶している。ここでいう変換情報は、通信先の識別情報（たとえばＩＰアドレスや品番）とデータ変換方法とを対にした情報である。データ変換方法とは、第２の機器２２が持つ情報（電力消費量など）を、その表現（独自プロトコルの電文、ＣＳＶファイル、ＨＴＭＬ（Hyper Text Markup Language）中の文字列）を解釈して抽出し、第１のプロトコルに変換する方法を意味している。本実施形態では、変換情報は少なくとも第１のプロトコル−第２のプロトコル間でのプロトコル変換の手順および必要なパラメータを含むプログラムである。

ここで、記憶部２１２は、通信先として複数種類の機器２に対応できるように、それぞれ異なる種類の第２のプロトコルに対応した複数の変換情報を記憶していてもよい。この場合、いずれの変換情報を使用するかは、管理装置１の操作によりユーザが任意に選択すればよい。また、第１の機器２１が、ソフトウェアのアップデートなどに対応した機器であれば、記憶部２１２に記憶されている変換情報は、第１の機器２１のソフトウェアのアップデートに併せて更新されてもよい。

処理部１１１は、第２の機器２２との通信時に、変換情報に従い変換モジュール２１１を用いて、第１のプロトコル−第２のプロトコル間でプロトコル変換を行うように機能する。つまり、管理装置１は、第１の機器２１から取得部１１２にて変換モジュール２１１および変換情報を取得し、この変換情報を処理部１１１にて実行することにより、処理部１１１が変換モジュール２１１を用いてプロトコル変換の処理を実施する。

さらに、本実施形態では、第２の機器２２は、第１の機器２１のＨＴＭＬファイルである「ｐｒｏｘｙ．ｈｔｍｌ」を保持している。このＨＴＭＬファイルには、変換モジュール２１１を取得部１１２に取得させるためのスクリプトが含まれている。

また、管理装置１は、Ｗｅｂブラウザの標準の機能として、メインのＷｅｂページである親ページ（メインページ）内に、任意のサイズのインラインフレーム（ｉｆｒａｍｅ）を表示する機能を有している。親ページ内の処理とインラインフレーム内の処理とは互いに独立しており、以下では、管理装置１の処理部１１１のうち、親ページ１０内の処理を担う部分を基本処理部とし、インラインフレーム内の処理を担う部分を応用処理部とする。

次に、本実施形態の機器管理システムの動作について図２〜４を参照して説明する。なお、図２では第２の管理装置１２の図示を省略しており、「１０」が管理装置１の親ページ、「１０１」がインラインフレームを表している。

まず、管理装置１は、Ｗｅｂブラウザにより親ページ１０上で第１の機器２１の監視画面にログインする。それから、管理装置１は、取得部１１２にて第１の機器２１から変換情報を取得する（図２のＳ１）。このとき、第１の機器２１は、記憶部２１２内の変換情報をＨＴＭＬ形式にして管理装置１に送信する。管理装置１は、変換情報を受信すると、この変換情報に従って図３に示す処理を実行する。

すなわち、管理装置１は、図３に示すように第１の機器２１との通信時には（Ｓ１１：Ｙｅｓ）、第１のプロトコルでＨＴＴＰ（Hyper Text Transfer Protocol）リクエストを行い、第１の機器２１からの応答を待つ（Ｓ１２）。第１の機器２１から電力消費量の応答があれば、管理装置１は、その内容に従って第１の機器２１の電力消費量をグラフ化した第１の機器２１の監視画面を生成し、画面表示を更新して第１の機器２１の電力消費量を親ページ１０にグラフ表示する（Ｓ１３）。

一方、第２の機器２２との通信時には（Ｓ１１：Ｎｏ）、管理装置１は、親ページ１０中にサイズ０（ゼロ）のインラインフレーム１０１を生成する（Ｓ１４）。なお、図２ではインラインフレーム１０１内の処理を明確にするためにある程度の大きさを持つインラインフレーム１０１を図示しているが、実際にサイズ０のインラインフレーム１０１は管理装置１の画面上には表示されない。ただし、応用処理部は、親ページ１０のバックグラウンドで、基本処理部とは別にインラインフレーム１０１内の処理を継続することになる。

そして、管理装置１は、応用処理部にて第２の機器２２からＨＴＭＬファイル（ｐｒｏｘｙ．ｈｔｍｌ）を読み込み（図２のＳ２）、リクエストに必要な情報をこのＨＴＭＬファイルに送信し、インラインフレーム１０１からの応答を待つ（Ｓ１５）。

インラインフレーム１０１内での処理Ｓ１５について詳しく述べると、管理装置１は、まずＨＴＭＬファイル内に埋め込まれているスクリプトタグに従って、第１の機器２１から変換モジュール２１１をインラインフレーム１０１内に読み込む（図２のＳ３）。これにより、管理装置１は、変換モジュール（ｔｒａｎｓｆｏｒｍ．ｊｓ）２１１に定義されている処理をインラインフレーム１０１内で応用処理部にて実行する。図４は、変換モジュール２１１に定義されている処理を表している。

すなわち、管理装置１は、応用処理部にて変換モジュール２１１を読み込むと、第１の機器２１の監視画面（親ページ１０）からのリクエストを待つ（図４のＳ１５１）。リクエストがあると（Ｓ１５１：Ｙｅｓ）、管理装置１は、応用処理部から第２の機器２２に対して第２のプロトコルでのＨＴＴＰリクエストを行い、第２の機器２２からの応答を待つ（Ｓ１５２）。ここで、リクエスト元になるＨＴＭＬファイルは第２の機器２２に配置されたファイルであるから、管理装置１は第２の機器２２に対して自由にＨＴＴＰリクエストを行うことができる。

第２の機器２２から電力消費量の応答があれば、管理装置１は、インラインフレーム１０１内で応用処理部にて応答の電文（第２のプロトコル）を第１のプロトコルに変換する（Ｓ１５３）。管理装置１は、第１のプロトコル形式に変換された第２の機器２２からの応答を、親ページ１０を表示している基本処理部に出力する（Ｓ１５４）。これにより、管理装置１は、画面表示を更新することにより、基本処理部にて第１の機器２１と第２の機器２２との両方の電力消費量を親ページ１０に並べてグラフ表示することができる（図３のＳ１３）。

なお、管理装置１は、第１の機器２１に配置されている変換モジュール２１１の全部を第１の機器２１から読み込んでもよいし、一部のみを第１の機器２１から読み込んでもよい。一部のみを読み込む場合、管理装置１は、第１のプロトコル−第２のプロトコル間でのプロトコル変換に必要な分の変換モジュール２１１を変換情報から判断し、その分の変換モジュール２１１を選択的に読み込む。

ここにおいて、上述したように親ページ１０からインラインフレーム１０１へのリクエスト送信時（Ｓ１５１）や、インラインフレーム１０１から親ページ１０への第２の機器２２の応答の出力時（Ｓ１５４）には、異なるページ間でのデータの授受が必要になる。言い換えれば、基本処理部と応用処理部とが異なるドメインと通信している際に、基本処理部と応用処理部との間でデータを授受する必要がある。そのためには、Ｗｅｂブラウザにおけるクロスドメイン通信の技術が前提となるので、この点について簡単に説明する。

すなわち、一般的に、Ｗｅｂブラウザは、異なるドメイン（プロトコル、ホスト、ポートのいずれかが自ホストと異なる通信相手）に対して、ＪａｖａＳｃｒｉｐｔ（登録商標）による通信ができない制約がある。そのため、本実施形態では、この制約を回避して異なるドメインと通信する方法が必要であるので、一例としてｗｉｎｄｏｗ．ｎａｍｅ方式とＰｏｓｔＭｅｓｓａｇｅ方式とのいずれかを採用する。ＰｏｓｔＭｅｓｓａｇｅ方式に対応したＷｅｂブラウザではＰｏｓｔＭｅｓｓａｇｅ方式を使い、対応していないＷｅｂブラウザではｗｉｎｄｏｗ．ｎａｍｅ方式を使う。

以下に、ｗｉｎｄｏｗ．ｎａｍｅ方式の動作を、管理装置１がホストＡの機器のＷｅｂページからホストＢの機器のデータを取得して処理する場合を例に説明する。この場合、管理装置１は、ホストＡのＷｅｂページにサイズ０（ゼロ）のインラインフレーム（ｉｆｒａｍｅ）を生成し、インラインフレームの「ｗｉｎｄｏｗ．ｎａｍｅ」にホストＢへのリクエスト用のパラメータを設定する。それから、管理装置１は、インラインフレームの「ｈｒｅｆ」を設定する。これにより、インラインフレームにホストＢの「ｐｒｏｘｙ．ｈｔｍｌ」が読み込まれる。「ｈｒｅｆ」に設定するＵＲＬのハッシュタグには、ホストＢの応答取得後に遷移するホストＡ上のＵＲＬ（「ｒｅｔｕｒｎ＿ＵＲＬ」）を記載する。「ｒｅｔｕｒｎ＿ＵＲＬ」は、ホストＡ上のＵＲＬであればよく、画像ファイルのＵＲＬなどでもよい。

それ以降、管理装置１は、インラインフレームの「ｈｒｅｆ」が「ｒｅｔｕｒｎ＿ＵＲＬ」になるまで、定期的にポーリングして確認する。インラインフレームの「ｈｒｅｆ」が「ｒｅｔｕｒｎ＿ＵＲＬ」になれば、管理装置１は、「ｗｉｎｄｏｗ．ｎａｍｅ」に設定されたホストＢからの応答を取得する。

一方で、管理装置１は、ホストＢのページ（「ｐｒｏｘｙ．ｈｔｍｌ」）での処理として、まず「ｗｉｎｄｏｗ．ｎａｍｅ」からホストＢへのリクエストに必要なパラメータを取得する。それから、管理装置１は、ホストＢにＨＴＴＰリクエストを行い、ホストＢからの応答を取得し、その応答を「ｗｉｎｄｏｗ．ｎａｍｅ」に設定する。そして、管理装置１は、自ページ（インラインフレーム）の「ｈｒｅｆ」を「ｒｅｔｕｒｎ＿ＵＲＬ」に変更する（ページ遷移）。

なお、クロスドメイン通信を可能とする技術としては、上記の例に限らず、たとえばＷｅｂブラウザの設定変更によりクロスドメイン通信を許可する方法などもある。また、最初からクロスドメイン通信可能な環境では、ＨＴＭＬファイル（ｐｒｏｘｙ．ｈｔｍｌ）が第２の機器２２でなく第１の機器２１に配置されていたとしても、管理装置１は、このＨＴＭＬファイルから第２の機器２２のデータにアクセスできる。

以上説明した本実施形態の機器管理システムによれば、管理装置１は、第２の機器２２との通信時に、処理部１１１が、変換情報に従い変換モジュール２１１を用いて、第１のプロトコル−第２のプロトコル間でプロトコル変換を行うように構成されている。要するに、プロトコル変換は機器２ではなく管理装置１で行われるので、機器２がたとえば限られたリソースを持つ組み込み機器である場合にも、十分対応できるという利点がある。さらに、充実した開発環境（ＨＴＭＬ、ＪａｖａＳｃｒｉｐｔ（登録商標）等）やライブラリを活用できるので、各種の変換モジュール２１１は短期間、低コストで開発できる。

また、プロトコル変換に必要な変換モジュール２１１および変換情報を記憶した記憶部２１２は第１の機器２１が有しており、管理装置１は、第１の機器２１から変換モジュール２１１および変換情報を取得する取得部１１２を有している。したがって、管理装置１は、元々、プロトコル変換を行うための変換情報を記憶した記憶部や変換モジュールを有している必要はなく、第１の機器２１から取得した変換情報に従って変換モジュール２１１を用いてプロトコル変換を行う処理部１１１があればよい。すなわち、本実施形態の機器管理システムは、管理装置１にてプロトコル変換を行いながらも、Ｗｅｂブラウザ機能を有する汎用のコンピュータ等を管理装置１として使用することができる。

要するに、本実施形態に係る機器管理システムによれば、管理装置１でプロトコル変換を行いながらも、汎用のコンピュータ等を管理装置１として使用可能であるという利点がある。

また、本実施形態では、変換モジュール２１１および記憶部２１２を第１の機器２１が有しているので、管理装置１は、特別な処理を必要とすることなく、変換モジュール２１１および変換情報を取得することができる。

さらにまた、管理装置１は、第２の機器２２から取得したＨＴＭＬファイル（ｐｒｏｘｙ．ｈｔｍｌ）に従って、第１の機器２１から変換モジュール２１１を取得するので、変換モジュール２１１をインラインフレーム内で動作させることができる。つまり、第１の機器２１に対応したＨＴＭＬファイルが第２の機器２２に予め配置されていれば、管理装置１は、基本処理部とは別の応用処理部にて変換モジュール２１１を読み込んで変換モジュール２１１を動作させることができる。

したがって、管理装置１は、メインである第１の機器２１の監視画面（親ページ）においては、第２のプロトコルを意識することなく、第２の機器２２を第１の機器２１と同じように扱うことできる。しかも、変換モジュール２１１にバグがあった場合でも、管理装置１は、メインである第１の機器２１の監視画面の表示動作については継続することができる。なお、この構成に限らず、管理装置１は、変換モジュール２１１および変換情報を、親ページとインラインフレームとの少なくとも一方に読み込むことで、プロトコル変換を行うことが可能である。すなわち、管理装置１は、変換モジュール２１１および変換情報を、親ページとインラインフレームとの一方にまとめて読み込んでもよいし、親ページに変換モジュール２１１、インラインフレームに変換情報を読み込んでもよい。

ところで、本実施形態の他の構成例として、図５に示すように、第１の機器２１は、第２の機器２２と直接通信するための通信路を構築（トンネリング）するトンネル機能２１３を有していてもよい。この構成では、管理装置１は、トンネル機能２１３にて構築される通信路を用いて、第１の機器２１を経由して第２の機器２２と通信するように構成されている。そのため、第２の機器２２が管理装置１のＷｅｂブラウザではアクセスできないＨＴＴＰ通信以外のプロトコルを採用しているような場合でも、管理装置１は第２の機器２２からの応答を取得することができる。なお、図５では第２の管理装置１２の図示を省略しており、「１０」が管理装置１の親ページ、「１０１」がインラインフレームを表している。

具体的に説明すると、図５の構成では、管理装置１は、第１の機器２１から変換情報を取得し、この変換情報に従って第１の機器２１から変換モジュール２１１を取得する。このとき、管理装置１は、上述の例と同様に、変換モジュール２１１をインラインフレーム１０１内に読み込み、変換モジュール２１１の処理をインラインフレーム１０１内で応用処理部にて実行する。図６は、変換モジュール２１１の処理を表している。

すなわち、管理装置１は、変換モジュール２１１を読み込むと、トンネル機能２１３の形式に変換された第２の機器２２に対するリクエスト電文を作成する（図６のＳ２１）。そして、管理装置１は、作成されたリクエスト電文を、第１の機器２１のトンネル機能２１３に送信し、応答を待つ（Ｓ２２）。リクエスト電文は、第１の機器２１のトンネル機能２１３を経由して第２の機器２２に送信され、これに対する第２の機器２２からの応答も、第１の機器２１のトンネル機能２１３を経由して管理装置１に送信される。

管理装置１は、トンネル機能２１３から応答があれば、応用処理部にて応答の電文（第２のプロトコル）を第１のプロトコルに変換する（Ｓ２３）。管理装置１は、第１のプロトコル形式に変換された第２の機器２２からの応答を、第１の機器２１の監視画面（親ページ１０）を表示している基本処理部に出力する（Ｓ２４）。これにより、管理装置１は、画面表示を更新することにより、基本処理部にて第１の機器２１と第２の機器２２との両方の電力消費量を親ページ１０に並べてグラフ表示することができる。

なお、管理装置１−トンネル機能２１３間の通信プロトコル（第３のプロトコル）について簡単に説明する。一例として、基本フォーマットは「〔コマンド〕：〔ＩＰアドレス〕：〔ポート番号〕：〔電文〕」となる。ここで、〔コマンド〕、〔ＩＰアドレス〕、〔ポート番号〕はＡＳＣＩＩ文字列、〔電文〕は１６進数表記に変換後の文字列（ＡＳＣＩＩ文字列）である。使用されるコマンドとしては、指定されたＩＰアドレスのポート番号にＴＣＰで接続し、〔電文〕で指定された電文を第２の機器２２に送信する「ｓｅｎｄ」、第２の機器２２からの応答を管理装置１に返信する「ｒｅｃｅｉｖｅｄ」がある。「ｒｅｃｅｉｖｅｄ」コマンドにおいては、〔ＩＰアドレス〕、〔ポート番号〕は「ｓｅｎｄ」コマンドと同じ〔ＩＰアドレス〕、〔ポート番号〕が指定される。また、第２の機器２２からの応答は１６進数表記のＡＳＣＩＩ文字列に変換されている。

以上説明した図５の構成によれば、第２の機器２２で用いられる第２のプロトコルは電文がテキスト、転送プロトコルがＨＴＴＰに限定されることなく、たとえばバイナリ電文を扱い且つ転送プロトコルがＨＴＴＰ以外のプロトコルであっても対応できる。これにより、管理装置１は、ｍｏｄｂｕｓ／ＴＣＰ等のＨＴＴＰ以外のＩＰ通信であっても、第１の通信プロトコルとの間でプロトコル変換可能になる。

なお、上記実施形態においては、管理装置１は、第１の機器２１との通信処理と、第２の機器２２との通信処理とを互いに独立した処理とするために、インラインフレームを使用している。つまり、管理装置１は、第１の機器２１との通信処理を基本処理部にて親ページ内で行い、第２の機器２２との通信処理を応用処理部にてインラインフレーム内で行っている。ただし、管理装置１は、第１の機器２１との通信処理と、第２の機器２２との通信処理とを互いに独立して実行できればよく、インラインフレーム以外の方法を使用する構成であってもよい。

（実施形態２）
本実施形態の機器管理システムは、図７に示すように変換モジュール２２１および記憶部２２２を第２の機器２２が有している点で実施形態１の機器管理システムと相違する。また、本実施形態では、第２の機器２２は、後述する画面書換モジュール（ｒｅｗｒｉｔｅ．ｊｓ）２２３を有している。以下、実施形態１と同様の構成については共通の符号を付して適宜説明を省略する。

次に、本実施形態の機器管理システムの動作について図７を参照して説明する。なお、図７では第２の管理装置１２の図示を省略しており、「１０」が管理装置１の親ページ、「１０１」がインラインフレームを表している。

まず、管理装置１は、Ｗｅｂブラウザにより親ページ１０上で第１の機器２１の監視画面にログインする（図７のＳ３１）。それから、管理装置１の親ページ１０上で、ユーザがブックマークレットを実行する。ここで、ブックマークレットは、第２の機器２２から画面書換モジュール２２３を取得し（Ｓ３２）、画面書換モジュール２２３を動作させるように記述されたスクリプトである。

管理装置１は、画面書換モジュール２２３を実行することにより、親ページ１０中にインラインフレーム１０１を生成し、このインラインフレーム１０１に第２の機器２２の監視画面を読み込む。このとき、管理装置１は、取得部１１２にて第２の機器２２から変換情報を取得する（Ｓ３３）。そして、管理装置１は、インラインフレーム１０１のサイズを最大化し、さらに最前面に設定することで、インラインフレーム１０１にて第１の機器２１の監視画面（親ページ１０）を覆い隠す。

なお、図７では親ページ１０内の処理を明確にするために親ページ１０内の一部にインラインフレーム１０１を図示しているが、実際には親ページ１０はインラインフレーム１０１で覆われるため管理装置１の画面上には表示されない。ただし、基本処理部は、インラインフレーム１０１のバックグラウンドで、応用処理部とは別に親ページ１０内の処理を継続することになる。

さらに、管理装置１は、親ページ１０内にスクリプトタグを生成して変換モジュール２２１を読み込み（Ｓ３４）、変換モジュール２２１を親ページ１０に登録する。これにより、管理装置１は、変換モジュール（ｔｒａｎｓｆｏｒｍ．ｊｓ）２２１に定義されている処理を親ページ１０内で基本処理部にて実行する。変換モジュール２２１に定義されている処理は、実施形態１で図４を用いて説明した処理と基本的に同様である。

すなわち、管理装置１は、基本処理部にて変換モジュール２２１を読み込むと、第２の機器２２の監視画面（インラインフレーム１０１）からのリクエストを待つ。リクエストがあると、管理装置１は、基本処理部から第１の機器２１に対して第１のプロトコルでのＨＴＴＰリクエストを行い、第１の機器２１からの応答を待つ。

第１の機器２１から電力消費量の応答があれば、管理装置１は、親ページ１０内で基本処理部にて応答の電文（第１のプロトコル）を第２のプロトコルに変換する。管理装置１は、第２のプロトコル形式に変換された第１の機器２１からの応答を、インラインフレーム１０１を表示している応用処理部に出力する。これにより、管理装置１は、画面表示を更新することにより、応用処理部にて第１の機器２１と第２の機器２２との両方の電力消費量をインラインフレーム１０１に並べてグラフ表示することができる。

以上説明した本実施形態の機器管理システムによれば、第１の機器２１が独自の認証方式を採用しており、またその動作仕様が不明である場合や、他の機器（第２の機器２２）のＨＴＭＬファイルが第１の機器２１に設定されていない場合にも対応することができる。すなわち、これらの場合でも、管理装置１は、第１の機器２１だけでなくプロトコルの異なる第２の機器２２についても統合管理することができる。

その他の構成および機能は実施形態１と同様である。

１ 管理装置
１１１ 処理部
１１２ 取得部
２１ 第１の機器
２２ 第２の機器
２１１ 変換モジュール
２１２ 記憶部
２１３ トンネル機能
２２１ 変換モジュール
２２２ 記憶部

Claims (5)

1. 管理装置と、前記管理装置との間で第１のプロトコルで通信する第１の機器と、前記第１のプロトコルとは異なる第２のプロトコルで通信する第２の機器とを備え、
   前記第１の機器は、
   プロトコル変換用の関数群からなる変換モジュールと、
   前記変換モジュールを用いて前記第１のプロトコルと前記第２のプロトコルとの間でプロトコル変換を行うための変換情報を記憶した記憶部とを有し、
   前記管理装置は、
   前記第１の機器から前記変換モジュールおよび前記変換情報を取得する取得部と、
   前記第２の機器との通信時に、前記変換情報に従い前記変換モジュールを用いて、前記第１のプロトコルと前記第２のプロトコルとの間でプロトコル変換を行うように機能する処理部とを有し、
   前記変換モジュールを取得するためのスクリプトを含むファイルを前記第２の機器が保持しており、
   前記管理装置は、前記ファイルを前記第２の機器から読み込み、前記ファイル内の前記スクリプトに従って、前記取得部にて前記第１の機器から前記変換モジュールを取得する
   ことを特徴とする機器管理システム。
2. 前記第１の機器および前記第２の機器は、Ｗｅｂページを提供するＷｅｂサーバとしての機能を有しており、
   前記管理装置は、前記第１の機器および前記第２の機器から提供されるＷｅｂページを表示するＷｅｂブラウザとしての機能を有する
   ことを特徴とする請求項１に記載の機器管理システム。
3. 前記第１の機器は、前記第２の機器と直接通信するための通信路を構築するトンネル機能を有し、
   前記管理装置は、前記トンネル機能にて構築される通信路を用いて、前記第１の機器を経由して前記第２の機器と通信するように構成されている
   ことを特徴とする請求項１または２に記載の機器管理システム。
4. 請求項１〜３のいずれか１項に記載の機器管理システムにおいて前記管理装置として用いられる
   ことを特徴とする管理装置。
5. 請求項１〜３のいずれか１項に記載の機器管理システムにおいて前記第１の機器または前記第２の機器として用いられる
   ことを特徴とする機器。

Images