电力需求响应技术规范V06讲述.docx

电力需求响应技术规范V06讲述.docx

《电力需求响应技术规范V06讲述.docx》由会员分享，可在线阅读，更多相关《电力需求响应技术规范V06讲述.docx（41页珍藏版）》请在冰豆网上搜索。

电力需求响应技术规范V06讲述

电力需求响应技术规范草案v0.6

事实证明，正确地实施需求响应，可以有效地抑制高峰负荷，提高电力系统的可靠性和经济性。

编制本规范是为了帮助各利益相关方在参与需求响应时在认识上达成一致并进行自动互操作，从而推动相关技术和市场的发展。

只要遵守本规范，任何系统或设备都可以参与需求响应，这将增加可参与需求响应的资源数量，减少实施需求响应的成本。

1概述

本规范描述了一种开放和兼容的信息模型，支持供应商与用户之间进行信息交互，同时也支持各利益相关方参与需求响应的监管、实施、评估和结算等事宜。

本规范涵盖需求响应计划、动态价格或需求侧竞标的信息模型。

本规范主要面向具备复杂信息处理能力的智能能源管理控制系统（SmartEMCSs），包括智能建筑物、智能工厂、智能家庭、电动汽车和分布式发电及储能等，同时也面向具有简单信息处理能力的智能设备（SmartFacilities）。

价格信号或可靠性信号随时可能发生，但用户侧的智能能源管理控制系统或智能设备由于种种原因可能出现故障或失效。

当它们恢复正常后，本规范将支持恢复数据。

本规范支持同一个用户同时参与多个供应商的多个需求响应计划、动态价格或需求侧竞标。

2范围

本规范定义了需求响应的信息模型，并以用例、域模型和类图的形式展现。

通过这些信息模型，需求响应的利益相关方之间就可以进行互操作，从而在行为上相互协调。

有的国家针对电力批发市场也开展了需求响应的研究和实践，包括能量市场（EnergyMarket）、容量市场（CapacityMarket）、日前计划备用市场（Day-aheadSchedulingReserveMarket）、同步备用市场（SynchronizedReserveMarket）和调节市场（RegulationMarket）等。

本规范目前只针对电力零售市场，不针对电力批发市场和其他市场。

本规范并不规定实现的细节。

例如，尽管定义了实体及其信息模型，但对如何设计数据模型以及如何持久化不作规定。

至于通信协议和用户界面设计，也不在本规范的范围内。

用户可以根据自己的意愿，对信号进行响应，也可以忽视信号，或在响应过程中退出。

本规范并不指导用户是否要参与需求响应计划，也不指导用户如何削减或转移负荷。

本规范需要对基线负荷建模，但不涉及基线负荷的具体算法。

本规范将削减服务提供商视为供应商的一种，不单独建模。

实现本规范的过程可能会涉及到专利权问题，但本规范不负责指出已有的专利权或专利申请。

由于世界各国在国情、体制等方面差异太大，本规范并不是一个完整的需求响应标准，而只是目前能达成共识的部分。

3参考标准

下面列出了本规范所引用的文档。

对于注明日期的引用，日期之后的版本是否适用于本规范，需要进行评估。

对于没有注明日期的引用，其最新版本适用于本规范。

IEC61970-301能量管理系统应用程序接口（EMS-API）第301部分：

公共信息模型（CIM）基础；

，，，

4术语

需求响应（DemandResponse）

当电力供给成本升高或者电力系统可靠性面临威胁的时候，通过价格或激励手段，促使需求侧改变用电行为（削减或转移负荷），从而缓减供需矛盾。

需求响应的内涵还在不断发展，未来有可能扩展到整个能源领域，只要供需双方的协调，多种能源形式的配合，有利于能效的提高或环境的改善，都可以视为需求响应。

计划（Program）

无论是供应方还是需求方，都是有一定弹性的，但弹性又都是有限的，需求响应计划就是运用价格或激励手段来发挥需求方弹性的商业模式。

交易（Transaction）

当用户愿意参与一个需求响应计划时，就要与供应商达成合约，明确双方的权利和义务，并以此为依据，进行评估和结算。

交易的要素应包括用户可削减的负荷（电量）、负荷类型、对应的时段。

如果是竞价产生的，还要有价格。

事件（Event）

