mdv aktuell II/06 – 5

In unserer vorletzten Ausgabe vonmdv-aktuell berichteten wir erfreut vomAuftragserhalt von LBSL (London BusServices Limited), der Regulierungsbe -hörde, die für die Koordination des ge -sam ten Busvehrkehrs in London zustän-dig ist. In dieser Ausgabe berichten wirnun ausführlich über die Arbeiten an die-sem Projekt.

Der Kunde LBSL

(London Bus Services Limited)

LBSL ist in London verantwortlich für Pla-nung, Ausschreibung, Betrieb und Über-wachung des Oberflächenverkehrs inLondon und für die Veröffentlichung derFahrpläne. Daneben betreut LBSL auchdie Infrastruktur und stellt technischeAusrüstung (Fahrscheindrucker, Funk,RBL) zur Verfügung. LBSL versorgt dasbestehende RBL mit Fahrplandaten undwird diese Aufgabe auch für das zukünf-tige Siemens-RBL übernehmen.Das von LBSL betreute Busnetz umfaßtüber 700 Linien, die von ca. 8.000 Bussenbedient werden. Bei sogenannten ‘highfrequency routes’ wartet der Fahrgast imSchnitt nur 6 Min. auf den nächsten Bus.An Werktagen werden bis zu 6 Mio. Pas-sagiere befördert. Es wird eine Fahrlei-stung von 700 Mio. km pro Jahr erbracht.Der Busverkehr in London ist vollständigprivatisiert. LBSL schreibt die Buslinien inder Regel alle 5 Jahre neu aus. Dabeiwerden von LBSL die gewünschteStrecken führung und die gewünschtenBedienfrequenzen je Tagesart vorgege-ben. Die zu bedienenden Haltestellenwerden nur grob vorgegeben bzw. sindbei der Ausschreibung teilweise nochnicht bekannt. Die Busunternehmengeben daraufhin ein Angebot für denBetrieb der Linie ab. Zu diesem Angebotgehört auch ein vollständig ausgearbei-teter Fahrplan. Die Unternehmen dürfenauch Varianten zu der von LBSL vorge-gebenen Streckenführung und derBedienfrequenz anbieten.LBSL ist auch für das Management derFahrplanänderungen zur Laufzeit desLinienvertrags zuständig. Wiederum gibtLBSL die Änderungen vor und das Bus -unternehmen muss einen passendenFahrplan ausarbeiten und zur Prüfungeinreichen.

Abb. 1 zeigt den typischen ‘Lebenslauf’einer LinieBei einer Neuausschreibung erarbeitetLBSL zunächst eine Spezifikation der

Linie. Die Unternehmen reichen Fahr -plan ent würfe ein. LBSL evaluiert die Ent-würfe, trifft unter den Unternehmen eineVorauswahl und fordert gegebenenfallsVerbesserungsvorschläge an. Letztend-lich bekommt ein Unternehmen den Zu -schlag. Danach sind noch Detailabstim-mungen des Fahrplans notwendig,außer dem muss das Unternehmen,bevor der neue Fahrplan in Kraft tritt,auch einen Fahrzeugumlaufplan undeinen Dienstplan vorlegen.Bei einer Fahrplanänderung ist der Vor-gang ähnlich. LBSL spezifiziert diegewünschte Änderung, die Unternehmenreichen so lange Fahrplanentwürfe einbis der Fahrplan den Anforderungen vonLBSL entspricht. LBSL verwendet derzeit das selbstent-wickelte System ’BusNet’ für die Planungdes Liniennetzes. Das System ist GIS-basiert und verfügt über ein komplexesLinienversionsmanagement. In BusNetwird aber nur die Topologie und die Geo-graphie der Linie verwaltet, es enthältkeine Fahrplaninformation.

Die Aufgabenstellung

Der oben geschilderte Austausch vonFahrplandaten geschieht heute teils aufPapierbasis, teils mittels spezieller

Datenschnittstellen. Grund dafür ist,dass bei den ca. 30 Busunternehmen inLondon die unterschiedlichsten Fahr-plansysteme im Einsatz sind, einige klei-

