CEN/TC 278 - Road transport and traffic telematics

This document defines the key actors in the eCall chain of service provision using IMS over packet switched networks (such as LTE/4G) as:
1) In-vehicle system (3.20) (IVS)/vehicle,
2) Mobile network Operator (MNO),
3) Public safety answering point (3.27) (PSAP),
and to provide conformance tests for actor groups 1) - 3).
NOTE 1 Conformance tests are not appropriate nor required for vehicle occupants (3.36), although they are the recipient of the service.
NOTE 2 Third party eCall systems (TPS eCall) are not within the scope of this deliverable. This is because the core TPS-eCall (3.32) standard (EN 16102) does not specify the communications link between the vehicle and the TPS service provider (3.29).
NOTE 3 These conformance tests are based an the appropriate conformance tests from EN 16454 which was published before Internet Protocol multimedia Systems (IMS) packet switched networks were available. This deliverable therefore replicates the appropriate tests from EN 16454 (and acknowledge their source); adapt and revise Conformance Test Protocols (CTP) from EN 16454 to an IMS paradigm; or provide new additional tests that are required for the IMS paradigm. Some 14 112-eCall (Pan European eCall) tests provided in EN 16454 are specific to GSM/UMTS circuit switched communications and not appropriate for the IMS paradigm and are therefore excluded from this deliverable.
This document therefore provides a suite of ALL conformance tests for IVS equipment, MNO's, and PSAPS, required to ensure and demonstrate compliance to CEN/TS 17184.
NOTE 4 Because in the event of non-viability or non-existence of an IMS supporting network at any particular time/location, IMS-eCall systems revert to CS networked eCall systems eCall via GSM/UMTS, IVS and PSAPs need to support, and prove compliance to both IMS and CS switched networks.
The Scope covers conformance testing (and approval) of new engineering developments, products and systems, and does not imply testing associated with individual installations in vehicles or locations.

In respect of pan European eCall (operating requirements defined in EN 16072), this document defines
the high level application protocols, procedures and processes required to provide the eCall service via
a packet switched wireless communications network using IMS (IP Multimedia Subsystem) and
wireless access (such as LTE, NR and their successors).
This document assumes support of eCall using IMS over packet switched networks by an IVS and a
PSAP and further assumes that all PLMNs available to an IVS at the time an eCall or test eCall is
initiated are packet switched networks. Support of eCall where eCall using IMS over packet switched
networks is not supported by an IVS or PSAP is out of scope of this document.
At some moment in time packet switched networks will be the only Public Land Mobile Networks
(PLMN) available. However as long as GSM/UMTS PLMNs are available (Teleservice 12/TS12)
ETSI TS 122 003 will remain operational. Both the use of such PLMNs and the logic behind choosing the
appropriate network in a hybrid situation (where both packet-switched and circuit-switched networks
are available) are out of scope of this document.
NOTE 1 The objective of implementing the pan-European in-vehicle emergency call system (eCall) is to
automate the notification of a traffic accident, wherever in Europe, with the same technical standards and the same quality of services objectives by using a PLMN (such as ETSI prime medium) which supports the European harmonized 112/E112 emergency number (TS12 ETSI TS 122 003 or IMS packet switched network) and to provide a means of manually triggering the notification of an emergency incident.
NOTE 2 HLAP requirements for third party services supporting eCall can be found in EN 16102.
This document makes reference to those provisions but does not duplicate them.

This document specifies the set-up of a testing system and the test suite structure and test purposes, i.e. tests to be used to assess the level of interference from RLAN devices operating in the 5,8 GHz range on tolling and tachograph devices operating in the same frequency range.
To obtain generalized results that can subsequently be used to design appropriate mitigation techniques, the test environment and the test cases are designed to:
1.   acquire a large number of transactions on devices of different makes and characteristics;
2.   ensure anonymity of results.
The test results ensure calculation of averages as well as standard deviations.
The tests specified in this document are for the sole purpose of investigating RLAN interference over DSRC communications. Other factors that can impact the performance of DSRC and also the level of interference in a test scenario are not subject to test specifications and out of the scope of this document.

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.

This document specifies the in-vehicle information (IVI) data structures that are required by different intelligent transport system (ITS) services for exchanging information between ITS stations (ITS-S). A general, extensible data structure is specified, which is split into structures called containers to accommodate current-day information. Transmitted information includes IVI such as contextual speed, road works warnings, vehicle restrictions, lane restrictions, road hazard warnings, location-based services and re-routing. The information in the containers is organized in sub-structures called data frames and data elements, which are described in terms of their content and syntax.
The data structures are specified as communications-agnostic. This document does not provide the communication protocols. This document provides scenarios for usage of the data structure, e.g. in case of real time, short-range communications.

