dpm information exchange v3.0 - nedu - nedunedu.nl/.../2014/10/dpm-information-exchange-v3-04.pdfdpm...

Detailed Process Model (DPM)

Information Exchange

Uitgave van EDSN Auteur WMWG (Werkgroep Marktmodel Wholesale Gas) Versienummer 3.0 Versiedatum 12 June 2013 Status Final

DPM Information Exchange v3.0.docx /39

Versions Version Name Date Status Distribution 0.5 Confirmation BPL call added, Non functionals

added 22-04-2009 Concept Subgroep DPM

Informatieuitwisseling0.6 SBS , examples added of Program,

Confirmation Program, POS and SBS. 13-05-2009 Concept Subgroep DPM

Informatieuitwisseling0.7 POS, SBS enhanced, examples added of

other messages. Berichtdefinitie van POS en SBS toegevoegd

22-06-2009 Concept Subgroep DPM Informatieuitwisseling

0.8 Review internal GTS, Gasterra and Essent processed. POS and SBS changed


0.9 Review Internal Gts, Edsn and Electrabel processed.


0.91 Review Gasterra and Electrabel processed 08-09-2009 Concept Subgroep DPM Informatieuitwisseling

1.0 Internal Review (consistecne other DPM’s and open items).

14-09-2009 Final Subgroep DPM Informatieuitwisseling WMWG

1.1 Planning added. Definitions POS/SBS changed. Appendix A changed. Various small changes.

22-09-2009 Final All

1.2 2.2 Planning: different dates for definition availability. 3.1.4 and 3.1.5 APERAK added from PRP to SO as already specified in 4.4 Corrections from review of MIG and Webservices POS/SBS: * 2.3.3 Error messages in Code Lists Edigas * 3 ‘possibly’ deleted * 4.1 point 4, specification of exact Portfolio 3. Balancing relation will be a message. (Edigas) 4.8 Balancing Agreement added. 4.3 Added “Type Bid” in bid price ladder offer.


1.21 3.1.4 and 4.5 Confirmation to Bidder explained, virtual networkpoints added 4.8 Balancing agreement, messaging, dot 7; with party the portfolio of a party is meant.


2.0 For ALV-NEDU approval. - Some typo’s have been corrected. - Fout! Verwijzingsbron niet gevonden. Fout! Verwijzingsbron niet gevonden. -> 15 minutes has become 20 minutes. - 4.3 Paragraph directly under ‘content’ is removed. 4.3 Content “Direction” added. 4.5 Design decisions, dot 3. clarified. 4.2 and 4.5 kWh/h added. 4.8 Balancing agreement: kwh is kWh/h. 4.8 Example stacked agreement: minimum of supplier 2 is 100.


3.0 Changes as a result of the update to the market model. - Removed every reference to the Bid

Price Ladder and the Bid activation as this is being replaced with the WDM Action

- Removed all references to development and certification of automated information streams and messages as the messages for the involved parties will stay the same or will be deprecated (like the BIDDOC and BIDACT).

- The Bid Price Ladder offer messages has

12-06-2013 Final Vastgesteld door ALV-NEDU 12 June 2013

All


been removed (BIDDOC). - The BIDACT document will only be used

for emergency measure calls - All Dutch texts have been removed - Only messages between GTS and PV-ers

are mentioned in this document. The (bilateral) messages between GTS and the WDM are not mentioned

- Some typos removed.

DPM members information exchange (v3.00) Company Name E-mail EDSN Gerrit Fokkema [email protected] ICE-Endex Egbert-Jan Schutte-Hiemstra [email protected] Eneco Energy Trade Karolien Nijhuis [email protected] Gasterra Wieger Vonk [email protected] GDF SUEZ Energie Nederland Gerda Frans [email protected] GTS Thomas Tinge [email protected] Piet Deuze [email protected] Alef Tuinman [email protected] Referenced documents Ref Name Owner Date Version 1 Market Process Model “Market Model

Whole Sale Gas” Werkgroep Marktmodel Wholesale Gas

- Last

2 DPM Programme WMWG - Last 3 DPM Within Day Balancing Action

process WMWG - Last

4 DPM Market and allocation WMWG - Last


Contents

1 Introduction ................................................................................................ 5

1.1 Goal of the document ............................................................................ 5

1.2 Scope of this document .......................................................................... 5

1.3 Abbreviations and terminology ................................................................ 5

2 Basic assumptions ....................................................................................... 6

2.1 Approach ............................................................................................. 6

2.2 Content ............................................................................................... 6

3 Overview ..................................................................................................... 8

3.1 Processes and information flows .............................................................. 9

3.2 Communication ................................................................................... 11

4 Content ...................................................................................................... 12

4.1 Program ............................................................................................ 12

4.2 Program Confirmation .......................................................................... 16

4.3 Causer Confirmations ........................................................................... 20

4.4 Emergency Measure Supplier Activation .................................................. 22

4.5 Emergency Measure Activation Confirmation messages ............................. 24

4.6 Portfolio Imbalance Signal – POS ........................................................... 26

4.7 System Balance Signal – SBS ................................................................ 30

4.8 Balancing Agreement ........................................................................... 33

Appendix A - GTS B2B webservices .................................................................. 38

Appendix B - Relation To Edigas messages ...................................................... 39


1 Introduction 1.1 Goal of the document This document is part of the Detailed Process Model (DPM) that covers the relevant information flows, as described in the MPM “Market Model Wholesale Gas” [1]. This document is strongly related to other DPM’s that describe the processes (see Referenced documents [2], [3] en [4]). The functional definitions of the information flows are described in this document. The final technical definitions are described in the technical specifications documents (e.g. Edigas and/or XML definitions).

1.2 Scope of this document In scope This document contains the functional description of the information exchange as a result of the market and balancing model as of 1 April 2014. On basis of this document the actual technical message descriptions have been or will be made (in separate documents). The scope in more detail is as follows: 1. For all the data groups that will be interfaced (automated) will be indicated in which form

(e.g. type of message) and with what kind of infrastructure (e.g. webservices, webscreens, etc.) the data are exchanged.

2. The information exchange which is used for steering purposes in the market and balancing regime. The near real-time information exchange which is used for parties “to act upon” (e.g.

POS, SBS, program and WDM Balancing Action process information) will be described in full detail.

3. The information exchange currently in use. The information exchange used in the current GTS B2B webservices will be described in

an appendix.

Not in scope 1. The non-automated information exchange. 2. The detailed layout and definitions of web screens.

1.3 Abbreviations and terminology PRP

Program Responsible Party

SO System Operator, in the Netherlands this is GTS (Gastransportservices). Sometimes called TSO (Transmission Service Operator)

Portfolio Group of Networkpoints on which level balancing is applied. Synoniem of ContractCode (i.e. GSABC)

ContractID Numerical identification of a Portfolio (i.e. numbers beginning with 56). Currently used in the Downloads.

UTC Coordinated Universal Time CET Central European Time = UTC+1 LET Local European Time Gas day A period commencing at 06.00 hours (LET) on a calendar day and ending at

06.00 hours (LET) the following calendar day, and the date of a gas day shall be the date of its beginning as herein defined.


2 Basic assumptions 2.1 Approach The following assumptions have been made as a starting point for the design and implementation of the information exchange in the Dutch market and balancing model: 1. The communication means are as much as possible easily accessible for all involved parties

and especially for new parties. 2. For the information being exchanged, as much as possible market standards have been used

for message design and infrastructure. 3. Development of messages (i.e. technical message definitions) is done by:

a. The Edigas organisation; b. EDSN; c. By GTS, on basis of the EDSN standards.

