発電設備最適運用システム（BTG-EMS）の開発

一般論文

発電設備最適運用システム（BTG-EMS）の開発
神戸事業所

技術第1部

発電計算機システム課
岩田 歩（3）OPC（注1）-GW

１．まえがき

制御装置とのデータ通信用ゲートウェイ装置であり、制御装置から受信するデータの収集と指令値の出力を、燃料生成や化学産業、製紙などの工場では、自家発電設

OPCサーバを介して行う。

備を設置し、工場内で消費する蒸気及び電力を賄っている。
従来、これらの設備の運用計画は、経験や実績に基づき決端末(遠隔地)定していたため、電力量の過不足が発生していた。発生し端末(中央制御室)

た過不足は、電力会社との契約に基づき調整を行っていた

端末(事務室)外部システムが、調整に係る損益は重要視されていなかった。近年、電力取引を利用し、これらの過不足をなくすことで、電力売買の損益改善を図り、エネルギーコストを削減したいというニーズが高まっている。
発電設備最適運用システム（Boiler Turbine Generator
Energy Manegement System:BTG-EMS）は、これらのニーズに応えるため、電力取引を考慮した設備の運用を行い、発電設備の運転を制御するシステムである。本システ

Webサーバムは、蒸気・電力需要、燃料・電力単価、及び設備自体の特性より、エネルギーコストを最小化した運用計画を算出する。さらに、制御装置と連係し、算出した運用計画に沿って、EMSサーバ設備を制御する。

自家発電設備制御システム

本稿では、開発時に考慮した事項について述べる。
OPC-GW

２．システムの構成
OPCサーバ2.1

ハードウェア構成

BTG-EMS

本システムは、自家発電設備を持つ工場に、広く販売し制御装置

図１．ハードウェア構成ていくことを想定している。よって、容易に導入できるようシステム構成を可能な限りシンプルにしている。本シス

2.2

テムは、図1に示す以下の機器より構成される。

ソフトウェア構成

本システムは、図2に示すソフトウェアから構成される。

（1）EMSサーバ（1）最適化計算処理

本システムの計算プログラムや、データベース、及び本処理では、プラントの配管構成や設備特性等を数式各種計算プログラムを搭載している。データベースは外としてモデル化した「最適化モデル」を利用し、エネルギー部のシステムにも公開している。

コストを最小化した場合の運用計画を算出する。

（2）Webサーバ（2）リアルタイム計算処理

遠隔地で利用するニーズへの対応、及び端末に対する本処理では、実際の設備の制御状態を監視するために専用アプリケーションのインストールを不要とすること必要となる数値計算を行う。各計算式は、発電設備の構を目的とし、HTML5、CSS3、及びスクリプト言語で画成に合わせてカスタマイズが必要となる。

面描画を実現している。

（3）対制御装置データ処理部対制御装置とのデータ入出力を行う処理である。本処理では、発電量、蒸気発生量等の現在のプロセス値と、（注１）プロセス制御における標準規格。クライアントサーバ型の通信モデルとなっている。

設備停止状態等のアラームを受信する。また、運用計画

32

発電設備最適運用システム（BTG-EMS）の開発策定時に算出された指令値を、制御装置へ送信する。

よって、高速かつ汎用的なデータアクセスが可能な仕組みの構築が必要であった。

（4）収集データシステム内で計算される運用計画、指令値や、制御装

3.2

置から受信するプロセス値、アラームを指す。データの完成度の高い最適化モデルの提供

制御や監視に必要なデータも含まれていることから、高適切な運用計画を自動生成するためには、発電設備の挙速にアクセスされる必要がある。本データは、システム動を正確に模擬した最適化モデルを準備することが重要での外部へも公開している。

ある。しかし、最適化モデルを準備するためには、大量の運転データを分析して最適化モデル設計を行う必要がある（5）OPC通信処理
OPC-GWに実装されている処理であり、OPCサーバため、非常に手間がかかり誤りが混入しやすい。との入出力を中継する処理である。

よって、大量のデータを効率的に分析できる最適化モデル設計プロセスを構築する必要があった。

