08.06.2021
5 Minuten Lesezeit

Streng nach Protokoll

Jetzt teilen!

Bahnapplikationen werden immer komplexer. Florian Einböck, Product Manager bei Frauscher, spricht in einem Interview darüber, wie High-Performance-Softwareprotokolle die essenzielle problemlose Kommunikation zwischen Systemen gewährleisten.

ie digitale Kommunikation setzt die Implementierung der entsprechenden Protokolle voraus, sie sind also ein ganz elementarer Bestandteil.
Florian Einböck Product Management

Eine Bahnbranche ohne Digitalisierung und Vernetzung kann man sich heute überhaupt nicht mehr vorstellen. Welche Rolle spielen Softwareprotokolle dabei?

Durch die Nutzung digitaler Daten hat sich eine große Bandbreite von neuen und verbesserten Applikationen für die Bahnbranche aufgetan. Diese wiederum machen den gegenseitigen Austausch der unterschiedlichsten Informationen zwischen Systemen möglich. Für diesen Datentransfer braucht es aber mehr als geeignete Schnittstellen. Die digitale Kommunikation setzt die Implementierung der entsprechenden Protokolle voraus, sie sind also ein ganz elementarer Bestandteil.

Daher gehört die Auswahl des optimalen Softwareprotokolls zu den Überlegungen, die bereits in der Projektplanungsphase anzustellen sind. Sie können entweder ein Protokoll übernehmen, das bereits im bestehenden System verwendet wird, oder Sie können ein vollkommen neues Protokoll oder ein Protokoll einführen oder entwickeln, das für das System fremd ist. Auf jeden Fall sollten oder müssen bei dieser Entscheidungen verschiedene Faktoren berücksichtigt werden.

Viele Systemintegratoren verwenden bereits spezifische Protokolle. Was sollten sie bei Anpassungen beachten, wenn neue Komponenten integriert werden sollen?

Wir haben schon mehrere Projekte realisiert, bei denen genau dieser Ansatz gewählt wurde. Dadurch haben wir wertvolle Erfahrungen in Bezug auf das Zusammenspiel und die Kompatibilität von Protokollen und Schnittstellen sammeln können. Wir wissen daher, dass es unabdingbar ist, die entsprechenden Protokollspezifikationen, beispielsweise im Hinblick auf den Initialisierungsprozess, genau zu kennen. Auch auf der Hardwareebene müssen Grundvoraussetzungen erfüllt werden. Die Anpassung bestehender Protokolle kann daher – je nach den Anforderungen – mit erheblichen Kosten verbunden sein.

Wenn aber ein Systemintegrator für die Kommunikation zwischen den Interlocking-Lösungen oder zwischen den im Feld installierten Elementen ein eigenes Sicherheitsprotokoll implementiert hat, dann ist beispielsweise die Einbindung eines Achszählers oder einer Tracking-Lösung über eben dieses Protokoll die einfachste und effektivste Lösung für den betreffenden Systemintegrator. So ist gewährleistet, dass in die bestehende Systemumgebung ganz einfach zusätzliche Daten integriert und dann weiter verarbeitet werden können.

Und welche Möglichkeiten gibt es, wenn kein Protokoll vorhanden ist?

In diesem Fall greift man in der Regel auf vorhandene Protokolle zurück, die aber im bestehenden System noch nicht verwendet werden und daher ebenfalls entsprechend angepasst werden müssen. Bei Applikationen im Bahnsektor heißt das auch, dass die entsprechenden Standards und Anforderungen berücksichtigt werden müssen. Da das Datenübertragungssystem in der Regel einer Vielzahl von Bedrohungen ausgesetzt ist, muss es möglich sein, die in EN 50159 aufgeführten Meldungsfehler zu identifizieren. In der Vergangenheit wurden zahllose standardisierte und proprietäre Protokolle entwickelt, die die entsprechenden Sicherheitsmerkmale enthielten. Die standardisierten Protokolle, z. B. UNISIG oder EULYNX, sind meist sehr komplex, was zur Folge hat, dass die Implementierung mit erheblichem finanziellem Aufwand verbunden wäre.

Proprietäre Protokolle gibt es sowohl in einfacher als auch in komplexer Form. Sie haben oft Entwicklungen durchlaufen, die zum Teil unnötige Overheads erzeugen, die dann weiter mitgeschleppt werden. Und wenn es Spezifikationen gibt, fehlen in ihnen oft zusätzliche Aspekte, die in der Implementierungsphase berücksichtigt werden müssen. Das Hauptproblem liegt jedoch in der Berechtigung, dieses Protokoll überhaupt implementieren und dann auch nutzen zu dürfen.

Das Protokoll Frauscher Safe Ethernet FSE wurde also vor dem Hintergrund dieser verschiedenen Möglichkeiten entwickelt?

So ist es. Das Ziel bei der Arbeit am FSE-Protokoll bestand in erster Linie in der Entwicklung eines bahnspezifischen Softwareprotokolls. Das Protokoll basiert auf UDP/IP und ermöglicht die Kommunikation zwischen zwei Punkten. Damit erfüllt es die Anforderungen gemäß CENELEC SIL 4 und EN 50159 Kategorie 2.