2.2 Content In this chapter the general requirements are defined that apply for all or a group of messages (Edigas messages or XML webservices).

2.2.1 General 1. Recognizing (portfolio’s of) market parties will be done primarily by the Edigas code. This is

the only identifier that is used (or is easy to acquire) by all parties. For details concerning the use of identifiers, see the detailed message definitions.

2. The standard (and sole) unit for exchanging Energy data is kWh/h for energy quantities per hour and kWh for an energy quantity. (e.g. Program - 6:00-8:00 500 kWh/h, this is a flow of 500 for each hour. POS -540 kWh this is a position and not a quantity per hour).

3. Prices are noted in 4 decimals (e.g. € 0,1012) and in Euro. 4. An entry amount is depicted with a negative (“-“) sign, e.g. -100 means 100 entry. 5. An exit amount is depicted without a sign, e.g. 100 means 100 exit. 6. The sign convention for a balance signal is as follows:

a. A negative imbalance amount (e.g. -15) means that a party has realised 15 more entry than exit. In other words: the party should have had 15 more exit or 15 less entry to be in balance (i.e. Long).

b. A positive imbalance amount (e.g. 80) means that a party has 80 more exit than entry. In other words: the party should have had 80 more entry or 80 less exit (i.e. Short).

2.2.2 XML messages (webservices) 1. Time in the messages is formatted in CET. 2. Allocated and measured energy amounts are noted in 6 decimals, e.g. 1200.123456 kWh/h.

The POS and SBS have no decimals. 3. As a label for a period of a full clock hour, the time of the next hour is used. E.g.:

c. 30th June from 08:00 – 09:00 will be expressed by the hour 09:00; d. 30th June from 23:00 – 0:00 will be expressed as 1st of July 0:00.

4. The information that is made available by GTS (e.g. POS, SBS, allocations, etc.) is made available on a “collect basis”. This means that the parties who use this data, have to collect it. In a technical way: GTS deploys webservices which the PRP can approach to get the needed data.

2.2.3 Edigas messaging 1. Time in the Edigas messages is formatted in UTC. 2. Energy amounts are noted in 0 decimals, e.g. 1200 kWh/h.


3. The Edigas version for all messages will be version 4 or higher. Only XML versions of the messages are supported.

4. For all Edigas messages where an amount (energy and or price) is given for a certain period, a period of a complete gasday is included in the message. For the hours where no amount is needed, a zero amount is given.

5. General header information Edigas messages. A lot of the information that is exchanged in Edigas messages is the same for all messages. The specification of these attributes will be included in the MIG (technical message description).

6. Acknowledgement Edigas messages. Edigas confirmation messages send by the SO are not acknowledged by the recipient (PRP). The reason for this is that the PRP already is aware of the fact that a confirmation will be send by the SO. When a problem in receiving the confirmation message occurs, the PRP is responsible for taking action. Only the Activation of the Emergency Measure needs to be acknowledged. An acknowledgement contains the feedback of the receipt and a possible error codes. The exact error codes will be specified in the Edigas Code lists.

7. Identification An Edigas document is unique for each combination of Issuer, Id and Version. If a document has more than one document type, the Id must be unique over all types. I.e. An exit program document and an entry program document must have an identification that is unique for both documents.

2.2.4 Examples The message examples in this document are only for illustration purposes and serve to illustrate. The examples should not seen as or be used as message specifications and/or implementation.


3 Overview In this chapter an overview is given of all information flows which are changing or are new. In the picture below the main part of the operational data flow is depicted.


3.1 Processes and information flows The processes are described in the Detail Process Models, see Referenced documents [2 t/m 4]1. In this paragraph a short summary of each process is given and the related information flows are defined.

3.1.1 Process programme The Program processing is described in [2] DPM Programme. The sub processes produce or process external information flows:

Process step Information flow From To 1 Publish parameters damping formula Parameters damping formula SO PRP 2 Submit program Program PRP SO 3 Validate internal consistency Acknowledgement

Feedback on internal consistency validation.

SO PRP

4 Confirm Program Confirmation Program SO PRP GTS publishes the parameters of the damping formula2. The Program Responsible Party (PRP) sends the Program (D-1) and is directly validated on internal consistency. GTS will acknowledge (positive or negative) the Program. After all programs are received by GTS an external consistency validation is performed which results in a confirmation of the program.

3.1.2 Publish POS and SBS The processing of the POS and SBS are described in [4] DPM Markted and allocation. The following processes produce or process external information flows.

Process step Information flow From To 1 Publish POS POS SO PRP 2 Publish SBS SBS SO PRP

Each 5-minutes the Portfolio Imbalance Signal (POS) is calculated and published, containing the prediction of the running hour. The near real-time imbalance is used for the Settlement in combination with the Off-line imbalance that is defined after the processing of the accountable measurements and allocations. The POS is also used for defining the SBS (sum of POSses) and the division of volume in case of a within day balancing action call or an Emergency call. The SBS is also calculated and published each 5-minutes, containing the prediction of the running hour.

1 The underneath global descriptions of the process is just for illustration purposes, the exact process is described in the DPM. 2 See the DPM for the exact timing constraints.


3.1.3 Process Within Day Balancing Action The processing of the Within Day Balancing Action is described in [3] DPM Within Day Balancing Action process. The following processes produce or process external information flows.

Process step Information flow From To 1 Publish Balancing Action volume and product

Balancing Action order (volume and product)

SO WDM SO PRP

2 Obtain called volume and product from WDM Trading Platform

Send order to WDM Trading Platform Confirmation of WDM order

SO WDM WDM SO

3 Submit Balancing Action confirmations to causers

Confirmation of Balancing Action volume to the causers

SO PRP

At some moments when the prognosis of the SBS at the end of the current hour is outside the defined borders, GTS triggers the Within Day Balancing Action. GTS will also publish the WDM order (via web screens). A Within Day Market Order is made by GTS to the WDM Trading Platform to make the necessary quantities available. The quantity that is ordered from the WDM is divided pro rata to the ‘causers’ (the PRP with a POS with an equal direction to the SBS). This is done with a CauserConfirmation (on a specific virtual networkpoint)

3.1.4 Process Emergency Call The processing of the Emergency Measure Call is described in [3] DPM Within Day Balancing Action process. The following processes produce or process external information flows.

Process step Information flow From To 1 Publish Emergency call

Emergency Measure Publication

SO PRP

2 Submit Emergency Activations to the suppliers

Emergency Measure Supplier Activation Acknowledgement Emergency Measure Confirmation to Suppliers

SO PRP PRP SO SO PRP

3 Submit Emergency gas confirmations to causers

Emergency Measure Confirmation to causers

SO PRP

At some moments when the prognosis of the SBS at the end of the current hour is outside the defined border and if there are no means available to solve the imbalance in time, GTS does an emergency call. A number of activations to the suppliers of emergency means are called to make the necessary quantities available. The quantity that is called is divided pro rata to the causers. The PRP’s with a POS with an equal direction of the SBS. This is done with a Emergency Measure Confirmation to causers (on the virtual Networkpoint Emergency Clearing point).


3.2 Communication For the information flows, the following means of communication will be used:

A. Edigas messages3 via:

1. Internet/AS2 using preferable EASEE-gas certificates (preferred protocol) or; 2. ISDN/FTP (supported for current users up to March 1st 2014).

Protocol: Edigas version 4.0 or higher4: XML (Edifact type messages are not supported).

B. GTS websites (web screens). 1. Private: Web screens (“Gasport” portal). 2. Public: The public GTS website.

Exact content and layout is not part of this DPM document.

C. EDSN XML messages (webservices). XML via internet, using Verisign certificates.