（6）画面制御処理
Webサーバの主となる処理であり、端末からの要求に3.3基づき、各種画面の制御を行う。

高いカスタマイズ性の実現

自家発電設備は、事業用発電設備と異なり、設備ごとに（7）HTML/スクリプト予め用意されたHTML・スクリプト群であり、端末上の構成や運用プロセスが大きく異なっているため、納入先ごブラウザからダウンロードすることにより、これらのファとに改造箇所が多くなる傾向にある。過去の類似システムイルが読み込まれ、系統図や、各種データ設定を行うたでも、以下に示す改造が複雑であるという課題があった。

めの汎用画面を表示することができる。なお、これらの（1）多岐にわたる制御装置との通信処理の改造ファイルは、発電設備ごとのカスタマイズが必要となる。

（2）ハードウェア更新時の改造

EMSサーバ（3）設備変更に対する現場での改造

端末

外部システム
系統図

要求・応答

自家発電設備へシステムの導入を行うためには、これら汎用画面の改造を容易に行える高いカスタマイズ性を持つ必要がダウンロード(1)最適化計算処理

生成
最適化モデル

要求・応答

(4)収集
データ要求・応答あった。

(7)HTML/
スクリプト

４．開発時に考慮した事項(6)画面制御処理

4章では、3.1～3.3項に示した課題への対応策について述

Webサーバ(2)リアルタイム計算処理(3)対制御装置
データ処理

凡例
通信
データアクセス
生成/ダウンロード処理

べる。

OPC-GW(5)OPC通信処理4.1

制御装置用
プロトコル
制御装置

制御装置用
プロトコル

4.1.1

OPCサーバ開発方針と性能目標

本システムでは、データを外部公開できるように汎用のファイルデータベース（PostgreSQL）を採用することとした。

装置

リアルタイムのデータ監視には、運用実績のある三菱電データ機（株）製データ収集ミドルウェア｢MELDAS｣を採用した。

図２．ソフトウェア構成

MELDASは共有メモリ上に仮想化したバイナリファイルを構築することが可能であり、数万点の計測信号に対して、1

３．システム開発上の課題
3.1

高速なデータ収集ミドルウェアとリレーショナルデータベースの連係秒未満のデータアクセス性能を実現することが可能である。
リアルタイムのデータ監視に利用したデータは、その後高速かつ汎用的な運転データアクセスの実現

計測値として保管するために、データベースに書き込んで本システムは、自家発電設備の制御に利用される。したおく必要がある。また、データベースに保管されている過がって、設備異常の発生時、制御装置への指令値出力を停去の計測値を用いて、データ監視に必要な数値を計算する止する等、適切な処置が行えるよう高速に運転データを蓄ために、データベースの値を読み込む必要もある。図3にイ積し監視する必要がある。一方で、運転データを外部シスメージを示す。

テムで利用可能とするためには、蓄積した運転データを汎用的な通信仕様で公開しなければならない。
33

発電設備最適運用システム（BTG-EMS）の開発

さらに、計測信号の数値を保存するテーブル内の構造に【要件】
制御装置から入力されたデータをリアルタイムに監視したい。

ついても、性能が低下しないよう配慮した設計を行っている。
本テーブルは、時刻をキーとして、グラフ等で一定期間収集データ内のデータを画面表示する機能を実現している。この場合、監視用
系統図

MELDASカラムが計測信号ごとの値となり、性能目標を満たすには1テーブルに数万件のカラムを実装することになる。しかし、データ保管やデータ計算のためにMELDASとPostgreSQL間の連係が必要

制御装置

PostgreSQL

PostgreSQLのカラム最大数は1,600件となっており、そのままでは実現は不可能である。そこで、図5のように信号の汎用的なデータアクセス【要件】外部システムで収集データを利用したい。

種別ごとに全点のデータを1つの配列にまとめ、データを格納した。

外部システムカラムを37000件も配置することができない！

図３．データアクセスの要件
このような要件から、高速かつ汎用的なデータアクセス

測定時刻

信号1信号2…

信号37000

2019-10-11 14:00:00

341.1

21.1

…

true

2019-10-11 14:01:00

340.8

21.2

…

true

