• No se han encontrado resultados

This subsection collects the technical and commercial requirements that have been defined in the previous sections and in the corresponding appendices in relation with the negotiation, activation and delivery of AD services or in a more general with the commercial and technical architectures as presented previously. It also presents structures to organize them in an appropriate way on the basis

ADDRESS Technical and Commercial Conceptual Architectures - Core document ADD-WP1-T1.5-DEL-EDF-D1.1-Technical_and_Commercial_Architectures

Revision 1.0

of the similarities that can be identified between the different services and the different players.

5.2.1.

Technical and commercial Requirements: recapitulative tables

Table 13 shows the requirements identified for the commercial architecture. These requirements apply to the service providers or requesters while negotiating or preparing the contract/bid/offer. Table 13 lists each of these requirements as an entry each with an ID, Label and Definition. The “ID” is to uniquely identify this requirement and will be used to refer to the requirement in the structures that will be presented later while the “Label” can be used as the title of the requirement. The explanation and meaning of the requirement is given in the “Definition” column. Those IDs with an asterisk (*) refer to the requirements, which also apply to the technical architecture, even though the context in which the requirements are applied is different.

Table 14 shows the requirements identified for the technical architecture. These requirements apply to the service providers or requesters to ensure that the service to be provided/requested is usable, effective and technically feasible. In general, when seeking for active demand products/services, the players should take these requirements into account so that what they acquire will meet their actual needs. More importantly, the aggregators providing the services must fulfil these requirements so that what they have promised/ been paid to provide will be realised.

Table 14 has the same structure as Table 13 and lists each of the technical requirements as an entry each with an ID, Label and Definition. Again those IDs with asterisk (*) refer to the requirements, which also belong to the commercial architecture, even though the context in which the requirements are applied is different.

ADDRESS Technical and Commercial Conceptual Architectures - Core document ADD-WP1-T1.5-DEL-EDF-D1.1-Technical_and_Commercial_Architectures

Revision 1.0

Table 13. Commercial architecture requirements Requirements

ID Requirements Label Requirements Definition

C1 Standing/Option Fee Specification The fee to be paid for making available the service must

be specified

C2 Deployment Energy Price

Specification

The price to be paid for the energy to be delivered for the service must be specified

C3 Penalty for Non-delivery The charge/penalty to be paid in case of non-delivery of

the committed service must be specified

C4 Participation to and Organized

Market of Re-profiling Products

Players must take part (directly or indirectly) to a re- profiling product based market

(C5) Procurement Strategy A procurement strategy must exist when procuring such

service

C6* Deployment Duration

Specification

The minimum time period (in mins/hours) that the active demand providers need to deploy and sustain the service must be defined

C7* Negotiation Gate Closure

Specification

The time window between contract definition or bid submission and actual delivery

(hours/days/weeks/months) must be defined

C8* Service Volume Specification

The amount of power to be delivered for the service must be defined (the minimum quantity may be fixed by DSO/TSO)

C9* Availability Interval Specification The duration (hours/days/weeks/months) over which the

service may be activated must be defined

C10* Activation Time Specification The lead time (mins/hours) allowed for aggregator to

deliver the service must be fixed

C11* Deployment/Ending Ramping

Limitation Range Specification

The deployment and end ramping limitations must be specified for the service

C12* Service Delivery Envelope

Specification The service delivery envelope must be defined

C13* Energy Payback Effect

Specification

The maximum amount in terms of energy and power which has to be “paid back” before or after delivery must be defined

C14* Location Specification from

Aggregator

Aggregator must group customers in the same load area for the service and communicate this grouping

assignment

C15* Maximum Amount of AD from one

Aggregator Specification

The maximum amount of active demand which can be provided from any single aggregator must be specified

ADDRESS Technical and Commercial Conceptual Architectures - Core document ADD-WP1-T1.5-DEL-EDF-D1.1-Technical_and_Commercial_Architectures

Revision 1.0

Table 14. Technical architecture requirements Requirements

ID Requirements Label Requirements Definition

T1 Location Information From DSO