当供应商与用户达成交易后，将按照需求响应计划的日程类型提前通知用户。

事件机制比较复杂，要考虑多种可能的情况。

日程（Schedule）

当供应商与用户达成交易后，需要提前一段时间来通知用户，以便用户做好准备。

不同的日程类型，对供应商和用户的影响是不同的，因而补偿也不同。

对供应商来说，日程越短越有利，但用户往往需要有足够的时间来调整用电方式，这就需要找到平衡点。

针对零售市场，可以提前一天通知（称为日前），可以当天通知，也可以提前1小时通知。

针对批发市场，一般只提前几分钟，并要求其技术支持系统提供扫描分辨率不低于1分钟的负荷曲线。

费率结构（RateStructure）

费率（电价）是市场的关键要素，费率的结构和形成机制决定了各市场主体的心态和行为。

分时电价（TimeofUsePricing，简称TOU）

分时电价是一种反映不同时段电能供给成本的价格机制，通过划分时段以及设置不同时段的电价，有利于引导用户合理安排消费需求，改善负荷曲线。

尖峰电价（CriticalPeakPricing，简称CPP）

可以认为是分时电价的一种，但它的电价高于普通的高峰电价，是在分时电价的基础上叠加尖峰费率而形成的，一般是在电力需求趋于临界、系统稳定性受到威胁时才实施的。

参与CPP的用户平时可享受折扣电价，但收到CPP信号后必须立即有效减少电力需求，否则将受到惩罚。

为了保护用户利益，每个用户一年中参与响应的天数是有限制的。

实时电价（RealTimePricing，简称RTP）

与分时电价和尖峰电价不同的是，实时电价不是提前设定的，而是直接反映每时每刻上游成本的变化。

当然，也可以根据历史数据和一定的规则提前一天预测并发布实时电价，以便用户及早采取措施。

直接负荷控制（DirectLoadControl，简称DLC）

在用电高峰时段或者可靠性受到威胁时，公用事业或ISO直接远程控制用户的用电设备，中断电力供应，而用户将获得相应的补偿。

这种项目类型一般用于住宅或商业建筑，且主要针对停电后不会对用户造成严重影响的用电设备，如热水器、空调等。

为了保护用户利益，一年或一季度内被中断的次数或小时数是有限制的。

可中断负荷（InterruptibleLoad，简称IL）

在电力短缺或可靠性受到威胁时要求用户减少需求，而用户则享受优惠电价或直接经济补偿。

如果用户不减少需求，将受到处罚。

实施IL项目时，一般要提前通知，提前的时间不同，补偿标准也不同。

紧急需求响应（EmergencyDemandResponse，简称EDR）

当可靠性受到威胁时可以实施EDR项目，用户则自愿选择参与或放弃。

容量市场项目（CapacityMarketProgram，简称CMP）

当出现容量短缺时，用户有义务减少预定电力负荷，否则将受到严重处罚。

辅助服务项目（AncillaryServiceProgram，简称ASP）

用户可自愿参与调节电压、频率、备用等，并获得补偿。

需求侧竞标（DemandSideBidding，简称DSB）

用户可以将自身可控的负荷或电量作为需求侧资源，与供应侧资源和其他需求侧资源一起，在电力市场竞争。

这种竞争机制可以有效地抑制高峰电价，防止发电商操纵市场。

用户可以自主报价，也可以在价格确定的情况下提交可削减的电力需求，通过竞争机制，形成双方认可的用户资源曲线。

该项目通常提前一天通知用户。

如果用户选择参与，但没有按照协议规定的数量减少电力需求，将受到处罚。

资源可用性曲线（AvailabilityCurve）

用于描述供应商期望的可用资源的曲线，包括期望可削减的负荷（电量）、负荷类型、对应的时段以及价格。

如果是竞标项目，该曲线将由供应商与用户交互产生。

频率响应（FrequencyResponse，简称FR）

电网的频率可以反映电网的供求情况。

当需求侧检测出频率下降时，就可以参与该项目。

供应商（Supplier）

需求响应计划、动态价格或竞标项目的发起者，一般是公用事业、独立运营商或者第三方的削减服务提供商，负责向参与的用户提供激励或补偿。

用户（User）

