Traffic and Traveller Information

I'm a paragraph. Click here to add your own text and edit me. It's

easy.

Overview

22 Traffic and Traveller Information (TTI)

22.1 Overview

22.1.1 Scope

This section concerns Traffic and Traveller information. Section 22.8 concerns all aspects of Public Transport and as such will cover many aspects of Traffic and Traveller Information (TTI) that relate to public transport services. Section 18 refers to Railway Traffic Information. Hence this section will primarily deal with the standards which cover TTI on roads with only generalised application to public transport information in some of the technologies.

22.1.2 History and requirement for TTI

With greater mobility across Europe and borders between countries crossed with ease, there has been a drive for solutions that enable seamless delivery of traffic and travel information in the preferred language of the traveller.

However, the delivery and reception of language independent information is not the whole story. Following the collection of traffic data and travel data, the information needs to be collated, that is combined from a number of sources, filtered by importance, location and relevance; it then needs to be coded and delivered to the dissemination media.

In the early days of TTI the main method of communication was the written word, such as in newspapers (traffic reports and road closures) or by spoken voice over the radio and rarely on the television. This information was often not specific to a particular location and, in many ways, was seen as “editorial filler” rather than informative content.

As traffic increased rapidly in the 1960s and 1970s it became apparent that more traffic information was needed, and radio stations started to dedicate staff to the collection and collation of traffic news. It should be remembered that this was before the days of mobile phones. FM radio was in its infancy and so the only broadcastings was on AM national radio. Traffic bulletins were delivered by voice and at set times but still required the traveller to be tuned into the station delivering the travel broadcast at the time.

A more direct and focused approach to traffic and travel information was needed.

22.1.3 European cooperation

In the mid 1970s German broadcasters (led by their research institute IRT) and a receiver manufacturer (Blaupunkt) developed the ARI (Autofahrer-Rundfunk-Information – Driver Radio Information System). ARI signalled the presence of traffic information in VHF/FM broadcasts used by the German public network of VHS/FM radio stations using a 57kHz subcarrier added to a station’s FM signal. ARI was the forerunner of the RDS travel flags (see later) and was replaced by RDS in the late 1980s (implemented by the BBC and Swedish Radio).

The Radio Data System (RDS) EN 50067:1998 is a communications protocol standard for embedding small amounts of digital information in conventional FM radio broadcasts. RDS standardises several types of information transmitted, including time, station identification and program information. Further information about RDS is provided in a later section of this chapter.

The RDS data stream includes two flags carried on the 57KHz RDS data stream which essentially do the same as ARI. They are the:

Traffic Programme flag (TP) that signals which stations are likely to carry traffic information announcements;

Traffic Announcement flag (TA) which signals that the tuned station is currently broadcasting a traffic announcement; this allows an in-vehicle receiver to either un-mute the receiver or switch from a CD player or other media to play the announcement.

These flags were only capable of alerting the traveller if the in-car receiver was tuned into the station transmitting the TA and TP flags. However, later on in the development of RDS, the “Extended Other Networks” (EON) scheme was developed that signals which other stations are linked (from the same broadcaster) to the present station, and hence enables access to traffic announcements on the linked stations.

For example, a receiver tuned to BBC Radio 4 could automatically tune to BBC Hereford and Worcester to pick up a spoken traffic broadcast and then return to BBC Radio 4 afterwards.

Most importantly, these systems only alert travellers to travel and traffic bulletins read into a microphone by a reporter. These generally take place at a maximum of 3 per hour, and then only during the peak hours. A system where the traffic bulletins were independent of the sound broadcasting on radio was needed; hence the development of coded traffic information which would be independent of the microphone.

The answer was to digitise the traffic information and transmit it to the vehicle alongside normal programming.

22.2 Architecture

The TTI chain is made up from a number of elements from the collection of traffic and traveller data/information, collation and combination of the information, formation of location referencing, TTI service provision, transmission (by a number of means/media) of the TTI, reception of the TTI and management in the receiving device, provision of the receivers and finally the end user.

It should be remembered that the base information can be static or dynamic.

Figure 22.1 shows the chain up until the dissemination of the TTI. It should be noted that there are two types of data used for TTI static and dynamic and that the data can come from multiple sources by a number of communication channels using a number of protocol formats.

