Grupa Ekspertów Protokołu Transportowego

Transport Protocol Experts Group , lub TPEG za krótki , to grupa ekspertów powstała w 1997 roku, którego celem było dostarczenie rozwiązania dla lepszej i bardziej szczegółowych informacji o ruchu i podróży niż systemy dostępne do tej pory. Z czasem „TPEG” stał się synonimem protokołu danych, który opracowała ta grupa ekspertów.

Uwaga: W dalszej części termin „TPEG” jest zawsze używany w odniesieniu do protokołu danych.

TPEG to seria protokołów danych do przesyłania informacji o ruchu drogowym i podróży. Składa się z różnych usług (zwanych również aplikacjami) i podstawowych struktur do zarządzania rzeczywistą transmisją danych. Ta ostatnia obejmuje na przykład grupowanie wiadomości w usługi, aktualizację i usuwanie wiadomości, mechanizmy korekcji błędów lub szyfrowanie usług komercyjnych. TPEG może być przesyłany różnymi kanałami danych (nośnikami), np. B. radio cyfrowe , komórkowe lub WiFi . Usługi TPEG obejmują na przykład raporty o zdarzeniach (wypadki, place budowy, korki), informacje o natężeniu ruchu (średnie czasy przejazdu na odcinkach dróg), informacje pogodowe, ceny paliw, informacje o parkingach lub informacje o lokalnym transporcie publicznym.

fabuła

Grupa Ekspertów Protokołu Transportowego powstała w 1997 r. W ramach Europejskiej Unii Nadawców (European Broadcast Union, EBU). Prace kontynuowano do 2007 roku pod kierownictwem EBU. Po fuzji z grupą kierowaną przez ERTICO ITS Europe w zakresie rozwoju protokołu Traffic Message Channel ( TMC ) i projektu Mobile.Info w Niemczech, gdzie TPEG był po raz pierwszy testowany w rzeczywistych warunkach pracy w pojazdach, Stowarzyszenie Usług Informacyjnych Podróżnych TISA ) z siedzibą w Brukseli.

Na początku prac nad TPEG wizją było rozwijanie usług daleko wykraczających poza dostępne do tej pory technologie, takie jak RDS - TMC czy autorskie rozwiązania. Oprócz informacji dotyczących transportu indywidualnego (tj. Dla zmotoryzowanych), TPEG powinno również obejmować usługi lokalnego i dalekobieżnego transportu publicznego (np. Godziny odjazdów i opóźnienia autobusów, metra i pociągów podmiejskich, pociągów dalekobieżnych, godziny odjazdów na lotniskach). Wszystko zaczęło się od usługi Road Traffic Messages (RTM) dla ruchu indywidualnego i drogowego. Wkrótce pojawiła się usługa informacji o transporcie publicznym (PTI). Zarówno RTM, jak i PTI wspólnie wykorzystują znormalizowaną metodę odniesienia do lokalizacji, TPEG Location Referencing.

TPEG RTM został zaprojektowany jako rozwiązanie monolityczne („jeden rozmiar dla wszystkich”). Jednak przy pierwszych wdrożeniach stwierdzono, że podejście to było zbyt skomplikowane, aby zintegrować RTM jako następcę wcześniej bardzo udanego RDS-TMC w systemach nawigacji. Ta pierwsza generacja usług TPEG, zwana również TPEG1, była również dostępna tylko w wersji binarnej. Wariant XML był dostępny tylko jako oddzielna specyfikacja. W efekcie poprawiono zarówno model danych, jak i proces modelowania i utworzono TPEG2. Zarówno implementacja binarna, jak i XML są oparte na jednolitym modelu UML, z którego warianty binarne i XML mogą być generowane automatycznie za pomocą odpowiednich generatorów kodu. Specyfikacja TPEG2 zawsze zawiera binarną i XML reprezentację odpowiedniej usługi.

Z pierwszym TPEG2 Traffic Event Compact (TEC) usługi, przełom został osiągnięty, bo usługodawców, producentów urządzeń końcowych i przemysł motoryzacyjny akceptowane TEC jako na następcę dotychczas bardzo udanych RDS-TMC.

Zarówno TPEG1, jak i TPEG2 zostały opublikowane przez międzynarodową organizację normalizacyjną ISO jako ISO / TS 18234 (TPEG1) i ISO / TS 21219 (TPEG2). TPEG1 jest obecnie ogólnie uważany za nieaktualny i nie zaleca się jego używania do nowych usług i urządzeń.

technologia

TPEG określa usługi w zakresie szczegółowych i precyzyjnych informacji o ruchu i podróży. TPEG może być rozpowszechniany za pośrednictwem różnych nośników, np. B. przez radio cyfrowe lub sieć komórkową. Ten ostatni jest obecnie najbardziej rozpowszechnionym medium nośnym.

