CEN/TC 278/WG 1 - Electronic fee collection and access control (EFC)

This document establishes requirements for short-range communication for the purposes of augmenting the localization in autonomous electronic fee collection (EFC) systems. Localization augmentation serves to inform on-board equipment (OBE) about geographical location and the identification of a charge object. This document specifies the provision of location and heading information and security means to protect against the manipulation of the OBE with false RSE.
The localization augmentation communication (LAC) takes place between an OBE in a vehicle and fixed RSE. This document is applicable to OBE in an autonomous mode of operation.
This document specifies attributes and functions for the purpose of localization augmentation, by making use of the dedicated short-range communications (DSRC) communication services provided by DSRC Layer 7, and makes these LAC attributes and functions available to the LAC applications at the RSE and the OBE. Attributes and functions are specified on the level of application data units (ADUs; see Figure 1).
As depicted in Figure 1, this document is applicable to:
—     the application interface definition between OBE and RSE;
—     the interface to the DSRC application layer, as specified in ISO 15628 and EN 12834;
—     the use of the DSRC stack.
The LAC is suitable for a range of short-range communication media. This document provides specific definitions regarding the CEN-DSRC stack as specified in EN 15509. Annexes C, D, E and H provide for the use of the Italian DSRC as specified in ETSI/ES 200 674-1, ISO CALM IR ARIB DSRC and WAVE DSRC.
This document contains a protocol implementation conformance statement (PICS) proforma in Annex B and transaction examples in Annex F. Annex G highlights how to use this document for the European Electronic Toll Service (EETS).
Test specifications are not within the scope of this document.

This document specifies requirements for short-range communication for the purposes of compliance checking in autonomous electronic fee collecting systems. Compliance checking communication (CCC) takes place between a road vehicle's on-board equipment (OBE) and an interrogator [fixed and mobile roadside equipment (RSE) or hand-held unit] and serves to establish whether the data that are delivered by the OBE correctly reflect the road usage of the corresponding vehicle according to the rules of the pertinent toll regime.
The operator of the compliance checking interrogator is assumed to be part of the toll charging role as defined in ISO 17573-1. The CCC permits identification of the OBE, vehicle and contract, and verification of whether the driver has fulfilled their obligations and the checking status and performance of the OBE. The CCC reads, but does not write, OBE data.
This document is applicable to OBE in an autonomous mode of operation. It is not applicable to compliance checking in dedicated short-range communication (DSRC)-based charging systems.
It specifies data syntax and semantics, but not a communication sequence. All the attributes specified herein are required in any OBE claimed to be compliant with this document, even if some values are set to “not specified” in cases where a certain functionality is not present in an OBE. The interrogator is free to choose which attributes are read in the data retrieval phase, as well as the sequence in which they are read. In order to achieve compatibility with existing systems, the communication makes use of the attributes specified in ISO 17573-3 wherever useful.
The CCC is suitable for a range of short-range communication media. Specific definitions are given for the CEN-DSRC as specified in EN 15509, as well as for the use of ISO CALM IR, the Italian DSRC as specified in ETSI ES 200 674-1, ARIB DSRC, and WAVE DSRC as alternatives to the CEN-DSRC. The attributes and functions specified are for compliance checking by means of the DSRC communication services provided by DSRC application layer, with the CCC attributes and functions made available to the CCC applications at the RSE and OBE. The attributes and functions are specified on the level of application data units (ADUs).
The definition of the CCC includes:
—     the application interface between OBE and RSE (as depicted in Figure 2);
—     use of the generic DSRC application layer as specified in ISO 15628 and EN 12834;
—     CCC data type specifications given in Annex A;
—     a protocol implementation conformance statement (PICS) proforma is given in Annex B;
—     use of the CEN-DSRC stack as specified in EN 15509, or other equivalent DSRC stacks as described in Annex C, Annex D, Annex E and Annex F;
—     security services for mutual authentication of the communication partners and for signing of data (see Annex H);
In addition, an example CCC transaction is presented in Annex G and Annex I highlights how to use this document for the European Electronic Toll Service (EETS).
Test specifications are not within the scope of this document.

This document specifies the test suite structure (TSS) and test purposes (TPs) for evaluation of on-board equipment (OBE) and roadside equipment (RSE) to EN 15509.
Normative Annex A presents the test purposes for the OBE.
Normative Annex B presents the test purposes for the RSE.
Normative Annex C provides the protocol conformance test report (PCTR) proforma for OBE.
Normative Annex D provides the PCTR proforma for RSE.

The scope for this European Standard is limited to:
-   payment method: Central account based on EFC-DSRC;
-   physical systems: OBU, RSE and the DSRC interface between them (all functions and information flows related to these parts);
-   DSRC-link requirements;
-   EFC transactions over the DSRC interface;
-   data elements to be used by OBU and RSE used in EFC-DSRC transactions;
-   security mechanisms for OBU and RSE used in EFC-DSRC transactions.

This document specifies the application interface in the context of electronic fee collection (EFC) systems using dedicated short-range communication (DSRC).
The EFC application interface is the EFC application process interface to the DSRC application layer, as can be seen in Figure 1. This document comprises specifications of:
—    EFC attributes (i.e. EFC application information) that can also be used for other applications and/or interfaces;
—    the addressing procedures of EFC attributes and (hardware) components (e.g. integrated circuit(s) card);
—    EFC application functions, i.e. further qualification of actions by definitions of the concerned services, assignment of associated ActionType values, and content and meaning of action parameters;
—    the EFC transaction model, which defines the common elements and steps of any EFC transaction;
—    the behaviour of the interface so as to ensure interoperability on an EFC-DSRC application interface level.
This is an interface standard, adhering to the open systems interconnection (OSI) philosophy (see ISO/IEC 7498-1), and it is as such not primarily concerned with the implementation choices to be realized at either side of the interface.
This document provides security-specific functionality as place holders (data and functions) to enable the implementation of secure EFC transactions. Yet the specification of the security policy (including specific security algorithms and key management) remains at the discretion and under the control of the EFC operator, and hence is outside the scope of this document.

