特許 7531818 数値データに対する識別子を用いた数値管理システム

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-08-02

(45)【発行日】2024-08-13

(54)【発明の名称】数値データに対する識別子を用いた数値管理システム

(51)【国際特許分類】

   G06F 16/28 20190101AFI20240805BHJP

【ＦＩ】

G06F16/28

【請求項の数】 9

(21)【出願番号】P 2023553149

(86)(22)【出願日】2023-03-16

(86)【国際出願番号】 JP2023010235

(87)【国際公開番号】W WO2023176916

(87)【国際公開日】2023-09-21

【審査請求日】2023-08-31

(31)【優先権主張番号】P 2022041086

(32)【優先日】2022-03-16

(33)【優先権主張国・地域又は機関】JP

【早期審査対象出願】

(73)【特許権者】

【識別番号】300023899

【氏名又は名称】株式会社ラプラス・システム

(74)【代理人】

【識別番号】110002295

【氏名又は名称】弁理士法人Ｍ＆Ｐａｒｔｎｅｒｓ

(72)【発明者】

【氏名】堀井 雅行

【審査官】早川 学

(56)【参考文献】

【文献】特開２００８－１４６１１９（ＪＰ，Ａ）

【文献】特開２０１７－１６７８８９（ＪＰ，Ａ）

【文献】特開２０１３－１５２５５７（ＪＰ，Ａ）

【文献】国際公開第２０２０／０６５９２５（ＷＯ，Ａ１）

【文献】特開２００８－２１７６１２（ＪＰ，Ａ）

【文献】特開２０１８－１５７７０８（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ １６／００－１６／９５８

(57)【特許請求の範囲】

【請求項1】

タイムスタンプと関連づけられた複数の数値列で構成された数値データが記録されたデータベースサーバー上に構築されるデータベースと、
前記データベースと物理的又は論理的に分離したＩＤ管理サーバーに記録されたデータ識別ＩＤであって、前記数値データを構成する数値の属性を一意に特定するデータ識別ＩＤと、ミドルウェアと、前記ミドルウェアを介して前記データベースに対して前記数値データを要求するアプリケーションと、
によって構成される一対の論理的なデータ構造を用いた数値管理システムであって、
前記データ識別ＩＤは、
前記数値データの単位を規定する少なくとも２バイトの文字列からなる単位ＩＤと、
前記数値データの種別を規定する少なくとも２バイトの種別ＩＤを定義した上で前記種別ＩＤを一意に特定するための少なくとも２バイトの整数値からなる項目番号と前記種別ＩＤとで構成される少なくとも４バイトの項目ＩＤと、
を含み、
前記単位ＩＤは、名称及び単位文字列と関連付けられており、
前記種別ＩＤは、少なくとも各種別ＩＤに対応する文字列と、前記単位ＩＤとを含み、
前記ミドルウェアを介して前記データ識別ＩＤを前記ＩＤ管理サーバーに送信すると共に前記タイムスタンプ及び前記タイムスタンプに対応する前記数値データを前記データベースサーバーに送信することにより前記データ構造が構築され、
前記数値データは、計測機器により取得された計測値データと前記計測値データに基づき計算された計算値データとを含むと共に、
前記数値データを構成する前記計測値データ及び前記計算値データにはいずれも前記データ識別ＩＤが付与され、
前記アプリケーションが前記ミドルウェアに前記データ識別ＩＤを付与して前記数値データを要求することにより、前記アプリケーションが前記ミドルウェアを介して前記データベースから前記数値データに含まれる前記計測値データ及び／又は前記計算値データを取得することを特徴とする、数値管理システム。

【請求項2】

前記ミドルウェアは、前記数値データを取得する計測端末内で実行されることを特徴とする、請求項１記載の数値管理システム。

【請求項3】

前記ミドルウェアは、前記計測端末とは物理的又は論理的に独立したミドルウェアサーバーにおいて実行されることを特徴とする、請求項２記載の数値管理システム。

【請求項4】

前記ミドルウェアがウェブサーバー上で実行され、ＷｅｂＡＰＩを利用して前記ウェブサーバーのＵＲＬに対してデータ識別ＩＤを含む付加情報を付与された読出要求を受け取ることにより、対象となる前記ウェブサーバーから必要な情報を返すことを特徴とする請求項１記載の数値管理システム。

【請求項5】

パワーコンディショナと前記パワーコンディショナに接続される機器とを含む発電システムに適用され、
前記データ識別ＩＤを用いることにより、
前記パワーコンディショナの通信プロトコルに依存することなく前記数値データの物理的意味を特定することを特徴とする、請求項１乃至請求項４のいずれか１項記載の数値管理システム。

【請求項6】

前記数値データは、複数の前記発電システムに設置された前記機器から取得した計測データを含むことを特徴とする請求項５記載の数値管理システム。

【請求項7】

前記数値列の１つは前記複数の発電システムのうち特に日射計を有する前記発電システムが取得した日射量を表すデータであり、前記データ識別ＩＤを用いて、前記発電システム外の発電システムにおける発電量の予測及び／又は前記発電システム外の発電システムの保守に前記日射量を表すデータを活用することを特徴とする請求項６記載の数値管理システム。

【請求項8】

前記アプリケーションを実行するアプリケーション・サーバーが、前記数値データに基づいて、前記発電システム内の機器の異常、故障又は経年劣化を検知する請求項７記載の数値管理システム。

【請求項9】

前記アプリケーションを実行するアプリケーション・サーバーが、前記複数の発電システム内で取得した前記数値データのうち特定のデータを要求しその合算値を取得する請求項７記載の数値管理システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、数値データに対する識別子を含むデータ構造及び当該データ構造を用いた数値管理システムに関する。

