案例：台区临时增容

本案例演示 Edge-EMS Builder 本身不包含“增容”这个业务逻辑，而是通过采集、聚合表达式、触发方案三个基础能力组合出这套控制策略。理解本案例后，可以按同样的思路把任意“监测阈值 → 计算余量 → 执行动作”类场景配置出来。

一、业务背景

配电台区（一台配电变压器所覆盖的供电区域）的容量是固定的（如 315kVA、400kVA）。当台区内出现短时集中负荷（如多台车同时快充、季节性用电高峰）时，实测负荷可能逼近甚至超过变压器额定容量，传统做法是向电网公司申请变压器增容改造，周期长、成本高，且很多时候只是为了应对短时峰值。

台区临时增容的思路是：在台区侧部署一套储能系统，由 Edge-EMS Builder 实时监测台区负荷，在负荷逼近变压器容量上限前自动指令储能放电，用储能出力顶替一部分变压器供电缺口，使台区总下网功率维持在安全阈值以内；负荷回落后自动退出增容模式，储能转为正常调度（如低谷充电）。整个过程无需改造变压器，仅通过软件策略 + 储能设备即可实现“临时”扩容效果。

二、涉及的设备与数据

角色	设备	关键点位
台区总表	配变出线智能电表	台区总下网功率 Feeder_active_power（kW）
储能系统	PCS + BMS	当前出力 PCS1_active_power（kW，正为放电）、SOC PCS1_soc（%）、可放电上限 PCS1_max_discharge_power（kW）
策略参数	自定义/聚合点位	变压器额定容量 Transformer_rated_capacity（kW）、增容触发阈值比例、SOC 保护下限

这些点位分别来自 数据模型 中的原始数据（电表、PCS/BMS 实测值）和分时/自定义数据（阈值参数，方便运营人员按季节调整而无需改脚本）。

三、聚合计算：台区剩余容量与增容需求

新增聚合点位 Feeder_headroom_kw（台区剩余容量），表达式：

-- 剩余容量 = 额定容量 × 触发阈值比例 - 实测下网功率
local rated = tonumber(${Transformer_rated_capacity} or 0)
local ratio = tonumber(${Capacity_trigger_ratio} or 0.9)  -- 默认按额定容量的 90% 作为触发线
local used = tonumber(${Feeder_active_power} or 0)

return rated * ratio - used

Feeder_headroom_kw 为负值时，代表台区负荷已逼近或超过触发线，需要储能介入分担负荷。

四、触发方案：负荷逼近阈值时自动放电

触发条件（数据变化触发，DATA_CHANGE）：

return tonumber(${Feeder_headroom_kw} or 0) < 0

触发动作：

local resultList = {}

local headroom = tonumber(${Feeder_headroom_kw} or 0)   -- 负值，代表缺口功率
local soc = tonumber(${PCS1_soc} or 0)
local maxDischarge = tonumber(${PCS1_max_discharge_power} or 0)

-- SOC 保护：低于下限时不参与增容，仅告警提示，避免过放
if soc < tonumber(${SOC_protect_min} or 20) then
    table.insert(resultList, buildCommonAlarmMap(
        "增容能力不足", "台区负荷超限但储能SOC过低（" .. soc .. "%），无法执行临时增容，请人工介入"
    ))
    return resultList
end

-- 需要补偿的功率 = 缺口的绝对值，且不超过储能最大放电能力
local needPower = math.min(-headroom, maxDischarge)

table.insert(resultList, buildCommonWriteMap("Collection", "PCS1_power_setpoint", needPower, nil, nil, true))
table.insert(resultList, buildCommonAlarmMap("台区临时增容已启动", "台区负荷超限，储能按 " .. needPower .. " kW 放电分担负荷"))
table.insert(resultList, buildMqttAlarmMap("台区临时增容已启动", "储能放电分担台区负荷", 1, "alarm/upload", 1))

return resultList

五、退出条件：避免频繁启停的滞回设计

如果直接用“剩余容量 ≥ 0”作为退出条件，负荷在阈值附近波动时会导致储能反复启停（俗称“震荡”）。做法是引入一个滞回带（Hysteresis）：进入增容模式的阈值和退出增容模式的阈值不是同一个值。

新增聚合点位 Feeder_headroom_exit_kw（退出判定余量，阈值比例更宽松，如 0.8 而不是 0.9）：

local rated = tonumber(${Transformer_rated_capacity} or 0)
local exitRatio = tonumber(${Capacity_exit_ratio} or 0.8)
local used = tonumber(${Feeder_active_power} or 0)

return rated * exitRatio - used

再新增一个触发方案，条件为 ${Feeder_headroom_exit_kw} >= 0 且 ${PCS1_power_setpoint} > 0（当前处于增容状态），动作为把 PCS1_power_setpoint 逐步归零，退出增容模式，转入正常调度策略（如低谷充电）。

六、与其他能力的组合

• 多台储能协同：若台区内有多套储能，可以通过 设备协作 把各储能的可用容量汇总为一个聚合点位，触发动作里按 SOC 高低或额定功率比例分配放电任务，思路与 充电桩负载均衡案例 中的均分算法一致。
• 云端可视化与调度：通过 云边协同 把 Feeder_headroom_kw、增容启停状态、储能出力等信息定时上报云平台，供运营人员远程监控多个台区的增容运行情况，云端也可以下发触发阈值等参数动态调整策略。
• 规模化复用：若同一批次项目有大量结构相同的台区（同型号 PCS/BMS、同样的策略骨架），可以用 设备单元动态扩展 把上述聚合点位定义为模板，新台区接入后自动生成配置，不需要逐个台区重复搭建。

七、小结

本案例中出现的所有能力——原始数据采集、聚合表达式计算余量、数据条件触发、写入动作下发指令、告警与 MQTT 上报——都是 Edge-EMS Builder 提供的通用零件，“台区临时增容”这个具体业务逻辑完全是通过配置组合出来的。把电表、PCS 换成其他设备，把阈值判断换成别的业务规则，同样的搭建思路可以复用到削峰填谷、需量控制、多能互补等几乎任何“监测 → 判断 → 执行”类场景。

本图根据本页配置逻辑绘制，展示数据与控制流程。具体操作字段请参照文中的配置与脚本。

⚠️ 本案例中的阈值比例、SOC 保护下限等参数仅为示例，实际项目需结合变压器额定容量、储能可用容量、当地调度要求等因素具体设定。