IntraDay Änderungen nach StromNZV Konzept zum Datenaustausch

Transkript

1 IntraDay Änderungen nach StromNZV Konzept zum Datenaustausch Feinkonzept IntraDay-Datenaustausch

2 Konzept zum Datenaustausch 2 Arbeitsgruppe Feinkonzept IntraDay Andreas Benger Stefan Boerger Dirk Pooschke Dirk Rauschenbach Stephan Schlunke Jörg Wozny RWE Transportnetze Strom E.ON Netz GmbH E.ON Netz GmbH RWE Transportnetze Strom Vattenfall Europe Transmisson GmbH EnBW Transportnetze AG Inhalt: 1. Zielstellung Allgemeine Rahmenbedingungen/Definitionen IntraDay Änderungen im Marktsystem Deutschland Normale IntraDay Änderungen IntraDay Änderungen infolge eines Kraftwerksausfalls Richtlinien für die Verwendung des Message Type Production failure Anwendungsbereich Regelwerk zur Umsetzung von IntraDay Änderungen im Fahrplanmanagement Basis-Konzept: zyklisch automatisierter Regelzonenabgleich Abgrenzung/Sonstiges Dateiformat Prozessphasen des Fahrplanmanagement Intraday-Fahrplananmeldung Fahrplananmeldung in der Prozessphase: Dayahead-Matching Fahrplananmeldung in der Prozessphase IntraDay Allgemein Gate-Closure-Time Zulässige Häufigkeit der Fahrplananmeldung Verwendung des Elementes Process Type innerhalb einer ESS Message Abstimmung Confimation-/Anomaly-Report Randbedingungen Prozessbeispiele Fehlerfreier Prozessablauf Intraday Änderung hat einen der Adressaten nicht erreicht Fehlerhafte Intraday Änderung wird durch den BKV nicht korrigiert Anhang Regeln für die Verwendung des Elements Process Type Verwendung von Imposed und Modified TimeSeries in einem ESS Confirmation Report Imposed TimeSeries Confirmed TimeSeries mit dem Status Modified Status in einem Confirmation Report Glossar Literatur..16

3 Konzept zum Datenaustausch 3 1. Zielstellung Konzeption/Implementierung einer Fahrplanmanagement-Systematik zur Ertüchtigung der Fahrplanmanagementsysteme der Übertragungsnetzbetreiber (ÜNB) in Bezug auf die sich aus der StromNZV ergebenen Anforderungen zu den Änderungsmöglichkeiten regelzonenüberschreitender Fahrplananmeldungen. Das Konzept verfolgt dabei folgende Teilziele: Anpassung der Vorlaufzeiten für Fahrplanänderungen gemäß 5 StromNZV. Minmale Änderungen an der Kommunikation zwischen Bilanzkreisverantwortlichen (BKV) und ÜNB. Schnelle Abstimmung zwischen den ÜNB bei regelzonenüberschreitenden Fahrplananmeldungen, sowie schnelle und vollständige Information der BKV über den Status der Fahrplananmeldung. Prozessablauf muss unabhängig vom Kommunikationsweg (Internet-Mail, ISDN-ftp) sein, über den der Datenaustausch realisiert wird. Weitestgehende Unabhängigkeit vom Datenformat: Zur Zeit ist neben dem ESS in der Version 2.3 [2] die Version 3.0 freigegeben und die Version 3.1 in der Diskussion. Eine spätere Anpassung des Prozesses an die höhere ESS Version sollte mit möglichst geringen Aufwendungen für alle Marktpartner verbunden sein. Einbeziehung von Fahrplan-Änderungen, die als Folge eines Kraftwerksausfalls angemeldet werden. Fahrplanänderungen als Folge eines Kraftwerksausfalls müssen durch die ÜNB im Rahmen des automatisierten Prozesses bearbeitet werden können. Die Umsetzung muss bis Ende 2006 erfolgen.

