Fahrplananmeldung in Deutschland - LDEWldew.de/bdew.nsf/id/DE_ETSO_Scheduling_System_ESS/$file/ESS... · Fahrplananmeldung in Deutschland mit Hilfe des ETSO Scheduling System (ESS)

Fahrplananmeldung in Deutschland

mit Hilfe des

ETSO Scheduling System (ESS)

Version: 1 Release: 0 Datum: 06.08.2003

2 ESS: Fahrplanabwicklung in Deutschland

Version: 1Release: 0

EnBW-Transportnetze AG Systemführung Jörg Wozny Datum: 06.08.2003

Änderungshistorie

Version Datum 0.3 25.06.2003 Entwurf Woz 1.0 06.08.2003 Veröffentlichung Woz

ESS: Fahrplanabwicklung in Deutschland 3

Version: 1 / Release: 0 Datum: 06.08.2003

Inhalt: 1. Einleitung ..................................................................................................................................4

1.1. Hinweise zu den verwendeten Schriften ............................................................................4 1.2. Begriffsdefinition der zeitlichen Fristen ..............................................................................4

2. Formatgegenüberstellung........................................................................................................5 3. Geschäftsvorfälle......................................................................................................................7

3.1. Regelzonenüberschreitende Geschäfte.............................................................................8 3.2. Regelzoneninterne Geschäfte ...........................................................................................9 3.2.1. Geschäfte zwischen Bilanzkreisen innerhalb einer Regelzone ..........................................9 3.3. Prognosefahrpläne für Erzeugung und Verbrauch von Energie innerhalb einer Regelzone9 3.3.1. Erzeugungsprognose ........................................................................................................9 3.3.2. Verbrauchsprognose .......................................................................................................10 3.3.3. Behandlung von „Not Used“-Feldern ...............................................................................10

4. Der ESS Datenaustauschprozess im deutschen Marktmodell ............................................11 4.1. Acknowledgement-Message und Eingangsprüfung .........................................................11 4.2. Anomaly-Message...........................................................................................................12 4.2.1. Regelzoneninterne Handelsgeschäfte .............................................................................12 4.2.2. Regelzonenüberschreitende Handelsgeschäfte...............................................................13 4.3. Intermediate Confirmation Message ................................................................................14 4.4. Status Request................................................................................................................14 4.5. Final Confirmation Message ............................................................................................15

5. Vorgaben zum Ausfüllen der Formulare ...............................................................................16 5.1. Pflichteinträge..................................................................................................................16 5.2. Allgemeines.....................................................................................................................18 5.3. Angabe von Zeitwerten....................................................................................................18

6. Namenskonventionen ............................................................................................................19 6.1. Dateinamen.....................................................................................................................19 6.1.1. Fahrplananmeldungen der Händler .................................................................................19 6.1.2. Rückmeldungen der ÜNB................................................................................................19 6.2. Message Identification.....................................................................................................20 6.2.1. Message Identification in den Fahrplananmeldungen der Händler...................................20 6.2.2. Message Identification bei Rückmeldungen der ÜNB ......................................................20 6.3. Time-Series Identification ................................................................................................20 6.3.1. Time-Series Identification in den Fahrplananmeldungen der Händler ..............................20 6.3.2. Time-Series Identification bei Rückmeldungen der ÜNB..................................................20

7. Glossar ....................................................................................................................................22 8. Literatur...................................................................................................................................23

8.1. Verwendete Literatur .......................................................................................................23 Anhang A.Liste der Eingangsprüfungen ...................................................................................24



1. Einleitung Mit fortschreitender Liberalisierung der Strommärkte in Europa und der steigenden Anzahl an Trans-aktionen und Akteuren sollen die operativen Voraussetzungen für den grenzüberschreitenden Strom-austausch weiter verbessert werden. Insbesondere sind die Datenformate und Bezeichnungen der Marktteilnehmer auf europäischer Ebene zu vereinheitlichen, damit ein reibungsloser internationaler Informations- und Datenaustausch auf elektronischem Wege erfolgen kann. Dazu wurde im Rahmen der Vereinigung der europäischen Übertragungsnetzbetreiber ETSO die Task Force „EDI“ (14) beauftragt, ein neues europaweit einheitliches Fahrplanformat, das so genan-nte ESS (ETSO Scheduling System) [4], zu entwickeln. Zum 01.Juli 2003 wird dieses Fahrplanformat in den Ländern Deutschland, Schweiz und Luxemburg für den operativen Gebrauch freigegeben. In Österreich wird das ESS ab dem 2.12.2003 eingeführt. Dadurch soll nach einer Übergangszeit das bisherige KISS-Format abgelöst werden. Das ESS definiert nicht nur das Nachrichtenformat für die Datenübermittlung, sondern beschreibt zu-dem den Datenaustauschprozess der für die Abwicklung des Energieverkehrs in Europa notwendig ist. - Kapitel 2 stellt an einem Beispiel die Formate „KISS“ und „ESS“ gegenüber. - Im Kapitel 3 wird erläutert, wie der Energieverkehr nach den Vorschriften der VV2 plus [1] und des

TransmissionCodes [2] im ESS abzubilden ist. - Das Kapitel 4 stellt den auf das deutsche Marktmodell abgebildeten ESS-Datenaustauschprozess

dar. - Kapitel 5 listet die Vorgaben für das deutsche Marktmodell auf. - Kapitel 6 gibt Hinweise für Dateinamen- und ID-Konventionen. - Kapitel 7 ist ein Glossar und erläutert die wichtigsten Begriffe. - In Kapitel 8 sind die verwendete Literatur und weiterführende Internetadressen aufgelistet.

1.1. Hinweise zu den verwendeten Schriften • Beispiele werden Kursiv dargestellt. • Dateinamen und ID-Konventionen sind in Courier dargestellt. • Pflichteinträge bzw. Einschränkungen innerhalb der Schedule Message sind in Old Style Fett

angegeben.

1.2. Begriffsdefinition der zeitlichen Fristen Innerhalb dieses Dokuments werden Begriffe benutzt, die sich auf die zeitli-chen Fristen für die Fahrplanabgabe und die daraus resultierenden Bear-beitungsschritte beziehen. Die Abb. 1 gibt dazu eine Übersicht.

Abb. 1: Begriffsdefinition der zeitlichen Fristen bei der Fahrplanab-gabe

Apr il 2003ESS - Fahrplananmeldung in Deutschland 1EnBW TNG B-FÜJörg Wozny

Begr iffsdefinition der zeitl ichen Fr isten bei der Fahrplanab-gabe

14:30

15:30

16:00

Erfüllungstag desFahrplans

„d“

Vor tag

„d-1“

„nächster“Arbeitstag

„d+1“

Weitere Bezeichnungen:Aktueller Tag

Aus Sicht des Vortages:Allgemein:

Folgetag



2. Formatgegenüberstellung Mit der Einführung eines auf XML basierenden Datenformates [4] ändert sich im Vergleich zu dem bisher verwendeten „KISS“-Format das Format der Nachricht. Der Dateninhalt hingegen, der ausgetauscht wird, bleibt im Wesentlichen gleich. Um dies zu verdeutlichen, wird in diesem Kapitel ein Energiegeschäft im „KISS“-Format und im XML-Format gegenübergestellt.1 Für die Gegenüberstellung der Formate wird folgendes Beispiel angenommen:

Beispiel 1: Der Händler ATOZ liefert am 02.07.2003 von 0:00 bis 24:00 Uhr 100,123 MW aus der Regelzone EnBW in die Regelzone RWE.

Eine Fahrplandatei im KISS-Format (Abb. 2, rechts) setzt sich aus den drei folgenden Ta-bellenblättern zusammen:

�� Info �� Extern �� Intern

Eine ESS Schedule Message (Abb. 2, links) besteht aus den Elementen:

�� Message Header �� Time Series Header �� Period und Interval Level

Der Message Header entspricht dabei dem Info-Blatt des KISS, mit zusätzlichen Informationen. Der Time Series Header ent-spricht dem Adressbereich einer

