Electricity Market Code

Transcription

1 Electricity Market Code Chapter 3 Schedules Version 53 This document contains a partial translation of the Austrian Electricity Market Code from German into English It is provided for the reader s convenience only, it does in no way constitute a binding document and has no regulatory character - for Austrian market rules, including market, grid and other codes, the reader should refer to the German versions of all relevant documents only E-Control assumes no liability whatsoever for the accuracy, correctness or completeness of the translation in this document

2 CONTENTS 1 INTRODUCTION 3 11 Schedule 3 12 Load units 4 2 SCHEDULE MANAGEMENT 5 21 Correspondence with ETSO terms 5 22 Identification of market participants 6 23 Process description External schedules General remarks Schedule submission Internal schedules General remarks Schedule submission Schedules for green electricity allocation Production schedules Power station maintenance schedules Messages Ground rules Schedule message Schedule message and time series identification Versioning of schedule time series Code tables Implementing section 4 on Capacity allocation Examples Acknowledgement message Reason Codes Example Time series anomaly report Reason Codes Example Time series confirmation report Reason Codes Examples 41 3 TRANSMISSION OF MESSAGES General remarks Filename convention for attachments Subject line convention addresses for returning messages Handling uninterpretable messages 45 4 CAPACITY ALLOCATION 47 5 ANNEX Description of segments Additional examples for external schedule messages 48 2

3 This document describes the implementation of the ETSO Scheduling Systems (ESS) for schedule management in Austria It is based on the ESS Implementation Guide (ESSIG) V 23 1 Introduction With the opening of the Austrian electricity market for all customers, in accordance with the Elektrizitätswirtschaft- und Organisationsgesetz (Electricity Act) 2000, a balance group system was introduced The planned exchange of electric energy between the balance groups (BG) within a control area (CA) and across control areas, control blocks and national borders is managed in the form of schedules (S) Regarding the form and transmission of these schedules, it was agreed to use the ESS schedule format developed by ETSO instead of the previous format based on Excel The ESS format is also used for the production schedules For power station maintenance schedules the Excel-based format is used The national implementation of the third energy package of the European Union had technical and organisational consequences for the operation of the Tyrol and APG control areas Until 31 December 2010, APCS determined the balancing energy for the APG control area, while A&B did so for the Tyrol and Vorarlberg control areas From 1 January 2011, 0000 hours (hereinafter referred to as the cut-off point), operation of the Tyrol and APG control areas became combined From this point on APG has been the control area manager for this combined control area For the periods from January 2011, the first clearings have been carried out by APCS The second clearing in the Tyrol control area for the periods to December 2010 continues to be managed by A&B, and the general terms & conditions of the clearing and settlement agent (GTC-CSA) A&B continue to apply Data (especially schedules and meter readings) for the Tyrol control area for the periods to December 2010 must continue to be submitted to A&B Data for periods from January 2011 shall be sent to APCS 11 Schedule Section 7 Electricity Act defines the term schedule as the document that shows the amounts of electric energy fed into and withdrawn at specific grid points as projected mean load during regular intervals (measurement periods) 3

4 Balance groups, according to section 7 Electricity Act, are virtual groups of suppliers and customers within which the amounts of electric energy procured (by procurement schedules, injections) and supplied (by delivery schedules, withdrawals) are balanced Consequently, the energy exchange between balance groups in the control area cannot be assigned to physical grid points To handle the energy exchange between balance groups of the control area as a schedule as defined by the Electricity Act, it is necessary to regard the feed-in and withdrawal points as virtual grid points 12 Load units The smallest unit for schedules between balance groups within the control area (internal schedules) is defined as 1 kw (mean load in the measurement period) Standard commercial rounding principles apply Schedules across control areas (external schedules) are governed by the provisions of the European Network of Transmission System Operators for Electricity (ENTSO-E) Exchange between Austrian and German control areas is possible at the minimum unit of 1 kw Exchange with other foreign countries is currently only possible in 1-megawatt (MW) increments and four identical 15-minute values per hour Depending on whether the foreign control area is part of the ENTSO-E Multi Time Frame System (MTFS), this restriction does not apply Control area managers publish (preferably on the internet) a list of their interconnection points with cross-border control areas and the minimum possible load units for them For grid calculations and load projections, it is sufficient if the data for network-node power station schedules and total-production or total-consumption schedules for the pumped storage of the balance group is given in whole MW Data reporting at variance with these for power stations on the distribution grid shall be contractually agreed 4

5 2 Schedule management 21 Correspondence with ETSO terms In connection with the market model (balance group system) introduced in Austria the ETSO roles listed below are relevant Table 1: Roles in the Austrian market model ETSO model Balance Area (BA) System Operator (SO) Balance Responsible Party (BRP) 1 Austrian market model Control area (CA) Control area manager (CAM) Balance group (BG) Trade Responsible Party (TRP) Consumption Responsible Party (BRP) 1 Production Responsible Party (PRP) Balance responsible party (BRP) Imbalance Settlement Responsible Party (ISRP) Clearing and settlement agent (CSA) Table 2: ETSO Scheduling System: terms and equivalents in the Austrian Market Rules ESS ESS ESSIG 23 Schedule Time series Acknowledgement message Anomaly report Confirmation report Out area In area Explanation ETSO Scheduling System ESS Implementation Guide, specifically version 2, release 3 (23) Schedule (Schedule) time series Acknowledgement of receipt Anomaly report Schedule confirmation Control area exporting/supplying energy Control area importing/receiving energy 1 Currently not used in Austria At present, only TRP and PRP are used 5

