OpenADR 2.0 DR Program Guide Certification Documentation

1 Introduction The OpenADR Demand Response Implementation Program Guide (referred to hereafter as the Program Guide) contains templates for common Demand Response (DR) programs and best practices recommendations for using OpenADR with those programs. The following DR programs are included in the Program Guide: • Capacity Bidding Program (CBP) • Critical Peak Pricing Program (CPP) • Distributed Energy Resources DR Program (DER) • Fast DR Dispatch Program (FDR) • Public Station Electric Vehicle RealTime Pricing Program (EVP) • Residential Electric Vehicle Time of Use Program (EVR) • Thermostat Program (THR) OpenADR 2.0 VTNs and VENs may obtain certification for one or more of the Demand Response Programs noted above. The objective of certification is to ensure VTNs and VENs can be easily deployed in DR programs where the technical requirements defined by Utilities also model the Program Guide recommendations. The purpose of this document is to provide all the information necessary to successfully certify that VENs and VTNs follow the Program Guide recommendations contained in the Program Guide. This documentation is divided into the following major sections: • Section 2, Test Methodology This section provides a detailed description of the test methodology used for the Program Guide certification test cases. • Section 3, Test Execution This section provides guidance on how to configure and execute the A or B profile DR Program Guide certification test cases. Note that this section assumes users are familiar with the A and B profile Test User Guides provided as part of the OpenADR message exchange certification documentation packages. • Section 4, Test Case Definitions This section provides detailed documentation for each of the required test cases used in certifying devices for conformance to Program Guide recommendations. • Annex A, PICS This section contains documentation that must be submitted to the test lab as part of the certification process. Readers should carefully review section 2, Test Methodology, before reviewing the balance of this document or attempting to run Program Guide certification test cases.

Trang 1

DR Program Guide Certification Documentation

Revision Number: 1.0.1 Document Status: Final Released: June 10, 2016

Trang 2

1.0.1 Updated Thermostat Program sample report JZ – 6/10/16

Trang 3

Contents

Trang 4

1 Introduction

The OpenADR Demand Response Implementation Program Guide (referred to hereafter as the "Program Guide") contains templates for common Demand Response (DR) programs and best practices recommendations for using OpenADR with those programs The following DR programs are included in the Program Guide:

• Capacity Bidding Program (CBP)

• Critical Peak Pricing Program (CPP)

• Distributed Energy Resources DR Program (DER)

• Fast DR Dispatch Program (FDR)

• Public Station Electric Vehicle Real-Time Pricing Program (EVP)

• Residential Electric Vehicle Time of Use Program (EVR)

• Thermostat Program (THR)

OpenADR 2.0 VTNs and VENs may obtain certification for one or more of the Demand Response Programs noted above The objective of certification is to ensure VTNs and VENs can be easily deployed in DR programs where the technical requirements defined by Utilities also model the Program Guide recommendations.

The purpose of this document is to provide all the information necessary to successfully certify that VENs and VTNs follow the Program Guide recommendations contained in the Program Guide This documentation is divided into the following major sections:

• Section 2, Test Methodology - This section provides a detailed description of the test

methodology used for the Program Guide certification test cases

• Section 3, Test Execution - This section provides guidance on how to configure and

execute the A or B profile DR Program Guide certification test cases Note that this section assumes users are familiar with the A and B profile Test User Guides provided

as part of the OpenADR message exchange certification documentation packages.

• Section 4, Test Case Definitions - This section provides detailed documentation for

each of the required test cases used in certifying devices for conformance to Program Guide recommendations.

• Annex A, PICS - This section contains documentation that must be submitted to the

test lab as part of the certification process.

Readers should carefully review section 2, Test Methodology, before reviewing the balance of this document or attempting to run Program Guide certification test cases.

Trang 5

1 Test Methodology

1 Terms and Acronyms

The following terms and abbreviations are used in this document:

2 Scope

Certification tests will be limited to validating the best practices

recommendations in the Program Guide are followed for a given Demand Response program

It is assumed that devices being submitted for certification have passed the message exchange certification process, and the test cases defined in this document will focus solely on validating the Program Guide recommendations.

3 Methodology

Test cases will model the simple, moderate, and complex use case examples defined in the Program Guide The test harness will play the role of the opposite party (VEN or VTN) in interactions with the Device under Test (DUT) Each test case will define a set of

prerequisites, a test scenario consisting of a sequence of VEN/VTN message exchanges, and

an expected result Test scenarios validate the following types of behavior:

• The ability to send or receive each of the event signals recommended

• The ability to target resources specified in the event and to cause the behavior of those resources to change in proportion to the signal values specified in the event.

• The ability to exhibit the recommended default optIn/optOut response.

• For B profile devices, the ability to qualify resources participating in an event using oadrCreateOpt if recommended in the guide, and to cause resources to adapt their behavior in response to that qualification.

• For B profile devices, the ability to request and publish each of the reports

recommended for a given program (if any) and to populate each report with realistic data for each of the requested data points.

