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 a mechanism for exchanging data and messages in the following cases: a) exchange between a traffic management centre and ITS roadside equipment for traffic management; b) exchange between ITS roadside equipment used for traffic management. This document is not applicable to: — communication between traffic management centres and in-vehicle units; — communication between ITS roadside equipment and in-vehicle units; — in-vehicle communication; — in-cabinet communication; — motion video transmission from a camera or recorded media. This document is suitable for use when both of the following conditions apply: 1) The data to be exchanged can be defined as one or more elements that can be retrieved or stored – SNMP can support a wide variety of devices and has adopted the concept of a management information base (MIB), which identifies the configuration, control and monitoring parameters for ITS roadside equipment. This standardized approach is commonly used for network management applications for devices such as routers, switches, bridges and firewalls. It is also used in many regions to control devices such as dynamic message signs. 2) Guaranteed, deterministic, real-time exchange of data is not critical – SNMP operations typically require less than 100 ms, but the underlying network can cause multi-second delays in delivering messages or even lost messages; thus, SNMP is not intended for applications that require reliable sub-second communications. This document can be used for: — intermittent exchange of any defined data (normal SNMP operations allow messages to be structured by combining any group of elements into a retrieval or storage request); — repeated, frequent exchanges of the same message structure (with potentially different values), even on relatively low-bandwidth links; NOTE 1 The dynamic object feature, defined in ISO/TS 26048-1, can be used to eliminate a considerable amount of overhead that is normally associated with SNMP communications to make it more suitable for low-bandwidth links. — allowing ITS roadside equipment to issue exception reports when special conditions arise. NOTE 2 Exception reporting uses SNMP notifications in combination with the notification management features defined in ISO/TS 26048-1.
- Standard19 pagesEnglish languagesale 15% off
This document specifies the general service framework and components for operating automated driving buses (ADBs) in public transport networks. It includes: a) a description of the ADB service components which consist of ADBs, the monitoring and control (MC) centre, Internet of Things (IoT) infrastructure, the smart bus stations and the passengers. b) a description of the use cases for the ADB service operation.
- Technical report26 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 central devices (managers). Field devices can be quite complex necessitating the standardization of many data concepts for exchange. As such, the ISO 22741 series is divided into several individual parts. This document identifies basic user needs for the management of virtually any field device and traces these needs to interoperable designs. This includes the ability to identify the device, its capabilities and its status. ISO 22741-1 provides additional details about how the ISO 22741 series relates to the overall ITS architecture.
- Technical specification15 pagesEnglish languagesale 15% off
ISO 13141:2015 establishes requirements for short-range communication for the purposes of augmenting the localization in autonomous electronic fee collection (EFC) systems. Localization augmentation serves to inform on-board equipment (OBE) about geographical location and the identification of a charge object. This International Standard specifies the provision of location and heading information and security means to protect from the manipulation of the OBE with false roadside equipment (RSE).
The localization augmentation communication takes place between an OBE in a vehicle and fixed roadside equipment. This International Standard is applicable to OBE in an autonomous mode of operation.
ISO 13141:2015 defines attributes and functions for the purpose of localization augmentation, by making use of the dedicated short-range communications (DSRC) communication services provided by DSRC Layer 7, and makes these LAC attributes and functions available to the LAC applications at the RSE and the OBE. Attributes and functions are defined on the level of Application Data Units (ADUs, see Figure 1).
- Standard45 pagesEnglish languagesale 10% offe-Library read for1 day
- Amendment10 pagesEnglish languagesale 10% offe-Library read for1 day
This document defines requirements for short-range communication for the purposes of compliance checking in autonomous electronic fee collecting systems. Compliance checking communication (CCC) takes place between a road vehicle's on-board equipment (OBE) and an interrogator (roadside mounted equipment, mobile device or hand-held unit), and serves to establish whether the data that are delivered by the OBE correctly reflect the road usage of the corresponding vehicle according to the rules of the pertinent toll regime.
The operator of the compliance checking interrogator is assumed to be part of the toll charging role as defined in ISO 17573-1. The CCC permits identification of the OBE, vehicle and contract, and verification of whether the driver has fulfilled his obligations and the checking status and performance of the OBE. The CCC reads, but does not write, OBE data.
This document is applicable to OBE in an autonomous mode of operation; it is not applicable to compliance checking in dedicated short-range communication (DSRC)-based charging systems.
It defines data syntax and semantics, but not a communication sequence. All the attributes defined herein are required in any OBE claimed to be compliant with this document, even if some values are set to "not defined" in cases where certain functionality is not present in an OBE. The interrogator is free to choose which attributes are read in the data retrieval phase, as well as the sequence in which they are read. In order to achieve compatibility with existing systems, the communication makes use of the attributes defined in ISO 14906 wherever useful.
The CCC is suitable for a range of short-range communication media. Specific definitions are given for the CEN-DSRC as specified in EN 15509, as well as for the use of ISO CALM IR, the Italian DSRC as specified in ETSI ES 200 674-1, ARIB DSRC and WAVE DSRC as alternatives to the CEN-DSRC. The attributes and functions defined are for compliance checking by means of the DSRC communication services provided by DSRC application layer, with the CCC attributes and functions made available to the CCC applications at the roadside equipment (RSE) and OBE. The attributes and functions are defined on the level of application data units (ADU).
The definition of the CCC includes:
— the application interface between OBE and RSE (as depicted in Figure 2);
— use of the generic DSRC application layer as specified in ISO 15628 and EN 12834;
— CCC data type specifications given in Annex A;
— a protocol implementation conformance statement (PICS) proforma is given in Annex B;
— use of the CEN-DSRC stack as specified in EN 15509, or other equivalent DSRC stacks as described in Annex C, Annex D, Annex E and Annex F;
— security services for mutual authentication of the communication partners and for signing of data (see Annex H);
— an example CCC transaction is presented in Annex G;
— the informative Annex I highlights how to use this document for the European electronic toll service (as defined in Commission Decision 2009/750/EC).
Test specifications are not within the scope of this document.
- Standard71 pagesEnglish languagesale 10% offe-Library read for1 day
This document provides information and specifications on the management of road traffic in controlled zones (CZ) through the application of geofencing. Specifically, this document specifies a “Controlled Zone Data Dictionary” (CZDD) for management of controlled zones, and provides an extendible toolkit that regulators can use, for example, to inform potential CZ users (e.g. vehicles) about: — the CZ area, i.e. the geographical boundaries of the CZ; — CZ access conditions including exemptions; — time windows indicating when these CZ access conditions are applicable. This allows potential CZ users to select an appropriate routing, either by pre-trip planning or ad hoc re-routing. This document also provides illustrations and guidelines on how to use this toolkit. The toolkit is designed in accordance with the general ITS station and communications architecture specified in ISO 21217, and with optionally applicable C-ITS protocols and procedures, e.g. ISO 22418 on “Service Announcement”, ISO 18750 on the “Local Dynamic Map”, and ISO 17419 on globally unique identifiers. Cybersecurity provision can be provided through conformance to ISO 21177. Enforcement is out of scope of this document.
- Standard22 pagesEnglish languagesale 15% off
This document specifies a freight vehicle safety information provisioning service application or function. It is intended for use within non-enforcement applications and potentially for regulated application services (RAS), for the road transport safety management purposes of regulated commercial freight vehicle movements. This document reinforces vehicle safety for non-enforcement purposes and other purposes by providing safety advisory information concerning overhead clearance provisions to freight vehicle drivers or operators transporting heavy goods on freight vehicles. This document specifies the framework for remote vehicle safety information provision for non-enforcement and for the conceptual operation of other management purpose applications. This document is intended to be beneficial to entities whose purpose is vehicle safety management. It provides additional use cases for TARV (telematics applications for regulated vehicles) service applications.
- Standard23 pagesEnglish languagesale 15% off
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.
- Standard45 pagesEnglish languagesale 10% offe-Library read for1 day
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.
- Standard71 pagesEnglish languagesale 10% offe-Library read for1 day
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.
- Standard36 pagesEnglish languagesale 15% off
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.
- Standard61 pagesEnglish languagesale 15% off
- Standard1 pageEnglish languagesale 15% off
- Standard1 pageFrench languagesale 15% off
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.
- Standard21 pagesEnglish languagesale 10% offe-Library read for1 day
- Amendment10 pagesEnglish languagesale 10% offe-Library read for1 day
This document provides minimum requirements and test procedures for automated braking at velocities below 2,8 m/s (10 km/h) with the specific aim of avoiding or mitigating collisions with pedestrians, other road users (e.g. vehicles) and stationary objects, including infrastructure elements (e.g. walls, pillars). These collisions mainly occur during reversing manoeuvres, but this document also addresses collisions in other directions during low-speed manoeuvring. Automated braking during low-speed manoeuvring (ABLS) requires information about the position and motion of the object, the motion of the subject vehicle, and the driver actions. It then determines if the evaluated situation represents a collision risk. If an imminent collision risk exists, ABLS will automatically activate a brake action to avoid or at least mitigate the collision. The document does not define test objects, but refers to the ISO 19206 series for test objects to be used. The human driver is assumed to perform or at least supervise all driving manoeuvres because the ABLS application is restricted to support only systems of SAE Level 0 – 2. Evasive steering manoeuvres are not within the scope of this document. This document applies to light vehicles only. Vehicles equipped with trailers are not within the scope of this document.
- Standard23 pagesEnglish languagesale 15% off
- Standard1 pageEnglish languagesale 15% off
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.
- Standard21 pagesEnglish languagesale 10% offe-Library read for1 day
This document describes the concept of smart transportation by facial recognition payment (f-payment) and how this means of payment improves the transportation experience for city inhabitants and visitors who agree to use their biometric data.
- Standard11 pagesEnglish languagesale 15% off
This document specifies the syntax and semantics of data objects in the field of electronic fee collection (EFC). The definitions of data types and assignment of values are provided in accordance with the abstract syntax notation one (ASN.1) technique, as specified in ISO/IEC 8824‑1. This document defines:
— ASN.1 (data) types within the fields of EFC;
— ASN.1 (data) types of a more general use that are used more specifically in standards related to EFC.
This document does not seek to define ASN.1 (data) types that are primarily related to other fields that operate in conjunction with EFC, such as cooperative intelligent transport systems (C-ITS), the financial sector, etc.
- Standard59 pagesEnglish languagesale 10% offe-Library read for1 day
In respect of pan-European eCall (operating requirements defined in EN 16072), this European Standard defines the high level application protocols, procedures and processes required to provide the eCall service using a TS12 emergency call over a 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.
- Standard44 pagesEnglish languagesale 10% offe-Library read for1 day
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
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
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.
- Standard59 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.
- Standard44 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
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
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
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
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
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
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
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
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
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
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
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
- 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
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.
- Standard121 pagesEnglish languagesale 15% off
- Standard129 pagesFrench languagesale 15% off
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
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
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
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