The data is then collated by a service provider and assembled for transmission (by any number of means) to the end user device. One of the established protocols used for the transference of data from centre to centre (but not for distribution for end users is DATEX standardised in the EN 16157 – series.

Figure 22.1 shows a path from the end user back through the system requesting information; this is usual for Public Transport operations where a route plan is requested that leads to the interrogation of the both the static and dynamic data sources. As far as this document is concerned we are only looking at one way data and information flows save the data links between the various service providers.

The significant standardised final leg from the service provider to the end user are RDS-TMC ALERT C and latterly TPEG 2.

In the case of DATEX II and TPEG 2 the standards are originally described in UML using Enterprise Architect and then output into XML and in the case of TPEG 2 into binary notation too. It may be possible in the future to translate from the UML models to ASN.1.

Figure 22.1 The “value chain” of Traffic and Traveller Information

22.3 Actors

In the information chain from the data providers there are a number of actors, some working individually and some combined into one entity.

22.3.1 Data collectors and providers

The data provider collects information that might be of use to the end user and transmits them to the data collator. The data can be static or dynamic such as variation from timetables, road closures, incidents, weather, etc.. The data can describe short and longer term issues. The data does not have to be solely event based, it can consist of delays, journey times, etc.. There are few standards in this area although there are more in public transport.

The data collectors can be road authorities or individual organisations who collect data from floating car systems or indeed crowd funding. Data can come as a biproduct from other systems such as Urban traffic control systems.

22.3.2 Data collators

Data collators bring data from a number of sources and use it to provide a picture of the traffic situation. To this end they transform the data to make it into information.

22.3.3 Service providers

The service provider puts all the elements from each of the actors to make an offering that can be provided to the user. The service provider may also coordinate the commercial activities with vehicle and equipment providers to ensure there is sufficient funding to ensure that services can continue.

22.3.4 Mapmakers

TTI is pointless unless events and information are put into a geographic framework.

In the case of RDS-TMC, the location codes formed using ISO EN 14819-3 are “stitched” onto existing map databases used by information providers, service providers and equipment providers; it is vital that there is synchronisation between location databases used by the service provider and the equipment provider.

In the case of DATEX II and TPEG 2 there are a number of location schemas that can be selected.

22.3.5 Broadcasters

The TTI described in this section is normally delivered as a one-to-many unidirectional broadcast although TPEG can be delivered as one-to-one. In the case of RDS-TMC the broadcaster takes the RDS-TMC data stream from the service provider and injects it into the RDS data stream of the chosen VHS/FM station(s).

In the case of TPEG 2 the data-stream from the service provider can be inserted into the chosen data stream, be it Digital Audio Broadcasting, or any other digital high-speed bearer such as wide-area WIFI or 4G/5G telephony.

22.3.6 Equipment suppliers

Equipment suppliers can be vehicle suppliers, their equipment suppliers or third-party suppliers who produce equipment capable of receiving, decoding and displaying TTI data streams.

End user equipment was originally considered as stand-alone systems where adapted vehicle receiving equipment would speak or display traffic information. However, the majority of receivers are now parts of other systems such as navigation systems where the traffic information is displayed relative to the user’s position or route to be followed. It is likely that TTI will be incorporated as a service in C-ITS applications.

TTI 22.1 Overview

TTI 22.2 Architecture

TTI 22.3 Actors

22.4 Location Referencing

This chapter is not specifically about location referencing but as all TTI relies on location refencing of some type or other it is worth briefly mentioning.

There are a number of location referencing methodologies that can be used in TTI. There are described in CEN TR 17297:1:2019 which provides a concise tutorial on the different location methodologies used. The companion Technical Specification CEN TS 17297-2:2019 proposes methods and implications of transforming from one location referencing method to another.

RDS-TMC proposes its own location referencing in EN ISO 14819-3:2021

TPEG 2 proposes a number of location referencing methodologies which can be signalled in it Location Referencing Container ISO TS 21219-7:2017.

Similarly DATEX II proposed a number of differencing location referencing methodology in EN 16157-2:2019.

Link to individual standards summaries:

22.5 DATEX II

With the internet becoming more pervasive, object-oriented programming in the mainstream and XML based systems being developed, a project was launched in the early 2000s, sponsored by the European Commission, to develop an object-oriented and XML based version of DATEX. This required conceptual models with detailed descriptions of data types and content including order of elements, grammatical rules and range constraints. The initial work was continued by the CENTRICO project and its subsidiary projects, such as STREETWISE, and continued by the EasyWay projects. The outcome became known as DATEX II.

The DATEX II modelling approach is based on Model Driven Architecture (MDA) principles with modelling undertaken using the Unified Modelling Language(UML). It separates the technical concerns of data content from data exchange and is technology independent.

Harmonising ITS concepts at a European level takes a long time and it would be unsuitable to capture the results from this effort in a short lived, technology dependent way. The UML offers exactly the required stability, with the concrete mapping to exchange artefacts.

The initial implementation platform for encoding DATEX II content is the W3C standard for XML schema definition. The mapping is well defined in the specifications and has been implemented in a tool that users can download together with the model itself, the whole specification and further supporting material. In the second half of the 2010's, other mappings from DATEX II UML were added: to json schema and ASN.1.

DATEX II can be used for all data exchange applications with dynamic information on transport systems and in particular the road system. The main uses are:

Rerouting, network management and traffic management planning both on motorway and urban networks;
Lane or queue control systems and related applications like ramp metering (controlling vehicle access onto motorways to smooth integration of new traffic) , dynamic speed limits and overtaking control;
Linking traffic management and traffic information systems;
Applications for data exchange between multi-modal management and information systems;
Applications for the exchange of traffic data;
Provision of services in the framework of road management with a strong link to network safety or performance like Truck Parking.

For all these domains DATEX II supports interoperability and cooperation between diverse actors to allow the unhindered exchange of data or information. However, DATEX II is also designed for use within single operator systems.

Users are able to extend the DATEX II model according to application specific needs, but they are also able to select those elements for schema creation that are actually used in their services. Thus, slim services can still work with slim schemas without having to carry the full burden of the huge DATEX II model.

Users that have created extensions that they feel could be of wider use can submit them in a dedicated section on the DATEX II website. Here they can be downloaded by other users and then discussed for future integration into the main standard.

The DATEX II organisation has defined an approval process that deals with these user community provided inputs as well as with all other user feedback (forum discussions, issue reports) via the website.

The DATEX II organisation not only supports DATEX II users and maintains the standard, it also monitors and supports the deployment of DATEX II at the European level. Its deployment and use are guided by guidelines from EU initiatives such as the EU IITS Platform (EU EIP).

At the time of writing there are twelve parts to the DATEX II data content specifications published by cen, standardised in Europe to Technical Specification (TS) level with moves towards taking them to full European standards (EN):

EN 16157-1:2018 Part 1 Context and framework;
EN 16157-2:2019 Part 2: Location referencing;
EN 16157-3:2018 Part 3: Situation publication;
EN 16157-4:2021 Part 4: Variable Message Sign (VMS) Publications;
EN 16157-5:2020 Part 5: Measured and Elaborated Data Publications;
CEN TS 16157-6:2015 Part 6: Parking Publication;
EN 16157-7:2018 Part 7: Common data elements.
CEN TS 16157-8:2020 Part 8: Traffic management publications and extensions dedicated to the urban environment
CEN TS 16157-9 Part 9: traffic signal management publications
CEN TS 16157-10:2022: Energy Infrastructure
CEN TS 16157-11:2022: Traffic regulations
CEN TS 16157-12:2022: Facilities

Link to individual DATEX II Standards summaries:

DATEX II exchange specifications are published as ISO CEN TS 19468:2022 (exchange platform-independent model and ISO CEN TS 14827-4:2022 (exchange platform-specific model for web services)

22.6 Traffic and Traveller Information Services

22.6.1 Radio Data Systems – Traffic Message Channel (RDS-TMC)

RDS-TMC is a one-to-many uni-directional broadcast systems. Its objective is to broadcast Traffic and Travel Information (TTI) messages as data on VHF/FM transmissions using RDS. This allows delivery of accurate, timely and relevant information without the need to interrupt the radio programme - just the opposite of the common practice with spoken traffic messages. Thus, TTI can be broadcast inaudibly in the background of existing VHS/FM radio programmes to be later presented to the user.

RDS-TMC relies upon a simple encoding process which requires the use of predetermined databases for event descriptions (and location information) to be present at both the Service Providers and all their customers or subscribers. Thus, a simple number can be transmitted via RDS-TMC, and by using a look-up method, it can be interpreted into an understandable message in the RDS-TMC receiver. Whilst this has some disadvantages, e.g. the receiver must have an up-to-date copy of the database, it has one big advantage: the customers can use a receiver which presents the information in their own language.

This is a big advantage in Europe, with so many languages in everyday use in very close geographical proximity. The coding also permits users to receive only those messages that are relevant to their needs. Thus, it may be possible for tourists to travel, for example, from London to Rome, through Belgium, Germany, Switzerland, France and Italy, while always getting the traffic announcements via RDS-TMC in their own language; the location codes being on a smart card or CD-ROM that was purchased in London.

The TTI messages that are distributed will, of course, be conveyed to and stored in receiver memory which may subsequently permit traffic announcements to be presented via speech synthesis in the language required or inserted onto a user understandable graphic display. Messages can be filtered on the basis of criteria derived from the needs of the end-user (e.g. location, direction, route). This filtering aims at enabling the user to receive only relevant information, selected from all the messages that are available on an RDS-TMC service, at any given time.

22.6.1.1 The RDS-TMC ALERT C protocol

The RDS-TMC ALERT C protocol is standardised in EN ISO 14819-1:2021. The RDS data stream employed for RDS-TMC is standardised in EN 50067:1998 Specification of the Radio Data System (RDS) for VHF/FM Sound Broadcasting in the Frequency Range from 87,5 to 108,0 MHz

A single group message is made up of 37 bits from the type 8A group. It is possible to have messages made up of more than one group - a multigroup. The presence of a multigroup message is signalled in the first group.

A single group 37 bit message is made up of the following parts:

Location 16 bits

Event 11 bits

Extent 3 bits

Direction 1 bit

Duration 3 bits

Diversion Advice 1 bit

F (0 = Single Group Message) 1 bit

T (0 = User Message) 1 bit

TOTAL 37 bits

If F = 1 then a multi group message is indicated.

Multi-group messages are sequences of between two and five type 8A groups which constitute a detailed TMC message. The presence of a multigroup message is signalled in the first 8A group. A continuity group is provided in subsequent 8A groups which is incremented for each 8A group of the multigroup messages.

Multigroup messages can contain:

The length of the route affected;
Speed limit advice;
Additional more detailed quantifies;
Supplementary information codes;
Explicit start time;
Explicit stop times;
Additional events;
Detailed diversion instructions;
Destination;
Precise location references;
Cross linkage to a source of the problem on a different route.

22.6.1.2 The RDS-TMC Message Set

The ALERT-C protocol event list is standardised in EN ISO 14819-2:2021 . These event phrases total over 1400 from a possible 2048 events, and these are divided into 31 update classes for coding and message management convenience. The Event list in this standard is written in so-called CEN-English to allow it to be translated by knowledgeable traffic engineering interpreters into user-friendly phrases in the languages of Europe.

22.6.1.3 RDS-TMC Location Referencing

Most RDS-TMC messages provide information about a location (e.g. a stretch of road, an intersection, a region) and they refer to it by using a location reference. This is an identifier that can be interpreted without ambiguity by the receiving system.

In RDS-TMC, locations are pre-defined and pre-coded, and the codes are stored in location code tables. The maximum number of codes in one table is determined by the field length for location codes in RDS-TMC, i.e. 16 bit, which corresponds to 65,536 possible codes.

One disadvantage of these tables is that they need to be created and maintained. Also, the receiving system must use exactly the same location code table as the one used for encoding of the message - otherwise the message is not receivable.

The rules for location reference coding are specified in EN ISO 14819-3:2021.

RDS-TMC uses a hierarchical structure of pre-defined locations. A system of pointers provides upwards references to higher level locations containing the specified location. For example, Kent would have an upward area reference to South-East England which will be upwards referenced to the UK, then the British Isles, then Europe.

Junction 25 on the M1 motorway in the UK would have a section of route referenced to a motorway segment, e.g. Leicester - Sheffield. This segment will then be referenced upwards to the whole road, i.e. the motorway M1.

Link to individual RDS-TMC Standards summaries:

22.6.2 TPEG (Traffic Protocol Experts Group)

22.6.2.1 Background

In 1997 the European Broadcasting Union (EBU) invited experts from the national broadcasters, transmission operators, consumer electronics manufacturers and transport authorities to come together in an EBU project named B/TPEG to develop a new protocol for Traffic and Travel Information that would be suited for a multimedia broadcasting environment using high speed broadcast bearers. It was planned that applications, service and transmission transport features would be developed which would enable travel-related messages to be coded, decoded, filtered and understood both by humans (visually and/or audibly) and by agent systems.

At that time RDS-TMC was beginning to be implemented but the EBU saw a number of shortcomings. Firstly, the low data rate of 104 bits/sec meant that only two messages could be broadcast every second. Secondly, the pre-coded predefined location referencing had limitations: there was a limit to the number of locations (only junctions could be coded) and the location table in the receiver had to be synchronised with the location table at the service provider. Thirdly, the fixed and rigid event table was not suitable for analysis by an intelligent agent in the vehicle. The EBU therefore wanted a faster and more flexible system with an “on-the fly” method of location coding.

22.6.3 TPEG Binary

Beginning in 1997 the B/TPEG group met for two days, once per month, to develop a new protocol. The first protocols coded in binary for efficiency.

TPEG was seen as providing a pipeline for data delivery such that users need not be aware of the mechanisms and communication technologies (e.g. DAB, Internet) involved; the Transport Layer in the OSI 7-layer conceptual model of communications (Wikipedia, n.d.).

The TPEG Specifications comprised a number of 'Parts', defining the mechanisms that permit Service Providers to operate services which can use one or more delivery technologies (e.g. DAB, Internet) from one message generation process. They allow a range of receiver types to be used simultaneously, ranging from sophisticated agent receivers serving navigation systems, through to simple receivers (e.g. a Personal Digital Assistant plug-in receiver/decoder card) only able to decode 'top level' information.

Further information can be found in ISO CEN TS 18234 parts 1, 2 and 3 which comprise Introduction, Numbering and Versions, Syntax, Semantics and Framing and Service and Network Information respectively.

Various applications for TPEG binary were developed in the CEN and ISO CEN TS 18234, – series which can be seen in Section 22.7.5.

22.6.3.1 TPEG-ML

During development of the binary versions of the standards, coding of applications in XML was beginning to be developed and it was agreed that all the binary applications should also be developed using XML. Hence, the development of the ISO CEN 24530 series. Again, due to synchronisation issues between CEN and ISO, not all parts were published in both standardisation bodies.

Additionally, synchronisation of part numbers were not carried through; for instance, RTM which was Part 4 in the binary version became Part 3 in the ML version and so on.

Various applications for TPEG-ML were developed in the CEN and ISO TS 18234 – series which can be seen in Section 22.7.5.

22.6.3.2 TPEG Location Referencing

One of the main reasons for developing TPEG was to move the technology beyond the pre-coded location tables employed by RDS-TMC towards describing actual event locations. An “on the fly” method was required that had greater locational resolution (not just junctions) and did not require synchronisation between the receiver and the service provider.

TPEG-LOC was developed to overcome these issues. TPEG-LOC is a combination of WGS84 location referencing plus a short description of the location. The short description is needed to confirm directionality and also to differentiate between roads in very close proximity. It is not that WG84 is inaccurate, rather that different maps vary in relation to an absolute WGS84 point. Hence, if the service provider is using a map from one provider which is different to the map in the receiver, then errors can occur.

During development of the original TPEG a number of other location referencing methodologies were proposed leading to the concept of a location referencing container in ISO CEN TS 18234 part 11 described earlier.

22.6.4 TPEG 2

The problems of synchronising standards in separate series for binary and for XML versions became a real burden for the development teams. This led to the decision in the mid 2000s to redefine all the applications using the Unified Modelling Language (UML) in a development tool Enterprise Architect software suite and translate from the UML to a binary and a XML implementation; this decision notable allowed non-coding experts, but more particularly TTI experts to help develop the applications without coding expertise constraints.

Additionally, it was agreed that TPEG2 would only be standardised by ISO to reduce the ISO/CEN synchronisation issues. Each standard now has a UML part and then a translation into the binary and XML parts.

The standardisation is in the ISO 21219 series. Currently there are 20 TPEG2 parts published, or close to being published’, as Technical Specifications or full ISO Standards. It is the eventual aim that all TPEG 2 standards become International Standards.

22.7 The TPEG2 Standards

Although there are 26 parts of TPEG2 declared, in reality a number will never be published as their contents are covered in other standards such as ISO 17572-1:2015, ISO 17572-2:2018 and ISO 17571-3:2015.

The standards can be considered in three parts:

Non TTI application control and TPEG toolkits;
Location referencing; and,
TPEG applications.

The first non-TTI application parts are:

1. ISO TS 21219-1:2016 – Part 1- Introduction, versions and numbering (in the process of being published as an IS in 2022

2. ISO 21219-2:2019 – UML modelling rules

3. ISO 21219-3:2019 – UML to binary conversion rules

4. ISO 21219-4:2019 - UML to XML conversion rules

5. ISO 21219-5:2019 – Service framework

6. ISO 21219-6:2019 – Message management container

7. ISO 21219-7:2019 – Location referencing container (in the process of being upgraded to an IS in 2022)

8. ISO TS 21219-9:2016 – Service and network information (in the process of being published as an IS in 2022

9. ISO TS 21219-10:2016 – Conditional access information (in the process of being published as an IS in 2022

10. ISO TS 21219-24:2017 – Light encryption (in the process of being upgraded to an IS in 2022)

The location referencing parts which are referenced by ISO 21219-6:2019 are:

1. ISO 17572-2:2018 – Precoded location referencing

2. ISO 17571-3:2015 – Dynamic location referencing

3. ISO TS 21219-21:2018 – Geographic location referencing (in the process of being upgraded to an IS in 2022)

4. ISO TS 21219-22:2017 – OpenLR location referencing

The application referencing parts are:

1. ISO TS 21219-14 – Parking information (in the process of being published as an IS in 2022)

2. ISO TS 21219-15:2016 – Traffic event compact (in the process of being published as an IS in 2022

3. ISO TS 21219-16:2016 – Fuel price information and availability (in the process of being published as an IS in 2022

4. ISO CD 21219-17 – Speed information (undergoing DIS ballot in 2022)

5. ISO 21219-18:2019 – Traffic flow and prediction

6. ISO TS 21219-19:2016 – Weather information (undergoing publication as an IS in 2022)

7. ISO TS 21219-23:2016 – Roads and multi-modal routes (in the process of being published as an IS in 2022

8. ISO TS 21219-24:2017 – Intelligent transport systems -- Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) -- Part 24: Light encryption (TPEG2-LTE)

9. ISO TS 21219-25:2017 – Electromobility charging infrastructure (in the process of being published as an IS in 2022

10. ISO TS 21219-26:2018 – Vigilance location information (in the process of being published as an IS in 2022

Link to individual TPEG Standards summaries:

22.8 Other message sets

Message sets do not have to just cover just events and status, there are other message sets that cover signs. The Graphic Data Dictionary ISO EN 14823:2018 assigns a structured code to each type of physical road signs based on the UN Vienna Convention on Road Signs. The list is further defined in ASN.1 which allows for the combination of signs and the assignment of attributes. A very useful Technical Report ISO TR 14823-2 has been produced that gives examples of the use of the Graphic Data Dictionary.

22.9 Regulations

22.9.1 Deployment of RDS-TMC

Communication from the Commission to the Council and the European Parliament on a Community strategy and framework for the deployment of road transport telematics in Europe and proposals for initial actions covering deployment of RDS-TMC among other RTTI initiatives.

22.9.2 National access points

The Commission Delegated Regulation (EU) 2017/1926 requires that Member States facilitate the easy exchange and reuse of data for the provision of comprehensive travel information services. Transport authorities, transport operators, infrastructure managers or transport on demand service providers, as appropriate, should make the static data, corresponding metadata and information on the quality of the data accessible to users through a national or common access point. This regulation will impact the formatting of traffic and travel data so as to allow easy exchange of data using DATEX II and the message sets developed previously in Europe.

22.10 Standards

22.10.1 Radio Data Systems (RDS) standards

22.10.1.1 EN 50067:1998 Specification of the Radio Data System (RDS) for VHS/FM sound broadcasting in the frequency range from 87,5 To 108,0 MHz

LINK: EN 50067:1998

The Radio Data System, RDS, is intended for application to VHS/FM sound broadcasts in the range 87.5 MHz to 108.0 MHz which may carry either stereophonic (pilot-tone system) or monophonic programmes. The main objectives of RDS are to enable improved functionality for FM receivers and to make them more user-friendly by using features such as Programme Identification, Programme Service name display and where applicable, automatic tuning for portable and car radios, in particular. The relevant basic tuning and switching information shall therefore be implemented by the type 0 group, and it is not optional unlike many of the other possible features in RDS.

22.10.2 DATEX II

Only the parts of EN 16157 that are relevant to TTI have been included.

22.10.2.1 EN 16157-1:2018 Intelligent transport systems - DATEX II data exchange specifications for traffic management and information - Part 1: Context and framework

LINK: EN 16157-1:2018

This document specifies and defines components required to support the exchange and shared use of data and information in the field of traffic and travel. The components include the framework and context for the modelling approach, data content, data structure and relationships.

This document is applicable to: - traffic and travel information which is of relevance to road networks (non-urban and urban), - public transport information that is of direct relevance to the use of a road network (e.g. road link via train or ferry service), - traffic and travel information in the case of Cooperative intelligent transport systems (C-ITS). This document establishes specifications for data exchange between any two instances of the following actors: - Traffic Information Centres (TICs), - Traffic Control Centres (TCCs), - Service Providers (SPs), Use of this document can be applicable for use by other actors.

This document covers, at least, the following types of informational content: - road traffic event information - planned and unplanned occurrences both on the road network and in the surrounding environment, - information about operator-initiated actions - including both advisory and mandatory measures, - road traffic measurement data, status data, and travel time data, - travel information relevant to road users, including weather and environmental information, - road traffic management information and information and advice relating to use of the road network.

This part of EN 16157 specifies the DATEX II framework of all parts of this European Standard, the context of use and the modelling approach taken and used throughout this European Standard. This approach is described using formal methods and provides the mandatory reference framework for all other parts.

22.10.2.2 EN 16157-2:2019 Intelligent transport systems - DATEX II data exchange specifications for traffic management and information - Part 2: Location referencing

LINK: EN 16157-2:2019

This European Standard series (EN 16157) specifies and defines component facets supporting the exchange and shared use of data and information in the field of traffic and travel. The component facets include the framework and context for exchanges, the modelling approach, data content, data structure and relationships.

This European Standard series is applicable to: - traffic and travel information which is of relevance to road networks (non-urban and urban), - public transport information that is of direct relevance to the use of a road network (e.g. road link via train or ferry service), - traffic and travel information in the case of Cooperative intelligent transport systems (C-ITS).

This European Standard series establishes specifications for data exchange between any two instances of the following actors: - Traffic Information Centres (TICs), - Traffic Control Centres (TCCs), - Service Providers (SPs). Use of this European Standard series may be applicable for use by other actors.

This European Standard series covers, at least, the following types of informational content: - road traffic event information – planned and unplanned occurrences both on the road network and in the surrounding environment, - operator initiated actions, - road traffic measurement data, status data, and travel time data, - travel information relevant to road users, including weather and environmental information, - road traffic management information and instructions relating to use of the road network.

This part of the EN 16157 series specifies the informational structures, relationships, roles, attributes and associated data types, for the implementation of the location referencing systems used in association with the different publications defined in the Datex II framework. It also defines a DATEX II publication for exchanging predefined locations. This is part of the DATEX II platform independent data model.

22.10.2.3 EN 16157-3:2018 Intelligent transport systems - DATEX II data exchange specifications for traffic management and information - Part 3: Situation Publication

LINK: EN 16157-3:2018

This document specifies and defines component facets supporting the exchange and shared use of data and information in the field of traffic and travel. The component facets include the framework and context for exchanges, the modelling approach, data content, data structure and relationships. This document is applicable to: - traffic and travel information which is of relevance to road networks (non-urban and urban), - public transport information that is of direct relevance to the use of a road network (e.g. road link via train or ferry service), - traffic and travel information in the case of Cooperative intelligent transport systems (C-ITS).

This document establishes specifications for data exchange between any two instances of the following actors: - Traffic Information Centres (TICs), - Traffic Control Centres (TCCs), - Service Providers (SPs), Use of this document can be applicable for use by other actors.

This document covers, at least, the following types of informational content: - road traffic event information - planned and unplanned occurrences both on the road network and in the surrounding environment, - operator-initiated actions, - road traffic measurement data, status data, and travel time data, - travel information relevant to road users, including weather and environmental information, - road traffic management information and instructions relating to use of the road network.

This document specifies the informational structures, relationships, roles, attributes and associated data types required for publishing situation traffic and travel information within the DATEX II framework. This is specified as a DATEX II Situation Publication sub-model which is part of the DATEX II platform independent model, but this part excludes those elements that relate to: - location information which are specified in EN 16157 2; - common information elements, which are specified in EN 16157 7.

22.10.2.4 EN 16157-4:2021 Intelligent transport systems - DATEX II data exchange specifications for traffic management and information - Part 4: Variable Message Sign (VMS) Publications

LINK: EN 16157-4:2021

This European Standard (EN 16157 series) specifies and defines component facets supporting the exchange and shared use of data and information in the field of traffic and travel. The component facets include the framework and context for exchanges, the modelling approach, data content, data structure and relationships.

This European Standard is applicable to: - Traffic and travel information which is of relevance to road networks (non-urban and urban), - Public transport information that is of direct relevance to the use of a road network (e.g. road link via train or ferry service), - Traffic and travel information in the case of Cooperative intelligent transport systems (C-ITS).

This European Standard establishes specifications for data exchange between any two instances of the following actors: - Traffic Information Centres (TICs), - Traffic Control Centres (TCCs), - Service Providers (SPs), Use of this European Standard may be applicable for use by other actors. This European Standard series covers, at least, the following types of informational content: - Road traffic event information – planned and unplanned occurrences both on the road network and in the surrounding environment, - Operator initiated actions, - Road traffic measurement data, status data, and travel time data, - Travel information relevant to road users, including weather and environmental information, - Road traffic management information and instructions relating to use of the road network.

This part of the CEN/TS 16157 series specifies the informational structures, relationships, roles, attributes and associated data types required for publishing variable message sign information within the DATEX II framework.

This is specified in two publications, a DATEX II VMS Table Publication sub-model and a VMS Publication sub-model, which are part of the DATEX II platform independent model, but this part excludes those elements that relate to: - location information which are specified in EN 16157-2, - common information elements, which are specified in EN 16157-7, - situation information which are specified in EN 16157-3.

The VMS Table Publication supports the occasional exchange of tables containing generally static reference information about deployed VMS which enable subsequent efficient references to be made to pre-defined static information relating to those VMS.

The VMS Publication supports the exchange of the graphic and textual content of one or several VMS plus any status information on device configuration that aid the comprehension of the informational content. This content is potentially subject to rapid change.

These publications are not intended to support the control or configuration of VMS equipment. Each is part of the DATEX II platform independent model.

22.10.2.5 EN 16157-5:2020 Intelligent transport systems - DATEX II data exchange specifications for traffic management and information - Part 5: Measured and elaborated data publication

LINK: EN 16157-5:2020

This document is the fifth part of the DATEX II European Standard which deals with the publication sub-models within the DATEX II model that support the exchange of measured and elaborated information. These publications are intended to support the exchange of informational content from the organization having the measured data and creating elaborated data to other organisations providing ITS services or onward information exchange. It also includes the exchange of static information about measurement sites.

This is specified in three sub-models, a DATEX II Measurement Site Table Publication sub-model, a DATEX II Measured Data Publication sub-model and a DATEX II Elaborated Data Publication sub-model.

22.10.2.6 CEN TS 16157-6:2021 Intelligent transport systems - DATEX II data exchange specifications for traffic management and information - Part 6: Parking Publications

LINK: CEN TS 16157-6:2021

This new work item will revise and extend the sixth part of the DATEX II Technical Specifications which defines three DATEX II parking-related publications and a truck parking profile and that supports the exchange of static as well as dynamic information about parking facilities and areas, including intelligent truck parking as defined by the Directive 2010/40/EU priority action e as well as urban parking as specified in action a.

The formerly used Level B extension will be replaced by a new namespace in the context of version 3.0 of DATEX II. The publications are intended to support the exchange of informational content from the organisation performing measurements and collecting/eliciting basic data to other organisations providing ITS services or onward information exchange.

It is the ambition to harmonise existing information models from different sources such as EasyWay deployment guidelines and truck parking initiatives, and to liaise with the stakeholders involved, especially with the Alliance for Parking Data Standards and CEN/TC 278 working group 3

22.10.2.7 EN 16157-7:2018 Intelligent transport systems - DATEX II data exchange specifications for traffic management and information - Part 7: Common data elements

LINK: EN 16157-7:2018

This document specifies and defines component facets required to support the exchange and shared use of data and information in the field of traffic and travel. The component facets include the framework and context for data content, data structure and relationships, communications specification.

This document covers, at least, the following types of informational content: - road traffic event information - planned and unplanned occurrences both on the road network and in the surrounding environment, - information about operator initiated actions - including both advisory and mandatory measures, - road traffic measurement data, status data, and travel time data, - travel information relevant to road users, including weather and environmental information, - road traffic management information and information and advice relating to use of the road network.

This part of EN 16157 (EN 16157-7:2018) specifies common informational structures, relationships, roles, attributes, and associated data types required for publishing information within the DATEX II framework. This is specified as a DATEX II sub-model which is part of the DATEX II platform independent model, but this part only covers common elements that are used by more than one publication. It excludes those elements that relate to location information which are specified in EN 16157-2.

22.10.3 RDS-TMC – Alert C

22.10.3.1 EN ISO 14819-1:2021 Intelligent transport systems -- Traffic and travel information messages via traffic message coding -- Part 1: Coding protocol for Radio Data System -- Traffic Message Channel (RDS-TMC) using ALERT-C

LINK: EN ISO 14819-1:2021

EN ISO 14819-1:2021 describes the ALERT-C protocol concept and message structure used to achieve densly coded messages to be carried in the RDS-TMC feature.

EN ISO 14819-6 has been withdrawn and is now included within EN ISO 14819-1:2021. establishes a method of encrypting certain elements of the ALERT-C coded data carried in the RDS-TMC type 8A data group, such that without application by a terminal or receiver of an appropriate keys, the information conveyed is virtually worthless.

Before a terminal can decrypt the data, the terminal requires two "keys". The first is given in confidence by the service provider to terminal manufacturers with whom they have a commercial relationship; the second is broadcast in the "Encryption Administration Group," which is also a type 8A group.

This specification explains the purpose of the two keys and how often and when the transmitted key may be changed. Before an individual terminal may present decrypted messages to the end-user, it must have been activated to do so. Activation requires that a PIN code be entered. The PIN code controls access rights to each service and subscription period, allowing both lifetime and term business models to co-exist.

The specification also describes the considerations for service providers wishing to introduce an encrypted RDS-TMC service, migrating from either a "free-to-air" service based on public "Location Tables" or a commercial service based on a proprietary Location Table.

Finally, "hooks" have been left in the bit allocation of the type 8A group to allow extension of encryption to other RDS-TMC services.

22.10.3.2 EN ISO 14819-2:2021 Intelligent transport systems -- Traffic and travel information messages via traffic message coding -- Part 2: Event and information codes for Radio Data System - Traffic Message Channel (RDS-TMC) using ALERT-C

LINK: EN ISO 14819-2:2021

EN ISO 14819-2:2021 defines the Events List to be used in coding those messages.

22.10.3.3 EN ISO 14819-3:2021 Intelligent transport systems -- Traffic and travel information messages via traffic message coding -- Part 3: Location referencing for Radio Data System - Traffic Message Channel (RDS-TMC) using ALERT-C

LINK: EN ISO 14819-3:2021

EN ISO 14819-3:2021 sets out ways of specifying places and positions in traffic and travel information messages, including RDS-TMC messages (the Radio Data System - Traffic Message Channel). It primarily addresses the needs of RDS-TMC ALERT-C messages which are already being implemented. However, the modular approach used is intended to facilitate future extension of the location referencing rules to other traffic and travel messaging systems.

22.10.3.4 EN ISO 14819-6:2014 Traffic and Traveller Information (TTI) -- TTI messages via traffic message coding -- Part 6: Encryption and conditional access for the Radio Data System - Traffic Message Channel ALERT C coding

LINK: EN ISO 14819-6:2014

EN ISO 14819-6:2014 establishes a method of encrypting certain elements of the ALERT-C coded data carried in the RDS-TMC type 8A data group, such that without application by a terminal or receiver of an appropriate keys, the information conveyed is virtually worthless.

Finally, "hooks" have been left in the bit allocation of the type 8A group to allow extension of encryption to other RDS-TMC services.

NOTE: EN ISO 14819-6:2014 will be withdrawn once EN ISO 14819-1:2020 is published. EN ISO 14819-3:2014 technology is fully incorporated into EN ISO 14819-1:2020.

22.10.4 Unused and legacy TPEG Standards

The CEN ISO 18234 series and CEN ISO 24530 series have been replaced by the ISO 21219 series.

The problems of synchronising standards in separate series for binary and for XML versions became a real burden for the development teams. This led to the decision in the mid 2000s to redefine all the applications using the Unified Modelling Language (UML) in a development tool Enterprise Architect software suite and translate from the UML to a binary and an XML implementation; this decision notable allowed non-coding experts, but more particularly TTI experts to help develop the applications without coding expertise constraints.

CEN ISO TS 18234-1:2013 Intelligent transport systems - Traffic and travel information via transport protocol experts group, generation 1 (TPEG1) binary data format - Part 1: Introduction, numbering and versions (TPEG1-INV)

This Technical Specification provides an introduction and index to the complete set of TPEG Generation 1 toolkit components and applications. It allows the indexing of new applications as they are added to the TPEG applications family, by defining their Application Identification (AID).

This Technical Specification will be updated when such developments occur, to indicate the latest status and the inter-working of the various TPEG specifications. It will be issued as a new editorial version every time a new issue of any other specification is issued.

ISO TS 18234-2:2013 Intelligent transport systems - Traffic and travel information via transport protocol experts group, generation 1 (TPEG1) binary data format - Part 2: Syntax, semantics and framing structure (TPEG1-SSF)

This Technical Specification establishes the method of referencing used within a TPEG data-stream to allow a service provider to signal availability of the same service on another bearer channel or similar service data from another service.

CEN ISO TS 18234-3:2013 Intelligent transport systems - Traffic and travel information via transport protocol experts group, generation 1 (TPEG1) binary data format - Part 3: Service and network information (TPEG1-SNI)

This Technical Specification establishes the method of delivering service and network information within a TPEG service. The TPEG-SNI application is designed to allow the efficient and language independent delivery of information about the availability of the same service on another bearer channel or similar service data from another service provider, directly from service provider to end-users.

ISO TS 18234-4:2006 Intelligent transport systems - Traffic and travel information via transport protocol experts group, generation 1 (TPEG1) binary data format - Part 4: Road Traffic Message (RTM) application

This document establishes the method of delivering Road Traffic Messages within a TPEG service. The TPEG-RTM application is designed to allow the efficient and language independent delivery of road information directly from service provider to end-users. The information provided relates to event and some status information on the road network and on associated infrastructure affecting a road journey. For example, limited information about abnormal operation of links in the network may be included, such as ferries, lifting-bridges, etc.

ISO TS 18234-5:2006 Intelligent transport systems - Traffic and travel information via transport protocol experts group, generation 1 (TPEG1) binary data format - Part 5: Public Transport Information (PTI) application

This Technical Specification describes the Public Transport Information (PTI) Application, which is intended to cover all modes of public (i.e. collective) transport as well as inter-urban and intra-urban travel. The application is designed to allow the efficient and language independent delivery of public transport information directly from service provider to end-users.

ISO TS 18234-6:2006 Intelligent transport systems - Traffic and travel information via transport protocol experts group, generation 1 (TPEG1) binary data format - Part 6: Location referencing applications (LOC)

This Technical Specification establishes the method of location referencing used by TPEG applications such as TPEG-RTM or TPEG-PTI.

CEN ISO TS 18234-7:2013 Intelligent transport systems - Traffic and travel information via transport protocol experts group, generation 1 (TPEG1) binary data format - Part 7: Parking information (TPEG1-PKI)

This Technical Specification specifies the TPEG Parking Information Application (PKI) which is designed to deliver parking information to a variety of receivers using a number of different channels, foremost digital broadcasting and internet technologies. Parking information may be presented to the user in many different ways including textually, voiced and graphically using standard formats.

ISO TS 18234-8:2012 Intelligent transport systems -- Traffic and travel information via transport protocol experts group, generation 1 (TPEG1) binary data format -- Part 8: Congestion and Travel Time application (TPEG1-CTT)

This Technical Specification establishes a method for delivering Congestion and Travel Time Messages within a TPEG service.

CEN ISO TS 18234-9:2013 Intelligent transport systems - Traffic and travel information via transport protocol experts group, generation 1 (TPEG1) binary data format - Part 9: Traffic event compact (TPEG1-TEC)

This Technical Specification defines the TPEG application Traffic Event Compact (TEC). It has been specifically designed to support information about traffic events, e.g. road works, traffic jams. A specific form of traffic event are local hazard warnings, which as safety-related messages, are sent with high priority to assist a driver in encountering dangerous situations (e.g. black-ice, accident behind curves, obstacles on road) unexpectedly.

CEN ISO TS 18234-10:2013 Intelligent transport systems - Traffic and travel information via transport protocol experts group, generation 1 (TPEG1) binary data format - Part 10: Conditional access information (TPEG1-CAI)

This Technical Specification contains the definition of the TPEG Conditional Access Information (CAI) application. It enables dedicated conditional access data, such as management messages (e.g. Control Words and Entitlement Control Messages) to be delivered to recipient client devices. This TPEG application is designed for a service provider to: establish setup, prolongation or revocation of services to a specific client device, using a limited capacity unidirectional broadcast channel and without recourse to service-client handshaking.

CEN ISO TS 18234-11:2013 Intelligent transport systems - Traffic and Travel Information (TTI) via transport protocol experts group, generation 1 (TPEG1) binary data format - Part 11: Location Referencing Container (TPEG1-LRC)

CEN ISO TS 18234-11:2013 establishes the method of signalling the specific location referencing used by all TPEG1 applications that require detailed location information to be delivered to client devices such as TPEG1-RTM, TPEG1-PTI, TPEG1-TEC or TPEG1-PKI. The TPEG1-Location Referencing Container (TPEG1-LRC) is described as well as 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 present ISO series and the internal location referencing method (TPEG1-LOC) defined in Part 6 of this series.

CEN ISO TS 24530-1:2006 Traffic and Travel Information (TTI) - TTI via Transport Protocol Experts Group (TPEG) Extensible Markup Language (XML) - Part 1: Introduction, common data types and tpegML

This document establishes the top-level “containers” for TPEG messages in XML and the common data types that are used by tpegML applications (e.g. tpeg-ptiML). Inherently tpegML is designed to “map” TPEG Binary (ISO TS 18234 series), however additional tags are provided to create a message and message set structure to facilitate internet file delivery.

CEN ISO TS 24530-2:2006 Traffic and Travel Information (TTI) - TTI via Transport Protocol Experts Group (TPEG) Extensible Markup Language (XML) - Part 2: tpeg-locML

This document establishes the XML encoding of the method of Location Referencing used by TPEG applications.

CEN ISO TS 24530-3:2006 Traffic and Travel Information (TTI) - TTI via Transport Protocol Experts Group (TPEG) Extensible Markup Language (XML) - Part 3: tpeg-rtmML

This document establishes the XML encoding of the method of the Road Traffic Message application.

CEN ISO TS 24530-4:2006 Traffic and Travel Information (TTI) - TTI via Transport Protocol Experts Group (TPEG) Extensible Markup Language (XML) - Part 4: tpeg-ptiML

This document establishes the XML encoding of the method of the Public Transport Information application.

22.10.5 Current TPEG Standards (ISO only)

22.10.5.1 ISO TS 21219-1:2016 Intelligent transport systems -- Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) -- Part 1: Introduction, numbering and versions (TPEG2-INV)

LINK: ISO TS 21219-1:2016

ISO TS 21219-1:2016 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.

ISO TS 21219-1:2016 will be updated when such developments occur, to indicate the latest status and the inter-working of the various TPEG specifications. It will be issued as a new editorial version every time a new issue of any other specification is issued.

NOTE 1: This TS has been upgraded to an EN and will be published in 2022

22.10.5.2 ISO 21219-2:2019 Intelligent transport systems -- Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) -- Part 2: UML modelling rules (TPEG2-UMR)

LINK: ISO 21219-2:2019

This document specifies rules for the creation and extending of TPEG application UML models. The rules are intended to ensure that TPEG application UML models can be interpreted unambiguously for conversion to physical format representations. TPEG application UML models that are defined according to these rules can be used for automatic generation of TPEG standards and for automatic generation of TPEG application physical format descriptions.

This document also specifies the preferred structure of TPEG application specifications.

The TPEG abstract data types and the set of TPEG tables of common use are specified in the annexes.

22.10.5.3 ISO 21219-3:2019 Intelligent transport systems -- Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) -- Part 3: UML to binary conversion rules (TPEG2-UBCR)

LINK: ISO 21219-3:2019

TPEG applications are modelled in UML to provide an application description that is independent of a physical format representation. By separating semantics from application description, applications can easily be developed at a functional level. Different physical format representations can be generated following a well defined set of rules on how to convert UML classes to different physical formats.

This document specifies the rules for converting UML models of TPEG application to the TPEG binary format. It contains the binary format definition of the abstract data types defined in ISO 21219-2:2019. Rules for converting compound data types are also defined.

22.10.5.4 ISO 21219-4:2019 Intelligent transport systems -- Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) -- Part 4: UML to XML conversion rules

LINK: ISO 21219-4:2019

22.10.5.5 ISO 21219-5:2019 Intelligent transport systems -- Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) -- Part 5: Service framework (TPEG2-SFW)

LINK: ISO 21219-5:2019

This document establishes a method of conveying data for a wide range of applications that require the efficient transmission of point to multi-point data over potentially unreliable broadcast channels. It is also suitable for point-to-point and multicast applications and may easily be encapsulated in Internet Protocol.

This document describes the basic capabilities of the generation 2 TPEG (TPEG2) for providing a multiplex of TPEG Services and applications. Together with the definitions of the general TPEG UML modelling rules and the physical TPEG representations for TPEG-binary streams (TISA: TPEG UML Conversion Rules) and tpegML files (TISA Specification: TPEG UML Conversion Rules), it replaces the former documents TPEG-INV and TPEG-SSF.

22.10.5.6 ISO 21219-6:2019 Intelligent transport systems -- Traffic and travel information(TTI) via transport protocol experts group, generation 2 (TPEG2) -- Part 6: Message management container (TPEG2-MMC)

LINK: ISO 21219-6:2019

This document adds a basic toolkit definition to the ISO 21219 series specifying the Message Management Container (MMC) which is used by all TPEG applications to provide information about the handling of messages on the TPEG client side. The MMC holds administrative information allowing a decoder to handle the message appropriately. This information is not aimed at the end user. The MMC is a toolkit and not a stand-alone application but is included by TPEG applications.

22.10.5.7 ISO TS 21219-7:2017 Intelligent transport systems -- Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) -- Part 7: Location referencing container (TPEG2-LRC)

LINK: ISO TS 21219-7:2017

ISO TS 21219-7 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 such as TPEG2-TEC.

The TPEG2-location referencing container (TPEG2-LRC) is described 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 present ISO series and the internal location referencing methods defined as parts of this series.

Note: This TS is in the process of being revised and upgraded to an IS (Dec 2020)

22.10.5.8 ISO TS 21219-9:2016 Intelligent transport systems -- Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) -- Part 9: Service and network information (TPEG2-SNI)

LINK: ISO TS 21219-9:2016

this Technical Specification establishes the method of delivering service and network information within a TPEG service.

The TPEG-SNI application is designed to allow the efficient and language independent delivery of information about the availability of the same service on another bearer channel or similar service data from another service provider, directly from service provider to end-users.

NOTE A number of tables of information are described, which provide comprehensive options for describing services, their timing, content, geographical coverage, etc. In all TPEG streams, it is mandatory to deliver to so-called GST. Additionally, it is possible to signal linkage of content between different bearers and services.

Note: This TS is in the process of being revised and upgraded to an IS (Dec 2020)

22.10.5.9 ISO TS 21219-10:2016 Intelligent transport systems -- Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) -- Part 10: Conditional access information (TPEG2-CAI)

LINK: ISO TS 21219-10:2016

ISO TS 21219-10:2016 defines the TPEG Conditional Access Information (CAI) application. It allows to protect the content of a TPEG service from unauthorized access. It further supports the management of subscriber information (e.g. Control Words and ECM) on the client devices in order to setup, prolong or revoke a subscription on a given client device.

The application defines:

- the logical channel, for the transmission of the additional CA information (CAI), and

- how the CAI is linked and synchronized to the scrambled content.

ISO TS 21219-10:2016 is related to conditional access applied on service component level. It is open for an integration of different conditional access systems.

NOTE The basic concept behind the CAI application is to transport CAI in separate TPEG service components of a dedicated application type and to define an SNI table that contains the link between scrambled content and related CAI.

Note: This TS is in the process of being revised and upgraded to an IS (Planned 2022)

22.10.5.10 ISO DIS 21219-13 Intelligent transport systems -- Traffic and travel information via transport protocol experts group, generation 2 (TPEG2) -- Part 13: Public transport information (TPEG2-PTS)

In approval process

This document describes the Public Transport Information Service (PTS) Application, which is intended to cover all modes of public (i.e. collective) transport both inter-urban and intra-urban travel. The 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 design is based on three main use cases:

Provision of alert information. An alert is a warning that indicates an emergency. This case is specifically relevant for broadcast / push mode, for major deviations/ disruptions 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 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 specification.

22.10.5.11 ISO TS 21219-14:2016 Intelligent transport systems -- Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) -- Part 14: Parking information application (TPEG2-PKI)