6 Out party In party Product Business type Object aggregation Metering point identification Capacity contract type Capacity agreement identification Seller (energy exporting balance group) Buyer (energy importing balance group) The product traded according to schedule, eg active load, active energy More descriptive term for the type of transaction for which a schedule is provided, eg production schedule, internal or external transaction Identification of aggregation level of a schedule, eg aggregation per control area or (virtual) metering point (eg interconnection point) Metering point administration number (MPAN) Describes the contract terms of a specific capacity agreement, eg daily auction, weekly auction Reference to a specific capacity agreement on which a schedule is based 22 Identification of market participants The individual market participants are identified by a code under the Energy Identification Coding Scheme (EIC), which is issued by individual issuing offices and can be seen on their websites Every balance responsible party operating in Austria must obtain an EIC for its balance group(s) from one of the EIC issuing offices and notify the CSA(s) of its/their establishment Table 3: Issuing offices currently operating in Austria, Germany and Switzerland (for latest list see wwwentsoeeu) Registration number (office code) Company 11 BDEW 12 Swissgrid 13 A&B 14 APCS 6

7 EICs are issued for balance groups The sub-roles used in the ENTSO-E role model (TRP, PRP - see Table 1) are also mapped to the balance group When schedules are transmitted, a BG acts as TRP for internal and external schedules and as PRP for production and pumping schedules Control areas and clearing and settlement agents are also identified by a code issued by ENTSO-E The codes for the Austrian control areas are listed in the table below A list of all ENTSO-E control areas can be found at wwwentsoeeu Table 4: EIC party code for control area managers (system operators) and EIC area code for control areas (balance areas) in Austria Control area manager Verbund Austrian Power Grid AG Alias name (until 31/3/2003) A_APG_N EIC area code EIC party code (EIC CAM) 10YAT-APG------L 10XAT-APG------Z Tiroler Regelzone AG A_TIRAG_N 10YAT-TIRAG-N--C 10XAT-TIRAG-N--Q Vorarlberger Kraftwerke Übertragungsnetz AG A_VKW_N 10YAT-VKW-UNG--K 10XAT-VKW-UNG--Y Table 5: EIC party code for clearing and settlement agents (imbalance settlement responsible parties) in Austria Clearing and settlement agent APCS control area APG A&B control area TIWAG Netz A&B control area VKW Netz AG EIC 14XAT-APCS-----Q 13X-AUNDB-T X-AUNDB-V----V 23 Process description The three control areas of Verbund-APG, TIWAG Netz AG and VKW Netz AG can comprise any number of balance groups trading with each other The resulting transactions can be divided into two types, internal control area and external and/or inter-block transactions Inter-area and inter-block transactions are notified via external schedules to the respective CAMs involved in these transactions (section 231) The CAMs forward processed schedules to the CSAs for the purpose of determining the balancing energy For transactions within a control area, internal schedules (section 232) are submitted to the 7

8 CSA responsible for the control area, in accordance with the timing rules in the GTC-CSA, again for the purpose of determining the balancing energy In addition to the schedules resulting from the aforementioned transactions, for safe system operation the CAMs also need production and pumped storage schedules (section 233) and power station maintenance plans (section 235) All schedule messages are subject to the ground rules defined in section External schedules 2311 General remarks It is part of the control area manager s responsibilities to accept external schedule messages, validate their formal correctness and legal and technical compliance, and match them with the control area managers of the other control areas involved If the existing interconnection capacities are not sufficient to meet all requests, the control area manager must proceed according to section 20 Electricity Act and the relevant provisions of European law See also sections 2424, 2425 and 4 (Capacity allocation) 2312 Schedule submission Transactions that cross control area borders must be notified by the BRP to the CAM as external schedules Such notification must happen in the CA that has an interconnection point to the other CA Depending on the individual business partner s market model, one of the following scheduling options applies: a) Submission of schedules between balance groups with the same EIC in different control areas; b) Submission of schedules from/to outside the control area to the balance group of a control area (normally for countries that do not have a balance group system); c) Submission of schedules between BGs with different EICs in different control areas For the submission of schedules as under (a) above the following applies: Transactions between balance groups of the same balance responsible party must be notified with the same EIC The BRP always submits the schedule in both control areas involved Note: Where it is possible under the market models in neighbouring control areas, inter-area scheduling between identical balance groups of the same balance responsible party as under 8

9 (a) above is strongly recommended Evidence has shown that this procedure minimises errors in schedule message transmission and hence guarantees high reliability For the submission of schedules as under (b) and (c) above the following applies: For inter-area transactions the BRP must name the buyer or seller outside its own control area in such a way that they are clearly identifiable by the control area manager and/or block manager of the other country involved and the schedule can be clearly assigned to the trading partners It must be granted for both control area managers that the individual transactions involved can be matched and verified The submission and acceptance of external schedules is done in three phases (see also ESSIG 23 Chapter 32, Schedule system information flows, figure 6, page 22) 9

10 Figure 1: Submission, validation and confirmation of external schedules Balance group For Control area manager Start Phase 1 Submission of schedule message Schedule message Receipt of schedule message Formal validation Error correction Negative acknowledgement msg No Ok? Schedule formally correct Error correction Discrepancies? Yes Positive acknowledgement msg Phase 2 Time series anomaly report Notification by phone Phase 3 Time series confirmation report Yes Yes Or Yes Technical validation and matching Restrictions violated? Discrepancies? No Schedules match No Schedule adjustment Schedule validated Transmission of schedules performed to CSA End End 10

