Die Transport Protocol Experts Group, kurz TPEG, ist eine 1997 gegründete Expertengruppe, deren Arbeit es zum Ziel hatte, Lösungen für bessere und detailliertere Verkehrs- und Reiseinformationen bereitzustellen, als die bis dahin verfügbaren Systeme. Mit der Zeit wurde „TPEG“ zum Synonym für das Datenprotokoll, welches diese Expertengruppe erarbeitete.

Hinweis: Im Folgenden wird der Begriff „TPEG“ stets für das Datenprotokoll verwendet.

TPEG ist eine Serie von Datenprotokollen für die Übertragung von Verkehrs- und Reiseinformationen. Sie besteht aus verschiedenen Diensten (auch Anwendungen genannt) sowie grundlegenden Strukturen für die Verwaltung der eigentlichen Datenübertragung. Letzteres umfasst beispielsweise die Gruppierung von Nachrichten zu Diensten, Aktualisierung und Löschung von Nachrichten, Fehlerkorrekturmechanismen oder Verschlüsselung von kommerziellen Diensten. TPEG kann über verschiedene Datenkanäle (Trägermedien) übertragen werden, z. B. Digitalradio, Mobilfunk oder auch WiFi. TPEG Dienste beinhalten beispielsweise Ereignismeldungen (Unfälle, Baustellen, Staus), Verkehrsflussinformationen (durchschnittliche Reisezeiten auf Straßensegmenten), Wetterinformationen, Kraftstoffpreise, Parkinformationen oder Informationen zum öffentlichen Nahverkehr.

Geschichte Die Transport Protocol Experts Group startete 1997 innerhalb der Europäischen Rundfunkunion (European Broadcast Union, EBU). Die Arbeit wurde unter Federführung der EBU bis 2007 fortgeführt. Nach dem Zusammenschluss mit der von ERTICO ITS Europe geleiteten Gruppe zur Entwicklung des Traffic Message Channel (TMC) Protokolls sowie des Mobile.Info Projektes in Deutschland, wo erstmals TPEG unter realen Einsatzbedingungen in Fahrzeugen getestet wurde, entstand Ende 2007 die Traveller Information Services Association (TISA) mit Sitz in Brüssel.

Zu Beginn der Arbeiten an TPEGEBU Technology&Innovation – TPEG (englisch, abgerufen am 18. August 2014). stand die Vision, Dienste zu entwickeln, die weit über die bis dahin verfügbaren Technologien, wie beispielsweise RDS-TMC oder proprietäre Lösungen, hinausgehen. Neben Informationen für den Individualverkehr (d. h. Autofahrer) sollte TPEG auch Dienste für den öffentlichen Nah- und Fernverkehr (z. B. Abfahrtzeiten und Verspätungen für Busse, U- und S-Bahnen, Fernzüge, Abflugzeiten an Flughäfen) beinhalten. Am Anfang stand also der Dienst Road Traffic Messages (RTM) für Individual- bzw. Straßenverkehr. Schon bald folgte der Dienst Public Transport Information (PTI). Sowohl RTM als auch PTI nutzten gemeinsam ein einheitliches Verfahren zur Ortsreferenzierung, das TPEG Location Referencing.

TPEG RTM wurde als eine monolithische Lösung („one size fits all“) entworfen. Mit den ersten Implementierungen stellte man allerdings fest, dass dieser Ansatz zu komplex war, um RTM als Nachfolger des bis dahin sehr erfolgreichen RDS-TMC in Navigationssysteme zu integrieren. Diese 1. Generation von TPEG Diensten, auch TPEG1 genannt, war außerdem nur in einer binären Version verfügbar. Eine XML Variante war nur als separate Spezifikation verfügbar. Konsequenterweise wurde sowohl das Datenmodell als auch der Modellierungsprozess überarbeitet und es entstand TPEG2. Hier gehen sowohl die binäre als auch die XML Umsetzung von einem einheitlichen UML Modell aus, von welchem die binäre und die XML Variante mit entsprechenden Codegeneratoren automatisch erzeugt werden können. Eine TPEG2 Spezifikation enthält also stets die binäre und die XML Repräsentation des betreffenden Dienstes.

Mit dem ersten TPEG2 Dienst Traffic Event Compact (TEC) wurde dann auch gleich ein Durchbruch erreicht, weil sowohl Dienstanbieter als auch Endgerätehersteller und die Automobilindustrie TEC als den Nachfolger des bis dahin sehr erfolgreichen RDS-TMC akzeptierten.

Sowohl TPEG1 als auch TPEG2 werden über die internationale Standardisierungsorganisation ISO publiziert als ISO/TS 18234 (TPEG1) bzw. ISO/TS 21219 (TPEG2). TPEG1 wird nun allgemein als veraltet betrachtet und von einer Verwendung für neue Dienste und Endgeräte abgeraten.