This document is a profile of the CEN/TS 16614 series. It focuses on information relevant to feed the necessary accessibility passenger information services and excludes operational and fares information. It is based directly on EPIP (CEN/TS 16614-4).
This European Passenger Information Accessibility Profile (EPIAP) for NeTEx is for exchanging passenger information; it describes how to extend EPIP (the European Passenger Information Profile) with additional information (including a minimal set) to feed the necessary accessibility passenger information services in a European wide and multimodal context. EPIAP especially formulates a mandatory minimal implementation that needs to be filled in by everybody to deliver the necessary information for an assessment of the accessibility of site(s), vehicles and on vehicle-site interaction for impaired persons. The minimal level allows an assessment and contains the information to produce PRM TSI if necessary. It will also cover what the current legislation usually warrants. It then describes how additional information must be provided if an organisation decides to provide it (e.g. the information of the full DELFI+ standard in Germany).
EPIP does not reflect part 5 (New Modes) yet. However, EPIAP takes it into account. EPIP will have to be adapted accordingly.
For EPIAP to be of use, the EC needs to declare the minimal level of EPIAP as mandatory.

This document specifies an additional SIRI functional service to exchange information about Control Actions, between monitoring systems and servers containing real-time public transport vehicle or journey time data. These include the control centres of transport operators, as well as information systems that deliver passenger travel information services. As for Transmodel, public transport modes include new modes of transport (vehicle sharing, vehicle pooling, etc.).
This document describes the SIRI Control Action service, one of a modular set of services for the exchange of Real-time information. The Control Action service (SIRI-CA) is concerned with the exchange of information about decision made concerning the real-time management of the operation of a transport system as performed by operators while operating the services.

This document specifies a graphic data dictionary (GDD), a system of standardized codes for existing road traffic signs and pictograms used to deliver traffic and traveller information (TTI). The coding system can be used in the formation of messages within intelligent transport systems (ITS).

This document contains specifications for a set of ITS station security services required to ensure the authenticity of the source and integrity of information exchanged between trusted entities, i.e.:
—     between devices operated as bounded secured managed entities, i.e. "ITS Station Communication Units" (ITS-SCU) and "ITS station units" (ITS-SU) as specified in ISO 21217; and
—     between ITS-SUs (composed of one or several ITS-SCUs) and external trusted entities such as sensor and control networks.
These services include the authentication and secure session establishment which are required to exchange information in a trusted and secure manner.
These services are essential for many intelligent transport system (ITS) applications and services, including time-critical safety applications, automated driving, remote management of ITS stations (ISO 24102-2), and roadside/infrastructure-related services.

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.

In respect of 112-eCall (pan-European eCall) (operating requirements defined in EN 16072), this document defines the additional high level application protocols, procedures and processes required to provide the eCall service whilst there are still both circuit switched and packet switched wireless communication networks in operation.
NOTE    The objective of implementing the pan-European in-vehicle emergency call system (eCall) is to automate the notification of a traffic accident, wherever in Europe, with the same technical standards and the same quality of services objectives by using a PLMN (such as ETSI prime medium) which supports the European harmonized 112/E112 emergency number (TS12 ETSI TS 122 003 or IMS packet switched network) and to provide a means of manually triggering the notification of an emergency incident.

This European Standard defines the key actors in the eCall chain of service provision as:
1) In-Vehicle System (IVS)/vehicle,
2) Mobile network Operator (MNO),
3) Public safety assistance point [provider](PSAP),
in some circumstances may also involve:
4) Third Party Service Provider (TPSP),
and to provide conformance tests for actor groups 1) - 4).
NOTE Conformance tests are not appropriate nor required for vehicle occupants, although they are the recipient of the service.
This European Standard covers conformance testing (and approval) of new engineering developments, products and systems, and does not imply testing associated with individual installations in vehicles or locations.

In respect of pan-European eCall (operating requirements defined in EN 16072), this document defines the high-level application protocols, procedures and processes required to provide the eCall service using a TS12 emergency call over a circuit-switched mobile communications network.
NOTE 1   The objective of implementing the pan-European in-vehicle emergency call system (eCall) is to automate the notification of a traffic accident, wherever in Europe, with the same technical standards and the same quality of services objectives by using a PLMN (such as ETSI prime medium) which supports the European harmonized 112/E112 emergency number (TS12 ETSI TS 122 003) and to provide a means of manually triggering the notification of an emergency incident.
NOTE 2   HLAP requirements for third-party services supporting eCall can be found in EN 16102, and have been developed in conjunction with the development of this work item, and is consistent in respect of the interface to the PSAP. This deliverable makes reference to those provisions but does not duplicate them.

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 semantics 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.

This document defines an additional data concept that can be transferred as the ‘optional additional data’ part of an eCall MSD, as defined in EN 15722, that can be transferred from a vehicle to a PSAP in the event of a crash or emergency via an eCall communication session.
The purpose of this document is to provide means to notify the PSAP of any limitations to the sending equipment that are endorsed by other standards, but not (immediately) apparent to the receiver. Lack of knowledge about these limitations can hamper the emergency process. This document describes an additional data concept which facilitates the inclusion of information about such limitations in a consistent and usable matter.
This document can be seen as an addendum to EN 15722; it contains as little redundancy as possible.
NOTE 1   The communications media protocols and methods for the transmission of the eCall message are not specified in this document.
NOTE 2   Additional data concepts can also be transferred, and it is advised to register any such data concepts using a data registry as defined in EN ISO 24978 [1]. See www.esafetydata.com for an example.

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.

