ISO/TC 204 - Intelligent transport systems

This document specifies data elements and data frames for messages a) exchanged between roadside modules and: 1) signal controllers; 2) traffic management centres, and/or; 3) other roadside modules. b) exchanged between traffic management centres and signal controllers. This document addresses the data in the application layer of the OSI (Open Systems Interconnection) reference model.

This document specifies the architecture and the logical data model of static map data for connected and automated driving system applications.

This document defines terms within the field of electronic fee collection (EFC). This document defines: — terms that are used in standards related to electronic fee collection; — terms of a more general use that are used more specifically in standards related to electronic fee collection. This document does not define terms related primarily to other fields that operate in conjunction with EFC, such as terms for intelligent transport systems (ITS), common payment systems, the financial sector, etc.

This document defines the end-to-end requirements for the entire management of electronic traffic regulations (METR) system of systems (SoS). This document introduces the reference architecture used by subsequent parts. NOTE The operational concept for METR is provided in ISO/TR 24315-2.[ REF Reference_ref_13 \r \h 9 08D0C9EA79F9BACE118C8200AA004BA90B0200000008000000110000005200650066006500720065006E00630065005F007200650066005F00310033000000 ]

The management of electronic transport regulations (METR) provides trustworthy, authoritative, machine-interpretable, transport-related rules for using the road network. This document describes the operational concept (ConOps) for METR in a format that is consistent with ISO/IEC/IEEE 29148.

This document defines detailed use cases, requirements and message specifications for supporting central ITS station based indoor positioning to provide indoor navigation functionality between a personal/vehicle (P/V) ITS station and the central ITS station. This document is only applicable to the core flow for the central ITS station based indoor positioning. The following issues which are adjunctive but essential for commercial navigation services are beyond the scope of this document: — authorized and authenticated access of users and services, including security; — payment; — preparation of indoor data which are necessary for indoor navigation; — low-level communication protocols required to transfer and share data from and to a roadside ITS station or a central ITS station; — other issues dependent on implementation of an instance of indoor navigation.

This document describes the physical and functional views defined in ISO/TS 14812 on integrated mobility, based on the role and responsibilities models in the mobility-as-a-service (MaaS) and mobility on demand (MOD) ecosystems as described in ISO/TR 4447 and ISO/TR 7878. This document focuses on mobility service concepts where the included transport services are publicly available.

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 environments, etc. The ISO 26048 series defines data that can be used to manage field devices, including device configuration, control and monitoring. Field devices can be quite complex, necessitating the standardization of many data concepts for exchange. As such, the ISO 26048 series is divided into several individual parts. This document (ISO/TS 26048-1) introduces the ISO 26048 series, provides content that is normatively referenced in subsequent parts, and defines data that is applicable to the management of a wide range of field devices. The scope of the ISO 26048 series does not define the logic used by the management station, the underlying protocols used to exchange the defined data elements, or internal design of the field device. However, the ISO 26048 series does define functional requirements on the interface and assumes an interface based on an SNMPv3 environment as specified by ISO 15784-2. NOTE Many of the concepts defined in this document were derived from NTCIP 1103[ REF Reference_ref_11 \r \h 1 08D0C9EA79F9BACE118C8200AA004BA90B0200000008000000110000005200650066006500720065006E00630065005F007200650066005F00310031000000 ] and NTCIP 1201[ REF Reference_ref_12 \r \h 2 08D0C9EA79F9BACE118C8200AA004BA90B0200000008000000110000005200650066006500720065006E00630065005F007200650066005F00310032000000 ], however, the design has been updated to better address security concerns. It is expected that future versions of NTCIP will migrate to the design defined in this document.

This document specifies the constructional and performance requirements and methods of tests for light emitting diode destination board systems (LEDDBSs) for use in all categories of buses and coaches (including mini/midi buses).

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

This document defines terms relating to intelligent transport systems (ITS).

This document describes remote support provided to LSADS operated at Level 4 automation on predefined routes by a remotely located human in order to facilitate safe trip continuation. "Remote support" refers to the provision of information, or temporary performance of the dynamic driving task (DDT), and remote monitoring required for these functions. This document is applicable to RS-LSADS in vehicles that provide passenger transport or logistics services on predefined routes. This document specifies: — the terms and definitions related to RS-LSADS and the system architecture of RS-LSADS; — functions of RS-LSADS, which are: remote monitoring, remote assistance and remote driving that is operated under very limited conditions, and conditions under which they need to be activated; — the performance requirements, system requirements and performance test procedures of RS-LSADS; — the data to be communicated between vehicles and the remote support facility (but not protocols or other aspects of communication system). This document is applicable to remote support of operational and tactical functions during continuous operations, but does not apply to strategic functions or to RS-LSADS daily startup or shutdown.