This document specifies:
—    the interfaces between electronic fee collection (EFC) back-office systems for vehicle-related transport services, e.g. road user charging, parking and access control;
—    an exchange of information between the back end system of the two roles of service provision and toll charging, e.g.:
—    charging-related data (toll declarations, billing details),
—    administrative data, and
—    confirmation data;
—    transfer mechanisms and supporting functions;
—    information objects, data syntax and semantics.
This document is applicable for any vehicle-related toll service and any technology used for charging.
The data types and associated coding related to the data elements described in Clause 6 are defined in Annex A, using the abstract syntax notation one (ASN.1) according to ISO/IEC 8824‑1.
This document specifies basic protocol mechanisms over which implementations can specify and perform complex transfers (transactions).
This document does not specify, amongst others:
—    any communication between toll charger (TC) or toll service provider (TSP) with any other involved party;
—    any communication between elements of the TC and the TSP that is not part of the back-office communication;
—    interfaces for EFC systems for public transport;
—    any complex transfers (transactions), i.e. sequences of inter-related application data units (ADUs) that can possibly involve several application protocol data unit (APDU) exchanges;
—    processes regarding payments and exchanges of fiscal, commercial or legal accounting documents; and
—    definitions of service communication channels, protocols and service primitives to transfer the APDUs.

This document defines:
—    personalization interface: dedicated short-range communication (DSRC),
—    physical systems: on-board equipment and the personalization equipment,
—    DSRC-link requirements,
—    EFC personalization functions according to ISO/TS 21719-1 when defined for the DSRC interface, and
—    security data elements and mechanisms to be used over the DSRC interface.
A protocol information conformance statement (PICS) proforma is provided in Annex B, and security computation examples are provided in Annex E.
It is outside the scope of this document to define:
—    conformance procedures and test specifications,
—    setting-up of operating organizations (e.g. toll service provider, personalization agent, trusted third party), and
—    legal issues.
NOTE       Some of these issues are subject to separate standards prepared by ISO/TC 204, CEN/TC 278 or ETSI ERM.

This document provides an analysis of the use of licence plate number (LPN) information and automatic number plate recognition (ANPR) technologies in electronic fee collection (EFC), through the description of the legal, technical and functional contexts of LPN-based EFC. It also provides an associated gap analysis of the EFC standards to identify actions to support standardized use of the identified technologies, and a roadmap to address the identified gaps.
The gap analysis in this document is based on use cases, relevant regulations, standards and best practices in the field of EFC, based on the European electronic toll service (EETS)[27] model.
Examples of licence plate number (LPN)-based tolling schemes are given in Annex A.

This document describes tests which verify on-board unit (OBU) conformance of functions and data structures implementations, as defined in the implementation conformance statement (ICS) based on ISO 14906 for EFC applications.
This document defines tests for assessing OBU conformance in terms of :
—     basic dedicated short-range communication (DSRC) L7 functionality,
—     EFC application functions,
—     EFC attributes (i.e. EFC application information),
—     the addressing procedures of EFC attributes and (hardware) components,
—     the EFC transaction model, which defines the common elements and steps of any EFC transaction, and
—     the behaviour of the interface so as to support interoperability on an EFC-DSRC application interface level.
After the tests of isolated data items and functions (C.2 to C.4), an example is given for testing a complete EFC transaction (C.3). Although this document defines examples of test cases for DSRC and EFC functionality (see Annex C), it does not intend to specify a complete test suite for a certain implementation. To compose a test suite for a specific EFC implementation, the test cases can be modified and new test cases can be defined and added in order for the conformance test suite to be complete. It can be useful to consider the following when defining a complete test suite:
—     small range: "exhaustive testing" of critical interoperability/compatibility features,
—     large range: testing of boundaries and random values, and
—     composite types: testing of individual items in sequence or parallel.
This document does not define tests which assess:
—     performance,
—     robustness, and
—     reliability of an implementation.
NOTE 1 ISO 14907‑1 defines test procedures that are aimed at assessing performance, robustness and reliability of EFC equipment and systems.
NOTE 2 The ISO/IEC 10373 series defines test methods for proximity, vicinity, integrated circuit(s) cards and related devices that can be relevant for OBUs which support such cards.
Annex D provides an informative overview of Japanese on-board equipment (OBE) conformance tests which are based on the ISO 14907 series, in order to illustrate how these can be applied in practice.

This document specifies the test suite structure (TSS) and test purposes (TPs) for evaluating the conformity of on-board equipment (OBE) and roadside equipment (RSE) to ISO 12813.
It provides a basis for conformance tests for dedicated short-range communication (DSRC) OBE and RSE to support interoperability between different equipment supplied by different manufacturers.
ISO 12813 defines requirements on the compliance check communication (CCC) interface level, but not for the RSE or OBE internal functional behaviour. Consequently, tests regarding OBE and/or RSE functional behaviour remain outside the scope of this document.

This document defines an information security framework for all organizational and technical entities of an EFC scheme and for the related interfaces, based on the system architecture defined in ISO 17573-1. The security framework describes a set of security requirements and associated security measures.
Annex D contains a list of potential threats to EFC systems and a possible relation to the defined security requirements. These threats can be used for a threat analysis to identify the relevant security requirements for an EFC system.
The relevant security measures to secure EFC systems can then be derived from the identified security requirements.

