Transport Protocol Experts Group

aus Wikipedia, der freien Enzyklopädie

Du hast neue Nachrichten (Unterschied zur vorletzten Version).

Die Transport Protocol Experts Group ist eine 1997 gegründete Expertengruppe innerhalb der Europäischen Rundfunkunion (UER/EBU). Sie entwickelte mit Fördermitteln der Europäischen Kommission den gleichnamigen offenen internationalen Standard zum Aussenden von sprachunabhängigen und multimodalen Verkehrs- und Reiseinformationen. Auf den Erfahrungen von RDS-TMC aufbauend können TPEG-Informationen einerseits von Maschinen verarbeitet werden und andererseits so aufbereitet werden, dass sie von Personen einfach verstanden werden.

Inhaltsverzeichnis

1 Designkriterien
2 Datenformat
- 2.1 Aufbau einer RTM Nachricht (vgl. [TPEG4])
- 2.2 Das Binärformat (nach [TPEG2])
3 Literatur
4 Weblinks

[Bearbeiten] Designkriterien

[Bearbeiten] Verwendbarkeit im öffentlichen Personen- sowie im Straßenverkehr

TPEG wurde so konzipiert, dass es sowohl im öffentlichen Personenverkehr als auch im Straßenverkehr verwendet werden kann. Aus diesem Grund wurde zunächst eine Grundstruktur entworfen, auf die dann zwei Profile für den Straßen- sowie für den öffentlichen Verkehr aufsetzen:

TPEG-RTM: Road Traffic Message Application
TPEG-PTI: Public Transport Information

Die Unterscheidung zwischen Straßenverkehr und öffentlichen Verkehrsmitteln rührt in erster Linie daher, dass es sich beim öffentlichen Verkehr um ein Liniennetz handelt, bei dem die einzelnen Routen jeweils einen bestimmten Start- und Endpunkt haben und der Verlauf einer Route während einer Fahrt in der Regel nicht geändert wird. [TPEG5]

Beim Straßenverkehr andererseits kann der Fahrer die Route jederzeit ändern und so direkt auf die aktuelle Situation reagieren. Die zu übertragenden Informationen unterscheiden sich demnach je nach System. Den Nutzern von öffentlichen Verkehrsmitteln müssen Informationen wie Verspätungen, Streichung von Verbindungen oder Sonderfahrten bereitgestellt werden.

Die von Auto- und LKW-Fahrern benötigten Informationen haben hingegen Auswirkungen auf die gewählte Route des Fahrers und auch auf die Sicherheit. Verkehrsteilnehmer im Straßennetz erhalten über TPEG-RTM Nachrichten über Unfälle, Staus, Baustellen oder Wetterbedingungen wie Glatteis oder Nebel. [TPEG4], [TPEG5] Die Zweiteilung des TPEG-Systems erlaubt es den Implementierungsaufwand für die Hersteller von Sendern als auch von Empfängern zu mindern, falls diese auf ihren Geräten nur eines der beiden Profile implementieren. Gleichzeitig führt dies zu kleineren Datenstrukturen.

Andererseits ist der grundlegende Aufbau beider Systeme gleich. So verwenden beide das gleiche Ortsreferenzierungssystem, erreichen die Sprachunabhängigkeit mit Hilfe von Übersetzungstabellen und verwenden das gleiche Übertragungssystem. Aus diesem Grund wird in diesem Artikel exemplarisch nur TPEG-RTM näher beschrieben.

[Bearbeiten] 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 an Hand 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 sicher zu stellen, 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 geisterfahrendes 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.

[Bearbeiten] 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-Koordinanten ist deshalb sinnvoll, da dieses Referenzierungssystem unter anderem von GPS verwendet wird und einen weltweiten Defacto-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.

[Bearbeiten] Unabhängigkeit vom Übertragungskanal

Da TPEG auf verschiedenen Übertragungskanälen wie beim Digital Audio Broadcasting (DAB), Digital Video Broadcasting (DVB) oder im Internet zum Einsatz kommen soll, darf die Art der Übertragung keine Rolle spielen. In der ursprünglichen TPEG-Spezifikation wurde deshalb ein Binärformat entwickelt, welches keine bestimmte Übertragungsform wie paket- oder verbindungsorientiert voraussetzt und auch keinen Rückkanal benötigt. [TPEG2] Um dies zu erreichen übernimmt das binäre TPEG-Protokoll im ISO/OSI-Schichtenmodell die Schichten 3 bis 7 selbst. TPEG ist also nur noch von den Schichten 1 und 2 abhängig. Das Übertragungsmedium selbst hat demnach nur noch die Aufgabe die einzelnen Bytes zu übertragen. Die höheren Funktionen wie das Segmentieren oder das Erkennen von Fehlern bei der Übertragung werden von TPEG selbst erledigt. [TPEG6] Die Segmentierung ist notwendig, da jede Meldung als einzelne Nachricht übertragen wird. Außerdem können so mehrere TPEG-Dienste ihre Nachrichten auf dem gleichen Kanal übertragen.