D. GTS XML messages (webservices). XML via internet, using Verisign certificates.

In the overview below the types of communication are mapped to the message or information group. Message Contents Communicatie type Program Day ahead prognoses A.

Confirmation Program

Acknowledgement of Program by GTS

A.

Confirmation mergency means

Call of GTS to use Bid Price Ladder Offer(s) to correct a imbalance in the network, with Quantity and Price

A.

Confirmation Within Day Balancing Action

Confirmation with quantity and Price to Causers

A.

POS (Portfolio Imbalance Signal)

Contains the Imbalance of the Portfolio of a PRP

B-1 C.

SBS (System Balance Signal)

Contains the total system balance

B-1 B-2 C.

Balancing agreement

Message of an agreed balancing agreement, sent in by both parties in the balancing relation.

A.

All other allocation and measurement downloads.

Near real time and accountable allocation and measurement data.

D. GTS XML webservice

4 The acknowledgement message (ACKNOW) will be version 5.0 because this version contains the right identification of the original message (including version nr). Besides this, the Control cannot be used in XML, this control is incorporated into the APERAK version 5.0.


4 Content 4.1 Program Estimation by the Program Responsible Party of the total gas transport of a gasday. Purpose It gives GTS information about the expected volumes (and damping) day ahead and is used for calculation of the imbalance position of the portfolio of the Program Responsible Party. Trigger A Program Responsible Party will send an Entry and/or Exit or Trade Program for each gasday. Design decisions 1. Type Program – Entry / Exit / Trade A distinction between Programs is needed. Therefore the Program Type is added with the possible values: Entry, Exit, Trade. An Entry or Exit Program can contain trades, only one of those Programs may be used to specify all trades (not both). 2. Use of Counter Portfolio GSTPENTRY A standard Counter Portfolio that always needs to be available in an Entry Program is GSTPENTRY. On this Portfolio the total of all Entry is specified this represents the transfer of the entry to the VPPV. This is used to validate the Programme. For Entry programs no damping will be applied. This means that the GSTPENTRY total is always the sum of the other Counter Portfolio’s in the Program for each hour. 3. Use of Counter Portfolio GSTPEXIT In Exit Programs a standard Counter Portfolio GSTPEXIT needs to be available. On this Portfolio the total Exit is specified, including the damping formula. The total of all other Counter portfolio’s and the damping is equal to the quantity on GSTPEXIT. A Trade program will contain only trade and the GSTPENTRY/GSTPEXIT portfolios are not present. 4. A Differentiation of protected users In an exit Program a distinction of the total exit needs to be made between protected users. For all PRP’ers with a B Licence this distinction is required. Therefore the Counter Portfolio GSTPPU is needs to be used to specify the total of Protected Users and the Counter Portfolio GSTPOTHER is used to specify the rest. In this case the GSTPEXIT or GSTPENTRY is not used. 5. A Differentiation of protected users for PRP with a balancing agreement When the PRP provides a balance the differentiation of protected users must be made by the Counter Portfolio’s GSTPPUB and GSTPOTHERB. 6. Networkpoint VPPV The location on which the program is placed on is the VPPV (see [1]) and is always the same for all programs. 7. A Program contains information for one Portfolio of the PRP at a time 8. A Program must contain one Gasday. 9. A Program will be acknowledged. When the validation takes place before publication of the

damping parameters the validation will take place in two steps. The first step validates the internal consistency and will lead to an acknowledgement message, the second step validates the application of the damping parameters and will lead to a second acknowledgement message. When a program is validated after publication of the damping parameters the validation will lead to one acknowledgement.


Content The content of the Program is: Attribute Definition Type Domain Example M Identification Program Identification of the Program

for each PRP for each gasday. Consists of a nuber to be defined by the PRP and a version if the Program is send more than once for the gasday. This identification is referenced in the Program confirmation.

AN PRODOC20090911000001 Version 01

Y

ValidityPeriod The gasday(s) in which the Program is valid.

Date Whole gasday

2009-05-30 2009-05-30

Y

TypeProgram Entry, Exit or Trade Program.

AN Entry Exit Trade

Entry Y

Portfolio (in Edigas: Contract Reference)

Id of the portfolio where the Program is placed in. A PRP can have more than one portfolio. (In Edigas terminology this is called a Contract Reference)

AN Issued by GTS

GSABC Y

Networkpoint The Networkpoint that is used for all Programs. This is always the VPPV (Virtual Point Program Responsible) for a program.

AN Issued by GTS

VPPV Y

For each Time interval and Counter portfolio the information underneath applies:

Time interval

Whole hour(s) within the Gasday for which the information is valid.

Date Hours within gasday

2009-05-30 4:00 2009-05-31 4:00

Y

Counter Portfolio (in Edigas : Account type)

Identification of the Portfolio (ContractCode) of the PRP counter party. Additionally the following Portfolio’s are possible: GSTPEXIT, GSTPPU, GSTPPUB, GSTPOTHER, GSTPOTHERB and GSTPENTRY.

Port folio

Issued by GT

GSXYZ Y

Quantity Total energy in kWh per hour of the Program in the Validity Period and for the Counter Portfolio

N17 0 decimals

40000 Y

Direction The direction of the quantity. Input = Entry = “-“ Output = Exit = “+”

AN - Entry + Exit

- Y

The acknowledgement can contain the following situations (the complete list will be specified in het Edigas MIG): Program is not allowed for this contract

The Portfolio mentioned in the Program is not valid.

Program accepted with remarks (damping parameters not yet available).

The Program is received before publication of the damping parameters and is accepted (the basic validations are performed).


4.1.1 Examples messages: Programs

1. Program – Entry (no trade) ValidityPeriod 06-05-2009 04:00 - 07-05-2009 04:00 (UTC) TypeProgram Entry Portfolio GSABC Networkpoint VPPV Counter Portfolio Time interval Quantity GSTPENTRY*1* 04:00-08:00 -100000 08:00-09:00 -100000 .. .. 02:00-03:00 -100000 03:00-04:00 -100000 GSABC*2* 04:00-08:00 100000 08:00-09:00 100000 .. .. 02:00-03:00 100000 03:00-04:00 100000 *1* GSTPENTRY portfolio is the total of all Entries. *2* In this example the whole quantity is transferred (over the vppv) to the party itself.

2. Program – Exit (with trade and damping) ValidityPeriod 06-05-2009 04:00 - 07-05-2009 04:00 (UTC) TypeProgram Exit Portfolio GSABC Networkpoint VPPV Counter Portfolio Time interval Quantity GSTPEXIT*1* 04:00-08:00 115000 08:00-09:00 126000 .. .. 02:00-03:00 123000 03:00-04:00 156000 GSABC*2* 04:00-08:00 -100000 08:00-09:00 -100000 .. .. 02:00-03:00 -100000 03:00-04:00 -100000 GSXYZ 04:00-08:00 -20000 08:00-09:00 -30000 .. .. 02:00-03:00 -20000 03:00-04:00 -50000 *1* GSTPEXIT portfolio is the total of all Exits without damping. The difference between GSTPEXIT and the other Counter Portfolio’s should be the damping calculated with the damping formula. *2* In this example the whole quantity is transferred (over the vppv) to the party itself. This quantity is also specified in the Exit program. The damping is not part of the exchanged information and is calculated with the damping formula. The total of all Delta’s during the Gasday should be 0. In this example the PRP calculated the following quantities for the delta:


04:00-08:00 5000 08:00-09:00 4000 .. .. 02:00-3:00 -3000 03:00-04:00 -6000