11 Day ahead scheduling Phase 1: Submission External schedules must reach the control area manager by 1430 hours on the day preceding supply or procurement in the form of a schedule message External schedules arriving with the control area manager up to that time for the following day are considered as received at the same time Schedules arriving after 1430 hours are not processed for the time being; validation and matching for the schedules received on time are completed first In the event of exceptional market situations the control area manager is entitled, in consultation with the relevant neighbouring control area managers, to extend the period for receipt of external schedules to 1530 hours Balance responsible parties are informed of the extension in good time and in an appropriate manner Schedules for interconnection points without congestions can be submitted one month in advance at the earliest For congested interconnections, submission is possible no earlier than 2 days in advance (from D-2, 1230 hours) Once a message has been formally validated, positive or negative feedback is transmitted to the sender in the form of an acknowledgement message Phase 2: Technical validation and matching As soon as all the information about a schedule is available, including counterpart time series from control area managers of the other involved control areas, technical validation (restrictions, capacity limits, feasibility) takes place and the schedule is matched with the neighbouring control areas If there are anomalies, either time series anomaly reports are transmitted to the sender or the sender is contacted by phone 2 The sender is then bound, without delay and by 1530 hours at the latest, to submit a corrected version of the schedule message Note: A balance group may receive several time series anomaly reports for one schedule message, and time series anomaly reports may also be received if no 2 For the time being, errors are notified via telephone However, notification by time series anomaly reports is planned for the foreseeable future 11

12 schedule message was sent, but there is a message in the other control area If the schedules cannot be matched by the involved control area managers by 1530 hours (cut-off time) and it is impossible to clarify this difference with the respective sender, in the case of a message according to article 2311a above the schedule of the receiving party prevails In all other cases (messages according to article 2311b and c) the schedule time series is zeroed out Phase 3: Confirmation: At 1630 hours at the latest the senders are told, in a time series confirmation report, in what form (unchanged or reduced) their external schedules can be performed Note: In certain circumstances several time series confirmation reports can be issued for one schedule message, if for example a message is changed again later by the other control area If an external schedule cannot be (fully) performed, the control area manager is obliged to provide a written explanation Where a schedule is reduced due to grid-related constraints, a letter of explanation shall be sent to the sender within 5 working days External schedules arriving with the control area manager between 1430 hours and 1530 hours are exclusively permitted for the correction of day ahead schedules Intraday changes Intraday trading begins at 1800 hours (D-1) Intraday schedules reaching the control area manager before D-1, 1800 hours, are rejected Intraday changes in external schedules require a lead time of at least 45 minutes and can only begin on the hour 20 minutes after the request was submitted, the CAM must inform the BRP about whether its requested changes are acceptable and have been confirmed by the CAMs of the other control areas Schedule messages (time series) containing discrepancies are immediately rejected (the previously matched schedule applies) If later versions of a schedule time series show incorrect values for intervals in the past and the lead time, the whole time series is rejected, because any new version must map the whole day correctly The matching process always takes place bilaterally between control areas Schedule messages for intraday changes are processed in Austria in the same format as day ahead schedule messages The A02 process type for intraday messages is not supported The 12

13 process flow is the same as for day ahead messages Intraday changes must also be notified to the control area manager by telephone 232 Internal schedules 2321 General remarks Within a control area, schedule transactions are possible between all the BGs registered in the respective control area According to the GTC-CSA, only the balance of transactions between the two participating BGs is reported to the CSA responsible for the control area The message is sent by both BRPs or by one BRP only, depending on the CSA s GTC To enable the CAM to determine - for the purposes of ensuring system stability - whether all the BGs in its control area are balanced, the CSA can, on request, send the control area manager each balance group s aggregate internal schedules as time series with 15-minute intervals The details of the submission of such information by the CSA is specified in the GTC- CSA 2322 Schedule submission Day ahead scheduling Internal schedules must be submitted by the BRP to the CSA by 1430 hours at the latest on the day preceding the day of supply or procurement Schedules may be submitted 30 days in advance at the earliest Note: Balance groups for which the applicable market rules or statutory provisions do not explicitly specify an obligation for daily schedule submission can continue to use the previous procedure for schedule submission Intraday changes Schedule changes at short notice after expiry of the day ahead notice period may be sent for every quarter of an hour at least 15 minutes in advance Modified schedules must be transmitted to the CSA by both the BRP of the procuring and the BRP of the supplying balance group Note: Any other options for changing schedules (eg for retrospective schedule changes) can be set forth in the GTC-CSA 13

14 Validation and matching Internal schedules are processed in the same way as external schedules (submission, validation, matching) If corresponding schedules do not match or were not transmitted, the relevant provisions of the GTC-CSA apply (eg receiving party rule, zero values for missing schedules) As regards validation and matching, the GTC-CSA specify in what form the results of the matching and validation process are provided to the market participants (eg time series anomaly / confirmation reports or information on the internet or telephone) Generally, ESS documents are to be given preference over other information communication procedures 14

15 Figure 2: Submission and validation of internal schedules 15