Existing public and private distribution API specifications will be identified, where practicable, and summarised in a number of ways, including: ownership of specification, scope of API functionality, basis of data model and data categorisation used, management of reference data, commercial access rules to the specification, governance of the specification, existing examples of use for MaaS booking, coherence with existing CEN standards, potential for becoming a new CEN standard.

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 conceptual and logical data model and physical encoding formats for geographic databases for Intelligent Transport Systems (ITS) applications and services. It includes a specification of potential contents of such databases (data dictionaries for Features, Attributes and Relationships), a specification of how these contents shall be represented, and of how relevant information about the database itself may be specified (metadata).
The focus of this document is on ITS applications and services and it emphasizes road and road-related information. ITS applications and services, however, also require information in addition to road and road-related information.
EXAMPLE 1    ITS applications and services need information about addressing systems in order to specify locations and/or destinations. Consequently, information about the administrative and postal subdivisions of an area is essential.
EXAMPLE 2    Map display is an important component of ITS applications and services. For proper map display, the inclusion of contextual information such as land and water cover is essential.
EXAMPLE 3    Point-of-Interest (POI) or service information is a key feature of traveller information. It adds value to end-user ITS applications and services.
Typical ITS applications and services targeted by this document are in-vehicle or portable navigation systems, traffic management centres, or services linked with road management systems, including public transport systems.
The Conceptual Data Model has a broader focus than ITS applications and services. It is application independent, allowing for future harmonization of this document with other geographic database standards.

This document specifies the conceptual and logical data model in addition to the physical encoding formats for geographic databases for Intelligent Transport Systems (ITS) applications and services. This document includes a specification of potential contents of such databases (data dictionaries for Features, Attributes and Relationships), a specification of how these contents are to be represented, and how relevant information about the database itself can be specified (metadata). This document further defines map data used in automated driving systems, Cooperative-ITS, and Multi-modal transport.
The focus of this document is firstly on emerging ITS applications and services, such as Cooperative-ITS and automated driving systems, and it emphasizes road, lane and relevant information on road and lane. However, ITS applications and services also require other information in addition to road and road-related information, which are provided as external databases to connect with GDF and to complement each other. Highly defined public transport databases, for instance, are indispensable in multi-modal transport applications and services in particular. Thus, this document focuses secondly on an expansion of the specification to connect with externally existing databases. It is particularly designed to connect a Transmodel (EN 12896-1 and EN 12896-2) conformant public transport database.
Typical ITS applications and services targeted by this document are in-vehicle or portable navigation systems, traffic management centres, or services linked with road management systems, including public transport systems.
The conceptual data model specified here has a broader focus than ITS applications and services. It is application independent, allowing for future harmonization of this model with other geographic database standards.

This document describes the architecture of a secure process flow between a source ITS system and a destination ITS system to provide an ‘incident support information system’ (ISIS) to emergency responders by accessing (with the agreement of the vehicle owners/keepers) data from a crashed vehicle and/or other vehicles, or drones, in the vicinity of the incident.

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 part of the EN12896-X series (Transmodel-Part 10) takes into account the conceptual data model for the 'new modes' (vehicle pooling, vehicle sharing, taxis, vehicle rental) elaborated within CEN TS 17413 (Models and Definitions for New Modes) and is dedicated to be amended and re- published as a reference data model for the alternative modes of transport (Part 10 of the Public Transport Reference Data Model).
This new publication takes into account the revision of the conceptual model (published as CEN TS 17413) by the project team TC278 PT0303 working on the implementation of the 'new modes' model (NeTEx-Part5).
EN12896-10, supplementing the series of EN12896-X, establishes the semantic reference for the alternative modes data domain and thus facilitates the integration of these modes into the overall mobility environment, in particular into multimodal travel services (e.g. trip planning systems).

Service Interface for Real Time Information (SIRI) is a specification for an interface that allows systems running computer applications to exchange information about the planned, current or projected performance of the public transport operations.
The scope of this WI is to update CEN/EN 15531-2:2015 which allows pairs of server computers to exchange structured real-time information about schedules, vehicles, and connections, together with general informational messages related to the operation of the services. The information can be used for many different purposes, for example:
• To provide real time-departure from stop information for display on stops, internet and mobile delivery systems;
• To provide real-time progress information about individual vehicles;
• To manage the movement of buses roaming between areas covered by different servers;
• To manage the synchronisation of guaranteed connections between fetcher and feeder services;
• To exchange planned and real-time timetable updates;
• To distribute status messages about the operation of the services;
• To provide performance information to operational history and other management systems.
Implementations SIRI have revealed a number of improvements and some minor enhancements necessary for a successful and uniform usage of the specification in the future.
The main elements out of this work item will be:
o Prepare an updated edition of the TS as a document
o Update the common XSD of SIRI parts 1-5
The new work item will consider the projects of
o PT companies and IT-suppliers especially in Switzerland, Germany, France, Netherlands and Sweden
o Railway traffic
o accessibility in public transport

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, based on ISO/TS 19468, specifies a platform-specific method for implementing data exchange among centres based on simple object access protocol (SOAP), supporting the EN 16157 series (DATEX II) for Push/Pull data delivery and service request/feedback collaborative intelligent transport system (ITS) services.
This document defines the message rules and procedures for communication between transport information and control systems using XML (Profile B).
This document clarifies how to package end-application messages and relevant data.
The payload data definition used in specific end-applications and the exact structure of the content payload delivered in the messages are beyond the scope of this document.
Rules and procedures for exchanging data-packets in lower communication layers are also out of the scope of this document. These functionalities can be implemented using generic protocols defined in the industry standards. However, this document does define how to use these protocols.

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.