Abb. 2: Aufbau der Nachrichten

April 2003ESS - Fahrplananmeldung in Deutschland 2EnBW TNG B-FÜJörg Wozny

ESS Schedule Message bzw. KISS-FahrplanAufbau der Nachr ichten

MessageHeader

Time SeriesHeader

Interval

0..N

Period

1

1..N

Datum

Adress-bereich

Werte-bereich

Kommen-tarbereich

Datenspalte. In diesem Bereich kann ebenfalls ein Kommentar eingegeben werden. Der Period und der Interval-Level entsprechen dem Wertebereich und der Zeitangabe einer Da-tenspalte des KISS-Formates. In der Abb. 3 sind die Details des Message Hea-ders der Schedule Message dargestellt. Die Einträge im gelben Bereich entsprechen den Angaben aus dem Beispiel 1:

Der Händler ATOZ (Sender Id) sendet eine Fahrplandatei (Message type) für das Da-tum 02.07.2003 (Schedule Time intervall) an den Empfänger EnBW TNG (Receiver Id).

Abb. 3: ESS Schedule Message: „Message Header“


ESS Schedule MessageMessage Header

Coding scheme

Reciver role

Sender role

Message date and time

Coding schemeReciver Id

Message identification

Schedule classification type

Message version

Sender Id

Process typeMessage type

Schedule time interval

A01

A04

A01

2003-07-01T09:00:00Z

A01

10XDE-ENBW--TNGX

ATOZ-20030707-001

A01

1

99XATOZ--------O

A01

A01

2003-07-01T22:00Z/2003-07-02T22:00Z

MessageHeader

Time SeriesHeader

Interval

0..N

Period

1

1..N

Diese Informationen sind im KISS-Format ebenfalls vorhanden, nur eben an unterschiedlichen Stellen innerhalb der Datei und nicht so systematisiert wie im Message Header.

1 An dieser Stelle werden die Einträge für das Beispiel nicht näher erläutert, um den Änderungsaufwand bei späteren An-passungen geringer zu halten. Die Erläuterung zu den Einträgen erfolgt in den folgenden Kapiteln.



Im Bereich des Message Headers und des Time Serie Headers gibt es eine Information, die in dieser Form innerhalb einer KISS-Datei nicht vorhanden ist. Dies ist die „Message Identification“ bzw. die „Time Series Identification“. Weitere Informationen dazu sind in den Kap. 5.1, 6.2 und 6.3 angegeben. In der Abb. 4 ist der Time Series Header, der „Kopf“ eines Fahrplangeschäftes, dargestellt. Hier wird der „Adressbereich“ des KISS-Formats abgebildet. Die Einträge im gelben Bereich entsprechen den Angaben aus dem Beispiel 1:

Der Händler ATOZ gibt einen externen Fahrplan (Business Type) ab. Die Energie wird aus der Regelzone EnBW (Out Area) in die Regelzone RWE (In Area) geliefert. Da im deutschen Marktmodell für einen ex-ternen Fahrplan die 1:1 Nominierung gilt, müssen die Angaben in den Feldern In Par-ty und Out Party gleich sein.

Abb. 4: ESS Schedule Message: „Time Series Header“


ESS Schedule MessageTime Ser ies Header

Coding scheme

Capacity contract type

Measurenent unit

Capacity agreement identification

Time Series identification

Object aggegation

Time Series version

In Area

Product

Business type

A01

<Empty>

MAW

<Empty>

r10YDE-ENBW-----Nss

A01

1

10YDE-RWENET---I

8716867000016

A06

Coding scheme

Out Area

A01

10YDE-ENBW-----N

Coding scheme

Metering point identification

<Empty>

<Empty>

Coding scheme

In Party

A01

99XATOZ--------O

Coding scheme

Out Party

A01

99XATOZ--------O

MessageHeader

Time SeriesHeader

Interval

0..N

Period

1

1..N

Die Elemente mit der Kennung <Empty> dürfen nicht in der Nachricht aufgeführt werden, da ein leeres Element eine Verletzung der DTD bedeu-tet. Im Period Level (Abb. 5) wird der Zeitbereich an-gegeben, für den der Fahrplan gültig sein soll (Time interval) und welches Zeitraster (Resoluti-on) verwendet wird. Die Einträge im gelben Bereich entsprechen den Angaben aus dem Beispiel 1:

Der Fahrplan ist für den Tag 02.07.2003 (Time interval) bestimmt, und es werden ¼-h Werte angegeben (Resolution).

Abb. 5: ESS Schedule Message: „Period Level“


ESS Schedule MessagePer iod

Resolution

Time interval

PT15M

2003-07-01T22:00Z/2003-07-02T22:00Z

MessageHeader

Time SeriesHeader

Interval

0..N

Period

1

1..N

Im Interval Level (Abb. 6) werden die Daten aus dem Wertebereich des KISS-Formats eingetra-gen. Dabei wird für jeden Wert eine Position (Pos) und eine Menge (Qty) angegeben. Die Einträge im gelben Bereich entsprechen den Angaben aus dem Beispiel 1:

Der Fahrplan ist für einen „normalen“ Tag bestimmt. Anhand der Resolution aus dem Period Level ergibt sich, dass 96 Einträge erwartet werden. Die Menge (Qty) beträgt für den gesamten Tag 100,123 MW.

Abb. 6: ESS Schedule Message: „Interval Level“


ESS Schedule MessageInterval

Pos 2

Qty 100.123

Pos 1

Qty 100.123

Pos 96

Qty 100.123

...

MessageHeader

Time SeriesHeader

Interval

0..N

Period

1

1..N



3. Geschäftsvorfälle In jeder der Regelzonen im Re-gelblock Deutschland kann es beliebig viele Bilanzkreise ge-ben, die miteinander Geschäfte tätigen können (Abb. 7). Die dabei entstehenden Ge-schäftsvorfälle können in zwei Arten, regelzoneninterne und -überschreitende Geschäfte, un-terschieden werden. Beide Arten werden jeweils noch in Untergruppen aufgeteilt (Tab. 1). Alle diese Geschäfte werden über „Fahrpläne“ bei den jewei-ligen ÜNB, die von diesen Ge-schäften tangiert sind, angemel-det. Dabei ist in den Fahrplänen nur jeweils der Saldo der Geschäfte anzugeben.

Abb. 7: Mögliche Geschäftsvorfälle


Händler CHändler BHändler A

RWE

ENBW

Ausland(Frankreich)


VE

(4)

(2)

Händler A

Händler B

Händler C

Mögliche Geschäftsvor fäl leÜbersicht

(1)

(1)

(1)(1)Händler CHändler BHändler A

RTE


EON(3)

Zusätzlich zu den Fahrplänen, die aus den oben genannten Geschäftsvorfällen resultieren, werden in einigen Fällen detailliertere Fahrpläne für z.B. Abrechnungszwecke benötigt. Tab. 1: Arten von Geschäftsvorfällen A) Externe

1) Regelzonenüberschreitende Geschäfte innerhalb Deutschlands und staatsgrenzenüberschrei-tende Geschäfte

B) Interne 2) Geschäfte zwischen Bilanzkreisen innerhalb einer Regelzone 3) Erzeugungsprognose 4) Verbrauchsprognose

Im folgenden werden die zuvor benannten Geschäftsvorfälle näher erläutert und die hierfür notwendi-gen Fahrpläne benannt. Siehe dazu auch [2]; S. 20f Anmerkung:

Für die Beispiele und Bilder in diesem Kapitel werden keine EIC Bezeichnungen verwendet, da diese für die Darstellung in den Bildern zu lang sind.



3.1. Regelzonenüberschreitende Geschäfte Abb. 8: Verbindungen zu ausländischen Regelzonen


SchweizSchweiz

FrankreichFrankreich

NiederlandeNiederlande PolenPolen

TschechienTschechien

ÖsterreichÖsterreich

DänemarkDänemark

BelgienBelgien DeutschlandDeutschland