Technologie TPEG spezifiziert Dienste für detaillierte und präzise referenzierte Verkehrs- und Reiseinformationen. TPEG kann über verschiedene Trägermedien verbreitet werden, z. B. über Digitalradio oder Mobilfunk. Letzteres ist inzwischen das am weitesten verbreitete Trägermedium.

TPEG ist ein Datenprotokoll, welches Informationen über spezifische Themen zu Diensten (Anwendungen) gruppiert und in Nachrichtencontainern transportiert. Über dieses Containerkonzept und die strukturierte Codierung von Nachrichten können jederzeit weitere Anwendungen entwickelt und zu bestehenden Diensten hinzugefügt bzw. bestehende Anwendungen durch neue Meldungen erweitert werden. Eine Rückwärtskompatibilität ist durch die Designprinzipien dabei jederzeit gewährleistet.

Designprinzipien Die Entwicklung von TPEG-Anwendungen folgt einem top-down Ansatz, bei dem Anwendungsszenarien (Use Cases) in der Unified Modeling Language (UML) modelliert werden. Ausgehend von dieser UML Modellierung können zwei TPEG Versionen abgeleitet werden: eine Codierung in der Extensible Markup Language (XML) – Diese Version ist sowohl maschinenlesbar als auch manuell lesbar/interpretierbar. Die Rückwärtskompatibilität wird dadurch gewährleistet, dass neue XML-Elemente (Tags) von älteren Geräten übersprungen werden, weil diese die neuen Tags nicht erkennen und interpretieren können. eine binäre Codierung - Diese Version ist nicht manuell lesbar/interpretierbar. Der Vorteil besteht jedoch darin, dass diese deutlich kompakter ist. Die Binär-Codierung wird deshalb vorwiegend dann verwendet, wenn Bandbreiteneffizienz höchste Priorität hat.

Grundprinzipien Die folgenden Prinzipien sind die Grundsteine bei der Entwicklung von Syntax und Semantik von TPEG (siehe auch ISO/TS 18234-2 bzw. ISO/TS 21219-5): Unidirektionalität – TPEG benötigt keinen Rückkanal (ein Rückkanal muss nicht, kann aber in TPEG implementiert werden, insbesondere für Dienste über Mobilfunk bzw. IP Netze) Byte-Orientierung asynchrone Rahmenstruktur hierarchische Fehlerdetektion durch Cyclic Redundancy Checks (CRC) auf verschiedenen Protokollebenen TPEG setzt geeignete Mechanismen zur Fehlerkorrektur im Übertragungsmedium voraus TPEG setzt einen transparenten Datenkanal voraus Hierarchische Rahmenstruktur für die Codierung von Nachrichten und Diensten TPEG bietet Mechanismen zur Übertragung von Informationen zu Dienstanbieter, Dienst und Netzwerk Verschlüsselung für kommerzielle Dienste

Weitere Funktionalitäten Separierung von Inhalt und Übertragung im Protokolldesign innerhalb der Inhaltscodierung Trennung von Nachrichteninhalt und Ortsreferenzierung Ortsreferenzierung sowohl über dynamische Referenzierungsmethoden (on-the-fly Location Referencing) oder über fixe Referenzpunkte auf Karten (Location Tables) für dynamische (on-the-fly) Ortsreferenzierung stehen mehrere Verfahren zur Verfügung Sprachunabhängigkeit optionale Codierung der Nachrichten mit umfangreichen Attributen und Zusatzinformationen Möglichkeit der Filterung von Diensten und Nachrichten nach verschiedenen Kriterien Erweiterbarkeit um neue Dienste und Meldungstypen Unabhängigkeit von Datenbanken mit Ortsreferenzen (wie z. B. bei RDS-TMC notwendig) Decodierung von TPEG Diensten ist sowohl für leistungsfähige Endgeräte (z. B. Navigationsgeräte mit Karten und Grafikdarstellung) als auch für einfachste Geräte (z. B. ohne Karte und nur mit Textanzeige) möglich Anpassung an neue Übertragungsmedien leicht möglich durch Definition von Adaptation Layern

Spezifische Eigenschaften und Funktionen von TPEG

Sprachunabhängigkeit Ein Verkehrsinformationssystem sollte in der Lage sein, die benötigte Information in der jeweiligen Sprache des Nutzers zu präsentieren.