LINK: ISO TS 21219-14:2016

ISO TS 21219-14:2016 specifies the TPEG Parking Information application which has been designed to deliver parking information to a variety of receivers using a number of different channels, foremost of course are digital broadcasting and Internet technologies. Parking information may be presented to the user in many different ways, including text, voice, or graphics.

Today, traffic congestion has become a serious problem in urban areas. Some traffic congestion is attributed to drivers searching for parking spaces. Therefore, timely provision of parking information could help ease traffic congestion. Furthermore, parking information would be valuable for the visitor, particularly when it could be used to signal where a temporary parking facility is established for a special occasion.

NOTE This TS has been revised and will be published as an IS (2022).

22.10.5.12 ISO TS 21219-15:2016 Intelligent transport systems -- Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) -- Part 15: Traffic event compact (TPEG2-TEC)

LINK: ISO TS 21219-15:2016

ISO TS 21219-15:2016 specifies the TPEG application: Traffic Event Compact (TEC). The TEC application has been specifically designed to support information about traffic events (e.g. road works, traffic jams). A specific form of traffic events are local hazard warnings which, being safety-related messages, are sent with high priority to warn a driver that may encounter dangerous situations (e.g. black-ice, accident beyond curves, obstacles on road, etc.) unexpectedly.

Generally, the Traffic Event Compact application is designed to allow receivers to

