Skip to content

Conversation

@tomwetjens
Copy link
Contributor

No description provided.

@tomwetjens tomwetjens changed the title Add baseline to ISP Add baseline to ISP + add ServiceType to FlexOrder Apr 17, 2025
@KoviaX
Copy link
Member

KoviaX commented Apr 18, 2025

Hi @tomwetjens ! Thank you for contributing again 🙂 . Could you explain the use-case where the "DefaultBaseline" would be used? This seems to be an artifact of not sending FlexRequests in the first place, as the setup with FlexRequests already accounts for this case in the form of re-sending them when things have changed.

The DefaultBaseline might work as a temporary solution in the transition phase, but when flexibility becomes part of day to day operations, it becomes very hard to determine what the "DefaultBaseline" is, as not all flexibility will come from Shapeshifter messages most likely.

Let me know what your view on this is!

@tomwetjens
Copy link
Contributor Author

Hi @tomwetjens ! Thank you for contributing again 🙂 . Could you explain the use-case where the "DefaultBaseline" would be used? This seems to be an artifact of not sending FlexRequests in the first place, as the setup with FlexRequests already accounts for this case in the form of re-sending them when things have changed.

The DefaultBaseline might work as a temporary solution in the transition phase, but when flexibility becomes part of day to day operations, it becomes very hard to determine what the "DefaultBaseline" is, as not all flexibility will come from Shapeshifter messages most likely.

@KoviaX so at GOPACS we have a use case where an AGR has two active flexibility contracts: e.g. a "TDTR" contract of 25 MW and a "CBC" contract of 50 MW. The contracted transport capacity (if no flexibility was activated) is 100 MW. Typically this is called the "GTV". The DSO normally wants to activate the TDTR contract first, if flexibility is needed, because it is cheaper. So it sends a FlexOrder to get the 25 MW. And then if more flexibility is needed, the DSO will activate the CBC contract, for let's say another 30 MW. So it sends another FlexOrder to get the 30 MW. The effective transport capacity available to the AGR at this point would 45 MW. Sometimes the CBC contract is used first and then the TDTR contract. It is up to the DSO.
If messages are delivered in time, in the correct order this should not be a problem. But if both FlexOrders were sent at the same time (automated), it could be unclear for the AGR what is the intention of the messages. Also for the settlement it might become unclear which one should be applied first. And additionally, the AGR cannot really do any automated validations without knowing the intent of the DSO.
So we propose that the DSO can make the intention of a FlexRequest and FlexOrder really clear by including the message what the DSO considers the "baseline" from which they are deviating when requesting or activating flexibility.
In the example above, the DefaultBaseline would always be the 100 MW "GTV". In the first FlexOrder for the 25 MW on the TDTR contract, the Baseline would be 100 MW since there was no flexibility activated before. In the second FlexOrder for the 30 MW on the CBC contract, the Baseline would be 75 MW. So the AGR can know that the intent is that the first 25 MW of flexibility was/should be activated by a different FlexOrder (which might still be under way).

We tried to keep the naming of DefaultBaseline and Baseline in line with the original part of the Shapeshifter specification that deals with baselines.

What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants