Add extracted tools: CitrineOS, OpenOCPP, ShapeShifter
- CitrineOS core extracted (CSMS OCPP 2.0.1) - OpenOCPP extracted (firmware OCPP 1.6J/2.0.1) - ShapeShifter library installed (pip install -e) - ShapeShifter specification extracted - EVerest extracted TODO updated with progress
This commit is contained in:
Eric F
@@ -0,0 +1,141 @@
|
||||
<!--
|
||||
SPDX-FileCopyrightText: 2020-2023 Contributors to the Shapeshifter project
|
||||
|
||||
SPDX-License-Identifier: Apache-2.0
|
||||
-->
|
||||
|
||||
# Contract phase
|
||||
|
||||
In [Contract phase](../../general-description/contract-phase.md) the informative description of the contract phase processes has been given.
|
||||
In this chapter use cases will be described as derived from the contract phase.
|
||||
|
||||
The USEF MCM contract phase specifies the following use cases:
|
||||
|
||||
_Use cases for the Contract phase._
|
||||
|
||||
| Name | Direction | Message types |
|
||||
|-------------------------------------------------------------------------------|-----------|-------------------------------------------------|
|
||||
| [Publish Congestion Points (Long-term)](#publish-congestion-points-long-term) | DSO → CRO | DSOPortfolioUpdate / DSOPortfolioUpdateResponse |
|
||||
| [Publish Connections](#publish-connections) | AGR → CRO | AGRPortfolioUpdate / AGRPortfolioUpdateResponse |
|
||||
|
||||
## Publish Congestion Points (Long-term)
|
||||
|
||||
Once a flexibility market is functional for an area, the DSO has to update and publish a register of possible congestion points, including the connection identifiers of connected prosumers.
|
||||
This register is maintained by the Common Reference Operator.
|
||||
If operating in open mode, the CRO will accept updates from any USEF-compliant participants implementing the DSO role.
|
||||
In closed mode, participants will need to be pre-configured in order for updates to be accepted.
|
||||
|
||||
Once populated, the common reference will allow AGRs to determine whether there are prosumers in their portfolio that can offer flexibility, via their connections, to one or more congestion points.
|
||||
|
||||
<figure markdown>
|
||||
{ .no-lightbox }
|
||||
<figcaption>Exchange of congestion points including connections by DSO</figcaption>
|
||||
</figure>
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th></th>
|
||||
<th colspan="2">Publish Congestion Points / DSO Portfolio</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Goal in context</th>
|
||||
<td colspan="2">In order to predict congestion and create a flex market: publish Congestion Points – including their associated Connections – to the Common Reference, so they become available to the AGRs.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Preconditions</th>
|
||||
<td colspan="2">Common Reference is available to DSO and AGRs</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Successful outcome</th>
|
||||
<td colspan="2">The Common Reference is updated with the latest Congestion points and associated Connections (i.e. all connected Prosumers)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th rowspan="6">Failure outcome</th>
|
||||
<th>RejectionReason</th>
|
||||
<th>Cause of rejection</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><See Message validation></td>
|
||||
<td>DSOPortfolioUpdate failed to pass validation by the CRO</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Unauthorized</td>
|
||||
<td>CRO is operating in closed mode and the DSO is not pre-registered as an authorized participant</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Subordinate sequence number</td>
|
||||
<td>The message sequence is lower than that of a previously received DSOPortfolioUpdate</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>[User defined]</td>
|
||||
<td>Any other reasonable cause to reject the message</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
### Related information
|
||||
|
||||
It is the responsibility of the CRO to have policies regarding access, data retention, data security and conflict resolution compliant with the USEF privacy & security guidelines.
|
||||
If the CRO detects strange behavior in the periods (e.g.an EndPeriod in the far past, an EndPeriod earlier than the StartPeriod or an EndPeriod of a congestion point earlier than the EndPeriod of a connection that it contains), it is up to the CRO to decide whether to reject the message, adjust the period or reply with a warning.
|
||||
|
||||
A DSO can update its portfolio by retransmitting the DSOPortfolioUpdate.
|
||||
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.
|
||||
To remove a congestion point, the DSO can transmit a new DSOPortfolioUpdate where the EndPeriod is the current time.
|
||||
The congestion point is then immediately expired.
|
||||
It is not necessary to add connections to this message since they will also expire.
|
||||
|
||||
## Publish Connections
|
||||
|
||||
Once a flexibility market is functional for an area, the AGR has to publish a list of the connection identifiers of the prosumers it has contracted.
|
||||
This list is stored and, subject to access controls, made available to other market participants by the CRO.
|
||||
|
||||
<figure markdown>
|
||||
{ .no-lightbox }
|
||||
<figcaption>Exchange of connections by AGR</figcaption>
|
||||
</figure>
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th></th>
|
||||
<th colspan="2">Publish Congestion Points / DSO Portfolio</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Goal in context</th>
|
||||
<td colspan="2">Publish all contracted Prosumer Connections in the Common Reference, in order to later discover Congestion Points and associated DSOs and to register the AGR’s presence at Connections to the associated DSOs.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Preconditions</th>
|
||||
<td colspan="2">Common Reference is available to DSO and AGRs</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Successful outcome</th>
|
||||
<td colspan="2">The Common Reference is updated with the all Prosumers (listed by their Connection identifiers) represented by the AGR.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th rowspan="6">Failure outcome</th>
|
||||
<th>RejectionReason</th>
|
||||
<th>Cause of rejection</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><See Message validation></td>
|
||||
<td>AGRPortfolioUpdate failed to pass validation by the CRO</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Unauthorized</td>
|
||||
<td>CRO is operating in closed mode and the AGR is not pre-registered as an authorized participant</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Subordinate sequence number</td>
|
||||
<td>The message sequence is lower than that of a previously received DSOPortfolioUpdate</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>[User defined]</td>
|
||||
<td>Any other reasonable cause to reject the message</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
### Related information
|
||||
|
||||
It is possible to transmit connection points to the CRO that have not yet been declared by the DSO.
|
||||
|
||||
An AGR can update its portfolio by retransmitting the AGRPortfolioUpdate.
|
||||
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.
|
||||
@@ -0,0 +1,182 @@
|
||||
<!--
|
||||
SPDX-FileCopyrightText: 2020-2023 Contributors to the Shapeshifter project
|
||||
|
||||
SPDX-License-Identifier: Apache-2.0
|
||||
-->
|
||||
|
||||
# Operate phase
|
||||
|
||||
In [Operate phase](../../general-description/operate-phase.md) 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](#exchange-updated-d-prognoses) | AGR → DSO | Prognosis / PrognosisResponse |
|
||||
| [Revocation Flexibility Offer](#revocation-flexibility-offer) | AGR → DSO | FlexOfferRevocation / FlexOfferRevocationResponse |
|
||||
| [Exchange Flexibility Orders](#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](validate-phase.md#exchange-d-prognoses-per-congestion-point).
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th></th>
|
||||
<th colspan="2">D-prognosis</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Goal in context</th>
|
||||
<td colspan="2">Changes in D-prognoses to be realized are transmitted.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Preconditions</th>
|
||||
<td colspan="2">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.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Successful outcome</th>
|
||||
<td colspan="2">Prognosis sent to DSO that reflects all relevant changes</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th rowspan="6">Failure outcome</th>
|
||||
<th>RejectionReason</th>
|
||||
<th>Cause of rejection</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><See Message validation></td>
|
||||
<td>D-prognosis failed to pass validation by the DSO</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Lacking ISPs</td>
|
||||
<td>The prognosis does not include all ISPs in the Period it applies to</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Power value rejection</td>
|
||||
<td>One or more Power values in the prognosis are not plausible</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Subordinate sequence number</td>
|
||||
<td>The message sequence is lower than that of a previously received D-prognosis</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>[User defined]</td>
|
||||
<td>Any other reasonable cause to reject the message</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
### Related information
|
||||
|
||||
The process is similar to that described in [Exchange D-Prognoses per Congestion Point](validate-phase.md#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](validate-phase.md#revocation-flexibility-offer).
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th></th>
|
||||
<th colspan="2">Revoke FlexOffer</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Goal in context</th>
|
||||
<td colspan="2">Inform the DSO that a previously sent flexibility offer is no longer valid, despite the validity period of the offer not having expired yet.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Preconditions</th>
|
||||
<td colspan="2">A flexibility offer has been sent to and acknowledged by the DSO</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Successful outcome</th>
|
||||
<td colspan="2">Flexibility offer revocation notification submitted to the DSO</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th rowspan="6">Failure outcome</th>
|
||||
<th>RejectionReason</th>
|
||||
<th>Cause of rejection</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><See Message validation></td>
|
||||
<td>FlexOfferRevocation failed to pass validation by the DSO</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Flexibility procured</td>
|
||||
<td>The FlexOffer cannot be revoked because its flexibility has already been ordered</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>[User defined]</td>
|
||||
<td>Any other reasonable cause to reject the message</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
### Related information
|
||||
|
||||
The process is similar to that described in [Revocation Flexibility Offer](validate-phase.md#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](validate-phase.md#exchange-flexibility-orders).
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th></th>
|
||||
<th colspan="2">Revoke FlexOrder</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Goal in context</th>
|
||||
<td colspan="2">Accept (some) flexibility offers to solve congestion during Operate phase.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Preconditions</th>
|
||||
<td colspan="2">Congestion detected while monitoring the grid, corresponding FlexOffer has been received and accepted by DSO and is still valid.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Successful outcome</th>
|
||||
<td colspan="2">Flexibility procured</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th rowspan="6">Failure outcome</th>
|
||||
<th>RejectionReason</th>
|
||||
<th>Cause of rejection</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><See Message validation></td>
|
||||
<td>FlexOrder failed to pass validation by the AGR</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>ISP mismatch</td>
|
||||
<td>ISPs from the FlexOrder do not match the ISPs given in the FlexOffer</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Power mismatch</td>
|
||||
<td>Ordered flexibility does not match the offered flexibility</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Price mismatch</td>
|
||||
<td>Price in the order does not match the price given in the offer</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>[User defined]</td>
|
||||
<td>Any other reasonable cause to reject the message</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
### Related information
|
||||
|
||||
The process is similar to that described in [Exchange Flexibility Orders](validate-phase.md#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.
|
||||
@@ -0,0 +1,184 @@
|
||||
<!--
|
||||
SPDX-FileCopyrightText: 2020-2023 Contributors to the Shapeshifter project
|
||||
|
||||
SPDX-License-Identifier: Apache-2.0
|
||||
-->
|
||||
|
||||
# Plan phase
|
||||
|
||||
In [Plan phase](../../general-description/plan-phase.md) the informative description of the plan phase processes are provided.
|
||||
In this chapter, use cases will be described as derived from the plan phase.
|
||||
|
||||
The USEF MCM plan phase specifies the following use cases:
|
||||
|
||||
_Use cases for the Plan phase._
|
||||
|
||||
| Name | Direction | Message types |
|
||||
|-------------------------------------------------------------------------------------|-----------|-------------------------------------------------------|
|
||||
| [Retrieve Congestion Points](#retrieve-congestion-points) | AGR → CRO | AGRPortfolioQuery / AGRPortfolioQueryResponse |
|
||||
| [Retrieve Active Aggregators](#retrieve-active-aggregators) | DSO → CRO | DSOPortfolioQuery / DSOPortfolioQueryResponse |
|
||||
| [Exchange Flexibility Reservation Update](#exchange-flexibility-reservation-update) | AGR ← DSO | FlexReservationUpdate / FlexReservationUpdateResponse |
|
||||
|
||||
The use cases are explained in the following sections.
|
||||
|
||||
If operating in open mode, the CRO will accept updates from any USEF-compliant participants implementing the AGR role.
|
||||
In closed mode, participants will need to be pre-configured in order for updates to be accepted.
|
||||
|
||||
## Retrieve Congestion Points
|
||||
|
||||
The common reference allows an AGR to determine whether there are any congestion points where prosumers in its portfolio
|
||||
can offer flexibility.
|
||||
|
||||
<figure markdown>
|
||||
{ .no-lightbox }
|
||||
<figcaption>Retrieval of Congestion Points corresponding to AGR's connections</figcaption>
|
||||
</figure>
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th></th>
|
||||
<th colspan="2">Publish Congestion Points / DSO Portfolio</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Goal in context</th>
|
||||
<td colspan="2">Retrieve a list of all registered Connections represented by this AGR, grouped by Congestion Point, in order to enable flex trading with the responsible DSO.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Preconditions</th>
|
||||
<td colspan="2">The AGR has registered the Connection identifiers for which it represents Prosumers in the Common Reference.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Successful outcome</th>
|
||||
<td colspan="2">The AGR receives a list of Connections, grouped by Connection Point and responsible DSO, and a list of Connections that have not been allocated to a DSO.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th rowspan="6">Failure outcome</th>
|
||||
<th>RejectionReason</th>
|
||||
<th>Cause of rejection</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><See Message validation></td>
|
||||
<td>AGRPortfolioQuery failed to pass validation by the CRO</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Unauthorized</td>
|
||||
<td>CRO is operating in closed mode and the AGR is not pre-registered as an authorized participant</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>No connections available</td>
|
||||
<td>The AGR has no registered connections at the Common Reference</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>[User defined]</td>
|
||||
<td>Any other reasonable cause to reject the message</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
### Related information
|
||||
|
||||
AGRs will only obtain DSO identities, congestion point identifiers and connection identifiers for those connections they have registered in the common reference themselves.
|
||||
|
||||
Registered connections that have not (yet) been allocated by a DSO are returned in a separate list, to inform the AGR that there is no DSO available to trade with at those connections.
|
||||
|
||||
## Retrieve Active Aggregators
|
||||
|
||||
If operating in open mode, the CRO will accept queries from any USEF-compliant participants implementing the AGR role.
|
||||
In closed mode, participants will need to be pre-configured in order for updates to be accepted.
|
||||
|
||||
<figure markdown>
|
||||
{ .no-lightbox }
|
||||
<figcaption>Retrieval of registered Connections, grouped by Congestion Point, including corresponding AGR identity</figcaption>
|
||||
</figure>
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th></th>
|
||||
<th colspan="2">Publish Congestion Points / DSO Portfolio</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Goal in context</th>
|
||||
<td colspan="2">Retrieve a list of all DSO-registered Congestion Points with, for each such point, a list of AGRs representing Prosumers there, including the number of Connections each AGR represents.</br></br>The DSO then knows from which AGRs D-prognoses can be expected, and which percentage of the total Connections on each Congestion Point is affected by those prognoses.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Preconditions</th>
|
||||
<td colspan="2">The DSO has determined its Congestion Points and published this information, including the associated Connection identifiers in the Common Reference.</br>The AGR has registered the Connection identifiers for which it represents Prosumers in the Common Reference (see UC1027)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Successful outcome</th>
|
||||
<td colspan="2">AGRs which represent Prosumers at any of the Congestion Points registered by the DSO are available to the DSO</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th rowspan="6">Failure outcome</th>
|
||||
<th>RejectionReason</th>
|
||||
<th>Cause of rejection</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><See Message validation></td>
|
||||
<td>DSOPortfolioQuery failed to pass validation by the CRO</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Unauthorized</td>
|
||||
<td>CRO is operating in closed mode and the AGR is not pre-registered as an authorized participant</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>No connections available</td>
|
||||
<td>The DSO has no registered connections at the Common Reference</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>[User defined]</td>
|
||||
<td>Any other reasonable cause to reject the message</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
### Related information
|
||||
|
||||
DSOs may only obtain AGR identities and combined connection counts for those congestion points they have registered in the common reference themselves.
|
||||
|
||||
## Exchange Flexibility Reservation Update
|
||||
|
||||
Where bilateral contracts are used, the FlexReservationUpdate message can be used at this stage to set or release reserved flexibility.
|
||||
|
||||
<figure markdown>
|
||||
{ .no-lightbox }
|
||||
<figcaption>Exchange of FlexReservationUpdate</figcaption>
|
||||
</figure>
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th></th>
|
||||
<th colspan="2">Publish Congestion Points / DSO Portfolio</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Goal in context</th>
|
||||
<td colspan="2">For all reserved power in a bilateral contract, the DSO signals which part of the contracted volume is still reserved and which part is not needed and may be used for other purposes.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Preconditions</th>
|
||||
<td colspan="2">The DSO and AGR have agreed on a bilateral contract (out of scope for UFTP) which the FlexReservationUpdate refers to.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Successful outcome</th>
|
||||
<td colspan="2">The AGR has received the update and can potentially reoptimize its portfolio based on the changes. The DSO registers the update for settlement purposes.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th rowspan="6">Failure outcome</th>
|
||||
<th>RejectionReason</th>
|
||||
<th>Cause of rejection</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><See Message validation></td>
|
||||
<td>FlexReservationUpdate failed to pass validation by the AGR</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Deadline expired</td>
|
||||
<td>The deadline for the DSO to release reserved flexibility has expired</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Power value rejection</td>
|
||||
<td>One or more Power values in the FlexReservationUpdate are not conform agreement</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>[User defined]</td>
|
||||
<td>Any other reasonable cause to reject the message</td>
|
||||
</tr>
|
||||
</table>
|
||||
@@ -0,0 +1,77 @@
|
||||
<!--
|
||||
SPDX-FileCopyrightText: 2020-2023 Contributors to the Shapeshifter project
|
||||
|
||||
SPDX-License-Identifier: Apache-2.0
|
||||
-->
|
||||
|
||||
# Settle phase
|
||||
|
||||
The informative description of the settle phase processes are provided in [Settle phase](../../general-description/settle-phase.md).
|
||||
In this chapter, the use cases will be described, as derived from the settle phase.
|
||||
|
||||
The USEF MCM settle phase specifies the following use case:
|
||||
|
||||
_Use cases for the settle phase._
|
||||
|
||||
| Name | Direction | Message types |
|
||||
|-------------------------------------------------------|-----------|----------------------------------------|
|
||||
| [Process Settlement Items](#process-settlement-items) | AGR ← DSO | FlexSettlement/ FlexSettlementResponse |
|
||||
|
||||
## Process Settlement Items
|
||||
|
||||
<figure markdown>
|
||||
{ .no-lightbox }
|
||||
<figcaption>Transmission of settlement including acceptance process per settlement item</figcaption>
|
||||
</figure>
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th></th>
|
||||
<th colspan="2">Revoke FlexOrder</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Goal in context</th>
|
||||
<td colspan="2">DSO sends consolidated settlement volumes and prices to the AGR for a specific period. AGR verifies the settlement calculations performed by DSO: acknowledge settlement items that are plausible according to the AGR or start a dispute process if they show disputable results. AGR returns the list of verified settlement items.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Preconditions</th>
|
||||
<td colspan="2">All settlement items within the period are available and complete</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Successful outcome</th>
|
||||
<td colspan="2">Periodic settlement invoice sent by DSO, validated by AGR and a potential dispute process is started.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th rowspan="6">Failure outcome</th>
|
||||
<th>RejectionReason</th>
|
||||
<th>Cause of rejection</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><See Message validation></td>
|
||||
<td>FlexSettlement failed to pass validation by the AGR</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Missing Settlement Items</td>
|
||||
<td>Not all flexibility that have been procured within the given period is included as a settlement item.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>PeriodStart rejected</td>
|
||||
<td>The settlement period starts too late (for example in case there are unsettled items from an earlier period) or is not plausible (for example in case it starts in the future).</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>PeriodEnd rejected</td>
|
||||
<td>The settlement period ends too early (for example in case there are unsettled items from a later period that have to be treated too) or is not plausible (for example in case it is earlier than the PeriodStart or in the future).</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>[User defined]</td>
|
||||
<td>Any other reasonable cause to reject the message</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
### Related information
|
||||
|
||||
If settlement items are missing, the message should be rejected (as mentioned in failure outcome).
|
||||
This is to encourage sending of all required information necessary to settle trades as soon as possible, thereby avoiding a series of unsettled trades for a given period.
|
||||
|
||||
Note that the rejection of a FlexSettlement message is not a means of raising a dispute for settlement items.
|
||||
The dispute process is out-of-scope for USEF.
|
||||
@@ -0,0 +1,363 @@
|
||||
<!--
|
||||
SPDX-FileCopyrightText: 2020-2023 Contributors to the Shapeshifter project
|
||||
|
||||
SPDX-License-Identifier: Apache-2.0
|
||||
-->
|
||||
|
||||
# Validate phase
|
||||
|
||||
In [Validate phase](../../general-description/validate-phase.md), 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](#exchange-d-prognoses-per-congestion-point) | AGR → DSO | Prognosis / PrognosisResponse |
|
||||
| [Exchange Flexibility Requests](#exchange-flexibility-requests) | AGR ← DSO | FlexRequest / FlexRequestResponse |
|
||||
| [Exchange Flexibility Offers](#exchange-flexibility-offers) | AGR → DSO | FlexOffer / FlexOfferResponse |
|
||||
| [Revocation Flexibility Offer](#revocation-flexibility-offer) | AGR → DSO | FlexOfferRevocation / FlexOfferRevocationResponse |
|
||||
| [Exchange Flexibility Orders](#exchange-flexibility-orders) | AGR ← DSO | FlexOrder / FlexOrderResponse |
|
||||
|
||||
The use cases are explained in the following sections.
|
||||
|
||||
## Exchange D-Prognoses per Congestion Point
|
||||
|
||||
<figure markdown>
|
||||
{ .no-lightbox }
|
||||
<figcaption>Exchange of D-prognoses</figcaption>
|
||||
</figure>
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th></th>
|
||||
<th colspan="2">D-prognosis</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Goal in context</th>
|
||||
<td colspan="2">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.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Preconditions</th>
|
||||
<td colspan="2">Congestion point(s) defined and retrieved from the CRO, AGR per congestion point retrieved from CRO by DSO, AGR-DSO contracts in place.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Successful outcome</th>
|
||||
<td colspan="2">D-prognosis message created and accepted by the DSO for each congestion point on which the AGR has active Connections</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th rowspan="6">Failure outcome</th>
|
||||
<th>RejectionReason</th>
|
||||
<th>Cause of rejection</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><See Message validation></td>
|
||||
<td>D-prognosis failed to pass validation by the DSO</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Lacking ISPs</td>
|
||||
<td>The prognosis does not include all ISPs in the Period it applies to</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Power value rejection</td>
|
||||
<td>One or more Power values in the prognosis are not plausible</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Subordinate sequence number</td>
|
||||
<td>The message sequence is lower than that of a previously received D-prognosis</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>[User defined]</td>
|
||||
<td>Any other reasonable cause to reject the message</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
### 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
|
||||
|
||||
<figure markdown>
|
||||
{ .no-lightbox }
|
||||
<figcaption>Exchange of FlexRequests</figcaption>
|
||||
</figure>
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th></th>
|
||||
<th colspan="2">FlexRequest</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Goal in context</th>
|
||||
<td colspan="2">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.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Preconditions</th>
|
||||
<td colspan="2">AGR-DSO market contract in place.</br>One or more Congestion Points registered in the Common Reference, with at least one AGR with contracted Connections on that point.</br>DSO grid safety analysis performed.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Successful outcome</th>
|
||||
<td colspan="2">Flexibility requests submitted to AGR(s)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th rowspan="6">Failure outcome</th>
|
||||
<th>RejectionReason</th>
|
||||
<th>Cause of rejection</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><See Message validation></td>
|
||||
<td>FlexRequest failed to pass validation by the AGR</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Lacking Requested Disposition</td>
|
||||
<td>The FlexRequest has no ISP with a “requested” disposition.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Requested Power discrepancy</td>
|
||||
<td>One or more ISPs with a "requested" disposition has no direction: MinPower < 0 and MaxPower > 0.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Power discrepancy</td>
|
||||
<td>One or more ISPs has a higher MinPower than MaxPower value.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>[User defined]</td>
|
||||
<td>Any other reasonable cause to reject the message</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
### 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
|
||||
|
||||
<figure markdown>
|
||||
{ .no-lightbox }
|
||||
<figcaption>Exchange of FlexOffers</figcaption>
|
||||
</figure>
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th></th>
|
||||
<th colspan="2">FlexOffer</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Goal in context</th>
|
||||
<td colspan="2">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.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Preconditions</th>
|
||||
<td colspan="2">AGR-DSO market contract in place.</br>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).</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Successful outcome</th>
|
||||
<td colspan="2">Flexibility offers sent to the DSO</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th rowspan="6">Failure outcome</th>
|
||||
<th>RejectionReason</th>
|
||||
<th>Cause of rejection</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><See Message validation></td>
|
||||
<td>FlexOffer failed to pass validation by the DSO</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>No baseline</td>
|
||||
<td>The AGR has no valid baseline, possibly lacking a valid D-prognosis</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Power value rejection</td>
|
||||
<td>One or more Power values in the FlexOffer are not plausible</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Request mismatch</td>
|
||||
<td>None of the ISPs with a "requested" disposition in the referred FlexRequest, is mentioned in the FlexOffer</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>No MutEx offer support</td>
|
||||
<td>The FlexOffer contains mutual exclusive offers (OfferOptions), which is not supported by the DSO</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>[User defined]</td>
|
||||
<td>Any other reasonable cause to reject the message</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
### 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
|
||||
|
||||
<figure markdown>
|
||||
{ .no-lightbox }
|
||||
<figcaption>Revocation of FlexOffer</figcaption>
|
||||
</figure>
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th></th>
|
||||
<th colspan="2">Revoke FlexOffer</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Goal in context</th>
|
||||
<td colspan="2">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.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Preconditions</th>
|
||||
<td colspan="2">The concerning flexibility offer has been sent to and acknowledged by the DSO, and has not (yet) been procured using a FlexOrder</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Successful outcome</th>
|
||||
<td colspan="2">Flexibility offer revocation notification submitted to the DSO</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th rowspan="6">Failure outcome</th>
|
||||
<th>RejectionReason</th>
|
||||
<th>Cause of rejection</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><See Message validation></td>
|
||||
<td>FlexOfferRevocation failed to pass validation by the DSO</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Flexibility procured</td>
|
||||
<td>The FlexOffer cannot be revoked because its flexibility has already been ordered</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>[User defined]</td>
|
||||
<td>Any other reasonable cause to reject the message</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
### 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](operate-phase.md#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
|
||||
|
||||
### Accepting a FlexOffer
|
||||
|
||||
<figure markdown>
|
||||
{ .no-lightbox }
|
||||
<figcaption>Exchange of FlexOrder</figcaption>
|
||||
</figure>
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th></th>
|
||||
<th colspan="2">FlexOrder</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Goal in context</th>
|
||||
<td colspan="2">Process for the DSO to accept (some) flexibility offers to solve Congestion based on the Prognosis.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Preconditions</th>
|
||||
<td colspan="2">Corresponding FlexOffer has been received and accepted by DSO and is still valid.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Successful outcome</th>
|
||||
<td colspan="2">Flexibility procured</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th rowspan="6">Failure outcome</th>
|
||||
<th>RejectionReason</th>
|
||||
<th>Cause of rejection</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><See Message validation></td>
|
||||
<td>FlexOrder failed to pass validation by the AGR</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>ISP mismatch</td>
|
||||
<td>ISPs from the FlexOrder do not match the ISPs given in the FlexOffer</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Power mismatch</td>
|
||||
<td>Ordered flexibility does not match the offered flexibility</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Price mismatch</td>
|
||||
<td>Price in the order does not match the price given in the offer</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>[User defined]</td>
|
||||
<td>Any other reasonable cause to reject the message</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
### FlexOrder without offer
|
||||
|
||||
<figure markdown>
|
||||
{ .no-lightbox }
|
||||
<figcaption>Exchange of FlexOrder without FlexOffer</figcaption>
|
||||
</figure>
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th></th>
|
||||
<th colspan="2">FlexOrder</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Goal in context</th>
|
||||
<td colspan="2">Process for the DSO to procure flexibility directly, without a FlexOffer, based on existing agreement, to solve Congestion based on the Prognosis.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Preconditions</th>
|
||||
<td colspan="2">AGR-DSO market contract in place.<br/>One or more Congestion Points registered in the Common Reference, with at least one AGR with contracted Connections on that point.</br>DSO grid safety analysis performed.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Successful outcome</th>
|
||||
<td colspan="2">Flexibility procured</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th rowspan="6">Failure outcome</th>
|
||||
<th>RejectionReason</th>
|
||||
<th>Cause of rejection</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><See Message validation></td>
|
||||
<td>FlexOrder failed to pass validation by the AGR</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Requested Power discrepancy</td>
|
||||
<td>One or more ISPs with a "requested" disposition has no direction: MinPower < 0 and MaxPower > 0.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Power discrepancy</td>
|
||||
<td>One or more ISPs has a higher MinPower than MaxPower value.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>[User defined]</td>
|
||||
<td>Any other reasonable cause to reject the message</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
### 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](../../general-description/validate-phase.md#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.
|
||||
Reference in New Issue
Block a user