OpenADR 2.0a Certification Test Specification

OpenADR 2.0a
Certification Test Specification
Version 1.1.0


Revisions:
Version
0.50
0.51

0.96
0.97

•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•

•
•
•
•

0.98

•

0.52
0.6
0.61
0.70

0.90

0.91
0.92
0.93
0.94
0.95

0.98.1
0.98.2
0.98.3
0.98.4

0.98.5
0.98.6
0.98.7

0.99.1
1.0.0

•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•

Changes
Initial Draf
Added visual checks by test engineer for event execution.
Edits based on feedback from Rolf
Minor edits
Add negative test cases
Added perquisite notes
Misc. updates, input from Rish
Added balance of negative test cases
Added transport test cases

Updated to reflect conformance rule changes at test event
Renumbered test cases
Added security tests
General Clean Up
Minor Edits
Update several test cases, fix minor errors
Add prompts to test case definitions
Minor Edits
Changes to implementation limits
Updated conformance rule 26, added rules 50 an 51
Added test cases 280, 380, and 670
Added test case 285
Removed conformance rule test and just provided reference to the
OpenADR Profile Spec
Numerous changes related to the 03/23/12 changes to conformance rules
and schema
Completed Appendix B, test case to conformane rule mapping
Added Appendix D with a test case to event state mapping
Added missing test E2/E3_0655
Minor edits
Minor edits
Test case additional and deletions as a result of 4/2/12 test event
Minor edits
Deleted test E2_0660
Changes related to new conformance rules 65 and 66
Modified test cases E2/E3 – 0685
Added test cases E2/E3- 0432 and E0/E1 – 0267/268
Minor Edits
Minor Edits
Minor Edits

Tweaked Security Section a bit
Addition of Security Tests

2

Date/Editor
01/18/12 – JZ
01/19/12 – JZ
01/23/12 – JZ
01/24/12 – JZ
01/25/12 – JZ
01/31/12 – JZ

02/06/12 - JZ

02/10/12 – JZ
02/18/12 – JZ
02/20/12 – JZ
02/23/12 – JZ
03/02/12 – JZ
03/06/12 – JZ
03/09/12 – JZ
03/25/12 – JZ

03/26/12 – JZ
04/05/12 – JZ
04/08/12 – JZ
04/16/12 – JZ

04/17/12 – JZ

04/25/12 – JZ
05/01/12 – JZ
05/23/12 – JZ
08/09/12 – JZ


1.0.1
1.0.2
1.0.4
1.0.5

•
•
•
•
•
•
•

•

1.0.6

•
•
•
•
•
•
•

1.1.0

•

Added prompts to verify *** CertificateRequest
Minor Edits
Edits from Test Event
E3_0655, T9_1200 - Prompt has been modified.
E2_0530/E3_0530 - Prompt has been modified.
Scenario for test case E2_0527 has been modified.
Removed the following test cases
E0_0030, E1_0030, E0_0050, E1_0050, E0_0084, E1_0084, E0_0088,
E1_0088, E0_0295, E0_0350, E1_0350, E0_0382, E1_0382, E0_0386,
E1_0386, E2_0464, E3_0464, E2_0466, E3_0466, E2_0476, E3_0476,
E2_0478, E3_0478.
Removed the following security tests.
S0_1310, S0_1320, S0_1330, S0_1340, S0_1350, S0_1360, S0_1370,
S1_1410, S1_1420, S1_1430, S1_1440, S2_1510, S2_1520, S2_1530,
S2_1540, S2_1550, S2_1560, S2_1570, S3_1610, S3_1620, S3_1630,
S3_1640, S3_1650, S3_1660

08/09/12 – JZ
08/09/12 - JZ
08/27/12 - JZ
2/12/14 – EP,
BD

Removed all references to startBefore
Mantis 139: Added Adjacent Event Execution - E0_0292/E1_0292

Mantis 164: Delete Test Case E0_0325/E1_0325 - MarketContext can have a
wild card, so can't do negative test
Mantis 166: Modified conformance rule check to verify that "Z" is at the
end of every dateTime string
Mantis 173: Conformance rule check modified to validate ordering of
intervals in reports
Mantis 186: Added test cases to verify expired certificates: cases S1_1405
and S3_1605
Revised tests E1_0285, E0_0285, E2_0510, E3_0510 and deleted tests
E2_0520, E3_0520, E2_530, and E3_0530 as the result of changes to rule
regarding overlapping events