TPEG to protokół danych, który grupuje informacje na określone tematy w usługi (aplikacje) i transportuje je w kontenerach wiadomości. Korzystając z tej koncepcji kontenera i strukturalnego kodowania komunikatów, w dowolnym momencie można opracować dalsze aplikacje i dodać je do istniejących usług lub rozszerzyć istniejące aplikacje o nowe komunikaty. Zasady projektowania gwarantują zgodność wsteczną przez cały czas.

Zasady projektowania

Rozwój aplikacji TPEG przebiega zgodnie z podejściem odgórnym, w którym scenariusze aplikacji (przypadki użycia) są modelowane w języku UML (Unified Modeling Language). Na podstawie tego modelowania UML można wyprowadzić dwie wersje TPEG:

  • Kodowanie w Extensible Markup Language (XML) - ta wersja jest zarówno do odczytu maszynowego, jak i do ręcznego odczytu / interpretacji. Zgodność wsteczną gwarantuje fakt, że nowe elementy XML (znaczniki) ze starszych urządzeń są pomijane, ponieważ nie mogą rozpoznać i zinterpretować nowych znaczników.
  • kodowanie binarne - tej wersji nie można odczytać / zinterpretować ręcznie. Zaletą jest jednak to, że jest znacznie bardziej kompaktowy. Kodowanie binarne jest zatem używane głównie wtedy, gdy wydajność przepustowości jest najwyższym priorytetem.

Podstawowe zasady

Poniższe zasady są kamieniami węgielnymi w rozwoju składni i semantyki TPEG (patrz także ISO / TS 18234-2 i ISO / TS 21219-5):

  • Jednokierunkowość - TPEG nie wymaga kanału zwrotnego (kanał zwrotny nie musi, ale może być zaimplementowany w TPEG, szczególnie dla usług za pośrednictwem mobilnej sieci radiowej lub sieci IP)
  • Orientacja bajtów
  • asynchroniczna struktura ramek
  • hierarchiczne wykrywanie błędów poprzez cykliczne kontrole nadmiarowości (CRC) na różnych poziomach protokołu
  • TPEG wymaga odpowiednich mechanizmów korekcji błędów w medium transmisyjnym
  • TPEG wymaga przezroczystego kanału danych
  • Hierarchiczna struktura ramowa do kodowania wiadomości i usług
  • TPEG oferuje mechanizmy przekazywania informacji do usługodawcy, serwisu i sieci
  • Szyfrowanie usług komercyjnych

Dalsze funkcjonalności

  • Separacja treści i transmisja w projekcie protokołu
    • Oddzielenie treści wiadomości i odniesień do lokalizacji w ramach kodowania treści
  • Odniesienia do lokalizacji zarówno za pomocą dynamicznych metod odniesienia (odniesienie do lokalizacji w locie), jak i za pomocą stałych punktów odniesienia na mapach (tabele lokalizacji)
    • Dostępnych jest kilka metod dynamicznego (w locie) odwoływania się do lokalizacji
  • Niezależność językowa
  • opcjonalne kodowanie wiadomości z rozbudowanymi atrybutami i dodatkowymi informacjami
  • Możliwość filtrowania usług i wiadomości według różnych kryteriów
  • Możliwość rozbudowy o nowe usługi i typy wiadomości
  • Niezależność od baz danych z odniesieniami do lokalizacji (np. Konieczne dla RDS-TMC)
  • Dekodowanie usług TPEG jest możliwe zarówno dla wydajnych urządzeń końcowych (np. Urządzenia nawigacyjne z mapami i grafiką), jak i dla najprostszych urządzeń (np. Bez mapy i tylko z wyświetlaczem tekstowym)
  • Dostosowanie się do nowych mediów transmisyjnych jest łatwe dzięki zdefiniowaniu warstw adaptacyjnych

Specyficzne właściwości i funkcje TPEG

Niezależność językowa

System informacji o ruchu drogowym powinien być w stanie przedstawić wymagane informacje w odpowiednim języku użytkownika.

TPEG umożliwia tę wielojęzyczność dzięki zastosowaniu rozszerzalnych tabel tłumaczeń. W tym celu słowa o podobnym znaczeniu, które są często wymagane w komunikatach TPEG, zestawiono w tabelach. Do tych słów można się odwoływać w komunikacie TPEG za pośrednictwem numeru. Te odniesienia są następnie przesyłane w komunikacie TPEG zamiast zwykłego tekstu. Tylko po stronie klienta dane wyjściowe są generowane na podstawie tabel, które muszą być dostępne na kliencie w żądanym języku. Może to być wiadomość tekstowa w języku użytkownika, symbol lub komunikat głosowy.

Na przykład różne pojazdy są wymienione w tabeli TPEG-RTM (rtm01) typ_pojazdu , takie jak samochód, taksówka, autobus lub tramwaj. Aby zapewnić możliwość rozwinięcia tabel, każda tabela zawiera również wartość domyślną. Oznacza to, że nie wszyscy klienci muszą być aktualizowani po rozszerzeniu tabel. Jeśli klient, który nie jest aktualny, otrzyma odniesienie do wpisu, który nie został jeszcze uwzględniony w jego wersji, zostanie wyświetlony wpis standardowy. Użytkownik zazwyczaj nadal jest w stanie zrozumieć komunikat, nawet jeśli prawdopodobnie utracono szczegóły [TPEG].