DSO must assign each customer to a specific load area for the service and communicate such grouping assignment to aggregators

T2 Location Information From TSO

TSO must aggregate load areas into TSO-zones for the service and communicate such grouping assignment to aggregators

T3 Balancing Regulation

The aggregator must use active demand to counter- balance the proposed service so as to nullify the imbalances so created

T4* Deployment Duration Specification

The minimum time period (in mins/hours) that the active demand providers need to deploy and sustain the service must be defined

T5* Negotiation Gate Closure

Specification

The time window between contract definition or bid submission and actual delivery

(hours/days/weeks/months) must be defined

T6* Service Volume Specification

The amount of power to be delivered for the service must be defined (the minimum quantity may be fixed by DSO/TSO)

T7* Availability Interval Specification The duration (hours/days/weeks/months) over which the

service may be activated must be defined

T8* Activation Time Specification The lead time (mins/hours) allowed for aggregator to

deliver the service must be fixed

T9* Deployment/Ending Ramping

Limitation Range Specification

The deployment and end ramping limitations must be specified for the service

T10* Service Delivery Envelope

Specification The service delivery envelope must be defined

T11* Energy Payback Effect

Specification

The maximum account in terms of energy and power which has to be “paid back” before or after delivery must be defined

T12* Location Specification from

Aggregator

The aggregator must group customers in the same load area for the service and communicate this grouping assignment to those who seek the service

T13* Maximum Amount of AD from one

Aggregator Specification

The maximum amount of active demand which can be provided from any single aggregator must be specified

T14 Interaction with Energy Box

The aggregator must interact with the Energy Box for flexibility activation and monitoring purposes for real- time delivery and performance assessment

T15 Aggregator’s Performance

Assessment

The performance of the aggregator must be monitored and assessed

T16 AD Consumers’ Performance

Assessment

The performance of the active demand consumers must be monitored

T17 Energy Payback Effect

Assessment

The energy payback effect of the committed active demand consumers must be monitored and assessed

ADDRESS Technical and Commercial Conceptual Architectures - Core document ADD-WP1-T1.5-DEL-EDF-D1.1-Technical_and_Commercial_Architectures

Revision 1.0

5.2.2.

Structures to organised the requirements

Three types of structures have been adopted to organize the technical and commercial requirements that were identified. They will be used later in other WPs of the project for the developments that will be carried out to achieve the implementation of the technical and commercial architectures.

- Structure 1 (requirement-based variant 1): the commercial and technical requirements collected in Table 13 and Table 14 are further categorised (if applicable) and the services that need to fulfil them are grouped and organised into two structures (a commercial and a technical one) where:

o the commercial or technical requirements appears at the first level of the hierarchy.

o The second level shows a sub-classification, if necessary, which further refines the requirement. For example, concerning the requirement on Deployment Duration (C6), depending on the service concerned, the duration can be in the time range of minutes, hours or days and the requirement is sub-classified accordingly

o the services fulfilling the requirement are listed at the (third and) last level of the hierarchy Figure 26 gives an extract of this type of structures for the commercial requirements.

ADDRESS Technical and Commercial Conceptual Architectures - Core document ADD-WP1-T1.5-DEL-EDF-D1.1-Technical_and_Commercial_Architectures

Revision 1.0

- Structure 2 (requirement-based variant 2): This variant is similar to the previous one but it shows this time in the last layer of the hierarchy the respective players associated to the services which when requested will need the requirements to be fulfilled (instead of the services). It is shown on Figure 27 for the technical requirements.

- Structure 3 (player-based): the structure shows the requirements which are applied to the players depending on the product(s) which they need, namely: the first level shows the players and the second level shows the requirements which might be applicable to them. Figure 28 shows the third structure again for the technical requirements. In this figure, the identification of the requirements and of their categories are further compacted with respect to the previous figures: for instance, Requirement C4 Category 1 is abbreviated as C4-1, Requirement C6 Category 3 as C6- 3, and so on.

The requirements for the implementation of the commercial and technical architectures are further discussed in Appendix H and the three structures presented above are described in detail.

5.3. Issues to be addressed for the implementation of