需求响应计划、动态价格或需求侧竞标的参与者，包括居民用户、商业用户和工业用户，其义务是削减或转移负荷，并因此获得补偿。

客户端（Client）

直接与供应商侧进行通信并参与需求响应的用户侧设备。

一个用户可以有多个客户端。

负荷控制开关（LoadControlSwitch）

当实施直接负荷控制（DLC）计划时，需要直接操作用户的负荷控制开关。

一个客户端可以有多个负荷控制开关，分别开断不同线路或不同相位。

监管者（Regulator）

需求响应计划、动态价格或需求侧竞标规则的制定者、费率结构的审批者和实施过程的监督者。

削减服务提供商（CurtailmentServiceProvider，简称CSP）

作为第三方供应商，削减服务提供商在获得公用事业、独立运营商授权的情况下也可以向用户提供需求响应计划、动态价格或需求侧竞标等服务，并居中获得收益。

负荷服务实体（LoadServingEntity，简称LSE）

负荷服务实体将一些零散的资源集中在一起，作为一个整体共同参与需求响应计划、动态价格或需求侧竞标，并代理相关的商务事宜。

基线负荷（BaseLine）

用户参与需求响应后，需要对其行为进行准确的评估，这就需要建立一个基准线，以此来判断用户的实际削减量。

基线负荷就是在需求响应事件期间，假设用户不参与需求响应的情况下，每一定间隔时间（间隔时间越短越精确）预计消耗的电量。

计算基线负荷比较复杂，需要在长期收集用户负荷数据的前提下，根据负荷的特点，采用不同的算法和调整因子。

实际削减量（ActualCurtailment）

理论上，用户的基线负荷减去用户的实际负荷就是实际削减量，但实际计算时要复杂得多。

计算出实际削减量后，与交易约定的数值对比，可以评价出用户的响应行为。

用户资源评价（EvaluationofUserResource）

在实施需求响应计划前，需要对用户的负荷曲线、负荷特性、削减潜力、所处电网位置、过去参与需求响应的行为特点进行分析，进而分析其对电价、备用、容量市场和市场流动性的影响。

对用户资源进行评价的目的是针对需求响应计划找出最佳参与者。

用户行为评价（EvaluationofUserBehavior）

在实施需求响应项目后，要对用户的参与行为进行评价，包括：

（1）响应及时性：

用户收到事件后，应按照交易约定的期限来开始响应，既不提前也不滞后，否则将影响需求响应的效果。

（2）响应持续性：

应按照交易约定的响应持续时问来响应，除非收到中止信号。

（3）恢复过程：

交易结束后，用户可以恢复常态，但要以一个缓慢的过程来恢复，以避免高峰反弹。

如果高峰仍然存在，而用户自动延长交易时间，将得到奖励。

（4）削减潜力：

用户每小时平均负荷削减量与非同时峰荷需求的比值可以判断出用户的削减潜力。

如果比值接近1，表明用户的削减潜力很大；反过来，说明用户的削减潜力不大，需要对其更多的指导和技术支持。

（5）基础设施的完备性：

如果用户的IT和量测设施能保持良好的状态，能够与供应商及时互动，能够以较高的扫描分辨率提供负荷数据，需求响应的效率将大大提高。

（6）历史信用记录：

记录用户过去的违约行为和受到的奖惩。

历史绩效记录（Performance）

用户有可能多次参与或者参与了多个需求响应项目，相应地，需要记录每次的绩效，结算时再合并。

基于历史绩效记录的奖励与提升政策（PerformanceBasedPromotionPolicy）

为了培育忠实的用户群体，激励用户更积极地参与需求响应，供应商可以根据用户的历史绩效记录，对用户使用积分奖励政策。

结算（Settlement）

在确定了基线负荷和实际削减量并对用户行为进行评价后，根据交易约定的条款，计算出本次交易的用户绩效，并与历史绩效记录合并后，确定用户应得的奖惩。

5标准架构（建议杨胜春和曹阳专家）

【描述一个完整的需求响应标准体系是怎么构成的，本规范与其他相关标准的关系，WG1/WG2的关系。

】

WG1的目标是，通过面向对象的建模技术，定义和描述智能电网与需求侧系统/设备互操作的接口，即信息交换模型，包括交互模式、消息模型、数据格式、通信协议、抽象服务接口、信息安全要求等。

