ISO/TS 16403-1:2012

Electronic fee collection — Evaluation of equipment for conformity to ISO/TS 17575-4 — Part 1: Test suite structure and test purposes

ISO/TS 16403-1:2011 specifies the test suite structure (TSS) and test purposes (TP) to evaluate the conformity of Front End and Back End to ISO/TS 17575-4.

Perception du télépéage — Évaluation de conformité de l'équipement à l'ISO/TS 17575-4 — Partie 1: Structure de la suite d'essais et objectif d'essai

General Information

• Status: Withdrawn
• Publication Date: 23-Feb-2012
• Withdrawal Date: 23-Feb-2012
• ICS: 03.220.20 - Road transport
• ICS: 35.240.60 - IT applications in transport
• Technical Committee: ISO/TC 204 - Intelligent transport systems
• Drafting Committee: ISO/TC 204/WG 5 - Fee and toll collection
• Current Stage: 9599 - Withdrawal of International Standard
• Completion Date: 19-Jan-2016

Relations

• Consolidates: ISO 9735-7:2002 - Electronic data interchange for administration, commerce and transport (EDIFACT) — Application level syntax rules (Syntax version number: 4, Syntax release number: 1) — Part 7: Security rules for batch EDI (confidentiality)
• Effective Date: 06-Jun-2022

Standards Content (Sample)

TECHNICAL ISO/TS
SPECIFICATION 16403-1
First edition
2012-03-01

Electronic fee collection — Evaluation of
equipment for conformity to
ISO/TS 17575-4 —
Part 1:
Test suite structure and test purposes
Perception du télépéage — Évaluation de conformité de l'équipement à
l'ISO/TS 17575-4 —
Partie 1: Structure de la suite d'essais et objectif d'essai




Reference number
ISO/TS 16403-1:2012(E)
©
ISO 2012

---------------------- Page: 1 ----------------------
ISO/TS 16403-1:2012(E)

COPYRIGHT PROTECTED DOCUMENT


©  ISO 2012
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56  CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published in Switzerland

ii © ISO 2012 – All rights reserved

---------------------- Page: 2 ----------------------
ISO/TS 16403-1:2012(E)
Contents Page
Foreword . iv
Introduction . v
1  Scope . 1
2  Normative references . 1
3  Terms and definitions . 2
4  Abbreviations . 2
5  Test Suite Structure (TSS) . 3
5.1  Structure . 3
5.2  Reference to conformance test specifications . 3
5.3  Test Purposes (TP) . 4
5.3.1  TP definition conventions. 4
5.3.2  TP naming conventions . 5
5.4  Protocol Conformance Test Report (PCTR) . 5
Annex A (normative) Test Purposes for Front End . 6
Annex B (normative) TP for Back End . 24
Annex C (normative) Data Structures . 31
Annex D (informative) PCTR Proforma for Front End . 40
Annex E (informative) PCTR Proforma for Back End . 44
Bibliography . 48

© ISO 2012 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO/TS 16403-1:2012(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
In other circumstances, particularly when there is an urgent market requirement for such documents, a
technical committee may decide to publish other types of document:
— an ISO Publicly Available Specification (ISO/PAS) represents an agreement between technical experts in
an ISO working group and is accepted for publication if it is approved by more than 50 % of the members
of the parent committee casting a vote;
— an ISO Technical Specification (ISO/TS) represents an agreement between the members of a technical
committee and is accepted for publication if it is approved by 2/3 of the members of the committee casting
a vote.
An ISO/PAS or ISO/TS is reviewed after three years in order to decide whether it will be confirmed for a
further three years, revised to become an International Standard, or withdrawn. If the ISO/PAS or ISO/TS is
confirmed, it is reviewed again after a further three years, at which time it must either be transformed into an
International Standard or be withdrawn.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO/TS 16403-1 was prepared by Technical Committee ISO/TC 204, Intelligent transport systems, in
collaboration with Technical Committee CEN/TC 278, Road transport and traffic telematics.
ISO/TS 16403 consists of the following parts, under the general title Electronic fee collection — Evaluation of
equipment for conformity to ISO/TS 17575-4:
— Part 1: Test suite structure and test purposes
— Part 2: Abstract test suite
iv © ISO 2012 – All rights reserved

---------------------- Page: 4 ----------------------
ISO/TS 16403-1:2012(E)
Introduction
This part of ISO/TS 16403 is part of a set of standards that supports interoperability of autonomous EFC-
systems, which includes ISO/TS 17575 that defines the EFC context data, their charge reports and their use
of communication infrastructure.
Within the suite of EFC standards this conformance evaluation procedure defines the process and tests for
conformity evaluation of Front End and Back End that comply with the requirements in ISO/TS 17575-4.
This part of ISO/TS 16403 is intended to
 assess Front End and Back End capabilities,
 assess Front End and Back End behaviour,
 serve as a guide for Front End and Back End conformance evaluation and type approval,
 achieve comparability between the results of the corresponding tests applied in different places at
different times, and
 facilitate communications between parties.
This part of ISO/TS 16403 is based on ISO/TS 17575-4.

© ISO 2012 – All rights reserved v

---------------------- Page: 5 ----------------------
TECHNICAL SPECIFICATION ISO/TS 16403-1:2012(E)

Electronic fee collection — Evaluation of equipment for
conformity to ISO/TS 17575-4 —
Part 1:
Test suite structure and test purposes
1 Scope
This part of ISO/TS 16403 specifies the test suite structure (TSS) and test purposes (TP) to evaluate the
conformity of Front End and Back End to ISO/TS 17575-4.
The objective of the present document is to provide a basis for conformance tests for the Front End and the
Back End in Electronic Fee Collection based on autonomous on-board equipment (OBE) to enable
interoperability between different equipment supplied by different manufacturers.
Autonomous OBE operate without relying on dedicated road-side infrastructure by employing wide-area
technologies such as Global Navigation Satellite Systems (GNSS) and Cellular Communications Networks
(CN). These EFC systems are referred to by a variety of names. Besides the terms autonomous systems and
GNSS/CN systems, also the terms GPS/GSM systems, and wide-area charging systems are in use.
Autonomous systems use satellite positioning, often combined with additional sensor technologies such as
gyroscopes, odometers, and accelerometers, to localise 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 is determined.
Test Purposes applicable for the Back End focus on the output produced by the Back End, i.e. Roaming Rules
data element. Test Purposes related to Front End focus on the main scenarios defined in ISO/TS 17575-4
6.2.4. To verify the Front End behaviour it is needed to observe Charge Reports which are defined in
ISO/TS 17575-1.
The dependencies between Context Data (defined in ISO/TS 17575-3), Charge Report (defined in
ISO/TS 17575-1) and Roaming (defined in ISO/TS 17575-4) to support a particular pricing scheme scenario
are outside of the scope of this part of ISO/TS 16403.
As ISO/TS 17575-4 does not specify any invalid behaviour of Front End and Back End, BI test purposes are
not applicable for any Test Purpose group.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO 14906, Electronic fee collection — Application interface definition for dedicated short-range
communication
ISO 17573, Electronic fee collection — Systems architecture for vehicle-related tolling
© ISO 2012 – All rights reserved 1

---------------------- Page: 6 ----------------------
ISO/TS 16403-1:2012(E)
ISO/TS 17575-1, Electronic fee collection — Application interface definition for autonomous systems —
Part 1: Charging
ISO/TS 17575-3, Electronic fee collection — Application interface definition for autonomous systems —
Part 3: Context data
ISO/TS 17575-4, Electronic fee collection — Application interface definition for autonomous systems —
Part 4: Roaming
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 17573, ISO/TS 17575-1 and the
following apply.
3.1
contract
expression of an agreement between two or more parties concerning the use of the road infrastructure
NOTE A contract specifies obligations, permissions and prohibitions for the objects involved.
[ISO 14906:2011, definition 3.7]
3.2
service provider
operator that accepts the user's payment means and in return provides a road-use service to the user
NOTE Taken from ISO 14906:2004.
3.3
toll charger
legal entity charging toll for vehicles in a toll domain
[ISO/TS 17574:2009, definition 3.27]
4 Abbreviations
For the purposes of this document, the following abbreviations apply, unless otherwise specified.
ADU Application Data Unit
ASN.1 Abstract Syntax Notation One
ATS Abstract Test Suite
BI Invalid Behaviour
BV Valid Behaviour
CCC Compliance Check Communication
CN Cellular Network
DUT Device Under Tests
EFC Electronic Fee Collection
GNSS Global Navigation Satellite Systems
HMI Human Machine Interface
2 © ISO 2012 – All rights reserved

---------------------- Page: 7 ----------------------
ISO/TS 16403-1:2012(E)
ID Identifier
OBE On-Board Equipment
PCTR Protocol Conformance Test Report
PICS Protocol Implementation Conformance Statements
TP Test Purposes
TSS Test Suite Structure
VAT Value Added Tax
5 Test Suite Structure (TSS)
5.1 Structure
Table 1 — Test Suite Structures shows the Test Suite Structure (TSS).
Table 1 — Test Suite Structures
Group Type of DUT Behaviour
General Front End Valid Behaviour
Invalid Behaviour not
applicable
Back End Valid Behaviour
Invalid Behaviour not
applicable
Combined Charge Report Front End Valid Behaviour
Invalid Behaviour not
applicable
Relevant EFC Contexts Front End Valid Behaviour
Invalid Behaviour not
applicable
Data Elements Back End Valid Behaviour
Invalid Behaviour not
applicable

5.2 Reference to conformance test specifications
This document takes into account already defined test purposes for conformance to the base standards by
referencing them, so that:
a) For test purposes that are identical to those defined in this specification or the base standards
conformance test cases direct reference is reported. For reader’s convenience, the title or a verbal
description of the referenced test purpose is given, together with the reference.
© ISO 2012 – All rights reserved 3

---------------------- Page: 8 ----------------------
ISO/TS 16403-1:2012(E)
b) For test purposes that are derived from those defined in the base standards conformance test cases, a
direct reference is reported, plus an indication on how the referred test purpose has to be modified for the
profile conformance testing.
c) For test purposes that are specific to ISO/TS 17575-4, a complete description is given.
d) An indication on whether a test purpose is identical, derived, or specific is given in each test purpose.
5.3 Test Purposes (TP)
5.3.1 TP definition conventions
The TPs are defined following the rules shown in Table 2 — TP Definition Rules below. All Test Purposes are
defined in Annex A and Annex B, including the special notation and symbol conventions that shall be used.
The data structures that shall be used are specified in Annex C and defined in ISO/TS 17575-3 and
ISO/TS 17575-4.
Table 2 — TP Definition Rules
TP ID according to the TP naming Title
conventions Reference
TP origin
Initial condition
Stimulus and expected behaviour

TP ID The TP ID is a unique identifier. It shall be specified according to
the TP naming conventions defined in the sub-clause below.
Title Short description of Test Purpose objective.
Reference The reference should contain the references of the subject to be
validated by the actual TP (specification reference, clause,
paragraph), or the reference to the standard document defining
the TP.
TP origin Indicates if the TP is identical to a TP defined in another test
standard, derived from a TP defined in another test standard, or
specific for this standard profile.
Initial condition The condition defines in which initial state the DUT has to be to
apply the actual TP.
Stimulus and expected
Definition of the events the tester performs, and the events that are
behaviour expected from the
DUT to conform to the base specification.

4 © ISO 2012 – All rights reserved

---------------------- Page: 9 ----------------------
ISO/TS 16403-1:2012(E)
5.3.2 TP naming conventions
Each TP is given a unique identification. This unique identification is built up to contain the following string of
information:
TP///-
TP  : to indicate that it is a Test Purpose;
: which group TP belongs to;
 : type of DUT (i.e. FE or BE);
X  : type of testing (i.e. Valid Behaviour tests – BV, or Invalid Behaviour tests – BI);
 : sequential TP number (01-99).
The naming conventions are as described in Table 3.
Table 3 — TP naming convention
Identifier:
TP///-

applicable for FE and BE
GEN General
applicable for FE
CCR Combined Charge Report
applicable for FE
REC Relevant EFC Contexts
applicable for BE
DAT Data elements


= type of DUT FE Front End
 BE Back End
x = Type of testing BV Valid Behaviour Tests
 BI Invalid Behaviour Tests
= sequential (01-99) Test Purpose Number
number

5.4 Protocol Conformance Test Report (PCTR)
The supplier of the Front End and Back End, respectively, is responsible for providing a Protocol
Conformance Test Report (PCTR).
The supplier of the Front End and the Back End shall complete a PCTR; see Annex D and Annex E for the
proformas.

© ISO 2012 – All rights reserved 5

---------------------- Page: 10 ----------------------
ISO/TS 16403-1:2012(E)
Annex A
(normative)

