简介T/CEC 239.1—2019《电力需求响应信息模型 第1部分集中式空调系统》是中国电力企业联合会发布的行业标准面向自动需求响应终端与接口的设计开发人员、智能电网系统集成者及空调设备厂商。标准围绕集中式空调参与电网需求响应的建模需求规定了建模原则、数据类型、通用包与专用包并附需求响应能力计算方法为终端与接口开发提供统一的信息模型依据。资源包共1个PDF文件约396KB内容涵盖范围、规范性引用文件、术语定义、建模原则、数据类型、通用包、专用包及资料性附录目录结构完整便于按章节查阅。已有306人学习下载适合从事需求响应系统开发、标准落地与设备集成的技术人员参考也可为分散式空调、电热水器等同类负荷的信息模型设计提供借鉴。1. 一台空调怎么跟电网“对话”从电费单里的困惑说起夏天最热的那几天写字楼里的空调几乎一刻不停。你有没有想过一个问题电网怎么知道这栋楼里那台巨大的中央空调此刻到底能关小一点、还是能撑多久更关键的是就算知道了它凭什么敢下指令让空调降功率这背后其实缺的不是设备而是一套“共同语言”。集中式空调系统需求响应信息模型说白了就是给空调和电网之间定的一套对话规则空调有什么部件、额定功率多大、当前运行在制冷还是制热、室内温度多少、能削减多少功率、能撑多长时间——这些信息用统一的格式说清楚电网侧的调度系统才敢发指令空调侧的终端才知道该怎么执行。没有这套模型双方就像两个说不同方言的人各自都懂业务却没法配合。搞懂它你就能看懂“电网喊空调让一让”这件事到底是怎么落地的也能明白为什么不同品牌的空调能接入同一套需求响应系统。2. 为什么需要一套“空调方言词典”信息模型到底解决什么问题2.1 没有统一模型时需求响应会卡在哪设想一个场景某园区里有三栋楼分别装了三个品牌的集中式空调系统。电网侧想在用电高峰时统一削减 500 千瓦负荷于是给三套系统各发一条指令。结果第一套系统回传的是“压缩机频率 45Hz”第二套回传的是“冷冻水出水温度 7.2℃”第三套干脆只回了一个“运行中”。调度人员看着这三条完全不同的信息根本没法判断谁削减了多少、还能不能再削。这就是没有信息模型的典型困境每家设备厂商都有自己的参数体系和通信格式电网侧要对接 N 个品牌就得写 N 套解析逻辑每接一个新品牌就像学一门新方言。更麻烦的是需求响应不是简单的“开/关”它需要知道设备的实时功率、可调节范围、持续时间约束这些信息如果格式不统一自动化的调度根本无从谈起。信息模型的作用就是把这门“方言”统一成“普通话”。它不规定设备内部怎么控制只规定设备对外“自我介绍”和“汇报状态”时用什么字段、什么单位、什么取值范围。打个比方它像一张标准化的体检表不管你是哪家医院量血压用毫米汞柱、量体温用摄氏度、身高用米填出来的表谁都能看懂。2.2 这套模型里到底装了什么从数据类型到通用包从结构上看这套模型分了几层。最底层是数据类型也就是“每个字段用什么格式表达”。比如温度用浮点数加摄氏度单位功率用浮点数加瓦特单位时间用 ISO 8601 格式的字符串。这些看起来琐碎但恰恰是互操作的基础——如果一方把温度写成“25”而没带单位另一方可能以为是华氏度整个计算就翻车了。往上一层是通用包装的是各类需求响应设备都需要的公共信息。设备出厂信息类记录设备名称、型号、生产厂家、出厂编号设备所属用户信息类记录用户类型、行业、用电客户编号、关口电表表号设备自动化能力信息类则回答几个关键问题这台设备能不能对外通信、支持哪种需求响应协议、底层走 TCP/IP 还是 BACnet、支持刚性开关控制还是柔性功率调节。这些信息不针对空调电热水器、电动汽车充电桩也用得上所以放在通用包里复用。再往上是专用包这才是集中式空调系统的“专业档案”。它定义了空调的工作模式制冷/制热、运行状态停机/运行/待机/故障、系统类型水冷/风冷/多联机、内部部件类型主机机组、冷冻水泵、冷却水泵等以及额定参数、实时运行信息、温湿度参数和需求响应能力。专用包和通用包的关系有点像简历里的“通用信息”和“项目经历”——前者谁都要填后者体现专业能力。2.3 建模原则背后的取舍为什么强调实用和扩展标准里列了四条建模原则实用性、便捷性、适用性、扩展性。这四条不是套话每一条都对应着真实的工程约束。实用性要求模型能直接支撑自动需求响应终端和接口的开发意思是字段不能太抽象得让写代码的人拿到就能用。便捷性要求建模所需参数便于获得比如室内面积、平均层高这些建筑基础数据物业手里一般都有不需要额外装传感器去测。适用性要求考虑主流品牌空调的技术参数不能只按某一家的产品来定字段否则其他品牌接进来就得做大量映射。扩展性则留了后路所有枚举类型都支持x-{User-defined}的自定义扩展因为需求响应业务还在演进今天没有的项目类型、通信方式明天可能就冒出来了。这四条原则合在一起其实是在回答一个问题这套模型是给工程现场用的不是给论文用的。它得能在参数不全、品牌混杂、业务变化的真实环境里跑起来。3. 通用包与专用包怎么分工一份设备“简历”的结构拆解3.1 通用包每台设备都要填的“基本信息表”通用包里的四个信息类构成了设备参与需求响应的“身份档案”。设备出厂信息类EQProductInfo记录设备叫什么、谁造的、什么型号、出厂编号和日期。这些字段看起来是资产管理用的但在需求响应场景里有实际意义调度系统需要知道某台设备的具体型号才能查它的额定参数和可调节能力出厂日期则帮助判断设备是否在寿命周期内避免对老旧设备下发超出能力的指令。设备所属用户信息类EQUserInfo把设备和用电主体绑定起来。用户类型分工业、商业、居民用户编号与电网公司分配的用电客户编号一致关口电表表号则指向计量点。这几个字段是需求响应结算的基础——电网要知道削减的负荷算在谁头上补贴或补偿发给谁。经纬度是可选字段用于地理位置相关的调度策略比如同一区域内的设备优先响应。设备自动化能力信息类EQAutoAbilityInfo是通用包里最“技术”的部分。它用几个布尔值和枚举值回答设备能不能对外通信ComAbility、走什么通信方式ComMode比如本地 RS485、本地无线、远程 4G、直接跟主站交互用什么需求响应协议DRProtocol比如 DL/T 1867 或 OpenADR、底层通信协议是什么UnderlyingProtocol比如 TCP/IP、BACnet、支持刚性控制还是柔性调节On-OffAbility 和 Flexability、有没有第三方平台接入。这几个字段决定了调度系统能用什么方式跟这台设备打交道。用户需求响应合约信息类UserDRContract记录合约层面的约束设备每年最多参与多少次需求响应、已经参与了多少次。这个类还关联到需求响应项目类型说明这台设备支持分时电价、尖峰电价、可中断响应还是直接负荷控制。合约信息的存在意味着需求响应不是随叫随到的它受商业协议约束。3.2 专用包空调系统的“专业能力档案”专用包才是集中式空调系统的核心。它先定义了几个枚举类型工作模式制冷/制热、运行状态停机/运行/待机/故障、系统类型水冷/风冷/多联机、部件类型主机机组、冷热水泵、冷却水泵。这些枚举看起来简单但它们是后续所有参数描述的“词汇表”——没有它们额定参数和实时信息就没法结构化表达。额定参数类RatedParameter描述系统的静态能力空调类型、室内制冷采暖面积、室内平均高度、制热能效比 COP、制冷能效比 EER、建筑物能量损失系数。这几个参数直接决定了需求响应能力的上限。举个例子同样削减 1℃ 室温面积大、层高高的建筑能“存”更多冷量可削减的功率就更大EER 越高同样的电功率能搬走更多热量调节的杠杆效应越明显。组成部件额定参数类ACComponentRatedParameter把视角下沉到部件级主机、循环水泵、冷却塔水泵、冷却塔风机、末端风机各有几台每台的额定电流、电压、功率、频率是多少主机的负荷率限定值是多少。这个类的价值在于需求响应往往不是整机开关而是选择性调节某几个部件——比如优先降主机负荷、保持水泵运行这时候就需要知道每个部件的独立参数。运行模式类OperationMode描述设备当前“怎么跑”是否支持变频、控制方式是远程还是本地、运行状态和故障状态、支持几种工作模式。实时信息类RealTimeInfo则是运行过程中的动态数据实时电压、电流、频率、有功功率、无功功率、主机负载率。温湿度参数类TRHParameter把温度测点铺开室内设定温度、室内平均温度、室内相对湿度、室外温湿度、冷凝器进出口温度、蒸发器进出口温度、采暖水送回水温度。这些测点是判断“还能调多少”的依据。需求响应能力类DRAbility是整个模型的落脚点只有三个字段可增加的有功功率、可削减的有功功率、持续时间。但这三个字段是前面所有信息的“计算结果”——额定参数决定理论上限实时信息决定当前余量温湿度参数决定用户舒适度边界最终汇成这三个数。调度系统拿到这三个数才敢下发指令。3.3 从字段到指令一个削减功率的计算例子标准附录里给了一个资料性计算方法用制冷工况的可削减功率公式来说明这些字段怎么串起来。公式的核心逻辑是建筑物里存的冷量等于空气密度乘以比热容乘以建筑面积乘以层高乘以允许的温度变化量这部分冷量除以 EER就是空调少耗的电功率再除以持续时间就是可削减的有功功率。用一段简化代码表达这个关系# 制冷工况可削减功率估算简化示意单位统一为国际单位 rho 1.177 # 空气密度 kg/m3300K 时干空气近似值 c 1005 # 空气定压比热容 J/(kg*K)即 1.005 kJ/(kg*K) S 2000 # 建筑面积 m2 H 3.5 # 平均层高 m T_limit 27.0 # 用户可承受的最高室温 ℃ T_set 25.0 # 用户设定的制冷温度 ℃ EER 3.2 # 制冷能效比 t_dr 1800 # 需求响应持续时间 s # 可削减冷量J 密度 × 比热容 × 体积 × 允许温升 cool_energy rho * c * (S * H) * (T_limit - T_set) # 可削减电功率W 冷量 / EER / 持续时间 p_decreased cool_energy / EER / t_dr print(f可削减有功功率约 {p_decreased/1000:.1f} kW)这段代码里每个变量都能在模型字段里找到对应S和H来自额定参数类的室内面积和平均高度T_set和T_limit来自温湿度参数类的设定温度和用户允许边界EER来自额定参数类t_dr来自需求响应能力类的持续时间。参数改动的含义也很直接允许温升越大、持续时间越短可削减功率越大EER 越高同样的冷量对应更少的电功率。实际工程中还要考虑建筑物能量损失系数和主机负荷率限定值公式会更复杂但字段之间的对应关系不变。提示这个公式是资料性附录里的估算方法假设响应前系统已处于平稳运行状态。实际调度中还要叠加通信延迟、设备响应死区、用户舒适度投诉风险等因素不能直接把计算结果当作承诺值。4. 容易混淆的几个概念别把信息模型当成控制协议4.1 信息模型 vs 通信协议一个管“说什么”一个管“怎么送”最容易混的一点是把信息模型和通信协议当成一回事。信息模型定义的是“有哪些字段、字段什么含义、取值范围是什么”它不关心这些字段用二进制还是 JSON 编码、走 TCP 还是串口、要不要加密。通信协议才管这些。打个比方信息模型是信封上该写哪些内容收件人、地址、邮编通信协议是邮局怎么把信送到平邮、快递、挂号。标准里专门列了需求响应协议类型和底层通信协议类型两个枚举恰恰说明它们是分开的同一套信息模型可以跑在 DL/T 1867 上也可以跑在 OpenADR 上底层可以是以太网也可以是 BACnet。初学者看到“模型”两个字就以为它包含传输细节结果在对接时把字段定义和报文格式搅在一起排查问题时分不清是数据不对还是通道不通。4.2 通用包 vs 专用包别把公共字段塞进空调档案第二个常见混淆是分不清哪些信息该放通用包、哪些该放专用包。有人觉得既然做的是空调系统就把所有字段都塞进专用包结果每接一种新设备类型就要重复定义一遍用户信息、出厂信息、通信能力。反过来也有人把空调特有的工作模式、部件参数往通用包里塞导致通用包越来越臃肿其他设备类型被迫携带一堆用不上的字段。区分的标准很简单问一句“这个字段是不是所有需求响应设备都需要”。用户编号、电表表号、通信方式、需求响应协议这些电热水器、电动汽车、储能设备都要用放通用包制冷制热模式、冷凝器进出口温度、主机负载率这些只有空调系统才有放专用包。通用包追求复用专用包追求精准两者的边界是设备类型的共性范围。4.3 刚性控制 vs 柔性调节两种完全不同的响应方式设备自动化能力信息类里有两个布尔字段On-OffAbility 和 Flexability。前者表示设备支持刚性控制也就是开关式调节——要么运行要么停机没有中间档后者表示设备支持柔性调节可以连续调整功率或温度设定值。这两个字段经常被混为一谈觉得“能控制就行”。实际差别很大。刚性控制实现简单但响应粒度粗频繁开关对设备寿命不友好用户体验也差——空调突然停机室温很快上升。柔性调节可以平滑地降功率、微调温度设定值用户体验好但对设备变频能力、控制接口要求高。调度系统看到这两个字段才知道该下发开关指令还是功率调节指令。如果一台设备只支持刚性控制却按柔性调节的方式去调度指令下去要么不执行要么执行成频繁启停这就是典型的踩坑场景。4.4 额定参数 vs 实时信息静态能力和动态余量不能互换额定参数类和实时信息类都涉及功率、电流、电压这些电气量初学者容易把两者当成重复定义。其实它们回答的是不同问题额定参数说“这台设备设计上最大能怎样”实时信息说“它此刻实际在怎样”。举个例子一台主机额定功率 200 kW这是额定参数当前实时有功功率 150 kW这是实时信息。需求响应要算可削减功率得用实时功率减去允许的最低运行功率而不是拿额定功率直接减。如果混淆两者可能算出超过设备实际运行水平的削减量指令下发后设备根本执行不了。额定参数是能力边界实时信息是当前状态前者用于规划后者用于执行不能互相替代。4.5 需求响应能力 vs 合约次数物理潜力和商业约束是两回事需求响应能力类给出的是物理层面的可增加/可削减功率和持续时间用户需求响应合约信息类给出的是每年最多参与次数和已参与次数。这两个信息经常被放在一起看但含义完全不同前者回答“这台设备此刻能调多少”后者回答“这份合约允许它今年再调几次”。物理能力再大合约次数用完了也不能再调反过来合约还有次数但设备当前负荷很低、可削减功率接近零调了也没意义。调度系统需要同时看这两个信息才能做决策。把物理能力当成合约额度或者把合约次数当成能力上限都会导致调度策略失真。5. 什么时候该用这套模型什么时候别硬套5.1 适用场景自动需求响应终端与接口开发这套模型最直接的用武之地是集中式空调系统自动需求响应终端和接口的设计开发。如果你在做一台需求响应网关需要把园区里几台不同品牌的中央空调接入电网调度平台这套模型就是字段字典设备档案按通用包填空调能力按专用包填实时数据按实时信息类上报需求响应能力按附录公式估算后填入 DRAbility。它帮你省去和调度平台反复对齐字段的时间也降低了换一个平台就要重做一遍映射的风险。另一个适用场景是需求响应系统的互操作性评估。当你拿到一台设备或一个平台想知道它能不能跟现有系统对接可以逐项对照模型字段通用包的信息全不全、专用包的枚举值是否覆盖、需求响应能力有没有按统一单位表达。缺哪块对接时就在哪块做适配。5.2 不适用场景别把它当控制算法或实时闭环规范这套模型的边界也很清楚它不规定控制算法不规定调节策略也不规定实时闭环的响应时间指标。它只定义信息怎么表达不定义信息怎么用。如果你要设计的是“室温升高 0.5℃ 时主机负荷降多少”的控制逻辑或者“指令下发后多少毫秒内必须响应”的实时性要求这套模型给不了答案得去看控制策略文档和通信协议的性能规范。还有一个容易硬套的地方分散式空调系统。这套标准是第 1 部分专门针对集中式空调分散式空调、电热水器、电热锅炉、电冰箱、分布式电源、电动汽车、分散式储能各有各的专用包。把集中式空调的专用包套到分体式空调上部件类型、水系统温度测点这些字段根本对不上硬套只会增加无效字段。选对部分比硬改字段更省事。5.3 一个判断清单拿到项目先问这几个问题实际项目里判断要不要按这套模型来做可以先问几个问题。设备是不是集中式空调系统有主机、水泵、冷却塔这些集中部件需求响应是自动化的需要终端和平台之间交换结构化信息而不是人工打电话通知对接方是否要求或建议遵循这套标准如果三个答案都是肯定的按模型字段来设计基本不会跑偏。如果设备是分散式、响应靠人工、对接方没有标准要求那这套模型的投入产出比就要重新算。判断维度适合按本模型做不适合硬套设备类型水冷/风冷/多联机等集中式系统分体式、家用分散空调响应方式自动需求响应终端与平台交换信息人工通知、手动拉闸对接要求要求字段统一、支持互操作单点私有对接、无复用需求关注重点信息表达、能力上报、合约约束控制算法、实时闭环性能我自己的习惯是每次拿到一个新项目先把通用包和专用包的字段清单过一遍标出哪些字段现场拿不到、哪些字段对接方用不上再决定是完整实现还是做子集。有一次没做这一步直接按全量字段开发结果现场物业拿不出建筑物能量损失系数接口卡了半个月最后只能改成可选字段加默认估算。从那以后我每次对接前都强制走一遍字段可得性核对宁可前期多问几句也不让字段缺口在联调阶段变成拦路虎。希望帮到你。本文还有配套的精品资源点击获取