简介：电力需求响应依赖标准化的信息模型实现平台与负荷设备之间的语义互操作。集中式空调作为城市中规模最大、热惯性最突出的柔性可调负荷，其对象类、属性与状态机设计是模型建设的样板。通过将冷水机组、输配系统、末端设备映射为统一对象实例，并明确量测、控制、状态、能力四类属性语义，可支撑可调容量申报、调节速率约束与状态迁移校验，大幅降低负荷聚合与平台接入的联调成本。该建模方法适用于楼宇能源管理、虚拟电厂、负荷聚合商等工程场景，为实际空调系统参与需求响应提供一套可复用的落地路径。
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、variableFrequencyFlag | variableFrequencyFlag 决定能否用变频泵做平滑调节 |
| 末端负荷 | terminalType（AHU/FCU/VRF）、occupancyStatus、temperatureSetting、loadSheddingEnable | 末端不逐一建模，按层或按功能区聚合上报 |
这些属性不是简单堆字段，而是“量测、控制、状态、能力”四种语义分开。presentPower 是量测结果，平台只能读不能写；supplyTempSet 是控制属性，允许在响应窗口内被下发；participationStatus 是状态属性，只由网关根据本地执行结果上报，平台不能凭空修改；maxControllableCapacity 来自申报并需要校核，属于能力属性。后续扩展新对象时，也要按这四类对齐，不应该把只读量测混进控制字段里。
2.3 资源描述与能力参数：可调容量、调节速率、可持续时长怎么申报
需求响应平台在派单前要回答一个问题：这个空调系统到底能贡献多少容量、多久能到位？这些答案在信息模型里由资源能力对象表达。常见做法是让聚合商在响应季前按日填报一组能力参数，平台控制策略再基于这些参数决定是否把楼宇纳入可用资源池。
| 参数 | 含义 | 常见取值与约束 |
|---|---|---|
| baselinePower | 基线功率 | 响应事件前 1 小时实测平均功率，或按历史相似日模板；作为削减量计算的基准 |
| controllableCapacity | 可调容量 | 与系统对象上的 maxControllableCapacity 保持一致，平台派单量不允许超过该值 |
| rampRate | 调节速率 | kW/min；冷水机组群控时较快，但要避免多台机组同时启动造成电流冲击 |
| responseTime | 从收到指令到功率到位的时间 | 常见为 5～10 分钟；包含网关通信时延和冷机启停保护等待 |
| sustainableDuration | 可持续时长 | 取决于 minStopTime 较大机组的限制；一般按 30～120 分钟申报 |
| recoveryTime | 恢复时间 | 指令结束后，冷冻水温度逐步回设定值的时间，通常 15～30 分钟 |
申报能力和实际能力差异大是正常的，平台要做注册校核。一般做法是“预申报 + 实测校核”：先把能力参数写进资源对象完成注册，再由真实响应事件回放来修正。这样信息模型才能支撑平台在多个楼宇之间做聚合排序，而不是拿台账额定功率硬算。
3. 把物理空调映射成信息模型实例：五步落地与字段填法
3.1 第一步：盘点现场设备并确定聚合层级
动手建模之前，先做一次物理设备盘点。盘点表不需要是完整的资产台账，但一定要包括设备类型、台数、单台功率、控制方式和保护约束。下面是一栋甲级办公楼的典型盘点结果：
| 设备类型 | 典型配置 | 单机功率 | 控制方式 | 可控性 |
|---|---|---|---|---|
| 离心式冷水机组 | 2 台 | 480 kW | 群控开关、回水温度回设 | 可控，但受最小停机时间约束 |
| 冷冻水一次泵 | 2 用 1 备 | 45 kW | 定频/变频 | 变频时可平滑下调 |
| 冷却塔 | 4 台 | 11 kW | 风机分组启停 | 部分可控 |
| 末端 AHU | 12 台 | 7.5 kW | 变频调节风机转速 | 可控，与室内温度强相关 |
| 末端 FCU | 约 300 台 | 平均 0.2 kW | 电磁阀开关 | 通常不纳入快速响应 |
这张表不是给信息模型用的，而是给项目确认一个前提：哪些设备能真正响应、哪些只是保护逻辑的对象。比如离心机组的最小停机时间有 30 分钟，那么平台在派单前就必须知道这个约束，不然指令到了现场也会被本地控制逻辑吞掉。
3.2 第二步：搭建对象实例，从台账到模型的一一对应
盘点完成后，把物理对象映射成信息模型实例。映射关系的常见做法如下：
| 物理对象 | 信息模型对象 | 实例 ID 建议 |
|---|---|---|
| 整栋楼空调系统 | CentralAirConditioningSystem | site.CBD01.ACSystem.main |
| 2 台冷水机组及关联冷却塔 | ChillerSet | site.CBD01.ChillerSet.01 |
| 冷冻水泵组 | DistributionSystem | site.CBD01.Distribution.Pump1 |
| AHU 及 FCU | TerminalLoad | site.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 已接收 | 指令已确认但尚未动作 | 平台下发响应指令，网关返回 ACK |
| S2 调节中 | 正在执行削减/提升 | 网关下发群控命令且功率开始变化 |
| S3 恢复中 | 指令结束，温度回设 | 事件到期或平台下发结束指令 |
| S4 完成 | 已恢复至基线，待结算 | 恢复结束且功率回到许可偏差 |
| S5 不可用 | 设备报警、维保或保护触发 | 网关自检异常 |
状态迁移合法性要写成约束，网关只有在 S0 状态才接收新指令，S2 中收到重复指令时要判断覆盖条件。平台订阅状态变化，每次变化事件必须带 fromState 和 toState，不允许出现跳变，保护触发除外。这些约束在信息模型里要用枚举加迁移条件表表达，而不是简单放一个 status 字段，否则联调时“状态对不上”的问题会非常难查。
4.2 事件交互时序：响应指令怎么下发、状态怎么上报
一次完整的集中式空调需求响应，时序大体如下：
| 步骤 | 发送方 | 动作 | 关键字段 |
|---|---|---|---|
| 1 | 平台 → 网关 | 事件通知 | eventId、时段、目标负荷类型 |
| 2 | 网关 → 平台 | 事件确认 | ACCEPT / REJECT / BUSY |
| 3 | 平台 → 网关 | 预冷指令（可选） | 目标温度、提前时间 |
| 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:00+08: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 先发给网关侧做自测，影子测试通过后才正式派单，这一套流程走下来，翻车概率明显低了很多。这个方向值得投入，信息模型建设得越细，后期接入越多设备时越省力，希望帮到你。
本文还有配套的精品资源，点击获取
