简介：这份资源是T/CEC 239.1—2019《电力需求响应信息模型 第1部分：集中式空调系统》标准全文，面向电力需求响应终端与接口的设计开发人员、智能电网研究人员及空调设备制造商。标准规定了集中式空调系统需求响应信息模型的建模原则、数据类型、通用包与专用包，并附有需求响应能力计算方法的资料性附录，适用于自动需求响应终端和接口的设计与开发。资源包内含1个PDF文件，大小约396KB，内容涵盖范围、规范性引用文件、术语定义、建模原则、数据类型、通用包、专用包及附录等完整章节，目录结构清晰，便于按模块查阅。目前已有306人学习下载。通过这份标准，读者可以掌握集中式空调系统参与电网需求响应的信息建模方法，理解实用性、便捷性、适用性与扩展性等建模原则，并借助附录中的计算方法评估需求响应潜力，为设备集成与软件开发提供规范依据。
1. 电力需求响应信息模型第1部分：集中式空调系统到底在建模什么
夏天午后两点，电网负荷曲线冲上尖峰，调度侧希望把一批写字楼的集中式空调系统短时降功率，但真正落地时你会发现一个尴尬现实：调度能看到的只是几路总功率遥测，既不知道每台冷水机组当前在不在可调节区间，也说不清“降多少、降多久、恢复到什么程度”该怎么下发。电力需求响应信息模型第1部分：集中式空调系统，要解决的就是这层语义断层——把集中式空调里可参与需求响应的设备、能力、约束和事件，用一套统一的信息模型描述出来，让主站、聚合商、楼宇自控三方对同一句话有同一个理解。
它适合三类人：做需求响应平台后端、需要对接空调负荷的开发者；做楼宇自控或能源管理、要把冷站数据往上送的工程师；以及做聚合调控策略、需要知道“这台机组到底能被调多少”的算法同学。这一部分专攻集中式空调系统，也就是冷水机组加冷冻水循环、冷却水循环、末端风机盘管或组合式空调箱这一类，而不是分体空调那种分散设备。模型的价值不在通信本身，而在于把“可调节能力”变成可计算、可校验、可下发的结构化信息。
2. 集中式空调参与需求响应的信息模型怎么分层
2.1 从物理设备到可调节资源的四层抽象
集中式空调要进需求响应，不能直接把一台冷水机组的启停信号丢给调度，中间必须做抽象。我一般按四层来拆：物理设备层、监控点位层、能力描述层、事件交互层。
物理设备层是冷站里真实存在的对象：冷水机组、冷冻水泵、冷却水泵、冷却塔、电动调节阀、末端空调箱。监控点位层是这些设备在楼宇自控里的测点，比如机组运行状态、冷冻水供回水温度、水泵频率、阀门开度。能力描述层是这套模型真正要新增的东西——它不描述“现在温度是多少”，而描述“在什么条件下、能把功率压到多少、持续多久、多久能恢复”。事件交互层则是需求响应事件的下发、确认、执行、反馈闭环。
这四层分开的好处是：设备换型、点位改名，不会动摇上层能力描述；调度策略调整，也不用去改底层点表。很多项目翻车就翻在把能力描述直接绑死在某个具体点位上，一旦冷站改造，整套对接全废。
2.2 为什么用面向对象而不是点表堆叠
传统做法是给调度一张大点表，几百个遥测遥信，调度自己猜哪些能调。集中式空调的调节能力是强耦合的：冷水机组降载会牵连冷冻水温度、末端舒适度、水泵频率，单看一个点根本判断不了可调空间。面向对象的建模方式把“集中式空调系统”作为一个整体对象，下面挂子设备对象，每个对象带属性、方法、事件。
对象化的核心收益是约束可以挂在对象上。比如“冷冻水供水温度不得高于某阈值”这条约束，属于系统级属性，而不是某个测点的属性。调度下发调节指令时，模型能直接校验这条约束，而不是等执行完才发现末端投诉。这也是这套模型和普通点表协议最本质的区别：它承载语义，不只是承载数值。
2.3 最小可用对象清单与属性定义
落地时不必一上来就全量建模，先做一个最小可用子集。下面这张表是我在几个项目里反复收敛出来的核心对象和关键属性，够跑通一次完整的调节事件。
| 对象 | 关键属性 | 说明 |
|---|---|---|
| 集中式空调系统 | 系统编号、额定功率、当前功率、可调功率上限、可调功率下限 | 聚合商视角的顶层对象 |
| 冷水机组 | 运行状态、负载率、最小负载率、允许启停次数/小时 | 决定可下调空间的核心设备 |
| 冷冻水循环 | 供水温度设定、回水温度、水泵频率、最低频率 | 约束调节幅度的关键回路 |
| 冷却水循环 | 冷却水温度、冷却塔风机档位 | 影响机组效率与调节可持续性 |
| 末端 | 区域温度、设定温度、允许偏差 | 舒适度约束来源 |
| 调节能力 | 可下调功率、可持续时长、恢复时长、调节精度 | 能力描述层的核心输出 |
属性定义时有两个容易忽略的点：一是量纲要统一，功率用千瓦、温度用摄氏度、时长用分钟，别混；二是每个可调属性都要带时间戳和品质位，否则调度拿到一个过期值做决策，后果比没有数据更糟。
2.4 一次需求响应事件的完整交互时序
模型建好之后，要能跑通一次事件。典型时序是：调度生成事件（含调节目标、起止时间、约束）→ 聚合商校验本侧可调能力 → 下发到楼宇自控 → 冷站执行降载 → 逐级反馈执行状态与实际功率 → 事件结束后按恢复时长回升。
这里的关键是“校验”和“反馈”两个环节。校验发生在下发前，用能力描述层的数据判断能不能接；反馈发生在执行中，用实际功率和状态回报。很多对接只做了下发没做反馈，调度根本不知道楼宇到底执行了没有，需求响应就成了开环控制，效果全凭运气。
# 需求响应事件校验的最小逻辑示例 # 输入：事件目标下调功率 target_kw，持续时长 duration_min # 输出：是否可接受，以及实际可承诺的调节量 def check_dr_capacity(system, target_kw, duration_min): # 1. 取系统当前可调功率上限（能力描述层提供） max_reducible = system.capability.max_reducible_kw # 2. 取可持续时长，超过则不可承诺全额 sustain_min = system.capability.sustain_minutes if duration_min > sustain_min: # 超出可持续时长，按比例折算可承诺量 ratio = sustain_min / duration_min committed = min(target_kw, max_reducible * ratio) else: committed = min(target_kw, max_reducible) # 3. 校验末端舒适度约束，若当前偏差已接近上限则拒绝 if system.terminal.temp_deviation >= system.terminal.allowed_deviation: return False, 0 # 4. 校验机组最小负载率，避免降载后触发停机 if system.chiller.load_rate - committed / system.chiller.rated_kw < system.chiller.min_load_rate: committed = (system.chiller.load_rate - system.chiller.min_load_rate) * system.chiller.rated_kw return committed > 0, committed这段逻辑说明三件事：可调量不是固定值，要同时受可持续时长、末端约束、机组最小负载率三重限制；折算比例是工程上常用的近似，真实项目里还要考虑冷量惯性；返回的 committed 才是能写进事件确认的量，而不是 target_kw。参数上，max_reducible_kw 和 sustain_minutes 来自能力描述层，min_load_rate 来自设备台账，allowed_deviation 来自舒适度合同或运行规程。
3. 把模型落到工程里的实现步骤
3.1 从冷站点表到模型对象的映射方法
第一步永远是点表梳理。拿到的冷站点表通常几百上千行，命名五花八门。我的做法是先按设备类型分组，再按“状态、测量、设定、报警”四类打标，最后只保留与调节能力相关的点进入模型。
映射时用一张对照表，左边是原点位，右边是模型对象属性。比如点位“CH1_RUN”映射到冷水机组对象的运行状态，“CH1_LOAD”映射到负载率。映射过程中会遇到一个点对应多个语义的情况，比如“冷冻水供水温度”既是测量值，又是约束判断依据，这时在模型里只存一份，通过引用被多处使用，避免数据不一致。
# 点表到模型对象的映射示例 POINT_MAPPING = { "CH1_RUN": ("chiller_1", "run_status", "bool"), "CH1_LOAD": ("chiller_1", "load_rate", "float"), "CHWP1_FRQ": ("chwp_1", "frequency", "float"), "CHWS_TEMP": ("chilled_water_loop", "supply_temp", "float"), "AHU1_TEMP": ("terminal_1", "zone_temp", "float"), } def map_point(point_name, raw_value): if point_name not in POINT_MAPPING: return None # 未映射点位直接丢弃，不进入模型 obj, attr, dtype = POINT_MAPPING[point_name] if dtype == "bool": value = bool(raw_value) elif dtype == "float": value = float(raw_value) else: value = raw_value return {"object": obj, "attribute": attr, "value": value}映射表要版本化管理，冷站改造后点表变了，映射表跟着更新，模型对象结构尽量不动。这是保持长期可维护的关键。参数上，dtype 决定了解析方式，未映射点位直接丢弃而不是塞进模型，能避免模型被垃圾数据污染。
3.2 可调节能力的计算与上报
能力描述层的数据不是测出来的，是算出来的。核心输入有三块：设备额定参数、当前运行工况、约束条件。输出是四个值：可下调功率、可上调功率（如果支持）、可持续时长、恢复时长。
计算可下调功率时，冷水机组是主力。可下调量约等于当前功率减去最小负载率对应的功率，再叠加水泵变频可降的部分。可持续时长受冷冻水温度上升速度约束，通常用历史数据拟合一个温升速率，反推允许的时长。恢复时长则取决于把温度拉回来需要多久，和机组制冷能力、末端负荷有关。
def calc_capability(system, history): # 可下调功率：机组 + 水泵 chiller_reducible = (system.chiller.load_rate - system.chiller.min_load_rate) * system.chiller.rated_kw pump_reducible = (system.chwp.frequency - system.chwp.min_frequency) / system.chwp.frequency * system.chwp.rated_kw max_reducible = max(0, chiller_reducible + pump_reducible) # 可持续时长：用历史温升速率反推 temp_rise_rate = history.temp_rise_per_minute # 摄氏度/分钟 allowed_rise = system.terminal.allowed_deviation sustain_minutes = allowed_rise / temp_rise_rate if temp_rise_rate > 0 else 60 # 恢复时长：按制冷余量估算 recover_minutes = allowed_rise / (system.chiller.rated_kw * 0.1) * 60 return { "max_reducible_kw": round(max_reducible, 1), "sustain_minutes": round(sustain_minutes, 0), "recover_minutes": round(recover_minutes, 0), }这段代码里 temp_rise_per_minute 是最关键的参数，必须用本楼历史数据拟合，不能套用别的项目。我见过直接抄别人参数导致承诺时长严重虚高的案例，事件执行到一半末端就超温了。恢复时长的估算系数 0.1 是经验值，实际要按机组部分负荷性能曲线修正。
3.3 事件下发与执行反馈的接口约定
接口约定要写清楚三件事：事件结构、确认机制、反馈频率。事件结构至少包含事件编号、调节目标、起止时间、约束条件、优先级。确认机制要求接收方在收到后返回接受或拒绝，拒绝要带原因码。反馈频率建议执行期间每 15 秒到 1 分钟回报一次实际功率和状态。
{ "event_id": "DR-2024-0001", "target_reduction_kw": 200, "start_time": "2024-07-15T14:00:00", "end_time": "2024-07-15T15:00:00", "constraints": { "max_supply_temp": 9.0, "min_chiller_load_rate": 0.3 }, "priority": 2 }约束条件写进事件里，执行侧就能本地校验，不必每次都回问调度。优先级用于多事件冲突时排序。反馈报文里要带实际功率、执行状态、当前约束满足情况，调度侧据此判断事件是否有效。
3.4 用模拟数据验证模型闭环
模型建完别急着接真实冷站，先用模拟数据跑闭环。构造一个虚拟冷站，给定初始工况，注入一个调节事件，看模型能否正确校验、下发、反馈、恢复。模拟数据要覆盖边界：可调量刚好够、可调量不够、执行中末端超温、机组触发最小负载率。
# 闭环验证：注入事件并检查反馈 def simulate_event(system, event): ok, committed = check_dr_capacity(system, event["target_reduction_kw"], 60) if not ok: return {"event_id": event["event_id"], "result": "rejected", "reason": "capacity_or_constraint"} # 模拟执行：按承诺量降载 system.chiller.load_rate -= committed / system.chiller.rated_kw feedback = { "event_id": event["event_id"], "result": "accepted", "committed_kw": committed, "actual_kw": committed * 0.95, # 模拟执行偏差 } return feedback验证阶段重点看两处：拒绝原因是否准确，实际执行和承诺的偏差是否在可接受范围。偏差长期偏大，说明能力计算模型需要重新标定。这套模拟验证能挡掉大部分对接阶段的低级错误，比直接上真实设备试错成本低得多。
4. 落地时最容易踩的坑与排查
4.1 可调能力上报虚高，事件执行到一半就崩
现象：聚合商上报可下调 300 千瓦，调度下发 250 千瓦，执行十几分钟后末端温度超标，被迫中止。原因：能力计算只用了额定参数，没考虑当前工况和温升速率，可持续时长拍脑袋填了一小时。解决：可持续时长必须用本楼历史温升数据拟合，且留 20% 余量；上报时把可持续时长一并给出，调度按最短约束决策。
4.2 点位映射错位，把回水温度当供水温度用
现象：模型里供水温度显示正常，但约束校验总是误判，调节指令频繁被拒。原因：点表里供回水命名不规范，映射时凭字面猜，把回水映射成了供水。解决：映射前核对设备图纸和自控点表，供回水必须现场确认；映射表加单元测试，用已知工况数据验证每个点位方向正确。
4.3 反馈频率过高把通道打满
现象：执行期间通信时断时续，反馈报文丢失，调度侧显示状态未知。原因：反馈频率设成每秒一次，几百个点位同时上报，通道带宽不够。解决：反馈按变化上报加定时心跳，正常时一分钟一次，功率变化超过阈值才即时上报；报文做精简，只带关键字段。
4.4 恢复阶段直接满负荷回升，触发机组报警
现象：事件结束后冷站恢复，冷水机组报警停机。原因：恢复逻辑写成直接回到事件前设定，机组负载率瞬间拉满，触发保护。解决：恢复要按恢复时长斜坡回升，每分钟升一定比例；恢复逻辑写进模型，作为事件闭环的一部分，而不是交给楼宇自控自由发挥。
4.5 多事件并发时优先级失效
现象：两个事件同时下发，执行侧按后到的执行，先到的高优先级事件被覆盖。原因：模型里定义了优先级但执行侧没实现冲突仲裁。解决：执行侧维护事件队列，按优先级和起止时间仲裁；同优先级按先到先服务；仲裁结果要回报给调度，避免调度以为两个都执行了。
5. 让模型真正可用的两个进阶技巧
第一个技巧是把能力描述做成随时间滚动的预测，而不是静态快照。集中式空调的可调能力随室外温度、楼内负荷、机组状态一直在变。我一般会用一个轻量的滚动计算：每 5 分钟用最近一段历史数据重新拟合温升速率，更新可持续时长，把能力描述层做成动态输出。这样调度拿到的是“未来一小时大概能调多少”，而不是“刚才那一秒能调多少”。实现上不复杂，把 3.2 节的计算函数挂到定时任务里，输出带时间戳写进能力对象即可。要注意的是预测值要带置信区间或保守系数，别把预测当承诺。
第二个技巧是给模型加一层自检。模型跑久了，映射会漂、参数会偏，靠人巡检不现实。我的做法是内置几条自检规则：供水温度长期高于设定值说明映射或传感器有问题；可调能力连续多日为负说明约束参数配错；反馈实际功率与承诺偏差持续超过 30% 说明能力计算需要重新标定。自检结果写进日志并告警，比等事件执行失败再回头查高效得多。
# 模型自检规则示例 def self_check(system, history): alerts = [] if history.supply_temp_avg > system.chilled_water_loop.supply_temp_set + 1.0: alerts.append("supply_temp_high: 检查映射或传感器") if system.capability.max_reducible_kw < 0: alerts.append("negative_capacity: 检查约束参数") if abs(history.actual_vs_committed_ratio - 1.0) > 0.3: alerts.append("commit_deviation: 重新标定能力模型") return alerts这两条经验都是踩过坑之后加的。早些年我总觉得模型建完、接口通了就完事，结果运行三个月后能力上报越来越不准，查了两周才发现是温升速率的历史窗口一直没更新。后来养成习惯：任何依赖历史数据的参数，都要有明确的更新周期和自检规则，否则模型就是个会慢慢失准的黑匣子。希望帮到你。
本文还有配套的精品资源，点击获取