3. Program – Trade ValidityPeriod 06-05-2009 04:00 - 07-05-2009 04:00 (UTC) TypeProgram Trade Portfolio GSABC Networkpoint VPPV Counter Portfolio Time interval Quantity GSA 04:00-08:00 120000 08:00-09:00 130000 .. .. 02:00-03:00 120000 03:00-04:00 150000 GSB 04:00-08:00 -120000 08:00-09:00 -130000 .. -120000 02:00-03:00 -120000 03:00-04:00 -150000


4.2 Program Confirmation Confirmation from GTS to the PRP that the program is processed. Contains also information about the possible errors. Purpose Give the PRP information about the processing of the program. The PRP could issue an adapted program as a result of this. Trigger The receipt of a Program triggers the Program Confirmation. Design decisions 1. Feedback of the Delta The calculated value of the Delta as a result of the application of the damping formula is added in the Confirmation of the program. This Delta is placed on a specific portfolio: GSTPD. The reason for this is that the Delta can be different as expected by the PRP due to error situations. The Delta is also part of the confirmation of the Entry program and will be zero. 2. Feedback of the total transferred from the VPPV. For an Exit program this is placed on a specific portfolio: GSTPVPPVEN For an Entry program this is placed on a specific portfolio: GSTPVPPVEX For an Exit program this is placed on the specific portfolio’s: GSTPVPPVEN and GSTPVPPVEX. 3. Acknowledgement A Program confirmation will not be acknowledged by the PRP. The PRP needs to take action themselves when no Program confirmation is received (in time). Content The content of the Confirmation of the Program is very much like the program itself with the exception that the Quantity can be different to the program due to matching errors, the error codes itself are also added. Attribute Definition Type Domain Example M ValidityPeriod The gasday in which the

Program is valid. Date One

gasday 2009-05-30 Y

TypeProgram Entry, exit or only Trade Program. An Entry program always contains the special Portfolio GSTPENTRY, but can also contain trade. This also accounts for the Exit program. A Trade program will contain only trade and the GSTPENTRY/GSTPEXIT portfolio’s are not present.

Code Entry Exit Trade

Entry Y


Id of the portfolio (ContractCode) where the Transport Program is placed in. A PRP can have more than one portfolio.

AN Issued by GTS

GSABC Y

Networkpoint The Networkpoint that is used for all Programs. This is always the VPPV (Virtual Point Program Responsible) for a program

AN Issued by GTS

VPPV Y

Confirmed Program Identification of the Program that is confirmed

AN PRODOC20090911000001 Version 01

Y


Attribute Definition Type Domain Example M For each Time interval and Counter portfolio the information underneath applies:

Time interval Whole hour(s) within the Gasday for which the information is valid.

Date Hour

Hour within Validity period

2009-05-30 4:00 2009-05-31 4:00

Y

Counter Portfolio (in Edigas : Account Type)

Identification of the Portfolio of the PRP counterparty. Additionally the following Portfolio’s are possible: GSTPEXIT, GSTPPU, GSTPPUB, GSTPOTHER, GSTPOTHERB, GSTPENTRY and GSTPVPPVEN, GSTPVPPVEX, GSTPD

Portfolio

Issued by GTS

GSXYZ Y

Quantity Total quantity that is confirmed. This can be another value than the program. The Quantity is 0 when there is a mismatch.

N17 kWh/h 35000 Y

Reason Reason code giving feedback about the confirmation. Ok if there are no errors or an error code if there are errors.

Code Edigas code list 9321

70G Y

The Reason code can contain the following situations (the complete list will be specified in het Edigas MIG): Program Accepted The program is accepted Damping Formula not correctly used in the program

The damping parameter is not applied correctly and is set to 0 in the Program confirmation.

Program Accepted with remarks (Message ok; chain is not correct yet)

All items in the program are accepted only not all programs in the chain of Counter portfolio’s are accepted.

Program Rearranged to match The quantity is adapted due to a mismatch.


4.2.1 Example messages: Program confirmations

1. Program – Entry (no trade) ValidityPeriod 06-05-2009 04:00 - 07-05-2009 04:00 (UTC) TypeProgram Entry Portfolio GSABC Networkpoint VPPV Counter Portfolio Time interval Quantity Reason GSTPENTRY 04:00-08:00 -120000 OK 08:00-09:00 -130000 OK .. .. OK 02:00-03:00 -120000 OK 03:00-04:00 -150000 OK GSABC 04:00-08:00 120000 OK 08:00-09:00 130000 OK .. .. OK 02:00-03:00 120000 OK 03:00-04:00 150000 OK GSTPD 04:00-08:00 0 OK 08:00-09:00 0 OK .. .. OK 02:00-03:00 0 OK 03:00-04:00 0 OK GSTPVPPVEX 04:00-08:00 -120000 OK 08:00-09:00 -130000 OK .. .. OK 02:00-03:00 -120000 OK 03:00-04:00 -150000 OK The GSTPDT (feedback of the delta) will always be zero in the entry program.

2. Program – Exit (with trade and damping) ValidityPeriod 06-05-2009 04:00 - 07-05-2009 04:00 (UTC) TypeProgram Exit Portfolio GSABC Networkpoint VPPV Counter Portfolio Time interval Quantity Reason GSTPEXIT 04:00-08:00 115000 OK 08:00-09:00 126000 OK .. .. OK 02:00-03:00 123000 OK 03:00-04:00 156000 OK GSABC 04:00-08:00 -100000 OK 08:00-09:00 -100000 OK .. .. OK 02:00-03:00 -100000 OK 03:00-04:00 -100000 OK GSXYZ 04:00-08:00 -20000 OK 08:00-09:00 -30000 OK .. .. OK 02:00-03:00 -20000 OK 03:00-04:00 -50000 OK GSTPD *1* 04:00-08:00 5000 OK


08:00-09:00 4000 OK .. .. OK 02:00-03:00 -3000 OK 03:00-04:00 -6000 OK GSTPVPPVEN 04:00-08:00 120000 OK 08:00-09:00 130000 OK .. .. OK 02:00-03:00 120000 OK 03:00-04:00 150000 OK *1* The extra Counter portfolio is added with the confirmed delta that is allowed according to the application of the damping formula.

3. Program – Trade ValidityPeriod 06-05-2009 04:00 - 07-05-2009 04:00 (UTC) TypeProgram Trade Portfolio GSABC Networkpoint VPPV Counter Portfolio Time interval Quantity Reason GSA 04:00-08:00 120000 OK 08:00-09:00 130000 OK .. .. OK 02:00-03:00 120000 OK 03:00-04:00 150000 OK GSB 04:00-08:00 -120000 OK 08:00-09:00 -130000 OK .. -120000 OK 02:00-03:00 -120000 OK 03:00-04:00 -150000 OK GSTPD 04:00-08:00 0 OK 08:00-09:00 0 OK .. .. OK 02:00-03:00 0 OK 03:00-04:00 0 OK GSTPVPPVEN 04:00-08:00 120000 OK 08:00-09:00 130000 OK .. .. OK 02:00-03:00 120000 OK 03:00-04:00 150000 OK GSTPVPPVEX 04:00-08:00 -120000 OK 08:00-09:00 -130000 OK .. .. OK 02:00-03:00 -120000 OK 03:00-04:00 -150000 OK


