Orchestrator/bahn/project-audit/data/confluence-export/pages/27525836_6.9 RNE Common Interface.md

6.9 RNE Common Interface

Confluence Page ID: 27525836 Version: 29 Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/6 IT Ist-Analyse/6.9 RNE Common Interface Labels:

---

 Für den Austausch von TAF/TAP-TSI-konformen Nachrichten zur Unterstützung der europaweiten Interoperabilität muss das neue Bestellsystem bestimmte Schnittstellen anbieten, bzw. anbinden. Die Schnittstellen-Spezifikation wird nachfolgend beschrieben. Anschließend wird die RNE-Referenzimplementierung vorgestellt und bewertet. 

Technische Spezifikation Common Interface (CI)

Die TAF-TSI-Verordnung (Siehe TAF-TSI-Verordnung, Commission Regulation 1305/2014) beschreibt im Abschnitt 4.2.12. Vernetzung und Kommunikation eine gemeinsame Architektur für den TSI-konformen Datenaustausch der beteiligten Eisenbahnunternehmen (EVUs und EIUs). Die dort beschriebene Architektur adressiert die Aspekte:

• Vernetzung der Akteure mittels eines hybriden Peer-to-Peer Kommunikationsmodells und einer Nachrichten-Schnittstelle (ausführlich beschrieben in TAF TSI — Anhang D.2: Anlage F — Modell für TAF-TSI-Daten und -Meldungen)
• Sicherheit des Datenaustauschs (Verschlüsselung und Signatur für ausgetauschte Nachrichten)
• Zentralspeicher für Metadaten und Verwaltung der öffentlichen Schlüsseln (Publik-Key-Infrasktruktur und Zertifizierungsbehörde).
• (verbindliche) Gemeinsame Schnittstelle zur Unterstützung der Interoperabilität. Dadurch wird anderen Akteuren ein einheitlicher Zugang zu allen TSI-Daten gewährleistet.  Vor allem die Gemeinsame Schnittstelle liegt im Fokus des Projekts Bestellsystem. Laut TAF-TSI-Verordnung gilt: Eine gemeinsame Schnittstelle muss Folgendes verarbeiten können:
• Formatierung abgehender Meldungen anhand der Metadaten,
• Signatur und Verschlüsselung abgehender Meldungen,
• Adressierung abgehender Meldungen,
• Überprüfung der Authentizität eingehender Meldungen,
• Entschlüsselung eingehender Meldungen,
• Konformitätsprüfungen eingehender Meldungen anhand der Metadaten,

Behandlung des gemeinsamen Zugangs zu den verschiedenen Datenbanken. Die technische Spezifikation der Schnittstelle erfolgt im TAF-TSI - ANNEX D.2: APPENDIX E - COMMON INTERFACE (zusätzlich zum Nachrichtenformat im Apendix F). Es wird eine mehrstufige Architektur für die Verarbeitung der TSI-Nachrichten vorgeschlagen (Nummern verweisen auf Abschnitte der TAF-TSI Verordnung):

Die Architektur behandelt folgende Funktionalitäten:

• API Adaptors
• Translation and Validation
• Metadata System
• Security and Transport
• XML (Messages)
• Generic API
• Message Queueing
• Data Compression
• Admin UI Es werden folgende nicht-funktionale Anforderungen adressiert:
• Capacity: up to 1000 partners
• Stress: 100 (nominal) – 200 (peak) msgs/sec, with delay of 500 (90 ) - 2000 (max) ms
• Availability: 99,9
• Internet resource utilization: 600 kb/s (~ 30 msgs/s)
• Computer resource utilization: <50  CPU load for 5 legacy applications Die eigentliche Kommunikation zwischen den einzelnen TSI-Teilnehmern (also EVUs und EIUs) erfolgt über einen Web Service. Der Web Service basiert auf SOAP (Simple Object Access Protocol) mit XML als Datenaustauschformat. Weitere Informationen zum Common Interface beschreibt das TAP-TSI and TAF-TSI - Sector Handbook for the Communication between Railway Undertakings and Infrastructure Managers  (RU/IM Telematics Sector Handbook). Hier wird zum einen die übergreifende RU/IM Architektur skizziert:

