Operate phase
In Operate phase the informative description of the operate phase processes are provided. In this chapter, the use cases will be described as derived from the operate phase.
The USEF MCM operate phase specifies the following use cases:
Use cases for the operate phase.
| Name | Direction | Message types |
|---|---|---|
| Exchange updated D-Prognoses | AGR → DSO | Prognosis / PrognosisResponse |
| Revocation Flexibility Offer | AGR → DSO | FlexOfferRevocation / FlexOfferRevocationResponse |
| Exchange Flexibility Orders | AGR ← DSO | FlexOrder / FlexOrderResponse |
The use cases are explained in the following sections.
Exchange updated D-Prognoses
The process diagram is similar to the figure in Exchange D-Prognoses per Congestion Point.
| D-prognosis | ||
|---|---|---|
| Goal in context | Changes in D-prognoses to be realized are transmitted. | |
| Preconditions | AGR has created initial D-prognoses in the Plan/Validate phases, and has subsequently detected deviations in Operate that resulted in a portfolio state that requires those prognoses to be re-created. | |
| Successful outcome | Prognosis sent to DSO that reflects all relevant changes | |
| 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
The process is similar to that described in Exchange D-Prognoses per Congestion Point. Deviations can be caused by new flexibility orders from the DSO and by unforeseen change of behavior by assets.
The basic process for re-creating D-prognoses is the same as that used to create them in the first place, in the plan/validate phases. When re-creating prognoses in the operate phase, values for ISPs that are already in the past should remain unchanged, as these will be ignored by DSOs anyway.
Revocation Flexibility Offer
The process diagram is similar to the figure in Revocation of FlexOffer.
| Revoke FlexOffer | ||
|---|---|---|
| Goal in context | Inform the DSO that a previously sent flexibility offer is no longer valid, despite the validity period of the offer not having expired yet. | |
| Preconditions | A flexibility offer has been sent to and acknowledged by the DSO | |
| 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
The process is similar to that described in Revocation Flexibility Offer.
Flexibility offers may be revoked in the operate phase provided that none of the ISPs in the period the offer applies to are already in, or past, the operate phase.
Exchange Flexibility Orders
This process is triggered when flexibility is required to resolve congestion detected during the operate phase. This might, for example, be the case when the prognoses change after the validate phase and there are still FlexOffers available.
The process diagram is similar to the figure in Exchange Flexibility Orders.
| Revoke FlexOrder | ||
|---|---|---|
| Goal in context | Accept (some) flexibility offers to solve congestion during Operate phase. | |
| Preconditions | Congestion detected while monitoring the grid, 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 process is similar to that described in Exchange Flexibility Orders. Note that where a FlexOrder is rejected, manual processing is unlikely to result in timely resolution at this stage. Note that although the updated D-prognosis is unlikely to be of immediate use to the DSO, it’s definitely required for settlement.