を実現すべく、MELDASのバイナリファイルと、データベースとの連係部分の開発を行った。
連係部分で実現する性能目標を以下に示す。

測定時刻

アナログ信号

デジタル信号

2019-10-11 14:00:00{341.1, 21.1,…}{…,true}

2019-10-11 14:01:00{340.8, 21.2,…}{…,true}（目標1）370,000点の計測信号を1秒以内にデータベース値を配列で持つことにより、カラムの上限制約を回避

図５．テーブル構造設計の問題点と解決策に書き込めること。

FDW機能を活用したデータ入出力処理の性能評価結果を（目標2）37,000点のデータ監視用の数値計算を行う信号

次に示す。

について1秒以内にデータベースからMELDAS

表1の結果から、1件当たりのデータベース書き込み時間へ読み書きできること。

は1秒以内に収まった。また、表2の結果から、1件当たり4.1.2のデータ入出力は1秒以内となった。

開発内容と評価

以上の評価結果より、MELDASのバイナリファイルと前項で示した性能目標を満たすため、PostgreSQLの拡張機能であるForeign Data Wrapper（FDW）

PostgreSQLのデータベースとの連係に必要な性能目標を満機能を活用（注2）足することができた。

し、独自のラッパープログラムを作成した。本ラッパープ
ログラムにより、SQLで共有メモリ上の仮想ファイルを使表１．性能評価結果（データベースの書き込み）用可能とした。ラッパープログラムのイメージを図4に示す。

項目
共有メモリ
0001 000f
0c00 1fff
1e11 …

要求値

測定結果

1[s]

32[ms]

データベースへの書き込み(1件当たりの書き込み時間)バイナリファイル
FAIVAL

FDW
PostgreSQL※計測信号点数：370,000点で測定

表２．性能評価結果（MELDASへの読み書き）本システム開発時にMELDASのMELDASでは、共有メモリ上 外部データラッパー(FDW)を開発のデータを仮想ファイルとして取り扱うことが可能

項目

PostgreSQL上から見た場合

meldas_aival
aival real[37000]

insert into value(select * from meldas_aival);

FDWを開発することで、ＰostgreSQL上で、MELDASの仮想ファイルをテーブルのように扱えるようにした。

value
date timestamp (KEY)aival real[37000]
aists smallint[37000]
dival bool[37000]
dists smallint[37000]

要求値

測定結果

MELDASの書き込み(1件当たりの書き込み時間)

1[s]44[ms]MELDASからの読み込み(100件当たりの読み込み時間)

1[s]20[ms]※数値計算用信号点数：37,000点で測定

図４．MELDAS-PostgreSQL間データ連係イメージ

4.2

最適化モデル設計作業の効率化

4.2.1

設計作業の概要と作業フロー

本システムでは、工場の設備配管系統や、特性等を数式にモデル化した｢最適化モデル｣を実装する。この最適化モ（注２）他のデータベースやファイルに格納されているデータをPostgreSQL上からアクセスできる機能

デルは、自家発電設備の設計図面だけではなく、実際の運34

発電設備最適運用システム（BTG-EMS）の開発転データを利用し設計する必要がある。
最適化モデル設計作業の流れを、図6に示す。

改善前

改善後

① 大量にあるデータをモデルに適合しているか目視で確認し、評価① 予めデータの因果関係より、許容される上下限を設定（例）下記の例であれば、再熱蒸気流量の上限は、主蒸気流量の値とする。

(1)設計図面による仮の最適化モデル作成(2)運転データによるモデル評価と修正(3)最適化計算によるモデル評価と修正

目視確認
大きく乖離しているデータは、目視で確認の上、除去していた。

NG

プラント構成上想定される値や、適正な運用を行った場合の範囲について、火力発電所向けの他システムで培ったノウハウを元に想定し、上下限を設定

図６．最適化モデル設計作業フロー（1）設計図面による仮の最適化モデル作成② 最適化計算を実行し、運用計画を算出すると、エラーが発生。

② ツールを実行させ、上下限のチェックを行う。
※チェック結果は、上記例の様に、背景色を変更する。
③ チェック結果を確認し、要因調査の上、最適化モデルの修正を行う。