Jeśli, na przykład, zgłoszono nieprawidłowo prowadzący motocykl, TPEG-RTM przenosi odniesienia do pozycji 19 i 7 w tabelach vehicle_type i vehicle_problem_type.

Gdyby wyżej wymieniony komunikat został przesłany do klienta, którego tablica vehicle_type nie zawiera jeszcze wpisu 19, użyty zostałby wpis domyślny (pojazd). Użytkownik systemu nawigacyjnego jest wyświetlany zamiast komunikatu „Motocykl jedzie do Ciebie autostradą A9 w kierunku Monachium!” Komunikat typu „Samochód jedzie do Ciebie autostradą A9 w kierunku Monachium!”.

Do określenia tabel stosuje się tak zwany CEN-English. Są to terminy techniczne, które często nie mają nic wspólnego z codziennym angielskim i stanowią definicję poszczególnych haseł. CEN-English jest używany, aby uniknąć nieporozumień lub nieścisłości. Ze względu na różnicę w stosunku do konwencjonalnego użycia, CEN-English nie powinien być również wydawany bezpośrednio w krajach anglojęzycznych, ale powinien być przetłumaczony na powszechnie używane terminy. [TPEG] Niezależność językowa ma jednak swoje ograniczenia w nazwach miejsc, ponieważ nie wszystkie wyobrażalne nazwy mogą być przechowywane w tabelach. Takie informacje są przekazywane w postaci ciągów, chociaż możliwe są tutaj również różne wersje językowe.

Niezależność od materiału mapowego (TPEG-Loc)

System odniesienia do lokalizacji TPEG nosi nazwę TPEG-Loc. Został zaprojektowany w taki sposób, aby generować możliwie precyzyjne odniesienia do lokalizacji zarówno na klientach posiadających bazę danych lokalizacji, jak i na klientach nieposiadających danych lokalizacyjnych. Ponadto położono nacisk na to, aby odniesienia do lokalizacji były zrozumiałe zarówno dla człowieka, jak i maszyny. Baza danych lokalizacji lub mapa, za pomocą której długość i szerokość geograficzną można przekształcić w określone informacje o lokalizacji, nie są absolutnie konieczne do zrozumienia danych TPEG-Loc.

Aby osiągnąć powyższe cele, oprócz współrzędnych lokalizacji w układzie współrzędnych WGS84 (World Geodetic System 1984) przekazywane są dodatkowe informacje, które mają dotyczyć środowiska. Transmisja za pomocą współrzędnych WGS84 ma sens, ponieważ ten system odniesienia jest używany między innymi przez GPS i de facto reprezentuje światowy standard.

Do opisu punktu położonego pomiędzy dwoma zjazdami z autostrady A i B, oprócz współrzędnych punktu używa się np. Nazw zjazdów. Zalety tej informacji są oczywiste: system nawigacyjny otrzymuje dokładne informacje, gdzie ten punkt się znajduje. Z drugiej strony urządzenia PDA bez materiału mapowego mogą przynajmniej z grubsza opisać swoim użytkownikom, że wspomniany punkt znajduje się między dwoma wyjściami A i B.

Niezależność od kanału transmisji

Ponieważ TPEG ma być używany w różnych kanałach transmisji, takich jak cyfrowe nadawanie dźwięku (DAB), cyfrowe nadawanie wideo (DVB) lub w Internecie, rodzaj transmisji nie może odgrywać żadnej roli. W oryginalnej specyfikacji TPEG opracowano więc format binarny, który nie wymaga określonej formy transmisji, takiej jak pakietowa lub połączeniowa, a także nie wymaga kanału zwrotnego. [TPEG2] Aby to osiągnąć, binarny protokół TPEG w modelu warstwowym ISO / OSI przejmuje same warstwy od 3 do 7. TPEG jest zatem zależny tylko od warstw 1 i 2. Sam nośnik transmisji ma za zadanie jedynie przesyłać pojedyncze bajty. Wyższe funkcje, takie jak segmentacja lub wykrywanie błędów podczas transmisji, są obsługiwane przez sam TPEG. [TPEG6] Segmentacja jest konieczna, ponieważ każda wiadomość jest transmitowana jako pojedyncza wiadomość. Ponadto kilka usług TPEG może przesyłać swoje komunikaty na tym samym kanale.

W tym miejscu należy jednak zaznaczyć, że ze względu na specyfikację klienci TPEG nie mają możliwości ponownego zażądania nieprawidłowo przesłanych informacji. To ograniczenie jest konieczne, aby TPEG radził sobie również z mediami transmisyjnymi bez kanału zwrotnego (np. DAB). Dlatego kanał transmisyjny powinien być maksymalnie odporny na błędy transmisji i posiadać funkcje kompensacji błędów. Ponadto, jeśli to możliwe, poszczególne wiadomości należy przesyłać wielokrotnie.