In order to ensure VTNs and VENs can be easily deployed in DR Programs that also model

CBP Capacity Bidding Program

CMP Complex Use Case

CPP Critical Peak Pricing Program

DER Distributed Energy Resources Program

DUT_VEN Device Under Test Virtual End Node (VEN)

DUT_VTN Device Under Test Virtual Top Node (VTN)

EV Electric Vehicle

EVP Public Station Electric Vehicle Real-Time Pricing Program

EVR Residential Electric Vehicle Time of Use Program

FDR Fast DR Dispatch Program

SMP Simple Use Case

TH_VEN Test harness playing the role of the VEN

TH_VTN Test harness playing the role of the VTN

THR Thermostat Program

TYP Typical Use Case

VEN Virtual End Node

VTN Virtual Top Node

Trang 6

In order to validate the functional behavior of a VEN being tested, the VEN implementer will

be required to provide the following capabilities as part of the VEN submitted for certification testing:

• Two mock load shedding resources that can be uniquely addressed using eiTarget resourceIDs that will visibly respond to changes in the signal values received as part of

a DR event The two mock resources associated with the VEN must be able

demonstrate three levels of load shed for each signal equivalent to the simple signal's medium, high, and special load shed levels

• B profile VENs must return telemetry data for each required report using either a real data source whose values are variable in nature or use a mock data source that will produce random values within a realistic range for the type of data contained in the report.

• The ability to configure the VEN to respond to either a simple signal or a more

complex signal where both are contained in the event payload

Validation of successful test execution will be done both programmatically and through operator observations of DUT behavior Each test scenario will contain matching VTN and VEN test cases.

Event durations, interval time frames, and reporting characteristics have been modified from those shown in the Program Guide to facilitate reasonable test case execution times.

Not all programs defined in the Program Guide have all three use case scenarios defined: Simple, Typical, and Complex Test cases will only be defined where use case scenarios exist

in the Program Guide

Some programs defined in Program Guide may only be practical in a push or pull exchange mode due to network latency or fire wall issues The following programs have only push or pull test cases:

• Pull Only Test Cases

o Residential Electric Vehicle Time of Use Program

• Push Only Test Cases

o Fast DR Program

Visual observation of ramp up or recovery times is out of scope for certification testing, although testable values will be sent as part of the Fast DR Dispatch test cases, and if the DUT_VEN performs ramp up and/or recovery behavior it will not cause the test cases to fail The test cases do not specify specific values for reportDataSource in the oadrRegisterReport payloads as there is no actionable behavior associated with these values and the VEN DUT may not have complete control of the values populated in this object.

4 Test Case Organization

The Program Guide test cases will be distributed as a separate folders within the same Eclipse projects distributed for the A and B profile message exchange certification tests The Program Guide tests are organized as follows within these projects:

• testcases

o pull

 DR_Program_Guide

• [Program Name]

Trang 7

5 Test Case Numbering

Test case numbering uses the following pattern: XXX_ZZZ_UV_TH_WWW_1

XXX = Three letters designating the DR Program

• CBP = Capacity Bidding Program

• CPP = Critical Peak Pricing Program

• DER = Distributed Energy Resources DR Program

• EVP = Public Station Electric Vehicle Real-Time Pricing Program

• EVR = Residential Electric Vehicle - Time of Use Program

• FDR = Fast DR Dispatch Program

• THR = Thermostat Program

ZZZ = The use case scenario being tested:

• SMP = Simple use case

• TYP = Typical use case

• CMP = Complex use case

U = A letter indicating the profile for the test case

• A = OpenADR 2.0a Profile

Trang 8

profiles pull test for Critical Peak Pricing that uses the typical use case data set, where the Test Harness plays the role of the VEN and the target for testing is the VTN This test case should be started before the DUT_VTN

Trang 9

6 DUT Configuration Capabilities

The VEN must have the following configuration capabilities:

• The ability to map the resourceID strings to mock or real resources associated with the device under test

• If necessary, the ability for the test operator to trigger the generation of mock data used

in each of the data points in a report required by the Program Guide test cases.

• The ability for the test operator to observe changes in resource behavior in proportion

to event signal interval values This can be an indicator in a console log output, or some visual or behavioral indicator.

• The ability to set event signal interval value thresholds that trigger resource load shed behavior Note that that the interval values send by the test harness can be control by modifying the Test Harness properties.

• The ability for the test operator to trigger oadrCreateOpt to modify the resources participating in an event, if the Program Guide template under test requires that

functionality.

The VTN must have the following configuration capabilities:

• The ability for the test operator to dispatch the event payloads defined in this test specification for the Program Guide template under test.

• The ability for the test operator to trigger reports requests defined in this test

specification for the Program Guide template under test.

7 DUT Transport and Security Configuration

Test cases for a given DR Program template will be executed once as part of the certification process using the transport and exchange model decision tree shown below:

• Thermostat Program (THR) and Residential Electric Vehicle Time of Use Program (EVR) test cases shall be tested over HTTP Pull.

