Background
Scheduling of million of micro flex-offers individually in near real-time is unrealistic. To this aim, similar flex-offers are aggregated into larger macro flex-offers that can then be scheduled within reasonable time. The aggregation component is thus responsible of both aggregation and disaggregation. Typically, aggregation inputs a large set (> 10.000.000 per day) of flex-offers and outputs a substantially smaller set of aggregated flex-offers, which can now be scheduled in reasonable time, producing a set of scheduled aggregated flex-offers. Disaggregation transforms these into a set of scheduled (micro) flex-offers. This process must always satisfy the:
Disaggregation requirement
It should be always
possible to correctly disaggregate scheduled flex-offers. Aggregated
scheduled flex-offers can always be converted into (non-aggregated)
scheduled flex-offers while respecting the initial flex-offer constraints. If not,
the macro-level schedule does not correspond to the micro-level one,
and it is impossible to balance energy supply and demand at the
micro-level.
Additionally, the process should try to as-well-as-possible satisfy the following 3 (conflicting) requirements:
Compression requirement. The number of aggregated flex-offers should be as small as possible to reduce scheduling time.
Flexibility requirement. The loss of flexibility in the aggregation should be as small as possible. When aggregating two or more flex-offers into a single one, either
energy flexibility (the ability to scale energy up or down at a given
time) or time flexibility (the ability to shift energy use/production in time) is often lost
because of the many possible flexibility combinations, only one of
which can be chosen.
Efficiency requirement. Aggregation, scheduling, and disaggregation must complete within a given (short) time.
First, it is assumed that a set of flex-offers is always aggregated into a single aggregated flex-offer. All internal constraints of an aggregated flex-offer are produced conservatively so that (1) all profiles of the underlying flex-offers can always be shifted in the time flexibility range of the aggregated flex-offer; (2) energy values in the aggregated flex-offer profile are computed by summing the values from the underlying flex-offers profiles. Such approach satisfies the disaggregation requirement because the schedule produced using the aggregated flex-offers can always be disaggregated into an equivalent schedule with the non-aggregated flex-offers.
Second, in order to provide control over the compression factor and flexibility losses a set of user-defined aggregation thresholds (e.g., duration tolerance, start after tolerance) is introduced. They allow determining similar flex-offers that can potentially be aggregated. Specifically, two flex-offers are allowed to be aggregated together only if their attribute values (e.g., duration, start after time) deviate by no more than user-specified thresholds. Combinations of the aggregation parameter values allow controlling the flexibility losses and the preferred compression factor. Moreover, the aggregation parameters might not be sufficient in cases when aggregating a large number of identical flex-offers. In those cases, all identical flex-offer will be aggregated into a single aggregated flex-offer thus losing the flexibility to schedule them individually. In order to prevent this, a so called bin-packer is designed. It allows to specify lower and upper bounds on one of the following properties of an aggregated flex-offer: (1) the number of flex-offers included into a single aggregate, (2) the amount of energy (or time flexibility) an aggregated flex-offer has to offers, etc. This bin-packer is an optional feature that can be turned off.
Third, an incremental aggregation is supported. Therefore, aggregated flex-offers can be incrementally updated with no need to recompute them from scratch (an aggregation from scratch is also supported). Thus, a more efficient flex-offer aggregation can be achieved.
Aggregation Details
Based on these design decisions, the aggregation component was implemented. It accepts a set of flex-offer updates, i.e., information about accepted or expiring flex-offers (those with approaching assignment before time), and produces a set of aggregated flex-offer updates, i.e., information about created, deleted, and changed aggregated flex-offers.
The aggregation component consist of the following 3 sub-components: (1) group-builder, (2) bin-packer, and (3) n-to-1 aggregator. These sub-components are chained so that provided flex-offer updates traverse them sequentially.
First, the flex-offer updates are accumulated within the group-builder until their further processing is invoked. Then, when invoked, the group-builder internally maintains similar flex-offer groups and produces group-updates, i.e., information about created, deleted, and changed groups.
Then, when the bin-packer receives those group-updates, it utilizes them to maintain so called sub-groups, i.e, bounds-satisfying groups of similar flex-offers, and to produce sub-group updates, i.e., information about created, deleted, and changed sub-groups.
Finally, the produced sub-group updates are issued to the n-to-1 aggregator. This sub-component, utilizes sub-group updates (or group-updates if the bin-packer is disabled) to maintain a set of aggregated flex-offers and to produce respective aggregated flex-offer updates. The disaggregation of flex-offers is also performed by the n-to-1 aggregator. Since our approach meets the disaggregation requirement, the disaggregation technique is quite straightforward and is hence not further detailed here.