WG2的目标是，基于信息交换模型，针对电力需求响应业务，定义和描述交互过程中的信息模型（需要与CIM兼容）以及功能性需求、性能需求和安全和防护要求等。

6概念模型（建议祁兵和张晶专家）

【从商业价值的角度描述需求响应业务的构成和利益相关者，并分析电力流、信息流、资金流以及它们如何融合。

】

7域模型（建议李杨、董军、王婷专家补充）

本规范将针对需求响应计划、动态价格和需求侧竞标，用域模型来描述主要实体对象以及它们之间的关系，如图1所示：

图1需求响应的域模型

8类图（建议李杨、董军、王婷专家补充）

8.1供应商（Supplier）

需求响应计划、动态价格或竞标项目的发起者，一般是公用事业、独立运营商或者第三方的削减服务提供商，负责向参与的用户提供激励或补偿。

Supplier类的固有属性：

属性

数据类型

描述

supplierName

（String）

供应商的名称。

supplierType

（SupplierType）

供应商的类型，是以下枚举值的一个：

（Utility、ISO或CSP）。

Supplier类固有的关联或聚合：

关系

重数

源

重数

目标

描述

关联

源->目标

（0..*）

Program

（1）

Supplier

一个计划必须且只对应一个供应商。

关联

源->目标

（1）

AvailabilityCurve

（1）

Supplier

一个资源可用性曲线必须且只对应一个供应商。

8.2用户（User）

需求响应计划、动态价格或需求侧竞标的参与者，包括居民用户、商业用户和工业用户，其义务是削减或转移负荷，并因此获得补偿。

User类的固有属性：

属性

数据类型

描述

userName

（String）

用户的名称。

userGroup

（UserGroup）

用户的分组，是以下枚举值的一个：

（待定）。

contactInfo

（String）

联系方式。

notificationInfo

（String）

通知方式。

settleInfo

（String）

结算方式。

User类固有的关联或聚合：

关系

重数

源

重数

目标

描述

聚合

源->目标

（1..*）

Client

（1）

User

一个用户至少有一个客户端，但一个客户端必须且只对应一个用户。

8.3客户端（Client）

直接与供应商侧进行通信并参与需求响应的用户侧设备。

一个用户可以有多个客户端。

Client类的固有属性：

属性

数据类型

描述

clientName

（String）

客户端的名称。

clientType

（ClientType）

客户端的类型，是以下枚举值的一个：

（Smart、Simple）。

geographicLocation

（String）

地理位置。

gridLocation

（String）

电网位置。

Client类固有的关联或聚合：

关系

重数

源

重数

目标

描述

聚合

源->目标

（1..*）

Client

（1）

User

一个用户至少有一个客户端，但一个客户端必须且只对应一个用户。

关联

源->目标

（0..*）

Transaction

（1）

Client

一个交易必须指定一个客户端。

8.4负荷控制开关（LoadControlSwitch）

定义：

当实施直接负荷控制（DLC）计划时，需要直接操作用户的负荷控制开关。

一个客户端可以有多个负荷控制开关，分别开断不同线路或不同相位。

LoadControlSwitch类的固有属性：

属性

数据类型

描述

feeder

（ID）

开关所属馈线的唯一标识符。

phase

（PhaseCode）

开关的相位，是以下枚举值的一个：

（A、B、C、N）。

LoadControlSwitch类固有的关联或聚合：

关系

重数

源

重数

目标

描述

聚合

源->目标

（1..*）

LoadControlSwitch

（1）

Client

一个客户端至少有一个负荷控制开关，但一个负荷控制开关必须且只对应一个客户端。

8.5监管者（Regulator）

需求响应计划、动态价格或需求侧竞标规则的制定者、费率结构的审批者和实施过程的监督者。

Regulator类的固有属性：

属性

数据类型

描述

regulatorName

（String）

监管者的名称。

Regulator类固有的关联或聚合：

关系

重数

源

重数

目标

描述

关联

源->目标

（0..*）

RateStructure

（0..1）

Regulator

一个费率结构可以没有监管者，也可以有一个监管者，这是为了兼容世界各国的体制。

8.6费率结构（RateStructure）

费率（电价）是市场的关键要素，费率的结构和形成机制决定了各市场主体的心态和行为。

RateStructure类的固有属性：