• The Fast DR Dispatch (FDR) test cases shall be run over XMPP if supported by the DUT Otherwise use HTTP Push.

• If the DUT does not support HTTP transport, tests cases shall be run over XMPP.

• If the DUT supports only the HTTP Transport and does not support the push exchange model, test cases shall be run over HTTP Pull.

• Each remaining DR program supported by the DUT shall be tested using an alternating combination of the supported transports and exchange models (push, pull)

All test cases will be run with the test harness configured for HTTP_SHA256_Security or XMPP_SHA256_Security security.

8 Test Harness Program Guide Property Values

1 Signal Interval Values

Trang 10

keys shown below will be used in the test case definitions Values shown are defaults and may

be changed as needed for testing with a specific DUT:

Validation of inbound oadrDistributeEvents sent from the VTN DUT will not include

matching the PayloadFloat values received in interval data with the values above, although the prompts to the test user will request these values be configured in the event Implementation dependent issues may prevent an exact match of values

2 Units Values

Some Event signals and reports require additional information for the units used payloads as show in the table below As these properties are used across multiple signal and report names, you may need to modify these property values on a test case by test case basis.

The B test harness has a single property called ResourceIDs that contains an array of resource

names The test case definitions in this document use the following properties array index identifiers in the test definitions Values shown are defaults and may be changed as needed for testing with a specific DUT:

Properties Array Identifier Default Value

ResourceIDs[0] "resource1"

Trang 11

ResourceIDs[1] "resource2"

The A test harness has a property called ResourceID that allows a single ID to be specified This is equivalent to ResourceIDs[0] shown in the test case definitions.

Trang 12

4 Report Data Values

The test harness will have the following new configuration properties to facilitate the

generation and validation of report interval values that are used in outbound

oadrUpdateReport payloads sent by the test harness and used for validating inbound reports from the DUT_VTN

The test harness by default uses dynamically allocated rID values for report descriptions However, when more than one data point exists in a report, it is helpful to use rID values that are well known values between the VTN and the VTN to avoid ambiguity in the interpretation

of data points that may use the same units of measure The Program Guide recommends use of the rID element as a well-known identifier for data points in OpenADR reports using the following syntax:

well-known-rID[:vendor-specific]

The strings used for the known rID values and the range of typical values for each known rID will be defined as test harness properties The range values will be used to validate report data sent from the DUT_VEN, as well as for random generation of report data when the test harness plays the role of the VEN Note that during validation of rID values, if a colon (:)

well-is present in the rID string, the colon and any text following the colon will be ignored for the purposes of validating that an expected well known rID value has been used for a particular data point.

The configuration properties are shown below and will also be used in the test case

definitions Values shown are defaults and may be changed as needed for testing with a specific DUT:

TelemetryUsage_PowerReal_WellKnown_rID Power Real

TelemetryUsage_PowerReal_Range 10, 20 (KW)

TelemetryUsage_Voltage_WellKnown_rID Voltage

TelemetryUsage_Voltage_Range 100, 120 (Volts)

ThermostatState_Status_WellKnown_rID Status

ThermostatState_Status_LevelOffset_Current_Range 0, 4 (Fahrenheit offset)

ThermostatState_CurrentTemp_WellKnown_rID Current Temp

ThermostatState_HVACModeSetting_WellKnown_rID HVAC Mode Setting

ThermostatState_HVACModeSetting_Range 0, 3 (0=OFF, 1=HEAT, 2=COOL, 3=AUTO)

ThermostatState_HVACMode_WellKnown_rID Current HVAC Mode

ThermostatState_HVACMode_Range 0, 2 (0=OFF, 1=HEAT, 2=COOL)

ThermostatState_FanModeSetting_WellKnown_rID Fan Mode Setting

ThermostatState_FanModeSetting_Range 0, 2 (0=OFF, 1=ON, 2=AUTO)

ThermostatState_CurrentHoldMode_WellKnown_rID Current Hold Mode

Trang 13

may not contain all the reports expected by non-Program Guide test cases, the registration bootstrap test cases (N1_1020 or N0_5020) should be rerun before executing non-Program Guide test cases.

In order to request the expected reports, the TH_VTN test cases will need to search the test harness registration database for a report matching required the reportName, reportType, well known rID values, and units for each data point If found the test harness can obtain the reportSpecifierID to request the report If not found, the test harness will provide the user with diagnostic information regarding what is expected so that they can compare it to the metadata report received during registration(contained in the test harness database files)

10 Test Case Template

Each test case definition results in up to four sets of mirrored test routines; one set each for A and B profile, one set each for push and pull exchange models, and one set of matched VEN and VTN test cases The result is that each test case definition can result up to 8 separate test cases, one each for the following: A VEN Push, A VTN Push, A VEN Pull, A VTN Pull, B VEN Push, B VTN Push, B VEN Pull, B VTN Pull Test cases can be run against their

counterpart DUT or against each other in a self test scenario

