Steuerung des Netzmodells: Was ändert sich, wenn der Betreiber nicht Eigentümer des Netzes ist?

Ein Netzbetreiber nimmt im Energiesektor eine ungewöhnliche Stellung ein. Er betreibt das Netz, ist jedoch weder dessen Eigentümer noch dessen Erbauer. Jeder Bestandteil seines physikalischen Modells stammt von einer anderen Stelle: einem Übertragungsnetzbetreiber, einem Konzessionsinhaber oder einem benachbarten Betreiber. Ein Übertragungsnetzbetreiber kann jederzeit auf Aufzeichnungen über seine eigenen Bauvorhaben zurückgreifen und diese als Bezugspunkt nutzen. Ein Netzbetreiber verfügt über keinen solchen Ankerpunkt.

Auf den ersten Blick mag dies wie ein rein administrativer Unterschied erscheinen, doch das ist es nicht. Für ein Übertragungsnetzunternehmen dient die Verwaltung der Modelldaten der Optimierung eines bestehenden Prozesses. Für einen Netzbetreiber ist die Verwaltung der Daten der Prozess selbst.

So sieht das in der Praxis aus 

Jeder, der schon einmal bei einem Netzbetreiber gearbeitet hat, wird die Symptome erkennen, ohne dass sie erklärt werden müssen.

Der Echtzeitbetrieb, die Betriebsplanung und die Erweiterungsplanung verfügen oft über eigene Versionen derselben Umspannstation. Zwischen der Anlagenstammdatenbank und den von Analysetools verwendeten CIM-Dateien befindet sich eine Kette aus internen Konvertern, Skripten und Tabellenkalkulationen, die über Jahre hinweg aufgebaut wurde. Das System funktioniert zwar, wird aber nur von einer Handvoll Personen vollständig verstanden – und diese Personen wechseln irgendwann den Arbeitsplatz oder gehen in den Ruhestand.

Dann kommen die weniger sichtbaren Folgen. Die exakte Reproduktion des Modells, wie es zum Zeitpunkt einer Störung existierte, ist langsam und in der Praxis nur annähernd möglich. Änderungen (wer sie vorgenommen hat, wann und auf wessen Anweisung) werden auf der Ebene einzelner Objekte selten erfasst. Unterdessen wächst die Warteschlange der Aktualisierungen schneller, als das Team sie bewältigen kann: neue Übertragungskonzessionen, erneuerbare Energien im Großmaßstab, Speicher, HGÜ-Verbindungen und dezentrale Ressourcen kommen alle als Modelländerungen mit festen Fristen hinzu.

Bisher: Jeder Integrationsweg wird zu einer separaten Vereinbarung hinsichtlich Format, Zeitplan und Qualität.

Warum handelt es sich hierbei nicht um einen technischen Fehler? 

Es lohnt sich, dies klar zu betonen, da diese Einschätzung oft fälschlicherweise als Kritik an den technischen Teams aufgefasst wird.

Keine dieser Herausforderungen ist auf mangelnde Sorgfalt zurückzuführen. Sie entstehen, wenn Modelldaten Pfad für Pfad integriert werden, anstatt zentral gesteuert zu werden. Jeder einzelne Pfad war zu seiner Zeit eine vernünftige Entscheidung, die unter Berücksichtigung der Budget- und Zeitvorgaben getroffen wurde. Die Anhäufung dieser Entscheidungen über einen Zeitraum von fünfzehn oder zwanzig Jahren wird letztendlich zum Engpass.

Deshalb besteht die Lösung nicht darin, die Teams zu mehr Sorgfalt aufzufordern. Vielmehr muss der Bezugspunkt verlagert werden.

Erfassungssystem und Aktionssystem 

Eine der anschaulichsten Möglichkeiten, dies zu erklären – insbesondere in Gesprächen mit Führungskräften –, ist die Unterscheidung zwischen zwei Rollen.