The objective of implementing the pan-European in-vehicle emergency call system (eCall) is to automate the notification of a traffic accident, wherever in Europe, with the same technical standards and the same quality of services objectives by using 'Public Land Mobile Networks'(PLMN) (such as GSM and UMTS), which supports the European pre-assigned emergency destination address (see normative references) and to provide a means of manually triggering the notification of an incident.
This document specifies the general operating requirements and intrinsic procedures for in-vehicle emergency call (eCall) services in order to transfer an emergency message from a vehicle to a Public Safety Answering Point (PSAP) in the event of a crash or emergency, via an eCall communication session and to establish a voice channel between the in-vehicle equipment and the PSAP.
Private third party in-vehicle emergency supporting services may also provide a similar eCall function by other means. The provision of such services are defined in EN 16102, and are outside the scope of this document.
The communications protocols and methods for the transmission of the eCall message are not specified in this document.
This document specifies the operating requirements for an eCall service. An important part of the eCall service is a Minimum Set of Data (MSD). The operating requirements for the MSD are determined in this document, but the form and data content of the MSD is not defined herein. A common European MSD is determined in EN 15722.
This document does not specify whether eCall is provided using embedded equipment or other means (for example in the case of aftermarket equipment).

In respect of 112-eCall (operating requirements defined in EN 16072), this document defines adaptations to eCall specifications defined in EN 16072 and other related documents to enable the provision of eCall for Powered Two Wheel Vehicles.
As with the existing provisions for eCall for Category M1/N1 vehicles, these are specified within the paradigm of being OEM fit equipment supplied with new vehicles.
For the purposes of the present document, the P2WV ‘L’ categories, as defined in Directive 2002/24/EC, Regulation (EU) No 168/2013, UNECE and as referenced/specified in EN 15722 apply.
This document includes only the requirements for Category L1 and L3 P2WV (vehicle based) with the exception of L1e-A (powered cycle), although other documents may subject other ‘L’ subcategories to use this document. Other Technical Specifications may be prepared for other UNECE category ‘L’ variants.
This document is a revision of CEN/TS 17249-5:2019 based on results achieved in sAFE project (sub-activity 3.5) [11] to obtain a specification allowing a more practical implementation of eCall for P2WVs.
The specifications herein relate only to the provision of pan-European eCall, and does not provide specifications for third party service provision of eCall. Other than in the 112-eCall paradigm, which involves a direct call from the vehicle to the most appropriate PSAP, third party service provision involves the support of an intermediary third party service provider before the call is forwarded to the PSAP.
NOTE   The provision of eCall for vehicles via the aftermarket (post sales and registration), and the operational requirements for any such aftermarket solution. will be the subject of other work, that will use the specifications of this document as a principle reference point.

The SIRI Situation Exchange service (SIRI-SX) allows the efficient exchange of data about Situations caused by planned and unplanned incidents and events and is intended to support the use cases identified in Annex C. Situations are actual or potential perturbations to normal operation of a transport network. The SIRI-SX service uses the common SIRI communication framework and services which are described in EN 15531-1 and not repeated in this document.
The Situation Exchange service has a rich Situation model, allowing a structured description of all aspects of multimodal travel Situations, including cause, scope, effect and rules for distribution to an audience. The structured values enabling computer based distribution through a wide variety of channels, and the presentation of data in different formats for different device and different audiences. The Situation Exchange Service allows the exchange of incident and event information between, amongst others:
-   Control centres;
-   Operations Staff;
-   Public Information systems;
-   Alert systems and personalised alert systems;
-   UTMC systems;
-   Journey planners;
-   AVMS (Automatic Vehicle Management Systems).
SIRI-SX uses a network model based on the CEN Transmodel conceptual model for Public Transport networks, schedules and operations, along with the CEN Identification of Fixed Objects in Public Transport (IFOPT) model for describing physical transport interchanges that is an integrated part of CEN Transmodel conceptual model for Public Transport networks.
The Situation Exchange service is envisaged as a 'back office' capture and exchange service that will feed other public facing travel information dissemination systems in particular those using the TPEG format. Transport Protocol Expert Group (TPEG) is a European Broadcasting Union fostered standard for broadcasting travel data over Digital Assisted Broadcasting (DAB) radio and other channels. TPEG is maintained by the Traveller Information Services Association (TISA). To this end, the SIRI-SX situation classification model has been harmonized as far as possible with that of TPEG and DATEX2 so that full interoperability can be achieved. Uses of structured elements from TPEG, for which translations already exist in most European languages, also facilitates human readability in different national languages. Maintaining and improving a harmonization with TPEG will be a continuing objective. In addition to the TPEG exchangeable content, SIRI-SX messages contain additional structured information which allows them to be processed in additional ways.
Situation and computer systems and applications are typically distributed, that is information will be captured on one system and exchanged with others for dissemination and further processing. This means that a message design is needed that allows the management of the identity of distributed messages over time and across different systems, so that subsequent updates to a Situation can be reconciled by different systems over a network, and obsolete messages can be retired automatically. The SIRI-SX SITUATION model is designed to support the distributed management of Situations.