2/22/16 - JZ

Version Change Only

3


Table of Contents

4


Introduction
This purpose of this document is to define a set of test cases that systems implementing the OpenADR
2.0a profile must successfully pass in order to obtain certification.

Terms and Acronyms
The following terms and abbreviations are used in this document:

Term
DR
DUT
DUT_VEN
DUT_VTN
TH
TH_VEN
TH_VTN
VEN
VTN

Description
Demand Response
Device Under Test – This is used to refer to the sofware
implementation of OpenADR and any supporting
hardware necessary to execute the sofware
Device Under Test VEN
Device Under Test VTN
Test Harness - A sofware implementation of OpenADR
playing the role of a VEN or VTN for the purpose of
running test cases
Test harness playing the role of the VEN
Test harness playing the role of the VTN
Virtual End Node
Virtual Top Node

Scope
OpenADR 2.0a is an application layer message exchange specification used for two-way communication
of Demand Response (DR), price, and Distributed Energy Resource (DER) signals between the electricity
service provider and their customers. OpenADR 2.0a is defined in the following documents:

•
•

The OpenADR 2.0a Profile Specification, Revision 1.1
The OpenADR 2.0a schema

The testable requirements are defined as a set of conformance rules in the OpenADR 2.0a Profile
Specification. These rules are referenced in both OpenADR 2.0 PICS and this document. Appendix B
provides a mapping between each of these conformance rules and the test cases defined in the test
specification.
The scope of the test cases will focus on validating the successful exchange of messages between VTNs
and VENs, or VTN/VEN pairs, validating that any exceptions are handled gracefully and without service
interruptions, and that security mechanism are properly implemented. Validating the functional
behavior of the DUT in response to payload content is out of scope for the certification tests. For
instance, the test cases will test that a VEN acknowledges the receipt of a DR Event but it will not
validate that the VEN actually sheds load as a result of this message.

5


For product certification, the certification test suite will be will be run over top of the specific transport
protocols supported by the DUT. If multiple transports are supported by the DUT, the full conformance
test will be run over one transport and a representative set of test cases will be run over the remaining
transports (See Appendix C). Conformance testing of the supported transports is out of scope for the
certification tests. However, limited testing will be done to validate OpenADR specific requirements for
implementation of the transports, such as the inclusion of specific http headers.
The certification test suite will be run utilizing each of the security mechanisms supported by the DUT.
Conformance testing of the security mechanisms is out of scope for the certification tests. However,
limited testing will be done to validate OpenADR specific configuration requirements for implementation
of the security mechanisms, such as use of x509 certificates, TLS versions, and cipher suites.

Exception handling tests will be limited to a small set of representative real world scenarios. The intent
of these test cases will not be to exhaustively test all possible exception scenarios, but to validate that
the DUT has sound exception handing capabilities. For instance, a test might validate that the DUT
trigger an error if it is sent a payload with an unknown VEN or VTN ID.
Boundary and limit testing will utilize values that are deemed to be practical from a test execution
perspective and typical from an implementation perspective, as specific implementation limits have not
been defined by the OpenADR 2.0a Profile Specification. For instance, testing that includes a
responseDescription string would use as most a few hundred characters, not 10’s of thousands.
Optional elements will be testing will be tested as follows: Most payloads will include only mandatory
elements only. Where practical all optional elements will be used in a single payload. Otherwise, the
entire set of optional payload elements will be exercised cumulatively across the set of test cases for a
given payload. Optional elements do not need to be included in the payload, but if they are, the VEN or
VTN receiving the payload must understand and act upon those optional elements

Test Methodology
The test harness will play the role of the opposite party (VEN or VTN) in interactions with the DUT. Each
test case will define a set of perquisites, a test scenario consisting of a sequence of VEN/VTN message
exchanges, and an expected result. Execution of that test scenario will result in payload exchanges
between the DUT and the Test Harness to be analyzed. The analysis will consist of the following:
•

•
•
•

