Introduction¶

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.

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

Symbols and abbreviated terms

Exchange Modelling Framework¶