Tegaron.de Dynamische Navigation

Tegaron Telematics GmbH

by admin file under Infos

Das Bonner Telematikunternehmen Tegaron schaffte 1997 ein neues Konzept, das Vorteile bei der dynamischen Navigation bot und einem wesentlich großen Kreis von Autofahrern zugänglich gemacht wurde. Der Kern des Konzeptes war die Verlagerung der Berechnung dynamischer Routen aus dem Autonavigationsgerät (onboard) in die Tegaronzentrale (offboard). Der Autofahrer hatte dadurch Zugriff auf beste Verkehrsdaten in Deutschland und wurde ohne spezielles und installiertes Navigationsgerät navigiert. In der Offboard-Navigation wurde das Ziel eingegeben, der Standort des Autos über GPS ermittelt und beide Daten in die Zentrale geschickt. Die aktuellen Verkehrsdaten und neueste elektronische Karten lagen stets von Tegaron vor. Die Route mit Standort, Ziel, digitaler Karte und Verkehrsdaten wurden errechnet und umgehend in das Endgerät vom Fahrzeug übermittelt. Die Routenführung erfolgte optisch und als Sprachausgabe.

TelematikUnterschiedliche Endgeräte konnten Autofahrer von Tegaron Scout nutzen. Zur Verfügung stand damals der Pocket PC (PDA, Personal Data Assistant) Ipaq H3630 von Compaq. Weitere Geräte sind hinzukommen, in denen die Fähigkeiten in Form eines Organizers auf einem Smartphone ermöglicht wurden. Autofahrer erlangten mit der Offboard-Navigation die gleichen Leistungen, wie sonst nur mit einem hochpreisigen dynamischen Navigationsgerät. Kosten für das jährlich notwendige Aktualisieren der digitalen Straßenkarte fielen nicht an. Tegaron Scout ermöglichte damit den Autofahrern, mehr Vorteile der dynamischen Navigation zu nutzen als vorher. 2003 war es dann so weit, T-Mobile International übernahm die Tegaron Telematics GmbH komplett. Von der Konzertmutter Deutsche Telekom und DaimlerChrysler Services vorheriges gleichberechtigtes Joint Venture betriebene Telematik Dienstleister änderte den Namen in T-Traffic und integrierte sich in den von Nikesh Aora geleiteten Vorstandsbereich Marketing von T-Mobile. Von Tegaron/T-Traffic wurden Verkehrsinformationen, Reiseinformationen, Routenplanung, dynamische Navigation oder automatische Notrufdienste angeboten. Dieser Bereich wurde von Karsten Heppner geleitet, der im Jahr zuvor die Geschäftsführer von Tegaron Hans-Jürgen Hilgendorf und Peter Mertens ablöste.

Sicherheit durch Tegaron

by admin file under Infos

Neben dem „Time to market“ wurde die hohe Verfügbarkeit eine der wichtigsten Anforderungen. Eine Ausfallsicherheit von fast 100 Prozent für sieben Tage die Woche und rund um die Uhr war die Forderung. Von den Hamburgern wurde ein System für einen objektorientierten Entwurf zugrunde gelegt. Es fiel die Entscheidung, dass im Hinblick auf die Verarbeitung der Transaktionen eine konventionelle, funktionsorientierte Software zu verwenden. Allerdings war nur ein leistungsfähiger Transaktionsmonitor fähig, die Anforderungen des Auftraggebers für eine Skalierbarkeit zu erfüllen. Von den Entwicklern wurde diskutiert, ob es für die Vermittlung von Nachrichten zwischen einzelnen Objekten eine Middleware auf Grundlage der Common Object Request Broker Architecture (Corba) zum Einsatz kommen sollte. Hack hielt es für unvermeidbar, dafür zusätzlich oberhalb dieser Corba-Implementierung einen Transaktionsmechanismus aufzubauen. Der Datenrevision Geschäftsführer war allerdings der Ansicht, es fehle den verfügbaren CORBA Implementierungen die Produktreife. Von den Entwicklern wurde daher die Nutzung eines Werkzeuges als Softwarebus beschlossen, um dies speziell für das Online Transaction Processing auszulegen: einen OLTP-Monitor. Die Hamburger schrieben eigene C++-basierte Interfaceklassen, um die Verbindung zwischen dem funktionsorientierten Tool und Softwareobjekten des Gesamtsystems herzustellen. Die Architektur des Systems bestand im Wesentlichen von einem Server für Daten, Kommunikation und Applikation, die zusammen untereinander via Messaging kommunizierten. Angebunden für den Short Message Service (SMS) waren zum Beispiel Schnittstellen, damit Nachrichten vom Endgerät des Nutzers in das System eingespeist werden konnten. Ebenso um Datenbanken für Verwaltung und Überprüfung der Kunden auszulagern. Arbeitsplätze der Verkehrsinformation konnten ebenfalls über Messaging auf den Kommunikationsserver zugreifen. Für Verkehrsdurchsagen diente ein Voice-Server für die Assemblierung und wurde über "Oracle Stored Procedures" angebunden. Auf das Produkt "Tuxedo" von der kalifornischen BEA Systems Inc. fiel die Wahl auf den geeigneten OLTP-Monitors. Die Nordlichter verzeichneten damit in der Vergangenheit gute Erfahrungen. Tuxedo enthielt einige Funktionen, die eine parallele Verarbeitung von Prozessen erleichtern sollte. Eine Anwendung wie Tegaron Info lief nur dann ausreichend schnell, wenn die Vorgänge der einzelnen Programmschritte unabhängig voneinander arbeiteten und für den nächsten Aufruf zur Verfügung standen, sobald der vorherige erledigt war. Vom Kunden musste daher verhindert werden, vom Anruf bis zum Erhalten der Antworten die Prozesskette zu blockieren. Zusätzliche Geschwindigkeiten wurden von den Entwicklern dadurch herausgeholt, indem häufig benötigte oder arbeitsintensive Services des Öfteren parallel ausgeführt wurden und bedarfsmäßig auf verschiedene Rechner verteilten. Bei der aufwendigen dynamischen Routenplanung hat sich das ausgezahlt.