The message interaction patterns are as expected. This includes…
o Correct response payloads. For instance, receiving a oadrCreatedEvent payload in
response to a oadrRequestEvent would not be correct.
o Appropriate request payloads. For instance a request containing oadrResponse payload
would not be correct.

That payloads contain well formed XML
That payloads conform to the alliance OpenADR 2.0a schema
That the specific conformance rules defined in the OpenADR Profile Specification are followed.
For instance, an OpenADR 2.0a conformance rule states that the payload element signalType
must contain the string “simple”. This is not validated by the schema, so it is done as a separate
conformance rule analysis step.

6


•

That the intent of the test case is met. The test case may expect the VEN to send an optType of
“optOut” and if this is not received, the test case will fail.

Note that some of the OpenADR conformance rules can be validated by simply analyzing the payloads of
all message exchanges that occur during execution of the certification test suites. These rules are
summarized in Appendix A. Other conformance rules will require specific test scenarios to validate.
A few test cases will require the test engineer executing the test to observe the behavior of the device
under test in order to determine the pass fail status.

Test Organization
Each test case will be classified into one or more groups as follows:
• VEN_Push –Tests where the DUT target is a VEN in a push message exchange pattern
• VTN_Push - Tests where the DUT target is a VTN in a push message exchange pattern
• VEN_Pull – Tests where the DUT target is a VTN in a pull message exchange pattern
• VTN_Pull – Tests where the DUT target is a VTN in a pull message exchange pattern
• Positive - This will be the bulk of the tests on successful message exchange. A small subset of the
positive tests will be tests focused on determining if the DUT can handle values at the
boundary/limits of what is typical from an implementation perspective.

• Negative - Tests focused on the devices ability to gracefully handle unexpected message
exchange scenarios and payload contents
• Transport - Tests for OpenADR 2.0a specific transport requirements
• Security - Tests for OpenADR 2.0a specific security requirements
Test case numbering uses the following pattern: XY_ZZZZ
X = A letter designating the service or special test type
• E= EiEvent Tests
• T = Transport Tests
• S = Security Tests
Y = A digit indicating the type of implementation:
0 = VEN Push
1 = VEN Pull
2 = VTN Push
3 = VEN Pull
9=N/A
ZZZZ = A numeric sequence number for the test case with initial increments of 10, with test
cases that use the same definition for both push and pull sharing the same number.
Test cases definitions within this document will be organized by operational sequences and further
subdivided by role and exchange pattern (VEN/VTN, Push/Pull). Each test case will be defined in a table
as shown below. The narrative text on the right describes each row in the table. Optional test cases will
be indicated by the string “(Opt)” in the title.
7


8


Test ID - name, Sequence (Opt)
Prerequisites

Scenario

Expected Results
{Notes}
Test Engineer observations

Any prerequisite actions required prior to the execution of the test
scenario. This may include configuring the DUT VTN with specific events,
or instructions on the specific payload values to be used in payloads
sent by the test harness. Prerequisite pending or active events in the
VTN or VEN will be programmatically generated by the test case unless
indicated otherwise in the test case.
The specific message exchange scenario required. Note that conditional
steps based on whether the DUT supports a push or pull model are
enclosed in brackets {}
In addition to the common pass verdicts, the specific expected behavior
as the result of the test scenarios execution.
Optional support required to run test case, objectives of test case, and
other notes to clarify the implementation or execution of the test case.
Instruction to the test engineer to observe the DUT to confirm the
status of the event execution.

DUT Configuration Requirements
In order for many test cases to run successfully, the DUT must be capable of being configured to initiate
action or respond to requests. For instance, there should be a way to cause a DUT_VEN to respond to an
event with an optOut. The following is a list of required configurable device behavior for DUTs being
submitted for certification.
•
•
•

•
•
•
•
•

•
•
•

VEN implementations submitted for certification testing must provide some visual means for a
test engineer to determine that an event is currently active
Some backchannel way of setting the marketContext URI so that the DUT and test harness can
interact with respect to the same marketContext.
A way to seed a VTN with events and to modify and/or cancel the events
A way to opt out of an event with a VEN
A way to trigger requests including oadrRequestEvent, and send oadrDistributeEvent
A way to initialize the DUT such that all events are cleared from the data store
A way to configure or determine the assigned VEN or VTN ID
If supported, to configure additional identification values used by the VEN and VTN
o groupID
o resourceID
o partyID
o VenID
A way to set the polling frequency on the VEN.
A way to set responseRequired for event configuration on VTN

