Implementation Guidelines 2021 - Connect+
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
1
2021
2
Implementation
Guidelines
Version: 2.0
RAIDA-Release: R4
Datum: 28.05.2021
Entwurf
3
Änderungshistorie
Version Status Datum Beschreibung
Qualitätssicherung • Aktueller Entwurf zur Review und Qualitätssicherung durch die Connect+-Test-
0.9 03.03.2021
durch Testnutzer nutzer
Erste Veröffentli- o
1.0 28.03.2021
chung für Release 3
• Thema ACK - Kapitel 3.5
o „Zurückhaltung von ACK“ erläutert
• Thema Paketierung- Kapitel 3.6
o Vorgaben und Empfehlungen zur Paketierung von Nachrichten für
Bewegungsdaten ergänzt
• Thema ANB-EIV-Wechsel- Kapitel 3.6
o Vorgehen zur Meldung von EIV- oder ANB-Wechsel ergänzt (Bedarf
ggfs. einer Aktualisierung gem. BDEW-Vorgaben)
• Thema Base-Client und XML-Excel-Konverter – Kapitel 4.5
o Kapitel gem. Vorgaben aus Benutzerhandbuch angepasst
Update für Release • Thema Sonderfälle Kommunikation:
2.0 28.05.2021
4 für Tester o Sonderfälle in der Kommunikation (Zwischengeschalteter Dienstleis-
ter oder mehrerer Interne Systeme eines PTN) erläutert.
• Thema Übersicht relevanter Dokumente – Anhang A
o Verweis auf relevante Dokumente und Veröffentlichungen auf aktu-
ellen Stand gebracht
• Thema Prüfregeln – Anhang C
o Prüfregeln auf alle Datenaustausch über Planungsdaten hinaus er-
weitert
• Veröffentlichung eines neuen XSD - Schemas für die RAIDA - Rückmeldung der
Stammdaten (STADA/R) Anhang B
▪ Hinweis zu neuem STADA/R-XSD ergänzt
4
5 Disclaimer
6 Bei diesem Dokument handelt es sich um eine Dokumentation der Funktionalitäten sowie der fachli-
7 chen und technischen Anforderungen zur Nutzung des IT-System RAIDA, welches im Rahmen des Pro-
8 jektes Connect+ entwickelt wird.
9 Die Implementation Guidelines spiegeln den aktuellen Stand der laufenden RAIDA-Softwareentwick-
10 lung wider und beziehen sich auf den entsprechenden Stand des Regelwerks zum Redispatch2.0 aus
11 den aktuellen BDEW- und BNetzA-Veröffentlichungen [ (1), (2), (3)].
12 Änderungen in den Redispatch2.0-Anforderungen sowie Anpassungen in der Softwareentwicklung
13 werden Anpassungen in den Implementation Guidelines in Form aktualisierter Versionen erforderlich
14 machen und werden nachgeführt.
15 Die Implementation Guidelines werden den RAIDA-nutzenden Prozessteilnehmern als unverbindliche
16 Hilfestellung für die Implementierung der RAIDA-Gegenstelle bereitgestellt und haben zum jetzigen
Version: 2.0 RAIDA-Release: R4 Seite 1 von 65 Stand: 28.05.2021
Entwurf
17 Zeitpunkt keinen Anspruch auf Aktualität und Vollständigkeit. Vor diesem Hintergrund wird keine Ga-
18 rantie für die Konsistenz der Inhalte der Implementation Guidelines mit den Vorgaben aus den BDEW-
19 und BNetzA- Veröffentlichungen [ (1), (2), (3)] übernommen.
20
21 Kontakt
22 Bei Fragen oder Hinweisen zu diesem Dokument wenden Sie sich bitte an:
23 Name: Andreas Schlesier
24 Email: schlesier.andreas@swm.de
25
Version: 2.0 RAIDA-Release: R4 Seite 2 von 65 Stand: 28.05.2021
Entwurf
26 1 Inhaltsverzeichnis
27 2 Einleitung und Ziele des Dokumentes ............................................................................................. 5
28 2.1 Das Netzbetreiberprojekt „Connect+“ .................................................................................... 5
29 2.2 Ziele und Adressaten des Dokumentes ................................................................................... 7
30 2.3 Erläuterung NKK und PVK ........................................................................................................ 8
31 3 RAIDA-Datenaustausche und funktionale Anforderungen ............................................................. 9
32 3.1 Einordnung von RAIDA im Redispatch 2.0-Prozess ................................................................. 9
33 3.2 Übersicht der Zusatzleistungen ............................................................................................. 12
34 3.3 Überblick über die von RAIDA abgedeckten RD2.0-Use Cases ............................................. 14
35 3.3.1 Datenaustausch im PVK (EIV/LF – NB) .......................................................................... 14
36 3.3.2 Datenaustausche im NKK (NB – NB) .............................................................................. 15
37 3.3.3 Optionaler PVK-UC: Übermittlung einer Stammdaten-Rückmeldung vom ANB an den
38 EIV 17
39 3.4 Überblick der über RAIDA ausgetauschten Datenformate ................................................... 18
40 3.5 ACK-Prozess ........................................................................................................................... 20
41 3.5.1 Ausgang von ACK-Dokumenten..................................................................................... 20
42 3.5.2 Eingang von ACK-Dokumenten...................................................................................... 21
43 3.5.3 Rückhaltung von ACK-Dokumenten bei der Weiterleitung von Abruf(-informationen)
44 im PVK-Datenaustausch ................................................................................................................ 21
45 3.6 Grundsätze im Datenaustausch mit RAIDA ........................................................................... 22
46 4 Technische Anforderungen für die Kommunikation mit RAIDA.................................................... 26
47 4.1 Allgemeine Regelungen zum Übertragungsweg ................................................................... 26
48 4.2 Inhaltsdatensicherung ........................................................................................................... 27
49 4.3 Angebotene Schnittstellentechnologien zur Kommunikation mit RAIDA und
50 Transportverschlüsselung ................................................................................................................. 27
51 4.3.1 E-Mail............................................................................................................................. 29
52 4.3.2 SFTP ............................................................................................................................... 30
53 4.3.3 REST-Schnittstelle .......................................................................................................... 32
54 4.4 Kommunikationsdaten von RAIDA ........................................................................................ 34
55 4.5 Zusätzlich zur Verfügung gestellte und optional nutzbare Werkzeuge ................................ 34
56 4.5.1 Basis-Kommunikationsclient ......................................................................................... 34
57 4.5.2 XML-Excel-Konverter ..................................................................................................... 36
58 4.6 Trennung von Test- und Produktivsystem ............................................................................ 38
59 4.7 Sonderfälle in der Kommunikation mit RAIDA und zu berücksichtigende Aspekte .............. 38
60 4.7.1 Sonderfall 1: Ein Prozessteilnehmer mit mehreren internen Systemen kommuniziert
61 mit RAIDA: Einrichtung einer Nachrichtenweiche......................................................................... 38
62 4.7.2 Sonderfall 2: Ein Dienstleister kommuniziert im Auftrag mehrerer PTN mit RAIDA..... 39
Version: 2.0 RAIDA-Release: R4 Seite 3 von 65 Stand: 28.05.2021
Entwurf
63 4.8 Allgemeine Vorgaben zur Registrierung, zum Testbetrieb und Fristen ................................ 40
64 5 Betriebliche Rahmenbedingungen für die Nutzung von RAIDA .................................................... 41
65 6 Verzeichnis der relevanten Veröffentlichungen ........................................................................... 42
66 Anhang A: Übersicht relevanter Dokumente/Dateien .......................................................................... 43
67 Anhang B: Beschreibung des optionalen Use Cases „Übermittlung einer Stammdaten-Rückmeldung
68 vom ANB an den EIV“ ............................................................................................................................ 46
69 Anhang C: RAIDA-spezifische Reason-Codes für ACK-Rückmeldungen je Dokumententyp ................. 48
70
71 Abkürzungsverzeichnis
Abkürzung Bedeutung
ACK Acknowledgement-Meldung (Automatisierte Empfangsbestätigung)
ANB Anschlussnetzbetreiber
BKV Bilanzkreisverantwortlicher
bNB betroffener Netzbetreiber
cNB clusternder Netzbetreiber
CR Clusterressource
EIV Einsatzverantwortlicher
LF Lieferant
NB Netzbetreiber
NKK Netzbetreiberkoordinationskonzept
PTN Prozessteilnehmer
PVK Postverteilkonzept
Bezeichnung des IT-Systems von Connect+ für den
RAIDA
Redispatch-2.0-Datenaustausch
RD2.0 Redispatch 2.0
SG Steuergruppe
SR Steuerbare Ressource
TR Technische Ressource
72
Version: 2.0 RAIDA-Release: R4 Seite 4 von 65 Stand: 28.05.2021
Entwurf
73 2 Einleitung und Ziele des Dokumentes
74 2.1 Das Netzbetreiberprojekt „Connect+“
75 Mit der Novellierung des Netzausbaubeschleunigungsgesetzes (NABEG 2.0) im Jahr 2019 werden die
76 Regelungen zum Einspeisemanagement von EE- und KWK-Anlagen in EEG und KWKG zum 01.10.2021
77 aufgehoben und in ein einheitliches Redispatchregime („Redispatch 2.0“) überführt. Dies bedeutet,
78 dass zukünftig auch EE-Anlagen und KWK-Anlagen ab 100 kW sowie Anlagen, die jederzeit durch einen
79 Netzbetreiber (NB) fernsteuerbar sind, in den planwertbasierten Redispatch einbezogen werden müs-
80 sen. Damit sind für alle Netzbetreiber aber auch für Erzeuger, Direktvermarkter, Einsatzverantwortli-
81 che (EIV) und Lieferanten (LF) neue Aufgaben verbunden.
82 Die prozessualen Rahmenbedingungen für den notwendigen Stamm- und Planungsdatenaustausch
83 zwischen Marktteilnehmern und Netzbetreibern sowie die entsprechenden Datenbedarfe wurden im
84 November 2020 von der Bundesnetzagentur unter dem Aktenzeichen BK6-20-059 (2) festgelegt. Die
85 Redispatch-2.0 Datenaustauschprozesse und Datenbedarfe an der Schnittstelle zwischen Netzbetrei-
86 bern im Rahmen der sog. Netzbetreiberkoordinationskonzept (NKK) werden im BDEW-Projekt „Redis-
87 patch 2.0“ erarbeitet und werden in der Anwendungshilfe -Detailprozesse für die Netzbetreiberkoor-
88 dination im Redispatch 2.0 (1) dokumentiert.
89 Die weiteren BNetzA-Festlegungen zum „Festlegungsverfahren zur Netzbetreiberkoordinierung bei
90 der Durchführung von Redispatch-Maßnahmen“ (4) vom 12.03.2021 sowie zum „Festlegungsverfahren
91 zur Informationsbereitstellung für Redispatch-Maßnahmen“ (5) vom 23.03.2021 ergänzen das Regel-
92 werk zu den fachlichen RD2.0-Vorgaben und sind ebenfalls zu berücksichtigen.
93
94 A BBILDUNG 1: E INORDNUNG DES PROJEKTES CONNECT+
Version: 2.0 RAIDA-Release: R4 Seite 5 von 65 Stand: 28.05.2021
Entwurf
95 Aufbauend auf den von der BNetzA festgelegten Datenaustauschprozessen und -formaten hat das
96 Netzbetreiberprojekt Connect+ die operative Umsetzung des für alle Redispatch-Prozesse erforderli-
97 chen Datenaustauschs zum Ziel.
98 Im Rahmen dieser Kooperation entwickeln die vier Übertragungsnetzbetreiber und aktuell 17 Verteil-
99 netzbetreiber das IT-System „RAIDA“, welches alle betroffene Marktteilnehmer und Netzbetreiber mit
100 einheitlichen, marktüblichen Schnittstellen für den gesamten deutschlandweiten Datenaustausch nut-
101 zen können. Anschlussnetzbetreiber können ihre originäre Funktion als verantwortlicher "Data-Provi-
102 der" (siehe BNetzA Az. BK6-20-059 (2)) an Connect+ übertragen. In diesem Fall übernimmt RAIDA den
103 operativen Datenaustausch mit allen weiteren betroffenen Akteuren.
104 Zu den grundlegenden Aufgaben und Funktionen des RAIDA-Systems zählen:
105 • Datenaustausch
106 Performant und sicher durch Umsetzung der in den EDI@Energy Regelungen zum Übertragungs-
107 weg (RzÜ) (3) vorgegebenen Verschlüsselungs- und Signierungsverfahren.
108 • Kommunikation via SPOC (single point of contact)
109 Jeder Prozessteilnehmer - angefangen beim Anschlussnetzbetreiber - kommuniziert nur mit
110 RAIDA. Es müssen keine weiteren Schnittstellen für die Kommunikation eingerichtet werden. Es
111 wird somit ein deutschlandweiter regelzonenübergreifender SPOC realisiert.
112 Jeder Prozessteilnehmer kann dabei seine bevorzugte Schnittstellentechnologie (gemäß RzÜ) nut-
113 zen. Die von RAIDA angebotenen Schnittstellentechnologien sind E-Mail, SFTP und REST-Webser-
114 vice (optional mithilfe des Basis-Kommunikationsclients)
115 • Datenversorgung
116 Automatisierte, regelbasierte und kontextabhängige Versorgung aller Prozessteilnehmer mit den
117 eingehenden Daten; der Datensender muss nicht wissen und vorgeben, welcher Dateninhalt an
118 welche Prozessteilnehmer zu liefern ist; RAIDA übernimmt diese Aufgabe anhand des Regelwerks
119 gemäß der in Anlage 2 zum „Festlegungsverfahren zum bilanziellen Ausgleich von Redispatch-
120 Maßnahmen (2) und Anwendungshilfe – Detailprozesse für die Netzbetreiberkoordination im
121 Redispatch 2.0 (1) definierten Prozesse sowie den in den Ressourcen-Stammdaten hinterlegten
122 betroffenen und berechtigten Prozessteilnehmern. Jeder Prozessteilnehmer bekommt dabei nur
123 die Daten, zu deren Empfang er auch berechtigt ist.
124 • Datenqualität
125 RAIDA übernimmt die formale und soweit möglich und sinnvoll die inhaltliche Prüfung der einge-
126 henden Daten; fehlerhafte Meldungen werden direkt abgewiesen und zurückgemeldet, sodass nur
127 von RAIDA validierte Daten zu den Prozessteilnehmern gelangen.
128 • Hohe Verfügbarkeit
129 Zur Gewährleistung einer hohen Verfügbarkeit ist das Hosting des RAIDA-Systems mehrfach re-
130 dundant ausgelegt. Das Hosting wird durch zwei Netzbetreiber verantwortet, sodass mindestens
131 die Branchenstandards an IT-Sicherheit und Verfügbarkeit eingehalten werden.
132 • Geringe Einstiegsbarrieren
133 Es wird optional ein Basis-Kommunikationsclient und ein Excel-XML-Konvertierungstool angebo-
Version: 2.0 RAIDA-Release: R4 Seite 6 von 65 Stand: 28.05.2021Entwurf
134 ten. Für Unternehmen, welche nicht über ausreichend Kapazitäten zur Implementierung einer ei-
135 genen Schnittstelle oder die eigene Generierung von XML-Daten verfügen, wird hiermit die Ein-
136 stiegshürde zur Nutzung von RAIDA verringert.
137 RAIDA dient allein dem Austausch von Prozessdaten (Stamm- und Bewegungsdaten) zwischen den
138 Marktrollen im Rahmen der RD2.0-Prozesse. Explizit nicht Teil der von RAIDA angebotenen Funktiona-
139 litäten sind zum aktuellen Zeitpunkt:
140 • Generierung bzw. Erhebung von Redispatch-Daten
141 • Steuerung von Redispatchanlagen oder jedweder Betriebsmittel
142 • Austausch von Basisdaten für den Bilanzierungs- und Abrechnungsprozess
143 • Austausch von Echtzeitdaten
144 • Austausch von Netzdaten und Betriebsmitteldaten
145
146 A BBILDUNG 2: Ü BERSICHT ZU DEN DURCH CONNECT+ ABGEDECKTEN AUFGABEN
147
148 2.2 Ziele und Adressaten des Dokumentes
149 Das vorliegende Dokument hat den Anspruch, den Nutzern des RAIDA-Systems als Implementierungs-
150 hilfe für die Umsetzung ihrer internen Gegenstelle zu dienen.
151 Die „Implementation Guidelines“ richten sich an alle RAIDA-nutzenden Prozessteilnehmer und sollen
152 eine Dokumentation der fachlichen Einordnung des RAIDA-Systems und aller angebotenen Funktiona-
153 litäten bieten. Zusätzliche Dokumente, welche für die Umsetzung des Redispatch-Basisdatenaustau-
154 sches relevant sind, werden an den entsprechenden Stellen in diesem Dokument referenziert.
155 Die fachlichen und prozessualen Anforderungen werden in Kapitel 3 aufgeführt. Kapitel 4 gibt den Ent-
156 wicklern der an RAIDA angebundenen End-2-End-Systeme einen Überblick der technischen Anforde-
157 rungen und IT-Sicherheitsstandards.
Version: 2.0 RAIDA-Release: R4 Seite 7 von 65 Stand: 28.05.2021Entwurf
158 Das vorliegende Dokument spiegelt den aktuellen Arbeitsstand im laufenden Projekt Connect+ wider.
159 Demzufolge können sich einzelne Spezifikationen im Laufe des Projektes ändern. Aus diesem Grund
160 sind die Implementation Guidelines als „lebendes Dokument“ zu verstehen, zu welchem für die Dauer
161 der Entwicklungsphase kontinuierliche Updates mit entsprechenden Anpassungen, Korrekturen und
162 Erweiterungen veröffentlicht werden. Insbesondere sollen hier auch die Erfahrungen, die Connect+
163 mit den Testnutzern im Rahmen der Testphase gewinnt, mitberücksichtigt werden.
164 2.3 Erläuterung NKK und PVK
165 Im Kontext des Redispatch-Prozesses wird zwischen Postverteilkonzept (PVK) und Netzbetreiberkoor-
166 dinierung (NKK) unterschieden. Das PVK umfasst sämtliche Prozesse welche Datenaustausche zwi-
167 schen Marktteilnehmern und Netzbetreibern enthalten. Das NKK umfasst Prozesse, welche Datenaus-
168 tausche allein zwischen Netzbetreibern untereinander beschreibt.
169 Abbildung 3 bietet eine Übersicht über die Datenaustausche im PVK und NKK. Prozessteilnehmer
170 können RAIDA für den Austausch sämtlicher hier aufgeführter Datenaustausche nutzen (blaue
171 Pfeile).
172
173 A BBILDUNG 3: Ü BERSICHT DER D ATENAUSTAUSCHE IM PVK UND NKK
174 Im nachfolgenden Dokument sind sämtliche referenzierte Dokument fett gekennzeichnet. Einen Über-
175 blick über diese Dokumente bietet Anhang A. In dieser Übersicht, sowie allgemein in diesem Doku-
176 ment, sind auch die Veröffentlichungen, unter welchen man sämtliche referenzierte Dokumente fin-
177 det, in Kapitel 6 verlinkt.
Version: 2.0 RAIDA-Release: R4 Seite 8 von 65 Stand: 28.05.2021Entwurf
178 3 RAIDA-Datenaustausche und funktionale Anforderungen
179 3.1 Einordnung von RAIDA im Redispatch 2.0-Prozess
180 Die Marktrolle des Data-Providers ist gemäß Anlage 2 des Festlegungsverfahren zum bilanziellen Aus-
181 gleich von Redispatch-Maßnahmen wie folgt festgelegt:
182 „Der Data-Provider empfängt und übermittelt Informationen. Hinweis: Der ANB nimmt die
183 Rolle des Data-Providers wahr, sofern er die Rolle nicht an einen Dritten übergibt.“
184 Das IT-System RAIDA hat den Anspruch, die Funktionen des Data-Providers als „Single Point of Contact“
185 abzubilden und zu übernehmen. Die prozessualen Rahmenbedingungen der Rolle Data-Provider bilden
186 an der Schnittstelle zwischen Netzbetreiber und Marktteilnehmer (PVK-Datenaustausch) die Vorgaben
187 aus dem o.g. Dokument Anlage 2 des Festlegungsverfahren zum bilanziellen Ausgleich von Redis-
188 patch-Maßnahmen. An der Schnittstelle zwischen Netzbetreibern untereinander (NKK-Datenaus-
189 tausch) erfüllt RAIDA die Aufgabe des Data-Providers gemäß den prozessualen Vorgaben der Anwen-
190 dungshilfe – Detailprozesse für die Netzbetreiberkoordination im Redispatch 2.0.
191 Die wesentliche Aufgabe von RAIDA besteht darin, Daten von den beteiligten Prozessteilnehmern ent-
192 gegenzunehmen, diese zu validieren und die darin befindlichen Inhalte an die zuständigen, berechtig-
193 ten und betroffenen Prozessteilnehmer zu versenden.
194 Entsprechend der Vorgaben der Redispatch-2.0-Prozesse erlaubt RAIDA somit die Weiterleitung fol-
195 gender RD2.0-Prozessdaten im Rahmen der in Kapitel 3.3 aufgeführten Use Cases:
196 • RD2.0-Stammdaten
197 • Planungsdaten
198 • Probeplanungsdaten für Prognoseprüfung1
199 • Nichtbeanspruchbarkeiten
200 • Flexibilitätsbeschränkungen
201 • Marktbedingte Anpassungen
202 • Abrufaufforderungen im Aufforderungsfall und Abrufinformationen
203 • Sensitivitäten
204 • Kostenblätter
205 • Beschaffungsvorbehalten
1
Der Datenaustausch „Probeplanungsdaten für Prognosegüten“ wird in der Veröffentlichung „____“ beschrie-
ben
Version: 2.0 RAIDA-Release: R4 Seite 9 von 65 Stand: 28.05.2021Entwurf
206 • Beschaffungsanforderungen
207 RAIDA bietet Funktionalitäten für den Datenaustausch für die folgenden gemäß Anlage 2 des Festle-
208 gungsverfahren zum bilanziellen Ausgleich von Redispatch-Maßnahmen definierten Marktrollen,
209 welche im Folgenden immer als Prozessteilnehmer bezeichnet werden:
210 • EIV: Einsatzverantwortlicher
211 • LF: Lieferant
212 • NB: Netzbetreiber
213 Auf der Objektebene erlaubt Connect+ die Weiterleitung von Daten für die folgenden in Anlage 2 des
214 Festlegungsverfahren zum bilanziellen Ausgleich von Redispatch-Maßnahmen bzw. in der Anwen-
215 dungshilfe – Detailprozesse für die Netzbetreiberkoordination im Redispatch 2.0 definierten Objekte:
216 • TR: Technische Ressource
217 • SR: Steuerbare Ressource
218 • SG: Steuergruppe
219 • CR: Clusterressource
220 Abbildung 4 bietet eine Übersicht der von Connect+ abgedeckten Datenaustausche im RD2.0.
221
Version: 2.0 RAIDA-Release: R4 Seite 10 von 65 Stand: 28.05.2021222 223 A BBILDUNG 4: E INORDNUNG RAIDA IM RD2.0
Entwurf
224 3.2 Übersicht der Zusatzleistungen
225 Über die reine Weiterleitung von Redispatchdaten gemäß den Aufgaben des Data-Providers hinaus,
226 bietet RAIDA einige weitere Funktionalitäten und optionale Zusatztools, welche im Folgenden aufge-
227 führt werden:
228 Sicherstellung einer hohen Datenqualität für alle Prozessteilnehmer
229 Generell erfolgt gemäß der Prozessdefinitionen der Versand und Empfang von technischen ACKs auf
230 jede Nachricht. RAIDA bietet ein entsprechendes ACK-Management, indem alle eingehenden Nach-
231 richten validiert und mit einem eigenen ACK zurückmeldet werden und indem bei ausgehenden Nach-
232 richten die ACK-Rückmeldungen entgegengenommen und auswertet werden. Die Prüfregeln und ent-
233 sprechenden ACK-Rückgaben je Datenformat werden in nachfolgenden Versionen der Implementation
234 Guidelines nachgereicht. Der ACK-Prozess ist unter Kapitel 3.5 erläutert. Durch die Anwendung von
235 abgestimmten Prüfregeln direkt bei der Entgegennahme von Dokumenten durch RAIDA kann sicher-
236 gestellt werden, dass nur geprüfte und valide Dokumente weiterverteilt werden.
237 Stammdaten-Rückmeldung vom ANB an den EIV
238 RAIDA gibt einem ANB die Möglichkeit, eine Stammdatenrückmeldung an den EIV zu geben. Die
239 Stammdatenrückmeldung gibt an, ob die vom EIV gemeldeten Stammdaten je Ressource inhaltlich ak-
240 zeptiert wurden oder ob die Stammdaten einer/mehrere Ressourcen (unter Angabe eines Ablehnungs-
241 grundes) nicht akzeptiert wurden. Dies soll den manuellen Abstimmungs- und Klärungsbedarf für alle
242 beteiligten Parteien reduzieren. Diese Funktionalität ist als PVK-Use Case näher unter Kapitel 3.3.3
243 erläutert. Die Nutzung dieser Funktionalität ist optional.
244 Message Routing und Splitting
245 Im Rahmen des Redispatch-Datenaustauschs zwischen verschiedenen Prozessteilnehmern ist es mög-
246 lich, Daten für mehrere Ressourcen, auch mit unterschiedlichen betroffenen Netzbetreibern, gebün-
247 delt in einem Dokument an RAIDA zu melden. RAIDA ist in der Lage, dieses Dokument in mehrere se-
248 parate Dokumente je Empfänger aufzuteilen bzw. zu vervielfältigen und diese an die in den Stammda-
249 ten hinterlegten berechtigten Empfänger zu versenden. Diese Dokumente erhalten jeweils eine eigene
250 DokumentID und RAIDA ist als Sender hinterlegt. Die „RefDokumentID“ verweist weiterhin auf das ur-
251 sprüngliche Dokument, so dass eine Zuordnung zu den Originalnachrichten immer möglich bleibt. Das
252 Grundprinzip des Message Routing und Splitting ist in Abbildung 5 dargestellt.
Version: 2.0 RAIDA-Release: R4 Seite 12 von 65 Stand: 28.05.2021Entwurf
253
254 A BBILDUNG 5: G RUNDPRINZIP DES MESSAGE ROUTING UND SPLITTING
255
256 Optionale Zusatztools: Basis-Kommunikationsclient und Konverter
257 Eine Anbindung an RAIDA ist grundsätzlich für drei der in den EDI@Energy –Regelungen zum Übertra-
258 gungsweg (RzÜ) beschriebenen Kommunikationstechnologien (E-Mail oder SFTP oder REST-Webser-
259 vice) möglich, wobei sich der Prozessteilnehmer auf genau eine dieser drei Kommunikationstechnolo-
260 gien festzulegen hat. Eine Anbindung per AS2 wird nicht angeboten. Jeder Prozessteilnehmer ist frei in
261 der Wahl seiner Kommunikationstechnologien und kann seine Gegenstelle eigenständig umsetzen.
262 Seitens Connect+ wird als präferierte Lösung die direkte Nutzung von REST empfohlen. E-Mail und SFTP
263 werden aus Kontinuitätsgründen angeboten.
264 Für eine vereinfachte Nutzung der REST-Schnittstelle des WebServices wird speziell für Prozessteilneh-
265 mer, welche nur begrenzt über Ressourcen zur Implementierung einer eigenen REST-Schnittstelle ver-
266 fügen, ein Basis-Kommunikationsclient angeboten, welcher nach dem Prinzip eines „Online-Drop-Ver-
267 zeichnisses“ den Datenversand und -empfang zu RAIDA ermöglicht. Hierdurch können Implementie-
268 rungsaufwände an der Gegenstelle durch die Prozessteilnehmer reduziert werden. Details werden im
269 Kapitel 4.5.1 erläutert.
270 Ein ebenfalls optional bereitgestellter XML-Excel-Konverter erlaubt es, Excel-Dateien, die ein fest vor-
271 gegebenes Format erfüllen, in die Redispatch2.0-XML-Datenformate und umgekehrt zu transformie-
272 ren. Details werden im Kapitel 4.5.2 erläutert.
Version: 2.0 RAIDA-Release: R4 Seite 13 von 65 Stand: 28.05.2021Entwurf
273 3.3 Überblick über die von RAIDA abgedeckten RD2.0-Use Cases
274 Die von RAIDA abgedeckten Use-Cases aus Anlage 2 des Festlegungsverfahren zum bilanziellen Aus-
275 gleich von Redispatch-Maßnahmen sowie aus der Anwendungshilfe – Detailprozesse für die Netzbe-
276 treiberkoordination im Redispatch 2.0 (1) werden nachfolgend in Tabelle 1 bzw. Tabelle 2 aufgelistet.
277 Die Use Cases werden ebenfalls in den Anwendungstabelle zu den jeweiligen Datenformaten aus der
278 Mitteilung Nr. 19 zu den Datenformaten zur Abwicklung der Marktkommunikation (3) referenziert.
279 Sollten sich Widersprüche zwischen den Dokumenten aus den verschiedenen BNetzA- und BDEW-Ver-
280 öffentlichungen (1) (2) (3) ergeben, hat immer das Dokument aus der aktuelleren Veröffentlichung
281 Gültigkeit.
282 Hinweis: In diesem Dokument werden einheitlich die UC-Nummerierungen und UC-Bezeichnungen gemäß BDEW genutzt.
283 Diese stimmen nicht mit der Nummerierung in älteren Connect+-Dokumenten (vor Nov. 2020) insbesondere dem Dokument
284 „Connect+: Bericht zu den initialen Anforderungen" überein. Die alte Nummerierung wird hier einmalig in den Tabellen ge-
285 nannt.
286 3.3.1 Datenaustausch im PVK (EIV/LF – NB)
287 Tabelle 1 zeigt den Datenaustausch im PVK (EIV/LF – NB) auf Basis von Anlage 2 des Festlegungsver-
288 fahren zum bilanziellen Ausgleich von Redispatch-Maßnahmen
289 T ABELLE 1: D ATENAUSTAUSCH IM PVK (EIV/LF – NB)
(veraltet)
RD2.0 Beteiligte Format- Ressour-
Bezeichnung Use Case Connect+
UC Rollen dokument2 cenebene UC-Nr.
PVK- Übermittlung initialer UC1 Schritt (#1
EIV, NB, DP Stammdaten SR
bis- #3)
UC2.1 Stammdaten
PVK- Übermittlung von angerei- UC1 (ab Schritt
NB, NB, DP Stammdaten SR
#6)
UC2.2 cherten Stammdaten
Übermittlung Stammdaten-
PVK- UC1 Schritt (#1
änderungen vom EIV (ver- EIV, DP, NB Stammdaten SR
bis- #3)
UC2.3
antwortlich) ausgehend
Übermittlung Stammdaten-
PVK- änderung vom (Anschluss- UC1 (ab Schritt
NB, NB, DP Stammdaten SR
#6)
UC2.4 )NB (verantwortlich) ausge-
hend
2
Nicht explizit aufgeführt aber in allen Datenaustauschen mit RAIDA als Empfangsbestätigung zu versen-
den/empfangen ist das AcknowledgementDocument (ACK)
Version: 2.0 RAIDA-Release: R4 Seite 14 von 65 Stand: 28.05.2021Entwurf
Planned
Resource
PVK- Übermittlung von Planungs-
EIV, NB, DP Schedule SR UC2
UC2.5 daten im Planwertmodell3 Document,
Kostenblatt
Unavailabili
PVK- Übermittlung von Nichtbe-
EIV, NB, DP ty_Market TR UC2
UC2.6 anspruchbarkeiten an NB Document
Übermittlung marktbe- Unavailabili
PVK-
dingte Anpassung im Prog- EIV, NB, DP ty_Market SR UC2
UC2.7 Document
nosemodell
Abruf im Aufforderungsfall NB, DP,
PVK- Activation
mit Delta-/Sollwertanwei- EIV, LF, SR UC6.1 + UC2
UC3.1 Document
sung (BKV)4
NB, DP, LF,
PVK- Abruf im Duldungsfall mit Activation
EIV, (BTR)2, SR UC6.2 + UC2
UC3.2 Sollwertanweisung Document
(BKV) 2
PVK-UC
zu Pro- Übertragung von Probepla-
bepla- nungsdaten für Prognosegü- EIV, NB, DP tbd SR -
nungs- teprüfung
daten
Optio- Übermittlung einer Stamm-
Stammda-
naler daten-Rückmeldung vom UC1 ( Schritt #4
NB, EIV, DP tenrückmel- SR
und #5)
PVK- ANB an den EIV dung
UC5 (siehe Kapitel 3.3.3)
290
291 3.3.2 Datenaustausche im NKK (NB – NB)
292 Tabelle 2 zeigt den Datenaustausch im NKK (NB – NB) auf Basis der Anwendungshilfe – Detailprozesse
293 für die Netzbetreiberkoordination im Redispatch 2.0
3
Über RAIDA wird ebenfalls die Übermittlung von Probeplanungsdaten für die Prognosegüteprüfung möglich
sein. Dieser Anwendungsfall ist für EIV relevant, welche sich im RD2.0-Betrieb einen Wechsel vom Prognosemo-
dell zum Planwertmodell beabsichtigen. Der Datenaustausch entspricht hierbei im Wesentlichen dem Daten-
austausch im PVK-UC2.5
4
BVK und BTR sind in den UC3.1 bzw. UC3.2 involviert. Die Datenaustausche zu diesen Marktrollen werden al-
lerdings nicht von RAIDA abgedeckt und müssen separat erfolgen.
5
Dieser Use Case ist nicht in den RD2.0-Prozessbeschreibungen vorgegeben. Es handelt sich um einen von
RAIDA angebotenen optionalen Use Case
Version: 2.0 RAIDA-Release: R4 Seite 15 von 65 Stand: 28.05.2021Entwurf
294 T ABELLE 2: D ATENAUSTAUSCHE IM NKK (NB – NB)
RD2.0- (veraltet)
Beteiligte Format- Ressour-
Use Bezeichnung Use Case Connect+
Rollen dokument6 cenebene UC-Nr.
Case
Übermittlung von initialen
NKK- NB, NB,
Cluster-Ressourcen-Stamm- Stammdaten CR, SG UC3
UC1.1 DP
daten zwischen NB mit DP
Änderung der Cluster-Res-
NKK- NB, NB,
sourcen-Stammdaten zwi- Stammdaten CR, SG UC3
UC1.2 DP
schen NB mit DP
Planned
Übermittlung Planungsdaten Resource
NKK- NB, NB,
für SR im Prognosemodell Schedule SR, CR, SG UC4.1
UC2.1 DP Document,
oder für SG, CR mit DP
Kostenblatt
Planned
Übermittlung von Sensitivitä-
NKK- NB, NB, Resource
ten zu Planungsdaten für SR, SR, CR, SG UC4.1
UC2.2 DP Schedule
SG und CR mit DP Document
Planned
Übermittlung prognostizier-
NKK- NB, NB, Resource
ter Abruf und Info über Abruf SR, CR, SG UC4.1
UC2.3 DP Schedule
über Planungsdaten mit DP Document
Network Keinem
NKK- Übermittlung Flex-Beschrän- NB, NB,
Constraint Objekt UC4.2
UC3.1 kung mit DP DP Document zuordbar7
Beschaf- Keinem
NKK- Übermittlung des Beschaf- NB, NB,
fungs- Objekt -
UC4.1 fungsvorbehalts DP vorbehalt zuordbar
Beschaf-
fungs- Keinem
NKK- Beschaffungsanforderung für NB, NB,
anforderung Objekt -
UC4.2 energetischen Ausgleich DP energ. Aus- zuordbar
gleich
Übermittlung des Abrufs ei-
NKK- NB, NB, Activation
ner steuerbaren Ressource an SR, SG UC7
UC5.1 DP Document
anweisenden NB mit DP
NKK- Abruf für eine Cluster-Res- NB, NB, Activation
CR UC7
UC5.2 source mit DP DP Document
6
Nicht explizit aufgeführt aber in allen Datenaustauschen mit RAIDA als Empfangsbestätigung zu versen-
den/empfangen ist das AcknowledgementDocument (ACK)
7
Eine Flex-Beschränkung ist keinem einzelnem RD-Objekt (TR, SR, SG oder CR) zuzuordnen. In der Flex-Be-
schränkung sind allerdings alle von dieser betroffenen TR, SR, SG und CR genannt.
Version: 2.0 RAIDA-Release: R4 Seite 16 von 65 Stand: 28.05.2021Entwurf
295
296 3.3.3 Optionaler PVK-UC: Übermittlung einer Stammdaten-Rückmeldung vom ANB an
297 den EIV
298 Über diesen Use Case hat der ANB die Möglichkeit, eine Stammdatenmeldung vom EIV (PVK-UC2.1
299 bzw. PVK-UC2.3) zu bestätigen, einen Korrekturvorschlag zu senden oder abzulehnen. Analog zu einer
300 Meldung der angereicherten Stammdaten kann der ANB unter Nutzung des Stammdatenformats eine
301 als „Rückmeldung an den EIV“ gekennzeichnete Stammdatenmeldung versenden, in der eine Ableh-
302 nung bestimmter Datensätze oder ggf. bereits Korrekturvorschläge zu den Daten an den EIV zurückge-
303 meldet werden. Eine Nutzung dieses UC kann bilateral zwischen ANB und EIV vereinbart werden, um
304 eine Vereinfachung von notwendigen Clearing-Prozessen zu erreichen. Details zur Umsetzung des UC
305 finden sich in Anhang B. Für diesen Use Case stellt Connect+ ein eigenes Datenformat „XSD ausschließ-
306 lich für Stammdatenrückmeldung ANB an EIV (Optionaler Connect+-UC)“ zur Verfügung, welches im
307 Downloadbereich der Projektwebsite zur Verfügung steht.
Version: 2.0 RAIDA-Release: R4 Seite 17 von 65 Stand: 28.05.2021Entwurf
308 3.4 Überblick der über RAIDA ausgetauschten Datenformate
309 Nachfolgend wird ein Überblick über die über RAIDA ausgetauschten Datenformate gegeben. Diese
310 entsprechen den von der BNetzA im Rahmen der Mitteilung Nr. 19 zu den Datenformaten zur Ab-
311 wicklung der Marktkommunikation (3) am 29.01.2021 veröffentlichten Datenformate.
312 Für jedes der ausgetauschten Datenformate finden sich in Mitteilung Nr.19 folgenden Dateien und
313 Begleitdokumente:
314 • XSD-Datei: Definition des XML-Formats für den jeweiligen Nachrichtentyp ((XML-Schemadefiniti-
315 onen im Format XSD). Die XSD-Schemadateien der Formate enthalten Referenzen auf weitere
316 Schemadateien der ENTSO-E, welche zur Validierung der RD2.0-Formate benötigt werden. Diese
317 umfassen Entsoe Core Components (Präfix ecc) und Entsoe Code list (Präfix ecl).
318 Diese Dateien wurden nicht als Teil der Mittelung Nr. 19 zu den Datenformate (3) mitveröffent-
319 licht, da diese Schemadateien selbst nicht im Zusammenhang des Redispatch 2.0 veröffentlicht
320 wurden. Die Dateien können der Website der ENTSO-E bezogen werden (6).
321 • Formatbeschreibung: Beschreibung der prozessualen Anwendung des XML-Formats inkl. der Da-
322 teinamenskonventionen
323 • Anwendungstabellen: Erläuterung der Elemente und Attribute in den jeweiligen Datenformaten
Hinweis:
Ergänzend zu dem in der Mitteilung Nr. 19 zu den Datenformaten zur Abwicklung der Markt-
kommunikation veröffentlichten EDI@Energy-Datenformaten stellt Connect+ zur Realisierung des
optionaler PVK-UC: „Übermittlung einer Stammdaten-Rückmeldung vom ANB an den EIV“ (Kapitel
3.3.3) ein weiteres Datenformat Stammdatenrückmeldung auf der Projektwebsite zur Verfügung.
324
Hinweis:
Bei Klärungsbedarf zu den BDEW-Datenformaten und deren Befüllung bietet die EDI@Energy auf
einem eigens einrichteten Forum die Möglichkeit Rückfragen zu stellen (9):
https://www.edi-energy.de/index.php?id=40&tx_bdew_bdew%5Bview%5D=public&tx_bdew_bdew%5Bac-
tion%5D=list&tx_bdew_bdew%5Bcontroller%5D=Frage&cHash=b897772b75abb9d311a99147147d4b3f
325
326
Format-
RD2.0-Use Case
dokument
PVK-UC2.1: Übermittlung initialer Stammdaten
PVK-UC2.2: Übermittlung von angereicherten Stammdaten
Stammdaten
PVK-UC2.3: Übermittlung Stammdatenänderungen vom EIV (verantwortlich)
ausgehend
Version: 2.0 RAIDA-Release: R4 Seite 18 von 65 Stand: 28.05.2021Entwurf
Format-
RD2.0-Use Case
dokument
PVK-UC2.4: Übermittlung Stammdatenänderung vom (Anschluss-)NB (verant-
wortlich) ausgehend
NKK-UC1.1: Übermittlung von initialen Cluster-Ressourcen-Stammdaten zwi-
schen NB mit DP
NKK-UC1.2: Änderung der Cluster-Ressourcen-Stammdaten zwischen NB mit
DP
PVK-UC2.5: Übermittlung von Planungsdaten im Planwertmodell
NKK-UC2.1: Übermittlung Planungsdaten für SR im Prognosemodell oder für
Planned CR mit DP
Resource
Schedule NKK-UC2.2: Übermittlung von Sensitivitäten zu Planungsdaten für SR und CR
Document mit DP
NKK-UC2.3: Übermittlung prognostizierter Abruf und Info über Abruf über Pla-
nungsdaten mit DP
Unavailability_ PVK-UC2.6: Übermittlung von Nichtbeanspruchbarkeiten an NB
MarketDocument PVK-UC2.7: Übermittlung marktbedingte Anpassung im Prognosemodell
Network
Constraint NKK-UC3.1: Übermittlung Flex-Beschränkung mit DP
Document
PVK-UC3.1: Abruf im Aufforderungsfall mit Delta-/Sollwertanweisung
PVK-UC3.2: Abruf im Duldungsfall mit Sollwertanweisung
Activation
Document NKK-UC5.1: Übermittlung des Abrufs einer steuerbaren Ressource an anwei-
senden NB mit DP
NKK-UC5.2: Abruf für eine Cluster-Ressource mit DP
Beschaffungs-
NKK-UC4.1: Übermittlung des Beschaffungsvorbehalts
vorbehalt
Beschaffungs-
anforderung NKK-UC4.2: Beschaffungsanforderung für energetischen Ausgleich
energ. Ausgleich
PVK-UC2.5: Übermittlung von Planungsdaten im Planwertmodell
Kostenblatt NKK-UC2.1: Übermittlung Planungsdaten für SR im Prognosemodell oder für
CR mit DP
Ackowledge-
Alle
mentDocument
To be defined Übertragung von Probeplanungsdaten für Prognosegüteprüfung
Stammdaten- Optionaler RAIDA-Use Case: Übermittlung einer Stammdaten-Rückmeldung
rückmeldung vom ANB an den EIV
327
Version: 2.0 RAIDA-Release: R4 Seite 19 von 65 Stand: 28.05.2021Entwurf
328 3.5 ACK-Prozess
329 Gemäß der Prozessdefinitionen für den RD2.0 erfolgt der Versand und Empfang von technischen ACK
330 auf jede Nachricht. RAIDA bietet ein entsprechendes ACK-Management, indem alle eingehenden Nach-
331 richten gemäß definierter Prüfregeln validiert und mit einem eigenen ACK zurückmeldet werden und
332 indem bei ausgehenden Nachrichten die ACK-Rückmeldungen entgegengenommen und auswertet
333 werden. Wenn die Prüfungen fehlschlagen, wird ein sog. „negativer ACK“ versendet. Bei erfolgreicher
334 Prüfung wird ein sog. „positives ACK“ versendet. An dieser Stelle wird darauf hingewiesen, dass
335 Connect+ keine fachliche Prüfung über die definierten Prüfregeln hinaus anbietet. In Anhang C werden
336 die Prüfregeln zu verschiedenen Datenformaten aufgeführt. Die Auflistung der Prüfregeln kann bei
337 Inbetriebnahme neuer Releases angepasst werden und wird dann in nachfolgenden Versionen der Im-
338 plementation Guidelines aktualisiert. Weitergehende fachliche Prüfungen befinden sich im Aufgaben-
339 bereich des Prozessteilnehmers.
340 3.5.1 Ausgang von ACK-Dokumenten
341 RAIDA erstellt für jede eingehende Meldung ein ACK und erwartet auf jede ausgegebene Meldung ein
342 ACK vom Empfänger. Die bei RAIDA eingehenden ACK verbleiben in RAIDA und werden nicht an wei-
343 tere Prozessteilnehmer weitergeleitet. Generell erfolgt nach dem Eingang von Nachrichten, unabhän-
344 gig von deren Format immer der Versand einer technischen Empfangs- und Prüfbestätigungen (ACK).
345 Die Prüfungen der eingegangenen Nachrichten erfolgt auf Basis der entsprechenden Schema-Dateien
346 und den Prüfregeln des jeweiligen Dokumentenformats.
347 Wenn die Prüfungen fehlschlagen, wird ein negativer ACK mit ReasonCode A02 (Message fully rejec-
348 ted) versendet. Zusätzliche Reasons enthalten Informationen über die fehlgeschlagenen Prüfregeln.
349 Diese Reason-Codes sowie die entsprechenden zugrundeliegenden Prüfungen sind in Anhang C aufge-
350 führt. Ist die Datei nicht lesbar, d. h. kann sie nicht gemäß dem XSD-Schema validiert werden, wird ein
351 technischer ACK versendet. Der technische ACK enthält nur das Element ReceivingPayloadName, nicht
352 die Elemente ReceivingDocumentIdentification, ReceivingDocumentVersion und ReceivingDocu-
353 mentType. Es erfolgt in diesem Fall keine Weiterverarbeitung der Daten aus der Eingangsdatei in
354 RAIDA.
355 Wenn die Prüfung der Nachricht positiv ist, wird die Nachricht durch RAIDA mit einem positiven ACK
356 mit ReasonCode A01 (Message fully accepted) beantwortet.
357 Die Namenskonvention für ACK-Nachrichten entspricht den Vorgaben aus Kapitel 6.12 der
358 EDI@Energy Allgemeine Festlegungen.
Version: 2.0 RAIDA-Release: R4 Seite 20 von 65 Stand: 28.05.2021Entwurf
359 3.5.2 Eingang von ACK-Dokumenten
360 Ebenfalls wird nach dem Versand einer Nachricht durch RAIDA an einen Prozessteilnehmer eine tech-
361 nische Empfangs- und Prüfbestätigungen (ACK) von diesem erwartet. Sollte in RAIDA ein negativer ACK
362 eingehen, wird für die mit diesem ACK verknüpfte Nachricht ein Eintrag in der Vorlage für den RAIDA-
363 Applikationsmanagement angelegt. Die Fehlerklärung erfolgt anschließend durch das RAIDA-Applika-
364 tionsmanagement.
365 3.5.3 Rückhaltung von ACK-Dokumenten bei der Weiterleitung von Abruf(-informati-
366 onen) im PVK-Datenaustausch
367 Im Normalfall gibt RAIDA auf jede eingehende Meldung unmittelbar nach Empfang der Meldung ein
368 ACK an den Sender zurück gemäß Abbildung 6 :
369
370 A BBILDUNG 6: ACK-DATENAUSTAUSCH OHNE RÜCKHALTUNG VON ACK (NORMALFALL )
371 Im Fall der Weiterleitung von Abrufmeldungen im PVK-Datenaustausch, wird von diesem Grundprinzip
372 abgewichen: RAIDA hält positive ACKs auf eingehende Abrufmeldungen/-informationen so lange zu-
373 rück, bis der Empfänger der Abrufmeldung den Empfang der weitergeleitete Abrufmeldung seinerseits
374 mit einem positiven ACK bestätigt hat (siehe Abbildung 7). Dieses Prinzip findet in sämtlichen RAIDA-
375 PVK-Datenaustauschen zur Weiterleitung von Abrufmeldungen/-informationen Anwendung, d.h. be-
376 troffen sind die folgenden UC:
377 • PVK-UC:3.1: Abruf im Aufforderungsfall mit Delta-/Sollwertanweisung
378 • PVK-UC3.2: Abruf im Duldungsfall mit Sollwertanweisung
Version: 2.0 RAIDA-Release: R4 Seite 21 von 65 Stand: 28.05.2021Entwurf
379
380 A BBILDUNG 7: R ÜCKHALTUNG VON ACK BEI A BRUFMELDUNGEN IM PVK-D ATENAUSTAUSCH
381
382 3.6 Grundsätze im Datenaustausch mit RAIDA
383 Verbindliche Vorgaben zum Datenaustausch der XML-Datenformate im Redispatch 2.0 sind in den For-
384 matbeschreibungen der einzelnen Formatdokumente sowie ebenfalls im Dokument EDI@Energy All-
385 gemeine Festlegungen aufgeführt (im Rahmen der Mitteilung Nr. 19 zu den Datenformaten zur Ab-
386 wicklung der Marktkommunikation (3) am 01.04.2021 veröffentlicht).
387 Das Kapitel 6 der EDI@Energy Allgemeine Festlegungen enthält Regelungen zu Statusangaben, Versi-
388 onierung Größenbeschränkung von XML-Nachrichte und Identifikation für Prozessteilnehmer, Doku-
389 mente und Ressourcen. Die Namenskonventionen für die verschiedenen Datenformate finden sich je-
390 weils am Ende der entsprechenden Formatbeschreibung.
391 Weitere neben diesen Vorgaben zu berücksichtigen Grundsätze für den Datenaustausch mit RAIDA
392 werden im Folgenden aufgeführt und erläutert.
393 Umgang mit „entfallenen“ optionalen Elementen in XML-Nachrichten
394 Bei der Befüllung der XML-Nachrichten haben die Prozessteilnehmer die Möglichkeit bestimmte opti-
395 onale Datenfelder entweder „leerzulassen“ oder zu befüllen. Sollte ein Prozessteilnehmer im Rahmen
396 einer Änderung einer Nachricht ein optional zu befüllendes Datenfeld, welches in einer vorherigen
397 Meldung befüllt war, in einer darauffolgenden Meldung leerlassen, wird RAIDA das besagte Datenfeld
398 in der Nachricht auch leer weiterleiten bzw. im Falle von Stammdaten entsprechend leer im System
399 hinterlegen. RAIDA wird nicht die Werte der Datenfelder aus der vorherigen, veralteten Meldung bei-
400 behalten oder übernehmen.
401 Vorgaben und Empfehlungen zur Paketierung von Nachrichten für Bewegungsdaten
Version: 2.0 RAIDA-Release: R4 Seite 22 von 65 Stand: 28.05.2021Entwurf
402 RAIDA orientiert sich für die Paketierung von Nachrichten an den allgemeinen Vorgaben aus den For-
403 matbeschreibungen, den Allgemeine Festlegungen zu den EDIFACT-und XML-Nachrichten und der
404 RzÜ. Daher gelten für die Zuordnung einzelner Ressourcen und Zeitreihen auf Dokumente mit eigener
405 DokumentenID, folgende Grundsätze:
406 • Die Bewegungsdaten für einen Use Case und eine Ressource müssen immer in einer Datei zusam-
407 men übertragen werden und dürfen nicht verteilt über mehrere Dateien gesendet werden.
408 • Der Nachrichtensender darf Zeitreihen zu beliebig vielen Ressourcen in einem Dokument gruppiert
409 verschicken (Technische Restriktion: Max. 10 MB nach Komprimierung). Sofern die Dokumenten-
410 größe dies zuließe, könnten also alle Zeitreihen für alle Ressourcen in einem Dokument versendet
411 werden. Es könnte aber auch für jede einzelne Ressource ein eigenes Dokument gesendet werden.
412 • Für einen Erfüllungstag müssen sich die einem Dokument zugeordneten Zeitreihen in jeder nach-
413 folgenden Version des Dokumentes wiederfinden. Dabei ist die Versionsnummer aufsteigend.
414 o Ein Entfernen/Auslassen von einzelnen Ressourcen oder Zeitreihen in einem Dokument (bzw.
415 einer DokumentenID) ist somit nicht zulässig.
416 o Ein Hinzufügen neuer Ressourcen oder Zeitreihen in einem Dokument (bzw. einer Dokumen-
417 tenID) dagegen schon.
418 o Für jeden neuen Erfüllungstag können die Zeitreihen den Dokumenten wieder neu zugeordnet
419 werden.
420 • Aus dem obigen Punkt folgt, dass bei einem Update mind. einer Zeitreihe immer auch alle anderen
421 Zeitreihen, die im selben Dokument enthaltenen sind, aktualisiert bzw. erneut versendet werden
422 müssen. (Unabhängig davon, ob diese sich überhaupt geändert haben, einen anderen Zeitreihentyp
423 haben oder einer anderen Ressource zugeordnet sind.)
424 Ein „schlechter“ Zuschnitt der Zeitreihen, die im selben Dokument zusammen versendet werden,
425 kann daher im Zweifel zu einem unnötigen, erhöhten Datenaufkommen führen.
426 Vor diesem Hintergrund gilt für die Paketierung von Bewegungsdaten generell die Empfehlung, im
427 Normalfall ein Nachrichtenvolumen von 1 MB nach Komprimierung pro Dokument nicht zu überschrei-
428 ten, um die Verarbeitung der Meldungen zu erleichtern. Diese Empfehlung gilt es insbesondere für
429 „datenreiche“ Nachrichten, welche Bewegungsdaten für eine Vielzahl von Ressourcen enthalten kön-
430 nen, einzuhalten und betrifft somit die Übertragung folgender Datenformate:
431 • PlannedRessourceScheduleDocument
432 • UnavailabilityMarketDocument
433 • Activation Document
434 • Kostenblatt
435 Sowohl die Übertragung zu großer Dateien, als auch die Übertragung zu vieler kleiner Dateien kann
436 negative Auswirkungen auf die Performance haben:
437 • Bricht die Übertragung einer einzelnen großen Datei ab oder wird die Datei mit einem negativen
438 ACK abgelehnt, so muss die gesamte Datei erneut übertragen werden. (Vorteil für kleinere Dateien)
439 • Wird eine (sehr) hohe Anzahl an kleinen Dateien übertragen, so muss jedes mal eine Verbindung
440 aufgebaut und wieder geschlossen werden, was zu unnötigem Overhead führt. (Vorteil für größere
441 Dateien)
Version: 2.0 RAIDA-Release: R4 Seite 23 von 65 Stand: 28.05.2021Entwurf
442 • Da immer alle initial im Dokument enthaltenen Zeitreihen übertragen werden müssen (s.o.), ändert
443 sich ggf. die Leistungsfähigkeit der Komprimierung im Laufe eines Erfüllungstages. Bspw. kann eine
444 Zeitreihe, die nur Nullen enthält, besser komprimiert werden als eine Zeitreihe, die unterschiedli-
445 che Werte enthält. Eine Datei die initial knapp kleiner als 10MB groß ist, könnte im Schlimmstfall
446 durch Aktualisierungen der Zeitreihen die Größe von 10MB überschreiten. (Vorteil für kleinere Da-
447 teien)
448 Zudem sind bestimmte fachliche/inhaltliche Prüfungen der Daten auf Dokumentebene nur dann um-
449 setzbar, wenn konsistente Versionen bestimmter Zeitreihen (bspw. PROD, RDV, RDA) in einen Doku-
450 ment zusammen übermittelt werden. Dies wird mit der zuvor genannten Einschränkung erreicht, dass
451 Bewegungsdaten für einen Use Case und eine Ressource nicht über mehrere Dateien verteilt gesendet
452 werden dürfen.
453 Umsetzung: Löschen/Neuzuordnen von einer untergeordneten Ressource (TR, SR, SG, CR) aus/auf
454 eine übergeordnete Ressource (SR, SG, CR)
455 Eine eigene Funktionalität bzw. ein eigener Use Case speziell zum Löschen oder Neuzuordnen einer
456 Ressource aus bzw. auf eine übergeordnete Ressource (z.B. Löschen einer TR aus einer SR, Zuordnung
457 einer SR zu Cluster A anstatt Cluster B) ist zum aktuellen Zeitpunkt weder in den BDEW-Vorgaben noch
458 in RAIDA vorgesehen und muss über eine Stammdatenänderung der betroffenen übergeordneten Res-
459 sourcen erfolgen. Ein Löschen einer untergeordneten Ressource X ist in der Praxis möglich, indem zur
460 übergeordnete Ressource A geänderte Stammdaten ohne Ressource X (je nach Fall: PVK-UC2.3, PVK-
461 UC2.4 oder NKK-UC1.2) versandt werden. Möchte man die Ressource X in einem nächsten Schritt im
462 Anschluss einer anderen übergeordneten Ressourcen B zuordnen, müssen im nächsten Schritt die ge-
463 änderten Stammdaten auch zu Ressource B versandt werden. Die Reihenfolge der Stammdatenände-
464 rung (erst neue Stammdaten für „geleerte“ Ressource, dann neue Stammdaten für „ergänzte“ Res-
465 source) ist beim Neuzuordnen von Ressourcen einzuhalten.
466 Umsetzung von EIV-Wechseln und ANB-Wechseln für eine Ressource
467 Hinweis: Zum dem Thema „Wechselprozesse“ laufen zum jetzigen Zeitpunkt im BDEW noch Abstim-
468 mungen im Rahmen von eingegangenen „Umsetzungsfragen“. In diesem Dokument wird die aktuelle
469 Umsetzung in RAIDA beschrieben. Abhängig von branchenweiten Abstimmungen im BDEW können
470 daher Prozessanpassungen in nachfolgende Releases resultieren.
471 • Für die Verteilung und Validierung der Nachrichten muss der DP zu jedem Zeitpunkt für eine Res-
472 source (TR/SR/CR/SG) einen gültigen EIV als „Besitzer“ sowie einen gültigen „ANB“ kennen.
473 • Eine direkte „Übernahme“ einer Ressource durch den neuen EIV/ANB ohne eine Bestätigung (durch
474 den alten EIV oder den ANB) ist nicht vorgesehen, da diese Meldung direkt die Weiterleitung von
475 Planungsdaten und Abrufen durch den DP beeinflusst.
476 • Hinweis: Der genaue Umgang mit Wechsel- und Gültigkeitszeiträumen ist aktuell noch in Klärung.
477
478 Vorgehen für den EIV-Wechsel einer Ressource:
Version: 2.0 RAIDA-Release: R4 Seite 24 von 65 Stand: 28.05.2021Entwurf
479 • Die Umsetzung erfolgt analog zum PVK-Use-Case: 2.1 Übermittlung von initialen Stammdaten.
480 • Der EIV Wechsel (einer dem DP bereits bekannten Ressource) muss durch den ANB bestätigt wer-
481 den (durch Rückmeldung der angereicherten StaDa durch den ANB).
482 • Schritt 1: Der neue EIV sendet eine StaDa-Nachricht für die entsprechende Ressource
483 o Diese StaDa-Meldung des neuen EIV wird nicht an alle bNB verteilt (Da es kein StaDa-Update
484 ausgehend vom bisherigen EIV der Ressource ist). Diese Nachricht geht also nur an den ANB.
485 o Da der neue EIV dem DP zu diesem Zeitpunkt nicht als Besitzer der Ressource bekannt ist, ist
486 er zu diesem Zeitpunkt noch nicht berechtigt Bewegungsdate/Abrufe zu dieser Ressource zu
487 senden/empfangen.
488 • Schritt 2: Der ANB muss angereicherte StaDa mit dem neuem EIV an den DP RAIDA zurückmelden,
489 damit der Wechsel des EIV im System umgesetzt wird
490 o Vorher werden keine Bewegungsdaten vom neuen EIV akzeptiert und keine Abrufe/Abruf-
491 Informationen an den neuen EIV versendet!
492 o Dieses Verhalten ist analog zum PVK-Use-Case: 2.1 Übermittlung von initialen StaDa.
493
494 Vorgehen für den ANB-Wechsel einer Ressource:
495 • Eine direkte Übernahme der Ressource durch eine Meldung des neuen ANB der Ressource ist aktu-
496 ell nicht möglich und auch nicht erwünscht, da diese Meldung sofort die Weiterverteilung der Nach-
497 richten beeinflusst: RAIDA verteilt nur Nachrichten der berechtigten Sender (in diesem Fall des al-
498 ten ANB) weiter, der neue ANB ist zu diesem Zeitpunkt kein berechtigter Sender.
499 • Daher muss der ANB-Wechsel durch den alten ANB gemeldet/initiiert werden (Als StaDa-Update)
Version: 2.0 RAIDA-Release: R4 Seite 25 von 65 Stand: 28.05.2021Entwurf
500 4 Technische Anforderungen für die Kommunikation mit RAIDA
501 Die Anforderungen an Sicherheits- und Schutzmechanismen sowie die Anforderungen an den Übertra-
502 gungswegen in RAIDA richten sich grundsätzlich nach den Vorgaben aus dem Dokument EDI@Energy-
503 Regelungen zum Übertragungsweg (RzÜ) für den Austausch von „Redispatch2.0-Prozessdaten“ im
504 XML-Format, welches am 01.04.2021 im Rahmen der Mittelung Mitteilung Nr. 19 zu den Datenforma-
505 ten zur Abwicklung der Marktkommunikation (3) veröffentlicht wurde. Sollten zur Kommunikation
506 über RAIDA weitere Aspekte zu beachten sein, sind diese im Folgenden explizit aufgeführt, ansonsten
507 wird auf die entsprechenden Kapitel der RzÜ verwiesen.
508 4.1 Allgemeine Regelungen zum Übertragungsweg
509 Die Vorgaben für den Austausch der Zertifikate und die Kommunikationsregeln aus Kapitel 2.3 und
510 Kapitel 4.3 der RzÜ sind zu berücksichtigen.
511 Für die Organisation und die technischen Vorgaben zur Signatur und Verschlüsselung gelten die Vor-
512 gaben aus Kapitel 5 der RzÜ. Zudem wird auf dem Downloadbereich der Connect+-Webseite eine Hil-
513 festellung Encodierung, welche eine Übersicht über den Prozessablauf zur Komprimierung, Verschlüs-
514 selung und Signierung von XML-Nachrichten bietet zur Verfügung gestellt (7).
515 Ebenfalls sind bei der Kommunikation mit RAIDA die organisatorischen Regelungen zum Umgang mit
516 Zertifikaten und die Konsequenzen bei Nicht-Einhaltung dieser Vorgaben gemäß Kapitel 11 und 12 der
517 RzÜ zu beachten.
Version: 2.0 RAIDA-Release: R4 Seite 26 von 65 Stand: 28.05.2021Sie können auch lesen
