Exchange Basics

Exchange Basics

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.

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

Term Definition Notes
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.
client 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  
snapshot 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.
Supplier 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

ASN.1 Abstract Syntax Notation One
BUC Business use case
HTTP Hyper-Text Transfer Protocol
ICT Information and Communication Technology
IP Internet Protocol
ITS Intelligent Transport Systems
MDA Model Driven Architecture
REST Representational State Transfer
RPC Remote Procedure Call
SOAP Simple Object Access Protocol
TCC Traffic Control Center
TMC Traffic Management Center
TIC Traffic Information Center
TCP Transmission Control Protocol
TMP Traffic Management Plan
UDDI Universal Description Discovery and Integration
UDP User Datagram Protocol
UML Universal Modelling Language
  Note: Specified in ISO/IEC 19505 series (2012)
W3C World wide web consortium
WSDL Web Service Definition Language
WSIL Web Services Inspection Language
WSS Web Services Security
XML eXtensible Markup Language

Exchange Modelling Framework

Introduction

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

image2

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.

image3

Figure 3 — Business scenario and Functional exchange profile

Business scenario: Information delivery

Overview

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.

EXAMPLE: It is done by using the form of publications, e.g. in the European DATEX II.

The data delivery business scenario considers the actors as defined in Figure 4:

image4

Figure 4 — General Data Delivery Business Scenario actors

The following Table provides the basic definitions for exchange:

Name Definition
Supplier System A system which gathers information (road information) which needs to be conveyed to another system named client system. Examples of supplier systems are traffic control centres or traffic information centres or service provider systems, gathering road data from any available source they have.
Client System A system which needs to update its internal information based on information which is available from another system named supplier. Examples of client systems are traffic control centres or traffic information centres or service provider systems.
Exchange Environment The set of components which enables information exchange among client systems and supplier systems via a data exchange protocol.
Supplier The component of exchange environment which is devoted to providing data to client, retrieving them from supplier system.
Client The component of exchange environment which is devoted to collecting data from supplier, delivering them to the client system.

Road and traffic information is gathered in a system which is named “Supplier System”. In case this information is needed by another system, named “Client System”, for any purpose, it has to be transferred among the two systems by the exchange environment.

The data delivery business scenario describes the exchange pattern and messages which are needed to be exchanged 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 update of information status at the supplier system shall be replicated to the client system via information delivery. The main objective of information delivery is that information on the client system is updated exactly in the same way as it is in the supplier system without any difference in information values and semantics.

“Exchange message” is defined as 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,

Formally:

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 enable this scope and other secondary requirements which are based on available features on considered platforms and patterns.

  1. Supplier system characterisation
    • Shall provide data as input to the data exchange environment
    • Is mandatory for the information data delivery process
  2. Data exchange environment
    • Shall be an environment supporting the exchange of information and data by means of messages
    • The supplier, of data exchange system, shall produce and transmit the messages (Notification)
    • The client, of data exchange system, should receive and process the messages
  3. Client system characterisation
    • Shall receive traffic and travel related data from the data exchange environment
    • Can 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

Requirements

The normative Annex B provides a description of all requirements that can exist for specific Business Scenario including Information Delivery whether they are used in a particular functional exchangeprofile or not. All requirements are organised into groups based ontheir characteristics.

Note

A FEP is a different concept from content profile. The description of the content profiles that can exist in an information delivery scenario is not in the scope of this document. Content profiles are handled in respect to which information is exchanged.

Data Delivery Exchange Pattern

For data delivery the concept of ”EP” is introduced, as well as PIM and FEP. These are defined as in Terms and definitions in the introduction.

Examples of exchange pattern are the GET method of HTTP, Pull, Push, PubSub, etc.

Once an exchange pattern and a selection of features (FEP) which can be implemented on this exchange pattern are set, a set of specification at PIM level for EP+FEP is well defined.

A PIM for EP+FEP that enables all mandatory requirements is a valid platform for the corresponding business case (information delivery or collaborative ITS services).

Specific Exchange Pattern Specification PIM included in this PIM part

In the following chapters PIM for Exchange Pattern/FEP will be described for the following platform:

  • Snapshot Pull
  • Snapshot Push
  • Simple Push
  • Stateful Push

The normative Annex E details the features of the main FEPs considered in this document for the corresponding exchange pattern.

Business scenario: Collaborative ITS Service

Overview

A service is any processing of data which enable a value to the data themselves.

In ITS fieald “ITS Services” can be considered as the processing of information to address specific requirement such as to manage traffic, deliver information.

“Collaborative ITS services” (CIS) are “ITS Services” which can be enabled by combing different “ITS Services” which are provided by several stakeholders which may have different roles (e.g. Traffic Management Centers, Traffic Information Centres, Service Providers).

CIS exchange specification explore user requirements and define common techniques to address them to implement collaborative “ITS services” by different centres. They are based on exchanging information to be processed by the different nodes and receiving the processing outcomes (feedback), giving a simple mechanism, upon which it could be possible to build more sophisticated workflows, enabling to coordinate operations distributed among many centres.

