CEN/TS 16331:2012

SLOVENSKI STANDARD
01-maj-2012
Elektronsko pobiranje pristojbin - Interoperabilni profili aplikacije za avtonomne
sisteme
Electronic fee collection - Interoperable application profiles for autonomous systems
Elektronische Gebührenerhebung - Interoperable Anwendungsprofile für unabhängige
Systeme
Perception du télépéage - Profil d'application d'interopérabilité pour les systèmes
autonomes
Ta slovenski standard je istoveten z: CEN/TS 16331:2012
ICS:
03.220.20 Cestni transport Road transport
35.240.60 Uporabniške rešitve IT v IT applications in transport
transportu in trgovini and trade
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

TECHNICAL SPECIFICATION
CEN/TS 16331
SPÉCIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION
March 2012
ICS 03.220.20; 35.240.60
English Version
Electronic fee collection - Interoperable application profiles for
autonomous systems
Perception du télépéage - Profil d'application Elektronische Gebührenerhebung - Interoperable
d'interopérabilité pour les systèmes autonomes Anwendungsprofile für unabhängige Systeme
This Technical Specification (CEN/TS) was approved by CEN on 8 January 2012 for provisional application.

The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to submit their
comments, particularly on the question whether the CEN/TS can be converted into a European Standard.

CEN members are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS available
promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in parallel to the CEN/TS)
until the final decision about the possible conversion of the CEN/TS into an EN is reached.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland,
Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom.

EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2012 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 16331:2012: E
worldwide for CEN national Members.