Each test case is based on simple, typical, or complex use case data set defined in the Program Guide These data sets define the specific event signals, number of intervals, report data points, and other characteristics for a given use case scenario Test cases are designed to exchange payloads such that each of the unique characteristics defined in the use case data sets are exchanged between the DUT and the Test Harness playing the role of the VEN or VTN.

Each test case definition will contain the following:

• Unique identifier for the test case

• The objective of the test case

• Any required prerequisites

• The expected results

• The use case data set values to be used in the test cases

• Push and Pull payload exchange patterns

• Any prompts or user interventions required to complete the test execution.

11 Common Pass and Fail Verdicts

In order to avoid repeating common expected results throughout test case definitions, unless stated otherwise in the test case definition, the following criteria will be used to determine if a test case passes or fails:

Common Pass Verdicts

Test case scenario runs to completion AND all exchanged payloads validate against the OpenADR 2.0 schema AND all OpenADR 2.0 conformance rule validation checks pass.

Common Fail Verdicts

Test case scenario fails to run to completion because of a timeout, transport error, or other

problem OR OpenADR 2.0 payload schema violation OR OpenADR 2.0 conformance rule validation failure OR a failure to meet the pass criteria defined in either the common pass

verdict noted above or the expected results defined for each test case Failure verdicts will only be defined in the test case definition if there is some unique non-intuitive circumstance

Trang 14

2 Test Execution

The key to successful execution of the Program Guide test cases is to make sure that the configuration settings between the DUT and the test harness are in perfect alignment The following sections are designed to walk a test engineer through the steps required to get this configuration correct.

12 Select Template and Test Cases

Each Program Guide template is certified independently, so even if the DUT supports multiple templates, it is best to tackle them one at a time from a certification test execution perspective Start by identifying which of the 7 supported templates you are going to test The supported templates are shown below Note the acronym used to refer to each program template.

• Capacity Bidding Program (CBP)

• Critical Peak Pricing Program (CPP)

• Distributed Energy Resources DR Program (DER)

• Fast DR Dispatch Program (FDR)

• Public Station Electric Vehicle Real-Time Pricing Program (EVP)

• Residential Electric Vehicle Time of Use Program (EVR)

13 Transport, Security, and Registration

The User Guides for the A and B profile Test Harness provide guidance on configuring the transport and security settings for the test harness, as well as registering B profile DUT with the test harness The simplest way to register for B profile devices is to use the DUT_Register utility program located at /src/testcases/util in the Eclipse Package Explorer Note that if you register for "push" you can run both push and pull test cases without needing to reregister.

If the DUT VEN does not offer the reports required by conformance rule 510 as part of the registration process, you will need to set the following Program Guide property to true to successfully register prior to running the Program Guide test cases:

14 Understand Test Case Requirements

Before starting to configure the Test Harness and DUT, refer to the table in Section 4.3 to understand the type of events, reports, resources, and other OpenADR characteristics that will

be part of the tests that will be run If you need further clarification of the test case

requirements you can refer to the detailed test case definitions found further on in Section 4.0.

Trang 15

15 Program Guide Properties Location

Program guide specific properties have been added to the end of the same properties file used

to configure the A and B profile message exchange certification tests The following types of configuration settings are available for Program Guide testing:

• Values used to construct events sent to DUT VEN

• Unit characteristics used by signals and reports

• Values used to construct outbound reports and validation of inbound reports

• Property to disable registration check for required reports

• Properties to disable specific validation checks for DR Programs

16 Resource Configuration

Refer to section 2.8.3 for information on resource configuration properties

1 Resource - DUT VEN

The test harness will use the venID in properties (for A profile) or the venID provided as part

of registration (B profile) for event targeting information in most test cases However, some test cases require that the resourceID target be used for event targeting The test cases will pull the strings used for the resourceID from properties (ResourceIDs for B, ResourceID for A) to include in the outbound event payloads

When the target for an event is the venID, all the resources associated with the VEN should respond to the event When the target is one or more resourceID values, ONLY the resources mapped to that resourceID(s) should respond VEN implementers should make sure their devices are appropriately configured to demonstrate this mapping as the test case prompts will ask the test engineer to observe the impact of specific resourceID on event targeting.

2 Resource - DUT VTN

When setting up events in the VTN, the test engineer will need to set targets as prompted by the test case The targets contained the received payloads from the DUT VTN must match the properties settings Most test cases use the venID as the target so no specific configuration is needed However, a few test cases request that a specific resourceID be used as part of the test execution The strings used for the resource names in the VTN should be configured in test harness properties using "ResourceIDs" to configure two resource names for the B profile tests and "ResourceID" to configure a single resource name for the A profile tests.

17 Event Configuration

Refer to section 2.8.1 and 2.8.2 for information on event configuration properties

1 Events - DUT VEN

When testing a DUT VEN, the test case will send events with signals as specified in the test case definitions; pulling interval values and unit details from properties (refer to Sections 2.8.1 and 2.8.2) The test engineer will be prompted to observe changes in load shed over the interval durations on the DUT VEN using a debug console or other mechanism DUT VEN

Trang 16