- ensure travel safety for the driver,

- enable the calculation of alternative routes,

- avoid delays (e.g. traffic jams),

- warn the driver of obstructions on route, and

- provide the driver with information on infrastructural problems (e.g. closed petrol stations, non-functioning emergency telephones).

NOTE This TS has been revised and will be published as an IS (2022).

22.10.5.13 ISO TS 21219-16:2016 Intelligent transport systems -- Traffic and travel information via transport protocol exports group, generation 2 (TPEG2) -- Part 16: Fuel price information and availability (TPEG2-FPI)

LINK: ISO TS 21219-16:2016

ISO TS 21219-16:2016 specifies the TPEG application: Fuel price information and availability (FPI). The FPI application has been specifically designed to support information of fuel stations, their location, fuel types offered and fuel pricing and availability information.

NOTE This TS has been revised and will be published as an IS (2022).

22.10.5.14 ISO CD 21219-17 Intelligent transport systems -- Traffic and travel information via transport protocol experts group, generation 2 (TPEG2) -- Part 17: Speed information (TPEG2-SPI)

LINK: ISO CD 21219-17

Speed limits are usually indicated to the driver through roadside signs. Drivers being aware of speed limits at any time improve road safety.

Most speed limit signs are static and remain 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 reflected in the map databases yet. Speed limit information is offered in an accurate way so that different lanes and different vehicle types can be differentiated.