16 Figure 3: Confirmation of internal schedules 233 Schedules for green electricity allocation Internal schedules for the allocation of green electricity to electricity suppliers are transmitted to the BRPs by the settlement agent for renewable energy, according to its general terms and conditions and the Electricity Market Code, daily up to 1000 hours on the day ahead (D-1) After processing these allocation schedules, the settlement agent for renewable electricity also transmits, by 1015 hours - based on the currently available forecasts - schedules for the day after next or, before weekends and public holidays, for all days up to and including the next working day This means that on the last working day (normally Friday) before each weekend schedules (first version), produced on the basis of the currently available forecasts, are transmitted for Sunday and the following Monday Green electricity quantities are allocated on Saturday for Sunday using a later schedule version, which replaces the previous day s schedule In addition, an updated forecast schedule is transmitted on Saturday for Monday On Sunday the green electricity quantities are ultimately allocated for Monday by transmitting an even later version of the schedule, as well as the schedule for Tuesday Schedule transmission in a week with no public holidays is shown in the table below (the 16

17 ultimately valid version is printed in bold in each case) Table 6: Schedules for the allocation of green electricity Schedule versions transmitted Version 1 Version 2 for for Monday Wednesday Tuesday Version 3 for Tuesday Thursday Wednesday Weekdays of schedule transmission Wednesday Friday Thursday Thursday Saturday Friday Friday Sunday, Monday Saturday Saturday Sunday, Monday Sunday Tuesday Monday This arrangement is to be applied likewise for public holidays Consequently, on the last working day before a public holiday, green electricity quantities are allocated for the holiday and the forecast schedule for the following working day is transmitted; the latter is replaced on the public holiday by transmission of a later version If, for technical reasons (eg no service available), a binding green electricity allocation schedule for the following day cannot be sent by 1015 hours, the settlement agent for renewable electricity, after previously notifying the BRP by telephone, can confirm that the schedule transmitted the previous day becomes binding 234 Production schedules Load flows for a given topology are determined exclusively by the amount and location of the injections and withdrawals The grid operators need power station schedules (net values) from the balance groups, separated into production and pumping schedules, in order to assess system stability 17

18 At any rate they need network-node schedules for all power stations that feed in or withdraw for pumped storage at grid levels 1 and 3 (equal to/greater than 110 kv), or that have a net capacity greater than 50 MW (regardless of the voltage level of the feed); this also applies to autoproducers Power stations below grid level 3 and with a net capacity smaller than/equal to 50 MW must also provide schedules if a grid operator demonstrates that this information is necessary for assessing system stability Network-node power station schedules shall be put in a central file (for each control area) The power station schedules for which individual grid operators have viewing rights are made available to the latter thereafter The central database is operated by the respective control area manager Power station schedules for the following day, and at weekends and before public holidays for up to and including the next working day, must be transmitted to this central database (for each control area) by 1430 hours (see Figure 4) Changes to power station schedules are possible at any time, but if there are deviations from the original schedule greater than 50 MW, the grid operators concerned and the control area manager shall be informed immediately, ie the modified schedules shall be transmitted to the central database as soon as possible Noncompliance with power station schedules or failure of BRPs to correct schedules is not acceptable, because both the grid operators operational security considerations and the control area manager s load forecasts and tracking of actual load in the control area are based on this data 18

19 Figure 4: Submission of production schedules To assess the quality of transmitted schedules and the metered data as well as the models used (estimate of other generation, models for calculating energy flows in the grid), the grid operators and the CAM need the actual (measured) quarter-hourly readings of the power stations (and storage pumps) for which network-node schedules must be produced The BRP to which the power station metering point is assigned sends the CAM the planned / forecast network-node schedules for all power stations that feed in or withdraw power for pumped storage at grid levels 1 and 3, or that have a net capacity of more than 50 MW The BRP must also give the CAM, for the purposes of estimating the balancing energy requirement, a schedule for the BG s total net production and the BG s total consumption for pumped storage Both types of production schedules (network-node schedules of power stations and aggregated schedules of BGs) must be contained in one message Reference to the network node is made by means of a virtual metering point and the metering point 19

20 administration number is specified by the CAM 235 Power station maintenance schedules Power station operators are obliged to inform the control area manager and the grid operators involved of the planned availability of their power station units for which network-node schedules must be issued (annual schedules with weekly information, to be updated when changes are made) The maintenance schedules (in a standardised format) are transmitted to each control area manager s central database in which power station schedules are filed by the BRP of the BG to which the respective power station is assigned Reduction of capacity due to maintenance work must be taken into account in these schedules for each network node (net values on the grid side), and separately for generator and pumps In the control area of TIWAG Netz AG and VKW Netz AG the use of this type of schedule is agreed with the BGs involved if required Power station maintenance schedules are transmitted as Excel 97/2000/XP workbooks with an information and a maintenance spreadsheet The sheets in the workbook are shown below 20

21 Figure 5: Info spreadsheet 21

22 Figure 6: Maintenance spreadsheet For each week, the available capacities of each power station for which network-node schedules must be issued, derived on the basis of the maintenance plans, are entered in this sheet The date to be indicated is always the 1st of January of the year to which the data relates 24 Messages With the exception of power station maintenance schedules and green energy allocation schedules, scheduling (see section 0) involves an exchange of the four ESS messages described below between market participants Schedule message Acknowledgement message (acknowledgement of receipt and result of formal validation) 22

