Tiêu chuẩn iso ts 17575 4 2014

maquette MOTS401E Reference number ISO/TS 17575 4 2011(E) © ISO 2011 TECHNICAL SPECIFICATION ISO/TS 17575 4 First edition 2014 04 Electronic fee collection — Application interface definition for auton[.]

General

EFC Front Ends necessitate specific data elements that outline the characteristics of the EFC regime in use, as defined by ISO/TS 17575-3 This framework enables the customization of the Front End to meet the requirements of local Toll Chargers, including the identification or measurement of toll-related objects Additionally, it involves the assembly of elements to generate and send accurate charge reports to the Back End In cases of single context EFC regimes, only one set of EFC context data may be required, potentially eliminating the need to adhere to roaming regulations.

Single EFC context Front Ends can operate without roaming rules, but they cannot be upgraded to manage multiple EFC contexts unless roaming functionality is added.

Copyright International Organization for Standardization

Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=sharabiani, shahramfs

No reproduction or networking permitted without license from IHS

In intricate EFC clusters, the complete framework can include multiple EFC domains, with each domain potentially comprising several EFC regimes Additionally, an EFC regime may implement one or more fundamental tolling principles, each defined within its own specific set of EFC context data.

This framework enables the establishment of an interoperable cluster of Electronic Fee Collection (EFC) regimes, allowing each regime to independently define its own rules Each EFC regime can specify its unique properties by utilizing one or more sets of context data, as outlined in ISO/TS 17575-3.

Such a composition of an EFC cluster may not be stable over time allowing new EFC regimes or contexts joining this cluster and/or others may terminate their operation

Front Ends must adjust their behavior based on intricate definitions, utilizing multiple sets of context data alongside a unified set of roaming rules.

The roaming rules outlined in ISO/TS 17575 specify essential data elements for Front Ends operating within an EFC cluster that encompasses multiple sets of EFC context data This requirement mandates the use of both mandatory and, when available, optional data elements as detailed in clauses 6.2.2.8 and 6.2.3.

To optimize the computational load of Front Ends, it is essential to focus their operations on EFC domains where vehicles are present or nearby This strategy enables the EFC application software for specific known EFC domains to enter a "dormant" state, conserving computing power, memory space, and external communication bandwidth Additionally, the roaming rules data elements incorporate optional data elements designed specifically for this optimization purpose.

The roaming rules, as defined in ISO/TS 17575, are established by each Toll Charger to address their specific requirements It is essential for different Toll Chargers, operating interdependent Electronic Fee Collection (EFC) schemes, to ensure that their expectations regarding the overall Front End behavior are aligned.

Roaming rules are included in the EFC context data sent by Toll Chargers to Toll Service Providers These providers can streamline and consolidate these rules into a unified set of roaming regulations applicable to all Front Ends within the interoperable EFC cluster The format of these comprehensive roaming rules aligns with that of complex EFC regimes, making them relevant for individual Toll Chargers as well.

Overview

Roaming rules and parameters govern the interactions between various Electronic Fee Collection (EFC) schemes These rules allow for scenarios where EFC domains can be adjacent, enabling a Front-End to utilize roaming data when transitioning to a neighboring EFC domain Initially, the system verifies the vehicle's toll liability based on its class and the current time If the vehicle is liable for tolls, roaming data activates a process to ensure all relevant EFC context data is accessible, initiating the creation of a new charge report The subsequent data download is contingent on the Front-End's memory structure and size, occurring only when a new EFC regime is introduced, when entering for the first time, or after an extended period of using a previous roaming data version.

To effectively manage toll payments, it is essential to identify the geographic boundaries of the adjacent EFC domain, its unique identifier, and the minimum vehicle class subject to toll fees In cases where EFC domains overlap, the aforementioned criteria remain applicable Additionally, in overlapping domains, it may be necessary to establish a secure environment in the Front End to facilitate the simultaneous assembly of multiple charge reports.

Overlapping EFC regimes can exhibit dependencies in the definition of charge objects, particularly in scenarios where larger outer areas are not charged when they fall within smaller inner areas.

The inner area may implement its own tariff scheme, and users may not incur charges when traveling on a sectioned toll road within the same area, which could either have fees or be free of charge.