EDF

ELT-RA

Ten-neT

APG

CEPS

PSE

EGL

NOK

KWB

ATELBKWEOS

CPTE

Verbindungen zu ausländischen Regelzonen

EON

VE

RWE

ENBW

TIRAGVKW

Tab. 2: Kuppelstellen zu ausländischen Regelzonen EnBW Frankreich, Österreich1, Schweiz RWE Niederlande, Frankreich, Österreich1, Schweiz Eon Dänemark, Niederlande, Österreich1, Tschechien VET Polen, Tschechien

1 Die Regelzone VKW ist nur über die Regelzone EnBW anzusprechen.

Bei der Anmeldung von Regel-zonenüberschreitenden Gesch-äften können nicht immer alle anderen Regelzonen angespro-chen werden. Es wird daher zwischen dem in-nerdeutschen und dem staats-grenzenüberschreitenden Ener-gieverkehr unterschieden. Im innerdeutschen Energiever-kehr ist es möglich, alle deut-schen ÜNB direkt anzuspre-chen. Für den staatsgrenzenübersch-reitenden Energieverkehr muss eine Fahrplananmeldung in der deutschen Regelzone erfolgen, die eine direkte Kuppelstelle zu dem betreffenden ausländisch-en Partner hat. (Abb. 8) Zur Zeit gibt es von den deut-schen ÜNB aus die in Tab. 2 aufgelisteten Verbindungen zu ausländischen ÜNB. Generell dürfen regelzonen- und staatsgrenzenüberschreitende Geschäfte nur zwischen den Bi-lanzkreisen des gleichen Bilanz-kreisverantwortlichen (BKV) ab-gewickelt werden. (1:1 Nominie-rung) Dieser BKV meldet den Fahr-plan immer bei beiden beteilig-ten Regelzonen an. In der Abb. 9 ist ein Ausschnitt aus einer regelzonenüberschrei-tenden Fahrplananmeldung in-nerhalb Deutschlands des Händlers B in der Regelzone EnBW dargestellt. Wie schon gesagt, dürfen dabei staatsgrenzenüberschreitende Geschäfte nur in der Regelzone angemeldet werden, die eine Kuppelstelle zu dem betreffen-den ausländischen Partner hat. (siehe dazu auch Abb. 8 bzw. Tab. 2)

Abb. 9: Regelzonen- oder staatsgrenzenüberschreitende Energiegeschäf-te



RWE

ENBW

Händler A

Händler B

Händler C

Mögliche Geschäftsvor fäl leRegelzonen- oder Staatsgrenzenüberschreitende Energiegeschäfte

(1)


RTE


EON

Schedule Document

Out Area:In Area:Out Party:In Party:

Y-ENBWY-RWEHändler BHändler B

Business Type A06Schedule Time Series

Sender ID: Händler BSchedule Message

Receiver ID: X-ENBW(1)

Ausland(Frankreich)



3.2. Regelzoneninterne Geschäfte

3.2.1. Geschäfte zwischen Bilanzkreisen innerhalb einer Regelzone Innerhalb einer Regelzone sind Fahrplangeschäfte zwischen al-len in der jeweiligen Regelzone angemeldeten Bilanzkreisen möglich. Dem ÜNB wird ebenfalls nur der Saldo dieser Geschäfte gemel-det. Die Fahrplananmeldung muss immer von beiden beteiligten Bi-lanzkreisen erfolgen. In der Abb. 10 ist ein Ausschnitt aus der Fahrplananmeldung des Händlers A dargestellt. Der Händler B muss eine ent-sprechende Fahrplananmeldung versenden.

Abb. 10: Geschäfte zwischen Bilanzkreisen innerhalb einer Regelzone



RWE

ENBW

(2)

Händler A

Händler B

Händler C

Mögliche Geschäftsvor fäl leGeschäfte zwischen Bilanzkreisen innerhalb einer Regelzone


RTE


EON

Schedule Document


Y-ENBWY-ENBWHändler AHändler B


Sender ID: Händler ASchedule Message

Receiver ID: X-ENBW

Ausland(Frankreich)

3.3. Prognosefahrpläne für Erzeugung und Verbrauch von Energie innerhalb einer Regelzone Im Gegensatz zu den bisher vorgestellten Fahrplänen müssen bei den Prognosefahrplänen für Er-zeugung bzw. Verbrauch nicht alle Felder im Schedule Time Series Level ausgefüllt werden. (siehe dazu in Abb. 11 bzw. Abb. 12 die freien Felder in den „Schedule Time Series“) Es gibt in diesem Fall so genannte „Not Used“-Felder. Das heißt aber nicht, dass in diesen Feldern keine Eingaben getätigt werden dürfen. Siehe dazu auch das Kap. 3.3.3 Behandlung von „Not Used“-Feldern.

3.3.1. Erzeugungsprognose Laut [1] (Anlage 2, Kap. 2.2.) sind die Marktteilnehmer ver-pflichtet einen unverbindlichen Summenfahrplan (Erzeugungs-prognose) für alle, dem jeweili-gen Bilanzkreis zugeordneten, Erzeugungseinheiten an den jeweiligen ÜNB zu senden. Im ESS gibt es hierfür den spe-ziellen Business Type „A01“. (siehe Abb. 11) Unter dieser Kennung kann die Erzeugungsprognose des Händ-lers abgegeben werden.

Abb. 11: Erzeugungsprognose innerhalb einer Regelzone (Production)

August 2003ESS - Fahrplananmeldung in Deutschland 11EnBW TNG B-FÜJörg Wozny


RWE

ENBW

(3)

Händler A

Händler B

Händler C

Mögliche Geschäftsvor fäl leErzeugungsprognose


RTE


EON

Schedule Document


Y-ENBW

Händler C


Sender ID: Händler CSchedule Message

Receiver ID: X-ENBW

Ausland(Frankreich)



3.3.2. Verbrauchsprognose Die ÜNB empfehlen, zusätzlich einen Fahrplan mit einer Ver-brauchsprognose innerhalb ei-ner Regelzone ebenfalls in die tägliche Anmeldung mit einzu-beziehen. Mit diesem Verfahren ist eine Kontrolle dahingehend möglich, ob das angemeldete Portfolio ausgeglichen ist. Im ESS gibt es hierfür den spe-ziellen Business Type „A04“. (siehe Abb. 12) Unter dieser Kennung kann die Verbrauchsprognose des Händ-lers abgegeben werden.

Abb. 12: Verbrauchsprognose innerhalb einer Regelzone (Consumption)

Apr il 2003ESS - Fahrplananmeldung in Deutschland 12EnBW TNG B-FÜJörg Wozny


RWE

ENBW

(4)

Händler A

Händler B

Händler C

Mögliche Geschäftsvor fäl leVerbrauchsprognose


RTE


EON

Schedule Document


Y-ENBW

Händler C


Sender ID: Händler CSchedule Message

Receiver ID: X-ENBW

Ausland(Frankreich)

3.3.3. Behandlung von „Not Used“-Feldern Die freien Felder in den Business Types „A01“ bzw. „A04“ gelten als sogenannte „Not Used“ Felder, d.h. in diesen Feldern muss in diesem Fall kein Eintrag erfolgen. Korrekte Einträge in den „Not Used“ Feldern führen nicht zu einer Fehlermeldung und ein entspre-chender Fahrplan wird von den Empfängern (ÜNB) akzeptiert. Bei einem Fehler wird allerdings die gesamte Fahrplandatei zurückgewiesen.

Beispiel 2: Gegenüberstellung der Meldung einer Verbrauchsprognose einmal mit und einmal ohne ausgefüllte „Not Used“-Felder.

1. „Not Used“-Felder

nicht ausgefüllt

2. „Not Used“-Felder

ausgefüllt Business Type A04 A04

Out Area 10YDE-ENBW-----N 10YDE-ENBW-----N

In Area 10YDE-ENBW-----N

Out Party 99XATOZ--------0 99XATOZ--------0

In Party 11XFC-CONS-----0