Es kann entweder die von der RNE zu entwickelnde Referenzimplementierung eingesetzt werden oder eine Eigenentwicklung vorgenommen werden. Eine Eigenentwicklung empfiehlt sich für neu entwickelte TAF/TAP-TSI-konforme Systeme, während Alt-Systeme mittels Referenzimplementierung angebunden werden könnten (siehe auch die Bewertung der Referenzimplementierung weiter unten). Analyse: Die Kommunikation erfolgt im Push-Verfahren, d.h. dass jeder Netzwerkteilnehmer jeden potentiellen Netzwerkteilnehmer kennen muss, um ihm Nachrichten zustellen zu können. Im Falle der DB Netze müssen der CI Endpunkt von jedem EVU bekannt sein, um dessen Trassenanfragen beantworten zu können.  Die TAF/TAP-TSI-Architektur verwaltet die Liste der registrierten Eisenbahnunternehmen (Company Codes), verzichtet aber auf eine gemeinsame Registry der zugehörigen CI Endpunkte. Stattdessen werden ausdrücklich bilaterale Abstimmungen über die Endpunkte zwischen den einzelnen Teilnehmern gefordert. Dies können ca. 1000 Partner pro Teilnehmer sein (vgl. nicht-funktionale Anforderungen oben und die mehr als 400 EVUs in Deutschland).

RNE CCS - Common Components System

Die TAF-TSI-Common Components Group bietet (mit RNE als Auftragnehmer) eine Referenzimplementierung für das Common Interface an. Diese kann, muss aber nicht, von den einzelnen Eisenbahnunternehmen eingesetzt werden. Im letzteren Fall muss eine kompatible Implementierung seitens des Eisenbahnunternehmens eingesetzt werden. Die Referenzimplementierung wird zusammen mit weiteren Komponenten als Common Components System bezeichnet. Das sind im Einzelnen:

• Common Reference Files Database (auch CRD für Central Repository Domain) für den Austausch der Stammdaten,
• Common Interface (CI) Implementierung inkl. Adapter für Bestandssysteme,
• Certification Authority (CA) für die Ausstellung und Verifikation der Zertifikate, wodurch TSI-Nachrichten verschlüsselt und verifiziert werden können.

Dabei werden die CRD und CA zentral von RNE betrieben, die konkrete von RNE erstellte CI-Implementierung wird wiederum sowohl von RNE selbst (z.B. im Falle von PCS bzw. dessen Nachfolger) als auch von EVUs und EIUs, die kein eigenes CI implementieren, genutzt.  CI-Implementierungen kommunizieren mit (relevanten) anderen CI-Implementierungen sowie mit der CA (Zertifikat-Validierung) und ggf. mit dem CRD  zur länderübergreifenden Stammdaten-Synchronisation. Die von der CA ausgestellten Zertifikate werden manuell beantragt und in der jeweiligen CI-Implementierung hinterlegt.

CRD - Common Reference File Database

Folgende Daten werden vom CRD verwaltet und verteilt, entweder per manuellem Download oder über einen Webservice:

• Location Reference Files (stations, customer sidings, loading, places)
• Partner Reference files (company codes)
• TAF-TSI-Metadata (XML Schemas für Nachrichtenaustauch)

Annahmen:

Der Upload der nationalen (deutschen) Daten zum CRD ist nicht im Scope des Projekts Bestellsystem.

• Der Abgleich der XML Schemas erfolgt manuell, da diese in der Regel nur bei der Weiterentwicklung des TSI-Standards notwendig werden und somit ohnehin eine Anpassung des Bestellsystems erfordern.
• Ein automatisierter Abgleich der Referenz-Daten, vom CRD zum Bestellsystem, ist nur bedingt sinnvoll, da sich diese vermutlich selten ändern werden und zum anderen eine Qualitätssicherung gewünscht sein kann. Es wäre denkbar diese automatisiert abzuholen, um dann nach manueller Prüfung (ggf. auf Testumgebungen) in die Produktion einzuspielen, dies wird aber nicht Teil des MVPs des Bestellsystems sein.

CA - Certification Authority

