DERMS向けマルチプロトコルゲートウェイ

導入

分散型エネルギー資源管理システム（DERMS）は、システムオペレータ（SCADA、DMS、マイクログリッドコントローラなど）と1つ以上の分散型エネルギー資源（DER）という2種類のリモートネットワーク間でマルチプロトコルメッセージをやり取りするためにゲートウェイデバイスを使用します。リモート操作されるDERは、リモート端末ユニット（RTU）を介して通信インフラストラクチャとインターフェースします。機器ベンダーやアプリケーションが多数存在するため、通常は複数のプロトコルが使用されます。ゲートウェイデバイスは、効率的なシステム統合のためにマルチプロトコルをサポートする必要があります。

このアプリケーションノートでは、汎用DERコンポーネント、通信プロトコル、およびそれらのクライアント/サーバー実装を利用して、DERMSゲートウェイの通信テスト環境をモデル化する方法を説明します。サンプルモデルは実際のゲートウェイデバイスを実装していません。ゲートウェイは、SCADAクライアントとRTU間のデータ交換を提供する「ブラックボックス」抽象化として表現されます。TCPクライアントはHIL SCADAに実装されており、DERMSとの間でTCPメッセージの送受信が可能です。さらに、DERMSはスケマティックエディタに配置され、汎用UIコンポーネントに含まれるRTUと通信します。通信プロトコルの実装とテストに最適なソリューションとして、汎用コンポーネントが使用されます。

モデルの説明

このモデルは、系統に接続された小規模なマイクログリッドを構築するための、PV発電所（汎用）とバッテリーESS（汎用）で構成されています。これらのコンポーネントは、Microgrid Toolboxに含まれています。さらに、モデルには定インピーダンス負荷が含まれています。

UIブロックはニーズに合わせて変更できます。この例では、これらのコンポーネントはリモートターミナルユニットとして表され、使用する通信プロトコルに応じてRTU（Modbus SunSpec）およびRTU（CANバス）という名前が付けられています。

各 UI ブロックのマスクでは、次の 2 つの制御方法から選択できます。

• 信号処理による制御を可能にするモデル制御。
• 通信プロトコルを制御できる通信。

通信による制御を選択した場合は、CAN バスがループバックとして実装されるため、RTU Modbus SunSpec コンポーネントで適切な IP アドレスを設定する必要があります。

シミュレーション

このモデルには、あらかじめ構築されたSCADAパネルが付属しています。シミュレーション実行時の監視や操作に必要な主要なユーザーインターフェース要素（ウィジェット）が用意されており、ニーズに合わせてさらにカスタマイズできます。

シミュレーションを行う前に、SCADA パネル モデル初期化ファイルで回路図エディターで使用したのと同じ Modbus IP アドレスを設定する必要があります。

SCADA パネルは、次の 3 つのウィジェット グループで構成されています。

• 制御室
• マルチプロトコルゲートウェイ
• 現場測定

制御室は、TCP要求がゲートウェイに送信される場所です。ゲートウェイはTCP要求を受信し、この例ではオンサイト測定グループに表示されているRTUメーターに送信します。オンサイト測定からRTU応答がゲートウェイに送信され、ゲートウェイはTCP応答を制御室に転送します。

Modbus SunSpec クライアントの実装は、パネル初期化中に SCADA API を通じて行われます。以下にその例を示します。

       SETTINGS_DIR = get_settings_dir_path() # 'add_to_python_path(folder)' 関数を使用すると、Python ファイルとパッケージを含むカスタム フォルダーを PYTHONPATH に追加できます。フォルダーを追加したら、そのフォルダーにあるすべての Python ファイルと Python パッケージを SCADA 名前空間にインポートできます。 # HIL API は 'hil' としてインポートされます。 # Numpy モジュールは 'np' としてインポートされます。 # Scipy モジュールは 'sp' としてインポートされます。 # 回路図エディター モデル名前空間は 'scm' としてインポートされます。 # HIL SCADA メッセージ ログに出力するための関数は 'printf' としてインポートされます。 path_to_communication1 = 'RTU (CAN バス)。' path_to_communication2 = 'RTU (Modbus Sunspec)。' path_to_communication3 = 'RTU (ベンダー)。' import typhoon.api.modbus as modbus from typhoon.api.modbus.exceptions import ModbusError, ModbusNotConnected, ModbusInvalidRegSpec import typhoon.api.modbus.util as mb_util PV_SERVER_ADDRESS = '192.168.0.33' PORT = 502 グローバル接続 # PVパネル PV_client = None #PV_client = modbus.TCPModbusClient(host=PV_SERVER_ADDRESS, # port=PORT, # auto_open=True) PV_input_register_values = [0]*8 PV_input_register_address = '[40000,40001]U,40002U,40003U,[40004:16]U,[40020:16]U, [40036:8]U,[40044:8]U,[40052:16]U,40068U,40069U,40070U,40071U,40072U,40076U,40077U, 40080U,40081U,40082U,40084I,40086I,40087U,40088U,40090U,40092I,40093I,40094I,40095U, 40096U,40097U,40098U,40099U,40100U,40101I,40102U,40103U,40104U,40105U,40106U,40107U, 40108I,40109i,40110I,40111u,40112I,40113i,40114I,40115i,40116I,40117I,40118I,[40119:2] U、40121I、40122U、40123I、40124U、40125I、40126I、40127I、40128I、40129I、40130I、40131I、40132I、40133U、40134U、[40135:2]U、[40137:2]U、[40139:2]U、[40141:2]U、[40143:2]U、[40145:2]U、40147U、40148U' が接続されています = False
     

一方、CANバスクライアントの実装はCANループバックを用いて行われます。導入部で述べたように、ゲートウェイデバイスは抽象化されているため、クライアント側にはCAN/Ethernetコンバータはモデル化されていません。クライアント・サーバー間のCANバスメッセージングは、HILデバイス上の2つのCANコントローラ間の直接的な物理ループバックによって実現されます。

すでに述べたように、モデル制御モードを選択し、図 9に示すように信号処理を介してこれらのマイクログリッド ユニットを制御することができます。

テスト自動化

この例のテスト自動化はまだありません。ご協力いただける場合はお知らせください。アプリケーションノートへの署名を喜んで承ります。

要件の例

表1は、モデルをリアルタイムで実行するためのファイルの場所とハードウェア要件に関する詳細情報と、この最小限のハードウェア構成でモデルを実行した場合のHILデバイスのリソース使用率を示しています。この情報は、モデルの実行とカスタマイズを必要に応じて行う際に役立ちます。

著者

[1] ヨヴァナ・マルコビッチ