Ze względu na wysoką entropię format binarny jest szczególnie odpowiedni do transmisji między punktem wysyłania a klientem, ponieważ można wtedy również stosować połączenia o małych szybkościach transmisji danych. Format binarny jest również korzystny dla użytkowników, którzy są połączeni z dostawcą TPEG za pośrednictwem GPRS (General Packet Radio Service) lub UMTS (Universal Mobile Telecommunications System), ponieważ często rozliczana jest tu wielkość transmisji. Ponadto format ten jest łatwiejszy do zdekodowania na klientach ubogich w zasoby niż później opracowany format XML tpegML (tpegML oznacza TPEG w XML ), do którego przetwarzania wymagane są złożone parsery XML. Z drugiej strony użycie łatwego w zarządzaniu formatu XML ma sens, zwłaszcza ze strony dostawcy treści. W międzyczasie parsery i walidatory XML są dostępne dla każdego wspólnego języka programowania. tpegML wykorzystuje te właściwości i odwzorowuje struktury danych TPEG na ten łatwy w użyciu format. Komunikaty TPEG mogą być wymieniane między poszczególnymi systemami w standardowym formacie podczas ich tworzenia. Dostawca treści może również wysyłać zapytania do wielu źródeł danych i przetwarzać ich informacje przy niewielkim wysiłku, jeśli źródła są zgodne z tym standardem. Pomimo sprzeczności między strumieniem binarnym a plikiem XML, informacje TPEG zawarte w obu formatach można odwzorować 1 na 1 na siebie. Niezależność transmisji danych w standardzie TPEG można zatem interpretować dwojako. Z jednej strony opracowano format binarny, który jest już używany na trzeciej warstwie w modelu ISO / OSI i wymaga jedynie prostej transmisji bitów. Z drugiej strony, w przypadku tpegML istnieje format danych oparty na XML, który można łatwo przesyłać, a przede wszystkim przetwarzać. Konwersja tego formatu jest również łatwa do przeprowadzenia dzięki licznym opcjom transformacji.

Format danych

Zasadniczo dane TPEG są przesyłane w pakietach lub jako pojedyncze wiadomości. Ponieważ TPEG wykorzystuje już warstwę 3 modelu ISO / OSI , segmentację przejmuje również TPEG. Wiadomość składa się co najmniej z kontenera zarządzania wiadomościami, który zawiera informacje sterujące dla aplikacji (RTM lub PTI). Jeśli oprócz informacji sterujących mają być przesyłane dane użytkownika, należy dołączyć kontener zdarzenia RTM lub PTI oraz kontener lokalizacji TPEG. Aby unieważnić inną wiadomość, używana jest wiadomość, która składa się tylko z kontenera zarządzania wiadomościami. [TPEG2] Należy zauważyć, że kontener zarządzania wiadomościami może się różnić w zależności od aplikacji.

Struktura komunikatu TPEG

Kontener zarządzania wiadomościami

Termin „Zarządzanie wiadomościami” podsumowuje wszystkie informacje, które są używane do kontrolowania wiadomości RTM i zarządzania nią (pola, które muszą być obecne, są zaznaczone):

  • Identyfikator wiadomości (obowiązkowy): W przeciwieństwie do tego, co sugeruje nazwa, nie jest to unikalna nazwa konkretnej wiadomości, ale nazwa wydarzenia. Oznacza to, że wszystkie wiadomości, które zawierają informacje o zdarzeniu (np. Korku na określonej ulicy) mają ten sam identyfikator wiadomości.
  • Numer wersji (obowiązkowy): kolejny numer, który pokazuje kolejność komunikatów dla określonego zdarzenia. Z każdą nową wiadomością o wydarzeniu numer wersji jest zwiększany o jeden. Dekoder TPEG może zatem przywrócić kolejność komunikatów, które należą do zdarzenia (tj. Mają ten sam identyfikator komunikatu), nawet jeśli komunikaty nie dotrą we właściwej kolejności. Ma to szczególne znaczenie w scenariuszach rozgłaszania, ponieważ odbiorca może rozpocząć słuchanie strumienia informacji w dowolnym momencie, a zatem odbiera tylko nieodebrane wiadomości w sekwencji wiadomości, gdy wiadomości są wysyłane wielokrotnie.
  • Data i godzina utworzenia wiadomości: sygnatura czasowa tworzona podczas generowania wiadomości.
  • Data i godzina rozpoczęcia: Ten znacznik czasu wskazuje, kiedy zdarzenie miało lub będzie miało miejsce.
  • Data i godzina zakończenia: Wskazuje, kiedy wydarzenie się zakończyło.
  • Data i godzina wygaśnięcia wiadomości: Data wygaśnięcia wiadomości. Jeśli klient otrzyma wiadomość, której data ważności już minęła, zignoruje tę wiadomość.
  • Informacje o harmonogramie: można ich użyć do przypisania harmonogramu do wydarzenia. Można określić jeden lub więcej przedziałów czasowych, w których ma miejsce zdarzenie określone w komunikacie. Można również określić cotygodniowe powtórzenia. Więc z. Na przykład można określić, że określony odcinek trasy jest zamknięty we wszystkie dni powszednie w godzinach od 17:00 do 21:00. Informacje o harmonogramie są ważne tylko w okresie między datą i godziną rozpoczęcia a datą i godziną zakończenia.
  • Wskaźnik ważności: wskazuje ważność wiadomości. Użytkownik ma możliwość sortowania przychodzących wiadomości według ich ważności lub ukrywania nieistotnych wiadomości.
  • Niezweryfikowane informacje: Wskazuje, czy treść wiadomości została zweryfikowana, tj. H. pochodzi z zaufanego źródła lub został zweryfikowany przez zaufane źródło.