This document provides a Guide to Intelligent transport system standards deliverables from CEN and ISO, and other associated deliverables from other SDOs, together with hotlinks to their source, and to other relevant and related information and Regulations.

There are many potential ways for passenger transport operations centres to interact. The approach taken by SIRI is for an open-ended set of standard data structures, carried over a communications channel constructed using one of a small number of specific options.
Part 2 of this document specifies the communications channel. This Part 3 section specifies a number of functional modules, based on the ‘use cases’ identified in Annex B to Part 1:
-   Production Timetable (PT): this service enables the provision of information on the planned progress of vehicles operating a specific service, identified by the vehicle time of arrival and departure at specific stops on a planned route for a particular Operational Day.
-   Estimated Timetable (ET): this service enables the provision of information on the actual progress of Vehicle Journeys operating specific service lines, detailing expected arrival and departure times at specific stops on a planned route. There will be recorded data for stops which have been passed, and predicted data for stops not yet passed. In addition the Estimated Timetable service allows Vehicle Journeys to be cancelled, added or changed.
-   Stop Timetable (ST): this service provides a stop-centric view of timetabled vehicle arrivals and departures at a designated stop. It can be used to reduce the amount of information that needs to be transmitted in real-time to stops and displays, as reference data for a Stop Monitoring Service; and provides a data feed of the static timetables.
-   Stop Monitoring (SM): this service provides a stop-centric view of vehicle arrivals and departures at a designated stop. It can be used by displays and other presentation services to provide departure board and other presentations of timetable and real-time journey information both at stops and at a distance.
-   Vehicle Monitoring (VM): this service enables the provision of information on the current location and status of a set of vehicles. It provides all the current relevant information from one AVMS relating to all vehicles fulfilling a set of selection criteria.
-   Connection Timetable (CT): this service may be used to provide information about the scheduled arrivals of a feeder vehicle to the operator of a connecting distributor service. The distributor operator can then plan how to guarantee the connection, either with the expected vehicle or a different vehicle.
-   Connection Monitoring (CM): this service is used to provide information about the expected arrival of a feeder vehicle to the operator of a connecting distributor service. The distributor operator can then manage the service to guarantee the connection, based on actual vehicle running.
-   General Message (GM): the SIRI "General Message" service is used to exchange informative messages between identified individuals in free or an arbitrary structured format. It enables messages to be sent and to be revoked. Messages are assigned validity periods in addition to the actual content.

1.1   Interfaces specified by this document
1.1.1   Business Context
Real-time information may be exchanged between a number of different organisations, or between different systems belonging to the same organisation. Key interfaces include the following:
-   Between public transport vehicle control centres - generally, for fleet and network management.
-   Between a control centre and an information provision system - generally, to provide operational information for presentation to the public.
-   Between information provision systems - generally, sharing information to ensure that publicly available information is complete and comprehensive.
-   Between information provision systems - and data aggregation systems that collect and integrate data from many different sources and different types of data supplier and then distribute it onwards.
-   Between information provision systems and passenger information devices such as mobile phones, web browsers, etc.
Annex B describes the business context for SIRI in more detail.
SIRI is intended for wide scale, distributed deployment by a wide variety of installations. In such circumstances it is often not practical to upgrade all the systems at the same time. SIRI therefore includes a formal versioning system that allows for the concurrent operation of different levels at the same time and a disciplined upgrade process.
In this general framework, SIRI defines a specific set of concrete functional services. The services separate the communication protocols from the message content (‘functional services’). This allows the same functional content to be exchanged using different transport mechanisms, and different patterns of exchange. Figure 1 below shows this diagrammatically.
1.1.2   SIRI Communications
SIRI provides a coherent set of functional services for exchanging data for different aspects of PT operation. A common data model, based on Transmodel 6.0, is used across all services.
...

This new work item will revise and extend the sixth part of the DATEX II Technical Specifications which defines three DATEX II parking-related publications and a truck parking profile and that supports the exchange of static as well as dynamic information about parking facilities and areas, including intelligent truck parking as defined by the Directive 2010/40/EU priority action e as well as urban parking as specified in action a.
The formerly used Level B extension will be replaced by a new namespace in the context of version 3.0 of DATEX II.
The publications are intended to support the exchange of informational content from the organisation performing measurements and collecting/eliciting basic data to other organisations providing ITS services or onward information exchange. It is the ambition to harmonise existing information models from different sources such as EasyWay deployment guidelines and truck parking initiatives, and to liaise with the stakeholders involved, especially with the Alliance for Parking Data Standards and CEN/TC 278 working group 3.

