Topologie ist nicht Geografie: Wie Stadtwerke Abhängigkeiten zuverlässig nachvollziehen
/ Lesedauer: etwa 4 Minuten
Eine Backbone-Strecke fällt aus. Welche Ortsnetzstationen sind jetzt kommunikationstechnisch abgeschnitten? Welche Systeme hängen daran, welche Anschlüsse sind betroffen?
Die Frage klingt nach zwei Minuten Arbeit. In der Praxis kostet sie oft Stunden. Jemand sucht Pläne heraus, jemand öffnet eine Tabelle, ein Dritter erinnert sich, dass die Strecke vor zwei Jahren umgelegt wurde. Das Ergebnis der langwierigen Recherche klingt plausibel. Ob es jedoch vollständig und aktuell ist, lässt sich oft nur mit weiterem Aufwand sicher sagen.
Das ist kein Zeichen schlechter Dokumentation. In den meisten Stadtwerken sind die Daten und das Fachwissen vorhanden. Sie liegen nur verteilt über verschiedene Systeme und Abteilungen. Die Informationen lassen sich recherchieren, aber nicht unmittelbar abfragen.
Die Daten sind da. Der Zusammenhang fehlt.
Auffällig ist dabei eine Asymmetrie. Leitungen und Trassen der Versorgungsinfrastruktur sind im Geoinformationssystem (GIS) oder im Netzinformationssystem in aller Regel sorgfältig dokumentiert. Wo etwas liegt, ist bekannt.
Anders sieht es häufig bei der digitalen Infrastruktur aus, die selten in vergleichbarer Qualität erfasst ist. Gemeint sind Netzwerke und Verkabelung, IT- und OT-Komponenten, die Stationstechnik im Feld und die Stromversorgung, die diese Technik am Laufen hält. Genau diese Schicht entscheidet jedoch darüber, ob sich die Auswirkungen einer Störung verlässlich beurteilen lassen.
Dafür genügt es nicht zu wissen, wo sich ein Objekt befindet. Entscheidend ist auch, wie es mit anderen Objekten verbunden ist und welche Abhängigkeiten daraus entstehen.
Passende Lösung
Asset-Modell, Topologie und Connectivity
Im Alltag werden dabei drei Ebenen häufig vermischt.
Das Asset-Modell beantwortet, was vorhanden ist: das Inventar mit Zustand, Lebenszyklus und Verantwortlichkeit. Dazu gehören Server und aktive Netzknoten ebenso wie Stationstechnik, Patchfelder und Stromversorgungen.
Die Topologie beantwortet, wie diese Objekte zusammenhängen. Sie zeigt beispielsweise, welche Kommunikationseinrichtung zu welcher Station gehört, welche steuerbaren Verbrauchseinrichtungen einem Niederspannungsbereich zugeordnet sind oder welche Anschlüsse über eine Strecke angebunden sind.
Genau kommt es häufig zu einem Missverständnis, denn: Topologie ist nicht Geografie. Eine Karte zeigt, wo etwas liegt. Ein Topologie-Modell zeigt, was womit verbunden ist. Für ein vollständiges Verständnis der Infrastruktur braucht es beides.
Die Connectivity beschreibt schließlich die konkrete physische Verbindung zwischen zwei Punkten: über welche Glasfaser, Verteilfelder, Patchpunkte und Muffen eine Verbindung tatsächlich verläuft. Erst auf dieser Ebene lässt sich belastbar nachvollziehen, welche Anlagen und Anschlüsse von einer gestörten Strecke betroffen sind.
Liegt diese Information nur in Plänen, Tabellen und Zeichnungen, muss die Antwort auf die Eingangsfrage mühsam recherchiert werden. Liegt sie in einem konsistenten Modell vor, genügt eine einfache Datenabfrage.
Fachsysteme ergänzen, nicht ablösen
Das ist kein Mangel der vorhandenen Systeme. Das GIS dokumentiert Lage und Trassen zuverlässig. Das Leitsystem kennt den aktuellen Schaltzustand. Eine Configuration Management Database (CMDB) strukturiert IT-Konfigurationen. Jedes System erfüllt damit genau die Aufgabe, für die es eingeführt wurde.
Schwierig wird es, sobald die Daten zusammengeführt werden müssen. Verantwortlichkeiten, Änderungsverläufe und Abhängigkeiten zwischen IT, OT und physischer Infrastruktur liegen meist in unterschiedlichen Systemen. Eine gemeinsame, aktuelle Sicht darauf gibt es selten.
Genau hier setzt FNT Command an. Die Plattform ergänzt bestehende Fachsysteme um ein gemeinsames Modell für Anlagen, Topologie und Connectivity. Die führenden Daten bleiben in den jeweiligen Quellsystemen. Ihre Beziehungen werden jedoch in einem nachvollziehbaren Infrastrukturmodell zusammengeführt.
Von der Auskunft zum belegbaren Stand
Die Frage vom Anfang stellt sich nicht nur im Störfall. Sie kommt auch auf, wenn ein Stadtwerk gegenüber der Aufsicht oder im Audit Auskunft geben muss: Welche Anlagen sind betroffen? Wer trägt Verantwortung? Wann wurde eine Konfiguration zuletzt geändert? Und welche weiteren Systeme hängen daran?
Mit einer konsolidierten Datenbasis müssen diese Antworten nicht erst aus mehreren Quellen rekonstruiert werden. Ein Anlagenverzeichnis lässt sich nach dem jeweiligen Bedarf filtern. Die Historie am Objekt zeigt Änderungen mit Zeitpunkt, verantwortlicher Rolle sowie Vorher- und Nachher-Wert. Die Abhängigkeitssicht zeigt, welche weiteren Anlagen beim Ausfall einer Backbone-Strecke betroffen wären.
Entscheidend ist, dass es dieselbe Sicht ist, mit der die Verantwortlichen auch im Alltag arbeiten. Die Antwort entsteht aus dem laufenden Betrieb, nicht durch eine kurzfristig zusammengestellte Dokumentation.
Dafür braucht es neben der Plattform klare Regeln für die Datenpflege: Welches Quellsystem ist für welche Information führend? Wer gibt Änderungen frei? Wie werden Abweichungen zwischen Systemen behandelt? Erst wenn diese Fragen geklärt sind, lässt sich eine Auskunft auch bei Rückfragen verlässlich belegen.
Über die Prüfung hinaus
Der Nutzen bleibt auch nach dem Audit. Störungsanalysen, Kapazitätsbewertungen und Change-Planungen greifen auf dieselbe Datenbasis zu. Aus einer regulatorischen Pflicht wird so ein praktisches Fundament für einen resilienteren Betrieb.
Mehr zum Thema: Im Expert Paper „Drei Pflichten, ein Datenfundament“ zeigen wir am Szenario eines mittelgroßen Querverbund-Stadtwerks, wie Asset-Modell, Topologie und Connectivity in einer gemeinsamen Datenbasis zusammenkommen. Expert Paper jetzt herunterladen .