A Userguide to better understand Exchange 2020

Guide to Exchange documentation

Definitions

Term

Definition

Exchange

The transfer of information or data among IT Systems. DATEX II is mostly concerned among Road Information exchange among Traffic Control Centres, Traffic Management Centre, Traffic Information Centres and Service Providers.

Platform Independent Model (PIM)

an abstract description of an Exchange Environment in a way that is independent of any technical solution or technology.

Business Scenarios

these explain the context and global purpose for which Exchange is needed; two main business scenarios have been identified as:

  • Information Delivery

  • Collaborative ITS Services

Requirements

list of general properties of systems which should be implemented in a real environment to grant functionalities based on selected use cases: not all requirements are applicable or needed to all Use Cases or even consistent among themselves, this allow that a subset of requirements leads to different Features needed and consequent choices in Platform.

Exchange Environment

list of systems and subsystems which are needed to implement Exchange

Exchange Pattern (EP)

a combination of Systems/Subsystems and means of communication among them which enable information exchange which can be combined to implement the Exchange Environment and its requirements.

Features

a combination of Systems/Subsystems and means of communication among them which enable information exchange which can be combined to implement the Exchange Environment and its requirements.

Functional Exchange Profile (FEP)

available characteristics implemented in the Exchange Environment, Features can satisfy one or more requirements.

FEP/EP based Platform Indipendent Model (FEP/EP PIM)

a description of interaction among actors ( systems/subsystems) which describes an Exchange based on the implementation of features, in a way that is independent of specific technology.

Platform Specific model (PSM)

a definite Implementation of a FEP/EP based PIM which describes subsystems and means of communication under a specific choosen technology / Platform

Note

Exchange 2018 specification had been focused on basic use cases such as Snapshot Pull and Snapshot Push, then Simple Push had been introduced to enable link monitoring and Stateful Push adding further controls including session management capabilties, all these may be considered basic exchange pattern, with increasing complexity which is needed to implement a wider set of features to fulfil a wider set of requirements depending on data exchange usage. Those grants most of needed functionalities in everyday use cases. CIS Use case FEP have also been developed enabling service request and service feedback interaction as a basis to implement TMPlan services and general CIS workflows.

Exchange approach

image3

Figure 1 — Exchange PIM/PSM modelling approach

Exchange Global Business Scenarios in the context of Traffic Control Centres are derived abstracting from several use cases and requirements collection. This level is named Platform Independent Model (PIM) which describe exchange interaction among system in an abstract way not depending from a specific technology: the description of subsystem interaction is made by use of UML methodology as Collaboration, Sequence and State Diagrams.

As PIM level fully describe the interaction among systems, the implementation of the abstract model to a specific implementation technology is mostly focused on how interaction among subsystems are implemented and data are encoded into specific implementation framework used. E.g. deriving XML Schema for the Basic Exchange Data Model and naming and definition of WSDL methods which implements the abstract message interaction in the sequence diagrams.

Based on above schema the reference for all documentation provided for Exchange 2020 is as follows, including a reference to actually described PIMs and PSMs.

Document type

Support

Reference

Document Name

Exchange PIM

Exchange PSM

Content Description

Modeling Approach

PIM to PSM modeling

Selected FEP + EP PIM definition

Snapshot Pull

WS SOAP

Add link to the specific WSDL when deployed on website

http/get

Snapshot Push

WS SOAP

Simple Push

WS SOAP

Stateful Push

WS SOAP

CIS Service Request

WS SOAP

CIS Service Feedback

WS SOAP

Note

A platform-independent model for a “full publish subscribe” exchange pattern, aiming to describe a WS Notification (Oasis) specification based PSM , is available but has not been prioritised for implementation.

Exchange methods most suitable for implementations

In DATEX 2020 Exchange specification several Exchange methods are available, suiting different Use Cases defined for Road and Traffic Data Exchange among centres.

It is useful to recap DATEX II Exchange is designed to exchange Road and Traffic Information among Traffic Control Centres (TCC) Traffic Information Centres and / or Service Providers.

imagetccsp

As defined in ISO 19468 Information among centres may be exchanged for many purposes, we had defined 2 major Business Scenarios as:

  1. Data Delivery: only the information exchange requirements are considered, Exchange goal is information delivery itself and no further information processing scope is considered

  2. Collaborative ITS Services: after data Exchange a processing is needed and the outcome of the process is needed to fulfill specific goal such as Traffic Management Operation decision, VMS Setting, other devices / network resources configuration enabled.

Based on information usage requirements had been defined and collected and the more appropriate Exchange Platform can be selected according to the best fitting to requirements. The following table will provide some guidance in selecting the best usable Platform Exchange at the needed effort / implementation cost.

Use Case

Business Scenario

Available Exchange Methods

Triggered

Delivery of Road Traffic Data from Sensors for standard processing

Data Delivery

Snapshot Pull Snapshot Push

Periodic Condition Triggered

