电力需求响应信息模型：集中式空调负荷调控落地指南

简介：这份PDF文档是由中国电力企业联合会发布的正式标准《电力需求响应信息模型 第1部分：集中式空调系统》（T/CEC 239.1—2019），也是该系列标准的第1部分，于2020年1月1日起正式实施。它面向电网调度人员、自动需求响应终端与接口设计者、集中式空调设备厂商以及相关专业研究人员，重点解决大型建筑中集中式空调系统参与电力需求响应时，信息模型不统一、数据类型不规范、终端接口难以互联互通等问题，为负荷侧资源接入智能电网提供统一标准依据。资源共1个文件，为396KB的PDF全文，正文依次规定了建模原则、数据类型、通用包与专用包，并在资料性附录中给出了需求响应能力计算方法，结构清晰，便于直接查阅和引用。已有306人学习，适合从事需求响应系统开发、标准落地实施或空调节能方案设计的人员参考。通过该标准，读者可系统掌握集中式空调系统信息模型的构建要点，并为分散式空调、电热水器等其它负荷设备的信息建模提供对照框架。

1. 电力需求响应信息模型：先回答「空调能降多少、怎么降」

夏季电网尖峰时段，空调负荷在一栋商务楼里的占比经常到四五成，调度侧要削峰，第一反应就是动中央空调。真正难的不是能不能降，而是电网调度系统和楼宇能管系统之间说得上话——你问它「未来半小时能降多少」，它回你的是七八百个分散点位：冷机电流、水泵频率、阀门开度、温度设定值。电力需求响应信息模型（下文简称 DR 信息模型）第1部分：集中式空调系统，做的就是把这一堆点位翻译成一套标准语义：哪台设备、什么属性、单位是什么、能调到什么范围、响应要多久。这套模型定清楚之后，平台、网关、BA 系统厂商、运维单位各拿各的数据也能对齐。这篇笔记适合正在做需求响应平台或能管系统对接的集成工程师，也适合要给自己楼宇接 DR 的电气、暖通工程师。我只讲落地时真正用到的结构和参数，不给空泛概念。

2. 信息模型定的是什么：把语义边界、对象结构和数据粒度一次性说清

2.1 信息模型不是通信协议，也不是点位表

做集成时经常拿到一大沓点位表：地址 40101、寄存器值 28691、量程 0-65535。点位表描述了物理信号的存储位置，但要读懂它还是得靠老师傅的经验：28691 是「总有功功率」还是「冷冻水供水温度」？单位是 W 还是 0.1℃？同一个地址在不同厂商的控制器里可能含义完全不同。这就是语义问题，而语义问题正是 DR 信息模型要解决的。

信息模型只约定语义层，不管你数据是用 Modbus、BACnet 还是私有 TCP 协议传。通信协议解决「字节怎么传」，信息模型解决「这个字节代表什么」。把这一层拆开有个直接好处：通信可以继续沿用现有系统，只把语义对齐到同一套模型，不需要把楼宇自控系统推倒重来。很多项目失败，是因为把协议适配和语义转换搅在一起做，工期直接翻倍。我一般先做语义梳理，再谈协议怎么接。

2.2 三维度建模：物理对象、数据对象和服务对象

集中式空调 DR 信息模型在落地时通常拆成三个维度：

物理对象描述「有什么」，是树状结构，常见是四层：站点（Site，一栋楼或一个园区）、子系统（System，制冷站、空调水系统、末端风系统）、机组（Unit，冷水机组、水泵、AHU）、回路（Loop，某个区域或某组末端设备）。这棵树指导后续所有对象的寻址，相当于给每台设备上了户口。

数据对象描述「当前是什么状态」，一般分五类：测量值（Meaurement，功率、温度、流量，带量程和单位）、状态值（Status，运行/停机/故障/限载，枚举要定义全）、设定值（Setpoint，温度设定点、频率限值）、能力值（Capability，可调范围、响应时间）、事件（Event，告警、状态跳变）。注意区别：测量值是实时读出来的，能力值往往是算出来或标定出来的，两者来源不同，在模型里不能混。