TPEG Speed Information 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. The data is seen as informational and will be encoded in a compact way to minimize bandwidth consumption.

In any case legal restrictions for speed limits shall be followed by the drivers. This applies for example in countries where during wet conditions different speed limits must be followed.

TPEG2-SPI supports direct and indirect speed limits. Direct speed limits are used for signs showing a maximum speed a vehicle is allowed to travel. Such speed limit signs can be static or dynamic. Indirect speed limits are referring to the speed of other road users. Mostly the vehicle in front of the own vehicle is used as a reference.

TTI 22.4 Loc Ref

TT! 22.5 DATEX II

TTI 22.6 TT Inf Svs

TTI 22.7 TPEG2 Stds

TTI 22.8 other Msg Sets

TTI 22.9 Regulations

22.10 Standards

22.10.5.15 ISO 21219-18:2019 Intelligent transport systems -- Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) -- Part 18: Traffic flow and prediction application (TPEG2-TFP)

LINK: ISO 21219-18:2019

This document specifies the TPEG application Traffic Flow and Prediction (TFP). It has been specifically designed to provide information to a variety of receivers using different channels, including in the first instance digital broadcasting and Internet technologies. Traffic flow and prediction messages are intended for in-car applications and can also be presented directly to the user by textual, voice and graphical output devices.