Erweiterungen mit überschaubarem Aufwand

VerkehrssicherheitEs hatten sich durch die hochgradig parallelisierten Verarbeitungen einige Fehlfunktionen eingeschlichen. Es konnte vorkommen, dass ein Dienst eine Anfrage mit unterschiedlichen Nachrichten an das Endgerät beantwortet hat. Es gab die Gefahr der Nachrichtenüberholung und diese trafen in der falschen Reihenfolge beim Endgerät ein. Ein zusätzlicher Aufwand sollte das Problem lösen. Das Einbinden externer Komponenten, wie der Voice-Server und das geografische Informationssystem (GIS) in das transaktionsorientierte Konzept der Datenrevision, gestaltete sich als schwierig. Die Hamburger entwickelten eine Bibliothek für Schnittstellen und die Hersteller wurden um Anpassung ihrer Produkte an dieses Interfaces gebeten. Mit dem OLTP-Monitor musste sich nicht jeder Entwickler auskennen, da Tuxedo bereits das Gerüst für die gesamte Applikation bildete. Die spezifischen Zugriffe von Tuxedo wurden in wenigen Dienstleistungsklassen gekapselt und konnten auf einfache Art genutzt werden. Der objektorientierte Charakter der Applikation hatte dazu beigetragen, dass für technische Weiterentwicklungen das Entwicklungsteam gelassen blieb. Die Änderung der Funktionsaufrufe betraf nur einen Bruchteil der Klassen.

Was war der nächste Schritt?

Tegaron besaß reichliche Ideen für Dienstleistungsangebote im D1-Umfeld. Dazu gehörte ein Notfallsystem und dies wurde bei der internationalen Autoausstellung (IAA) damals zum ersten Mal vorgestellt. An die Technologieintegration wurden hohe Anforderungen gestellt. Bei einem Unfall sollte eine spezielle GSM-Karte automatisch die Notrufzentrale benachrichtigen und mithilfe eines Global-Positioning-Systems (GPS) den ermittelten Standort mitteilen. Ein Callcenter musste nun versuchen, eine Verbindung zum Fahrer herzustellen, damit vom Operator die Situation überprüft werden konnte. Zudem waren Konferenzschaltungen zwischen Polizei und Rettungsdiensten möglich, damit eine, bis zu 50 Prozent, schnellere Hilfe gewährleistet war.

Aktuelle Verkehrsinfos mit Tegaron

by admin file under Infos

Für den Feierabendverkehr konnte der Besitzer eines D1-Handys über die Telefontastatur die Fahrtrichtung eingeben und erhielt für sein Fahrtziel eine Stunde regelmäßige und exakte Stauwarnungen aus dem Sprachcomputer. Tegaron Telematics GmbH war der Anbieter dieser Dienstleistung, ein vorheriges gegründetes Joint-venture von T-Mobil und Debis. Im System waren alle Standortinformationen über die zugehörige Funkzelle des GSM-Netzes enthalten und der Kunde musste seinen Standort nicht genau angeben. Die Funkzellen besaßen zwar eine unterschiedliche Dichte, jedoch genügten die Angaben für eine Genauigkeit vollkommen aus. Wurde von der eingegebenen Richtung ausgegangen, legte das System ein Gebiet fest und gab für diese alle verfügbaren Verkehrsinformationen weiter. Diese Informationen stammten von der Deutschen Datengesellschaft (DDG), Joint-venture von Tegaron und Mannesmann Autocom und den Landesmeldestellen. Diese versorgten ebenfalls den Rundfunk und den ADAC mit Verkehrsmeldungen. Für eine dichte Verknüpfung im Verkehrsdatennetz wurden vom Bund in Symbiose mit der Industrie spezielle Sensoren auf den Autobahnbrücken installiert, damit der Verkehrsfluss besser beobachtet werden konnte. Ein weiteres Ziel war die Ermittlung von "Floating Car Data", indem ein automatisches Feedback vonseiten der Serviceteilnehmer gesendet werden sollte. Dafür hätte der Standort der Autofahrer, die an das System angeschlossenen waren, in bestimmten Intervallen mit dem Durchschnittswert der gefahrenen Strecke ermittelt und verglichen werden müssen. Auf diese Art sollte durch hinreichende Zahlen an Teilnehmer eine Landkarte zur Verkehrsdichte für die gesamte Bundesrepublik entstehen.

”Time to market” entscheidendes Element

VerkehrFür die Softwareentwickler stellte die fast unbeschränkte Teilnehmerzahl die größte Herausforderung dar. Der Geschäftsführer des Hamburger Lösungsanbieters Datenrevision Dieter Hack übertrug Tegaron die Verantwortung für das Projekt. Es war vorgesehen, dass kurz nach der Gründung der T-Mobil- und Debis-Tochter erste Tegaron-Dienste den Betrieb aufnehmen, denn für das damals junge Marktsegment war Schnelligkeit ein wichtiger Aspekt. Parallel zum Entwurf des Fachkonzeptes sollten bereits generelle Designentscheidungen getroffen und Architekturkonzepte erarbeitet werden. Die Vorstellungen der Details zur Leistung von Architektur und Technik hatten sich im Laufe des Vorhabens ergeben.