Contents Page
Foreword .5
Introduction .6
1 Scope .8
2 Normative references .9
3 Terms and definitions . 10
4 Abbreviations . 11
5 General profile independent IAP requirements . 12
5.1 The principle defining EFC cluster supported regime characteristics using profiles . 12
5.2 Toll Charger requirements . 12
5.2.1 General . 12
5.2.2 Toll Charge Back End requirements . 13
5.3 Toll Charger RSE requirements . 13
5.4 Service Provider requirements . 13
5.4.1 General . 13
5.4.2 Service Provider Back End Requirements . 14
5.4.3 Front End specific requirements . 14
6 The use of conditional requirements . 16
7 Standardised profiles . 16
7.1 General . 16
7.2 How to use standardised profiles . 21
7.2.1 General . 21
7.2.2 SR (Sectioned Roads tolling) . 21
7.2.3 SD (Sectioned Roads tolling or Distance based Area pricing) . 21
7.2.4 OSD (Overlapping Sectioned Roads tolling or Distance based Area pricing) . 22
7.2.5 OSDT (Overlapping Sectioned Roads tolling or Distance or Time based Area pricing) . 22
7.2.6 OSDTC (Overlapping Sectioned Roads tolling or Distance or Time based Area or Cordon
pricing) . 22
7.3 Front End classes selection . 22
Annex A (normative) Conditional profile requirements . 23
A.1 General . 23
A.2 Conditional requirements to be observed by the Toll Charger . 23
A.2.1 When using contextInterrelations . 23
A.2.2 When using roadSectionPricing . 23
A.2.3 When using arePricingDistance . 23
A.2.4 When using roadNetworks . 23
A.2.5 When using arePricingTime . 23
A.2.6 When using cordonPricing . 23
A.2.7 When using agnssGDFLayout or tollContextLayout . 24
A.2.8 When using tariffTable . 24
A.2.9 When using tariffClassDefinition . 24
A.2.10 When using localVehicleClassDefinition . 24
A.2.11 When using timeClassDefinition . 24
A.2.12 When using relativeTimePeriods . 24
A.2.13 When using classesSetExternally. 25
A.2.14 When using userClassdefinition . 25
A.2.15 When using actualNumberOfPassengers . 25
A.2.16 When using SectionLayout . 25
A.2.17 When using AreaLayout . 25
A.2.18 When using roadNetwork . 25
A.2.19 When using chargeReportingEvents . 25
A.2.20 When using chargeReportConfiguration . 25
A.3 Conditional requirements to be observed by the Service Provider . 27
A.3.1 When using tollDeclarationADU . 27
A.3.2 When using combinedChargeReportContexts. 28
A.3.3 When using precedenceLevel . 28
A.3.4 When using roadSectionPricing . 28
A.3.5 When using areaPricingDistance . 29
A.3.6 When using areaPricingDistance.roadNetworks . 29
A.3.7 When using areaPricingTime . 29
A.3.8 When using cordonPricing . 29
A.3.9 When using tariffTable . 29
A.3.10 When using tariffClassDefinition . 29
A.3.11 When using localVehiceClasses . 29
A.3.12 When using timeClasses . 29
A.3.13 When using timeClasses.ordinalElements.relativeTimeClasses . 30
A.3.14 When using timeClasses.nominalElements.classesSetEexternally . 30
A.3.15 When using userClasses . 30
A.3.16 When using tollContextLayout. 30
A.3.17 When using chargeReportingEvents . 30
A.3.18 When using chargeReportConfiguration . 30
A.4 Conditional requirements to be observed by the Front End . 30
A.4.1 When using in the ChargeReport all other elements than usageStatement . 30
A.4.2 When using in the ChargeReport the usageStatementList . 31
A.4.3 When using aggregatedFee. 31
A.4.4 When using aggregatedSingleTariffClassSession . 31
A.4.5 When using listOfChargeObjects . 31
A.4.6 When using listOfRawUsageData . 31
Annex B (normative) The use of identifiers . 32
B.1 General . 32
B.2 Identifiers specified in CEN ISO/TS 13141 . 36
B.3 Identifiers specified in CEN ISO/TS 17575-1 . 36
B.4 Identifiers specified in CEN ISO/TS 17575-3 . 38
B.5 Identifiers specified in CEN ISO/TS 17575-4 . 39
B.6 Identifiers specified in CEN ISO/TS 12813 . 39
B.7 Identifiers specified in EN ISO 12855 . 39
Annex C (normative) Protocol Implementation Conformance Statement . 41
C.1 Guidance for completing the PICS proforma . 41
C.1.1 Purposes and structure . 41
C.1.2 Abbreviations and conventions . 41
C.1.3 Instructions for completing the PICS proforma . 43
C.2 PICS proforma for the Toll Charger’s Back-end . 43
C.2.1 Identification of the implementation . 43
C.2.2 Identification of the protocol . 46
C.2.3 Global statement of conformance . 46
C.2.4 Profiles. 46
C.2.5 EN ISO 12855 . 46
C.3 PICS proforma for the Toll Charger RSE . 50
C.3.1 Identification of the implementation . 50
C.3.2 Identification of the protocol . 52
C.3.3 Global statement of conformance . 52
C.3.4 Support for CCC and LAC Applications . 52
C.4 PICS proforma for the Service Provider Back-end . 54
C.4.1 Identification of the implementation . 54
C.4.2 Identification of the protocol . 56
C.4.3 Global statement of conformance . 56
C.4.4 Profiles. 57
C.4.5 EN ISO 12855 . 57
C.5 PICS proforma for the Service Provider Front End . 61
C.5.1 Identification of the implementation . 61
C.5.2 Identification of the protocol . 63
C.5.3 Global statement of conformance . 63
C.5.4 Front End Class . 64
C.5.5 CEN ISO/TS 17575-1 Charge Report - Usage Statement. 64
C.5.6 CEN ISO/TS 17575-3 –Charge Report Configuration . 64
C.5.7 Support for CCC and LAC Applications . 65
Annex D (informative) IAP taxonomy and numbering . 66
D.1 General . 66
D.2 Taxonomy of Interoperable Application Profiles (IAP) . 66
D.2.1 Specified profiles . 66
D.2.2 Future new profiles . 67
D.3 IAP numbering and referencing . 67
D.3.1 IAP numbering . 67
D.3.2 IAP referencing . 67
Annex E (informative) How to define new profiles - the profile creation principle . 68
Bibliography . 69

