EMS Builder 整体架构、工作模式与能力边界
Edge-EMS Builder 位于现场设备与上层系统之间，以边缘自治为基础，并可扩展为云边协同和多节点协同。它把“读到数据、算出状态、判断规则、执行动作”组织成持续运行的控制闭环。
本文回答四个问题：
- Edge-EMS Builder 的整体架构如何分层？
- 它可以按哪些工作模式运行？
- 一个业务需求如何被组合出来？
- 有线、无线和跨站点连接能扩展到哪里？
本文的“工作模式”指系统运行方式，不是商业合作方式。Platform、Solution、Co-create 三种合作方式请查看 Edge-EMS Builder 服务模式。
一、整体架构：现场、边缘与云端形成闭环
Section titled “一、整体架构：现场、边缘与云端形成闭环”
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，前端可通过标准通道订阅数据和发起控制。
- 云端不可用时仍可保留本地闭环：关键判断与动作在边缘执行；具体离线能力取决于项目配置和外部依赖。
二、一次控制是怎样完成的
Section titled “二、一次控制是怎样完成的”任意一条业务策略都可以拆成“采集 → 计算 → 决策 → 执行”四步：
| 步骤 | EMS Builder 做什么 | 示例：台区容量支撑 |
|---|---|---|
| ① 采集 | CommBridge 读取原始点位并同步给 EMS Builder | 读取变压器负荷、PCS 状态、SOC |
| ② 计算 | 表达式引擎计算中间状态、余量或风险 | 计算容量缺口和储能可用放电功率 |
| ③ 决策 | 触发方案判断条件并选择动作 | 负荷接近上限且 SOC 允许时启动支撑 |
| ④ 执行 | 写入设备、记录告警、发布 MQTT 或推送前端 | 向 PCS 下发功率并上报执行状态 |
执行后的功率、SOC 和设备状态会再次被采集，进入下一轮判断。一个稳定策略还应包含启动/退出阈值、防抖、优先级、通信异常处理、设备保护和人工接管，而不只是简单的 IF / THEN。
两项贯穿闭环的支撑机制
Section titled “两项贯穿闭环的支撑机制”- 共享目标：其他 Edge-EMS Builder 节点的数据可以像本机数据一样参与表达式与触发判断，形成跨设备协同。
- 设备单元动态扩展（UDE）：同类设备定义一次模板，新实例接入后自动物化聚合、分组和共享配置，减少重复配置。
三、三种工作模式
Section titled “三、三种工作模式”
三种模式使用同一套 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 通过共享目标同步数据，主节点可以汇总从节点状态并进行统一计算，从节点也可在角色切换后承担新的任务。
典型链路： 多个从节点共享数据 → 主节点计算站点目标 → 各节点执行分配结果
适合需求： 多机功率分配、跨区域设备群控、站点级负载均衡、冗余与角色切换。
设计重点： 定义主从关系、共享周期、数据时效、网络异常状态和失联后的本地策略。
四、核心能力与运行支撑
Section titled “四、核心能力与运行支撑”
| 能力 | 解决的问题 | 在闭环中的位置 |
|---|---|---|
| 数据模型 | 统一原始、分时、聚合和共享数据的组织方式 | 采集与计算基础 |
| 表达式引擎 | 用 Lua 完成求和、筛选、状态判断和跨设备计算 | 计算 |
| 触发方案 | 用“条件 + 动作”编排业务规则 | 决策与执行 |
| MQTT 云边协同 | 数据发布、指令订阅、响应和云边双向通信 | 云边连接 |
| 设备协同与共享目标 | 让多个节点共享数据并参与彼此计算 | 分布式协同 |
| 设备单元动态扩展（UDE） | 模板、动态占位符与已有实例对账 | 规模化扩展 |
| 告警生命周期 | 跟踪异常、恢复与人工解决 | 状态与处理 |
| 历史与归档 | 趋势分析、异步导出、多计划归档 | 数据留存 |
| 运行维护 | 容量建议、配置来源、维护冻结与控制日志 | 持续运行 |
此外，前端实时推送与直接控制 提供面向前端和后端系统的 WebSocket 通道，使自定义界面可以订阅实时数据，也可以在权限与安全约束下发起控制。
五、不同需求如何组合出来
Section titled “五、不同需求如何组合出来”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 退出的双阈值条件；
- PCS 功率写入动作、频率限制和失败处理；
- SOC/温度/告警保护、人工接管和通信异常策略；
- 正常、临界、断网、设备故障等测试用例。
由此可见，Edge-EMS Builder 提供的是表达和执行策略的基础设施；策略是否安全、正确，仍取决于需求定义、设备能力和验证质量。
六、有线、无线与跨站点连接的可能性
Section titled “六、有线、无线与跨站点连接的可能性”Edge-EMS Builder 的核心逻辑与具体网络介质解耦，但“可以联网”不等于“任何无线链路都适合实时控制”。
上层 IP 网络
Section titled “上层 IP 网络”MQTT/MQTTS、HTTP 和 WebSocket 可以运行在可达的 IP 网络上。项目可以根据硬件与网络条件使用以太网、Wi-Fi、4G/5G 或专网连接云端和其他节点。
这属于架构可行性，不是 Edge-EMS Builder 边缘硬件内置无线模块的规格承诺。具体无线能力需结合所选硬件、运营商网络、现场覆盖和认证要求确认。
现场设备网络
Section titled “现场设备网络”PCS、BMS、电表等设备能否通过无线接入，取决于设备本身、无线网关以及 CommBridge 的协议适配。无线链路只是传输方式，不会自动解决寄存器映射、实时性或控制权限问题。
无线或广域连接必须额外处理
Section titled “无线或广域连接必须额外处理”- 时延与抖动：毫秒级闭环优先留在本地，广域链路更适合目标下发、数据上报和非强实时协同。
- 断线与数据过期：为共享数据标记时效，明确断线后的保持、降级或退出策略。
- 安全：采用 TLS、身份认证、最小权限和审计，避免把设备控制接口直接暴露到公网。
- 现场保护：硬件联锁、设备保护和本地安全控制不能依赖云端或不稳定链路。
因此，推荐的总体原则是：
实时控制留在边缘，优化目标可以来自云端；无线负责连接，安全与容灾负责兜底。
七、从“无线连接”走向“无限扩展”
Section titled “七、从“无线连接”走向“无限扩展””Edge-EMS Builder 的能力边界可以用三个条件判断：
| 前提 | 需要回答的问题 |
|---|---|
| 数据可获得 | 所需状态能否稳定采集，来源是否可信、是否具有时效？ |
| 规则可表达 | 目标、约束、优先级和异常路径能否被明确描述与测试？ |
| 动作可执行 | 设备或系统是否提供合规、可授权、可验证的控制接口？ |
三项都满足时，Edge-EMS Builder 不仅可以用于传统 EMS，还可以扩展到园区设备群控、柔性负荷调节、生产计划联动、环境与能源协同等“感知 → 判断 → 执行”的自动化场景。
但以下边界始终存在：
- Edge-EMS Builder 不能替代设备厂商的保护逻辑、安全认证和现场联锁。
- 接入外部预测或 AI 结果时，应进行范围校验、超时处理和安全限幅，不能直接绕过确定性规则控制关键设备。
- 多设备协同的效果取决于时钟、网络、数据质量和目标分配算法。
- 新策略必须经过仿真或测试环境验证，再按受控流程进入生产。
八、部署容量：用实测数据做起点
Section titled “八、部署容量：用实测数据做起点”AFE-E630 当前已验证的推荐场景 S3.5 为：5,000 点/秒采集配置负载、30 个聚合运算、90 次 Trigger/秒、20 次 MQTT/秒和 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 “上线前检查清单”- 设备点表、量纲、精度、读写权限和异常值是否确认；
- 策略启动、退出、防抖、优先级和冲突处理是否明确；
- 断网、数据过期、设备离线和写入失败是否有降级路径；
- 设备保护、硬件联锁、人工接管和权限审计是否独立有效；
- 是否用真实脚本、消息大小、数据库历史量和目标硬件完成压力测试；
- 是否建立配置版本、回滚方案、日志与告警监控。
- 先看产品价值与场景：阅读 Edge-EMS Builder 产品介绍。
- 开始理解配置对象：阅读 核心概念。
- 查看业务配置过程：阅读 台区临时增容 或 充电桩集群负载均衡。
- 查看前端与云端集成：前端实时推送与直接控制、MQTT 云边协同。