Bei der Meldung einer Verbrauchsprognose sind die Felder „In Area“ und „In Party“ „Not Used“-Felder. Hinweis zu Anmeldungen bei VE-Transmission: Das Feld „In Party“ muss Bestandteil der Schedule Message sein.



4. Der ESS Datenaustauschprozess im deutschen Marktmodell Der Datenaustauschprozess, wie er im Implementation Guide des ESS [4] dargestellt wird, ist die Hüllkurve dessen, was in den einzelnen Ländern an Datenaustausch für die Abwicklung des Energie-verkehrs benötigt wird. Daher gibt es mehrere Möglichkeiten die einzelnen Prozessschritte durchzu-führen. Zudem können die Marktmodelle in den Ländern teilweise die Abwicklung von Prozessschrit-ten vorgeben. Aus diesem Grund muss auch für das deutsche Marktmodell eine ESS Prozessabbildung erstellt wer-den. In diesem Fall lässt sich der Prozess der Fahrplananmeldung und -abwicklung in den folgenden Teilprozessen darstellen.

4.1. Acknowledgement-Message und Eingangsprüfung Mit dem Eingang einer Schedule Message bei einem ÜNB wird dieses Message verschiedenen Prüfungen unterzogen. (Abb. 13) In einem ersten Schritt wird ge-prüft, ob die eingesandte Nach-richt eine XML-Datei ist und der gültigen DTD entspricht. Ist dies nicht der Fall, wird dem Absender eine formlose Text-meldung zurückgegeben, die auf dieses Problem hinweist. Die fehlerhafte Schedule Mes-sage wird nicht weiterbearbei-tet. Der Absender kann daraufhin eine korrigierte Schedule Mes-sage mit der gleichen Message Version nochmals versenden.

Abb. 13: Acknowledgement Message und Eingangsprüfung


ESS Workflow im deutschen Marktmodel lAcknowledgment Message / Eingangsprüfung

BKV ÜNB

Prüfung„XML-Datei“

Ergebnis derPrüfungen

Fahrplan-korrektur

Bei Fehlern

Eingangsprüfung

NeinFehlerNachr icht:„Parserfehler , Datei entspr icht nicht der

gültigen DTD“

Ja

Fahrplan-abgabe

ScheduleMessage

Wenn Prüfungen fehlerfrei-> Datenübernahme

DB-System FPL-

Management

Nein

Fehler

*) bei Fehlern mit entsprechendem Fehlerl isting

AcknowledgmentMessage *)

Ja

Entspricht die Schedule Message einer gültigen DTD, ist sie also „gültig“, kann die Eingangsprüfung der Daten durchgeführt werden. Die Eingangsprüfung umfasst dabei alle Prüfungen, für die keine Daten anderer Marktteilnehmer not-wendig sind. Als Ergebnis der Eingangsprüfung wird eine Acknowledgement Message mit einer der folgenden Kennungen an den Absender zurückgesandt.

- Eingangsprüfung fehlerfrei: Bei einem fehlerfreien Ergebnis wird der Reason Code „A01“ (Message fully accepted) zurückgegeben. Die Daten wurden in dieser Form dann in das je-weilige Datenbank-System übernommen (akzeptiert).

- Eingangsprüfung mit Fehlern: Sind bei der Eingangsprüfung hingegen Fehler aufgetreten, so wird die gesamte Nachricht mit dem Reason Code „A02“ (Message fully rejected) zurück-gewiesen. Zudem wird in der Acknowledgement Message eine Auflistung der erkannten Fehler beigefügt.

Die Acknowledgement Message als Ergebnis der Eingangsprüfung enthält lediglich eine Aussage da-hingehend, dass die Daten der übermittelten Schedule Message in dieser Form übernommen werden konnten. Es enthält keine Aussage hinsichtlich der Datengüte. Die Acknowledgement Message ist zudem die Eingangsbestätigung des Empfängers auf eine ver-sandte Schedule Message, d.h. erst nach Erhalt dieser Nachricht kann der Absender davon ausge-hen, dass die Fahrpläne bei dem Empfänger eingegangen sind.



4.2. Anomaly Report Bei dem Prozessschritt „Versand von Anomaly Reports" muss zwischen regelzoneninternen und -überschreitenden Handelsgeschäften unterschieden werden. Der Unterschied ist dabei in der Haupt-sache der Zeitpunkt, zu dem die Datenprüfung durchgeführt werden kann. Die Datenprüfungen (Verifikation) beinhalten Prüfungen, für die Daten korrespondierender Marktteil-nehmer benötigt werden.

- Bei regelzoneninternen Handelsgeschäften ist eine Prüfung nach dem Eintreffen der Daten des korrespondierenden Handelspartners möglich.

- Regelzonenüberschreitende Handelsgeschäfte können erst nach dem Anmeldeschluss ge-prüft werden.

Durch die Art des Prozessablaufes kann ein Händler möglicherweise mehrere Anomaly Reports er-halten, die neben den schon gemeldeten Unstimmigkeiten weitere erkannte Fehler auflisten.

4.2.1. Regelzoneninterne Handelsgeschäfte Nach dem Durchlaufen des Empfangsprozesses (Daten-empfang und Eingangsprüfung) erfolgt eine erste Verifizierung der eingegangenen Daten des jeweiligen BKV. D.h. es wird nach Abschluss des Empfangsprozesses geprüft, ob z.B. schon Schedule Messages anderer Handelspartner zu den angegebenen regelzoneninter-nen Geschäften vorhanden sind. In diesem Fall wird die Überein-stimmung der Daten geprüft. Die Abb. 14 stellt das Schema eines Verifizierungsprozesses am Beispiel der Händler A und B dar.

Abb. 14: Anomaly Report bei regelzoneninternen Handelsgeschäften


ESS Workflow im deutschen Marktmodel lAnomaly Report bei regelzoneninternen Handelsgeschäften

BKV A ÜNB

Ergebnis derDatenprüfung

AnomalyReport

an beide BKV

Fahrplan-korrektur durchA und / oder B

BeiFehlern

Datenprüfung„ Intern“

(„A“ mit „B“ )

FehlerJa

Nein

DB-SystemFPL-

Management

Ende

BKV B

Fahrplan-abgabe

Beispiel 3: Die Händler „A“ und „B“ haben dem ÜNB ein regelzoneninternes Geschäft gemeldet. Die Schedule Message von „A“ ist vor dem von „B“ eingetroffen.

Sobald die Schedule Message des Händlers B (Beispiel 3) eingetroffen ist, und bei dessen Eingangs-prüfung keine Fehler aufgetreten sind, kann eine Verifikationsprüfung angestoßen werden. Die Ergebnisse werden dabei wie folgt verarbeitet:

- Verifikationsprüfung ohne Befund: Werden keine Unstimmigkeiten festgestellt, wird die Prüfung ohne Meldung an die Händler beendet.

- Verifikationsprüfung mit Fehlern: Werden Unstimmigkeiten festgestellt, wird beiden betroffenen Händlern jeweils ein relevantes Anomaly-Report zugesandt, das alle - zum Versandzeitpunkt – bekannten bzw. erkannten Fehler des betroffenen Händlers enthält. Ein Fehler kann z.B. sein:

- Unstimmigkeit der Werte: Der Händler A hat ein Geschäft mit 100 MW für einen bestimmten Zeitraum angemeldet, der Händler B hat aber für den selben Zeitraum 80 MW gemeldet.

- Fehlende Gegenmeldung: Einer der beiden Händler ein Geschäft zwischen A und B angemeldet hat, der andere aber nicht.

Bei der Ergebnisausgabe ist zusätzlich der Prüfungszeitpunkt relevant:



Erst nach dem Anmeldeschluss für den Folgetag (in Deutschland 14:30 Uhr) kann im Anomaly Report ein Fehler für ein regelzoneninternes Geschäft ausgegeben werden, wenn der korres-pondierende BKV keine Fahrplandatei abgegeben hat.

