Konventionelle Implementierungsansätze
Bild 1. Konventionelle Lösung – Anforderung einer Engpasskoordination mittels Bestandssystemen und zentralem Datenaustausch. (Quelle: BTC)
Bestehende Kopplungen von Netzbetreiberleitstellen für spezielle, technisch eingeschränkte Zwecke sind in sehr geschützten Bereichen angelegt und nicht für beliebig viele sowie willkürlich wechselnde Kopplungen mit Systemen von Einsatzverantwortlichen und weiteren Parteien vorgesehen. Auch sind sie nicht für die genannten technischen B2B-Aufgaben ausgerüstet und nicht in der Lage, globale Geschäftsprozessabläufe zu unterstützen und zu verfolgen. Trotzdem wird zur Umsetzung der Redispatch-Prozesse vom BDEW zurzeit eine Kopplung der Leitstellen zu diesem Zweck sowie eine zentrale Plattform diskutiert. Ein monopolartiger Datenaustausch über eine zentrale Instanz würde dabei wahrscheinlich einer Regulierung unterzogen. Dies würde Verzögerungen gegenüber einer reinen Standardisierung und unflexible inhaltliche Beschränkungen gegenüber künftigen Erweiterungen der Standards zur Folge haben.
Ein solcher Lösungsansatz für die Engpasskoordination könnte beispielsweise wie in Bild 1 dargestellt aussehen.
Gemäß diesem Ansatz müsste jeder Netzbetreiber allein für die Engpasskoordination mehr als 20 Nachrichtentypen in geeigneter Reihenfolge übertragen und mithilfe seiner Bestandssysteme, zum Beispiel Leitstellen oder Prognosesystemen, umsetzen. Außerdem ist der Austausch von Stamm- und Bewegungsdaten zu vor- und nachgelagerten Netzebenen über einen zentralen Datenaustausch erforderlich. So muss der Netzbetreiber gegebenenfalls auch die Schritte A bis D umsetzen. Der abgebildete Ablauf beschränkt sich dabei auf die Netzbetreiberkoordination und berücksichtigt noch nicht alle übrigen, oben genannten und noch zu erarbeitenden Prozessteile.
Auch wenn Definitionen von Standardschnittstellen zur Verfügung stehen würden, müssten also zusätzlich bei jedem betroffenen Netzbetreiber zahlreiche Standardschnittstellen und unternehmensübergreifende Workflows in Bestandssystemen proprietär umgesetzt und in Betrieb genommen werden. Im Worst Case müsste also bei diesem konventionellen Ansatz jeder Netzbetreiber neben der Umsetzung einer eigenständigen Lösung für das eigene Netz auch die technischen Festlegungen zahlreicher unterschiedlicher und übergreifender Nachrichtentypen sowie Workflows zusammen mit benachbarten Netzbetreibern und Dritten auf Basis seiner Bestandssysteme umsetzen, einführen und testen.
Unterschiedliche Interpretationen der Standards würden bei einem solchen Vorgehen zu uneinheitlichen Lösungen, Inkompatibilitäten, Fehlern, umfangreichen Tests untereinander und Aufwänden sowie langen Umsetzungszeiten führen – auch bei weiteren Releases. Ergebnis wäre eine drastisch reduzierte Agilität und bei jeder umsetzenden Partei ein erheblicher, regelmäßig entstehender Mehraufwand im Vergleich zu einer einheitlicheren Lösung.
Zusätzlich wäre die Umsetzung und Einbindung einer zentralen Datenaustauschplattform zumindest für Bewegungsdaten inklusive der Gründung einer zugehörigen Betreibergesellschaft notwendig. Diese Plattform wäre hinsichtlich Anzahl gleichzeitig aktiver Nutzer, Datenumfang, Geschwindigkeit, Kritikalität, Angreifbarkeit und Ausfallschadensrisiko wesentlich komplexer und anspruchsvoller als zum Beispiel die Umsetzung des Marktstammdatenregisters.
Zusammengefasst würde sich für jedes Unternehmen und auch übergreifend ein hoher Aufwand, lange Projektlaufzeiten und hohe Kosten ergeben. Vor allem vor dem Hintergrund der geforderten Umsetzung bis Oktober 2021 ist dies eine große Herausforderung.
Ähnlich sieht die Situation auch bei einer möglichen Automatisierung der Netzbetreiberkaskade (gemäß VDE-Anwendungsrichtlinie 4140) aus [1] und eventueller weiterer künftiger Aufgaben der Netzbetreiber. Die aktuell diskutierten konventionellen Varianten zur Umsetzung würden dann aufgrund mehrerer Anwendungsszenarien zu einer enormen Belastung der zum Teil kritischen Bestandssysteme führen, die dafür nicht ausgelegt sind.