服务对象描述「能做什么动作」，常见是四类：读请求、写请求、控制命令、事件订阅。控制命令不是简单写个寄存器，它要携带执行时间、目标值、持续时长、恢复策略。信息模型把服务也建模进去，是防止执行端拿着语义不清的字段乱操作。

2.3 粒度：调度要看整栋楼，排查要能钻到单台设备

信息模型设计里影响集成成本最大的决策是聚合粒度。DR 平台调度时只需要「整栋楼此刻的功率、未来还能降多少」，它调用站点级聚合对象的可调容量就够了。但现场调试时，楼宇某个区域温度没起来，你总要能从聚合值一路钻到是哪个 AHU 出了问题。如果模型里只有楼宇级的数据，排查时两眼一抹黑；如果每台设备每个轴承温度都建模，平台又被数据淹没。

我一般按三层来定粒度：聚合层给调度用，提供站点与子系统级的实时功率、可调容量、响应状态；设备层给运维和诊断用，提供单台设备的运行状态、设定值、故障码；映射层在网关侧做实时聚算。聚合值不是各传各的，而是通过映射关系实时算出来，这样才能保证上下两层看到的是同一个数。聚合结果和原始数据都在模型里保留，只是通过对象层级区分用途。

3. 集中式空调系统怎么被调：功率构成、能力参数与调度参数

3.1 先看清集中式空调的功率盘子

集中式空调系统通常由四块组成：冷源（水冷离心机组或风冷模块）、冷冻水系统（冷冻泵和管路）、冷却水系统（冷却泵、冷却塔）、末端系统（AHU 和风机盘管）。从功率占比看，典型经验是：冷机主机约占 50%-60%，冷却塔加冷却泵约占 20%-25%，冷冻泵约占 10%-15%，末端风机约占 10%-15%。

DR 调度时，这几块的调节手段完全不同，信息模型要把这些差异表达出来。冷水机组用台数控制和冷冻水出水温度上调来降载，但主机有最低负载率限制，一般不宜低于 40%-50%；变频冷冻泵和冷却泵可以限频运行，功率随频率的三次方下降，从 50Hz 降到 42Hz，功率大约能降四成；冷却塔风机可以按台数轮停，见效快但会影响冷凝压力；末端 AHU 风机降频或区域轮停，直接作用在室内温度上，舒适度约束最强。这些手段在模型里不是简单存一个额定功率完事，而是要让执行端知道「这个对象允许用哪种方式调」。

3.2 能力参数：能降多少、能坚持多久、响应多快

DR 申报时平台问的前三个问题永远是：当前出力是多少、可调容量是多少、多久能达到。能力对象就是回答这三个问题的，字段设计我一般用下面这套：

这里最容易翻车的点是 adjustable_power_max。不少项目直接拿铭牌容量去算可调容量，结果执行时发现根本达不到。可调容量受三件事限制：压缩机最低负载率、冷凝压力保护、末端室内温度上限。所以能力参数不应该从铭牌抄，应该实测标定，第5章我会专门展开。

3.3 调度参数：事件、控制模式与恢复策略

需求响应不是一个瞬时指令，而是一个有时间边界的过程。信息模型在调度侧要表达三段式：启动段，事件开始前预冷，把楼宇蓄冷量提前加满；保持段，通过温度上调、风机降频、冷机轮停把负荷压住；恢复段，事件结束后散热负荷分批回弹，不让功率瞬间冲回去。

这三段在模型里落到调度对象上。控制模式用枚举表达，比只给一个功率数值可靠得多。常见枚举包括：温度设定值偏移（TEMP_SETPOINT_OFFSET）、频率下限控制（FREQUENCY_LIMIT）、冷机轮停（CHILLER_SHED）、末端轮停（FCU_ROTATION）。每种模式都绑定自己的参数集，比如温度偏移模式带偏移量和允许的最高室温，频率下限模式带 Hz 限值和斜坡时长。