23 Time series anomaly report (report of schedule discrepancies) Time series confirmation report (schedule confirmation) 241 Ground rules The entire process is based on the assumption that certain basic rules are complied with These basic rules (as stated in the ESSIG 23, chapter 33) are: 1 Generally, a balance group communicates its global position in its schedule message In the Austrian market model, this means that for one balance group all schedule time series relating to the same day and recipient (CAM or CSA) are transmitted within one message, ie for the same day, all external time series are sent in one message to the CAM, all production schedule time series in one message to the CAM, and all internal schedule time series in one message to the CSA 2 A time series determined by a combination of Product, Business Type, Object Aggregation, In Area, Out Area, Metering Point Identification, In Party, Out Party, Capacity Contract Type and Capacity Agreement Identification may only occur once in one schedule message 3 Each new version of a schedule message must include all the schedule time series transmitted and formally accepted in the previous versions The information content of a schedule message may not be reduced in scope compared with that previously accepted This means that, if for example a schedule with a time series for a specific transaction is submitted and formally accepted for a certain day and the transaction is later on cancelled, the time series concerned may not be deleted but must be retained until the end of the day in question and be zeroed out Incomplete messages are rejected 4 All version numbers shall be sequential positive integer values with up to three digits and leading zeroes shall be suppressed 5 For all schedule messages received either positive or negative acknowledgement reports shall be sent 6 All time series in a formally correct schedule message may be used to balance the complementary time series as soon as these are available 7 All times in the schedule messages are to be expressed in Coordinated Universal Time 23

24 (UTC) in the format YYYY-MM-DDTHH:MMZ 8 All the time intervals are expressed in the format YYYY-MM-DDTHH:MMZ/YYYY-MM- DDTHH:MMZ (eg 00:00Z to 01:00Z is exactly one hour) 9 The resolution of a time series shall be expressed in minutes; in Austria it is defined as 15 minutes 10 The schedule time interval of time series shall be a whole multiple of its resolution In Austria the schedule time interval is defined as the local-time day: Normal 24 hour day (96 time intervals); Start of summer time: 23 hour day (92 time intervals); End of summer time: 25 hour day (100 time intervals) 11 The schedule time interval must correspond to the time intervals of the time series and is defined as the local-time day in Austria The start and end time of the interval is expressed in UTC time 12 No negative values are permitted in schedule time series The direction is not defined by a sign, but by the following information: Out Area, In Area, Out Party, In Party The schedule time series are aggregated If such an aggregated time series contains both directions, a schedule is needed for each direction At any one point in time only one of these two schedules can differ from zero For schedule time series relating to capacity reservation and allocation, section 2424 applies 13 A time series is deleted in a newer version of a schedule message by zeroing out all values (see also point 3 above) 14 Values in a schedule time series indicate mean load The unit is MW (code MAW) In Austria up to three digits after the point are allowed; the decimal separator is the point ( ) 15 Quantities for reserved capacities indicate maximum capacity The unit is MW (code MAW) 16 Where coded names and references (identifications) are used, the coding scheme must always be supplied The coding scheme also defines the characters permitted The ESS Implementation Guide (ESSIG) describes and explains the structure of messages and the elements included in the messages In addition, the following applies to all message types: 24

25 The address of the document type definition (DTD) within each message shall be given as a relative address according to the ESSIG 23 If an element is not used in a message, it shall not be defined as an element with the attribute = in the XML document but omitted completely To avoid generating unnecessarily large messages, it is recommended, when generating XML messages, to avoid line indents or at least use tabs In reason and other texts, no non-printable characters or language-specific special characters may be used apart from German umlauts 242 Schedule message For each type of schedule (external, internal and production schedule) a separate schedule message containing the time series is transmitted The sender is responsible for the formal and factual correctness of the schedule message 2421 Schedule message and time series identification The message and time series identification assigned by the sender is returned to the sender in acknowledgement, anomaly and confirmation messages and provides reference to the messages and time series submitted The maximum length of the message and time series identification is 35 characters Only the following characters are allowed: 0-9, A-Z, a-z, hyphen ( - ), underscore ( _ ) The ESSIG defines the following rules for generating the message and time series identification: The sender shall assign a unique identification for every message for each day and type of time series (external, internal, production schedules) If schedules change, the message identification remains the same, only the version number is incremented The sender shall assign a unique time series identification for all time series within a message If the time series changes, the time series identification remains the same, but the time series version number is incremented In a message for a different day (ie also with a different message identification), other identifications can be assigned to the time series 25

26 2422 Versioning of schedule time series When assigning version numbers, the following conventions shall apply: the version number starts from 1 every day and must be contained in every time series version and message version With every change, the message version is incremented by 1, and the changed time series are marked with this new version number As a general rule, assigning the version number is the responsibility of the sender If the latter wishes to change a transaction already notified, it must also change the version number in line with the convention described; if the version number is not changed, the recipient might interpret the transaction as unchanged Example: Table 7: Initial transmission of a schedule Message ID Message version Time series ID Time series version MUID001 1 FPL01 1 FPL02 1 FPL03 1 Table 8: Changed time series Message ID Message version Time series ID Time series version MUID001 2 FPL01 1 FPL02 2 FPL03 1 Table 9: New time series added Message ID Message version Time series ID Time series version MUID001 3 FPL01 1 FPL02 2 FPL03 1 FPL04 3 Versioning of time series in the case of intraday changes in the APG control area: Section 2311 specifies the conditions for changes to external schedules on the same day If the intraday change is received in time, the control area manager starts to match the 26

