Decision Proposal 196 - Candidate DER End Points

[CDR-API-Stream]

This decision proposal contains a recommendation for the candidate URIs and end points for Distributed Energy Resources (DER) Data. This proposal has been developed with the aid of AEMO.

The decision proposal is embedded below:
Decision Proposal 196 - Candidate DER End Points.pdf

This consultation will be open for feedback until the 1st October 2021.

[EnergyAustraliaBA]

Hi - we note that NMI is not included in the response. Retailer will request DER data on NMI level. Is there any reasoning of not providing NMI back to requestor?

[johnAEMO]

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

AEMO's response is in the attached document:
Decision Proposal 196 - AEMO Response v1.0.docx

[CDR-API-Stream]

Thanks everyone for the feedback. This consultation is now being closed. We will provide a response to feedback shortly.

[CDR-API-Stream]

In response to the feedback from @EnergyAustraliaBA:

Hi - we note that NMI is not included in the response. Retailer will request DER data on NMI level. Is there any reasoning of not providing NMI back to requestor?

The above point has been clarified in response to a similar query by AEMO in DP 195

The response in the comment was:

NMI has been excluded from this payload on purpose. It is only passed in the standing data payload to help establish the servicePointID, which is the CDR specific id for all subsequent payloads requests. Note that the servicePointID attribute will be populated with the NMI for any request response interaction between a retailer and AEMO.

[CDR-API-Stream]

In response to feedback from @johnAEMO:

Reference to External Standards
Remove this section in total – this standard is no longer relevant.

We will remove the reference as suggested

Response Payloads

• page 5, presumably ServicePointId will be populated by the retailer (as it will be unknown by AEMO)
• page 5, after ServicePointId we note that NMI is not included yet it is included in the NMI Standing Data Payload. Should it be included here also?

The above two points have been clarified in DP 194 and DP 195

• page 5, hasCentralProtectionControl (Optional) needs to be changed to Mandatory and in the Description the last sentence “If absent…” should be removed.

Mandatory attributes with only two possible values (like hasCentralProtectionControl) are often represented as optional in CDR standards, with a default value inferred if the attribute is not present in the payload (as stated in the description). They are fundamentally mandatory attribute as their absence still implies a value. This is done to help minimise the payload size.

• page 5, protectionMode the Description needs to include "One or more of the following fields will be provided to describe the protection modes in place:"
• page 5, underFrequencyProtection the Description the last sentence “Default value…” should be removed.
• page 5, underFrequencyProtectionDelay the Description the last sentence “Default value…” should be removed.
• page 5, overFrequencyProtection the Description the last sentence “Default value…” should be removed.
• page 5, overFrequencyProtectionDelay the Description the last sentence “Default value…” should be removed.
• page 6, underVoltageProtection the Description the last sentence “Default value…” should be removed.
• page 6, underVoltageProtectionDelay the Description the last sentence “Default value…” should be removed.
• page 6, overVoltageProtection the Description the last sentence “Default value…” should be removed.
• page 6, overVoltageProtectionDelay the Description the last sentence “Default value…” should be removed.
• page 6, acConnections needs to be changed to Mandatory

We will make all the above changes

• page 6, equipmentType needs to be changed to Mandatory and in the Description the last sentence “If absent…” should be removed.

DSB Response – See above response with regards to hasCentralProtectitionControl

• page 7, commissioningDate needs to be changed to Mandatory.
• page 7, installationStage needs to be removed. This is a field included during the creation of the record. Once created this field is no longer supported.
• page 7, status needs to be changed to Mandatory.
• page 7, derDevices needs to be changed to Mandatory.

We will make all the above changes

• page 7, manufacturer needs to be changed to Mandatory and the Description needs to include “May be “unknown””.
• page 7, modelNumber needs to be changed to Mandatory and the Description needs to include “May be “unknown””
• page 8, subtype needs to be changed to Mandatory and the Description needs to include “May be “other””.

The above attributes will be kept as optional and AEMO will exclude “unknown” values in response. The attribute description will be updated to reflect this change.

• page 7, (derDevices) status needs to be changed to Mandatory.
• page 7, (derDevices) installationStage needs to be removed. This is a field included during the creation of the record. Once created this field is no longer supported.
• page 8, type needs to be changed to Mandatory.
• page 8, nominalRatedCapacity needs to be changed to Mandatory.
• page 8, nominalStorageCapacity needs to be changed to Conditional and the Description needs to include “Always present if type is “STORAGE””

We will make all the above changes

[CDR-API-Stream]

Please find attached the final decision of the Chair:
Decision 196 - Candidate DER End Points.pdf