multiple signals The DUT VEN must be configured to respond to the expected signal as defined by the test case requirements (and noted in the prompts) For instance, a VEN may receive an event with both a SIMPLE and LOAD_DISPATCH signal, and be expected to respond to the values in the LOAD_DISPATCH signal.

2 Events - DUT VTN

No specific properties configuration is required for the event specific portions of the Program Guide test cases when testing a DUT VTN The test case will prompt the test engineer to configure the events in the VTN using specific signals, targets, interval duration, and interval values Upon receipt or the event payload, the Test harness will validate the event payload values are as expected.

18 Report Configuration

Refer to section 2.8.4 for information on report configuration properties This section can be ignored if no reports are required as part of the Program Guide template being tested.

1 Reports - DUT VEN

The test harness will expect the DUT VEN to offer reports matching the requirements of the test case as part of the registration bootstrap sequence The reports offered must have the expected reportName and expect data point characteristics including well known rID value, reportType, units, readingType, and any other required values When the test harness requests

a report, it will validate that a report with the required characteristics has been previously offered by the DUT VEN The test harness stores available reports offered by the DUT VEN

in /src/db/vtndb.xml

There are two types of properties that can be configured for reports The first is the well known data point name that the test harness expects the DUT VEN to use for a given report The default well known rID values configured in the test harness properties are likely to be adopted as formal Program Guide recommendations, so these values should be used unless there is a compelling reason to change them in properties

The allowable range of expected interval values for a given data point can also be configured

in properties and should be adjusted to accommodate the nature of the report data generating resources associated with the DUT VEN When an oadrUpdateReport payload is received from the VEN, the test harness will validate that the interval values fall within the ranges configured in properties.

2 Reports - DUT VTN

Reports sent by the test harness to the DUT VTN will use the well known data point names defined in properties and will have interval values that fall between the ranges specified in properties At the start of each test case where the where the scenario requires reporting, the test case will send an oadrRegisterReport payload containing the required report(s) The test engineer will subsequently be prompted to select the required report from the DUT VTN user interface

The test harness will validate that the DUT VTN requests the expected report and all the required data points offered by that report The test harness will also deliver the reports to the DUT VTN, although no specific validation is done beyond confirmation from the DUT VTN that it successfully received the oadrUpdateReport payload.

Trang 17

19 Running Test Cases, Prompts, Observations

Running test cases is identical to the process used to run the A and B profile message

exchange certification test cases There are, however, a large number of user prompts in the Program Guide test cases that should be reviewed carefully during test execution as these prompts provide specific guidance on DUT configuration of events and reports.

When testing a DUT VEN, all test cases will prompt the test engineer to observe the load shed behavior on the targeted resources and to confirm with a Yes/No answer whether the DUT VEN exhibited the expected load shed behavior Test engineers can determine the expected behavior by reviewing the prompt details or the detailed test case definitions in this document.

In general, the test engineer should note from the prompts the number of intervals in the event, the duration of each interval, and the level of load shed for that interval (medium, high, and special) With this information the test engineer should have a clear expectations of the behavior of the DUT during the event execution For instance, if a light bulb is attached as a targeted resource, the brightness of the bulb should change in proportion to the level of load shed.

A small number of test cases may ask the test engineer if the current test execution is part of a self test If testing a real DUT, just answer the prompt with an "N"

20 Certification Submission

When submitting a device for certification, you must complete the PICS document found in Annex A, as well as provide the test lab with a detailed list of Program Guide properties settings that are required for your DUT to successfully pass certification.

21 Validation Checks

During the execution of each test case the characteristics described in the Test Methodology section of this document are validated against the values configured in properties During pre- certification testing the Program Guide specific conformance checks can be disabled if

necessary During certification testing all these settings shown in the table below must be set

to false

1 Conformance Check Disable Properties

Disable Program Guide Checks

Trang 18

3 Test Case Definitions

This section contains a detailed description of each test case scenario Each test scenario

definition defines the test objectives, the use case scenario data set, and sequence diagrams for push and pull scenarios The tables below are a quick reference for all A and B Profile

Program Guide test cases Each column in the table represents a particular type of device

under test (DUT) and the 3-digit prefix on each test case name indicates the specific DR

program followed by the use case scenario type (simple, typical, or complex) Refer to the

acronyms list in Section 2.1.

A Profile Test Cases Table

DUT = Pull VEN DUT = Pull VTN DUT = Push VEN DUT = Push VTN

CBP_SMP_A1_TH_VTN_1 CBP_SMP_A1_TH_VEN CBP_SMP_A0_TH_VTN CBP_SMP_A0_TH_VEN_1

CPP_SMP_A1_TH_VTN_1 CPP_SMP_A1_TH_VEN CPP_SMP_A0_TH_VTN CPP_SMP_A0_TH_VEN_1

EVR_SMP_A1_TH_VTN_1 EVR_SMP_A1_TH_VEN N/A N/A

N/A N/A FDR_SMP_A0_TH_VTN FDR_SMP_A0_TH_VEN