Allerdings ist hier zu beachten, dass TPEG-Clients auf Grund der Spezifikation keine Möglichkeit haben, fehlerhaft übertragene Informationen erneut anzufordern. Diese Einschränkung ist nötig, damit TPEG auch mit Übertragungsmedien ohne Rückkanal (z.B. DAB) zurecht kommt. Der Übertragungskanal sollte deshalb möglichst robust gegenüber Übertragungsfehlern sein, und Fehlerkompensationsfunktionen besitzen. Außerdem sollten die einzelnen Nachrichten nach Möglichkeit wiederholt übertragen werden.

Wegen seiner hohen Entropie eignet sich das Binärformat besonders für die Übertragung zwischen Sendestelle und Client, da dann auch Verbindungen mit niedrigen Datenraten verwendet werden können. Das Binärformat ist auch für Nutzer von Vorteil, die beispielsweise über GPRS (General Packet Radio Service) oder UMTS (Universal Mobile Telecommunications System) an einen TPEG-Provider angebunden sind, da hier häufig das Übertragungsvolumen in Rechnung gestellt wird. Außerdem ist das Format auf ressourcenschwachen Clients leichter zu dekodieren, als das später entwickelte XML-Format tpegML (tpegML steht für TPEG in XML), für dessen Verarbeitung komplexe XML-Parser nötig sind. Andererseits ist die Verwendung eines leicht handhabbaren XML-Formats vor allem auf der Seite des Contentproviders sinnvoll. Mittlerweile sind XML-Parser und Validatoren für jede verbreitete Programmiersprache verfügbar. tpegML macht sich diese Eigenschaften zu Nutze und bildet die TPEG-Datenstrukturen auf dieses leicht handhabbare Format ab. TPEG-Nachrichten können so schon während ihrer Erstellung in einem normierten Format zwischen einzelnen Systemen ausgetauscht werden. Auch kann ein Contentprovider mehrere Datenquellen abfragen und deren Informationen ohne großen Aufwand verarbeiten, wenn sich die Quellen an diese Norm halten. Trotz der Gegensätzlichkeit zwischen einem Binärstream und einer XML-Datei lassen sich die enthaltenen TPEG-Informationen beider Formate 1 zu 1 aufeinander abbilden. Die Unabhängigkeit bei der Datenübertragung im TPEG-Standard ist demnach auf zwei Arten zu interpretieren. Einerseits wurde ein Binärformat entwickelt, welches im ISO / OSI Modell schon auf der dritten Schicht einsetzt und nur die simple Übertragung von Bits voraussetzt. Andererseits gibt es mit tpegML ein XML-basiertes Datenformat, das sich einfach übertragen und vor allem verarbeiten lässt. Auch ist die Konvertierung dieses Formats dank zahlreicher Transformationsmöglichkeiten einfach durchführbar.

[Bearbeiten] Datenformat

Grundsätzlich werden TPEG-Daten paketweise bzw. als einzelne Nachrichten übertragen. Da TPEG bereits auf Schicht 3 des ISO / OSI Models einsetzt, wird auch die Segmentierung von TPEG übernommen. Eine Nachricht besteht mindestens aus dem Message Management Container, welcher Steuerinformationen für eine Applikation (RTM oder PTI) enthält. Sollen neben den Steuerinformationen auch Nutzdaten übertragen werden, müssen der RTM bzw. PTI Event Container und der TPEG Location Container angehängt werden. Um eine andere Nachricht für ungültig zu erklären, wird eine Nachricht verwendet, die lediglich aus einem Message Management Container besteht. [TPEG2] Es ist zu beachten, dass sich der Message Management Container von Applikation zu Applikation unterscheiden kann.

[Bearbeiten] Aufbau einer RTM Nachricht (vgl. [TPEG4])

[Bearbeiten] Message Management Container

Unter dem Begriff „Message Management“ sind alle Informationen zusammengefasst, die zur Steuerung und Verwaltung einer RTM-Nachricht dienen (Felder, die zwingend vorhanden sein müssen, sind gekennzeichnet.):