属性

数据类型

描述

periodStart

（DateTime）

时段开始时间。

periodEnd

（DateTime）

时段结束时间。

periodType

（PeriodType）

时段的类型，是以下枚举值的一个：

（peak、offpeak、normal、critical）。

periodPrice

（Float）

对应于时段的价格。

其中，如果是尖峰时段，尖峰费率叠加在原峰时段电价之上。

RateStructure类固有的关联或聚合：

关系

重数

源

重数

目标

描述

关联

源->目标

（0..*）

Program

（1）

RateStructure

一个计划必须有一个经批准的费率结构。

关联

源->目标

（0..*）

RateStructure

（0..1）

Regulator

一个费率结构可以没有监管者，也可以有一个监管者，这是为了兼容世界各国的体制。

8.7日程（Schedule）

当供应商与用户达成交易后，需要提前一段时间来通知用户，以便用户做好准备。

不同的日程类型，对供应商和用户的影响是不同的，因而补偿也不同。

对供应商来说，日程越短越有利，但用户往往需要有足够的时间来调整用电方式，这就需要找到平衡点。

Schedule类的固有属性：

属性

数据类型

描述

scheduleType

（ScheduleType）

日程的类型，是以下枚举值的一个：

（待定）

Schedule类固有的关联或聚合：

关系

重数

源

重数

目标

描述

关联

源->目标

（0..*）

Program

（1）

ScheduleType

一个计划必须有一个日程。

8.8计划（Program）

无论是供应方还是需求方，都是有一定弹性的，但弹性又都是有限的，需求响应就是运用价格或激励手段来发挥需求方弹性的商业计划。

Program类的固有属性：

属性

数据类型

描述

programType

（ProgramType）

计划的类型，是以下枚举值的一个：

（待定）。

programPriority

（ProgramPriority）

计划的优先级，是以下枚举值的一个：

（高、中、低）。

responseTimes

（Integer）

有效期内最多响应次数，这是为了保护用户利益。

responseDuration

（Integer）

每次响应的最多持续时间，以分钟为单位。

recoveryType

（RecoveryType）

恢复的类型，是以下枚举值的一个：

（待定）。

minLoad

（Float）

可参与计划的最小可削减负荷，以kW为单位。

minEnergy

（Float）

可参与计划的最小可削减电量，以kWh为单位。

penaltyClause

（String）

违约的惩罚措施。

如果为空，表示不惩罚。

startTime

（DateTime）

计划的有效期起始时间。

endTime

（DateTime）

计划的有效期结束时间。

Program类固有的关联或聚合：

关系

重数

源

重数

目标

描述

关联

源->目标

（0..*）

Program

（1）

Supplier

一个计划必须且只对应一个供应商。

关联

源->目标

（1）

Program

（0..*）

Schedule

一个计划必须有一个日程。

关联

源->目标

（1）

Program

（0..*）

RateStructure

一个计划必须有一个经批准的费率结构。

关联

源->目标

（0..*）

Transaction

（1）

Program

一个交易必须且只对应一个计划。

关联

源->目标

（0..*）

Event

（1）

Program

一个事件必须且只对应一个计划。

8.9交易（Transaction）

当用户愿意参与一个需求响应计划时，就要与供应商达成合约，明确双方的权利和义务，并以此为依据，进行评估和结算。

不是所有的需求响应计划都需要与用户达成交易，例如分时电价或实时电价。

Transaction类的固有属性：

属性

数据类型

描述

curtailLoad

（Float）

承诺可削减负荷，以kW为单位。

curtailEnergy

（Float）

承诺可削减电量，以kWh为单位。

Transaction类固有的关联或聚合：

关系

重数

源

重数

目标

描述

关联

源->目标

（0..*）

Transaction

（1）

Program

一个交易必须且只对应一个计划。

关联

源->目标

（0..*）

Transaction

（1）

Client

一个交易必须且只对应一个客户端。

8.10事件（Event）

当供应商与用户达成交易后，将按照需求响应计划的日程类型提前通知用户。

事件机制比较复杂，要考虑多种可能的情况。

Event类的固有属性：

属性

数据类型

描述

eventType

（EventType）

事件的类型，是以下枚举值的一个：

（待定）。

eventValue

（Float）

与事件类型对应的值。

userFilte