か精査した上で、仮の最適化モデルへ代入し、最適化モ③ エラー箇所をチェックすると、タービンに関する値が、不正であることが判明。
要因調査し、最適化モデルを修正すると、今度は異なる箇所でエラーが発生。

デルが自家発電設備を模擬できているか評価する。モデ④ ②～③を繰り返す。

自家発電設備の設計図面よりモデル化する対象機器を決定し、仮の最適化モデルを作成する。
（2）運転データによるモデル評価と修正
対象機器の運転データに異常値などが含まれていない

ルに問題がある場合は修正し、（2）をやり直す。

④ 運用計画算出では、エラーが起こらず、モデルの設計が完了する。

図７．最適化モデル設計作業フローの改善点（3）最適化計算によるモデル評価と修正（2）の最適化モデルを使用して最適化計算を行い、算出4.3された運用計画について最適化の効果が表れているか評

制御装置通信への汎用プロトコルの適用価する。運用計画を求められない場合、または最適化の自家発電設備制御装置の納入メーカは、多岐にわたる。

効果が十分に表れていない場合はモデルを修正し、（2）か各メーカの通信仕様に合わせたデータ入出力処理を実装すらやり直す。

ると、納入先ごとに本システムのカスタマイズが生じ、コスト増加や、作業に伴う品質問題の発生リスクが生じる。

4.2.2

そこで、本システムでは納入先ごとのカスタマイズを最作業フローの改善

前項の最適化モデル設計作業フローにおいて、（2）の作業小限に抑えることを目的に、制御装置で一般的に対応してで問題が発見された。

いるプロトコルを採用することとした。

本作業では、1週間×4パターン（季節等）における運転デー

一般的なプロトコルの一覧を表3に示す。

タの精査を行う。この精査作業は、データの測定精度が疑表３．一般的な制御装置用通信プロトコル

われる値（異常値）や設備停止等により変動したデータ（特異プロトコル値）を取り除くものである。運転データは小規模の設備でも100点×1時間値のデータ量となるが、開発当初は目視で、これらの値を除去していた。そのため、運用計画を算出した後に、運転データに異常値が含まれていることが判明し、OPC-DA(OPC Classic)

Windowsに搭載されているOLEとよばれる技術を利用して、通信を行う。

OPC-UA

OPC-DAをOSに依存せず利用できるよう、拡張したプロトコル。OPC-DAに対して上位互換性を持つ。近年、対応できる制御装置が増加。

Modbus TCP

シリアル接続で使用されていたプロトコルであるModbusをEthernet上へ適用したもの。

SLMP

三菱電機(株)製のプロトコルであるCC-Linkを利用している制御ネットワークとEthernet間のデータを通信できるようにするプロトコル。

FL-netサイクリック通信とよばれる定周期通信を行い、ネットワークに接続された装置間でデータを共有する。伝送路を他のEthernet通信と共有することができない制約がある。

手戻りが生じていた。
そこで、図7に示すように、運転データ間の因果関係から、プラント構成上で想定される値や、適正な設備運用を行っている場合に想定される上下限値を設定することで、運転データを可視化できるツールを作成した。このツールにより、運用計画算出前に、特異値・異常値を確認し、除去することができるようにした。

35

特徴

発電設備最適運用システム（BTG-EMS）の開発

地改造作業を短時間で、確実に実施できるツール群を準備

将来的には、一覧に示した全プロトコルについて対応すした。

る必要があるが、本開発では、現時点で自家発電設備の制御装置に広く搭載されるプロトコルであるOPC-DAについて、他の一般的なプロトコルへの対応に先行して実装した。

4.5.2

以下に、ツール群について説明する。

なお、今後、プロトコルの拡張に対応できるよう、データ入出力処理において、信号ごとに受信元設備と対応するプ（1）系統図作成ツール
Windowsが搭載されているPCで作成した系統図画面ロトコルを選択できるような仕組みを実装している。

4.4

改造作業を支援するツールの概要を、Web上で表示できる形式へ変換するツールである。

仮想化技術の適用

本ツールのイメージを、図9に示す。