This document: — describes and specifies globally unique addresses and identifiers (ITS-S object identifiers) that are both internal and external to ITS stations and are used for ITS station management; — describes how ITS-S object identifiers and related technical parameters are used for classification, registration and management of ITS applications and ITS application classes; — describes how ITS-S object identifiers are used in the ITS communication protocol stack; — introduces an organizational framework for registration and management of ITS-S objects; — defines and specifies management procedures at a high functional level; — specifies an ASN.1 module for the identifiers, addresses and registry records identified in this document; and — specifies an ASN.1 module for a C-ITS data dictionary containing ASN.1 type definitions of general interest. This document is based on the architecture of an ITS station specified in ISO 21217 as a bounded secured managed domain (BSMD).

This document describes the common description of the driving behaviour information set (DBIS) data structure and data exchange procedures for sharing among distributed ITS stations by nomadic devices.

This document addresses the provision of tyre pressure monitoring (TPM) services. It specifies the form and content of the transmission data required to support TPM systems (TPMS) and the access methods for these data. This document provides specifications for common communications and data exchange aspects of the TPM application service that a jurisdiction regulator or operator can elect to require or support as an option, including: a) a high-level definition of the service that a service provider has to provide [the service definition describes common service elements (SEs), but does not specify the detail of how such an application service is instantiated, nor the acceptable value ranges of the data concepts defined]; b) the means to realize the service; c) application data naming, content and quality that an in-vehicle system (IVS) has to deliver, including a number of TPM profiles or data (noting that requirements and constraints of what can/cannot be transmitted over the air can vary between jurisdictions); d) support for a number of defined communication profiles to enable remote inspection. This document provides specifications for the following application profiles: — Application profile A1: the cyclical initiation of TPM message by on-board equipment (TPM-C). — Application profile A2: the exceptional initiation of TPM message by on-board equipment (TPM-E). — Application profile A3: the provision of TPM data as the result of an off-board request (TPM-R). — Application profile A4: The provision of TPM data as the result of an off-board reading of tyre pressures of vehicles which can potentially be unequipped (TPM-O).

This document: — specifies communication service parameters presented by ITS station (ITS-S) application processes to the ITS-S management in support of automatic selection of ITS-S communication profiles in an ITS station unit (ITS-SU); — specifies related procedures for the static and dynamic ITS-S communication profile selection processes at a high functional level; — provides an illustration of objectives used to estimate an optimum ITS-S communication profile.

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-office system of the two roles of service provision and toll charging, e.g.: — charging-related data (toll declarations, billing details, payment claims, payment announcements), — administrative data (trust objects, EFC context data, etc.), 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 specified 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 TC or 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 ADUs that can possibly involve several APDU exchanges; — processes regarding payments and exchanges of fiscal, commercial or legal accounting documents; — definitions of service communication channels, protocols and service primitives to transfer the APDU.

This document specifies the data transfer models between roadside equipment (RSE) and integrated circuit cards (ICCs) and the interface descriptions between the RSE and on-board equipment (OBE) for on-board accounts using an ICC. It also provides examples of interface definitions and transactions deployed in several countries. This document covers: — data transfer models between the RSE and ICC which correspond to the categorized operational requirements and the data transfer mechanism for each model; — the interface definition between the RSE and OBE based on each data transfer model; — the interface definition for each model; — the functional configuration; — RSE command definitions for ICC access; — the data format and data element definitions of RSE commands; — a transaction example for each model (Annex B).

This document: — describes the functionality of a "local dynamic map" (LDM) in the context of the "bounded secured managed domain" (BSMD); — specifies: — general characteristics of LDM Data Objects (LDM-DOs) that can be stored in an LDM, i.e. information on real objects such as vehicles, road works sections, slow traffic sections, special weather condition sections, which are as a minimum requirement location-referenced and time-referenced; — service access point functions providing interfaces in an ITS station (ITS-S) to access an LDM for: — secure add, update and delete access for ITS-S application processes; — secure read access (query) for ITS-S application processes; — secure notifications (upon subscription) to ITS-S application processes; — management access: — secure registration, de-registration and revocation of ITS-S application processes at LDM; — secure subscription and cancellation of subscriptions of ITS-S application processes; — procedures in an LDM considering: — means for maintaining the content and integrity of the data store; — mechanisms supporting several LDMs in a single ITS station unit.