nere Unternehmen planen auch ‘vonHand’. Dadurch entsteht ein hoher Aufwand fürdie Bereitstellung aktueller und exakterFahrplandaten – schließlich hat LBSLeinige interne und externe technischeSysteme mit Solldaten zu versorgen, soz.B. das bestehende RBL und dieSchnittstelle zur EFA. Die mehr oderweniger manuelle Datenversorgung stelltnatürlich auch eine Fehlerquelle dar.Die fachlichen Anforderungen an dasneu zu erstellende System waren- Es sollte ermöglicht werden, daß die

Busunternehmer ihre Fahrplandatenauf elektronischem Weg einreichen.

- Dazu war zunächst einmal ein Stan-dardformat für die Datenübertragungzu entwickeln, das von allen sich imEinsatz befindlichen Planungssyste-men erzeugt werden konnte. Wichtigwar, daß nicht durch die Art derSchnittstelle ein Zugangshindernisgeschaffen wurde.

- Alle so eingereichten Fahrpläne solltenin einer zentralen Datenbank gespei-chert werden. Die Datenbank sollte einautomatisches Versionsmanagementbeinhalten, sodass kein eingereichterFahrplan durch eine neuere Versioneinfach überschrieben wird und jedeeingereichte Fahrplanänderung zu -

CAESAR - nicht nur ein römischer Staatsmann

Abb. 1: Lebenslauf einer Linie

6 – mdv aktuell II/06

rück verfolgt werden kann.- Die Fahrpläne sollten beim Einreichen

sofort geprüft werden, etwaige Fehlersollten an die Busunternehmer sofortzurückgemeldet werden.

- Da die eingereichten Fahrpläne im Falleiner Neuausschreibung zu den Aus-schreibungsunterlagen gehören, mussdas System diese vor unbefugtem Zu -griff schützen und sicherstellen, dassnur bestimmte Benutzer während derAusschreibung Zugriff darauf haben.

- Das System sollte nicht nur dem Bus -unternehmen ermöglichen, ihre Fahr-pläne einzureichen, sondern auchumgekehrt bestimmte Referenzdaten(z.B Linienverlauf, Tagesarten etc.) zurVerfügung stellen.

- Während des Lebenszyklus einer Liniesind unterschiedliche Abteilungen fürdie Fahrpläne zuständig. Das Systemsollte eine workflow-Komponente ent-halten, die jeweils die zuständigen Be -arbeiter informiert, wenn neue Datenvorliegen oder wenn Bearbeitungs -fristen überschritten wurden. Die work-flow-Komponente sollte auch sicher-stellen, dass die Fahrpläne zumrichtigen Zeitpunkt in der richtigenAbteilung sichtbar werden.

- Das System sollte LBSL bei der Prü-fung und Bewertung der Fahrpläneunterstützen. Dazu war eine Vielzahlan statistischen Auswertungen zu ent-wickeln.

- Es waren einige Schnittstellen zunach gelagerten Systemen zu ent-wickeln – zur Leistungskontrolle (per-formance monitoring), zum bestehen-den RBL, zur EFA, zumAus hang fahrplan.

- Es war eine Schnittstelle zum neubeschafften Siemens-RBL zu ent-wickeln. Das von LBSL beschaffte Sie-mens-RBL (codename ‘iBus’) stellt dasgrößte RBL-Projekt in der Geschichteder RBL-Systeme dar. LBSL hat dieAufgabe übernommen, dieses Systemmit Daten zu versorgen.

Daneben gab es noch eine Reihe vontechnischen Anforderungen- Das System sollte komplett browserba-

siert sein, um jedem Mitarbeiter vonLBSL online Zugriff auf aktuelle Fahr-plandaten zu ermöglichen und um

gleichzeitig den Installation- und War-tungsaufwand gering zu halten.

- Das System sollte mächtig genug sein,alle Fahrplandaten für 12 Jahre verfüg-bar zu halten.

- Die Performance des Systems solltehoch genug sein, um ca. 60 Bearbei-tern gleichzeitig ein flüssiges Arbeitenzu ermöglichen und zusätzlich einengelegentlichen Zugriff von ca. 300 Mit-arbeitern zu erlauben.

- Es sollte höchstmögliche Verfügbarkeit(99.95 %) während der Betriebszeitvon 8 – 20 Uhr gewährleistet werden.

Bei der Entwicklung waren einige fahr-plantechnische Besonderheiten zu be -achten, die zumindest im deutschspra-chigen Verbreitungsgebiet eher unüblichsind- Sehr hohe Bedienfrequenzen – da -