When entering an inner area where the outer area's charge report assembly is paused, it can be specified whether to forward the assembled charge report to the Back End Small inner domains, such as ferries operated by different Toll Chargers, do not disrupt the outer area's charge report assembly Conversely, if the inner area is an urban region, the vehicle may remain longer, making it reasonable to finalize the outer area's charge report and send it to the Back End.

To adapt a Front End to regulatory requirements, it is essential to establish a precedence level for each participating EFC context, ensuring that only those with the highest precedence apply the charge Additionally, if an EFC domain with a higher precedence level is entered, the corresponding EFC account must be closed, and a charge report sent Complex EFC regimes can define an overall tariff scheme using multiple overlapping or non-overlapping basic EFC contexts, which may encompass various areas such as a country, urban regions, or specific city districts Furthermore, a sectioned toll road network with a distinct tariff scheme may be managed by a single Toll Charger, integrating these diverse contexts into a cohesive system.

The Toll Charger may necessitate the receipt of a comprehensive charge report that encompasses all relevant details Additionally, it can facilitate the user by providing a single bill that covers toll usage across an entire region or country.

Note: this may be used not to bother the User with details on how the regime is split into different contexts

To configure the charge report effectively, it is essential to have a consolidated list of EFC contexts that pertains to a single Toll Charger Additionally, stringent privacy regulations may necessitate that in complex EFC regimes with multiple overlapping domains, vehicle presence should remain undisclosed in charge reports This can be achieved by aggregating and concealing all charge objects while still revealing the regime identifier.

In certain situations, it may be necessary to conceal the presence of a vehicle in a specific area In these instances, a single aggregated fee can encompass multiple Electronic Fee Collection (EFC) regimes, provided that the same Toll Charger manages the operation, ensuring that the fee recipient remains consistent.

General

The "roaming" data set features a single attribute called RoamingRules, which is essential for a Front End to function under the specific conditions of a user This requirement remains constant regardless of the complexity of the interoperable EFC cluster that the Front End is supporting.

Without presumption of any implementation it is anticipated that the data elements of the roaming rules are used in a Front End ensuring:

⎯ that each relevant EFC context is recognised as such and charging reports are assembled when the vehicle is moving inside the domain

For each relevant EFC context, the corresponding EFC context data set is accessible in the Front End This access must be guaranteed, particularly when the vehicle is within or just outside the EFC domain.

⎯ that the information required handling interdependencies between EFC contexts regarding tariff exclusivenesses are respected in the process evaluating the tariff due

The information required to do so are the information provided by the RoamingRules attribute

In contrast to roaming rules, all data elements necessary for the Front End to evaluate a single EFC context are supplied by the EFC context data attributes as outlined in ISO/TS 17575-3.

Elements of the roaming rules attribute

The roaming rule identifier

In the Back End, multiple roaming rules data sets will be created and managed to accommodate version control and various combinations of interoperable EFC contexts for different users Each individual set of roaming rules will be identified by a unique identifier, efcRoamingRulesId, which is of type Int2 and must remain unique within the Back End domain.

The list of relevant EFC contexts

The roaming attribute's key aspect is the list of relevant EFC contexts that define the EFC cluster's composition for Front End operation, ensuring interoperability This list can evolve over time based on user registrations for various EFC contexts, the introduction of new EFC regimes, or the termination of existing ones The necessary information for the Front End is supplied through the relevantEfcContexts data element, which contains a list of RelevantEfcContext Any EFC contexts not included in this list will be unknown to the Front End and subsequently disregarded.

This section of ISO/TS 17575 does not address the need for proxies operating for multiple OBEs to implement the correct roaming rules This is particularly crucial when Service Providers offer interoperability across various EFC context combinations.

6.2.2.2 Sub elements of the RelevantEfcContext element

The RelevantEfcContext data element includes sub data elements that enable Front Ends to effectively manage the download of context data attributes from the Back End and streamline internal operations.

The efcContextId shall be used to identify the EFC context This identifier shall correspond with the identifier used in the EFC context data as defined in ISO/TS 17575-3

As described above a Front End should optimise its external communication effort Supporting this the

RelevantEfcContext data contains elements allowing to indicate that another EFC context applies identical tariffs and that downloading a copy of the tariff information attribute is redundant