This document specifies the functional requirements and test procedures for an acceleration control for pedal error (ACPE) system. This document applies to the systems installed in light vehicles (category M1 and N1)[2] and it does not apply to those installed in large vehicles or motorcycles.

This document describes a role model for predictive safety risk information provisioning primarily applicable for non-enforcement applications, and potentially applicable for enforcement application services are out of scope of this document. This role model is dedicated to human centric road transport safety management purposes considering all road users on the roads. It can be applicable to enforcement application services.

The management of electronic transport regulations (METR) provides a means for METR users to obtain trustworthy, authoritative, machine-interpretable, publicly available and transport-related information for the use of the road network, in order to provide safer and more efficient, sustainable, comfortable, and equitable transport services. The scope of METR includes both rules that are relatively static (e.g. static speed limits) as well as those that are dynamic (e.g. variable speed limits, signalized intersections). Where appropriate, METR incorporates existing documents (e.g. ISO/TS 19091 for signalized intersections). This document defines terms specific to the ISO 24315 series on the management of electronic transport regulations.

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

This document specifies a unified logical data model based on available existing dynamic information standards. The data has precise relative location references to be linked with ISO/TS 22726-1 which specifies the architecture and the logical data model of static map data for connected and automated driving applications. Dynamic event data comes from external systems and has been defined and specified independently by existing standards. Therefore, the logical data model in this document is formed to synthesize contents referring to other standards.

This document describes the classification of notifications provided to and from users and automated driving systems (ADS) of level 3 or higher. This document does not include recommendations on how to provide information. This document also includes information on transmission between nomadic devices and ADS in the context where the user is concentrating on a device such as a smartphone, and the smartphone is able to monitor the user’s condition.

This document specifies the following elements for cooperative telematics applications for regulated commercial freight vehicles directly communicating via a secure vehicle interface: a) a framework for the provision of cooperative telematics application services for regulated commercial freight vehicles; b) a description of the concept of operation, regulatory aspects and options and the role models; c) a conceptual architecture using an on-board platform and wireless communications to a regulator or their agent; d) references for the key documents on which the architecture is based; e) the architecture of the facilities layer; f) a taxonomy of the organization of generic procedures. This document does not replace, but is complementary to ISO 15638-1. It provides an alternative communication architecture for achieving similar service provision by means of a standardized secure vehicle interface.

This document analyses the processes of image-based systems to be used for tolling purposes, with the aim to identify their specific characteristics, and where these characteristics can be observed. The study intends to answer the following questions: a) Which are the relevant characteristics of an image-based system used for electronic fee collection (EFC)? b) How can these characteristics be specified?

This document specifies the requirements for a secure interface for the provision of telematics applications for regulated commercial freight vehicles (TARV) application services data to jurisdictions and other relevant parties within the following scenarios: a) a secure credential management system (SCMS) already exists for ITS data management and access in the location of the service provision; b) an SCMS does not yet exist for ITS data management and access in the location of the service provision.

This document establishes a method of using geographic location referencing (GLR) that can be used by relevant TPEG applications. The GLR type, defined in this document, is used for defining geographic location references (points, polylines and geographical areas). The GLR method is intended to be one of the methods that can be transported inside a TPEG-Location Referencing Container (TPEG-LRC) for those TPEG applications providing information for primarily geographical locations (e.g. weather). The GLR specification is deliberately kept basic and compact, so that it can also be employed advantageously in non-navigation devices, for simple TPEG services such as weather information, safety alerts, etc. As such, the GLR location referencing method is intended to be complementary to map-related location referencing methods, where the focus is on the referencing of anthropogenic artefacts such as roads and highways. For this reason, the scope of GLR is limited to geographic locations on the Earth’s surface.