Foreword
This document (CEN/TS 16331:2012) has been prepared by Technical Committee CEN/TC 278 “Road
transport and traffic telematics”, the secretariat of which is held by NEN.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such patent rights.
This document has been prepared under a mandate given to CEN by the European Commission and the
European Free Trade Association.
According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following
countries are bound to announce this Technical Specification: Austria, Belgium, Bulgaria, Croatia, Cyprus,
Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy,
Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia,
Spain, Sweden, Switzerland, Turkey and the United Kingdom.
Introduction
This Technical Specification should be used by stakeholders of a group of electronic fee collection (EFC)
regimes as a guide when planning to establish or extending an EFC cluster providing interoperability for tolled
vehicles in all participating EFC domains.
The scope of this document covers the tolling principles for autonomous EFC systems.
The goal of an interoperable EFC cluster is to ensure that all tolled vehicles can be charged the due toll
amount in all EFC domains. This can be achieved by requiring that all necessary equipment, whether in the
tolled vehicles, the Toll Service Providers’ central systems, the Toll Chargers’ central systems and along the
roadside in the EFC domains, conform to the same interface standards and to an Interoperable Application
Profile, as defined in this Technical Specification.
The system architecture defined in ISO 17573 is the basis for all standards that relate to Electronic Fee
Collection systems. It specifies the roles and responsibilities needed within an interoperable EFC cluster.
Such a cluster is illustrated in Figure 1, and consists of multiple Toll Service Providers and multiple Toll
Chargers. Each Toll Charger has its own EFC Domain and its own EFC regime. Conversely, each Toll Service
Provider has a number of clients, who own vehicles and may be liable to pay toll in the EFC domains of the
Toll Chargers.
Figure 1 — Actors and interfaces within an interoperable EFC cluster
CEN has produced a set of standards that together specify a basis for EFC systems. This document refers to
these standards as the ‘base standards’. They are necessary to ensure technical interoperability between
different EFC-systems, but in themselves they are not sufficient to achieve this, as they contain a large
number of options and choices to be made in a concrete implementation.
Figure 2 shows the base standards and their relationships.

Figure 2 — Suite of EFC related standards
NOTE There may be one or more instances of each box representing an actor
This set of base standards includes the CEN ISO/TS 17575-suite, ISO 17573, EN ISO 12855,
CEN ISO/TS 13141 and CEN ISO/TS 12813. These standards have the characteristic of toolbox standards,
specifying messages and data elements, which - if used – are to be used in the prescribed way. However,
these base standards contain many optional features that may or may not be implemented by different Toll
Chargers or Service Providers. Therefore, the base standards alone do not guarantee interoperability between
the systems of different actors without further restrictions of the use of optional features of these base
standards. This is the purpose of this profile standard – to restrict the choices from the above listed set of
base standards.
This Technical Specification defines a number of Interoperable Application Profiles (IAP) for autonomous
Electronic Fee Collection systems, according to the concept of "International Standardised Profiles (ISP)" as
defined in ISO IEC/TR 10000-1. Each profile provides a coherent set of choices from among the options in the
base standards. A profile thus may be used to determine a concrete set of requirements for EFC constituents.
When multiple EFC systems are based on the same profile, the profile will serve as a common technical
platform for EFC interoperability. Which profile should be chosen will depend on the needs of all participants in
this EFC cluster and on the outcome of negotiations between them.
The profiles in this Technical Specification were created in order to meet the requirements of early adoptions
of the general principles of autonomous interoperable EFC clusters, such as the upcoming European
Electronic Toll Service. This Technical Specification specifies also a methodology to define a customised
profile if none of the specified profiles are acceptable to all participants in an interoperable EFC cluster.
Each Toll Service Provider taking part in an EFC cluster should be aware that he needs to implement all the
features of the chosen profile. Therefore, it will generally be in the best interest of the Service Providers to
select the simplest profile that is still acceptable to all Toll Chargers.
Toll Chargers within the same EFC cluster, however, still have the choice to use any of these features or not.
1 Scope
This Technical Specification defines a set of interoperable application profiles suitable to be used defining the
overall functionality of an interoperable EFC cluster using autonomous vehicle equipment. Doing so, it also
defines a way of defining further profiles for future use.
The profiles cover a wide range from simple toll road systems up to very complex tolling principles and tariff
rules. An EFC cluster shall select and use one of these profiles covering the needs of all participating Toll
Chargers.
The scope is limited to those base standards providing data elements or messages to be used specifically
when defining the data exchange for autonomous tolling principles. This covers ISO 17573 and the base
standards CEN ISO/TS 17575 parts 1 to 4, CEN ISO/TS 12813, CEN ISO/TS 13141 and those parts of
EN ISO 12855 specifying messages which are only relevant for autonomous systems.
Figure 3 provides a graphical illustration of the scope of this Interoperable Application Profile which is based
on the ISP concept according to ISO IEC/TR 10000-1.

Figure 3 — The scope of this IAP covers the interfaces within the dotted lined box