TFP is status oriented, i.e. the transmitted information continuously updates the receiver's knowledge for a dedicated road network. In particular the traffic states are delivered any time and for all road sections of the network, even when there are no abnormal traffic situations.

Generally, TFP focuses on the following requirements:

— provides dynamic navigation systems with up-to-date traffic state information;

— ensures travel safety for the driver;

— enables the calculation of alternative routes;

— avoids delays (e.g. traffic jams);

— lowers traffic load on over-saturated parts of the network;

— keeps the driver informed about current and upcoming traffic;

— compact and efficient coding of the traffic information.

22.10.5.16 ISO TS 21219-19:2016 Intelligent transport systems -- Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) -- Part 19: Weather information (TPEG2-WEA)

LINK: ISO TS 21219-19:2016

ISO TS 21219-19:2016 defines the TPEG Weather (WEA) application for reporting weather information for travellers. It provides general weather-related information to all travellers and is not limited to a specific mode of transportation.

This application does not provide specific weather-related safety warnings to drivers; these are provided as Safety Related Messages as part of the TPEG2-TEC application.

The WEA application provides weather-related forecasts and status information over multiple time periods and for multiple, possibly linked, geographical areas.

NOTE The presentation of the information is dependent of the specific HMI of the receiving device.

ISO TS 21219-19:2016, therefore, does not define any prerequisites for the HMI of the device.

Note: This TS is in the process of being revised and upgraded to an IS (Dec 2020)

22.10.5.17 ISO TS 21219-21:2018 Intelligent transport systems -- Traffic and travel information via transport protocol experts group, generation 2 (TPEG2) -- Part 21: Geographic location referencing (TPEG-GLR)

LINK: ISO TS 21219-21:2018

ISO TS 21219-21:2018 defines a method of using geographic location referencing (GLR) that can be used by relevant TPEG applications. The GLR type is defined in this document. It 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 kept basic and compact on purpose, such 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 rather is on the referencing of man-made artefacts such as roads and highways.

The scope of GLR is limited to geographic locations on the Earth's surface for the above-mentioned rationale.

22.10.5.18 ISO TS 21219-22:2017 Intelligent transport systems -- Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) -- Part 22: OpenLR location referencing (TPEG2-OLR)

LINK: ISO TS 21219-22:2017

ISO TS 21219-22:2017 specifies the logical data format of OpenLRTM location references and general requirements of the method in Section 22.6 and defines the structure of the TPEG toolkit for OpenLRTM location referencing (OpenLRTM) in Sections 227, 22.8 and 22.9. The toolkit is intended to be used in the TPEG location referencing container (TPEG-LRC).

