Decision Proposal 193 - Energy Non-functional Requirements

[CDR-API-Stream]

This decision proposal defines changes to the existing non-functional requirements, and metric reporting APIs, to accommodate energy specific characteristics.

The decision proposal is embedded below: Decision Proposal 193 - Energy Non-functional Requirements.pdf

This consultation will be open for feedback until the 10th September 2021.

[CDR-API-Stream]

A proposal for this item is intended to be published this week

[PratibhaOrigin]

While DSB is working on the non-functional requirements proposal for energy sector, Origin wanted to raise a concern which we think should be considered based on our review of the DP 192.

DP 192 - AEMO Exposed End Points states –

“All occurrences of the servicePointId field, whether in a request, a response, or as a query parameter should be populated with the NMI instead of a service point ID using the ID permanence rules. AEMO will not be able to translate between a NMI and servicePointId as they will not be aware of the recipient or the subject associated with the consent. As a result, the retailer will be expected to translate the NMI provided in the servicePointId field into an ID conformant with the ID permanence rules.”

• This transformation from servicePointID to NMI or NMI to servicepointID will have added complexity and time lag while fulfilling a data sharing request. • We request the DSB to take this into account while working on the non-functional requirements for energy – the timing requirements for retailer (data holder) should not consider the delay or time take by AEMO to fulfill the data request. • However, it should take into consideration the added time for transformation on NMI to servicepointID and vice-versa before passing on the data.

Cheers! Prats

[CDR-API-Stream]

Thank you for your feedback Prats. The proposal (which is now posted) does take into account the processing time required for a retailer to process a request that is passed to AEMO. It has been aligned with expectations applied to data holders in the banking sector that also have to align to ID permanence rules.

[PratibhaOrigin]

Thanks for the opportunity to provide feedback on this topic.

We have reviewed the paper and few queries and comments for clarification below – 1) How is “secondary request” and “large secondary request” defined? Considering the CDR expansion to future sectors, it will be good to have a proper definition for these terms.

2) Time-frame requirements – Paper suggests –

a. The threshold for the Primary Data Holder will be set at 1000ms b. The threshold for the Secondary Data Holder will be set at 1500ms

So, when does the time-frame of 1000ms for primary data holder start – • just after receiving request from the ADR (but taking out the time required by AEMO to provide data) OR • only after the receiving the requested data from AEMO.

3) With the bulk data payloads, the above NFR seems bit ambitious.

o The threshold for the Primary Data Holder will be set at 1500ms o The threshold for the Secondary Data Holder will be set at 4500ms

For example with usage end point , considering the 5ms data or C&I data , the payload will be enormous and the NFR threshold seems bit ambitious for that. We request DSB to consider it again on those grounds. Also providing at least 12 month grace period for these NFRs and not make them binding from day 1.

4) Pagination standards can be used to some extent to manage the bulk data. We wanted to clarify the scenarios where large secondary request is made from primary data holder to AEMO , say 'Bulk Usage', will AEMO manage the bulk data and send paginated records to the primary data holder OR the primary data holder will get the bulk data (all records) and they are required to paginate the records while they perform data transformation to replace NMI with servicepointID , before passing the data to the ADR.

[johnAEMO]

Thank you for the opportunity to respond to the above Decision Proposal.

As a Secondary Data Holder AEMO understands the intent of the proposed NFR settings and accepts that any new APIs will need to be designed and built or modified with these performance requirements as its target. We agree that the consumers’ experience is paramount to the success of CDR in Energy especially with the key Usage data payload.

AEMO believes the Secondary performance targets of 95% of transactions within 1.5 seconds may be achievable for NMI Standing Data, DER data and at least Usage data for Basic meters, however, the Usage data for 30 minute Interval meters and 5 minute Interval meters are unlikely to be met without a disproportionate investment in the systems that support this feed. A typical two register 5 minute Interval metered installation translates to over 400,000 meter readings over the stipulated 2 year period or approximately 14 MB of data (7+ MB per register). It would be good to understand the CX expectations of working with such as large data-set as well as how pagination might work via the primary data holders.

In terms of metrics, while we understand and support the need for overall performance to be measured from a consumer’s perspective (that is by the retailer), we will also measure our own performance, provide an audit trail and report on both as a data holder.

[gurchan-AGL]

AGL appreciates the opportunity to provide feedback on this decision proposal

1. Clarity of understand

   Under performance requirements a new Secondary Request band will be created with two thresholds:

   • The threshold for the Primary Data Holder will be set at 1000ms
   • The threshold for the Secondary Data Holder will be set at 1500ms

For the purposes of clarity AGL understands these time thresholds are measured from the point of ingress and egress for each Data Holder party and excludes the elapsed transit time between the Primary and Secondary. Subsequently the total request time maybe greater than 2500ms. Please confirm if this is not the correct interpretation.

Under performance requirements a new Large Secondary Request band will be created with two thresholds:

• The threshold for the Primary Data Holder will be set at 1500ms
• The threshold for the Secondary Data Holder will be set at 4500ms

Likewise for Large Secondary Request the total request time maybe greater than 6000ms. Please confirm if this is not the correct interpretation.

2. Confirmation of TTL guidelines for cached responses AGL would like to clearly understand from DSB on the (TTL) time to live data standards/guidelines and whether these can be applied to Secondary Data Holder requests. To ensure the most optimal consumer experience it would be prudent for data holder to maintain some short-term caching mechanism for the very frequent/repeated request from the customer/ADR, which inherently does not have any change in data to fetched from system of records.

