This Technical Specification defines a common set of data exchange specifications to support the vision of a seamless interoperable exchange of traffic and travel information across boundaries, including national, urban, interurban, road administrations, infrastructure providers and service providers. Standardisation in this context is a vital constituent to ensure interoperability, reduction of risk, reduction of the cost base, promotion of open marketplaces and many social, economic and community benefits to be gained from more informed travellers, network managers and transport operators.

Especially in Europe, delivering Transport Policy in line with the White Paper issued by the European Commission requires co-ordination of traffic management and development of seamless pan European services. With the aim to support sustainable mobility in Europe, the European Commission has been supporting the development of information exchange mainly between the actors of the road traffic management domain for a number of years.

This Technical Specification supports a methodology that is extensible.

To be able to successfully connect systems and start exchanging data, in an interoperable and easy way, there is a need to describe and agree on how the exchange should be done. This is set out in a data exchange specification. Data exchange in different scenarios can have different needs and requirements. Therefore, several data exchange specifications can be needed.

Data exchange specifications need to address two main issues. First, they must model the stakeholders and actors involved in data exchange – each potentially in different roles – as well as abstract exchange patterns for their interactions. Second, they must select a suitable implementation platform and clearly specify how the abstract scenarios and patterns are effectively implemented on this platform.

The following diagram shows such an abstract communication scenario from the perspective of a road operator who requires data exchange interfaces between the different components of its own operational systems – either between centre side components or between centre and field devices – but also to exchange information with other road operators or service providers.


Abstract communication scenario

While the black links between centre side components and field devices may use a variety of communication protocols – mostly depending on the physical link conditions – the vast majority of other coloured links between centre - side components – internal to one organisation or external to others – is based on an IP network and mostly use the TCP transport layer protocol (UDP is also possible in a few cases).

Nevertheless – as the different colours indicate – they can very well have significantly different requirements. Internal links (blue) can reside in one domain of trust, hence do not require protocols compatible with security gateways. This can already be different for links to other road operators (red) and will certainly not hold for links to other types of organisations – like service providers – via the Internet (green).

While different security requirements offer the most striking and obvious example, there are more criteria that can lead to different preferences on different types of links, e.g. scalability, robustness, integration complexity, etc.

In broad terms, the colours blue – red – green form a hierarchy from more internal, closely-coupled, well-integrated systems towards external, loosely-coupled and non-integrated systems. The world of information and communication technology (ICT) offers a broad range of solutions for these different scenarios, offering different advantages and disadvantages. It is obvious that the one-size-fits-all principle will not provide the most efficient way of working here. Even on the highest level of abstraction and inside the ICT domain itself, we already find a well-known battle of paradigms between remote-procedure-call (RPC) type service specifications and RESTful architectures. The same clusters of options are found in the domain of ITS standards, where for example the European standard for the real-time information interface relating to public transport operations (SIRI – EN 15531 series [6]) introduces both concepts as complementary options: Publish-Subscribe and Request-Response.

The drafting of this Technical Specification was guided by the following principles:

  • Interoperability, such that different implementations can successfully engage in a data exchange process;
  • Support legacy implementations which are based on existing (exchange) specification, in order to maximize investments already made by stakeholders;
  • Address other user profiles, not only road operators, and thus make this Technical Specification available to a broader audience;
  • Reuse of existing (communications) standards, in order to reduce implementation complexity and take benefit of proven and already existent solutions for common ICT problems;
  • Clear separation between the payload content and the exchange model.

The informative Annex A details more the adopted methodology for defining this Exchange Platform Independent Model.


Add link to Annex Abstract


The scope of this Technical specification is to define and specify 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 data content, structure and relationships necessary and the communications specification, in such a way they are independent from any defined technical platform.

This Technical Specification establishes specifications for data exchange between any two instances of the following actors:

  • Traffic Information Centres (TIC),
  • Traffic Control Centres/Traffic Management Centres (TCC/TMC),
  • Service Providers (SP).

Use of this Technical Specification may be applicable for use by other actors like e.g. car park operators....

This Technical Specification includes the following types of information:

  • The use cases and associated requirements, and features relative to different exchange situations,
  • The different functional exchange profiles,
  • The abstract elements for protocols,
  • The data model for exchange (informational structures, relationships, roles, attributes and associated data types required).

In order to set up a new technical exchange framework, it is necessary to associate one functional exchange profile with a technical platform providing an interoperability domain where plug-and-play interoperability at technical level can be expected. The definition of such interoperability domains is not part of this Technical Specification but can be found in other standards or technical specifications like in ISO 14827-3. This Technical Specification is restricted to data exchange, definition of payload content models being beyond its scope.




This part of the content still has to be delivered

Exchange Modelling Framework

Introduction of the framework

Model driven approach is chosen to describe Exchange: this lead to describe exchange systems by means of abstract model which are named Platform Independent Model (PIM), modelling of exchange features is done by describing interaction among systems and subsystems which are described as Exchange Patterns, those interactions implements system capabilities as features which fulfils exchange requirements requested by specific Business Scenarios which are used to specify specific use of Exchange.

