テクノロジー
技術レポート:アーカイブ
Category:電力システム
発電設備最適運用システム(BTG-EMS)の開発

燃料生成や化学産業、製紙などの工場では、自家発電設備を設置し、工場内で消費する蒸気及び電力を賄っている。従来、これらの設備の運用計画は、経験や実績に基づき決定していたため、電力量の過不足が発生していた。発生した過不足は、電力会社との契約に基づき調整を行っていたが、調整に係る損益は重要視されていなかった。近年、電力取引を利用し、これらの過不足をなくすことで、電力売買の損益改善を図り、エネルギーコストを削減したいというニーズが高まっている。発電設備最適運用システム(Boiler Turbine GeneratorEnergy Manegement System:BTG-EMS)は、これらのニーズに応えるため、電力取引を考慮した設備の運用を行い、発電設備の運転を制御するシステムである。本システムは、蒸気・電力需要、燃料・電力単価、及び設備自体の特性より、エネルギーコストを最小化した運用計画を算出する。さらに、制御装置と連係し、算出した運用計画に沿って、設備を制御する。本稿では、開発時に考慮した事項について述べる。
参考情報:
- この技術レポートは、当社が展開する公共・エネルギー事業の電力システムソリューションに係る技術について著述されたものです。
- 電力システムソリューションは、神戸事業所/横浜事業所/ トータルソリューション事業所が提供しています。
発電設備最適運用システム(BTG-EMS)の開発 (3)OPC(注1)-GW制御装置とのデータ通信用ゲートウェイ装置であり、制御装置から受信するデータの収集と指令値の出力を、OPCサーバを介して行う。2.2 ソフトウェア構成本システムは、図2に示すソフトウェアから構成される。(1)最適化計算処理本処理では、プラントの配管構成や設備特性等を数式としてモデル化した「最適化モデル」を利用し、エネルギーコストを最小化した場合の運用計画を算出する。(2)リアルタイム計算処理本処理では、実際の設備の制御状態を監視するために必要となる数値計算を行う。各計算式は、発電設備の構成に合わせてカスタマイズが必要となる。(3)対制御装置データ処理部対制御装置とのデータ入出力を行う処理である。本処理では、発電量、蒸気発生量等の現在のプロセス値と、設備停止状態等のアラームを受信する。また、運用計画 1.まえがき 燃料生成や化学産業、製紙などの工場では、自家発電設備を設置し、工場内で消費する蒸気及び電力を賄っている。従来、これらの設備の運用計画は、経験や実績に基づき決定していたため、電力量の過不足が発生していた。発生した過不足は、電力会社との契約に基づき調整を行っていたが、調整に係る損益は重要視されていなかった。近年、電力取引を利用し、これらの過不足をなくすことで、電力売買の損益改善を図り、エネルギーコストを削減したいというニーズが高まっている。発電設備最適運用システム(Boiler Turbine GeneratorEnergy Manegement System:BTG-EMS)は、これらのニーズに応えるため、電力取引を考慮した設備の運用を行い、発電設備の運転を制御するシステムである。本システムは、蒸気・電力需要、燃料・電力単価、及び設備自体の特性より、エネルギーコストを最小化した運用計画を算出する。さらに、制御装置と連係し、算出した運用計画に沿って、設備を制御する。本稿では、開発時に考慮した事項について述べる。 2.システムの構成 2.1 ハードウェア構成本システムは、自家発電設備を持つ工場に、広く販売していくことを想定している。よって、容易に導入できるようシステム構成を可能な限りシンプルにしている。本システムは、図1に示す以下の機器より構成される。(1)EMSサーバ本システムの計算プログラムや、データベース、及び各種計算プログラムを搭載している。データベースは外部のシステムにも公開している。(2)Webサーバ遠隔地で利用するニーズへの対応、及び端末に対する専用アプリケーションのインストールを不要とすることを目的とし、HTML5、CSS3、及びスクリプト言語で画面描画を実現している。発電設備最適運用システム(BTG-EMS)の開発神戸事業所 技術第1部 発電計算機システム課岩田 歩一般論文(注1)プロセス制御における標準規格。クライアントサーバ型の通信モデルとなっている。OPC-GWEMSサーバWebサーバ外部システム端末(中央制御室)端末(事務室)端末(遠隔地)OPCサーバ制御装置自家発電設備制御システムBTG-EMS図1.ハードウェア構成33発電設備最適運用システム(BTG-EMS)の開発よって、高速かつ汎用的なデータアクセスが可能な仕組みの構築が必要であった。3.2 完成度の高い最適化モデルの提供適切な運用計画を自動生成するためには、発電設備の挙動を正確に模擬した最適化モデルを準備することが重要である。しかし、最適化モデルを準備するためには、大量の運転データを分析して最適化モデル設計を行う必要があるため、非常に手間がかかり誤りが混入しやすい。よって、大量のデータを効率的に分析できる最適化モデル設計プロセスを構築する必要があった。3.3 高いカスタマイズ性の実現自家発電設備は、事業用発電設備と異なり、設備ごとに構成や運用プロセスが大きく異なっているため、納入先ごとに改造箇所が多くなる傾向にある。過去の類似システムでも、以下に示す改造が複雑であるという課題があった。(1)多岐にわたる制御装置との通信処理の改造(2)ハードウェア更新時の改造(3)設備変更に対する現場での改造自家発電設備へシステムの導入を行うためには、これらの改造を容易に行える高いカスタマイズ性を持つ必要があった。4.開発時に考慮した事項4章では、3.1~3.3項に示した課題への対応策について述べる。4.1 高速なデータ収集ミドルウェアとリレーショナルデータベースの連係4.1.1 開発方針と性能目標本システムでは、データを外部公開できるように汎用のデータベース(PostgreSQL)を採用することとした。リアルタイムのデータ監視には、運用実績のある三菱電機(株)製データ収集ミドルウェア「MELDAS」を採用した。MELDASは共有メモリ上に仮想化したバイナリファイルを構築することが可能であり、数万点の計測信号に対して、1秒未満のデータアクセス性能を実現することが可能である。リアルタイムのデータ監視に利用したデータは、その後計測値として保管するために、データベースに書き込んでおく必要がある。また、データベースに保管されている過去の計測値を用いて、データ監視に必要な数値を計算するために、データベースの値を読み込む必要もある。図3にイメージを示す。策定時に算出された指令値を、制御装置へ送信する。(4)収集データシステム内で計算される運用計画、指令値や、制御装置から受信するプロセス値、アラームを指す。データの制御や監視に必要なデータも含まれていることから、高速にアクセスされる必要がある。本データは、システムの外部へも公開している。(5)OPC通信処理OPC-GWに実装されている処理であり、OPCサーバとの入出力を中継する処理である。(6)画面制御処理Webサーバの主となる処理であり、端末からの要求に基づき、各種画面の制御を行う。(7)HTML/スクリプト予め用意されたHTML・スクリプト群であり、端末上のブラウザからダウンロードすることにより、これらのファイルが読み込まれ、系統図や、各種データ設定を行うための汎用画面を表示することができる。なお、これらのファイルは、発電設備ごとのカスタマイズが必要となる。3.システム開発上の課題3.1 高速かつ汎用的な運転データアクセスの実現本システムは、自家発電設備の制御に利用される。したがって、設備異常の発生時、制御装置への指令値出力を停止する等、適切な処置が行えるよう高速に運転データを蓄積し監視する必要がある。一方で、運転データを外部システムで利用可能とするためには、蓄積した運転データを汎用的な通信仕様で公開しなければならない。端末WebサーバOPC-GW制御装置OPCサーバ系統図汎用画面(5)OPC通信処理(6)画面制御処理ダウンロード要求・応答制御装置用プロトコルEMSサーバ(1)最適化計算処理(2)リアルタイム計算処理(3)対制御装置データ処理(4)収集データ最適化モデル外部システム生成制御装置用プロトコル要求・応答要求・応答通信データアクセス生成/ダウンロード処理装置ファイルデータ(7)HTML/スクリプト凡例図2.ソフトウェア構成34発電設備最適運用システム(BTG-EMS)の開発さらに、計測信号の数値を保存するテーブル内の構造についても、性能が低下しないよう配慮した設計を行っている。本テーブルは、時刻をキーとして、グラフ等で一定期間内のデータを画面表示する機能を実現している。この場合、カラムが計測信号ごとの値となり、性能目標を満たすには1テーブルに数万件のカラムを実装することになる。しかし、PostgreSQLのカラム最大数は1,600件となっており、そのままでは実現は不可能である。そこで、図5のように信号の種別ごとに全点のデータを1つの配列にまとめ、データを格納した。FDW機能を活用したデータ入出力処理の性能評価結果を次に示す。表1の結果から、1件当たりのデータベース書き込み時間は1秒以内に収まった。また、表2の結果から、1件当たりのデータ入出力は1秒以内となった。以上の評価結果より、MELDASのバイナリファイルとPostgreSQLのデータベースとの連係に必要な性能目標を満足することができた。4.2 最適化モデル設計作業の効率化4.2.1 設計作業の概要と作業フロー本システムでは、工場の設備配管系統や、特性等を数式にモデル化した「最適化モデル」を実装する。この最適化モデルは、自家発電設備の設計図面だけではなく、実際の運このような要件から、高速かつ汎用的なデータアクセスを実現すべく、MELDASのバイナリファイルと、データベースとの連係部分の開発を行った。連係部分で実現する性能目標を以下に示す。(目標1)370,000点の計測信号を1秒以内にデータベースに書き込めること。(目標2)37,000点のデータ監視用の数値計算を行う信号について1秒以内にデータベースからMELDASへ読み書きできること。4.1.2 開発内容と評価前項で示した性能目標を満たすため、PostgreSQLの拡張機能であるForeign Data Wrapper(FDW)(注2)機能を活用し、独自のラッパープログラムを作成した。本ラッパープログラムにより、SQLで共有メモリ上の仮想ファイルを使用可能とした。ラッパープログラムのイメージを図4に示す。収集データ制御装置MELDAS監視用系統図外部システム汎用的なデータアクセス【要件】制御装置から入力されたデータをリアルタイムに監視したい。【要件】外部システムで収集データを利用したい。PostgreSQLデータ保管やデータ計算のためにMELDASとPostgreSQL間の連係が必要図3.データアクセスの要件0001 000f0c00 1fff1e11 …共有メモリバイナリファイルFAIVALMELDASでは、共有メモリ上のデータを仮想ファイルとして取り扱うことが可能PostgreSQLFDW本システム開発時にMELDASの外部データラッパー(FDW)を開発aival real[37000]meldas_aivaldate timestamp (KEY)aival real[37000]aists smallint[37000]dival bool[37000]dists smallint[37000]valueinsert into value(select * from meldas_aival);FDWを開発することで、PostgreSQL上で、MELDASの仮想ファイルをテーブルのように扱えるようにした。PostgreSQL上から見た場合図4.MELDAS-PostgreSQL間データ連係イメージ(注2)他のデータベースやファイルに格納されているデータをPostgreSQL上からアクセスできる機能測定時刻信号1 信号2 … 信号370002019-10-11 14:00:00 341.1 21.1 … true2019-10-11 14:01:00 340.8 21.2 … trueカラムを37000件も配置することができない!測定時刻アナログ信号デジタル信号2019-10-11 14:00:00 {341.1, 21.1,…} {…,true}2019-10-11 14:01:00 {340.8, 21.2,…} {…,true}値を配列で持つことにより、カラムの上限制約を回避図5.テーブル構造設計の問題点と解決策項目要求値測定結果データベースへの書き込み(1件当たりの書き込み時間)1[s] 32[ms]※計測信号点数:370,000点で測定表1.性能評価結果(データベースの書き込み)項目要求値測定結果MELDASの書き込み(1件当たりの書き込み時間)1[s] 44[ms]MELDASからの読み込み(100件当たりの読み込み時間)1[s] 20[ms]※数値計算用信号点数:37,000点で測定表2.性能評価結果(MELDASへの読み書き)35発電設備最適運用システム(BTG-EMS)の開発4.3 制御装置通信への汎用プロトコルの適用自家発電設備制御装置の納入メーカは、多岐にわたる。各メーカの通信仕様に合わせたデータ入出力処理を実装すると、納入先ごとに本システムのカスタマイズが生じ、コスト増加や、作業に伴う品質問題の発生リスクが生じる。そこで、本システムでは納入先ごとのカスタマイズを最小限に抑えることを目的に、制御装置で一般的に対応しているプロトコルを採用することとした。一般的なプロトコルの一覧を表3に示す。転データを利用し設計する必要がある。最適化モデル設計作業の流れを、図6に示す。(1)設計図面による仮の最適化モデル作成自家発電設備の設計図面よりモデル化する対象機器を決定し、仮の最適化モデルを作成する。(2)運転データによるモデル評価と修正対象機器の運転データに異常値などが含まれていないか精査した上で、仮の最適化モデルへ代入し、最適化モデルが自家発電設備を模擬できているか評価する。モデルに問題がある場合は修正し、(2)をやり直す。(3)最適化計算によるモデル評価と修正(2)の最適化モデルを使用して最適化計算を行い、算出された運用計画について最適化の効果が表れているか評価する。運用計画を求められない場合、または最適化の効果が十分に表れていない場合はモデルを修正し、(2)からやり直す。4.2.2 作業フローの改善前項の最適化モデル設計作業フローにおいて、(2)の作業で問題が発見された。本作業では、1週間×4パターン(季節等)における運転データの精査を行う。この精査作業は、データの測定精度が疑われる値(異常値)や設備停止等により変動したデータ(特異値)を取り除くものである。運転データは小規模の設備でも100点×1時間値のデータ量となるが、開発当初は目視で、これらの値を除去していた。そのため、運用計画を算出した後に、運転データに異常値が含まれていることが判明し、手戻りが生じていた。そこで、図7に示すように、運転データ間の因果関係から、プラント構成上で想定される値や、適正な設備運用を行っている場合に想定される上下限値を設定することで、運転データを可視化できるツールを作成した。このツールにより、運用計画算出前に、特異値・異常値を確認し、除去することができるようにした。(1)設計図面による仮の最適化モデル作成(3)最適化計算によるモデル評価と修正(2)運転データによるモデル評価と修正NG図6.最適化モデル設計作業フロー改善前① 予めデータの因果関係より、許容される上下限を設定 (例)下記の例であれば、再熱蒸気流量の上限は、主蒸気流量の値とする。① 大量にあるデータをモデルに適合 しているか目視で確認し、評価目視確認② 最適化計算を実行し、運用計画を 算出すると、エラーが発生。③ エラー箇所をチェックすると、タービンに関する値が、不正であることが判明。 要因調査し、最適化モデルを修正すると、今度は異なる箇所でエラーが発生。④ ②~③を繰り返す。② ツールを実行させ、上下限のチェックを行う。 ※チェック結果は、上記例の様に、背景色を変更する。③ チェック結果を確認し、要因調査の上、最適化モデルの 修正を行う。④ 運用計画算出では、エラーが起こらず、モデルの設計が完了する。改善後大きく乖離しているデータは、目視で確認の上、除去していた。プラント構成上想定される値や、適正な運用を行った場合の範囲について、火力発電所向けの他システムで培ったノウハウを元に想定し、上下限を設定図7.最適化モデル設計作業フローの改善点プロトコル特徴OPC-DA(OPC Classic)Windowsに搭載されているOLEとよばれる技術を利用して、通信を行う。OPC-UA OPC-DAをOSに依存せず利用できるよう、拡張したプロトコル。OPC-DAに対して上位互換性を持つ。近年、対応できる制御装置が増加。Modbus TCP シリアル接続で使用されていたプロトコルであるModbusをEthernet上へ適用したもの。SLMP 三菱電機(株)製のプロトコルであるCC-Linkを利用している制御ネットワークとEthernet間のデータを通信できるようにするプロトコル。FL-net サイクリック通信とよばれる定周期通信を行い、ネットワークに接続された装置間でデータを共有する。伝送路を他のEthernet通信と共有することができない制約がある。表3.一般的な制御装置用通信プロトコル36発電設備最適運用システム(BTG-EMS)の開発将来的には、一覧に示した全プロトコルについて対応する必要があるが、本開発では、現時点で自家発電設備の制御装置に広く搭載されるプロトコルであるOPC-DAについて、他の一般的なプロトコルへの対応に先行して実装した。なお、今後、プロトコルの拡張に対応できるよう、データ入出力処理において、信号ごとに受信元設備と対応するプロトコルを選択できるような仕組みを実装している。4.4 仮想化技術の適用本システムでは、ハードウェアの耐用年数を10年として推奨しており、耐用年数を過ぎた場合は、ハードウェア更新が必要となる。図8に示すように、従来、ハードウェア更新の際は、ドライバ等、OSを構成するモジュールの変更が生じ、ソフトウェアの改造が必要であった。本システムでは、ハードウェア更新時に、このようなソフトウェア改造が不要となるよう仮想化技術を適用した。4.5 現地改造を支援するツールの開発4.5.1 改造作業の概要自家発電設備は、測定方法の変更や設備自体の改造等により、監視や制御に利用している信号の情報が変化する場合や、信号自体が追加・削除される場合がある。本システムも、その影響で画面変更・計算式変更といった改造作業が必要となる。これらの改造作業は自家発電設備の特性調整なども関係するため、現地で行うことが必要となる。その際、システムの停止が許される短時間での作業を余儀なくされるため、確実に作業を行うことが求められる。本システムでは、現地改造作業を短時間で、確実に実施できるツール群を準備した。4.5.2 改造作業を支援するツールの概要以下に、ツール群について説明する。(1)系統図作成ツールWindowsが搭載されているPCで作成した系統図画面を、Web上で表示できる形式へ変換するツールである。本ツールのイメージを、図9に示す。(2)汎用画面定義生成ツール系統図以外の画面について、画面要素(テーブル、ボタン等)を定義すると、HTMLを自動生成できるツールである。本ツールのイメージを、図10に示す。(3)計算式グラフィカルエディタツール監視及び制御に必要な計算処理を作成するツールである。本ツールでは、計算式が図で表現され、ツール上でハードウェアOSドライバBTG-EMSハードウェアOSドライバBTG-EMSハードウェア更新→ハードウェア更新により、OSを構成するモジュールが影響を受け動作しなくなるため、OS更新や、アプリケーションの改造が必要となる。ハードウェアゲストOSドライバBTG-EMSハードウェアゲストOSBTG-EMSハードウェア更新→ハードウェア更新により、影響を受けるのは仮想化ソフトウェアのみ。アプリケーションに影響を与えないため、改造作業が不要。仮想化ソフトウェアドライバ仮想化ソフトウェア★物理マシン上にシステムを構築した場合★仮想マシン上にシステムを構築した場合凡例: 更新対象 影響範囲図8.仮想化の目的系統図エディタ系統図画面データ(中間ファイル)系統図変換ソフトウェアスクリプト言語ソースファイル①PC上で系統図を編集②系統図画面データを Web上で表示できる形式に変換図9.系統図作成ツールCSVファイル画面表示スクリプト②画面表示時にCSVファイルをダウンロードし、スクリプトで解析画面要素定義ファイル①PC上で画面要素を定義HTMLファイル③解析結果を元に HTMLファイルを 自動生成図10.汎用画面定義生成ツール37発電設備最適運用システム(BTG-EMS)の開発執筆者紹介岩田 歩 イワタ アユム2010年入社。火力発電所向けシミュレータシステム及びプラント計算機システムのソフトウェア開発に従事。現在、神戸事業所技術第1部発電計算機システム課。作図を行うことで、所望の計算処理を作成できる。本ツールのイメージを、図11に示す。本ツール群を実装することにより、短時間で正確な改造作業を行えるよう改善を図った。5.今後の開発の動向本システムに対する新たな要望として、「複数の工場に対応した運用計画算出」と、「システムのクラウド化」の2点が挙がっている。(1)複数の工場に対応した運用計画算出工場が複数ある場合、工場間の電力融通を考慮し、事業者全体の視点からエネルギーコストの低減を図るための計算手法の開発が求められている。(2)システムのクラウド化工場から離れた事業拠点でも使用できるようクラウド化のニーズがあり、遠隔地からのプラント制御を行うための性能面やセキュリティ面における対応が急務である。今後は、このような要望に対する開発を実施していくことで、自家発電設備を持つ事業者のニーズに応えるとともに、本システムの受注拡大に貢献していく。6.むすび本開発遂行に当たり、貴重な御意見、御指導をいただいた関係者の方々に深く感謝申し上げる。計算処理ソフトウェア②エディタ上でコンパイルを行い、 ソフトウェアを生成計算式グラフィカルエディタ①PC上で計算式を編集図11.計算式グラフィカルエディタツール