Drucken

Redispatch 2.0: Ergebnisse der BNetzA-Konsultation der EDIFACT und XML-Datenformate

Die Beschlusskammer 6 der Bundesnetzagentur hat die EDI@Energy-Dokumente, in denen die Anpassungen für die Umsetzung der drei Festlegungen zu den Redispatch-Maßnahmen 2.0 vorgenommen wurden, am 29. Januar 2021 zur Konsultation gestellt. Die wesentlichen Entscheidungen aus der Konsultation stellt der BDEW vor.

None

© Wxin / Shutterstock

Für die Umsetzung der drei BNetzA-Festlegungen zu den Redispatch-Maßnahmen

hat der BDEW neue XML-Datenformate entwickelt sowie neue Anwendungsfälle in den EDIFACT-Formaten aufgenommen. Zeitgleich wurden die Entscheidungsbaum-Diagramme, die als Antworten für die EDIFACT-Nachrichten dienen, angepasst sowie die XML-Dokumente in die Regelungen zum Übertragungsweg integriert.

XML-Datenformate

Für die Umsetzung der Redispatch 2.0-Prozesse wurden von der BDEW-Projektgruppe neun neue XML-Datenformate für die Konsultation der BNetzA im Februar 2021 erarbeitet und erstmalig konsultiert.

  • Stammdaten
     
  • PlannedResourceScheduleDocument
     
  • ActivationDocument
     
  • Unavailability_MarketDocument
     
  • NetworkConstraintDocument
     
  • AcknowledgementDocument
     
  • Kostenblatt
     
  • Beschaffungsvorbehalt
     
  • Beschaffungsanforderung_energetischerAusgleich

Konsultationsergebnisse

An der Konsultation haben sich 29 Unternehmen mit rund 849 Konsultationsbeiträgen beteiligt. In den beiden Konsultationssitzungen, die zusammen mit dem jeweils zuständigem BDEW-Gremium und den Konsultationseinreichern durchgeführt wurden, hat die BNetzA folgende Entscheidungen getroffen:

1) OBIS-Kennzahlen

Bei der Umsetzung der Redispatch 2.0-Prozesse hat die PG EDI@Energy bei der Übermittlung der Einzel- und Summenzeitreihen für die Ausfallarbeit, dem Fahrplananteil, bei Solar und bei Wind auf die Verwendung der OBIS-Kennzahl verzichtet. Stattdessen wurden Codes für diese Medien verwendet. Diese Entscheidung beruht darauf, dass in der entsprechenden DIN keine OBIS-Kennzahlen für diese Zwecke vorgesehen sind und damit auch klargestellt wird, dass OBIS-Kennzahlen nur bei Werten, die gemessen werden können, zur Anwendung kommen.

Die BNetzA konnte dieser Entscheidung folgen.

2) Rückführung von Antwortcodes aus den Entscheidungsbaum-Diagrammen in die Formate

Insbesondere für die Prozesse zur Stammdatenänderung wurde im Rahmen der Konsultation gefordert, die Codelisten aus dem Dokument „Entscheidungsbaum-Diagramme und Codelisten“ zurück in die UTILMD zu überführen, da die Codelisten aufgrund der schwierigen Zuordnung zu einer hohen Anzahl an Fehlerkorrekturen geführt haben und wahrscheinlich weiter führen werden. Da die Änderung erst zum 1. April 2021 umgesetzt wird, hat die BNetzA eine Rückführung in die Formate abgelehnt.

3) Splittung der Lastgänge

Durch die Aufnahme der neuen Anwendungsfälle für die Redispatch-Zeitreihen und die Übermittlung von meteorologischen Daten ist auch die Splittung des bisherigen Lastgangs „Messwert Lastgang (Strom)“ in „Lastgang Messlokation, Netzkopplungspunkt“ sowie „Lastgang Marktlokation, Tranche“ vorgenommen worden. In den Konsultationsbeiträgen ist gefordert worden, diese Aufteilung wieder rückgängig zu machen, da durch die zusätzliche Vorgabe in den „Allgemeinen Festlegungen“ zum sortenreinen Versand der MSCONS-Nachrichten, die Möglichkeit wegfällt die Werte für Messlokationen und Marktlokationen zusammen in einer MSCONS-Datei zu übermitteln. Die BNetzA entscheidet nach eingehender Diskussion, dass die Aufteilung der Lastgänge beibehalten wird, da der Versand einer weiteren Nachricht für die Marktteilnehmer zumutbar sei.

4) Stammdatensynchronisation

Einige Konsultationsbeiträge hätten sowohl in den Formaten als auch in den Entscheidungsbaum-Diagrammen zu Änderungen geführt. Aufgrund der kontroversen Diskussion dieser Punkte stellt die BNetzA nochmals klar, dass aus fachlicher Sicht, der Prozess der Stammdatensynchronisation immer zu Ende geführt werden muss. Aus dieser Klarstellung resultieren folgende Anpassungen:

- Alle Verarbeitbarkeitsprüfungen-Prüfungen im UTILMD AHB Stammdatenänderung sind in dem Anwendungsfall 11186 vom ÜNB nicht anzuwenden.

- Im UTILMD AHB Stammdatenänderung werden im Anwendungsfall 11187 die Muss-Datenelemente auf Soll mit der Bedingung gesetzt werden, dass sie anzugeben sind, wenn dem ÜNB diese Daten vom LF gesendet wurden.

- Aufnahme der sich aus den Bedingungen des Anwendungsfalls 11186 ergebenden Prüfungen als Prüfschritte in die Entscheidungsbaum-Diagramme zur Stammdatensynchronisation und zur Information über die Zuordnung einer Marktlokation zur Datenaggregation durch den ÜNB.

Da diese Änderungen sehr umfangreich sind, wird die Veröffentlichung des EDI@Energy-Dokuments „Entscheidungsbaum-Diagramme und Codelisten“ dreistufig erfolgen.

Stufe 1

Veröffentlichung einer konsolidierten Lesefassung mit Fehlerkorrekturen des EDI@Energy-Dokuments „Entscheidungsbaum-Diagramme und Codelisten“ am 31. März 2021. In dieser Fehlerkorrektur wird in den EBD E_0453 und E_0455 der Antwortcode A99 „Ablehnung Sonstiges“ wieder aufgenommen, so dass dessen Nutzung nicht wie bisher vorgesehen am 1. April 2021 endet. Bei der Nutzung des Codes ist dann in der UTILMD die Begründung im FTX-Segment als Freitext anzugeben.

Die Umsetzung erfolgt zum 1. April 2021.

Stufe 2

Am 1. April 2021 wird das EDI@Energy-Dokument „Entscheidungsbaum-Diagramme und Codelisten“ als Ergebnis der Konsultation veröffentlicht, in dem aber die beiden EBD zur Stammdatensynchronisation und zur Information über die Zuordnung einer Marktlokation zur Datenaggregation durch den ÜNB noch nicht enthalten sind. Alle anderen EBD und Codelisten sind aber in dem Zustand, in dem sie ab dem 1. Oktober 2021 produktiv genutzt werden müssen.

Stufe 3

Bis spätestens zum 1. Mai 2021 wird das EDI@Energy-Dokument „Entscheidungsbaum-Diagramme und Codelisten“ erneut veröffentlicht, in dem sind die beiden EBD zur Stammdatensynchronisation und zur Information über die Zuordnung einer Marktlokation zur Datenaggregation durch den ÜNB um alle neuen Prüfungen ergänzt und der Code A99 „Ablehnung Sonstiges“ ist nicht mehr enthalten. Somit enthält das Dokument in dieser Version alle Konsultationsergebnisse.

Am 1. April 2021 werden das UTILMD AHB Stammdatenänderung und das APERAK/CONTRL AHB mit den Änderungen der Bedingungen bzw. der Präzisierung der APERAK-Prüfung veröffentlicht.

5) Zeitpunktangaben in der MSCONS

In der Konsultationsversion des MSCONS AHB sind Präzisierungen zur Interpretation der Datumsangaben von Zählerständen vorgenommen worden. Hierzu gab es sehr unterschiedliche Konsultationsbeiträge. Einige haben die vorgenommene Ergänzung begrüßt, andere wollten gerne die Uhrzeit bei den Zählerständen mit angegeben haben. Auch gab es Diskussionen dazu, ob es sich bei der Datumsangabe um den Beginn des Tages oder das Ende des Tages handelt. Des Weiteren wurde angeregt, dem Beispiel der XML-Datenformate zur folgen und die Zeitangaben in den EDIFACT-Formaten ebenfalls auf UTC-Zeit umzustellen. Nach eingehender Diskussion mit den Konsultationsteilnehmern hat die BNetzA folgendes entschieden:

- Bei allen Ablesungen mit dem Code MRV (Turnusablesung, Zwischenablesung und Abgrenzung) ist bei der Datumsangabe das Ende des Tages zu verstehen.

- In allen EDIFACT-Formaten erfolgt die Umstellung auf UTC-Zeit für alle Zeitpunkte und für Zeiträume, wenn diese mittels zweier DTM-Segmente definiert werden. Die Anpassung der Formate erfolgt für die Konsultation am 1. August 2021 und die Umsetzung im Markt, dem Änderungsmanagement entsprechend, am 1. April 2022. Eine erste Information zur Einführung der UTC-Zeit wird in die MSCONS zum 1. April 2021 aufgenommen.