1.1   General
NeTEx is dedicated to the exchange of scheduled data (network, timetable and fare information). It is based on Transmodel European reference model for PT data. The most recent version of NeTEx v1.1 is based on the most recent version of Transmodel, V6.0 (EN 12986 1/2/3/4/5/6), which now incorporates the prior IFOPT (EN 28701). NeTEx also relates to SIRI (CEN 15531-1/2/3/4) and supports the exchange of information of relevance for passenger information about public transport services and also for running Automated Vehicle Monitoring Systems (AVMS).
NOTE   NeTEx is an implementation of a subset of Transmodel (including IFOPT); the definitions and explanations of its concepts are extracted directly from Transmodel and reused in NeTEx, sometimes with adaptations in order to fit the NeTEx context. Although the data exchanges targeted by NeTEx Parts 1 to 5 are predominantly oriented towards provisioning passenger information systems, AVMS and fare systems with data from transit scheduling systems, it is not restricted to this purpose and NeTEx can also provide an effective solution to many other use cases for transport data exchange.
1.2    Alternative Modes Scope
This Part 5 of NeTEx is specifically concerned with the exchange of reference data to support “new” alternative modes for mobility services, adding certain new concepts to the NeTEx schema (indicated as NeTEx v1.2.2), but also to a high degree making use of existing schema elements defined in NeTEx Parts 1, 2 and 3.
The high-level design for alternative modes support is derived from a conceptual model for alternative modes CEN PT1711 (CEN/TS 17413:2020) prepared by CEN working group TC278 WG17. This CEN Technical Specification describes a conceptual model for alternative modes as an extension to Transmodel V6.0 and based on a detailed set of use cases taken from CEN PT1711 and given in Appendix A.
The NeTEx format is concerned with a subset of the use cases for reference data (real-time use cases are covered by dynamic protocols such as SIRI and DATEX II). Overall, it is concerned with data for the following purposes:
-   to be able to integrate legs made on alternative modes with conventional mode legs in seamless trip plans;
-   to describe the coverage areas of alternative mode mobility services so that trip planning engines and others can make passengers aware of the possibility of using them, and provide appropriate links to invoke the dynamic services;
-   to be able to find the locations of access points for alternative mode services, such as parking points, pooling stations, etc. including their relation to access points for conventional modes;
-   to be able to indicate the costs of the mobility services for specific trip legs. Where operators offer a bundle of modes services (for example free cycle use with metro use) to be able to include the “fare product” for alternative mode legs in the sales offer;
-   to be able to indicate how to book, purchase and pay for mobility services, and how to access them.
NeTEx is primarily concerned with the exchange of reference data to allow the integration of new modes with other data; it does not describe dynamic services. The PT1711 specification indicates the nature of some of these services such as trip planning.
1.3   Transport modes
All mass public transport modes are taken into account by NeTEx, including train, bus, coach, metro, tramway, ferry, air, and their submodes. Such modes are provided by transport operators, who may operate one or more modes.
NeTEx part 5 widens the concept of an operator to include providers of other forms of transport, and introduces the separate concept of a “mode of operation” to classify the way services are provided: conventional, flexible, pooling, sharing, etc.
...

This document specifies and defines component facets supporting the exchange and shared use of data and information in the field of traffic and travel.
The component facets include the framework and context for exchanges, the modelling approach, data content, data structure and relationships.
This document is applicable to:
—   Traffic and travel information which is of relevance to road networks (non-urban and urban) ;
—   Public transport information that is of direct relevance to the use of a road network (e.g. road link via train or ferry service) ;
—   Traffic and travel information in the case of Cooperative intelligent transport systems (C-ITS).
This document establishes specifications for data exchange between any two instances of the following actors:
—   Traffic Information Centres (TICs);
—   Traffic Control Centres (TCCs);
—   Service Providers (SPs);
—   Use of this document may be applicable for other actors.
This document series covers, at least, the following types of informational content:
—   Road traffic event information – planned and unplanned occurrences both on the road network and in the surrounding environment;
—   Operator initiated actions;
—   Road traffic measurement data, status data, and travel time data;
—   Travel information relevant to road users, including weather and environmental information;
—   Road traffic management information and instructions relating to use of the road network.
This Part of CEN/TS 16157 specifies the informational structures, relationships, association ends, attributes and associated data types required for publishing information about facilities within the DATEX II framework. This is specified as a DATEX II "Facilities" namespace, which is part of the DATEX II platform independent model, but this Part excludes those elements that are specified in EN 16157-2 (Location referencing) and EN 16157-7 (Common data elements).

This document specifies a publication sub-model within the DATEX II model that supports the publication of electronic traffic regulations.
This publication is intended to support the exchange of informational content from road traffic authorities issuing traffic regulation orders and organisations implementing these orders to other organisations providing ITS services or onward information exchange.

