OpenADR 2.0b Certification Test Harness Users Manual

OpenADR 2.0b
Certification Test Harness
User's Manual
Version 1.1.1

1


Revisions:
Version
1.0.0
1.0.1
1.0.2
1.0.3
1.0.4

1.0.6
1.0.7

•
•
•
•
•
•
•
•
•
•

1.1.0

1.1.1

•
•

1.0.5

Changes
Initial Release
Updates
Updates
Corrected typo in property disable_MarketContext_Check
Added utility class VTNPollQueue_Clear to clear the VTN poll queue
maxSocketTimeout property has been added.
Updated Appendix D for 1.0.5 release
Deleted Appendix E and open issues documented here have been resolved
Updated Appendix D for 1.0.6 release. ECC certificate support is added.
SHA1 removal
Many other edits
Version Change
HTML Logfile Added

2

Date/Editor
06/28/13 – JZ
07/25/13 - SK
08/06/13 – SK
08/06/13
08/22/13

09/11/13 - JZ
03/19/14 - SK
11/1/15 – JZ
2/22/16 – JZ
6/26/16 - JZ


Table of Contents

3


Quick Start
The following steps will get the test harness running in a localhost environment in just a few
minutes:
Step 1 - Install a version of Eclipse on your computer (See Eclipse Configuration on page 9).
Step 2 - Unzip the Eclipse project OpenADR20bCertTest_v1_x_x into your eclipse working
directory. Import the project into your Eclipse environment.
Step 3 - Start Eclipse and expand the tree in Package Explorer src/testcases/push/registerParty/
Step 4 - Run a VEN registration test case against a VTN test in a self test mode over http as
follows (Shortcut: run SelfTest_Register in util):
• Run ven/N0_5020_TH_VTN_1
• Click Resume on first two prompts
• Run vtn/N0_5020_TH_VEN
• Click Resume on prompt
• Watch the console windows as test cases execute
Step 5 - To view a detailed transaction log (starting with TraceLog_xxx), you can look in the log
folder off the Eclipse root (you might need to refresh the folder) or point a browser at the
logfile.html file in the same folder for a prettier interface. (Shortcut: run LogFiles_View in util)
Step 6 - Now let's run the same tests over XMPP. Unzip openfire_Windows_xxxxx or

openfire_Linux_xxxxx file into a system folder.
Step 7 - Start Openfire from the bin directory. On Windows use openfire.exe or
"OpenADR_Start.Bat" if you encounter issues. On Linux use"./openfire start".
Optional Step 8 - You can start the Openfire console at 127.0.0.1:9090 from a browser. Enter
username as admin and password as password. Ignore warning about RSA cert not matching
server domain.
Step 9 - Modify the selftest properties located in the Eclipse Package Tree at src/properties/
vendor.selftest.openadrconfig.properties as follows: Transport_Type=XMPP.
Step 10 - Repeat steps 3, 4, and 5 to run the same registration test case over XMPP.
You have now successfully run test cases across both transports! Suggested next steps:
•
•
•

Review Appendix B to get a feel for how the test harness is configured.
Skim the balance of this user manual so you know what information is available.
Set up your device, configure the test harness, and start running tests!
4


Overview
OpenADR 2.0b is an application layer message exchange protocol used for two-way
communication of Demand Response (DR), price, and Distributed Energy Resource (DER) signals
between the electricity service provider and its customers. The technical requirements for the
protocol are defined in the OpenADR 2.0b Profile Specification.
Devices that implement OpenADR 2.0b must pass a certification test. The requirements for the
certification test are spelled out in the OpenADR 2.0b Certification Test Specification. Each test
case defined in the test specification is implemented in the OpenADR 2.0b Certification Test
Harness.
All OpenADR 2.0b interactions are between a Virtual End Node (VEN) and a Virtual Top Node