durch Schwerpunkt eher auf Einhal-tung der Taktfolge als auf Einhaltungabsoluter Fahrzeiten.

- Die Planung der Fahrzeiten basiert auf‘timing points’, Zwischenzeiten werdeninterpoliert.

- Auf vielen Linien existiert 24-Stunden-Betrieb, es werden separate Nacht-fahrpläne erstellt.

- Kein zentrales Fahrplanwechselda-tum, sondern Änderungen auf jederLinie je nach Bedarf

Die technische Lösung

Das System besteht aus folgenden Kom-ponenten (siehe auch Abb. 2: Systemü-bersicht)- Operator Communication Centre

(OCC)- Caesar Application Centre (CAC)- Oracle 10g Datenbank server- Hyperion Server

Das ‘Operator Communication Centre’ist der Teil des Systems, den die Bus -unter nehmer nutzen. Technisch handeltes sich um einen Windows 2003 Server,auf dem mittels Internet Information Ser-ver 6 eine Internet website bereitgestelltwird. Hier können die Busunternehmersowohl die Linienspezifikationen für neuausgeschriebene Linien oder Fahrplan -änderungen herunterladen, als auch dieerstellten Fahrpläne hochladen. DerZugang ist selbstverständlich nur mitBenutzer und Paßwort möglich. Um dieDatenübertragung zu schützen, wird dasSSL-Protokoll verwendet, das die mei-sten Computerbenutzer auch vomOnline Banking kennen.Das ‘Caesar Application Centre’ ist derTeil des Systems, der von den LBSLAngestellten genutzt wird. Hier handeltes sich ebenfalls um einen Windows2003 Server mit Internet Information Ser-ver 6. Allerdings sind die hier bereitge-

CAESAR - nicht nur ein römischer Staatsmann

Abb. 2: Systemübersicht

mdv aktuell II/06 – 7

stellten Applikationen nur im Intranet vonLBSL verfügbar. Neben der eigentlichenWebapplikation sind hier die Daten-schnittstellen zu den vor- und nachgela-gerten Systemen installiert. Alle Daten des Systems werden in einerOracle 10g Datenbank gespeichert.Sowohl OCC als auch CAC greifen aufdiese Datenbank zu. Als Systemplattformverwendet LBSL hier Sun/Solaris. Selbst -verständlich kann die Datenbank aberauch unter Windows betrieben werden.Bei ‘Hyperion’ handelt es sich um dieunternehmensweit eingesetzte Repor-ting-Lösung. Hyperion ist eine soge-nannte ‘Business Intelligence Solution’.Das System ermöglicht eine sehr flexibleErstellung von Reports auf Datenbank-basis (Stichwort data warehouse, datamart). Diese Reports können im Intranetfür alle Anwender verfügbar gemachtwerden.

Das System Caesar

Aus Sicht der Unternehmer

Der Busunternehmer öffnet im InternetBrowser den Link zum OCC (OperatorCommunication Centre) (siehe Abb. 3)und meldet sich mit Benutzer und Pas-swort an. Daraufhin gelangt er auf eineHomepage, in der er aktuelle Informatio-nen vorfindet. Dazu gehören- Liste der nächst ausgeschriebenen

Linien.- Liste der ‘eigenen’ Linien, auf denen

demnächst Fahrplanänderungen anlie-gen.

- LBSL-Nachrichtenbereich. Hier wer-den z.B geplante Wartungszeiträume,Verfügbarkeit neuer Daten etc.angekündigt.

Klickt er auf eine Linie, gelangt er zu denDetails dieser Linie, z.B. die Folge der zubedienenden ‘timing points’ (timing point= Haltestelle, an der die Fahrzeit definiertund überwacht wird) (siehe Abb.4).

In einem eigenen Downloadbereich stelltLBSL wichtige Referenzdaten zur Verfü-gung, z.B. Liste der offiziellen ‘timingpoints’, Liste der Tagesarten, Dokumen-tation des Systems etc. Außerdem wirdhier für Unternehmer, die kein eigenes

Fahrplansystem benutzen, ein speziellesExcel-Sheet bereitgestellt. Das Excel-Sheet wird mit der Linienspezifikationvorbesetzt und ermöglicht dann eine rela-tiv einfache Erfassung der Fahrplanda-ten. VBA-Makros ermöglichen eine Prü-fung der eingegebenen Daten.