9

VTN Test Interface
Testing of a VTN requires various event scenarios to be configured on the VTN. In order to provide a
simple and easy to use interface for the test house that will be doing the certification, the vendor
submitting the device for certification must provide the following interface:
•
•
•

•

A drop down menu listing an option for each point in the test case execution where a VTN
control panel configuration or action is requested via a prompt.
The naming convention for the drop down menu should be the test case name followed by an
index indicating the prompt sequence within the test case, such as E3_0420_FirstPrompt for the
first prompt in the test case requiring operator intervention.
Submitting or clicking on the menu option should do one of the following:
o The first request for operator intervention should clear the data store of any pending or
active events and then add the requested event(s)
o Subsequent prompts to modify, cancel, or add additional events should be executed as
instructed when the menu option is selected
o Prompts in push scenarios to resend the events in the existing data store should do just
that.
Events should be grouped by common push or pull functionality and sorted alphabetically in the
menu.

DUT Implementation Limits
The implementation being submitted for certification must support the following minimum capabilities
in order to successfully execute the certification test suite. Note that these limits do not imply minimum
market needs for an “a” profile implementations.
•

•
•
•
•
•

responseDescription, vtnComment – 250 characters
venID, vtnID, requestID, uid, groupID, partyID, resourceID, eventID – 50 characters
SignalName, MarketContext – 100 characters
Maximum size of oadrDistributeEvent: A payload with 4 events each with 3 intervals per signal
and a payload with 1 event containing 24 intervals
Number of instances of resourceID in eiTarget – 4
Number of eventResponses in oadrResponse - 4

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 Verdict
o Test case scenario runs to completion
AND
o All exchanged payloads validate against the OpenADR 2.0a schema
AND
o All OpenADR 2.0a conformance rule validation checks in Appendix A pass
10


•

Common fail verdicts
o Test case scenario fails to run to completion because of a timeout, transport error, or
other problem
OR
o OpenADR 2.0 payload schema violation
OR
o OpenADR 2.0a conformance rule validation failure
OR
o 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 shall be considered a failure
verdict. As such, failure verdicts will only be defined in the test case definition if there is
some unique non-intuitive circumstance that should be considered a failure.

Items with Limited Testing
The following items are tested, but with a limited scope:
• As there is no programmatic way to determine when or if the DUT_VEN is executing an event,
testing of tolerance, eiNotification, x-eiRampUp, x-eiRecovery, and dtstart is limited to sending
values to the device and determining that no errors occur and the device opts into events as
expected. A limited set of test cases will construct scenarios where the test engineer executing
the test case can observe a visual indicator on the VEN to determine when an event is active,
which will allow some validation of correct behavior with respect to dtstart, duration, and
tolerance.
• Only “level” and “price” are used as values for signalType
• EiTarget in oadrDirstributeEvent is tested with all matching sub-elements and all non-matching
sub-elements. Although conformance rules state that sub-elements should be OR’d together to
determine a match, the rules also state that the VEN’s behavior with respect to eiTarget is
implementation dependent. This creates a somewhat ambiguous situation with respect to a
partial match and therefore is not tested.
• Testing of multiple VTNs interacting with a single VEN will only be tested in the push direction

from a single common IP address, providing that the DUT VEN supports configuration of multiple
VTN relationships.
• Conformance Rules 16, 31, 32, and 33 have limited or no test coverage as documented in
Appendix B
• Not all possible permutations of event status, modification number, response required, previous
acknowledgement, and VEN response are tested as documented in Appendix D
• Test case E0_0185 attempts to push two separate events to the VEN before the VEN responds
with an oadCreatedEvent to the first event. Due to limitations in the Test Harness framework,
the test imposes a 5 second delay between the first event push and the second push.

11


Application Layer Test Cases
Each table below represents the definition of a single test case. Tests are organized by operational
sequence. Most test case definition tables map to two test case numbers, one for push and one for pull.
Braces {} are used to indicate conditional portions of the scenario based pull support or conditional
responses from the DUT.