OpenLRTM has been designed for the use case of transferring traffic information from a centre to in-vehicle systems, built-in or used as an add-on (PND, smart phone). The information transferred can consist of the current traffic situation at a certain location, a traffic forecast or special alerts. The corresponding locations are roads, a list of connected roads, points of interest, or areas.

In order to transmit location information from a sending to a receiving side, the OpenLRTM method defines rules for generating map-independent location references, that is, the actual location references are generated dynamically not requiring use of pre-defined location references.

22.10.5.19 ISO TS 21219-23:2016 Intelligent transport systems - Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) -- Part 23: Roads and multimodal routes (TPEG2-RMR)

LINK: ISO TS 21219-23:2016

ISO TS 21219-23:2016 describes new mobility services like car sharing, car rental or park and ride as well as the integration of different transport modes by multimodal or off-board navigation are gaining increasing importance.

Furthermore, the cooperative management of the transport infrastructure requires the provision of precise information and guidance on dedicated routes from a central knowledge base to a traveller's mobile device.

Such use cases are addressed by the TPEG application defined in this document. The Road and Multimodal Routes (RMR) application enables the service provision for road routes as well as multimodal routes including more than one transport mode and parking. For example, an optimal multimodal route may include a drive by car to a train station with parking facility, a train connection to a station nearby the destination and a local public transport ride from the train station to the traveller's destination.

The standardized delivery, via TPEG technology, of routing information has some potential benefits for the users of an RMR TPEG service, for instance:

- Enabling of specialized routing services like scenic routing or Eco routing;

- The best use of the overall transport network, i.e. not only the road network;

- Cost and time savings to traveller;

- Harmonization of in-car navigation and traffic management, e.g. routing advices by variable message signs;

- Personalized service provisioning, i.e. information services considering the specific characteristics of a user.

Some of the use cases above, in particular personalized service, may require a Peer-to-Peer (P2P) communication while others may apply a broadcast communication approach, e.g. city routing.

22.10.5.20 ISO TS 21219-24:2017 Intelligent transport systems -- Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) -- Part 24: Light encryption (TPEG2-LTE)

LINK: ISO TS 21219-24:2017

ISO TS 21219-24:2017 defines the LTE encryption mechanism for TPEG Service Data Frames. It has been specifically designed for use with Business to Business (B2B) business models.

The objective of this document is to provide a simple to use, yet effective Conditional Access mechanism for TPEG including encryption for use with both broadcast and/or point-to-point delivery.

For both service providers and device manufacturers, a standardized conditional access mechanism is beneficial to avoid a proliferation of proprietary methods with multiplied implementation effort and lead times.

22.10.5.21 ISO TS 21219-25:2017 Intelligent transport systems -- Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) -- Part 25: Electromobility charging infrastructure (TPEG2-EMI)

LINK: ISO TS 21219-25:2017

ISO TS 21219-25:2017 defines the TPEG application electromobility charging infrastructure (EMI). It 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 a longer period of time, information on availability/waiting time and reservation options are highly relevant for a user of an electric vehicle to optimally plan his route/trip and are therefore also accounted for.

The standardized delivery, through a TPEG technology, of information on charging infrastructures has the following benefits to an end user of this TPEG service:

a) Identifying suitable charging units for his vehicle, thus preventing unnecessary driving around to find a fitting unit (also has environmental benefits).

b) Verifying the real-time availability of charging units.

c) Being able to plan ahead and reserve a spot in a charging park and thus optimize the planning of his trip.

d) Being able to select a financially attractive charging point in a charging park the operator of which has billing agreements with the user's electromobility provider.

In addition to these end-user benefits, also electromobility providers and charging park operators benefit from a standardized TPEG format as it allows an easier harmonization of the electromobility charging infrastructure information with the data formats used for the exchange of information between management systems of electromobility providers and charge park operators and according specifications (e.g. Open Charge Alliance[1], eMobility ICT Interoperability Innovation (eMI3)[2], etc.).

The TPEG application electromobility charging infrastructure, as add-on service component next to, for example traffic information, is laid out to support large numbers of charge parks with only modest bandwidth requirements.

[1] http://www.openchargealliance.org/

[2] http://emi3group.com/

22.10.5.22 ISO TS 21219-26:2018 Intelligent transport systems -- Traffic and travel information via transport protocol experts group, generation 2 (TPEG2) -- Part 26: Vigilance location information (TPEG2-VLI)

LINK: ISO TS 21219-26:2018

This document defines the application for Vigilance Location Information (VLI).

Vigilance messages are intended for in-car applications to inform drivers when they should pay extra attention to their driving behaviour because of dangerous road stretches, traffic enforcement cameras or other hazardous locations, requiring increased driver vigilance. The warnings can be presented visually, audibly, or with the spoken voice, or as a combination of all three.

The presentation of such messages to the drivers allows them to drive relaxed, in the knowledge that they will be warned when necessary. The situation where a vigilance message makes sense can be very different. For example speed cameras are usually placed in areas where vigilance is required; the information about those locations promote safe driving and also more safety for other road users and outside traffic participants. Another example for areas requiring high driver attention are roads close-by a school.

The information can be categorized in two ways:

fixed or mobile locations:
- Fixed locations refer to locations which are fixed of nature, such as the presence of known accident black-spots.
- Mobile locations refer to locations which are transient in nature, such as the presence of a mobile speed camera.
Spot locations or zones:

Spot locations refer to single points on a road network where the warning is located, with an indication of which direction of traffic is affected by the vigilance information.
Zones refer to stretches of road network which represent a continuous area of warning affecting only one traffic direction.

The local regulations regarding the signalling of speed measurement systems, e.g. fixed speed cameras, or mobile speed radar locations can vary depending on the country or region.

The signalling of speed measurement systems is encouraged by local authorities in certain markets whereas it can be punishable by law in other markets.

22.10.6 Location referencing

22.10.6.1 ISO 17572-1:2015 Intelligent transport systems (ITS) — Location referencing for geographic databases — Part 1: General requirements and conceptual model

LINK: ISO 17572-1:2015

The ISO 17572 series specifies location referencing methods (LRMs) that describe locations in the context of geographic databases and will be used to locate transport-related phenomena in an encoder system as well as in the decoder side. The ISO 17572 series defines what is meant by such objects and describes the reference in detail, including whether or not components of the reference are mandatory or optional, and their characteristics.

The ISO 17572 series specifies two different LRMs: pre-coded location references (pre-coded profile) and dynamic location references (dynamic profile).

The ISO 17572 series does not define a physical format for implementing the LRM. However, the requirements for physical formats are defined.

The ISO 17572 series does not define details of the Location Referencing System (LRS), i.e. how the LRMs are to be implemented in software, hardware, or processes.

ISO 17572-1:2015 specifies the following general LRM-related sections:

-requirements of a location referencing method;

-conceptual data model for location referencing methods;

-inventory location referencing methods;

-examples of conceptual model use;

-description of selected UML elements;

-comparison of definitions with ISO/TC 211;

-introduction to the TPEG physical format.

22.10.6.2 ISO 17572-2:2018 Intelligent transport systems (ITS) — Location referencing for geographic databases — Part 2: Pre-coded location references (pre-coded profile)

LINK: ISO 17572-2:2018

The ISO 17572 series specifies LRMs that describe locations in the context of geographic databases and are used to locate transport-related phenomena in an encoder system as well as in the decoder side.

The ISO 17572 series defines what is meant by such objects and describes the reference in detail, including whether or not components of the reference are mandatory or optional, and their characteristics.

The ISO 17572 series specifies two different LRMs:

— pre-coded location references (pre-coded profile);

— dynamic location references (dynamic profile).

The ISO 17572 series does not define a physical format for implementing the LRM. However, the requirements for physical formats are defined.

This document specifies the pre-coded LRM, comprising:

— specification of pre-coded location references (pre-coded profile);

— logical format for VICS link location (Annex A);

— TPEG physical format for ALERT-C (TMC) location references (Annex B, C & D);

— TPEG physical format for ETLs (Annex E, F & G);

— TPEG physical format for Korean node-link ID references (Annex H, I & J).

— logical format for Road Section Identification Data set (Annex K).

22.10.6.3 ISO 17571-3:2015 Intelligent transport systems (ITS) — Location referencing for geographic databases — Part 3: Dynamic location references (dynamic profile)

LINK: ISO 17571-3:2015

The ISO 17572 series specifies two different LRMs:

-pre-coded location references (pre-coded profile);

-dynamic location references (dynamic profile).

The ISO 17572 series does not define a physical format for implementing the LRM. However, the requirements for physical formats are defined.

ISO 17572-3:2015 does not define details of the location referencing system (LRS), i.e. how the LRMs are to be implemented in software, hardware, or processes.

ISO 17572-3:2015 specifies the dynamic location referencing method, comprising;

-attributes and encoding rules;

-logical data modelling;

-TPEG physical format specification for dynamic location references;

-coding guidelines for dynamic location references;

-compressed data format specification

22.10.6.4 ISO 17572-4:2020 Intelligent transport systems (ITS) — Location referencing for geographic databases — Part 4: Precise relative location references (precise relative profile)

LINK: ISO 17572-4:2020

This document describes and lists the characteristics of the Precise Relative Location Referencing Method (PRLRM) which describes precise relative locations in the context of geographic databases and is used to locate transport-related objects in an encoder system as well as in the decoder side.

This document does not define a physical format for implementing the PRLRM. However, the requirements for physical formats are defined. This document does not define details of the Precise Relative Location Referencing System (PRLRS), i.e. how the PRLRM is to be implemented in software, hardware or processes.