27 schedules with the neighbouring control area affected and to make the necessary changes in its systems In most of the southern and eastern European control areas this matching is done by telephone To be able to process an intraday change in the time allowed, care must generally be taken with an intraday change in the Verbund-APG control area that only the version numbers of those schedule time series which are changed or added by the intraday change are incremented All schedule time series not affected by the intraday change must under no circumstances have their version number (Senders Time Series Version) changed Intraday changes that do not comply with this requirement are rejected altogether 2423 Code tables The type of a schedule message (external, internal, production) and the schedule time series it contains is defined by the codes and identifications in the elements of the XML message The following tables describe the codes to be used according to the ESS Code list, version 12 Table 10: Schedule message class External schedule to CAM Internal schedule to CSA Production schedule to CAM Message identification See 2421 See 2421 See 2421 Message version See 2422 See 2422 See 2422 Message type A01 A01 A01 Process type A01 A01 A01 Schedule classification type Sender identification, coding scheme A01 A01 A01 EIC of BG A01 EIC of BG Sender role A01 A01 A06 Receiver identification, coding scheme EIC CAM A01 A01 EIC CSA of CA Receiver role A04 A05 A04 Message date and time Time of message generation in UTC A01 Time of message generation in UTC EIC of BG A01 EIC CAM A01 Time of message generation in UTC Schedule time interval Local-time day in UTC Local-time day in UTC Local-time day in UTC 27

28 Table 11: Time series class External schedule time series Internal schedule time series Production schedule time series Without reservation With reserved capacity at domestic CAM Aggregated production One power station Aggregated pumping One pump Senders TS identification See 2421 See 2421 See 2421 See 2421 See 2421 See 2421 See 2421 Senders TS version See 2422 See 2422 See 2422 See 2422 See 2422 See 2422 See 2422 Business type A06 A03 A02 A01 A01 A04 A04 Product Object aggregation A01 A01 A01 A01 A02 A01 A02 In area, coding scheme = A01 EIC of importing CA (Area) EIC of importing CA (Area) EIC CA (Area) EIC CA (Area) EIC CA (Area) Out area, coding scheme = A01 EIC of exporting CA (Area) EIC of exporting CA (Area) EIC CA (Area) EIC CA (Area) EIC CA (Area) Metering point ID, coding scheme Metering point NAT 3) -- Metering point NAT 3) In party, coding scheme = A01 1) Buyer 1) Buyer 1) EIC Buyer BG EIC BG EIC BG Out party, coding scheme = A01 1) Seller 1) Seller 1) EIC Seller BG EIC BG EIC BG Capacity contract type -- (A01, A02, A03 or A04 ) 2)

29 Capacity agreement identification External schedule time series -- Assigned at time of reservation Identification of allocated capacity by assigning EIC of CA (10YAT-APG L, 10IT-GRTN---- -B, etc) Internal schedule time series Production schedule time series Measurement unit MAW MAW MAW MAW MAW MAW MAW MAW Key: -- = not used, element not contained in message 1) Coding scheme for In/Out Party in external schedule time series may not always be A01 for nominations concerning areas that do not have a balance group system or areas that do not use the ETSO EIC system 2) Specifies the type of reservation 3) National coding scheme for metering point identification 29

30 2424 Implementing section 4 on Capacity allocation See also section 4 on Capacity allocation For external schedule transactions with cross-border control areas, where interconnection capacities are congested, there are different procedures for allocating capacity at the interconnection points Control area managers publish (preferably on the internet) a list of their interconnection points with cross-border control areas and the associated rules for capacity allocation at these interconnection points An external schedule time series must make absolutely clear to the control area manager which reserved capacity it refers to External schedule time series relating to reserved capacity shall use the Business Type A03 The Capacity Contract element must state the type of capacity reservation (eg daily [A01], weekly [A02] or annual [A04]) and the Capacity Agreement Identification element must specify the contract number, to be issued by the control area manager for the reserved capacity External schedule time series at interconnection points without congestions use Business Type A06 Due to the distinguishing features of external schedule time series one schedule message may include several time series that describe transactions with the same trading partner These time series differ from each other in at least one of the elements Business Type, Capacity Contract and Capacity Agreement Identification Section 52 gives examples for external schedule messages 2425 Examples For additional examples, see also section 52 External schedule message: <?xml version="10" encoding="utf-8"?> <!DOCTYPE ScheduleMessage SYSTEM "/schedulev2r3/dtd/schedule-xmldtd"> <ScheduleMessage DtdVersion="2" DtdRelease="3"> <MessageIdentification v="12345"/> <MessageVersion v="1"/> <MessageType v="a01"/> <ProcessType v="a01"/> 30