Kontener z opisem wydarzenia

Ten obszar wiadomości zawiera informacje o samym zdarzeniu. Opis zdarzenia ma strukturę hierarchiczną, tak że poziom szczegółowości rośnie z każdym poziomem hierarchii. Klient, który dekoduje tylko pierwszy poziom hierarchii, otrzymuje zatem tylko przybliżone informacje, które stają się bardziej szczegółowe z każdym dodatkowym zdekodowanym poziomem. Jest to przydatne, ponieważ na przykład w przeglądzie wiadomości powinny być wyświetlane tylko przybliżone informacje. Klienci, którzy nie są w stanie zdekodować złożonej wiadomości z powodu ograniczonych zasobów, mogą po prostu zignorować niższe poziomy hierarchii. Następujące typy są obecnie zdefiniowane dla pierwszego poziomu, który z kolei zawiera podtypy dla dokładniejszego opisu:

  • Wypadek: opis wypadków
  • Przeszkody: niepełnosprawność
  • Działania: imprezy takie jak parady lub pokazy
  • Warunki drogowe: Informacje o warunkach drogowych
  • Wydajność sieci: informacje o natężeniu ruchu (np. Korki lub wolno poruszający się ruch)
  • Warunki sieciowe: reguły ruchu odbiegające od normalnych warunków, np. B. czasowa zmiana pierwszeństwa przejazdu
  • Alert bezpieczeństwa: ostrzeżenia dotyczące sytuacji, które mogą stanowić zagrożenie dla kierowcy (np. Zagrożenie bombowe).
  • Informacje o transporcie publicznym: Informacje o zakłóceniach w systemie transportu publicznego, które mogą mieć wpływ na ruch drogowy.
  • Widzialność: opis warunków widoczności (np. Mgła)
  • Pogoda: informacje pogodowe, które mają wpływ na podróż (np. Czarny lód)
  • Diversion Advise: Informacje o alternatywnych trasach, takich jak objazdy.

Zdarzenie jest opisane przez co najmniej jeden z tych typów, ale może też składać się z kilku. Czy to przychodzi B. korek drogowy spowodowany wypadkiem spowodowanym uszkodzeniem drogi i słabą widocznością, komunikat składa się z typów: Wypadek, Działanie sieci, Warunki drogowe i Widoczność.

Kontener lokalizacyjny TPEG

Ten kontener zawiera odniesienie do lokalizacji, jak już opisano powyżej ( TPEG-Loc ). Każda wiadomość, która jest powiązana z lokalizacją, ma taki kontener.

Format binarny (zgodnie z TPEG2)

W tej sekcji opisano część formatu binarnego, która jest specyficzna dla tego formatu; H. dla którego nie ma odpowiednika w formacie XML. Zasadniczo rozróżnia się dwa typy wiadomości, które rozróżnia się za pomocą pola „Typ ramki”:

  • Informacje o katalogu strumienia: zawiera listę wszystkich dostawców usług aktywnych w tym strumieniu.
  • Konwencjonalne dane ramki usług: zawierają dane użytkownika