【背景技術】

【0002】

計測機器から取得された数値データなど、デジタル化されたあらゆる数値データは、データ表（計測の場合はチャンネル表とよぶ）を用いて数値データに意味づけが行われる。例えば、図５（Ａ）は、簡単なチャンネル表の一例である。この例では、チャンネル１が発電電力で単位はｋＷ、チャンネル２は温度で単位は℃、チャンネル３は日射強度であり単位はｋＷ／ｍ^２であることを示している。

【0003】

複数の経路で通信する場合とは異なり、１つの経路を用いて複数種類の数値データをデータ通信装置によって送受信する場合、受信側では、送られてくるデータの値だけでなく、順番にも重要な意味がある。プロトコル仕様書は、受信側において、何番目に受け取ったデータが何を意味するかを示すテーブルであり、送信元で事前に設定される。

【0004】

特許文献１には、センサー信号をエンコードする際に、測定の単位や制度や誤差等の情報をメッセージヘッダを付加してセンサーからのデータを転送する方法が開示されている。特許文献２には、太陽光発電システム用無線通信の制御方法に関して、送信機と受信器との間に送られる通信データの一部に太陽光発電システムの識別情報を付加することで、積算発電量データなどを認識する方法が開示されている。

【先行技術文献】

【特許文献】

【0005】

【文献】特開２０１１－５２０３０９号公報

【文献】特開２００６－２７７３８３号公報

【文献】特表２０１７－５３０６７１号公報

【発明の概要】

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

【0006】

デジタルデータに対するデータ表や通信データに対する通信プロトコルには、いずれも様々な種類が存在し、統一した規格は存在していないのが実情である。計測機器を例にとると、プロトコル仕様書に含まれるチャンネル表は計測機器ごとに異なっている。太陽光発電システムにおけるＰＣＳ（パワーコンディショナ）とＰＣＳに接続される制御端末間の通信プロトコルも、各社各型式ごとに異なっている。

【0007】

例えば、図５（Ｂ）は、あるＰＣＳのチャンネル表の例を示している。チャンネル表には、チャンネル毎にデータが意味する物理量の内容（例えば入力電圧、入力電流）、データサイズ（４バイト、６バイト）、データフォーマット（小数点の位置等）、データ範囲、備考などが示される。このようなチャンネル表にはさらに詳細な注釈が設けられている。例えば、符号はセットするが小数点はセットしないこと、ＰＣＳ停止時のデータＮｏ．４［出力電圧（Ｖ）］は系統電圧とする、ＰＣＳ自立運転時データＮｏ．４［出力電圧（Ｖ）］は自立出力電圧とする（自立運転機能タイプのみ）、といった注釈である。

【0008】

しかも、このようなチャンネル表に記載される仕様は頻繁に更新される。そのため、計測機器の設置現場でのトラブルを防止するため、プロトコル仕様書は、常にバージョン管理を行う必要がある。

【0009】

さらに、計測端末のチャンネル番号は、それぞれの計測端末内部でしか一意ではない。仮に、１つの発電システム内に複数の計測端末がある場合、チャンネル番号に重複が生じうる。すなわち、この問題は、ローカル内でのみ使用され、かつ仕様が頻繁に更新されるプロトコル仕様書を用いることによって引き起こされている問題であり、長年にわたり抜本的な対応がとられていなかった本質的な問題であるといえる。

【0010】

本発明は、上記に鑑みてなされたものであり、ローカル内でのみ使用可能であったプロトコル仕様書を、グローバルで一意に使用可能にすることで、ローカル側にプロトコル仕様書がなくても、数値と数値データの意味をグローバルに特定することを可能にする、新規なデータ構造を提供することを目的とする。

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

【0011】

本発明に係るデータ構造は、
タイムスタンプと関連づけられた複数の数値を含む数値データが記録されたデータベースサーバー上に構築される論理的なデータベースと、
前記数値データを構成する数値の属性を一意に特定するデータ識別ＩＤと、
によって構成される一対の論理的なデータ構造であって、
前記データ識別ＩＤは、
前記数値データの単位を規定する少なくとも２バイトの文字列からなる単位ＩＤと、
前記数値データの種別を規定する少なくとも２バイトの種別ＩＤを定義した上で前記種別ＩＤを一意に特定するための少なくとも２バイトの整数値からなる項目番号と前記種別ＩＤとで構成される少なくとも４バイトの項目ＩＤと、
を含み、
前記単位ＩＤは、名称及び単位文字列と関連付けられており、
前記種別ＩＤは、少なくとも各種別ＩＤに対応する文字列と、前記単位ＩＤとを含むことを特徴とする。

【0012】

上記構成において、前記単位ＩＤは、単位の前につく接頭語がさらに関連付けられていてもよい。

【0013】

上記構成において、前記データ識別ＩＤは、
前記データベースと物理的又は論理的に分離したＩＤ管理サーバーに記録されていると共に、
更新されたタイムスタンプと関連づけられた複数の数値の新規登録又は前記データベースに記録されている任意の数値の読み出しは、ミドルウェアを介して実施されることにより、
前記データ識別ＩＤと、前記データ識別ＩＤと関連付けられた前記複数の数値データに含まれるそれぞれの数値とが、常に一対のデータとして取り扱われるように構成されていてもよい。

【0014】

上記構成において、前記ミドルウェアは、前記数値データを取得する計測端末内で実行されてもよい。

【0015】