This document describes the “public transport information service” (PTS) application, which is intended to cover all modes of public (i.e. collective) transport, both for inter-urban and intra-urban travel. The PTS application is designed to allow the efficient and language-independent delivery of public transport information directly from a service provider to end-users. The PTS application design is based on three main use cases. — Provision of alert information: an alert is a warning that indicates an emergency situation. This case is specifically relevant for broadcast/push mode, for major deviations or disruptions which are relevant for a large number of travellers. A dedicated alert request is also defined and can be used if a backchannel is available. — Timetable information, both scheduled and real time: this information is in some cases relevant for broadcast, e.g. in case of large events for the transport modalities to/from the event site. A dedicated timetable request is also defined and can be used if a backchannel is available. — Individual requests for trip information (backchannel is required). The PTS application focuses on providing core information regarding public transport in order to ensure the compactness of the TPEG application. Specific information as provided in typical public transport apps (e.g. fare information) is not in the scope of this document.

This document specifies the syntax and semantics of data objects in the field of electronic fee collection (EFC). The definitions of data types and assignment of 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 field of EFC; — ASN.1 (data) types of a more general use that are used more specifically in standards related to EFC. This document does not seek to define ASN.1 (data) types that are primarily related to other fields that operate in conjunction with EFC, such as cooperative intelligent transport systems (C-ITS), the financial sector, etc.

This document specifies the "electromobility information" (EMI) TPEG application. The EMI application has been specifically designed to support information about charging infrastructure for electric vehicles (not just cars), the location of e-charging points and their suitability for the respective vehicle (e.g. connector type, charging modality). As electric vehicles will occupy a “charging space” for longer a time than other vehicles, information on availability/waiting time and reservation options are accounted for, as they are highly relevant for enabling a user of an electric vehicle to optimally plan their route/trip. The standardized delivery, via TPEG technology, of electromobility information has the following benefits to an end user of this TPEG service: a) identification of suitable charging units for vehicles, thus preventing unnecessary travel to find a fitting unit (also has environmental benefits); b) verification of the real-time availability of charging units; c) possibility of planning ahead and reserving a spot in a charging park, thus optimizing trip planning; d) possibility of selecting a financially attractive charging point in a charging park where the operator has billing agreements with the user’s electromobility provider. In addition to these end-user benefits, electromobility providers and charging park operators also benefit from a standardized TPEG format as it facilitates harmonization of the electromobility information with the data formats used for the exchange of information between management systems of electromobility providers and charge park operators and related specifications (e.g. Open Charge Alliance,[1] eMobility ICT Interoperability Innovation (eMI3),[2] etc.). The EMI application, as an add-on service component next to traffic information, for example, is laid out to support large numbers of charge parks with only modest bandwidth requirements.

This document specifies the minimum governance procedure requirements for ITS data management and access using secure interfaces (and, particularly, secure vehicle interfaces) in order to meet objectives in accordance with the principles of ISO/TC 204 policy documents concerning ITS data governance policy. NOTE 1 Where an ITS data management and access paradigm is already in existence, this document proposes only to provide a suitable checklist for any assessment of its competency. This document does not propose that existing arrangements that are acceptably competent be changed. NOTE 2 This document does not affect proprietary original equipment manufacturer (OEM) communications using ExVe (see ISO 20077-1), but does provide means for its complementary coexistence.

This document describes use cases related to seamless positioning systems for multimodal transportation in ITS stations. The use cases define the effectiveness of the seamless positioning concept model based on the P-ITS-S to conclude basic PVT service results using available sensors when mobility is moving indoor and outdoor in a network on/off situation. Use cases are provided for each stage in different environments, e.g. indoor, outdoor, tunnel and out-of-network area when travelling starts or ends. Within the use cases, the nomadic device implements a personal ITS station (P-ITS-S) to achieve compatibility with other ITS stations as referenced in this document. The main purpose of this document is to describe the overall concept model, which specifies: — the concept model and actors for each domain; — the relationship of actors under the material domain; — the message sequence diagrams for each domain; and — the data transmission list for each actor to provide a seamless indoor and outdoor positioning system through sensor data fusion. In addition, this document provides: — basic principles used in its drafting; and — a gap analysis, consisting of a formal study of: — the status of seamless positioning technology and implementations, — how seamless positioning technology intends to evolve, and — how to close the gap between current and future technology and implementations. — This document compares desired and actual outcomes and pinpoints opportunities for improvement.