Oprócz typu ramki binarny komunikat TPEG zawiera dodatkowe pola, które wyjaśniono poniżej:

  • Sync Word (2 bajty): używane przez dekoder do rozpoznawania nowej wiadomości. To słowo synchronizacji ma zawsze wartość szesnastkową FF0F.
  • Długość pola (2 bajty): Całkowita długość ramki usługi w bajtach. Ramka usługi nie może być większa niż 65535 bajtów.
  • Typ ramki (1 bajt): zapewnia wyżej wspomniane rozróżnienie między „Informacją o katalogu strumieniowym” a „Konwencjonalnymi danymi ramek usług”.
  • Nagłówek CRC: suma kontrolna zapewniająca poprawność danych nagłówka. Suma ta jest obliczana przy użyciu pól Sync Word, Field Length, Frame Type i pierwszych 11 bajtów ramki serwisowej. Więcej informacji na temat tego obliczenia można znaleźć w [TPEG2].
  • Ramka usługi: zawiera dane użytkownika (prawdopodobnie w postaci zaszyfrowanej), a także identyfikator usługi. Dostawcę zawartości można wyraźnie zidentyfikować za pomocą identyfikatora usługi (SID). Rama serwisowa jest z kolei podzielona na następujące komponenty:
    • SID-A do C (1 bajt każdy): razem dają unikalny numer identyfikacyjny usługodawcy, porównywalny z adresem IP, np. B. 133.168.123.
    • Wskaźnik szyfrowania (1 bajt): określa metodę szyfrowania na podstawie wartości od 0 do 255. Wartości od 0 do 127 są zarezerwowane dla metod znormalizowanych. 128–255 są przeznaczone do bezpłatnego użytku przez usługodawcę. Szyfrowanie może np. B. rozwijał płatne usługi. Korzystanie z zaszyfrowanych wiadomości byłoby również możliwe w aplikacjach krytycznych dla bezpieczeństwa, takich jak B. można użyć radia policyjnego lub wojskowego.
    • Component Multiplex: Ten prawdopodobnie zaszyfrowany obszar danych zawiera następnie aktualne komunikaty TPEG, jak opisano na początku rozdziału 3. Dopóki nie zostanie przekroczony maksymalny rozmiar 65531 bajtów, obszar ten może pomieścić kilka wiadomości. Kodowanie tych danych można znaleźć w specyfikacji.

Aplikacje TPEG2

Nr ISO Odniesienie ISO tytuł akronim opis
21219-1 Część 1: Wprowadzenie, numeracja i wersje Wprowadzenie i nazewnictwo komponentów i usług TPEG 2.generacji, w tym identyfikacja aplikacji (AID).
21219-2 Część 2: Zasady modelowania UML Składnia i semantyka usług TPEG, niezależnie od fizycznego formatu danych (binarny lub XML).
21219-3 Część 3: UML na binarne reguły konwersji Usługi TPEG są modelowane w języku UML, aby zapewnić niezależność od określonego kodowania (binarnego lub XML). Oddzielając semantykę i opis aplikacji, można łatwo i jednolicie opracować funkcje dla obu kodowań. Formaty kodowania są następnie generowane bezpośrednio z opisu UML przy użyciu narzędzi do tłumaczenia (generatorów kodu).
21219-4 Część 4: Reguły konwersji UML na XML Zestaw reguł konwersji opisów TPEG UML do formatu XML.
21219-5 Część 5: Ramy usług Opis kompilacji (multipleksowania) ofert usług (bukietów) z poszczególnych usług.
21219-6 Część 6: Kontener zarządzania wiadomościami Zarządzanie wiadomościami w urządzeniu końcowym
21219-7 Część 7: Lokalizacja z odniesieniem do kontenera Kontener TPEG2 do odwoływania się do lokalizacji (kontener odniesienia do lokalizacji) pokazuje, która metoda odniesienia jest używana. Można osadzić różne metody odwoływania się do lokalizacji.
21219-9 Część 9: Informacje o usługach i sieci Kodowanie wyświetlania usługodawcy, usługi, komponentów usługi i nośnika. Może być również używany do łączenia tych samych lub powiązanych usług za pośrednictwem innych mediów nośnych (łączenie usług).
21219-10 Część 10: Informacje o dostępie warunkowym Funkcje do szyfrowania usług komercyjnych
21219-11 Część 11: Odniesienia do lokalizacji uniwersalnej Uniwersalna metoda odwoływania się do lokalizacji
21219-14 Część 14: Aplikacja do informacji parkingowych Informacje o miejscach parkingowych i garażach (lokalizacja, godziny otwarcia, liczba wolnych miejsc itp.)
21219-15 Część 15: Kompaktowa aplikacja dotycząca zdarzeń drogowych TEC Kompaktowa reprezentacja komunikatów o zdarzeniach, szczególnie do przetwarzania w urządzeniach nawigacyjnych i do obsługi dynamicznych zmian trasy (zalecenie objazdu)
21219-16 Część 16: Aplikacja informacyjna o cenach paliw Informacje o stacjach benzynowych i cenach paliw
21219-18 Część 18: Przepływ ruchu i aplikacja do prognozowania TFP Kompaktowe przedstawienie informacji o ruchu drogowym, szczególnie do przetwarzania w urządzeniach nawigacyjnych i do obsługi dynamicznych zmian trasy (zalecenie objazdu)
21219-19 Część 19: Aplikacja do informacji o pogodzie Informacje o pogodzie
21219-20 Część 20: Rozszerzone odniesienia do lokalizacji TMC Rozszerzenie dla odniesień do lokalizacji z tabelami odniesienia dla stałych lokalizacji (TMC Location Tables), szczególnie do użytku w połączeniu z TEC
21219-21 Część 21: Odniesienia do lokalizacji geograficznej Metoda odniesień do lokalizacji dla obszarów i punktów niezależnych od ulic
21219-22 Część 22: Odwołania do lokalizacji OpenLR Metoda odniesienia do lokalizacji
21219-23 Część 23: Zastosowanie tras drogowych i multimodalnych Informacje o trasach multimodalnych

Usługi TPEG na całym świecie

Nadawanie

