Externe Externe Externe Schnittstelle Schnittstelle Schnittstelle Externe Externe Schnittstelle Schnittstelle Aktuelle Situation 2-mal implementiert 1-mal implementiert UZ 1 M1 M2 DB Mn neu 3-mal implementiert VRZ Konfiguration / Parametrierung Datenhaltung / Auswertungen Datenhaltung & Archiv UZ 2 M1 M2 DB Mn neu LVE Grundfunktionen (Steuer-) Modelle n-mal implementiert n-mal implementieren n-mal testen n-mal dokumentieren n-mal bezahlen UZ m M1 M2 DB Mn neu
Aktuelle Situation Mehrfache Entwicklung der gleichen Funktionalität Kein einheitliches Vorgehensmodell bei Spezifikation und Realisierung Unabhängigkeit der Einzelprojekte Integration wird i. d. R. völlig vernachlässigt Zu wenig (keine) Vorgaben/Detaillierung bei der Systemtechnik Fachliche Vorgaben zu grob Ergebnisse damit letztendlich unterschiedlich Nebeneinander der Systeme Unterschiedliche Bedienung mit Gefahr der Fehlbedienung sowie hohem Schulungsaufwand Mehrfacherstellung mit Mehrfachtest der Software, hohes Fehlerrisiko Software ist plattformabhängig Software ist herstellerabhängig
Ziele des s Plattformunabhängigkeit TCP/IP Java Organisationsunabhängigkeit Datenmodell definiert sich selbst (Metamodell) Datenmodell besteht aus Teilmodellen (Erweiterbarkeit) System kennt vor Start keine Funktionalität (Generizität) Zukunftssicherheit (Wirklich) offene Schnittstellen Gekapselte Kommunikation (Geheimnisprinzip) Konfiguration enthält Wissen über die Umgebung und verteilt dies auf alle Anwendungen Alle funktionalen Einheiten sind gekapselt (Austauschbarkeit, Unabhängigkeit)
Entwurfsprinzipien Entkopplung fachlicher Einheiten Modularisierung Kapselung (Unabhängigkeit der Module untereinander) Austauschbarkeit Übertragbarkeit Erweiterbarkeit Unabhängigkeit von HW-Einheiten System muss beliebig auf Rechner aufteilbar sein Aufteilung/Umorganisation darf keine SW-Änderungen nach sich ziehen Unabhängigkeit von Aufbauorganisationen Systemarchitektur muss freie Zusammenstellung der Module zu aufbauorganisatorischen Einheiten ermöglichen (VRZ, UZ, etc.)
Systemarchitektur Konfiguration Datenmodell Konfigurationsdaten Konfiguration Datenmodell Datenkatalog Konfigurationsdaten Kommunikationsinterface DaV sbibliothek DaV en Fachapplikationen Generische en en mit externen Schnittstellen (KEx) KEx TLS
Systemarchitektur Konfiguration Datenmodell Konfigurationsdaten VRZ DaV Konfig Datenmodell Datenkatalog Konfigurationsdaten Kommunikationsinterface DaV sbibliothek UZ DaV Konfig Datenmodell Datenkatalog Konfigurationsdaten en Fachapplikationen Generische en en mit externen Schnittstellen (KEx) KEx TLS
Konfiguration Bereitstellung und Verwaltung aller Konfigurationsdaten Konfigurationsdaten: definierende Daten zu Objekten, z. B. MQs, AQs, Anlagen, Streckenstationen, DEs, Systemobjekte, etc. Dynamische Konfigurationsdaten: Stauobjekte, etc. Konfiguration Datenmodell Datenkatalog Konfigurationsdaten DaV KEx TLS
Quellenunabhängigkeit Kommunikation mit externen Partnern (KEx) Externe Partner werden über spezielle Softwareeinheiten angeschlossen Alle schnittstellenspezifischen Besonderheiten werden in den KEx-Modul behandelt Das kann nicht mehr erkennen, aus welchem externen System Daten gekommen sind Daten werden auf einheitliches Format normiert Beispiel TLS: vpkw = 255 nicht ermittelbar
Quellenunabhängigkeit normierte Daten Andere Verkehrsdaten FCD, DDG, Kommune, KEx Archiv Verkehrsdaten TLS KEx TLS DaV
Motivation Vorteile/Nutzen für Behörden/Hersteller/Ingenieurbüros Investitionsschutz Unabhängigkeit Reduktion von Kosten Flexibilität Konzentration auf Kerngeschäft Konzentration auf Optimierung/Erweiterung Vergrößertes Leistungsspektrum
Vorteile der gewählten Lösung Vorteile aus Betreibersicht Reduktion der Komplexität eines solchen Systems durch Verwendung weniger, einheitlicher Schnittstellen sowohl für interne als auch externe Kommunikation. Kostensenkung durch Mehrfacheinsatz der gleichen Software und durch das Open-Source-Prinzip. Zeitgewinn: Standardanwendungen sind schnell installiert. Bei neuen Funktionalitäten müssen nur die entsprechenden anwendungsspezifischen en erstellt werden und nicht die Gesamtsysteme. Verbesserung der Qualität: Durch den Mehrfacheinsatz der Software wird das System insgesamt robuster. Akzeptanzgewinn: Die anwendungsspezifischen Algorithmen sind bewährt und führen zu plausiblen Anzeigen für den Verkehrsteilnehmer. Erhöhung der Wirksamkeit von Verkehrsbeeinflussungsanlagen: Die standardisierten und vielfach überprüften verkehrstechnischen Algorithmen und die Akzeptanz der Verkehrsteilnehmer erhöhen die Wirksamkeit solcher Anlagen
Vorteile der gewählten Lösung Vorteile aus Systemsicht Einfache, übersichtliche Struktur des Gesamtsystems Einheitliche, fest definierte Schnittstelle für alle en Beliebige Verteilung der en auf mehrere Rechner Einfacher Erweiterbarkeit um zusätzliche en Einfacher Austausch einer bestehenden durch eine Variante (z.b. anderer Berechnungsalgorithmus) Einfache Erweiterbarkeit um zusätzliche Daten (Telegramme) Unabhängigkeit der en untereinander
Einsatz in Deutschland Neumünster Malchow Peißen Leverkusen Koblenz Frankfurt Nürnberg Stuttgart München