In CIS business scenario the exchange of information among centres is considered as a base mechanism to trigger specific processing and to provide services on this data, so the data exchange layer is to be considered as an “ITS services” enabler.

“ITS Services” description is out of the scope of this document: a detailed description of possible usage of CIS detailed in informative Annex G .

Example of “ITS Service” in the different “ITS domain” are:

  • TIS: Traffic Information Services
    • Information Delivery
    • Allowed Channels
  • TMS: Traffic Management Systems
    • Hard Shoulder Running
    • Dynamic Speed
    • Dynamic Lane Management
    • etc.
  • F&L: Freight&Logistic
    • Secure Truck Parking
    • etc.

Data exchange enabling service request and feedback paradigm

The involved systems, which in data delivery had been considered as supplier and client, can be considered in this paradigm respectively as service requester and service provider.

At application level, for implementing a business case, such as management of TMP, workflow management is usually requested; this could be a simple workflow (one shot request and acceptancs or rejection) or a more complex one: complex workflow modelling at application level is out of the scope of this document. This document provides the essential tools as building blocks to implement such simple workflow to a raise service request and provide feedback as exchange of payload to be processed and processing results.

CIS enabling mechanism:

  • Service request delivery from service requester to the involved service providers.
  • Service feedback delivery from service provider to the relative service requester.

CIS main characteristics are as follows:

  • collaborative: 2 to many systems interact to achieve a common objective by processing data and exchange processing results;
  • CIS modelling consider using a set of “1 to n” exchange connections considering any single CIS triggering request as 1 service requester and 1 to many service providers so that any complex interaction can be considered a combination of single usages from multiple requesters;
  • possible lock of resources at service provider sides which are to be managed at application or human operator level are not described in the document.

Requirements

The normative Annex B provides a description of all requirements that can exist for specific business scenario including Collaborative Information Services

Exchange Data Model

To implement some exchange features, such as session management or link monitoring, or security features, extra information is to be added to the informational (payload) content. This extra information, named exchange information, enables messages to convey information and data which are related to client and supplier status, identity, authorisation, etc.

Exchange information could be different among EP+FEP selection, but some common general information models are considered, which can be specialised to manage specific exchange pattern and PIM.

A general UML model for managing a minimum set of information for exchange is provided in Annex C

Data exchange features

Context Diagram

This document defines the features and rules that systems shall implement in order to be able to communicate in the traffic and travel data exchange world.

The context diagram below in Figure 5 shows the entities and the features specified in this document and which need to be addressed by the technical implementations. The diagram presents the features in different layers for communication, message rules and application:

  • The “Application layer” is used for defining how using and implementing different business and application needs. This document describes the features to deal with how and when the information is published and made available, how subscriptions are managed, how to handle services and transactions. This layer defines the semantics of the communication.
  • The “Messages Rules layer” defines the features and the rules used for the transport of the messages. This is the layer where the rules (protocol) are defined that enable different systems (suppliers and clients) to communicate and understand each other, i.e. for sending and receiving messages. This layer defines the syntax of the communication.
  • The “Communication layer” deals with the support for communication between systems, and defines the protocols and services used by the data exchange applications, e.g. TCP/IP, security, web services. The communication layer deals with rules at the lowest level, i.e. the physical exchange. This layer provides solutions to the defined requirements and features although it is up to upper applications to define what protocols to use and how to use them. This layer defines the physical support for the communication.

The context diagram below (Figure 5) shows the topics broken up into boxes representing the exchange features and the relation with each layer.

image5

Figure 5 - Context diagram

Features