This document defines requirements to support information exchanges among related entities of a common payment scheme. It defines: a) EFC-related functional requirements for a common payment medium; b) an application structure in a common payment medium; c) EFC application data in a common payment medium. The following is outside the scope of this document: — requirements and data definitions for any other transport services such as public transport; — a complete risk assessment for an EFC system using a common payment medium; — security issues arising from an EFC application among all transport services; — the technical trust relationship between a CSRP and a service user; — concrete implementation specifications for implementation of security for an EFC system; — detailed specifications required for privacy-friendly EFC implementations; — any financial transactions of the CSRP.

This document identifies the architecture of a toll system environment in which a toll charger (TC) can act to support traffic management with the use of a tariff scheme. This document defines: — the architecture relevant to the scope of this document; — a standard framework and data flow model; — an exchange of information between a TC and a road and traffic manager (RTM), e.g.: — level of service (LOS); — tariff scheme; — data which is needed to support traffic management (vehicle probe and traffic flow data). The detailed definitions of mandatory and optional elements in real implementation are outside the scope of this document. This document does not define communication stacks or timings.

This document specifies the functional requirements of nomadic devices for lane-level positioning and integrity monitoring with the network-based precise positioning infrastructure for land transportation (NETPPI-LT), a lane-level positioning system based on global navigation satellite systems (GNSS) described in ISO/TR 22086-1. This document identifies the GNNS threats to monitor and the errors to remove or mitigate to achieve lane-level accuracy and integrity. It also specifies the data sets to be contained in messages between the nomadic device and the control station providing GNSS correction and integrity information. This specification enables the nomadic device to support lane-level positioning and integrity monitoring. Enabling techniques and methods, which can be different for each provider or vendor, are not addressed in this document.

Variable message signs (VMSs) are installed in areas where traffic managers identify a frequent need to convey information to the travelling public, such as upstream from interchanges to alert the public to downstream congestion in time for them to alter their routes. This allows traffic managers to improve the efficiency, safety and quality of traveller journeys. In order to manage the operation of a VMS and the messages displayed, information exchange between the management systems and the VMS is needed. This document identifies basic user needs for the management of light-emitting diode (LED) matrix VMSs and traces these needs to interoperable designs. This includes the ability to identify the device, its capabilities, and its status.

This document provides a freight vehicle dynamic charging information collecting service function or application for non-enforcement applications and for regulated application services (RAS). It is intended for the road transport decarbonizing management purposes of regulated commercial freight vehicle movements using battery-powered heavy electric vehicles. This document also specifies the framework for remote energy consumption information collecting for non-enforcement and the conceptual operation of other management purpose applications. This document is intended to reinforce vehicle energy efficiency for non-enforcement and other purposes by collecting dynamic charging information of battery powered heavy electric vehicles. Collected information can be used for fee collection and energy management purposes, which are outside the scope of this document. This document is applicable to dynamic charging applications. It is not applicable to information exchange purposes such as charging right and payment authorization. Static charging information exchange application is standardized by other ISO Technical Committees, such as ISO TC 22, Road vehicles, Subcommittee SC 31, Data communication. It is not applicable to this document.

This document provides a framework and information on the total amount of energy appropriate for the deployment of smart city mobility and energy efficiency technologies. These technologies can increase operational energy efficiency and unlock enhanced transportation waste-free energy applications, as well as measuring energy consumption. The standard framework for energy-based green intelligent transport systems (G-ITS) builds on the best practices for energy efficient transport and management systems, as well as applications of intelligent transport systems (ITS), and aims to accommodate the specific needs of energy-based green ITS in smart cities. G-ITS use data platforms to measure energy for transport and to forecast demand. A smart city provides G-ITS services to improve energy efficiency by using nomadic devices and by monitoring energy supply and demand. This document describes the change in the traffic paradigm from the perspective of energy efficiency. It outlines: — general information for energy-based G-ITS as a service using nomadic and mobile devices; — use cases for energy-based G-ITS services using nomadic and mobile devices; — use cases for energy-based mobility services, for example electric vehicles (EV), transportation infrastructure and other mobility services using nomadic devices.

This document defines requirements and specifications of indoor positioning references, which can be referenced for positioning in indoor space, for supporting indoor navigation functionality of a personal/vehicle (P/V) ITS station. NOTE Specific structure and contents of indoor positioning references depend on types of indoor positioning technologies. This document defines: a) the composition of an indoor map for indoor navigation of P/V ITS stations; b) the schema and encoding format of the indoor map for indoor navigation at the P/V ITS stations. This document focuses on the specification and format of the indoor map. The following issues which are adjunctive but essential for commercial navigation services are beyond the scope of this document: — authorized and authenticated access of users and services, including security; — payment; — preparation of indoor data which are necessary for indoor navigation; — low-level communication protocols required to transfer and share data from and to a roadside ITS station or a central ITS station; — other issues dependent on implementation of an instance of indoor navigation.