上記構成において、前記ミドルウェアは、前記計測端末とは物理的又は論理的に独立したミドルウェアサーバーにおいて実行されてもよい。
ここで、「ミドルウェアサーバー」とは、プログラムであるデータアクセスミドルウェア（以下、「ミドルウェア」という場合がある。）を実装するための他のサーバーとは物理的又は論理的に独立した構成のサーバーである。

【0016】

本発明に係る数値管理システムは、少なくとも、
前記ＩＤ管理サーバーと、前記データベースサーバーと、前記ＩＤ管理サーバーと前記データベースサーバーとの間に介在する前記ミドルウェアと、を含む、請求項３乃至５のいずれか１項記載のデータ構造を用いたことを特徴とする。

【0017】

上記構成において、前記ミドルウェアは、前記データベースに対する要求と返答を代理するように構成してもよい。

【発明の効果】

【0018】

本発明によれば、データの意味づけをするためのデータ表やプロトコル仕様書をローカル側で準備する必要がなくなることで、プロトコルのバージョン管理から解放され、現場での混乱がなくなるほか、データの一層活用を促すことに貢献する。

【図面の簡単な説明】

【0019】

【図1】図１は、第１の実施形態の発電システムの構成例を示す図である。

【図2】図２は、物理単位ＩＤの一覧を例示する表である。

【図3】図３は、物理種別ＩＤの一覧を例示する表である。

【図4】図４は、項目ＩＤのフォーマットを示している。

【図5】（Ａ）簡単なチャンネル表の一例である。（Ｂ）あるＰＣＳのチャンネル表の例を示している。

【図6】（Ａ）データアクセスミドルウェア１０２を配置せず、ユーザーが複数の遠隔監視サイト１～３を介して計測データサーバ４に直接アクセスする場合の構成図、（Ｂ）データアクセスミドルウェアを介して計測データサーバ４にアクセスする場合の構成図である。

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

【0020】

本発明の基本的な考え方は、同一のシステム内で扱われるあらゆるデータ（数値）或いはその数値に対して付随する単位等を一意に特定するための識別子（これを、本明細書では「データ識別ＩＤ」と定義する。）を割り当てたテーブル（データベース）を、計測データベースとは別に用意し、それによりデータ等を一元的に管理するというものである。以下、データ識別ＩＤの詳細については各実施形態を通じて説明する。なお、物理量を表す数値は、それぞれの物理量の単位を伴うが、さらにｍ（ミリ）、μ（マイクロ）、ｐ（ピコ）などの小数、ｋ（キロ）、Ｍ（メガ）といった大数の単位接頭語を伴う。これらについても一意に特定される必要があるため、数値データの一種として扱い、本明細書では「データ等」という。

【0021】

（第１の実施形態）－物理量に適用されるデータ識別ＩＤ－

【0022】

第１の実施形態では、主に計測機器を通じて取得され、デジタル通信によってやりとりされる物理量に適用されるデータ識別ＩＤ（物理量データ識別ＩＤ）について説明する。

【0023】

［データ識別ＩＤ］
ここで、データ識別ＩＤについてより詳細に説明する。
例えば、物理量についてのデータ識別ＩＤ（以下、「物理量データ識別ＩＤ」という。）は、ａ．物理単位ＩＤとｂ．物理種別ＩＤとで構成され、その両者を全てのソフトウェアがファイルとして持ち、必要に応じて参照する。物理単位ＩＤと物理種別ＩＤの一覧表はサーバー上に保存し、インターネット等の電気通信回線を通じていつでも参照したりダウンロードできるようにしておくことが好ましい。

【0024】

ａ．物理単位ＩＤ
図２は、物理単位ＩＤの一覧を例示する表である。物理単位ＩＤとは、物理単位を規定する値であり、全てのソフトウェアで共通である。項目として、ＩＤ、名称、単位文字列を持つ。同じ単位でも単位接頭語（ｍ，ｋ，Ｇ，Ｍ 等）毎に物理単位ＩＤを持つ。例えば、電力を表す場合、２００Ｗなのか２００ｋＷなのか、単位だけでなく接頭語も重要となる。物理単位ＩＤの種類はそれほど多くないため、例えば２バイト（６５５３６通り）で十分に表現可能である。

【0025】

ｂ．物理種別ＩＤ
物理種別ＩＤとは、日射量、気温、直流電力、パワーコンディショナ（ＰＣＳ）出力電力などデータの物理的或いは役割的な種別を識別するための値であり、あらゆる物理量に対して物理種別ＩＤを割り当てる。更に、指標、効率などの計算値も同様である。物理種別ＩＤも２バイトで表現する。

【0026】

図３は、物理種別ＩＤの一覧を例示する表である。太陽光発電という大分類に対して、太陽光発電システムにおいて扱うであろう物理量に対して物理種別ＩＤを付与する。各物理種別ＩＤには、項目名称とＴＡＧ名を割り当てる。

【0027】

物理種別ＩＤには、名称・ＴＡＧ名・変数名・単位ＩＤ、（単位文字列）、等を紐付け、物理種別ＩＤ（ＩＤ）は整数値、物理種別名称（ｎａｍｅ）は文字列と定義する。

【0028】

図３には分類・項目名称・ＩＤ・ＴＡＧ名のみ記載されているが、単位ＩＤは物理種別ＩＤごとに、セットされる。例えば直流電圧であれば「Ｖ」が割り当てられ、その「Ｖ」に対して単位ＩＤが割り当てられる。

【0029】

