テペグ

トランスポート プロトコル エキスパート グループ( TPEG )は、交通および旅行関連情報のデータ プロトコル スイートです。TPEG は、デジタル ブロードキャストやセルラー ネットワーク (ワイヤレス インターネット) などのさまざまな伝送メディア (ベアラー) を介して伝送できます。TPEG アプリケーションには、道路状況、天気、燃料価格、駐車場、公共交通機関の遅延に関する情報などがあります。

TPEG は、交通および旅行関連情報を伝送するためのデータ プロトコルのセットであり、さまざまなアプリケーションと、特定のアプリケーションに属するさまざまなメッセージの処理、アプリケーションをデータ フレームにグループ化、メッセージの更新とキャンセルなど、アプリケーション自体の送信を管理するための基本的な構成要素で構成されています。TPEG は、デジタル放送^{[1] [2] [3]やセルラー ネットワーク (無線インターネット) などのさまざまな伝送メディア (ベアラ) を介して伝送できます。TPEG アプリケーションには、道路状況、天気、 [4]}燃料価格、駐車場、公共交通機関の遅延 に関する情報などが含まれます。

トランスポート プロトコル専門家グループは、1997 年に欧州放送連合(EBU) によって設立されました。^[5]この作業は EBU の支援の下で 2007 年まで続けられ、その後、このグループは、ERTICO – ITS Europe が主催するトラフィック メッセージ チャネル(TMC) プロトコルに取り組む別のグループおよび Mobile.Info プロジェクトと合併しました。Mobile.Info プロジェクトでは、TPEG 技術の最初のプロトタイプが、多くの自動車メーカーとそのサプライヤーによってさまざまな車載ナビゲーション システムで実際の運転条件下でテストされました。現在、開発作業は旅行者情報サービス協会(TISA) によって行われており、同協会は現在、RDS-TMC サービスの実装に使用される Alert-C 標準も管理しています。

トランスポート プロトコル専門家グループの初期には、RDS-TMC や独自プロトコルなどの既存の技術をはるかに超えて交通情報サービスを拡張できるアプリケーションを開発する計画がありました。さらに、TPEG には、個人輸送 (車を使用) と公共輸送 (バス、地下鉄、電車など) の間など、さまざまな輸送モード間での旅行者の移動を容易にする、マルチモーダル旅行者情報サービスが含まれる必要があります。すべては道路交通メッセージ (RTM) ^[6]アプリケーションから始まり、すぐに公共輸送情報 (PTI) アプリケーションによって補完され、両方とも共通のネイティブ TPEG 位置参照方法を共有しました。

TPEG RTM は、「1 つのサイズですべてに対応」するアプリケーションとして意図されていました。しかし、初期の実装では、RTM 構造が広すぎて、TMC の代わりにナビゲーション システムで使用することができないことがすぐに判明しました。この第 1 世代の TPEG アプリケーション (TPEG 世代 1、またはTPEG1 ) もバイナリ エンコーディングのみを提供し、場合によっては XML エンコーディングへのマッピング用に別の仕様がありました。その結果、一般的な情報モデリング スタイルと設計アプローチの両方が改訂され、TPEG は特定のユース ケース向けに明確に定義され分離されたアプリケーションとトップダウンのデータ モデリング アプローチへと移行しました。この第 2 世代の TPEG アプリケーション (TPEG 世代 2、または TPEG2) は、UML モデルで指定されるようになりました。このモデルから、バイナリ エンコーディングと XML エンコーディングの両方が自動的に派生します。TPEG2 アプリケーション仕様には、バイナリ エンコーディングと XML エンコーディングの両方が仕様の不可欠な部分として含まれています。

^{最初のTPEG2 TECアプリケーションでは、サービスプロバイダー[7]}とデバイスメーカーの両方がTPEG2をTMC ^[8]の後継として受け入れ、多くの国で展開される という点で画期的な進歩が達成されました。

TPEG1 と TPEG2 はどちらも、ISO/TS 18234 (TPEG1) および ISO/TS 21219 (TPEG2) として国際標準化機構で標準化されています。TPEG1 は現在、レガシー システムと見なされており、TPEG1 に基づく新しいサービスの実装は推奨されていません。