Test Purposes for Front End
A.1 Introduction
This annex contains the Test Purposes (TP) for the conformity evaluation of Front End to ISO/TS 17575-4.
A.1.1 TP symbols conventions
A special notation and symbol convention is used, as defined in what follows.
Symbols are used in the description of the TPs, with meanings according to Table A.1 below.
Table A.1 — Description of TP Symbols
SYMBOL DESCRIPTION
XXX.rq ⇒ The Tester sends the XXX.rq to the DUT
The Tester sends the XXX.rq to DUT with argument arg1
XXX.rq(arg1=value1) ⇒
equal to value value1.
roamingRules = The Tester sends RoamingRuleX data element defined in
Annex C to the DUT
RoamingRulesX ⇒
⇐ YYY.rs It is expected DUT sends the YYY.rs to the Tester
⇐ YYY.rs (arg1=value1) It is expected DUT sends the YYY.rs to the Tester. Received
value of argument arg1 shall be stored by the tester as
value1.
A ≡ B A “is equal to” B
A → B A “is transformed” into B
Ø Means “empty” or “not set”.
A != B A is not equal B

A.2 General Test Purposes
These Test Purposes apply to requesting update of RoamingRules when recognizing the event requiring new
roaming data as claimed in ISO/TS 17575-4 clause B.5.4 Table B.3/1.
A.2.1 BV test purposes
Test subgroup objective:
 to test the behaviour of the DUT in relation to requesting roaming rule update
by means of the syntactically and contextual correct ADU consisting of RoamingRules and
ChargeReportResponse ADU.
6 © ISO 2012 – All rights reserved

---------------------- Page: 11 ----------------------
ISO/TS 16403-1:2012(E)
TP/GEN/FE/BV/01 Verify whether Front End requests an update of the roaming rule
attribute
TP Origin Specific
Reference ISO/TS 17575-4, Clause 7.1
Initial Condition Front End is initialized and can accept Context Data (including Roaming
Rules).
Front has already received the following context data:
 for EFC Context #1::
 11'D – TollContextOverview
 tollContext.countryCode = countryCode1
 tollContext.providerIdentifier = 1
 tollCharger.countryCode = countryCode1
 tollCharger.providerIdentifier = 1000
 21'D – TariffTable
 22'D – TariffClassDefinition
 23'D - LocalVehicleClassDefinition
 24'D - TimeClassDefinition
 25'D - UserClassDefinition
 31'D - TollContextLayout
 41'D – ChargeReportingEvents
 42'D - ChargeReportConfiguration (regimeId of usageStatement
is enabled)
OBU belonging to the Front End is located within geographic area of EFC
Context #1.
No authentication is required by the Front End.
Stimulus and Expected Behaviour
Tester DUT
1 Iso17575-3Adu = {aduHeader, ⇒
roamingRules = RoamingRules6}

2
At least one UsageStatement can be reported by
Front End for EFC Context #1 AND event defined
in 41’D – ChargeReportingEvents of EFC Context
#1 occurred.
3 ⇐ ChargeReport = { obeId, vehicleLPNr, paymentMeans,
serviceProviderContract, tol ha ger, timeOfReport,
reportPeriod, versionInfo, usageStatementList,
vatForThisSession, accountStatus, transactionCounter,
mileage, listOfCCCAttributes, authenticator}
4 IF  ChargeReport not received
THEN TP failed
ENDIF
5 ChargeReportResponse = { reportRecipientId = any, ⇒
dataReceived = (ChargeReport.timeOfReport |

ChargeReport.mileage |
ChargeReport.transactionCounter) ,
versionsResponse = verResp1, obeStatusForDriver
= 0, accountUpdate = ø, responseAuthenticator = ø}
NOTE verResp1 indicates that new roaming
rules are available. ISO/TS 17575-4 does not specify
versionsResponse syntax.
© ISO 2012 – All rights reserved 7

---------------------- Page: 12 ----------------------
ISO/TS 16403-1:2012(E)

⇐ DUT requests an update of roaming rules attribute as
defined in ISO/TS 17575-4.
6 IF request received
THEN TP passed
ELSE TP failed
ENDIF

A.2.2 BI test purposes
No BI test purposes are applicable for this TP group.
A.3 Relevant EFC Context Test Purposes
These Test Purposes apply to relevant EFC Contexts as claimed in ISO/TS 17575-4 Clause B.5.4
Table B.5/2, reuse of tariff information as claimed in ISO/TS 17575-4 Clause B.5.4 Table B.6/2, reuse of
reporting rules as claimed in ISO/TS 17575-4 Clause B.5.4 Table B.6/3, precedence level as claimed in
ISO/TS 17575-4 Clause B.5.4 Table B.6/6, and sending charge report if entering EFC context as claimed in
ISO/TS 17575-4 Clause B.5.4 Table B.6/7.
A.3.1 BV test purposes
Test subgroup objective:
 to test the behaviour of the DUT in relation to roaming rule update;
 to test the behaviour of the DUT in relation to ignoring not listed EFC Contexts;
 to test the behaviour of the DUT in relation to re-use of tariff class and reporting rules from another EFC