＜物理種別ＩＤのクラス定義例＞
class Tphysic ID {
int ID; //物理種別ＩＤ
string name; //物理種別名称
int unit_ID //物理単位ＩＤ
string unit_name //単位名称
void set() //物理単位ＩＤより、物理種別名称、単位ＩＤ、単位名称をセットする。
};

【0030】

図３に示すとおり、例えば、太陽光発電システムにおける直流電圧に対してＩＤ＝２０００とＴＡＧ名：ＰＶ＿ＤＣ＿Ｖを付与する。同様に、直流電流に対してＩＤ＝２００１とＴＡＧ名：ＰＶ＿ＤＣ＿１を付与する。このように、予め決められた物理種別ＩＤによってあらゆる物理種別を定義することを可能にする。

ＩＤ＝２０００ ＴＡＧ名：ＰＶ＿ＤＣ＿Ｖ （意味：太陽光発電の直流電圧）
ＩＤ＝２００１ ＴＡＧ名：ＰＶ＿ＤＣ＿１ （意味：太陽光発電の直流電流）

【0031】

なお、１つの計測拠点（サイト）において複数系統の計測機器が存在する場合など、一意の物理種別ＩＤが複数系統存在する場合を考慮し、２バイトの物理種別ＩＤに１からはじまる２バイトの自然数を「項目番号」として付加することで「項目ＩＤ」を定義する。例えば、複数系統があり、それぞれにＰＣＳが複数台つながっていたとしても、系統毎に１から割り振るのではなく、全体で番号を割り振る。その他、日射計やモジュール温度など、同じ物理種別ＩＤが割り当てあられた複数の物理種別ＩＤが存在する場合、項目ＩＤによって区別できるようにする。

【0032】

＜クラス設計例＞
クラスとはプログラムにおけるオブジェクトであり、先ずそれらを全体的に統括する「計算式全体のクラス」を定義した上で、この計算式全体のクラスのもとで、さらに計算方法の違いによって「各計算式のクラス」を定義する。こうすることで、チャンネルと同様に、「計算式全体のクラス」と、「各計算式のクラス」とに分ける。

【0033】

計算式とは、計測データ（生データ）に対する演算処理のための計算式を意味する。この計算式によるデータを計算式データと定義して、計測データとは区別されて取り扱う。

【0034】

class Tkeisanki {
int siki_su;
vevtor<Tsiki> siki;
void<Tsiki> siki;
void addEmptyVectorSiki (int siki_su);
};

class Tsiki {
Tkomoku_ID komoku_ID; //項目ＩＤクラス

【0035】

計測データだけでなく、それを元に特定の計算式を使って計算されたデータついても識別ＩＤの概念を適用する。

【0036】

ｃ．項目ＩＤ
項目ＩＤとは、物理種別ＩＤと、それが複数ある場合の項目番号を合体させた値と定義する。項目ＩＤは、１つのサイトのデータ群（計測チャンネル、計算式、入力式等）において決して重複せず一意の値として特定できるものとする。

【0037】

図４は、項目ＩＤのフォーマットを示している。この図のように、項目ＩＤは、項目番号（２バイト）＋物理種別ＩＤ（２バイト）を結合させた形式とする。

【0038】

項目番号は１からはじまる整数値の連番とする。同じ物理種別ＩＤが複数ない場合でも１とする。一つのサイトにおいて、番号が重複することはない。例えば、複数系統があり、それぞれにＰＣＳが複数つながっていたとしても、系統毎に１から割り振るのではなく、全体で番号を割り振る。更に、計測端末が複数あり、複数の計測システムがあったとしても、同様に番号が重複しないように割り振る。その他、複数の日射計、複数のモジュール温度など、物理種別ＩＤが同じものが複数ある場合に用いる。
※ 項目ＩＤを下記のように全てクラスで処理することも考えられるが、一応定義しておく。

【0039】

ｄ．統合データ処理（データアクセスミドルウェア）クラス
データへのアクセスを統合的に行うクラス。計測データだけでなく他の種類のデータ（例えば、計算式データ、入力データ、診断データ、統計データ等）も汎用的に処理できるものとする。計測データ及び３．４．１で示す各種データにアクセスする場合、必ず本クラスを用いる。データファイルへの直接アクセスはもちろん、チャンネルクラス内のｄａｔａ変数なども直接参照しない。
＜データの種類＞
（１）計測データ
（２）計算式データ
（３）入力データ
（４）診断データ
（５）統計データ
それぞれのデータ種別において、データの番号と項目ＩＤが設定されているものとする。

【0040】

各アプリケーション・サーバー５上で実行されるアプリケーションが直接データベースにアクセスするのではなく、本ミドルウェアで共通化されたインターフェースを介してアクセスできるようにすることにより、データの破壊や不正アクセスを防ぐことができるだけでなく、全てのアプリケーションが共通の方法でデータにアクセスできることになる。

【0041】

＜クラス設計＞
・データ取得関数は、従来Ｔｃｈａｎｎｅｌの中にあったが、これを外部に出し、新たなクラスとして独立させる。
・様々なパラメータでデータを取得できるようにした。
・項目ＩＤのみで、全データ種別のデータを意識せず取得できる。
・時刻を指定しなかった場合、Ｔｃｈａｎｎｅｌ．ｔｉｍｅが示している時刻のデータ（Ｔｃｈ＿．ｄａｔａに格納されているデータ）を得る（通常は最新値の時刻、データが格納されている。）
・項目ＩＤ２を用いれば、前菜とのデータを取得できる。

【0042】

＜クラス設計＞
//統合データ処理（データアクセスミドルウェア）クラス定義
class Tdata {
enum data_type {DATATYPE_CH, DATATYPE_CAL, DATATYPE_INPUT, DATATYPE_DIAG, DATATYPE_TOKEI}};
//データの種類：計測データ、計算式、入力値、診断値、統計値
double get_data (Tkomoku_ID komoku_ID) //項目ＩＤクラスよりデータを取得
double get_data (Tkomoku_ID komoku_ID, Ttime time) //項目ＩＤクラス、時刻よりデータを取得
bool get_data (Tkomoku_ID komoku_ID, Ttime time_s, Ttime time_e, double *data)
//項目ＩＤクラス、時刻範囲よりその間のデータを取得
bool get_data (Tkomoku_ID komoku_ID, Ttime time, int kosu, double *data)
//項目ＩＤクラス、時刻より、指定個数のデータを取得
double get_data (int data_type, int no) //データ種別とデータ番号より取得
};;
・時刻の指定が無い場合は、最新値とする。
・その他多数のデータ取り込み関数が考えられる。