恢复策略是很多人漏掉的一项。事件结束所有空调同时恢复，负荷立刻反弹，形成比事件前更高的尖峰。常见做法是配「分批复归」：把末端按区域分成三批，每批隔几分钟恢复，能把回弹峰值压低不少。信息模型里要预留恢复策略字段，字段里至少包含恢复方式枚举、批次号、批次间隔。没有它的模型，调度侧永远会担心事件结束那一瞬间。

4. 从模型到报文：集中式空调 DR 的对象映射与落地样例

4.1 先把对象映射表做出来

我实施时不会直接写代码，而是先做一张映射表，把现场设备和信息模型对象对应起来。以典型的水冷集中式空调系统为例，映射表大概是这样的：

映射表是后续所有工作的核心作业。每家厂商的点表命名都不一样，这张表就是翻译字典。做表时有一个细节：备注列一定要写联动关系。比如「冷冻水出水温度上调 1℃ 对应冷机负载率大约下降 7%」这种经验值，写进去之后调试时排查快很多。表做完了，映射脚本只是机械劳动。

4.2 能力申报、实时遥测、控制指令三个报文样例

信息模型最终要通过报文体现。我用三组 JSON 样例说明常见做法，字段名以你最终使用的模型文档为准，但设计思路是通用的。

设备接入 DR 平台时，先做能力申报：

{ "dr_report": { "report_id": "RPT-CAP-20240715-001", "report_type": "capability_report", "timestamp": "2024-07-15T14:00:00+08:00", "object_id": "site.shanghai.cbd.tower_a", "capability": { "rated_power_kw": 520, "power_adjustable_max_kw": 128, "response_delay_s": 300, "max_shed_duration_s": 7200, "chilled_water_setpoint_range_c": [7, 10], "zone_temp_setpoint_range_c": [24, 28] } } }

这段报文的关键在能力字段的取值口径。rated_power_kw 写的是当前工况下的参考功率，不是铭牌容量；power_adjustable_max_kw 表示未来 30 分钟内预计能降出的最大负荷，这个数是实测标定出来的，不是估算出来的；response_delay_s 取 300 是因为集中式空调从指令下达到冷机实际降载，整个链路加系统惯性通常需要 5 到 10 分钟，报得太短会导致平台对响应速度判断失误。如果楼里有蓄冷罐，还可以在能力里增加一个预冷时长字段，表明这次降载能维持多久。

DR 事件执行中，网关按周期上报遥测数据，常见做法是 1 分钟上报原始数据、5 分钟做一次聚合：

{ "dr_telemetry": { "report_id": "TEL-20240715-1445-0008", "report_type": "telemetry", "timestamp": "2024-07-15T14:45:00+08:00", "object_id": "site.shanghai.cbd.tower_a.power", "measurements": { "total_active_power_kw": 468.5, "chilled_water_supply_temp_c": 8.2, "chilled_water_return_temp_c": 12.8, "zone_avg_temp_c": 25.5, "compressor_running_status": "running", "estimated_shed_kw": 51.5 } } }

上报频率直接关系到结算的准确性。DR 结算允许的负荷曲线粒度一般是 5 分钟，我把遥测做成 1 分钟原始、5 分钟聚合，既保证曲线不缺数又不把链路压满。温度类测量值要设死区，比如变化超过 0.3℃ 才上报，否则设定值附近的微小波动会让上报量翻倍。estimated_shed_kw 是网关根据基线实时算的估算降载量，给平台一个即时反馈，平台不用等到结算才知道这次响应做得好不好。

控制指令报文是执行端最关心的部分：

{ "dr_command": { "command_id": "CMD-DR-20240715-001", "command_type": "SET_ZONE_TEMP", "object_id": "site.shanghai.cbd.tower_a.zone.b3", "execution_time": "2024-07-15T14:30:00+08:00", "parameters": { "target_temp_c": 26, "ramp_duration_s": 600, "hold_duration_s": 3600, "recovery_policy": "batch_release", "recovery_batch": 2 } } }

