Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
Communication Protocol Mapping Guide 1.0, OpenADR 2.0 to ANSI/CTA-2045-A
Requirements for Exchanging Information Between OpenADR 2.0 Clients and ANSI/CTA-2045 Technologies
3002008854
10435823
10435823
EPRI Project Manager
C. Thomas
ELECTRIC POWER RESEARCH INSTITUTE 3420 Hillview Avenue, Palo Alto, California 94304-1338 PO Box 10412, Palo Alto, California 94303-0813 USA
800.313.3774 650.855.2121 [email protected] www.epri.com
Communication Protocol Mapping Guide 1.0, OpenADR 2.0 to ANSI/CTA-2045-A
Requirements for Exchanging Information Between OpenADR 2.0 Clients and ANSI/CTA-2045 Technologies
3002008854 Technical Update, May 2019
10435823
DISCLAIMER OF WARRANTIES AND LIMITATION OF LIABILITIES THIS DOCUMENT WAS PREPARED BY THE ORGANIZATION(S) NAMED BELOW AS AN ACCOUNT OF WORK SPONSORED OR COSPONSORED BY THE ELECTRIC POWER RESEARCH INSTITUTE, INC. (EPRI). NEITHER EPRI, ANY MEMBER OF EPRI, ANY COSPONSOR, THE ORGANIZATION(S) BELOW, NOR ANY PERSON ACTING ON BEHALF OF ANY OF THEM:
(A) MAKES ANY WARRANTY OR REPRESENTATION WHATSOEVER, EXPRESS OR IMPLIED, (I) WITH RESPECT TO THE USE OF ANY INFORMATION, APPARATUS, METHOD, PROCESS, OR SIMILAR ITEM DISCLOSED IN THIS DOCUMENT, INCLUDING MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, OR (II) THAT SUCH USE DOES NOT INFRINGE ON OR INTERFERE WITH PRIVATELY OWNED RIGHTS, INCLUDING ANY PARTY'S INTELLECTUAL PROPERTY, OR (III) THAT THIS DOCUMENT IS SUITABLE TO ANY PARTICULAR USER'S CIRCUMSTANCE; OR
(B) ASSUMES RESPONSIBILITY FOR ANY DAMAGES OR OTHER LIABILITY WHATSOEVER (INCLUDING ANY CONSEQUENTIAL DAMAGES, EVEN IF EPRI OR ANY EPRI REPRESENTATIVE HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES) RESULTING FROM YOUR SELECTION OR USE OF THIS DOCUMENT OR ANY INFORMATION, APPARATUS, METHOD, PROCESS, OR SIMILAR ITEM DISCLOSED IN THIS DOCUMENT.
REFERENCE HEREIN TO ANY SPECIFIC COMMERCIAL PRODUCT, PROCESS, OR SERVICE BY ITS TRADE NAME, TRADEMARK, MANUFACTURER, OR OTHERWISE, DOES NOT NECESSARILY CONSTITUTE OR IMPLY ITS ENDORSEMENT, RECOMMENDATION, OR FAVORING BY EPRI.
The Electric Power Research Institute (EPRI) prepared this report. This is an EPRI Technical Update report. A Technical Update report is intended as an informal report of continuing research, a meeting, or a topical study. It is not a final EPRI technical report.
NOTE For further information about EPRI, call the EPRI Customer Assistance Center at 800.313.3774 or e-mail [email protected].
Electric Power Research Institute, EPRI, and TOGETHER…SHAPING THE FUTURE OF ELECTRICITY are registered service marks of the Electric Power Research Institute, Inc.
Copyright © 2019 Electric Power Research Institute, Inc. All rights reserved.
10435823
This publication is a corporate document that should be cited in the literature in the following manner:
Communication Protocol Mapping Guide 1.0, OpenADR 2.0 to ANSI/CTA-2045-A: Requirements for Exchanging Information Between OpenADR 2.0 Clients and ANSI/CTA-2045 Technologies. EPRI, Palo Alto, CA: 2019. 3002008854.
iii
ACKNOWLEDGMENTS The Electric Power Research Institute (EPRI) prepared this report.
Principal Investigator C. Thomas
This report describes research sponsored by EPRI.
This document was compiled from knowledge gained through collaborative research performed by EPRI between 2009 and 2019, that focused on developing and testing communication protocols to facilitate open access to behind-the-meter devices. The knowledge gained through research was made possible through contributions from technical leaders across many different utilities, national laboratories, member organizations, standard development organizations, manufacturers and service providers including, but not limited to the following:
Utilities
Bonneville Power Administration (BPA) Duke Energy Electric Power Board (EPB) Hawaiian Electric Company Hydro One Jackson EMC McMinnville Electric System (MES) Oglethorpe Power Portland General Electric (PGE) Southern Company Tennessee Valley Authority (TVA)
National Labs Oak Ridge National Laboratory (ORNL) Pacific Northwest National Laboratory (PNNL) National Renewable Energy Laboratory (NREL) Lawrence Berkeley National Laboratory (Berkeley Lab)
Member Organizations OpenADR Alliance Northwest Energy Efficiency Alliance (NEEA) Consortium of Energy Efficiency (CEE)
Standards Development Organizations
Consumer Technology Association (CTA) Air-Conditioning, Heating, and Refrigeration Institute (AHRI)
Manufacturers
AO Smith Siemens Pentair Emerson IslandAire
Service Providers Nebland LLC SkyCentrics e-Radio
10435823
10435823
v
ABSTRACT The intent of this publication is to provide the industry with a standardized approach to exchanging information between two different open communication standards, OpenADR 2.0 and ANSI/CTA-2045-A. The document defines how a specific set of messages from one standard are mapped to the other (i.e. protocol map). The map included herein was implemented and field tested with behind-the-meter (BTM) loads in systems designed to provide services to the grid. The systems were comprised of the following actors (1) an OpenADR 2.0 certified demand response management system, (2) an ANSI/CTA-2045 communication module with an embedded certified OpenADR 2.0 client and (3) different types of BTM loads that were preconfigured to respond to information exchanged through a native ANSI/CTA-2045-A port The responses of each BTM load was made predictable by requiring manufacturers to support a specific set of ANSI/CTA-2045-A messages. The set of ANSI/CTA-2045-A messages that BTM loads were required to support (included in Section 4.0 of this report) was used to determine the core set of messages include in the map, The mapping requirements and other information included in this document are intended to enable (1) manufacturers to embed “grid service” functionality into off-the shelf products, (2) consumers to directly access or manage access (i.e. utility, aggregator or third-party service provider) to information or functions embedded into their own devices to manage energy or demand BTM or provide services to the grid across the meter and (3) utilities, aggregators or any third-party to design and deploy systems with components that could be interchanged with those produced by manufacturers other than the original.
Keywords ANSI/CTA-2045 ANSI/CTA-2045-A Behind-the-meter BTM Communication port Demand response EVSE Functional requirements Grid interactive water heater Grid services Load management Modular interface OpenADR 2.0 Pool pump Smart grid Water heater
10435823
10435823
vii
GLOSSARY OF TERMS Actor – Representative name assigned to each of the subcomponents of a system that contribute to the output of a system. Example actors are humans, machines, or applications.
Application – Software program designed to provide a specific service.
Behind-the-meter (BTM) – Term used to describe resources physically located within the customer’s premises.
Compliance – Conformance to a specific set of rules or requirements. This term is typically used in reference to standards and is used to signify that a technology or service meets the rules or requirements defined in a specific standard.
CTA – Consumer Technology Association
CTA-2045 Communication Module or Universal Communication Module (UCM) – A communication module that complies with the ANSI/CTA-2045-A standard under the form factor classification of either AC or DC.
Demand Response Management Application (DRMA) – An application designed to manage the aggregate services provided by resources.
Demand Response Management System (DRMS) – A DRMA and components required to support aggregate demand response services.
DRMS Operator – Human that interfaces with the DRMS through a graphical user interface that enables the DRMS and Human to exchange information.
Functional Requirement – A requirement defines the contribution of an actor within a system or the system itself. Functional requirements define specific functions or behaviors of actors within a system or the system.
Grid Service – Functions or behaviors of a device that could provide a benefit to the public.
GUI (Graphical User Interface), HMI (Human-Machine Interface), or H2M (Human-to-Machine) – These acronyms are used to represent an interface that enables humans and machines to share information.
Interface – Communications interfaces represent a pathway by which information is exchanged between actors. The interface is a pathway that conforms to a specific set of rules that must be supported by all actors that are required to exchange information.
Interoperability – The capability of two or more actors or systems to be connected to one another and exchange and process information in a predictable way without having to make any modifications to the involved actors.
M2M (Machine-to-Machine) Interface – Pathway over which information is shared between two machines.
Machine – Device that consumes, generates, or stores energy.
10435823
viii
Non-Functional Requirement – A requirement that defines the qualities of a system, such as security, maintainability, and scalability, that can be used to judge how well the system operates and evolves.
OpenADR 2.0 – Open Automated Demand Response, published by the OpenADR Alliance, is a communication specification that defines the rules for sharing information between a server and one or more clients on a shared network. The specification includes application-layer messages that exchange information to support energy and other services. The standard also requires that messages be secured in accordance with TLS 1.2 and transported using HTTP or XMPP.
Profile – A set of constraints or rules for applying a standard.
REQ – Requirement
Resource – Smart-Grid Device (SGD)
Requirement – (1) A condition or capability needed to achieve an objective. (2) A condition or capability that must be met or possessed by an actor or system.
Smart-Grid Device (SGD) – Used in the ANSI/CTA-2045-A standard to describe the end-use device.
Standard – A technical specification, usually produced by a Standards Development Organization (SDO). Standards define sets of rules that can be tested across products or services provided by any manufacturer.
Subsystem – one or more actors within a system that work together to perform a specific task. Typically, actors within a subsystem communicate to one another through proprietary interfaces supplied by one manufacturer.
System (Control) – A collection of components (actors) whose collective output (dependent variable) can be predicted by managing the inputs (independent variables).
System (Operational Procedures) – A set of procedures that describes how to operate the system.
Universal Communication Module (UCM) – Name used in the ANSI/CTA-2045-A standard to describe the module that plugs into a ANSI/CTA-2045-A port of an end-use device.
Use-case – A document that includes the rules, requirements, actors, and operational and technical objectives of a system.
10435823
ix
CONTENTS ABSTRACT .................................................................................................................................. v GLOSSARY OF TERMS ............................................................................................................. vi 1 INTRODUCTION .................................................................................................................... 1-1
1.1 Approach ........................................................................................................................ 1-1 1.2 Intended Use .................................................................................................................. 1-2
2 MAPPING REQUIREMENTS ................................................................................................. 2-1 2.1 Housekeeping Functions (Normative) ............................................................................ 2-2 2.2 Load Management Functions (Normative) ..................................................................... 2-7 2.3 Monitoring and Reporting Functions (Normative) ........................................................ 2-11
3 GROUPING / TARGETING BEHIND-THE-METER RESOURCES ........................................ 3-1 3.1 Targeting Requirements (Normative) ............................................................................. 3-2
3.1.1 ResourceID Format (Normative) ........................................................................... 3-5 3.1.2 GroupID Format (Normative) ................................................................................ 3-5
3.2 Example Targeting Application (Informative) ................................................................. 3-6
4 FUNCTIONAL REQUIREMENTS FOR ANSI/CTA-2045 RESOURCES (INFORMATIVE) ........................................................................................................................ 4-1
Domestic Water Heaters ...................................................................................................... 4-2 Heat Pump Water Heater ..................................................................................................... 4-3 Programmable Thermostat .................................................................................................. 4-4 Variable-Speed Pool Pump .................................................................................................. 4-5 Electric Vehicle Supply Equipment ...................................................................................... 4-6 Packaged Terminal Air Conditioner ..................................................................................... 4-7 Variable Capacity Heat Pumps ............................................................................................ 4-8
5 REFERENCES AND RESOURCES (INFORMATIVE) ........................................................... 5-1 5.1 Reference Standards ..................................................................................................... 5-1 5.2 Open Source Code Repositories ................................................................................... 5-1 5.3 System Diagrams (Symbols – Definition, Nomenclature, Use) ...................................... 5-2
10435823
10435823
xi
LIST OF FIGURES Figure 1-1 Reference BTM System Diagram ............................................................................. 1-3 Figure 1-2 Example 1 – Architecture of a Load Management System ...................................... 1-4 Figure 1-3 Example 2 – Architecture of a Load Management System ...................................... 1-4 Figure 2-1 Example application of OpenADR 2.0 and ANSI/CTA-2045-A ................................. 2-1 Figure 2-2 Conceptual mapping application and its functional blocks ....................................... 2-2 Figure 3-1 Use of groups and their assigned level of filtering .................................................... 3-5 Figure 3-2 Example Use of Targeting Requirements ................................................................. 3-7 Figure 5-1 Example use of symbols in a system that relies on OpenADR 2.0 and
ANSI/CTA-2045-A to dispatch BTM resources .................................................................... 5-5
10435823
10435823
xiii
LIST OF TABLES Table 1-1 Functional Specifications for ANSI/CTA-2045-A Resources ..................................... 1-2 Table 1-2 Example Application of the Requirements (Filtered by Actor) ................................... 1-5 Table 2-1 Housekeeping Requirements .................................................................................... 2-3 Table 2-2 Load Management Mapping Requirements ............................................................... 2-8 Table 2-3 Measurement and Reporting Mapping Requirements ............................................. 2-12 Table 3-1 Uses of Targeting in the OpenADR 2.0 Demand Response Program
Implementation Guide, Revision 1.1, Document Number 20140701. (Informative) ............. 3-2 Table 3-2 Five grouping levels supported by and defined in OpenADR 2.0a and 2.0b ............. 3-3 Table 3-3 Target Level Filtering ................................................................................................. 3-4 Table 3-4 Resource Device Types for eiTarget:groupID ........................................................... 3-5 Table 4-1 Demand Response-Ready Domestic Water Heater Specification: Preliminary
Requirements for CEA-2045 Field Demonstration. EPRI, Palo Alto, CA: 2014. 3002002710 ......................................................................................................................... 4-2
Table 4-2 Demand Response-Ready Heat Pump Water Heater Specification: Preliminary Requirements for CEA-2045 Field Demonstration. EPRI, Palo Alto, CA: 2014. 3002002719. .............................................................................................................. 4-3
Table 4-3 DR-Ready Programmable Thermostat Specification: Preliminary Requirements for CEA-2045 Field Demonstration. EPRI, Palo Alto, CA: 2014. 3002002711 ......................................................................................................................... 4-4
Table 4-4 Demand Response-Ready Variable-Speed Pool Pump Specification: Preliminary Requirements for CEA-2045 Field Demonstration. EPRI, Palo Alto, CA: 2016. 3002008320 ............................................................................................................... 4-5
Table 4-5 DR-Ready Electric Vehicle Supply Equipment Specification: Preliminary Requirements for CEA-2045 Field Demonstration. EPRI, Palo Alto, CA: 2014 3002002712 ......................................................................................................................... 4-6
Table 4-6 Demand Response-Ready Programmable Packaged Terminal Air Conditioner Specification: Preliminary Requirements for CEA-2045 Field Demonstration EPRI, Palo Alto, CA: 2015 3002006951 ......................................................................................... 4-7
Table 4-7 Requirements for Variable Capacity Heat Pumps (Air Conditioning, Heating and Refrigeration Institute (AHRI) Standard P1380. ............................................................ 4-8
Table 5-1 Referenced Communication Standards ..................................................................... 5-1 Table 5-2 Open Source Code Repositories for OpenADR 2.0 and ANSI/CTA-2045
Applications .......................................................................................................................... 5-1 Table 5-3 System Diagram Symbol Definitions ......................................................................... 5-2
10435823
10435823
1-1
1 INTRODUCTION This document defines the requirements for exchanging information between the application layers of OpenADR 2.01 and ANSI/CTA-2045-A2. The requirements included herein (i.e. protocol map) were implemented and field tested in a system comprised of the following actors (1) demand response management system that supports OpenADR 2.0, (2) an ANSI/CTA-2045-A communication module that supports OpenADR 2.0 and (3) end-use devices that support ANSI/CTA-2045-A that conform to publicly available device type specific functional requirements (overview included in Section 4.0 of this report). The research was carried out to demonstrate how loads with built-in demand responsive features, accessible through an open interface could respond directly to dispatch signals, eliminating the need for an intermediary cloud application to consume the dispatch signal and disseminating instructions to loads through a proprietary messaging protocol. The key actor in this system was the ANSI/CTA-2045-A communication module, that was tasked with exchanging information with an OpenADR 2.0 server, converting dispatch instructions into a process by which information is exchanged with the load in a sequential order to provide the instructed service to the grid.
1.1 Approach OpenADR 2.0 and ANSI/CTA-2045-A were developed to facilitate the open exchange of information between actors participating in a load management system. Even though both protocols were designed to support actors in load management systems, they were designed to exchange information with specific actors. Since both protocols support load management systems, the information supported by the application-layers of both protocols are similar, but they are very different. OpenADR 2.0 for example, was designed to exchange secured information with one or more actors in the system over a shared network (i.e. internet), whereas ANSI/CTA-2045-A was designed to exchange information between two actors, the end-use device (i.e. BTM resource) and a communication module over a private serial communication port. OpenADR 2.0 and ANSI/CTA-2045-A were designed to coexist with one another within the same system. Since load management services are provided by resources at their point of connect to the grid, the systems are dependent on the load management functions supported by resources and the accessibility of their functions. The map between ANSI/CTA-2045-A and load management functions for different types of resources were used to determine the information set to include in this guideline. Specifications for mapping ANSI/CTA-2045-A to functions of different types of resources are included in Table 1-1. The set of ANSI/CTA-2045-A messages common across the specifications listed in Table 1-1 were used to determine the minimum set of OpenADR 2.0 messages to include in the map. Tables that summarize the functional specifications listed in Table 1-1 are included in Section 4.0.
1 OpenADR Alliance, OpenADR 2.0 Profile Specification B v1.1, 11-17-2015. 2 Consumer Technology Association, ANSI/CTA-2045-A Modular Communications Interface for Energy Management, March 2018.
10435823
1-2
Table 1-1 Functional Specifications for ANSI/CTA-2045-A Resources
Resource Types EPRI Publication ID for
Functional Requirements
Summary Tables (Map between
ANSI/CTA-2045-A Messages and
Functions)
Domestic Electric Water Heater 3002002710 Table 4-1
Heat Pump Water Heater 3002002719 Table 4-2
Thermostat 3002002711 Table 4-3
Variable Speed Pool Pump 3002008320 Table 4-4
Electric Vehicle Supply Equipment 3002002712 Table 4-5
Packaged Terminal Air Conditioners 3002006951 Table 4-6
Variable Capacity HVAC AHRI P1380 Table 4-7
To ensure that the requirements defined herein could be applied in contemporary and near-future systems, a general assessment of the technologies available today was performed. Summary findings are included below.
• OpenADR 2.0 Virtual Top Nodes, Applications and services are available through different service providers3. Open source OpenADR 2.0 server application (certified by the OpenADR Alliance) is available on GitHub (see Section 5.2).
• OpenADR 2.0 Virtual End Nodes, Applications and libraries that support different operating systems are available through a number of different service providers. Open source applications for a variety of OpenADR 2,0 clients are available on GitHub (see Section 5.2).
• ANSI/CTA-2045 Communication Modules, Hardware with one or more types of physical communication interfaces capable of transporting OpenADR 2.0 payloads are produced by different manufacturers.
• ANSI/CTA-2045 Resources (Power Consuming Devices), Multiple types of resources are available from different manufacturers. Section 4.0 include the recommended (and applied) functional specifications requirements for most of the device types available today.
1.2 Intended Use This document is intended to enable (1) manufacturers to embed “grid service” functionality into off-the shelf products, (2) consumers to directly access or provide others access (i.e. utility, aggregator or third-party service provider) to the embedded functionality and (3) utilities, aggregators or any third-party to design and deploy systems with interchangeable components that rely on BTM resources to provide predictable services to the grid. The map is intended to be used in the design, development and deployment of systems that manage BTM resources. Before example applications of the requirements are introduced, it’s important to be familiar with system architectures and how these systems are represented in this document. The graphic
3 The OpenADR Alliance publishes a list of OpenADR 2.0 certified applications and technologies.
10435823
1-3
in Figure 1-1 is used to represent a simplified BTM system. The components of this system include (actors), the flow of information between actors (interface), decisions and actions (logic) that each actor must support to achieve the system’s objective (output or grid service). For further reference, the symbols used in this diagram and subsequent figures are defined in Section 5.3.
Actorb
To other Systems
Interface(a,b)
Grid Service
Actorc
ActordActora
Interface(b,Systemx)
Interface(b,c) Interface(c,d)
Input Output
Logi
c
Logic
Logi
c
Physical Process
System
Logi
c
Logi
c
Logic
Logi
c
Process
Human
Machine Machine
Human
Change of Demand or Eneryg
Information InformationInformation
Information
Figure 1-1 Reference BTM System Diagram
The following diagrams are intended to illustrate how the map could be deployed within systems designed to support the same use-case, but architected with different components. To help provide some insight into how the systems are intended to work, some general rules and requirements of the use-case are listed below.
• A Resource is any off-the-shelf energy consuming device that support a variety of different types and levels of grid services that can be accessed at the device through an ANSI/CTA-2045-A interface.
• Dispatch signals conform with the OpenADR 2.0 standard. • Resources can be dispatched either manually by an operator or automatically by a secondary
system. • Information from the resources, such as Power, Energy Usage, Operational State and other
information is available to the operator or to a secondary system. • Dispatch signals can be sent to a single resource or groups of resources as determined by the
operator or secondary system. • The OpenADR 2.0 client resides within the premise.
In the system illustrated in Figure 1-2, an OpenADR 2.0 client embedded into an ANSI/CTA-2045-A communication module receives dispatch signals. The module uses the information contained in the dispatch signal to determine the sequence of information that must be exchanged with the resource to satisfy the dispatch.
10435823
1-4
Resource
Grid
Ser
vice
Operator
OpenADR 2.0
Ope
nADR
2.0
Se
rver
ControlU
ser
Inte
rface
Premises
To Other Systems (i.e. Event trigger, price schedule, real-
time feed, M&V, etc)
CTA-2045-AOperator Interface
Process Controller
Fu
nctio
n an
d D
ata
Map
CT
A-20
45-A
O
ther
Sy
stem
s
OpenADR-to-CTA-2045(OpenADR.UCM)
Universal Communication Module
CTA
-204
5-A
Mapping Application
O
penA
DR
2.0
Virt
ual E
nd N
ode
Control
User User
Energy / Demand Response / Distributed Energy Resource - Management System
(E/DR/DER MS)
Figure 1-2 Example 1 – Architecture of a Load Management System
In the system illustrated in Figure 1-3, an OpenADR 2.0 client embedded into a Home Energy Management System (HEMS) receives dispatch signals. The HEMS uses the information contained in the dispatch signal to determine which resource to target and sequence of information that must be exchanged with the resource to satisfy the dispatch.
Premises
Resource
Grid
Ser
vice
Operator
OpenADR 2.0
Ope
nADR
2.0
Se
rver
Ope
nAD
R 2
.0
Clie
nt
Home Energy Management System
(HEMS)
VOLT
TRO
N
Any
Inte
rfac
e
Mapping Application
Control
Control
Use
r In
terfa
ce
To Other Systems (i.e. Event trigger, price schedule, real-
time feed, M&V, etc)
Any Interface CTA-2045-AOperator Interface
Process Controller
Any
Inte
rfac
e
CTA
-204
5-A
Mapping Application
Control
Fu
nctio
n an
d D
ata
Map
CT
A-20
45-A
O
ther
Sy
stem
s
User
User
Energy / Demand Response / Distributed Energy Resource - Management System
(E/DR/DER MS) HEMS-to-CTA-2045(HEMS.UCM)
Universal Communication Module
Figure 1-3 Example 2 – Architecture of a Load Management System
Table 1-2 shows how the contents of this document could be used by the components (actors) of both example systems. Included in this table are the names of the actors, their role in the system and how the contents of different sections of this document could be applied to support the system.
10435823
1-5
Table 1-2 Example Application of the Requirements (Filtered by Actor)
Actor Description / Role Dependent Actor(s) Referenced Section
Example Use of the Requirements in Reference Section
Energy / Demand Response / Distributed Energy Resource - Management System (E/DR/DER MS)
Application designed to manage resources located before or behind the meter to provide aggregation and other control services as determined by the requirements of the system the application is intended to support
OpenADR.UCM HEMS Operator (not specified) Other Systems (not specified)
2.2 To specify the minimum set of OpenADR 2.0 event signals required to dispatch ANSI/CTA-2045-A resources. To specify, design and/or develop user interfaces configured to support each event signal identified in the minimum set.
2.3 To determine the information that could be reported. To specify the information must be made available to support control or measurement and verification requirements of te program
3.0 To setup groups and subgroups to enable dispatch signals to be sent to a single resource or multiple resources within a group.
4.0 To determine what functions embedded in different types of resources could be leveraged to provide the most value to consumers and the grid.
Home Energy Management System (HEMS) Controller
Application running on a controller within a premises that’s designed to manage energy usage or demand of one or more behind the meter resources. Interfaces: OpenADR 2.0 VEN Undefined
E/DR/DER MS HEMS.UCM User or Consumer (not specified)
2.0 If programmatic rules require pending and active event notifications at the device, this section could be used to specify how to use issue notifications To specify the Link Layer messages and how to use the payload of the Outside Communication Status command
2.2 To specify how OpenADR 2.0 dispatch signals must be processed by the controller
2.3 To specify the information and frequency by which data from the device must be queried and presented to an OpenADR 2.0 VTN through the EiReport service
3.0 To specify the naming conventions for the resources behind the VEN (ResourceID) To specify the use and format of GroupIDs for filtering and processing events To specify how EiEvents with one or more group IDs match those assigned to the HEMS’s VEN
4.0 To determine and specify the type and level of services that different resources could provide to the grid and how the ANSI/CTA-2045-A interface is used to access the services.
HEMS-to-CTA-2045 (HEMS.UCM) Communication Module
A device that meets the minimum requirements for a communication module as defined in ANSI/CTA-2045-A standard that also includes software and hardware required to connect to and communicate with the HEMS
RESOURCE HEMS User or Consumer (not specified)
2.0 To specify the minimum set of ANSI/CTA-2045-A commands to communicate with the resource To specify commands required to support the HEMS or the system in which the HEMS is supporting.
2.2 To specify how OpenADR 2.0 dispatch signals must be converted to ANSI/CTA-2045-A commands and the sequence by which the commands must be sent to the resource.
10435823
1-6
Actor Description / Role Dependent Actor(s) Referenced Section
Example Use of the Requirements in Reference Section
2.3 To specify the commands that must be sent to the resource to obtain information required to support the HEMS or the system in which the HEMS is supporting.
3.0 To specify the naming convention for the attached resource (ResourceID).
4.0 To determine and specify the type and level of services that different resources could provide to the grid and how the ANSI/CTA-2045-A interface is used to access the services
OpenADR-to-CTA-2045 (OpenADR.UCM) Communication Module
A device that meets the minimum requirements for a communication module as defined in ANSI/CTA-2045-A standard. The module also includes a certified OpenADR 2.0b VEN and the hardware required to connect to and communicate with an OpenADR 2.0b VTN located outside the premises.
E/DR/DER MS RESOURCE User or Consumer (not specified)
2.0 To specify the minimum set of commands required to communicate with a ANSI/CTA-2045-A resource To specify commands required to support the system in which the module is intended to support.
2.2 To specify how OpenADR 2.0 dispatch signals must be converted to ANSI/CTA-2045-A commands and the sequence by which the commands must be sent to the resource.
2.3 To specify the commands that must be sent to the resource to obtain information required to support the HEMS or the system in which the HEMS is supporting.
3.0 To specify the naming conventions for the resources behind the VEN To specify the use and format of GroupIDs for filtering and processing events To specify how EiEvents with one or more group IDs match those assigned to the VEN
4.0 To determine and specify the type and level of services that different resources could provide to the grid and how the ANSI/CTA-2045-A interface is used to access the services
RESOURCE Energy consuming resource with embedded grid services that can be accessed through a ANSI/CTA-2045-A interface
HEMS.UCM OpenADR.UCM
4.0 To specify the type and level of services that must be embedded into the resources and how they must be accessed through an ANSI/CTA-2045-A port.
10435823
2-1
2 MAPPING REQUIREMENTS The requirements in this section define the rules by which information contained in the application-layer of one communication protocol is shared with the application-layer of another. The set of messages (i.e. information) contained in OpenADR 2.0 and ANSI/CTA-2045-A are similar, however the rules that govern how messages are exchanged between specific actors are quite different. OpenADR 2.0 is designed to exchange information over a network, shared by other devices. In the majority of contemporary systems where OpenADR 2.0 is deployed, the shared network is the public internet4. ANSI/CTA-2045-A is designed to exchange information between two devices (one being the BTM load and the other, a device physically attached to the load) over a private serial communication bus. Figure 2-1 is included to show where in a system these standards were intended to be deployed. In this system, Actora conforms to the rules of a OpenADR 2.0 server (i.e. Virtual Top Node) exchanges information with multiple clients over a shared network. Actorb conforms to the rules for both an OpenADR 2.0 client (i.e. Virtual End Node) and ANSI/CTA-2045-A communication module. The module exchanges information with Actorc which conforms to the functional specifications for ANSI/CTA-2045 resources (see Section 4.0).
Figure 2-1 Example application of OpenADR 2.0 and ANSI/CTA-2045-A
4 To deter security threats inherent to public networks, OpenADR 2.0 requires that the payloads be encrypted using transport-layer security (TLS 1.2).
10435823
2-2
Each standard defines the roles for each actor along with information each must support and the process for exchanging information between the actors. Each of these two standard define processes that are very different from one another that govern what and when information is exchanged. This process must be considered when applying the mapping requirements and when developing the requirements for the hardware and software to implement the map. For example, the information exchanged between OpenADR 2.0 actors are primarily triggered by events, even though there are some exchanges are scheduled, whereas ANSI/CTA-2045-A actors sequentially exchange information in real-time. The block diagram in Figure 2-2 is included to show the functional blocks of a conceptual mapping application (see Actorb) and that the sequence and time by which information is exchanged between Actorb and Actora will not align with the sequence and time by which information is exchanged between Actorb and Actorc.
Figure 2-2 Conceptual mapping application and its functional blocks
2.1 Housekeeping Functions (Normative) This section is titled “Housekeeping” because there are a few ANSI/CTA-2045-A commands that the standard requires all actors to support or are common across the functional specifications for all device types included in Section 4.0. These messages include the link-layer ACK/NAK, query capabilities (Message Types of Supported Query/Response, Max Payload Length, verify that the data contains the appropriate information (Basic Application ACK/NAK) and to inform the resource of its communication status (Outside Communication Status).
This section also includes messages that could be required to support a specific grid services use-case and other information obtained through the information exchange processes themselves. These additional commands include (Operational State Query/Response) used to query the resource for its operational state, (Pending Event Time) and (Pending Event Type) which could be used if the system requires the resource to be informed of the next event type and time (duration) till the next event. Requirements for how these commands must be applied are included in Table 2-1.
10435823
2-3
Table 2-1 Housekeeping Requirements
REQ.H#
ANSI/CTA-2045-A Commands
Use Message
Type Name Opcode 1 Opcode 2 Payload
REQ.H1 Link Layer ACK
Type Byte 1 Byte 2 ACK 0x06 0x00
Refer to Section 6.1 in ANSI/CTA-2045-A
Link Layer ACK and NAK messages are used in response to all messages except other link layer ACKs and NAKs
REQ.H2 Link Layer NAK
Type Byte 1 Byte 2 NAK 0x15 NAK Code
Refer to Section 6.1 in ANSI/CTA-2045-A
Link Layer ACK and NAK messages are used in response to all messages except other link layer ACKs and NAKs NAK Codes
Link NAK Error Code Priority Description Usage
0x00 No Reason Not used.
0x01 1 Invalid Byte
Indicates that a byte framing or other invalid byte error has occurred (e.g., missing stop-bit on the AC RS-485 interface).
0x02 2 Invalid Length Used to indicate that the length indicated in the PDU length field is out of range.
0x03 3 Checksum Error The bytes in the checksum field at the end of the message did not agree with the computed checksum.
0x04 4 Reserved NA
0x05 5 Message Timeout
Indicates that more than tML (defined in Error! Reference source not found.) elapsed between receipt of the first byte and receipt of the last byte in a message transmission. tML was selected to allow any combination of data rate and payload. As additional speeds and payloads are added some combinations may be invalid. This error code is not used by the DC Form Factor as noted in Appendix A.
0x06 6 Unsupported Message Type
Indicates that the “Message Type” is not supported.
0x07 7 Request Not Supported
Indicates that the requested setting is not supported (e.g., a requested Power Mode or Bit Rate is not supported). This error code is used only in regards to link layer requests, not in regards to lack of support for application layer requests.
REQ.H3 Link Layer
Message Type
Supported Query
Message Type MS Byte
Message Type LS
Byte Description
0x00 to 0x05 0x00 to 0xFF Reserved for vendor proprietary use
0x06 0x00 to 0xFF Reserved to avoid confusion with link layer ACK
0x07 0x00 to 0xFF For Future Assignment
0x08 0x01 Basic DR Application (at least partially supported by all devices)
0x08 0x02 Intermediate DR Application 0x08 0x03 Data-Link Messages
0x08 0x04 Commissioning and Network Support Messages
0x08 0x05 to 0xFF For Future Assignment 0x09 0x01 USNAP 1.0, Pass-Through 0x09 0x02 ClimateTalk, Pass-Through
0x09 0x03 Smart Energy Profile 1.0, Pass-Through
Message type supported query is mandatory. After power-up, communications modules and end devices shall begin communication assuming only that the mandatory functions of the Basic DR application are supported.
Byte 1 Byte 2
Byte 3 Byte 4 Byte 5 Byte 6
Reserved Payload Length
Desired Message Type 0x00 0x00 Checksum
10435823
2-4
REQ.H#
ANSI/CTA-2045-A Commands
Use Message
Type Name Opcode 1 Opcode 2 Payload
0x09 0x04 Smart Energy Profile 2.0 over IP, Pass-Through
0x09 0x05 OpenADR1.0 over IP, Pass-Through 0x09 0x06 OpenADR2.0 over IP, Pass-Through
0x09 0x07 Generic IP Pass-Through (IP packets self-identify version so both IPV4 and IPV6 are covered)
0x09 0x08 ECHONET Lite Pass-Through 0x09 0x09 KNX Pass-Through 0x09 0x0A LonTalk Pass-Through 0x09 0x0B Sunspec Modbus Pass-Through 0x09 0x0C BACnet Pass-Through 0x09 0x0D to 0xFF For Future Assignment
0x0A to 0x14 0x00 to 0xFF For Future Assignment
0x15 0x00 to 0xFF Reserved to avoid confusion with link layer NAK
0x16 to 0xEF 0x00 to 0xFF For Future Assignment 0xF0 to 0xFF 0x00 to 0xFF Reserved for vendor proprietary use
REQ.H4 Basic Application ACK 0x03
Opcode 1 of last
message received
Any except for 0x03
Acknowledge successful receipt and support of previous command. Verification that the last message was received by responding or receiving a response with Opcode 1 of the previous message
REQ.H5 Basic Application NAK 0x04 Reason
Reason 0x00 = No reason given 0x01 = Opcode1 not supported 0x02 = Opcode2 invalid 0x03 = Busy 0x04 = Length Invalid 0x05 = Customer Override is in effect 0x06 to 0xFF Reserved
If SGD responds with either; 0x00 = No reason given 0x03 = Busy Then retry every 1-min until the duration specified in the Time Interval has timed out. If SGD responds with; 0x05 = Customer Override is in effect Then record in x-CTA2045_STATUS report
REQ.H6 Basic
Outside Comm
Connection Status
0x0E Connect Status Code
Connect Status Code
0x00 = No / Lost Connection 0x01 = Found / Good Connection 0x02 = Poor / Unreliable Connection 0x03 to 0xFF = Reserved
The “Connection” refers to the connection between the communication module and the application it depends on for control. 0x00 = Over the Time Interval, connection could not be established 0x01 = Successful connection 0x02 = Two-thirds of the attempts to connect with the DRMA over the Time Interval fail. 0x03 to 0xFF = Reserved REQ.H3.1, Time Interval = 15-min (non-overlapping)
REQ.H7 Link Layer ACK
Type Byte 1 Byte 2 ACK 0x06 0x00
Refer to Section 6.1 in ANSI/CTA-2045-A
Link Layer ACK and NAK messages are used in response to all messages except other link layer ACKs and NAKs
10435823
2-5
REQ.H#
ANSI/CTA-2045-A Commands
Use Message
Type Name Opcode 1 Opcode 2 Payload
REQ.H8 Link Layer NAK Type Byte 1 Byte 2 NAK 0x15 NAK Code
Refer to Section 6.1 in ANSI/CTA-2045-A
Link Layer ACK and NAK messages are used in response to all messages except other link layer ACKs and NAKs NAK Codes
Link NAK Error Code Priority Description Usage
0x00 No Reason Not used.
0x01 1 Invalid Byte
Indicates that a byte framing or other invalid byte error has occurred (e.g., missing stop-bit on the AC RS-485 interface).
0x02 2 Invalid Length Used to indicate that the length indicated in the PDU length field is out of range.
0x03 3 Checksum Error The bytes in the checksum field at the end of the message did not agree with the computed checksum.
0x04 4 Reserved NA
0x05 5 Message Timeout
Indicates that more than tML (defined in Error! Reference source not found.) elapsed between receipt of the first byte and receipt of the last byte in a message transmission. tML was selected to allow any combination of data rate and payload. As additional speeds and payloads are added some combinations may be invalid. This error code is not used by the DC Form Factor as noted in Appendix A.
0x06 6 Unsupported Message Type
Indicates that the “Message Type” is not supported.
0x07 7 Request Not Supported
Indicates that the requested setting is not supported (e.g., a requested Power Mode or Bit Rate is not supported). This error code is used only in regards to link layer requests, not in regards to lack of support for application layer requests.
REQ.H9 Link Layer
Message Type
Supported Query
Message Type MS Byte
Message Type LS
Byte Description
0x00 to 0x05 0x00 to 0xFF Reserved for vendor proprietary use
0x06 0x00 to 0xFF Reserved to avoid confusion with link layer ACK
0x07 0x00 to 0xFF For Future Assignment
0x08 0x01 Basic DR Application (at least partially supported by all devices)
0x08 0x02 Intermediate DR Application 0x08 0x03 Data-Link Messages
0x08 0x04 Commissioning and Network Support Messages
0x08 0x05 to 0xFF For Future Assignment 0x09 0x01 USNAP 1.0, Pass-Through 0x09 0x02 ClimateTalk, Pass-Through
0x09 0x03 Smart Energy Profile 1.0, Pass-Through
0x09 0x04 Smart Energy Profile 2.0 over IP, Pass-Through
0x09 0x05 OpenADR1.0 over IP, Pass-Through 0x09 0x06 OpenADR2.0 over IP, Pass-Through
0x09 0x07 Generic IP Pass-Through (IP packets self-identify version so both IPV4 and IPV6 are covered)
0x09 0x08 ECHONET Lite Pass-Through 0x09 0x09 KNX Pass-Through 0x09 0x0A LonTalk Pass-Through 0x09 0x0B Sunspec Modbus Pass-Through 0x09 0x0C BACnet Pass-Through 0x09 0x0D to 0xFF For Future Assignment
0x0A to 0x14 0x00 to 0xFF For Future Assignment
Support of the message type supported query is mandatory. After power-up, communications modules and end devices shall begin communication assuming only that the mandatory functions of the Basic DR application are supported.
Byte 1 Byte 2 Byte 3 Byte 4
Byte 5 Byte 6 Reserved Payload Length
Desired Message Type 0x00 0x00 Checksum
10435823
2-6
REQ.H#
ANSI/CTA-2045-A Commands
Use Message
Type Name Opcode 1 Opcode 2 Payload
0x15 0x00 to 0xFF Reserved to avoid confusion with link layer NAK
0x16 to 0xEF 0x00 to 0xFF For Future Assignment 0xF0 to 0xFF 0x00 to 0xFF Reserved for vendor proprietary use
REQ. H10 Basic Pending
Event Time 0x18 Time Until Event
Used to inform the resource (and possibly the user) that a Grid Service event will occur in
the near future.
Time Until Event See Section 8.1.2 for format
For all events that are within 4-hours from their start time, the UCM shall inform the resource of the remaining time at intervals of 15-min.
REQ. H11 Basic Pending
Event Type 0x19 Opcode 1 of the Pending
Event
Applies to Basic commands
Opcode2 set to 0x02 (End Shed/Run Normal) informs the resource that the pending event
has been canceled,
For all events that are within 4-hours from their start time, the UCM shall inform the resource of the Basic command that’s mapped to the upcoming EiEvent signals.
10435823
2-7
2.2 Load Management Functions (Normative) The purpose of this section is to define the relationship between the application-layer messages of OpenADR 2.0 and ANSI/CTA-2045-A and how to exchange information between the two protocols. The messages included in this section are those targeted at influencing the behavior of different types of ANSI/CTA-2045-A loads (see Section 4.0).
10435823
2-8
Table 2-2 Load Management Mapping Requirements
REQ.LM# OpenADR 2.0 EiEvent Signal ANSI/CTA-2045-A Message
Use Signal Name Signal Type Value Units Duration Message
Type Name Opcode 1 Opcode 2
REQ.LM1 Simple Level 0 None Any Basic
End Shed/Run
Normal
0x02 Event Duration At start of the event, the same Duration provided
in the EiEvent must be sent to the SGD. If the UCM sends subsequent curtailment requests to the resource during the active period of the OpenADR 2.0 event, the Duration sent to the resource must be the actual time remaining in the event and not the original Duration included in the original OpenADR 2.0 signal.
REQ.LM2 Simple Level 1 None Any Basic Shed 0x01 Event Duration
REQ.LM3 Simple Level 2 None Any Basic Critical Peak Event 0x0A Event
Duration
REQ.LM4 Simple Level 3 None Any Basic Grid
Emergency
0xB Event Duration
REQ.LM5 Custom x-CTA-2045 0 None Any Basic
End Shed/Run
Normal
0x02 Not Used
The custom signals are similar to that of the SIMPLE LEVEL, except there are (5) five choices (0-4) instead of (4) four. For this custom signal, the “load up” request is assigned to the value of 4..
REQ.LM6 Custom x-CTA-2045 1 None Any Basic Shed 0x01 Event Duration
REQ.LM7 Custom x-CTA-2045 2 None Any Basic Critical Peak Event 0x0A Event
Duration
REQ.LM8 Custom x-CTA-2045 3 None Any Basic Grid
Emergency
0xB Event Duration
REQ.LM9 Custom x-CTA-2045 4 None Any Basic Load Up 0x17 Event Duration
REQ.LM10 ELECTRICITY_PR
ICE pricemultiplier any None Any Basic Present
Relative Price 0x07 Relative
Price Indicator
ANSI/CTA-2045-A use of Relative Price: Relative price = Relative_Price_Indicator = Present_Price / Average_Price. See standard for details on Average Price.
REQ.LM11 LOAD_DISPATC
H level -10 to
10 powerXXX Any Basic Request for Power Level 0x06
Percent Setting
MSbit = 0 =
Power Absorbed
Percent setting 0x00 to 0x7F = 0 to 100% = LOAD_DISPATCH,level(value must be between 0 to -10) At the conclusion of the LOAD_DISPATCH event, the UCM must send the SGD an End Shed/Run Normal Opcode 1 (0x02)
10435823
2-9
REQ.LM# OpenADR 2.0 EiEvent Signal ANSI/CTA-2045-A Message
Use Signal Name Signal Type Value Units Duration Message
Type Name Opcode 1 Opcode 2
REQ.LM12 LOAD_CONTROL
x-LoadControlL
evelOffset
Integer None Any Intermediate
Set Temperature
Offset 0x03 0x02
Payload
Byte Description Map to OpenADR 2.0 Signal
1 Opcode1
2 Opcode2
3 Current Offset Value
4 Units See Note1 Note1: OpenADR 2.0 does not require that the LoadControlOffset signal be used solely for temperature offset.
REQ.LM13 LOAD_CONTROL
x-LoadControlS
etpoint any None Any Intermediate Set Setpoint 0x03 0x02
LOAD_CONTROL x-LoadControlSetpoint = SetSetpoint(Set Point 1)
Payload Byte
Payload
Map to OpenADR 2.0
Signal
1 Opcode1
2 Opcode2
S Device Type** See Note1
5 Units Unit
6-7 Set Point 1 Value
8-9 Set Point 2 Note1: This command requires the Device Type of the DER to be included in the payload. Device type must be known or acquired by Get Information command.
REQ.LM14 ELECTRICITY_PR
ICE price any currency/k
Wh Any Intermediate Set Energy Price 0x03 0x00
Payload Byte
Payload
Map to OpenADR 2.0 Signal
1 Opcode1
2 Opcode2
10435823
2-10
REQ.LM# OpenADR 2.0 EiEvent Signal ANSI/CTA-2045-A Message
Use Signal Name Signal Type Value Units Duration Message
Type Name Opcode 1 Opcode 2
3-6 Current Price Value
7-8 Currency Code Unit
9 Digits After Decimal Point
Note 1
10-13 Expiration Time/Date in UTC seconds
14-117 Next Price Note 1: Since OpenADR does not specify the number of digits after the decimal points, this will need to be determined before this message can be sent.
10435823
2-11
2.3 Monitoring and Reporting Functions (Normative) This section includes requirements for transferring operational state type information from the device and making it available to an OpenADR 2.0B server through an OpenADR 2.0b client. OpenADR 2.0B. The information included in this section align with the commands defined in the “monitoring/feedback” sections of each of the functional specification documents, see Section 4.0. Table 2-3 includes the ANSI/CTA-2045-A command and information that could be obtained from the BTM load and how to package the information into a report for the OpenADR 2.0B client to make available to an OpenADR 2.0 server.
10435823
2-12
Table 2-3 Measurement and Reporting Mapping Requirements
REQ.M#
ANSI/CTA-2045-A Commands
OpenADR 2.0b EiReport Service Message
Type Name Opcode 1 Opcode 2 Payload
REQ.M1 Basic
Operational State
Query and Response
0x12 0x00 Not User N/A
0x13 Operational state
code
Op
State Code
Name
0 Idle Normal 1 Running Normal 2 Running Curtailed 3 Running Heightened 4 Idle Curtailed 5 SGD Error Condition 6 Idle Heightened 7 Cycling On 8 Cycling Off 9 Variable Following
10 Variable Not Following 11 Idle, Opted Out 12 Running, Opted Out
13-125 Not Used 126-255 Reserved
OpenADR 2.0b EiReport Service
REQ Report Name x-CTA2045_Status
M1.1
Report Structure Status Interval rID OperationalState
1-min Report Type Reading Reading Type Direct Read Units customUnit
ANSI/CTA-2045-A Message Message Operational State Query Response Element Mapped to rID Opcode 2 of Basic 0x13
REQ.M2 Intermediate Info Request 0x01
Request 0x01
Respons
e 0x81
Payload Byte
Description
1 Opcode1
2 Opcode2 (Reply always has bit 7 high)
3 Response Code
4-5 CTA-2045 Version – ASCII*
6-7 Vendor ID
8-9 Device Type
OpenADR 2.0b EiReport Service
REQ Report Name x-CTA2045_Metadata
R2.1
Report Structure Value rID CTA-2045_Version* Report Type Reading Reading Type Direct Read Units customUnit
ANSI/CTA-2045-A Message Message Info Request
Element Mapped to rID Response 0x01,0x81, Payload Byte 4-5
10435823
2-13
REQ.M#
ANSI/CTA-2045-A Commands
OpenADR 2.0b EiReport Service Message
Type Name Opcode 1 Opcode 2 Payload
10-11 Device Revision
12-15 Capability Bitmap
16 Reserved
17-32 Model Number – ASCII
33-48 Serial Number – ASCII
49 Firmware Year – 20YY
50 Firmware Month
51 Firmware Day
52 Firmware Major
53 Firmware Minor
Capability Bitmap Matric Bit (2n) Description
0 Cycling supported 1 Tier mode supported 2 Price mode supported
3 Temperature Offset supported
4 Continuously variable power
5 Discreetly variable power 6-31 Reserved
See section 9.1.1 Info Request for device types.
OpenADR 2.0b EiReport Service REQ Report Name x-CTA2045_Metadata
M2.2
Report Structure Value rID Vendor_ID Report Type Reading Reading Type Direct Read Units customUnit
ANSI/CTA-2045-A Message Intermediate Message Info Request
Element mapped to rID Response 0x01,0x81, Payload Byte 6-7
OpenADR 2.0b EiReport Service
REQ Report Name x-CTA2045_Metadata
M2.3
Report Structure Value rID Device_Type Report Type Reading Reading Type Direct Read Units customUnit
ANSI/CTA-2045-A Message Intermediate Message Info Request
Element mapped to rID Response 0x01,0x81, Payload Byte 8-9
OpenADR 2.0b EiReport Service
REQ Report Name x-CTA2045_Metadata
M2.4
Report Structure Value rID Device_Revision Report Type Reading Reading Type Direct Read Units customUnit
ANSI/CTA-2045-A Message Intermediate Message Info Request
Element mapped to rID Response 0x01,0x81, Payload Byte 10-11
OpenADR 2.0b EiReport Service
REQ Report Name x-CTA2045_Metadata
M2.5 Report Structure Value rID Capability_Bitmap Report Type Reading
10435823
2-14
REQ.M#
ANSI/CTA-2045-A Commands
OpenADR 2.0b EiReport Service Message
Type Name Opcode 1 Opcode 2 Payload
Reading Type Direct Read Units customUnit
ANSI/CTA-2045-A Message Intermediate Message Info Request
Element mapped to rID Response 0x01,0x81, Payload Byte 12-15
OpenADR 2.0b EiReport Service
REQ Report Name x-CTA2045_Metadata
M2.6
Report Structure Value rID Model_Number-ASCII Report Type Reading Reading Type Direct Read Unitsz customUnit
ANSI/CTA-2045-A Message Intermediate Message Info Request
Element mapped to rID Response 0x01,0x81, Payload Byte 17-32
OpenADR 2.0b EiReport Service
REQ Report Name x-CTA2045_Metadata
M2.7
Report Structure Value rID Serial_Number– ASCII Report Type Reading Reading Type Direct Read Units customUnit
ANSI/CTA-2045-A Message Intermediate Message Info Request
Element mapped to rID Response 0x01,0x81, Payload Byte 33-48
OpenADR 2.0b EiReport Service
REQ Report Name x-CTA2045_Metadata
M2.8
Report Structure Value rID Firmware_Year_20YY Report Type Reading Reading Type Direct Read Units customUnit
ANSI/CTA-2045-A Message Intermediate Message Info Request
10435823
2-15
REQ.M#
ANSI/CTA-2045-A Commands
OpenADR 2.0b EiReport Service Message
Type Name Opcode 1 Opcode 2 Payload
Element mapped to rID Response 0x01,0x81, Payload Byte 49
OpenADR 2.0b EiReport Service
REQ Report Name x-CTA2045_Metadata
M2.9
Report Structure Value rID Firmware_Month Report Type Reading Reading Type Direct Read Units customUnit
ANSI/CTA-2045-A Message Intermediate Message Info Request
Element mapped to rID Response 0x01,0x81, Payload Byte 50
OpenADR 2.0b EiReport Service
REQ Report Name x-CTA2045_Metadata
M2.10
Report Structure Value rID Firmware_Day Report Type Reading Reading Type Direct Read Units customUnit
ANSI/CTA-2045-A Message Intermediate Message Info Request
Element mapped to rID Response 0x01,0x81, Payload Byte 51
OpenADR 2.0 EiReport Service
REQ Report Name x-CTA2045_Metadata
M2.11
Report Structure Value rID Firmware_Major Report Type Reading Reading Type Direct Read Units customUnit
ANSI/CTA-2045-A Message Intermediate Message Info Request
Element mapped to rID Response 0x01,0x81, Payload Byte 52
10435823
2-16
REQ.M#
ANSI/CTA-2045-A Commands
OpenADR 2.0b EiReport Service Message
Type Name Opcode 1 Opcode 2 Payload
REQ.M3 Basic Customer Override 0x11 0x00 or
0x01
0 = No Override, 1 = Override
OpenADR 2.0b EiReport Service
REQ Report Name x-CTA2045_Status
M3.1
Report Structure Status Interval rID OverrideStatus
1-min Report Type Reading Reading Type Direct Read Units customUnit
ANSI/CTA-2045-A Message Message Customer Override Element Mapped to rID Opcode 2 of Basic 0x11
The mapping application shall record the Customer Override state of the DER and send to the OpenADR 2.0b VTN via the VEN’s EiReport Service Depending on the ANSI/CTA-2045 version implemented by the DER, the override status could be provided by two other messages. Operational State Response (Code 11 and 12) NAK (Reason 0x05 = Customer Override is in effect)
REQ.M4 Intermediate
GetTemperatureOffset Request and Reply
0x03
0x02
Reply 0x82
DER Reply
Payload Byte Comments
1 Opcode1
2 Opcode2 (Reply always has bit 7 high)
3 Response Code
4 Current Offset
5 Units
OpenADR 2.0b EiReport Service REQ Report Name x-CTA2045_Status
M4.1
Report Structure Status Interval rID TemperatureOffset
1-min Report Type Reading Reading Type Direct Read Units customUnit
ANSI/CTA-2045-A Message Message Get Temperature Offset Element Mapped to rID Reply 0x03,0x82 Byte 4
OpenADR 2.0b EiReport Service REQ Report Name x-CTA2045_Status
M4.2
Report Structure Status Interval
rID TemperatureOffsetUnits 1-min Report Type Reading
Reading Type Direct Read
10435823
2-17
REQ.M#
ANSI/CTA-2045-A Commands
OpenADR 2.0b EiReport Service Message
Type Name Opcode 1 Opcode 2 Payload
Units customUnit ANSI/CTA-2045-A Message
Message Get Temperature Offset Element Mapped to rID Reply 0x03,0x82 Byte 5
The UCM shall record the Temperature Offset of the DER and send to the OpenADR 2.0 VTN via the VEN’s EiReport Service
REQ.M5 Intermediate GetSetPoint 0x03
0x03
Reply 0x83
Payload
Byte Comments
1 Opcode1
2 Opcode2 (Reply always has bit 7 high)
3 Response Code
4-5 Device Type
6 Units
7-8 Set Point 1
9-10 Set Point 2
OpenADR 2.0b EiReport Service
REQ Report Name x-CTA2045_Status
R.5.1
Report Structure Status Interval rID SetPointDeviceType
1-min Report Type Reading Reading Type Direct Read Units customUnit
ANSI/CTA-2945-A Message Message Get Set Point (Get Reply) Element Mapped to rID Reply 0x03,0x83 Byte 4-5
OpenADR 2.0b EiReport Service
REQ Report Name x-CTA2045_Status
M5.2
Report Structure Status Interval rID SetPointUnits
1-min Report Type Reading Reading Type Direct Read Units customUnit
ANSI/CTA-2945-A Message Message Get Set Point (Get Reply) Element Mapped to rID Reply 0x03,0x83 Byte 6
OpenADR 2.0b EiReport Service REQ Report Name x-CTA2045_Status
M5.3
Report Structure Status Interval rID SetPoint1
1-min Report Type Reading Reading Type Direct Read Units customUnit
ANSI/CTA-2945-A Message
10435823
2-18
REQ.M#
ANSI/CTA-2045-A Commands
OpenADR 2.0b EiReport Service Message
Type Name Opcode 1 Opcode 2 Payload
Message Get Set Point (Get Reply) Element Mapped to rID Reply 0x03,0x83 Byte 7-8
OpenADR 2.0b EiReport Service
RFQ Report Name x-CTA2045_Status
M5.4
Report Structure Status Interval rID SetPoint2
1-min Report Type Reading Reading Type Direct Read Units customUnit
ANSI/CTA-2945-A Message Message Get Set Point (Get Reply) Element Mapped to rID Reply 0x03,0x83 Byte 9-10
The UCM shall Get the Set Point and other data provided in the reply payload from of the DER and send to the OpenADR 2.0b VTN via the Report Name specified in the tables above using the EiReport Service
REQ.M6 Intermediate GetPresentTemperature
0x03
0x04
Reply 0x84
Payload
Byte
Comments 1 Opcode1
2 Opcode2 (Reply always has bit 7 high)
3 Response Code
4-5 Device Type
6 Units
7-8 Present Temperature
OpenADR 2.0b EiReport Service
REQ Report Name x-CTA2045_Status
M6.1
Report Structure Status Interval
rID PresentTempDeviceType
1-min Report Type Reading Reading Type Direct Read Units customUnit
ANSI/CTA-2945-A Message Message Reply to Get Present Temperature Element Mapped to rID Reply 0x03,0x84 Byte 4-5
OpenADR 2.0b EiReport Service
REQ Report Name x-CTA2045_Status
M6.2
Report Structure Status Interval rID PresentTempUnits
1-min Report Type Reading Reading Type Direct Read Units customUnit
ANSI/CTA-2945-A Message Message Reply to Get Present Temperature Element Mapped to rID Reply 0x03,0x84 Byte 6
10435823
2-19
REQ.M#
ANSI/CTA-2045-A Commands
OpenADR 2.0b EiReport Service Message
Type Name Opcode 1 Opcode 2 Payload
OpenADR 2.0b EiReport Service
REQ Report Name x-CTA2045_Status
M6.3
Report Structure Status Interval rID PresentTemp
1-min Report Type Reading Reading Type Direct Read Units customUnit
ANSI/CTA-2945-A Message Message Reply to Get Present Temperature Element Mapped to rID Reply 0x03,0x84 Byte 7-8
The UCM shall Get the Present Temperature and other data provided in the reply payload from of the DER and send to the OpenADR 2.0b VTN via the Report Name specified in the tables above using the EiReport Service
REQ M7 Intermediate Commodity Read 0x06
Request 0x00
Reply 0x80
Request
Commodity Codes
*Lower 7-bits
Description Units
0 Electricity Consumed
W & W-hr
1 Electricity Produced
W & W-hr
2 Natural gas cu-ft/hr & cu-ft 3 Water Gal/hr & Gallons 4 Natural gas cubic meters/hour (m3)
& cubic meters (m3) 5 Water liters/hr & liters 6 Total
Energy Storage/Take Capacity
W-hr Note: Instantaneous field in CommodityRead is not used.
Payload Byte
Comments
1 Opcode1
2 Opcode2
3 Requested Commodity Code
OpenADR 2.0b EiReport Service
REQ Report Name x-CTA2045_Status
M7.1
Report Structure Status Interval rID DataSource
1-min Report Type Reading Reading Type Direct Read Units customUnit
ANSI/CTA-2945-A Message
Message Get Commodity (0x06,0x00 Byte 3) = Any
Element Mapped to rID
If Reply (0x06,0x80 Byte 4) = 0x0X Then DataSource = 1 = Measured If Reply (0x06,0x80 Byte 4) = 0x8X Then DataSource = 2 = Estimated Where X = any Commodity Codes
The above data point is designed to record the origin of the commodity value provided by the DER. 1, Measured, (Instrumentation is used to derive commodity values) 0, Estimated, (Calculated based on Operating States or other data, Instrumentation is NOT used to derive commodity values)
10435823
2-20
REQ.M#
ANSI/CTA-2045-A Commands
OpenADR 2.0b EiReport Service Message
Type Name Opcode 1 Opcode 2 Payload
(see Figure 1)
7 Present Energy Storage/Take Capacity
W-hr Note: Instantaneous field in CommodityRead is not used.
8 Rated Max Consumption Level Electricity
W Note: Cumulative field in CommodityRead is not used.
9 Rated Max Production Level Electricity
W Note: Cumulative field in CommodityRead is not used.
10-127 Reserved *MSBit MSBit = 1, Measured, (Instrumentation is used to derive commodity values) MSBit = 0, Estimated, (Calculated based on Operating States or other data, Instrumentation is NOT used to derive commodity values) Get Commodity Reply
Payload Byte
Comments
1 Opcode1
2 Opcode2 (Response has 1st bit
set)
3 Response Code
4 Commodity Code
5-10 Instantaneous Rate
11-16 Cumulative Amount
OpenADR 2.0b EiReport Service
Point Report Name x-CTA2045_Status
M7.2
Report Structure Status Interval rID ElectricPowerUsage
1-min Report Type Reading Reading Type Direct Read Units Watts
ANSI/CTA-2945-A Message
Message Get Commodity 0x06,0x00 (Byte 3 = 0x00)
Element Mapped to rID Reply 0x06,0x80 Bytes 5-10
OpenADR 2.0b EiReport Service REQ Report Name x-CTA2045_Status
M7.3
Report Structure Status Interval rID ElectricPowerUsage
1-min Report Type Reading Reading Type Direct Read Units Watts
ANSI/CTA-2945-A Message
Message Get Commodity 0x06,0x00 (Byte 3 = 0x00)
Element Mapped to rID Get Commodity Reply 0x06,0x80, Bytes 11-16
Note: The cumulative number provided by the DER could be reset to 0 at any time.
OpenADR 2.0b EiReport Service REQ Report Name x-CTA2045_Status
M7.4
Report Structure Status Interval rID TotalEnergyCapacity
1-min Report Type Reading Reading Type Direct Read Units W-h
ANSI/CTA-2945-A Message
Message Get Commodity 0x06,0x00 (Byte 3 = 0x06)
10435823
2-21
REQ.M#
ANSI/CTA-2045-A Commands
OpenADR 2.0b EiReport Service Message
Type Name Opcode 1 Opcode 2 Payload
Element Mapped to rID Get Commodity, Reply 0x06,0x80 Bytes 11-16
OpenADR 2.0b EiReport Service REQ Report Name x-CTA2045_Status
M7.5
Report Structure Status Interval
rID PresentEnergyCapacity
1-min Report Type Reading Reading Type Direct Read Units W-h
ANSI/CTA-2945-A Message
Message Get Commodity 0x06,0x00 (Byte 3 = 0x07)
Element Mapped to rID Get Commodity, Reply 0x06,0x80 Bytes 11-16
10435823
10435823
3-1
3 GROUPING / TARGETING BEHIND-THE-METER RESOURCES The purpose of this section is to establish a common method for targeting groups or individual BTM resources that reside behind a common client. In OpenADR 2.0, dispatch signal information (i.e. dispatch instructions) are communicated through the EiEvent service. A component of the dispatch signal are messages that are intended to be used to target individual or groups of resources. An excerpt from Section 8.2.1 of the OpenADR 2.0B 2015 OpenADR Alliance specification, included below, provides some insight into how these messages are intended to be used.
Section 8.2.1 Event Targets and Resources (OpenADR 2.0, 2015) While the A Profile supported event targets (EiTarget), the B Profile includes several more target types, and also allows device class targeting to be applied at the signal level.
A VEN is a communication endpoint that represents one or more logical resources (individual shedable loads, endpoint equipment, meters, etc.).
Event targets select which specific VEN resources the event applies to. If an event target is not specified, the VEN should assume that it applies to all of its resources. How resources are assigned properties (location, pnode associations, resourceIDs, groupIDs, etc.) is outside the scope of the specification and is up to deployment configurations in the VTN and VEN. However, if a VEN receives an event target that it is not configured for, it should reject the message with the appropriate error code described in section 8.7. [emphasis added]
This excerpt was included to highlight the last two sentences, which state that the application of these targets is beyond the scope of the OpenADR 2.0b specification. To provide some guidance on the use of Targets in different DR programs, the OpenADR Alliance published the OpenADR 2.0 Demand Response Program Implementation Guide, Revision 1.1, Document Number 20140701. The purpose of this document is to provide guidance to those implementing DR programs that utilize OpenADR 2.0 to dispatch resources. With regards to event targeting, the above referenced guide includes informative examples of how different DR programs use event targeting. Included in Table 3-1 is a summary of how targets could be used to support the requirements of different programs. It’s important to note that the guide does not specify how resources must be targeted within a specific program. Instead, it only provides guidance on how they could be targeted.
10435823
3-2
Table 3-1 Uses of Targeting in the OpenADR 2.0 Demand Response Program Implementation Guide, Revision 1.1, Document Number 20140701. (Informative)
Program Type Target Loads Event Targets
Critical Peak Pricing Program (CPP) Any venID or resourceIDs (Typical)
Capacity Bidding Any venID or resourceID representative of the aggregated load associated with a VEN
Thermostat HVAC resourceIDs or venID with event signal device class target set to Thermostat
Fast DR Dispatch Those which can respond to real-time dispatches
venID or a resourceID representative of the aggregated load associated with a VEN
Residential EV TOU Programs EV Chargers
No advanced targeting required but targeting can be used to send prices to specific transformers, feeders, or geographic areas.
Public Station Electric Vehicle (EV) Real-Time Pricing Program
Public EV Chargers No advanced targeting required but targeting can be used to send prices to specific transformers, feeders, or geographic areas.
Distributed Energy Resources (DER) Any venID. No other advanced targeting required
The Universal Smart Energy Framework (USEF) Incentive-based
HVAC, Industrial loads venID or resourceIDs (Typical)
The Universal Smart Energy Framework (USEF) Transaction based Program
Any venID or a resourceID representative of the aggregated load associated with a VEN
The Universal Smart Energy Framework (USEF) Override based Program
Those which can respond to real-time dispatches
venID or a resourceID representative of the aggregated load associated with a VEN
3.1 Targeting Requirements (Normative) The purpose of this section is to define a standardized set of rules for targeting BTM resources in systems with architectures similar to those shown in Figure 1-2 and Figure 1-3. The reason for defining these rules is to improve the interchangeability between the components of one system and the components of another system. The groups listed in Table 3-2 are some of the mechanisms that the OpenADR 2.0 supports to facilitate the targeted distribution of dispatches.
10435823
3-3
Table 3-2 Five grouping levels supported by and defined in OpenADR 2.0a and 2.0b
Group XML Element Definition Intended use
MarketContext eventDescriptorType Identifies a particular program or application defined grouping that pertains to an event.
Used to send an event to a group of VENs with the same MarketContext.
ei:venID eiTarget:eiTargetType
A VEN is a communication endpoint that represents one or more logical resources (individual shedable loads, endpoint equipment, meters, etc.). venID must be a unique number.
Used to send an event to a specific VEN
ei:partyID eiTarget:eiTargetType No definition Undefined
ei:groupID eiTarget:eiTargetType No definition Undefined
ei:resourceID eiTarget:eiTargetType Unique ID assigned to a single logical resource- (individual shedable loads, endpoint equipment, meters, etc.).
Used to send an event to an individual DER
OpenADR 2.0 defines rules for how clients accept or reject dispatches based on MarketContext and eiTarget. Besides the venID and resourceID, the protocol does not include rules or provide guidance on what the other eiTargets (such as partyID and groupID) should be used to represent. If eiTargets (besides venID and resourceID) are used in deployments without rules or guidelines that govern their use, each deployment could be unique. This means that a client that interoperates within one deployment is not likely to interoperate in other deployments, even if that client has been certified. To reduce variability between deployments, rules that define the use of partyID and groupID, along with logic for how VENs use targets to determine if events should be accepted (i.e. logic), are included in Table 3-3.
10435823
3-4
Table 3-3 Target Level Filtering
REQ.T# Target Level Group Use Target Filtering Logic (VEN Application)5
REQ.T1 1 MarketContext Unique name of a DER program
If eventDescriptorType:MarketContext and the MarketContext of the VEN match, then process event
REQ.T2 2 ei:venID Unique ID assigned to a VEN
If eventDescriptorType:MarketContext and the MarketContext of the VEN match,
AND If eiTarget:ei:venID and ei:venID of the VEN match, then process event
REQ.T3 3 ei:partyID
Electric network location (Substation / Transformer)
If eventDescriptorType:MarketContext and the MarketContext of the VEN match,
AND
If eiTarget:ei:venID and ei:venID of the VEN match,
AND If eiTarget:ei:PartyID and the eiTarget:ei:PartyID of the VEN match, then process event
REQ.T4 4 ei:groupID
Device Type (see Table 3-4 for groupID definitions)
If eventDescriptorType:MarketContext and the MarketContext of the VEN match,
AND If eiTarget:ei:venID and ei:venID of the VEN match,
AND If eiTarget:ei:PartyID and the eiTarget:ei:PartyID of the VEN match, then process event
AND If eiTarget:ei:groupID and the eiTarget:ei:groupID of the VEN match, then process event
REQ.T5 5 ei:resourceID
Unique ID assigned to a single logical resource
If eventDescriptorType:MarketContext and the MarketContext of the VEN match,
AND If eiTarget:ei:resourceID and ei:resourceID of the VEN match, then process event
5 The filtering logic for level 1,2 and 5 are defined in the OpenADR 2.0 specification.
10435823
3-5
3.1.1 ResourceID Format (Normative) The resourceID must be in the following format:
resourceID = partyID:groupID:UniqueIDassignedtoresource
A graphical representation of the targeting filter logic is illustrated in Figure 3-1. For example, to targeted resources at a specific location, the EiEvent must include the MarketContext, vanID, partyID.
MarketContext
venID
partyID
groupID
resourceID
Program
VEN
Location
Device Type
DER
Level 1
Level 2
Level 3
Level 4
Level 5
Figure 3-1 Use of groups and their assigned level of filtering
The Info Request message of the ANSI/CTA-2045-A standard includes a list of Device Types that must be included in the payload in response to a GetInfo query. This message enables the ANSI/CTA-2045-A communication module application to obtain the device type directly from the end-use device. Once obtained, the OpenADR 2.0 client shall use as the groupID. This mapping between GetInfo Device Type and groupID demonstrates how OpenADR 2.0 and ANSI/CTA-2045-A complement one another. The Device Types that must be used for groupID are listed in Table 3-4.
3.1.2 GroupID Format (Normative) The groupID must include one of the device types listed in Table 3-4.
GetInfo Response (Device Type) = eiTarget:groupID.
Table 3-4 Resource Device Types for eiTarget:groupID
eiTarget:groupID ANSI/CTA-2045-A Get/Set Info Request (Device Types)
Device Type (String) Device Type (HEX) Unspecified_Type 0x0000
Water_Heater_Gas 0x0001 Water_Heater_Electric 0x0002
Water_Heater_Heat_Pump 0x0003 Central_AC_Heat_Pump 0x0004
Central_AC_Fossil_Fuel_Heat 0x0005 Central_AC-Resistance_Heat 0x0006
Central_AC_(only) 0x0007
10435823
3-6
eiTarget:groupID ANSI/CTA-2045-A Get/Set Info Request (Device Types)
Device Type (String) Device Type (HEX) Evaporative_Cooler 0x0008
Baseboard_Electric_Heat 0x0009 Window_AC 0x000A
Portable_Electric_Heater 0x000B Clothes_Washer 0x000C
Clothes_Dryer_Gas 0x000D Clothes_Dryer_Electric 0x000E
Refrigerator/Freezer 0x000F Freezer 0x0010
Dishwasher 0x0011 Microwave Oven 0x0012
Oven_Electric 0x0013 Oven_Gas 0x0014
Cook_Top_Electric 0x0015 Cook_Top_Gas 0x0016 Stove_Electric 0x0017
Stove_Gas 0x0018 Dehumidifier 0x0019
Central_AC_Heat_Pump_Variable_Capacity
0x001A
Fan 0x0020 Pool_Pump_Single_Speed 0x0030
Pool_Pump_Variable_Speed 0x0031 Electric_Hot_Tub 0x0032 Irrigation_Pump 0x0040
Clothes_Dryer_Heat_Pump 0x0041 Electric_Vehicle 0x1000 Hybrid_Vehicle 0x1001
Electric_Vehicle_Supply_Equipment_general(SAE_J1772)
0x1100
Electric_Vehicle_Supply_Equipment_Level_1(SAE_J1772)
0x1101
Electric_Vehicle_Supply_Equipment_Level_2(SAE J1772)
0x1102
Electric_Vehicle_Supply_Equipment_Level_3(SAE J1772)
0x1103
In_Premises_Display 0x2000 Energy_Manager 0x5000 Gateway_Device 0x6000
Distributed_Energy_Resources 0x7000 Solar_Inverter 0x7001
Battery_Storage 0x7002 x-(user_defined) 0x8000 – 0xFFFF
3.2 Example Targeting Application (Informative) The architectural diagram in Figure 2-1 is provided as an example application of the targeting requirements. In this example, the Operator targets all resources classified as Device Type A and connected to Substation X. Upon the receipt of the dispatch signal, the OpenADR 2.0 client would filter the eiTarget field and determine which resources are being targeted. After the
10435823
3-7
resources have been identified, the information would be passed to the subroutine that maps the converts the information into ANSI/CTA-2045-A commands and used to manage resources to automatically provide the requested grid service.
DER Resource1
Grid Service
CTA-2045 UCM
DER Resource2
Grid Service
CTA-2045 UCM
DER Resource3
Grid Service
CTA-2045 UCM
DER
Resource4
Grid Service
CTA-2045 UCM
DER Resource5
Grid Service
CTA-2045 UCM
DER Resource6
Grid Service
CTA-2045 UCM
DER Resource7
Grid Service
CTA-2045 UCM
DER Resource8
Grid Service
CTA-2045 UCM
DER Resource9
Grid Service
CTA-2045 UCM
Operator
Interface Legend= CTA-2045= H2M Interface
= OpenADR 2.0
OpenADR 2.0 Virtual Top Node
OpenADR 2.0 Virtual End Node
MarketContext: DER1Substation: X
Device Type: AResource: 1
MarketContext: DER2Substation: X Device
Type: BResource: 5
MarketContext: DER1Substation: X
Device Type: BResource: 2
MarketContext: DER1Substation: Y
Device Type: ASesource: 6
MarketContext: DER2Substation: X
Device Type: AResource: 3
MarketContext: DER2Substation: X Device
Type: BResource: 7
MarketContext: DER1Substation: Y
Device Type: AResource: 4
MarketContext: DER2Substation: X
Device Type: BResource: 9
MarketContext: DER1Substation: X
Device Type: AResource: 8
MarketContext: DER1MarketContext: DER2venID: 1a2b3c4resourceID: X.A.1resourceID: X.B.2resourceID: X.A.3resourceID: Y.A.4resourceID: X.B.5resourceID: Y.A.6resourceID: X.B.7resourceID: X.A.8resourceID: X.B.9
= Not Specified
MarketContext: DER1venID: 1a2b3c4
partyID(Location): XgroupID(Device Type): A
EiEvent VEN Configuration
Figure 3-2 Example Use of Targeting Requirements
10435823
10435823
4-1
4 FUNCTIONAL REQUIREMENTS FOR ANSI/CTA-2045 RESOURCES (INFORMATIVE) The tables in this section are included to show the relationship between load management functions of different types of resources and how ANSI/CTA-2045 is used to access these functions. For the full set of requirements, references are included in the captions of each table.
10435823
4-2
Domestic Water Heaters Table 4-1 Demand Response-Ready Domestic Water Heater Specification: Preliminary Requirements for CEA-2045 Field Demonstration. EPRI, Palo Alto, CA: 2014. 3002002710
ANSI/CTA-2045 Messages Domestic Water Heater Functional Responses
Link Layer Link ACK, NAK, Max Payload Length Query/Response and Message Type Supported
*Shed Moderately reduce energy usage while maintaining customer comfort at a level determined by the OEM. OEM determines the level of comfort on the estimated average frequency of this request (Estimated AVG Frequency = 1/day)
End Shed/Run Normal Return to normal operation
*Critical Peak Event
Aggressively reduce energy usage while maintaining customer comfort at a level determined by the OEM. OEM determines the level of comfort on the estimated average frequency of this request (Estimated AVG Frequency = 20/year)
*Grid Emergency Immediately stop using energy and do not use energy for the duration of this event (If the duration of the event is longer than 1-hr, energy can be added to maintain a minimum customer comfort level, as determined by the OEM)
Outside Comm Connection Status
If a curtailment event is active and this message is not communicated, unit will return to normal operating mode
Customer Override
Device is required to have a local interface by which the user can override curtailment events. The Customer Override message is used to report the override state of the device. If override occurs when any curtailment event is in effect, ignore all curtailment requests for the next 4-hours. If override occurs when an event is not in effect, ignore all curtailment requests for the next 24-hours.
Operational state Query and Response
Operational states: Idle, Running, Idle Grid, Running Grid, Heightened Grid and Fault
*Load Up Unit will go to max set point (as determined by the user)
Get/Set Info Request Vendor ID, Device Type, Model #, SN and Firmware revision
Get/Set Temperature Offset
Not supported
Get/Set Set Point Not supported
Get/Set Commodity Read
Instantaneous power (W), cumulative energy (W-h), Energy Storage Capacity (W-h), Present Energy Storage Level (W-h). Commodities can be estimated
GetPresent Temperature Not supported
Note (*): Referred to as “curtailment events” in ANSI/CTA-2045-A
10435823
4-3
Heat Pump Water Heater Table 4-2 Demand Response-Ready Heat Pump Water Heater Specification: Preliminary Requirements for CEA-2045 Field Demonstration. EPRI, Palo Alto, CA: 2014. 3002002719.
ANSI/CTA-2045 Messages Heat Pump Water Heater Responses
Link Layer Link ACK, NAK, Max Payload Length Query/Response and Message Type Supported
*Shed
Moderately reduce energy usage while maintaining customer comfort at a level determined by the OEM. OEM determines the level of comfort on the estimated average frequency of this request (Estimated AVG Frequency = 1/day) If the stored energy drops below the min comfort level, only the heat pump unit should engage to heat water as long as the curtailment event is in effect.
End Shed/Run Normal Return to normal operation
*Critical Peak Event
Aggressively reduce energy usage while maintaining customer comfort at a level determined by the OEM. OEM determines the level of comfort on the estimated average frequency of this request (Estimated AVG Frequency = 20/year) If the stored energy drops below the min comfort level, only the heat pump unit should engage to heat water as long as the curtailment event is in effect.
*Grid Emergency Immediately stop using energy and do not use energy for the duration of this event (If the duration of the event is longer than 1-hr, energy can be added to maintain a minimum customer comfort level, as determined by the OEM)
Outside Comm Connection Status If a curtailment event is active and this message is not communicated, unit will return to normal operating mode
Customer Override
Device is required to have a local interface by which the user can override curtailment events. The Customer Override message is used to report the override state of the device. If override occurs when any curtailment event is in effect, ignore all curtailment requests for the next 4-hours. If override occurs when an event is not in effect, ignore all curtailment requests for the next 24-hours.
Operational state Query and Response
Operational states: Idle, Running, Idle Grid, Running Grid, Heightened Grid and Fault
*Load Up Unit will go to max set point (as determined by the user)
Get/Set Info Request Vendor ID, Device Type, Model #, SN and Firmware revision
Get/Set Temperature Offset Not supported
Get/Set Set Point Not supported
Get/Set Commodity Read
Instantaneous power (W), cumulative energy (W-h), Energy Storage Capacity (W-h), Present Energy Storage Level (W-h). Commodities can be estimated
GetPresent Temperature Not supported
10435823
4-4
Programmable Thermostat Table 4-3 DR-Ready Programmable Thermostat Specification: Preliminary Requirements for CEA-2045 Field Demonstration. EPRI, Palo Alto, CA: 2014. 3002002711
ANSI/CTA-2045 Messages Thermostat Responses
Link Layer Link ACK, NAK, Max Payload Length Query/Response and Message Type Supported
Shed Initiate a 4-degree offset for the duration of the event. Display text notification on thermostat’s user interface for the duration of the event.
End Shed/Run Normal Used to clear text notification field and to return to user defined set points
Critical Peak Event
Initiate a 8 degree offset for the duration of the event. Display text notification on thermostat’s user interface for the duration of the event.
Grid Emergency Immediately stop using energy and do not use energy for the duration of this event.
Outside Communication Status
If a curtailment event is active and this message is not communicated, thermostat will stop processing event and return to user-defined set points. In conjunction with an indicator, this message is used to convey the connectivity status between the communication module and its supervisory controller.
Customer Override
Device is required to have a local interface by which the user can override curtailment events. The Customer Override message is used to report the override state of the device. If override occurs when any curtailment event is in effect, ignore all curtailment requests for the next 4-hours. If override occurs when an event is not in effect, ignore all curtailment requests for the next 24-hours.
Query operational state Idle, Running, Idle Grid, Running Grid and Heightened Grid supported
Load Up If unit is in Cool mode, set point will be decreased by 1 degree. If in Heat mode, set point will be incremented by 1 degree.
Info Request Vendor ID, Device Type, Model #, SN and Firmware revision
Get/Set Temperature Offset
Current offset can be read and set. "Conservation Event" displayed in text box until an End Shed is received.
Get/Set Setpoint Cool and Heat mode setpoints can be read and set
Get/Set Commodity Read
Thermostat assumes HVAC system draws 2200W. Instantaneous power and cumulative energy are estimated based on this assumption and provided to the communication module.
GetPresent Temperature The current temperature of the controlled zone can be read
10435823
4-5
Variable-Speed Pool Pump Table 4-4 Demand Response-Ready Variable-Speed Pool Pump Specification: Preliminary Requirements for CEA-2045 Field Demonstration. EPRI, Palo Alto, CA: 2016. 3002008320
ANSI/CTA-2045 Messages Pool Pump Responses
Link Layer Link ACK, NAK, Max Payload Length Query/Response and Message Type Supported
Shed If running, pump will decrease speed to 2X the min setpoint as determined by the operator or limited by the pump.
End Shed/Run Normal
Return to normal operation. Normal operation is the mode that the unit would running if the curtailment event were not processed.
Critical Peak Event
If running, pump will decrease speed to the min setpoint as determined by the operator or limited by the pump
Grid Emergency Pump will stop pumping and remain off until midnight of the day the event is received
Outside Communication Status
The pool pump must monitor for this “heartbeat” signal which is sent from the communication module. If the pool pump is processing a curtailment request and the heartbeat is not received within 15 minutes, the pool pump will return to normal operation.
Customer Override User can override curtailment events through a user interface
Query operational state Idle, Running, Idle Grid, Running Grid, Heightened Grid, Opt Out Idle, Opt Out Running supported
Load Up Unit will run at max speed (default is 3000 RPM). Total daily circulation will not be exceeded in a 24hr period
Power Level Command will variably set speed of pump between min and max RPM (0-100%, where max RPM = 100%)
Info Request Vendor ID, Device Type, Model #, SN and Firmware revision
Get/Set Commodity Read Instantaneous power and cumulative energy are supported
10435823
4-6
Electric Vehicle Supply Equipment Table 4-5 DR-Ready Electric Vehicle Supply Equipment Specification: Preliminary Requirements for CEA-2045 Field Demonstration. EPRI, Palo Alto, CA: 2014 3002002712
ANSI/CTA-2045 Messages EVSE Responses
Link Layer Link ACK, NAK, Max Payload Length Query/Response and Message Type Supported
Shed Upon receipt of this message, the maximum EV charging current will be set to 50% of max rated current, as determined by the EVSE user
End Shed/Run Normal
Return to normal operation. Normal operation is the mode that the unit would running if the curtailment event were not processed.
Critical Peak Event
The EVSE will set the maximum allowable EV charging current to the min setting as determined by J1772 standard (6A at 240V)
Grid Emergency EVSE will open contactor and stop charging EV. The pilot is still active and the car will continue to request power from the EVSE. At the end of the event, the EV will return to charging
Outside Communication Status
The EVSE must monitor for this “heartbeat” signal which is sent from the communication module in intervals less than 5-minutes. If the EVSE is processing a curtailment request and the heartbeat is not received within 15 minutes, the EVSE will return to normal operation.
Customer Override
Device is required to have a local interface by which the user can override curtailment events. The Customer Override message is used to report the override state of the device. If override occurs when either Shed or Critical Peak Event is in effect, ignore all curtailment requests for the next 4-hours. During a Grid Emergency event, the device will ignore the Customer Override and all curtailment requests during the first hour of this event. After the Grid Emergency has been in effect for 1-hour, the customer overrides and curtailment requests will be processed. If override occurs when an event is not in effect, ignore all curtailment requests for the next 24-hours.
Query operational state Idle, Running, Idle Grid, Running Grid, Opt Out Idle, Opt Out Running supported
Power Level Command will variably set max EV charging level between min (6A) and max as set by user. 0-100%, where 100% = Max rated current. Resolution is 1%
Info Request Vendor ID, Device Type, Model #, SN and Firmware revision
Get/Set Commodity Read Instantaneous power and cumulative energy are supported
10435823
4-7
Packaged Terminal Air Conditioner Table 4-6 Demand Response-Ready Programmable Packaged Terminal Air Conditioner Specification: Preliminary Requirements for CEA-2045 Field Demonstration EPRI, Palo Alto, CA: 2015 3002006951
ANSI/CTA-2045 Messages Packaged Terminal Air Conditioner Responses
Link Layer Link ACK, NAK, Max Payload Length Query/Response and Message Type Supported
Shed 4 deg offset is applied for the event duration
End Shed/Run Normal Used to clear text notification field and to return to user defined set points
Critical Peak Event 8 deg offset is applied for the event duration
Grid Emergency Fan and compressor are turned off for the event duration
Outside Comm Connection Status
The PTAC must monitor for this “heartbeat” signal which is sent from the communication module in intervals less than 5-minutes. If the PTAC is processing a curtailment request and the heartbeat is not received within 15 minutes, the PTAC will return to normal operation.
Customer Override
Device is required to have a local interface by which the user can override curtailment events. The Customer Override message is used to report the override state of the device. If override occurs when any curtailment is in effect, ignore all curtailment requests for the next 4-hours. If override occurs when an event is not in effect, ignore all curtailment requests for the next 24-hours.
Query operational state Idle, Running, Idle Grid, Running Grid and Heightened Grid supported
Load Up If unit is in Cool mode, set point will be decreased by 2 deg. If in Heat mode, set point will be incremented by 2 degree
Info Request Vendor ID, Device Type, Model #, SN and Firmware revision
Get/Set Temperature Offset
Current offset can be read and set.
Get/Set Set Point Cool and Heat mode set points can be read and set
Get/Set Commodity Read Instantaneous power and cumulative energy.
GetPresent Temperature The current temperature of the controlled zone can be read
10435823
4-8
Variable Capacity Heat Pumps Table 4-7 Requirements for Variable Capacity Heat Pumps (Air Conditioning, Heating and Refrigeration Institute (AHRI) Standard P1380.
ANSI/CTA-2045 Messages Variable Capacity HVAC Responses
Shed Limit input power to a maximum of 70% of the Benchmark Power, do not exceed if set
End Shed/Run Normal
Informs HVAC equipment that any curtailment or price events that may be presently in effect are terminated.
Critical Peak Event Limit input power to a maximum of 40% of the Benchmark Power
Grid Emergency Directs HVAC equipment to turn off, reducing input power to near zero
Outside Communication Status
Used as a “heartbeat” signal which is sent from the communication module in intervals less than 5-minutes.
Info Request Vendor ID, Device Type, Model #, SN and Firmware revision
Get/Set Temperature Offset
Shall be used as the “Maximum Indoor Temperature Offset” for HVAC equipment during a load control or price event unless locally modified by the consumer.
Get/Set Commodity Read N/A
Customer Override
User can override curtailment events by manually changing set point or by changing the mode to manual
Query operational state
Idle, Running, Idle Grid, Running Grid, Heightened Grid, Idle Heightened, Idle, Opted Out, Running Opted Out
Pending Event Warning and Pending Event
Equipment manufacturers may optionally use this information to take proactive action ahead of the event such as precooling or preheating
Pending Event Type Pending event type or notice of cancellation
10435823
5-1
5 REFERENCES AND RESOURCES (INFORMATIVE) 5.1 Reference Standards The requirements included herein apply to the version of the standards listed in Table 5-1.
Table 5-1 Referenced Communication Standards
Reference Number Source Name Revision Release
Date [1] OpenADR Alliance OpenADR 2.0 Profile
Specification B Profile 1.1 11-17-2015
[2] Consumer Technology Association
ANSI/CTA-2045-A Modular Communications Interface for Energy Management
A March 2018
5.2 Open Source Code Repositories The applications and source code listed in Table 5-2 were developed and published to advance research and the adoption of open communication standards.
Table 5-2 Open Source Code Repositories for OpenADR 2.0 and ANSI/CTA-2045 Applications
Name and Link Description Programming Language
OpenADR 2.0 Virtual Top Node (VTN)
This application is an implementation of a virtual top node (VTN) as defined in the OpenADR Alliance’s OpenADR 2.0 Profile Specification.
Ruby
OpenADR 2.0b Virtual End Node (HTTP Poll)
This application is an implementation of a virtual end node (VEN) as defined in the OpenADR Alliance’s OpenADR 2.0 Profile B Specification (HTTP pull)
C#
OpenADR 2.0b Virtual End Node (HTTP Poll) C++ Library
This library was developed to support the requirements of an OpenADR 2.0b HTTP Poll VEN client.
C++
CTA-2045 Desktop Simulator
This application is designed to aid in the develop and test of ANSI/CTA-2045 communication ports. This repository also includes hardware designs for the physical test harnesses (AC and DC form factors).
Visual Basic
CTA-2045 C++ Library (Communication Module Role)
This software is a C++ library developed and released to support companies in the marketplace who are developing or planning to develop ANSI/CTA-2045 communication modules
C++
10435823
5-2
5.3 System Diagrams (Symbols – Definition, Nomenclature, Use) Table 5-3 includes definitions for symbols used to compile the system diagrams included in Section 1.2. Another example use of these symbols in a system that leverages OpenADR 2.0 and ANSI/CTA-2045-A to automatically dispatch BTM resources is shown in Figure 5-1. Table 5-3 System Diagram Symbol Definitions
Representative Element
Definition, Nomenclature, Use Symbol
Actor
Actors are any human or machine whose interaction with the system contributes to the system’s output. Actor(letter)
Actor(Letter)
Actor(Letter)
Human Machine
Information Exchange Point
A point at which data is exchanged with an actor. This point is represented by a circle located on one or more sides of an actor.
Actor(Letter)
Actor(Letter)
Human Machine
Interface
A specific format and rules that one or more actors use to exchange information. The colors in the symbol represent a specific format and rules (protocol). Suggested Naming Convention Interface(number)
Actora Actorb
Human-to-machine Actorb Actorc
Machine-to-machine
Interface Legend
An Interface Legend is used to map the colors used to differentiate one interface to another to the name of the interface.
= Interface1
= Interface2
Interface Legend
10435823
5-3
Representative Element
Definition, Nomenclature, Use Symbol
Information Flow (Direction)
Direction by which information is sent from one actor to another.
From Actora to Actorb
Actora Actorb
From Actorb to Actora
Information Exchange Sequence
The sequence by which information is shared between actors across a system.
First Sequence
Actora Actorb
Second Sequence
1
2
Information
Information (i.e. data, messages, instructions, commands, requests, etc.) shared between actors. Example Naming Convention Info InterfaceNumber.MessageNumber
(SendingActorLetter, ReceivingActorLetter)
Info InterfaceNumber.MessageNumber (SendingActor, ReceivingActor)
Info InterfaceNumber.MessageNumber (SendingActor, ReceivingActor)
Hierarchical Role (Upstream or Downstream)
Term used to describe the role of an actor with reference to another within the system. Note: For example, this concept is analogous to the roles for Masters and Slaves or Servers and Clients.
Upstream (Ex. Master or Server)
Downstream (Ex. Slave or Client)
Interface
The Colors behind the Actor’s Information Exchange point are used to represent a common interface. Suggested Naming Convention Interface(number)
Actora Actorb
1
4
Human-to-machine
Actorb2
3
Actorc
Machine-to-machine
10435823
5-4
Representative Element
Definition, Nomenclature, Use Symbol
A legend is used to map names to the colors selected to represent the interfaces
= Interface1
= Interface2
Interface Legend
Logic
The Logic block represents decisions or actions that each actor must execute to fulfill the system’s objective Arrows between the logic blocks can be used to represent interactions between one or more logic blocks within the same actor. Example Naming Convention Logic(ActorLetter).(BlockNumber) Application Note: For Actors representing Machines, logic blocks could represent subroutines such as mapping information to other subroutines that process and execute their functional role in the system. Application Note: For Actors representing Humans, the logic blocks are used to represent thought processes and actions.
Logi
c c.1
Logi
c c.2
Logi
c b.1
Logi
c b.4
Logicb.2
Logicb.3
Logica.1
Logica.2
10435823
5-5
Demand Response Management System (DRMS)
DRMA CTA-2045 UCM
Logi
c B.1
Logi
c B.4
LogicB.2
Logi
c B.3
Logi
c B.D
B
Logi
c C.1
Logi
c C.3
Logi
c C.2
Logi
c C.5
Logi
c C.4
Logi
c B.5
Ope
nAD
R 2.
0b
I1 `
DRMS Operator CTA-2045 DER DER User
LogicA.1
LogicA.3
LogicA.2
Logi
c D.1
Logi
c D.3
Logi
c D.2
Grid Service
LogicE.1
LogicE.3
LogicE.2
UCM UserLogicF.1
LogicF.3
LogicF.2
LogicG.1
LogicG.3
LogicG.2
DRMS User
= H2M Interface I1
Interface LegendDERMS
Ope
nAD
R 2.
0b
Not
Spe
cifie
d
I3 I4
I7
I8
I6I5`
DERMS Operator
LogicE.1
LogicE.3
LogicE.2
= M2M Interface I2
= CTA-2045 Interface I3
= M2M Interface I4
= H2M Interface I5
= OpenADR 2.0 Interface I6
= H2M Interface I7
= H2M Interface I8Logi
c H.1
LogicH
.2 I9
I2
= H2M Interface I9
DAQ / M&V
Figure 5-1 Example use of symbols in a system that relies on OpenADR 2.0 and ANSI/CTA-2045-A to dispatch BTM resources
10435823
10435823
10435823
Electric Power Research Institute 3420 Hillview Avenue, Palo Alto, California 94304-1338 • PO Box 10412, Palo Alto, California 94303-0813 • USA
800.313.3774 • 650.855.2121 • [email protected] • www.epri.com
The Electric Power Research Institute, Inc. The Electric Power Research Institute, Inc. (EPRI, www.epri.com) conducts research and development relating to the generation, delivery and use of electricity for the benefit of the public. An independent, nonprofit organization, EPRI brings together its scientists and engineers as well as experts from academia and industry to help address challenges in electricity, including reliability, efficiency, affordability, health, safety and the environment. EPRI also provides technology, policy and economic analyses to drive long-range research and development planning, and supports research in emerging technologies. EPRI members represent 90% of the electricity generated and delivered in the United States with international participation extending to 40 countries. EPRI’s principal offices and laboratories are located in Palo Alto, Calif.; Charlotte, N.C.; Knoxville, Tenn.; and Lenox, Mass.
Together…Shaping the Future of Electricity
© 2019 Electric Power Research Institute (EPRI), Inc. All rights reserved. Electric Power Research Institute, EPRI, and TOGETHER…SHAPING THE FUTURE OF ELECTRICITY are registered service marks of the Electric Power Research Institute, Inc.
3002008854
10435823