【0043】

（第２の実施形態）［システム構成例］
図１は、第１の実施形態において説明したデータ識別ＩＤの具体的な適用事例の１つとして、発電システムに適用した構成例を示す図である。
このシステムは、発電システム１と計測データサーバー４とがネットワークを通じて接続され、さらに、各種アプリケーション・サーバー５（５ａ～５ｃ）と計測データサーバー４とは、データアクセスミドルウェア１０２を介して接続された構成を有する。さらに、データ識別ＩＤを管理するＩＤ管理サーバー１０１が設けられ、データアクセスミドルウェア１０２と通信して必要なＩＤ管理データのやりとりを行うことができる。

【0044】

計測端末２（２ａ、２ｂ）は、ＰＣＳから各種の計測データを取得すると共に、インターネット等の電気通信回線を通じて計測データサーバー４に接続されている。各地の計測データは計測データサーバー４に集められる。データサーバー４は計測データ等のデータベースを管理するサーバーであり、データベース自体は、発電システム（発電所）を特定する識別子に紐付けられたタイムスタンプと、タイムスタンプに紐付けられた複数の数値列で構成された従来のデータ構造と変わらないものであってもよい。

【0045】

ここで、発電システム１（１Ａ、１Ｂ）は、各地に点在する発電所を構成する単位であり、発電所の規模によって様々な場合がある。例えば、発電システム１Ａは複数の計測端末２（２ａ、２ｂ、・・・）を有するが、発電システム１Ｂは１つ乃至複数の計測端末２（２ａ、２ｂ、・・・）に加えて、日射計３を備えているとする。計測端末２には図示しないＰＣＳとよばれる発電制御装置やＰＣＳを制御するための発電制御装置などに接続されており、ＰＣＳの先には発電装置（例えば太陽光発電用のパネル）が接続されている。

【0046】

但し、発電装置の種類は特に限定されず、発電量の制御が必要な発電装置であればよい。例えば、太陽光の他には、風力や地熱、水力その他様々な自然エネルギーを用いた発電装置が想定される。これらは発電量が気象条件等によって変動しうる要素が大きいため、遠隔地にある計測データサーバー４に集約される計測データを通じて、各システム内の機器の状態を監視したり、機器の故障やその兆候を検知することへのニーズが高いためである。

【0047】

各種アプリケーション・サーバー５（５ａ～５ｃ）は、計測データサーバー４に保存された様々な計測データを活用して種々のサービスを提供する。例えば、遠隔地にある発電システムの運転状況等を診断するための遠隔監視システム５ａ、運転状況の確認とメンテナンスを行うためのＯ＆Ｍ（オペレーション＆メンテナンス）システム５ｂ、発電システム内の機器の異常や故障或いは経年劣化等を診断する発電診断システム５ｃ、などがある。

【0048】

従来の発電システムは、アプリケーション・サーバー５が計測データサーバー４に直接アクセスし、データの要求や返答を行う構成が採用されていた。しかし、それぞれのアプリケーション・サーバー５が直接データベースにアクセスする構成の場合、データベースサーバーへのアクセス集中、各アプリケーション・サーバー５の上で実行されるプログラムのエラー、その他不測の事態によって、計測データサーバー４に記録されているデータベースが破壊される恐れがある。或いは、アプリケーション・サーバー５を踏み台として計測データベースサーバー４に対する不正アクセスの原因となる危険性も高まる。

【0049】

このような問題を回避するため、本実施形態では、計測データサーバー４とアプリケーション・サーバー５との間に、データアクセスミドルウェア１０２を介在させる構成を採用すると共に、各地に散在する発電システムの計測データや計測データに付随する様々なデータを一意に特定するためのＩＤ管理サーバー１０１によってデータアクセスミドルウェア１０２に対する管理データ要求及び返答を管理させる構成とする。

【0050】

ＩＤ管理サーバー１０１は、データ識別ＩＤを管理するためのサーバーであり、計測端末が複数台あっても、計測端末に依存することなく一意にデータ等を特定することができることを可能にする。データアクセスミドルウェア１０２は、いずれかのサーバー上で動作させることも可能であるし、計測端末２ａ上で動作させてもよい。

【0051】

このような構成によると、各アプリケーション・サーバー５は、データアクセスミドルウェア１０２によって共通化されたインターフェースを介して計測データベース４にアクセスすることにより、計測データサーバー４内のデータの破壊や計測データサーバー４に対する不正アクセスのリスクを低減することができる。

【0052】