4 Konzept zum Datenaustausch 4 2. Allgemeine Rahmenbedingungen/Definitionen 2.1 IntraDay Änderungen im Marktsystem Deutschland Im Marktsystem Deutschland werden nach der Verordnung über den Zugang zu Elektrizitätsversorgungsnetzen (StromNZV) [7] zwei Arten von IntraDay Änderungsmöglichkeiten unterschieden: o 5 Abs. 2 Satz 1: Regelzonenübergreifende Fahrpläne können mit einem zeitlichen Vorlauf von mindestens drei Viertelstunden zu jeder Viertelstunde eines Tages geändert werden. o 5 Abs. 4 Satz 1-3: Das durch ungeplante Kraftwerksausfälle entstehende Ungleichgewicht zwischen Einspeisungen und Entnahmen ist vom Betreiber von Übertragungsnetzen für vier Viertelstunden einschließlich der Viertelstunde, in der der Ausfall aufgetreten ist, auszugleichen. Für die Zeit nach Ablauf dieser vier Viertelstunden ist der Bilanzkreisverantwortliche zum Ausgleich der ausgefallenen Leistung verpflichtet. Hierzu kann er abweichend von [ 5] Absatz 2 Satz 1 seine Fahrpläne mit einer Vorlaufzeit von 15 Minuten zum Beginn einer jeden Viertelstunde ändern. Definition: Als IntraDay Änderung werden alle regelzonenüberschreitenden Fahrplanänderungen bezeichnet, die nach dem Anmeldeschluss des Vortages bei dem jeweiligen ÜNB eintreffen. Für die in der StromNZV genannten Vorlaufzeiten und alle weiteren Prüfungen, die darauf basieren, gilt der Eingangszeitpunkt (-zeitstempel) der Datei (ESS Message) bei dem jeweiligen ÜNB, nicht der Absende- bzw. Erzeugungszeitpunkt dieser Datei bei dem Absender Normale IntraDay Änderungen Für die Abwicklung der normalen IntraDay Änderungen (StromNZV 5 Abs. 2) ist ein weitestgehend automatisierter Abgleichprozess zwischen den beteiligten ÜNB erforderlich. Dieser Prozess wird in Kap. 3 beschrieben IntraDay Änderungen infolge eines Kraftwerksausfalls Der Abgleich von Fahrplanänderungen, die durch einen Kraftwerksausfall verursacht werden, muss im kritischsten Fall in einem minimalen Zeitraum von weniger als ca. 10 Min. erfolgen (eine systembedingte Vorlaufzeit von 5 min ist für die Regler nötig). Die Unterscheidung der Fahrplananmeldungen auf Grund eines Kraftwerksausfalls von den normalen IntraDay Änderungen erfolgt über den Message Type: Für Fahrplananmeldungen infolge Kraftwerksausfalls wird ein neuer Message Type Z10 (Production failure) eingeführt, der in diesem Falle anstelle des Message Types A01 (Balance responsible schedule) in der Datei mitzuführen ist (siehe dazu auch die Erläuterungen in Kap. 5.1). Die nachfolgenden Abgleichprozesse zwischen den ÜNB können dann über das gleiche Schema wie der Abgleich von normalen IntraDay Änderung durchgeführt werden.

5 Konzept zum Datenaustausch Richtlinien für die Verwendung des Message Type Production failure Der besondere Message Type wird nur zur Unterscheidung der zulässigen Vorlaufzeiten benötigt. Alle anderen Regeln für die Fahrplananmeldung bleiben erhalten: Informationsumfang bei Änderungen: Der Informationsgehalt einer vom ÜNB akzeptier- Vergabe von von Versionsnummern ten Fahrplananmeldung (Schedule Message) darf sich bei einer Änderung oder Stor- Die Versionsnummer beginnt für für jeden Tag neu bei bei nierung nicht verringern. Alle bereits beim Sie Sie wird als als Message Version und als als Time Series Version geführt ÜNB eingereichten und akzeptierten Time- Series müssen bei weiteren Fahrplananmeldungen für den betreffenden Tag vollständig Bei Bei jeder Änderung wird die die Message Version um um 1 hochgezählt und die die geänderten oder neuen Time Series mit mit dieser neuen enthalten sein. Nummer gekennzeichnet. Beispiel: Stornierung von Zeitreihen: Wurde für einen Ver Versions Nr Nr Datei Tag eine Zeitreihe eingereicht und soll diese Geschäft A Geschäft B Geschäft C Er Erstanmeldung Nicht Nicht vorhanden vorhanden storniert werden, dann müssen alle Werte Geschäft B ändert sich sich Nicht Nicht vorhanden vorhanden Geschäft auf 0 geändert und bis zum Ende des be- A ändert sich sich Nicht Nicht vorhanden vorhanden Neues Geschäft C treffenden Tages mitgeführt werden. EnBW TNG B- FÜ EnBW TNG B-FÜ Jörg Wozny ESS - Fahr pl ananmel dung in Deutschland April Jörg Wozny April 2003 Message Identification / TimeSeries ID: Die Abbildung 1: Versionisierung ID dürfen sich im Vergleich zur Vorversion nicht ändern. Message Version: Die Versionisierung hat gemäß ESS IG Version 2.3 [2] Kap zu erfolgen. (siehe auch: Abbildung 1) Fahrplanänderungen auf Grund eines Kraftwerksausfalls werden nicht gesondert versioniert. ESS - Fahr pl ananmel dung in Deutschland Anwendungsbereich Die beschriebene Systematik wird für alle Intraday-Fahrplananmeldungen innerhalb und zwischen den Regelzonen der ÜNB EnBW Transportnetze, EON Netz, RWE Transportnetz Strom und VE Transmission angewendet.