THR_SMP_A1_TH_VTN_1 THR_SMP_A1_TH_VEN THR_SMP_A0_TH_VTN THR_SMP_A0_TH_VEN_1

B Profile Test Cases Table

DUT = Pull VEN DUT = Pull VTN DUT = Push VEN DUT = Push VTN

DER_TYP_B1_TH_VTN_1 DER_TYP_B1_TH_VEN DER _TYP_B0_TH_VTN DER_TYP_B0_TH_VEN_1

EVP_TYP_B1_TH_VTN_1 EVP_TYP_B1_TH_VEN EVP_TYP_B0_TH_VTN EVP_TYP_B0_TH_VEN_1

EVR_SMP_B1_TH_VTN_1 EVR_SMP_B1_TH_VEN N/A N/A

EVR_TYP_B1_TH_VTN_1 EVR_TYP_B1_TH_VEN N/A N/A

N/A N/A FDR_SMP_B0_TH_VTN FDR_SMP_B0_TH_VEN

N/A N/A FDR_TYP_B0_TH_VTN FDR_TYP_B0_TH_VEN_1

N/A N/A FDR_CMP_B0_TH_VTN FDR_CMP_B0_VEN

THR_SMP_B1_TH_VTN_1 THR_SMP_B1_TH_VEN THR_SMP_B0_TH_VTN THR_SMP_B0_TH_VEN_1

THR_TYP_B1_TH_VTN_1 THR_TYP_B1_TH_VEN THR_TYP_B0_TH_VTN THR_TYP_B0_TH_VEN_1

THR_CMP_B1_TH_VTN_1 THR_CMP_B1_TH_VEN THR_CMP_B0_TH_VTN THR_CMP_B0_TH_VEN_1

The table on the following page provides a very terse and highly abbreviated synopsis of all

the test cases in the section Please refer to the detailed test descriptions for any needed

clarifications.

Program Test Scenario Synopsis Table

Simple(level), Bid_Load(Setpoint, powerReal)

1 interval (Med-2m) - venIDCBP

Complex Simple(level), Bid_ Load(Setpoint, PowerReal),Bid_Price(price, CurrencyPerKW)

2 Intervals(med-2m, high-2m)ResourceIDs[0] + ResourceIDs[1]

TELEMETRY_USAGEUsage, powerRealFreq=1, gran=1 (Mins)

Bid_Price has one 4minute interval

3 intervals(med-1, high-2m, Spec-1m)

Trang 19

Signals Reports Comments

ResourceIDs[0] + ResourceIDs[1]

DER

Typical

Electricity_Price(price, CurrencyPerKWh)

24 interval (med-2m, high-2m, repeat) - venID

"never" Resp ReqCancellationEVP

Typical Electricity Price(price, CurrencyPerKWh)1 Interval (med-2m) - venID

3 Intervals(med-1m, high-2m, med-1m) - venIDFDR

Simple

Simple(level)

1 Interval (Spec - 0m) - venID

Zero durationCancellationFDR

Typical Load_Dispatch(delta, powerReal)Simple(level),

1 interval (high-1m) - venID

TELEMETRY_USAGEUsage, powerRealFreq=1, gran=1 (Mins)

Ramp up, Recovery

FDR

Complex

Simple(level),Load_Dispatch(Setpoint, PowerReal

2 intervals (med-2m, spec-2m) - ResourceIDs[0]

TELEMETRY_USAGEUsage, powerRealUsage, VoltageFreq=5, gran=5 (secs)

Ramp up, RecoveryFast Reporting

TELEMETRY_STATUSx-resourceStatus, Status setpoint,Cur TempsetPoint ,Heat Temp SettingsetPoint , Cool Temp SettingoperatingState,HVAC SettingoperatingState, current HVAC

ModeoperatingState , Fan SettingoperatingState, Current HoldoperatingState, Current AwayoperatingState , Current HumidityFreq=1, gran=1 (Mins)

Randomized

THR

Complex

Simple(level),Load_Control(x-loadControlCapacity)

2 interval (high-1m, med-3m)ResourceIDs[0] + ResourceIDs[1]

RandomizedCreateOpt

Trang 20

22 Capacity Bidding Program (CBP)

1 CBP Simple Use Case

Test Case Root ID

B Pull Test Case CBP_SMP_B1_

B Push Test Case CBP _SMP_B0_

A Pull Test Case CBP _SMP_A1_

A Push Test Case CBP _SMP_A0_

Objective Verify that the DUT_VTN can send the event

signal(s) defined in the CBP simple use case data set

Verify that the DUT_VEN can receive the event signal(s) defined in the CBP simple use case data set and act upon the event

Prerequisites DUT_VTN is in a registered state 1) DUT_VEN is in a registered state

2) DUT_VEN configured to respond to interval value(s) shown in use case data set

Expected Results 1) Verify that event payload signal characteristics

defined in use case data set match received payload

1) Confirm DUT_VEN opts in to event2) Confirm DUT_VEN executes the event, monitoring that only the targeted resources shed load in proportion to the interval signal values defined in the use case data set

