Validate phase
In Validate phase, informative description of the validate phase processes has been given. In this chapter the use cases will be described as derived from the validate phase.
The USEF MCM validate phase specifies the following use cases:
Use cases for the Validate phase.
| Name | Direction | Message types |
|---|---|---|
| Exchange D-Prognoses per Congestion Point | AGR → DSO | Prognosis / PrognosisResponse |
| Exchange Flexibility Requests | AGR ← DSO | FlexRequest / FlexRequestResponse |
| Exchange Flexibility Offers | AGR → DSO | FlexOffer / FlexOfferResponse |
| Revocation Flexibility Offer | AGR → DSO | FlexOfferRevocation / FlexOfferRevocationResponse |
| Exchange Flexibility Orders | AGR ← DSO | FlexOrder / FlexOrderResponse |
The use cases are explained in the following sections.
Exchange D-Prognoses per Congestion Point
| D-prognosis | ||
|---|---|---|
| Goal in context | D-prognoses are (re)created by the AGR per congestion point, based on its portfolio. These D-prognoses will be submitted to the DSO. D-prognoses should be submitted at least once before the gate closure time. D-prognoses can be updated by transmitting a new one. | |
| Preconditions | Congestion point(s) defined and retrieved from the CRO, AGR per congestion point retrieved from CRO by DSO, AGR-DSO contracts in place. | |
| Successful outcome | D-prognosis message created and accepted by the DSO for each congestion point on which the AGR has active Connections | |
| Failure outcome | RejectionReason | Cause of rejection |
| <See Message validation> | D-prognosis failed to pass validation by the DSO | |
| Lacking ISPs | The prognosis does not include all ISPs in the Period it applies to | |
| Power value rejection | One or more Power values in the prognosis are not plausible | |
| Subordinate sequence number | The message sequence is lower than that of a previously received D-prognosis | |
| [User defined] | Any other reasonable cause to reject the message | |
Related information
Congestion points (with associated DSOs) at which the AGR has contracted prosumers, and active AGRs, are available via the common reference and should have been retrieved prior to executing this use case.
It is essential to use a sequence number that is incremented each time a new revision is sent so the order of transmission can be traced.
Exchange Flexibility Requests
| FlexRequest | ||
|---|---|---|
| Goal in context | If grid congestion is expected, requests for flexibility are created by the DSO and sent to AGRs potentially capable of helping to reduce that congestion. These requests serve as the basis for subsequent flexibility offers. | |
| Preconditions | AGR-DSO market contract in place.One or more Congestion Points registered in the Common Reference, with at least one AGR with contracted Connections on that point.DSO grid safety analysis performed. | |
| Successful outcome | Flexibility requests submitted to AGR(s) | |
| Failure outcome | RejectionReason | Cause of rejection |
| <See Message validation> | FlexRequest failed to pass validation by the AGR | |
| Lacking Requested Disposition | The FlexRequest has no ISP with a “requested” disposition. | |
| Requested Power discrepancy | One or more ISPs with a "requested" disposition has no direction: MinPower < 0 and MaxPower > 0. | |
| Power discrepancy | One or more ISPs has a higher MinPower than MaxPower value. | |
| [User defined] | Any other reasonable cause to reject the message | |
Related information
Each flexibility request should include the ISPs for which congestion is expected, including a direction (MinPower ≥ 0 or MaxPower ≤ 0), and it is advisable to send multiple ISPs for which capacity is still available, to allow AGRs to time-shift load. For each period during which congestion is expected, the DSO may create any number of flexibility requests (including no requests at all). If multiple requests are created, their content must not be identical. Which variations (more/less requested power per ISP, time-shift of load) are created is a DSO-internal business decision.
Exchange Flexibility Offers
| FlexOffer | ||
|---|---|---|
| Goal in context | The AGR creates flexibility offers based on previous DSO flexibility requests and sends these to the originating DSOs. It is also possible to send FlexOffers that do not originate from a FlexRequest, which are called unsolicited FlexOffers. Each offer indicates to which extent the AGR can provide flexibility, what the effect on its baseline will be and what the price for the flexibility would be. | |
| Preconditions | AGR-DSO market contract in place.AGR has at least one contracted Connection on the Congestion point. Flexibility offers can be based on previous flexibility requests that have been accepted and stored, or be initiated without a preliminary flex request (called an unsolicited flex offer). | |
| Successful outcome | Flexibility offers sent to the DSO | |
| Failure outcome | RejectionReason | Cause of rejection |
| <See Message validation> | FlexOffer failed to pass validation by the DSO | |
| No baseline | The AGR has no valid baseline, possibly lacking a valid D-prognosis | |
| Power value rejection | One or more Power values in the FlexOffer are not plausible | |
| Request mismatch | None of the ISPs with a "requested" disposition in the referred FlexRequest, is mentioned in the FlexOffer | |
| No MutEx offer support | The FlexOffer contains mutual exclusive offers (OfferOptions), which is not supported by the DSO | |
| [User defined] | Any other reasonable cause to reject the message | |
Related information
- USEF does not specify how the AGR determines the optimal flexibility offer, offer price or optimal timing to send the offer to the DSO.
- AGRs may choose to send multiple FlexOffer messages: this includes sending a FlexOffer that better meets the DSO request at a much later time when circumstances have changed. Unsolicited FlexOffers are also allowed, in which case the FlexRequestOrigin and FlexRequestSequence fields are empty.
- Sending a FlexOffer for partial activation is always allowed, although it is ignored by the DSO if it does not support partial activation (in which case the MinActivationFactor is always 1).
Note that acceptance of the FlexOffer message does not imply ordering of the flexibility.
Revocation Flexibility Offer
| Revoke FlexOffer | ||
|---|---|---|
| Goal in context | When a previously sent flexibility offer is no longer valid, despite the validity period of the offer not having expired yet, the AGR informs the DSO that the offer is revoked. After revocation, the DSO cannot order the flexibility from this offer anymore. | |
| Preconditions | The concerning flexibility offer has been sent to and acknowledged by the DSO, and has not (yet) been procured using a FlexOrder | |
| Successful outcome | Flexibility offer revocation notification submitted to the DSO | |
| Failure outcome | RejectionReason | Cause of rejection |
| <See Message validation> | FlexOfferRevocation failed to pass validation by the DSO | |
| Flexibility procured | The FlexOffer cannot be revoked because its flexibility has already been ordered | |
| [User defined] | Any other reasonable cause to reject the message | |
Related information
Only flexibility offers communicated using a FlexOffer message which has already been acknowledged by the DSO can be revoked. If the acknowledgement is still pending, the AGR should delay sending its FlexOfferRevocation message until the acknowledgement has been received. When the DSO receives a revocation of a flexibility offer it wants to order, this is not a valid base to reject the revocation. After revocation, the offer can no longer be ordered.
FlexOffers may be revoked at any time in the plan and validate phases (and also in operate phase as described in Revocation Flexibility Offer), unless there is already a FlexOrder based on the offer. Notice that FlexOrders and FlexOfferRevocations can cross each other. Where this is the case, priority should be given to the FlexOfferRevocation.
Exchange Flexibility Orders
| FlexOrder | ||
|---|---|---|
| Goal in context | Process for the DSO to accept (some) flexibility offers to solve Congestion based on the Prognosis. | |
| Preconditions | Corresponding FlexOffer has been received and accepted by DSO and is still valid. | |
| Successful outcome | Flexibility procured | |
| Failure outcome | RejectionReason | Cause of rejection |
| <See Message validation> | FlexOrder failed to pass validation by the AGR | |
| ISP mismatch | ISPs from the FlexOrder do not match the ISPs given in the FlexOffer | |
| Power mismatch | Ordered flexibility does not match the offered flexibility | |
| Price mismatch | Price in the order does not match the price given in the offer | |
| [User defined] | Any other reasonable cause to reject the message | |
Related information
The DSO needs to make its own decisions about which FlexOffers to accept. FlexOffers can only be ordered once and have to be ordered as specified in the corresponding offer for the specified price. Only in situations where partial activation is supported and offered in the FlexOffer can the ISP power and price be altered to conform to the specifications from Section Flexibility trading between the AGR and DSO. After a successful FlexOrder transmission, the AGR is responsible for providing the ordered flexibility via an updated D-prognosis which reflects the traded flexibility.