4.3 Causer Confirmations As described in chapter 3, after a Within Day Balancing Action Trigger, all Causers receive information about the rearrangement of their POS. This leads to confirmations on administrative network points, to make the differentiation between the situations. This message is used for the following information stream: 1. Causer Confirmation (CLRCON message). Purpose Divide the confirmed quantity from the Confirmed Within Day Market Order amongst the causers, this as a result from the Within Day Balancing Action Trigger. Trigger The Within Day Balancing Action Trigger as published. Design decisions 1. Causers The Causers receive a clearing confirmation message after the Within Day Balancing Action Trigger is published and the Confirmed Within Day Market Order is processed by the SO (GTS) as received from the Within Day Market Trading Platform. 2. Quantity The quantity confirmed to the Causer will be assigned to the networkpoint Balancing Virtual Point with message type ALS. 3. Time interval The Clearing Confirmation message is always complete, i.e. always contains all called hours in one gas day. 4. Price The price as specified in the DPM Within Day Balancing Action process [3]. 5. Acknowledgement No acknowledgement is needed in respons to the Causer Confirmations. The PRP knows already by the published Within Day Balancing Action Trigger (via Portal/website) that a Within Day Order has been made to the Trading Platform and which position the PRP has (causer). Based on this information the PRP needs to take action when none or too few confirmations have been received.


Content Attribute Definition Type Domain Example M ValitityPeriod The gasday in which the Bid Price

Ladder Offer is valid Date 2013-05-30

04:00 2013-05-31 04:00

Y

Message Type The type of confirmation5

AN ALR ALR

Portfolio Id of the portfolio of the causer. (in Edigas: Contract Reference)

AN Issued by GTS

GSABC Y

Networkpoint Identification of the administrative Networkpoint: Balancing Virtual Point

AN See Definition

BVP Y

Currency The currency of the price. Standard: Euro

Unit Euro Euro Y

For each combination of ValitityPeriod, Quantity, Price


Date 2013-05-31 4:00 2013-05-31 5:00

Y

Quantity The quantity of the correction of the POS

N11.6 kWh/h 15000 Y

Direction The direction of the Quantity Code - or + Z02 Y

Price The price of the quantity offered per unit. Can be positive and negative.

N1,4 + and - 0,0020 Y

4.3.1 Example message: Causer Confirmation Within Day Order Within Day Order at 13:20 (UTC) Clearing Confirmation on BVP ValidityPeriod 06-05-2009 04:00 - 07-05-2009 04:00 (UTC) Portfolio GSABC Networkpoint BVP Currency Euro Time interval Quantity Price 04:00-08:00 0 - 08:00-09:00 150000 0,0099 09:00-04:00 0 -

5 See the MIG BALMAN for the exact description.


4.4 Emergency Measure Supplier Activation Assignment to PRP to make available a certain quantity at a certain price. Purpose Emergency call to compensate an imbalance in the System (BIDACT message).. Trigger An emergency situation at the SO. Design decisions 1. Validity period A confirmation will always cover a whole gasday. If the Call has occurred more than one time on that day, the activation of the previous hours are also part of this message. If an hour is called twice, the quantities for the activation are cumulative. 2. Quantity The quantity that is called can be smaller than needed to fulfil the complete void of the emergency situation. 3. Price The price as specified in the DPM Within Day Balancing Action process [3]. 4. Acknowledgement Each Emergency Measure Supplier Activation needs to be acknowledged by the PRP. Content Attribute Definition Type Domain Example M ValitityPeriod The gasday in which the Bid

Price Ladder Offer is valid Date One

gasday 2013-05-30 04:00 2013-05-31 04:00

Y

Portfolio Id of the portfolio. (in Edigas: Contract Reference)

AN Issued by GTS

GSABC Y


Unit Euro Euro Y

For each combination of Networkpoint, Lead time

PhysicalNetworkpoint Identification of the physical Networkpoint of the offer.

AN Issued by GTS

Zuidwen Y

Lead time The lead time of the offer: Fast (30 minutes), Medium (90), Slow (150 minutes).

Time 30, 90, 150

30 Y

Direction The direction of the quantity offered. - = Entry, + = Exit

AN - or + - Y

For each combination Time interval, Direction, Price the sum of Quantity that is called.


DateHour

Hour within Validity period

2013-05-30 4:00 2013-05-30 5:00

Y


N1.4 + and - 0,0091 Y

Quantity The quantity requested. N17 kWh/h 1500 Y


4.4.1 Example message: Emergency Measure Activation Emergency measure Activation ValidityPeriod 06-05-2009 04:00 - 07-05-2009 04:00 (UTC) Portfolio GSABC Currency Euro Physical Networkpoint Lead time

Time interval *1* Quantity Direction

Price 2

UGS1 30 04:00-08:00 0 - 90 08:00-09:00 150000 + 0,0093 30 09:00-04:00 0 - *1* The time interval will always be a whole gasday, only the called offers are specified.


4.5 Emergency Measure Activation Confirmation messages This message is used for the following information streams: 1. Confirmation to emergency means supplier (CLRCON message).. 2. Emergency Measure confirmation to causers (CLRCON message).. As described in chapter 3, after an Emergency Measure Supplier Activation, all Causers receive information about the rearrangement of the POS. This leads to confirmations on administrative network points, to make differentiation between the situations. Purpose Divide the called quantity from the Emergency Measure Supplier Activation amongst the Causers. Trigger The Emergency Measure Supplier Activation based on an emergency situation at the SO. Design decisions 1. Causers In case of an emergency situation the causers will receive a confirmation on the Networkpoint NVP with message type ALT when the Emergency Measure Supplier Activation is made. 2. Emergency measure suppliers In case of an emergency situation the confirmation to the suplliers will contain Networkpoint NAP with message type ALT. 3. Time interval A confirmation is always complete, i.e. always contains all activated hours in one gas day. 4. Acknowledgement No acknowledgement is needed on these Emergency Measure confirmation messages. The PRP knows already by the published Emergency Measure Activations (via Portal/website) that an Emergency Measure Activation has been made to the suppliers. The position (POS) is known by the PRP (causer). Based on this information the PRP needs to take action when none or too few confirmations have been received.


Content Attribute Definition Type Domain Example M ValitityPeriod The gasday in which the Bid Price

Ladder Offer is valid Date 2013-05-30

04:00 2013-05-31 04:00

Y

Message Type The type of confirmation6

AN ALS, ALT

ALS


Id of the portfolio where the BidPriceladderOffer is placed on.

AN Issued by GTS

GSABC Y

Networkpoint Identification of the administrative Networkpoint: NAP Noodmaatregel Aanbieder Punt NVP Noodmaatregel Veroorzaker Punt

AN See Defini-tion

BPL Transfer point BPL-gas

Y


Unit Euro Euro Y

For each combination of ValitityPeriod, Quantity, Price


Date 2013-05-31 4:00 2013-05-31 5:00

Y

Quantity The quantity of the correction of the POS

N11.6 kWh/h 15000 Y

Direction The direction of the Quantity Code - or + - Y


N1,4 + and - 0,0020 Y

4.5.1 Example message: Emergency Measure Supplier Activation The examples are only for illustration purposes and serve to illustrate the messages. The examples should not be seen or used as a message specification. Emergency Measure Activation Confirmation ValidityPeriod 06-05-2013 04:00 - 07-05-2013 04:00 (UTC) Portfolio GSABC Networkpoint NAP Currency Euro Time interval Quantity Price 04:00-08:00 0 - 08:00-09:00 150000 0,0099 09:00-04:00 0 -

6 See the MIG BALMAN for the exact description.


4.6 Portfolio Imbalance Signal – POS Information about the imbalance position of the Portfolio of the Program Responsible Party. Purpose Give the PRP information about the realized and predicted imbalance position of his Portfolio. This information will be used for settlement, bid ladder call and balancing the portfolio by the PR. Trigger A POS is determined every 5 minutes after the processing of the measurements and the calculation of the allocations. The trigger of the POS-message will be the request by the PRP. Design decisions 1. The POS will be available for download and will not be send to each PRP. This option is more