データアクセスミドルウェア１０２は、アプリケーション・サーバー５からの要求（リクエスト）を受けて必要なデータを返答する機能を持つ。そのため、ＩＤ管理サーバー１０１に予めデータ識別のＩＤ管理情報と計測データとの関係を登録しておくことが必要となる。これは必ずしもデータアクセスミドルウェア１０２自身が行う必要はなく、事前にＩＤ管理サーバー１０１に必要な情報を入力しておくことで実現される。
ＩＤ管理サーバー１０１はデータ識別ＩＤのデータベースを管理しており、計測データサーバー４に記録されているデータベース（テーブル）に含まれる数値列に対しての意味付けを行うテーブルを保存している。そのため、データアクセスミドルウェア１０２からの要求に応じて必要なデータに対応する特定のＩＤ管理データを返答する機能を有する。

【0053】

データアクセスミドルウェア１０２の実装方法に制限はなく、ネットワークに接続された単体の専用サーバー上で動作する構成を採用してもよい。例えば、必須ではないが、ウェブサーバー上にデータアクセスミドルウェアを実装し、Ｗｅｂアプリケーションとして実装することもできる。この場合、サーバーのドメイン等に特定のコマンドやデータを含めたＵＲＬとしてアプリケーション・サーバー５からデータ要求を行うように構成してもよい。或いは、より簡単なシステムでは、発電システム１内の１つ又は複数の計測端末２の内部に同様の機能が搭載される実装であってもよい。

【0054】

計測データサーバー４に記録されている計測データは、タイムスタンプとその時刻における複数の数値データとで構成されるテーブルとして表現可能な数値データの集まりであり、通常は発電システム（発電所）ごとにこれらの数値が記録されている。計測データがどの発電システムや計測サイトの計測端末からアップロードされたものかは事前に設定しておくことで判別可能である。また、数値データの何番目のデータがどの識別ＩＤに対応するかを予め設定しておく。数値データの順番は、計測端末の設定変更が行われない限りは変わらない。逆に、計測端末の設定変更が行われる場合は、ＩＤ管理サーバー１０１の設定変更も必ず行われるようにすることが必要である。

【0055】

次に、データアクセスミドルウェア１０２の動作について説明する。データを必要とするアプリケーション・サーバー５は、要求する計測データに識別ＩＤを付与してデータアクセスミドルウェア１０２に要求する。データアクセスミドルウェア１０２は、要求に応じて計測データサーバー４にアクセスして必要なデータを読み出し、アプリケーション・サーバー５に返答する。アプリケーション・サーバー５からデータアクセスミドルウェア１０２に送信するデータ要求としては、以下のような形式が考えられる。
発電所ＩＤ：１２３４５６（ラプラス発電所）
計測システムＩＤ：７８９（計測システム１）
項目ＩＤ：１０（ＰＣＳ１の交流電力）
要求期間：２０２２年２月１日

【0056】

上記のような識別ＩＤを与えてデータアクセスミドルウェア１０２にアクセスすると、ＩＤ管理サーバへの問い合わせを行うことで、ラプラス発電所の計測システム１のＰＣＳ１台目の交流電力のうち、２０２２年２月１日のデータを要求することができる。そして、予めＩＤ管理サーバー１０１に登録された情報から、計測データサーバー４に記録されているデータの対象レコード及び対象位置が分かるので、データアクセスミドルウェア１０２から計測データサーバー４にアクセスして必要な計測データを取得し、アプリケーション・サーバー５に返答する。
アプリケーション・サーバー５は、複数のデータ識別ＩＤを与えてデータを要求することが可能である。例えば、複数の発電所から複数の計測項目を要求できるほか、期間についても複数期間分のデータを要求できる。指定期間の集計処理（例えば、平均値や積算値）の算出をデータアクセスミドルウェア１０２側で行ってその結果を返答するように構成してもよい。

【0057】

＜データアクセスミドルウェアの活用事例＞
データアクセスミドルウェアを用いる利点について、事例を参照して説明する。
図６（Ａ）は、データアクセスミドルウェア１０２を配置せず、ユーザーが複数の遠隔監視サイト１～３を介して計測データサーバ４に直接アクセスする場合の構成図を示している。これに対して、図６（Ｂ）は、データアクセスミドルウェアを介して計測データサーバ４にアクセスする場合の構成図を示している。両者の比較を通じてデータアクセスミドルウェアの活用事例を説明する。

【0058】

はじめに、前提として、データアクセスミドルウェア１０２は、複数の数値を含む数値データが記録されたデータベースサーバー上に構築される論理的なデータベースに対して特定のデータの読出しを要求し、その要求に対する返答を行うシステムを前提とする。

【0059】

従来のミドルウェアを用いない構成（図６（Ａ））では、データの読出し要求は複数の遠隔監視サイト５ａ～５ｃを介して計測データベースサーバー４に要求され、各遠隔監視サイトを介して読出し要求に対応する数値データの返答を受ける仕組みであった。計測データサーバー４から取得した数値データの意味づけは、遠隔監視サイト側で行われるか、或いはデータを要求した側で、数値データの意味を解釈する必要があった。

【0060】

これに対して、図６（Ｂ）の構成では、数値データの要求は全てデータアクセスミドルウェア１０２を介して行われる。データアクセスミドルウェア１０２は、図１に示すとおり、ＩＤ管理サーバー１０１と通信し、計測データベースサーバー４に記録された数値データの属性等を紐付けることで、数値データに「意味づけ」を行うことができることが前提である。すなわち、データアクセスミドルウェアは、計測データベースサーバー４に対して前記数値データを要求するために実行されるプログラムであって、数値データに含まれる特定のデータの読出し要求を受けて、計測データベースサーバー４から特定のデータを読み出す。そして、数値データを構成する数値の属性を一意に特定するデータ識別ＩＤが記録されたＩＤ管理サーバーからデータ識別ＩＤを含むＩＤ管理データを取得して、特定のデータに含まれる数値の属性を紐付けした状態で、読み出し要求に対する応答を行う。