Context;
 to test the behaviour of the DUT in relation to precedence level handling;
 to test the behaviour of the DUT in relation to sending charge report when entering particular EFC
Context
by means of the syntactically and contextual correct ADU consisting of RoamingRules.

8 © ISO 2012 – All rights reserved

---------------------- Page: 13 ----------------------
ISO/TS 16403-1:2012(E)
TP/REC/FE/BV/01 Roaming Rules update
TP Origin Specific
Reference ISO/TS 17575-4, Clause 6.2.2.1
Initial Condition Front End is initialized and can accept Context Data (including Roaming
Rules).
Front has already received the following context data:
 for EFC Context #1:
 11'D – TollContextOverview
 tollContext.countryCode = countryCode1
 tollContext.providerIdentifier = 1
 21'D – TariffTable
 22'D – TariffClassDefinition
 23'D - LocalVehicleClassDefinition
 24'D - TimeClassDefinition
 25'D - UserClassDefinition
 31'D - TollContextLayout
 41'D - ChargeReportingEvents (different than in EFC Context
#2)
 42'D - ChargeReportConfiguration (different than in EFC
Context #2, but regimeId of usageStatement is enabled).
 for EFC Context #2::
 11'D – TollContextOverview
 tollContext.countryCode = countryCode1
 tollContext.providerIdentifier = 2
 21'D – TariffTable
 22'D – TariffClassDefinition
 23'D - LocalVehicleClassDefinition
 24'D - TimeClassDefinition
 25'D - UserClassDefinition
 31'D - TollContextLayout
 41'D - ChargeReportingEvents (different than in EFC Context
#1)
 42'D - ChargeReportConfiguration (different than in EFC
Context #1, but regimeId of usageStatement is enabled).
 for EFC Context #3:
 11'D – TollContextOverview
 tollContext.countryCode = countryCode1
 tollContext.providerIdentifier = 3
 31'D - TollContextLayout
OBU belonging to the Front End is located within geographic borders of EFC
Context #3.
Geographic area of EFC Context #1, #2 and #3 do not overlap.
No authentication is required by the Front End.
Stimulus and Expected Behaviour
Tester DUT
1 Iso17575-3Adu = {aduHeader, ⇒
roamingRules = — RoamingRules1 }

2
At least one UsageStatement can be reported by
Front End and Event defined in 41’D –
ChargeReportingEvents of EFC Context #1
© ISO 2012 – All rights reserved 9

---------------------- Page: 14 ----------------------
ISO/TS 16403-1:2012(E)
occurred
3
⇐ ChargeReport = { obeId, vehicleLPNr, paymentMeans,
serviceProviderContract, tollCharger, timeOfReport,
reportPeriod, versionInfo, usag  tementList,
vatForThisSession, accountStatus, transactionCounter,
mileage, listOfCCCAttributes, authenticator}
4
Verify whether ChargeReport data elements
corresponds to 42'D –
ChargeReportConfiguration of EFC Context #1
AND usage statement list corresponds to EFC
Context #3 (by verifying regimeId value of
usageStatement).
Mapping rules between regimeId in ChargeReport
and contextId in Iso17575-3Adu shall be defined
before running a test purpose.
5
IF verify NOT OK
THEN TP failed
ENDIF
6
Iso17575-3Adu = {aduHeader, ⇒
roamingRules =— RoamingRules2 }

7 At least one UsageStatement can be reported by
Front End and Event defined in 41’D –
ChargeReportingEvents of EFC Co text #2
occurred
8
⇐ ChargeReport = { obeId, vehicleLPNr, paymentMeans,
serviceProviderContract, tollCharger, timeOfReport,
reportPeriod, versionInfo, usageStatementList,
vatForThisSession, accountStatus, transactionCounter,
mileage, listOfCCCAttributes, authe ticator}
9
Verify whether ChargeReport data elements
corresponds to 42'D –
ChargeReportConfiguration of EFC Context #2
AND usage statement list corresponds to EFC
Context #3 (by verifying regimeId value of
usageStatement).
Mapping rules between regimeId in ChargeReport
and contextId in Iso17575-3Adu shall be defined
before running a test purpose.
10
IF verify NOT OK
THEN TP failed
ELSE TP passed
ENDIF

10 © ISO 2012 – All rights reserved

