简介电力需求响应依赖标准化的信息模型实现平台与负荷设备之间的语义互操作。集中式空调作为城市中规模最大、热惯性最突出的柔性可调负荷其对象类、属性与状态机设计是模型建设的样板。通过将冷水机组、输配系统、末端设备映射为统一对象实例并明确量测、控制、状态、能力四类属性语义可支撑可调容量申报、调节速率约束与状态迁移校验大幅降低负荷聚合与平台接入的联调成本。该建模方法适用于楼宇能源管理、虚拟电厂、负荷聚合商等工程场景为实际空调系统参与需求响应提供一套可复用的落地路径。1. 电力需求响应信息模型为什么集中式空调会排在“第1部分”“电力需求响应信息模型”这串名词听起来像档案室里的一份标准文档但对接过需求响应平台的工程师都清楚它就是平台、聚合商和空调网关之间唯一能说同一种话的基础。一栋办公楼的集中式空调冷源、输配、末端设备来自不同厂家各自的数据字典、量测单位、控制方式完全不一样如果没有统一的模型每一家接入都要重新做协议翻译。这个系列把集中式空调放在第1部分因为它是城市里数量最大、热惯性最好、改造代价最低的可调负荷。本文写给做平台接入、负荷聚合或楼宇改造的工程师读完能把一台真实空调系统映射为模型实例并跑通一次完整的响应联调。2. 信息模型的核心组成对象类、属性和它们背后的设备语义2.1 从“点位表”到对象类信息模型到底改变了什么实际项目中最常见的做法是“点位表”对接在 DCS 或 BA 系统里导出一个个模拟量和开关量平台按照点位地址去读。点位表能解决“读到值”但解决不了“值是什么意思”同样一个 Power 属性A 厂家给的是整机功率B 厂家给的是机组电功率同样一个 Mode有人用 1 表示运行、有人用 0 表示运行。于是每接入一个新项目开发人员就要手工翻译一遍数据字典接口文档越写越厚语义仍然不统一联调基本靠猜和试成了黑匣子。信息模型的思路是把语义抽出来先定义行业通用的对象类再让各家设备实例去“继承”这些类。点位表的“地址-值”被替换成“对象-属性-值”平台不需要关心数据来自哪个寄存器只要这个对象是集中式空调系统就一定具备额定制冷量、额定功率、当前输出功率这些属性只要这个对象是冷水机组就一定具备最小启停间隔、冷冻水出水温度设定值这些属性。语义一致了接口变成标准化映射接入成本才会降下来。为什么这个系列的第一部分选集中式空调而不是电动汽车或储能因为它结构最规整冷源冷水机组、冷却塔、输配冷冻泵、冷却泵、末端风机盘管、AHU三个层级几乎每个项目都能套用而且它的响应特性最适合需求响应——热惯性大短时间调整几度设定值就能释放几百千瓦的容量人员感知又不明显。先把这个“样板”模型做稳定再去扩展到其他负荷才是正确的路径。2.2 集中式空调的模型骨架四个必建对象类和一张属性清单我建议至少建立四个对象类集中式空调系统系统级聚合根、冷源设备组、输配系统、末端负荷。前三个对应物理系统第四个对应楼宇内分散的末端设备它们之间是聚合与包含的关系。系统级对象负责容量、状态和结算相关的所有对外属性设备组对象负责可执行的控制属性输配系统和末端负荷对象支撑细粒度的调节策略评估。下表是我在一类项目里常用的属性清单字段名和类型可以直接在信息模型里沿用对象类建议属性说明集中式空调系统systemID、ratedPower、maxControllableCapacity、baselinePower、presentPower、participationStatus系统级对象只放聚合与结算属性participationStatus 取值有 available、reserved、curtailing、recovering、unavailable冷源设备组chillerNumber、totalRatedPower、coolingWaterSupplyTemp、coolingWaterReturnTemp、supplyTempSet、minRunTime、minStopTime、chillerPower最小启停间隔是模型里的关键保护参数后续派单策略要读取它输配系统pumpNumber、primaryPumpPower、secondaryPumpPower、flowRate、pressureDifference、variableFrequencyFlagvariableFrequencyFlag 决定能否用变频泵做平滑调节末端负荷terminalTypeAHU/FCU/VRF、occupancyStatus、temperatureSetting、loadSheddingEnable末端不逐一建模按层或按功能区聚合上报这些属性不是简单堆字段而是“量测、控制、状态、能力”四种语义分开。presentPower 是量测结果平台只能读不能写supplyTempSet 是控制属性允许在响应窗口内被下发participationStatus 是状态属性只由网关根据本地执行结果上报平台不能凭空修改maxControllableCapacity 来自申报并需要校核属于能力属性。后续扩展新对象时也要按这四类对齐不应该把只读量测混进控制字段里。2.3 资源描述与能力参数可调容量、调节速率、可持续时长怎么申报需求响应平台在派单前要回答一个问题这个空调系统到底能贡献多少容量、多久能到位这些答案在信息模型里由资源能力对象表达。常见做法是让聚合商在响应季前按日填报一组能力参数平台控制策略再基于这些参数决定是否把楼宇纳入可用资源池。参数含义常见取值与约束baselinePower基线功率响应事件前 1 小时实测平均功率或按历史相似日模板作为削减量计算的基准controllableCapacity可调容量与系统对象上的 maxControllableCapacity 保持一致平台派单量不允许超过该值rampRate调节速率kW/min冷水机组群控时较快但要避免多台机组同时启动造成电流冲击responseTime从收到指令到功率到位的时间常见为 510 分钟包含网关通信时延和冷机启停保护等待sustainableDuration可持续时长取决于 minStopTime 较大机组的限制一般按 30120 分钟申报recoveryTime恢复时间指令结束后冷冻水温度逐步回设定值的时间通常 1530 分钟申报能力和实际能力差异大是正常的平台要做注册校核。一般做法是“预申报 实测校核”先把能力参数写进资源对象完成注册再由真实响应事件回放来修正。这样信息模型才能支撑平台在多个楼宇之间做聚合排序而不是拿台账额定功率硬算。3. 把物理空调映射成信息模型实例五步落地与字段填法3.1 第一步盘点现场设备并确定聚合层级动手建模之前先做一次物理设备盘点。盘点表不需要是完整的资产台账但一定要包括设备类型、台数、单台功率、控制方式和保护约束。下面是一栋甲级办公楼的典型盘点结果设备类型典型配置单机功率控制方式可控性离心式冷水机组2 台480 kW群控开关、回水温度回设可控但受最小停机时间约束冷冻水一次泵2 用 1 备45 kW定频/变频变频时可平滑下调冷却塔4 台11 kW风机分组启停部分可控末端 AHU12 台7.5 kW变频调节风机转速可控与室内温度强相关末端 FCU约 300 台平均 0.2 kW电磁阀开关通常不纳入快速响应这张表不是给信息模型用的而是给项目确认一个前提哪些设备能真正响应、哪些只是保护逻辑的对象。比如离心机组的最小停机时间有 30 分钟那么平台在派单前就必须知道这个约束不然指令到了现场也会被本地控制逻辑吞掉。3.2 第二步搭建对象实例从台账到模型的一一对应盘点完成后把物理对象映射成信息模型实例。映射关系的常见做法如下物理对象信息模型对象实例 ID 建议整栋楼空调系统CentralAirConditioningSystemsite.CBD01.ACSystem.main2 台冷水机组及关联冷却塔ChillerSetsite.CBD01.ChillerSet.01冷冻水泵组DistributionSystemsite.CBD01.Distribution.Pump1AHU 及 FCUTerminalLoadsite.CBD01.Terminal.Level3实例 ID 要全局唯一建议统一规则按“站点.区域.对象类型.序号”拼装。一个物理设备不允许同时挂在多个系统对象下跨系统设备必须由系统级对象做引用避免两台冷水机组分别属于两个模型对象后平台按两个资源去派单结果现场一开一个跳闸。注意搭建实例时必须把“物理设备”和“注册资源”分开。物理设备完成映射只是台账工作只有把申报能力填进资源对象后系统才真正成为平台可调度的负荷。3.3 第三步能力参数、量测属性和状态枚举的取值约定参数怎么设是所有建模项目里最容易吵起来的地方。我给过一版约定基本能覆盖初版工程参数建议约定一句解释maxControllableCapacity额定功率 × 可切系数 × 同时系数例如两台 480 kW 的机泵组可切系数 0.7同时系数 0.8申报值约 537 kW比台账额定功率小 30%更接近实际响应能力minStep占总容量的 5%防止功率调节命令太密集造成平台指令震荡温度步进±1 ℃/次每次下调不得超过 1 ℃两次下调间隔至少 10 分钟功率上报周期15 分钟与结算周期匹配响应窗口内可加密到 1 分钟统计窗口1 分钟平均或 15 分钟平均平台侧做评估时统一口径避免按瞬时值判定量测属性的取值要明确单位功率统一为 kW温度统一为摄氏度。上报的温度如果是华氏度换算来的平台侧必须按模型里的 unit 字段换算不能看数值就直接入库。状态枚举也必须在模型里限定取值范围网关上报一个枚举之外的字符串时应该直接丢弃并告警而不是尝试解析。4. 需求响应的交互流程状态机、事件时序和报文格式4.1 状态机设计从“可调”到“恢复”的五个状态迁移有了对象模型还需要一套交互状态机来定义资源从接收到结束的完整生命周期。我常用的状态定义如下状态含义触发条件S0 待命系统可接受响应指令网关自检通过资源已注册S1 已接收指令已确认但尚未动作平台下发响应指令网关返回 ACKS2 调节中正在执行削减/提升网关下发群控命令且功率开始变化S3 恢复中指令结束温度回设事件到期或平台下发结束指令S4 完成已恢复至基线待结算恢复结束且功率回到许可偏差S5 不可用设备报警、维保或保护触发网关自检异常状态迁移合法性要写成约束网关只有在 S0 状态才接收新指令S2 中收到重复指令时要判断覆盖条件。平台订阅状态变化每次变化事件必须带 fromState 和 toState不允许出现跳变保护触发除外。这些约束在信息模型里要用枚举加迁移条件表表达而不是简单放一个 status 字段否则联调时“状态对不上”的问题会非常难查。4.2 事件交互时序响应指令怎么下发、状态怎么上报一次完整的集中式空调需求响应时序大体如下步骤发送方动作关键字段1平台 → 网关事件通知eventId、时段、目标负荷类型2网关 → 平台事件确认ACCEPT / REJECT / BUSY3平台 → 网关预冷指令可选目标温度、提前时间4平台 → 网关调节指令对象 ID、调节方向、目标调整量、生效时间、上报周期5网关 → 平台状态上报当前状态、实时功率、与目标偏差6平台 → 网关结束指令事件结束或提前终止7网关 → 平台恢复确认进入恢复状态上报剩余分钟数预冷指令只在填谷场景使用提前 30 分钟上调设定温度给混凝土楼板蓄冷相当于把削减容量折价转移到非高峰时段。调节指令里的“调节方向”是枚举值CURTAIL / SHIFT / RESUME。平台下发时给出一个目标承载值由网关按本地群控策略分批把功率拉过去而不是一次性切断设备。4.3 报文实例基于信息模型的 JSON 表达下面是一条调节指令的报文实例字段直接对应模型里的对象和属性{ eventId: DR-EVT-2025-0715-003, objectId: site.CBD01.ACSystem.main, action: { id: ACT-0032-01, type: CURTAIL, attribute: supplyTempSet, unit: DEGC, targetValue: 11, step: 1, stepIntervalMin: 10, effectiveTime: 2025-07-15T14:00:0008:00, durationMin: 60, reportPeriodSec: 300 } }这段报文想表达的是平台请求 CBD01 楼宇的空调系统执行削峰把冷冻水供水温度设定值从当前值下调到 11 ℃每次只调 1 ℃、间隔 10 分钟在 14:00 生效持续 60 分钟窗口内每 300 秒上报一次状态。这里的 attribute 指向的是模型里的控制属性 supplyTempSet而不是直接要求功率值功率变化是温度设定改变后的间接结果这样更符合空调系统的物理特性。提示effectiveTime 必须用带时区的绝对时间戳不能用“5 分钟后”之类的相对描述。网关收到的每一条指令都要先做 schema 校验校验不通过直接返回 REJECT而不是尝试理解。报文里的 step 和 stepIntervalMin 是保护参数来源于冷水机组的运行约束。如果平台一次性把温度从 14 ℃ 改到 11 ℃冷冻水温度骤降会让机组冷凝压力波动甚至触发喘振保护通过步进参数让控制过程可预期联调时也便于区分是平台策略问题还是设备执行问题。5. 落地避坑联调中常见的 5 个坑与排查路径5.1 现象、原因、解决五条真实踩坑记录坑 1聚合层级不一致平台算出来的可调容量偏大现象第一次联调时平台侧根据台账计算的可调容量比网关自报的值高约 30%下发削减后实际功率下降幅度并没有达到平台预期。 原因平台侧的建模把整个变压器下的全部空调负荷都算入了可调容量网关侧只统计了可控冷水机组对应的那部分功率两者口径没有在一个对象层级上对齐。 解决在信息模型里把“可调容量”属性固定挂在集中式空调系统对象上聚合商只允许在这个对象上进行容量申报子设备的功率量测只用作评估不参与派单。联调开始前先做一次模型一致性校验比对着两份对象实例清单逐条过。坑 2温度单位与精度不一致设定值被悄悄改写现象网关回传“已执行到 11.3 ℃”平台显示 11 ℃偏差判断始终不过。 原因网关侧采集的是华氏度整数换算成摄氏度后出现小数模型又把温度属性定义成了整型精度被截断。 解决温度属性统一定义为带两位小数的十进制数报文里同时带 unit 字段网关在上报前保留原始值不做二次舍入。联调前要确认单位是 DEGC 而不是 DEG-F这个字段一旦错后面所有温度相关判断都是翻车的。坑 3功率上报窗口不一致平台判定“未响应”现象平台显示该楼宇响应偏差超限网关侧却显示功率已经降到位两边截图对不上。 原因平台侧按 15 分钟平均功率判断网关上报的是 1 秒瞬时值瞬时值里冷冻泵启停的尖峰把平均值拉高了。 解决在量测属性里增加 statisticalWindow 字段明确该值是 1 分钟平均、5 分钟平均还是 15 分钟平均评估逻辑按同一窗口计算拿瞬时值对比平均值本身就是错的。坑 4机组保护逻辑吞掉调节指令现象平台下发了削减指令冷水机组没有动作网关也不报错只显示“指令已下发”。 原因上一轮运行刚结束机组还在最小停机时间内本地群控系统把启动指令拦截了信息模型里没有这个保护参数平台不知道现场执行不了。 解决在资源能力对象里增加 minCycleTime 与 protectionActive 标志。平台派单前先读取该标志在保护时段内不安排响应同时要求网关在保护拦截时返回状态 S5而不是静默忽略。坑 5恢复状态没有定义平台误判“过度响应”现象指令到期后网关立刻把设定温度回设到舒适温度功率反弹超过基线平台判定该用户超量响应影响了结算。 原因模型里只有“削峰”和“结束”两个状态没有给恢复过程留位置恢复期间功率升高是正常物理现象但评估逻辑把它当成恶意超调。 解决在状态枚举里补充 S3 恢复中并带上 remainingRecoveryTime。评估窗口必须覆盖恢复期把恢复阶段功率与基线功率的偏差单列统计不计入响应偏差。5.2 避坑的通用手段一致性校验清单与契约测试以上问题靠人盯是盯不过来的。项目启动时我会准备一张一致性校验清单校验项校验方法对象完整性每个上报对象必须能对应到已注册实例属性完备性必填字段缺失率为 0允许只读属性缺失枚举合法性参与状态值必须来自模型定义的枚举单位和标幺值功率统一为 kW温度统一为摄氏度杜绝裸数值上报周期reportPeriodSec 字段必须与平台约定一致状态迁移合法性状态跳变必须能沿状态机路径解释契约测试的做法是把信息模型导出成 schema网关侧在注册时先做 schema 校验平台侧用 mock 报文回放测试解析逻辑。正式联调分两步先纯离线对报文做解析和字段一致性核对再连真实设备做影子验证。网关侧自测不通过就不进入真实联调这能把上面的坑提前拦掉一大半。6. 验证与进阶用影子测试和扩展模型把信息模型做厚6.1 影子测试在没有真实响应事件时验证模型行为平台和网关都建好后先别急着派真实指令。常见做法是搭一条影子通道把真实空调运行数据复制一份进入平台的测试实例用同一套信息模型 schema 重新打包、重新上报平台侧完整执行派单、评估、结算逻辑但不对任何设备下发动作。用历史需求响应事件回放做输入检查平台策略容量选得对不对、上报链路时延有多大、状态机是否按预期跳转。影子测试的价值在于给平台策略一个“后悔药”。我一般会做一个对照影子通道和真实通道同时上报同一份数据平台不应出现双倍告警。如果影子通道在回放历史事件时把状态跳成了不可用说明模型的迁移条件写得太紧这时候调整的是模型而不是现场设备代价小很多。6.2 面向未来在信息模型上扩展负荷健康度评估信息模型不是建完就冻结的。集中式空调接入后平台真正关心的是“可持续调节能力”不是单次响应的瞬时值。我倾向于在现有对象上扩展一个健康度评估对象给每套机组增加 filterPressureDiff、copEstimate、energyAnomalyScore 三个属性让平台在派单前能看到设备是否处于亚健康状态。比如冷却塔填料结垢导致冷凝温度偏高时机组的可调容量会自动下降平台据此动态修正派单量。最后说一个我的习惯以前做项目时我总喜欢先把台账映射做完就觉得模型完成了结果真实联调时被状态一致性校验反复折腾。现在我会把 schema 先发给网关侧做自测影子测试通过后才正式派单这一套流程走下来翻车概率明显低了很多。这个方向值得投入信息模型建设得越细后期接入越多设备时越省力希望帮到你。本文还有配套的精品资源点击获取
简介电力需求响应依赖标准化的信息模型实现平台与负荷设备之间的语义互操作。集中式空调作为城市中规模最大、热惯性最突出的柔性可调负荷其对象类、属性与状态机设计是模型建设的样板。通过将冷水机组、输配系统、末端设备映射为统一对象实例并明确量测、控制、状态、能力四类属性语义可支撑可调容量申报、调节速率约束与状态迁移校验大幅降低负荷聚合与平台接入的联调成本。该建模方法适用于楼宇能源管理、虚拟电厂、负荷聚合商等工程场景为实际空调系统参与需求响应提供一套可复用的落地路径。1. 电力需求响应信息模型为什么集中式空调会排在“第1部分”“电力需求响应信息模型”这串名词听起来像档案室里的一份标准文档但对接过需求响应平台的工程师都清楚它就是平台、聚合商和空调网关之间唯一能说同一种话的基础。一栋办公楼的集中式空调冷源、输配、末端设备来自不同厂家各自的数据字典、量测单位、控制方式完全不一样如果没有统一的模型每一家接入都要重新做协议翻译。这个系列把集中式空调放在第1部分因为它是城市里数量最大、热惯性最好、改造代价最低的可调负荷。本文写给做平台接入、负荷聚合或楼宇改造的工程师读完能把一台真实空调系统映射为模型实例并跑通一次完整的响应联调。2. 信息模型的核心组成对象类、属性和它们背后的设备语义2.1 从“点位表”到对象类信息模型到底改变了什么实际项目中最常见的做法是“点位表”对接在 DCS 或 BA 系统里导出一个个模拟量和开关量平台按照点位地址去读。点位表能解决“读到值”但解决不了“值是什么意思”同样一个 Power 属性A 厂家给的是整机功率B 厂家给的是机组电功率同样一个 Mode有人用 1 表示运行、有人用 0 表示运行。于是每接入一个新项目开发人员就要手工翻译一遍数据字典接口文档越写越厚语义仍然不统一联调基本靠猜和试成了黑匣子。信息模型的思路是把语义抽出来先定义行业通用的对象类再让各家设备实例去“继承”这些类。点位表的“地址-值”被替换成“对象-属性-值”平台不需要关心数据来自哪个寄存器只要这个对象是集中式空调系统就一定具备额定制冷量、额定功率、当前输出功率这些属性只要这个对象是冷水机组就一定具备最小启停间隔、冷冻水出水温度设定值这些属性。语义一致了接口变成标准化映射接入成本才会降下来。为什么这个系列的第一部分选集中式空调而不是电动汽车或储能因为它结构最规整冷源冷水机组、冷却塔、输配冷冻泵、冷却泵、末端风机盘管、AHU三个层级几乎每个项目都能套用而且它的响应特性最适合需求响应——热惯性大短时间调整几度设定值就能释放几百千瓦的容量人员感知又不明显。先把这个“样板”模型做稳定再去扩展到其他负荷才是正确的路径。2.2 集中式空调的模型骨架四个必建对象类和一张属性清单我建议至少建立四个对象类集中式空调系统系统级聚合根、冷源设备组、输配系统、末端负荷。前三个对应物理系统第四个对应楼宇内分散的末端设备它们之间是聚合与包含的关系。系统级对象负责容量、状态和结算相关的所有对外属性设备组对象负责可执行的控制属性输配系统和末端负荷对象支撑细粒度的调节策略评估。下表是我在一类项目里常用的属性清单字段名和类型可以直接在信息模型里沿用对象类建议属性说明集中式空调系统systemID、ratedPower、maxControllableCapacity、baselinePower、presentPower、participationStatus系统级对象只放聚合与结算属性participationStatus 取值有 available、reserved、curtailing、recovering、unavailable冷源设备组chillerNumber、totalRatedPower、coolingWaterSupplyTemp、coolingWaterReturnTemp、supplyTempSet、minRunTime、minStopTime、chillerPower最小启停间隔是模型里的关键保护参数后续派单策略要读取它输配系统pumpNumber、primaryPumpPower、secondaryPumpPower、flowRate、pressureDifference、variableFrequencyFlagvariableFrequencyFlag 决定能否用变频泵做平滑调节末端负荷terminalTypeAHU/FCU/VRF、occupancyStatus、temperatureSetting、loadSheddingEnable末端不逐一建模按层或按功能区聚合上报这些属性不是简单堆字段而是“量测、控制、状态、能力”四种语义分开。presentPower 是量测结果平台只能读不能写supplyTempSet 是控制属性允许在响应窗口内被下发participationStatus 是状态属性只由网关根据本地执行结果上报平台不能凭空修改maxControllableCapacity 来自申报并需要校核属于能力属性。后续扩展新对象时也要按这四类对齐不应该把只读量测混进控制字段里。2.3 资源描述与能力参数可调容量、调节速率、可持续时长怎么申报需求响应平台在派单前要回答一个问题这个空调系统到底能贡献多少容量、多久能到位这些答案在信息模型里由资源能力对象表达。常见做法是让聚合商在响应季前按日填报一组能力参数平台控制策略再基于这些参数决定是否把楼宇纳入可用资源池。参数含义常见取值与约束baselinePower基线功率响应事件前 1 小时实测平均功率或按历史相似日模板作为削减量计算的基准controllableCapacity可调容量与系统对象上的 maxControllableCapacity 保持一致平台派单量不允许超过该值rampRate调节速率kW/min冷水机组群控时较快但要避免多台机组同时启动造成电流冲击responseTime从收到指令到功率到位的时间常见为 510 分钟包含网关通信时延和冷机启停保护等待sustainableDuration可持续时长取决于 minStopTime 较大机组的限制一般按 30120 分钟申报recoveryTime恢复时间指令结束后冷冻水温度逐步回设定值的时间通常 1530 分钟申报能力和实际能力差异大是正常的平台要做注册校核。一般做法是“预申报 实测校核”先把能力参数写进资源对象完成注册再由真实响应事件回放来修正。这样信息模型才能支撑平台在多个楼宇之间做聚合排序而不是拿台账额定功率硬算。3. 把物理空调映射成信息模型实例五步落地与字段填法3.1 第一步盘点现场设备并确定聚合层级动手建模之前先做一次物理设备盘点。盘点表不需要是完整的资产台账但一定要包括设备类型、台数、单台功率、控制方式和保护约束。下面是一栋甲级办公楼的典型盘点结果设备类型典型配置单机功率控制方式可控性离心式冷水机组2 台480 kW群控开关、回水温度回设可控但受最小停机时间约束冷冻水一次泵2 用 1 备45 kW定频/变频变频时可平滑下调冷却塔4 台11 kW风机分组启停部分可控末端 AHU12 台7.5 kW变频调节风机转速可控与室内温度强相关末端 FCU约 300 台平均 0.2 kW电磁阀开关通常不纳入快速响应这张表不是给信息模型用的而是给项目确认一个前提哪些设备能真正响应、哪些只是保护逻辑的对象。比如离心机组的最小停机时间有 30 分钟那么平台在派单前就必须知道这个约束不然指令到了现场也会被本地控制逻辑吞掉。3.2 第二步搭建对象实例从台账到模型的一一对应盘点完成后把物理对象映射成信息模型实例。映射关系的常见做法如下物理对象信息模型对象实例 ID 建议整栋楼空调系统CentralAirConditioningSystemsite.CBD01.ACSystem.main2 台冷水机组及关联冷却塔ChillerSetsite.CBD01.ChillerSet.01冷冻水泵组DistributionSystemsite.CBD01.Distribution.Pump1AHU 及 FCUTerminalLoadsite.CBD01.Terminal.Level3实例 ID 要全局唯一建议统一规则按“站点.区域.对象类型.序号”拼装。一个物理设备不允许同时挂在多个系统对象下跨系统设备必须由系统级对象做引用避免两台冷水机组分别属于两个模型对象后平台按两个资源去派单结果现场一开一个跳闸。注意搭建实例时必须把“物理设备”和“注册资源”分开。物理设备完成映射只是台账工作只有把申报能力填进资源对象后系统才真正成为平台可调度的负荷。3.3 第三步能力参数、量测属性和状态枚举的取值约定参数怎么设是所有建模项目里最容易吵起来的地方。我给过一版约定基本能覆盖初版工程参数建议约定一句解释maxControllableCapacity额定功率 × 可切系数 × 同时系数例如两台 480 kW 的机泵组可切系数 0.7同时系数 0.8申报值约 537 kW比台账额定功率小 30%更接近实际响应能力minStep占总容量的 5%防止功率调节命令太密集造成平台指令震荡温度步进±1 ℃/次每次下调不得超过 1 ℃两次下调间隔至少 10 分钟功率上报周期15 分钟与结算周期匹配响应窗口内可加密到 1 分钟统计窗口1 分钟平均或 15 分钟平均平台侧做评估时统一口径避免按瞬时值判定量测属性的取值要明确单位功率统一为 kW温度统一为摄氏度。上报的温度如果是华氏度换算来的平台侧必须按模型里的 unit 字段换算不能看数值就直接入库。状态枚举也必须在模型里限定取值范围网关上报一个枚举之外的字符串时应该直接丢弃并告警而不是尝试解析。4. 需求响应的交互流程状态机、事件时序和报文格式4.1 状态机设计从“可调”到“恢复”的五个状态迁移有了对象模型还需要一套交互状态机来定义资源从接收到结束的完整生命周期。我常用的状态定义如下状态含义触发条件S0 待命系统可接受响应指令网关自检通过资源已注册S1 已接收指令已确认但尚未动作平台下发响应指令网关返回 ACKS2 调节中正在执行削减/提升网关下发群控命令且功率开始变化S3 恢复中指令结束温度回设事件到期或平台下发结束指令S4 完成已恢复至基线待结算恢复结束且功率回到许可偏差S5 不可用设备报警、维保或保护触发网关自检异常状态迁移合法性要写成约束网关只有在 S0 状态才接收新指令S2 中收到重复指令时要判断覆盖条件。平台订阅状态变化每次变化事件必须带 fromState 和 toState不允许出现跳变保护触发除外。这些约束在信息模型里要用枚举加迁移条件表表达而不是简单放一个 status 字段否则联调时“状态对不上”的问题会非常难查。4.2 事件交互时序响应指令怎么下发、状态怎么上报一次完整的集中式空调需求响应时序大体如下步骤发送方动作关键字段1平台 → 网关事件通知eventId、时段、目标负荷类型2网关 → 平台事件确认ACCEPT / REJECT / BUSY3平台 → 网关预冷指令可选目标温度、提前时间4平台 → 网关调节指令对象 ID、调节方向、目标调整量、生效时间、上报周期5网关 → 平台状态上报当前状态、实时功率、与目标偏差6平台 → 网关结束指令事件结束或提前终止7网关 → 平台恢复确认进入恢复状态上报剩余分钟数预冷指令只在填谷场景使用提前 30 分钟上调设定温度给混凝土楼板蓄冷相当于把削减容量折价转移到非高峰时段。调节指令里的“调节方向”是枚举值CURTAIL / SHIFT / RESUME。平台下发时给出一个目标承载值由网关按本地群控策略分批把功率拉过去而不是一次性切断设备。4.3 报文实例基于信息模型的 JSON 表达下面是一条调节指令的报文实例字段直接对应模型里的对象和属性{ eventId: DR-EVT-2025-0715-003, objectId: site.CBD01.ACSystem.main, action: { id: ACT-0032-01, type: CURTAIL, attribute: supplyTempSet, unit: DEGC, targetValue: 11, step: 1, stepIntervalMin: 10, effectiveTime: 2025-07-15T14:00:0008:00, durationMin: 60, reportPeriodSec: 300 } }这段报文想表达的是平台请求 CBD01 楼宇的空调系统执行削峰把冷冻水供水温度设定值从当前值下调到 11 ℃每次只调 1 ℃、间隔 10 分钟在 14:00 生效持续 60 分钟窗口内每 300 秒上报一次状态。这里的 attribute 指向的是模型里的控制属性 supplyTempSet而不是直接要求功率值功率变化是温度设定改变后的间接结果这样更符合空调系统的物理特性。提示effectiveTime 必须用带时区的绝对时间戳不能用“5 分钟后”之类的相对描述。网关收到的每一条指令都要先做 schema 校验校验不通过直接返回 REJECT而不是尝试理解。报文里的 step 和 stepIntervalMin 是保护参数来源于冷水机组的运行约束。如果平台一次性把温度从 14 ℃ 改到 11 ℃冷冻水温度骤降会让机组冷凝压力波动甚至触发喘振保护通过步进参数让控制过程可预期联调时也便于区分是平台策略问题还是设备执行问题。5. 落地避坑联调中常见的 5 个坑与排查路径5.1 现象、原因、解决五条真实踩坑记录坑 1聚合层级不一致平台算出来的可调容量偏大现象第一次联调时平台侧根据台账计算的可调容量比网关自报的值高约 30%下发削减后实际功率下降幅度并没有达到平台预期。 原因平台侧的建模把整个变压器下的全部空调负荷都算入了可调容量网关侧只统计了可控冷水机组对应的那部分功率两者口径没有在一个对象层级上对齐。 解决在信息模型里把“可调容量”属性固定挂在集中式空调系统对象上聚合商只允许在这个对象上进行容量申报子设备的功率量测只用作评估不参与派单。联调开始前先做一次模型一致性校验比对着两份对象实例清单逐条过。坑 2温度单位与精度不一致设定值被悄悄改写现象网关回传“已执行到 11.3 ℃”平台显示 11 ℃偏差判断始终不过。 原因网关侧采集的是华氏度整数换算成摄氏度后出现小数模型又把温度属性定义成了整型精度被截断。 解决温度属性统一定义为带两位小数的十进制数报文里同时带 unit 字段网关在上报前保留原始值不做二次舍入。联调前要确认单位是 DEGC 而不是 DEG-F这个字段一旦错后面所有温度相关判断都是翻车的。坑 3功率上报窗口不一致平台判定“未响应”现象平台显示该楼宇响应偏差超限网关侧却显示功率已经降到位两边截图对不上。 原因平台侧按 15 分钟平均功率判断网关上报的是 1 秒瞬时值瞬时值里冷冻泵启停的尖峰把平均值拉高了。 解决在量测属性里增加 statisticalWindow 字段明确该值是 1 分钟平均、5 分钟平均还是 15 分钟平均评估逻辑按同一窗口计算拿瞬时值对比平均值本身就是错的。坑 4机组保护逻辑吞掉调节指令现象平台下发了削减指令冷水机组没有动作网关也不报错只显示“指令已下发”。 原因上一轮运行刚结束机组还在最小停机时间内本地群控系统把启动指令拦截了信息模型里没有这个保护参数平台不知道现场执行不了。 解决在资源能力对象里增加 minCycleTime 与 protectionActive 标志。平台派单前先读取该标志在保护时段内不安排响应同时要求网关在保护拦截时返回状态 S5而不是静默忽略。坑 5恢复状态没有定义平台误判“过度响应”现象指令到期后网关立刻把设定温度回设到舒适温度功率反弹超过基线平台判定该用户超量响应影响了结算。 原因模型里只有“削峰”和“结束”两个状态没有给恢复过程留位置恢复期间功率升高是正常物理现象但评估逻辑把它当成恶意超调。 解决在状态枚举里补充 S3 恢复中并带上 remainingRecoveryTime。评估窗口必须覆盖恢复期把恢复阶段功率与基线功率的偏差单列统计不计入响应偏差。5.2 避坑的通用手段一致性校验清单与契约测试以上问题靠人盯是盯不过来的。项目启动时我会准备一张一致性校验清单校验项校验方法对象完整性每个上报对象必须能对应到已注册实例属性完备性必填字段缺失率为 0允许只读属性缺失枚举合法性参与状态值必须来自模型定义的枚举单位和标幺值功率统一为 kW温度统一为摄氏度杜绝裸数值上报周期reportPeriodSec 字段必须与平台约定一致状态迁移合法性状态跳变必须能沿状态机路径解释契约测试的做法是把信息模型导出成 schema网关侧在注册时先做 schema 校验平台侧用 mock 报文回放测试解析逻辑。正式联调分两步先纯离线对报文做解析和字段一致性核对再连真实设备做影子验证。网关侧自测不通过就不进入真实联调这能把上面的坑提前拦掉一大半。6. 验证与进阶用影子测试和扩展模型把信息模型做厚6.1 影子测试在没有真实响应事件时验证模型行为平台和网关都建好后先别急着派真实指令。常见做法是搭一条影子通道把真实空调运行数据复制一份进入平台的测试实例用同一套信息模型 schema 重新打包、重新上报平台侧完整执行派单、评估、结算逻辑但不对任何设备下发动作。用历史需求响应事件回放做输入检查平台策略容量选得对不对、上报链路时延有多大、状态机是否按预期跳转。影子测试的价值在于给平台策略一个“后悔药”。我一般会做一个对照影子通道和真实通道同时上报同一份数据平台不应出现双倍告警。如果影子通道在回放历史事件时把状态跳成了不可用说明模型的迁移条件写得太紧这时候调整的是模型而不是现场设备代价小很多。6.2 面向未来在信息模型上扩展负荷健康度评估信息模型不是建完就冻结的。集中式空调接入后平台真正关心的是“可持续调节能力”不是单次响应的瞬时值。我倾向于在现有对象上扩展一个健康度评估对象给每套机组增加 filterPressureDiff、copEstimate、energyAnomalyScore 三个属性让平台在派单前能看到设备是否处于亚健康状态。比如冷却塔填料结垢导致冷凝温度偏高时机组的可调容量会自动下降平台据此动态修正派单量。最后说一个我的习惯以前做项目时我总喜欢先把台账映射做完就觉得模型完成了结果真实联调时被状态一致性校验反复折腾。现在我会把 schema 先发给网关侧做自测影子测试通过后才正式派单这一套流程走下来翻车概率明显低了很多。这个方向值得投入信息模型建设得越细后期接入越多设备时越省力希望帮到你。本文还有配套的精品资源点击获取