6 Konzept zum Datenaustausch 6 3. Regelwerk zur Umsetzung von IntraDay Änderungen im Fahrplanmanagement 3.1 Basis-Konzept: zyklisch automatisierter Regelzonenabgleich Unmittelbar nach jedem Viertelstundenwechsel werden alle bis zum betreffenden Viertelstundenwechsel eingelaufenen Intraday-Fahrplananmeldungen zwischen den deutschen ÜNB automatisch abgestimmt. Unmittelbar nach der Abstimmung wird das Ergebnis der Abstimmung per Intermediate Confirmation-Report (CNF) und bei erkannten Unstimmigkeiten durch zusätzlichen Anomaly-Report (ANO) den betroffenen BKV automatisch mitgeteilt. 3.2 Abgrenzung/Sonstiges Zur Umsetzung des zyklischen automatisierten Regelzonenabgleichs wurden folgende Abstimmungen getroffen. Die Aussagen in den Folgepunkten beziehen sich dabei ausschließlich auf regelzonenüberschreitende (externe) Fahrplanänderungen zwischen den deutschen ÜNB, sofern nicht anders beschrieben: 3.3 Dateiformat Das Format der Dateien für Fahrplananmeldungen der BKV bei den ÜNB, die IntraDay Änderungen zum Inhalt haben, unterscheidet sich nicht von den bis 14:30 Uhr des Vortages übermittelten Fahrplananmeldungen. Sie müssen vollständig sein (d. h. alle Fahrpläne für den betreffenden Tag enthalten). Die Versionierungen von Message und TimeSeries entsprechen den bisherigen allgemeinen deutschen Marktregeln und sind ESS-konform. Die Behandlung als IntraDay Fahrplananmeldung gegenüber einer normalen Fahrplananmeldung bis zur Gate-Closure-Time 14:30 Uhr des Vortages erfolgt ausschließlich in Abhängigkeit des Eingangszeitstempels beim jeweiligen Empfänger-ÜNB. (Siehe auch Definition in Kap. 2.1) 3.4 Prozessphasen des Fahrplanmanagement Bezüglich der Abwicklung des Fahrplananmeldungen für einen Tag D sind folgende grundsätzliche Phasen zu unterteilen: DayAhead: Vormonat bis D-1, 14:30 Uhr: Keine Änderung gegenüber den bisherigen Regeln. Dayahead-Matching von D-1, 14:30 Uhr, bis D-1, 18:00 Uhr: Die Besonderheiten werden im Kapitel 3.5.1, Fahrplananmeldung in der Prozessphase: Dayahead-Matching behandelt. IntraDay: von D-1, 18:00 Uhr, bis D, 24:00 Uhr: Startzeit für den automatisierten IntraDay-Abstimmprozess ist in der Regel D-1, 18:00 Uhr. Dieser Startzeitpunkt kann in Ausnahmefällen auf einen späteren Zeitpunkt verschoben werden. In diesem Fall verlängert sich die Phase Dayahead-Matching. Alles Weitere ist den folgenden Kapiteln zu entnehmen. DayAfter: von D+1 00:00 Uhr bis 16:00 Uhr des auf D folgenden Werktages: Keine Änderung gegenüber den bisherigen Regeln. Daraus ergibt sich, dass zwischen 18:00 Uhr und 24:00 Uhr täglich sowohl der aktuelle als auch der nachfolgende Tag sich innerhalb der Phase IntraDay befinden.

7 Konzept zum Datenaustausch Intraday-Fahrplananmeldung Fahrplananmeldung in der Prozessphase: Dayahead-Matching Zwischen dem Ende der Phase DayAhead (D-1, 14:30 Uhr) und dem Startzeitpunkt der Phase Intra- Day (D-1, 18:00) einlaufende und formal korrekte Fahrplananmeldungen mit Fahrplanänderungen werden bis zum Startzeitpunkt der Phase IntraDay zwar durch den Empfänger-ÜNB entgegengenommen, aber erst einmal nicht weiter bearbeitet und abgestimmt. Dem BKV wird lediglich eine informelle Eingangsbestätigung in Form einer Textdatei zugestellt. Enthält die Datei formale Fehler, wird dem betroffenen BKV unverzüglich ein formaler negativer Acknowledgement-Report (ACK, mit dem Reason Code A02: Message fully rejected ) zugesendet. Die formale Prüfung innerhalb dieses Zeitraumes erfolgt immer gegen die während der Phase DayAhead vom BKV empfangenen und formal per ACK quittierten Fahrplananmeldungen des BKV (hierzu gehören auch die abgelehnten Fahrplananmeldungen). CNF und ANO, die der BKV während dieser DayAhead-Matching-Phase erhält bzw. per Status Request angefordert hat, basieren in der Regel auf der letzten bis 14:30 Uhr empfangenen Fahrplananmeldungen, die die Grundlage für die Folgetagsabstimmung der ÜNB im UCTE-Verbundbetrieb bildet und die dem BKV mit einem ACK mit Reason Code A01 bestätigt wurde.. Ausnahmen zur obigen Regel bilden Nachmeldungen im Zusammenhang mit der Dayahead- Abstimmung, bei denen durch den ÜNB manuell die weiteren Verarbeitungsschritte angestoßen werden, die in der DayAhead-Phase automatisch ablaufen und die mit dem Versand von ACK und ggf. ANO an den BKV abgeschlossen werden. Mit dem Start der Phase IntraDay wird die letzte bis dato vorliegende Anmeldung eines jeweiligen BKV, die mit einer Textdatei zum Zeitpunkt des Empfangs quittiert wurde, beim ÜNB in den Abstimmprozeß der Phase IntraDay übernommen. Im Ergebnis der Verarbeitung übermittelt der ÜNB dem BKV einen ACK Fahrplananmeldung in der Prozessphase IntraDay Allgemein In der Prozessphase IntraDay ist eine Fahrplananmeldung jederzeit möglich. Es erfolgt durch die ÜNB eine unmittelbare formale Prüfung und Bestätigung per ACK, sofern nicht gerade der viertelstündliche Abstimmungsprozess läuft. In diesem Fall wird die einlaufende Fahrplananmeldung des betreffenden BKV bis zum Abschluss des Abstimmungsprozesses zurückgestellt. Die formale Prüfung und Bestätigung per ACK erfolgt unmittelbar nach Abschluss des Abstimmungsprozesses im Ergebnis der Weiterverarbeitung der Fahrplananmeldung. Im Falle mehrerer während des Abstimmprozesses empfangener Fahrplananmeldungen eines BKV erfolgt die chronologische Verarbeitung entsprechend der Eingangsreihenfolge. Es ist zu beachten, dass in dem nach jedem Viertelstundenwechsel (xx:00, xx:15, xx:30, xx:45) laufenden Abstimmungsprozess bei allen ÜNB der zum Zeitpunkt des Viertelstundenwechsels vorliegende Stand der Anmeldung abgestimmt wird. Somit ist durch den BKV zu gewährleisten, dass zum Zeitpunkt des Viertelstundenwechsels spätestens zur Gate-Closure-Time - identische Fahrplananmeldungen bei beiden ÜNB vorliegen! Gate-Closure-Time Die Gate-Closure-Time ist der Zeitpunkt des Viertelstundenwechsels, zu dem eine Datei mit regelzonenüberschreitenden Fahrplanänderungen spätestens bei den betreffenden ÜNB eingegangen sein muss. Sie ergibt sich aus der minimalen Vorlaufzeit der gewünschten Intraday-Fahrplanänderung von 45 Minuten (StromNZV 5 Abs. 2) bzw. von 15 Minuten bei einer durch Kraftwerksausfall begründeten Fahrplananänderung (StromNZV 5 Abs. 4) in Bezug auf die aktuell beim ÜNB vorliegende und mit ACK akzeptierte Fahrplananmeldung.