TPEG ermöglicht diese Mehrsprachigkeit durch Verwendung von erweiterbaren Übersetzungstabellen. Hierzu werden Wörter ähnlicher Bedeutung, die in TPEG-Nachrichten öfter benötigt werden, in Tabellen zusammengefasst. Diese Wörter können in einer TPEG-Nachricht über eine Nummer referenziert werden. In einer TPEG-Meldung werden dann an Stelle von Klartext diese Referenzen übertragen. Erst auf der Clientseite wird anhand der Tabellen, die auf dem Client in der gewünschten Sprache vorliegen müssen, eine Ausgabe generiert. Dies kann eine Textmeldung in der Sprache des Nutzers, ein Symbol oder auch Sprachausgabe sein.

Z. B. werden in der TPEG-RTM Tabelle (rtm01) vehicle_type verschiedene Fahrzeuge aufgeführt, wie Car, Taxi, Bus oder Tram. Um die Erweiterbarkeit der Tabellen sicherzustellen, enthält jede Tabelle außerdem einen Standardwert. So müssen nicht alle Clients bei Erweiterung der Tabellen auf den neuesten Stand gebracht werden. Erhält ein Client, der nicht auf dem aktuellen Stand ist, eine Referenz auf einen Eintrag, der in seiner Version noch nicht enthalten ist, so wird der Standardeintrag ausgegeben. Der Nutzer ist so meist trotzdem in der Lage, eine Nachricht zu verstehen, auch wenn evtl. Details verloren gehen [TPEG].

Wird beispielsweise ein falschfahrendes Motorrad gemeldet, überträgt TPEG-RTM Referenzen auf die Einträge 19 und 7 in den Tabellen vehicle_type und vehicle_problem_type.

Würde die oben genannte Meldung an einen Client übertragen, dessen vehicle_type Tabelle den Eintrag 19 noch nicht enthält, so würde der Defaulteintrag (vehicle) verwendet. Dem Nutzer eines Navigationssystems wird also statt der Meldung „Auf der A9 in Richtung München kommt Ihnen ein Motorrad entgegen!“ eine Meldung der Art „Auf der A9 in Richtung München kommt Ihnen ein Fahrzeug entgegen!“ angezeigt.

Zur Spezifikation der Tabellen wird so genanntes CEN-English verwendet. Hierbei handelt es sich um technische Begriffe, die häufig nichts mit der englischen Umgangssprache zu tun haben und eine Definition für die einzelnen Einträge darstellen. CEN-English wird verwendet, um Verwechslungen oder Ungenauigkeiten zu vermeiden. Wegen des Unterschieds zum herkömmlichen Sprachgebrauch sollte CEN-English auch in englischsprachigen Ländern nicht direkt ausgegeben werden, sondern in die allgemein üblichen Begriffe übertragen werden. [TPEG] Ihre Grenzen findet die Sprachunabhängigkeit allerdings bei den Ortsbezeichnungen, da nicht alle denkbaren Namen in den Tabellen hinterlegt werden können. Derartige Informationen werden in Form von Strings übertragen, wobei auch hier mehrere Sprachversionen möglich sind.

Unabhängigkeit vom Kartenmaterial (TPEG-Loc) Das Ortsreferenzierungssystem von TPEG trägt den Namen TPEG-Loc. Es wurde so konzipiert, dass es sowohl auf Clients, die über eine Ortsdatenbank verfügen, als auch auf Clients, die nicht mit Ortsdaten ausgestattet sind, möglichst präzise Ortsreferenzen erzeugt. Außerdem wurde Wert darauf gelegt, die Ortsreferenzen sowohl für Mensch als auch Maschine verständlich zu machen. Eine Ortsdatenbank oder eine Karte, mit deren Hilfe Längen- und Breitengrade in konkrete Ortsangaben umgewandelt werden können, ist für das Verstehen der TPEG-Loc-Daten nicht zwingend erforderlich.

Um die oben genannten Ziele zu erreichen, werden neben den Ortskoordinaten im Koordinatensystem WGS84 (World Geodetic System 1984) weitere Informationen übertragen, die einen Bezug zur Umgebung herstellen sollen. Die Übertragung mit Hilfe von WGS84-Koordinaten ist deshalb sinnvoll, da dieses Referenzierungssystem unter anderem von GPS verwendet wird und einen weltweiten De-facto-Standard darstellt.

Zur Beschreibung eines Punktes, der zwischen zwei Autobahnausfahrten A und B liegt, werden beispielsweise neben den Koordinaten des Punktes auch die Namen der Ausfahrten verwendet. Die Vorteile dieser Angaben liegen auf der Hand: Ein Navigationssystem erhält die genaue Information, wo sich dieser Punkt befindet. PDAs ohne Kartenmaterial hingegen können ihren Nutzern zumindest ungefähr beschreiben, dass sich der genannte Punkt zwischen den beiden Ausfahrten A und B befindet.

Unabhängigkeit vom Übertragungskanal