This document specifies the test procedures of electronic fee collection (EFC) roadside equipment (RSE) and on-board equipment (OBE) with regard to the conformance to standards and requirements for type approval and acceptance testing which is within the realm of EFC application specifically.
The scope of this document is restricted to systems operating within the radio emission, electromagnetic compatibility (EMC) regulations, traffic, and other regulations of the countries in which they are operated.
This document identifies a set of suitable parameters and provides test procedures to enable the proof of a complete EFC system, as well as components of an EFC system, e.g. OBE, related to the defined requirements of an application. The defined parameter and tests are assigned to the following groups of parameters:
—     functionality;
—     quality;
—     referenced pre-tests.
An overview of the tests and parameters provided by this document is given in 5.1 and 5.2.
This document describes procedures, methods and tools, and a test plan which shows the relation between all tests and the sequence of these tests. It lists all tests that are required to measure the performance of EFC equipment. It describes which EFC equipment is covered by the test procedures; the values of the parameters to be tested are not included. It also describes how the tests are to be performed and which tools and prerequisites are necessary before this series of tests can be undertaken. It is assumed that the security of the system is inherent in the communications and EFC functionality tests, therefore they are not addressed here. All tests in this document provide instructions to evaluate the test results.
This document defines only the tests and test procedures, not the benchmark figures that these are to be measured against. The test procedures defined in this document can be used as input, e.g. by scheme owners, for prototype testing, type approvals, tests of installations and periodic inspections.
Related to a conceptual model of an EFC system, this document relates only to the equipment of the user and the service provider. Any other entities are outside the scope of document.
EFC systems for dedicated short-range communication (DSRC) consist, in principle, of a group of technical components, which in combination fulfil the functions required for the collection of fees by electronic automatic means. These components comprise all, or most, of the following:
—     OBE within a vehicle;
—     OBE containing the communications and computing sub-functions;
—     optional integrated circuit card which may carry electronic money, service rights, and other secured information;
—     communication between OBE and RSE based on DSRC;
—     equipment for the fee collection at the RSE containing the communications and computing sub-functions;
—     equipment for the enforcement at the roadside;
—     central equipment for the administration and operation of the system.
The scope of this document relates solely to OBE and RSE and the DSRC interface between OBE and RSE including its functions to perform the fee collection. All the equipment used for enforcement (e.g. detection, classification, localization, and registration) and central equipment are outside the scope of this document.

This document provides an EETS gap analysis with the aim to identify the need for new or updated standards to provide an enhanced support of the recast of the EU EETS legislation [29], [31], [32].

This document defines the architecture of electronic fee collection (EFC) system environments, in which a customer with one contract may use a vehicle in a variety of toll domains with a different toll charger for each domain.
EFC systems conforming to this document can be used for various purposes including road (network) tolling, area tolling, collecting fees for the usage of bridges, tunnels, ferries, for access or for parking. From a technical point of view the considered toll systems may identify vehicles subject to tolling by means of electronic equipment on-board in a vehicle or by other means (e.g. automatic number plate recognition, ANPR).
From a process point of view the architectural description focuses on toll determination, toll charging, and the associated enforcement measures. The actual collection of the toll, i.e. collecting payments, is outside of the scope of this document.
The architecture in this document is defined with no more details than required for an overall overview, a common language, an identification of the need for and interactions among other standards, and the drafting of these standards.
This document as a whole provides:
—          the enterprise view on the architecture, which is concerned with the purpose, scope and policies governing the activities of the specified system within the organization of which it is a part;
—          the terms and definitions for common use in an EFC environment;
—          a decomposition of the EFC systems environment into its main enterprise objects;
—          the roles and responsibilities of the main actors. This document does not impose that all roles perform all indicated responsibilities. It should also be clear that the responsibilities of a role may be shared between two or more actors. Mandating the performance of certain responsibilities is the task of standards derived from this architecture;
—          identification of the provided services by means of action diagrams that underline the needed standardised exchanges;
—          identification of the interoperability interfaces for EFC systems, in specialised standards (specified or to be specified).

This document specifies transactions and data for Compliance Checking - Secure Monitoring. The Scope of this document consists of:
—-   the concept and involved processes for Secure Monitoring;
-   the definition of transactions and data;
-   the use of the OBE compliance checking transaction as specified in EN ISO 12813, for the purpose of Compliance Checking - Secure Monitoring;
-   the use of back end transactions as specified in EN ISO 12855, for the purpose of Compliance Checking – Secure Monitoring. This includes definitions for the use of optional elements and reserved attributes;
-   a specification of technical and organizational security measures involved in Secure Monitoring, on top of measures provided for in the EFC Security Framework;
-   the interrelations between different options in the OBE, TSP and TC domain and their high level impacts.
NOTE   Outside the Scope of this document is: The information exchange between OBE and TR, choices related to compliance checking policies e.g. which options are used, whether undetected/unexpected observations are applied, whether fixed, transportable or mobile compliance checking are deployed, locations and intensity of checking of itinerary freezing and checking of toll declaration, details of procedures and criteria for assessing the validity or plausibility of Itinerary Records.

This document defines the requirements for the secure application module (SAM) used in the secure monitoring compliance checking concept. It specifies two different configurations of a SAM:
-   trusted recorder, for use inside an OBE;
-   verification SAM, for use in other EFC system entities.
This document describes
-   terms and definitions used to describe the two Secure Application Module configurations;
-   operation of the two Secure Application Modules in the secure monitoring compliance checking concept;
-   functional requirements for the two Secure Application Modules configurations, including a classification of different security levels;
-   the interface, by means of transactions, messages and data elements, between an OBE or front end and the trusted recorder;
-   requirements on basic security primitives and key management procedures to support Secure Monitoring using a trusted recorder.
This document is consistent with the EFC architecture as defined in EN ISO 17573-1 and the derived suite of standards and Technical Specifications, especially CEN/TS 16702-1 and CEN ISO/TS 19299.
The following is outside the scope of this document:
-   The life cycle of a Secure Application Module and the way in which this is managed;
-   The interface commands needed to get a Secure Application Module in an operational state;
-   The interface definition of the verification SAM;
-   Definition of a hardware platform for the implementation of a Secure Application Module.

This document provides a suite of tests in order to assess the central equipment of toll chargers and toll service providers for compliancy towards the requirements listed in CEN/TS 16986. This document contains the definition of such tests in the form of test cases, reflecting the required individual steps listed in specific Test Purposes defined in CEN/TS 17154-1. The test cases are written in Testing and Test Control Notation version 3 (TTCN v3).

This document specifies the test suite structure (TSS) and test purposes (TP) to test conformity of central equipment of both toll chargers and toll service providers versus CEN/TS 16986.
It further provides templates for the protocol conformance test reports (PCTR) for the implementation under tests (IUT) for both the toll charger and the toll service provider.
This document contains the technical provisions to perform conformance testing of functional and dynamic behaviour of implementations conforming to CEN/TS 16986.
NOTE   The specifications in this Part provide the base for the tree and tabular combined notation (TTCN) of the test cases and steps which are provided in CEN/TS 17154 2.