注意这个指令没有直接写「降功率 20%」，而是写「把 B3 区室温目标设到 26℃，用 10 分钟斜坡爬上去，保持 1 小时，按第二批分批复归」。这里体现的是信息模型对控制模式的约束：只有知道执行端的控制模式能力，才能发对指令。ramp_duration_s 很关键，如果平台要求瞬时压负荷，空调系统只能粗暴停机，结果就是温度失控；斜坡时长给了控制系统缓冲时间，让冷机负载率平缓变化。

提示：三个报文里的字段名和枚举值是我在项目里常用的设计，最终以你采用的信息模型文档为准。重点是取值口径和控制模式的建模思路，别照抄字段名。

4.3 交换流程：从事件广播到闭环状态回报

报文不是孤立的，它要嵌在一个固定的交换流程里跑。常见的需求响应交换流程分四步：

第一步，平台下发 DR 事件通知，内容包括事件 ID、开始结束时间、目标削峰功率或控制模式。第二步，网关或楼宇自控系统确认收到事件，并返回能力申报，告诉平台这次实际能响应多少、预计延迟多久。第三步，事件执行中，网关按周期上报遥测数据，同时上报每台关键设备的执行状态。第四步，事件结束，网关上报恢复日志和完整负荷曲线，供结算和复盘用。

这个流程看似简单，实际跑起来常见的问题是平台下发的目标削峰功率是一个瞬时固定值，而空调系统的负荷变化是一条缓慢的斜坡曲线，两边对不上。解决方案是流程里强制加一步「执行可行性确认」：网关收到目标功率后，根据当前工况算出预计达到时间和最大可调容量，回给平台确认。平台按确认后的时间轴去考核，而不是按自己预想的固定时间点。这一条确认逻辑放在流程里，对接时能避免大量扯皮。

5. 集中式空调 DR 落地的五个常见坑与排查思路

5.1 时间基准不一致：结算时负荷曲线对不上账

现象：DR 事件结束，拉出平台记录的负荷曲线和现场楼宇自控系统导出的曲线一对比，两条曲线整体偏移三五分钟，结算电量怎么都对不上。

原因：现场的 PLC、DDC 控制器各自维护本机时间，时基漂移普遍存在。遥测报文里的时间戳有的是设备本机时间打的，有的是网关打的，混在一起就成了错位曲线。

解决：信息模型里所有时间戳统一由网关打点，设备时间只作为辅助字段上报。网关自身要配置标准时间同步，并且在校验逻辑里比较设备时间和网关时间的偏差，偏差超过 30 秒直接告警拒绝接收。时间问题不在模型字段上，而在数据链路的时间戳归属上，这一点最容易忽视，却最容易在结算阶段引发争议。

5.2 能力参数照抄铭牌：申报的可调容量全是虚的

现象：平台侧按设备铭牌额定功率算出可调容量，第一个正式 DR 事件执行时发现负荷根本降不到申报值，实际可调只有申报的六成。

原因：铭牌容量是设备在标准工况下的边界功率，可调容量受到多重限制：冷水机组最低负载率、主机冷凝压力保护、末端室内温度舒适度上限、水泵最低频率。这些约束叠加之后，可调空间远小于铭牌差值。

解决：能力申报不用铭牌数据，用实测标定。做法是挑非高峰时段做一次 30 分钟的真实响应测试，记录完整功率曲线，取三次测试的稳定可调值作为申报依据。宁可报小一点，让每次事件都稳稳达标，也不要报个亮眼数字然后每次执行都翻车。实测标定这个动作应该在正式接入前完成，并且每年重新标定一次，设备老化和工况变化都会让数据失效。

5.3 控制指令把「调节」做成「关断」