Hat der Unternehmer einen Fahrplan fer-tiggestellt, kann er ihn in das Systemübertragen. Das System prüft die Datensofort und der Unternehmer kann fest-stellen, wo noch Probleme existieren.Das System ist dabei relativ tolerant.Sofern es sich nicht um fatale Fehler han-delt, wie etwa Formatfehler oder Inte-

CAESAR - nicht nur ein römischer Staatsmann

Abb.3: OCC - Homepage

Abb. 4: Schedule Header

Abb. 5: Validation Errors

8 – mdv aktuell II/06

gritätsfehler, wird der Fahrplan zunächsteinmal angenommen (siehe Abb. 5). DerUnternehmer erhält eine ‘Quittung’, dieer ausdrucken kann und die im Fall vonSystemproblemen als Beleg gilt (sieheAbb. 6).Selbstverständlich gibt es auch eine‘upload-history’ auf der alle vorangegan-gen Übertragungen notiert sind, und esgibt einen ‘Fahrplan-Viewer’, mit Hilfedessen der Unternehmer im Zweifelsfallprüfen kann ob alles richtig bei LBSLangekommen ist.

Aus Sicht LBSL

Jeder Systembenutzer hat ein oder meh-rere Rollen, üblicherweise in Abhängig-keit der Abteilung, in der er angestellt ist.Die Rollen steuern, welche Teile desSystems überhaupt sichtbar sind undwelche Aktionen möglich sind. Die im System gespeicherten Fahrplänehaben einen Bearbeitungszustand, ab -hängig von diesem sind die Fahrpläne fürdie einzelnen Abteilungen bzw. Benutzersichtbar oder nicht sichtbar. So gibt esz.B. die Zustände- Entwurf (Bestehender Vertrag)- Entwurf (Neu-Ausschreibung)- Unternehmer ist in Vorauswahl (für

Ausschreibung)- Linienfahrweg abgestimmt- Fahrzeiten fixiert- Umlauf / Dienstplan fixiert- LIVE- Abgelaufen

Meldet sich der Benutzer am System an,gelangt er zunächst auf eine Homepagemit aktuellen Systemnachrichten. Diesekönnen z.B. sein- Neue Linienspezifikation von BusNet

erhalten.- Unternehmer x hat neuen Fahrplan für

Linie y eingereicht.- Fahrplan xy: Zustand gewechselt

auf…- Linie xy: 6 Wochen vor Fahrplanwech-

sel und kein gültiger Fahrplan vorhan-den.

- Linie xy: 3 Wochen vor Fahrplanwech-sel und kein gültiger Fahrplan vorhan-den.

- Startdatum für Fahrplanwechsel aufLinie xy geändert.

Abb. 6: Upload Receipt

Abb. 7: CAC Homepage

Abb. 8: Schedule Overview

CAESAR - nicht nur ein römischer Staatsmann

mdv aktuell II/06 – 9

- usw… (siehe Abb. 7)In der Fahrplanübersicht können dieBearbeiter gezielt die vorhandenen Fahr-pläne durchsuchen. Dazu können ver-schiedene Filterkriterien eingegebenwerden, z.B.- Linie- Tagesart- Unternehmer- Tranche- Fahrplanbeginn- Bearbeitungszustand(siehe Abb. 8)Für die Betrachtung der Fahrpläne stehtein vielfältig konfigurierbarer Viewer zurVerfügung (siehe Abb.9).

Im Fahrplanmanager erfolgt die Überprü-fung und Bewertung der Fahrpläne

(siehe Abb. 10). Hier können die Bear-beiter die Fahrpläne auf den jeweilsnächsten Bearbeitungszustand setzen.Dabei werden die Prüfkriterien natürlichimmer strenger. So müssen anfänglichnicht einmal alle Haltestellen vorhandensein – im Endzustand dagegen müssendie Fahrpläne mit korrekter Umlauf – undDienstinformation vorliegen.

Für die Analyse und Bewertung derFahrpläne wurden einige spezielleDarstel lungen entwickelt, z.B.- Der ‘Headway and running time view’,

auf dem man zusätzlich zu den abso-luten Fahrzeiten auch die relativenFahrzeiten zwischen den ‘timingpoints’ und die Taktzeiten zwischenden Fahrten sehen kann.