TPEG は、さまざまな種類の交通情報や旅行者情報を高精度に提供するための仕様を定義します。TPEG では、デジタル放送やインターネットなどのさまざまなベアラを介してデータを転送できます。実際、今日では、これは主に道路、線路、さらには歩行者を旅行者に知らせるために使用されています。道路状況、天気、燃料価格、駐車場、公共交通機関の遅延など、快適な旅のための情報は、TPEG でコード化されています。TPEG は、特定のコンテンツを運ぶコンテナを備えたプロトコルで、特定のコンテンツに関する各サービス、いわゆる「アプリケーション」は、個別の技術仕様で定義されています。TPEG は、最新かつ柔軟に設計されており、さらに将来性があり、新しいトレンド、ニーズ、条件に簡単に適応できます。適切なアプリケーションと技術実装プロファイルを選択すると、すべての旅行者に安全関連情報を時間どおりに、正確に、正確に提供できます。この大きな利点により、TPEG は規制当局や公的機関からも歓迎されています。TPEG ベースの製品は、すでにさまざまなサプライヤからヨーロッパ、アジア、アメリカのいくつかの市場で提供されています。このような製品は、コンテンツ作成/管理^[9]からエンコーダ/デコーダ機器^{[10] [11] [12]、}テスト機器^[13]、受信機/ナビゲーションデバイス^{[14] [15]、}世界中でオンラインで提供される多数のサービス^{[16] [17] [18] [19] [20] [21]}にまで及びます。さらに、暗号化ソリューション^[22]は商用サービスとして利用可能です。

TPEG は、統一モデリング言語(UML)のモデリング ユース ケースに基づいてトップダウン方式で開発されています。UML モデリングに基づいて、次の 2 つのエンコーディング バージョンが派生します。

• 拡張マークアップ言語(XML) エンコーディング – この形式は人間と機械が読み取り可能で、XML 構造を解析することでナビゲーション デバイスで簡単にレンダリングできます。さらに、新しい XML タグを特定のアプリケーションに含めることができるという点で下位互換性があり、これらのタグを認識しない古いデバイス グループでは単にスキップされます。ただし、新しいデバイス グループでは新しい機能のメリットを享受できます。
• バイナリ エンコーディング- この形式は人間が判読できるものではありませんが、XML 表現よりもはるかにコンパクトです。そのため、バイナリ エンコーディングは、利用可能な帯域幅が小さく、サービスのコンパクトなエンコーディングが重要である場合によく使用されます。

以下の原則は、TPEGプロトコル、構造、セマンティクスの開発において中核となると考えられています（^[23]と^[24]を参照）。

TPEG:

• 一方向（ブロードキャスト）および双方向通信チャネル（IPなど）用に設計されています。
• バイナリバージョンはバイト指向です
• 非同期フレーミングと階層型データフレーム構造を備えたプロトコル構造を提供します。
• さまざまなプロトコルレベルでCRCエラー検出機能を搭載
• 基礎となる通信層がエラー訂正を提供すると仮定する
• 透過的なデータチャネルを使用する
• サービスプロバイダー名、サービス名、ネットワーク情報などの送信を容易にします。
• ^{暗号化[22]}メカニズムの使用を許可する（例えば商用サービスへのアクセスを制限するため）

TPEGの追加機能

TPEG:

• 動的な（「オンザフライ」）位置参照方法をサポートしているため、事前にロードされた位置データベース（例：TMCロケーションテーブル）は必要ありません。
• リッチコンテンツエンコーディングを提供
• 言語に依存しない
• クライアントデバイスによるサービスコンテンツのフィルタリングを容易にする
• 「シック」および「シン」クライアントデバイスをサポートするように設計されています
• 異なる通信ベアラに適応層を提供する

• 交通標準化団体
• 旅行者情報サービス協会(TISA)

• 旅行者情報サービス協会 (TISA)
• Institut für Rundfunktechnik (IRT)
• BESTコンソーシアム
• 世界DABフォーラム
• 翻訳元