For each specified profile, the conditional requirements resulting from the actual use of data elements being
still optional according to this profile are specified in Annex A. A set of rules on how to re-use identifiers of a
specific entity within the full chain of transactions is specified in Annex B and a protocol implementation
conformance statement (PICS) proforma in Annex C.
Outside of the scope are:
 details on how to achieve security using the authenticator data elements of the base standards;
 how to operate the enforcement process;
 commercial aspects and the billing process;
 the handling of DSRC charging transactions;
 system monitoring and performance indicators;
 test standards;
 the initial configuration of the OBE.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO 17573:2010, Electronic fee collection - Systems architecture for vehicle-related tolling
EN ISO 12855:2009, Electronic fee collection – Information exchange between service provision and toll
charging (ISO/DIS 12855:2009)
CEN ISO/TS 12813:2009, Electronic fee collection - Compliance check communication for autonomous
systems (ISO/TS 12813:2009)
CEN ISO/TS 13141:2010, Electronic fee collection - Localisation augmentation communication for
autonomous systems (ISO/TS 13141:2010)
CEN ISO/TS 17575-1:2010, Electronic fee collection - Application interface definition for autonomous systems
- Part 1: Charging (ISO/TS 17575-1:2010)
CEN ISO/TS 17575-2:2010, Electronic fee collection - Application interface definition for autonomous systems
- Part 2: Communication and connection to the lower layers (ISO/TS 17575-2:2010)
CEN ISO/TS 17575-3:2011, Electronic fee collection - Application interface definition for autonomous systems
- Part 3: Context data (ISO/TS 17575-3:2011)
CEN ISO/TS 17575-4:2011, Electronic fee collection - Application interface definition for autonomous systems
- Part 4: Roaming (ISO/TS 17575-4:2011)
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
attribute
application information formed by one or by a sequence of data elements, used for implementation of a
transaction
[SOURCE: EN ISO 14906:2011]
3.2
back end
generic name for the computing and communication facilities of the Service Provider and/or the Toll Charger
[SOURCE: CEN ISO/TS 17575-1:2010]
3.3
charge report
data structure transmitted from the Front End to the Back End to report road usage data and supplementary
related information
[SOURCE: CEN ISO/TS 17575-1:2010]
3.4
context data
information defined by the responsible Toll Charger necessary to establish the toll due for circulating a vehicle
on a particular Toll Domain and to conclude the toll transaction
[ISOURCE: SO 17573:2010]
3.5
context layout
group of attributes of the context data providing the geographic information of the EFC domain
3.6
EFC cluster
a group of toll schemes operating under a common agreement providing interoperability for vehicles equipped
with an appropriate OBE and being contracted under a Toll Service Provider being part of the cluster
[SOURCE: CEN ISO/TS 17575-4:2011]
3.7
EFC domain
same as toll domain: area or part of a road network where a toll regime is applied
[SOURCE: ISO 17573:2010]
3.8
EFC regime
same as toll regime: set of rules, including enforcement rules, governing the collection of toll in a toll domain

[SOURCE: ISO 17573:2010]
3.9
front end
part(s) of the toll system where road usage data for an individual road user are collected, processed and
delivered to the Back End
Note to entry The Front End comprises the on-board equipment and an optional proxy.

