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

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

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:

Figure 4 — General Data Delivery Business Scenario actors

The following Table provides the basic definitions for exchange:

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.

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.

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.

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

Figure 7 — Data Delivery Exchange actors definitions

Figure 8 — Communication: Features and requirements

Figure 9 — CIS Exchange agents definition

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.

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.

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.