(VTN) using either a push or pull exchange model. The functionality of OpenADR 2.0b is split
across 5 services which include EiEvent, EiOpt, EiReport, EiRegisterPart, and OadrPoll. When a
test is run, the test harness plays the role opposite that of the device under test. For instance,
when testing a VEN Push implementation, the test harness will play the role of a VTN Push
implementation.
This document describes how to use the OpenADR 2.0b Certification Test Harness to execute
one or more sets of tests, the sum of which represents the OpenADR certification requirements.
Test Cases contained in the test harness are organized in a hierarchy as follows:
•

src
o

testcases
 Exchange Model (push or pull)
• Service (event, report, registerparty, opt, or general)
o Role (VEN or VTN)
 Test case 1
 Test case 2
 Etc.

Test cases listed under "DR_PRogram_Guide" are not part of the message exchange
certification and they may be ignored . The specific sets of tests required to pass certification
are outlined in the OpenADR 2.0b PICS document. In order to successfully pass each of the
certification tests, the device under test (DUT) must have certain capabilities as outlined in the
following sections of the OpenADR 2.0b Test Specification:
•
•

DUT Configuration Requirements

DUT Implementation Limits

The Test Harness is built on top of the open source Eclipse integrated development
environment. The test harness consists of a large body of code, referred to as the Test

5


Framework that implements the OpenADR 2.0 protocols, and a series of small test case
programs that implement the test case-specific logic.
Running a test case is as simple as selecting the test case from the Test Harness “Package
Explorer” and clicking the green Run toolbar button, watching the text case execute in the
Console window, and reviewing the test results in a browser. The following figure shows the
major functional areas of the Test Harness GUI.
The run button is
used to execute a
test case

This is the test
code which the
user should not
need to alter

Test Cases
appear in
the Package
Explorer

Figure 1 – Eclipse IDE

6

During test
execution progress
indications will
appear in the
console window


Once a test case has completed execution, a pass/fail indication is shown in the Console window.
Detailed transaction logs are recorded for each test execution, and these transaction logs can be used to
isolate the cause of a test case failure. Figure 2 shows the Test Result Summary screen. When a tracelog
link is clicked, a detailed transaction log will be displayed in a text editor as show in Figure 3.

Figure 2 – Test Result Summary

Figure 3 – Transaction Log
7


Installation
Java
The security test cases require the test harness be run on top of Java 1.7. This can be obtained
at the following site:
/>
Eclipse IDE for Java Developers
The test harness uses the Eclipse Juno IDE for Java Developers, which can be downloaded from
the following site:
/>
Note that the test code is not sensitive to the version of Eclipse that is used as long as it is Juno

or later. The narrative in this user’s guide presumes the Juno version of Eclipse is being used.

Eclipse Configuration
Two changes need to be made to the Eclipse environment (Fig. 4a and Fig. 4b). From the Main
Menu select Window, Preferences, Java. Expand Compiler, and then select the Errors/Warning
option. On the right panel under Deprecated API, change the Forbidden reference to Warning.
Also from Window, Preferences, select General, Workspace, and check Refresh using native
hooks or polling.

Figure 4a – Eclipse Configuration Setting

8


Figure 4b – Eclipse Configuration Setting

Test Harness installation
The OpenADR 2.0b Test Harness is distributed as an Eclipse project zip file. The process for
installing the Test Harness in the Eclipse workspace is as follows:
•
•

•
•

Extract the project into a temporary directory.
Rename the project folder to something unique, and then copy the project directory into
the Eclipse workspace directory. Note that the project folder name will become the
project name inside Eclipse.
Use the Eclipse File, Import, General, "Existing Project into Workspace" option.

You can then move over any property settings from the previous release and then delete
the previous release if desired.

It is easier to traverse the test cases when running tests if you use the drop down menu in the
Package Explorer to change the package presentation to hierarchical (Fig. 5).

9


Figure 5 – Package Presentation

Openfire Installation
When testing a VEN over XMPP, the test harness VTN configuration includes an XMPP server
called Openfire, and this server must also be installed. Note that when testing a VTN, the test
harness will be communicating with the XMPP server that is part of the device under test.
Create a folder on your local system and unzip one of the following Openfire packages to that
folder:
•
•