8 Konzept zum Datenaustausch 8 Fahrplananmeldungen mit regelzonenüberschreitenden Änderungen, welche nach dem Verstreichen der Gate-Closure-Time vom ÜNB empfangen werden, werden im Zuge der formalen Prüfung per ACK zurückgewiesen. Beispiele: Externe Fahrplanänderung zwischen zwei deutschen Regelzonen für den laufenden Tag, erste Änderung in der Intraday-Fahrplananmeldung für die Viertelstunde 14:00+14:15 Uhr: Gate-Closure-Time = 13:15:00 Uhr Externe Fahrplanänderung zwischen zwei deutschen Regelzonen, Fahrplananmeldung wg. Kraftwerksausfalls, erste Änderung für die Viertelstunde 14:00-14:15Uhr: Gate-Closure-Time = 13:45:00 Uhr Für externe Fahrplananmeldungen mit ausländischen Regelzonen gelten jeweils die restriktiveren Regelungen, die durch die Marktregeln beiderseits der Grenzen in den betroffenen Ländern vorgegeben werden Zulässige Häufigkeit der Fahrplananmeldung Die zulässige Anzahl/Häufigkeit der Fahrplanänderungen wird nicht eingeschränkt. Diese ist lediglich durch die Versionierung (ESS: max. Message/-TimeSeries-Version = 999 pro Tag) begrenzt Verwendung des Elementes Process Type innerhalb einer ESS Message Im Marktsystem Deutschland werden die einzelnen Prozessphasen eines Fahrplantages im ESS Prozess zur Zeit nicht unterschieden. Während der Einführung des ESS Prozesses (in der Version 2.3) im Jahre 2004 wurde bewusst auf die Unterscheidung nach Prozessphasen innerhalb einer ESS Message verzichtet. Für das in diesem Papier vorgestellte Konzept zur automatisierten Abwicklung des IntraDay Prozesses ist eine solche Unterscheidung ebenfalls nicht notwendig, da eintreffende Fahrplandateien jeweils über den Eingangszeitpunkt und den betreffenden Tag, für den die Fahrplananmeldung bestimmt ist, zweifelsfrei den jeweiligen Prozessphasen zugeordnet werden können Abstimmung Confimation-/Anomaly-Report Nach jedem Viertelstundenwechsel und zusätzlicher Beruhigungszeit von ca. 1 Minute beginnt der Abstimmungsprozess der ÜNB, er dauert maximal 5 Minuten: Die ÜNB tauschen im Falle mindestens einer seit dem letzten Abstimmungsprozess empfangenen Fahrplanänderung untereinander automatisch eine Datei mit den regelzonenübergreifenden Fahrplänen aus (CAS-Datei). Diese Datei enthält auch die beabsichtigten neuen Fahrplanänderungen (pro BKV jeweils die zum Viertelstundenwechsel aktuellste Fahrplanänderung). Das Ergebnis des Abstimmungsprozesses wird den betroffenen BKV nach Beendigung des Abstimmungsprozesses in Form vollständiger CNF-/ANO-Reports übermittelt. Bei funktionierender Inter-ÜNB-Kommunikation 1 und vorliegenden Inkonsistenzen in den Fahrplanänderungen sind folgende Szenarien zu unterscheiden: Gate-Closure-Time noch nicht erreicht: Im Rahmen des vollständigen CNF-/ANO-Reports erhält der BKV im ANO-Report die Mitteilung über die erkannten Inkonsistenzen. Der BKV hat die Möglichkeit, eine Korrektur der Änderung an einen oder beide ÜNB zu senden. Sofern die Inkonsistenz dadurch hervorgerufen wurde, daß die Fahrplanänderung durch einen der beiden ÜNB erst in der nächsten Viertelstunde empfangen wurde, braucht keine Korrektur durch den BKV versendet zu werden, die erfolgreiche Abstimmung erfolgt dann im Rahmen des folgenden Abstimmungsprozesses nach dem nächsten Viertelstundenende. 1 Bei funktionierender Kommunikation liegen innerhalb der Abstimmphase zu allen externen zum Viertelstundenwechsel vorliegenden (Anmelde-) Fahrplanänderungen eines BKV ein per CAS-Datei vom Partner-ÜNBÜNB zugestellter Vergleichs-Fahrplan vor. Des Weiteren wurden alle (Anmelde-)Fahrplanänderungen eines BKV per CAS-Datei an die Partner-ÜNBÜNB versendet und von diesen per CAS-ACK bestätigt.

