まとめ
この記事では主に、共有エネルギー貯蔵 SCADA システムのビッグ データ アーキテクチャ、Honghu を使用して SCADA システムの機能をより適切に最適化する方法、およびユーザーにセルフサービス データ分析を提供する方法を紹介します。
1. 共有エネルギー貯蔵の概要
共用蓄電というと馴染みのない方も多いと思いますが、共用蓄電の価値と今後の技術開発の方向性について簡単にご紹介します。
1.1 共有エネルギー貯蔵の価値
エネルギー貯蔵技術には大きな価値があり、エネルギー貯蔵には 4 つの基本機能があります。1 つはピークカットとバレーフィリング、2 つ目は仮想同期、3 つ目は正確な制御性、4 つ目は系統コマンドと負荷制御への応答です。エネルギー貯蔵のビジネスモデルは、当初は電力供給側に設置される電力供給側で利用されていましたが、2019年6月に系統側に移され、系統から送電されるシェアードエネルギー貯蔵と呼ばれています。共有エネルギー貯蔵は送電網によって供給されます。
「共有エネルギー貯蔵」ビジネスモデルは、すべての関係者のニーズを完全に考慮しています。
国際的な観点から見ると、テスラは 2021 年に合計 4 GWh のエネルギー貯蔵プロジェクトを展開する予定で、2030 年の目標である 1,500 GWh は、比較すると 375 倍に増加しています。市場の需要が生産能力を上回り続ける中、テスラのエネルギー貯蔵事業の成長はサプライチェーンの課題によって依然として制限されている。
2020年にテスラの米国公式ウェブサイトで産業用バッテリーエネルギー貯蔵システム「メガパック」が正式に発売される予定で、価格は100万ドルからで、企業向けにのみ販売されているが、依然として好調に売れている。同年の第2四半期の決算会見でマスク氏は、メガパックの2022年末までの生産能力が完売したことを明らかにした。
国内では、2021年4月21日、国家発展改革委員会と国家能源局は「新エネルギー貯蔵開発の加速に関する指導意見（コメント草案）」（以下「コメント草案」という）を発表した。 。「コメント草案」では、2025年までに新エネルギー貯蔵の商業化の初期段階から大規模開発への転換が実現し、新エネルギー貯蔵の設備容量が3,000万キロワット以上に達すると提案している。
2030年までに新エネルギー貯蔵の包括的な市場開発を実現する。
以下の図は、将来の共用型蓄電市場における各国の設備容量に関するブルームバーグの予測を示しており、中国であろうと米国であろうと、将来の蓄電市場は少なくとも兆レベルの市場になることがわかります。天井は十分に高いです。新エネルギーが急増するこの時代において、共有エネルギー貯蔵は新しい電力システムの基本要素となっています。
(出典: ブルームバーグ)
1.2 バッテリーエネルギー貯蔵は技術開発の未来である
一般的に言えば、現在、共有エネルギー貯蔵には、機械的エネルギー貯蔵、電磁エネルギー貯蔵、バッテリー (電気化学的とも呼ばれる) エネルギー貯蔵が含まれます。以下の表から、リチウム電池に基づくエネルギー貯蔵技術には明らかな利点があり、現在および将来の共有エネルギー貯蔵の主流でもあることがわかります。
その他には、圧縮空気エネルギー貯蔵、高エネルギーコンデンサエネルギー貯蔵、液体フロー電池エネルギー貯蔵、ナトリウム硫黄電池エネルギー貯蔵、鉛蓄電池エネルギー貯蔵などが含まれます。地理的制約や低比エネルギーなどのさまざまな理由により、それは、業界の主流のテクノロジーではありません。当社の共有エネルギー貯蔵 SCADA システムも、主にリチウム電池の共有エネルギー貯蔵に基づいています。
2. 従来のSCADAシステム
いわゆるSCADA（Supervisor Control And Data Acquisition）データ収集システムは、測定技術、コンピュータ技術、通信技術を統合した包括的な統合制御システムであり、共有エネルギー貯蔵システムのリアルタイムの集中監視と管理スケジューリングを実現できます。
典型的な SCADA は次の図に示されており、ステーション端末と管理端末に分かれています。ステーション側：主に下部コンピュータ、通信ネットワーク、上部コンピュータの 3 つの部分で構成されます。管理端末: 通常、事前取得アプリケーションと SCADA アプリケーションが含まれます。
初期の SCADA システムが直面するデータ量は比較的少なかったため、そのほとんどはスタンドアロンまたは C/S アーキテクチャを使用し、ストレージには一般に MySQL、SQL Server などのリレーショナル データベースを使用していました。収集データの増加に伴い、データを長期間保存することができず、数か月単位の定期的なデータクリーニング戦略を設定することになり、長期にわたるデータの比較分析が必要な場合、その需要に応えることが困難になります。
以下は、お客様が使用している従来の SCADA システムです。
3. ビッグデータプラットフォームに基づく共有エネルギー貯蔵SCADAシステム
さまざまな新エネルギー（風力や太陽光）発電所の建設に伴い、発電所のデータ収集層は大規模なデータ収集と高い収集頻度という特徴を持ち、履歴データベースは必然的に複雑で異種のエネルギー貯蔵ビッグデータを形成します。 SCADA システムは、コンピュータ CPU のアップグレード、メモリ不足、コンピュータ ハードウェアの拡張、コストの増加などの一連の問題に直面し始めました。従来のデータ処理方法では、大規模な共有エネルギー貯蔵ビッグデータを迅速に処理することが困難です。
したがって、当社の共有エネルギー貯蔵の顧客は、ビッグデータ プラットフォームに基づいた共有エネルギー貯蔵 SCADA システムの構築を提案しています。
3.1 全体的なアーキテクチャ
一般的に、共有エネルギー貯蔵発電所は、主に変電および配電設備、エネルギー貯蔵バッテリーパック、エネルギー管理システム（EMS）、バッテリー管理システム（BMS）、エネルギー変換制御システム（PCS）およびSCADAシステムで構成されます。
構築にあたっては、既存の共用型蓄電システムの複雑さと収集拠点の多さを考慮し、主要なデータストレージとして時系列データベースを採用しました。さらに、共有蓄電システムの一般的な要件は、閉鎖環境にあり、インターネットに接続できないことであるため、時刻同期には GPS (Beidou) に基づくタイムサーバーを使用します。
次の図は、当社の共有エネルギー貯蔵 SCADA システムの概略図です。
一部のサードパーティ標準収集ボックスをより便利に統合するために、データ送信のメイン プロトコルとして MQTT プロトコルを使用します。これにより、サードパーティ標準収集ボックスはデータを収集するために簡単に構成するだけで済みます。
取得プログラムをより柔軟に記述するため、開発にはPython言語を使用し、データの表示と分析にはフロントエンドとバックエンドを分離し、バックエンドは主流のJavaフレームワークであるSpring Bootを使用して開発し、フロントエンドはVueを使って。
3.2 データストレージ
収集されたデータは主に InfluxDB に保存されますが、一部の特殊なレポート要件については、定期的にデータを MySQL リレーショナル データベースに ETL 送信します。
InfluxDB のストレージ構造では、一部のクエリの効率が比較的低いため、高速なデータ分析のニーズを満たすために事前に事前計算が実行されます。もちろん、これはビッグ データ システムにとって非常に一般的な要件でもありますが、幸いなことに InfluxDB には Rollup 関数が用意されており、SQL ステートメントを記述することでサンプリング精度とデータ集計方法に応じて便利に事前計算できます。
3.3 ライブ撮影
これは、当社のSCADAシステムを使用した共有エネルギー貯蔵発電所の最初の実際のショットであり、共有エネルギー貯蔵発電所は、基本的に、負荷シェービング、系統コマンドへの応答、および負荷制御という、一般的な共有エネルギー貯蔵発電所の主な機能を備えています。
3.4 システムインターフェース
下図は当社の共同蓄電発電所の主要系統図であり、図中の全てのデータはリアルタイムに収集・表示されます。さらに、顧客のニーズに応じて、いくつかの簡単なシステム相互作用制御をシステム図上で直接実行できます。
一般に、共有エネルギー貯蔵発電所のSCADAシステムのホームページでは、ユーザーは、グリッドコンピュータのAGCコマンドに応答するエネルギー貯蔵システムのリアルタイムの状況を確認し、現在の稼働状況を迅速に分析することを望んでいます。エネルギー貯蔵システムの電力。下の図は、私たちが構築した典型的な SCADA システムのホームページです。
4.Honghu を使用して共有エネルギー貯蔵 SCADA システムを最適化する
新しいビッグデータ製品が中国で発売されたことを知り、それを試してみたいと思っています。もちろん、以前にも他の製品も検討しましたが、価格や使いやすさの点で既存のアーキテクチャと比べて大幅な改善はありませんでした。使用。
4.1 私たちの問題点
ビッグデータプラットフォームに基づいた当社のこれまでの製品は、従来のSCADAシステムに比べて大きく進歩しましたが、まだ不十分な点もいくつかあります。
4.1.1 柔軟性の欠如
共有エネルギー貯蔵SCADAシステムの場合、一般的なSCADAシステムと同じ監視機能を有することに加えて、共有エネルギー貯蔵SCADAシステムが系統の命令に応答してエネルギー貯蔵装置の出力を正確に制御することがより重要である。システム (つまり、前述したエネルギー貯蔵システム。4 つの基本機能のうち、後の 2 つ) は、データ分析サービスを提供し、意思決定を支援します。
共有エネルギー貯蔵システムの完成から約 3 ～ 6 か月後は、系統指令応答アルゴリズムのデバッグ期間に入り、アルゴリズム モデルを調整して最適化するために、電力エンジニアとアルゴリズム エンジニアは引き続き多くの作業を行うことになります。アルゴリズムの調整後にデータが変化した場合、ユーザーはさらに、新しい指標や統計グラフが表示されることを期待します。
すべての統計分析機能は Java コードで実装する必要があるため、ユーザーがさらに多くのデータ分析要件を提出したら、要件を再スケジュールする必要があります。WYSIWYG 補助データ分析ツールがあれば、明らかに、一時的および探索的な分析ニーズをより適切に満たすことができます。共有エネルギー貯蔵システムのアルゴリズム モデルのデバッグの進行を加速します。
4.1.2 ETL の依存関係
当社のコア収集データは InfluxDB に保存されていますが、現在の蓄電発電所の 1 日当たりの収集データ量は約 8 ～ 12 GB であり、現在、最初の共用蓄電発電所 SCADA システムを構築し、1 年間運用した後、蓄積されたデータは約 3TB です。SQL を介して一部のレポートについて InfluxDB に直接クエリするのは非効率であるため、比較的複雑な分析とレポートの要件を満たすために、ETL スクリプトを介して統計レポート データの一部を InfluxDB から MySQL に抽出します。
4.1.3 拡張にはコストがかかる
データ量が増えると、将来的にInfluxDBクラスターを使用したい場合、コストがかなり高くなります。InfluxDB のコミュニティ版はクラスターモードをサポートしていないため、クラスターモードをサポートする InfluxDB Enterprise Edition について関連チャネルに問い合わせましたが、価格は 100 万に達する可能性があると言われており、SCADA システムとしては明らかに手が届きません。
4.2 選択の比較
柔軟性の向上、ETL への依存の軽減、合理的なコストなどのいくつかの要因に基づいて、ETL プロセスとモデルをより柔軟に保存できる ElasticSearch、Splunk、およびその他の製品を好みます。私たちは最近、業界の友人から学びました。中国は Splunk よりも優れた製品、Honghu Community Edition をリリースしました。私はそれを試してみたくて仕方ありません。特にHonghuの読み取り時間モデリングとベクトルアクセラレーションの特性を見ると、これまでの問題点を明らかに解決できます。
4.2.1 読み取り時のモデリング
公式ドキュメントの説明によると、「読み込み中モード」とは、データを検索しながら生データから有用なフィールド（フィールド）を抽出する技術です。ETL部分を省略できるため、データインポートのオーバーヘッドを大幅に削減できます。これは、SCADA システム ユーザーの一時的および探索的なニーズに非常に適しています。
特にデータ収集がプラットフォームに入ると、元のデータが直接保存され、いくつかの列フィールド抽出ルールを定義することで、クエリ時に参照されるルールに従って元のデータからフィールド値が動的に抽出されます。
(この写真は紅湖の公式文書より)
4.2.2 ベクトル加速
使用を通じて、Honghu システムの非常に重要な特徴もわかりました。それは、CPU の SIMD (単一命令複数データ) 命令を最大限に活用できるベクトル加速コンピューティングの使用です。この種の命令は 1 つの命令で複数のデータを同時に操作できるため、データ処理のパフォーマンスが大幅に向上します。そのため、Honghu はインストール時に CPU が AVX2 命令セットをサポートすることを要求しています。
4.3 新しいアーキテクチャ
当社の新しいアーキテクチャは、リレーショナル データベースを Honhu に置き換え、設置容量が小さいエネルギー貯蔵発電所のメイン データ ストレージとしても使用できます。
以下の図に示すように、Honghu との統合により、既存の SCADA システムの柔軟性が向上しました。これは、元のシステムにセルフサービス分析を直接追加するのと同じです。
新しいアーキテクチャでは、Honghu と InfluxDB を連携させます。Honhu を使用すると、一方では MySQL の役割と InfluxDB の事前計算処理の一部が置き換えられますが、他方では、ユーザーが Honhu の管理インターフェイスに直接ログインしてセルフサービス データ分析を実行できるようになります。ユーザーが以前から期待していたもの。
4.4 プロジェクトの統合
ここまで言ってきましたが、システム統合を試すのが待ちきれません。
4.4.1 Honhu システムのインストール
Honhu システムのインストールは非常に簡単です。基本的に、公式ドキュメントに従って段階的に実行できます。システム メモリに必要なのは 8G の制限のみです。携帯電話のメモリが 8G を超える今日の時代でも、まだ必要ありません。非常に良心的な構成要件です。
ただし、Honghu はベクトル コンピューティング テクノロジを使用しているため、公式ドキュメントでは、Honghu Computing Engine がベクトル コンピューティング アクセラレーションに AVX2 高度な命令セットを使用することを示唆しているため、Honghu は AVX2 命令セットをサポートする CPU 上で実行する必要があります。
もちろん、公式ドキュメントにはテスト方法が記載されており、次のコマンドを実行して CPU が AVX2 命令セットをサポートしているかどうかを確認できます。
たまたま古いサーバーが手元にあったので、早速テストしてみました。残念ながら、彼は...協力的ではありません。
すぐにクラウドホストを見つけて完璧に解決しました。
インストールには docker とその他の関連コンポーネントをインストールする必要がありますが、インストールプロセスは非常に簡単で、公式のインストールドキュメント ( https://yanhuang.yuque.com/staff-sbytbc/rb5rur/auwfm3? ) にステップバイステップで従うだけです。
これはインストール完了後のインターフェースですが、まさに「数字が大きくてシンプル」です。
4.4.2 MQTTデータの受信
早速Honghuの機能を試すために、まずはデータを入力する必要がありますが、もちろんお試しであればcsvやjsonなどのファイルでデータをインポートすることも可能です。
以前のアーキテクチャでは、EMQX を使用してさまざまなデバイスからデータを収集するため、試行プロセスでは、単純に EMQX から MQTT データを受信し、Honghu に転送するサービスを開発し、Github プラットフォーム上で公開しました。
開発プロセスは詳細には記載されていませんが、次のアドレスにアクセスして確認およびダウンロードできます。
https://github.com/neulf/mqtt-honghu
4.4.3 データ事前計算技術
データ量が増加したため、通常、InfluxDB での事前計算にはロールアップを使用して、大規模なデータの処理能力を強化し、クエリのパフォーマンスを向上させます。したがって、新しいビッグデータ製品については、当然のことながら、データの事前計算についても非常に懸念しています。
公式ドキュメントから、Honghu はマテリアライズド ビュー、事前保存されたクエリ、スケジュールされたレポートなど、さまざまなデータ事前計算テクノロジを提供していることがわかりました。これらのテクノロジの適用シナリオは公式ドキュメントで確認できるため、ここでは説明しません。ここで繰り返します。
4.4.4 柔軟なクエリ
Bird & Bird は、シンプルなクエリ機能と高度なクエリ機能を提供し、業界で一般的な生産性向上ツールである SQL クエリをサポートしています。これは、ほとんどのエンジニア、データ アナリスト、さらには上級オペレータにとっても非常に便利です。
Honhu SQLの概要については、こちらを参照してください。
（https://yanhuang.yuque.com/staff-sbytbc/rb5rur/znakv0? ）
4.4.5 すぐに使える豊富なチャート
Honhu は非常に豊富なチャートを提供します。いくつかの商用 BI 製品 (Tableau、PowerBI など) を使用したことのある人にとって、このコミュニティ製品は非常に強力です。以前はカスタマイズする必要があった機能の統合を試みています。 AGC コマンドやシステム出力電力などの指標の曲線は、Honghu の高度なクエリ機能によって実現され、非常にシンプルです。
4.5 概要
試用版から判断すると、Honghu はインストールが非常に簡単で、チャート分析機能が豊富なコミュニティ製品です。挿入パフォーマンスに関してHonghuおよびいくつかの時系列データベースのベンチマークテストを行っていないため、他の検索エンジンと時系列データベースの比較および個人的な経験から、新しい共有エネルギー貯蔵SCADAシステムは、挿入パフォーマンスの点でベンチマークテストを行っていません。取得の同時実行パフォーマンスに対する要件が厳しすぎる場合は、Honghu をメイン ストレージとして直接使用できます。既存のプロジェクトの変換である場合、または非常に高いパフォーマンス要件がある場合は、アーキテクチャの観点から、Honghu と組み合わせてシーケンシャル データベースの使用を検討できます。 。