flexible than sending a predefined message and is equal to the current available downloads. The POS needs to be requested by the PRP by issuing the PortfolioID to GTS.

2. The POS contains the following data streams (the data streams are implemented as separate

webservices):

Operational Accountable POS – This is information of a whole hour. This information is always final and is available between 15 and 20-minutes after the hour. The operational version is available until 24 hours after gashour. Analysis Accountable POS – This is information of a whole hour. This information is always final and is available the calendar day after gasday. The analysis version can deliver 7 years of history. Operational POS - Prognosis of the POS for the end of the running hour. Every 57 minute of the end of the running hour the imbalance position is calculated based on the predicted hourly allocations and hourly program.

3. Several options will be possible in the request. These options will be equal to the current

ones specified in the XML-downloads if relevant (Portfolio, Period, Start and Enddatetime). The Energy Unit (kWh) and Timebase (CET) will be fixed for the POS (and SBS).

7 This is the normal situation, in exceptional situations the information can be available later.


Contents POS The POS message contains the following information: Attribute Definition Type Domain Example M Portfolio The Edigas code of the

portfolio of which the POS is calculated.

AN Issued by GTS

GSPV1 Y

Energy Unit The energy unit used for all the energy amounts in the message.

AN kWh kWh Y

Time Format8 The time format used for all the time attributes in the message.

AN CET CET Y

For each MeasurementDateTime

Cycle DateTime Measurement

The Date and Time (in steps of 5 minutes) of the cycle of the measurements that form the basis for the POS.

Date-Time

Every 5 minutes

2009-05-30 13:05

Y

Accountable POS information

DateTimePOS The Date and Time in whole hours of the latest final POS position.

Date-Time

Whole hours

2009-05-30 12:00

Y

POS Position The cumulative imbalance position (in kWh) of the latest hour based on the final allocations.

N12 120123 Y

Prognosis POS information

DateTimePOS The Date and Time in whole hours of the POS Position. This is always the end of the running hour9.

Date-Time

Whole hours

2009-05-30 14:00

Y

POS Position The cumulative imbalance position (in kWh) on the end of the running hour based on the extrapolated allocations.

N12 76231 Y

8 Since ISO8601 is used for Date and time formats, the Time format CET is implemented as part of each Datetime as an offset to UTC (+1). 9 The values with a MeasurementDateTime in between the hours (e.g. 04:15) are predictions to the next whole hour (e.g. 05:00). The values with a MeasurementDateTime of a full hour (e.g. 05:00) are values of this hour (e.g. 05:00).

4.6.1 Example message: POS Accountable Prognosis

Portfolio

Creation time (hh:mm:ss)

Cycle DateTime Measurement(Date= 2009-08-06) DateTimePOS

POS Position DateTimePOS

POS Position

GSPV1 13:09:45 13:05 12:00 120 14:00 76 GSPV2 13:09:46 13:05 12:00 -65 14:00 -43 GSPV1 13:15:49 13:10 13:00 100 14:00 82 GSPV2 13:15:49 13:10 13:00 -53 14:00 -55

GSPV1 13:19:46 13:15 13:00 100 14:00 100 GSPV2 13:19:46 13:15 13:00 -53 14:00 -59 GSPV1 13:24:45 13:20 13:00 100 14:00 88 GSPV2 13:24:46 13:20 13:00 -53 14:00 -56 GSPV1 13:29:45 13:25 13:00 100 14:00 90 GSPV2 13:29:45 13:25 13:00 -53 14:00 -48 GSPV1 13:34:45 13:30 13:00 100 14:00 98 GSPV2 13:34:45 13:30 13:00 -53 14:00 -45 GSPV1 13:39:45 13:35 13:00 100 14:00 103 GSPV2 13:39:45 13:35 13:00 -53 14:00 -43 GSPV1 13:44:45 13:40 13:00 100 14:00 108 GSPV2 13:44:45 13:40 13:00 -53 14:00 -43 GSPV1 13:49:45 13:45 13:00 100 14:00 111 GSPV2 13:49:45 13:45 13:00 -53 14:00 -45 GSPV1 13:54:45 13:50 13:00 100 14:00 113 GSPV2 13:54:45 13:50 13:00 -53 14:00 -47 GSPV1 13:59:45 13:55 13:00 100 14:00 115 GSPV2 13:59:45 13:55 13:00 -53 14:00 -49 GSPV1 13:04:45 14:00 13:00 100 14:00 117 GSPV2 13:04:45 14:00 13:00 -53 14:00 -50 GSPV1 14:09:45 14:05 13:00 100 15:00 105 GSPV2 14:09:45 14:05 13:00 -53 15:00 -62 GSPV1 14:15:49 14:10 14:00 120 15:00 105 GSPV2 14:15:49 14:10 14:00 -50 15:00 -62 GSPV1 14:19:49 14:15 14:00 120 15:00 121 GSPV2 14:19:49 14:15 14:00 -50 15:00 -62 GSPV1 14:24:49 14:20 14:00 120 15:00 -9 GSPV2 14:24:49 14:20 14:00 -50 15:00 -9 GSPV1 14:29:49 14:25 14:00 120 15:00 -7 GSPV2 14:29:49 14:25 14:00 -50 15:00 0


Specific situations in the examples The example is showing the POS for two Portfolio’s (GSPRP1 and GSPRP2) for each 5 minute situation. The Cycle DateTime Measurement is showing a whole hour (yellow) and the next 25 minutes in the next hour (green). An accountable stream is shown for the previous hour during the first 15 minutes (blue) because of the ‘delay’ of the steering signal. The POS will be available at 5 minutes after the Cycle DateTime of the Measurements. This moment is mentioned in the examples: Publication DateTime. This information is not part of the POS message. The following situations are explained: Cycle time of measurements 13:05 The measurements of 13:00 -13:05 are processed and allocated and are available at the latest at 13:10. The allocations for RNB-Networkpoints are based on the steering signal of 12:00 hours. The allocations are extrapolated delivering the Prognosis of 14:00 Hour (76 and -43). The latest accountable POS position is still 12:00 hour (120 and -65) because the steering signal is not yet available. Cycle time of measurements 13:10 The measurements of 13:00 -13:10 are processed and allocated and are available at the latest at 13:15. The allocations for RNB-Networkpoints are based on the steering signal of 13:00 hours. These allocations are extrapolated delivering the Prognosis of 14:00 Hour (82 and -55). The allocations of the CSS (steering signal) are processed and lead to the accountable POS of 13:00 hour (100 and -53). Cycle time of measurements 14:00 The measurements of 13:00 -14:00 are processed and allocated and are available at the latest at 14:05. No extrapolation is needed because this is already a whole hour. (117 and -50). This is still a prognosis because the information of the steering signal is not yet available. The latest accountable POS is still 13:00 hour.


4.7 System Balance Signal – SBS The SBS gives information about the balance position of the total transport system. This is the total of all POS imbalance positions for all PRP’s. Purpose Gives involved parties (GTS and PRP) information about the balance position of the total system so that they can take corrective actions. Trigger An SBS is determined every 5 minutes after the calculation of all POSses. Design decisions 1. The SBS contains a prediction of the end of the next full hour (e.g. 08:00). No other hours

ahead are predicted.

2. The SBS will be available for download and will not be sent to each PRP. This option is more flexible than sending a predefined message and is equal to the current available downloads. The SBS needs to be requested by the PRP by issuing the PortfolioID to GTS.

3. The zone information is available in the SBS. 4. The SBS contains the following data streams:

a. SBS Position b. Zone information. Each zone and the absolute size of the zone is specified. c. Helper and Causer information as part of the accountable stream. Is needed to