4.2.2. Regelzonenüberschreitende Handelsgeschäfte Kurz nach 14:30 Uhr, dem An-meldeschluss für die Handels-fahrpläne des Folgetages (siehe auch [1], Anhang 2 Kap. 2.3), gleichen die ÜNB ihre Regelzo-nensalden ab. Die BKV werden im Anschluss über Fehler unterrichtet und müssen bis 15:30 Uhr einen der beiden, bei den ÜNB eingesand-ten, Fahrpläne durch eine korri-gierte Fahrplananmeldung bes-tätigen (siehe auch [1], Anhang 2 Kap. 2.9.1). Die Ergebnisse werden dabei wie folgt verarbeitet: - Verifikationsprüfung ohne

Befund: Werden keine Un-stimmigkeiten festgestellt, wird die Prüfung ohne Mel-dung an den Händler been-det.

Abb. 15: Anomaly Report bei regelzonenüberschreitenden Handelsge-schäften


ESS Workflow im deutschen Marktmodel lAnomaly Report bei regelzonenüberschreitenden Handelsgeschäften

BKV ÜNB


AnomalyRepor t

Fahrplan-korrektur

CAS-Datei(en)

DB-SystemFPL-

ManagementDatenprüfung

14:30

Fahrplan-abgabe

FehlerJa

Nein

Ende

- Verifikationsprüfung mit Fehlern: Werden Unstimmigkeiten festgestellt, wird dem betrof-fenen Händler ein Anomaly Report zugesandt, das alle - zum Versandzeitpunkt - bekannten bzw. erkannten Fehler enthält, d.h. es werden hier auch noch bestehende regelzoneninter-ne Fehler aufgelistet.

Nach dem erfolgreichen Abgleich (nach Beseitigung aller Diskrepanzen in den regelzonenüberschrei-tenden Anmeldungen) erhalten die BKV einen Intermediate Confirmation Report.



4.3. Intermediate Confirmation Report Da sich Fahrpläne am aktuellen Tag ändern können, kann der ÜNB am Vortag und auch am aktuellen Tag nur ein Intermedi-ate (vorläufigen) Confirmation Report versenden. Zu diesem Zeitpunkt existierende Diskre-panzen hinsichtlich der Gegen-anmeldung werden, sofern sie nicht einer Anpassung durch den ÜNB unterworfen wurden, über einen zusätzlichen Anoma-ly Report dem BKV mitgeteilt. Der Workflow ist in Abb. 16 dar-gestellt.

Abb. 16: Intermediate Confirmation Report


ESS Workflow im deutschen Marktmodel lIntermediate Confirmation Repor t

BKV ÜNB


AnomalyRepor t

Fahrplan-korrektur

BeiFehlern

IntermediateConfirmation

Repor t

DB-SystemFPL-

Management

*) wenn RZ abgestimmt

Datenprüfung15:30 *)

Fahrplan-abgabe

BeiFehlern

4.4. Status Request Da ein Anomaly Report nur dann versandt wird, wenn bei einem Fahrplan ein Fehler hin-sichtlich einer Gegenanmeldung erkannt wurde, erhält der Ab-sender nur „negative“ Meldun-gen, d.h. wenn alle Daten kor-rekt sind, erhält der BKV nach der Acknowledgement Message einen „Intermediate Confirmati-on Report“. Der Absender einer Fahrplanda-tei kann daher vor dem Emp-fang eines Confirmation Reports nicht mit 100%-iger Sicherheit davon ausgehen, dass seine Daten korrekt sind, wenn er kei-ne Fehlermeldungen erhält.

Abb. 17: Status Request


ESS Workflow im deutschen MarktmodellStatus Request

BKV ÜNB

Trigger zurPrüfung


Datenprüfung

Trigger-empfang

StatusRequest

Fahrplan-korrektur

Bei Fehlern

stößt an

DB-SystemFPL-

Management

Fahrplan-abgabe

AnomalyReport

BeiFehlern

IntermediateConfirmation

Report

Daher wurde mit dem „Status-Request“ eine Möglichkeit geschaffen, mit der ein BKV den Versand bestimmter Reports durch Senden eines „Status Request“ an den ÜNB selbst auslösen kann, um ei-nen aktuellen Status seiner Anmeldung bei dem jeweiligen ÜNB zu erhalten. Nach dem Eingang eines „Status Requests“ wird eine Verifikationsprüfung der bereits vorhandenen Daten des BKV durchgeführt. An die im System hinterlegte Kommunikationsadresse des Händlers wird dann ein Intermediate Con-firmation Report und ggf. ein Anomaly Report versandt. Basis dieser Reports sind die Daten, die zum Eingangszeitpunkt des Status Request beim ÜNB in der Datenbank abgelegt sind. Bei der Ergebnisausgabe des Status Request ist zusätzlich der Prüfungszeitpunkt relevant:



Erst nach dem Anmeldeschluss für den Folgetag (in Deutschland 14:30 Uhr) kann im Anomaly Report ein Fehler für ein regelzoneninternes Geschäft ausgegeben werden, wenn der korrespon-dierende BKV keine Fahrplandatei abgegeben hat. Vor diesem Zeitpunkt wird dieses Geschäft im Confirmation Report mit einem Status „Unbestätigt“ geführt.

4.5. Final Confirmation Report Laut der VV II+ dürfen regelzo-neninterne Fahrpläne bis zum nächsten Arbeitstag 16:00 Uhr auch noch rückwirkend geändert werden. (siehe dazu auch [1] Anhang 2 Kap. 2.8) Daher kann ein Final Confirma-tion Report erst nach diesem Zeitpunkt versandt werden. Der Report enthält die Daten, die von Seiten des Fahrplansys-tems der Bilanzkreisabrechnung übergeben wurden.

Abb. 18: Final Confirmation Report


BKV ÜNB

Ergebnis derDatenanalyse

Bestimmung derAbweichungen

Fahrplan-analyse

FinalConfirmation

Report

DB-SystemFPL-

Management

Information überAbweichungen bzw.

Fahrplanbestätigungen

DB-SystemAbrechnung

Fehler

Weitergabeder Daten

Ja

Nein

ESS Workflow im deutschen MarktmodellFinal Confirmation Report



5. Vorgaben zum Ausfüllen der Formulare

5.1. Pflichteinträge Eine Schedule Message eines Fahrplantyps muss die vollständigen Daten aller Fahrpläne (Time Ser-ies) für einen Kalendertag enthalten. Folgende Einträge sind in der Schedule Message vorzunehmen: a) Message identification: Sie ist durch den Bilanzkreisverantwortlichen im Rahmen der Vorgaben

gemäß [4] frei wählbar. Durch die Message identification sind die Fahrplananmeldung(en) bzw. Transitanmeldung(en) für einen Kalendertag bei einem ÜNB eindeutig durch den BKV definiert. Das bedeutet, dass je Kalendertag, Fahrplantyp (Fahrplananmeldung oder Anmeldung von Tran-sitfahrplänen) und Empfänger seitens des Absenders eine eineindeutige Message identification vergeben werden muss.

b) Message version: Die Versionierung hat ge-mäß [4] Kap. 4.2.2.1.1 zu erfolgen. (siehe auch: Abb. 19)

c) Message type: Für die Fahrplananmeldung sowie für die Anmeldung der Transitfahrpläne ist „A01“ einzutragen.

d) Process type: Für Fahrplananmeldungen ist hier die Kennung „A01“ einzutragen. Für die CBT-Transitfahrpläne ist die Kennung „A03“ einzutragen.

e) Schedule classification type: Für die Fahr-plananmeldung sowie für die Anmeldung der Transitfahrpläne ist „A01“ einzutragen.

f) Sender identification – Coding scheme:

Abb. 19: Versionierung


Vergabe von Versionsnummern

� Die Versionsnummer beginnt für jeden Tag neu bei 1.

� Sie wird als Message Version und als Time Ser ies Versiongeführt

� Bei jeder Änderung wird die Message Version um 1 hoch-gezähl t und die geänder ten oder neuen Time Ser ies mit dieserneuen Nummer gekennzeichnet.