The EN 16157 series specifies and defines component facets supporting the exchange and shared use of data and information in the field of traffic and travel.
The component facets include the framework and context for exchanges, the modelling approach, data content, data structure and relationships.
The EN 16157 series is applicable to:
- traffic and travel information which is of relevance to road networks (non-urban and urban);
- public transport information that is of direct relevance to the use of a road network (e.g. road link via train or ferry service);
- traffic and travel information in the case of Cooperative intelligent transport systems (C-ITS).
This series establishes specifications for data exchange between any two instances of the following actors:
- Traffic Information Centres (TICs);
- Traffic Control Centres (TCCs);
- Service Providers (SPs).
Use of this series can be applicable for use by other actors.
This series covers, at least, the following types of informational content:
- road traffic event information – planned and unplanned occurrences both on the road network and in the surrounding environment;
- operator initiated actions;
- road traffic measurement data, status data, and travel time data;
- travel information relevant to road users, including weather and environmental information;
- road traffic management information and instructions relating to use of the road network.
This part of the CEN/TS 16157 series specifies details of infrastructure for vehicle energy supply. The provided data model is separated into two publications for static and dynamic information. The static information regarding the infrastructure is not subject to frequent changes, whereas the dynamic part offers the ability to provide highly up-to-date information. The static part covers all relevant information on vehicle energy infrastructure, e.g. sites, stations and refill points for electric vehicles as well as petrol, gasoline or gas-based refuelling for vehicles. In terms of dynamic information, the availability of the infrastructure, possible faults and a price indication are covered.

This document defines and specifies component facets supporting the exchange and shared usage of data and information in the field of traffic and travel.
The component facets include the framework and context for exchanges, the data content, structure and relationships necessary and the communications specifications, in such a way that they are independent from any defined technical platform.
This document establishes specifications for data exchange between any two instances of the following actors:
—    Traffic information centres (TICs);
—    Traffic control centres/Traffic management centres (TCCs/TMCs);
—    Service providers (SPs).
This document can also be applied for use by other actors, e.g. car park operators.
This document includes the following types of information:
—   use cases and associated requirements, and features relative to different exchange situations;
—   different functional exchange profiles;
—   abstract elements for protocols;
—   data model for exchange (informational structures, relationships, roles, attributes and associated data types required).
In order to set up a new technical exchange framework, it is necessary to associate one functional exchange profile with a technical platform providing an interoperability domain where plug-and-play interoperability at a technical level can be expected. The definition of such interoperability domains is out of scope of this document but can be found in other International Standards or Technical Specifications (e.g. the ISO 14827 series).
This document is restricted to data exchange. Definition of payload content models is out of the scope of this document.

This document specifies an additional SIRI functional service to exchange information about changes to availability of facilities, between monitoring systems and servers containing real-time public transport vehicle or journey time data. These include the control centres of transport operators, as well as information systems that deliver passenger travel information services. As for Transmodel, public transport modes include new modes of transport (vehicle sharing, vehicle pooling, etc.).
This document describes the SIRI Facility Monitoring service, one of a modular set of services for the exchange of Real-time information. The Facility Monitoring service (SIRI-FM) is concerned with the exchange of information about alterations to the availability of facilities for passengers among systems, including equipment monitoring, real-time management and dissemination systems.

This document specifies:
personalization interface;
physical systems: on-board equipment (OBE), personalization equipment (PE) and integrated circuit(s) cards (ICCs);
electronic fee collection (EFC) personalization functions between the PE and the OBE in accordance with ISO/TS 21719-1 when using an ICC;
data and security elements that are transferred between the PE and the OBE using the ICC.
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, etc.);
legal issues;
the exact commands and security functionality within ISO/IEC 7816-4 used by the PE and the OBE, respectively, to interface an ICC.
NOTE         Some of the issues that are outside the scope of this document are the subject of separate standards prepared by CEN/TC 278 and ISO/TC 204.

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.

The ALERT-C protocol is designed to provide mostly event-oriented road end-user information messages.
This document specifies the messages which are presented to the user in accordance with a set of general requirements. It defines the message structure and content and its presentation to the end-user.
The message management component of this document describes the message management functions of RDS-TMC. The ALERT-C protocol distinguishes between user messages and system messages. User messages are those potentially made known to the end-user, as defined in Clause 5. System messages are of use only to the RDS-TMC terminal, for message management purposes.
RDS-TMC information comprises both ?system information' and ?user messages'. System information relates to the TMC service and details the parameters that the terminal needs to be able to find, identify and decode the TMC information. System information is transmitted in type 3A groups and in type 8A groups.
User messages contain the details of the traffic events; these may use one or more type 8A groups. Most messages may be transmitted using a single type 8A group, however messages with more detail (e.g. diversion advice) may use up to a total of five, type 8A groups.
The transmission component of this document conveys the messages over-air. The ALERT-C protocol, used by RDS-TMC, has the fundamental approach of aiming to code most messages entirely within a single RDS group.
The ALERT-C Event List, which contains all event descriptions, is described in ISO 14819‑2.