oadrDistributeEvent Operational Sequence
The test cases in this section all utilize the following operational sequence:
Payload
VEN (Pull only)
VTN
VEN (push only)
VEN (async)
VTN

{oadrRequestEvent }
oadrDistributeEvent

{Transport Acknowledgement }
oadrCreatedEvent
OadrResponse

Three types of oadrDistributeEvent(s) will be used in these test scenarios:
•
•
•

Critical Peak Pricing (CPP) – 3 intervals
24_Prices – 24 one hour intervals, notification 2 hours
Dispatch – 1 interval with a duration of 0 and notification time of 0

Unless otherwise specified, the following defaults will be used for payloads generated by the test system:
oadrDistributeEvent:
• Mandatory elements unless otherwise specified in the test description
• marketContext as configured in the test system
• oadrResponseRequired set to always
• eiTarget with no subelements
• dtstart set to currentTime +2 minutes
• x-eiNotification set to a duration of 1 minute
• signalType for CPP and Dispatch set to level
• signalType for 24_Prices set to price
• signalID set to a placeholder value.
• Overall duration for CPP set to 3 minutes
• Interval durations for CPP set to 1 minute
• Interval signalPayload set to a repeating sequence of 1, 2, 3, 2, 1
• eiResponse element with mandatory elements included if responding to a oadrRequestEvent
• requestID = unique value
oadrCreatedEvent:

• Mandatory elements only unless otherwise specified in the test description

12


•

Respond with a oadrCreatedEvent to all oadrDistributeEvent payloads unless the test case
description states differently with regards to oadrResponseRequired
oadrRequestEvent:
• Mandatory elements only unless otherwise specified in the test description
oadrRequestEvent, oadrResponse:
• requestID set as an empty element
• Mandatory elements only

VEN Push/Pull Positive Test Scenarios
The VEN Push test cases are functionally identical to the VEN Pull tests cases in a pull scenario the
exchange sequence is initiated by the DUT_VEN using an oadrRequestEvent .
Each of the test cases below show a conditional oadrRequestEvent as the first operation in the sequence
which applies to the pull scenario only and a conditional transport acknowledgement which applies to
the push scenario only.

13


E0_0020 – No Events, VEN Push oadrDistributeEvent (Opt)
E1_0020 – No Events, VEN Pull oadrDistributeEvent
Prerequisites
Scenario

{DUT_VEN: oadrRequestEvent }
TH_VTN: oadrDistributeEvent
{DUT_VEN: Transport Acknowledgement}

Expected Results

1)Common Pass/Fail verdicts
2)No oadrCreatedEvent returned

Notes

-No events returned to the VEN in the oadrDistibuteEvent payload

14


E0_0040 –Send 24_Prices Event, VEN Push oadrDistributeEvent
E1_0040 –Send 24_Prices Event, VEN Pull oadrDistributeEvent
Prerequisites
- DUT_VEN has no pending or active events
Scenario

{DUT_VEN: oadrRequestEvent }
TH_VTN: oadrDistributeEvent – 24 Prices Event, “always”
{DUT_VEN: Transport Acknowledgement}
DUT_VEN: oadrCreatedEvent
TH_VTN: oadrResponse , success
Note: set the responseRequired element in the oadrDistributeEvent to “always”
for this test case. Set signalType to “prices”

Expected Results

1)Common Pass/Fail verdicts
2)Received oadrCreatedEvent with optType equal to optIn

Notes

-A basic 24 hour pricing event transaction

15


E0_0060 –Send Event with Optional Elements, VEN Push oadrDistributeEvent
E1_0060 –Send Event with Optional Elements, VEN Pull oadrDistributeEvent
Prerequisites
- DUT_VEN has no pending or active events
Scenario

{DUT_VEN: oadrRequestEvent }
TH_VTN: oadrDistributeEvent – CPP Event
{DUT_VEN: Transport Acknowledgement}
DUT_VEN: oadrCreatedEvent
TH_VTN: oadrResponse , success
Note: TH_VTN initialized with one new CPP Event containing the following
optional elements:
• responseDescription = “success” (pull only)
• priority =0
• testEvent = false
• vtnComment = “comment”
• startAfter = 1 minute