CAESAR - nicht nur ein römischer Staatsmann

- Der ‘Corridor view’: Eine den DIVA-Mischlinien ähnliche Ansicht, die esermöglicht, alle Fahrten aller Liniendarzustellen, die eine ausgewählteFolge von Haltestellen bedienen.

- Der ‘Day type comparison view’, mitdem die Fahrpläne verschiedenerTagesarten verglichen werden könnenund Differenzen sichtbar gemacht wer-den können.

- Der ‘24 hour view’: Ermöglicht eineGesamtdarstellung von Tag- undNachtfahrplänen.

Projektablauf

Direkt nach der Auftragserteilung am 19.August 2005 wurde mit der Pflichtenheft-phase begonnen. Hier galt es, aus ca.300 Einzelanforderungen ein System zuentwerfen. Nach einer sehr intensivenPhase des gegenseitigen Kennenler-nens und miteinander Arbeitens standdas Pflichtenheft Anfang Oktober.Zusätzlich dazu musste ein technischesDatenaustauschformat für die Fahrplan-daten spezifiziert und mit den Busunter-nehmen und deren Planungssystemher-stellern abgestimmt werden. Auch diesgelang bis Mitte November. Um dieAbstimmung mit den vielen Beteiligten zubeschleunigen, wurde ein Wikipedia-Ser-ver aufgesetzt, auf dem sich alle Beteilig-ten auf dem neuesten Stand halten konn-ten. Unmittelbar im Anschluss an diePflichtenheftphase wurde eine techni-sche Detailspezifikation des Systemserarbeitet und mit den Fachleuten vonLBSL abgestimmt. Parallel dazu wurdenbereits Vorarbeiten für die Entwicklunggeleistet. Noch vor Weihnachten konnten dann dieersten Komponenten des Systems livebesichtigt werden. Dazu hat mdv eineInternet Website errichtet, die es denLBSL Kunden ermöglichte, die Applika-tion von London aus zu testen.Im Februar 06 wurden dann in einem ein-wöchigen Workshop die Testszenarienfür den Akzeptanztest identifiziert. Hierwaren Vertreter aller Abteilungen betei-ligt, die das System später verwendenwürden. Insgesamt wurden ca. 70 Test -szenarien ausgearbeitet.

Abb.10: SchedManager

Abb.9: SchedViewer

10 – mdv aktuell II/06

CAESAR - nicht nur ein römischer Staatsmann

Anfang März 06 wurde dann zunächstder technische Integrationstest durchge-führt. Hier wurde geprüft, ob Caesar mitdem vorgelagerten BusNet-System kor-rekt zusammenarbeitet, und ob die inter-nen LBSL-Systeme mit den von CAESAR generierten Ausgabedatenfunktionieren.Der Akzeptanztest für Caesar selbstwurde in zwei Schritten durchgeführt:Zunächst wurde die für die Busunterneh-mer vorgesehene Website getestet undim April in Betrieb genommen, zunächstohne upload-Funktionalität. Dies war not-wendig, damit die Busunternehmer sichbereits die Referenzdaten für die näch-sten geplanten Fahrplanänderungen her-unterladen und mit den Vorarbeitenbeginnen konnten.

Im April 2006 begann dann nach Osterndie heiße Phase des Akzeptanztests fürden Intranet-Teil der Anwendung. Insge-samt vier Wochen lang wurde dasSystem von den LBSL-Anwendern aufHerz und Nieren getestet, mdv hat dabeipro Woche mindestens ein Update zurVerfügung gestellt. Nach einer gewalti-gen Anstrengung aller Beteiligten gelanges, das System termingerecht am 22. Mai2006 in Betrieb zu nehmen. Mittlerweileläuft das System 4 Wochen ohne größereProbleme und es wurden bereits über 80Fahrpläne elektronisch übermittelt.

LBSL Teammitglieder von links nach rechts: Alex Moffat, Steve Robinson, William Elcock, Andy Corbett, Phi-

lippa Taylor, Mark O’Donovan, Wayne Butler

Natürlich hat auch uns der Entwick-lungsprozess des Projektes interessiertund wir haben Alex Moffat gebeten unsInformationen darüber zu geben, die wirhier gerne weitergeben möchten.