This document defines requirements and specifications for indoor positioning references, which can be referenced for positioning in indoor space, for supporting indoor navigation functionality of a personal/vehicle (P/V) ITS station. This document defines: a) the composition of indoor positioning references for use in obtaining indoor positions for indoor navigation of P/V-ITS-stations; b) the schema and encoding format of indoor positioning references for P/V-ITS-stations. This document focuses on indoor positioning references. The following issues which are adjunctive but essential for commercial navigation services are beyond the scope of this document: — authorized and authenticated access of users and services, including security; — payment; — preparation of indoor data which are necessary for indoor navigation; — low-level communication protocols required to transfer and share data from and to a roadside ITS station or a central ITS station; — other issues dependent on implementation of an instance of indoor navigation.

This document provides an overview of the ground-based automated mobility systems deployment paradigm. The paradigm covers such kerbsides and pathways as are suitable for co-temporal, collaborative use by various types and combinations of automated and non-automated, wheeled, or ambulatory, motorized and non-motorized, mobility-related vehicles and devices as well as for various levels of automated or remote operation of such vehicles. This includes vehicles and devices that move people as well as goods within proximate distances of human bystanders. Note Aerial (flying) drones are not part of the scope.

This document provides a description of the primary services that have been internationally defined to promote consistency among implementations. Implementations can provide any of these services in combination with any other services that are appropriate. This document organizes ITS services by defining service groups, which are placed into one of several service domains. Each service group contains one or more individual services, each of which is described. This document is intended for use by at least two groups of people involved in the ITS sector: a) those who are looking for ideas about the services that ITS implementations can provide, and b) those who are developing International Standards. For the first group, this document provides service descriptions that can act as the catalyst for more detailed descriptions. The level of detail can differ from one ITS implementation to another, depending on whether or not a national ITS architecture is involved, and whether or not this architecture is based directly on services, or on groups of functions. The service descriptions in this document are pitched at a high-level as too much detail can be prescriptive and reduces flexibility. For standards developers, this document is applicable to Technical Committees who are developing International Standards for the ITS sector. This document is designed to provide information and explanations of services that can form the basis and reason for developing standards. Due to its nature, this document is largely advisory and informative with minimal requirements. It is designed to assist the integration of services into a cohesive reference architecture, thereby promoting interoperability and the use of common data definitions. Specifically, services defined within the service groups can be the basis for defining “use cases”, “user needs” or "user service requirements” depending on the methodology being used to develop the resultant ITS architecture functionality. They can also assist with defining applicable data within data dictionaries, and applicable communications and data exchange standards.

This document addresses the minimum requirements for minimal risk manoeuvres (MRM), which are the response of an ADS to perform automated fallback to reach a minimal risk condition (MRC). This document specifies the classification framework for MRMs. The classification framework establishes the concept of MRM operation, classification of different MRM types, and basic principles of the decision-making process to decide which MRM type can be performed based on the situation. This document also specifies the minimum requirements of the control strategy and test procedures for the two simplest types of MRM: straight stop for type 1 and in-lane stop for type 2. The scope of the MRM described in this document covers minimum requirements for ADS performance during MRM action, from initiation to termination, aimed at achieving an MRC. MRM action-specific safety requirements for robust system design, such as those specified in ISO 26262 and ISO 21448, are not within the scope of this document. The MRM described in this document are intended to be used on light-duty vehicles equipped with Level 3-5 ADS. The scope does not include methods for detecting ADS failures and the decision-making process to initiate an MRM. This is because there are numerous cases that can initiate MRMs, and there is no general agreement on classification of those cases in the industry.

This document establishes the method of signalling the specific location referencing used by all TPEG2 applications that require detailed location information to be delivered to client devices. This document describes the TPEG2-Location Referencing Container (TPEG2-LRC) and shows how it is used to signal which specific location referencing method is in use for a particular TPEG message. It is able to handle location referencing methods that are external to the ISO 21219 series and the internal location referencing methods defined as parts of this series.

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

This document 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.

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.

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.