• x-eiRampUp = 1 minute
• x-eiRecovery = 1 minute (With a leading minus sign)
For Push, include the eiResponse element in the oadrDistibuteEvent payload.

Expected Results

1)Common Pass/Fail verdicts
2) Received oadrCreatedEvent with optType equal to optIn

Notes

-Include some optional elements in the oadrDistributeEvent payload.

16


E0_0070 –Send Event with EiTarget subElements, VEN Pull oadrDistributeEvent
E1_0070 –Send Event with EiTarget subElements, VEN Pull oadrDistributeEvent
Prerequisites
- DUT_VEN has no pending or active events
Scenario

Prompt: “If supported, the VEN and test harness properties should be configured
with matching target elements including groupId, resourceID, venID, and partyID. If
not supported by the DUT, leave test harness properties for these elements
undefined.”
{DUT_VEN: oadrRequestEvent }
TH_VTN: oadrDistributeEvent
{DUT_VEN: Transport Acknowledgement}
DUT_VEN: oadrCreatedEvent(s)

TH_VTN: oadrResponse , success
Note: TH_VTN initialized with one new CPP Event containing the following
optional eiTarget subelements. If the DUT_VEN could not be configured to
specify a value for one of these elements, include an empty element
• groupID
• resourceID
• venID
• partyID

Expected Results

1)Common Pass/Fail verdicts
2) Received oadrCreatedEvent with optType equal to optIn

Notes

-Matching eiTarget subelements sent as part of payload to VEN.
-Even though response to eiTarget is implementation dependent, the VEN should
respond to the event as there is a matching condition and oadrResponseRequired is
set to always.

17


Event State Sequence Tests, VEN Push oadrDistributeEvent
Event State Sequence Tests, VEN Pull oadrDistributeEvent
Note that E0 tests a push and E1 tests are Pull
Test ID
EventStatus
Mod Number

ResponseReq
Previously Ack'd
E0_0082
Pending
0
always
No
E1_0082
E0_0086
Pending
0
never
No
E1_0086
E0_0090
Pending
1
always
No
E1_0090
E0_0092
Pending
1
never
No
E1_0092
E0_0094
Active
0
always

No
E1_0094
E0_0096
Active
0
never
No
E1_0096
E0_0098
Active
1
always
No
E1_0098
E0_0100
Cancelled-Pend
1
always
No
E1_0100
E0_0102
Cancelled-Act
1
always
No
E1_0102
E0_0104
Cancelled - Pend
1
never

No
E1_0104
Prerequisites
- Tests designated with Mod=1 must have a new event sent to the DUT_VEN with
an acknowledgement before initiating the primary test sequence on that event
-Tests designated as previously ack’d = Yes ,must send the designated test sequence
as both a prerquisite to get the acknowledgement, then again as the primary
sequence.
Sequence

Prerquisite if required…
{DUT_VEN: oadrRequestEvent }
TH_VTN: oadrDistributeEvent – CPP Event
{DUT_VEN: Transport Acknowledgement }
DUT_VEN: oadrCreatedEvent(s)
TH_VTN: oadrResponse , success
5 second delay
Primary Test Sequence…
{DUT_VEN: oadrRequestEvent }
TH_VTN: oadrDistributeEvent - same CPP Event
{DUT_VEN: Transport Acknowledgement }
DUT_VEN: oadrCreatedEvent(s)
TH_VTN: oadrResponse , success
18


Notes:
1)Use CPP event templateS
2)Pending events should be set 5 minutes in the future
3) Pending event modifications should be to set to alter the dtstart time to one

minute further in the future.
4)Active events should be set 1 minute in the past
5)Active event modifications should extend the overall duration and last interval
duration by one minute
Expected Results

1)Common Pass/Fail verdicts
2) For events with responseRequired set to never, the ven should not respond.
3)For events with responseRequired set to always, the DUT should do an optIn
with correct modification number returned in eventResponse.

Notes

-Iterate through a number of events involving different EventStatus,
modificationNumber, responseRequired, and previously acknowledged states

19