9 Konzept zum Datenaustausch 9 Gate-Closure-Time überschritten: Alle durch den BKV geänderten Werte des inkonsistenten (differierenden) Fahrplanes werden mit den bisher gültigen Werten der bereits zuvor empfangenen und gegenbestätigten Fahrplanversion überschrieben (modifiziert). Der BKV erhält von den ÜNB einen vollständigen CNF-/ANO-Report. Der modifizierte Fahrplan ist Bestandteil des CNF-Reports, die modifizierten Werte sind als solche gekennzeichnet (siehe dazu auch Festlegungen zum Thema Modified und Imposed TimeSeries in Kap. 5.2). Im ANO-Report sind ggf. weitere erkannte Inkonsistenzen aufgelistet, die andere Fahrpläne betreffen und deren Korrektur entsprechend den Marktregeln noch zu einem späteren Zeitpunkt möglich ist. Der aktuelle Abstimmungszyklus ist damit für den betreffenden BKV abgeschlossen. Sofern der BKV eine Änderung von auf die alten Werte modifizierten Fahrplanwerten wünscht, für die die Gate- Closure-Time noch nicht erreicht ist, muss er diese Änderung im Rahmen einer Fahrplananmeldung erneut bei beiden ÜNB anmelden. Sofern geänderte Fahrplanwerte bereits zum Zeitpunkt des Eintreffens der Fahrplananmeldung beim ÜNB die Gate-Closure-Time unterlaufen, erfolgt eine Zurückweisung der gesamten Fahrplananmeldung bereits im Ergebnis des Eingangschecks. Der BKV erhält die Mitteilung darüber im ACK-Report. Bei fehlerhafter Inter-ÜNB-Kommunikation erfolgt das Zusenden von vollständigen CNF-/ANO- Reports an den BKV nach dem Ablauf der 5-Minuten-Frist auf Grundlage des bis dato erreichten Abstimmungsstandes. In diesem Zustand wird der ÜNB die Abstimmung durch manuelle Eingriffe weiterführen, wobei das dabei erzielte Ergebnis dem BKV ebenfalls durch das Zusenden vollständiger CNF-/ANO-Reports mitgeteilt wird Randbedingungen Bei der Abstimmung ist zu beachten, dass bei einer IntraDay Änderung eines BKV im Falle der Existenz gegenläufiger Fahrpläne zu einer Partnerregelzone immer beide Richtungen im Zusammenhang betrachtet und somit geprüft werden müssen. Andernfalls kann die Situation eintreten, dass die Fahrpläne in beiden Richtungen nicht mehr genettet sind. Das bedeutet im Einzelnen: (1) Werden durch den BKV beide Richtungen regelkonform geändert und weist eine der beiden Richtungen Inkonsistenzen auf, dann kann auch die Fahrplanänderung in der anderen Richtung (ohne Inkonsistenzen) nicht gegenbestätigt (confirmed) werden; (2) Weist nach Überschreitung der Gate-Closure-Time eine der beiden geänderten, gegenläufigen Zeitreihen immer noch Inkonsistenzen auf, dann werden immer beide geänderten gegenläufigen Zeitreihen auf die zuletzt gegenbestätigte Version dieser Zeitreihen modifiziert. Beispiel: Ein BKV meldet bei den betroffenen ÜNB die IntraDay Fahrpläne (C, D bzw. E, F) an. Die Richtung ÜNB A >> ÜNB B (Spalten C und E) ist in beiden Anmeldungen korrekt. In der Richtung ÜNB B >> ÜNB A (Spalten D und F) besteht zum Zeitpunkt 8 eine Unstimmigkeit. Wenn jetzt nur je Richtung geprüft würde, würden die Daten für die Richtung ÜNB A >> ÜNB B ü- bernommen, da diese Fehlerfrei sind. Für die Richtung ÜNB B >> ÜNB A würden die Daten der zuletzt abgestimmten Version (Spalte B) weiterhin gelten, da die beiden Fahrpläne in dieser Richtung eine Inkonsistenz aufweisen.. Im Ergebnis entstünde ein nicht genetteter IntraDay Fahrplan (Spalten G und H) Um diese Unstimmigkeiten zu vermeiden, wird zusätzlich geprüft, ob beide Richtungen (ÜNB A >> ÜNB B, bzw. ÜNB B >> ÜNB A) korrekt sind. Im Ergebnis können entweder die Fahrpläne in beiden Richtungen übernommen werden oder, im Fall von Unstimmigkeiten, werden beide Fahrpläne durch die zuvor bereits abgestimmten Fahrpläne überschrieben, die damit unverändert weiterhin gelten.