This document specifies PRLRM, comprising:

— conceptual data model for Location Referencing Methods (LFMs);

— specification of location referencing for precise relative information;

— use cases for Precise Relative Location References (informative Annex C);

— use cases for elements of Precise Relative Location References (informative Annex D);

— implementation of Precise Relative Location References (Japanese example) (informative Annex E).

This document defines methods that enable exchange location information of the object to be referenced in the lane or the lane junction. This document does not specify the road (link) on which the object of reference exists.

22.10.6.5 CEN TR 17297:1:2019 Intelligent transport systems - Location referencing harmonization for Urban ITS - Part 1: State of the art and guidelines

LINK: CEN TR 17297:1:2019

This document presents: - a concise tutorial on location referencing methods; - applicable location referencing specifications, standards and directives; - an introduction into challenges given by a multiplicity of different location referencing systems.

22.10.6.6 CEN TS 17297-2:2019 Intelligent transport systems - Location Referencing Harmonisation for Urban-ITS - Part 2: Transformation methods

LINK: CEN TS 17297-2:2019

This document specifies requirements, recommendations, and permissions related to translations between location referencing methods applicable in the urban transport environment.

22.10.7 Graphic Data Dictionary

22.10.7.1 ISO EN 14823:2018 Intelligent transport systems – Graphic data dictionary

LINK: ISO EN 14823:2018

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

22.10.7.2 ISO TR 14823-2:2019 Intelligent transport systems – Graphic data dictionary – Part 2 Examples

LINK: ISO TR 14823-2:2019

This document reports examples of ASN.1 codes based on ISO 14823-1[1], which specifies a graphic data dictionary (GDD) including the ASN.1 coding rule for GDD.

NOTE: Some of the ASN.1 codes described in this document are re-formatted based on ISO 14813-6.

22.11 Bibliography

Collection and Delivery of Traffic and Travel Information, Paul Burton and Alan Stevens, The Institute of Engineering and Technology, ISBN 978-1-772-0.

TTI 22.11 Biblio

22.10.7 Graphic data D

22.10.6 location Ref

22.10.5 TPEG

RDS-TMS Alert C

22.10.1 DATEX II

Graphic Data Dictionary

ITS Communications & Information Protocols

Traffic and Traveller Information

22 Traffic and Traveller Information (TTI)

22.1 Overview

22.1.1 Scope

22.1.2 History and requirement for TTI

22.1.3 European cooperation

22.2 Architecture

22.3 Actors

22.3.1 Data collectors and providers

22.3.2 Data collators

22.3.3 Service providers

22.3.4 Mapmakers

22.3.5 Broadcasters

22.3.6 Equipment suppliers

​

22.4 Location Referencing

22.5 DATEX II

22.6 Traffic and Traveller Information Services

22.6.1 Radio Data Systems – Traffic Message Channel (RDS-TMC)

22.6.1.1 The RDS-TMC ALERT C protocol

22.6.1.2 The RDS-TMC Message Set

22.6.1.3 RDS-TMC Location Referencing

22.6.2 TPEG (Traffic Protocol Experts Group)

22.6.2.1 Background

22.6.3 TPEG Binary

22.6.3.1 TPEG-ML

22.6.3.2 TPEG Location Referencing

22.6.4 TPEG 2

22.7 The TPEG2 Standards

22.8 Other message sets

22.9 Regulations

22.9.1 Deployment of RDS-TMC

22.9.2 National access points

22.10 Standards

​

22.10.1 Radio Data Systems (RDS) standards

22.10.1.1 EN 50067:1998 Specification of the Radio Data System (RDS) for VHS/FM sound broadcasting in the frequency range from 87,5 To 108,0 MHz

22.10.2 DATEX II

22.10.2.1 EN 16157-1:2018 Intelligent transport systems - DATEX II data exchange specifications for traffic management and information - Part 1: Context and framework

22.10.2.2 EN 16157-2:2019 Intelligent transport systems - DATEX II data exchange specifications for traffic management and information - Part 2: Location referencing

22.10.2.3 EN 16157-3:2018 Intelligent transport systems - DATEX II data exchange specifications for traffic management and information - Part 3: Situation Publication

22.10.2.4 EN 16157-4:2021 Intelligent transport systems - DATEX II data exchange specifications for traffic management and information - Part 4: Variable Message Sign (VMS) Publications

22.10.2.5 EN 16157-5:2020 Intelligent transport systems - DATEX II data exchange specifications for traffic management and information - Part 5: Measured and elaborated data publication

22.10.2.6 CEN TS 16157-6:2021 Intelligent transport systems - DATEX II data exchange specifications for traffic management and information - Part 6: Parking Publications

22.10.2.7 EN 16157-7:2018 Intelligent transport systems - DATEX II data exchange specifications for traffic management and information - Part 7: Common data elements

22.10.3 RDS-TMC – Alert C

22.10.3.1 EN ISO 14819-1:2021 Intelligent transport systems -- Traffic and travel information messages via traffic message coding -- Part 1: Coding protocol for Radio Data System -- Traffic Message Channel (RDS-TMC) using ALERT-C

22.10.3.2 EN ISO 14819-2:2021 Intelligent transport systems -- Traffic and travel information messages via traffic message coding -- Part 2: Event and information codes for Radio Data System - Traffic Message Channel (RDS-TMC) using ALERT-C

22.10.3.3 EN ISO 14819-3:2021 Intelligent transport systems -- Traffic and travel information messages via traffic message coding -- Part 3: Location referencing for Radio Data System - Traffic Message Channel (RDS-TMC) using ALERT-C

22.10.3.4 EN ISO 14819-6:2014 Traffic and Traveller Information (TTI) -- TTI messages via traffic message coding -- Part 6: Encryption and conditional access for the Radio Data System - Traffic Message Channel ALERT C coding

22.10.4 Unused and legacy TPEG Standards

22.10.5 Current TPEG Standards (ISO only)

​

22.10.5.1 ISO TS 21219-1:2016 Intelligent transport systems -- Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) -- Part 1: Introduction, numbering and versions (TPEG2-INV)

22.10.5.2 ISO 21219-2:2019 Intelligent transport systems -- Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) -- Part 2: UML modelling rules (TPEG2-UMR)

22.10.5.3 ISO 21219-3:2019 Intelligent transport systems -- Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) -- Part 3: UML to binary conversion rules (TPEG2-UBCR)

22.10.5.4 ISO 21219-4:2019 Intelligent transport systems -- Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) -- Part 4: UML to XML conversion rules

​

22.10.5.5 ISO 21219-5:2019 Intelligent transport systems -- Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) -- Part 5: Service framework (TPEG2-SFW)

22.10.5.6 ISO 21219-6:2019 Intelligent transport systems -- Traffic and travel information(TTI) via transport protocol experts group, generation 2 (TPEG2) -- Part 6: Message management container (TPEG2-MMC)

22.10.5.7 ISO TS 21219-7:2017 Intelligent transport systems -- Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) -- Part 7: Location referencing container (TPEG2-LRC)

22.10.5.8 ISO TS 21219-9:2016 Intelligent transport systems -- Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) -- Part 9: Service and network information (TPEG2-SNI)

22.10.5.9 ISO TS 21219-10:2016 Intelligent transport systems -- Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) -- Part 10: Conditional access information (TPEG2-CAI)

22.10.5.10 ISO DIS 21219-13 Intelligent transport systems -- Traffic and travel information via transport protocol experts group, generation 2 (TPEG2) -- Part 13: Public transport information (TPEG2-PTS)

22.10.5.11 ISO TS 21219-14:2016 Intelligent transport systems -- Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) -- Part 14: Parking information application (TPEG2-PKI)

22.10.5.12 ISO TS 21219-15:2016 Intelligent transport systems -- Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) -- Part 15: Traffic event compact (TPEG2-TEC)

22.10.5.13 ISO TS 21219-16:2016 Intelligent transport systems -- Traffic and travel information via transport protocol exports group, generation 2 (TPEG2) -- Part 16: Fuel price information and availability (TPEG2-FPI)

22.10.5.14 ISO CD 21219-17 Intelligent transport systems -- Traffic and travel information via transport protocol experts group, generation 2 (TPEG2) -- Part 17: Speed information (TPEG2-SPI)

22.10.5.15 ISO 21219-18:2019 Intelligent transport systems -- Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) -- Part 18: Traffic flow and prediction application (TPEG2-TFP)

22.10.5.16 ISO TS 21219-19:2016 Intelligent transport systems -- Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) -- Part 19: Weather information (TPEG2-WEA)

22.10.5.17 ISO TS 21219-21:2018 Intelligent transport systems -- Traffic and travel information via transport protocol experts group, generation 2 (TPEG2) -- Part 21: Geographic location referencing (TPEG-GLR)

22.10.5.18 ISO TS 21219-22:2017 Intelligent transport systems -- Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) -- Part 22: OpenLR location referencing (TPEG2-OLR)

22.10.5.19 ISO TS 21219-23:2016 Intelligent transport systems - Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) -- Part 23: Roads and multimodal routes (TPEG2-RMR)

22.10.5.20 ISO TS 21219-24:2017 Intelligent transport systems -- Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) -- Part 24: Light encryption (TPEG2-LTE)

22.10.5.21 ISO TS 21219-25:2017 Intelligent transport systems -- Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) -- Part 25: Electromobility charging infrastructure (TPEG2-EMI)

22.10.5.22 ISO TS 21219-26:2018 Intelligent transport systems -- Traffic and travel information via transport protocol experts group, generation 2 (TPEG2) -- Part 26: Vigilance location information (TPEG2-VLI)

22.10.6 Location referencing

​

22.10.6.1 ISO 17572-1:2015 Intelligent transport systems (ITS) — Location referencing for geographic databases — Part 1: General requirements and conceptual model