calculate the possible impact of a Bid Price Ladder Call for the PRP.

The SBS can contain the following data streams (implemented as separate webservices): Operational SBS – Prognosis of the SBS for the end of the current hour. Operational Accountable SBS - This is information of a whole hour. This information is always final and is available between 15 and 20 minutes after the hour. The operational version is available until 24 hours after gas hour. Analysis Accountable SBS - This is information of a whole hour. This information is always final and is available the calendar day after gasday. The analysis version can deliver 7 years of history.

5. Change in SBS

It is not needed to specify the change in SBS since the last calculation, the PRP’s can calculate this themselves if needed. The change in SBS is defined as the (SBS on t) – (SBS on t-1).

6. The defined information for the SBS can (optionally) be combined with the already available allocations and POS in one download/service. The PRP will in most cases need the SBS in combination with the POS and allocations which form the underlying detailed information. Therefore an extra option will be added in the XML download of the Allocations to add the POS and/or SBS information.


Contents SBS Attribute Definition Type Domain Example M For each MeasurementDateTime

Cycle DateTime Measurement

The Date and Time (in steps of 5 minutes) of the cycle of the measurements that form the basis for the SBS.

Date-Time

Every 5 minutes

2009-05-30 4:20

Y

Energy Unit The energy unit used for all the energy amounts in the message.

AN kWh kWh Y

Time Format The time format used for all the time attributes in the message.

AN CET CET Y

Prognosis SBS

SBSDateTime The Date and Time in whole hours of the predicted SBS (for the end of the running hour).

Date-Hour

Whole hours

2009-05-30 5:00

Y

SBS Position The cumulative system balance position at the end of the running hour10.11

N12 -3.000.000 Y

Zone information. Occurs for each zone for each Hour.

Name zone (Status) The status of the zone (Dark green, Light green, Orange)

AN Dark Green, Light Green, Orange

Dark Green Y

Border max. The max. position of the border of the zone.

N12 2.500.000 Y

Border min. The min. position of the border of the zone.

N12 -2.500.000 Y

Helper and Causer information12

DateTime AccountableSBS

Date and time of the latest accountable SBS .

Date-Time

Whole hours

2009-05-30 4:00

Y

Accountable SBS The accountable cumulative system balance position.

N12 -2.000.000 Y

SumHelpers Total amount of the POS positions of the Helpers of the SBS of the last whole hour.

N12 -2.600.000 Y

SumCausers Total amount of the POS positions of the Causers of the SBS of the last whole hour.

N12 600.000 Y

10 The values with a MeasurementDateTime in between the hours (e.g. 04:15) are predictions to the next whole hour (e.g. 05:00). The values with a MeasurementDateTime of a full hour (e.g. 05:00) are values of this hour (e.g. 05:00). 11 The SBS is in a certain zone when the SBS Position =< Border max and >= Border min for the first zone mentioned in the list. When the SBS Position is outside the Borders of the Orange zone, the Zone is Red. 12 This is the split between the helpers amount and causers amount of the realised SBS of the previous hour to be used to calculate the effect of a possible call of the Bid price ladder. This quantity can be different from the sum of the helpers and causers because some helpers can be left out of the SBS.

4.7.1 Example message: SBS Prognoses Zones Helpers/Causers Cycle DateTime Measurement (Date= 2009-08-06) DateTimeSBS

System Balance Position

Name Zone

Border Min

Border Max

Name Zone

Border Min

Border Max

Name Zone

Border Min

Border Max

DateTime Last final POS

SumPOS Helpers

SumPOS Causers

13:05 14:00 33 DarkGreen -50 50 LightGreen -60 60 Orange -65 65 12:00 -65 120







13:40 14:00 65 DarkGreen -50 50 LightGreen -60 60 Orange -65 65 13:00 -65 12013:45 14:00 66 DarkGreen -50 50 LightGreen -60 60 Orange -65 65 13:00 -65 12013:50 14:00 66 DarkGreen -50 50 LightGreen -60 60 Orange -65 65 13:00 -65 12013:55 14:00 67 DarkGreen -50 50 LightGreen -60 60 Orange -65 65 13:00 -65 12014:00 14:00 70 DarkGreen -50 50 LightGreen -60 60 Orange -65 65 13:00 -65 12014:05 15:00 43 DarkGreen -50 50 LightGreen -60 60 Orange -65 65 13:00 -65 12014:10 15:00 43 DarkGreen -50 50 LightGreen -60 60 Orange -65 65 14:00 -30 10014:15 15:00 59 DarkGreen -50 50 LightGreen -60 60 Orange -65 65 14:00 -30 10014:20 15:00 -18 DarkGreen -50 50 LightGreen -60 60 Orange -65 65 14:00 -30 10014:25 15:00 -7 DarkGreen -50 50 LightGreen -60 60 Orange -65 65 14:00 -30 100

4.8 Balancing Agreement Purpose The balancing agreement message is used by parties to inform GTS of a balancing deal between these parties. On basis of the balancing agreement information, GTS will be able to take the balancing agreement into account in the allocation process. In order to facilitate this balancing relation, a message will be developed that is used by both parties involved in the balancing relation (on the TTF). The message will be a unique balancing agreement message and will use the same protocol as the nomination messages. Matching will be applied to the balancing messages. Trigger When parties decide upon a balancing deal, both will inform GTS. Messaging: balancing agreement Attribute Definition Type Domain Example M From party The Edigascode of the portfolio

of the sender.

AN Party Edig@s code

GS_GasCom Y

For the sending portfolio, the the following attributes are added (repeating group).

Balancing agreement with

The Edigascode of the portfolio of the party with whom the sender has a balancing deal.

AN Party Edig@s code

GS_GasInt Y

Role13 The role of the sender (“From party”) in the balancing relation.

AN Supplier Receiver

Receiver Y

For the above combination, the following attributes must or may be added (repeating group).

Validity period Validity period for which the agreement exists; date-time from to date-time to.

Date 1-10-2010 06:00 – 1-11-2010 06:00

Y

Category14 End user category for which the balancing deal applies

AN3 G1a, G2a, G2c, GKV, GGV GXX

G1a Y

Percentage15 The percentage of the unbalance that will be allocated

N % 100% Y

Minimum16 The excluded quantity. This quantity will not be allocated in this deal.

N kWh/h 1000 Y

Maximum The maximum value of the amount that will be allocated in this deal.

N kWh/h 50000 N

1. A balancing agreement is always sent in by both the balancing receiving party and the

balancing providing party. 13 A supplier role message will have to match with a receiver role message and vice versa. 14 Only one category can be mentioned. 15 If smaller than 100% (partial delivery), the minimum must be 0 (zero). 16 If the minimum is more than 0, the percentage must be 100% (no partial delivery).

Dea

l


2. All deals (see message definition above) for the sending portfolio will be sent in one (1) message. In case of a change in one of the deals, all of the deals will be sent (once again).

3. All attributes in the deal will be part of the matching process. In case of a mismatch in one of the attributes, the complete deal will be rejected (and has to be resent).

4. A balancing deal with a partial delivery (percentage of less than 100%) cannot be combined with a minimum (excluded quantity) of more than 0 (zero).

5. Balancing deals that will allocate more than 100% of the sum of the exits (for the balancing receiving portfolio) are not permitted. For example: balancing deals are not permitted if the percentages for all balancing deals for a certain portfolio, for one specific category, for a certain period, for a balancing receiving party will exceed 100%.

6. A party can create stacks of balancing deals (within the same portfolio, within the same period, within the same category) with several balance suppliers. In this stack of balance suppliers a supplier portfolio can only appear once.

7. In the same period and the same user category, a portfolio cannot have both roles (supplier and receiver).

