简介《电力需求响应信息模型 第1部分集中式空调系统》是中国电力企业联合会发布的T/CEC 239.1—2019标准面向自动需求响应终端与接口的设计开发人员、智能电网软件工程师及电力需求侧管理从业者。标准规定了集中式空调系统需求响应信息模型的建模原则、数据类型、通用包与专用包并附有需求响应能力计算方法的资料性附录为设备制造商和软件开发者接入智能电网提供统一框架。资源包为1个PDF文件约396KB完整收录标准正文、前言、目次及附录便于查阅建模原则的实用性、便捷性、适用性与扩展性要求以及整型、字符串、浮点、布尔量、日期时间等数据类型定义。目前已有306人学习下载适合需要理解集中式空调参与需求响应业务互动、开展终端接口开发或研究同类负荷信息模型的读者参考。1. 集中式空调怎么变成电网的“可调负荷”电力需求响应信息模型拆开看夏天午后一栋写字楼的中央空调主机正满负荷运转冷冻水出水温度设到 7℃风机盘管呼呼吹。此时电网侧因为高温负荷吃紧调度希望这栋楼在 15 分钟内把用电功率压下来 200 kW。问题来了调度系统怎么知道这栋楼“能压多少、压多久、压完怎么恢复”楼里的自控系统又怎么知道“现在该执行哪条指令、执行到什么程度算完成”这两边如果各说各话需求响应就永远停在纸面。《电力需求响应信息模型 第1部分集中式空调系统》要解决的正是这件事给集中式空调这类可调负荷定义一套双方都能读懂的信息模型把“可调节能力”“响应指令”“执行状态”“基线”“效果核验”这些概念用统一的数据结构表达出来。它面向的是做楼宇自控、负荷聚合、虚拟电厂平台、电网需求响应系统的工程师不是纯理论研究者。你如果正在对接空调群控和调度主站这套模型就是中间的翻译层。2. 信息模型到底建了什么从物理设备到可交换数据对象2.1 集中式空调里哪些量值得建模集中式空调系统中央空调和分体式空调最大的区别是它有一套集中的冷热源和输配系统冷水机组、冷冻水泵、冷却水泵、冷却塔、末端风机盘管或组合式空调箱。需求响应关心的不是每个螺丝而是能影响电功率、又能在可接受时间内调整的那些量。常见做法是把可建模对象分成三类。第一类是状态量机组启停、水泵频率、阀门开度、冷冻水供回水温度、室内温度。第二类是能力量当前可上调/下调功率、可持续时间、恢复时间、最小调节步长。第三类是事件量响应开始、响应结束、执行反馈、效果评估结果。这三类量对应到信息模型里就是设备对象、能力对象和事件对象。我一般会先画一张“电功率影响链”哪些设备耗电、哪些参数能改、改了之后功率变化多少、多久能改到位。这张链决定了模型里要暴露哪些字段。比如冷却塔风机变频功率不大但调节快冷水机组加减机功率大但受最小运行时间限制。模型如果不区分这些时间尺度聚合商就会误判可调容量。2.2 信息模型的四层结构设备、能力、指令、反馈把上面三类量组织起来一个可落地的信息模型通常分四层。设备层描述“我是谁”设备唯一标识、设备类型冷机/水泵/冷却塔/末端、额定功率、所属系统。能力层描述“我能做什么”可调节功率区间、调节方向、响应时长、恢复时长、调节精度。指令层描述“要我做什么”指令编号、目标功率或目标温度、开始时间、持续时间、执行优先级。反馈层描述“我做了什么”实际执行功率、执行状态、偏差原因、完成时间。这四层不是拍脑袋分的它对应需求响应业务流程注册、能力上报、指令下发、执行反馈、效果结算。模型的价值在于让每一步都有明确的数据字段而不是靠电话和表格。2.3 用 JSON 表达一个空调可调节能力对象下面这段 JSON 是我在对接聚合平台时常用的能力上报结构字段名可以按实际协议调整但语义层次基本一致。{ resource_id: hvac_plant_001, resource_type: central_air_conditioning, rated_power_kw: 1200, adjustable_capacity: { down_kw: 200, up_kw: 0, min_step_kw: 20, response_time_min: 15, sustain_duration_min: 60, recovery_time_min: 30 }, constraints: { min_chiller_runtime_min: 30, supply_water_temp_range_c: [7, 12], indoor_temp_range_c: [24, 26] }, status: { online: true, current_power_kw: 980, current_mode: cooling } }这段结构里adjustable_capacity是核心它告诉调度“我最多能降 200 kW最小调 20 kW15 分钟能到位能撑 1 小时之后需要 30 分钟恢复”。constraints是边界防止指令把冷冻水温度设到结冰或把室温拉到不舒适。status是实时快照让调度知道你现在是不是在线、当前功率多少。参数说明response_time_min不是设备启动时间而是从收到指令到功率变化到位的时间包含通信、控制、物理过程。sustain_duration_min受室内温升速度限制写太大就是给自己挖坑。recovery_time_min是响应结束后回到正常运行的缓冲聚合商排计划时必须留出来。2.4 指令对象和反馈对象怎么配对指令下发和反馈上报必须能配对否则结算时对不上账。常见做法是用同一个event_id贯穿。{ event_id: dr_20240815_001, resource_id: hvac_plant_001, command: { type: power_reduction, target_kw: 200, start_time: 2024-08-15T14:00:0008:00, duration_min: 60, priority: high }, feedback: { status: executing, actual_reduction_kw: 180, deviation_reason: chiller_min_runtime_limit, timestamp: 2024-08-15T14:18:0008:00 } }command里target_kw是目标削减量不是目标功率。feedback里actual_reduction_kw是实际削减量deviation_reason解释为什么没达标。这个字段非常关键没有它聚合商和楼宇方就会互相扯皮。priority用于多事件冲突时决定谁先执行。3. 从模型到落地对接集中式空调系统的四个实操步骤3.1 第一步盘点可调设备并确定通信方式落地第一件事不是写代码是去现场或看图纸把参与需求响应的设备列出来。冷水机组、冷冻水泵、冷却水泵、冷却塔风机、末端空调箱哪些能接受外部指令哪些只能读不能写哪些有变频器哪些是工频直接启动。通信方式常见有三类BACnet、Modbus、厂家私有协议。BACnet 在楼宇自控里最通用Modbus 在中小项目里最多私有协议往往需要网关。我一般会先确认“写点”是否存在能不能远程改冷冻水出水温度设定、能不能远程限制机组负载率、能不能远程启停水泵。如果只能读不能写那这个设备只能作为状态监测不能算可调节资源。这一步的输出是一张设备清单表至少包含设备编号、设备类型、通信协议、可写点、可读点、功率范围、调节时间。这张表直接决定后面能力模型怎么填。3.2 第二步把设备能力映射成信息模型字段有了设备清单就可以填能力对象。映射规则我一般按下面这张表来。设备能力模型字段取值示例注意点最大可削减功率down_kw200取所有可调设备之和但要考虑同时率最小调节步长min_step_kw20受变频器精度和机组最小负载限制响应时间response_time_min15取最慢设备的时间不是平均值可持续时间sustain_duration_min60受室温允许波动范围约束恢复时间recovery_time_min30防止连续响应导致设备疲劳冷冻水温度下限supply_water_temp_range_c7低于此值可能结冰或效率骤降室温上限indoor_temp_range_c26超过此值舒适度投诉风险高这张表里最容易翻车的是“同时率”。比如三台冷机各能降 80 kW不代表能降 240 kW因为可能只有两台在运行或者降载后冷冻水温度会互相影响。我一般会按 0.7 到 0.8 的同时率折算再留 10% 余量。3.3 第三步写一个能力上报和指令接收的最小服务下面是一个用 Python 写的极简服务模拟资源侧向聚合平台上报能力、接收指令并返回反馈。实际项目里你会用 Flask 或 FastAPI这里用标准库减少依赖。import json import time from http.server import BaseHTTPRequestHandler, HTTPServer # 模拟当前设备状态 current_state { resource_id: hvac_plant_001, online: True, current_power_kw: 980, current_mode: cooling } # 能力对象实际应从设备盘点结果生成 capability { resource_id: hvac_plant_001, resource_type: central_air_conditioning, rated_power_kw: 1200, adjustable_capacity: { down_kw: 200, up_kw: 0, min_step_kw: 20, response_time_min: 15, sustain_duration_min: 60, recovery_time_min: 30 }, constraints: { min_chiller_runtime_min: 30, supply_water_temp_range_c: [7, 12], indoor_temp_range_c: [24, 26] } } class Handler(BaseHTTPRequestHandler): def do_GET(self): # 聚合平台拉取能力 if self.path /capability: body json.dumps(capability).encode() self.send_response(200) self.send_header(Content-Type, application/json) self.end_headers() self.wfile.write(body) # 聚合平台拉取实时状态 elif self.path /status: body json.dumps(current_state).encode() self.send_response(200) self.send_header(Content-Type, application/json) self.end_headers() self.wfile.write(body) else: self.send_response(404) self.end_headers() def do_POST(self): # 接收需求响应指令 if self.path /command: length int(self.headers.get(Content-Length, 0)) cmd json.loads(self.rfile.read(length)) event_id cmd.get(event_id) target_kw cmd.get(command, {}).get(target_kw, 0) # 这里应调用实际控制逻辑示例只做状态更新 actual min(target_kw, capability[adjustable_capacity][down_kw]) feedback { event_id: event_id, resource_id: capability[resource_id], feedback: { status: executing, actual_reduction_kw: actual, deviation_reason: if actual target_kw else capacity_limit, timestamp: time.strftime(%Y-%m-%dT%H:%M:%S08:00) } } body json.dumps(feedback).encode() self.send_response(200) self.send_header(Content-Type, application/json) self.end_headers() self.wfile.write(body) else: self.send_response(404) self.end_headers() if __name__ __main__: server HTTPServer((0.0.0.0, 8080), Handler) print(resource agent listening on 8080) server.serve_forever()逻辑说明GET /capability返回能力对象聚合平台注册时调用一次之后定期刷新。GET /status返回实时状态用于调度前确认资源在线。POST /command接收指令示例里直接按能力上限返回反馈真实项目里要触发设备控制逻辑并等待实际功率变化后再上报。参数说明target_kw是目标削减量不是目标功率。actual_reduction_kw应来自电表或功率采集不能直接抄指令值。deviation_reason为空表示达标非空要写清楚原因比如capacity_limit、device_fault、min_runtime_limit。时间戳建议带时区避免跨系统对时出错。3.4 第四步用基线核验响应效果需求响应做完必须算效果。最常用的基线算法是“前 N 天同时段平均法”取响应前 5 个非响应日的同一时段功率平均值作为基线功率。响应时段的实际功率与基线之差就是削减量。def calculate_baseline(history_power, event_start_hour, event_duration_hour): history_power: 列表每个元素是某天 24 小时功率单位 kW event_start_hour: 响应开始小时如 14 event_duration_hour: 响应持续小时如 1 # 取前 5 天同时段数据 samples [] for day in history_power[-5:]: segment day[event_start_hour:event_start_hour event_duration_hour] samples.append(sum(segment) / len(segment)) baseline sum(samples) / len(samples) return baseline def calculate_reduction(baseline_kw, actual_kw): # 削减量 基线 - 实际负值表示反而增加 return baseline_kw - actual_kw逻辑说明history_power是历史功率序列按天组织。calculate_baseline取最近 5 天同时段平均这是最常见做法。calculate_reduction算削减量正数表示有效削减。参数说明天数取 5 是经验值取太少受偶然波动影响取太多受天气趋势影响。如果响应时段跨越小时边界要按分钟级数据插值。实际项目中还要剔除异常日比如设备检修日、节假日。4. 避坑指南集中式空调需求响应最容易翻车的五个点4.1 现象指令下发后功率没变化反馈却显示“执行中”原因控制点写错了或者写到了只读寄存器。有些楼宇自控系统对外提供的是“监测点”而不是“控制点”写进去没反应。还有一种情况是网关做了地址映射文档和实际不一致。解决下发指令前先用读命令确认能读到该点再用写命令试写一个无害值观察设备响应。不要直接写目标值先用最小步长试。如果写不进去检查网关配置和权限。4.2 现象响应达标了但室温很快超标用户投诉原因可持续时间填得太乐观或者没有考虑室内热惯性。集中式空调降载后冷冻水温度上升末端换热能力下降室温会慢慢爬升。如果响应时间选在午后高温段温升更快。解决sustain_duration_min要按最不利工况填不要按额定工况。我一般会在响应前 30 分钟预冷把室温降到下限争取更多缓冲。同时设置室温上限保护超过 26℃ 自动退出响应。4.3 现象冷水机组频繁加减机能耗反而上升原因指令要求快速降载控制系统直接减机但减机后冷冻水温度波动又触发加机来回震荡。冷机有最小运行时间限制频繁启停既伤设备又费电。解决在模型里明确min_chiller_runtime_min控制逻辑里加迟滞区间。降载优先调水泵频率和冷却塔风机最后才动冷机。如果必须减机提前 10 分钟开始调整不要等到响应开始才动作。4.4 现象基线算出来偏高结算时被质疑原因基线选取的历史日包含了其他需求响应事件或者天气差异大。如果前 5 天里有 2 天也在做响应基线就偏低削减量被低估如果前 5 天都是凉爽天基线偏低削减量反而被高估。解决剔除响应日和异常日用天气相似日筛选。常见做法是按干球温度±2℃ 筛选历史日再取平均。如果数据够可以用回归法建立功率-温度模型比简单平均更稳。4.5 现象多个事件同时下发设备不知道听谁的原因没有优先级机制或者优先级字段没定义清楚。聚合平台可能同时收到电网调度指令和本地优化指令两者目标冲突。解决在指令对象里加priority字段约定数值越小优先级越高。本地安全保护永远最高优先级比如室温超限、设备故障。响应指令之间按优先级排序低优先级事件在高优先级执行期间挂起。5. 进阶技巧用能力曲线代替单点能力让聚合商更敢用你前面讲的能力对象是“单点能力”一个down_kw、一个response_time_min。但实际空调的可调能力是随时间变化的响应第 10 分钟能降 200 kW第 40 分钟可能只能降 120 kW因为室温在爬升。如果只报单点能力聚合商要么保守少用要么用过头导致你退出。进阶做法是上报“能力曲线”把可持续时间分成若干段每段给一个可削减功率。下面是一个能力曲线的 JSON 示例。{ resource_id: hvac_plant_001, capability_curve: [ {duration_min: 15, down_kw: 200}, {duration_min: 30, down_kw: 180}, {duration_min: 60, down_kw: 120}, {duration_min: 90, down_kw: 60} ], recovery_time_min: 30, min_step_kw: 20 }这张曲线告诉聚合商前 15 分钟能降 200 kW撑到 30 分钟只能降 180 kW撑到 1 小时只能降 120 kW超过 90 分钟只剩 60 kW。聚合商排计划时如果只需要 30 分钟响应可以按 180 kW 报如果需要 1 小时只能按 120 kW 报。这样既不会浪费可调能力也不会因为过度承诺导致违约。生成这条曲线的方法在响应时段内每隔 5 分钟记录一次实际功率和室温做多次响应试验取平均。如果没有试验条件可以用热力学模型估算室温从 24℃ 升到 26℃ 允许的时间就是可持续时间上限。我一般会留 10% 余量比如估算能撑 70 分钟就报 60 分钟。验证方法拿历史响应数据回测。把每次响应的实际削减量和持续时间画成散点看是否落在能力曲线下方。如果经常超出说明曲线报高了如果远低于曲线说明报保守了可以适当上调。还有一个技巧是“分段恢复”响应结束后不要一次性恢复满功率而是分 2 到 3 步每步间隔 10 分钟。这样对电网更友好也避免冷机频繁启停。恢复时间recovery_time_min要包含这个分段过程。最后说个血泪经验能力曲线不是一次标定就永久有效。季节变化、设备老化、末端改造都会影响可调能力。我一般每季度复测一次至少每年一次。如果懒得复测就在曲线上打个 8 折宁可少报不要违约。希望帮到你。本文还有配套的精品资源点击获取