【0061】

以上のような基本的な構成を、太陽光発電システムの計測データを解析する仕組みに適用した事例を説明する。ここで太陽光発電システム（発電所）は、図１に示すように、太陽光発電システム（発電所）毎に設置された計測端末或いは計測機器から取得した計測データを計測データベースサーバー４にアップロードする仕組みを有しているものとする。

【0062】

［事例１］
複数の発電所から同種のデータ（例えば発電電力量）を取得する際に、図６（Ａ）に示すように、各々の遠隔監視サイトにアクセスするのではなく、図６（Ｂ）に示すように、ミドルウェアを介することで一度の要求で処理が可能となる。複数の発電所のデータを横断的に取得できることは、複数発電所を同時に監視するような顧客やＯ＆Ｍ会社（オペレーション＆メンテナンス）において有用である。例えば保有する発電所の各データを一覧で表示する機能を実現するにあたり、ウェブサイト、スマートフォン上で動作するアプリケーションソフトウェアなど、異なる通信媒体を介してアクセスされる場合でも、すべてはミドルウェアを介してデータを取得することが可能になる。

【0063】

［事例２］
機器の異常や故障或いは経年劣化等の診断する現在の発電診断機能は、各発電所ごとに個別に実施されている。そのため、各発電所毎に蓄積された過去の発電データ等との比較に基づく診断しかすることができなかった。しかし、データアクセスミドルウェアを活用すれば、異なる複数の発電所から必要なデータを取得することが可能となる。これにより、取得したデータを解析することが可能となる。
例えば、地理的に近い発電所、定格容量が同じ発電所、機器の構成が近い発電所、といった、複数の観点から、似たような構成の別々のデータを発電所を超えて横断的に比較等することにより、機器の故障又は異常を検知する発電診断を行うことが可能となる。

【0064】

［事例３］
すでに述べたとおり、一般的にデータには様々な種類が存在するが、「データ識別ＩＤとデータのセット」として管理されたデータを扱うミドルウェアは、データの種類に関わらず、扱いを統一することができる利点がある。つまり、もとになるデータは自社データだけでなく、他社データであっても、ミドルウェアがその違いを吸収することで、顧客や上位のアプリケーションがデータを要求する時には、元データの違いは意識する必要がないことになり、データを要求する側はシンプルで分かりやすくなる。

【0065】

なお、図６（Ａ）及び図６（Ｂ）を用いて説明した上記［事例１］～［事例３］は、いずれも、太陽光発電システムにおける発電データ解析を念頭に、ユーザー或いは特定の機器が、「計測データ」を記録する計測データサーバー４に対する計測データを要求し、求める計測データ（数値データ）の返答を受けるために、「ミドルウェア」を介する例を示したが、数値データとデータ識別ＩＤとを紐付けることにより数値データに対する意味づけを行ったうえで、要求された数値データを返答するという点が重要である。数値データは計測データに限られず、文字列及びコンピュータ上で扱うことが可能な全てのデータを全て含むことは言うまでも無い。このような仕組みは機器の故障又は異常を検知する診断システムに適用することができる。

【0066】

（第２の実施形態）－データの通信方法－
データを扱うためのアプリケーション・サーバー５が計測データサーバー４へのアクセス要求をミドルウェア１０２に対して行う際に、データ識別ＩＤを用いて必要なデータを特定できる。よって、ミドルウェア１０２は、計測データサーバー４が管理するデータベースから速やかに必要なデータを取得して、アクセス要求を受けたアプリケーションサーバー５にデータを送り返すことが可能となる。

【0067】

この具体的な実現手段は１つとは限らないが、一例として、いわゆるＷｅｂＡＰＩを利用する方法が想定される。一般に、ＷｅｂＡＰＩは、対象となるサーバーのＵＲＬに対して、ＵＲＬに追加でオプション（付加情報）を付与して通信することで、サーバから必要なデータが返答されるウェブアプリケーションプログラムである。上記の場合、対象となるミドルウェアサーバー１０１をＷｅｂサーバーとして起動し、そのＵＲＬがミドルウェアの入り口となり、そのオプションとして、データ識別ＩＤ、データ期間、データ形式などの情報を加えてアクセス要求を行う。また、返答されるデータは、事前の設定により、バイナリ形式のほか、ＪＳＯＮ形式、ＣＳＶ形式など複数の出力形式からアプリケーション毎に扱い易い出力形式を任意に選択できる態様が想定される。

【0068】

ここで、再び太陽光発電システムを例に説明する。従来、太陽光発電システムにおけるパワーコンディショナ（ＰＣＳ）に接続された計測端末において、ＰＣＳから発電電力を受信し表示させる場合、チャンネル表を参照して該当するチャンネル番号を設定する必要がある。これは、ＰＣＳから取得したデータは、取得直後は単なる数値の羅列にすぎないためである。順番に並べられた数値の何番目が何のデータであるか（例えば、１番目の数値は１台目のＰＣＳの交流電力である）という情報がチャンネル表により定義されている。

【0069】

ＰＣＳの設置現場では、ＰＣＳの増設や通信仕様の変更が行われる際に順番が変わり、その度毎にチャンネル表は更新されることも少なくない。これが、トラブルの原因となっている。一般に、順番はＰＣＳの通信プロトコルに依存することが多いようである。

