Search
Member Login

Certifying an OpenADR 3.0 System

OpenADR 3.0 (3.0) for the most part maintained the general ideas and functions of OpenADR 2.0 (2.0). The main goal was to simplify the implementation which ultimately lead us to a RESTfull API structure using JSON. This if of course a significant change from 2.0 which can generally be seen as a SOAP exchange protocol using XML schema. The 2.0 test tool is a locally installed tool that exercises the necessary exchange patters to validate an implementation. For 3.0 this was not necessary as we are dealing with REST web services. Instead, we created an online test tool and members can purchase an unlimited license to run tests.

Purchase a test tool license here (coming soon)

The certification test does not require the usage of a test house anymore. Rather, the Certifier (company that wants to get certification for their product) obtains a certification license. The license includes access to the certification test tool and 4 hours time with a Certification Manager (person to witness the testing and confirms 'test pass' status).

Purchase a certification license here (coming soon)

VTN Testing and Certification

Note: Unless the VTN is only used in a specific environment (not a commercial VTN for sale), the VTN needs to implement OpenADR 2.0b and OpenADR 3.0. Contact us to obtain an exception.

The Test Tool (TT) contains over 200 test scripts that make requests to a VTN and evaluate responses. Tests include happy path, authorization, bad methods, bad inputs, and query params.

Licensing

User must obtain a testing license from openadr.org. Login to openadr.org with your Alliance member credentials and follow the web flow defined in that application to obtain a testing and/or certification license.

Testing

Once a license had been obtained, it must be provisioned into the Test Tool by a TT admin. User's will be notified via email when their license has been provisioned and the Test Tool is ready to be used for testing.

Login into the Test Tool with your Alliance credentials. At the top navigation bar of the Test Tool one may select "VTN Tests". If this option is not available, the current user does not have a VTN testing license provisioned in the Test Tool.

Selecting "VTN Tests" will transition to a new page where the user may view past test results or select "Create VTN Test Run". Selecting this will prompt the user to input the internet accessible address of their VTN, after which one may execute a test run and view results.

VEN Testing and Certification

Profiles

Profiles are used to verify VEN interoperability with one or more Demand Response use cases. For example, Continuous Pricing (CP) is a common DR use case. A CP profile is used to ensure a VEN will interoperate with any utility varying price program.

The Baseline profile tests a minimal subset of operations of a VEN. We use this in the example below. Test profiles entail launching the VTN RI and executing a Business Logic client to populate the VTN. More detail on profile workflows follow.

Any general commercial VEN product shall implement at least the Baseline profile unless it is specifically only used to receive prices. CP products will marked as such.

VEN Requirements

A number of VEN requirements are definded in Definitions 3.0.1 (availble from the OpenADR Alliance as a core part of the OpenADR 3 platform defintion).

These include: * VEN MUST enroll with VTN provider to be provisioned with security credentials (Definitions 3.0.1 section 5.3). * For testing and certification VENs will use the following credentials: client_id: ven_client, client_secret: 999. * VEN MUST use a ven name unique to a vtn instance, and resource names unique to their associated VEN (Definitions 3.0.1 section 6.10). * For testing, VENs may use any name as their is only one VTN in scope and one resource per ven in certain tests. * VEN MUST make a request to <>/auth/token to exchange client_id and client_secret for a bearer token. * VEN MUST include bearer token in all API requests except to <>/auth/token (Definitions 3.0.1 section 11.1). * VEN MUST be manually provisioned with VTN URL (Definitions 3.0.1 section 11.2)

Additional requirements per profile are detailed below.

Profile Details

The general test workflow is: - A business logic client populates a test VTN with program, events, and other relevant objects for the profile - The business logic client subscribes to reports and other relevant objects to detect objects reads and writes by a VEN - A VEN client reads objects from the test VTN. May also be required to subscribe to changes in object state, and write ven and resource objects and responds to report requests.

Baseline Profile

The baseline profile simply evaluates a VENs ability to read programs and events.

VEN requirements

  1. VEN MUST poll for programs
  2. VEN MUST poll for events

BL Workflow

  • BL writes a program to the VTN.
  • BL subscribes to program GET with VTN.
  • BL receives notification of program GET.
  • BL writes an event to the VTN.
  • BL subscribes to event GET with VTN.
  • BL receives notification of event GET.

Continuous Pricing (CP) profile

Continuous Pricing publishes events that include 24 hourly prices.

VEN requirements

A VEN is expected to poll for events, and on receipt of any that include a report request, write a report.

Workflow

  • BL writes an event to the VTN.
  • BL subscribes to event GET with VTN.
  • BL subscribes to reports POST with VTN.
  • VEN reads event from VTN.
  • VEN writes report to VTN.
  • VTN notifies BL of event.
  • VTN notifies BL of report.
  • BL verifies report and verifies behavior of VEN.

Local execution of baseline VEN tests

For developers who have access to the to Test Tool, test callback service and VTN Reference Implementation GitHub repos and have cloned the repo into .

In terminal window 1

Start VTN Reference Implementation Follow instructions in /openadr3-vtn-reference-implementation README

In terminal window 2

Start callback service Follow instructions in /test_callback_service README

In terminal window 3

Start Business Logic test client open terminal window and change directory to client
cd <localpath>/copenadr3-test-tool

setup test tool
create virtualenv
virtualenv venv
source venv/bin/activate
pip3 install -r requirements.txt

start ven test
pytest VEN_test/profiles/baseline/baseline_ven_test.py --html=./logs/pytest_report.html

In terminal window 4

Start VEN test client

open terminal window and change directory to client
cd <localpath>/copenadr3-test-tool

setup test tool
create virtualenv
virtualenv venv
source venv/bin/activate
pip3 install -r requirements.txt

start ven test
`pytest VEN_test/profiles/baseline/baseline_ven_implementation.p

Execute VEN

Execute a VEN implementation by configuring it to address the local Reference Implementation VTN. Restart the RI between tests.