ISO/TS 21719-1:2018 describes:
-      an overall description of the EFC personalization process;
-      a description of EFC functionality that can be used for personalization.
The personalization process takes place within the domain of the entity that is responsible for the application in the OBE.

ISO 13140-1:2016 specifies the test suite structure (TSS) and test purposes (TP) to evaluate the conformity of on-board units (OBU) and roadside equipment (RSE) to ISO 13141.
It provides a basis for conformance tests for dedicated short-range communication (DSRC) equipment (on-board units and roadside units) to enable interoperability between different equipment supplied by different manufacturers.

This European Standard specifies the abstract test suite (ATS) to evaluate the conformity of on-board equipment (OBE) and roadside equipment (RSE) to EN 15509 in accordance with the test suite structure and test purposes defined in EN 15876-1:2016.
The objective of the present document is to provide a basis for conformance tests for DSRC equipment (OBE and RSE) to support interoperability between different equipment supplied by different manufacturers.

This Technical Specification defines an application interface definition by selecting suitable options from the base standard EN ISO 12855:2015. Furthermore, it defines transfer mechanisms and supporting functions to ensure the interoperability between TCs and TSPs.
This Technical Specification covers:
-   exchange of information between the central equipment associated with the two roles service provision and toll charging, e.g.:
-   charging related data (exception lists, toll declarations, billing details, payment claims);
-   administrative data (trust objects, EFC context data, contact details for enforcement, etc.);
-   confirmation data.
-   transfer mechanisms and supporting functions;
-   semantics of data elements;
-   implementation conformance statement proforma (Annex A), as a basis for assessment of conformity to this Technical Specification;
-   an Interoperability statement proforma (Annex B), as a basis for assessment of transactional intereoperability of two technical implementations;
-   a web service definition (Annex C) for the use of web services as communication technology.
The implementation of the underlying back office systems and their business processes is not covered. Therefore, outside of the scope is in particular:
-   details on how to achieve security using the authenticator data elements of the base standards;
-   how to operate compliance checking and the enforcement process;
-   commercial aspects;
-   definition of non-functional features such as performance indicators like accuracy, availability and reporting requirements.
This Technical Specification further provides an assessment of support of the EETS (Annex D) and an explanation how to read the unified modelling language (UML) diagrams (Annex E) that are used in this document.

ISO/TS 17574:2017 provides guidelines for preparation and evaluation of security requirements specifications, referred to as Protection Profiles (PP) in ISO/IEC 15408 (all parts) and in ISO/IEC TR 15446.
By Protection Profile (PP), it means a set of security requirements for a category of products or systems that meet specific needs. A typical example would be a PP for On-Board Equipment (OBE) to be used in an EFC system. However, the guidelines in this document are superseded if a Protection Profile already exists for the subsystem in consideration.

ISO 13143-2:2016 specifies the abstract test suite (ATS) to evaluate the conformity of on-board equipment (OBE) and roadside equipment (RSE) to ISO 12813 in accordance with the test suite structure and test purposes defined in ISO 13143‑1:2016.
It provides a basis for conformance tests for dedicated short-range communication (DSRC) equipment (OBE and RSE) to enable interoperability between equipment supplied by different manufacturers.
In order to ascertain that OBE and RSE fulfil essential radio requirements, they are also likely to be subject to additional factory, site and system acceptance testing (e.g. of physical and environmental endurance, quality assurance and control at manufacturing, and charge point integration), which is outside the scope of this document.

ISO 13140-2:2016 specifies the abstract test suite (ATS) to evaluate the conformity of on-board equipment (OBE) and roadside equipment (RSE) to ISO 13141:2015 in accordance with the test suite structure and test purposes defined in ISO 13140‑1:2016.
It provides a basis for conformance tests for dedicated short-range communication (DSRC) equipment (OBE and RSE) to support interoperability between different equipment supplied by different manufacturers.

This Technical Specification defines an application interface definition by selecting suitable options from the base standard EN ISO 12855:2015. Furthermore, it defines transfer mechanisms and supporting functions to ensure the interoperability between TCs and TSPs.
This Technical Specification covers:
-   exchange of information between the central equipment associated with the two roles service provision and toll charging, e.g.:
-   charging related data (exception lists, toll declarations, billing details, payment claims);
-   administrative data (trust objects, EFC context data, contact details for enforcement, etc.);
-   confirmation data.
-   transfer mechanisms and supporting functions;
-   semantics of data elements;
-   implementation conformance statement proforma (Annex A), as a basis for assessment of conformity to this Technical Specification;
-   an Interoperability statement proforma (Annex B), as a basis for assessment of transactional intereoperability of two technical implementations;
-   a web service definition (Annex C) for the use of web services as communication technology.
The implementation of the underlying back office systems and their business processes is not covered. Therefore, outside of the scope is in particular:
-   details on how to achieve security using the authenticator data elements of the base standards;
-   how to operate compliance checking and the enforcement process;
-   commercial aspects;
-   definition of non-functional features such as performance indicators like accuracy, availability and reporting requirements.
This Technical Specification further provides an assessment of support of the EETS (Annex D) and an explanation how to read the unified modelling language (UML) diagrams (Annex E) that are used in this document.

This Technical Report includes a threat analysis, based on ISO/TS 19299 (EFC - Security Framework), of the CEN DSRC link as used in EFC applications according to the following Standards and Technical Specification
-   EN 15509:2014,
-   ISO 12813:2015,
-   ISO 13141:2015,
-   CEN/TS 16702-1:2014.
This Technical Report contains:
-   a qualitative risk analysis in relation to the context (local tolling system, interoperable tolling environment, EETS);
-   an assessment of the current recommended or defined security algorithms and measures to identify existing and possible future security leaks;
-   an outline of potential security measures which might be added to those already defined for DSRC;
-   an analysis of effects on existing EFC systems and interoperability clusters;
-   a set of recommendations on how to revise the current standards, or proposal for new work items, with already made implementations taken into account.
The security analysis in this Technical Report applies only to Security level 1, with Access Credentials and Message authentication code, as defined in EN 15509:2014.
It is outside the scope of this Technical Report to examine Non DSRC (wired or wireless) interfaces to the OBE and RSE.