现象：下发某条控制指令后，楼宇自控系统直接停掉一台冷水机组，楼内温度快速上升，随后收到一堆投诉。

原因：现场集成时信息模型里只建了设备启停点位，没有建温度设定值偏移和频率下限这类调节型点位。执行端接到指令后，发现模型里没有对应执行通道，只能拿唯一的启停点位去响应，把调节需求变成了开关操作。

解决：在建模型阶段就把控制模式枚举定义完整，温度设定值偏移、频率下限、冷机轮停、末端轮停各是一种模式，每种模式绑定明确的参数约束。执行端只能按模式执行，不允许跨模式操作。验收时专门做一次控制通道检查，用 5 分钟的测试性调节验证每个模式都能工作，而不是等到正式事件才发现执行端只会开关。

5.4 点位表私有化：每次接入新厂商都要重新翻译

现象：接入第一家空调供应商时，花了两个星期做点表翻译。接入第二家时，同样的事情又来一遍，而且命名风格完全不一样，映射脚本也要重写。

原因：各家楼宇自控厂商的点表是私有格式，命名规则、点位粒度、数值单位各有各的约定。没有统一中间层，每次对接都是在重复造轮子。

解决：把信息模型对象映射表做成网关侧的固定中间层。网关对内接收厂商私有点表，对外只输出标准信息模型对象。厂商点位到标准对象的转换用一份映射配置维护，新厂商接入只改配置不改进程。实施时还有一个常见做法：把点位表按「数据类点位、控制类点位、状态类点位」先分组，再映射到信息模型，翻译效率会高很多。

5.5 只建遥测不建控制闭环：事件执行一半没有反馈

现象：平台能看到负荷数据，但 DR 事件执行到一半发现空调设备根本没动作，遥测值一点没变，事件白白走过去。

原因：集成时只把测量类数据对象接上了，服务对象的控制通道没联调。数据在上行，指令在下行，两条链路只有一条通。

解决：实施时先做控制通道自检。网关接入后，对每台可控设备执行一次测试性调节，确认指令发得下去、状态回得来、功率有变化，三步都通过再进入正式事件运营。测试性调节的幅度要小，比如温度设定点上调 0.5℃，既验证链路又不影响正常运营。控制闭环的检查应该写进验收清单，不是可选项。

6. 验收与进阶：一致性测试、真机检查和一份复盘文件

6.1 一致性测试：先过报文，再过对象树

一致性测试是正式并网前的最后一道关卡。我习惯分三层做：第一层是格式一致性，用脚本对报文逐字段校验类型、单位、枚举值是否合法；第二层是对象树一致性，把设备上报的对象清单和模型定义做映射比对，发现有没有缺失对象或多余对象；第三层是时序一致性，模拟一次完整的 DR 事件，检查事件通知、能力申报、遥测上报、恢复日志之间的先后关系是否符合模型里的流程定义。三层都过了，才放行到真机阶段。

6.2 真机验证：48 小时基线加两次事件

真机验证我的标准动作是跑 48 小时：前 24 小时采集基线负荷，后 24 小时做两次真实 DR 事件，一次是 30 分钟的浅调，一次是 60 分钟的强调。看三个指标：响应延迟是否落在申报范围内，容量达成率是否达到申报值的九成以上，恢复期回弹峰值是否控制在事件前功率的一点二倍以内。这三个指标直接决定这个系统能不能进入正式运营。

6.3 坚持写复盘文件：把每次 DR 事件变成下一次的输入

我自己的习惯是每次 DR 事件结束，把事件计划、实际负荷曲线、基线数据、温度轨迹、告警日志打成一个带时间戳的文件包，命名规则是「日期_D R_事件编号」。这家楼宇这次响应为什么只达到申报的八成，是预冷不充分还是某台冷机没跟上，全写在这个包里的备注文件上。下次做新项目时，先翻旧复盘比翻新文档更管用——设备会老化，工况会变，但踩过的坑永远是同一批。希望帮到你。

本文还有配套的精品资源，点击获取