31 <ScheduleClassificationType v="a01"/> <SenderIdentification v="13xbilanzgr-2--q" codingscheme="a01"/> <SenderRole v="a01"/> <ReceiverIdentification v="10xat-apg------z" codingscheme="a01"/> <ReceiverRole v="a04"/> <MessageDateTime v=" t11:24:35z"/> <ScheduleTimeInterval v=" t23:00z/ t23:00z"/> <ScheduleTimeSeries> <SendersTimeSeriesIdentification v="ts0001"/> <SendersTimeSeriesVersion v="1"/> <BusinessType v="a06"/> <Product v=" "/> <ObjectAggregation v="a01"/> <InArea v="10yat-apg------l" codingscheme="a01"/> <OutArea v="10yat-tirag-n--q" codingscheme="a01"/> <InParty v="13xbilanzgr-2--q" codingscheme="a01"/> <OutParty v="13xbilanzgr-2--q" codingscheme="a01"/> <MeasurementUnit v="maw"/> <Period> <TimeInterval v=" t23:00z/ t23:00z"/> <Resolution v="pt15m"/> <Pos v="01"/> <Qty v="50000"/> <Pos v="02"/> <Qty v="50000"/> <Pos v="95"/> <Qty v="50000"/> <Pos v="96"/> <Qty v="50000"/> </Period> </ScheduleTimeSeries> </ScheduleMessage> Internal schedule message: <?xml version="10" encoding="utf-8"?> <!DOCTYPE ScheduleMessage SYSTEM "/schedulev2r3/dtd/schedule-xmldtd"> <ScheduleMessage DtdVersion="2" DtdRelease="3"> <MessageIdentification v="1234"/> <MessageVersion v="1"/> <MessageType v="a01"/> <ProcessType v="a01"/> <ScheduleClassificationType v="a01"/> 31

32 <SenderIdentification v="14xbilanzgr-1--f" codingscheme="a01"/> <SenderRole v="a01"/> <ReceiverIdentification v="14xat-apcs-----q" codingscheme="a01"/> <ReceiverRole v="a05"/> <MessageDateTime v=" t11:24:35z"/> <ScheduleTimeInterval v=" t23:00z/ t23:00z"/> <ScheduleTimeSeries> <SendersTimeSeriesIdentification v="ts0001"/> <SendersTimeSeriesVersion v="1"/> <BusinessType v="a02"/> <Product v=" "/> <ObjectAggregation v="a01"/> <InArea v="10yat-apg------l" codingscheme="a01"/> <OutArea v="10yat-apg------l" codingscheme="a01"/> <InParty v="14xbg-empfang -0" codingscheme="a01"/> <OutParty v="14xbilanzgr-1--f" codingscheme="a01"/> <MeasurementUnit v="maw"/> <Period> <TimeInterval v=" t23:00z/ t23:00z"/> <Resolution v="pt15m"/> <Pos v="01"/> <Qty v="45200"/> <Pos v="02"/> <Qty v="40000"/> <Pos v="95"/> <Qty v="45000"/> <Pos v="96"/> <Qty v="40000"/> </Period> </ScheduleTimeSeries> </ScheduleMessage> Production schedule message: aggregated production, power station production, aggregated pumping, pump: <?xml version="10" encoding="utf-8"?> <!DOCTYPE ScheduleMessage SYSTEM "/schedulev2r3/dtd/schedule-xmldtd"> <ScheduleMessage DtdVersion="2" DtdRelease="3"> <MessageIdentification v="erz-1234"/> <MessageVersion v="1"/> <MessageType v="a01"/> <ProcessType v="a01"/> 32

33 <ScheduleClassificationType v="a01"/> <SenderIdentification v="13xverbund1234-p" codingscheme="a01"/> <SenderRole v="a06"/> <ReceiverIdentification v="10xat-apg------z" codingscheme="a01"/> <ReceiverRole v="a04"/> <MessageDateTime v=" t11:24:35z"/> <ScheduleTimeInterval v=" t23:00z/ t23:00z"/> <ScheduleTimeSeries> <SendersTimeSeriesIdentification v="ts0001"/> <SendersTimeSeriesVersion v="1"/> <BusinessType v="a01"/> <Product v=" "/> <ObjectAggregation v="a01"/> <InArea v="10yat-apg------l" codingscheme="a01"/> <InParty v="13xverbund1234-p" codingscheme="a01"/> <MeasurementUnit v="maw"/> <Period> <TimeInterval v=" t23:00z/ t23:00z"/> <Resolution v="pt15m"/> <Pos v="01"/> <Qty v="100000"/> <Pos v="02"/> <Qty v="100000"/> <Pos v="95"/> <Qty v="100000"/> <Pos v="96"/> <Qty v="100000"/> </Period> </ScheduleTimeSeries> <ScheduleTimeSeries> <SendersTimeSeriesIdentification v="ts0002"/> <SendersTimeSeriesVersion v="1"/> <BusinessType v="a01"/> <Product v=" "/> <ObjectAggregation v="a02"/> <InArea v="10yat-apg------l" codingscheme="a01"/> <MeteringPointIdentification v="at kraftwerk0xy v" codingscheme= "NAT" /> <InParty v="13xverbund1234-p" codingscheme="a01"/> <MeasurementUnit v="maw"/> <Period> <TimeInterval v=" t23:00z/ t23:00z"/> <Resolution v="pt15m"/> <Pos v="01"/> <Qty v="65500"/> 33

34 <Pos v="02"/> <Qty v="65500"/> <Pos v="95"/> <Qty v="65500"/> <Pos v="96"/> <Qty v="65500"/> </Period> </ScheduleTimeSeries> <ScheduleTimeSeries> <SendersTimeSeriesIdentification v="ts0003"/> <SendersTimeSeriesVersion v="1"/> <BusinessType v="a04"/> <Product v=" "/> <ObjectAggregation v="a01"/> <OutArea v="10yat-apg------l" codingscheme="a01"/> <OutParty v="13xverbund1234-p" codingscheme="a01"/> <MeasurementUnit v="maw"/> <Period> <TimeInterval v=" t23:00z/ t23:00z"/> <Resolution v="pt15m"/> <Pos v="01"/> <Qty v="75000"/> <Pos v="02"/> <Qty v="75000"/> <Pos v="95"/> <Qty v="75000"/> <Pos v="96"/> <Qty v="75000"/> </Period> </ScheduleTimeSeries> <ScheduleTimeSeries> <SendersTimeSeriesIdentification v="ts0004"/> <SendersTimeSeriesVersion v="1"/> <BusinessType v="a04"/> <Product v=" "/> <ObjectAggregation v="a02"/> 34