[SOURCE: CEN ISO/TS 17575-1:2010]
3.10
overview
attribute and group of data elements providing the information if an EFC context is relevant for a specific
vehicle or not
3.11
relative time
point in time relative to a defined event e.g. the entrance of a vehicle into an EFC specific area in minutes
and/or hours
3.12
roaming rules
set of attributes for Front Ends according to CEN ISO/TS 17575-4, defining the group of associated EFC
contexts and their relationships; and/or for Back Ends according to EN ISO 12855, defining the relations for
multi-context EFC domains
4 Abbreviations
For the purposes of this document, the following abbreviations apply throughout the document unless
otherwise specified.
ADU Application Data Unit
CCC  Compliance Check Communication
DSRC Dedicated Short Range Communication
EFC  Electronic Fee collection
GDF Geographic Data File
GNSS Global Navigation Satellite System
IAP  Interoperable Application Profile
IUT  Implementation Under Test
ISP  International Standardised Profile
LAC Localisation Augmentation Communication
OBE  On Board Equipment
OBU  On Board Unit
OSD Overlapping Sectioned Roads tolling and Distance based Area pricing
OSDT Overlapping Sectioned Roads tolling and Distance and Time based Area pricing
OSDTC Overlapping Sectioned Roads tolling, Distance and Time based Area and Cordon pricing
PICS Protocol Implementation Conformance Statement
SD  Short form for the profile covering Sectioned Roads tolling and Distance based Area pricing
SR  Short form for the profile covering Sectioned Roads tolling
RSE  Road Side Equipment
SP  Service Provider (Toll Service Provider)
SUT  System Under Test
TC  Toll Charger
TSP  Toll Service Provider
Short form for the profile covering.
5 General profile independent IAP requirements
5.1 The principle defining EFC cluster supported regime characteristics using profiles
This Technical Specification shall be used specifying the supported frame of the functional characteristics of
an EFC cluster. This includes the supported basic tolling principles as well as details of the tariff models and
the formats and details of toll declarations to be reported to the Toll Chargers. Each participating EFC regime
shall be described staying within the EFC cluster specific functional frame.
The frame of the functional details supported in an EFC cluster is defined by including or excluding optional
data elements of the base standards. These data elements represent parameters describing details of the
rules to be observed by tolled vehicles, its users and the associated Service Providers. Hence, including or
excluding a certain data element will result in allowing or not allowing a certain detail of the EFC regime
characteristics.
Therefore, it is important, when defining this frame of defined characteristics within an EFC cluster, to include
all the needs of all participating EFC regimes. This will form the basis for the associated EFC cluster specific
profile.
To ease this selection process this Technical Specification provides a set of optional data elements of the
base standards which are in different lists marked as allowed which means mandatory (m) or not allowed
which means not applicable (n/a).
Each of these lists represents an interoperable application profile (IAP), also referred to as a profile (in short
form) (see also Table 1, Table 2 and 7.2).
Stakeholders of an EFC cluster may agree to use one of these standardised IAPs or they agree to define an
own profile using the same methodology as used within this Technical Specification.
From that follows that according to the variety of required tolling principles and other details a more or less
complex profile may be selected as the EFC cluster profile.
5.2 Toll Charger requirements
5.2.1 General
Profiles according to this Technical Specification are constituted by a list of optional data elements of base
standards which are re-classified as mandatory (m) or not applicable (n/a) for a specific profile (see Table 1).
To be compliant with any profile a Toll Chargers shall be compliant with all the base standards listed in
Clause 2.
To be compliant with a specific profile a Toll Charger shall also follow the following rules:
 For all data elements where the Toll Charger is listed as the sender of a message the Toll Charger shall
use only those data elements of the profile specific list which are marked as mandatory (m) and which are
actually required for the toll domain specific needs (see the TC->TSP indication in the column
"information flow" in Table 1).
NOTE 1 From that follows that Toll Chargers still have the choice using mandatory data elements or not.
 For all data elements where the Toll Charger is listed as the receiver of a message the Toll Charger shall
be prepared to receive and process all data elements marked as mandatory and which could be not
logically excluded (see the TC<-TSP indication in the column "information flow" in Table 1).
NOTE 2 A mandatory data element may be logically excluded if in other configuration settings under the control of the
Toll Charger this data element was "deselected" e.g. in the ChargeReportConfiguration
If the actual use of profile conformant data elements causes conditional requirements then the Toll Charger
shall comply with them. These conditional requirements are specified in individual clauses in Annex A and
they are referenced in the data element list (see Table 1). Other optional data elements of the base standards
which are not mentioned in the data element tables remain optional. Toll chargers shall be prepared to
process these data elements as specified in the base standards.
5.2.2 Toll Charge Back End requirements
For data exchange with the central equipment of one or more Service Providers the Toll Charger shall provide
a Back End interface compliant with EN ISO 12855 for the following ADUs:
 efcContextDataADU
 tollDeclarationADU