� Beispiel :Versions Nr

Datei Geschäft A Geschäft B Geschäft CErstanmeldung 01 1 1 Nicht vorhanden

Geschäft B ändert sich 02 1 2 Nicht vorhanden

Geschäft A ändert sich 03 3 2 Nicht vorhanden

Neues Geschäft C 04 3 2 4

Die in [4] genannte Code Liste „Coding Scheme“ (UID ET0004) wird auf den Wert „A01“ be-schränkt, somit ist nur die EIC-Bezeichnung für den Absender zulässig und zu verwenden.

g) Sender role: Für Bilanzkreisverantwortliche als Absender der Fahrplananmeldung ist gemäß [4], Code List (UID ET 00005) die Kennung „A01“ anzugeben.

h) Receiver identification – Coding scheme: Die in [4] genannte Code Liste „Coding Scheme“ (UID ET0004) wird auf den Wert „A01“ beschränkt, somit ist nur die EIC-Bezeichnung des Emp-fängers zulässig und zu verwenden. Als Receiver identification für den ÜNB ist der jeweilige EIC „10X.....“ zu verwenden (siehe www.edi.etso-net.org) und nicht den EIC Area Code „10Y...“ aus den In/Out Einträgen!

i) Receiver role: Für den ÜNB als Adressat der Fahrplananmeldung ist gemäß [4] aus der Code List (UID ET 00005) die Kennung „A04“ zu verwenden.

j) Message date and time: Datum und Uhrzeit der Übermittlung der Fahrplananmeldung an den ÜNB. Die Angabe der Uhrzeit hat in UTC-Zeit zu erfolgen (Format s. [4], Kap. 4.3.10)

k) Schedule time interval: Es sind der Anfangszeitpunkt sowie der Endzeitpunkt des Tages, für den die Fahrplananmeldung übermittelt wird, in UTC-Zeit gemäß [4], Kap. 4.3.11 anzugeben.

Beispiel 4: Die Angabe der Fahrplananmeldung für den 01.07.2003 lautet 2003-06-30T22:00Z/2003-07-01T22:00Z

l) Senders time Series identification: Sie sind durch den Bilanzkreisverantwortlichen im Rahmen der Vorgaben gemäß [4], Kap. 4.4.1 frei wählbar.

m) Senders time Series version: Die Versionierung hat gemäß [4] Kap. 4.4.2.1.1 zu erfolgen. (Sie-he auch Abb. 19)



n) Business type: Im Rahmen der Fahrplananmeldung sind folgende Kennungen zu verwenden: Tab. 3: Business Types Code Beschreibung A01 Produktion (Prognose) in der Regelzone, bisher: FC_PROD A02 Fahrpläne, die bisher auf dem Blatt „Intern“ aufgeführt waren. A03* Fahrpläne, die bisher auf dem Blatt „Extern“ aufgeführt waren und über einen auktionierten

Netz-Engpass abgewickelt werden. (Richtungsbezogen) A04 Verbrauch (Prognose) in der Regelzone, bisher: FC_CONS A05 Wird zwischen Händler und ÜNB nicht verwendet A06 Fahrpläne, die bisher auf dem Blatt „Extern“ aufgeführt waren und nicht über einen auktionier-

ten Netz-Engpass abgewickelt werden (Richtungsbezogen). A07 Wird zwischen Händler und ÜNB nicht verwendet A08 Wird zwischen Händler und ÜNB nicht verwendet *) Da derzeit Auktionierungen von Netz-Engpässen nicht vollständig über ESS abgewickelt werden können, ist an Stelle des Business-Type A03 der Typ A06 zu verwenden.

o) Product: Da die Zeitreihen ausschließlich Viertelstundenleistungswerte enthalten, ist ausschließ-lich der xml-Code für Wirkleistung („8716867000016“) zu verwenden.

p) Object aggregation: Als Eintrag ist ausschließlich „A01“ zu verwenden. q) Metering point identification: An dieser Stelle erfolgt kein Eintrag. r) In area; Out area; In party; Out party: Entspricht den Einträgen des KISS-Formates „an Regel-

zone“; „aus Regelzone“; „nach Bilanzkreis“ „von Bilanzkreis“. Es sind ausschließlich Einträge ge-mäß EIC vorzunehmen.

s) Capacity contract type: Da im Regelblock Deutschland der Business Type „A03“ zur Zeit nicht verwendet wird, gibt es keinen Eintrag für dieses Element. Es darf demzufolge im Rahmen der Schedule Message nicht aufgeführt werden.

t) Capacity agreement identification: Da im Regelblock Deutschland der Business Type „A03“ zur Zeit nicht verwendet wird, gibt es keinen Eintrag für dieses Element. Es darf demzufolge im Rah-men der Schedule Message nicht aufgeführt werden.

u) Measurement unit: Da alle Werte der Time Series in MW anzugeben sind, ist als notwendige Angabe gemäß der ESS Code List (UID ET0011) nur „MAW“ zulässig.

v) Period/Time Interval: Der Eintrag für Time Interval, der für jede Time Serie vorzunehmen ist, muss dem Inhalt und der Form nach der Angabe zum Schedule Time Interval entsprechen.

w) Period/Resolution: Die Time Series bestehen ausschließlich aus Viertelstundenwerten. Als Ein-trag ist gemäß [4], Kap. 4.6.2 nur der Eintrag “PT15M“ zulässig.

x) Interval/Pos: Für jeden Viertelstundenwert ist bezüglich seines ¼-h-Zeitintervalles die Stelle an-zugeben, an der das betreffende ¼-h-Zeitintervall in der zeitlichen Abfolge der Viertelstunden auf-tritt. Da immer die Viertelstundenwerte für einen Kalendertag (bezogen auf die Ortszeit) übermit-telt werden, müssen Werte für die Positionen 1 bis 96 (an Tagen mit Zeitumstellung für 92 bzw. 100 Positionen) angegeben werden. Jede Position muss je Time Serie genau einmal vorhanden sein.

Beispiel 5: Der Wert für die Viertelstunde 3.00 Uhr bis 3.15 Uhr Ortszeit (UTC-Zeit im Sommerhalbjahr 1.00 Uhr bis 1.15 Uhr) hat die Position 13.

y) Interval/Qty: Hier erfolgt der Eintrag des Wertes für die entsprechende Position (Viertelstunde). Es sind maximal 3 Nachkommastellen möglich. Damit ist die kleinste Leistungseinheit, die im Fahrplanverkehr abgewickelt werden kann, 1 kW. Die Nachkommastellen sind nicht durch ein Komma, sondern durch einen Punkt abzutrennen. Tausendertrennzeichen sind nicht zulässig. Es muss für alle ¼-h-Zeitintervalle (Interval-Position) des betreffenden Tages ein Wert in Form einer Zahl >=0 übermittelt werden.

Beispiel 6: Der Wert für 3500043 kW ist als „3500.043“ einzutragen.



5.2. Allgemeines

Bei der Bildung bzw. Zusammenstellung der Time Series für die Anmeldung bei den ÜNB gelten des weiteren folgende Grundsätze: Netting: Es sind „genettete“ d.h. saldierte Time-Series ohne Vorzeichen abzugeben.

Bei allen anzugebenden Fahrplänen handelt es sich um genau einen Saldofahrplan: Die Richtung wird nicht durch ein Vorzeichen definiert, sondern durch die Angaben: „In Area“, „Out Area“, „In Party“, „Out Party“. Existieren in einem Saldo beide Richtungen, so wird für jede Richtung eine Time Serie gemeldet. Für ein ¼-h-Zeitintervall (Interval-Position) kann nur einer dieser beiden Fahrpläne von Null ver-schieden sein.

Informationsumfang bei Änderungen: Der Informationsgehalt einer vom ÜNB akzeptierten Fahr-plananmeldung (Schedule Message) darf sich bei einer Änderung oder der Stornierung nicht ver-ringern. Alle bereits beim ÜNB eingereichten und akzeptierten Time Series müssen bei weiteren Fahrplananmeldungen für den betreffenden Tag vollständig enthalten sein.

