简介这份资源是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这两条经验都是踩过坑之后加的。早些年我总觉得模型建完、接口通了就完事结果运行三个月后能力上报越来越不准查了两周才发现是温升速率的历史窗口一直没更新。后来养成习惯任何依赖历史数据的参数都要有明确的更新周期和自检规则否则模型就是个会慢慢失准的黑匣子。希望帮到你。本文还有配套的精品资源点击获取
