Exchange Basics


A common set of data exchange specifications are defined 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 model 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 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 select a suitable implementation platform and clearly specify how the abstract scenarios and patterns are effectively implemented on this platform. The diagram in Figure 1 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

Figure 1 - 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.

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.

As well, the ITS station architecture is not in contradiction with this document but is complementary of what is defined in this document. According to the principles and the taxonomy defined in ISO 21217, this document defines a conceptual notion of:

  • How 2 central ITS (sub) stations could communicate to:
    • deliver (application data units) information,

    • negotiate functional service behaviour for collaborating traffic management functions (even if this use case could not directly be matched to ISO 21217 as it is not about information delivery).

  • How a central ITS (sub) station could communicate to deliver information (application data units) to another ITS station with the characteristics of a central ITS station.

This document specifies the process of defining the exchange characteristics by use case-driven feature selection of relevant parameters for the relevant OSI layers as defined in ISO 21217. Two exchange schemas are considered: Information delivery and Functional service negotiation between central ITS stations.

  • 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.

Terms and definitions




business scenario

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

See also Use Case.


entity that receives the information

It is represented in the Information Delivery business scenario

Collaborative ITS Services

collaborative ITS services are ITS Services which can be enabled by combing different “ITS Services” which are provided by combined effort of two or up to several stakeholders which may have different roles.

It is represented in the Information Delivery business scenario

Exchange Pattern (EP)

the basic exchange architecture template, described by UML communication diagrams, which identifies the actors in the exchange framework and the available interactions among them, which enable data exchange functionalities as a set of exchange features

Functional Exchange Profile (FEP)

selection of data exchange features for a particular Business Scenario

HTTP Server

software application that provides content to client applications by using the HTTP protocol

interoperability domain

pair of FEP and platform selected for implementing a data exchange subsystem

Each PSM document defines an Interoperability Domain, which ensures that two implementations of this PSM are interoperable and can successfully exchange payload.

payload content model / content model

UML definition of the data structures that can be used to describe travel and traffic information to be exchanged in an exchange system

payload publication / payload

bundle of information that is exchanged between two exchange systems containing an instance of the content model

Platform Independent Model (PIM)

document describing the abstract model of the standardised data exchange process in a platform independent way

This definition is specific to this part.

Platform Specific Model (PSM)

document providing the implementation details of a FEP described in the PIM for a concrete platform

This definition is specific to this part.

profile-to-platform mapping

act of defining an Interoperability Domain

pub / sub

Publish-Subscribe pattern

pull exchange

situation where the exchange of information is originated by the client

push exchange

situation where the exchange of information is originated by the supplier

simple push

push-based exchange pattern where that does not require state to be maintained


set of data providing all of the last known state as opposed to providing partial changes

This definition is specific to this part.

snapshot pull

pull-based exchange pattern where only the last snapshot version is exchanged

This definition is specific to this part.

snapshot push

push-based exchange pattern where only the last snapshot version is exchanged

This definition is specific to this part.

stateful push

push-based exchange pattern where data describing a communication session is maintained across successive communication within that session

This definition is specific to this part.


entity that provides the information

It is represented in the information delivery business scenario.

Use Case (UC)

set of operational interactions between entities (called actors) and a system to ease understanding the main functions behind such interactions

Symbols and abbreviated terms


Abstract Syntax Notation One


Business use case


Hyper-Text Transfer Protocol


Information and Communication Technology


Internet Protocol


Intelligent Transport Systems


Model Driven Architecture


Representational State Transfer


Remote Procedure Call


Simple Object Access Protocol


Traffic Control Center


Traffic Management Center


Traffic Information Center


Transmission Control Protocol


Traffic Management Plan


Universal Description Discovery and Integration


User Datagram Protocol


Universal Modelling Language

Note: Specified in ISO/IEC 19505 series (2012)


World wide web consortium


Web Service Definition Language


Web Services Inspection Language


Web Services Security


eXtensible Markup Language

Exchange Modelling Framework


The model driven approach is chosen to describe exchange: this leads to describe exchange systems by means of abstract models which are named platform independent model (PIM), in which modelling of exchange features is done by describing interaction among systems and subsystems as exchange patterns (EP). These interactions implement system capabilities as features which fulfil exchange requirements requested by specific business scenarios which are used to describe specific uses of exchange.

Business scenarios and functional exchange profile

This document is based on business scenarios, i.e. a 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. Business scenarios are derived from application requirements on useful business information needed and on technical capabilities enabled by available technologies. FEPs are identified to ensure interoperable services with the restriction of determining one FEP per business scenario for a specific exchange pattern, which are abstract model of available technical platforms.

One business scenario can be supported by more then one FEP which can be enabled by several EP (Figure 2).


Figure 2 — Business scenario and Functional exchange profile

This version of the Technical Specification addresses the following business scenario:

  • Information delivery

  • Collaborative ITS services.

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

Requirements, Feature and Exchange Patterns

Requirements can vary depending on data exchange applications, i.e. use cases to be fulfilled, so there are many reasons to consider or not any requirement based both on the gathering of data at supplier system and the usage of the delivered data in the client.

Requirements address the following items:

  • Information provision,

  • Communications,

  • Security,

  • Financial aspects.

Exchange is defined through enabling features which fulfils data exchange requirements.

Many possible technical exchange platform are possible, each of which can enable subset of requirements in different ways. To be interoperable a client and a supplier shall implement the same platform with the same pattern. Allowing a wide variety of possible exchange patterns, the best suitable for an use case application is chosen, in order to fulfils the needed set of requirements.

Based on the requirements of a specific business scenario selected for application use cases implementation, a set of appropriate exchange features shall be combined into a FEP.

The following schema in Figure 3 represent the domains of PIM and PSM introducing exchange pattern (EP) and FEP.


Figure 3 — Business scenario and Functional exchange profile