What’s the AEMO been considering, as a possible solution to the delayed receipt of Target?

Earlier today 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).

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)  Highlights some of the problems that AEMO highlighted in its presentation on 21st May 2024 … with those highlighted are probably stemming from particular issues raised by participants earlier.

What slides have the AEMO published, to illustrate a potential ‘solution’ being considered?

If we step further into the slide deck from Meeting #16 on 21st May 2024 we can see what the AEMO has been exploring as one possible* ‘solution’ to the problem:

* again, perhaps on the basis that this possible solution was first suggested by these participants who first spoke up?

In slide 43/60 from the 21st May 2024 meeting, they suggest that they could ‘take the SCADA snapshot ~20 seconds earlier’, with a (very!) simplified illustration as follows:

If we wind forward to Meeting #18 on 16th July 2024 (full slide deck here) we can include slide 40 that illustrates in a different way:

So we note from this slide that (as at 16th July 2024):

1)  In terms of feedback from participant:

(a)  The AEMO noted (in the meeting on 16th July 2024)  that three participants had provided support for the change initially disclosed 2 months earlier (in the 21st May 2024 meeting); and

(b)  I’m inferring from this slide (as I was not at the meeting) that there were no concerns raised at that time by any other participant…

… though we are now aware that the AEMO is aware that a number of stakeholders have concerns (including us at Global-Roam Pty Ltd).

2)  There is a note here about ‘low downside risk’, but it’s perhaps ambiguous in the slide …

(a)  This slide seems to clearly indicate that those 3 supportive participants perceived it to be ‘low downside risk’;

(b)  … but perhaps that the AEMO had not yet formed a clear view?

(c)   … or (at the very least) was open to further feedback in July 2024

(d)  and the fact that the issue has not yet been resolved (in April 2025) suggests an awareness that this issue might be more complex than might have been implied in a ‘low downside risk’ statement?

A mashup to illustrate what’s being considered as the change…

Taking two of the illustrations used by the AEMO in its EWCF meetings, I have mashed them together (please excuse my lack of advanced graphics skills) to illustrate the change that is being considered:

As I hope I have highlighted here, the key points are:

1)  The overall duration of the ‘Magic Happens’ sequence of steps remains about the same length;

2)  It’s just shifted forward in time by ~20 seconds such that:

(a)  Data gathering happens earlier … during the preceding dispatch interval;

(b)  Including (importantly, from our perspective)

(c)  The ‘SCADA Snapshot’ (i.e. that currently creates ‘Initial MW’ at the start of each Dispatch Interval) is moved to be at roughly ~23 seconds prior to the end of the preceding dispatch interval.

We have reservations!

But it’s important to note that we have some reservations about the mooted ‘solution’ to this problem, and we understand other parties do as well.  Readers might like to read on, to ‘Why we have reservations about the possible solution AEMO has been considering’ .