10 Konzept zum Datenaustausch 10 Abgestimmte Fpl IntraDay IntraDay Resultierende Version Anmeldung bei Anmeldung bei IntraDay TSO A TSO B Anmeldung (Vortag) A B C D E F G H Aus Regelzone TSO A TSO B TSO A TSO B TSO A TSO B TSO A TSO B An Regelzone TSO B TSO A TSO B TSO A TSO B TSO A TSO B TSO A Version Zeit Gegenläufige Fahrpläne wären nicht mehr genettet!

11 Konzept zum Datenaustausch Prozessbeispiele Die Prozessgrafiken stellen nur den prinzipiellen Datenaustausch dar und erlauben keine Aussage über die Transferzeiten der Nachrichten bzw. die Verarbeitungszeiten in den Systemen. 4.1 Fehlerfreier Prozessablauf In der Abbildung 1 ist der fehlerfreie Prozessablauf dargestellt. Ein BKV meldet bei den betroffenen ÜNB seine Änderung an. Zu dem der Anmeldung folgenden Viertelstundenende tauschen diese CAS Dateien aus. Wenn der Abgleich erfolgreich durchgeführt werden konnte, wird dem BKV dies über einen Confirmation Report mitgeteilt. 4.2 Intraday Änderung hat einen der Adressaten nicht erreicht In der Abbildung 2 ist ein fehlerbehafteter Prozessablauf dargestellt. Die Fahrplananmeldung des BKV erreicht den ÜNB B nicht. Zu dem der Anmeldung folgenden Viertelstundenende sendet der ÜNB A eine CAS Datei an ÜNB B. Dieser reagiert auf dem Empfang der CAS Datei, indem er neben dem ACK zusätzlich eine CAS Datei mit seinen Daten an ÜNB A sendet. Händler TPS ACK ÜNB B CAS CNF ÜNB A 13:00 Jede 1/4h + 1 min Datenaustausch zwischen den ÜNB Jede 1/4h + 5 min Abgleich der Austauschprogramme Abbildung 1: Fehlerfreier Prozessablauf Händler TPS ACK ÜNB A CAS CNF ANO ÜNB B 13:00 Jede 1/4h + 1 min Datenaustausch zwischen den ÜNB Jede 1/4h + 5 min Abgleich der Austauschprogramme Zeitreihe abgestimmt Beide ÜNB senden im Anschluss an den Abgleichvorgang einen Anomaly Report an den BKV. Der BKV reagiert mit einer neuen Fahrplananmeldung. Dabei ist es dem BKV überlassen, ob er beiden ÜNB eine neue Fahrplananmeldung sendet oder nur demjenigen, der zuvor die Daten nicht erhalten hatte. 14:00 Zeitreihe abgestimmt Fahrplanänderung ab 14:00 Uhr Abbildung 2: IntraDay Anmeldung hat einen der Adressaten nicht erreicht 14:00 Fahrplanänderung erst ab 14:15 möglich

12 Konzept zum Datenaustausch 12 Zu dem der Korrektur / Neuanmeldung folgenden Viertelstundenende tauschen die ÜNB wiederum CAS Dateien aus. Wenn der Abgleich erfolgreich durchgeführt werden konnte, wird dem BKV dies im Confirmation Report mitgeteilt. 4.3 Fehlerhafte Intraday Änderung wird durch den BKV nicht korrigiert In der Abbildung 3 ist Händler ein fehlerbehafteter TPS Prozessablauf dargestellt. ACK Erneuter ANO Wiederholung Die Fahrplananmeldung des BKV erreicht ÜNB B solange, bis CAS Deadline den ÜNB C nicht. unterschritten Zu dem der Anmeldung folgenden Viertelstundenende sendet der ÜNB B eine CAS Datei an ÜNB C. Der ÜNB C reagiert auf dem Empfang dieser CAS Datei, indem er neben dem ACK zusätzlich eine CAS Datei an ÜNB B sendet. CNF ANO ÜNB C 13:00 Jede 1/4h + 1 min Datenaustausch zwischen den ÜNB Jede 1/4h + 5 min Abgleich der Austauschprogramme Händler darf bis 45min vorher anmelden Abgleich nicht möglich, zurücksetzen auf abgestimmte Vorgänger-Zeitreihe Mit den zurückgesetzten Zeitreihen (modified TS) Mit den zurückgesetzten Zeitreihen (abgestimmte Vorgänger TS) Beide ÜNB senden im Gate Closure (45 min vorher) Anschluss an den Abgleichvorgang einen Abbildung 3: Fehlerhafte Intraday Änderung wird durch den BKV nicht korrigiert Full Anomaly Report an den BKV. In diesem Fall reagiert der BKV aber nicht auf die Fehlermeldungen der ÜNB. Der Versand der Anomaly Reports durch die ÜNB an den BKV wird fortgesetzt, solange ein regelzonenüberschreitender Fehler besteht, oder die Gate-Closure-Time für die betreffende Änderung erreicht wird. Mit Erreichen der Gate-Closure-Time für eine Zeitreihe wird diese dann auf die zuletzt gegenbestätigten Zeitreihen zurückgesetzt (modifiziert). Dies wird dem BKV in einen Confirmation Report mitgeteilt. 14:00 Zeitreihe abgelehnt, bzw. auf Vorgänger TS modified Fahrplanänderung