Windows = openfire.zip
Linux = openfire.tar.gz

Openfire can be started from the Openfire bin directory using openfire.exe (if you encounter
issues use "OpenADR_Start.Bat" for Windows) or on Linux with "./openfire start". The Windows
OpenFire, if started with the batch file, will run in a DOS window, as a special startup script was
needed to get it to run under Java 1.7 on some systems.

Configuration
In order for the test suite to work with a device under test, a number of properties need to be

set in the test harness, Openfire server, and the device under test. In general the following types
of settings need to be configured:
•

Information necessary to connect to test harness to the device under test, including IP
addresses, port numbers, user names, passwords, and security configuration
10


•

OpenADR specific Information necessary for VENs and VTNs to interoperate, including
VEN IDs, market context, available resources, etc.

Appendix A provides detailed information on appropriate settings for various test combinations.
Appendix B provides a summary of all configuration settings. Appendix C provides a listing of
one of the security profile configuration files, which should normally not need to be changed.
The following sections focus on how to make the changes, not what the changes themselves
should be.

Test Harness Configuration Mapping
The test harness configuration properties are located under “src.properties”. The configuration
file openadrconfig.properties acts as a pointer to vendor-specific configuration files. The
contents of this file looks as follows:
####################################################
# OpenADR Properties
# Test harness configuration properties are read from
# the file point to by the Properties_File key
# listed below.
#####################################################

Properties_File=vendor.selftest.openadrconfig.properties
######################################################

To create your own configuration file, copy and paste selftest configuration file
(vendor.selftest.openadrconfig.properties) and make your own edits. Each configuration characteristic
had a key, such as TH_VEN, and a value, such as "ven_123". The configuration files can be edited
from within Eclipse or with any text editor. It is helpful to have multiple configuration files for
different configurations of transport and security configurations during the testing process.
In addition to the properties files noted above, there are 6 security configuration files located in
"src.properties.security". Each of these files has a specific set of settings that represents a
particular security profile. The security profile used when running a test case is controlled by
two settings in the main properties file, explained in more detail below. Please note that the
security profile files are not normally modified by the user and are not documented beyond an
example listing of a representative file in Appendix C.

11


Transport and Security Configuration
By default, the test harness is configured to communicate over http in a localhost environment.
The following Test Harness property can be used to switch between XMPP and HTTP:
•

Transport_Type=HTTP

Security is controlled separately for HTTP and XMPP using the following default properties:
•
•

HTTP_Security=HTTP_Basic_Or_No_Security

XMPP_Security=XMPP_SHA256_Security