【0070】

そこで、チャンネル表の代わりに発電電力の識別ＩＤ（物理量識別ＩＤ）を設定し、識別ＩＤとそれに対応するデータとを常にペアとして扱うことで、データを保存する順序が変わってもデータの意味が失われないようにすることが可能となる。例えば、発電電力を表すデータがチャンネル表の何番目であるとしても、識別ＩＤを目印に特定できるようになる。データの保存順序の指定も不要となる。

【0071】

同様に通信でデータを送出する際にも、データと識別ＩＤを常にペアで持つルールさえ守れば送信の順序にも意味がなくなり、任意のタイミングでデータを送信できるようになる。すなわち、プロトコルの指定は不要となる。

【0072】

さらに、チャンネル番号はそれぞれの計測端末内部でしか一意ではない。もし、１つの発電システム内に複数の計測端末があれば、チャンネル番号に重複が生じうる。その点、データ識別ＩＤは、同一の発電システム内では一意の値に割り当てることができるため、計測端末が複数台あっても計測端末に依存することなく一意データを特定し、取得することができる。

【0073】

本実施形態のように、順番に依存しない形で必要なデータのみを取り出せることは、処理の汎用性を飛躍的に向上させることに寄与する。

【0074】

データ識別ＩＤは、計算式や、入力値、演算値などにも応用することができ、計算値と計測値を同等に扱うことができる。そして、全てのサイトが同様のルールに則っていれば、サイト毎の固有のシステム形式に左右されることなく、一律の処理が可能となる。仮に、全世界の計測システムにこの方式が取り入れられたならば、全世界の全てのデータが汎用的に扱えるようになる。

【0075】

＜実施例１＞
アプリケーション・サーバー５が、複数の発電システム１（１Ａ、１Ｂ、・・・）に対してそれぞれの発電電力を要求しその合算値を取得するシステムを構築することが可能となる。これは、複数の発電システムを管理するユーザーにとって大きなメリットとなりうる。
この点、従来のシステムでは、アプリケーション側が各発電システムの情報それぞれ要求・取得し、さらにそれらを合算する必要があり、処理に時間がかかっていた。また、通信も各発電システムに対しての要求毎に必要となるため、無駄が大きかった点を考えると、その利点は大きい。

【0076】

＜実施例２＞
比較的距離の近い場所に２つの発電システム１Ａ、１Ｂがあり、かつどちらか一方のみ（例えば発電システム１Ｂ）に日射計３が取り付けられている状況を想定する。日射計３は高額なため、全ての発電所に取り付けることは現実的でない場合が多い。しかし、日射計３は、発電量の予測や保守には有用なため、日射計を取り付けていない発電システムに対しても同様に発電量の予測や保守に日射計のデータを活用できれば好ましい。従前であれば、発電システム外のデータを別の発電システムのデータとして活用することは容易ではなかったが、識別ＩＤによりデータを要求することで、発電システムの単位を超えたデータの取得が可能となり、データ活用の幅を広げることができる。

【0077】

図１を参照して説明される第１及び第２実施態様では、計測システムに特化したデータ識別ＩＤの例について説明してきた。しかし、もっとも本質的な点は、データサーバーによって管理される「データベース」上のデータの１つ１つが、「データ識別ＩＤ」によって一意に特定され、それにより意味付けされる点にある。データ識別ＩＤを管理するために「データサーバー」とは別に「ＩＤ管理サーバー」を用いる点、及び「データサーバー」へのアクセスに「データアクセスミドルウェア」を介して行う点については、具体的な構成例としてもっとも合理的な態様の１つであるものの、他の構成、例えば、ＩＤ管理サーバーの機能を計測データサーバーの一部に含めたり、ミドルウェアサーバーを省略したり、取り扱うデータの規模により、複数のサーバーを集約して簡素化することも考えられる。

【0078】

（第３の実施形態）
本発明の本質は、扱うデータの種別を問わない。データベースとデータ識別ＩＤを管理するＩＤ管理サーバーとを分離しつつ、データアクセスミドルウェアを介してデータベースにアクセスする点が重要である。そのため、扱う数値データは物理量以外の数値、たとえば売上、利益などの金銭にまつわるデータ等も対象とすることができる。
例えば、売上や利益などの経理情報は、従来は財経管理システムなどの特定のシステムの中だけで参照される構成が一般的であった。しかし、データ識別ＩＤを管理するＩＤ管理サーバーをデータベースサーバーから分離して設ける一方、データベースへのアクセスはデータアクセスミドルウェアを介することで、特定のシステムに縛られないデータ参照が可能となり、システム連携がしやすくなる。例えば、売上、利益等の数値データは、現状の営業分析、将来の利益計画にも利用することができるため、財経システム以外でも必要とされることがあるが、必要なデータのみを別途ファイルなどで出力して使用しなければならず、利便性に欠けていたが、あらかじめデータ識別ＩＤが付与されたデータとして管理されることで、それを必要とするシステムが要求すれば即座に参照することができるため、極めて高い利便性を提供することができる。

【産業上の利用可能性】

【0079】

ＩｏＴ機器が普及する中、ＩｏＴ機器が取得した数値データを各社毎の独自仕様で、或いは各拠点（サイト）毎に定義しているのでは数値データの汎用的な取り扱いが不可能であるが、本発明のデータ構造を前提に各社が同様の通信ルールで数値データのやりとりを行うことになれば、ＩＰアドレスやＱＲコード（登録商標）のように、異なる機器で同等に数値データを扱えるようになり、産業性の利用可能性は極めて大きい。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】