1-openADR通信协议-翻译

OPENADR通信规范本报告提交加利福尼亚能源委员会公益能源研究项目本报告由 劳伦斯伯克利国家实验室需求响应研究中心、AKUACOM公司完成声明本报告是加利福尼亚能源委员会资助项目的研究成果，但能源委员会包括其下属职员不对该研究报告承担法律责任和义务。致谢 本报告由需求响应研究中心牵头，加利福尼亚能源委员会公益能源研究项目资助。编者在此感谢技术咨询组提供的协助。前言加利福尼亚能源委员会公益能源研究项目（PIER）支持公益能源研究与开发，通过向电力市场提供环境安全、可持续、可靠的能源服务和产品，提高生活质量。PIER赞助领域主要如下：建筑物终端节能新能源小额补贴与能源相关的环境影响研究能源系统集成环境优先的高级发电工业/农业/供水 终端节能可再生能源技术输电开放式需求响应通信规范是开放式自动需求响应项目的最终成果。摘要开放式自动需求响应通信规范，也称为OpenADR或者Open Auto-DR，其开发开始于2002年的加利福尼亚大规模电力危机。该规范描述了一种开放式基于标准的通信数据模型，该模型被设计用于促进公用事业机构、独立系统操作员（Independent System Operator，ISO）、电力用户间使用需求响应价格和可靠性信号的通用信息交互。OpenADR将给加利福尼亚带来两方面的好处：提高参与需求响应的机构数量，降低成本以促进经常性和持续性需求响应的参与。关键词：需求响应、建筑物、电力使用、自动化、通信、开放标准、数据模型、规范内容提要开放式自动需求响应通信规范，也称为OpenADR或者Open Auto-DR，其开发开始于2002年的加利福尼亚大规模电力危机。加利福尼亚州、美国其他州以及国外的很多公用事业机构、政府部门、独立系统操作员和其他部门也正致力于引入需求响应来管理不断增长的电力需求和电力系统的尖峰负荷。DR被定义为“一种通过响应价格、货币激励或者系统指令以降低电力需求的行为，从而保证可靠地电力供应服务，避免高电价”。OpenADR是智能电网信息和通信技术的一个元素，以提高电力供应和需求的匹配能力。开放式自动需求响应通信规范定义，包含以下特征：l 连续、安全、可靠-l 翻译l 自动化l 自愿退出-当参与者不希望削减终端服务时，可以向参与者提供自愿退出或对DR事件信息忽视的功能。l 完整的数据模型为通信价格、可靠性和其他DR响应信号提供详细的数据模型和架构描述l 灵活的体系架构l 开放的标准OpenADR已经在加利福尼亚的很多DR项目中获得了测试。本通信规范的研究范围主要关注于DR事件和价格信号。本规范也包含了价格数据模型，并不包含与具体的DR电力削减或转移策略相关的信息。OpenADR通信规范用于推动消费侧的自动需求响应行为，不论这些行为是负荷终端或转移。这种通信数据模型可以用于每天的连续操作。潜在的收益 提高参与企业数量、降低成本。l 开放的规范l 灵活性-提供开放、灵活、平台独立、可互操作的通信接口和协议l 创新及互用性鼓励开放创新和互用性，允许在现有策略基础上实现工厂和企业内部控制与通信，以减少技术操作和维护成本、不良资产和过时技术。l 易集成l 远程访问通过web端口提供自愿终端和忽视功能，可以将标准的DR相关操作模式换为DR策略和控制系统。研究计划包括继续与真实的工业标准研究组织合作，以通过相关努力使这些数据模型与标准协调发展。DR研究中心也会继续推进面向家庭、大型及小型商业建筑和工业企业的终端DR控制策略研究。专利需要提请注意，实现本规范可能会涉及到专利权问题。参与人员OpenADR工作组包括以下成员：技术咨询组1 概述开放式自动需求响应通信规范，也称为OpenADR或者Open Auto-DR，其开发开始于2002年的加利福尼亚大规模电力危机。加利福尼亚州、美国其他州以及国外的很多公用事业机构、政府部门、独立系统操作员和其他部门也正致力于引入需求响应来管理不断增长的电力需求和电力系统的尖峰负荷。DR被定义为“一种通过响应价格、货币激励或者系统指令以降低电力需求的行为，从而保证可靠地电力供应服务，避免高电价”。OpenADR是智能电网信息和通信技术的一个元素，以提高电力供应和需求的匹配能力。该项目由加利福尼亚能源委员会公益能源研究项目资助。OpenADR具有如下特征：l 连续、安全、可靠-l 翻译l 自动化l 自愿退出-当参与者不希望削减终端服务时，可以向参与者提供自愿退出或对DR事件信息忽视的功能。l 完整的数据模型为通信价格、可靠性和其他DR响应信号提供详细的数据模型和架构描述l 灵活的体系架构l 开放的标准OpenADR在加利福尼亚的200个用户中应用，为几个需求响应项目提供自动系统。这些项目从商业和工业用户提供了50MW的响应容量。效益提高参与企业数量、降低成本。l 开放的规范l 灵活性-提供开放、灵活、平台独立、可互操作的通信接口和协议l 创新及互用性鼓励开放创新和互用性，允许在现有策略基础上实现工厂和企业内部控制与通信，以减少技术操作和维护成本、不良资产和过时技术。l 易集成l 远程访问通过web端口提供自愿终端和忽视功能，可以将标准的DR相关操作模式换为DR策略和控制系统。本报告的章节结构如下。首先介绍OpenADR规范的目的、范围和原因，以及规范使用和实现概念的介绍。然后介绍DRAS的需求、组成元素和功能规范，以及数据模型和概要。最后一部分讨论了应用项目接口、安全策略和预期计划。OpenADR的预期计划包括与正式标准组织的合作。附录包括了技术支持和接口文件、安全问题的讨论和DR项目用例。2 研究领域开放式自动需求响应通信规范定义了DRAS功能和特征的接口，DRAS通过通信客户端来提供用户自动响应各种需求响应项目和动态电价的自动化手段。该规范也可以用于指导第三方团体，如公用事业机构、ISO、能源和企业管理者、集成商、硬件和软件厂商如何使用DRAS的功能来实现需求响应项目和动态电价的自动化。2.1 目的需求响应项目和公用事业机构和IDS提供的动态电价需要依靠实时、可靠的事件和信息通信。如果可以不需要人工干预，通信信号可以自动翻译为参与者的负荷削减或调整信号，将使得需求响应项目更加低成本、可靠和易于实现。 。 OpenADR是智能电网先进技术的一部分，如高级信息、控制和通信技术。这些技术可以用于优化电力服务商和用户的联系。2.2 原因一些参与者如集成商和大公司业务范围在地里上跨越多个电力监管区，因此必须处理多个公用事业机构。3 参考标准以下参考文档可以指导文档的应用。OpenADR规范的使用不需要建筑物自动化控制网络的实现。l “BAC网络/WS Web服务接口”,ANSI/ASHRAEl RFC2246:传输层安全协议V1.0，互联网工程任务4 规范的使用本文档被设计用于规范DRAS系统中必须实现的功能集。如前所述，DRAS是一个架构组件，被用于向企业和集成商自动发布DR事件信息。该文档希望满足以下要求：l 使公用事业机构和ISO具有将其信息技术设施与DRAS兼容的能力l 使控制器厂商将其能源管理装置和其他控制器与DRAS兼容l 允许相关操作人员（如企业和参与者操作员）获得参与需求响应控制层次的理解l 允许IT从业人员为公用事业机构或者ISO和相关操作员设计用户接口l 允许第三方机构建设DRAS或DRAS客户端，并可以从DRAS客户端或DRAS接收DR信号章节结构图：4.1 实现DRAS接口OpenADR规范可以规范DRAS系统必须具备的功能。规范书并不规定接口中每个功能的确切技术或者实现细节。例如规范规定必须使用SOAP web服务和WSDL，但并没有规定使用确切的语言和计算平台来实现DRAS。DRAS接口相关的三方接口如下：l 公用事业机构和ISO操作接口l 参与者操作员接口l DRAS客户端接口图1显示了三种接口间的联系l DRAS由不属于公用事业机构或者ISO的第三方机构开发，操作员接口也由第三方开发。在这种情况下，DRAS需要具备所有的三种接口l DRAS集成于一个公用事业机构的信息基础设施中，因而公用事业接口可以不需要。另外，公用事业机构提供了web页面，因此操作员接口也可以不需要。客户端接口仍然是必需的。l DRAS由不属于公用事业机构或者ISO的第三方机构开发，但操作员接口由同一个机构开发并集成到DRAS系统中，在这种情况下，公用事业接口和客户端接口都不需要，只需要操作员接口。可以注意到，任何情况下，操作员接口都是必需的。4.2 正确使用和引用OpenADR规范的正确引用如下：5 DRAS需求5.1 DR项目和动态电价中DRAS的通常角色DRAS自动需求响应项目中的一个基础设施组件，支持实体间的通信，这些实体既包括进行配电运营的公用事业机构和ISO，也包括管理电力消费的设施和集成商。DRAS使自动需求响应项目和动态电价中必须的通信通道实现自动化。这些通信包括将动态电价和可靠性相关消息和信息由公用事业机构或ISO发送到各种实体，以便于调整电力消费行为从而削减高峰负荷时的电力消费。5.2 用例其实Use Case就是对系统功能的描述而已本节介绍自动需求响应的一个典型用例，主要关注于DRAS在这些项目和动态定价中的角色。本节所介绍的用例只是一种归纳，附录D中包括针对具体DR项目和动态定价的用例，包括用例图中那些符号和术语的详细描述。用例中通常包含以下角色。5.2.1 用例场景公用事业机构中的角色l 公用事业机构项目操作员管理机构DR项目和动态定价的各个方面l 项目发布者向参与者发布DR事件和相关信息的计算机子系统或操作员l 项目结算负责通过测量电力使用进行DR项目结算，并将信息反馈到公用事业机构结算系统。DRAS中的角色l 事件发布者向参与者发布公用事业机构DR事件的子系统。该角色被专门设计用于需求响应自动化所需的端到端通信。l RTP发布者在价格发生变化时向参与者发布实时电价信息的子系统。该角色被专门设计用于需求响应自动化所需的端到端通信。l 项目发布者DRAS中的子系统，可以向参与的操作员发布DR项目和动态定价相关的各种事件。l 竞价代理（Bidding Proxy）- DRAS中的子系统，在DR项目或者动态定价需要参与者向公用事业机构提交出价时，作为自动投标代理。DRAS Client Roles DRAS Event Client. This is a sub-system of the DRAS Client and is responsiblefor notifying the facilitys automation sub-systems about DR program events. DRAS Feedback Client. This is a sub-system of the DRAS that providesfeedback to the DRAS concerning what is happening in a facility in response to aDR event. DRAS Operator. A human actor with the responsibility of creating other usersDRAS客户端中的角色集l DRAS事件客户端DRAS客户端的子系统，负责向用户的子系统通知DR项目事件。l DRAS 反馈 客户端- DRAS客户端的子系统，向DRAS反馈用户将如何响应DR事件l DRAS操作员-负责市场开拓的人员，创造更多的用户。Participant RolesParticipants are the customers of the utilities or ISOs that are participating in the DR programs and dynamic pricing. In general there will be one or more operators as part of the participants organization that is responsible for managing various aspects of their involvement in the DR program. Within the context of the use cases, there are the following roles:Facility Manager. A human operator responsible for managing various aspectsof the facility related to the DR program. Within the context of this document afacility manager may also be referred to as a “Participant Manager” or a“Participant Operator”. Aggregator Manager. A human operator responsible for managing variousaspects of the aggregators participation in the DR program.参与者角色集参与者是公用事业机构或ISO中参与DR项目和动态电价的客户。通常而言，参与者组织中会有一个或多个操作员负责管理DR项目中的各个方面。在用例环境中，主要有以下角色：l 组织管理者。负责管理组织中有关DR项目各个方面的操作员，也可以称为参与方管理者或者参与方操作员l 集成管理者（Aggregator Manager）。操作人员，负责管理DR项目中集成商的各个方面。5.3 用例场景每一个用例从以下三个场景进行说明：l 项目配置l 项目执行l 项目维护每一个场景讨论了各种角色的不同行为。5.3.1 项目配置项目配置包含了建立并自动运行一个具体的DR项目时所需要完成的动作，主要侧重于DRAS的配置。某些情况下，配置活动可能与DRAS无关。这些活动仅仅列出一个清单，以提供整个DR项目的完整性，并不涉及细节。项目执行项目执行包含了自动需求响应项目中实际执行和参与的活动。主要是公用事业单位向参与者发送DR相关信息时所需要的活动。某些情况下，这些活动可能与DRAS无关。这些活动仅仅列出一个清单，以提供整个DR项目的完整性，并不涉及细节。项目维护项目维护包括维护DR项目时所需要的动作，如更改配置、生成报告、监控DRAS运行状态。某些情况下，这些活动可能与DRAS无关。这些活动仅仅列出一个清单，以提供整个DR项目的完整性，并不涉及细节。5.3.2 需求响应项目的用例归纳 表2显示了附录D中多种用例文档中存在的需求响应功能，这有助于识别DR项目和动态定价中的公用活动。这些活动是DR项目中各种活动的概括。关于DRAS的实施可以概括如下：l 使用集成商的用例和直接与组织及组织管理者操作的用例是相似的；因此可以将集成商和组织管理者的角色同等对待。l 所有主要用于广播事件的用例对不同场景具有类似的步骤。区别主要与事件中传递的信息有关。l 所有自动运行竞价处理过程的用例包含相似的步骤。l 尽管竞价过程与具体的事件相联系，在竞价过程和广播事件的过程中并没有强联系。在DR项目和动态定价的分析中，可以发现只有2种功能：l 与DR事件通知自动化相关的动作l 与DR竞价过程自动化相关的动作基于以上分析，可以产生具有两种功能类的整体用例。在接下来的几章中将介绍这些用例。5.3.2.1一般基于事件的项目（GEBP）在各种用例中用来广播事件的步骤顺序基本相同。5.3.2.1.1 GEBP配置该场景包括输入所有参与DR项目所需要的信息，包括以下动作：1. 公用事业单位的项目操作员在单位信息系统（Utility Information System）中建立GEBP项目。包括与参与者签订合同，输入相关信息。相关细节不在本文档的讨论范围。2. 公用事业单位的项目操作员在DRAS中为参与的组织配置GEBP。包括在DRAS中输入信息以允许参与组织的管理者可以访问DRAS，设置DRAS客户端以与DRAS进行通信。需要输入以下信息：l 项目定义：m 项目安排参数，如执行时间、持续时间等m DR事件中规定的信息类型（如价格、等级等）m 提供DRAS客户端发布计划信号的项目事件信息（Program event information provided to DRAS Client for signal mapping）l 公用事业单位确定用于结算的账号l 参与者标识l 参与者密码l 地理位置l 电网位置3a.参与组织管理者为DR配置参与组织的EMCS或网络。可能会与EMCS供应商和IT部门冲突。可以对EMCS进行编程以使之可以恰当地削减或调整负荷以响应DR事件。相关细节不在本文档的讨论范围。3b. 参与组织管理者配置DRAS客户端。客户端可以采用多种形式，主要包括硬件和软件。通过配置DRAS客户端可以与参与组织的系统进行通信以管理负荷。相关细节不在本文档的讨论范围。3c.配置DR项目参数和客户端到DRAS的连接。建立DRAS与DRAS客户端的连接。一般包含以下信息：l 参与者身份标识和密码l 合同信息（电话号码、寻呼机、email地址等）l DRAS客户端通信参数m DRAS IP地址m IDm 密码m IP连接信息m 轮询周期l 可中断负荷潜力（(per time block per level)）l 其他参数l 自愿退出时间以上活动主要在DRAS完成，但也取决于在正式的OpenADR标准中如何实现，可能会在DRAS客户端而不是DRAS中完成。5.3.2.1.2 GEBP执行执行GEBP事件的活动包含以下步骤：1. 公用事业单位的项目操作员在信息系统中创建DR事件。他会在信息系统中为事件制定日程表。2. 公用事业单位的项目发布者从信息系统中获取DR事件信息，并在DRAS中启动事件。发布子系统向DRAS发布的信息包含以下内容：l 项目类型l 事件日期和时间l 启动日期和时间l 地理位置l 参与者名单（账号）3. DRAS的事件发布者向恰当的DRAS客户端发送DR事件信息，包括：l 公用事业单位事件信息m 事件日期和时间m 启动日期和时间m 地理位置m 模式及启动信号（Mode and pending signals）l DRAS客户端的等级（正常、中等、高）Mode signal levels for simple DRAS Clients (e.g. normal, moderate, high)l DRAS客户端事件启动信号（yes/no）Event pending signal for simple DRAS Clients (e.g. yes/no, or simplequantification of how far in advance notification is to be sent作为配合的一部分，DRAS客户端会向DRAS发送确认信息以表明已经收到DR事件信息。另外，确认信息中会显示客户端是否参加该事件。这提供了参与组织选择退出的功能，并可以向DRAS通知。4. DRAS事件客户端将事件信息发送到参与者系统，以进行负荷削减。5. DRAS反馈客户端向DRAS发送系统负荷状态。这种反馈机制可以用于记录参与方如何响应DR事件，包括以下信息：l 项目标识l 组织标识l 事件日期和时间l 削减的负荷容量l Near real time loadl 终端消费负荷削减（暖气、通风和空调、照明）l 事件类型（日前、日中）6. 公用事业单位结算程序测量参与组织的电力用量。公用事业单位操作员修改或者取消已启动DR事件的能力暂未包括，见图2的修改GEN事件。5.3.2.1.3 GEBP维护该场景包括维护GEBP项目的主要步骤。之前的配置和执行场景都含有预先描述清楚的执行步骤，维护场景则与之不同，主要是在不确定的时间由各种角色完成可能的动作。1a.公用事业单位的项目操作员获得操作报告。参与方的管理者可以在任意时刻从DRAS获得以下状态信息：l 事件状态（面向所有参与者）m 当前未完成（outstanding）事件n 所有参与者在项目中的负荷削减潜力n 从DRAS客户端得到的反馈m 事件日志1b.参与方管理者检查状态。公用事业单位的项目操作员可以在任意时刻从DRAS获得以下状态信息：l DRAS客户端通信状态m 当前状态m 最新合同m 当前信号级别m 当前参与者控制级别（选择性退出）m 通信日志m 信号日志m 人工控制日志l 事件状态（与以上内容相同）1c. 公用事业单位的项目操作员可以增加、修改和删除项目中的参与组织。类似于开始的配置步骤1d.参与方的管理者可以选择退出DR项目。任何时候，都可以退出DRAS。当处于选择退出状态时，DR事件不向DRAS客户端广播。选择退出可以针对整个DR项目或者某个单独的事件。在参与方接口中，操作员可以调用其中的一个方法在任意时候退出DR事件。1e. 公用事业单位的项目操作员或者参与方的管理者可以在异常时从DRAS收到退出通知。当异常发生，并需要以上两个角色做出反应时，DRAS会通过email或寻呼机向各自操作员发送信息。某些异常信号可能包括硬件或平台异常，如“磁盘空间不足”，这些不属于本文档的处理范围。本接口中处理的异常包括DRAS客户端连接异常5.3.2.2一般竞价项目（GBP）本节介绍GBP的一个用例.主要表述一个通常的竞价过程如何通过DRAS实现自动化。本节仅涉及竞价和出价接收过程，并不涉及上一节介绍的事件广播过程。5.3.2.2.1 GBP配置包括以下动作：1. 公用事业单位的项目操作员在单位信息系统（Utility Information System）中建立GBP项目。包括与参与者签订合同，输入相关信息。相关细节不在本文档的讨论范围。2.公用事业单位的项目操作员在DRAS中为参与的组织配置GBP。包括在DRAS中输入信息以允许参与组织的管理者可以访问DRAS，设置DRAS客户端以与DRAS进行通信。需要输入以下信息：l 项目定义：m 项目安排参数，如执行时间、持续时间等m DR事件中规定的信息类型（如价格、等级等）m 提供DRAS客户端发布计划信号的项目事件信息（Program event information provided to DRAS Client for signal mapping）l 公用事业单位确定用于结算的账号l 参与者标识l 参与者密码l 地理位置3参与组织管理者在DRAS中设定初始（standing）报价。该报价会在公用事业单位的报价请求到达时由DRAS自动设置（place）。包含以下内容：l 每一个时间段得负荷削减报价5.3.2.2.2 GBP执行 竞价过程包含以下步骤：1.公用事业单位的项目操作员在信息系统中创建DR事件。在该步骤中，项目操作员会在UIS中安排GBP竞价事件。相关细节不在本文档的讨论范围。2.公用事业单位的项目发布者从信息系统中获取GBP报价事件信息，并在DRAS中启动GBP报价请求。发布子系统向DRAS发布的信息包含以下内容：l 项目类型l 事件日期和时间l 启动日期和时间l 地理位置l 参与者名单（账号）l 请求报价(RFB)日期和时间l RFB关闭时间l 每一时间段的负荷削减报价3DRAS项目通知者向参与方管理者发送报价请求，通知形式可能是email、电话或寻呼机。4. 参与方管理者会选择或退出DRAS中的当前报价。如果没有任何动作，DRAS会在竞价结束时提交初始报价。5.当定价时间截止时，竞价代理会在UIS中设置当前价格。DRAS会向每一个参与方发送以下信息：l 参与者账号l 每一时段的负荷削减价格6公用事业单位的项目发布者从UIS中获取最终报价，并在DRAS中选择接受或拒绝。报价包含以下信息：l 参与者清单l 接受或拒绝l 每一时段的负荷削减价格7.DRAS项目发布者会通过电话、email或寻呼机向参与方管理者发送接受或拒绝通知。5.3.2.2.3 GBP维护该场景包括维护GEBP项目的主要步骤。之前的配置和执行场景都含有预先描述清楚的执行步骤，维护场景则与之不同，主要是在不确定的时间由各种角色完成可能的动作。1a.公用事业单位的项目操作员获得操作报告。参与方的管理者可以在任意时刻从DRAS获得以下状态信息：l 事件状态（面向所有参与者）m 当前未完成（outstanding）事件n 所有参与者在项目中的负荷削减潜力n 从DRAS客户端得到的反馈m 事件日志l 每一时段的负荷削减报价和信号级别（面向所有参与者、个体或者联合体）1b.参与方管理者检查状态。公用事业单位的项目操作员可以在任意时刻从DRAS获得以下状态信息：l DRAS客户端通信状态m 当前状态m 最新合同m 当前信号级别m 当前参与者控制级别（选择性退出）m 通信日志m 信号日志m 人工控制日志l 事件状态（与以上内容相同）1c. 公用事业单位的项目操作员可以增加、修改和删除项目中的参与组织。类似于开始的配置步骤1d.参与方的管理者可以选择退出DR项目。任何时候，都可以退出DRAS。当处于选择退出状态时，DR事件不向DRAS客户端广播。选择退出可以针对整个DR项目或者某个单独的事件。在参与方接口中，操作员可以调用其中的一个方法在任意时候退出DR事件。1e.参与方管理者在DRAS中配置初始竞价。5.4 总体需求本章表述了DRAS通常需求的清单，可能不针对某个具体的用例。通常的主要需求包括以下内容：Should use industry accepted methods and standards to ease integration andaccess to DRAS services from third parties.l 是否采用行业认可的方法和标准来简化集成，以及是否需要从第三方访问DRAS服务l 必须遵循成熟的安全策略以保证交互的信息可以通过认证l 必须与终端用户的企业IT基础设施易于集成m 方便防火墙配置m 完善的IT网络（没有安全风险、没有无用网络负载）l DR事件的等待时间不超过1分钟，与DRAS和DRAS客户端间的交互配置有关l DRAS必须在15分钟内维护l DRAS必须允许参与方使用一个DRAS来参与多个DR项目和动态定价l 在参与组织故障时DRAS可以良好得恢复，数据丢失最小。可能故障如电力中断或通信连接中断6 规范本章提供DRAS各种组件和功能的规范。6.1 自动需求响应架构图4和5显示了组件和系统架构与DRAS的接口，以管理实际的自动需求响应事件。同样，这些图显示了组件和系统的架构，这些组件和系统通过接口接入DRAS以使项目中参与者竞价提交自动化。用户接口完成了DRAS通信中的各种功能，但他们的描述、使用体验和实现细节不属于本规范的范围。因此，DRAS 用户接口web服务器和WEB客户端在DRAS的领域外显示。需要规范的是与DRAS的信息交互，以制定用户接口用于控制与DRAS的信息交互。理论上，在DRAS中支持用户接口是可能的，但这些用户接口如何实现不在本规范的讨论范围。 图中还包括了“第三方通知系统”。该子系统负责采用电话、email、传真等现有技术向参与方操作员发布通知。 值得注意的是在图4和图5所示的架构图中，DRAS本身被描述为一个独立于公用事业单位和参与者IT基础设施的服务。事实上，DRAS的具体实现可能还是会与IT设施相结合。6.2 一般需求通过之前对多种用例和上一节对架构的分析，可以将功能需求分为图6所示的几组。DRAS支持的接口业务可以分为3组：l 公用事业和ISO业务l 参与者业务l DRAS客户端业务这种分类可以反映DRAS中的角色。因为DRAS可能不是一个独立的实体，而是与公用事业的IT设施集成，不需要支持那些已有的功能。而在DRAS没有与IT设施集成时，仍然需要支持这些接口。并且，DRAS的某个具体实现可能包含web server，就不需要参与者为第三方实现自己的基于web的用户接口。任何情况下，DRAS必须遵守属于DRAS客户端接口范围的方法。除了提供业务描述之外，作为这些方法参数的数据模型实体（data model entities）也进行了说明6.3 公用需求所有的DRAS功能必须满足以下需求：l 他们必须使用某些可靠的通信方法来实现，以便于确认业务执行的信息被正确接收；l 所有功能必须遵循第十章的最小安全策略l 所有功能必须采用标准的web服务来实现l 所有功能必须根据安全角色进行约束访问6.3.1 DRAS用户账号和安全角色每个功能的访问只能通过DRAS授权的用户进行。相关细节在DRAS安全策略中描述。另外，用于访问DRAS功能的账号具有多个安全角色。以下安全角色有所使用：l DRAS操作员高度信任，具有所有信息和业务的访问权限。包括创建其他用户并分配对应的安全权限。DRAS操作员不能被本规范中描述的接口创建。l 参与方管理者具有与其参与方账号相关所有信息的访问权限。可以使用0.3节描述的函数来创建，也可以称为“参与方操作员”。l DRAS客户端主要是指作为DRAS和参与方组织间实现端到端通信的软件代理。DRAS客户端可以在0.2节的配置过程中完成。l 公用事业单位和ISO操作员可以访问所有DRAS中本单位内部的方法和业务。6.3.2 日志和报告DRAS必须可以追踪和保留活动日志。通常，由于各种操作通知产生的告警见6.3.3节。DRAS操作员和公用事业单位项目操作员可以访问所有交易的告警信息，而参与方管理者只能访问与自身交易相关的告警信息。任何人无权删除日志。日志不可能无限保存下去，但日志的处理过程不在本文档的研究范围内。主要的日志类型有：6.3.2.1 DRAS客户端通信状态DRAS需要掌握每一个DRAS客户端的通信状态，主要有以下几种：l 在线通信正常l 受限在线但有异常l 通信中断l 暂停服务（Out of Service，测试或维护）6.3.2.2 所有与DRAS的交易活动为正常工作，DRAS必须记录所有业务的请求。被记录的信息称为交易日志，在数据模型一章中进行描述。6.3.2.3 异常和报警条件DRAS需要跟踪以下信息：l DRAS客户端变为在线或离线状态6.3.3中主要描述因操作通知引起的告警，另外DRAS中的告警必须记录日志，因此需要使用第0节描述的功能。6.3.3 操作员通知DRAS需要向各种操作员发布通知，因此需要支持email通知以及与第三方信息发布系统的接口访问，如寻呼机、语音邮件、文本信息等。如何实现接口访问不在本文档范围。DRAS必须发布以下通知：l DRAS客户端在线、离线状态，通知对象包括：m 管理DRAS客户端的参与方操作员m 配置参与方账号的公用事业单位项目操作员m 所有的DRAS操作员DR event initiated. When the utility or ISO issues a DR event or modifies an existing DR event then a notification must be sent to all participant operators that are associated with DRAS Clients that would normally receive that event. Note that the program may require bidding by the participant in which case this notification may be a request for a bid.l DR事件启动。当公用事业单位或ISO启动或修改DR事件时，该通知必须发送给所有的参与方操作员，从而使DRAS客户端可以接收这一事件。另一种翻译：DRAS客户端接收事件通知，操作员从客户端接收该通知当需要参与方报价时，该通知会请求一个报价。l 参与方报价接受或拒绝。参与方的报价被接受或拒绝时操作员必须得到通知6.3.4 测试DRAS必须支持DR事件配置和与客户端通信的测试。l DR事件的端到端测试。同其他DR事件一样，测试事件也是向DRAS客户端发送信息，唯一的区别是测试事件中会含有一个说明该事件为测试事件的域。DRAS客户端接收到测试事件后可以选择恰当的方式进行处理，也可以直接忽略。l DRAS客户端测试。DRAS客户端安装程序可以将客户端下线并向DRAS发送测试信息。安装程序可以设置各种状太以实现人工控制。相关细节见7.3.6。6.4 接口函数使用的数据实体的介绍本章对信息交互中使用的多种数据实体进行简要描述，这些信息交互是通过规范中描述的多种函数来完成的。本章仅对各种数据实体进行主要介绍和概念性概述。概念性数据模型表达了作为DRAS操作一部分的各种数据元素，这些元素是从公用事业单位和参与方的角度出发的。该模型并不试图描述一个具体的数据库实现方案，而只是描述在公用事业单位、参与方和DRAS客户端与DRAS接口联系时所使用的各种数据模型。概念性数据模型以几个实体关系图简记E-R图是指以实体、关系、属性三个基本概念概括数据的基本结构，从而描述静态数据结构的概念模式（Entity-Relationship (ER) diagrams）来描绘。每一个图是实体和实体间的关系的集合。每一个实体代表了一个具有以下属性的基本数据模型：l 数据实体名l 实体主键。用于描述该实体区别于其他实体的标识符。l 数据元素或属性。实体的各种域。l 与其他实体的关系。实体与其他实体的关系可以用外键来描述。外键是与该实体相联系的实体的主键。接口函数图的关键内容与箭头相关的顺序号表示有多少实体与该实体关系相关l 1.* 表示至少一个但可能有多个l 1 表示着只有1个l *表示0到多个6.4.1 支持公用事业机构和ISO用例动作的数据实体本节的实体被支持公用事业机构或ISO功能的操作来使用。因此，被按照完成的业务进行组织：6.4.1.1公用事业单位事件当公用事业机构或ISO启动一个DR事件时使用这些实体。UtilityDREvent实体用来规范所有与DR事件相关的信息，包含以下通用属性：l 事件标识符系统唯一ID，在事件创建时由公用事业单位分配。用于关联和恢复具体DR事业相关的信息。l 项目名l 事件状态号是事件标识符的一个子标识符，用于确定何时事件发生改变。l 公用事业单位IT系统名启动DR事件的IT系统名称，可选域。l 事件投递地址接收DR事件的标识符列表m 确切的参与方账号IDm 组标识符m DRAS客户端位置规范l 事件计时-事件的各种事件参数m 通知时间-参与方应被通知DR事件的时间m 开始时间m 结束时间l 竞价信息m 开始时间m 关闭时间l 事件信息包含以下EventInfoInstance：每个事件可能包含一个事件信息实例列表，用于描述伴随事件发生时的信息。每个事件信息实例实体包含以下通用属性：l 事件信息类型名当DR项目定义时，这些类型即被定义并给予相应的名字。l 事件内容如果有多个值，则每个值对应于DR事件中某个时间段。相关细节见6.5节。l 参与方事件内容对应的参与方。l 信息组参与方属于某一个组，组用来指定哪些参与方可以接收该信息。UtilityDREvent在创建前，以下实体必须已经存在：l 公用事业单位项目l 参与方账号l 事件信息类型6.4.1.2 公用事业机构配置DRAS当公用事业单位或ISO配置DRAS时，使用图8所示的实体：UtilityProgram实体描述了所有与DR项目相关的信息。每一个项目都包含一系列属性以表述从DRAS和参与者的角度来如何管理和运行项目。主要属性包括：l 名字l 以日期和时间属性等形式表示的项目参数实体，用于标识DR事件何时可以发布l 参与者列表l 控制参与者如何完成竞价的参数l 与DR事件相关的信息类型的规范，以EventInfoType实体为形式。l EventInfoType实体，与DR事件相关信息的类型规范l 项目优先级EventInfoType实体是UtilityProgram的一部分，在事件创建时，用于规范与DR事件相关信息的类型规范。这些信息可能是实时电价、削减或转移级别。EventInfoType包含以下通常属性：l 名字l 信息数据类型规范l 允许值范围，如最小值、最大值l 在事件期间值变化的规范。以电价为例，DR事件的第一个小时为一种价格、第二小时为另一个价格，也可能在剩余事件段里还有另一个价格EventInfoType的更多信息在6.5节中描述。ParticipantAccount实体包含以下信息：l 参与方名称l 访问DRAS业务的访问认证（用户名和密码）。值得注意的是一个ParticipantAccount可能包含多个DRAS客户端的账号，每一个DRAS客户端的访问认证是不同的，与此处定义的访问认证不同。l 参与方隶属的组别。组用于处理1个以上的参与方进行DRAS的各个操作。l 参与者可能参加的项目和动态定价活动l 与参与方参与项目中相关变量相关的ProgramConstraint变量。l DRASClient实体。参与方与DRAS进行通信的实体l 竞价信息。参与方可能设置的初始报价l 合同信息。DRAS发给参与方操作员的通知ParticipantAccount实体由公用事业单位创建，更多细节见8.5节。6.4.1.3公用事业机构管理竞价当参与方在参加一个DR事件提交报价时，这些报价被提交给公用事业单位或者ISO。用于表示报价的数据实体见section 0。6.4.1.4 公用事业机构获得日志和告警DRAS需要维护和跟踪告警。用于表示这些活动的数据实体见图9的ER图。每个实体包含了足够的信息，以确定活动中涉及的执行人、事件和内容。更多细节见图8.76.4.2 支持参与者操作功能的数据实体参与者配置图10显示了可能由参与者创建和配置的多种实体，反映了各种操作所需要的数据块。公用事业单位创建ParticipantAccount.参与方只能修改与该实体相关的一部分属性，细节见8.5节。参与者可以定义很多项目约束，与一个特定的项目相关，定义了参与者参与项目的限制。ParticipantAccount可能包含很多Bid实体，描述了需要竞价的项目中的初始报价。ParticipantAccount可能定义很多DRASClient实体6.4.3 支持DRAS客户端功能的数据实体6.5 DRAS事件模型本章提供了公用事业机构和ISO如何对DR事件进行思考和建模的细节，这些事件由公用事业机构发布，DRAS客户端接收这些事件。6.5.1 公用事业机构或ISO对需求响应事件的观点当公用事业机构或ISO启动一个DR事件时会使用公用事业机构DR事件实体，包括以下常见属性：l 事件所针对的需求响应项目l 事件发生的日期和时间参数l 参与者应接收到事件通知的日期和时间参数l 时间发布者及发布区域l 事件相关信息。有关事件的项目信息，如RTP或削减或调整级别。需求响应事件时间和日期参数6.5.2 DRAS发布DR事件由公用事业机构或ISO下 DRAS客户端的DR事件发布由很多数据实体和参数来控制，他们由公用事业机构或ISO或参与者来配置。通常包含如下层次：l 项目和动态定价（DR事件作为项目的一部分）参与者属于项目，DRAS客户端属于参与者项目项目约束6.5.3 DRASclient对DR事件的观点交互模式PUSH or PULL前者由DRAS主动发送 后者由client发起Simple or smart两种客户端类型：简单和智能型的智能型：可以解析事件信息并对如何反应该事件做出决定简单型：只有简单的EMCS DRAS会将事件信息翻译为简单的格式以提供给简单客户端DR事件信息Smart DRAS客户端事件信息6.6 需求响应自动竞价模型DRAS可以通过为参与者支持“直接竞价“概念，提供参与者参与DR项目自动竞价。“直接竞价”是指没有其他参与者提供竞价时由DRAS直接提交的竞价。7 功能规范本章简要描述DRAS需要的多种功能，以支持前面介绍的DR事件用例和接口。7.1 公用事业机构或ISO操作功能本部分介绍为兼容DRAS，公用事业机构或ISO需要具备的功能。7.1.1 公用事业机构或ISO处理DR事件初始化DR事件：在DRAS中实现，由Utility或者ISO来启动。修改DR事件调整参与者列表获得DR事件信息设置事件约束获得事件约束7.1.2 公用事业机构或ISO支持自动竞价l 向DRAS查询已有报价l DRAS发送报价给utility或ISO的信息系统l 关闭竞价获取当前报价（PULL模式）：utility从DRAS获取设置报价（PUSH模式）：由utility或ISO的信息系统实现，并允许DRAS向参与者发送参与者的报价信息。关闭报价设置竞价状态7.1.3 公用事业机构或ISO配置DRAS管理项目创建项目修改项目删除项目获取项目信息调整项目参与方管理参与方账号创建修改删除获取账号获取组别7.1.4 公用事业机构或ISO监控DRAS活动获取DRAS客户端当前通信状态7.2 DRAS客户端功能本章主要DRAS和DRAS客户端进行DR事件相关的信息交互时所需方法的功能描述。7.3 参与者操作功能本章描述参与者操作接口的一部分。7.3.1 需求响应事件自愿退出自愿退出状态是指参与者不参与DR事件的一种条件集合。7.3.2 向DRAS提交反馈该功能用于参与者反馈状态。7.3.3 自动竞价本章节所描述的功能主要用于参与者管理与需要报价的DR事件相关的报价。报价以7.3.4 DRAS中参与者相关信息的配置这些功能被参与者用于配置接收与具体项目相关的DR事件。以下实体由参与者管理，并介绍如何操作和接收DR事件。l 参与者账号l DRAS客户端l 响应顺序l 项目参数7.3.5 DRAS相关活动监控DRAS日志记录6.3.2节中描述的多种交易和告警。7.3.6 DRAS客户端的安装和测试这些函数被用于测试DRAS客户端和DRAS之间的通信。8 详细数据模型和模式本节所描述的详细模式全部使用XML模式定义XSD（XML模式定义）是互联网联盟推荐的，它规定了可扩展标记语言（XML）文件中的元素的描述方式。来进行规范和文档化。8.1 公用程序见UtilityProgram.xsd8.2 公用DR事件见UtilityDREvent.xsd8.3 响应模式See ResponseSchedule.xsd8.4 函数参数See ProgramConstraint.xsd8.5 参与者账号See ParticipantAccount.xsd8.6 自愿退出状态See OptOutState.xsd8.7 日志See Logs.xsd8.8 反馈See FeedBack.xsd8.9 事件信息See EventInfo.xsd8.10 DRAS客户端See DRASClient.xsd8.11 竞价See Bid.xsd8.12 事件状态See EventState.xsd9 详细应用程序接口规范本节所描述的应用程序接口规范主要使用WSDL语言来规范，WSDL是描述SOAP简单对象访问协议（SOAP）是一种轻量的、简单的、基于 XML 的协议，它被设计成在 WEB 上交换结构化的和固化的信息。 web服务接口的标准方法。9.1 公用程序操作API9.2 参与者操作APIs9.3 DRAS客户端APIs 本章描述了用于DRAS和DRAS客户端通信应用程序接口方法的细节。9.3.1 用于交互DR事件状态信息简单REST服务的使用9.3.2 用于交互DR事件信息的简单SOAP服务的使用9.3.3 用于交互DR事件信息的BACnet web服务10 安全策略本章概括了与DRAS通信相关的安全策略，并指出了OpenADR规范需要的最小的安全策略元素和接口10.1 范围10.2 访问控制和安全角色11 开发计划12 定义、首字母和缩写附录A：XSD模式文件附录B：WSDL接口文件附录C：安全分析和需求本章提供了OpenADR通信规范中多种风险因素的高级安全分析。本附录同时介绍了基于以上分析的安全需求C.1 假设以下假设构成了OpenADR安全分析的基础：本文档是应用程序接口规范。因此为了便于讨论，DRAS的安全边界包含了定义API的函数。C.2 现有安全标准OpenADR规范意在恰当的时候可以影响和改变现有的安全策略和标准。以下策略和标准可能会被涉及到：l 北美电力可靠性协会（NERC）关键基础设施保护（CIP） CIP-002-009l 美国国家标准技术研究院(NIST) SP800-82 工业控制系统（ICS）系统安全导则l 结构信息标准化促进组织（OASIS）web服务安全标准l 开放式高级计量体系安全策略(OpenAMI-SEC)C.3 DRAS风险环境C.4 DRAS风险源C.5 不利的风险影