Die sichere Kommunikation zwischen den TSI-Teilnehmern wird mithilfe von digitalen Zertifikaten sichergestellt (X.509, vgl. https://docs.microsoft.com/en-us/previous-versions/tn-archive/bb123848(v=exchg.65)). Diese werden zentral von RNE CA vergeben, die wiederum von teilnehmenden IT-Systemen als "Trusted Authority" anerkannt werden müssen. Die Zertifikate dienen der SSL/TLS Kommunikation zwischen den einzelnen CI's und CRD. Sie erlauben auch eine (optionale) Verschlüsselung und Signierung der Nachrichteninhalte. Es sollen ausschließlich die von der RNE ausgestellten Zertifikate zum Einsatz kommen.

Analyse:

Bei X.509-Zertifikaten und deren Einsatz in SSL/TLS sowie zur Verschlüsselung von Nachrichten handelt es sich um Industrie-Standards, die von der eingesetzten Software unterstützt werden müssen. Eine Verschlüsselung auf Transportebene gewährleistet eine sichere Übertragung, eine separate Verschlüsselung auf Nachrichtenebene über PKI Verfahren ist aufwendig, verlangsamt die Kommunikation und ist nicht empfehlenswert. Aus technischer Sicht ist es unerheblich, ob Zertifikate nur von RNE oder auch von anderen Quellen CAs kommen, solange diese als Trusted Authority in der Software (z.B. Java Keystore) registriert werden.

CI - Common Interface Implementation

Die von der RNE entwickelte und (mit Lizenz) verfügbare Referenzimplementierung ist im folgenden beschrieben.

Das Software-Paket kann von EVU bzw. EIU lokal installiert und konfiguriert werden. RNE CI agiert als Adapter (Local Instance) zwischen den Bestandssystemen (Legacy Systems) und anderen TSI-Teilnehmern (Remote CI). Die letzteren können die CI Referenzimplementierung oder eine eigene Implementierung des CI sein. Das RNE CI enthält folgende Komponenten:

• CI Web Service für eingehende und ausgehende Nachrichten inkl. Verschlüsselung, Signieren, Kompression
• Verwaltung der Metadaten (Schemas und Referenzdaten) sowie der Zertifikate und zusätzliche privater Stammdaten
• Konnektoren für Bestandssysteme (FTP, Dateien, JMS, SMTP, WebServices)
• Routing-Regeln für die Weiterleitung zwischen den internen und externen Systemen
• Mapping der TAF-TSI-Daten auf interne Datenformate (z.B. UIC 407-1) sowie manuelle (graphische) Mappings auf andere XML Datenformate Analyse: Die RNE CI Implementierung liegt aktuell in Version 2.1 vor. Das RNE CI unterstützt aktuell noch nicht den redundanten skalierbaren Betrieb mehrerer Instanzen mit Ausfallsicherheit, siehe auch das Dokument Common Interface Performance & Hardware Recommendation, Version 1.3, Kapitel 5.4. RNE Common Component Normal Deployment with Load Balancer and Failover: This deployment option is not yet practically implemented and tested yet.  Das RNE CI erlaubt den Betrieb und Konfiguration verschiedener CI-Instanzen pro Kommunikationspartner. Diese statische Zuordnung ist allerdings inflexibel verglichen mit der längst üblichen dynamischen Lastverteilung mittels Load Balancer. Analyse: Die fehlende Unterstützung der oben genannten nicht-funktionalen Anforderungen stellt ein erhebliches Risiko dar. Der Technologiestack von RNE CI umfasst unter anderem Wildfly 14.0.1 und MySQL 5.7. Der letztere wird nur bis 2023 unterstützt (vgl. https://endoflife.software/applications/databases/mysql). Für Wildfly 14.0.1 endet der reguläre Support im Februar 2023 (vgl. https://access.redhat.com/support/policy/updates/jboss_notes). Der Hauptanwendungsfall des RNE CI liegt auf der Integration der (unveränderten) Bestandssysteme in die TSI-Kommunikation. Dies erfolgt mithilfe der Konnektoren, Datenmappings und Routing-Regeln. Dies unterscheidet sich grundlegend vom Scope des Bestellsystems, das eine TAF/TAP-TSI-konforme Integration vom Vertrieb über den Fahrplan bis in den Betrieb ausgeht. Der Einsatz des RNE CI stellt ein hohes Risiko bzgl. der Flexibilität und Time-To-Market dar, da eine Unterstützung der neuen Funktionen und Fehlerbehebung stets seitens RNE erfolgen muss. Ein kritisches Bespiel hier ist die Unterstützung, der noch nicht final verabschiedeten CaseReference-Objekte, die für nationale Erweiterungen des TSI-Standards von entscheidender Bedeutung sind. Entscheidung: Für erste Tests mit Kommunikationspartnern kann das RNE CI für das neue Bestellsystem initial verwendet werden, um eine TSI-konforme Implementierung der Bestellsystem-CI sicherzustellen. Eine eigene DB Netz Implementierung sollte jedoch durch das Projekt sichergestellt werden. Begriffsdefinitionen:
• TSI - Technical Specification for Interoperability
• CRD -  Common Repository Domain: Europa-weite Metadaten, die im Central Reference Files Database des RNE verwaltet werden. Der letztere wird häufig ebenfalls als CRD bezeichnet.
• CA - Certification Authority: Service zur Ausgabe und Verifikation von digitalen Zertifikaten
• CI - Common Interface: Spezifikation einer gemeinsamen Schnittstelle für den Austausch von TSI Nachrichten
• RNE CI - Common Interface Reference Implementation: die von RNE entwickelte Integrationslösung für TAF/TAP TSI
• CCS - Common Components System: 
• LI - Local Instance: eine konkrete Installation des RNE CI
• UIC-Common Component: Synonym für RNE CI