When multiple EFC contexts utilize the same definition of tariff information, it is more efficient to forward and store this data attribute only once Subsequently, other EFC contexts can simply reference this stored information, indicating its reuse.

A Front End may use the list reuseTariffInformationFrom to organize this

The reporting rules can be consistent across various EFC contexts, as outlined in section 6.2.2 To streamline processes, the reuseReportingRulesFrom list can be utilized, preventing the need to download and store multiple copies of the same reporting rules, in accordance with ISO/TS 17575-3.

The efcDomainFrame element features a BoundingPolygon that outlines the outer edge of an EFC context The specifications for this bounding polygon, including distance and resolution, are determined by the Front End's requirements It is essential that the distance, based on a specific vehicle speed, enables preparation for the Front End's behavior as it approaches the next EFC domain, even before reaching its actual border.

The BoundingPolygon is defined as a sequence of points, each represented by a Latitude and Longitude It is understood that these points are connected by a line in the order they appear, with the final point linking back to the initial one.

The Front End of a vehicle must activate its preparation to participate in accordance with local EFC regime rules when it enters the efcDomainFrame This activation should be completed upon reaching the actual EFC domain border, as specified in ISO/TS 17575-3.

NOTE 1 The term “liable vehicle class” should be read as a vehicle class causing the driver being liable paying toll if he's using a vehicle belonging to it

The sub-element specifies vehicle groups as outlined in the VehicleClass attribute of EN 15509 If the exact definitions of liable vehicle classes cannot be captured by these groups, broader categories must be utilized to encompass all applicable classes Additionally, the EFC context data in ISO/TS 17575-3 provides a more detailed definition of vehicle classes, which will be utilized by the Front End when declaring toll road usage.

NOTE 2 This may result in indicating a certain vehicle as “liable” for tolling in the roaming data set and “not liable” in the EFC context data The definition of the EFC context data finally will be applied

When multiple overlapping EFC domains rely on each other for declaring toll-relevant events, their individual precedence levels can be utilized for effective management.

A declared toll object in a higher precedence level EFC domain will block the declaration of the same type or amount of toll object in any overlapping EFC domain with a lower precedence level.

If both precedence levels are same, then both toll objects shall be declared or forwarded

Note: An example for this may be an area tolling context which is crossed by an arterial road which is defined as being

When dealing with toll roads, it is essential to establish distinct EFC contexts for both the area and the sectioned toll road If the sectioned toll road context holds a higher precedence, the usage statement for the area context should disregard the distance of the sectioned toll road In cases of a time-based tariff scheme, the presence in the area should also be temporarily overlooked while on the sectioned toll road.

The term "close account" refers to the process of terminating the collection of usage data for a specific EFC context, which leads to the submission of the compiled usage data in a charge report to the Back End.

This sub element may be applied in overlapping EFC domains where the probability of staying longer inside the domain with a higher precedence level is quite high

The charge report created for the previous EFC context will be finalized upon entering any of the domains specified in sendChargeReportIfEntering that have a higher precedence level.

The list of EFC contexts which are grouped using a single charge report

The data element combinedChargeReportContexts provides a list of one or more

The CombinedChargeReportContext mandates that a single charge report be issued to a tollRecipient, detailing the usage statements associated with the specified EFC contexts These contexts are included in the relevantEfcContexts and are further identified within the appropriate EFC context by the efcContextId element.

In order to identify different clusters the element reportingClusterId is provided It shall be unique within the entire EFC cluster the Back End is managing

Because the Charge reports generated for different EFC contexts will be forwarded to a single recipient the tollRecipient data element shall be used identifying it.

House keeping data elements

Each roaming rule data set contains a roamingRuleVersion in the format of VersionAndValidity and an authenticator in the format of MessageAuthenticator both as defined in ISO/TS 17575-3

Attribute/Element Scenario Remark efcRoamingRulesId Data type Int2 roamingRulesVersion date and time when validity period of this set of roaming data starts authenticator

General authenticator of the full set of roaming data attribute signed by the originator of the content relevantEfcContexts List of adjoining EFC domains

RelevantEfcContext list efcContextId entity identifier according to