kraj Dostawca usługi status produkt Usługi TPEG
Belgia Be-Mobile relacja na żywo Premia TEC / TFP
Niemcy ARD relacja na żywo Free to Air TEC / TFP
Niemcy TUTAJ relacja na żywo Premia TEC / TFP
Niemcy Mediamobile relacja na żywo Ruch pionowy TEC / TFP
Luksemburg Be-Mobile relacja na żywo Premia TEC / TFP
Holandia Be-Mobile relacja na żywo Premia TEC / TFP
Norwegia Mediamobile relacja na żywo Ruch pionowy TEC / TFP
Zjednoczone Królestwo Inrix relacja na żywo Premia TEC / TFP
Zjednoczone Królestwo Mistrz ruchu relacja na żywo Premia TEC
Transmisje testowe
Francja Mediamobile Trial (w niektórych miastach) Ruch pionowy TEC / TFP
Włochy Infoblu Próba Premia TEC / TFP
Polska Mediamobile Próba Ruch pionowy TEC / TFP
Szwecja Mediamobile Próba Ruch pionowy TEC / TFP

Transmisja komórkowa

kraj Dostawca usługi status produkt Usługi TPEG
Andora Tomtom relacja na żywo Premia TEC / TFP / WEA
Argentyna TUTAJ relacja na żywo Premia TEC / TFP
Australia TUTAJ relacja na żywo Premia TEC / TFP
Australia Tomtom relacja na żywo Premia TEC / TFP / WEA
Austria TUTAJ relacja na żywo Premia TEC / TFP
Austria Tomtom relacja na żywo Premia TEC / TFP / WEA
Belgia TUTAJ relacja na żywo Premia TEC / TFP
Belgia Tomtom relacja na żywo Premia TEC / TFP / WEA
Brazylia TUTAJ relacja na żywo Premia TEC / TFP
Brazylia Tomtom relacja na żywo Premia TEC / TFP / WEA
Kanada TUTAJ relacja na żywo Premia TEC / TFP
Kanada Tomtom relacja na żywo Premia TEC / TFP / WEA
Chile Tomtom relacja na żywo Premia TEC / TFP / WEA
Chiny Tomtom relacja na żywo Premia TEC / TFP / WEA
Republika Czeska TUTAJ relacja na żywo Premia TEC / TFP
Republika Czeska Tomtom relacja na żywo Premia TEC / TFP / WEA
Chorwacja TUTAJ relacja na żywo Premia TEC / TFP
Dania TUTAJ relacja na żywo Premia TEC / TFP
Dania Tomtom relacja na żywo Premia TEC / TFP / WEA
Finlandia TUTAJ relacja na żywo Premia TEC / TFP
Finlandia Tomtom relacja na żywo Premia TEC / TFP / WEA
Francja TUTAJ relacja na żywo Premia TEC / TFP
Francja Tomtom relacja na żywo Premia TEC / TFP / WEA
Niemcy Tomtom relacja na żywo Premia TEC / TFP / WEA
Niemcy TUTAJ relacja na żywo Premia TEC / TFP
Niemcy Inrix relacja na żywo Premia TEC / TFP
Gibraltar Tomtom relacja na żywo Premia TEC / TFP / WEA
Grecja TUTAJ relacja na żywo Premia TEC / TFP
Węgry TUTAJ relacja na żywo Premia TEC / TFP
Indie TUTAJ relacja na żywo Premia TEC / TFP
Indonezja TUTAJ relacja na żywo Premia TEC / TFP
Irlandia TUTAJ relacja na żywo Premia TEC / TFP
Irlandia Tomtom relacja na żywo Premia TEC / TFP / WEA
Włochy TUTAJ relacja na żywo Premia TEC / TFP
Włochy Tomtom relacja na żywo Premia TEC / TFP / WEA
Lesotho Tomtom relacja na żywo Premia TEC / TFP / WEA
Liechtenstein Tomtom relacja na żywo Premia TEC / TFP / WEA
Luksemburg TUTAJ relacja na żywo Premia TEC / TFP
Luksemburg Tomtom relacja na żywo Premia TEC / TFP / WEA
Malezja TUTAJ relacja na żywo Premia TEC / TFP
Malezja Tomtom relacja na żywo Premia TEC / TFP / WEA
Malta Tomtom relacja na żywo Premia TEC / TFP / WEA
Meksyk TUTAJ relacja na żywo Premia TEC / TFP
Meksyk Tomtom relacja na żywo Premia TEC / TFP / WEA
Monako Tomtom relacja na żywo Premia TEC / TFP / WEA
Holandia TUTAJ relacja na żywo Premia TEC / TFP
Holandia Tomtom relacja na żywo Premia TEC / TFP / WEA
Nowa Zelandia TUTAJ relacja na żywo Premia TEC / TFP
Nowa Zelandia Tomtom relacja na żywo Premia TEC / TFP / WEA
Norwegia TUTAJ relacja na żywo Premia TEC / TFP
Norwegia Tomtom relacja na żywo Premia TEC / TFP / WEA
Polska TUTAJ relacja na żywo Premia TEC / TFP
Polska Tomtom relacja na żywo Premia TEC / TFP / WEA
Portugalia TUTAJ relacja na żywo Premia TEC / TFP
Portugalia Tomtom relacja na żywo Premia TEC / TFP / WEA
Portoryko TUTAJ relacja na żywo Premia TEC / TFP
Rosja TUTAJ relacja na żywo Premia TEC / TFP
Rosja Tomtom relacja na żywo Premia TEC / TFP / WEA
San Marino Tomtom relacja na żywo Premia TEC / TFP / WEA
Arabia Saudyjska TUTAJ relacja na żywo Premia TEC / TFP
Arabia Saudyjska Tomtom relacja na żywo Premia TEC / TFP / WEA
Singapur TUTAJ relacja na żywo Premia TEC / TFP
Singapur Tomtom relacja na żywo Premia TEC / TFP / WEA
Słowacja TUTAJ relacja na żywo Premia TEC / TFP
Słowenia TUTAJ relacja na żywo Premia TEC / TFP
Afryka Południowa TUTAJ relacja na żywo Premia TEC / TFP
Afryka Południowa Tomtom relacja na żywo Premia TEC / TFP / WEA
Korea Południowa TUTAJ relacja na żywo Premia TEC / TFP
Hiszpania TUTAJ relacja na żywo Premia TEC / TFP
Hiszpania Tomtom relacja na żywo Premia TEC / TFP / WEA
Szwecja TUTAJ relacja na żywo Premia TEC / TFP
Szwecja Tomtom relacja na żywo Premia TEC / TFP / WEA
Szwajcaria TUTAJ relacja na żywo Premia TEC / TFP
Szwajcaria Tomtom relacja na żywo Premia TEC / TFP / WEA
Tajwan TUTAJ relacja na żywo Premia TEC / TFP
Tajwan Tomtom relacja na żywo Premia TEC / TFP / WEA
Tajlandia TUTAJ relacja na żywo Premia TEC / TFP
Tajlandia Tomtom relacja na żywo Premia TEC / TFP / WEA
indyk TUTAJ relacja na żywo Premia TEC / TFP
indyk Tomtom relacja na żywo Premia TEC / TFP / WEA
Ukraina TUTAJ relacja na żywo Premia TEC / TFP
Zjednoczone Emiraty Arabskie TUTAJ relacja na żywo Premia TEC / TFP
Zjednoczone Emiraty Arabskie Tomtom relacja na żywo Premia TEC / TFP / WEA
Zjednoczone Królestwo TUTAJ relacja na żywo Premia TEC / TFP
Zjednoczone Królestwo Tomtom relacja na żywo Premia TEC / TFP / WEA
Stany Zjednoczone TUTAJ relacja na żywo Premia TEC / TFP
Stany Zjednoczone Tomtom relacja na żywo Premia TEC / TFP / WEA
Watykan Tomtom relacja na żywo Premia TEC / TFP / WEA

