On Tuesday 1st April 2025 we noted about ‘Challenges in ‘Time taken for Dispatch Targets to be made available to participants’ (ICF002)’, which …
1) Followed from several earlier articles about what lies within each Dispatch Interval; and
2) Highlighted some slides in the AEMO’s Presentation to EWCF Meeting #14 on 19th March 2024 (now over 12 months ago).
On the same day we then wrote about ‘What’s the problem(s) with dispatch targets arriving ~20 seconds into the Dispatch Interval?’ to draw on one slide in the AEMO’s EWCF Meeting #16 on 21st May 2024 (full slide deck here) that:
1) without sliding all the way into the rabbit hole of exploring/explaining the (many!) problems that arise because the ‘infinitesimally small’ gap in which we noted that ‘Magic Happens’ in this deliberately Simplistic View is certainly not the case in reality …
2) … the AEMO highlighted some of these problems in its presentation on 21st May 2024
3) … with those highlighted (perhaps?) stemming from particular issues raised by participants prior to the meeting, and prompting the ICF002 initiative?
Finally on that day, we wrote ‘What’s the AEMO been considering, as a possible solution to the delayed receipt of Target?’:
1) Including this mashed-together image (i.e. taking a couple images earlier published by AEMO and re-arranging) to summarise the mooted change:
2) we also circulated on social media in order to solicit input from more learned NEM stakeholders (e.g. on LinkedIn here, which has attracted some comments from some NEM stakeholders).
AEMO notes ‘complications and considerations’
In the EWCF Meeting #24 on 11th February 2025 (note that the full slide deck is here), we note that the AEMO provided one slide as an update on the ICF002 process, but it is worth highlighting:
We understand that there will be further updates provided this Tuesday (i.e. 8th April 2025) in the EWCF Meeting #26, so we’ll see if one of our team members can be on that call.
Differentiating between two different approaches that could (possibly?) be explored to resolve this problem
Before we get into the specifics of the concerns we have, it’s worth highlighting that it seems (to us) that there might be two different approaches taken to trying to resolve, as follows:
Approach #1 = shortening the ‘dead zone’ in the process
Were it possible for the AEMO to take steps to shorten the overall time taken in this ‘dead zone’ between SCADA snapshot and participants receiving their Dispatch Targets, that would seem to be more unambiguously a very good thing.
… note that the AEMO has in the past taken steps to tighten the timing of certain dispatch process, such as the two initiatives we noted in December 2021 via the article ‘Two recent improvements (in late November 2021) by AEMO in the dispatch process’:
(a) With respect to file creation times for P5MIN predispatch; and
(b) With respect to Gate Closure #2.
However to us it appears that this is not what has been proposed (at least to date) in the ICF002 changes….
Approach #2 = shifting the ‘dead zone’ in time (but retaining the same length)
… rather, what’s been proposed is does not appear to be shortening that ~23 second ‘dead zone’ but rather just shifting it earlier in time (unless I’m missing something?), as noted in this updated mash-up image here:
With respect to this approach (and noting that we have a number of questions to which we don’t have answers yet about the specifics of the approach proposed) we’re wondering if this might just cause (different) problems to appear at different parts of the dispatch process?
… a bit like squeezing a large balloon half-filled with water, with different parts of the balloon bulging depending on where pressure is exerted?
There’s more to come in ‘Questions and concerns, about proposals to shift the ~23 second dead zone within the Dispatch Interval (ICF002)’ [ARTICLE TO COME].
Leave a comment