Message Identifier (obligatorisch): Anders als die Bezeichnung evtl. vermuten lässt, handelt es sich dabei nicht um eine eindeutige Bezeichnung für eine bestimmte Nachricht sondern um eine Bezeichnung für ein Event. D.h. alle Nachrichten, die Informationen zu einem Ereignis (z.B. Stau auf einer bestimmten Straße) enthalten, haben den gleichen Message Identifier.
Version Number (obligatorisch): Fortlaufende Zahl, welche die Reihenfolge der Nachrichten eines bestimmten Events anzeigt. Mit jeder neuen Nachricht zu einem Event wird diese Version Number um eins erhöht. Ein TPEG-Dekoder kann so die Reihenfolge der Nachrichten, die zu einem Event gehören (also den gleichen Message Identifier tragen), auch dann wieder herstellen, wenn die Nachrichten nicht in der richtigen Reihenfolge bei ihm eintreffen. Dies ist in Broadcast-Szenarien von besonderer Bedeutung, weil ein Empfänger zu einem beliebigen Zeitpunkt mit dem Abhören des Informationsstroms beginnen kann und so bereits verpasste Nachrichten einer Nachrichtensequenz erst beim wiederholten Aussenden der Nachrichten erhält.
Message Generation Daten and Time: Zeitstempel der beim Erzeugen der Nachricht angelegt wird.
Start Date and Time: Dieser Zeitstempel gibt an, wann ein Ereignis eingetreten ist oder eintreten wird.
Stop Date and Time: Gibt an, wann ein Event zu Ende ist bzw. war.
Message Expiry Date and Time: Verfallsdatum einer Nachricht. Trifft eine Nachricht bei einem Client ein, deren Verfallsdatum überschritten ist, wird diese Nachricht vom Client ignoriert.
Time Schedule Information: Hiermit kann einem Event eine zeitliche Planung zugewiesen werden. Es können ein oder mehrere Zeitintervalle angegeben werden, in denen das, in der Nachricht definierte Event stattfindet. Auch können wochentägliche Wiederholungen spezifiziert werden. So kann z.B. angegeben werden, dass ein bestimmter Streckenabschnitt an allen Wochentagen zwischen 17:00 und 21:00 Uhr gesperrt ist. Die Time Schedule Information ist nur im Zeitraum zwischen Start Date and Time und Stop Date and Time gültig.
Severity Factor: Gibt die Wichtigkeit einer Nachricht an. Der Benutzer ist so in der Lage, eingehende Nachrichten nach ihrer Wichtigkeit zu sortieren oder unwichtige Nachrichten auszublenden.
Unverified Information: Zeigt an, ob der Inhalt einer Nachricht verifiziert wurde, d.h. aus einer vertrauenswürdigen Quelle stammt oder durch eine vertrauenswürdige Quelle überprüft wurde.

[Bearbeiten] Event Description Container

Dieser Bereich einer Nachricht enthält Informationen über das Event an sich. Die Beschreibung des Events ist hierarchisch gegliedert, so dass der Detaillierungsgrad mit jeder Hierarchiestufe zunimmt. Ein Client, der nur die erste Hierarchiestufe dekodiert erhält also nur Grobinformationen, die mit jeder zusätzlich dekodierten Stufe detailreicher werden. Dies ist sinnvoll, da beispielsweise in einer Nachrichtenübersicht nur Grobeinformationen angezeigt werden sollen. Auch können Clients, die auf Grund begrenzter Ressource nicht in der Lage sind eine komplexe Nachricht zu dekodieren, die niedrigeren Hierarchiestufen einfach ignorieren. Für die erste Ebene sind derzeit folgende Typen definiert, welche wiederum Untertypen zur genaueren Beschreibung enthalten:

Accident: Beschreibung von Unfällen
Obstructions: Behinderungen
Activities: Veranstaltungen wie Umzüge oder Demonstrationen
Road Conditions: Informationen über den Straßenzustand
Network Performance: Informationen zum Verkehrsfluss (z.B. Stau oder zähfliesender Verkehr)
Network Conditions: Vom Normalzustand abweichende Verkehrsregeln, z.B. das temporäre Ändern der Vorfahrtsverhältnisse
Security Alert: Sicherheitshinweise über Situationen, die den Fahrer in Gefahr bringen können (z.B. eine Bombendrohung).
Public Transport Information: Hinweise über Störungen im öffentlichen Verkehrssystem, die Auswirkungen auf den Straßenverkehr haben können.
Visibility: Beschreibung der Sichtverhältnisse (z.B. Nebel)
Weather: Wetterinformationen, die die Fahrt beeinflussen (z.B. Glatteis)
Diversion Advise: Informationen über Alternativrouten, wie Umleitungen.

Ein Event wird durch mindestens einen dieser Typen beschrieben, kann aber auch aus mehren bestehen. Kommt es z.B. zu einem Stau wegen eines Unfalls auf Grund von Straßenschäden und schlechter Sicht, so besteht die Nachricht aus den Typen Accident, Network Performance, Road Conditions und Visibility.