Delivery of Road Traffic Data from Sensors for real time processing

Data Delivery

Simple Push (Snapshot / Delta)

Periodic Condition Triggered On Occurrence

Delivery of Road Traffic Data for ITS delivery Services such broadcast or VMS Setting or Traffic Management

Data Delivery

Simple Push Stateful Push

Condition Triggered On Occurrence

Delivery of Road Traffic Data for Traffic Management / VMS Setting

Collaborative ITS Services

Simple CIS Stateful CIS

On Occurrence

Examples of the four cases stated above:

Delivery of Road Traffic Data from sensors for standard processing

Information gathered at the centre is delivered to other centre for internal use and Traffic Analysis to be managed, data are processed at discrete time interval, not dramatically depending on specific time. Error recovery is possible in case of network errors to gather data after the error had been recovered.

Delivery of Road Traffic Data from sensors for real time processing

Information gathered at the centre is delivered to other centre for internal use and Traffic Analysis to be managed, data are processed when available, to deliver information to implement some services e.g. travel time information or any other real time information which evolve time to time. Error network or data unavailability invalid the data processed which can’t be delivered further, until the exchange is fully recovered.

Delivery of Road Traffic Data for ITS delivery Services such broadcast or VMS Setting or Traffic Management

Information is delivered to be processed within shortest time period to grant information is delivered to final services users

Delivery of Road Traffic Data for Traffic Management / VMS Setting

Information is delivered to be processed within shortest time period to implement road network management decision. Precise Feedback on information processing is given to proceed further to any further processing and operation decision.

Note

The difference among Simple CIS and Stateful CIS is that Simple CIS allows to exchange Service Request and Service Feedback without need to establish a session so they are stateless for connection purposes, while Stateful CIS is based on Session and link monitoring is enabled to monitor network and connection status besides.

The following qualitative table resumes main requirements available in the different platforms

Exchange Methods

Snapshot Push / Pull

Simple Push

Stateful Push

Pub Sub

Requirements

Periodic

Condition Triggered

Timely Information(on occurrence)

N

N

Y

Y

Y

Network Error Management

N

N

Y

Y

Y

Accurate Information(full lifecycle)

N

N

N

Y

Y

Implementation Complexity / Cost

Low

Low

Medium

High

Highest

Functionality

Low

Low

Medium

Medium-High

Full

Note

This diagram is a qualitative one provided to easily orientate users to analysis and choices, a full set of requirement analysis and requirement implementation table by Platform Specific Model is defined in Exchange PIM annexes.

Exchange Methods

Delivery Method

Feature

argument

return

Snapshot Pull

pullSnapshotData

Data Delivery

ExchangeInformation

MessageContainer

Snapshot Push

putSnapshotData

Data Delivery

MessageContainer

ExchangeInformation

Simple Push

putSnapshotData

Data Delivery

MessageContainer

ExchangeInformation

putData

Data Delivery

MessageContainer

ExchangeInformation

keepAlive

Link Monitoring

ExchangeInformation

ExchangeInformation

Stateful Push

putData

Data Delivery

putSnapshotData

Data Delivery

openSession

Session Management

closeSession

keepAlive

The following table lists the available methods available per implemented WSDL web service.

Exchange Methods available / Feature implemented

pullData

putSnapshotData

putData

openSession

closeSession

keepAlive

puCISServiceRequest

putCISServiceFeedback

Data Delivery

Session Lifecycle

SessionLifecycle

Link Monitoring

Support Information Processing

Support Information Processing

Snapshot Pull

X

Snapshot Push

X

Simple Push

X

X

X

Stateful Push

X

X

X

X

X

CIS Service Request/Feedback

X

X

X

X

X

Exchange Data Model: how to use to include profiled/extended Payload Publication

Basic Data Exchange Model is delivered within DATEX II documentation as a plug and play tool to wrap Payload Information adding information needed to improve and implement Exchange functionalities and Information Management.

basicdataexchange

The hook to implement profiled payload information is the PayloadPublication class A set of XSD needed for CIS are provided which are included in Message Container description schema and will then include Payload Publication as well through MessageContainer xsd definition:

  • DATEXII_3_CISInformation.xsd

  • DATEXII_3_ExchangeInformation.xsd

  • DATEXII_3_InformationManagement.xsd

  • DATEXII_3_MessageContainer.xsd

Based on DATEX II methodology and tool any user has to create his own D2Payload from a pre-packaged Model that contains Exchange and Common, plus all other package he needs. Then generate the schemas with DATEX II tool ( webtool at http://webtool.datex2.eu ) and use the schemas created that way together with the WSDLs provided.

Warning

PROGRAMMER NOTE Code Generation by JAXB: Please note that importing the WSDL and xsd schemas generated with JAXB the generated code need a manual update to set XMLRoot for ExchangeInformation and MessageContainer such as - add tag @XmlRootElement to ExchangeInformation and MessageContainer classes after they had been generated by JAXB