Dadurch beschleunigt sich die Integration neuer Komponenten in verschiedene Projekte deutlich. Es können maximal 512 Byte Applikationsdaten übertragen werden. Dazu gehören neben Informationen von bis zu 40 Zählköpfen oder 80 Gleisabschnitten über nur eine Kommunikationsbaugruppe auch Rückstellinformationen und E/A-Informationen von der Interlocking-Lösung zur Kommunikationsbaugruppe. Redundante Baugruppen- oder Netzwerkstrukturen werden ebenfalls unterstützt.

Die Entwicklung des Softwareprotokolls FSE als Ethernet-Format liegt einige Jahre zurück. Was waren damals die Gründe für die Wahl dieses Formats und welche Vorteile hat es heute noch?
 

Für uns war ausschlaggebend, wie verbreitet das Format war und immer noch ist: Ethernet kann in den meisten bestehenden Netzwerken als Standard verwendet werden – ganz ohne zusätzliche Hardwarekosten. Insbesondere im Hinblick auf den Einsatz im Bahnbereich sprechen verschiedene Vorteile für das Ethernet-Format. Einer davon ist die extrem sichere Verbindung, die eine sehr schnelle Datenübertragung bis hin zur Echtzeitübertragung gewährleistet.

Und die sehr stabile Verbindung sorgt dafür, dass praktisch keine Daten verloren gehen. Dank des großen Adressraums können sehr viele Teilnehmer gleichzeitig Zugriff haben. Außerdem ist es auch möglich, verschiedene Daten über ein Netzwerk zu übertragen, bei dem verschiedene Datenübertragungsmedien, wie Kabel, Lichtwellenleiter und Funk, kombiniert werden können.

Das Protokoll Frauscher Safe Ethernet FSE hat sich vielfach bewährt:

  • Frei verfügbar und konkret für Bahnapplikationen entwickelt
  • Schnelle Integration und Systemerweiterung
  • Bidirektionale Übertragung
  • Frei definierbare Datasets

Wie macht Frauscher seinen Kunden und Partnern sein Protokoll verfügbar?

Wir haben dies ausführlich diskutiert. Mit unserem Fokus auf die Kunden und deren Bedürfnisse verstehen wir die Bedeutung von Ethernet-Schnittstellen und Datenaustausch – auch auf einer sicheren Ebene. Daher sind wir einhellig zu der Entscheidung gekommen, FSE kostenlos für verschiedene Applikationen verfügbar zu machen, was wiederum der Philosophie von Frauscher entspricht: Beide Seiten sollen von den offenen Partnerschaften und Kooperationen mit Anwendern profitieren – und zwar durch den Austausch von Informationen und den praktischen Einsatz.

Bislang wurde das FSE-Protokoll auf vier verschiedenen PLC-Plattformen erfolgreich implementiert. Dadurch konnten wir mehr als 100 Kundenprojekte für verschiedene Applikationen realisieren. Diese Lösungen sind jetzt rund um die Welt im Einsatz. In 40 weiteren Unternehmen haben die Arbeiten zur Implementierung dieser Lösungen unter Verwendung weiterer Hardwareplattformen begonnen oder die Implementierung ist bereits abgeschlossen. Insgesamt wurde bereits mit über 150 interessierten Parteien über das Protokoll und dessen Potenzial in verschiedenen Applikationen gesprochen.

Und obwohl es speziell für die Übertragung von Achszählungsdaten entwickelt wurde, kann es aufgrund seiner vorteilhaften Eigenschaften auch für die Übertragung von Nicht-Achszählungsdaten eingesetzt werden. Auch wir lernen mit jeder neuen Implementierung dazu. Wer an den frei verfügbaren Informationen zum FSE-Protokoll interessiert ist, kann sich einfach bei uns melden. Nachdem wir Details wie den Verwendungszweck und mögliche Anpassungen geklärt haben, können wir mit der Umsetzung beginnen – gemeinsam und ganz flexibel, aber immer streng nach Protokoll.

 

Mit FSE können verschiedene Informationen übertragen werden:

  • Informationen zum Status des FMA
  • Aktuelle Anzahl der Achsen in einem FMA
  • Zuglängenangabe
  • Richtung
  • Geschwindigkeit
  • Raddurchmesser
  • E/A-Informationen aus der AEB/IO-EXB
  • Testbyte
  • Andere frei definierbare Datasets

Können Sie uns abschließend vielleicht noch einen Ausblick auf zukünftige Entwicklungen und Prioritäten geben?

Wie bereits erwähnt, lassen wir Erkenntnisse aus jeder neuen Implementierung fortlaufend in die Entwicklung und Verbesserung unserer Produkte einfließen. Auch wenn der Verweis auf die Digitalisierung etwas abgedroschen klingen mag, bedeutet deren Umsetzung mit allem, was dazu gehört, für uns auch, Cybersecurity oder Netzwerkresilienz als oberste Priorität anzusehen, damit wir weiter auf dem richtigen Weg bleiben und das Feld anführen.

Jetzt teilen!
Ähnliche Artikel

Artikel