Valid values for these properties are listed in comments in the property file. Note that these
security properties control which of the 6 security profile files are used at run time.
The test harness and Openfire server are preconfigured with test certificates provide by the
Alliance Certificate Authority, NetworkFX. Vendors should configure their devices with test
certificates from the OpenADR/NetworkFX portal ( />The test harness certificate stores are configured as follows:
• Truststore contains both root and intermediate certs
• Keystores used by the test harness when playing the the role of a VEN or VTN contain
the device cert and private key.
• The keystore used by the XMPP server contains a complete certificate chain from the
root cert through the device cert.
VENs being submitted for certification must have host authentication of the x.509 certificate CN
field disabled to avoid needing to reconfigure the test harness server certificates. VENs can also
avoid the need to reconfigure the test harness XMPP server by using a CN address of
111111111111 for the X.509 client certificate installed in the implementation.
VTNs being submitted for certification must have the XMPP Server per-configured for the user
name of 111111111111, which the test harness uses to connect to the implementation's VTN
XMPP server. Note that the user names in the Openfire server MUST match the name in the CN
field of the X.509 VEN client certificate.
The VTN test certificates used as part of the test harness and Openfire builds have been
generated with a CN name of "vtn" and "127.0.0.1" respectively. As long as the device under
test has host authentication disabled, these certificates will work correctly in both the test
harness and the Openfire server. It is beyond the scope of this manual to provide detailed
guidance for rebuilding trust and keystore files with new certificates on both the test harness
and Openfire server.
12


If you are attempting to test a device remotely, you will need to open your firewall to the

various ports used by the test harness, Openfire server, and device under test. Most of these
ports are listed in the test harness properties file (i.e. 8080, 8081, 5222).

OpenFire Configuration
The security configuration of the Openfire server MUST match that of the test harness
XMPP_Security setting. In the /bin directory of the Openfire server installation there are 2 batch
files/shell scripts that allow you to switch between Plain and SHA256 security on the Openfire
server. The Openfire server must be restarted after changing these settings. The batch files are
named:
•
•

OpenADR_XMPP_Plain_Security
OpenADR_XMPP_SHA256_Security

Openfire has an administrative console that can be accessed at 127.0.0.1:9090 with a username
of admin and a password of password. From the administrative console, select system
properties (see figure 6).
If you are testing a VEN, the XMPP user name for the DUT VEN must match the CN field of the
x.509 certificate for the VEN. If the DUT certificate was generated using a CN field of
"111111111111" no action is needed. If not, please configure Openfire as show in figure 6a to
add a user name matching the CN name of the ven client certificate to Openfire.
If you are testing a VTN, the test harness default VEN CN name of "111111111111" must be
added as a user to the DUT's XMPP configuration assuming the VTN's XMPP server has the same
constraints as OpenFire.

Figure 6a - Open Fire User Summary
13

If you are testing a VEN, and the test harness, Openfire, and DUT are not all on the same
system, you will need to modify the following settings so that the Openfire server IP address is
correctly configured in the DUT, Openfire, and Test Harness. The following settings will need to
be configured with the new IP base address:
•

•

•

Openfire system properties (See Figure 6b)
o openadr2.vtn.jid
o xmpp.domain
Test harness properties
o TH_XMPP_Address or DUT_XMPP_Address (refer to comments in properties for
correct configuration)
VEN DUT
o Set the IP address of the Openfire server

If the test harness, Openfire, and DUT are not all set up pointing at the same IP address for the
Openfire server, you will not be able to communicate. In particular, you cannot leave the IP
address in the openadr2.vtn.jid xmpp.domain Openfire properties set to 127.0.1 if inbound JID
addresses are using the actual IP address of the Openfire server.

Figure 6b - Openfire System Properties

14


Running Test Cases

Test Case Naming
Test case numbering uses the following pattern: XY_ZZZZ_TH_WWW_1
X = A letter designating the service or special test type
• E= EiEvent Service Tests
• P=EiOpt Service Tests
• R=EiReport Service Tests
• N=EiRegisterParty Tests
• G=General Tests (includes non-service specific test such as security)
Y = A digit indicating the type of implementation:
• 1= Pull Test
• 0 = Push Test
ZZZZ = A numeric sequence number for the test case with initial increments of 10. For a
given Push or Pull test scenario, each VEN test case must have a matching VTN Test case
with the same 4 digit value.
TH_WWW = The "TH" indicates Test Harness and the WWW indicates the role, either
"VEN" or "VTN". This helps the user keep track of the role that the test harness is playing
in the exchange.
_1 = An optional postfix to indicate that the test case should be started before the device
under test.
So, an example test case would be R1_1223_TH_VEN_1. This would be an EiReport Push
Test case where the test case is playing role of the VEN, and this test case should be
started first.
Note that test cases migrated from the A profile test harness will be prefixed with an
"A_".

Test Logs
Test execution can be observed in the Eclipse Console window, and you will see a pass or fail
indication at the end of test case execution. However, detailed transactions records and failure
information can be found in a log file generated for each test case in the log directory (in the
"log" folder off the Eclipse project root).

Two test cases under “erc/testcases/util” (LogFiles_Clear and LogFiles_View) will allow you to
clear the log directory and to launch a browser to see the log file summary, which will show all
log files with a pass/fail status. From the log file summary, click on the link to see the detailed
15


log. After running a test case, you will need to refresh the browser to see additional test results.
You can also click on the logfile.html in the log directory and to open the file with your default
browser.
The security tests (Gx_4005, 4007, 4010, 9010) enable the Java network debug output in the
console window. This debug output is not captured in the test logs, so you may wish to cut and
paste these results from the console window into a text file if preserving the debug TLS
exchange details is important. The OpenADR application layer exchange that occurs as part of
the security tests is captured in the test logs.
It should be noted that when the test harness is playing the role of the VTN, the network debug
output shows the negotiation over the private connection between the test harness and the
Openfire server. You will need to use Wireshark to capture the communication between the
Openfire server and the VEN DUT if necessary for debugging purposes.

Self Test Routines
The B profile test definitions result in set two sets of mirrored test routines, one set each for
push and pull exchange models, and within each set a VEN and VTN test routine. The result is
that each test case definition will result in 4 separate test routines, one each for the following
entities: VEN Push, VTN Push, VEN Pull, VTN Pull. These mirrored test cases can be run against
their counterpart device under test or against each other in a self test scenario.
When running test cases against each other, you should always start the test case with the "_1"
prefix first. Also note that when running self-test routines it is not necessary to configure events
or to wait for specific time periods as requested by the prompts.
The B Profile test suite contains a large number of EiEvent service test cases that were ported
over from the A Profile test harness. These ported test cases contain a set of self test routines

that allow you to run test cases without the need for a real device to be attached to the test
harness. However, these are not implemented as mirrored test cases as noted above, as they
are stand-alone pieces of code that can be used to test a particular ported test case. These
ported A profile self test routines are located as follows:
•
•

testcase.pull.event.selftest_a_ported
testcase.push.event.selftest_a_ported

These self test simulations have DUT in the test case name. Note that the DUT self-test routines
do not simulate time-based state changes, so you can typically just click through prompts on the
observation test cases when using these self-test routines. Ported A profile test cases can be
identified with the "A_" prefix.
To run a self test code against a ported A test case, simply start the test case or the self test
routine that has the _1 postfix, then the start the test representing the other side of the
conversation.
16


Optional Test Cases
Some test cases are dependent on the ability to configure specific values on the Device Under
Test. If these values are not configurable, the OpenADR 2.0b PICS document provides a list of
questions that determine which optional test cases can be skipped. This can be found under the
heading Optional Test Case Guidelines.

Registration DB and Utilities
The test harness has two small database files that are used to store device and report
registration information for the VEN and VTN (vtndb.xml and vendb.xml). These files are located
off the Eclipse project root in the "db" folder.

Registration test cases have a prompt indicating whether they expect the test harness and DUT
to be in a registered or unregistered state. All other test cases assume the test harness and DUT
have completed device and report registration.
The following utilities are provided in the src/testcase/util to facilitate making sure that the test
harness and the DUT are in the appropriate registration state prior to running tests.
•

DUT_Register - Runs the appropriate test case to establish both device and report
registration between the test harness and the DUT.

•

DUT_CancelRegistration - Runs the appropriate test case to cancel registration between
the test harness and the DUT.

•

SelfTest_Register - Runs VEN and VTN registration test cases against each other so that
test cases can be validated against each other.

•

SelfTest_CancelRegistration - This simply clears the VEN and VTN database instances,
effectively unregistering the devices from a self test perspective.

•

SelfTest_RegisterNoReports - This is a shortcut routine that stuffs the VEN and VTN
databases with just device registration information. Great for running just registration
test cases in self test mode. Note that report registration info is not populated in the

database with this utility.

•

TH_ClearRegistrationDatabases - This resets the VEN and VTN database instances in
case the registration state between the TH and DUT gets out of sync.

•

VTNPollQueue_Clear –Used to clear the VTN oadrPoll queue. This recursively polls VTN
Queue till oadrResponse is received.

17


Please note that anytime you switch transports, Push or Pull models, or switch from testing
VENs to VTNs, you need to re-establish the registration state between the test harness and the
device under test.

Helpful Hints
Active Event Indicator – A number of test cases will ask the test operator to observe the

transition of an event to Active using the Active Event indicator. However, if you have access to
a DUT Control Panel that shows the start and end of an event, as well as the eventStatus, it may
not be necessary to actually wait for an event to end if you can see from the DUT console that
the event has been scheduled to end at a specific time. Judgment must be exercised!

Set polling to 10 seconds – For Pull VENs, configure the VTN to set the polling interval to

around 10 seconds when doing registration. The test cases deal in events that are just minutes

long, so a longer poll time may result in false failures. This can be set in properties.

Time Synchronization – While all the payload validation is based on the createdDateTime

in the payload, some false failures may occur if there is a delta between the time on the Device
Under Test and the time on the PC executing the test suite. Note that there is a built-in
conformance rule check that validates that the DUT is reasonably synced with the test harness,
which should avoid most issues. Note that some VTNs may cache events, which could cause
problems for test cases expecting to see event state changes.

Errors in the Log Window – We shut down the test suite http server after each test case
execution. During the shutdown process, an async payload from the DUT may generate an error
in the Console window. However, always check the test report in the log directory, as typically
you will see that the test case did run successfully even though an error appears at the end of
the Console window trace.

Failure information in test reports – The Console window just shows status and an
overall pass/fail status. For detailed conformance errors you will need to scan through the test
report log file for specific errors that caused the test to fail.

Processes Left Running – If you start and then abort a test case, you may leave processes
running. If you don’t kill these processes in the Eclipse Debug perspective or allow them to time
out, subsequent test cases may not run correctly.

Clearing the event data store – Generally speaking, implicit cancellation when testing the
EiEvent service on VENs takes care of flushing the DUT at the start of each test case. However, it
is critical on VTNs that the event data store be cleared before the next test. VTN Pull test cases
will prompt you to clear the data store at the start of each test case. The VTN Push test cases
will prompt at the end of each test case and also wait 10 seconds for any retries to occur before
ending the test case.

18


Conformance Rule Disable – Conformance rules can be disabled selectively by inserting
code at the top of the test() method in test cases using the following format:
ConformanceRuleValidator.setDisableCreatedEvent_ResponseCodeSuccess_Check(true);

Self Tests – Make sure processes have stopped before running the next test. If running two

tests against each other, you can toggle the Console window to kill the process if necessary to
move on to the next test.

Eclipse Getting Confused – Sometimes Eclipse gets confused and starts claiming that it

cannot access the “main” routine in the test case. Other odd occurrences include messages that
the Eclipse cannot delete in the bin directory, or that changes to properties do not seem to be
recognize by the running test case. The solution for these issues is some combination of killing
any active processes, using the Project, Clean menu option, the File, Refresh option, or exiting
and restarting Eclipse.

Firewalls – In most test scenarios, the test harness is playing the role of an http server. It is
necessary to open up any Windows or network firewalls to allow traffic to and from the IP
address of the DUT. We have discovered in some circumstances just opening up a port is not
adequate and disabling the firewall is necessary.

Wireshark - The test framework writes the payloads to the log file before it hands them to

the transport layer. Because we are using Restlet for http on top of the jetty http server, our
application code is a couple of layers removed from transport failures, and the failures don't
percolate back up to the test code. If it appears that you have a communication problem, it is

best to monitor traffic with Wireshark, as the test logs can sometimes provide a false positive
that traffic is being exchanged.

Disabling TH Host Verification – When security is enabled in properties, the URL IP

address is verified against the certificates received by the test harness client. The verifications
are disabled by default but can be changed in the properties file using the
vtnClientVerifyHostName and venClientVerifyHostName in security properties.

Disabling DUT Host Verification – The test harness, when playing the role of the TLS
server, uses a certificate with a CN and SubAltName of "vtn". You will need to disable host name
verification on the DUT or this server certificate will be rejected.

TLS Console Debug Listings - If you are having trouble connecting with security enabled,
you can turn on the network_debug flag in properties so that a TLS debug listing appears in the
console window when that test case is run. You can also enable XMPP_Debug in properties to
see the XMPP message exchange traffic.

19


Error when launching browser or log - The following error appears in the console log of

some systems when the browser or log viewer is launched programmatically. We have not been
able to isolate the cause of this error, but it appears to do no harm.
******** ERROR ********************************************************
This program is improperly using Base::Config by not initializing config
with the Load functions
See the documentation in Base/Dev/index.html for usage instructions.
At the minimum, LoadCommandLine should be use with a dummy command line

consisting of the program name.
************************************************************************

20


Appendix A – Configuration Tables
These following tables use the following addresses to illustrate the configuration options:
•
•
•
•
•
•
•
•

•
•

Test Harness and Openfire installed on 192.168.5.100
Test Harness VTN http listener port for HTTP: 8080
Test harness VEN http listener port for HTTP: 8081
Test harness XMPP Port 5222
Device under test IP address 192.168.5.120 (http or XMPP, VEN or VTN)
Device under test HTTP port 8082
Device under test XMPP port 5222
User names configured on XMPP server (Openfire or DUT VEN):
o VEN: 111111111111
o VTN: 222222222222

Devices support SHA256 ciphers
The well known service http postfix is not shown in examples

Pull VEN Configuration
Characteristic
ven ID of the DUT
vtnID of the test
harness
Market Context
Associated with VEN
Resource Supported

If the DUT requires a
special string to invoke
a test event, add it to
properties
HTTP Configuration

Test Harness (VTN) Property
VEN_ID=DUT_VEN

DUT VEN Configuration
DUT_VEN

VTN_ID=TH_VTN

TH_VTN

DR_MarketContext_1_Name=
http://MarketContext1

DR_MarketContext_2_Name=
http://MarketContext2
ResourceIDs= resource1,
resource2,resource3,resource4

http://MarketContext1
http://MarketContext2

Device_Class=Thermostat,Strip_Heater
TestEventString=Test Event

Thermostat,Strip_Heater

Transport_Type=HTTP
HTTP_VtnURL_Port=8080
HTTP_Security= HTTP_SHA256_Security

URL used to talk to VTN
https://192.168.5.100:8080

21

resource1, resource2,
resource3, resource4


Push VEN Configuration
Characteristic
venID of the DUT

Test Harness (VTN) Property
VEN_ID=DUT_VEN

DUT VEN Configuration
DUT_VEN

venID of the test
harness

VTN_ID=TH_VTN

TH_VTN

Market Context
Associated with
VEN

DR_MarketContext_1_Name=
http://MarketContext1
DR_MarketContext_2_Name=
http://MarketContext2

http://MarketContext1
http://MarketContext2

ResourceIDs= resource1,
resource2,resource3,resource4

resource1, resource2, resource3,
resource4

Device_Class=Thermostat,Strip_Heater

Thermostat,Strip_Heater

Resource
Supported
If the DUT requires
a special string to
invoke a test event,
add it to properties

HTTP
Configuration

TestEventString=This is a test Event

Transport_Type=HTTP
HTTP_VtnURL_Port=8080
HTTP_Security= HTTP_SHA256_Security

URL used to talk to VTN
https://192.168.5.100:8080
Listen on 8082
Transport Address sent in
registration:
https://192.168.5.120:8082

XMPP Test
Harness

Configuration

Transport_Type=XMPP
XMPP_VTN_Username=222222222222
TH_XMPP_Address=192.168.5.100
TH_XMPP_Port=5222
XMPP_Security=XMPP_SHA256_Security

XMPP Username = 111111111111
XMPP Server = 192.168.5.100
XMPP Port = 5222
Transport Address sent in
registration:
/client
Client Cert CN Field = 111111111111

XMPP Openfire
Server System
Properties

openadr2.vtn.jid =


xmpp.domain = 192.168.5.100
User names configured on XMPP
Server: 111111111111, 222222222222
Run OpenADR_XMPP_SHA256_Security.Bat

22

Pull VTN Configuration
Characteristic
venID of the test harness
venID of the device under
test
Market Context Associated
with VTN

Resource Supported

HTTP Configuration

Test Harness (VEN) Property
VEN_ID=DUT_VEN

DUT VTN Configuration
DUT_VEN

VTN_ID=TH_VTN

TH_VTN

DR_MarketContext_1_Name=
http://MarketContext1
DR_MarketContext_2_Name=
http://MarketContext2

http://MarketContext1
http://MarketContext2

ResourceIDs= resource1,
resource2,resource3,resource4

resource1, resource2,
resource3, resource4

Device_Class=Thermostat,Strip_Heater

Thermostat,Strip_Heater

Transport_Type=HTTP

Listen on port 8082

HTTP_VTN_BaseURL=
http://192.168.5.120:8082

HTTP_Security= HTTP_SHA256_Security

23


Push VTN Configuration
Characteristic
venID of the test harness

Test Harness (VEN) Property
VEN_ID=DUT_VEN

DUT VTN Configuration
DUT_VEN

venID of the device under
test
Market Context
Associated with VTN

VTN_ID=TH_VTN

TH_VTN

DR_MarketContext_1_Name=
http://MarketContext1
DR_MarketContext_2_Name=
http://MarketContext2

http://MarketContext1
http://MarketContext2

ResourceIDs= resource1,
resource2,resource3,resource4

resource1, resource2,
resource3, resource4

Device_Class=Thermostat,Strip_Heater
Transport_Type=HTTP

Thermostat,Strip_Heater

Resource Supported

HTTP Configuration

Listen on 8082

HTTP_VenURL_Port=8080
HTTP_Security= HTTP_SHA256_Security
HTTP_VTN_BaseURL=
http://192.168.5.120:8082
HTTP_VEN_BaseURL=

http://192.168.5.100:8081
XMPP Test Harness
Configuration

Transport_Type=XMPP
XMPP_VEN_Username=111111111111
DUT_XMPP_Address=192.168.5.120
DUT_XMPP_Port=5222
XMPP_Security=XMPP_SHA256_Security
Transport Address sent in registration:
/client

24

XMPP Username = vtn
XMPP Server =
192.168.5.120

XMPP Port = 5222
User names configured on
XMPP Server: 111111111111, vtn
Security must match Test
Harness


Appendix B – Test Harness Configuration Properties
###################################################################
# Vendor Specific Properties
# To use this file set Properties_File key in
# in openadconfig.properties to point to this file name
####################################################################
#########################################
######### Change Transport ##############
#########################################
# Switches between HTTP and XMPP transports. Valid values are HTTP or XMPP.
Transport_Type=HTTP
#########################################
######### Change Security ##############
#########################################
# Note that the security settings below control which security configuration file is
read when a
# test case is run. The security configuration files are located in
scr.properties.security
# ********** HTTP Security *************
# HTTP_Basic_Or_No_Security, HTTP_SHA256_Security, HTTP_SHA256_Expired
HTTP_Security=HTTP_SHA256_Security
# ********** XMPP Security *************
# XMPP_Plain_Security, XMPP_SHA256_Security

XMPP_Security=XMPP_SHA256_Security
# ********** Security Debug *************
# This controls whether a detailed TLS handshake transaction log is output to the
console during message exchange.
Security_Debug=false
#########################################
######### HTTP Configuration ############
#########################################
# These values point to the base URL of the the DUT and the TH based on there roles
# Example: If the DUT is a VEN, set HTTP_VEN_BaseURL to point to the DUT base URL
# Example: If the TH is a VEN, set HTTP_VTN_BaseURL to point to the TH base URL
# Do not use https as this is automatically set when Security_Enabled=true
HTTP_VEN_BaseURL=http://127.0.0.1:8081
HTTP_VTN_BaseURL=http://127.0.0.1:8080
# This is the port that the test harness listens on depending on the role it is
playing
# If the test harness is a VTN, set vtnURL_Port
HTTP_VtnURL_Port=8080
HTTP_VenURL_Port=8081
# Setting a name and password will cause basic authentication to be used for http
# If left blank, basic authentication key values will not be put in the http header
# Basic authentication is NOT part of the OpenADR requirements, so leave these values
blank unless you have a special need
Login_Name=
Login_Password=

25