EMS Builder：エネルギープロジェクトをゼロから作り直さないために
Edge-EMS Builder は、エネルギー現場に配置するインテリジェントなオーケストレーションプラットフォームです。デバイス接続、データ処理、制御ロジック、クラウド・エッジ通信、複数デバイスの協調を再利用可能な機能として蓄積し、EMS を「一度きりの納品物」から「継続して展開・更新できるプラットフォーム資産」へ変えます。
産業・業務用蓄電、太陽光・蓄電・充電、マイクログリッド、構内エネルギー管理は、いずれも EMS と呼ばれますが、現場の条件が完全に同じことはほとんどありません。デバイスメーカー、ポイント一覧、電気料金、容量が異なり、顧客は新しい制御ルールを追加し続けます。
PCS、BMS、電力計、太陽光発電インバーターを接続する案件もあれば、充電器、ディーゼル発電機、空調負荷、顧客独自のクラウドまで接続する案件もあります。時間帯別料金差の活用、逆潮流防止、最大デマンドを重視する顧客もいれば、「配電変圧器供給区域の一時的な容量補強」のような要件を後から追加する顧客もいます。
案件ごとにデバイス接続、制御ロジック、クラウドインターフェースを作り直すと、導入規模の拡大に伴い、重複開発と保守のコストが増加します。Edge-EMS Builder はこの課題を解決します。
Edge-EMS Builder は、複雑なエネルギープロジェクトのデバイス、データ、制御ロジックを整理し、EMS の構築を「案件ごとに作り直す」方式から「プラットフォーム上で素早く設定・展開する」方式へ移行できるよう支援します。
同じデータ・制御基盤で、異なるデバイス構成、制御目標、プロジェクトパラメーターに対応できます。
EMS Builder が必要な理由
Section titled “EMS Builder が必要な理由”デバイスが増えても、制御ロジックをプロトコルから作り直さない
Section titled “デバイスが増えても、制御ロジックをプロトコルから作り直さない”1 つの拠点に PCS、BMS、電力計、太陽光発電インバーター、充電器、ディーゼル発電機、空調負荷、外部プラットフォームが混在することがあります。制御ロジックが扱うべきなのは「連系点の上限を超えているか」「SOC が放電の継続を許容するか」であり、個々のレジスターがどのプロトコル由来かではありません。
Edge-EMS Builder は CommBridge でデバイスを接続し、データ識別子を統一することで、上位の制御ロジックを業務上の意味に基づいて構築できるようにします。デバイスのモデルやプロトコルが変わっても、通常はデータポイントのマッピングを調整することで、検証済みの中核ロジックを再利用できます。
変化する要件に対応できる制御ロジック
Section titled “変化する要件に対応できる制御ロジック”電気料金、容量、運転時間帯、制御しきい値は変わる可能性があります。現在は逆潮流防止だけが必要でも、将来はデマンド制御や蓄電池と充電器の協調が求められるかもしれません。
Edge-EMS Builder は業務ロジックをデータ、計算、条件、アクションに分解します。エンジニアはパラメーター、式、トリガープランを変更でき、業務要件が変わるたびにソフトウェア全体を作り直す必要はありません。
案件を展開するたびに、経験を企業の資産へ
Section titled “案件を展開するたびに、経験を企業の資産へ”検証済みのピークカット・負荷平準化、充電負荷分散、複数機器の協調ロジックを、1 つの拠点だけに留める必要はありません。Edge-EMS Builder では、次のように段階的に再利用を進められます。
現場検証 → データポイントとパラメーターの抽象化 → テンプレート化 → 新規案件で再利用 → 継続的な改善
案件を重ねるほど、再利用できる制御ロジック、ポイント一覧、テストケースが充実します。新規案件はゼロから開発する作業から、「テンプレートを選び、マッピングし、パラメーターを調整する」作業へ近づきます。
EMS Builder とは
Section titled “EMS Builder とは”Edge-EMS Builder は通常、エッジゲートウェイや産業用 PC 上で動作し、現場デバイスとクラウドまたは業務システムの間に配置されます。主に次の 4 つの役割を担います。
| EMS Builder の役割 | 概要 | プロジェクトで得られる結果 |
|---|---|---|
| 接続の統一 | メーカーやプロトコルが異なるデバイスを共通のデータ体系へ接続 | PCS、BMS、電力計、充電器などを統一的に利用可能 |
| データ処理 | 生のデータポイントを、制御ロジックで扱える状態や指標に加工 | 電力、SOC、容量、余裕量、アラーム状態を計算に直接使用可能 |
| 制御ロジックの構成 | 式と「条件 + アクション」で制御ルールを記述 | ピークカット・負荷平準化、逆潮流防止、デマンド制御などを自動実行 |
| システム連携 | 現場データと判断結果をクラウド、フロントエンド、他のノードへ送信 | 遠隔運用保守、集中監視、制御ロジック配信、複数デバイスの協調に対応 |
Edge-EMS Builder は「収集・接続 → 統合データプール → Lua による判断 → 出力の実行」を継続します。実行結果はデータプールへ戻り、制御ループが継続します。
EMS Builder の適用範囲
Section titled “EMS Builder の適用範囲”- ダッシュボードだけの監視ソフトウェアではありません：データ表示に加え、制御ロジックに基づく自動制御ループを構築できます。
- 特定の制御ロジックを固定実装した EMS ではありません：プラットフォームがロジック構築機能を提供し、具体的な業務ルールはプラン設定で決まります。
- デバイス保護を代替する安全コントローラーではありません：ハードウェアインターロック、BMS/PCS 保護、現場の安全上の制約は、引き続き独立して有効にする必要があります。
- 特定のフロントエンドを必須としません：標準 WebSocket インターフェースで独自の監視・制御画面を構築できます。
端的に表すと、次のようになります。
Edge-EMS Builder は「1 つのシーン専用の EMS」ではなく、「多様な EMS を継続して構築するための機能基盤」です。
EMS Builder がもたらす 4 つの変化
Section titled “EMS Builder がもたらす 4 つの変化”| 従来のプロジェクト方式 | EMS Builder 導入後 |
|---|---|
| 案件ごとに接続と開発を繰り返す | 共通機能をプラットフォームへ蓄積し、新規案件はマッピングと設定が中心に |
| 制御ロジックを案件固有のコードやファームウェアへ固定実装 | データ、式、トリガー条件、アクションを組み合わせて構成 |
| 各デバイスが個別に動作し、協調には専用開発が必要 | 共有データをデバイス間の計算や判断に直接使用 |
| 稼働開始後の継続的な改善が難しい | クラウド配信、遠隔設定、公開インターフェース、制御テンプレートの更新に対応 |
ロジックの再利用
Section titled “ロジックの再利用”制御ロジックは共通して dataKey を参照します。PCS、BMS、電力計のモデルを変更しても、通常はデータマッピングと現場パラメーターを調整するだけで、中核の判断フローを再利用できます。
Edge-EMS Builder は収集、計算、トリガー、デバイス書き込み、クラウド・エッジ通信、フロントエンド向けリアルタイムチャネルを提供します。プロジェクトチームは制御ロジックそのものと業務画面に注力できます。
制御ロジックの蓄積
Section titled “制御ロジックの蓄積”現場検証済みの制御ロジックをテンプレート化し、対象デバイス、必須ポイント、調整可能なパラメーター、保護条件、テストケースを記録して、企業独自の制御ロジックライブラリーを構築できます。
オープンな拡張
Section titled “オープンな拡張”MQTT、HTTP、WebSocket、デバイス書き込みチャネルで、外部データ、クラウド、業務システム、制御可能なデバイスを接続します。信頼できるデータソース、表現可能なルール、要件に適合した実行インターフェースがあれば、新しい自動制御ループを構築できる可能性があります。
AI ネイティブ：ポイント一覧から制御ロジックの稼働まで AI が支援
Section titled “AI ネイティブ：ポイント一覧から制御ロジックの稼働まで AI が支援”これまでの機能が示すとおり、Edge-EMS Builder 自体は特定の業務ロジックを内蔵しません。データは収集設定、ルールは Lua スクリプト、連動はトリガープランから決まり、すべての設定操作に標準 API が用意されています。そのため、画面を 1 ページずつ操作する以外にも、AI Agent を含むプログラムから設定できます。
これにより、Edge-EMS Builder の導入方法を変えられます。
- AI による設定支援：Edge-EMS Builder Skills は、ポイント一覧の変換、データモデリング、Lua と制御ロジックの構成、アラーム設定、運用保守を支援します。エンジニアは要件の記述、結果のレビュー、現場検証を担当します。
- 公開インターフェース：外部 Agent はアカウント権限に応じてデータ照会や設定 API の呼び出しを行えます。制御を実行するかどうかやモデルの配置方法は、実際の統合設計で決まります。
AI は設定と分析を支援できます。実行範囲、制御ロジックのレビュー、現場受入れは、エンジニアリングプロセスで定めます。
設定手順とインストール方法は、AI による設定支援 と Skills を参照してください。
同じプラットフォームを適用できるシーン
Section titled “同じプラットフォームを適用できるシーン”
| シーン | 構築できる代表的な要件 | 主な協調対象 |
|---|---|---|
| 産業・業務用蓄電 | 時間帯別充放電、料金差の活用、ピークカット・負荷平準化、デマンド制御、逆潮流防止 | PCS、BMS、連系点電力計 |
| 太陽光・蓄電の統合 | 自家消費、太陽光発電の有効活用、逆潮流防止、計画曲線に沿った制御 | 太陽光発電インバーター、蓄電設備、連系点 |
| 太陽光・蓄電・充電拠点 | 充電スケジューリング、充電負荷分散、蓄電設備による充電ピークの補助 | 太陽光、蓄電設備、充電器、変圧器 |
| マイクログリッド | 太陽光・蓄電・ディーゼル発電の協調、電力バランス、系統連系・自立運転制御 | 太陽光、蓄電設備、ディーゼル発電機、重要負荷 |
| 配電変圧器供給区域の一時的な容量補強 | 変圧器負荷を監視し、ピーク時に蓄電設備で容量を補助 | 変圧器、電力計、蓄電設備 |
| 複数拠点の運用 | クラウドへのデータ送信、集中監視、遠隔運用保守、制御ロジックの一括配信 | 複数のエッジノードとクラウド |
これらのシーンは、同じ基本機能の組合せで構築できます。一時的な容量補強 と 充電負荷分散 の汎用設定例を参照してください。
要件を再利用可能な制御ロジックに変える
Section titled “要件を再利用可能な制御ロジックに変える”通常、プロジェクトの要件は次の手順で実装します。
- 目標を明確にする：例：「連系点の電力を 800 kW 以下にする」。
- データを整理する：連系点電力、PCS 電力、SOC、デバイス状態など、必要なポイントを確認します。
- 計算を記述する：容量不足分、使用可能な充放電電力、保護上の制限を計算します。
- トリガーを設定する：開始・終了条件、チャタリング防止、異常時の縮退動作を定義します。
- 実行・検証する：電力指令を送信し、アラームと実行結果を記録して、通常条件、境界条件、故障条件で試験します。
- テンプレートへ抽象化する：拠点固有のポイント、容量、しきい値をパラメーター化し、次の案件で再利用します。
これにより、プロジェクトの経験は移植しにくいコードだけでなく、制御ロジック、パラメーター、ポイントマッピング、試験条件を含む資産になります。
性能検証済みの機能
Section titled “性能検証済みの機能”AFE-E630（4 コア Arm Cortex-A55、メモリー 3.81 GB）で実施した 2026-07-29 の試験（報告書 v1.3）では、推奨シナリオ S3.5 の設定負荷と結果は次のとおりです。
| 指標 | 試験時の設定／結果 |
|---|---|
| データ収集の設定負荷 | 5,000 ポイント/秒 |
| 集約演算 | 30 個 |
| Trigger タスク | 90 回/秒、平均処理量達成率 99.97% |
| MQTT タスク | 20 回/秒、平均処理量達成率 99.90% |
| 協調タスク | 10 回/秒 |
| Trigger / MQTT の P95 遅延 | 56 ms / 77 ms |
| システム全体の CPU 使用率 平均／P95 | 50.16% / 71.09% |
| 装置全体の実メモリー使用率 平均／P95 | 40.49% / 41.41% |
この結果は、特定のハードウェア・ソフトウェアと測定方法での処理能力を示すもので、すべての案件で同じ容量を保証するものではありません。試験では短時間の有効リソースサンプル 2,000 件を集計しました。本番配置では、検証済み負荷に対し約 20% の設計余裕を確保し、実際のスクリプト、メッセージサイズ、データベース規模で再試験することを推奨します。
環境、集計方法、制限事項の詳細は AFE-E630 性能試験 を参照してください。
EMS Builder が適しているチーム
Section titled “EMS Builder が適しているチーム”- 機器メーカーとシステムインテグレーター：導入時の重複作業を減らし、独自の EMS 製品と制御ロジック資産を構築したいチーム。
- 自社開発能力を持つエネルギーチーム：制御ロジック、フロントエンド、クラウドの発展を自ら管理したいチーム。
- 案件を迅速に展開する EPC・運用事業者：検証済みテンプレートで拠点の稼働開始までの期間を短縮したいチーム。
- 複雑な現場を扱うプロジェクトチーム：特殊なデバイス、複数エネルギー源の協調、既存プラットフォームとの密接な統合が必要なチーム。
チームの能力と導入目標に応じて、プラットフォーム上での自社構築、標準ソリューション、共同カスタマイズを選択できます。サービスモデル を参照してください。
目的からドキュメントを探す
Section titled “目的からドキュメントを探す”| 目的 | ドキュメント |
|---|---|
| 最初の計算ループを構築 | クイックスタート |
| データポイント、時間帯別スケジュール、グループを整理 | データモデル |
| 制御ルールとアラームフローを記述 | トリガープラン、アラームのライフサイクル |
| 同種デバイスの増設とテンプレート更新 | UDE と動的プレースホルダー |
| トレンド表示、エクスポート、継続保存 | 履歴照会、エクスポート、定期アーカイブ |
| 容量、設定、保守を管理 | ストレージの推奨事項、動作設定、保守時の書き込み停止 |
| デバイスの実行結果を追跡 | デバイス制御ログ |
| Agent による設定支援 | 23 個の EMS Builder Skills |