13 Konzept zum Datenaustausch Anhang 5.1 Regeln für die Verwendung des Elements Process Type Für das Marktsystem in Deutschland wurde eine Lösung gewählt, in der IntraDay Fahrplanänderungen nicht gesondert gekennzeichnet werden. Jede regelzonenüberschreitende Fahrplanänderung, die nach der Gate-Closure-Time des Vortages bei einem ÜNB eintrifft, wird zunächst einmal als IntraDay Fahrplanänderung betrachtet. Die Einhaltung der für den Prozess gültigen Vorlaufzeiten wird über den Eingangszeitpunkt der Fahrplandatei und dem ersten geänderten Fahrplanwert ermittelt. Da die Datenbasis für alle Prozesse gleich ist, muss innerhalb der Nachricht eine Kennzeichnung erfolgen, damit diese gegen die richtige Vorlaufzeit von 45 bzw. 15 Minuten geprüft werden kann.. In dem hier vorgestellten Konzept erfolgt die Kennzeichnung über den Message Type innerhalb der ESS Nachricht. Im folgenden werden die Gründe für diesen Schritt dargestellt. Der ESS Impementation Guide in der Version 2.3 [2] und die Version 3.0 bzw. die zur Zeit in der Diskussion befindliche Version 3.1 legen unterschiedliche Maßstäbe für die Verwendung des Elementes Process Type an. In der ESS Version 2.3 gibt es Regeln, die dahingehend interpretiert werden können, dass bei der Verwendung eines anderen Process Types gleichzeitig auch eine neue Message Identification verwendet werden sollte, auch wenn der gleiche Dateninhalt verwendet wird. (siehe dazu ESS IG V2.3 Kap Message Identification: Description ) In der ESS Version 3.0, die schon freigegeben ist, gibt es mit der Einführung des Elementes Domain und der Kopplung von Domain und Process Type den Zwang, eine neue Message Identification zu verwenden, wenn ein anderer Process Type benutzt wird. (siehe dazu ESS IG V 3.0) Zudem bedeutet die Kopplung an die Domain, dass eine Nachricht, mit einem anderen Process Type, auch einen anderen Dateninhalt haben kann / muss. Z.B. nur die Daten für die aktuelle IntraDay Änderung. Das Marktsystem in Deutschland ist darauf ausgelegt, dass die Fahrplandatei eines BKV die gesamte Handelstätigkeit des BKV widerspiegelt. Dieses Prinzip ist auch so in der StromNZV festgeschrieben. (Siehe [7]; 5; Abs. 1, letzter Satz) [ ] Die Fahrpläne müssen vollständig sein, eine ausgeglichene Bilanz des Bilanzkreises und damit eine ausgeglichene Bilanz der jeweiligen Regelzone ermöglichen. Daher würde eine Übermittlung von Ausschnitten der Handelstätigkeit, wie sie im ESS 3.0 möglich, aber nicht zwingend vorgeschrieben ist, den deutschen Markregeln widersprechen.

14 Konzept zum Datenaustausch Verwendung von Imposed und Modified TimeSeries in einem ESS Confirmation Report In einem ESS Confirmation Report können einem Marktteilnehmer TimeSeries als Confirmed bzw. Imposed zurück gegeben werden. Für das Marktsystem Deutschland werden hierzu folgende Regeln festgelegt: Imposed TimeSeries Eine Zeitreihe, die durch den ÜNB neu in das Portfolio eines BKV eingestellt wird und die bisher für diesen Tag durch den BKV noch nicht angemeldet wurde, ist eine Imposed TimeSeries. 1. Die TS-ID wird durch den ÜNB generiert, da durch den BKV keine Zeitreihe mit dieser Konstellation bis zu diesem Zeitpunkt angemeldet wurde und demzufolge auch keine TS-ID vorliegt, die der ÜNB nutzen kann. Die durch den ÜNB erzeugte und für diese Zeitreihe verwendete TS- ID heißt deshalb Imposed TS-ID. 2. Als Versionsnummer der Imposed TimeSeries wird die Confirmed MessageVersion verwendet. 3. Für den Fall, dass der BKV überhaupt noch keine akzeptierte Fahrplananmeldung an den ÜNB für den betreffenden Tag übermittelt hat, wird für die Imposed TimeSeries die Versionsnummer 1 zurückgegeben. In diesem Fall werden die Elemente Confirmed MessageID und Confirmed MessageVersion nicht übermittelt. 4. Eine vom ÜNB vergebene Imposed TS-ID darf vom BKV bei einer erneuten Fahrplananmeldung für den betreffenden Tag einmalig mit einer eigenen TS-ID überschrieben werden, die dann auch für alle nachfolgenden aktualisierten Fahrplananmeldungen weiterhin genutzt werden muss Confirmed TimeSeries mit dem Status Modified Werden von Seiten des ÜNB Werte in einer bereits angemeldeten Zeitreihe geändert, so ist diese eine Confirmed TimeSeries mit dem Status Modified. 1. Als Versionsnummer wird die letzte akzeptierte und vom BKV übermittelte TimeSeries-Version beibehalten. 2. Der geänderte Fahrplan muss im Confirmation-Report durch einen Reason-Code auf TimeSeries-Level gekennzeichnet werden Status in einem Confirmation Report Schedule global position accepted Confirmed TimeSeries alle im Portfolio des BKV genannten Zeitreihen wurden beim ÜNB von den Marktteilnehmern ohne Einschränkung bestätigt Imposed TimeSeries Schedule global position partially accepted Confirmed TimeSeries aufgeführte Zeitreihe: - ist beim ÜNB durch den Marktteilnehmer ohne Einschränkung bestätigt worden ReasonCodes: A63 auf TS-Level - durch ÜNB geändert (Modified) A43, A44 auf IV-Level Imposed TimeSeries Können erst nach den entsprechenden Deadlines ausgegeben werden. aufgeführte Zeitreihe wurde durch ÜNB - in das Portfolio neu eingestellt ReasonCode: A30 auf TS-Level Abbildung 4: Status in einem Confirmation Report