o Signal Name: simple

 Signal Type: level

 Units: N/A

 Number of intervals 1

 Interval Duration(s):2 minutes

 Interval Value(s): Simple_Medium

 Signal Target: N/A

o Event Target(s): venID

o Priority: 1

o VEN Response Required: always

o VEN Expected Response: optIn

• Reports

o None

Trang 21

Pull Test Sequence

create event as defined in the use case data set>TH_VTN Prompt: <Confirm DUT_VEN is configured to respond to interval value threshold

in use case data set>

2 oadrPoll (B profile)

oadrRequestEvent (A profile)

3 oadrDistributeEvent TH_VTN Note: Include all signals defined in use

case data set

4 oadrCreatedEvent

for targeted resources and interval duration(s) as defined in use case data set>

Push Test Sequence

case data set

3 HTTP Ack

4 oadrCreatedEvent

Trang 22

2 CBP Typical Use Case

Test Case Root ID

B Pull Test Case CBP _TYP_B1_

B Push Test Case CBP _TYP_B0_

signal(s) defined in the CBP typical use case data set

Verify that the DUT_VEN can receive the event signal(s) defined in the CBP typical use case data set and act upon the event

2) DUT_VEN configured to respond to complex interval value(s) shown in use case data set

1) Confirm DUT_VEN opts in to event2) Confirm DUT_VEN executes the event, monitoring that only the targeted resources shed load in proportion to the complex interval signal values defined in the use case data set

 Units: N/A

 Interval Value(s): Simple_Medium

 Signal Target: None

o Signal Name: BID_LOAD (VTN to respond to this signal)

 Signal Type: setpoint

 Units: powerReal

 Interval Value(s): Bid_Load_Setpoint_Medium

o Event Targets: venID

o Priority: 1

• Reports

o None

Trang 23

create event as defined in the use case data set>TH_VTN Prompt: <Configure DUT_VEN to respond to the complex signal in the payload and configure the DUT_VEN to respond to interval value threshold in use case data set>

2 oadrPoll

case data set

4 oadrCreatedEvent

for targeted resources and complex signal interval duration(s) as defined in use case data set>

case data set

3 HTTP Ack

4 oadrCreatedEvent

Trang 24

3 CBP Complex Use Case

Test Case Root ID

B Pull Test Case CBP _CMP_B1_

B Push Test Case CBP _CMP_B0_

signal(s) defined in the CBP complex use case data set, as well as request the expected reports

Verify that the DUT_VEN can receive the event signal(s) defined in the CBP complex use case data set and act upon the event, as well as send the expected reports

2) DUT_VEN has offered the reports required by the use case data set as part of the bootstrap process

2) Confirm that the DUT_VTN requests the appropriate offered report and that it requests each

of the data points defined in the use case dataset

1) Confirm DUT_VEN opts in to event2) Confirm DUT_VEN executes the event, monitoring that only the targeted resources shed load in proportion to the actionable complex interval signal values defined in the use case data set

3) Confirm that the DUT_VEN returns the requested report and that it contains each of the data points defined in the use case data set, and thatthe interval values returned are realistic and within the range allowed by the test harness properties

Trang 25

 Units: N/A

 Number of intervals: 2

 Interval Duration(s): 2 minutes, 2 minutes

 Interval Value(s): Simple_High, Simple_Medium

o Signal Name: BID_LOAD

 Signal Type: setpoint

 Interval Duration(s): 2 minutes, 2 minutes

 Interval Value(s): Bid_Load_Setpoint_High, Bid_Load_Setpoint_Medium

o Signal Name: BID_PRICE (informational data)

 Signal Type: price

 Units: currencyPerKW

 Interval Value(s): Bid_Price_Value

o Event Targets: ResourceIDs[0], ResourceIDs[1]

o Priority: 1

• Report(s)

o Report Name: TELEMETRY_USAGE

o Report Frequency: every 1 minute

o Report Granularity: 1 minute

o Data Point

 Report Type: usage

 Reading Type: Direct Read

 Well Known rID Property: TelemetryUsage_PowerReal_WellKnown_rID

 Well Known rID Values: TelemetryUsage_PowerReal_Range

Trang 26

Step TH_VEN TH_VTN Prompts/Notes

1 oardRegisterReport TH_VEN Note: publish a metadata report

containing the reports required by the DUT VTN for this test case

2 [oadrRegisteredReport] TH_VTN Note: This payload response will not be

used if testing a real device

4 oadrPoll

case data set

6 oadrCreatedEvent

for targeted resources and complex signal interval duration(s) as defined in use case data set Observetransition from Bid_Load_Setpoint_High to Bid_Load_Setpoint_Medium.>

request periodic report defined in use case data set>

10 oadrPoll

11 oadrCreateReport TH_VTN Note: Request report defined in use case

data set by searching test harness database for the report Verify report name, rID values, units, reportType

12 oadrCreatedReport

report are delivered before exiting test case

15 oadrUpdateReport