Das Referenzsystem enthält das Modell. Das Ausführungssystem steuert das Raster. Dabei handelt es sich um grundlegend unterschiedliche Funktionen mit unterschiedlichen Lebenszyklen und Auswahlkriterien.

Befinden sich beide auf derselben Plattform, ist das Modell an das Steuerungssystem gebunden. Ein Austausch der Plattform erfordert dann auch die Verlagerung des Modells, wodurch aus einer routinemäßigen Technologieaktualisierung ein umfangreiches Transformationsprojekt wird. Sind beide voneinander getrennt, verbleibt das Modell beim Betreiber, und die Betriebsplattform kann ausgetauscht werden.

Danach: Zwischen den Datenquellen und den nutzenden Systemen befindet sich ein einziges, zentral verwaltetes Repository.

Dieser Ansatz ist nicht neu. Die gemeinsam mit Übertragungsnetzbetreibern, Netzbetreibern und Softwareanbietern entwickelten Anforderungen des EPRI definieren acht Funktionsbereiche, die ein Netzwerkmodell-Manager abdecken sollte, und gliedern die Modellierungsprozesse in fünf Gruppen. Dabei sticht ein durchgängiges Thema hervor: Governance ist kein übergeordnetes Element, sondern eine Kernkompetenz, die in die Art und Weise eingebettet ist, wie das Modell erstellt, gepflegt und organisationsweit genutzt wird.

„Wir haben bereits einen Datenbankadministrator.“ 

Das ist der häufigste Einwand – und ein berechtigter dazu. Die meisten Betreiber nutzen bereits eine Datenbank oder einen Modellmanager, die im Lieferumfang ihrer Steuerungsplattform enthalten sind. Diese Tools sind real und erfüllen ihren Zweck.

Anstatt dies abstrakt zu diskutieren, lohnt es sich, bei jedem in Frage kommenden System – einschließlich des bereits bestehenden – zwei praktische Fragen zu stellen.

Anstatt dies abstrakt zu diskutieren, lohnt es sich, bei jedem in Frage kommenden System – einschließlich des bereits bestehenden – zwei praktische Fragen zu stellen.

Kann es neben dem Bestandsmodell auch ein zukunftsorientiertes Projekt enthalten und aus beiden eine Fallstudie zusammenstellen?

Kann eine Drittanbieteranwendung das Modell unabhängig vom Plattformanbieter nutzen?

Wenn beide Fragen mit „Ja“ beantwortet werden, liegt das Problem wahrscheinlich nicht beim Tool. Wenn eine der beiden Fragen mit „Nein“ beantwortet wird, ist das der Ausgangspunkt für das Gespräch.

Die vollständige Broschüre herunterladen 

Wir haben eine achtseitige Broschüre zusammengestellt, die sich ausführlicher mit diesem Thema befasst, als es in diesem Artikel möglich ist. Sie enthält:

• Eine Vorher-Nachher-Darstellung der gesamten Architektur, die die fünf typischen Datenquellen und acht nutzenden Anwendungen zeigt, wobei die fünf Prozessgruppen des EPRI den Abläufen zugeordnet sind.
• Eine Aufschlüsselung der acht Funktionsfamilien des EPRI, die direkt dem IPS® NMM zugeordnet sind.
• Ein Vergleich zwischen einem plattformbasierten Modellmanager und einem eigenständigen CIM-basierten System of Record anhand von sechs Dimensionen, einschließlich fünf zentraler Bewertungsfragen für Ihre aktuelle Lösung.
• Ein schrittweiser Einführungsansatz, der mit einem Proof-of-Concept für einen Teilbereich der Topologie beginnt, ohne dass ein vollständiger Austausch erforderlich ist.
• Die Auswirkungen auf die einzelnen Funktionsbereiche, vom Leitstellenbetrieb bis hin zur Aufsicht durch die Geschäftsleitung, einschließlich eines Referenzbeispiels eines nationalen Übertragungsnetzbetreibers, der diesen Ansatz bereits umgesetzt hat.