NOTE 1 Within the context of this IAP only EFC contexts according to the GNSS choice are specified.
NOTE 2 The use of other ADUs defined in EN ISO 12855 may be specified in other profile standards or documents.
To be compliant with a specific profile a Toll Charger shall use only those or a subset of those optional data
elements of the efcContextDataADU which are specified in Table 1 in Clause 7 as being mandatory for this
profile and shall also fulfil the conditional requirements referenced for each used data element in the same
table.
In general optional data elements within the underlying ASN1 structure of the used data elements are
remained. However, explicit restrictions on that specified within Table 1 or within the applicable conditional
requirements specified in Annex A shall be observed. The Toll Charger shall use the tollDeclarationADU
received from the Service Provider to initiate the billing process.
The Toll Charger shall use the requestADU, ackADU and the retrieveTollDeclarationADU as specified in
EN ISO 12855.
5.3 Toll Charger RSE requirements
For data exchange with OBE for the purpose of compliance, check the Toll Charger shall provide RSE
compliant with CEN ISO/TS 12813. The underlying communication stack shall comply with the CEN DSRC
choice as specified in CEN ISO/TS 12813:2009, 5.5.
NOTE 1 The density and locations of CCC RSE are decided by the Toll Charger.
For data exchange with OBE for the purpose of localisation augmentation the Toll Charger shall provide RSE
compliant with CEN ISO/TS 13141. The underlying communication stack shall comply with the CEN DSRC
choice as specified in CEN ISO/TS 13141:2010, 5.5.
NOTE 2 The locations of LAC RSE are decided collectively by the Toll Charger and the Service Providers.
5.4 Service Provider requirements
5.4.1 General
As mentioned above profiles according to this Technical Specification are constituted by a list of optional data
elements of base standards which are re-classified as mandatory (m) or not applicable (n/a) for a specific
profile (see Table 1 and Table 2).
To be compliant with any profile a Service Provider shall be compliant with all the base standards listed in
Clause 2.
To be compliant with a specific profile a Service Provider shall also follow the following rules:
 For all data elements where the Service Provider is listed as the sender of a message the Service
Provider shall use only those data elements of the profile specific list which are marked as mandatory (m)
and which are actually required for the toll domain specific needs (see the TSP->TC or TSP-> FE
indication in the column "information flow" in Table 1 and Table 2).
NOTE From that follows that a Service Provider needs to select the choices using mandatory data elements or not
according to the actual needs of a toll domain. These needs can be extracted from the EFC context data or contractual
agreements.
 For all data elements where the Service Provider is listed as the receiver of a message the Service
Provider shall be prepared to receive and process all data elements marked as mandatory.
If the actual use of profile conformant data elements causes conditional requirements then the Service
Provider shall comply with them. These conditional requirements are specified in individual clauses in
Annex A and they are referenced in the data element list (see Table 1 and Table 2).
Other optional data elements of the base standards which are not mentioned in the data element tables
remain optional. Service providers shall be prepared to process these data elements as specified in the base
standards.
5.4.2 Service Provider Back End Requirements
For data exchange with one or more Toll Chargers the Service Provider shall provide an interface compliant
with EN ISO 12855 for the following ADUs:
 efcContextDataADU
 tollDeclarationADU
NOTE The use of other ADUs defined in EN ISO 12855 may be specified in other profile standards or documents.
To be compliant with a specific profile the Service Provider shall support all of the optional data elements of
the efcContextDataADU which are specified in Table 1 in Clause 7 as being mandatory for this profile. This
shall include all optional data elements and choices used to specify their type and formats in all levels of the
underlying ASN1 code.
The Service Provider shall assemble tollDeclarationADU(s) compliant with the content of the data element
chargeReportConfiguration in the efcContextDataADU received from the Toll Charger.
The Service Provider shall forward a tollDeclarationADU to the Toll Charger at events as specified in the
chargeReportingEvents data element in the efcContextDataADU received from the Toll Charger.
The Service Provider shall use the requestADU, ackADU and tollDeclarationADU as specified in
EN ISO 12855.
Identifiers received by the Service Provider which are re-used in other message exchanges pointing to the
same entity shall be used as specified in Annex B.
5.4.3 Front End specific requirements
Service Providers shall use Front Ends
 compliant with CEN ISO/TS 17575 and;
 compliant with the envisaged profile specified within this IAP document and;
 according to one of the OBE classes as specified in Table 3.
In case the Front Ends do not process on their own the required choice of data elements of the
tollDeclarationADU as required by the Toll Charger, the Service Provider shall complete the missing data
elements using further back end processes.
NOTE 1 This concept is called the use of thin clients together with a proxy server.
Service Providers shall originate context and roaming data according to CEN ISO/TS 17575-3 and -4 and
forward them to their Front Ends.
These context and roaming data shall include only those or a subset of those optional data elements as
defined in CEN ISO/TS 17575-3 and 4 which are marked as mandatory in Table 2 in Clause 7 for the
envisaged profile. In a
...