This Technical Report (TR) contains an analysis of the technical and operational feasibility of using a generic ITS Station as specified in ETSI EN 302 665, Intelligent Transport Systems (ITS); Communications Architecture, for EFC applications compliant to the requirements specified in ISO 17573, EN ISO 12855, CEN ISO/TS 17575 (all parts), EN ISO 14906, EN 15509, CEN ISO/TS 12813, CEN ISO/TS 13141 and CEN/TS 16439.
The scope of this Technical Report includes:
-   description of the context of Cooperative ITS and the ITS Stations;
-   providing details of the context of EFC applications;
-   outlining the basic architectural concepts and role model of both EFC and Cooperative ITS;
-   identification of core requirement areas for operation of an EFC application on an ITS Station;
-   specification of a set of recommendations for functional, operational and security requirements to the ITS Station supporting the EFC application(s);
-   description of a possible role model in which the roles known in EFC applications make use of the roles in the C-ITS system in order to provide EFC services in an C-ITS context;
-   provision of considerations in particular areas of EFC like certification and governances;
-   guideless and recommendations for further standardization work in this area;
-   emphasising on security related elements of EFC that need to be considered in a C-ITS environment.
The scope of this Technical Report is limited to in-vehicle ITS Stations. However, an EFC service always requires the involvement of in-vehicle and central functionalities. Furthermore, for enforcement purposes as well as in DSRC based toll domains for toll charging purposes also, it is essential that road-side based functions are provided and operated. In order to facilitate EFC services a set of functionalities, tasks and responsibilities are defined and specified in an EFC role model (ISO 17573). These functionalities, tasks and responsibilities are shared between the roles Toll Charger, Toll Service Provider, Road User and Interoperability Management. All these roles interact with each other. As a consequence this Technical Report provides in various areas explanations that are beyond the in-vehicle environment. This is required in order to present the full environment and context. It keeps the readability of this document at a sound level and provides valuable information to those readers which are not yet familiar with EFC in detail.
Outside the scope of this Technical Report is:
-   detailed technical specifications for EFC services and applications on C-ITS systems;
-   implementation specific elements.

1.1 Definition of VAS
Value Added Services, VAS, is a term that was coined in the telecommunications industry for services that go
beyond core service, such as mobile voice communications. Such additional services are intended to add
value for the consumers in order to encourage them to use the telecommunications service more often and to
add an additional revenue stream for the Service Provider.
In the context of EFC, a VAS in this strict sense is a telematics service offered to the Service User by means
of an EFC OBE. This service might directly be consumed by the driver in the vehicle, or might, particularly in
the case of heavy vehicles, be targeted at the freight operator and be consumed in a back office. Such
services can be fleet management services like track-and-trace, payment services such as paying petrol
automatically at the pump, or regulatory applications such as Electronic Licence Plate or access control. Such
additional services and applications create additional value to the user, either by the value the new service
creates to him, or in the case of regulatory services, by combining several functionalities in a single device,
thus removing the need to install and maintain several pieces of equipment simultaneously.
In a wider sense, the operator of the EFC service can draw additional benefit from the data collected by the
EFC system. Data from EFC OBE gives a good account of the traffic situation on the charged network, and
may be utilised for statistical purposes, for traffic planning or even in real-time for traffic information purposes.
The scope of this TR covers both the original meaning of VAS, namely both additional services to the user of
the core EFC service and additional value created for the operator of the charging system.
1.2 Coverage
The TR analyses all telematics applications that have the potential to be delivered as a VAS to EFC. The
analysis covers the requirements of the VAS applications and the fit to the resources offered by the EFC
system. It also analyses prerequisites in terms of business and technical system architecture in order to
enable VAS to be delivered, including questions of control and governance, security aspects and privacy
issues.
The TR does not analyse commercial viability. Cost to benefit ratio and market potential for VAS are
considered to be out of scope.
The TR analyses the potential and pre-conditions for EFC equipment to serve as platforms for a diverse range
of VAS. The VAS are considered to be add-ons to EFC equipment. The TR does not analyse the reverse
situation, namely the situation where an EFC application is added to a telematics platform that has been
deployed for another core service, such as the suitability of navigation systems to serve as platforms for EFC.

1.1   Background and expected benefits of first-mount OBE
It could be foreseen that in future the DSRC OBE will be delivered by car manufacturer as a feature of the vehicle as they do today with car radio which are parts of the most sold vehicles. For the vehicle owner, the OBE supplier is the car manufacturer acting as an OEM (Original Equipment Manufacturer).
The integration of first mount OBE by car manufacturer is the only way to create a future mass market for EFC application based upon DSRC as well as GNSS/CN, as at present the integration of this type of OBEs cannot be achieved except for heavy goods vehicles. Regarding DSRC, this is also an opportunity to extend the capability of today’s EFC technologies by providing increased quality of service, and possibly a greater range of services using in-vehicle electronics and resources.
1.2   Personalisation concept
The personalisation procedure is the procedure where the EFC Service Provider initialize, customise, and finally activate the EFC interoperable service to OBE, for a customer with or without existing account. Two different kinds of personalisation methods can be defined:
a)   the personalisation procedure can be done “over the air”. In such case, personalisation data can be encoded in the OBE by the Service Provider over a secure air-link, or
b)   personalisation data can be loaded directly by the driver into the OBE or Service Provider via a personal storage media.
Theses are two fundamentally different approaches. The second method is perfectly fitted for critical initialisation data, such as encryption keys, to enable the driver to use the same EFC contract in different vehicles, and also to send personalisation data via post to a large number of customers.
In any case, the personalisation procedure shall be implemented in a practical way. It was reminded that the very large majority of Service Provider distribution networks (and related point of sales) are not suited to (...)