[Bearbeiten] TPEG-Location Container

Dieser Container enthält eine Ortsreferenz wie sie weiter oben bereits beschrieben ist (TPEG-Loc). Jede Nachricht, die mit einem Ort verknüpft ist, hat einen solchen Container.

[Bearbeiten] Das Binärformat (nach [TPEG2])

Dieser Abschnitt beschreibt den Teil des Binärformats, der für dieses Format spezifisch ist, d.h. für den es keine Entsprechung im XML-Format gibt. Grundsätzlich wird zwischen zwei Typen von Nachrichten, welche an Hand des Felds „Frame Type“ unterschieden werden, differenziert:

Stream directory information: Enthält eine Liste aller Serviceprovider, die in diesem Stream aktiv sind.
Conventional service frame data: enthält Nutzdaten

Neben Frame Type enthält eine binäre TPEG Nachricht weitere Felder, die im Folgenden erläutert werden:

Sync Word (2 Bytes): dient dem Decoder zur Erkennung einer neuen Nachricht. Dieses Sync Word hat immer den Wert FF0F hex.
Field Length (2 Bytes): Gesamtlänge des Services Frames in Bytes. Ein Service Frame kann somit nicht größer als 65535 Bytes sein.
Frame Type (1 Byte): sorgt für die weiter oben besprochene Unterscheidung zwischen „Stream directory information“ und „Conventional service frame data“.
Header CRC: Prüfsumme um die Korrektheit der Headerdaten sicherzustellen. Diese Summe wird anhand der Felder Sync Word, Field Length, Frame Type und der ersten 11 Byte des Service Frames berechnet. Nähere Informationen zu dieser Berechnung finden sich in [TPEG2].
Service Frame: enthält die Nutzdaten (evtl. in verschlüsselter Form) sowie die Service Identifier. Über die Service Identifier (SID) kann ein Contentprovider eindeutig identifiziert werden. Das Service Frame wird wiederum in folgende Bestandteile unterteilt:
- SID-A bis C (je 1 Byte): ergeben zusammen eine eindeutige Identifikationsnummer eines Service Providers, vergleichbar mit einer IP-Adresse, z.B. 133.168.123.
- Encryption-Indikator (1 Byte): spezifiziert anhand eines Wertes zwischen 0 und 255 eine Verschlüsselungsmethode. Die Werte 0 bis 127 sind dabei für standardisierte Methoden vorbehalten. 128-255 sind für die freie Verwendung durch einen Service Provider vorgesehen. Die Verschlüsselung kann z.B. genutzt werden, um kostenpflichtige Dienste zu entwickeln. Auch wäre die Verwendung verschlüsselter Nachrichten evtl. bei sicherheitskritischen Anwendungen, wie z.B. Polizei- oder Militärfunk nutzbar.
- Component Multiplex: Dieser evtl. verschlüsselte Datenbereich enthält dann die eigentlichen TPEG-Nachrichten, wie sie zu Beginn von Kapitel 3 beschrieben sind. Solange die Maximalgröße von 65531 Bytes nicht überschritten wird, kann dieser Bereich mehrere Nachrichten aufnehmen. Die Kodierung dieser Daten ist der Spezifikation zu entnehmen.

[Bearbeiten] Literatur

[EBU02] EUROPEAN BROADCASTING UNION, Guidelines for TPEG on the Internet, 2002
[EBU03] EUROPEAN BROADCASTING UNION, TPEG – What is it all about?, 2003
[TPEG] EUROPEAN BROADCASTING UNION, TPEG specifications – Supplement: TPEG Tables: RTM, PTI, Loc - Version 3.0, 2002
[TPEG2] EUROPEAN BROADCASTING UNION, TPEG specifications - Part 2: Syntax, Semantics and Framing Structure, 2002
[TPEG4] EUROPEAN BROADCASTING UNION, TPEG specifications - Part 4: Road Traffic Message Application, 2002
[TPEG5] EUROPEAN BROADCASTING UNION, TPEG specifications - Part 5: Public Transport Information Application, 2002
[TPEG6] EUROPEAN BROADCASTING UNION, TPEG specifications - Part 6: Location Referencing for Applications, 2002
[TPEGML1] EUROPEAN BROADCASTING UNION, tpegML specifications - Part 1: Introduction, common data types and tpegML v1.00, 2004
[TPEGML2] EUROPEAN BROADCASTING UNION, tpegML specifications - Part 2: tpeg-locML v1.00, 2004
[TPEGML3] EUROPEAN BROADCASTING UNION, tpegML specifications - Part 3: tpeg-rtmML v1.00, 2004
[Mar00] MARKS, B., Guidelines for TPEG in DAB, 2000