35 <OutArea v="10yat-apg------l" codingscheme="a01"/> <MeteringPointIdentification v="at pumpe0kraftwerk0xy0v" codingscheme= "NAT" /> <OutParty v="13xverbund1234-p" codingscheme="a01"/> <MeasurementUnit v="maw"/> <Period> <TimeInterval v=" t23:00z/ t23:00z"/> <Resolution v="pt15m"/> <Pos v="01"/> <Qty v="55500"/> <Pos v="02"/> <Qty v="55500"/> <Pos v="95"/> <Qty v="55500"/> <Pos v="96"/> <Qty v="55500"/> </Period> </ScheduleTimeSeries> </ScheduleMessage> 243 Acknowledgement message After receipt of a schedule message it is validated for formal correctness The sender of a schedule message receives the result of this validation in the form of an acknowledgement message This also acts as confirmation of receipt for the sender If there is a formal error in a schedule message, the whole schedule message is rejected If this happens, the formal errors are communicated to the sender of the schedule message in the acknowledgement message with Reason Codes Feedback on formal errors found may take place at several levels with elements called Reason Codes (see section 2431) Several Reason Code elements may be contained at each level The reason text of a Reason Code element can contain more detailed information about the error 35

36 2431 Reason Codes Message level: The Reason Code elements at this level describe the overall result of the formal validation and the status of the schedule message at the recipient Table 12: Reason Codes for acknowledgement messages at message level Reason Code Meaning Reason text (optional) A01 A02 A03 A04 A05 A51 A52 A53 A57 A59 Message completely formally accepted Message completely rejected (additional codes describe reason for rejection) Faulty time series, described with Reason Codes at time series level Time interval of schedule message is faulty, eg no local-time day Sender is not an active balance group Same or later version of schedule message previously received One or more time series missing (message information content reduced) Incorrect recipient Legitimate transmission period exceeded eg external schedule received for an earlier day, or internal schedule received after end of clearing Message does not conform to market rules Further explanation Time series level: The Reason Code elements at this level describe errors in the time series identified by a time series rejection element Table 13: Reason Codes for acknowledgement messages at time series level Reason Code Meaning Reason text (optional) A20 Time series completely rejected (other codes describe reason for rejection) 36

37 A04 A22 A23 A27 A41 A50 A55 A59 Time interval of time series is not the same as in message header (no localtime day) Error in In Party or Out Party (eg unknown EIC) Error related to control area (eg incorrect EIC or unknown control area) Reserved capacity exceeded No 15-minute intervals in time series Version conflict in time series Error in time series identification (eg time series exists more than once) Message does not conform to market rules Further explanation Time interval level: The Reason Code elements at this level describe errors concerning individual intervals and values of a time series The interval affected is identified by a time interval error element Table 14: Reason Codes for acknowledgement messages at time interval level Reason Code Meaning Reason text (optional) A42 A46 A49 A59 Invalid value (eg more than three digits after the point, decimal separator is not a point, no figure) Negative value Error in position number of value (eg number missing or outside value range) Message does not conform to market rules Further explanation A fully accepted schedule message contains only the elements of the Acknowledgement Message Class and a Reason Code element with the Code A01; a rejected schedule message contains the Code A02 and at least one other Code It is the responsibility of the sender of a schedule message to submit schedule messages that are correct in form and content It cannot be assumed that a formal validation process will 37

38 reveal all possible formal errors 2432 Example Acknowledgement message: Message completely formally accepted <?xml version="10" encoding="utf-8"?> <!DOCTYPE AcknowledgementMessage SYSTEM "/schedulev2r3/dtd/acknowledgementxmldtd"> <AcknowledgementMessage DtdVersion="2" DtdRelease="3"> <MessageIdentification v="rz-ack-id-2345"/> <MessageDateTime v=" t12:00:00z"/> <SenderIdentification v="10xat-apg------z" codingscheme="a01"/> <SenderRole v="a04"/> <ReceiverIdentification v="13xbilanzgr-2--q" codingscheme="a01"/> <ReceiverRole v="a01"/> <ReceivingMessageIdentification v="1234"/> <ReceivingMessageVersion v="1"/> <Reason> <ReasonCode v="a01"/> </Reason> </AcknowledgementMessage> 244 Time series anomaly report With one or more time series anomaly report messages the sender of a schedule message can be informed of discrepancies with counterpart time series and/or the violation of restrictions Normally, a time series anomaly report contains only the time series identified as incorrect It should be noted, however, that not all incorrect time series must be contained in one anomaly report (the necessary information may not be available yet, eg no counterpart time series available) In extreme cases several anomaly reports may be received for one time series Balance groups can also receive time series anomaly reports when they have not sent a schedule message, but other schedule messages do contain time series referring to this balance group Instead of this report, notification can also be effected by telephone or via other information systems (eg the internet) For internal schedules the GTC-CSA specify in what form the results of the matching process are provided to the market players (time series anomaly report or information on the internet) 2441 Reason Codes Table 15 gives the Reason Codes possible in an anomaly report 38