Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

23.03.1990 - 

DB-System mit richtungsweisenden Akzenten für ausländische Staatsbahnen

Kurs '90 soll Programmierer nur noch selten auf den Plan rufen

Bei Kurs '90, dem rechnergestützten "Kundenfreundlichen Reise-, Informations- und Verkaufssystem" der Deutschen Bundesbahn, mußten harte Nüsse insbesondere hinsichtlich Benutzeroberflächen, DFÜ und Bahntarifen geknackt werden. Einer der obersten Leitsätze lautete, nachträgliche Änderungen an der eingesetzten Software auf SQL-Basis weitgehend auszuschließen.

Obwohl die eigentliche Designphase erst im Januar 1988 begann, wurde mit dem Entwurf und der Programmierung von systemnahen Funktionen bereits im Oktober 1987 begonnen. Voraussetzung dafür war eine bindende Strukturierung des Gesamtsystems, die vorsah, sowohl die Verwaltung von 1800 eigenständigen Rechnern als auch den Einsatz der Host-Software als Rückfall-Lösung zu ermöglichen. Dies geschieht mit Hilfe eines einheitlichen Programmsystems, das fast völlig datengesteuert alle Berechnungen durchführt, so daß in Zukunft nur bei erheblichen Verschiebungen im Rahmen der Tarifstruktur Änderungen am Programm vorzunehmen sind. Dieser Punkt ist von zentraler Bedeutung, da die außerordentlich komplizierte Tarifstruktur der Bahn zunächst datentechnisch analog abgebildet werden mußte.

Gikom ist hier ohne vertragliche Absicherung mit der Realisierung systemnaher Applikationen in Vorleistung getreten, da der festgelegte Endtermin für die Einführung von Kurs '90 sonst nicht hätte eingehalten werden können. Überhaupt stellte sich in der Folgezeit heraus, daß die sonst strikt eingehaltene Trennung von System-planung, Design und Realisierung nicht durchsetzbar war, da der Projektablauf dadurch beeinträchtigt worden wäre.

So ist es zu erklären, daß das Design der SQL-Datenbank auf dem Host ebenfalls bereits im Oktober 1987 mit der Installation der NonStop-SQL-BetaVersion und der parallel dazu durchgeführten Schulung von zwei Gikom- und zwei Tandem-Mitarbeitern begann. Der Vertragsabschluß für Fin/Faus Stufe 1 erfolgte Ende November 1987 und sicherte die bis dahin geleisteten Arbeiten rechtlich ab.

In diesem Zusammenhang wurde seitens der Gikom im Dezember '87 mit der Systemplanung zusätzlicher Module begonnen, die damals erst für die zweite Stufe von Kurs '90 angedacht waren Diese Konzeptionierung nahm einige Wochen in Anspruch, so daß erst im Januar 1988 das eigentliche Design und die Programmierung von Datenbank- und Hilfsfunktionen begann. Zu diesem Zeitpunkt waren sechzehn Mitarbeiter voll im Einsatz.

Der Designbeginn des Teilprojekts "Fin/Faus Stufe 1" fiel in den Februar 1988. Das vorgesehene Ende dieses Abschnitts wurde mit April 1988 terminiert. Tatsächlich zogen sich diese Arbeiten aufgrund zahlreicher Einzelprobleme (Verbindung der ITs und des Hosts über zwei völlig unterschiedliche DFÜ-Netze, Transdata von Siemens mit Berücksichtigung des Anschlusses des Start-Reisebürosystems und das bahneigene Integrierte Netz IN auf der Basis von X.25) dann bis August 1988 hin, wobei bei den weiteren Überlegungen berücksichtigt werden mußte, daß eine Überlastung des Transdata-Netzes in jedem Fall zu vermeiden war. Gleichzeitig war klar, daß die Verknüpfung zweier derart verschiedener Netze softwaretechnische Neuentwicklungen verlangen würde. Hier seien APS-Programme und MSV-Treiber genannt.

