Wer durch eine Fahrzeugpanne einmal zum Nothalt gezwungen wurde, erinnert sich vielleicht an ein eher beiläufiges Problem in dieser ohnehin ärgerlichen Situation: Die Frage der via Handy herbeigerufenen Helfer nach der Position des liegen gebliebenen Wagens brachte so manchen Pechvogel in Verlegenheit. Glück im Unglück haben hier Fahrzeuglenker, die über einen Telematikdienst in ihrem Auto verfügen. Dieser ermittelt anhand des Global Positioning System (GPS) die exakten Positionsdaten und sendet sie per SMS zum Beispiel an ein ADAC-Call-Center. Eine aufgrund der unidirektionalen Übermittlung recht einfache Anwendung, erklärt Heinz Schneeweiss, Leiter der Telematik Systementwicklung (TSE) beim ADAC. Deutlich aufwändiger gestalten sich dagegen bidirektional arbeitende Applikationen, wie sie ein derzeit besonders häufig nachgefragter Service erfordert: die Abfrage von Verkehrsinformationen für einen bestimmten Streckenabschnitt.
Das Problem bei der Entwicklung solcher Dienste liegt in der Vielzahl der Telematikprotokolle, die zurzeit noch nicht standardisiert sind. "Jeder, der in diesem Umfeld Systeme einrichten will, kämpft mit der Implementierung proprietärer Kommunikationsprotokolle", beschreibt Schneeweiss die Situation. Entsprechende Projekte erfordern je nach Komplexität einen Aufwand von zwei bis zehn Mannmonaten. Welche Verantwortung auf den Entwicklern lastet, zeigt sich besonders bei der bidirektionalen Kommunikation. Protokollfehler können die Endgeräte in einen undefinierten Zustand versetzen und so schlimmstenfalls eine Rückrufaktion in die Werkstatt auslösen, wo sie reaktiviert werden müssen.
Damit entpuppt sich die Fähigkeit, Protokolle möglichst schnell und robust implementieren zu können, als einer der kritischen Erfolgsfaktoren im Telematikumfeld. Die Abteilung TSE um Schneeweiss nahm sich dieses Problems an und startete Anfang 1999 im Auftrag der ADAC Telematik GmbH (ATG) das Projekt Plato. Der zuvor erfolgten Ausschreibung des Projekts folgte das Angebot einer externen Firma, das jedoch um 40 Prozent über den intern veranschlagten Kosten lag.
Die an Plato herangetragenen Anforderungen beschränkten sich keineswegs auf eine schnelle Protokollimplementierung. Die bekannten Dienste für "Panne/Notruf", "Verkehrsinformationen" etc. sollten sich ohne großen Aufwand um neue Services wie das Aktivieren einer Fahrzeugdiagnose, die Diebstahlverfolgung oder Routenführung erweitern lassen. Darüber hinaus ist der ADAC bestrebt, seine Telematikdienste europaweit im Verbund mit den jeweils nationalen Automobilclubs anzubieten. Für die Anwendung bedeutete dies, neben der Unterstützung mehrerer Sprachen auch über Schnittstellen zu verfügen, die eine Integration in die verschiedenen Telefon- und Geo-Informationssysteme erlauben.
Damit war klar, dass Plato modular entwickelt werden musste, um die einzelnen Komponenten leichter warten und gegebenenfalls austauschen zu können. Über die Verwendung von Entwurfsmustern wurden Funktionen definiert und deren Implementierungsdetails gekapselt. Eine Voraussetzung, wenn man Module wie "Map Matching", "Geo-Visualisierung" oder "Computer-Telefonie" schnell durch andere Produkte ersetzen will. Die objektorientierte Programmierung erfolgte in Java, wobei die Unified Modelling Language (UML) als Modellierungssprache für Analyse und Design verwendet wurde. Als Modellierungswerkzeug kam "Rational Rose" zum Einsatz, die Entwicklungsumgebung stellte Symantecs "Visual Cafe".
Ein Vorteil der Objektorientierung bestand auch darin, dass man in einzelnen Teilprojekten parallel arbeiten konnte, so dass Plato bereits nach einem Jahr im Februar 2000 erstmals von einem Automobilhersteller für den Serieneinsatz zertifiziert wurde. Das System besteht im Wesentlichen aus den drei Komponenten "Communication-Controller", "Session-Controller" (entwickelt nach dem Model-View-Controller-Konzept) sowie einem Frontend.
Das Kommunikationsmodul unterstützt derzeit vier Telematikprotokolle und erfüllt mit seinem generischen Application Programming Interface (API) das eigentliche Ziel des ADAC: Der Zeitaufwand für die Protokollimplementierung ist im Vergleich zu früher um 30 Prozent gesunken. Über das API können Protokolle ohne Einblick beziehungsweise Kenntnisse des Servers diesem "beigestellt" werden. Die Datenkommunikation mit dem Fahrzeug-Endgerät erfolgt derzeit noch über den SMS-Kanal. Die Einbettung der protokollkonformen Informationen auf Byte-Level in das SMS-Format (ISO-OSI-Layer 4 nach Layer 3) übernimmt ein separates Modul. Bei Bedarf können weitere Module zum Beispiel für GPRS oder UMTS eingesetzt werden.
Die zweite Schicht über dem Communication-Controller bildet der Session-Controller. Er überwacht den Zustand der Fahrzeug-Endgeräte und wächst deshalb in seiner Komplexität mit der des jeweils eingesetzten Dienstes. Die Anbindung der Frontends erfolgte nach dem Model-View-Controller-Konzept, das die Trennung von Datenhaltung und Visualisierung gewährleisten sollte. So war es möglich, die Oberflächen unabhängig vom Server zu entwerfen und sie für neue Clients wie Web-Browser, Handheld-Devices beziehungsweise Personal Digital Assistants (PDAs) vorzubereiten.
Die Anwendung ist so gekapselt, dass verschiedene Interface-Techniken zur Ankopplung der Frontends möglich sind. Derzeit unterstützt Plato Remote Method Invocation (RMI), eine Corba-Schnittstelle sowie die Anbindung über ein proprietäres Socket-Protokoll. Dies war notwendig, da zahlreiche Partnerclubs mit Frontends arbeiten, die in C++ geschrieben sind, und diese auch behalten wollen.
Darüber hinaus hatte das in Spitzenzeiten aus 14 Mitarbeitern bestehende Projektteam um Schneeweiss einige Anforderungen hinsichtlich der Back-Office-Funktionen zu erfüllen. Hierunter fiel ein universelles Kundendatenmodell, das ein Erfassen und Speichern von Daten über die Clubgrenzen hinweg erlauben sollte. Auch der Ablauf eines Servicekontakts sollte sich etwa als Gesprächsaufzeichnung protokollieren und zur Historienverfolgung in einer Datenbank ablegen lassen. Eine weitere Aufgabe des Back-Office ist das Erstellen von Statistiken und Kundenrechnungen, wobei eine gewisse Flexibilität erwartet wurde, damit sich die Belange anderer Betreiber berücksichtigen ließen.
Zur Darstellung der aus den Fahrzeug-Endgeräten versendeten Informationen wurde ein generisches Anzeigemodul auf Basis von Javabeans entwickelt. Das gleiche Modul verwendet Plato auch für den umgekehrten Weg der Nachrichten vom Operator zum Fahrzeug. Um die Eingabe größerer Informationsmengen zu erleichtern, werden die Informations-Container vom Server vorgeblendet, das heißt, die Dateninhalte sind dort im XML-Dialekt von IBMs "Beans Markup Language" (BML) hinterlegt. Auf diese Weise können die Informations-Container zur Laufzeit unter Verwendung von XML-Technik eingelesen werden.
Schließlich musste noch ein API entwickelt werden, um die auf Compaq-NT-Rechnern laufenden Plato-Java-Server in die beim ADAC vorherrschende Microsoft-Welt integrieren zu können. Dieses Interface stellt sicher, dass die Server-Komponenten mit Hilfe von Microsofts "SDK 3.2 für Java" als voll funktionsfähige NT-Services gewrappt werden können.
Für das Plato-Projekt hat der ADAC eigens eine räumliche Nähe zwischen Entwicklung und Fachbereich geschaffen. Auf diese Weise war der Fachbereich schon während der Analyse- und Designphase eng in das Projekt involviert. So konnten die Operatoren bereits sehr früh ihre Erfahrungen in das Prototyping der Oberflächen einbringen.
Außerdem wurde das Projektteam von Anfang an um eine Qualitäts-Management-Gruppe ergänzt, die in Anlehnung an das V-Modell über alle Phasen hinweg entsprechende Testdokumente, -skripte und -verfahren erarbeitet hat. Zudem wurden spezielle Test-Tools insbesondere zur Simulation der Hardware in den Fahrzeug-Endgeräten entwickelt. Dieses Vorgehen erwies sich als äußerst nützlich, denn der Projektverlauf zeigte, dass die Endgeräte meist später als geplant verfügbar waren und ein Warten darauf die Entwicklung verzögert hätte.
Stolz verweist Schneeweiss darauf, dass das Projekt mit einem Aufwand von 1,8 Millionen Mark und einer Laufzeit von 14 Monaten den vorgegeben Rahmen nicht überschritten hat. In diesem Zusammenhang gibt er die hohe Komplexität von Telematikprojekten zu bedenken, die wie hier eine enge Zusammenarbeit des ADAC mit seinen europäischen Partnerclubs, den Endgeräte- und Fahrzeugherstellern sowie den Netzwerkbetreibern voraussetzen. Die Koordination erfolgte in monatlich ganztägigen Abstimmungsrunden. Entscheidend für den Projekterfolg war auch die klare Zuordnung von Ansprechpersonen bei dem jeweiligen Partner.
Als Fazit der Plato-Entwicklung führt Schneeweiss nicht nur die geringeren Kosten für Protokollimplementierungen, die Plattformunabhängigkeit und den Aspekt der vergleichsweise einfachen Diensteerweiterung an. Im Telematik-Business seien darüber hinaus die geringen Betriebskosten für ein Call-Center ausschlaggebend. Die Flexibilität von Plato erlaube es, Einrichtungen geografisch auf Orte mit günstigen Mieten und Löhnen zu verteilen.
Stefan Ueberhorst
ADAC
Als Verein ist der ADAC mit Hauptsitz in München eine Non-Profit-Organisation. Er beschäftigt derzeit etwa 6300 Mitarbeiter, 230 davon im IT-Bereich. Als eine seiner Kernleistungen nennt der Automobilclub neben der Pannenhilfe auch Telematikdienste.