The ISO 14906 standard outlines the reuse of tariff information and reporting data within the EFC domain frame, specifically focusing on the bounding polygon It includes a list of vehicle classes that are liable for tolls, as defined by EN 15509, and specifies a precedence level to identify the priority of charges when multiple contexts are involved Additionally, it addresses the requirement to send a charge report upon vehicle entry.

The EFC contexts relevant to the Front End include a list of contexts that, when entered, trigger a charge event from the previous context Additionally, the combinedChargeReportContexts consist of overlapping EFC contexts that necessitate a unified charge report.

CombinedChargeReportContext list reportingClusterId entity identifier according to

ISO 14906 tollRecipient entity identifier according to

ISO 14906 involvedEfcContexts multi EFC context schemes using a common charge report list of entity identifiers according to ISO 14906

7 Communicating the roaming rules attribute

Requesting an update of the roaming rules attribute

In response of any charge report forwarded by the Front End to the Back End the Back End may include a

VersionID as defined in ISO/TS 17575-1 This data element indicates the availability of a new version which shall be used according to the validity period included in this new version

The Front End shall take this information requesting an update of the roaming rules attribute The request forwarded to the Back End shall be according to ISO/TS 17575-2

The Back End will assess the relevance of the requested roaming rule attribute version for the Front End and may provide a response with the updated version.

Responding to a roaming rules download request

In the view of this part of ISO/TS 17575, the roaming rules attribute constitute the ADU body as defined in 7.1 of ISO/TS 17575-3:2011

To communicate the ADU body it must be completed adding the ADU header as defined in 7.2 of ISO/TS 17575-3:2011 Forwarding this ADU shall be according to ISO/TS 17575-2.

ASN1 coding rules

The EFC data types and their corresponding coding, as outlined in Clause 6, are defined using Abstract Syntax Notation One (ASN.1) in accordance with ISO/IEC 8824-1 Additionally, the packed encoding rules specified in ISO/IEC 8825-2 will be implemented.

Data elements at lower levels contribute to those at higher levels, illustrating a hierarchical structure where, for instance, level 3 data elements are included within the data elements of levels 1 and 2, as depicted in Figure A.1.

-efcContextId -reuseTariffInformationFrom -reuseReportingRulesFrom -efcDomainBorder -liableVehicleClasses -precedenceLevel -closeChargeAccountIfEntering

Figure A.1 — Hierarchy of data elements (informative)

RoamingModule {iso standard 175754 modules(0) efc(0) version(1)}

FROM EfcModule {iso standard 14906 modules(0) efc(0) version(1)}

MessageAuthenticator, EquipmentOBUId, Duration, Distance, VersionID

FROM ChargingModule {iso standard 17575 modules(0) efc(0) version(1)}

FROM ContextDataModule {iso standard 175753 modules(0) efc(0) version(1)}

FROM CccModule {iso standard 12813 modules(0) ccc(0) version(1)};