本システムでは、ハードウェアの耐用年数を10年として系統図エディタ推奨しており、耐用年数を過ぎた場合は、ハードウェア更①PC上で系統図を編集新が必要となる。図8に示すように、従来、ハードウェア更新の際は、ドライバ等、OSを構成するモジュールの変更が生じ、ソフトウェアの改造が必要であった。
本システムでは、ハードウェア更新時に、このようなソフトウェア改造が不要となるよう仮想化技術を適用した。
★物理マシン上にシステムを構築した場合
BTG-EMSOS

BTG-EMS

ドライバ

ハードウェア更新

OS

ハードウェア②系統図画面データをWeb上で表示できる形式に変換

ドライバ

ハードウェア系統図変換ソフトウェア→ハードウェア更新により、OSを構成するモジュールが影響を受け動作しなくなるため、OS更新や、アプリケーションの改造が必要となる。

系統図画面データ（中間ファイル）★仮想マシン上にシステムを構築した場合
BTG-EMS
ゲストOS

図９．系統図作成ツール

BTG-EMS

ドライバ

ハードウェア更新

ゲストOS（2）汎用画面定義生成ツール

ドライバ

仮想化ソフトウェア

仮想化ソフトウェア

ハードウェアハードウェア系統図以外の画面について、画面要素（テーブル、ボタン等）を定義すると、HTMLを自動生成できるツールである。本ツールのイメージを、図10に示す。
画面要素定義ファイル→ハードウェア更新により、影響を受けるのは仮想化ソフトウェアのみ。
アプリケーションに影響を与えないため、改造作業が不要。
凡例：

更新対象

スクリプト言語
ソースファイル①PC上で画面要素を定義

影響範囲

図８．仮想化の目的

4.5
4.5.1

現地改造を支援するツールの開発
改造作業の概要②画面表示時にCSVファイルをダウンロードし、スクリプトで解析

自家発電設備は、測定方法の変更や設備自体の改造等により、監視や制御に利用している信号の情報が変化する場③解析結果を元にHTMLファイルを自動生成

画面表示スクリプト合や、信号自体が追加・削除される場合がある。本システム
も、その影響で画面変更・計算式変更といった改造作業が必CSVファイル

要となる。

HTMLファイル

図10．汎用画面定義生成ツール

これらの改造作業は自家発電設備の特性調整なども関係するため、現地で行うことが必要となる。その際、システ（3）計算式グラフィカルエディタツール

ムの停止が許される短時間での作業を余儀なくされるため、監視及び制御に必要な計算処理を作成するツールであ確実に作業を行うことが求められる。本システムでは、現る。本ツールでは、計算式が図で表現され、ツール上で36

発電設備最適運用システム（BTG-EMS）の開発作図を行うことで、所望の計算処理を作成できる。本ツー
ルのイメージを、図11に示す。
計算式グラフィカルエディタ①PC上で計算式を編集②エディタ上でコンパイルを行い、ソフトウェアを生成計算処理
ソフトウェア

図11．計算式グラフィカルエディタツール
本ツール群を実装することにより、短時間で正確な改造作業を行えるよう改善を図った。

５．今後の開発の動向
本システムに対する新たな要望として、｢複数の工場に対応した運用計画算出｣と、｢システムのクラウド化｣の2点が挙がっている。
（1）複数の工場に対応した運用計画算出
工場が複数ある場合、工場間の電力融通を考慮し、事業者全体の視点からエネルギーコストの低減を図るための計算手法の開発が求められている。
（2）システムのクラウド化
工場から離れた事業拠点でも使用できるようクラウド化のニーズがあり、遠隔地からのプラント制御を行うための性能面やセキュリティ面における対応が急務である。
今後は、このような要望に対する開発を実施していくことで、自家発電設備を持つ事業者のニーズに応えるとともに、本システムの受注拡大に貢献していく。

６．むすび
本開発遂行に当たり、貴重な御意見、御指導をいただいた関係者の方々に深く感謝申し上げる。

執筆者紹介
岩田歩

イワタ

アユム

2010年入社。火力発電所向けシミュレー
タシステム及びプラント計算機システムのソフトウェア開発に従事。現在、神戸事業所技術第1部発電計算機システム課。

37