15 Konzept zum Datenaustausch 15 Hat ein CNF-Report den Status A06 (Schedule global position accepted), dann sind alle Fahrpläne des BKV durch den ÜNB ohne Änderungen bestätigt worden. Hat ein CNF-Report dagegen den Status A07 (Schedule global position partially accepted) erhalten, dann ist der Inhalt des CNF-Reports in Abhängigkeit davon zu interpretieren, ob es sich um einen Intermediate oder um einen Final CNF handelt: Intermediate CNF Final CNF - Der Report umfaßt nicht zwingend das gesamte Portfolio des BKV. Einzelne inkonsistente oder von der Gegenseite nicht übermittelte Fahrpläne können im Intermediate CNF-Report fehlen, sie werden ggf. dem BKV in einem separaten ANO-Report unter Angabe des konkreten Fehlers übermittelt. In der DayAhead- Phase werden Fahrpläne, die nur von einer Seite empfangen wurden, weder im CNF-, noch im ANO-Report dem BKV übermittelt. - Der Intermediate CNF-Report kann geänderte (modified) oder ergänzte (imposed) Zeitreihen enthalten. - Der Report umfaßt das gesamte Portfolio des BKV. Die übermittelten Zeitreihen sind verbindlich und werden für die Bilanzkreisabrechnung herangezogen. Der Status A07 weist beim Final CNF-Report darauf hin, daß mindestens eine der enthaltenen Zeitreihen durch den ÜNB geändert (modified) oder ergänzt (imposed) wurde. 5.3 Glossar Gegenbestätigte Zeitreihe: Für einen BKV gilt eine Zeitreihe als gegenbestätigt (=abrechnungsrelevant), wenn Ihm diese Zeitreihe vom ÜNB in einem Confirmation Report übermittelt wurde. Innerhalb des Confirmation Reports kann diese Zeitreihe als Confirmed TS in unveränderter oder modifizierter Form oder als Imposed TS übermittelt werden. Gegenbestätigte Zeitreihen (Fahrpläne) sind für den ÜNB ebenfalls abrechnungsrelevant, im Fall regelzonenüberschreitender gegenbestätigter Fahrpläne zusätzlich auch regelsollrelevant. Regelzonenüberschreitende Fahrpläne werden im Ergebnis eines CAS-Checks automatisch oder manuell gegenbestätigt. Akzeptierte Zeitreihe: Eine Zeitreihe erhält den Status Akzeptiert (accepted) wenn sie in einer ESS Nachricht enthalten war, die in einem ACK mit dem Reason Code A01 (Message fully accepted) bestätigt wurde. Sie wird vom ÜNB für die weitere Abstimmung verwendet.

16 Konzept zum Datenaustausch Literatur [1] EIC; The ETSO Identification Coding Scheme, A common Identification System for the electricity Industry, Version 2 Release 1; , [2] ESS; ETSO Scheduling System; Implementation Guide, Version 2 Release 3, vom , [3] ESS; ETSO Scheduling and Settlement System; Code List, Version 2 Release 0; vom [4] TransmissionCode 2003; Netz und Systemregeln der deutschen Übertragungsnetzbetreiber; August 2003; Verband der Netzbetreiber e.v. beim VDEW; Berlin; [5] TransmissionCode 2003; Netz und Systemregeln der deutschen Übertragungsnetzbetreiber - Anhänge -; August 2003; Verband der Netzbetreiber e.v. beim VDEW, Berlin; [6] Fahrplananmeldung in Deutschland mit Hilfe des ESS; Version 1 Release 0; vom ; Verband der Netzbetreiber e.v. beim VDEW, Berlin; [7] StromNZV; Verordnung über den Zugang zu Elektrizitätsversorgungsnetzen; (Stromnetzzugangsverordnung StromNZV); vom ;