The features that support the requirements defined by use cases specified in this document are detailed below:

  1. The “Subscription contract”, detailed in the table below, supports all features related to the contract or agreement, such as:

    1. Contract and contract life cycle: a model and features that can be used for the support of the information of a subscription contract
    2. Catalogue: a model for handling catalogues;

    The subscription contract is optional and may include the following features:

    Features Requirement Type Requirement Name
    Contract Information Subscription
        Client profiles
        Filter handling
    Catalogue Information Catalogue exchange
  2. The “Session” feature group, detailed in the table below, supports all features related to the establishment of a logical session.

    1. Session life cycle – features for managing the life cycle of a logical session (create, manage and terminate);
    2. Link Monitoring – features for link monitoring and control;

    The session feature group is optional and includes the following Features:

    Features Requirement Type Requirement Name
    Session life cycle Communication Error handling
        Timeout management
        Session
    Link Monitoring Communication Error handling
        Timeout management
        Full reliability
        Link monitoring and control
  3. The “Information management” handles the features related to the management of the information, includes features such as:

    1. “Operating modes”: features to specify what portion of the information shall be exchanged
    2. “Update methods”: features that let a data exchange system specify when the information should be exchanged
    3. “Lifecycle management”: features for handling the life cycle management of exchanged payload information for payload for which life cycle is applicable; a. Situation lifecycle management b. Filter handling
    4. “Support information processing”: feature for handling directives to process exchanged data and send feedback on processing outcomes.
    5. Distributed transaction: features for handling a transaction on several systems consistently, i.e. an operation is capable to keep data consistency among several systems based on operator undertaken actions. The information management group includes the following features:

    The “information management” group includes the features listed in the following table.

    Features Requirement Type Requirement Name
    Operating modes Information Reference datasets for different versions
    Update methods Information Full audit trail data delivery (all state changes)
    Lifecycle management Information Support for life cycle management
    Support Information Processing Information Support for information management
        Support for feedback on information management
    Distributed transaction Information Distributed transaction
        Distributed atomic transaction
  4. The “data delivery” feature group supports all features to exchange data between the supplier and client. In the publish-subscribe pattern this feature group will support all related interfaces between the producer and the consumer; it supports features such as:

    1. Data delivery: features to delivery information by the supplier to the client on a push mode (direct delivery and fetched delivery);
    2. Data request: features to exchange information requested by the client;
    3. Large datasets: support the exchange messages with large volumes;
    4. Synchronisation: how to ensure data synchronisation between the systems that are communicating.

    The “data delivery” group includes features and requirements listed in the next table.

    Features Requirement Type Requirement Name
    Data delivery Information Extensibility
      Communication Delivery/response
        Message sequence
        Snapshot data delivery (last known state)
        Exchange quality measures (ex. response timestamp)
        On occurrence update
        Periodic update
      Security Client identification
        Supplier identification
      Information Incremental data delivery
    Data request Information Extensibility
      Communication Request/response
        Message sequence
        Snapshot data delivery (last known state)
        Exchange quality measures (ex. response timestamp)
        On occurrence update
        Periodic update
      Security Client identification
        Supplier identification
    Large datasets handling Information Data delivered as soon as possible
        Delayed delivery
        Multi-part data delivery
    Synchronisation Information Synchronisation
      Communication With state supplier
        Failed data recovery
  5. Communication – Handles all features related to the protocol (close to the physical layer). It is used by the application for the message transport.

    1. Communication – describe the protocols of communication that can be used;
    2. Security – describe how security features can be implemented;
    3. Compression – how data compression can be used while transmitting data.
    4. Bidirectional communication – enable client to send back data to supplier as feedback on data exchanged and processing status of data based on supplier processing directive in Collaborative ITS Services The communication function is responsible for implementing the following Features:

    The communication function is responsible for implementing the following features:

    Features Requirement Type Requirement Name
    Security Security Security (data)
        Integrity
        Confidentiality
        State the intended recipient
        Client authentication
        Supplier authentication
        Client authorization
        Non-repudiation
    Compression Communication Compression
    Communication Communication Timely responses
    Bidirectional communication Communication Bidirectional communication

Exchange Pattern modelling using UML

Exchange patterns which enables features for selected FEP can be described by use of some UML diagrams which describe which actors are involved in the exchange, and the specific interactions among them which enable the features themselves.

Exchange system description assumes external systems like TCC and TMC are external to exchange and exchange agents are the actors which may implement the exchange role of client, supplier, service requester or service provider as defined in the business case.

The Figure 6 describes the main exchange involved actors as well as other interacting actor external to exchange.

image6

Figure 6 — Exchange actors

Systems (e.g. TCC or TMC system) may act both as client or supplier and for exchange purposes, systems need to interact with the exchange agent, of the same client or supplier type, which realise a system interface enabling the exchange features.

Based on multiple option for a system to be a client or supplier for Data Delivery, or a Service Requester or Service Provider for Collaborative ITS Services business scenario, the relative system and interfaces can specialise. Figure 7 and Figure 9 shows the exchange agent and interfaces specialisation respectively for data delivery

image7

Figure 7 — Data Delivery Exchange actors definitions

image8

Figure 8 — Communication: Features and requirements

image9

Figure 9 — CIS Exchange agents definition

image10

Figure 10 — CIS Exchange systems, agents and interfaces

This system, exchange agents and interfaces classes will be used in any of the FEP+EP specification descriptions in the following clauses to describe the provided interfaces and interactions. Each of exchange interface realisation will be implemented as a specific specialisation for its FEP+EP, e.g. Snapshot Push will have its specific “snapshot push” supplier interface”, i.e. the “Snapshot Push Client Interface”, which will be described as a specialisation of the exchange snapshot push client interface. The modelling for a snapshot push client system and its Exchange agent and interface is shown in Figure 11.

image11

Figure 11 — Sample of “Snapshot Push” client system and its Exchange agent and interface

The relevant Communication Diagrams will be introduced in the FEP+EP descriptions in the following clauses. In the description of the interactions among exchange systems and subsystems UML Sequence Diagrams will be used. Interactions among actors and their interfaces are described using the actor themselves, the realised specialised interfaces are not mentioned for schema understanding convenience. Figure 12 is an example of provided Sequence Diagram.

image12

Figure 12 — CIS Exchange actors

State Diagrams can be used as well to specify specific status of exchange operation which will lead to specific interfaces behaviours such as return messages definition and specific interaction provided (e.g. synchronisation, synchronisation request). State Diagram are not needed for understanding in simple cases such as stateless FEP+EP so they will not be described in some FEP+EP descriptions.