E0_0110 –Send new event with modificationNumber >0 , VEN Push oadrDistributeEvent
E1_0110 –Send new event with modificationNumber >0 , VEN Pull oadrDistributeEvent
Prerequisites
- DUT_VEN has no active events
Scenario

{DUT_VEN: oadrRequestEvent}
TH_VTN: oadrDistributeEvent – Mod = 3
{DUT_VEN: Transport Acknowledgement}
DUT_VEN: oadrCreatedEvent(s)
TH_VTN: oadrResponse , success

Note: TH_VTN to send CPP event with the modification number set to 3

Expected Results

Notes

1)Common Pass/Fail verdicts
2) Received oadrCreatedEvent with optType equal to optIn
3) As the DUT_VEN has not seen the eventID before, it should treat it as a new
event even though the modification number is greater than 0.
Send a new event whose modification number is greater than 0 simulating a
scenario where the VEN may have missed the initial new event transmission.

20


E0_0130 –Send test event , VEN Push oadrDistributeEvent
E1_0130 –Send test event , VEN Pull oadrDistributeEvent
Prerequisites
- DUT_VEN has no pending or active events
Scenario

Prompt: “Make sure that the test harness properties have been configured with an
implementation specific testEvent string to send as part of the payload for this test
case.”
{DUT_VEN: oadrRequestEvent }
TH_VTN: oadrDistributeEvent – Test Event
{DUT_VEN: Transport Acknowledgement}
DUT_VEN: oadrCreatedEvent(s)
TH_VTN: oadrResponse , success

Expected Results

Notes

Note: TH_VTN sends a new CPP event and the testEvent element set to a value
other than “false”, pulled from the test harness properties
1)Common Pass/Fail verdicts
2) Received oadrCreatedEvent with optType equal to optIn
3) The assumption is that the event will execute normally, however the VEN will not
initiate DR actions based in the signaling (validating this is out of scope)
-Send a test event and verify the message exchange proceeds as if a real event is
occurring.

21


E0_0180 –New, modified, Cancelled in one payload , VEN Push oadrDistributeEvent
E1_0180 –New, modified, Cancelled in one payload , VEN Pull oadrDistributeEvent
Prerequisites
- DUT_VEN has no pending or active events
Scenario

{DUT_VEN: oadrRequestEvent }
TH_VTN: oadrDistributeEvent – two new events
{DUT_VEN: Transport Acknowledgement}
DUT_VEN: oadrCreatedEvent(s)
TH_VTN: oadrResponse , success
{DUT_VEN: oadrCreatedEvent(s) }
{ TH_VTN: oadrResponse , success }

{DUT_VEN: oadrCreatedEvent(s) }
{ TH_VTN: oadrResponse , success }
Delay for 5 seconds – push only
{DUT_VEN: oadrRequestEvent }
TH_VTN: oadrDistributeEvent – new, cancelled, modified
{DUT_VEN: Transport Acknowledgement}
DUT_VEN: oadrCreatedEvent(s)
TH_VTN: oadrResponse , success
{DUT_VEN: oadrCreatedEvent(s) }
{ TH_VTN: oadrResponse , success }
{DUT_VEN: oadrCreatedEvent(s) }
{ TH_VTN: oadrResponse , success }
Note: The TH_VTN sends two new events. Then a second oadrDistribute event is
sent containing one new event, a modification of a previous event, and a
cancellation of a previous event. Configuration of events as follows:
- DUT_VEN has two CPP pending events with dtstart at current time + 5 minutes
and current time + 10 minutes.

Expected Results

Notes

-TH_VTN initialized to send 3 events in a single payload as follows:
• A new CPP event with dtstart at current time + 15 minutes
• A modified version of pending DUT_VEN event. Extend dtstart by one
minute
• A cancellation of the second pending DUT_VEN event
1)Common Pass/Fail verdicts
2) Received oadrCreatedEvent with optType equal to optIn for the eventID’s related
to the new and modified event, and optType equal to optIn or optOut for the

cancelled event.
3) From one to three oadrCreated events may be returned containing the optType
values for the 3 events.
-A more complex scenario with a single oadrDistributeEvent payload containing
new, modified, and cancelled events.
22