3. Rationale for the inclusion of Get Service Points into NFR Category of "Secondary Request"

   Secondary Request

   • Get Service Points

Its unclear why this particular endpoint has been included into this category. Are you able to provide further details?

[CDR-API-Stream]

In response to the feedback from @PratibhaOrigin:

1. How is “secondary request” and “large secondary request” defined? Considering the CDR expansion to future sectors, it will be good to have a proper definition for these terms.
2. Time-frame requirements – Paper suggests –

a. The threshold for the Primary Data Holder will be set at 1000ms b. The threshold for the Secondary Data Holder will be set at 1500ms

So, when does the time-frame of 1000ms for primary data holder start – • just after receiving request from the ADR (but taking out the time required by AEMO to provide data) OR • only after the receiving the requested data from AEMO.

It would be the former. The Primary Data Holder response time would be the overall response time (as per normal for any API invocation) minus the response time from AEMO.

1. With the bulk data payloads, the above NFR seems bit ambitious.

o The threshold for the Primary Data Holder will be set at 1500ms o The threshold for the Secondary Data Holder will be set at 4500ms

For example with usage end point , considering the 5ms data or C&I data , the payload will be enormous and the NFR threshold seems bit ambitious for that. We request DSB to consider it again on those grounds. Also providing at least 12 month grace period for these NFRs and not make them binding from day 1.

There is no evidence this would be a difficult threshold to meet for Retailers (although it may be for AEMO). Payload sizes will be constrained by the maximum record could that applies to all paginated endpoints and the ADR NFR restricting abusive call patterns. For a passthrough gateway providing minimal payload alteration this threshold would be considered generous by normal API industry practices.

1. Pagination standards can be used to some extent to manage the bulk data. We wanted to clarify the scenarios where large secondary request is made from primary data holder to AEMO , say 'Bulk Usage', will AEMO manage the bulk data and send paginated records to the primary data holder OR the primary data holder will get the bulk data (all records) and they are required to paginate the records while they perform data transformation to replace NMI with servicepointID , before passing the data to the ADR.

The former. Pagination parameters are expected to be passed to AEMO unfiltered and pagination will be managed by AEMO. This is according to the proposal in consultation on AEMO endpoints.

[CDR-API-Stream]

In response to the feedback from @johnAEMO:

As a Secondary Data Holder AEMO understands the intent of the proposed NFR settings and accepts that any new APIs will need to be designed and built or modified with these performance requirements as its target. We agree that the consumers’ experience is paramount to the success of CDR in Energy especially with the key Usage data payload.

AEMO believes the Secondary performance targets of 95% of transactions within 1.5 seconds may be achievable for NMI Standing Data, DER data and at least Usage data for Basic meters, however, the Usage data for 30 minute Interval meters and 5 minute Interval meters are unlikely to be met without a disproportionate investment in the systems that support this feed. A typical two register 5 minute Interval metered installation translates to over 400,000 meter readings over the stipulated 2 year period or approximately 14 MB of data (7+ MB per register). It would be good to understand the CX expectations of working with such as large data-set as well as how pagination might work via the primary data holders.

This could be addressed by moving the Get Usage For Service Point endpoint to the Large Secondary Request category. This would appear reasonable given the feedback from AEMO and from Origin.

[CDR-API-Stream]

In response to the feedback from @gurchan-AGL:

1. Clarity of understand

Under performance requirements a new Secondary Request band will be created with two thresholds:

• The threshold for the Primary Data Holder will be set at 1000ms
• The threshold for the Secondary Data Holder will be set at 1500ms

For the purposes of clarity AGL understands these time thresholds are measured from the point of ingress and egress for each Data Holder party and excludes the elapsed transit time between the Primary and Secondary. Subsequently the total request time maybe greater than 2500ms. Please confirm if this is not the correct interpretation.

Not quite. As the proposal is for the secondary to be data holder to be measured via the metrics API by the primary data holder the gap between primary and secondary would be included in the response times of the secondary data holder.

Total request time, as seen by the ADR, may be higher than reported by the primary data holder as the primary data holder will only be able to record from their point of ingress (as is currently acknowledged in the CDR NFRs).

Under performance requirements a new Large Secondary Request band will be created with two thresholds:

• The threshold for the Primary Data Holder will be set at 1500ms
• The threshold for the Secondary Data Holder will be set at 4500ms

Likewise for Large Secondary Request the total request time maybe greater than 6000ms. Please confirm if this is not the correct interpretation.

Same response as above.

1. Confirmation of TTL guidelines for cached responses AGL would like to clearly understand from DSB on the (TTL) time to live data standards/guidelines and whether these can be applied to Secondary Data Holder requests. To ensure the most optimal consumer experience it would be prudent for data holder to maintain some short-term caching mechanism for the very frequent/repeated request from the customer/ADR, which inherently does not have any change in data to fetched from system of records.

This is an excellent pickup and will be added. It would appear reasonable for the primary data holder to be able to cache responses within reasonable boundaries.

2. Rationale for the inclusion of Get Service Points into NFR Category of "Secondary Request"

Secondary Request

• Get Service Points

Its unclear why this particular endpoint has been included into this category. Are you able to provide further details?

The Get Service Points endpoint is a component of the NMI Standing Data data cluster which, as defined by the designation instrument, is to be provided by AEMO as a secondary data holder.

[CDR-API-Stream]

Thanks for the feedback. Consultation on this thread will be now be closed while a decision paper is created for submission to the Chair. This decision will accommodate the feedback provided.

[CDR-API-Stream]

The Chair has approved the attached decision for this consultation: Decision 193 - Energy Non-functional Requirements.pdf