03.220.20 - Road transport
ICS 03.220.20 Details
Road transport
Stra?enverkehr
Transport routier
Cestni transport
General Information
e-Library Subscription
Create subscription and get permanent access to documents within 03.220.20 - Road transport
Currently subscription includes documents marked with .We are working on making all documents available within the subscription.
This document specifies security means and procedures for AVPS Type 3 as specified in ISO 23374-1. It focuses on operation interfaces and management interfaces as defined in ISO 23374-1.
- Technical specification44 pagesEnglish languagesale 15% off
- Draft44 pagesEnglish languagesale 15% off
- Draft44 pagesEnglish languagesale 15% off
This document defines an additional data concept that may be transferred as the ‘optional additional data ’ part of an eCall MSD, as defined in EN 15722, that may 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.
- Standard18 pagesEnglish languagesale 10% offe-Library read for1 day
- Draft18 pagesEnglish languagesale 10% offe-Library read for1 day
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.
- Draft55 pagesEnglish languagesale 10% offe-Library read for1 day
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.
- Draft54 pagesEnglish languagesale 10% offe-Library read for1 day
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.
- Standard49 pagesEnglish languagesale 15% off
This document gives guidance on ethical considerations with regards to road traffic safety of autonomous vehicles (AVs). It is applicable to vehicles in level 5 mode according to SAE J3016 in 2022, as part of its report. This document does not apply to the technical method used to control the decision-making process, nor does it give any guidance on the desired outcomes of those decisions; it gives guidance on ethical aspects for consideration in the design of decision-making process. This document does not set requirements for the outcomes of ethical decisions, nor does it offer guidance on methodology. It only details aspects of the behaviour of AVs for which considerations may be made by the designer/manufacturer to ensure that key aspects are not overlooked or disregarded. This document does not offer the technical precision to prescribe the required controls but would, rather, offer a set of “protocol guidelines” that all decision makers regarding automated driving could choose to self-certify against to assure that the desired necessary ethical considerations were addressed during design and effectively controlled.
- Standard44 pagesEnglish languagesale 15% off
- Draft44 pagesEnglish languagesale 15% off
Automated valet parking systems (AVPSs) perform level 4 automated driving of individual or multiple unoccupied vehicles within a prescribed area of a parking facility. This document specifies performance requirements for the operation functions, the environmental conditions within parking facilities where automated vehicle operation is performed, and the test procedures to verify the performance requirements. An AVPS is comprised of physically separated sub-systems distributed among vehicles, facility equipment and user domains. The functionalities of AVPSs are realized by cooperation of these sub-systems, which are, in many cases, provided by different organizations. This document defines the system architecture and the communication interfaces between the sub-systems at the logical level. An AVPS manages its system participants (i.e. AVPS-compliant vehicles and parking facilities) and provides interfaces to other facility users and involved persons (e.g. system operators, facility managers). This document contains requirements for the management functions such as checking compatibility between vehicles and parking facilities, performing remote assistance and recovery when automated driving cannot be performed, and executing operation stop commands in response to the actions of other facility users. AVPSs are intended for use by a service provider upon receiving authority over vehicles from individual service recipients. This document does not include parking automation technologies that are solely based on usage by an individual user. If the vehicle is put into driverless operation directly by the user, this is not considered to be part of the AVPS.
- Standard153 pagesEnglish languagesale 15% off
- Technical specification146 pagesEnglish languagesale 15% off
- Draft146 pagesEnglish languagesale 15% off
- Draft146 pagesEnglish languagesale 15% off
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.
- Standard18 pagesEnglish languagesale 10% offe-Library read for1 day
- Draft18 pagesEnglish languagesale 10% offe-Library read for1 day
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.
- Standard61 pagesEnglish languagesale 10% offe-Library read for1 day
- Draft59 pagesEnglish languagesale 10% offe-Library read for1 day
It defines the test suite structure and the test purposes for conformity evaluation of on-board and roadside equipment designed for compliance with the requirements set up in EN 15509.
- Standard122 pagesEnglish languagesale 10% offe-Library read for1 day
- Draft147 pagesEnglish languagesale 10% offe-Library read for1 day
Motorway chauffeur systems (MCS) perform Level 3 automated driving on limited access motorways with the presence of a fallback-ready user (FRU). MCS can be implemented in various forms capable of responding to different driving scenarios. This document describes a framework of MCS including system characteristics, system states/transition conditions and system functions. MCS are equipped with a basic set of functionalities to perform in-lane operation and can also be equipped with additional functionalities such as lane changing. This document specifies requirements of the basic set of functionalities and test procedures to verify these requirements. The requirements include vehicle operation to perform the entire dynamic driving task (DDT) within the current lane of travel, to issue a request to intervene (RTI) before disengaging, and to extend operation and temporarily continue to perform the DDT after issuing an RTI. This document describes one specific form of system engagement. Other forms are possible. These other system engagement forms, especially those provided in combination with other driving automation system features, are not within the scope of this document. Requirements and test procedures for the additional functionalities are provided in other parts of the ISO 23792 series. Means related to setting a destination and selecting a route to reach the destination are not within the scope of this document. This document applies to MCS installed in light vehicles.
- Technical specification30 pagesEnglish languagesale 15% off
- Draft30 pagesEnglish languagesale 15% off
- Draft30 pagesEnglish languagesale 15% off
This document defines the charging performance metrics to be used during the evaluation or on-going monitoring of an electronic fee collection (EFC) system and the examination framework for the measurement of these metrics. It specifies a method for the specification and documentation of a specific examination framework which can be used by the responsible entity to evaluate charging performance for a particular information exchange interface or for overall charging performance within a toll scheme. The following scheme types are within the scope of this document: a) discrete schemes; b) continuous schemes (autonomous type of systems). This document defines measurements only on standardized interfaces. This document defines metrics for the charging performance of EFC systems in terms of the level of errors associated with charging computation. This document describes a set of metrics with definitions, principles and formulations, which together make up a reference framework for the establishment of requirements for EFC systems and the subsequent examination of charging performance. This document defines metrics for the following information exchanges: — charge reports (including usage evidence); — toll declarations; — exception lists; — billing details and associated event data; — payment claims on the level of service user accounts; — end-to-end metrics which assess the overall performance of the charging process. These metrics focus solely on the outcome of the charging process, i.e. the amount charged in relation to a pre-measured or theoretically correct amount, rather than intermediate variables from various components as sensors, such as positioning accuracy, signal range or optical resolution. This approach ensures comparable results for each metric in all relevant situations. The following aspects are outside the scope of this document. — Definition of specific numeric performance bounds, or average or worst-case error bounds in percentage or monetary units. — Specification of a common reference system which would be required for comparison of performance between systems. — Measurements on proprietary interfaces. NOTE It is not possible to define standardized metrics on such system properties. Neither is it possible to define metrics for parts of the charging processing chain which are considered to be the internal matter of an interoperability partner, such as: — equipment performance, e.g. for on-board equipment (OBE), roadside equipment (RSE) or data centres such as signal range, optical resolution or computing system availability; — position performance metrics: the quality of data generated by position sensors is considered as an internal aspect of the GNSS front end. It is masked by correction algorithms, filtering, inferring of data and the robustness of the charge object recognition algorithms. — The evaluation of the expected performance of a system based on modelling and measured data from a trial at another place.
- Technical specification118 pagesEnglish languagesale 15% off
- Draft120 pagesEnglish languagesale 15% off
- Draft120 pagesEnglish languagesale 15% off
This document defines the TPEG Speed information (SPI) application for reporting speed information for travellers. Speed limits are usually indicated to the driver through roadside signs. Drivers who are aware of the speed limit at all times are more likely to drive safely, which improves road safety. Most speed limit signs are static and remain unchanged for years and are thus available through navigation system map databases. However, there is an increasing number of variable message signs, temporary signing (e.g. for road works) and also changed speed limits which are not yet reflected in the map databases. With the TPEG-SPI application, speed limit information is offered in an accurate way so that different lanes and different vehicle types can be differentiated. TPEG-SPI also allows the drivers to be aware of the current allowed (maximum) speed, by delivering timely information about the current position and values of speed limits to the navigation or driver assistance systems. These data are seen as informational and are intended to be encoded in a compact way to minimize bandwidth consumption. TPEG2-SPI supports direct and indirect speed limits. Direct speed limits are used for signs showing a maximum speed at which a vehicle is allowed to travel. Such speed limit signs can be static or dynamic. Indirect speed limits refer to the speed of other road users. It is primarily the vehicle in front of the own vehicle that is used as a reference.
- Standard35 pagesEnglish languagesale 15% off
- Draft33 pagesEnglish languagesale 15% off
This standard 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 can be specified (metadata).
The focus of this standard 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.
Typical ITS applications and services targeted by this International Standard 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 standard with other geographic database standards.
In order to deal with a multiple data provider environment and new applications, conceptual models, features, attributes and relationships are expanded in GDF5.1.
GDF5.1 is separated into two parts according to methods of utilization.
GDF5.1 Part 1 defines application-independent map data shared between multiple sources.
GDF5.1 Part 2 defines map data used in automated driving systems, cooperative ITS, and multi-modal transport.
- Standard1077 pagesEnglish languagesale 10% offe-Library read for1 day
- Draft1074 pagesEnglish languagesale 10% offe-Library read for1 day
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.
- Technical specification33 pagesEnglish languagesale 10% offe-Library read for1 day
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.
- Standard131 pagesEnglish languagesale 10% offe-Library read for1 day
- Draft130 pagesEnglish languagesale 10% offe-Library read for1 day
This standard 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 can be specified (metadata).
The focus of this standard 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.
Typical ITS applications and services targeted by this International Standard 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 standard with other geographic database standards.
In order to deal with a multiple data provider environment and new applications, conceptual models, features, attributes and relationships are expanded in GDF5.1.
GDF5.1 is separated into two parts according to methods of utilization.
GDF5.1 Part 1 defines application-independent map data shared between multiple sources.
GDF5.1 Part 2 defines map data used in automated driving systems, cooperative ITS, and multi-modal transport.
- Standard604 pagesEnglish languagesale 10% offe-Library read for1 day
- Draft601 pagesEnglish languagesale 10% offe-Library read for1 day
This document defines an index to the complete set of TPEG Generation 2 toolkit components and applications. New applications are enumerated with an application identification (AID) as they are added to the TPEG applications family. NOTE 1 This document will be updated when new applications occur in order to indicate the latest status and the inter-working of the various TPEG specifications. This document will be revised as a new edition every time a new issue of any other specification is issued. NOTE 2 Preliminary AIDs are allocated and managed by TISA and are listed at Reference.
- Standard9 pagesEnglish languagesale 15% off
This document specifies basic control strategies, minimum functional requirements, basic driver interface elements, and test procedures for verifying the system requirements for collision evasive lateral manoeuvre systems (CELM). A CELM is a safety system aimed at supporting the driver’s vehicle operation by avoiding collisions with objects in the forward path of the vehicle. When a collision is predicted, the CELM controls lateral movement of the vehicle by generating yaw moment. The lateral control manoeuvres can be performed automatically by CELM or can be initiated by the driver and supported by CELM. Specific methods for object detection and other environmental perception technologies are not described in this document. This document applies to light vehicles and heavy trucks. Vehicles equipped with trailers are not within the scope of this document.
- Standard31 pagesEnglish languagesale 15% off
This document: — examines and analyses the safety environment for low-speed automated driving services (LSADS); — describes the safety role supplement to the functional model described in ISO/TS 5255-1; — describes the supplemental safety points for LSADS; — describes role for the functional model of service applications for LSADS. This document can contribute to the development of future automated driving system service safety requirement use cases, other than the one described in ISO/TS 5255-1. This document is applicable to services using LSADS-equipped vehicles only. In-vehicle control system is not in scope of this document.
- Technical report9 pagesEnglish languagesale 15% off
- Technical report9 pagesEnglish languagesale 15% off
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.
- Standard131 pagesEnglish languagesale 10% offe-Library read for1 day
- Draft130 pagesEnglish languagesale 10% offe-Library read for1 day
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.
- Standard1077 pagesEnglish languagesale 10% offe-Library read for1 day
- Draft1074 pagesEnglish languagesale 10% offe-Library read for1 day
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.
- Standard121 pagesEnglish languagesale 15% off
- Standard129 pagesFrench languagesale 15% off
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.
- Standard604 pagesEnglish languagesale 10% offe-Library read for1 day
- Draft601 pagesEnglish languagesale 10% offe-Library read for1 day
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.
- Technical specification33 pagesEnglish languagesale 10% offe-Library read for1 day
A gap analysis related to the use of vehicle licence plate information and ANPR technology in EFC systems, notably based on DSRC and GNSS, provisionally covering
• State of play (user needs, existing regulations and standards)
• Recommendations regarding the use of existing standards
• Recommendations to close identified gaps, notably in terms of proposed (extensions of or new) standards
• Informative annexe on use cases, such as
o Degraded mode – usage of white lists
o Trip (re)construction
o Occasional users: pre-registration for a given trip, for a period
o Occasional users: post-trip actions to ensure voluntary compliance
o Non-compliance – OBE mounted in wrong vehicle
o Non-compliance – detection of fraudulent user
It is outside the scope of this document to define Interoperable Toll collection Service exclusively based on vehicle license plate.
- Technical report55 pagesEnglish languagesale 10% offe-Library read for1 day
This document, based on ISO/TS 19468 Methodology and platform independent models for exchange involving traffic control centres, traffic information centres and service providers, aims to fully specify a platform specific method to implement data exchange among centres based on SOAP, supporting DATEX II, for push pull data delivery and service request/feedback collaborative ITS services.
- Technical specification25 pagesEnglish languagesale 10% offe-Library read for1 day
ISO/TS 21719-2:2018 specifies
- 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.
Protcol information conformance statement (PICS) proforma is provided in Annex B, whereas security computation examples are provided in Annex E.
- Technical specification46 pagesEnglish languagesale 10% offe-Library read for1 day
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 European Standard 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 European Standard.
The communications protocols and methods for the transmission of the eCall message are not specified in this European Standard.
This European Standard 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 European Standard, but the form and data content of the MSD is not defined herein. A common European MSD is determined in EN 15722.
This European Standard does not specify whether eCall is provided using embedded equipment or other means (for example in the case of aftermarket equipment).
- Standard29 pagesEnglish languagesale 10% offe-Library read for1 day
- Draft29 pagesEnglish languagesale 10% offe-Library read for1 day
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.
- Standard164 pagesEnglish languagesale 10% offe-Library read for1 day
- Draft170 pagesEnglish languagesale 10% offe-Library read for1 day
This document specifies the general framework and the automated driving bus (ADB) system components for operating ADBs in public transport networks, including: a) the general framework and the operation scheme for public transport systems in cooperation with ADBs; b) definitions of system components for operating ADBs; and c) definitions of functions and requirements of each system component for providing transport services with ADBs. This document is applicable to bodies in public transport systems and services including transportation operators, public transport governing authorities and relevant industries.
- Standard35 pagesEnglish languagesale 15% off
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.
- Technical specification46 pagesEnglish languagesale 10% offe-Library read for1 day
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.
- Technical specification37 pagesEnglish languagesale 15% off
- Draft38 pagesEnglish languagesale 15% off
- Draft38 pagesEnglish languagesale 15% off
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.
- Technical specification18 pagesEnglish languagesale 10% offe-Library read for1 day
Field devices are a key component in intelligent transport systems (ITS). Field devices include traffic signals, message signs, weather stations, traffic sensors, roadside equipment for connected ITS (C-ITS) environments, etc. Field devices often need to exchange information with other external entities (managers). Field devices can be quite complex, necessitating the standardization of many data concepts for exchange. As such, the ISO 20684 series is divided several individual parts. This document specifies the needs, requirements and design for the field device to send notifications to one or more managers. It relies upon the definition of triggers as defined in ISO/TS 20684-3. NOTE 1 There are similarities between certain portions of NTCIP 1103 and this document. NOTE 2 ISO 20684-1 provides additional details about how the ISO 20684 series relates to the overall ITS architecture.
- Technical specification28 pagesEnglish languagesale 15% off
Field devices are a key component in intelligent transport systems (ITS). Field devices include traffic signals, message signs, weather stations, traffic sensors, roadside equipment for connected ITS (C-ITS) environments, etc. Field devices often need to exchange information with other external entities (managers). Field devices can be quite complex, necessitating the standardization of many data concepts for exchange. As such, the ISO 20684 series is divided several individual parts. This document specifies user needs, requirements and design elements that are normatively used by other parts of the ISO 20684 series. Specifically, it defines an internal field device clock, a mechanism for grouping object values together to provide for more efficient transfer of data, and it provides formal requirements for the SNMP target and target parameters as defined in IETF RFC 3413. NOTE 1 There are similarities between certain portions of NTCIP 1103 and NTCIP 1201 and this document. NOTE 2 ISO 20684-1 provides additional details about how the ISO 20684 series relates to the overall ITS architecture.
- Technical specification43 pagesEnglish languagesale 15% off
Field devices are a key component in intelligent transport systems (ITS). Field devices include traffic signals, message signs, weather stations, traffic sensors, roadside equipment for connected ITS (C-ITS) environments, etc. Field devices often need to exchange information with other external entities (managers). Field devices can be quite complex, necessitating the standardization of many data concepts for exchange. As such, the ISO 20684 series is divided several individual parts. This document specifies the user needs, requirements and design elements that are used to record timestamped information in a log for later retrieval. This allows a manager to determine the state of a particular object instance nearly simultaneously when the trigger action occurs without frequent polling. NOTE 1 There are similarities between certain portions of NTCIP 1103. NOTE 2 ISO 20684-1 provides additional details about how the ISO 20684 series relates to the overall ITS architecture.
- Technical specification22 pagesEnglish languagesale 15% off
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).
- Standard29 pagesEnglish languagesale 10% offe-Library read for1 day
- Draft29 pagesEnglish languagesale 10% offe-Library read for1 day
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.
- Technical report55 pagesEnglish languagesale 10% offe-Library read for1 day
This document defines the terms and definitions related to truck platooning systems (TPS), and the mode transitions in the platooning control system (PCS). The PCS is comprised of two main functions: the platooning operation control function (POCF) and the platooning manoeuvre control function (PMCF). This document specifies: — POCF and PMCF governing how vehicles join and leave platoons; — PMCF governing longitudinal and lateral control of each vehicle; NOTE PMCF makes reference to current International Standards, such as ISO 20035, ISO 11270 and ISO 21717, where appropriate. — functional evaluation test methods for POCF and PMCF. This document also describes: — the data to be communicated for POCF and PMCF in vehicle to vehicle (V2V) messages and optionally in vehicle to infrastructure (V2I) messages, including local roadside and broader network and cloud; — strategies for forming platoons, such as ad-hoc or planned formation, and types of truck platooning systems, such as top-down management and peer-to-peer. This document covers: — platooning of heavy goods vehicles of multiple brands and fleets, operated by on-board drivers. Light trucks, buses and passenger cars are excluded; — level 1 and 2 driving automation systems, which provide driver support and operate under the continuous supervision of the drivers. The functions and operations of the back office (BO) are out of scope of this document.
- Standard42 pagesEnglish languagesale 15% off
Field devices are a key component in intelligent transport systems (ITS). Field devices include traffic signals, message signs, weather stations, traffic sensors, roadside equipment for connected ITS (C-ITS) environments, etc. Field devices often need to exchange information with other external entities (managers). Field devices can be quite complex, necessitating the standardization of many data concepts for exchange. As such, the ISO 20684 series is divided several individual parts. This document specifies the needs, requirements and design for multiple mechanisms to fire triggers, which result in the device attempting to perform an action. Specific types of actions are defined in other documents and can include sending notifications (ISO/TS 20684-4), entering data into a log for later retrieval (ISO/TS 20684-5), and/or initiating SNMP-based requests (ISO/TS 20684-6). NOTE 1 There are similarities between certain portions of NTCIP 1103 and NTCIP 1201 and this document. NOTE 2 ISO 20684-1 provides additional details about how the ISO 20684 series relates to the overall ITS architecture.
- Technical specification58 pagesEnglish languagesale 15% off
Field devices are a key component in intelligent transport systems (ITS). Field devices include traffic signals, message signs, weather stations, traffic sensors, roadside equipment for connected ITS (C-ITS) environments, etc. Field devices often need to exchange information with other external entities (managers). Field devices can be quite complex, necessitating the standardization of many data concepts for exchange. As such, the ISO 20684 series is divided several individual parts. This document specifies the user needs, requirements and design elements that are used to issue an SNMP set-request in response to a trigger firing. This allows a manager to configure the field device to implement simple responses to conditions in the field. NOTE 1 There are similarities between certain portions of the Event MIB defined in IETF RFC 2981 and this document. NOTE 2 ISO 20684-1 provides additional details about how the ISO 20684 series relates to the overall ITS architecture.
- Technical specification16 pagesEnglish languagesale 15% off
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.
- Technical report46 pagesEnglish languagesale 15% off
- Technical report50 pagesFrench languagesale 15% off
- Draft46 pagesEnglish languagesale 15% off
- Draft46 pagesEnglish languagesale 15% off
This document defines the data exchange protocol used to implement use cases for applications based on the personal ITS station defined in ISO 13111-1, which provides and maintains ITS services to travellers, including drivers, passengers and pedestrians. The ITS applications supported by this document include multimodal transportation information services and multimodal navigation services that are based on personal ITS stations in various application scenarios defined in ISO 13111-1. The use case implementations described in this document refer to the architecture defined in ISO 21217 and ISO 13184.
- Standard69 pagesEnglish languagesale 15% off
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.
- Standard164 pagesEnglish languagesale 10% offe-Library read for1 day
- Draft170 pagesEnglish languagesale 10% offe-Library read for1 day
This document describes the concept and goals of smart transportation by autonomous vehicles on public roads. It provides guidelines for the successful introduction and organisation of autonomous vehicles, with the aim of enhancing the safety of public road transportation and addressing the challenges to cities such as an aging population and diverse travel demands. This document focuses on the deployment of autonomous vehicles as an operational system for actual use on public roads. This document is intended for those in academia, autonomous vehicle developers, policy makers, research institutions, road infrastructure operators, public road administrators, testing inspection and certification bodies, and vehicle manufacturers. NOTE 1 This document targets autonomous vehicle services except on-demand responsive services with shared vehicles. For on-demand responsive passenger services with shared vehicles, see ISO 37168. NOTE 2 A bus vehicle is shared by different passenger groups and can be chartered. A taxi vehicle is hired and can, if local regulations permit, be shared by different passenger groups.
- Standard9 pagesEnglish languagesale 15% off
This document describes criteria to organize smart transportation to save fuel in bus transportation services where the reduction of energy consumption is intended. Smart transportation aims not only at fuel efficiency, but at pollutant emission reduction for engine driven buses, as well as the financial stabilization of bus transportation services for citizens and city visitors.
- Standard11 pagesEnglish languagesale 15% off
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.
- Technical specification151 pagesEnglish languagesale 10% offe-Library read for1 day
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.
- Standard153 pagesEnglish languagesale 15% off
- Standard167 pagesFrench languagesale 15% off
- Standard167 pagesFrench languagesale 15% off
- Draft154 pagesEnglish languagesale 15% off