This section is intended to validate a client’s ability to monitor and report data relating to the DER(s) under its management.
3.3.1 ALL-02 INDIVIDUAL READINGS (A)
3.3.1.1 Purpose
This test is intended to validate the client’s ability to post average values for the following readings using the MirrorMeterReading POST method:
a) Site real power
b) Site reactive power
c) DER real power
d) DER reactive power
e) Frequency (if supported by the communications client)
f) Site and/or DER voltage
3.3.1.2 Test procedure
The steps SHALL be performed as described in Table 7. The test results SHALL be compared against the Expected Result column in Table 7.
Table 7 – Test steps for Communications Client – Individual Readings
Step No. | Manual or utility server step | Expected comms client result |
1 | The client completes the discovery process as detailed in test 3.2.1, including receiving the MirrorUsagePoint resource link from the utility server. | Client requests resource information from the utility server’s MirrorUsagePointList endpoint. |
2 | Utility server sends the MirrorUsagePointList resource that should not yet contain an entry for the client’s MirrorUsagePoint. | The client posts a valid MirrorUsagePoint payload to the MirrorUsagePointList endpoint on the utility server. |
3 | The server returns a HTTP payload confirming that the MirrorUsagePoint is valid. | The client again requests resource information from the utility server’s MirrorUsagePointList endpoint. |
4 | Utility server sends the MirrorUsagePointList resource that now contains an entry for the client’s MirrorUsagePoint including relevant information such as the postRate required for MirrorMeterReading posts. | The client posts MirrorMeterReading or MirrorMeterReadingList payloads to the MirrorUsagePointList endpoint at the configured interval (default is 60 seconds), including all of the required and claimed data points as described above in clause 3.3.1.1. |
3.3.1.3 3.3.1.3 Criteria
If during testing the client experiences one of the following events these are considered non- conformances with this requirement:
i) The client does not post readings to the utility server.
ii) The client fails to post some or all of the mandatory and optionally-claimed data values as specified in Section 3.3.1.1.
iii) The client posts readings at an incorrect interval.
Notes:
i) It has been noted that there are multiple ways a client can configure one or more MirrorUsagePoint resources for a site, and that different utility servers may require different configurations. This test validates that the MirrorUsagePoint resources are configured in a functional way, and does not specify which configuration is to be supported. Clarification on an intended configuration is expected to be provided in a future revision to CSIP-AUS.
ii) The averaging window of data reported SHALL match the configured MirrorUsagePoint postRate.
3.3.2 ALL-03 CONNECTION STATUS (A)
3.3.2.1 Purpose
This test is intended to validate the client’s ability to post DER generation connection status to the utility server.
3.3.2.2 Test Procedure
The steps SHALL be performed as described in Table 8. The test results SHALL be compared against the Expected Result column in Table 8.
Table 8 – Test steps for Communications Client – Connection Status
Step No. | Manual or utility server step | Expected comms client result |
1 | The client is online and the DER is in a connected state. | No result necessary. |
2 | DER is physically disconnected from the grid supply. Where a client manages multiple | The client posts to the utility server with bit 0 of genConnectStatus = 0. |
DER all DER are disconnected / reconnected as part of this test. | ||
3 | DER is physically reconnected to the grid supply. | The client posts to the utility server with bit 0 genConnectStatus = 1. |
3.3.2.3 Criteria
If during testing the client experiences one of the following events these are considered non- conformances with this requirement:
a) The client does not post the connection status on disconnection.
b) The client does not post the connection status on reconnection.
Notes:
i) During testing the client SHALL report bit 0 of genConnectStatus = 0 only if all DER are disconnected.
3.3.3 ALL-04 OPERATIONAL MODE STATUS (A)
3.3.3.1 Purpose
This test is intended to validate the client’s ability to post DER operational mode status to the utility server.
3.3.3.2 Test Procedure
The steps SHALL be performed as described in Table 9. The test results SHALL be compared against the Expected Result column in Table 9.
Table 9 – Test steps for Communications Client – Operational Mode Status
Step No. | Manual or utility server step | Expected comms client result |
1 | The client is online and the DER is operating. | The DER is sourcing or sinking at least 2000W or 50% of the DER’s active power rating, whichever value is lower. |
2 | DER is stopped from being capable of sourcing or sinking power (e.g. power source/sink is set to 0W). | The client posts OperationalModeStatus = 1 to the utility server. |
3 | DER resumes sourcing/sinking power. | The client posts OperationalModeStatus = 2 to the utility server. |
3.3.3.3 Criteria
If during testing the client experiences one of the following events these are considered non- conformances with this requirement:
a) The client does not post OperationalModeStatus on ceasing power supply/draw.
b) The client does not post OperationalModeStatus on recommencing power supply/draw.
c) The client reports OperationalModeStatus = 0 or OperationalModeStatus = 3 at any time.
3.3.4 ALL-05 CAPABILITIES AND SETTINGS (A)
3.3.4.1 Purpose
This test is intended to validate the client’s ability to post DER capabilities and settings.
3.3.4.2 Test Procedure
The steps SHALL be performed as described in Table 10. The test results SHALL be compared against the Expected Result column in Table 10.
Table 10 – Test steps for Communications Client – Capabilities and Settings
Step No. | Manual or utility server step | Expected comms client result |
1 | The client completes the discovery process as detailed in test 3.2.1, including receiving the DERCapability and DERSettings resource links from the utility server. | Client posts DERCapability and DERSettings payloads to the utility server as required (either on-connection or on- change as specified below). |
3.3.4.3 Criteria
If during testing the client experiences one of the following events these are considered non- conformances with this requirement:
a) The client does not post the DERCapability payload to the utility server on connection.
b) The client does not post the DERSettings payload to the utility server on-change.
c) The client posts incorrect capabilities or settings values to the utility server.
Notes:
i) Where multiple DER are present their values are to be aggregated.
3.3.5 ALL-06 UPDATE POST RATES (A)
3.3.5.1 Purpose
This test is intended to validate the client’s ability to act on changes to posting rates for the Metering Mirror function set.
3.3.5.2 Test Procedure
The steps SHALL be performed as described in Table 11. The test results SHALL be compared against the Expected Result column in Table 11.
Table 11 – Test steps for Communications Client – Update Post Rates
Step No. | Manual or utility server step | Expected comms client result |
1 | The server updates the postRate value from the default of 60s to 300s. | The client receives the new posting rate (either on next poll of the MirrorUsagePointListLink for direct clients or immediately for subscription/notification clients) and the next MirrorMeterReading is posted by the client after 300s. |
2 | The server updates the postRate value to 60s. | The client receives the new posting rate (either on next poll of the MirrorUsagePointListLink for direct clients or immediately for subscription/notification clients) and the next MirrorMeterReading is posted by the client after 60s. |
3.3.5.3 Criteria
If during testing the client experiences one of the following events these are considered non- conformances with this requirement:
a) The client does not correctly update posting rates.