We left it off our company update for Q3 2021, but one of the other things worth noting is that we’re finding ourselves increasingly called on to help clients with the delivery of AEMO market data.
There are a number of different flavours of this service … ranging:
1) from Hosted MMS for Registered Participants (and other stakeholders);
2) through bundled arrangements as part of our products (such as in the deSide® service for spot-exposed energy users);
3) down to more smaller, bespoke solutions in certain niche areas … like the smaller <5MW (but spot exposed) solar farms I have mentioned before in other articles.
At the core, it means we are investing an increasing amount of time to understand what’s going on with the data AEMO publishes (cadence, latency and so on).
As a result of this, I posted an article in August about Tripwire #4 … asking ‘Do you know what’s causing some increased latency on P5MIN data files on MarketNet in recent weeks’ – as a result of which there were some investigations being conducted inside of AEMO, I believe.
I don’t recall hearing anything further about this – and we also were busy with the transition to Five Minute Settlement (Dan’s company update did cover this!) and now we have moved onto ez2view v9.3, GenInsights21 and other things.
(A) Ongoing, sporadic delays in P5 predispatch file Creation Time
However we’ve fielded a number of questions recently from clients – as a result of which one of our team members ran some numbers Monday afternoon to produce the following trend, which I have tidied up a little and added annotations for the WattClarity® readership here today:
What this shows is the distribution of file creation time at the AEMO for P5 predispatch data from the start of the dispatch interval – with:
1) Many P5 predispatch files* being created ~40 seconds after the start of the dispatch interval
* note that the creation of Dispatch data is about 20-30 seconds faster than this.
2) But there are a significant number of times when it seems some delays creep into the AEMO processes from somewhere and the file creation time can blow out …
(a) to almost 3 minutes in the 8-day period above:
i. With the spike seeming to occur in the middle of the day on most occasions
ii. But not all the time (e.g. last Friday)
(b) and even over 3 minutes in this longer-range analysis in August.
—
We don’t understand what’s happening here – but would be greatly appreciative if any of our readers (if they do know) can help us understand:
1) What the causes of this might be; and
2) What (if anything) is being done to rectify?
(B) Implication of these delays
As noted on the image, a dispatch interval is only 300 seconds long – so on the occasion where it’s taking almost 180 seconds just to create a P5 predispatch file, this does not leave a whole lot of time to do everything else required to take some action within the dispatch interval as a result. This might include:
1) Receiving the file from the AEMO (there’s a bit more time involved in this);
2) Processing, and understanding what’s in it … either with a human in the loop or with an increasing amount of AI being used in automated bidders.
3) Making some decision about what to do, and getting some approval for that (if required):
(a) e.g. rebid – if Scheduled or Semi-Scheduled, or
(b) automate some other action – if Non-Scheduled (or even totally invisible)
4) If rebidding is the course of action, then being able to submit your (correctly formatted) change in bid before ‘Gate Closure’ …
(a) especially keeping in mind that ‘Gate Closure’ on rebids into NEMDE is actually ~60 seconds before the 300 second mark as we showed here.
(b) with the earlier ‘Gate Closure’ to enable NEMDE to run through its process again so that the dispatch data can be published at 10-20 seconds after the start of the dispatch interval
(C) Reflecting back, to 5 Minute Settlement
Given these obvious challenges with operating the P5 predispatch process and delivering new data files in a timely manner, it’s quite obvious why there would have been some resistance at the AEMO to market participant requests to extend P5 predispatch look-ahead beyond the current 11 x dispatch interval useful window beyond the current dispatch interval:
1) Requests came from several organisations (including us) as part of the planning and transition to Five Minute Settlement.
2) Because this could not be done, market participants (the officially registered ones, and a whole lot more who are spot exposed) are left dealing with the challenges of Tripwire #1 and Tripwire #2 in terms of the P30 Predispatch process.
—
Many thanks for those who can help us understand more!
Leave a comment