E0_0185 –oadrCreatedEvent Response, VEN Push oadrDistributeEvent
Prerequisites
- DUT_VEN has no pending or active events
Scenario

TH_VTN: oadrDistributeEvent – one new event
DUT_VEN: Transport Acknowledgement
TH_VTN: oadrDistributeEvent – old event and one new event
DUT_VEN: Transport Acknowledgement
DUT_VEN: oadrCreatedEvent – Response to 1st payload
TH_VTN: oadrResponse , success
DUT_VEN: oadrCreatedEvent(s) - Response to 2nd payload
TH_VTN: oadrResponse , success
{DUT_VEN: oadrCreatedEvent(s) }
{ TH_VTN: oadrResponse , success }
Note: The TH_VTN sends two oadrDisributeEvent payloads without waiting for
the asyc oadrCreatedEvent from the 1st payload. The VEN should respond to each
payload independently.
Set up the first event as a CPP pending event with dtstart at current time + 5
minutes and duration of 5 minutes
Set up the second payload with a new event with dtstart at current time + 20
minutes and duration of 5 minutes. The second payload must also contain the

event from the 1st payload

Expected Results

1)Common Pass/Fail verdicts
2) Received oadrCreatedEvent with optType equal to optIn for the eventID from the
first payload.
2) Received oadrCreatedEvent with optType equal to optIn for the eventID from the
second payload.
3) From one to three oadrCreated events may be returned containing the optType
values for the 3 events.

Notes

-Send two consecutive oadrDistribute events with no intervening delay in order to
see if the VEN responds to both payloads independently.

23


E0_0190 – Static requestID, VEN Push oadrDistributeEvent
E1_0190 – Static requestID, VEN Pull oadrDistributeEvent
Prerequisites
- DUT_VEN has no pending or active events
Scenario

{DUT_VEN: oadrRequestEvent }
TH_VTN: oadrDistributeEvent
{DUT_VEN: Transport Acknowledgement}
DUT_VEN: oadrCreatedEvent(s)

TH_VTN: oadrResponse , success
Delay 5 seconds – Push Only
{DUT_VEN: oadrRequestEvent }
TH_VTN: oadrDistributeEvent – Same request ID
{DUT_VEN: Transport Acknowledgement}
DUT_VEN: oadrCreatedEvent(s)
TH_VTN: oadrResponse , success
Note: The TH_VTN sends a new CPP Event, follow by a second CPP event that has
the same requestID as the previous oadrDistributeEvent message.

Expected Results

1)Common Pass/Fail verdicts
2)Received oadrCreatedEvent with optType equal to optIn in both instances

Notes

-Confirm that the VEN does not require the requestID contained in the
oadrDistributeEvent payload to be unique

24


E0_0200 – Limit Values, VEN Push oadrDistributeEvent
E1_0200 – Limit Values, VEN Pull oadrDistributeEvent
Prerequisites
- DUT_VEN has no pending or active events
dtstart values set respectively to current time plus 5 minutes, 10 minutes, 15
minutes, and 20 minutes
Scenario

{DUT_VEN: oadrRequestEvent }
TH_VTN: oadrDistributeEvent – four events, limits
{DUT_VEN: Transport Acknowledgement}
DUT_VEN: oadrCreatedEvent
TH_VTN: oadrResponse , success
{DUT_VEN: oadrCreatedEvent(s) }
{ TH_VTN: oadrResponse , success }
{DUT_VEN: oadrCreatedEvent(s) }
{ TH_VTN: oadrResponse , success }
{DUT_VEN: oadrCreatedEvent(s) }
{ TH_VTN: oadrResponse , success }
Note-TH_VTN sends a payload with 4 new CPP events (3 intervals each) containing
the following values:
•
•
•
•

responseDescription, vtnComment – 250 characters
vtnID, requestID, groupID, partyID, resourceID, eventID, eventID – 50
characters
SignalName, MarketContext – 100 characters
In eiTarget 4 instances of groupID, PartyID, and resourceID, and one
matching VEN ID.

Expected Results

1)Common Pass/Fail verdicts
2)Received oadrCreatedEvent with optType equal to optIn

Notes

-Confirm the implementation limits from the Certification test do not cause any
issues with the DUT_VEN

25