Messaging: own use (part of the message) Own Use The deemed amount that the

balance receiving party delivers to the balance supplier.

N 10000 N

1. Own use can be (but does not have to be) used in combination with a balancing agreement. 2. The own use amount is nominated (by both the balance receiver and supplier) by the use of

the regular nomination message, sent in on the regular TTF point. 3. The same matching and allocation rules apply as for the regular deemed nominations. 4. The own use is a deemed quantity and will always be allocated (if confirmed). Allocation of the balancing deal 1. All balancing deals will be allocated on the special TTF-B (Balancing) point. 2. The own use deals will be allocated (and nominated) on the regular TTF point. 3. The combination in a balancing deal of both the minimum (excluded quantity) and the

percentage is not possible. The balancing partners should choose one of both or neither. 4. The allocation based upon the balancing agreement will be done in the following steps (for

each deal separately): 1 The sum of all the exits in the portfolio of the balance receiver in the mentioned end

user category will be determined.

2 Or: a. Of the amount calculated in 1, the minimum value (excluded quantity) is deducted.

Or: b. The percentage is calculated of the amount calculated in 1.

3 From the amount calculated in 2, the amount above the maximum is deducted.

4 The amount calculated above is allocated to both the balance receiver (-, entry amount) and the balance supplier (+, exit amount) on the TTF-B point.

None of the above steps can produce a negative value, a negative value will result in a zero (0) value. Exception is of course step 4 in which the allocation direction is indicated by a + or – sign). 5. The allocations on both the regular TTF and TTF-B (Balancing) are part of the Portfolio

Imbalance Position (POS).


Examples Balancing agreement with own use In the example below one balance supplier delivers gas to one balance receiver.

Both parties send in a balancing agreement and an own use nomination (a regular deemed trade nomination is used for handing over the own use amount). In case of a full delivery (100%), a minimum of 0 (zero) and no maximum, an amount equal to the total exit of the balancing receiver (in the specified use category) will be allocated to both the balance receiver (entry allocation on TTF-B) and the balance supplier (exit allocation on TTF-B).


Stacked Balancing agreement (with own use) In the example below three balance suppliers deliver gas (stacked) to one balance receiver. The first balance supplier delivers the gas up to an amount of 100, the second balance supplier delivers the amount between 100 and 200 and the third one delivers the amount over 200. The receiver brings an amount of 150 into the deal with the third balance supplier. In the example below, the values near the arrows depict the allocations.

All parties sent in a balancing agreement and the balance receiver and balance supplier-3 sent in a separate own use nomination. The balance agreement messages sent in by the balance receiver contain the following values (the deal content of the messages by the balance suppliers is equal):

Sender: B-Receiver Agreement with: B-Supplier-1 Role: Receiver Validity period: … Category: G1a Percentage: 100% Minimum: 0 Maximum: 100

Sender: B-Receiver Agreement with: B-Supplier-2 Role: Receiver Validity period: … Category: G1a Percentage: 100% Minimum: 100 Maximum: 100

Sender: B-Receiver Agreement with: B-Supplier-3 Role: Receiver Validity period: … Category: G1a Percentage: 100% Minimum: 200 Maximum: -


The total sum of the exits of the balance receiver is used as calculation input for each balancing deal. Allocation to B-receiver and B-Supplier-1: In the above example, the input value of 400 is capped by the maximum of 100; the allocation on TTF-B will be 100 for both the B-Receiver and the B-Supplier-1. Allocation to B-receiver and B-Supplier-2: In the above example, the input value of 400 will be reduced with the minimum of 10017 (or: excluded quantity); the then remaining amount is 300. This amount is capped by the maximum of 100. Thus, the allocation on TTF-B will be 100 for both the B-Receiver and the B-Supplier-2. Allocation to B-receiver and B-Supplier-3: In the above example, the input value of 400 will be reduced with the minimum of 200 (or: excluded quantity); the then remaining amount is 200. There is no maximum. Thus, the allocation on TTF-B will be 200 for both the B-Receiver and the B-Supplier-3. Note that in the case of stacked balancing agreements, for the balance suppliers, the minimum value is not an absolute value in the deal but a border value (for the total sum of exits of the balance receiver). In some cases the minimum can be greater than the maximum.

17 If the minimum is greater than the input value (sum of exits) an amount of zero will be allocated to both portfolio’s.


Appendix A - GTS B2B webservices

In this appendix a list of B2B webservices are given. The following types of information are distinguished: 1. Prognosed

Actual near real-time information (5-minute values) predicting the realised volumes / energy at the end of the current hour. This information is needed for the actual steering activities of the PRP and consists of the SBS, POS and allocations.

2. Operational Actual near real-time information (hourly values) with a history of max 36 hours. This information contains a.o. the SBS, POS and allocations. Besides this, actual measurements are available for Information contract users.

3. Analysis Accountable near real-time Historic near real-time data: the hourly accountable values of near real-time information for analysis purposes. This information can be used by the PRP for validation of the settlement and consists of the accountable near real-time SBS, POS and allocations.

4. Analysis Accountable off-line Historic information of offline data: the hourly values of offline accountable data for analysis purposes. This information can be used for validation of the settlement by the PRP and consists of the accountable off-line Imbalance and allocations. Besides this accountable measurements are available for Information contracts.

In the overview below the new Information Services are categorized to the types of information.

# Information service MessageType

#1 Publish Operational Portfolio Networkpoint Portfolio Networkpoint (1) #2 Publish Analysis Portfolio Networkpoint Portfolio Networkpoint (1) #3 Publish Operational Allocations Operational Allocations (2) #4 Publish Operational Networkpoint Measurements Networkpoint Measurements (6)

#5 Publish Operational Accountable Allocations Accountable Allocations (3) #6 Publish Analysis Accountable Near Real-Time

Allocations Accountable Allocations (3)

#7 Publish Analysis Accountable offline Allocations Accountable Allocations (3)

#8 Publish Operational Prognosis POS POS (4) #9 Publish Operational Accountable POS POS (4) #10 Publish Analysis Accountable POS POS (4) #11 Publish Analysis offline Imbalance Imbalance (14) #12 Publish Operational Prognosis SBS SBS (5) #13 Publish Operational Accountable SBS SBS (5) #14 Publish Analysis Accountable SBS SBS (5) #15 Publish Operational Bufferzones Bufferzones (7) #16 Publish Analysis Bufferzones Bufferzones (7) #17 Publish Operational Damping parameters Damping parameters (8) #18 Publish Analysis Damping parameters Damping parameters (8) #19 Publish Operational Run Measurements Run Measurements (9) #20 Publish Operational Run Measurements And

Quality Run Measurements And Quality (10)


#21 Publish Analysis Run Measurements And Quality Run Measurements And Quality (10)

#22 Publish Operational WeatherInformation WeatherInformation (11) #23 Publish Analysis WeatherInformation WeatherInformation (11) #24 Publish Analysis Networkpoint RestAllocation Networkpoint RestAllocation

(12) #25 Publish Analysis RunRestVolume Run RestVolume (13)

Appendix B - Relation To Edigas messages

The relation between the messages as described in this DPM and the implementation in Edigas messages is specified below: Message description Edigas message Message type Program Program document PRODOC Confirmation Program Program confirmation PROCON Causer Confirmation Clearing confirmation CLRCON Call emergency means Bid activation BIDACT Emergency Measure Supplier Activation Clearing confirmation CLRCON Acknowledgement message for Edigas messages Acknowledgement ACKNOW

dpm information exchange v3.0 - nedu - nedunedu.nl/.../2014/10/dpm-information-exchange-v3-04.pdfdpm...

Documents