Stornierung von Zeitreihen: Wurde für einen Tag eine Zeitreihe eingereicht und soll diese storniert werden, dann müssen alle Werte auf „0“ geändert und bis zum Ende des betreffenden Tages mit-geführt werden.

Fahrplananmeldungen an Auslandgrenzen: Für Fahrplananmeldungen an Auslandgrenzen gelten die jeweiligen bilateralen Regelungen.

Dateinamenskonvention: Für das Versenden von Schedule Messages wird ein eindeutiger Datei-name gemäß Kap. 6 empfohlen. Rückmeldungen der deutschen ÜNB erfolgen grundsätzlich nach den Konventionen gemäß Kap. 6.

5.3. Angabe von Zeitwerten Wie oben schon gesagt, müs-sen die Start- und Endzeiten ei-nes Fahrplans im UTC-Zeitfor-mat angegeben werden. (siehe im Kap. 5.1 die Punkte k) und v)) Die UTC-Zeit unterscheidet sich von der MEZ (Mitteleuropäische Zeit) dahingehend, dass sie sich auf die Greenwich Time bezieht. Die Abb. 20 stellt die Angabe der UTC-Zeit für einen Kalen-dertag in den unterschiedlichen Zeitbereichen (Winterzeit, Som-merzeit, sowie die Tage der Zeitumstellung) dar.

Abb. 20: Angabe von Zeitwerten


Winterzeit Sommerzeit Winterzeit

Schedule Time IntervalStar t- und Endzeit eines Fahrplans im UTC-Format

Jan MrzFeb Apr JunMai Jul SepAug Okt DezNov

Zeitumstellung:Winter -> Sommerzeit

2003-03-29T23:00Z/2003-03-30T22:00Z

2003-04-01T22:00Z/2003-04-02T22:00Z

2003-01-01T23:00Z/2003-01-02T23:00Z

2003-11-01T23:00Z/2003-11-02T23:00Z

Zeitumstellung:Sommer -> Winterzeit2003-10-25T22:00Z/2003-10-26T23:00Z

02.01.200300:00 - 24:00 Uhr

02.04.200300:00 - 24:00 Uhr

02.11.200300:00 - 24:00 Uhr

96 1/4-h-Werte 96 1/4-h-Werte 96 1/4-h-Werte

92 1/4-h-Werte 100 1/4-h-Werte



6. Namenskonventionen Der Austausch von Fahrplandaten erfolgt über elektronische Medien. Es ist vorstellbar, dass in Zukunft ein Großteil des Datenaustausches vollelektronisch ablaufen wird, und immer mehr „Nachrichten“ verschiedenster Art über XML-Formate ausgetauscht werden. Da diesen XML-Nachrichten u.U. andere DTD’s zu Grunde liegen, sind möglichst eindeutige Datei-namen sehr hilfreich, um die jeweilige Datei direkt richtig zu identifizieren und mit der richtigen DTD zu bearbeiten. Für die im folgen vorgestellten Namenskonventionen gelten folgende Grundsätze: �� Die Namenskonventionen sind eine Empfehlung. �� Sie werden nicht formal überprüft, da die im Dateinamen enthaltenen Informationen im Kopf des

ESS-Dokuments ebenfalls vorhanden sind. �� Die Namensgebung dient zur schnellen manuellen Identifikation der entsprechenden Datei bzw.

der e-Mail (Regel: E-mail-Betreff = Dateiname), um bei Problemen die entsprechende Originalda-tei und die dazugehörigen Meldungen problemlos zu finden.

6.1. Dateinamen

6.1.1. Fahrplananmeldungen der Händler �� Anmeldung „Händlerfahrplan“:

<JJJJMMTT>_<TYP>_<EIC-NAME-HÄNDLER>_<EIC-NAME-TSO>_<VVV>.XML �� Anforderung eines Confirmation-Reports durch den Händler („Status-Request“)

Der Dateiname des „Status-Request“ sollte gemäss dieser Namenskonvention generiert werden. <JJJJMMTT>_<TYP>_<EIC-NAME-HÄNDLER>_<EIC-NAME-TSO>_CRQ.XML

6.1.2. Rückmeldungen der ÜNB Die Dateinamen der Rückmeldungen werden von den ÜNB wie folgt generiert: �� Acknowledgement Message

<JJJJMMTT>_<TYP>_<EIC-NAME-HÄNDLER>_<EIC-NAME-TSO>_<VVV>_ACK.XML �� Anomaly Report

<JJJJMMTT>_<TYP>_<EIC-NAME-HÄNDLER>_<EIC-NAME-TSO>_<VVV>_ANO_<yyyy-mm-ddThh-mm-ssZ>.XML

�� Confirmation Report

<JJJJMMTT>_<TYP>_<EIC-NAME-HÄNDLER>_<EIC-NAME-TSO>_<VVV>_CNF_<yyyy-mm-ddThh-mm-ssZ>.XML

Tab. 4: Beschreibung der Elemente <JJJJMMTT> Gültigkeitsdatum des Fahrplans, bezogen auf den realen Kalendertag <TYP> Typ des Händlerfahrplans (3 Zeichen) siehe Tab. 5 <VVV> Version der Fahrplanmeldung. Die Version ist 3stellig mit führenden Nullen <jjjj-mm-ttThh-mm-ssZ>

Zeitpunkt der Erstellung der Anomaly bzw. Confirmation Meldung. Der Zeitstem-pel dient zur Unterscheidung mehrerer Anomaly- (und ggf. auch Confirmation-) Meldungen zu einer Fahrplanmeldung.

Tab. 5: Typen von Händlerfahrplänen TPS Trade-responsible Party Schedule Händlerfahrplan PPS Production-responsible Party Schedule Erzeugerfahrplan CPS Consumption-responsible Party Schedule Verbrauchsfahrplan TRS CBT (TRS) – Fahrplan



6.2. Message Identification

6.2.1. Message Identification in den Fahrplananmeldungen der Händler Für Message Identification der Fahrplananmeldungen der Händler gibt es keine Vorgaben.

6.2.2. Message Identification bei Rückmeldungen der ÜNB Die ÜNB werden die Message Identification ihrer Rückmeldungen nach folgendem Schema generie-ren:

<JJJJMMTT>_<EIC-NAME-TSO>_<TYP>_<NNNNN>

Tab. 6: Beschreibung der Elemente <JJJJMMTT> Gültigkeitsdatum der Daten dieser Nachricht, bezogen auf den realen Kalendertag <EIC-NAME-TSO> EIC Name des ÜNB <TYP> Typ des TSO-Dokumentes (3 Zeichen) siehe Tab. 7 <NNNNN> Laufende Nr.

Tab. 7:Typen von TSO-Dokumenten ACK Acknowledgement-Dokument ANO Anomaly-Report CNF Confirmation-Report

6.3. Time-Series Identification Die „Time-Series ID“ (max. 35 Zeichen) eines XML-Dokuments muss für alle Versionen des Doku-ments eindeutig sein. Beim Bau eines Konverters KISS => ESS muss der Konverter diese eindeutige „Time-Series ID“ erzeugen. Die „Excel-Spaltennummer“ ist zur Erzeugung der „Time Series ID“ nicht geeignet, da die Reihenfolge der Spalten im KISS-Format nicht fixiert ist. Die Vergabe einer „laufen-den Nummer“ verursacht einen erheblichen Verwaltungsaufwand.

6.3.1. Time-Series Identification in den Fahrplananmeldungen der Händler Für Time-Series Identification in den Fahrplananmeldungen der Händler gibt es keine Vorgaben. Wir empfehlen, die Time Series ID analog der Time Series Identification der ÜNB zu bilden. Damit ist im Acknowledgement Report der Fahrplan, auf den Bezug genommen wird, über die mit der Time Series ID übermittelte „von-an-Beziehung“ erkennbar.

