Datenverteiler-System

Transkript

1

2 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

3 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

4 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)

5 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.)

6 Systemarchitektur Konfiguration Datenmodell Konfigurationsdaten Konfiguration Datenmodell Datenkatalog Konfigurationsdaten Kommunikationsinterface DaV sbibliothek DaV en Fachapplikationen Generische en en mit externen Schnittstellen (KEx) KEx TLS

7 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

8 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

9 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

10 Quellenunabhängigkeit normierte Daten Andere Verkehrsdaten FCD, DDG, Kommune, KEx Archiv Verkehrsdaten TLS KEx TLS DaV

11 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

12 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

13 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

14 Einsatz in Deutschland Neumünster Malchow Peißen Leverkusen Koblenz Frankfurt Nürnberg Stuttgart München