Usługi hybrydowe (broadcast + komórkowe)

kraj Dostawca usługi status produkt Usługi TPEG
Stany Zjednoczone Total Traffic and Weather Network relacja na żywo Hybryda TTN HD TEC / TFP / FPI

literatura

  • EUROPEJSKA UNIA NADAWANIA, Wytyczne TPEG w Internecie, 2002
  • EUROPEJSKA UNIA NADAWANIA, TPEG - O co w tym wszystkim chodzi?, 2003
  • EUROPEJSKA UNIA NADAWANIA, Specyfikacje TPEG - Suplement: TPEG Tabele: RTM, PTI, Loc - Wersja 3.0, 2002
  • EUROPEJSKA UNIA NADAWANIA, Specyfikacje TPEG - Część 2: Składnia, semantyka i struktura ramek, 2002
  • EUROPEJSKA UNIA NADAWANIA, Specyfikacje TPEG - Część 4: Komunikat o ruchu drogowym, 2002
  • EUROPEJSKA UNIA NADAWCZA, Specyfikacje TPEG - Część 5: Wniosek dotyczący informacji o transporcie publicznym, 2002
  • EUROPEJSKA UNIA NADAWANIA, Specyfikacje TPEG - Część 6: Odniesienia do lokalizacji dla zastosowań, 2002
  • EUROPEJSKA UNIA NADAWCZA, specyfikacje tpegML - Część 1: Wprowadzenie, typowe typy danych i tpegML v1.00, 2004
  • EUROPEJSKA UNIA NADAWCZA, specyfikacje tpegML - Część 2: tpeg-locML v1.00, 2004
  • EUROPEJSKA UNIA NADAWCZA, Specyfikacje tpegML - Część 3: tpeg-rtmML v1.00, 2004
  • MARKS, B., Guidelines for TPEG in DAB, 2000

linki internetowe

Indywidualne dowody

  1. ↑ EBU Technology & Innovation - TPEG (w języku angielskim, dostęp 18 sierpnia 2014).