Reporting in OpenADR: background information & implementation strategies
Reporting is the key service for exchanging information, primarily about status of VEN (and associated resources / devices): is it online, how much power is it consuming, how much load shift is available, etc.
This will cover an overview of the reporting service and some key insights, but please refer to section 8 of the OpenADR 2.0b specification to get familiar with the true spec.
Reporting Steps
In OpenADR, reporting can flow from either VTN or VEN to the other, but practically it is only implemented VEN => VTN, so we will assume that to be the case. There are typically three key steps in the reporting flow:
- Report registration: The VEN tells the VTN what kind of reports it has available, and provides IDs for those reports and data points to help the VTN understand what it can request
- Report request: VTNs requests a report from the VEN - either a one-time data request, or a periodic data request (i.e. send me this report every 60 minutes)
- Sending report: VEN delivers the report as requested by the VTN, and repeats periodically if requested
Over time, reports can be re-registered (if the VEN has new reports to share), and report requests can be updated or cancelled if the VTN wants to provide different data.
Registering reports (VEN => VTN)
The VEN can register multiple reports with the VTN. They all need the following parameters:
reportSpecifierID
: the ID for the report when the VEN registers with the VTN. This is then referred to in the Report Requests.rIDs
: a specific data type / point referred to in the report (each report can have multiple rIDs associated with it)Duration
: how much data history is available, or can be available when requestedSamplingRate
- defines the granularity of data available, the VTN must query within the boundaries set- Can define "onChange" as true, which means you have the ability to only report data when it has changed
Try not to get confused between rID
and reportSpecifierId
. reportSpecifierId
refers to the overall report, for example usageReport
. rID
refers to a particular data type, for example usage-energy
or usage-power
. It must be unique. Often there will just be one rID
per report, but there can be many. For example, if you have multiple devices controlled by one VEN, you may specify an rID for each device, e.g. device1-status
, device2-status
, etc.
Requesting Reports (VTN => VEN)
Once the VTN has understood what reports are available from the VEN, it can request any or all of those reports from the VEN.
The report request must reference the reportSpecifierId
, as well as:
- Which rIDs to include in the response (or all of them)
- Whether this is a one-time or recurring request
- If recurring, a start time / end time and frequency to generate reports
- If one-time, what period of time to cover
Report timing and granularity are specified by:
- startTime / duration: when to start reporting and how long to report for. If Duration == 0, there is no end
- granularity: how frequently to report data (e.g. 5 mins, ).
- If granularity = 0, that means only report data if there is a change
- reportBackDuration: interval for sending reports back (if recurring). If 0, only send one report.
Report requests can then be updated or cancelled by the VTN.
Sending reports (VEN => VTN)
When a report needs to be sent (e.g. it was just requested, or the periodic report time is now), the VEN will send the report information to the VTN. Reports themselves are quite minimal, for the most part they just include multiple data points that include the rID, time, value and data quality.
Available reports
OpenADR defines three reports by default:
History usage report
: logs of historical usage data (e.g. in kWh or kW) that can be queried by the VTNTelemetry usage report
: real-time usage data (e.g. kWh or kW), usually the most recent data point availableTelemetry status report
: most recent data available on device status (e.g. online or offline)
Within the parameters of the report format, any number of custom reports can be defined and used.
Where used, reports are typically the VTN operator's responsibility to define what reports they need to for the VEN to participate in the program. VEN owners can then program their VENs to register that report with the VTN, and provide the data when required.