Diagnose für das digitale Stellwerk

Das digitale Stellwerk (DSTW) wird bei der DB Netz AG in den nächsten Jahren für Neubauvorhaben und Ersatzinvestitionen z.B. im Digitalen Knoten Stuttgart (DKS), im DSTW Koblenz-Trier, Mainz und Rostock zum Einsatz kommen.
Die Architektur des DSTW partitioniert die Anforderungen auf Systeme, Teilsysteme und Umsysteme, und legt Schnittstellen im sicherheitsrelevanten Bereich SCI-[XY] zwischen diesen Systemen fest. Zusätzlich dazu müssen auch die Schnittstellen zur Diagnose SDI-[XY] festgelegt werden.

Anforderungen und Modelle
Startpunkt sind die Anforderungen des Infrastrukturbetreibers, die hier nur auszugweise dargestellt sind, wie beispielsweise die Notwendigkeit des Instandhalters, Zugang zu aktuellen Diagnose- und Prognosedaten aus dem Feld zu haben, die sich auf die aktuelle Struktur (as built) der Anlage bezieht, wozu Livedaten benötigt werden. Eine weitere Anforderung ist es, die Bedeutung der Daten der Anlage (Konfigurations-, Roh-, Diagnose- und Prognosedaten) verstehen zu können, ohne herstellerspezifische Dokumentationen lesen zu müssen., was nicht bedeuten soll, dass der Aufbau der Produkte mehrerer Hersteller standardisiert werden muss. Hierzu bedarf es eines standardisierten Baukastensystems als Equipmentmodell, mit dem der Hersteller die nicht standardisierte hierarchische Struktur seiner Anlage bis zur kleinsten tauschbaren Einheit abbilden kann.
Da sich der Bedarf ganzer Teilmodelle und verschiedener Attribute aus den oben genannten Anforderungen ergibt, muss die Diskussion dieser Anforderungen vor allen detaillierten Diskussionen über bestimmte Attribute in den folgenden Teilmodellen stehen. Das ermöglicht eine fokussierte Diskussion mit abgestimmter Betrachtungsebene. Das ist eine Grundlage für den komplexen Vorgang der Vereinheitlichung und Standardisierung, z.B. zwischen mehreren Betreibern.

Das Produktgruppenmodell (oder auch betriebliches oder logisches Modell) betrachtet, ob das Teilsystem seine betrieblichen Funktionen erfüllen kann. Ein Beispiel für eine von Field Element abgeleitete Klasse ist beispielsweise die Weiche.
Das Equipmentmodell ermöglicht, das Material (also den Typ) bis hin zur Seriennummer und Einbauort eines ausgefallenen Bauteils bereits von Ferne (remote) zu identifizieren. Der Instandhalter kann deshalb ein neues Equipment vom Typ des ausgefallenen Materials im Rahmen einer optimierten Wertschöpfungskette zur Entstörung mitnehmen.
Die Schwierigkeit besteht bisher darin, dass trotz standardisierter Partitionierung des Gesamtsystems die spezielle Architektur der Teilsysteme im Feld herstellerspezifisch ist. Trotzdem möchte ein Betreiber mögliche Abweichungen, Fehler oder Störungen erkennen und die zugrunde liegenden Diagnosen und hierarchischen und funktionalen Fehlerfortpflanzungen in ihrer Bedeutung verstehen.
Die Lösung ist ein standardisiertes Baukastensystem – hier als Equipmentmodell bezeichnet - mit dem der Hersteller die spezifische hierarchische und funktionale Architektur seiner Anlage bis zur kleinsten tauschbaren Einheit abbildet.

Über die funktionale Referenz IsImplmentedBy/Implements zwischen Objekten des Produktgruppenmodells und dem Equipmentmodell wird erkennbar, welche Produktgruppe durch welches Equipment implementiert wird. Umgekehrt wird klar, auf welche logischen Produktgruppen ein Ausfall eines Equipments ausstrahlt.

Umsetzung im Protokoll OPC UA

Für eine Schnittstellen müssen vor allem die Semantik (Bedeutung) der übertragenen Daten, die Syntax und das Protokoll standardisiert werden. Für die Diagnoseschnittstellen wird das Protokoll OPC UA verwendet.

Dieses Protokoll hat u.a. folgende Vorteile:

• Unterstützung von Informationsmodellen
• Standardisierung einer kompakten Binärsyntax als Teil des Protokolls
• Anerkannte Security mit Zertifikaten und der Unterstützung eines Reverse Connect vom sichereren Netzwerkbereich in die weniger gesicherten Bereiche

Zusammenfassung

Das dargestellte Produktgruppenmodell liefert die Sicht auf die technische Verfügbarkeit einer betrieblichen Komponente. Das Equipmentmodell ermöglicht, das Material (also den Typ) bis hin zur Seriennummer und Einbauort eines ausgefallenen Bauteils bereits von Ferne (remote) zu identifizieren. Ob der Ausfall einer Subkomponente zu einem Ausfall auf der darüber liegenden Ebene führt, kann durch die gezeigte Abbildung der Redundanz erkannt werden.
Neben den hierarchischen Beziehungen werden auch funktionale Abhängigkeiten verwendet. So lassen sich Ausfallwirkungen verfolgen und die tiefere Ursache (Root Cause) von Ausfällen erkennen.
Das dargestellte Modell ist Basis der Standardisierung der SDI-Schnittstellen in EULYNX.

Prof. Dr.-Ing. Karl-Albrecht Klinge, Professur für Angewandte Informatik - Verteilte Systeme | Dekan Fachbereich Technik | CIO, Hochschule Mainz – Mainz University of Applied Sciences