Eine wesentliche Aufgabe bestand dann in einer prinzipiellen Unterscheidung von Stammdaten und "Lerndaten", um die lokale Autonomie der angeschlossenen ITs zu erhalten. Es sollte gewährleistet sein, daß etwa 80 Prozent aller Fahrscheine offline verkauft werden können. Dieses kontrollierte Nebeneinander von lokalen und zentralen Funktionen macht auf allen Ebenen den Hauptaspekt der Kurs '90-Software aus.

Im Hinblick auf die anfallende Datenmenge, die es rund um die Uhr schnell, sicher, komfortabel und ökonomisch zu verarbeiten, verteilen und verwalten gilt, war die meßbare Beschleunigung interner Kommunikationsabläufe eines der Kriterien für den Erfolg. Dabei hatten Studien im Vorfeld gezeigt, daß nur die entschiedene Reduzierung des Online-Betriebs jene Belastbarkeit und Variabilität des Systems gewährleisten kann, die den größten Vorteil von Kurs '90 beschreibt. Deshalb beruht die Systemarchitektur auf einer ausgewogenen Mischung von Online- und Offline-Komponenten.

Doch auch auf den Monitoren sollte sich einiges tun. So sah das Design eine Abkehr von den herkömmlichen, "programmierten" Bildschirmmasken vor, die durch sogenannte "dynamische Masken" ersetzt worden sind. Ihr größter Vorzug besteht darin, erst während des Verkaufsvorganges aus der Datenbank erstellt zu werden. Sie sind Bestandteil eines eingabeabhängigen Systems, das auf die Fragen: "wann", "mit welcher Art Fahrschein", "unter welchen Sonderbedingungen" und "wohin" eine Konsistenzprüfung macht und daraufhin in Abhängigkeit vom jeweils gültigen Tarif nur die Maske lädt, die dem Anfrageprofil exakt entspricht. Dadurch sind für den Bediener, je nachdem, welchen Fahrschein er zu erstellen hat, lediglich die Felder auf dem Monitor sichtbar, die für den speziellen Fall erforderlich sind. Mit diesem ergebnisorientierten Bildaufbau werden Eingabefehler und überflüssige Cursor-Bewegungen absolut minimiert. Diese Art der Feldernachblendung leistet einen nicht zu unterschätzenden Beitrag zur Verbesserung der Ergonomie am Arbeitsplatz.

In einem weiteren Schritt wurde die datengesteuerte Übernahme von Feldinhalten vom Bildschirm auf den zu druckenden Fahrschein geregelt, weshalb keinerlei Programmanpassungen mehr nötig sind, die sich auf Datenanforderungen beziehen, die aktuell nicht zur Berechnung benötigt werden (Paßnummer, Flugticketnummer). Die Position, Attribute, Feldgrößen, Felddefaults und Feldwerte für Bildschirm und Druckausgabe sollten nach Fertigstellung des Systems ausschließlich in der Datenbank gepflegt werden können. Und zwar unmittelbar von der "Zentralstelle Absatz" der Bundesbahn selbst, was heißt, daß die eingabe der erforderlichen Informationen keinerlei Support von DV-Spezialisten verlangt, sondern durch Fachleute der Verkaufsorganisation erfolgt. Damit verwirklicht die reine Datensteuerung des Systems eine außerordentliche Transparenz der Softwarestruktur. Für die Nutzer ist völlige Selbständigkeit gegeben.

Herzstück ist die in Frankfurt eingerichtete NonStop-SQL-Datenbank, in der sämtliche Informationen für den Fahrscheinverkauf abgelegt sind. Die Arbeitsplatzrechner in den Bahnhöfen wurden über das bundesbahneigene X.25-Netz angeschlossen. Sie verfügen nun über einen 20 MB-Stammdatenbestand mit standortspezifischen Daten für den Routinebetrieb und eine Lerndatei. Ihre stattliche Speicherreserve von über 50 MB dient zur Abwicklung des eigentlichen Schaltergeschäfts. Die Host-Software hat einen Umfang von 300 000 LOC (300 Programme), die IT-Software kommt gesondert auf 230 000 LOC (380 Programme).