Since simple data exchange process is no longer sufficient for resolving all business needs, this Technical Specification encompasses more business functions as the stakeholders consolidate their systems and look at new ways to address the requests they encounter with the tools they already know and have in place.

Business scenarios and functional exchange profile

This Technical Specification is based on business scenarios, i.e. high-level description of the interactions that can exist within a system being analysed or between the system and external entities (called actors) in terms of business functions. Derived from requirements a business scenario has on information as well as technical parameters, Functional Exchange Profiles (FEPs) are identified to ensure interoperable services with the restriction of determining one FEP per business scenario for a specific technical platform. One FEP can support more than one business scenario.


This version of the Technical Specification addresses the information delivery business scenario.

Other business scenarios can be developed in future versions using the same methodology.

Requirements, Feature and Exchange Patterns

Requirements may vary depending on data exchange application i.e. Use Cases to be fulfilled, so there could be many reasons to consider or not any requirement based both on the gathering of data at Supplier System and the usage of Delivered data in the Client.

Requirements address the following items:

  • Information provision,
  • Communications,
  • Security,
  • Financial aspects.

Exchange is defined through Features which implement the Information Exchange and fulfils Data Exchange requirements.

Depending on many possible Exchange Platform considered for implementation, a subset of features and relative requirements is possible to be implemented. To fulfil a set of requirements many Platform are possible, but to be interoperable client and supplier shall implement the same platform with the same pattern. Allowing a wide variety of possible Exchange Pattern, the best suitable for an application may be chosen, according to requirements which fulfilment is granted by the selected Exchange Pattern

Based on the requirements of a specific Business Scenario, a set of appropriate exchange features has to be combined into a Functional Exchange Profile (FEP).

The following schema represent the domains of PIM and PSM introducing Exchange Pattern EP and Functional Exchange Profile FEP.


Business scenario: Information delivery


One of the most common applications of a data exchange system is the exchange of traffic and travel information between two nodes. In such a scenario, one node acts as the supplier of the information while the other acts as the intended receiver of that information, i.e. the client.


It is done by using the form of the European DATEX II publications.

The Data Delivery Business Scenario consider the actors as defined in the following figure:


Assuming the definitions in following Table:

Name Definition
Supplier System A system which gathers information (Road Information) which has to be conveyed to another system named Client System. Examples of Supplier Systems may be Traffic Control Centres or Traffic Information Centres o Service Providers Systems, gathering road data by any available source they have.
Client System A system which needs to update its internal information based on information which is available at another Systems named Supplier. Example of Client Systems are Traffic Control Centres or Traffic Information Centres or Service Providers Systems
Exchange Environment The set of components which enable information Exchange among Client System and Supplier Systems via DATEX protocol
Supplier The component of Exchange Environment which is devoted to provide Data to Client, retrieving them from Supplier System
Client The component of Exchange Environment which is devoted to collect Data from Supplier, delivering them to the Client System

Road and Traffic Information is gathered at a System which is named “Supplier System” in case the information it stores is needed to be transferred to another system, named Client System, for any purpose.

The Data Delivery Business Scenario describes the Exchange pattern and Messages which are needed to be exchange among Supplier and Client Systems besides the underneath technology and exchange pattern. The purpose for which information is exchanged is not considered in this use case description.

As explained in the Information Delivery Background in Annex F any updates of Information status at the Supplier system has to be replicated to the Client System via Information Delivery. The main scope of Information delivery is that Information on Client System is updated exactly in the same way as it is in the Supplier system without any difference on information values and semantics.


Link to annex F

We can define “Exchange Message” the data structure in which the information is coded to transfer Information in the Exchange System from the Supplier to the Client.

Assuming Sc = Client Status, Ss = Supplier Status, Exchange is a mean to have Sc equivalent to Ss,


Ss => Information => Supplier => Exchange Message => Client => Information => Sc

i.e. Client System Status is updated in equivalent mode as Supplier System Status by means of Data Delivery Exchange Messages through Supplier and Client.

Information Delivery Business Scenario scope is implemented by selected Exchange Features which enables this scope and other secondary requirements which are possible based on available Features on considered Platforms and Patterns.

  1. Supplier System Characterization
  • Shall provide data as input to the data exchange Environment
  • Is mandatory for the information data delivery process
  1. Data Exchange Environment
  • Shall be an environment supporting the exchange of information and data by mean of Messages
  • The Supplier of data exchange System shall produce and transmit the messages (D2Notification)
  • The Client of data exchange System should receive and process the messages
  1. Client System Characterization
  • Could receive traffic and travel related data from the data exchange Environment
  • could be either another system for further processing or a simple Client for the content visualization, the purpose of information exchange is not considered to be relevant in Information Delivery Business Scenario
  • Is mandatory for the information data delivery process

User support

Reference profiles


DATEX II Archive

Other links