This technical report (TR) analyses requirements for a universal Pre-Pay account system for EFC including the following issues:
-   relations to other existing standards in this domain;
-   the core requirements and functionality that must be provided.
This technical report will show an analysis of the requirements for a universal prepay system and categorise possible different types of pre-pay solutions, in terms of functionality, technical and legal considerations. As far as legal requirements are concerned it will be clarified whether the pre-payment means fall within the scope of European Directive 2000/46/EC on the taking up, pursuit of and prudential supervision of the business of electronic money institutions and whether the medium-issuing organisation has to act as a financial institution and falls within the scope of the Payment Service Directive 2007/64/EC. The latter applying exactly to payment activities undertaken by entities but do not require a full bank license.
The technical report will describe the current state-of-affairs of EFC pre-payment systems, including the demand for standards and inventory of provisions provided by standards. It will identify and prioritize gaps in terms of standards or other enablers needed in order for the market to provide viable pre-payment solutions in a European context.
There are two general approaches to represent the content of the TR:
a)   allocate each requirement under each pre-pay solution;
b)   allocate each pre-pay solution under each requirement.
To achieve a better understanding and readability alternative a) has been decided (this refers to Clause 8 and Clause 9 only).
The TR does not give any decision on how or whether one of the pre-payment solutions described is commercially feasible to be considered as an implementable offer to the Service User. The return for invest for any TSP regarding the system architecture requirements and other obligations (refunding of SU) is questionable.

This technical report analyses DSRC Urban Charge Point Requirements including the following issues:
-   The core requirements and functionality that must be provided within DSRC equipment in an urban context;
-   The potential aesthetic impact;
-   How to handle the different traffic conditions in urban areas;
-   Accommodation of the diversity of road users;
-   The potential need to address highly variable topology;
-   A wide variety of installation challenges;
-   Minimisation of the impact of E-M interference;
-   How to ensure interoperability with systems in non-urban contexts (e.g. motorways, plaza systems, handheld readers, etc);
-   How to minimise and, if possible, have no impact upon OBE design;
-   Relations to other existing standards in this domain;
-   How to meet international requirements for Health and Safety;
-   The wider policy context that city centres must address in addition to tackling congestion.
The physical location and configuration of the installation represent a compromise between the needs of the DSRC transaction, of the local electromagnetic environment and of the existing built environment locally both above and below ground. The urban charging system, of which the DSRC element is a part, will be required to fit within a wider social and transport policy context.
It is recognised that not all the elements above lend themselves to a standard, nor will industry be interested in promoting all above topics. However, with an increasing number of urban Charging Schemes being considered, there is a need to create relevant standards from the above lists and hence make it easier for suppliers to offer equipment and services to meet the requirements.

Metallised windscreens are produced by spraying small metal particles on one of the glass or plastic layers of the vehicle’s windscreen. This leads to a windscreen with high thermal qualities, ranging from far-reduced power consumption by air-conditioning equipment to short times for de-icing.
The production of certain vehicles in Europe which were equipped with metallised windscreens has created a major problem for the installation and operation of On-Board Units (OBUs) which rely on Dedicated Short-Range Communications (DSRC) for ITS (as the most-widely deployed DSRC ITS application to date, the remainder of this report will refer to Electronic Toll Collection (EFC) but the developed solutions will be valid for all DSRC ITS applications). As is shown in Table 1, windscreen properties have a decisive influence on the transmission of microwave communication and, for metallised windows, it is essential to compensate these losses by special measures (Ref 1).

This document defines an application interface definition by selecting suitable options from the base standard EN ISO 12855:2021. Furthermore, it defines transfer mechanisms and supporting functions to ensure the interoperability between Toll Chargers and Toll Service Providers.
This document covers:
—   exchange of information between the central equipment associated with the two roles service provision and toll charging, e.g.:
o   charging related data (exception lists, toll declarations, billing details, payment claims);
o   administrative data (trust objects, EFC context data, contact details for enforcement, etc.);
o   confirmation data.
—   transfer mechanisms and supporting functions;
—   semantics of data elements;
—   restrictions on parameters and their values
—   implementation conformance statement proforma, in an Annex, as a basis for assessment of conformity to this document;
—   an Interoperability statement proforma, in an Annex, as a basis for assessment of transactional interoperability of two technical implementations;
—   a web service definition, in an Annex, for the use of web services as communication technology.
The implementation of the underlying back office systems and their business processes is not covered.

2016-01-26: WI cancelled following cancellation of equivalent ISO WI (ISO notification in dataservice on 2016-01-19).

This Technical Specification specifies a system architecture for electronic fee collection (EFC) systems concerning vehicle related transport services such as the use of toll roads, zone access, parking and route guidance.
This Technical Specification does not cover person related transport services such as public transport. However, some of the clauses in this standard may also be applicable for fare collection.
NOTE   Fare collection architecture in public transport is covered by other Working Groups in CEN/TC278 and ISO/TC204, e.g. WG3 Public Transport in CEN/TC278.
This Technical Specification provides the overview of, and inter-relationship among, the set of standards for design, development, testing and operation of applications in the field of EFC.
This Technical Specification is also applicable to the TICS Fundamental Service called Electronic Financial Transactions which is the use of electronic, or 'cashless' payment systems for transportation. Hence, this standard covers toll collection systems, parking fee collection systems, systems for road and congestion pricing and integrated payment systems for transport services.

ISO 13141:2015 establishes requirements for short-range communication for the purposes of augmenting the localization in autonomous electronic fee collection (EFC) systems. Localization augmentation serves to inform on-board equipment (OBE) about geographical location and the identification of a charge object. This International Standard specifies the provision of location and heading information and security means to protect from the manipulation of the OBE with false roadside equipment (RSE).
The localization augmentation communication takes place between an OBE in a vehicle and fixed roadside equipment. This International Standard is applicable to OBE in an autonomous mode of operation.
ISO 13141:2015 defines attributes and functions for the purpose of localization augmentation, by making use of the dedicated short-range communications (DSRC) communication services provided by DSRC Layer 7, and makes these LAC attributes and functions available to the LAC applications at the RSE and the OBE. Attributes and functions are defined on the level of Application Data Units (ADUs, see Figure 1).

