※一部、英文及び仏文を自動翻訳した日本語訳を使用しています。
序章
0.1 自律システム
ISO 17575 は、自律型車載機器 (OBE) に基づく電子料金徴収 (EFC) におけるフロントエンドとバックエンド間の情報交換を定義する一連の規格です。 EFC システムは、高速道路の通行料、都市部のゾーンベースの料金、橋やトンネルなどの特別なインフラストラクチャの料金、距離ベースの料金および駐車料金など、道路インフラの使用に関する課金データを自動的に収集します。
自律型 OBE は、全地球的航法衛星システム (GNSS) やセルラー ネットワーク (CN) などの広域技術を採用することにより、専用の路側インフラに依存することなく動作します。これらの EFC システムは、さまざまな名前で呼ばれています。自律システムと GNSS/CN システムという用語の他に、GPS/GSM システムと広域課金システムという用語も使用されています。
自律システムは衛星測位を使用し、多くの場合、ジャイロスコープ、走行距離計、加速度計などの追加のセンサー技術と組み合わせて、車両の位置を特定し、帯電した道路や帯電したエリアなどの帯電した地理的オブジェクトを含む地図上でその位置を見つけます。課金対象、車両の特性、時間帯、その他の道路利用に関するデータから、料金、最終的には道路利用料金が決定されます。
電子料金徴収への自律的アプローチの 2 つの強みは、考えられるほぼすべての課金原則の実装を可能にする柔軟性と、ローカル インフラストラクチャからの独立性です。これにより、この技術は、課金システムや国全体での相互運用性に有利になります。相互運用性は、明確に定義されたインターフェースによってのみ達成できます。これは、ISO 17575 の目的と正当化です。
0.2 ビジネス アーキテクチャ
ISO 17575 のこの部分は、ISO 17573 で定義されているビジネス アーキテクチャに準拠しています。このアーキテクチャによれば、料金請求者は道路インフラの提供者であり、したがって道路使用料の受領者です。料金請求者は、料金請求の役割に関連付けられたアクターです (図 1 を参照)
図 1 — ISO 17575 の基礎となる役割ベースのモデル
サービス プロバイダーは、道路インフラのユーザーに OBE を発行します。サービス プロバイダーは、車両が通過するすべての課金システムで道路使用量を記録する OBE を運用し、課金データを個々の課金者に配信する責任があります。一般に、各サービス プロバイダーは課金データを複数の料金請求者に配信し、一般に、各料金請求者は複数のサービス プロバイダーから課金データを受信します。相互運用性管理は、図 1 に示すように、料金請求環境全体を管理する一連のルールを定義および維持するすべての仕様とアクティビティで構成されます。
0.3 技術アーキテクチャ
図 2 の技術アーキテクチャは、特定の実際の実現とは無関係です。これは、一部の処理機能を OBE または関連するオフボード コンポーネント (プロキシ) に割り当てることができるという事実を反映しています。オンボードまたはオフボードのいずれかで実現できる処理機能の例は、マップ マッチングです。この場合、GNSS から測定された座標に関する車両の位置は、オンボードまたはオフボードに存在するマップ上の地理的オブジェクトに関連付けられます。また、タリフの計算は、OBE タリフ テーブルと処理、またはオフボード コンポーネントを使用して行うことができます。
図 2 —想定される技術アーキテクチャとインターフェース
OBE とプロキシを組み合わせた機能は、フロント エンドと呼ばれます。処理が主に OBE 側で行われるフロント エンドの実装は、スマート クライアント (またはインテリジェント クライアント、ファット クライアント) またはエッジ ヘビーとして知られています。ほとんどの処理がオフボードで行われるフロント エンドは、シン クライアントまたはエッジライト アーキテクチャと呼ばれます。図 2 のくさびの段階的な移行によって示されるように、「薄い」極端と「厚い」極端の間の多くの実装が可能です。どちらの極端なアーキテクチャの選択にもメリットがあり、メーカーがオンとオフの間の機能の個別の割り当てと競合する 1 つの手段です。 -ボードと中央リソース。
特にシン クライアント OBE の場合、メーカーは OBE とオフボード コンポーネント間のローカリゼーション データ転送のさまざまな最適化を考案する可能性があり、データ削減とデータ圧縮に独自のアルゴリズムが使用されます。この転送の標準化は、完全に可能でも有益でもありません。
0.4 仕様インターフェースの位置
これらのアーキテクチャ実装の選択を抽象化し、独立させるために、ISO 17575 の主な範囲は、フロント エンドとバック エンドの間のデータ交換です (図 2 の対応する垂直線を参照)すべての通行料制度について、バックエンドはコンテキストデータ、つまり課金オブジェクト、課金ルール、および必要に応じて料金体系に関する料金制度の説明をフロントエンドに送信し、フロントエンドから使用状況データを受信します。 .
また、サービス プロバイダーと料金請求者の間のタスクと責任の配分は、個々に異なることに注意する必要があります。地域の法的状況に応じて、料金請求者は「より薄い」または「より厚い」データを必要とし、特定のデータ処理タスクをサービス プロバイダーに任せる場合としない場合があります。したがって、ISO 17575 のデータ定義は、いくつかのインターフェイスで役立つ場合があります。
ISO 17575 はまた、基本的なメディアに依存しない通信サービスを提供します。この通信サービスは、フロント エンドとバック エンドの間の通信に使用できます。これは、回線ベースまたはエア リンクである場合があり、OBE と中央の間のエア リンクにも使用できます。通信サーバー。
0.5 ISO 17575 の一部
Part 1: 課金では、フロント エンドからバック エンドへの使用状況データの転送に関する属性を定義します。課金レポートの内容は料金体系によって異なる場合があるため、生のローカリゼーション データの属性、地図と一致する地理的オブジェクトの属性、完全に料金設定された料金トランザクションの属性に至るまで、すべての要件の属性が提供されます。通行料制度は、課金ネットワーク、課金原則、責任のある車両、および課金レポートに必要な内容の定義を含む、課金に関する一連の規則で構成されます。
Part 2: 下位層への通信と接続は、OBE エアリンクを介した、またはフロント エンドとバック エンド間のデータ転送のための基本的な通信サービスを定義します。 ISO 17575-1 および ISO 17575-3 で定義されているデータは、ISO 17575-2 で定義されている通信スタックを使用して交換できますが、交換する必要はありません。
Part 3: コンテキスト データは、課金対象の地理的オブジェクトと課金およびレポート ルールに関して、個々の課金システムの説明に使用されるデータを定義します。すべての料金請求者のシステムでは、ISO 17575-3 で定義されている属性を使用してデータをフロント エンドに転送し、どのデータを収集して報告するかをフロント エンドに指示します。
0.6 ISO 17575 がカバーするアプリケーションのニーズ
ISO 17575 シリーズの規格
- ISO 17573:2010 で定義されたアーキテクチャに準拠しています。
- 道路区間（橋、トンネル、峠などを含む）の使用料、非常線の通過（出入り）、およびエリア内のインフラストラクチャの使用（距離、時間）に対する料金をサポートします。
- 距離または期間の単位に基づく課金、およびイベントの発生に基づく課金をサポートし、
- 車両カテゴリ、道路カテゴリ、使用時間、および契約タイプ (免除車両、特別関税車両など) による料金の調整をサポートします。
- 使用期間ごとに定義された上限による料金制限のサポート、
- さまざまな法的地位の手数料をサポートします (例: 公税、私的通行料)
- 特に以下の観点から、料金請求者ごとに異なる要件をサポートします。
- 地理的ドメインとコンテキストの説明、
- 請求レポートの内容と頻度
- ドライバーへのフィードバック (例: 緑または赤のライト)、および
- 要求に応じて追加の詳細データを提供すること（紛争の解決など）
重複する地理的有料ドメインをサポートし、
の変化への適応をサポートします。
- 有料インフラ、
- 関税、および
- 参加体制、および
フロント エンドから発信されたデータの料金請求者に対する、サービス プロバイダーによる信頼保証の提供をサポートします。
Introduction
0.1 Autonomous systems
ISO 17575 is a series of standards defining the information exchange between the Front End and the Back End in electronic fee collection (EFC) based on autonomous on-board equipment (OBE). EFC systems automatically collect charging data for the use of road infrastructure including motorway tolls, zone-based fees in urban areas, tolls for special infrastructure like bridges and tunnels, distance-based charging and parking fees.
Autonomous OBE operates without relying on dedicated road-side infrastructure by employing wide-area technologies such as Global Navigation Satellite Systems (GNSS) and Cellular Networks (CN). These EFC systems are referred to by a variety of names. Besides the terms autonomous systems and GNSS/CN systems, the terms GPS/GSM systems and wide-area charging systems are also in use.
Autonomous systems use satellite positioning, often combined with additional sensor technologies such as gyroscopes, odometers and accelerometers, to localize the vehicle and to find its position on a map containing the charged geographic objects, such as charged roads or charged areas. From the charged objects, the vehicle characteristics, the time of day and other data that are relevant for describing road use, the tariff and ultimately the road usage fee are determined.
Two strengths of the autonomous approach to electronic fee collection are its flexibility, allowing the implementation of almost all conceivable charging principles, and its independence from local infrastructure, thereby predisposing this technology towards interoperability across charging systems and countries. Interoperability can only be achieved with clearly defined interfaces, which is the aim and justification of ISO 17575.
0.2 Business architecture
This part of ISO 17575 complies with the business architecture defined in ISO 17573. According to this architecture, the toll charger is the provider of the road infrastructure and, hence, the recipient of the road usage charges. The toll charger is the actor associated with the toll charging role (see Figure 1).
Figure 1—The role-based model underlying ISO 17575
Service providers issue OBE to the users of the road infrastructure. Service providers are responsible for operating OBE that will record the amount of road usage in all toll charging systems the vehicle passes through and for delivering the charging data to the individual toll chargers. In general, each service provider delivers charging data to several toll chargers and, in general, each toll charger receives charging data from more than one service provider. Interoperability management, as shown in Figure 1, comprises all specifications and activities that define and maintain a set of rules that govern the overall toll charging environment.
0.3 Technical architecture
The technical architecture of Figure 2 is independent of any particular practical realization. It reflects the fact that some processing functionalities can either be allocated to the OBE or to an associated off-board component (proxy). An example of processing functionality that can be realized either on- or off-board is map-matching, where the vehicle locations in terms of measured coordinates from GNSS are associated to geographic objects on a map that either reside on- or off-board. Also, the computation of tariffs can be done with OBE tariff tables and processing, or with an off-board component.
Figure 2—Assumed technical architecture and interfaces
The combined functionality of OBE and proxy is denoted as Front End. A Front End implementation where processing is predominately on the OBE-side is known as a smart client (or intelligent client, fat client) or edge-heavy. A Front End where processing is mostly done off-board is denoted as thin-client or edge-light architecture. Many implementations between the “thin” and “thick” extremes are possible, as depicted by the gradual transition in the wedges in Figure 2. Both extremes of architectural choice have their merits and are one means where manufacturers compete with individual allocations of functionality between on-board and central resources.
Especially for thin client OBE, manufacturers might devise a wide variety of optimizations of the transfer of localization data between OBE and off-board components, where proprietary algorithms are used for data reduction and data compression. Standardization of this transfer is neither fully possible nor beneficial.
0.4 Location of the specification interface
In order to abstract from, and become independent of, these architectural implementation choices, the primary scope of ISO 17575 is the data exchange between Front End and Back End (see the corresponding vertical line in Figure 2). For every toll regime, the Back End will send context data, i.e. a description of the toll regime in terms of charged objects, charging rules and, if required, the tariff scheme to the Front End, and will receive usage data from the Front End.
It has to be noted also that the distribution of tasks and responsibilities between service provider and toll charger will vary individually. Depending on the local legal situation, toll chargers will require “thinner” or “thicker” data, and might or might not leave certain data processing tasks to service providers. Hence, the data definitions in ISO 17575 may be useful on several interfaces.
ISO 17575 also provides for basic media-independent communication services that may be used for communication between Front End and Back End, which might be line-based or an air-link, and can also be used for the air-link between OBE and central communication server.
0.5 The parts of ISO 17575
Part 1: Charging, defines the attributes for the transfer of usage data from the Front End to the Back End. The contents of charge reports might vary between toll regimes, hence, attributes for all requirements are offered, ranging from attributes for raw localization data, for map-matched geographic objects and for completely priced toll transactions. A toll regime comprises a set of rules for charging, including the charged network, the charging principles, the liable vehicles and a definition of the required contents of the charge report.
Part 2: Communication and connection to lower layers, defines basic communication services for data transfer over the OBE air-link or between Front End and Back End. The data defined in ISO 17575-1 and ISO 17575-3 can but need not be exchanged using the communication stack as defined in ISO 17575-2.
Part 3: Context data, defines the data to be used for a description of individual charging systems in terms of charged geographical objects and charging and reporting rules. For every toll charger's system, attributes as defined in ISO 17575-3 are used to transfer data to the Front End in order to instruct it on which data to collect and report.
0.6 Application needs covered by ISO 17575
The ISO 17575 series of standards
- is compliant with the architecture defined in ISO 17573:2010,
- supports charges for use of road sections (including bridges, tunnels, passes, etc.), passage of cordons (entry/exit) and use of infrastructure within an area (distance, time),
- supports fee collection based on units of distance or duration, and based on occurrence of events,
- supports modulation of fees by vehicle category, road category, time of usage and contract type (e.g. exempt vehicles, special tariff vehicles, etc.),
- supports limiting of fees by a defined maximum per period of usage,
- supports fees with different legal status (e.g. public tax, private toll),
- supports differing requirements of different toll chargers, especially in terms of
- geographic domain and context descriptions,
- contents and frequency of charge reports,
- feedback to the driver (e.g. green or red light), and
- provision of additional detailed data on request, e.g. for settling of disputes,
supports overlapping geographic toll domains,
supports adaptations to changes in
- tolled infrastructure,
- tariffs, and
- participating regimes, and
supports the provision of trust guarantees by the service provider to the toll charger for the data originated from the Front End.