再生可能エネルギー予測システムの開発

再生可能エネルギー予測システムの開発
１．まえがき
FIT（固定価格買取制度）の導入以降、太陽光をはじめとした風力・地熱・バイオマスなどの再生可能エネルギー（以下、再エネ）の導入量が急速に拡大することにより、電力系統全体に対する再エネによる発電量の割合が増えてきている。特に太陽光、風力による発電量は天候による変動が大きい。そのため、急激な発電量の変動に備えた予備電力の確保、コストの増加や電力系統の周波数変動による電力の品質低下が問題となっている。最小限の予備電力で電力系統の品質を確保するには、天候により変動する再エネ発電量の正確な予測が必要となる。このような背景から、複数の電力会社で再エネの発電量を予測するニーズが高まっている。三菱電機㈱は、これに応えるため、再生可能エネルギー予測システム（以下、本システム）を開発した。本システムの開発において、当所はアプリケーションとインフラのソフトウェア開発を担当した。本システムは複数電力会社への展開を視野に入れたパッケージ開発を行い、2014～2016年度にかけ複数電力会社へ納入した。本稿では本システムの開発における取り組みと課題、対策について紹介する。
２．システム概要
本システムの代表的な構成を図1に示す。本システムは外部システムから日本とその近海の気象予報データ（GSM,MSM（注1））を受信し、各発電所の発電能力から太陽光発電所及び風力発電所の発電出力予測を算出する。太陽光発電所では、雲量の気象予報データを元に地上面に対する日射量を算出し、算出した日射量から太陽光発電所の発電出力予測を算出する。風力発電所では風速及び風向の気象予報データより、風力発電の発電出力予測を算出する。気象予報データを使用した予測では、気象予報の対象期間に応じ、264時間先と39時間先までの発電出力予測を算出する（注2）。また、リアルタイムに受信する気象実績データと発電出力実績データを使用し、12時間先までの発電出力予測を算出する。算出した発電出力予測データは中央給電指令所に送信し、電力広域的運営推進機関向けの発電計画立案などに活用される。本システムのヒューマンマシンインタフェース（以下、HMI）はクライアント・サーバシステムを採用し、ブラウザを用いて複数の端末から閲覧可能である。本システムの特徴を以下に示す。（1）過去データの学習による予測精度向上過去の気象予報データ、気象実績データ、発電出力実績データから各発電所や地域の特性を学習し、予測精度の向上を実現している。本システムでは最大10年間の過去データを蓄積し、至近3年分のデータを対象に学習を行っている。（2）外部システムインタフェースのカスタマイズ納入先電力会社により外部システムとのインタフェース仕様が異なる。この差異を外部システムインタフェース部分のカスタマイズで吸収し、4.1節で後述する予測機能とデータベースのパッケージ化を実現している。一般論文再生可能エネルギー予測システムの開発神戸事業所　技術第3部　電力システム第3課大谷 晃平１．まえがきFIT（固定価格買取制度）の導入以降、太陽光をはじめとした風力・地熱・バイオマスなどの再生可能エネルギー（以下、再エネ）の導入量が急速に拡大することにより、電力系統全体に対する再エネによる発電量の割合が増えてきている。特に太陽光、風力による発電量は天候による変動が大きい。そのため、急激な発電量の変動に備えた予備電力の確保、コストの増加や電力系統の周波数変動による電力の品質低下が問題となっている。最小限の予備電力で電力系統の品質を確保するには、天候により変動する再エネ発電量の正確な予測が必要となる。このような背景から、複数の電力会社で再エネの発電量を予測するニーズが高まっている。三菱電機㈱は、これに応えるため、再生可能エネルギー予測システム（以下、本システム）を開発した。本システムの開発において、当所はアプリケーションとインフラのソフトウェア開発を担当した。本システムは複数電力会社への展開を視野に入れたパッケージ開発を行い、2014～2016 年度にかけ複数電力会社へ納入した。本稿では本システムの開発における取り組みと課題、対策について紹介する。２．システム概要本システムの代表的な構成を図1 に示す。本システムは外部システムから日本とその近海の気象予報データ（GSM,MSM（注1））を受信し、各発電所の発電能力から太陽光発電所及び風力発電所の発電出力予測を算出する。太陽光発電所については、雲量の気象予報データを元に地上面に対する日射量を算出し、算出した日射量から太陽光発電所の発電出力予測を算出する。風力発電所については風速及び風向の気象予報データより、風力発電の発電出力予測を算出する。気象予報データを使用した予測では、気象予報の対象期間に応じ、264時間先と39時間先までの発電出力予測を算出する（注2）。また、リアルタイムに受信する気象実績データと発電出力実績データを使用し、12時間先までの発電出力予測を算出する。算出した発電出力予測データは中央給電指令所に送信し、電力広域的運営推進機関向けの発電計画立案などに活用される。本システムのヒューマンマシンインタフェース（以下、HMI）はクライアント・サーバシステムを採用し、ブラウザを用いて複数の端末から閲覧可能である。本システムの特徴を以下に示す。(1)過去データの学習による予測精度向上過去の気象予報データ、気象実績データ、発電出力実績データから各発電所や地域の特性を学習し、予測精度の向上を実現している。本システムでは最大10年間の過去データを蓄積し、至近3年分のデータを対象に学習を行っている。(2)外部システムインタフェースのカスタマイズ納入先電力会社により外部システムとのインタフェース仕様が異なる。この差異を外部システムインタフェース部分のカスタマイズで吸収し、4.1節で後述する予測機能とデータベースのパッケージ化を実現している。（注1）気象庁の数値予報モデルGSM：地球全体が対象。格子間隔は20kmMSM：日本とその近海が対象。格子間隔は5km図１．再エネ予測システム概略構成図再生可能エネルギー予測システムの開発神戸事業所 技術第３部 電力システム第３課大谷 晃平（注2）納入先電力会社が使用している気象予報データの長さに応じ、算出する予測対象期間が異なる図１．再エネ予測システム概略構成図（注１）気象庁の数値予報モデルGSM：地球全体が対象。格子間隔は20kmMSM：日本とその近海が対象。格子間隔は5km（注２）納入先電力会社が使用している気象予報データの長さに応じ、算出する予測対象期間が異なる53再生可能エネルギー予測システムの開発３．ソフトウェア構成本システムのソフトウェア構成を図2に示す。本システムは、動作環境に仮想化技術を採用している。仮想マシン上のインフラ環境には三菱電機㈱の第4世代ミドルウェア（以下、MW）であるMoove（Middleware for OpensourceOriented Virtual Environment）を採用し、本システムの構成制御・インフラ管理を実現している。R D B M S（Relational Database Management System）にはPostgreSQLを採用した。次期システム開発時やハードウェアの更新時には、仮想マシンを移植しIPアドレスなどの最低限の設定変更のみで、新しいマシンに上記環境が構築できる。アプリケーションは、システム管理機能、HMI機能、予測機能、データベースインタフェース機能（以下、DBI機能）で構成される。システム管理機能と予測機能、DBI機能は、MWでサポートされているC言語で開発した。HMI機能はWebアプリケーション開発に適したJavaを採用し、クライアント側とサーバ側をそれぞれJava8.20、Java7.55で開発した（詳細は4.2節に記載）。予測機能は、三菱電機㈱情報技術総合研究所考案のロジックを実装した。当所は、システム管理機能、HMI機能、DBI機能、構成制御機能の開発を担当した。４．当所担当機能の特徴当所で担当した機能のうち、本稿では特に新規開発要素が多かった、システム管理機能、HMI機能の特徴を紹介する。4.1　システム管理機能システム管理機能は、主に本システムの入出力データを管理する機能であり、外部システムとのインターフェース機能を有している。2章（2）で述べたとおり、納入先電力会社により外部システムとのインタフェース仕様が異なるため、本機能で各外部システムとの入出力データの差異を吸収している。外部システムのインタフェースのデータ形式は、納入先に応じてCSVファイルやバイナリファイル、画像ファイル、xmlファイルなどがある。本機能を各データ形式に合わせカスタマイズし、数値データに変換してデータベースに保存している。また、データ転送プロトコルは納入先に応じてFTP（File Transfer Protocol）やhttp（Hypertext Transfer Protocol）で実装している。4.2　HMI機能本システムのHMIは、クライアント-サーバシステムを採用しており、複数端末からブラウザで画面を閲覧できる。クライアント側のアプレットは、Java8.20に標準搭載されたRIA（Rich Internet Application）（注3）ライブラリであるJavaFX2.0を採用した。JavaFX2.0を使用することで、従来使用してきたJavaのGUI（Graphical User Interface）ツールキットであるAWT（Abstract Window Toolkit）、Swing（注4）に比べ、低コストで高機能かつ視認性が高い画面を実現している。サーバ側のサーブレットはMWでサポートされているJava7.55を採用した。これによりC言語とJavaの差異をMWで吸収させ、C言語で製作した他機能のプログラムの起動やデータ連携などの機能連携を容易にした。また、画面仕様は、三菱電機㈱デザイン研究所と連携して考案した。デザイン研究所との連携とJavaFX2.0の採用により、視認性と使用性が高いユーザインタフェースを実現した。５．本システム開発における取り組み当所が担当した機能のうち、5.1節にシステム管理機能、5.2節に機能共通のデータベース設計における取り組みを述べる。5.1　気象予報データの読み込み納入先のひとつで採用している気象予報データは、日本とその近海の数値予報データを20kmまたは5kmの格子点で分割し、国際気象通報式FM92 GRIB 二進形式格子点資料気象通報式（第2版）（以下、GRIB2））という国際規格でエ（注３）RIA：表現力豊かなWebアプリケーション（注４）AWT：JavaのGUIツールキットSwing：AWTを拡張したJavaのGUIツールキット図２．ソフトウェア構成３．ソフトウェア構成本システムのソフトウェア構成を図2に示す。本システムは、動作環境に仮想化技術を採用している。仮想マシン上のインフラ環境には三菱電機㈱の第４世代ミドルウェア（ 以降MW ） であるMoove(Middleware forOpensource Oriented Virtual Environment）を採用し、本システムの構成制御・インフラ管理を実現している。RDBMS（Relational Database Management System）にはPostgreSQLを採用した。次期システム開発時やハードウェアの更新時には、仮想マシンを移植しIPアドレスなどの最低限の設定変更のみで、新しいマシンに上記環境が構築できる。アプリケーションはシステム管理機能、HMI機能、予測機能、データベースインタフェース機能（以下、DBI機能）で構成される。システム管理機能と予測機能、DBI機能はMWでサポートされているC言語で開発した。HMI機能はWebアプリケーション開発に適したJavaを採用し、クライアント側とサーバ側をそれぞれJava8.20、Java7.55で開発した（詳細は4.2節に記載）。予測機能は三菱電機㈱情報技術総合研究所考案のロジックを実装した。当所はシステム管理機能、HMI機能、DBI機能、構成制御機能の開発を担当した。図2．ソフトウェア構成４．当所担当機能の特徴当所で担当した機能のうち、本稿では特に新規開発要素が多かった、システム管理機能、HMI機能の特徴を紹介する。４．１ システム管理機能システム管理機能は、主に本システムの入出力データを管理する機能であり、外部システムとのインターフェース機能を有している。2章(2)で述べたとおり、納入先電力会社により外部システムとのインタフェース仕様が異なるため、本機能で各外部システムとの入出力データの差異を吸収している。外部システムとのインタフェースのデータ形式は納入先に応じてCSVファイルやバイナリファイル、画像ファイル、xmlファイルなどがある。本機能を各データ形式に合わせカスタマイズし、数値データに変換してデータベースに保存している。また、データ転送プロトコルは納入先に応じてFTP(File TransferProtocol)やhttp(Hypertext Transfer Protocol)で実装している。４．２ HMI機能本システムのHMIはクライアント-サーバシステムを採用しており、複数端末からブラウザで画面を閲覧できる。クライアント側のアプレットは、Java8.20に標準搭載されたRIA（Rich Internet Application）（注3）ライブラリであるJavaFX2.0を採用した。JavaFX2.0を使用することで、従来使用してきたJavaのGUI(Graphical User Interface)ツールキットであるAWT(Abstract Window Toolkit)、Swing（注4）に比べ、低コストで高機能かつ視認性が高い画面を実現している。サーバ側のサーブレットはMWでサポートされているJava7.55を採用した。これによりＣ言語とJavaの差異をMWで吸収させ、C言語で製作した他機能のプログラムの起動やデータ連携などの機能連携を容易にした。また、画面仕様は三菱電機㈱デザイン研究所と連携して考案した。デザイン研究所との連携とJavaFX2.0の採用により、視認性と使用性が高いユーザインタフェースを実現した。５． 本システム開発における取り組み当所が担当した機能のうち、5.1節にシステム管理機能、5.2節に機能共通のデータベース設計における取り組みを述べる。５．１ 気象予報データの読み込み納入先のひとつで採用している気象予報データは、日本とその近海の数値予報データを20kmまたは5kｍの格子点で分割し、国際気象通報式FM92 GRIB 二進形アプリケーション（FSM, HMI, DBI .EFA）※2（注4）AWT：Java のGUI ツールキットSwing：AWT を拡張したJava のGUI ツールキット（注3）RIA：表現力豊かなWeb アプリケーションMoove(MW)（SCN 含む）※1ホストOS(CentOS5.9 or 7.0)PostgreSQL9.2.4仮想マシン ゲストOS(CentOS5.9)Java 7.55ソフトウェア構成（サーバ）※1 SCN：構成制御機能※2 FSM：システム管理機能 DBI：データベースインタフェース機能EFA：予測機能 HMI：ヒューマンマシンインタフェース機能インフラOS(Windows7)Java 8.20アプリケーション（HMI のみ）ソフトウェア構成（クライアント）54再生可能エネルギー予測システムの開発ンコードしたバイナリファイルである。GRIB2形式は当部門で扱った実績がないデータ形式であり、データのデコードと予測対象領域を切り出す仕組みを検討した。確立した仕組みを以下に述べる。まず、予測対象領域の緯度経度を決定した（図3①）。次に予測対象領域の緯度経度情報を定義ファイルに定義した（図3②）。最後に、GRIB2形式データのデコーダであるwgrib2（注5）のCSV出力機能を使用し、予測対象領域のデータをCSVファイルに出力した（図3③）。このCSVファイルをプログラムがリードすることで、GRIB2形式の気象予報データから数値データ読み込みが可能となった。5.2 　データベース設計本システムでは、最大10年分のデータを保存するため、蓄積データ量の増加に伴うデータベース容量とレコード数増加による応答性に関する課題があった。この課題に対する取り組みを以下に述べる。（1）レコード数削減の設計本システムで扱うデータの最小粒度は3秒値であり、10年分保存すると膨大なデータ量、レコード数となる。一般的にはレコード数が増加すると、SQLの応答性能が悪くなる。また、本システムの予測計算では、30分平均値も必要であり、テーブル数とレコード数を少なくするデータベース設計が必要であった。図4に示すとおり、1レコードに3秒値を30分まとめて配列でパッキングし、30分値平均も同じレコードに定義した。この設計により、1発電所30分当たり約600レコードの削減を実現した。また、1回のSQL文発行で3秒値と30分平均値を取得可能とし、処理の効率化を図った。（2）ディスクへの並列アクセス本システムの予測機能は、過去3年分のデータをデータベースから取得し、予測計算を行っている。最短計算周期である30分以内に予測計算を終了させる必要があるため、複数プロセスの並列処理で高速化を図っている。並列処理でデータベースアクセスを行う場合、ディスクI/Oの待ち時間が発生するリスクがあった。そのためディスクアクセス待ち時間発生の対策として、データを種類と期間ごとに分割し、複数ディスクに分散して保存する設計とした。アプリケーションでは、過去の特定期間に対して複数種類のデータを取得する処理が多いことから、各時系列データを月単位のテーブルに分割し、3つのディスクに分散して保存する設計とした。これにより同一期間のデータを取得する際、特定のディスクへのアクセスを分散させることができる。例えば図5に示すとおり、データ①、データ②の2月データを取得する場合、ディスク1、ディスク2に並行してアクセス可能となり、ディスクI/Oの待ち時間を削減できた。120.0E 150.0E50.0N20.0N87～264Hr先1～84Hr先②予測対象領域緯度経度の定義CSVファイル予測対象時間ごとのバイナリファイル（GRIB2 形式）定義ファイルフイル①予測対象領域の決定③デコード結果をCSV ファイルに出wgrib2(デコーダ))図３．気象予報データの読み込み図４．レコード数・テーブル数削減のための設計（注５）wgrib2：アメリカ国立気象局が公開しているGRIB2形式ファイルのデコーダ55再生可能エネルギー予測システムの開発６．開発上の課題と対策本システム開発における課題と対策を以下に述べる。6.1　HMI機能の性能改善HMI機能では、画面に大量データを表示する際、著しい表示速度の低下が発生し、本現象の改善が課題であった。4.2節で述べたとおり、HMI機能の開発にはJavaFX2.0を採用したが、本ライブラリは従来使用してきたAWTやSwingに比べ、メモリ上のJavaヒープ領域を多く使用する傾向がある。Javaヒープ領域が満杯になると、FullGC（注6）が発生しJavaヒープ領域をクリアする。FullGC中はJavaアプリケーションが停止するため、FullGCが短時間に頻発したことで画面の性能が悪化した。上記問題の原因と対策を図6に説明する。メモリ上のJavaヒープ領域にロードされたオブジェクトは、まずNew領域に保存される（ 図6 ① ）。N e w 領域が満杯になるとScavengeGC（注7）が発生し、プログラムから参照されていない不要なオブジェクトをNew領域からクリアする（図6②）。ScavengeGC 発生時に規定回数以上New領域に保持され続けたオブジェクトはOld領域に移動する（図6③）。Old領域が満杯になると、FullGCが発生し、New領域とOld領域を両方をクリアする（図6④）。FullGCの発生数を削減する対策として、New領域を定義ファイルの変更により拡張するチューニングを行った（図6⑤）。New領域を拡張することで、ScavengeGCの発生を抑え、Old領域にオブジェクトが移動する頻度を削減した。本対策により、FullGCの発生頻度が大幅に減少した。画面に大量データを表示する際の表示速度は60%高速化し、課題を解消することができた。７．むすび本システムは2014～2016年度にかけ複数電力会社へ納入した。今後は当システムのインプットとなる気象予報データにGSM、MSMよりも高精度が期待できるLFM（注8）を導入するなど、予測精度向上へ向けた取り組みを行っていく。最後に、本開発にあたり貴重なご意見、ご指導をいただいた関係者の方々に深く感謝申し上げる。図5．複数ディスクへのデータ分散６． 開発上の課題と対策本システム開発における課題と対策を以下に述べる。６．１ HMI機能の性能改善HMI機能では画面に大量データを表示する際、著しい表示速度の低下が発生し、本現象の改善が課題であった。4.2 節で述べたとおり、HMI 機能の開発にはJavaFX2.0を採用したが、本ライブラリは従来使用してきたAWTやSwingに比べ、メモリ上のJavaヒープ領域を多く使用する傾向がある。Javaヒープ領域が満杯になると、FullGC(注6)が発生しJavaヒープ領域をクリアする。FullGC中はJavaアプリケーションが停止するため、FullGCが短時間に頻発したことで画面の性能が悪化した。上記問題の原因と対策を図6に説明する。メモリ上のJavaヒープ領域にロードされたオブジェクトは、まずNew領域に保存される（図6①）。New領域が満杯になるとScavengeGC（注7）が発生し、プログラムから参照されていない不要なオブジェクトをNew領域からクリアする（図6②）。ScavengeGC 発生時に規定回数以上New領域に保持され続けたオブジェクトはOld領域に移動する（図6③）。Old領域が満杯になると、FullGCが発生し、New領域とOld領域を両方をクリアする（図6④）。FullGCの発生数を削減する対策として、New領域を定義ファイルの変更により拡張するチューニングを行った（図6⑤）。New領域を拡張することで、ScavengeGCの発生を抑え、Old領域にオブジェクトが移動する頻度を削減した。本対策により、FullGCの発生頻度が大幅に減少した。画面に大量データを表示する際の表示速度は60%高速化し、課題を解消することができた。図6．Javaヒープ領域チューニング７．むすび本システムは2014～2016年度にかけ複数電力会社へ納入した。今後は当システムのインプットとなる気象予報データにGSM、MSMよりも高精度が期待できるLFM（注8）を導入するなど、予測精度向上へ向けた取り組みを行っていく。最後に、本開発にあたり貴重なご意見、ご指導をいただいた関係者の方々に深く感謝申し上げる。執筆者紹介大谷 晃平 オオタニ コウヘイ2007年入社。主に電力システムの支援系ソフトウェア開発に従事。現在、神戸事業所技術第３部電力システム第３課。データ① 3 月 データ② 4 月アクセス対象テーブルデータ① 2 月 データ② 3 月データ① 1 月 データ② 2 月データ① 2 月アクセスデータ② 2 月アクセスディスク1アクセス対象テーブルディスク2ディスク3WNew 領域Old 領域1 WW 1 1 1W 1 1 1 1 1 1W①②③④⑤FullGC 発生New 領域が満杯になるNew 領域にScavengeGC発生。プログラムから参照されていない不要なオブジェクトをクリア規定回数ScavengeGC で保持されたオブジェクトはOld 領域へ移動ScavengeGC を繰り返しOld 領域が満杯になるとFullGC が発生New 領域を拡張しOld 領域にオブジェクトが移動しないようチューニング拡張し余裕を持たす1・・・・オブジェクト領域サイズ拡張ロードクリア（注8） LFM：気象庁の数値予報モデル日本とその近海が対象。格子間隔は2km（注6）FullGC:Java ヒープ領域全体を対象にしたガーベジコレクション（注7） ScavengeGC：Java ヒープ領域のNew 領域を対象にしたガーベジコレクションNew 領域Old 領域①②New 領域が満杯になるNew 領域にScavengeGC 発生。プログラムから参照されていない不要なオブジェクトをクリア・・・・オブジェクトロードクリア③規定回数ScavengeGC で保持されたオブジェクトはOld 領域へ移動⑤New 領域を拡張しOld 領域にオブジェクトが移動拡張し余裕を持たす しないようチューニング領域サイズ拡張ScavengeGC を繰り返しOld 領域が満杯になるとFullGC が発生④FullGC 発生図５．複数ディスクへのデータ分散図６．Javaヒープ領域チューニング（注６）FullGC：Javaヒープ領域全体を対象にしたガーベジコレクション（注７）ScavengeGC：Javaヒープ領域のNew領域を対象にしたガーベジコレクション（注８）LFM：気象庁の数値予報モデル日本とその近海が対象。格子間隔は2km執筆者紹介大谷　晃平 オオタニ　コウヘイ2007年入社。主に電力システムの支援系ソフトウェア開発に従事。現在、神戸事業所技術第3部電力システム第3課。