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,26 @@
|
||||
<!--
|
||||
SPDX-FileCopyrightText: 2020-2023 Contributors to the Shapeshifter project
|
||||
|
||||
SPDX-License-Identifier: Apache-2.0
|
||||
-->
|
||||
|
||||
# Common concepts
|
||||
|
||||
The USEF specification standardizes the logical interfaces and defines the minimum functionality of the components in the form of use cases (this chapter) and [message transport specifications](../appendix/message-transport-mechanism.md) and [message descriptions](../message-descriptions/scope.md).
|
||||
This leaves room for innovation and possibilities to develop specific implementation architectures based on e.g. size of the market, specific local circumstances or commercial exploitation of USEF platforms.
|
||||
Stakeholders involved in a USEF market can and must develop business functions and capabilities independently, and focus on their core business and competitive advantage.
|
||||
|
||||
While the USEF specification is technology and implementation agnostic, there are some basic principles to which any USEF implementation architecture must adhere.
|
||||
Some of these are listed as high-level requirements.
|
||||
When an ICT implementation architecture is defined, the actual implementation requirements must be defined and included in the design.
|
||||
|
||||
- A USEF market implementation will typically consist of multiple information systems interacting together according to the USEF interaction standard in order to run the market processes.
|
||||
The USEF foundation does not want to narrow down the open nature of the USEF specifications by defining exactly how the information system architecture must be implemented.
|
||||
- The USEF specifications do not currently define exceptions and how to handle them.
|
||||
Therefore, the use cases also prescribe only the default main scenario without error handling, and only the successful outcome.
|
||||
The single exception to this rule is described in the next bullet.
|
||||
USEF does provide some recommended practices for handling some of the failure handling.
|
||||
- Any USEF IT architecture must adhere to the USEF privacy & security guideline.[^B5]
|
||||
In the USEF use cases the most relevant privacy & security considerations are provided.
|
||||
|
||||
[^B5]: USEF Foundation, "USEF: The Privacy and Security Guideline," USEF Foundation, Arnhem, 2015. Available: [https://www.usef.energy/app/uploads/2016/12/USEF_PrivacySecurityGuideline_3nov15.pdf](https://www.usef.energy/app/uploads/2016/12/USEF_PrivacySecurityGuideline_3nov15.pdf)
|
||||
@@ -0,0 +1,75 @@
|
||||
<!--
|
||||
SPDX-FileCopyrightText: 2020-2023 Contributors to the Shapeshifter project
|
||||
|
||||
SPDX-License-Identifier: Apache-2.0
|
||||
-->
|
||||
|
||||
# Message validation
|
||||
|
||||
Incoming messages need to be validated by the recipient for their correctness.
|
||||
Validation of the semantics is performed by the HTTP over TLS (explained in [Message transport mechanism](../appendix/message-transport-mechanism.md)), but the content still needs to be checked for possible discrepancies.
|
||||
If the message passes validation, a response message is sent with ‘accepted’ in the result field.
|
||||
If it fails validation, a response message is sent with ‘rejected’ in the result field, along with a description of the reason why the message is rejected in the RejectionReason field.
|
||||
Some causes to reject a message are specific for the type of message and are mentioned in the remainder of this chapter.
|
||||
Other causes are more generic and are listed in the table below.
|
||||
|
||||
This list is not all-encompassing: stakeholders are allowed to formulate other reasonable causes to reject a message, as long as it is clearly explained in the RejectionReason field. Adding the cause of the rejection will facilitate in building a correct implementation.
|
||||
This field can contain multiple reasons for rejections (separated by a semicolon).
|
||||
|
||||
| RejectionReason | Cause of rejection | Applicable to messages |
|
||||
|---|---|---|
|
||||
| Unknown SenderDomain (SignedMessage) | SenderDomain specified in the SignedMessage is unknown to the receiving implementation. | SM |
|
||||
| Invalid SenderRole | The SenderRole specified in the SignedMessage is invalid. | SM |
|
||||
| Invalid Sender combination | The combination SenderDomain and SenderRole in the SignedMessage is invalid.| SM |
|
||||
| Mismatch SenderDomain | SenderDomain specified in the SignedMessage doesn't match with the SenderDomain in the inner XML message. | SM & All other message types |
|
||||
| Invalid SignedMessage | The SignedMessage complies with the XSD schema, but failed to pass validation. | SM |
|
||||
| Invalid Message | Despite being schema-compliant, the syntax, type or semantics of the message were unacceptable for the receiving implementation. | All message types |
|
||||
| Unknown RecipientDomain | The RecipientDomain specified in the inner XML message is not known to the receiving implementation. | All message types |
|
||||
| Unknown SenderDomain (message) | SenderDomain specified in the message is unknown to the receiving implementation. | All message types except SM |
|
||||
| Barred Sender | This endpoint is explicitly blocking messages from this sender. | SM |
|
||||
| Duplicate Identifier | The MessageID attribute of the inner XML message is not unique, and has already been used for a message with different content. This message has been rejected. | All message types except SM |
|
||||
| Already Submitted | The MessageID attribute of the inner XML message is not unique, but since the message content is the same as that of a previously accepted message, this copy can be considered to be successfully submitted as well. | All message types except SM |
|
||||
| ISP duration rejected | The message specifies a ISP duration that is not the agreed-upon common value for the market in which it is used. | All message types that contain ISP's: FRU, DP, FR, FO, FOR, M, FS, FS_R|
|
||||
| TimeZone rejected | The message specifies a TimeZone that has a different UTC offset than is the agreed-upon common value for the market. | All message types that contain Period: APQ, APQ_R, DPQ, DPQ_R, FRU, DP, FR, FO, FOR, M, FS, FS_R |
|
||||
| Invalid CongestionPoint | Unknown CongestionPoint or the recipient is not active at this CongestionPoint. | FRU, DP, FR, FO, FOR, FS |
|
||||
| Unknown <MessageType\>MessageID reference | The message the MessageID refers to is unknown.<br />For <MessageType\> the referenced MessageType can be filled in.<br />For example: *FlexRequestMessageID* or *D-PrognosisMessageID*. | APU_R, APQ_R, FRU_R, DP_R, FR_R, FO, FOF_R, FOFR, FOFR_R, FOR, FOR_R, M_R, FS, FS_R |
|
||||
| Reference Period mismatch | The message the <MessageType\>MessageID refers to contains a different Period. | MessageTypes that refer to other messages using <MessageType\>MessageID AND contain a Period themselves: APQ_R, FO FOFR, FOR, FS, FS_R |
|
||||
| Reference message expired | The message <MessageType\>MessageID refers to is expired. | APU_R, APQ_R, FRU_R, DP_R, FR_R, FO, FOF_R, FOFR, FOFR_R, FOR, FOR_R, M_R, FS, FS_R |
|
||||
| Reference message revoked | The message <MessageType\>MessageID refers is revoked. | APU_R, APQ_R, FRU_R, DP_R, FR_R, FO, FOF_R, FOFR, FOFR_R, FOR, FOR_R, M_R, FS, FS_R |
|
||||
| ISPs out of bounds | One or more ISPs are outside the tolerated boundaries.<br /> - At least 1 ISP should exist in the messages that expect them. <br />- Also, the amount of ISPs that are about a Period (one *day*) can never exceed *(24 hours / ISP-Duration (in hours)) + DST_offset*<br />What that means is that for example: you can't have more than (24 hours (1 Period) / 0.25 (PT15M)) = 96 ISPss. <br />Exceptions are depending on wether or not DST applies (for Europe for example), then you have an hour less or more on the day so the maximums would in those cases be: 96 - 4 = 92 or 96 + 4 = 100. More ISPs for that specific Period would be invalid. | FRU, DP, FR, FO, FOR, M, FS, FS_R |
|
||||
| ISP conflict | One or more ISPs are defined more than once, possibly because of an incorrect duration.<br />For example:<br /><pre><FlexRequest<br /> <ISP Start = 1 Duration = 4 ... /\><br /> <ISP Start = 2 Duration = 1 ... /\><br />/\></pre><br /> The second ISP will overlap the first. | FRU, DP, FR, FO, FOR, M, FS, FS_R |
|
||||
| Period out of bounds | Period of the message is inappropriate.<br />For example: a FlexRequest with a Period in the past or a settlement item in a FlexSettlement with a Period outside the concerning settlement period. | APQ, APQ_R, DPQ, DPQ_R, FRU, DP, FR, FO, FOR, M, FS, FS_R |
|
||||
| ExpirationDateTime out of bounds | ExpirationDateTime is in the past or exceeds the ISPs in the message. The acceptable content can best be discussed and agreed upon between the sending and receiving parties. | FR, FOF |
|
||||
| [Other reasonable cause] | [Implementation specific rejection reason] | TBD |
|
||||
|
||||
Because typing all MessageTypes out in full takes a lot of space, a list of abbreviations has been created that can be used when communicating about the specification:
|
||||
|
||||
| MessageType | Abbreviation |
|
||||
|---|---|
|
||||
| SignedMessage | SM |
|
||||
| TestMessage | TM |
|
||||
| TestMessageResponse | TM_R |
|
||||
| AGRPortfolioUpdate | APU |
|
||||
| AGRPortfolioUpdateResponse | APU_R |
|
||||
| AGRPortfolioQuery | APQ |
|
||||
| AGRPortfolioQueryResponse | APQ_R |
|
||||
| DSOPortfolioUpdate | DPU |
|
||||
| DSOPortfolioUpdateResponse | DPU_R |
|
||||
| DSOPortfolioQuery | DPQ |
|
||||
| DSOPortfolioQueryResponse | DPQ_R |
|
||||
| FlexReservationUpdate | FRU |
|
||||
| FlexReservationUpdateResponse | FRU_R |
|
||||
| D-Prognosis | DP |
|
||||
| D-PrognosisResponse | DP_R |
|
||||
| FlexRequest |FR |
|
||||
| FlexRequestResponse | FR_R |
|
||||
| FlexOffer | FOF |
|
||||
| FlexOfferResponse | FOF_R |
|
||||
| FlexOfferRevocation | FOFR |
|
||||
| FlexOfferRevocationResponse | FOFR_R |
|
||||
| FlexOrder | FOR |
|
||||
| FlexOrderResponse | FOR_R |
|
||||
| Metering | M |
|
||||
| MeteringResponse | M_R |
|
||||
| FlexSettlement | FS |
|
||||
| FlexSettlementResponse | FS_R |
|
||||
@@ -0,0 +1,32 @@
|
||||
<!--
|
||||
SPDX-FileCopyrightText: 2020-2023 Contributors to the Shapeshifter project
|
||||
|
||||
SPDX-License-Identifier: Apache-2.0
|
||||
-->
|
||||
|
||||
# Privacy and security by design
|
||||
|
||||
USEF – like most complex information systems – deals with sensitive data and therefore requires security and privacy preservation measures.
|
||||
Privacy & security are system-wide issues; protection of individual subsystems/components is not enough; the system is as strong as the weakest link.
|
||||
USEF therefore follows the principle of privacy & security by design.
|
||||
|
||||
USEF provides a separate privacy and security guideline [^B5] that lists approximately 50 design principles which, combined, present a complete view of the privacy and security aspects associated with smart energy systems.
|
||||
It takes into account the current legal and social views on privacy & security and links these to the future directions in which they will likely evolve.
|
||||
|
||||
[^B5]: USEF Foundation, "USEF: The Privacy and Security Guideline," USEF Foundation, Arnhem, 2015. Available: [https://www.usef.energy/app/uploads/2016/12/USEF_PrivacySecurityGuideline_3nov15.pdf](https://www.usef.energy/app/uploads/2016/12/USEF_PrivacySecurityGuideline_3nov15.pdf)
|
||||
|
||||
The guideline forms the basis for the logical security architecture that is reflected in USEF’s process flows and use cases.
|
||||
Some remarks about security and responsibility:
|
||||
|
||||
- Personal and personally identifiable data represent commercially sensitive information. These include:
|
||||
- connection identifiers
|
||||
- existence of congestion points
|
||||
- details on AGRs associated to a connection
|
||||
- portfolio data
|
||||
- forecast data, content of D-prognoses and the fact whether or not a given AGR submitted a D-prognosis in a timely fashion
|
||||
- the existence, content and timing of a flexibility request and other flexibility trading messages
|
||||
- settlement items, including the acknowledgement or disputation of their correctness
|
||||
- Personal and personally identifiable data (such as forecasts or smart meter readings) should not be retained longer than strictly required. The retention period should be specified and be communicated to the data subject.
|
||||
- The exact identity of the AGR for each connection should not be disclosed to the DSO. Instead, only aggregate connection counts should be provided (which represent commercially sensitive 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.
|
||||
- The CRO should only disclose the existence of the congestion point on a need-to-know basis, i.e. only to those AGRs which provide an associated connection identifier in their queries.
|
||||
@@ -0,0 +1,19 @@
|
||||
<!--
|
||||
SPDX-FileCopyrightText: 2020-2023 Contributors to the Shapeshifter project
|
||||
|
||||
SPDX-License-Identifier: Apache-2.0
|
||||
-->
|
||||
|
||||
# Reading guidelines
|
||||
|
||||
This chapter contains separate sections per USEF phase: Plan, Validate, Operate, and Settle.
|
||||
In each section the use cases are specified in a standard table format:
|
||||
|
||||
_Standard table format for USEF use cases._
|
||||
|
||||
| | |
|
||||
|------------------------|------------------------------------------------------------------------------------------------------------------------------|
|
||||
| **Goal in context** | High-level description of the activity. |
|
||||
| **Preconditions** | The state of the system that must be present prior to a use case being performed. |
|
||||
| **Successful outcome** | The state the system will be in immediately after a use case has finished without failure. |
|
||||
| **Failure outcome** | The state the system will be in immediately after a use case has finished after failure, plus identification of the failure. |
|
||||
@@ -0,0 +1,30 @@
|
||||
<!--
|
||||
SPDX-FileCopyrightText: 2020-2023 Contributors to the Shapeshifter project
|
||||
|
||||
SPDX-License-Identifier: Apache-2.0
|
||||
-->
|
||||
|
||||
# Scope
|
||||
|
||||
This chapter provides details of the functions that contain interactions relevant to the DSO and AGR, in order to be active in the USEF MCM.
|
||||
To be USEF compliant, these functions must be implemented according to the use case descriptions in this chapter.
|
||||
|
||||
The use cases have been derived from the MCM sequence diagrams detailed in Chapter [General description](../general-description/index.md).
|
||||
Use cases are separate activities that require interaction between DSO and AGR, each containing multiple messages in both directions.
|
||||
DSO and AGR internal processes are not addressed in this chapter.
|
||||
|
||||
The messages types that occur in these use cases are mentioned and further described in Section [Message catalog](../message-descriptions/message-catalog/index.md).
|
||||
|
||||
## Introduction
|
||||
|
||||
The core of the USEF specification is the MCM and the processes governing it.
|
||||
These define how the different stakeholders active in the MCM should behave and interact.
|
||||
All use cases related to these functions are described to the extent relevant for the USEF specifications.
|
||||
All aspects not specified by USEF are explicitly mentioned.
|
||||
An example of this is that USEF does not specify how an AGR optimizes its portfolio or determines how much flexibility is available, where or when.
|
||||
The result of this portfolio optimization is, however, a prerequisite for participating in the flexibility bidding process.
|
||||
|
||||
For the flexibility market to function, it is essential to have a functioning common reference populated with all AGR-represented connections.
|
||||
|
||||
Given the open nature of the USEF specifications, any implementation can choose to adopt all or only part of the specifications.
|
||||
In any situation, all participants within a single USEF market will have to adopt a common specification of the market processes and information exchange.
|
||||
@@ -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