Würden sie uns bitte ihre Aufgaben

bei London Buses näher

beschreiben?

London Buses plant, bestimmt, beschafft,überwacht und publiziert den öffentlichenVerkehr der Londoner Busse. Außerdemsind wir verantwortlich für die Infra -struktur (z. B. Busbahnhöfe und Halte -stellen) und bieten die technische Ausrü-stung an (z. B. Fahrkarten auto maten,Funkgeräte und RBL). Der Bus dienstselbst wird von privaten Busunter -nehmern angeboten, die sich in Konkur-renz für einzelne Routen bewerben. DieUnternehmer erstellen ihren eigenenFahrplan, der an unsere Vor gaben ange-glichen werden muss. Meine Aufgabebesteht darin zu garantieren, dass dieAusführung der Busunter nehmer denStandards entspricht, die wir in den Ver-trägen festegelegt haben. Wir überwa-chen laufend die Leistung der Unterneh-mer und arbeiten ständig mit ihnen daranProbleme zu lösen. Teil dieser Arbeit istes zu garantieren, dass die geplantenFahrplanänderungen rationell und effek-tiv ausgeführt werden. Wir verfolgen alleFahrplanänderungen in unserem Systemund stellen sicher, dass die Ausführungunseren Erwartungen entspricht.

Was ist die Hauptzielsetzung des

CAESAR Projekts ?

Viele Dienststellen quer durch Tfl/LBSLbenötigen Fahrplaninformationen für ver-schiedene Zwecke, wie z.B. für dieBewertung von Verträgen, für dieLeistungs überwachung oder für dieErstellung von Veröffentlichungen. DieseDienststellen erhielten vom BetreiberFahrpläne in verschiedenen Formaten.Dies hat zunehmend zu Datenqualitäts -problemen und Unwirtschaftlichkeit geführt,verursacht durch die Notwendigkeit,Daten manuell zu erfassen und dann mitden Referenzdaten in den LBSL-Daten-banken zu verbinden. Zusätzlich (undentscheidend) war, dass die Leistung des

Ihr Ansprechpartner:Wilfried Düxduex@m.mentzdv.deTel.: +49 (0)89 418 68-114

mdv aktuell II/06 – 11

kürzlich mit Siemens neu entwickelteiBus Systems abhängig ist von genauenund rechtzeitigen Fahr plandaten ineinem einheitlichen Format.Deshalb sind die wichtigsten Ziele desProjekts:- Sammeln der Fahrplandaten in einer

Quelle- dem Betreiber eine Möglichkeit bieten

seine Fahrpläne in elektronischer Formzu liefern

- den Fahrplan-Bearbeitungsprozessbei LBSL zu rationalisieren

- rechtzeitige Lieferung genauer Fahr-planinformationen zu unseren Be -triebs systemen (iBus, EFA, RBL, TABSund SSTT)

Ein paar Worte über das LBSL Caesar

Projekt Team

Das Projektteam wurde zusammenge-setzt aus den Mitarbeitern von LBSL, dieverantwortlich sind für die Spezifizierungund die Ausschreibung der Busdienste,Durchführung der Fahrplanänderungen,und Einführung des neuen iBus RBL -Systems. Zusätzlich wurde ein Mit -arbeiter der Beratungsgesellschaft PAConsulting für die Laufzeit des Projektesals Projektleiter eingesetzt.

Alex Moffat (LBSL) ist Leiter der Abtei-lung zur Leistungsüberwachung undGesamtverantwortlicher des Projekts beiLBSL.Will Elcock (PA Consulting) war der Pro-jektleiter.Mark O’Donovan (LBSL) ist Leiter derAbteilung für die Ausschreibung der Ver -kehrsleistungen.Wayne Butler, Andy Corbett und Ian Wal-ker sind erfahrene Sachbear -beiter/Anwender der (bestehenden) EDV.Pip Taylor ist Arbeitsgruppenleiterin undunterstützt den Projektleiter Will Elcock.Steve Robinson (TSG) analysiert dieGeschäftsprozesse, unterstützt die tech-nische Entwicklung und stellt die Ver -bindung zum Projekt iBus (RBL-Ein-führung) her.

Ein paar Worte über den Ausschrei-

bungsprozess. Wie wurde er vorberei-

tet und warum wurde mdv als Auftra-

gnehmer ausgewählt.