6) Abwärtskompatibilität der XML-Datenformate

Bei der Erarbeitung der XML-Datenformate hat die PG Redispatch XML-Datenformate auf die Abwärtskompatibilität zu Bestandsformaten der System Operation Guideline (SO GL) und des harmonisierten Aktivierungsprozesses (HAP) geachtet. Dies betrifft das PlannedResourceScheduleDocument, ActivationDocument, Unavailability_MarketDocument und AcknowledgementDocument. Bis zu einer mittelfristigen Zusammenführung von SO GL und Redispatch 2.0 kann durch die Abwärtskompatibilität eine Validierung der SO GL und HAP-Nachrichten gegen die entsprechenden Redispatch 2.0-Formate ermöglicht werden. Die BNetzA kann diesem vorgeschlagenen Vorgehen folgen und lehnt somit die Konsultationsbeiträge, anhand derer feste Einschränkungen die Abwärtskompatibilität der Bestandsformate gebrochen werden würden, ab. Es wird zudem diesbezüglich festgehalten, dass die jetzt konsultierten XML-Datenformate nicht mehr nachträglich zur Wahrung der Abwärtskompatibilität umstrukturiert werden, sofern in Zukunft in den SO GL-Formaten die Struktur und Inhalte geändert werden.

7) Wechselwirkungen Redispatch-Bilanzierung

Im Rahmen der Konsultation der XML-Datenformate wird gefordert, das ActivationDocument für die Abstimmung der Fahrpläne zum Bilanzausgleich zwischen Bilanzkreisverantwortlichen (des anfordernden Netzbetreibers und des Lieferants) um die Angabe der Energiemengen zu erweitern. Die aktuell beschriebenen Prozesse für den Redispatch 2.0 beinhalten jedoch nicht klar den Schritt zur Abstimmung von Energiemengen für den bilanziellen Ausgleich.

Die BNetzA folgt der Empfehlung der BDEW-PG Redispatch XML-Datenformate, diese prozessuale Lücke zunächst fachlich zu klären und lehnt es ab, die Abstimmung der Fahrpläne zum Bilanzausgleich aktuell über das ActivationDocument zu lösen. Die prozessuale Klärung diesbezüglich solle durch den BDEW mitgenommen werden und durch Prozessexperten aufbereitet werden, um es im Anschluss in den Formaten berücksichtigen zu können.

8) Neue Struktur der XML-Stammdaten

In Konsultationsbeiträgen wird im Rahmen der Konsultation zu den XML-Datenformaten gefordert, die Angabe von Tranchen in den Stammdaten zu ermöglichen und aufgrund der Tranchen mehrere Lieferanten unter den technischen Ressourcen zuzuordnen.

Zur Einbindung der Tranchen und für einen klareren Aufbau der Stammdaten hat die BDEW-PG Redispatch XML-Datenformate eine Umstrukturierung des Stammdatenformats vorbereitet. Diese führt nun die speziellen Informationsbedarfe je Ressource nach dem folgenden Prinzip auf und ermöglicht eine eindeutigere Referenz zu möglicherweise enthaltenen Ressourcen je Objekt:

  • Dokumentenkopf
     
  • Objekt der steuerbaren Ressource (SR)

    • Enthaltene technische Ressourcen (TR)

    - Enthaltene Tranchen
     
  • Objekt der Clusterressource (CR)

    • Enthaltene Referenzen zu den Objekten der SR, CR, SG
     
  • Objekt der Steuergruppe (SG)

    • Enthaltene Referenzen zu den Objekten der SR Die BNetzA genehmigt in der Konsultationssitzung die Umstrukturierung der Stammdaten.

Die BNetzA entscheidet ferner, dass einer technischen Ressource immer nur eine MaStR-Nr. (Häufigkeit 0..1) zugeordnet werden kann und nicht mehr als eine MaStR-Nr. (Häufigkeit 0..unbounded).

Veröffentlichung und Umsetzung

Gemäß dem Änderungsmanagement erfolgt die Veröffentlichung der entgültigen EDI@Energy-Dokumente am 1. Aptil 2021 auf der Seite der Bundesnetzagentur sowie im BDEW-Forum Datenformate. Die Umsetzung im Markt erfolgt am 1. Oktober 2021.

Infotage

Zur Unterstützung unserer Mitgliedsunternehmen werden folgende BDEW-Informationstage zu den Datenformaten angeboten:

  • „EDI@Energy - Das Format UTILMD“ am 27. April 2021, Online
     
  • „EDI@Energy - Das Format MSCONS“ am 28. April 2021, Online
     
  • „Die neuen XML-Formate – Umsetzung der Redispatch-Prozesse“ am 29. April 2021, Online

Suche