RoamingRules ::= SEQUENCE { efcRoamingRulesId INT2, relevantEfcContexs SEQUENCE OF RelevantEfcContext, combinedChargeReportContexts SEQUENCE OF CombinedChargeReportContext OPTIONAL, roamingRulesVersion VersionAndValidity, authenticator MessageAuthenticator

The RelevantEfcContext is a structured sequence that includes an efcContextId, optional references for reuse of tariff information and reporting rules, and an optional bounding polygon for the efcDomainFrame It also specifies the liable vehicle classes as a sequence of VehicleGroup, includes an optional precedence level, and allows for sending charge reports upon entry, with the relevant entities listed as a sequence of EntityId.

CombinedChargeReportContext ::= SEQUENCE { reportingClusterId EntityId, tollRecipient EntityId, involvedEfcContexts SEQUENCE OF EntityId

The BoundingPolygon is defined as a sequence where edges connect consecutively listed vertices, with the final edge linking the last vertex back to the first The area is situated to the right of the line drawn from one vertex to the next, specified by latitude and longitude coordinates.

VehicleGroup ::= INT1 vehicle group as defined in EN 15509:2007, Annex A, Table A2

This clause contains the Protocol Implementation Conformance Statements (PICS) proforma to be used for Front End implementation of the charge report protocol defined in clause 6 and Annex A

To assess the compliance of a specific implementation, an Implementation Conformance Statement (ICS) is required, detailing the capabilities and options that have been implemented When the statement pertains to transactions, it is referred to as a Protocol Implementation Conformance Statement (PICS) This annex includes PICS templates for equipment suppliers to complete.

The PICS proforma serves as a standardized tool for suppliers to convey information regarding their implementation of the requirements outlined in ISO/TS 17575.

The PICS proforma is subdivided into clauses for the following categories of information:

B.4 Instruction for completing the PICS Proforma

A capability is said to be supported if the Implementation Under Test (IUT) is able:

- to generate the corresponding operation parameters (either automatically or because the end user requires that capability explicitly);

- to interpret, handle and when required make available to the end user the corresponding error or result

A protocol element is considered supported by a sending implementation if it can generate the element under certain conditions, either automatically or at the explicit request of the end user for specific services.

A protocol element is said to be supported for a receiving implementation if it is correctly interpreted and handled and also, when appropriate, made available to the end user

This column specifies the support level necessary for compliance with the ISO/IEC standard The designations are as follows: "m" indicates mandatory support is required, while "o" signifies that optional support is allowed, provided it adheres to the standard's specifications and restrictions, which may influence the optionality of other items Additionally, "c" denotes that support for the capability is conditional, meaning it depends on a specific predicate; if the predicate is true, the item becomes mandatory ("c: m"), but it is optional otherwise.

- the item is not applicable; i the item is outside the scope of this PICS

In the PICS proforma tables, every leading item marked 'm' shall be supported by the IUT Sub-items marked

'm' shall be supported if the corresponding leading item is supported by the IUT

This column shall be completed by the supplier or implementor to indicate the level of implementation of each item The proforma has designed such that values required are:

Y yes, the item has been implemented;

N no, the item has not been implemented;

- the item is not applicable;

All entries in the PICS proforma must be made in ink Any changes should be made by crossing out the original entry without erasing it, and the new entry should be written next to it Additionally, all alterations must be initialed by the staff member who made them.

The PICS proforma features numbered lines on the left edge, which serve to uniquely identify all implementation details This numbering facilitates easy referencing both within the PICS proforma itself and in relation to other test specification documents.

The means of referencing individual responses is done by the following sequence:

⎯ a reference to the smallest enclosing the relevant item;

⎯ the reference number of the row in which the response appears;

If more than one response is present in the row indicated by the reference number, each possible entry is labeled sequentially as a, b, c, and so on, from left to right, with the corresponding letter added to the sequence.

B.5 PICS proforma for the Front End

1 Date of Statement (DD/MM/YY)

3 System Conformance Statement Cross Reference

B.5.1.2 Identification of the implementation and/or system

1 Service provider or EFC context name

B.5.1.3 Identification of the Front End supplier

B.5.1.4 Identification of the Front End

5 Serial Numbers of supplied units

1 Title, Reference No, publication date of the

5 Implementation Defect Reports (Ref No)

Are all mandatory capabilities implemented? (Yes/No) ………

Answering "No" to this question signifies a lack of compliance with the specification Any mandatory capabilities that are not supported must be detailed in the ICS, along with an explanation for the non-conformance, on the pages attached to the ICS proforma.

Which security level is implemented (0/1) ………

NOTE 2 See 5.1.5 and Annex D for definition of the of security levels

This part of the PICS proforma identifies the supported application context, the communication services and attributes (ADUs)

Item No Element Reference Status Support

1 requesting update when recognising the event requiring new roaming data 7.1 m

2 Initialization of the communication channel 7.1 and

5 receiving structured Messages ISO/TS m

6 interpreting ADU header ISO/TS

1 ISO/TS 17575-2 access ISO/TS

Table B.4 — Level 1 data elements supported

Item No Element Reference Status Support authentication Support coding

The following table can be used to provide any other relevant information:

Important information regarding the Front End relevant for testing includes additional features such as various communication media and proprietary attributes intended for local use.

B.6 PICS proforma for the Back End

1 Date of Statement (DD/MM/YY)

B.6.1.2 Identification of the implementation and/or system

1 Service provider or EFC context name

B.6.1.3 Identification of the Back End supplier

B.6.1.4 Identification of the Back End

4 Serial Numbers of supplied units

1 Title, Reference No, publication date of the Technical Specification