Es wurde eine Zusammenstellung derAnforderungen erstellt an der alle ent-scheidenden Interessenvertreter beteiligtwaren. Es wurde dann eine Rangfolgeder Anforderungen für die Ausschreibungfestgelegt. Der Auftrag wurde nach EURecht ausgeschrieben. 35 Firmen hattenanfangs ihr Interesse an der Aus -schreibung ausgedrückt. Das Angebotvon mdv wurde schließlich aus folgen-den Gründen ausgewählt:- einer genauen verständlichen Dar -

stellung der LBSL Anforderungen unddie Fähigkeit, eine entsprechendeLösung zu liefern

- ein engagiertes und erfahrenes Pro-jektteam

- Einhaltung der von LBSL angegebe-nem Zeitrahmen

- Hinweis auf vor-Ort-Betreuung- Preis-/Leistungsverhältnis

CAESAR wurde in München ent-

wickelt und implementiert. War die

Entfernung zwischen mdv und LBSL

ein Problem für den Support?

Aus der Tatsache, dass mdv in Münchenund nicht in London ist, ergaben sichkeine zusätzlichen Probleme. mdv warmit LBSL in täglichem telefonischen undemail-Kontakt, und wenn notwendig,wurden persönliche Treffen mit den inenglisch sprachgewandten mdv-Mit -arbeitern in London vereinbart.

Was sind aus ihrer Sicht die kritisch-

sten Phasen und Herausforderungen

in der Entwicklung des Systems?

- Ein System anzubieten, das allenBusunternehmern (die verschiedeneFahrplanerstellungssysteme benut-zen) eine Schnittstelle bietet.

- Eine Schnittstelle anzubieten zwischenCAESAR und dem bestehenden undzukünftigen LBSL-Systemen.

- Das Projekt hat einen sehr engen Zeit-rahmen durch die iBus Entwicklung mitSiemens.

- Erreichen der Zusammenschlüsse vonzahlreichen betriebsinternen Abteilun-gen von TfL, die die Fahrplandatenbenutzen.

- Erweiterung bestehender Systeme(Busnet, Confirm) und Sicherstellen,

dass die LBSL Bezugsdaten brauchbarund fehlerfrei zur Verwendung in CAESAR und iBus Systemen sind.

Das System ist nun seit 4 Wochen in

Betrieb. Können sie schon eine erste

Zusammenfassung über die Leis -

tungen des Systems und die An -

wenderakzeptanz aufzeichnen?

- CAESAR funktioniert gut und die An -wender sprechen von guter Leistungund leichter Bedienung.

- Die Leistung war gut bei minimalerAusfallzeit für Korrekturen.

- Es gab einige offene Punkte aus demAkzeptanztest, die aber von mdv

abgearbeitet werden und im nächstenRelease des Systems zum Test bereit-stehen werden.

Wieviele neue Linienausschreibungen

und Fahrplanänderungen werden in

Zukunft durch das neue System pro

Jahr verarbeitet werden?

LBSL schreibt ungefähr 20 % - das sindca. 150 Linien - seines Busnetzes jährlichneu aus. Für jede Linie bekommen wir imDurchschnitt 3-4 Angebote, welche Fahr-pläne für jeden Tagestyp enthalten unddazu noch eine Vielzahl von zusätzlichenOptionen. Alles in allem sind das unge-fähr 500 Linienfahr plan wechsel pro Jahr.

Was sind die Erwartungen in der

Zukunft vom System CAESAR ?

- Eine erfolgreiche Kopplung zum iBusSystem (Siemens RBL).

- Die bestmöglichste Nutzung der Mög-lichkeiten, die durch EDV-gestütztenFahrplandaten angeboten werden, z.B. genaue und rechtzeitige Veröffentli-chung (JP, SSTT etc.) sowie genaueund vollständige Auswertung der Fahr-pläne.

- Weitere Automatisierung der Fahrplan-bewertung und -auswertung.

- Nachdem das System von einer breite-ren Anwenderbasis genutzt wird,erwarten wir eine weitere Optimierungdes Arbeitsablaufs und eine Weiterent-wicklung der Benutzeroberfläche.

- Das System soll die wichtige Kommu-nikation zwischen Anwendern und denBusunternehmen verbessern.

CAESAR - nicht nur ein römischer Staatsmann