This European Standard (EN 16157 series) specifies and defines component facets supporting the exchange and shared use of data and information in the field of traffic and travel.
The component facets include the framework and context for exchanges, the modelling approach, data content, data structure and relationships.
This European Standard is applicable to:
-   Traffic and travel information which is of relevance to road networks (non-urban and urban),
-   Public transport information that is of direct relevance to the use of a road network (e.g. road link via train or ferry service),
-   Traffic and travel information in the case of Cooperative intelligent transport systems (C-ITS).
This European Standard establishes specifications for data exchange between any two instances of the following actors:
-   Traffic Information Centres (TICs),
-   Traffic Control Centres (TCCs),
-   Service Providers (SPs),
Use of this European Standard may be applicable for use by other actors.
This European Standard series covers, at least, the following types of informational content:
-   Road traffic event information – planned and unplanned occurrences both on the road network and in the surrounding environment,
-   Operator initiated actions,
-   Road traffic measurement data, status data, and travel time data,
-   Travel information relevant to road users, including weather and environmental information,
-   Road traffic management information and instructions relating to use of the road network.
This part of the CEN/TS 16157 series specifies the informational structures, relationships, roles, attributes and associated data types required for publishing variable message sign information within the Datex II framework. This is specified in two publications, a DATEX II VMS Table Publication sub-model and a VMS Publication sub-model, which are part of the DATEX II platform independent model, but this part excludes those elements that relate to:
-   location information which are specified in EN 16157-2,
-   common information elements, which are specified in EN 16157-7,
-   situation information which are specified in EN 16157-3.
The VMS Table Publication supports the occasional exchange of tables containing generally static reference information about deployed VMS which enable subsequent efficient references to be made to pre-defined static information relating to those VMS. The VMS Publication supports the exchange of the graphic and textual content of one or several VMS plus any status information on device configuration that aid the comprehension of the informational content. This content is potentially subject to rapid change.
These publications are not intended to support the control or configuration of VMS equipment. Each is part of the DATEX II platform independent model.

ISO 14819-1 describes the ALERT-C protocol concept and message structure used to achieve densely coded messages to be carried in the RDS-TMC feature. This document specifies the `Events List' to be used in coding those messages.

This document specifies location referencing rules to address the specific requirements of Traffic Message Channel (TMC) systems, which use abbreviated coding formats to provide traffic and travel information (TTI) messages over mobile bearers (e.g. GMS, DAB) or via exchange protocols like DATEX
II. In particular, the rules address the Radio Data System-Traffic Message Channel (RDS-TMC), a means
of providing digitally-coded TTI to travellers using a silent data channel on FM radio stations, based on the ALERT-C protocol.

Within the context of 112-eCall (operating requirements defined in EN 16072), this document defines specifications for the provision of 112-eCall for regulated commercial vehicles, including rigid body trucks and variants thereof, prime mover and trailer combinations (sometimes called "semi’s", road trains [one prime mover with multiple trailers]) and other regulated commercial vehicles (for example vans carrying medical supplies or radioactive material).
The work of CEN/TS 16405 is adopted and extended in this document. (A revised version of CEN/TS 16405 will remain the principal reference document for the content and definition of the commercial vehicle optional additional data set).
As with the existing provisions for 112-eCall for Category M1/N1 vehicles, these are specified within the paradigm of being OEM fit equipment supplied with new vehicles.
The scope of this specification is limited to the provision of eCall from a commercial vehicle prime mover /rigid body truck) designed for conveying cargo. (UNECE Category N).
This document specifies the requirements for the use of 112-eCall by a commercial vehicle prime mover /rigid body truck and defines the interface between the PSAPs and an external transport database.
Unless superseded by European Regulation at some future date, all data schemas specified herein and defined in a revision of CEN/TS 16405 are “Optional Additional Data” (OAD) concepts, as enabled in accordance with EN 15722:2020 as part of the minimum set of data As OAD they, and the elements within them, are, by definition, “optional” with use at the discretion of the operator of the vehicle.
This document defines how eCall for commercial vehicles is expected to interact with the future eFTI standards and the prerequisites for these standards to allow the access to the relevant freight information for the PSAPSs in case of an eCall.
NOTE 1 The provision of eCall from IVS located within trailers is not included in this document, but could be the subject of a further standards deliverable.
NOTE 2 The provision of eCall for vehicles via the aftermarket (post sale and registration) will be the subject of other work, and in respect of the operational requirements for any such aftermarket solutions for commercial vehicles, will use this document as a principle reference point.
NOTE 3 The 112-eCall paradigm involves a direct call from the vehicle to the most appropriate PSAP (third party service provision by comparison, involves the support of an intermediary third party service provider before the call is forwarded to the PSAP). The specifications herein relate only to the provision of 112-eCall or IMS-112-eCall, and do not provide specifications for third party service provision of eCall, although in the case of 112-eCall for commercial vehicles, links to third party provision of service aspects (such as cargo contents) could be required.