EMS Builder の全体アーキテクチャ、動作モード、適用範囲
Edge-EMS Builder は現場デバイスと上位システムの間に位置し、エッジでの自律動作を基盤に、クラウド・エッジ連携や複数ノードの協調へ拡張できます。「データの取得、状態の計算、ルールの判定、アクションの実行」を、継続して動作する制御ループにまとめます。
このページでは、次の 4 点を説明します。
- Edge-EMS Builder の全体アーキテクチャはどのような層で構成されるか。
- どのような動作モードを利用できるか。
- 業務要件をどのように組み立てるか。
- 有線、無線、拠点間の接続でどこまで拡張できるか。
このページの「動作モード」はシステムの動作方式であり、商業上の協業方式ではありません。Platform、Solution、Co-create については Edge-EMS Builder サービスモデル を参照してください。
1. 全体アーキテクチャ：現場・エッジ・クラウドの制御ループ
Section titled “1. 全体アーキテクチャ：現場・エッジ・クラウドの制御ループ”
Edge-EMS Builder はエッジで動作します。CommBridge が現場プロトコルの違いを吸収し、MQTT、WebSocket、HTTP がクラウド、フロントエンド、外部システムを接続します。
| 層 | 主な役割 | 代表的な対象／チャネル |
|---|---|---|
| 業務・クラウド層 | 統合監視、遠隔設定、制御ロジック配信、運用分析、外部業務システムとの統合 | JelinaCloud、顧客クラウド、SCADA、ディスパッチシステム。MQTT / HTTP |
| インタラクション・統合層 | フロントエンドへのリアルタイム配信、制御指令の受信、外部システムへの読み書き機能提供 | 独自の Web フロントエンド、バックエンドサービス。WebSocket / HTTP |
| EMS Builder エッジエンジン | データ統合、リアルタイム計算、制御判断、アクション実行、アラーム、共有、設定拡張 | データモデル、式エンジン、トリガープラン、共有先、UDE |
| CommBridge 収集層 | 下位プロトコルに対応し、現場ポイントを EMS Builder が識別できるデータへ変換 | Modbus、OPC UA、S7、シリアル、IEC 101/104、CAN など |
| 現場デバイス層 | リアルタイムデータを提供し、最終的な制御を実行 | PCS、BMS、電力計、充電器、太陽光発電インバーター、センサー、外部デバイス |
層を分ける理由
Section titled “層を分ける理由”- デバイス変更で制御ロジックを作り直さない：下位プロトコルとポイントの適応は収集層で行い、上位ロジックは共通の
dataKeyを使用します。 - 業務変更で通信ドライバーを変更しない：しきい値、時間帯、制御ルールは制御ロジック層で調整し、デバイスプロトコルの実装は変更不要です。
- 画面と制御エンジンを分離：Edge-EMS Builder は固定 UI に依存せず、フロントエンドは標準チャネルでデータを購読し、制御を要求できます。
- クラウド停止時もローカルの制御ループを維持可能：重要な判断とアクションをエッジで実行します。具体的なオフライン機能はプロジェクト設定と外部依存関係によって決まります。
2. 1 回の制御が完了するまで
Section titled “2. 1 回の制御が完了するまで”どの業務制御ロジックも「収集 → 計算 → 判断 → 実行」の 4 段階に分解できます。
| 段階 | EMS Builder の処理 | 例：配電変圧器供給区域の容量補助 |
|---|---|---|
| ① 収集 | CommBridge が生データポイントを読み取り、EMS Builder へ同期 | 変圧器負荷、PCS 状態、SOC を取得 |
| ② 計算 | 式エンジンが中間状態、余裕量、リスクを計算 | 容量不足分と蓄電設備の利用可能な放電電力を計算 |
| ③ 判断 | トリガープランが条件を判定し、アクションを選択 | 負荷が上限に近づき、SOC が許容する場合に補助を開始 |
| ④ 実行 | デバイス書き込み、アラーム記録、MQTT パブリッシュ、フロントエンド配信 | PCS へ電力指令を送り、実行状態を報告 |
実行後の電力、SOC、デバイス状態を再び収集し、次の判断へ進みます。安定した制御ロジックには、単純な IF / THEN だけでなく、開始・終了しきい値、チャタリング防止、優先順位、通信異常処理、デバイス保護、手動介入も必要です。
制御ループ全体を支える 2 つの仕組み
Section titled “制御ループ全体を支える 2 つの仕組み”- 共有先：他の Edge-EMS Builder ノードのデータをローカルデータと同様に式やトリガー判定へ使用し、デバイス間で協調できます。
- デバイスユニットの動的拡張（UDE）：同種デバイスのテンプレートを一度定義すると、新規インスタンス接続時に集約・グループ・共有設定を自動生成し、設定の繰り返しを減らします。
3. 3 つの動作モード
Section titled “3. 3 つの動作モード”
3 つのモードは同じ Edge-EMS Builder エンジンを使用し、単独でも、同一プロジェクト内で組み合わせても利用できます。
1. エッジ自律動作
Section titled “1. エッジ自律動作”収集、計算、判断、制御をすべて拠点内で実行します。応答速度、連続稼働、データのローカル保持が求められる現場に適しています。
代表的な経路： 現場デバイス → CommBridge → Edge-EMS Builder 制御ロジック → 現場デバイス
適した用途： 時間帯別充放電、逆潮流防止、デマンド制御、デバイスインターロック、拠点内アラーム。
設計上の重点： ローカル保護を優先します。外部の電気料金、天候、クラウド指令などへの依存には、キャッシュ、タイムアウト、縮退動作を設計します。
2. クラウド・エッジ連携
Section titled “2. クラウド・エッジ連携”エッジがリアルタイム実行を担い、クラウドが統合管理、制御ロジックの構成、遠隔運用保守、拠点横断分析を担います。MQTT は双方向パブリッシュ／サブスクライブと応答に対応し、Edge-EMS Builder は HTTP で許可された外部情報を取得することもできます。
代表的な経路： クラウドから目標・制御ロジックを配信 → エッジで検証・実行 → 結果をクラウドへ返送
適した用途： 複数拠点の監視、遠隔パラメーター調整、計画曲線の配信、運用分析、集中アラーム。
設計上の重点： クラウドの目標が現場の安全制約を迂回してはいけません。通信断時に、継続実行、最後の有効値の保持、安全制御への移行のいずれを行うか明確にします。
3. 複数ノードの協調
Section titled “3. 複数ノードの協調”複数の Edge-EMS Builder が共有先を通じてデータを同期します。親ノードは子ノードの状態を集約して一括計算でき、子ノードも役割の切り替え後に新たなタスクを担えます。
代表的な経路： 複数の子ノードがデータを共有 → 親ノードが拠点目標を計算 → 各ノードが割当て結果を実行
適した用途： 複数機器の電力配分、区域をまたぐデバイス群制御、拠点単位の負荷分散、冗長化と役割切り替え。
設計上の重点： 親子関係、共有周期、データの鮮度、ネットワーク異常状態、通信断後のローカル制御を定義します。
4. 中核機能と運用支援
Section titled “4. 中核機能と運用支援”
| 機能 | 解決する課題 | 制御ループ内の役割 |
|---|---|---|
| データモデル | 生データ、時間帯別、集約、共有データの構成を統一 | 収集・計算の基盤 |
| 式エンジン | Lua による合計、選別、状態判定、デバイス間計算 | 計算 |
| トリガープラン | 「条件 + アクション」で業務ルールを構成 | 判断・実行 |
| MQTT クラウド・エッジ連携 | データ配信、指令購読、応答、クラウドとエッジの双方向通信 | クラウド・エッジ接続 |
| デバイス協調と共有先 | 複数ノードでデータを共有し、相互の計算に利用 | 分散協調 |
| デバイスユニットの動的拡張（UDE） | テンプレート、動的プレースホルダー、既存インスタンスの差分照合 | 大規模展開 |
| アラームのライフサイクル | 異常、復旧、手動解決を追跡 | 状態・対応 |
| 履歴とアーカイブ | トレンド分析、非同期エクスポート、複数プランのアーカイブ | データ保存 |
| 運用保守 | 容量の推奨、設定の出所、保守時の書き込み停止、制御ログ | 継続稼働 |
また、フロントエンドへのリアルタイム配信と直接制御 は、フロントエンドとバックエンドシステム向けの WebSocket チャネルを提供します。独自画面でリアルタイムデータを購読し、権限と安全上の制約に従って制御を要求できます。
5. 異なる要件の組立て方
Section titled “5. 異なる要件の組立て方”Edge-EMS Builder は「全案件で同じ制御ロジックを使う」ことを前提とせず、同じ構築方法で異なる要件に対応します。
要件 = 必要なデータ + 計算規則 + トリガー条件 + 実行アクション + 保護・検証
| 要件 | 必要なデータ | 計算・判断 | 代表的なアクション |
|---|---|---|---|
| ピークカット・負荷平準化／デマンド制御 | 連系点電力、SOC、PCS 状態、デマンド目標 | 電力不足分と利用可能な充放電能力を計算 | PCS 電力指令、制御状態の記録 |
| 逆潮流防止 | 連系点電力、太陽光発電電力、蓄電設備の利用可能電力 | 逆潮流傾向を判定し、出力を制限 | 蓄電池への充電、太陽光出力制限、アラーム |
| 充電器の負荷分散 | 変圧器の余裕容量、各充電器の要求と状態 | 配分可能な電力を計算し、規則に従って配分 | 各充電器の電力上限を調整 |
| 複数機器の協調 | 各ユニットの SOC、電力上限、利用可能状態 | SOC、容量、優先度に基づいて拠点目標を配分 | 複数 PCS・ノードへ個別目標を送信 |
| 時間帯別制御と計画曲線 | 時間帯、電気料金、SOC、負荷予測 | 現在の時間帯に照合し、保護上の制限を確認 | 充放電目標の切り替え、実行結果の返送 |
| 外部情報に基づく制御 | 電気料金、天候、生産計画、予測結果 | データの鮮度を確認し、最適化や判断に利用 | 目標調整、縮退制御への移行、アラーム |
例：業務要件を EMS Builder 設定へ変換
Section titled “例：業務要件を EMS Builder 設定へ変換”要件：
「連系点電力が 800 kW を超え、SOC が 20% より高い場合、蓄電設備が自動放電する。760 kW まで低下したら終了する。」
少なくとも次の設定が必要です。
- 連系点電力、SOC、PCS 利用可能状態、最大放電電力などのデータ。
- 容量不足分と目標放電電力の式。
- 800 kW で開始し、760 kW で終了する 2 つのしきい値条件。
- PCS 電力の書き込みアクション、頻度制限、失敗処理。
- SOC・温度・アラーム保護、手動介入、通信異常時の制御。
- 通常、境界、通信断、デバイス故障などのテストケース。
Edge-EMS Builder が提供するのは、制御ロジックを表現・実行する基盤です。安全性と正確性は、要件定義、デバイス能力、検証品質に依存します。
6. 有線・無線・拠点間接続の可能性
Section titled “6. 有線・無線・拠点間接続の可能性”Edge-EMS Builder の中核ロジックはネットワーク媒体から独立しています。ただし、ネットワーク接続できることは、あらゆる無線リンクがリアルタイム制御に適することを意味しません。
上位 IP ネットワーク
Section titled “上位 IP ネットワーク”MQTT/MQTTS、HTTP、WebSocket は、到達可能な IP ネットワークで動作します。ハードウェアとネットワーク条件に応じ、Ethernet、Wi-Fi、4G/5G、専用網でクラウドや他のノードへ接続できます。
これはアーキテクチャ上の実現可能性であり、Edge-EMS Builder のエッジハードウェアに無線モジュールが内蔵されるという仕様保証ではありません。選択するハードウェア、通信事業者のネットワーク、現場の電波到達性、認証要件を確認してください。
現場デバイスネットワーク
Section titled “現場デバイスネットワーク”PCS、BMS、電力計などを無線で接続できるかは、デバイス自体、無線ゲートウェイ、CommBridge のプロトコル対応によって決まります。無線リンクは伝送方法であり、レジスターマッピング、リアルタイム性、制御権限を自動的に解決するものではありません。
無線・広域接続で追加対応が必要な事項
Section titled “無線・広域接続で追加対応が必要な事項”- 遅延とジッター：ミリ秒単位の制御ループはローカルを優先します。広域リンクは目標配信、データ報告、厳密なリアルタイム性を要求しない協調に適しています。
- 切断とデータの期限切れ：共有データの有効期間を示し、切断後の保持、縮退、終了の方針を明確にします。
- セキュリティ：TLS、認証、最小権限、監査を使用し、デバイス制御 API をインターネットへ直接公開しないようにします。
- 現場保護：ハードウェアインターロック、デバイス保護、ローカル安全制御を、クラウドや不安定なリンクへ依存させてはいけません。
全体の推奨原則は次のとおりです。
リアルタイム制御はエッジで実行し、最適化目標はクラウドから取得できます。無線は接続を担い、安全対策と障害対策が動作を支えます。
7. 無線接続から、さらに広がる拡張へ
Section titled “7. 無線接続から、さらに広がる拡張へ”Edge-EMS Builder の適用範囲は、次の 3 条件で判断できます。
| 前提 | 確認事項 |
|---|---|
| データを取得できる | 必要な状態を安定して収集できるか。送信元は信頼でき、データは最新か。 |
| ルールを表現できる | 目標、制約、優先度、異常時の経路を明確に記述・試験できるか。 |
| アクションを実行できる | デバイスやシステムが、要件に適合し、認可・検証可能な制御 API を提供するか。 |
3 条件を満たせば、従来の EMS に加え、構内デバイス群制御、柔軟な負荷調整、生産計画との連動、環境とエネルギーの協調など、「検知 → 判断 → 実行」の自動化へ拡張できます。
ただし、次の制約は常に残ります。
- Edge-EMS Builder は、機器メーカーの保護ロジック、安全認証、現場インターロックを代替できません。
- 外部予測や AI の結果を利用する場合は、範囲検証、タイムアウト処理、安全上の出力制限を設け、確定的なルールを迂回して重要設備を直接制御しないでください。
- 複数デバイスの協調効果は、時刻、ネットワーク、データ品質、目標配分アルゴリズムに依存します。
- 新しい制御ロジックはシミュレーションまたはテスト環境で検証し、管理された手順で本番へ適用してください。
8. 配置容量：実測値を出発点にする
Section titled “8. 配置容量：実測値を出発点にする”AFE-E630 で現在検証済みの推奨シナリオ S3.5 は、収集設定負荷 5,000 ポイント/秒、集約演算 30 個、Trigger 90 回/秒、MQTT 20 回/秒、協調タスク 10 回/秒です。変化時保存を使用し、遅くとも 10 秒ごとに保存します。
2026-07-29 の試験（報告書 v1.3）では、このシナリオの Trigger / MQTT の P95 遅延は 56 ms / 77 ms、装置全体の CPU 使用率 P95 は 71.09%、装置全体の実メモリー使用率 P95 は 41.41% です。本番の初期容量計画では、この実測負荷に約 20% の設計余裕を確保することを推奨します。
この結果は指定ハードウェア・ソフトウェアと短時間の有効サンプル 2,000 件に基づき、72 時間の安定性検証ではありません。異なるスクリプト、メッセージサイズ、データベース規模へ直接外挿できません。AFE-E630 性能試験報告 を参照してください。
稼働開始前のチェックリスト
Section titled “稼働開始前のチェックリスト”- デバイスのポイント一覧、物理量・単位、精度、読み書き権限、異常値を確認したか。
- 制御の開始・終了、チャタリング防止、優先度、競合処理が明確か。
- 通信断、データ期限切れ、デバイスオフライン、書き込み失敗時の縮退経路があるか。
- デバイス保護、ハードウェアインターロック、手動介入、権限監査が独立して機能するか。
- 実際のスクリプト、メッセージサイズ、履歴データ量、対象ハードウェアで負荷試験を実施したか。
- 設定バージョン、ロールバック手順、ログ・アラーム監視を用意したか。
次のステップ
Section titled “次のステップ”- 製品の価値と適用シーン：Edge-EMS Builder 製品紹介。
- 設定オブジェクトの理解：基本概念。
- 業務設定の手順：一時的な容量補強、充電器群の負荷分散。
- フロントエンドとクラウドの統合：フロントエンドへのリアルタイム配信と直接制御、MQTT クラウド・エッジ連携。