Abfragen von Entfernungs- und Wegewerten beim Host finden nur noch einmal "auf Bestellung" statt. Resultate werden gespeichert. Im Wiederholungsfall greifen die ITs dann auf die eigene Platte zurück, so daß Preisberechnungen direkt auf den PCs stattfinden und die Zentralanlage entlasten. Außerdem kann der Schalterdienst bei eventuell auftretenden Leitungsproblemen weitgehend offline fortgesetzt werden, wohingegen bei Störungen am IT der Online-Zugriff möglich bleibt. Zeitkritische Verzögerungen werden netzweit vermieden. Redundante Rechenzeiten fallen fort. Wertvolle Zeit und Leitungswege bleiben dadurch verfügbar, um bei Bedarf Anpassungen des Datenbestandes vornehmen zu können. Sogar äußerst kurzfristige Änderungen der Systemparameter (etwa in der Tarifdatei) können durch ein vollautomatisches Download-Verfahren an jedes IT weitergegeben werden. Das verkürzt die früher üblichen Vorlaufzeiten ("Rosa Wochen"!) und erlaubt eine sehr bewegliche Angebotspolitik. Selbst heute noch gar nicht existente Tarife, wie etwa zeit- oder streckenführungsabhängige Preise, sind jederzeit einrichtbar. Ebenso denkbar ist eine spätere Einrichtung sogenannter selektiver Verkaufsstrategien, zu denen die "Last-Minute" -Angebote zählen.

Die erste Testrunde auf der hauseigenen Tandem-Anlage der Gikom fand im Januar 1989 statt, die zweite Testrunde bei der DB folgte im Februar.

Der eigentliche Probebetrieb in den beiden eigens ausgewählten Intercity-Knotenpunkten Gießen und Wiesbaden wurde dann im März 1989 gestartet. Bundesweit sind inzwischen bereits mehr als 900 ITs (Endausbau: 1100) installiert, womit die Umstellung auf das neue System als weit vorangeschritten einzustufen ist. Bis es soweit war, wurden von allen Beteiligten zirka 30 Mannjahre in zwei Zeitjahren geleistet - erfreulicherweise mit dem guten Resultat, daß Kurs '90 das erste Großprojekt der Bundesbahn ist, dessen Inbetriebnahme vertragsgetreu und termingerecht erfolgt.

Dabei sind übersichtliche Bedienerführung, Funktionsschutz, Wartungsfreundlichkeit und Erweiterbarkeit selbstverständliche Features des Systems. Im Endausbau werden diese Merkmale voll realisiert. Der zu erwartende Folgeaufwand für Wartung und Pflege ist dementsprechend gering. In diesem Sinne ist Kurs '90 Prüfstein der Zukunft und doch schon der Zukunft etwas voraus.

Die hier geschilderten Innovationen der Deutschen Bundesbahn sind richtungsweisend über ihren nationalen Geschäftsbereich hinaus. Im Vorgriff auf den europäischen Verkehrsverbund des Jahres 2000, der zugleich auch ein europäischer Rechnerverbund sein wird, zeichnet sich ein lebhaftes Interesse ausländischer Staatsbahnen ab, dem Beispiel der DB zu folgen und ihrerseits entsprechende Anwendungssoftware in Angriff zu nehmen.

Außer Dänemark, Österreich, der Schweiz, der Tschechoslowakei und Polen hat Australien Interesse an der zukunftssicheren Software von Kurs '90 gezeigt.

Speziell für die Disposition und die lückenlose Überwachung des Güterverkehrs ist ein Folgeprojekt "InterCargo" vorgesehen. "Hermes soll die Bereitstellung von Bahninformationen über Ländergrenzen hinweg internationalisieren. Mit "Docimil" denkt man daran, das frachtbegleitende Papier durch ein elektronisches "Dokument" zu ersetzen.

Gikom ist an diesen Bestrebungen schon jetzt durch mehrere Releases ihres europaweit in über 50 Installationen verbreiteten FTS (File Transfer Systems) beteiligt, mit dem einige Großkunden der Bahn Datensätze zur Anmeldung, Abstimmung und Kontrolle ihres Transportbedarfs über Datex-P versenden.

Mit Fin/Faus ist die Bahn auf einem guten Weg zu einem führenden verkaufsorientierten Dienstleistungsunternehmen des nächsten Jahrzehnts zu werden.

*Peter Welge ist geschäftsführender Gesellschafter des System- und Softwarehauses Gikom in Bonn.