Flex-Offers
Flex-offer is generated by the sender, e.g. the Posumer or in case of an aggregated FlexOffer the BRP, which has defined flexibilities in time and in quantity for a given price. The energy must be delivered within the flexoffer time and energy constraints. There are additional parameters defined by the sender for handling the flexibilities. One such parameter is Acceptance before time, which is the time until which the flex-offer must be accepted or refused. Another one is Assignment before time, which is the time until which the flexibilities must be fixed. Alternatively to (absolute) time, the sender can state time intervals: Acceptance before period is the minimal time interval prior to the actual delivery (termed Operation start time) that the send must be informed whether the flex-offer has been accepted or rejected; Assignment before period is minimal time interval prior to the Operation start time that the sender must be informed about the delivery (fixing the flexibilities). Assigned flex-offer is a flex-offer with fixed flexibilities. Assignment of the flex-offer produces the flexcontract.
Flexibility Parameters
The advantage of flexibilities is derived from business strategy of BRP, for which the flexibilities in flex-offers are an additional instrument for trading. For management of flexibilities at BRP there are two important parameters: Acceptance before time (or Acceptance before period and Assignment before time (or Assignment before period), also called Revoke time/period. Their significance can be explained as follows:
(click picture to enlarge)
- When trading far before the Operation start time (e.g. in day ahead or further ahead market), first firm offers and then flex-offers with distant Assignment before times - long revoke periods are traded.
- Flex-offers with close Assignment before times - short revoke periods, are not used up but are kept for trading closer to operation start time, such as in the present intra-day trading. The advantage of flex-offers is that they enable compensation of imbalances. Since with the MIRABEL, the status will be calculated periodically in short time intervals minimizing the time difference to the operation interval as much as possible, e.g. 1 hour or less, the BRP can come with its latest forecast close to the operation start time as much as computationally possible - providing that constraints imposed by the electricity market system allow it - and compensate the imbalances to a very high degree. A similar strategy is used for including more RES on the grid.
Additionally, the flex-offers have to be accepted sufficiently before the operation period, to enable flex-offer processing i.e. aggregation, scheduling and matching, and disaggregation. The additional important parameter in flexoffer management is therefore the Acceptance before time (or Acceptance before period).
Lifecycle
A Flex-Offer issued by Prosumers is send to their BRP (e.g. Utility company) and processed.
(click picture to enlarge)
Negotiation
Demand Response based on the flex-offer concept increases the BRPs ability to reduce peak energy demand or supply. Thus Mirabel gives BRPs the oportunity increase their profit by reducing costs on the reserve energy market. Each flex-offer potentially increases the profit of the BRP. He can avoid costs on the reserve energy market or trade capacities. The Prosumer can expect a monetary incentive for each flex-offer. Negotiation finds an agreement between the prosumer and its BRP about the price for flex-offers. Depending on the business strategy of the BRP various price setting schemes are possible, see Negotiation.
Planning
During planning the BRP maximizes its profit by calculating the optimal assignment of all currently accepted FlexOffers. Aggregated sets of FlexOffers are used to reduce the problem size for the Scheduling component while minimizing the loss of flexibility.
Control
Once a FlexOffer has been assigned its flexibilities are fixed and will not be changed the the BRP anymore. The Prosumer gets informed about the assignment parameters and is responsible for the timely execution.
Billing
Billing is done after the execution time of each FlexOffer.