---------------------- Page: 15 ----------------------
ISO/TS 16403-1:2012(E)
TP/REC/FE/BV/02 Verify whether EFC Context not listed in roaming rules is ignored
TP Origin Specific
Reference ISO/TS 17575-4, Clause 6.2.2.1
Initial Condition Front End is initialized and can accept Context Data (including Roaming
Rules).
Front has already received the following context data:
 for EFC Context #1:
 11'D – TollContextOverview
 tollContext.countryCode = countryCode1
 tollContext.providerIdentifier = 1
 21'D – TariffTable
 22'D – TariffClassDefinition
 23'D - LocalVehicleClassDefinition
 24'D - TimeClassDefinition
 25'D - UserClassDefinition
 31'D - TollContextLayout
 41'D - ChargeReportingEvents
 42'D - ChargeReportConfiguration
 for EFC Context #4:
 11'D – TollContextOverview
 tollContext.countryCode = countryCode1
 tollContext.providerIdentifier = 4
 21'D – TariffTable
 22'D – TariffClassDefinition
 23'D - LocalVehicleClassDefinition
 24'D - TimeClassDefinition
 25'D - UserClassDefinition
 31'D - TollContextLayout
 41'D - ChargeReportingEvents
 42'D - ChargeReportConfiguration

OBU belonging to the Front End is located within geographic borders of EFC
Context #4.
Geographic area of EFC Context #1 and #4 do not overlap.
No authentication is required by the Front End.
Stimulus and Expected Behaviour
Tester DUT
1 Iso17575-3Adu = {aduHeader, ⇒
roamingRules = — RoamingRules1 }

2
At least one UsageStatement can be reported by
Front End and Event defined in 41’D –
ChargeReportingEvents of EFC Context #4
occurred
3 ⇐ ChargeReport = { obeId, vehicleLPNr, paymentMeans,
serviceProviderContract, tollCharger, timeOfReport,
reportPeriod, versionI fo, usageStatementList,
vatForThisSession, accountStatus, transactionCounter,
mileage, listOfCCCAttributes, authenticator}
© ISO 2012 – All rights reserved 11

---------------------- Page: 16 ----------------------
ISO/TS 16403-1:2012(E)
4
IF ChargeReport received
THEN TP failed
ELSE TP passed
ENDIF


12 © ISO 2012 – All rights reserved

---------------------- Page: 17 ----------------------
ISO/TS 16403-1:2012(E)
TP/REC/FE/BV/03 Verify whether Tariff Classes are re-used
TP Origin Specific
Reference ISO/TS 17575-4, Clause 6.2.2.4
Initial Condition Front End is initialized and can accept Context Data (including Roaming
Rules).
Front has already received the following context data:
 for EFC Context #1:
 11'D – TollContextOverview
 tollContext.countryCode = countryCode1
 tollContext.providerIdentifier = 1
 21'D – TariffTable
 22'D – TariffClassDefinition
 23'D - LocalVehicleClassDefinition
 24'D - TimeClassDefinition
 25'D - UserClassDefinition
 31'D - TollContextLayout
 41'D - ChargeReportingEvents
 42'D – ChargeReportConfiguration ( regimeId of
usageStatement and tariffClass of
AggregatedSingleTariffClassSessionContent,
DetectedChargeObjectContent and
ListOfRawUsageDataContent is enabled)
 for EFC Context #3:
 11'D – TollContextOverview
 tollContext.countryCode = countryCode1
 tollContext.providerIdentifier = 3
 31'D - TollContextLayout
OBU belonging to the Front End is located within geographic borders of EFC
Context #3.
Geographic area of EFC Context #1 and #3 do not overlap.
No authentication is required by the Front End.
Stimulus and Expected Behaviour
Tester DUT
1 Iso17575-3Adu = {aduHeader, ⇒
roamingRules = — RoamingRules1 }

2
At least one UsageStatement can be reported by
Front End and Event defined in 41’D –
ChargeReportingEvents of EFC Context #1
occurred
3 ⇐ ChargeReport = { obeId, vehicleLPNr, paymentMeans,
serviceProviderContract, tollCharger, timeOfReport,
reportPeriod, versionInfo, usageStatementList,
vatForThisSession, accountStatus, transactionCounter,
mileage, listOfCCCAttributes, authenticator}
4 IF (each tariffClass data element is composed of
locationClassId, timeClassId, userClassId which
are defined in context data of EFC Context #1
(attributes 22'D, 23'D, 24'D and 25'D))
THEN TP passed
ELSE TP failed
ENDIF
© ISO 2012 – All rights reserved 13
...