This document defines requirements for short-range communication for the purposes of compliance checking in autonomous electronic fee collecting systems. Compliance checking communication (CCC) takes place between a road vehicle's on-board equipment (OBE) and an interrogator (roadside mounted equipment, mobile device or hand-held unit), and serves to establish whether the data that are delivered by the OBE correctly reflect the road usage of the corresponding vehicle according to the rules of the pertinent toll regime.
The operator of the compliance checking interrogator is assumed to be part of the toll charging role as defined in ISO 17573-1. The CCC permits identification of the OBE, vehicle and contract, and verification of whether the driver has fulfilled his obligations and the checking status and performance of the OBE. The CCC reads, but does not write, OBE data.
This document is applicable to OBE in an autonomous mode of operation; it is not applicable to compliance checking in dedicated short-range communication (DSRC)-based charging systems.
It defines data syntax and semantics, but not a communication sequence. All the attributes defined herein are required in any OBE claimed to be compliant with this document, even if some values are set to "not defined" in cases where certain functionality is not present in an OBE. The interrogator is free to choose which attributes are read in the data retrieval phase, as well as the sequence in which they are read. In order to achieve compatibility with existing systems, the communication makes use of the attributes defined in ISO 14906 wherever useful.
The CCC is suitable for a range of short-range communication media. Specific definitions are given for the CEN-DSRC as specified in EN 15509, as well as for the use of ISO CALM IR, the Italian DSRC as specified in ETSI ES 200 674-1, ARIB DSRC and WAVE DSRC as alternatives to the CEN-DSRC. The attributes and functions defined are for compliance checking by means of the DSRC communication services provided by DSRC application layer, with the CCC attributes and functions made available to the CCC applications at the roadside equipment (RSE) and OBE. The attributes and functions are defined on the level of application data units (ADU).
The definition of the CCC includes:
—     the application interface between OBE and RSE (as depicted in Figure 2);
—     use of the generic DSRC application layer as specified in ISO 15628 and EN 12834;
—     CCC data type specifications given in Annex A;
—     a protocol implementation conformance statement (PICS) proforma is given in Annex B;
—     use of the CEN-DSRC stack as specified in EN 15509, or other equivalent DSRC stacks as described in Annex C, Annex D, Annex E and Annex F;
—     security services for mutual authentication of the communication partners and for signing of data (see Annex H);
—     an example CCC transaction is presented in Annex G;
—     the informative Annex I highlights how to use this document for the European electronic toll service (as defined in Commission Decision 2009/750/EC).
Test specifications are not within the scope of this document.

This document specifies the syntax and semantics of data objects in the field of electronic fee collection (EFC). The definitions of data types and assignment of values are provided in accordance with the abstract syntax notation one (ASN.1) technique, as specified in ISO/IEC 8824‑1. This document defines:
—    ASN.1 (data) types within the fields of EFC;
—    ASN.1 (data) types of a more general use that are used more specifically in standards related to EFC.
This document does not seek to define ASN.1 (data) types that are primarily related to other fields that operate in conjunction with EFC, such as cooperative intelligent transport systems (C-ITS), the financial sector, etc.

The ISO 16407 series provides a suite of tests in order to assess the Front End (FE) and Back End (BE) behaviour compliancy towards the requirements listed in ISO 17575‑1. This document contains the definition of such tests in the form of test cases, reflecting the required individual steps listed in specific test purposes defined in ISO 16407‑1. The test cases are written in Testing and Test Control Notation version 3 (TTCN v3).

The ISO 16410 series provides a suite of tests in order to assess the Front End (FE) and Back End (BE) behaviour's compliancy towards the requirements listed in ISO 17575‑3. This document contains the definition of such tests in the form of test cases, reflecting the required individual steps listed in specific test purposes defined in ISO 16410‑1. The test cases are written in Testing and Test Control Notation version 3 (TTCN v3).

ISO/TR 16401-2:2018 contains the definition of test cases, reflecting the individual steps listed in specific test purposes defined in ISO/TR 16401-1. The test cases are written in Testing and Test Control Notation version 3 (TTCN-3).

ISO/TR 16401-1:2018 covers the test purposes for Front End Communications API covering functionalities related to instance handling, session handling, communication service primitives (i.e. sending/receiving of ADUs) and visible state transitions. It covers EFC communication services described in ISO 17575‑2:2016, Clause 5 and PICS proforma in ISO 17575‑2:2016, B.2. Claims related to Front End storage capacity are out of scope of this document.
ISO/TR 16401-1:2018 covers the test purposes for Front End Application related to session establishment on Back End request and related to session re-establishment when session requested by Back End failed. There are no other claims with respect to Front End Application described in ISO 17575‑2.
The underlying communication technology requirements for layer 1 to 4 specified in ISO 17575‑2:2016, Clause 6 are out of scope of this document.
Similarly, Back End Communications API is out of scope of this document. According to ISO 17575‑2 it is expected that these Front End Communications API will be "reflected" in the BE; however, BE Communications API is out of scope of ISO 17575‑2.
Test purposes have been organized into the test suite groups, designated for the Front End Communications API and Front End Application, respectively.
Aside from the test purposes, this document also provides proforma conformance test reports templates for both the Front End and Back End test purposes.
ISO 17575‑2 contains more information regarding the requirements against which the conformance is evaluated in this document.