6.3.2. Time-Series Identification bei Rückmeldungen der ÜNB Für den Fall, dass die ÜNB für Rückmeldungen eigene Time-Series ID für einen eingesandten Händ-lerfahrplan erzeugen müssen, werden diese ID nach folgendem Verfahren gebildet: Aus der jeweiligen Time Series werden die Angaben in den Feldern „Area“ und „Party“ ausgelesen, und hintereinander geschrieben.

<Out Area><In Area><Out Party><In Party> Da diese Bildungsvorschrift aber die vorgesehene Länge des Feldes (maximal 35 Zeichen) über-schreiten würde, müssen diese sinnvoll abgekürzt werden:

Bei einem Händlerfahrplan werden im Kopf der Schedule Message immer Sender und Empfän-ger des Fahrplans genannt. Somit können Sender mit „s“ und Empfänger mit „r“ („Receiver“) abgekürzt werden. Wenn jetzt eine Angabe in den Feldern „Area“ oder „Party“ mit den Einträgen in den Feldern Sender bzw. Empfänger übereinstimmt, so wird die entsprechende Abkürzung „s“ bzw. „r“ ver-wendet und der Name nicht ausgeschrieben. Hinweis: Ist als Sender oder Empfänger ein ÜNB eingetragen (10X...), dann wird von einer Ü-bereinstimmung gesprochen, wenn der Area Code (10Y...) die Regelzone des absendenden bzw. empfangenden ÜNB repräsentiert.



Beispiel 7 Der Händler C (Sender) meldet einen Fahrplan in der Regelzone A (Empfänger) an:

Interner Fahrplan Externer Fahrplan Time Series ID:

rrsHändlerD rRegelzoneBss

Out Area: RegelzoneA RegelzoneA In Area: RegelzoneA RegelzoneB

Out Party: HändlerC HändlerC In Patry: HändlerD HändlerC

Sender ID: 99XATOZ--------O

Receiver ID: 10XDE-ENBW--TNGX Interner Fahrplan Externer Fahrplan Time Series ID:

rrs99XZOTA--------S r10YDE-RWENET---Iss

Out Area: 10YDE-ENBW-----N 10YDE-ENBW-----N In Area: 10YDE-ENBW-----N 10YDE-RWENET---I

Out Party: 99XATOZ--------O 99XATOZ--------O In Patry: 99XZOTA--------S 99XATOZ--------O



7. Glossar CAS-Datei: (Control Area Schedules) Eine CAS-Datei wird zwischen zwei ÜNB zum Abgleich des Regelzonen-

saldos der beiden ÜNB ausgetauscht. Die Datei enthält alle Händler-Fahrpläne, die den Energieaustausch zwischen den beiden Regelzonen (z.B. EnBW und RWE) beschreiben.

CAX-Datei: (Control Area Exchange) Die Datei enthält die Regelzonensalden des betreffenden ÜNB auf Basis der abgegebenen „externen“ Fahrpläne der Händler. CAX-Dateien werden zwischen den ÜNB im deutschen Regelblock ausgetauscht, d.h. jeder ÜNB stellt den anderen seine Salden zur Verfügung.

Datenprüfung: siehe Verifikationsprüfung Eingangsprüfung: Die Eingangsprüfung umfasst alle Prüfungen, für die keine Daten anderer Marktteilnehmer

oder andere Datentypen benötigt werden. In Area: Entspricht der Angabe „An Regelzone“ im Excel-Format

Regelzonenüberschreitender Fahrplan: Regelzone in die Energie geliefert werden soll. Regelzoneninterner Fahrplan: Hier ist die Regelzone einzutragen, für die dieser Fahrplan abgegeben wurde. Die Angaben in den Feldern "Out Area" und "In Area" müssen identisch sein.

In Party: Entspricht der Angabe „Nach Bilanzkreis“ im Excel-Format Regelzonenüberschreitender Fahrplan: Regelzonen bzw. staatsgrenzenüberschreitende Fahrpläne dürfen nur zwischen den Bilanzkreisen des gleichen Bilanzkreisverantwortlichen ausgetauscht werden, daher müs-sen die Angaben in den Feldern "Out Party" und "In Party" identisch sein. Regelzoneninterner Fahrplan: Bilanzkreis, an den die Energie geliefert werden soll.

Message Version: Änderungskennung: Version des abgegebenen Fahrplans. Die Versionsnummer beginnt täglich mit 1 und wird bei jeder Änderung, getrennt nach Datenspalten (Time Series), hoch gezählt. (siehe dazu auch [4], Kap. 4.2.2.1.1.)

Out Area : Entspricht der Angabe „Aus Regelzone“ im Excel-Format Regelzonenüberschreitender Fahrplan: Regelzone aus der die Energie bezogen werden soll. Regelzoneninterner Fahrplan: Hier ist die Regelzone einzutragen, für die dieser Fahrplan abgegeben wurde. Die Angaben in den Feldern "Out Area" und "In Area" müssen identisch sein.

Out Party: Entspricht der Angabe „Von Bilanzkreis“ im Excel-Format Regelzonenüberschreitender Fahrplan: Regelzonen bzw. staatsgrenzenüberschreitende Fahrpläne dürfen nur zwischen den Bilanzkreisen des gleichen Bilanzkreisverantwortlichen ausgetauscht werden, daher müs-sen die Angaben in den Feldern "Out Party" und "In Party" identisch sein. Regelzoneninterner Fahrplan: Bilanzkreis, von dem die Energie bezogen werden soll.

Receiver Identification: Name des Empfängers Schedule Time Interval: Anfangs- und End-Zeitpunkt des Fahrplans im UTC-Format Sender Identification: Name des Absenders TAS-Datei: (Transit Control Area Schedules) Eine TAS-Datei entspricht einer CAS-Datei und enthält die Daten

der Transit-Fahrpläne. TAX-Datei: (Transit Control Area Exchange) Eine TAX-Datei entspricht einer CAX-Datei und enthält die Regel-

zonensalden auf Basis der Transit-Fahrpläne. UTC-Zeitformat: siehe Norm: ISO 8601; für das ESS gelten die in [4] beschriebenen Formate. UTC (Universal Time Coordinated): engl. Abk. Universal Time Coordinated. Koordinierte Weltzeit. Die Zeitan-

gaben aller Länder beziehen sich auf diese Zeit. Entspricht der GMT (Greenwich Mean Time). Die UTC läuft kontinuierlich und kennt keinen Wechsel zwischen Sommer- und Winterzeit. In Deutschland gilt die MEZ (Mitteleuropäische Zeit) bzw. die MESZ (Mitteleuropäische Sommerzeit). Die MESZ liegt zwei Stunden nach der koordinierten Weltzeit, die MEZ eine Stunde nach der koordinierten Weltzeit. [Quelle: BET Fachwörterbuch, http://www.bet.de/lexikon)

Verifikationsprüfung: Verifikationsprüfungen beinhalten Prüfungen, für die Daten korrespondierender Markt-teilnehmer benötigt werden.



8. Literatur

8.1. Verwendete Literatur [1] VV II+; Verbändevereinbarung über die Kriterien zur Bestimmung von Netznutzungsentgelten für

elektrische Energie; 13.12.2001 [2] TransmissionCode 2003; Netz- und Systemregeln der deutschen Übertragungsnetzbetreiber;

Verband der Netzbetreiber – VDN - e.V.; Berlin; August 2003, www.vdn-berlin.de [3] EIC; The ETSO Identification Coding Scheme, A common Identification System for the electricity

Industry, Version 2 Release 1; 10.11. 2002, www.edi.etso-net.org [4] ESS; ETSO Scheduling System; Implementation Guide, Version 2 Release 3, 29.04.2003,

www.edi.etso-net.org



Anhang A. Liste der Eingangsprüfungen





Documents

Fahrplananmeldung in Deutschland - LDEWldew.de/bdew.nsf/id/DE_ETSO_Scheduling_System_ESS/$file/ESS... · Fahrplananmeldung in Deutschland mit Hilfe des ETSO Scheduling System (ESS)