16 oadrUpdatedReport TH_VEN Note: Deliver two instances of report at

the requested reportBackDuration before exiting test case

17 oadrUpdateReport

1 oardRegisterReport TH_VEN Note: publish a metadata report

containing the reports required by the DUT VTN for this test case

2 [oadrRegisteredReport] TH_VTN Note: This payload response will not be

used if testing a real device

case data set

5 HTTP Ack

6 oadrCreatedEvent

for targeted resources and complex signal interval duration(s) as defined in use case data set Observetransition from Bid_Load_Setpoint_High to Bid_Load_Setpoint_Medium.>>

Trang 27

9 TH_VEN Prompt: <Configure DUT_VTN to

request periodic report defined in use case data set>

10 oadrCreateReport TH_VTN Note: Request report defined in use case

data set by searching test harness database for the report Verify report name, rID values, units, reportType

11 oadrCreatedReport

report are delivered before exiting test case

13 oadrUpdateReport

14 oadrUpdatedReport TH_VEN Note: Deliver two instances of report at

the requested reportBackDuration before exiting test case

15 oadrUpdateReport

Trang 28

23 Critical Peak Pricing Program (CPP)

1 CPP Simple Use Case

Test Case Root ID

B Pull Test Case CPP_SMP_B1_

B Push Test Case CPP_SMP_B0_

A Pull Test Case CPP_SMP_A1_

A Push Test Case CPP_SMP_A0_

signal(s) defined in the CPP simple use case data set

Verify that the DUT_VEN can receive the event signal(s) defined in the CPP simple use case data set and act upon the event

1) Confirm DUT_VEN opts in to event2) Confirm DUT_VEN executes the event, monitoring that only the targeted resources shed load in proportion to the interval signal values defined in the use case data set

 Units: N/A

 Interval Value(s): Simple_High

 Signal Target: N/A

o Event Target(s): venID

o Priority: 1

• Reports

o None

Trang 29

2 oadrPoll (B profile)

oadrRequestEvent (A profile)

case data set

4 oadrCreatedEvent

create event as defined in the use case data set>

case data set

3 HTTP Ack

4 oadrCreatedEvent

Trang 30

2 CPP Typical Use Case

Test Case Root ID

B Pull Test Case CPP_TYP_B1_

B Push Test Case CPP _TYP_B0_

signal(s) defined in the CPP typical use case data set

Verify that the DUT_VEN can receive the event signal(s) defined in the CPP typical use case data set and act upon the event

 Units: Level 0, 1, 2, 3

 Interval Value(s): Simple_Special

o Signal Name: ELECTRICITY_PRICE

 Units: USD per Kwh

 Interval Value(s): Electricity_Price_Special

o Priority: 1

• Reports

o None

Trang 31

2 oadrPoll

case data set

4 oadrCreatedEvent

case data set

3 HTTP Ack

4 oadrCreatedEvent

Trang 32

3 CPP Complex Use Case

Test Case Root ID

B Pull Test Case CPP _CMP_B1_

B Push Test Case CPP _CMP_B0_

signal(s) defined in the CPP complex use case data set

Verify that the DUT_VEN can receive the event signal(s) defined in the CPP complex use case data set and act upon the event

 Units: N/A

 Interval Duration(s):1 minutes, 2 minutes, 1 minute

 Interval Value(s): Simple_Medium, Simple_High ,Simple_Special

 Interval Duration(s): 1 minutes, 2 minutes, 1 minute

 Interval Value(s): Electricity_Price_Medium, Electricity_Price_High,Electricity_Price_Special

o Event Targets: ResourceIDs[0], ResourceIDs[1]

o Priority: 1

• Reports

o None

Trang 33

1 TH_VEN Prompt: <Configure DUT_VTN to

2 oadrPoll

case data set

4 oadrCreatedEvent

for targeted resources and complex signal interval duration(s) as defined in use case data set Observethe transition from Electricity_Price_Medium to Electricity_Price_High to

Electricity_Price_Special >

case data set

3 HTTP Ack

4 oadrCreatedEvent

for targeted resources and complex signal interval duration(s) as defined in use case data set Observer the transition from

Electricity_Price_Medium to Electricity_Price_High toElectricity_Price_Special.>

24 Distributed Energy Resources DR Program (DER)

1 DER Typical Use Case

Test Case Root ID

B Pull Test Case DER _TYP_B1_

B Push Test Case DER _TYP_B0_

signal(s) defined in the DER typical use case data set

Verify that the DUT_VEN can receive the event signal(s) defined in the CPP typical use case data set and act upon the event

1) Confirm DUT_VEN does not respond with oadrCreatedEvent

2) Confirm DUT_VEN executes the event,

Trang 34

 Interval Duration(s):2 minute each

 Interval Value(s): Electricity_Price_Medium, Electricity_Price_High (mapped toalternating intervals)

o Priority: 1

o VEN Response Required: never

o VEN Expected Response: n/a

• Reports

o None

Định dạng
Số trang	68
Dung lượng	865,78 KB