The ISO 16410 series provides a suite of tests in order to assess compliance of the Front End and Back End behaviours in relation to the requirements in ISO 17575‑3. ISO 16410-1:2017 contains the definition of such tests in the form of test purposes, listing the required initial conditions, references and individual steps in a structured textual manner. ISO 16410‑2 contains the identical tests written in testing and test control notation version 3 (TTCN v3).
The test purposes defined in ISO 16410-1:2017 reflect the structural and semantic requirements stated in ISO 17575‑3.
-      Presence/absence of particular data elements (see ISO 17575‑3:2016, 8.5.5);
-      Semantics related to various data elements, e.g.:
-     Activation of context data and handling multiple contexts (see ISO 17575‑3:2016, 8.3);
-     Handling the precedence and priority levels (see ISO 17575‑3:2016, 8.5.2 to 8.5.4);
-     Uniqueness of relevant data elements (see ISO 17575‑3:2016, 8.5.2 to 8.5.4);
-     Correct definition of the charge objects (see ISO 17575‑3:2016, 8.5.4);
-      Fee calculation algorithm (see ISO 17575‑3:2016, 8.5.3.7);
-      Security (see ISO 17575‑3:2016, 7.2).
With regard to the individual data sets and EFC attributes defined in ISO 17575‑3, the test purposes have been organized into the test suite groups, designated for the Front End and Back End respectively.
In addition to the test purposes, ISO 16410-1:2017 also provides proforma conformance test report templates for both the Front End and Back End test purposes and an informative statement on the usage of ISO 16410-1:2017 for the European electronic toll service (EETS).
For more information regarding the requirements against which the conformance is evaluated in ISO 16410-1:2017, refer to ISO 17575‑3.
Testing of the following behaviours and functionalities is outside the scope of ISO 16410-1:2017:
-      dynamic behaviour, i.e. sequence of messages and triggering events that must be exchanged/happen to fulfil certain charging scenarios;
-      profiles and business logic built on top of particular pricing schemas;
-      behaviour invalid of Front End and Back End, BI test purposes are not applicable for any test purpose group (as ISO 17575‑3 does not specify behaviour invalid).

The ISO 16407 series of standards specifies a suite of tests in order to assess the Front End and Back End behaviour compliancy towards the requirements listed in ISO 17575-1. ISO 16407-1:2017 contains the definition of such tests in the form of test purposes, listing the required initial conditions, references and individual steps in a structured textual manner.

ISO 25110:2017 defines the data transfer models between roadside equipment (RSE) and integrated circuit card (ICC) and the interface descriptions between the RSE and on-board equipment (OBE) for on-board accounts using the ICC. It also provides examples of interface definitions and transactions deployed in several countries.

ISO 17575-2:2016 defines how to convey all or parts of the data element structure defined in other parts of ISO 17575 over any communication stack and media suitable for this application. It is applicable only to mobile communication links (although wired links, i.e. back office connections, can use the same methodology).
To establish a link to a sequence of service calls initializing the communication channel, addressing the reception of the message and forwarding the payload are required. The definition provided in this part of ISO 17575 includes the required communication medium independent services, represented by an abstract application programming interface (API).
The communication interface is implemented as an API in the programming environment of choice for the Front End (FE) system. The specification of the Back End (BE) API is outside the scope of this part of ISO 17575.
The definition of this API in concrete terms is outside of the scope of this part of ISO 17575. This part of ISO 17575 specifies an abstract API that defines the semantics of the concrete API as illustrated in Figure 3 and its protocol implementation conformance statement (PICS) proforma (see Annex B). An example of a concrete API is presented in Annex C. Where no distinction is made between the abstract and concrete communications APIs, the term "communications API" or just "API" can be used.
ISO 17575-2:2016 also provides a detailed specification for the structure of associated API statements, an example on how to implement it and its role in a complex toll cluster such as the EETS (see Annex A to Annex E).
Media selection policies, certificate handling and encryption mechanisms are outside of the scope of this part of ISO 17575.

ISO 17575-3:2016 defines the content, semantics and format of the data exchange between a Front End (OBE plus optional proxy) and the corresponding Back End in autonomous toll systems. It defines the data elements used to specify and describe the toll context details. Context data are transmitted from the Back End to the Front End to configure it for the charging processes of the associated toll context.
In ISO 17575, context data is the description of the properties of a single instance of an electronic fee collection (EFC) context. This single instance of an EFC context operates according to one of the basic tolling principles such as
-      road section charging,
-      area charging (according to travelled distance or duration of time), and
-      cordon charging.
EFC context data comprise a set of rules for charging, including the description of the charged network, the charging principles, the liable vehicles and a definition of the required contents of the charge report. This set of rules is defined individually for each EFC context according to local needs.
The following data and associated procedures are defined in this part of ISO 17575:
-      data providing toll context overview information;
-      data providing tariff information (including definitions of required tariff determinants such as vehicle parameters, time classe, etc.);
-      data providing context layout information;
-      data providing reporting rules information.
ISO 17575-3:2016 also provides the required definitions and data specifications to be applied when one single toll context is spilt inot more than one toll context partitions. This is applicable to cases where one EFC scheme and the rules applied cannot be described with a single set of context data.
Annex A provides the data type specification using ASN.1 notation.
The protocol implementation conformity statements (PICS) proforma are provided in Annex B.
Annex C provides a graphical presentation of the structure of the toll context data.
Annexes D, E and F contain further information and descriptions, which may support the understanding and the implementation of the rules specified in this part of ISO 17575.
Annex G provides information how this part of ISO 17575 can be used in a European Electronic Toll Service (EETS) environment, with reference to EU Decision 2009/750.

ISO 17575-1:2016 defines the format and semantics of the data exchange between a Front End (OBE plus optional proxy) and corresponding Back Ends in autonomous toll schemes. It defines the data elements that are used to generate charge reports containing information about the road usage of a vehicle for certain time intervals, sent from the Front End to the Back End. It also defines the data that can be used to re-configure the ongoing process of gathering charge relevant information in the Front End. The scope is shown in Figure 1.
The constitution of the charge report is dependent on configuration data that are assumed to be present in the Front End. The assembly of charge reports can be configured for each individual toll scheme according to local needs. Charge reports generated in accordance with this part of ISO 17575 are consistent with the requirements derived from the architectural concept defined in ISO 17573:2010.
The definitions in ISO 17575-1:2016 comprise
-      reporting data, i.e. data for transferring road usage data from Front End to Back End, including a response from the Back End towards the Front End,
-      data for supporting security mechanisms,
-      contract data, i.e. data for identifying contractually essential entities,
-      road usage data, i.e. data for reporting the amount of road usage,
-      account data for managing a payment account,
-      versioning data, and
-      compliance checking data, i.e. data imported from ISO 12813:2015, which are required in compliance checking communication.
Annex A contains the data type specifications using ASN.1 notation.
The protocol implementation conformity statements (PICS) proforma are provided in Annex B.
Annex C provides a graphical presentation of the structure of the data elements described in Clause 7.
Annex D provides information on how this part of ISO 17575 can be used in EETS environment and how the requirements that are specified in the EU-Decision 2009/750 are addressed by this standard.