ANNEX

A - Methodology presentation

(informative)

Introduction

This informative annex presents the approach followed for this Technical Specification and the rationale behind the choices made.

Apply Model Driven Architecture

The original approach taken for modelling the full set of aspects covered by data exchange clearly identified the need to separate the exchange specifications, of what needs to be exchanged and the exchange of the data itself. This is reflected by creating two independent interoperability domains:

  • The information interoperability domain as reflected in the content PIM (e.g. of DATEX II)

  • The exchange interoperability domain as reflected by this Technical Specification.

While the payload content model can be regarded as describing “what to exchange”, the present exchange specification deals with the problems about “how to exchange”.

A distinction has also been made in the modelling phase to separate the abstract model from its concrete implementation(s). In practice, this approach led to the creation of a Platform Independent Model for Exchange (PIM), which described the concepts behind exchange, and one or more Platform Specific Models (PSMs) which defined how the abstract model would actually be implemented on specific technical platforms. As this basic principle of the Model Driven Architecture (MDA) has guided all the work that was already undertaken for creating the full set of specifications for content definition with notable success, it was chosen as well for the Exchange Specification definition.

Therefore, this Exchange Specification is based on a Platform Independent Model for Exchange (the Exchange PIM), which is detailed in one or more documents containing specifications targeted to specific platform implementations (PSM).

Use Case Driven

One of the principles followed in this Technical Specifications is to clearly identify the Business Scenarios that are addressed by the specifications plus the full set of features that can be available for implementing actual systems based on this Technical Specification for each of those Business Scenarios. This led to the identification of two main Business Scenarios:

  • Information Delivery

  • ITS Services Collaboration

The Information Delivery Business Scenario addresses the exchange of traffic and travel information between two data exchange nodes, whereas the ITS Services Collaboration Business Scenario broadens this approach by including the possibility of having one data exchange node stimulating actions within another data exchange node by requesting the execution of a particular service offered by this node.

These two Business Scenarios clearly show distinct characteristics, but in order to fully describe them, both need to be detailed further, leading to different possible options. Therefore, the approach was to further refine these general Business Scenario’s into particular, more detailed use cases, each of which addressing specific requirements.

The term use case is used here to describe a set of interactions between entities (called actors) and the system being analysed, providing a better understanding of the main functions behind such interactions.

In the case of the Information Delivery domain, the actors involved in the corresponding use cases are the supplier of exchanged information and the receiver of such information – the client. For the ITS Services Collaboration domain, the actors involved are the entity requesting the ITS Services, or the service consumer, and the entity providing the service, i.e. the service provider.

Functional Exchange Profiles

When analysing the Business Scenarios and requirements for this Technical Specification, it became apparent that different use cases within such a Business Scenario might contain disparate requirements, which could not be easily accommodated into a single, specific implementation. Even worse, some use case might even contain requirements that are, by nature, contradictory, depending on the business needs of the user community they originated from.

Having that in mind, this specification identifies the full set of features that can be available for a data exchange process to take place. Then – in a second step – the specification reflects the particular use cases and selects the best suited set of features for each of them. This selection is denoted a Functional Exchange Profile – FEP.

Profile to Platform Mapping

By performing a short survey on the capabilities that modern ICT platforms offer it became apparent that some of the features indicated for implementing data exchange systems can be realised differently depending on the platforms chosen. As such, the one-size-fits-all approach that was followed on the previous version of the Exchange Specification for creating concrete implementations simply does not fit into the new paradigm.

At the heart of the current Specification sits the Platform Independent Model (PIM) for data exchange. Its purpose is to model the interactions that were identified for each use case in an abstract, platform independent way. The Exchange PIM is detailed in this Technical Specification.

This platform independent specification then has to be mapped to a realisation of the indicated FEP on a specific technical platform, described in a Platform Specific Model (PSM) for data Exchange, covered by Part 3 of this Specification. The act of matching a FEP to a platform is also known as Profile to Platform Mapping. Each one of these mappings form what is called an Interoperability Domain. It is only in the scope of such an Interoperability Domain that two data exchange nodes can expect to be interoperable, i.e. if two different implementers of data exchange systems need to be sure that their system will be able to communicate, they both must follow the same mapping.

B - Definition of requirements

(normative)

Information Requirements

The primary intent of the information delivery scenario is the provision of information by a supplier to a client. This subclause provides requirements that are related to the data actually being transferred from supplier to client. For each requirement it is stated whether applicable to Data Delivery or Collaborative ITS Services Business (CIS) Scenarios, assuming for CIS supplier is intended as Service Requester and Client as Service Provider and Data are exchanged or processed as input to provision of services.

Table B.1 — Information requirements

Requirement

Description

Data Delivery

Collaborative ITS Services

Stateless server

In a stateless exchange the supplier keeps no track of previous interactions that have occurred between with any of its clients. Therefore, the client is responsible for providing the supplier with all information it can need in order to serve his request. Note that this requirement does not oblige the supplier to have a mechanism for receiving state information as that depends on the availability of other requirements described in this clause (e.g. filter handling).

Y

With state server

Any supplier implementing this feature should provide some sort of state keeping mechanism that will allow it to know what information was sent to his client. Therefore, it would be possible for the supplier to send only information that has not been already sent before. A supplier implementing this mechanism can also support other requirements that allow clients to shape the actual data set being received (e.g. filter handling).

Y

Y

Subscription

The information that a supplier delivers to a client is defined by a subscription. A subscription results from an interchange/license agreement, where both parties agree on parameters like, e.g. the information type and periodicity that should be observed upon data delivered. The supplier can choose to reject requests without proper subscription, or it can deliver a standard set of information.

Y

Y

Catalogue Exchange

The information a supplier provides is described in a catalogue. The catalogue is used to identify the information contained in a subscription.

Y

Y

Self-description

The ability of two nodes to exchange information that will allow them to negotiate the requirements supported by both of them (handshake).

This feature deals with exchange parameters, which is different from a catalogue exchange that deals with content.

Y

Y

Filter handling

A supplier implementing this feature enables clients to provide specific filters that must be applied to the information being exchanged.

Y

Y

Client profiles

A client profile lets suppliers shape the information they send according to the requirements of the client requesting it.

Y

Y

Interchange/License agreement

Legal artefact where parties taking part in data exchange define the terms and conditions that govern the whole exchange process (e.g. Non-disclosure of information, service level agreements, etc.).

Y

Y

Integrity

This feature implies that the data that is prepared by the supplier should reach its intended recipient without being tampered in any way, semantic, structural or other.

Y

Y

Full audit trail data delivery (all state changes)

All data item versions are delivered to the client.

Y

Y

Snapshot data delivery (last known state)

Only the current version of the data items is delivered to the client.

Y

Y

Incremental Data Delivery

A mechanism where the server sends only the information that has changed since the previous exchange cycle

Y

Y

Reference datasets for different versions

Service a supplier should provide for the client to access referenced data in a versioned way. Even if new versions appear the old versions remain accessible.

Y

Y

Extensibility

Extensions to the data exchange protocol should be supported; therefore, any implementation of the data delivery use case must consider that the protocol can evolve. Thus, each message should state the protocol version it refers to.

Y

Y

Support for lifecycle management

A set of function for updating information at client systems according to updated information gathered at supplier system

Y

Y

Support for information management

A set of functions that will let the supplier (as service requester) tell the client (as service provider) what to do with the information being exchanged (processing directive).

Y

Support for feedback on information management

A set of functions that will let the client (service provider) tell the supplier (service requester) the outcomes of processing the information by the stated directive which had been exchanged.

Y

Distributed transaction

A capability for the exchange system to coordinate among several involved service provider systems to collaborate in implementing a distributed service.

Y

Distributed atomic transaction

A capability for the exchange system to coordinate among several involved service provider systems to collaborate in implementing a distributed service keeping consistency in transaction.

Y

Synchronization

A mechanism that lets clients request the whole set of information currently known to the supplier to ensure that its internal data structures be in exactly the same state as those of the supplier. (intended for CIS the Service provider need the exact information to provide the requested services)

Y

Y

Delayed delivery

In the case that preparing and sending a data set by the supplier would take too much time to complete, the supplier should inform the client about this fact. This mechanism should also define how and when the client would be able to access the information it needs.

Y

Data delivered as soon as possible

This feature is used to ensure that the supplier sends the information as soon as it becomes available in its system.

Y

Y

On demand request (query)

The ability of the client to ask the server for information it needs whenever it wants (Client Pull).

Y

Communication Requirements

Communication requirements characterise the mechanism that data exchange nodes implement in order to address problems specific to the communication layer of the data exchange process. These requirements are completely unaware of both the security and information features that are in use. The idea is that given a supplier has prepared a particular dataset; the requirements described in this subclause can be used to successfully convey it to the client.

Table B.2 — Communication requirements

Requirement

Description

Data Delivery

Collaborative ITS Services

Sessionless

No session is used during the data exchange process

Y

Y

Session

Client and supplier negotiate and establish a session before starting to exchange information. The session parameters constitute state information shared between both stations.

Y

Y

Request/response

A mechanism where the client requests the data and instantly receives the response.

Y

Y

Delivery/response

A mechanism where the supplier initiates the data delivery process, while the client patiently waits for it.

Y

Y

Error handling

A mechanism that allows both client and supplier to detect that an error has occurred during the exchange process and to decide what actions should be taken to handle it.

Y

Y

Timely responses

The communication layer should introduce a minimum delay on the data delivery process, ideally none.

Y

Y

Timeout management

The ability to handle timeout situations that happen during an exchange process.

Y

Y

Exchange quality measures (ex. response timestamp)

The messages exchanged should include extra information that allows both parties involved to measure the quality of service of the communication layer.

Y

Y

Logging

A mechanism for storing information about exchange activities, which could then be used to analyse the whole process.

Y

Y

Failed data recovery

When the supplier fails to deliver the information to the client, this feature ensures that the failed data messages will be successfully delivered to the client at a later time.

Y

Y

Message sequence

A mechanism that allows identifying each message exchanged between two entities by including a unique sequence number.

Y

Y

Full reliability

A mechanism that ensures that data sent by a supplier is really received by the client provided that both client and supplier are active and have the ability to communicate.

This does not include any semantic validation. Syntax validation is optional.

Y

Y

Link monitoring and control

This feature enables both parties to continually check whether the communication link works properly and act accordingly when it is broken.

Y

Y

On occurrence update

A supplier implementing this feature should send the information to the client as soon as it is available.

Y

Periodic update

A supplier implementing this feature should buffer all the information to be sent to a particular client for a pre-defined time period send information only when this period has elapsed.

Y

Multi-part data delivery

When the size of the information to be delivered is too large, the supplier can choose to deliver it in chunks. At the first request, the supplier returns the first data chunk. The response contains the message ID and the total number of parts (chunks) that comprise the dataset. The client then has to request each of the remaining parts of the message.

Y

Y

Compression

The ability to pack the same information in a smaller amount of data in order to decrease the transmission time.

Y

Y

Security Requirements

The requirements described in this subclause deal with all aspects used to provide security services at any of the different communication levels, such as peer authentication, channel security and so on.

Table B.3 — Security requirements

Requirement

Description

Data Delivery

Collaborative ITS Services

Client Authentication

The act of establishing or confirming a client as authentic.

Y

Y

Client Authorization

The process of verifying if a client is allowed to access some resource (commonly referred to as read access) or execute some action (commonly referred to as write access).

Y

Y

Supplier Authentication

The act of establishing or confirming a supplier as authentic.

Y

Y

Supplier Authorization

The process of verifying if a supplier is allowed to access some resource (commonly referred to as read access) or execute some action (commonly referred to as write access).

Y

Y

State the intended recipient

The act of indicating the destination peer of a message.

Y

Y

Confidentiality

Ensuring that information is accessible only to those authorized to have access (ISO 27002).

Y

Y

Client identification

A mechanism that allows a client to provide his identity.

Y

Y

Supplier identification

A mechanism that allows a supplier to provide his identity.

Y

Y

Non-repudiation

A mechanism to guarantee that the sender (supplier of a client) of a message cannot later deny having sent the message.

Y

Y

Financial/economic requirements

Although being not at the same level the requirements described in this subclause have some economic/financial impact on the actual implementation of the data exchange sub-system.

Table B.4 — Financial/economic requirements

Requirement

Description

Data Delivery

Collaborative ITS Services

Reasonable TCO (Total Cost of Ownership)

The data exchange sub-system must have a reasonable TCO (Total Cost of Ownership).

Y

Y

Expandability at a reasonable cost (scalability)

The data exchange sub-system should be implemented in such a way that it can be possible to increase the capacity of the system at a reasonable cost. Capacity relates to any of the system resources, such as data volumes, computation power, parallel processing, etc.

Y

Y

Low processing resources

It shall be possible to implement a data exchange sub-system on systems with low processing resources.

Y

Y

C - Basic Exchange Data Model and Data Dictionary

(informative)

Methodology issue

The current Data Model implements DATEX II methodology to implement a Model useful to encode not payload information which is needed to implement Information Delivery Business case in a DATEX Environment besides the Snapshot Pull and Snapshot Push FEP+EP.

For any need a reference to this document is DATEX II methodology EN-16157-1

Whenever Exchange features as Session Management, Link Monitoring are needed some extra information need to be conveyed among Supplier and Client to enable control and reliable exchange management.

Furthermore, in some context, more than one Information Payload may be exchanged, so that this model further allows to exchange multiple payloads based on such extra exchange requirements.

This model is not needed to implement for Simplified Information Delivery FEP+EP such as Snapshot Pull, Snapshot Push.

Basic Exchange Data Model

Exchange Data Model is used to convey information which are needed to manage Exchange Features such as Information Management, Session Management, Link Monitoring.

Further Information is needed to manage CIS.

MessageContainer Diagram

image0

Figure C.1 - MessageContainerDiagram

A MessageContainer Class is introduced to allow delivery of further information besides payload such as:

  • Exchange Information: which is needed to manage Exchange feature such as Session Management and Link Monitoring and Exchange Error management.

  • Information Management related information

  • Collaborative ITS Services information

All linked Classes are optional, constraints on implementation depending by different FEP+EP which will implement the Exchange and its features, e.g. Exchange Class will be mandatory in a FEP+EP which needs to implement Session Management, such as Stateful Push FEP+EP.

D2Container class also allows to convey multiple Payload Publication within a single exchanged message.

ExchangeInformation Diagram

image1

Figure C.2 - ExchangeInformation Diagram

Exchange Information is used to convey information about Exchange Environment such as:

  • Exchange Contest, which is implied by Supplier and Client(s) identification, the type of protocol which is defined to be used in exchanging data, the implemented version of this protocol.

  • Dynamic Information: such as Exchange Status and Return Status (within a set of predefined Exchanged Status and Return Status Enumeration List and their Reason) and SessionID for Exchange Patterns which manages Sessions

Exchange contest is optional as mostly implicit in subscription contract and normally can be omitted so the link to ExchangeContext Class is not mandatory. Otherwise such information could be used to simplify or double check some Communication features such as Supplier and Client Identification, Authentication, Authorisation, which can only be implemented in a reliable way based on Communication Layers.

Dynamic information is the only mandatory class in which the attribute exchangeStatus is the only mandatory information. Other information will be mandatory whenever needed to be managed in different FEP+EP: i.e. in case of Session Management Feature implementation SessionID attribute in class SessionInformation will be needed to be managed.

InformationManagement Diagram

image2

Figure C.3 - InformationManagement Diagram

Information Management Class allows to deliver Information Management Data: as defined in Annex F for lifecycle information only valid information is managed in the payload, whenever an element ends it lifecycle, i.e. being closed or cancelled, it is no more conveyed in the payload and information management is to be delivered to manage closures or cancellation of such elements.

These closed and cancelled elements are conveyed linked through InformationManagedResourceList Class and are addressed by Element Reference Class which allow identification of the element by its reference or versioned reference, specifying its managementStatus, i.e. closed, cancelled.

CISInformation Diagram

image3

Figure C.4 - CISInformation Diagram

With Reference to Annex G Collaborative ITS Services transform the vision of Supplier and Client in Service Provider and Service Requester: CISInformation conveys in the data model the information needed to implement Service Request and Service Feedback as described to be exchanged among Service Provider and Service Requester.

CISInformation Class: allows to convey any Service Request and Service Feedback which are requested to be exchanged among Service Requester and Service Providers through the respective named classes ServiceRequest and ServiceFeedback

ServiceRequest: conveys information related to a single Service Request

  • Service Request creation and update time

  • predefinedService: to be chosen among an enumerated list such as processing, broadcast Delivery, VMS Message process, Traffic Management Plan activation

  • not predefined service name

  • custom service parameter: custom parameter to raise for processing

  • requestedAction: Approve, Implement, terminate, cancel

  • element to process reference or external reference

  • expiry time when a service is valid only implemented within a limited time amount after which it will be no more needed

Service Request may be related to a Service Condition through ServiceCondition class identifying the need for that kind of service through some payload reference for a predefined, coded or not predefined i.e. unpredictable condition.

ServiceRequest class also allows addressing the identification of implied Service Providers needed to implement such request and the service.

ServiceFeedback: allows to convey information about the processing of a Service request previously exchanged through reference information to the Service Request itself and specifying its Status among a set (compliant, failed, not compliant, processing, rejected, scheduled, success, timedOut) plus a reason for that status.

Data Dictionary Overview

This data dictionary describes the characteristics of the different classes, attributes and roles appearing in the data model defined in Clause. The dictionary is specified as a set of tables grouping classes, attributes and roles for each package as they are defined in Clause.

For each package are successively provided:

  1. The class table,

  2. The association role table.

  3. The attribute table,

Each table of a given type has the same structure.

The data dictionary is categorised into sections following the different UML model packages as mentioned above. It defines for every package the entities and elements corresponding.

The table columns have the following meaning:

  1. Columns Name: they provide the symbolic name (either in Lower or Upper Camel Case) given to the corresponding class, attribute or association role.

  2. Column Designation: it provides the corresponding name in natural language of the corresponding class, attribute or role.

  3. Column Definition: it provides a comprehensive definition detailing this class, attribute or association role.

Some columns are specific for one or two tables. The class tables include the following two columns:

  1. Column Abstract: it indicates if the corresponding class is abstract (value “yes”) or concrete (value “no”). Abstract classes are defined in ISO/IEC 19505-1.

The attribute tables and the association tables include the following column:

  1. Column Multiplicity: it provides the number of occurrences a class may have when instantiating this association (resp. a class attribute may have when instantiating this class). The adopted syntax is the following: m..n where ‘m’ and ‘n’ respectively represent the minimum and the maximum value of multiplicity.

  2. For association roles, the possible value for ‘m’ are:

  1. 0 in case of an optional participation of the corresponding class when instantiating the association;

  2. 1 in case of a mandatory participation of the corresponding class when instantiating the association;

  3. 2, 3, … in case a minimum number of participations of the corresponding class is explicitly defined when instantiating the association.

  1. For association roles, the possible value for ‘n’ are:

    1. 1 in case only one class instance is at most participating at the association instantiation;

    2. * in case several instances are allowed participating at the association instantiation;

    3. 2, 3, .. in case a maximum number of participations of the corresponding class is explicitly defined when instantiating the association.

  1. For attributes, the possible value for ‘m’ are:

    1. 0 in case of an optional attribute;

    2. 1 in case of a mandatory association / attribute;

    3. 2, 3, … in case a minimum number of occurrences is explicitly defined.

  1. For attributes, the possible value for ‘n’ are:

    1. 1 in case only one attribute instance is allowed;

    2. * in case several instances are allowed for this attribute without being specified;

    3. 2, 3, .. in case a maximum number of occurrences is explicitly defined.

For the attribute tables, the following column has been added:

  1. Column Type: it provides the class name used as data type. It is only provided for elements corresponding to class attributes. When the type name ends with ‘Enum’ this means it corresponds to an enumeration of accepted values defined in Errore. L’origine riferimento non è stata trovata..

For the association table, the following column has been added:

  1. Column Target: it provides the class name appearing at the second end of the relationship, i.e. linked through the corresponding association.

Data dictionary for Basic Exchange Data Model

Data Dictionary for “ExchangeDataModel”

Classes

MessageContainer/InformationManagement/Classes

“Classes” package classes

Table A.1— Classes of the “Classes” package

Class name

Designation

Definition

Stereotype

Abstract

ElementReference

Element reference

Element Reference

D2Class

no

InformationManagedResourceList

Information managed resource list

Managed Resource List

D2Class

no

InformationManagement

Information management

Information Managment

D2Class

no

Associations of “Classes” package

Table A.2— Associations of the “Classes” package

Class name

Association end

Designation

Definition

Multiplicity

Target

InformationManagedResourceList

elementReference

Element reference

1..*

ElementReference

InformationManagement

informationManagedResourceList

Information managed resource list

0..1

InformationManagedResourceList

“Classes” package attributes

Table A.3— Attributes of the “Classes” package

Class name

Attribute name

Designation

Definition

Multiplicity

Type

ElementReference

managementStatus

Management status

It identifies the status of the element referenced

1..1

ManagementTypeEnum

reference

Reference

It identifies the DatexII reference

0..1

Reference

versionedReference

Versioned reference

It identifies the DatexII versioned reference

0..1

VersionedReference

“Classes” package

MessageContainer/ExchangeInformation/Classes

“Classes” package classes

Table A.4— Classes of the “Classes” package

Class name

Designation

Definition

Stereotype

Abstract

DynamicInformation

Dynamic information

Dynamic Exchange Information

D2Class

no

ExchangeContext

Exchange context

Exchange Context

D2Class

no

ExchangeInformation

Exchange information

Exchange Information

D2Class

no

SessionInformation

Session information

Session Information

D2Class

no

Associations of “Classes” package

Table A.5— Associations of the “Classes” package

Class name

Association end

Designation

Definition

Multiplicity

Target

DynamicInformation

sessionInformation

Session information

0..1

SessionInformation

ExchangeContext

client

Client

client information, depending on Exchange Pattern may be stated for single or multiple client or not stated

0..*

InternationalIdentifier

supplier

Supplier

define the supplier of information of the exchange

1..1

InternationalIdentifier

ExchangeInformation

dynamicInformation

Dynamic information

1..1

DynamicInformation

exchangeContext

Exchange context

0..1

ExchangeContext

“Classes” package attributes

Table A.6— Attributes of the “Classes” package

Class name

Attribute name

Designation

Definition

Multiplicity

Type

DynamicInformation

exchangeReturnStatus

Exchange return status

Exchange Return Status defined by protocol Specification

0..1

ExchangeReturnEnum

exchangeReturnStatusReason

Exchange return status reason

multilingual textual description of Exchange Return Status defined by protocol Specification

0..1

MultilingualString

exchangeStatus

Exchange status

Status of Exchange defined by protocol Specification

0..1

ExchangeStatusEnum

exchangeStatusDescription

Exchange status description

multilingual textual Status description of Exchange defined by protocol Specification

0..1

MultilingualString

ExchangeContext

protocolType

Protocol type

the exchange protocol type as referenced by any standard or by agreement among client and supplier

1..1

String

protocolVersion

Protocol version

the version of the protocol used for the exchange as by standard or as agreed among client and supplier

1..1

String

SessionInformation

sessionID

Session i d

the ID of Sessione established among Client and Supplier

1..1

String

“Classes” package

MessageContainer/CISInformation/Classes

“Classes” package classes

Table A.7— Classes of the “Classes” package

Class name

Designation

Definition

Stereotype

Abstract

CISInformation

C i s information

CIS information

D2Class

no

ServiceFeedback

Service feedback

Feedback about a specific Service Request from the Service Implementer to the Requester

D2Class

no

ServiceRequest

Service request

Service Request from the Service Implementer to the Requester

D2Class

no

ServiceRequestCondition

Service request condition

specifies the condition which is behind the need for the service request, e.g. a specific situation or situation record, travel times status, specific road data or external conditions

D2Class

no

Associations of “Classes” package

Table A.8— Associations of the “Classes” package

Class name

Association end

Designation

Definition

Multiplicity

Target

CISInformation

serviceFeedback

Service feedback

0..*

ServiceFeedback

serviceRequest

Service request

0..*

ServiceRequest

ServiceFeedback

serviceImplementer

Service implementer

It Identifies the international identifier requester feedback

1..1

InternationalIdentifier

ServiceRequest

serviceRequestCondition

Service request condition

0..1

ServiceRequestCondition

serviceRequester

Service requester

It Identifies the international identifier requester

1..1

InternationalIdentifier

serviceImplementer

Service implementer

It Identifies the list of international identifier implementer

1..*

InternationalIdentifier

“Classes” package attributes

Table A.9— Attributes of the “Classes” package

Class name

Attribute name

Designation

Definition

Multiplicity

Type

ServiceFeedback

serviceRequestFeedbackReason

Service request feedback reason

additional text to feedback about the Status of the Service Request

0..1

MultilingualString

serviceRequestReference

Service request reference

Reference to the service request to which refers the Service Feedback

1..1

VersionedReference

serviceRequestStatus

Service request status

specifies the Status of Service request referenced

1..1

ServiceActionStatusEnum

ServiceRequest

customServiceParameter

Custom service parameter

a string conveying information for custom parameter to Service

0..1

String

elementToProcessReference

Element to process reference

Element reference to be process

0..1

Reference

elementToProcessVersionedReference

Element to process versioned reference

Element versioned reference to be process

0..1

VersionedReference

expiryTime

Expiry time

date time until which to implement the required action for Service

0..1

VersionedReference

externalReference

External reference

Extranle reference to be process

0..1

String

notPredefinedServiceName

Not predefined service name

Name of service not predefined

0..1

String

predefinedService

Predefined service

Type of predefined service

1..1

PredefinedServiceEnum

requestedAction

Requested action

identifies the action requested for the specified Service

1..1

ServiceActionEnum

servicerRequestCreationTime

Servicer request creation time

Time of creation request

1..1

DateTime

servicerRequestVersionTime

Servicer request version time

Time of version request time

1..1

DateTime

ServiceRequestCondition

conditionDescription

Condition description

A multilingual description of the condition under which the Service Request is instantiated

0..1

MultilingualString

externalIdCondition

External id condition

en external reference ID to the condition for the Service Request

0..*

String

referencedCondition

Referenced condition

the list of condition information which are referenced by a Identifiebla in payload publications

0..*

Reference

versionReferencedCondition

Version referenced condition

the list of condition information which are version referenced by a Identifiebla in payload publications

0..*

VersionedReference

“Common” package <<D2ExternalNamespace>>

MessageContainer/Common

“Common” package classes

Table A.10— Classes of the “Common” package

Class name

Designation

Definition

Stereotype

Abstract

“Common” package external classes

Table A.11— External classes of the “Common” package

Class name

Designation

Definition

Stereotype

InternationalIdentifier

International identifier

D2ExternalClass

PayloadPublication

Payload publication

D2ExternalClass

Associations of “Common” package

There are no defined associations in the “Common” package.

“Common” package attributes

There are no defined attributes in the “Common” package.

“D2Payload” package <<D2ExternalNamespace>>

MessageContainer/D2Payload

“D2Payload” package classes

Table A.12— Classes of the “D2Payload” package

Class name

Designation

Definition

Stereotype

Abstract

“D2Payload” package external classes

Table A.13— External classes of the “D2Payload” package

Class name

Designation

Definition

Stereotype

D2Payload

D2 payload

D2ExternalClass

Associations of “D2Payload” package

There are no defined associations in the “D2Payload” package.

“D2Payload” package attributes

There are no defined attributes in the “D2Payload” package.

“MessageContainer” package

MessageContainer

“MessageContainer” package classes

Table A.14— Classes of the “MessageContainer” package

Class name

Designation

Definition

Stereotype

Abstract

MessageContainer

Message container

a Container class to manage further information classes as Payload, Information Management, CIS Information and Exchange Information

D2ModelRoot

no

Associations of “MessageContainer” package

Table A.15— Associations of the “MessageContainer” package

Class name

Association end

Designation

Definition

Multiplicity

Target

MessageContainer

cisInformation

Cis information

0..1

CISInformation

informationManagement

Information management

0..1

InformationManagement

exchangeInformation

Exchange information

0..1

ExchangeInformation

payload

Payload

0..*

PayloadPublication

“MessageContainer” package attributes

There are no defined attributes in the “MessageContainer” package.

Data Dictionary of <<D2Datatype>> for “ExchangeDataModel”

There are no defined data types in the “ExchangeDataModel”.

Data Dictionary of <<D2Enumeration>> for “ExchangeDataModel”

This clause contains the definitions of all enumerations which are used in the “ExchangeDataModel”.

The <<D2Enumeration>> “ExchangeReturnEnum”

Enumeration that identifies the return status

Table A.16— Values contained in the enumeration “ExchangeReturnEnum”

Enumerated value name

Designation

Definition

ack

Ack

request fulfilled

closeSessionRequest

Close session request

client request to close session

fail

Fail

request failed

snapshotSynchronisationRequest

Snapshot synchronisation request

client request for snapshot synchronisation

The <<D2Enumeration>> “ExchangeStatusEnum”

Enumeration that identifies the status of exchange session

Table A.17— Values contained in the enumeration “ExchangeStatusEnum”

Enumerated value name

Designation

Definition

closingSession

Closing session

the closure of Session is under negotiation for protocol with Session management

offline

Offline

no exchange is possible due to lack of connectivity

online

Online

exchange connection is regular with no errors detected

openingSession

Opening session

Session Opening for protocols with Session management

resuming

Resuming

some errors had happened and Session is resuming for protocol with Session Management

The <<D2Enumeration>> “ManagementTypeEnum”

Enumeration of status information

Table A.18— Values contained in the enumeration “ManagementTypeEnum”

Enumerated value name

Designation

Definition

cancelled

Cancelled

The information has been cancelled

closed

Closed

The information has been closed

The <<D2Enumeration>> “PredefinedServiceEnum”

list of predefined service requests

Table A.19— Values contained in the enumeration “PredefinedServiceEnum”

Enumerated value name

Designation

Definition

broadcastDelivery

Broadcast delivery

Service delivery broadcast

other

Other

other service

tmpActivation

Tmp activation

Service TMP activation

vmsMessageProcessing

VMS message processing

Activation of VMS Message processign on information

The <<D2Enumeration>> “ServiceActionEnum”

The current or requested status of TMP activation during request, implementation and termination phases

Table A.20— Values contained in the enumeration “ServiceActionEnum”

Enumerated value name

Designation

Definition

agreement

Agreement

request for CIS agreement

cancellation

Cancellation

request to cancel the CIS Agreement or Implementation Request before agreement or implementation phase is completed

implementation

Implementation

the request of CIS Implementation, whenever no need of agreement proposal is needed, or a previous proposal have been agreed

processing

Processing

request to process information according to Requested Service (e.g. processing of any information to generate messages to display on VMS)

statusInformation

Status information

Request on previously delivered service request processing status information, to be delivered in Feedback

termination

Termination

request to terminate the CIS Activation once implemented

The <<D2Enumeration>> “ServiceActionStatusEnum”

Defines values of service status

Table A.21— Values contained in the enumeration “ServiceActionStatusEnum”

Enumerated value name

Designation

Definition

compliant

Compliant

service request has been found compliant to required specification for the service

failed

Failed

service request failed during processing

notCompliant

Not compliant

service request has not been found compliant to required specification for the service

processing

Processing

service request processing fase is not yet completed

rejected

Rejected

service request has been rejected by the service provider

scheduled

Scheduled

the Service Request had been scheduled for processing by the Service Provider

success

Success

the Service Request had been successfully processed by the Service Provider

timedOut

Timed out

the Service Request had not been fulfilled in the agreed time

Data Dictionary of <<D2ExternalType>> for “ExchangeDataModel”

This clause contains the definitions of all external types which are used in the “ExchangeDataModel”.

The <<D2ExternalType>> “DateTime”

The <<D2ExternalType>> “MultilingualString”

The <<D2ExternalType>> “Reference”

The <<D2ExternalType>> “String”

The <<D2ExternalType>> “VersionedReference”

D - Introduction to communications and protocols

(informative)

Overview

This informative annex includes a description of solutions and options that can give an answer to the DATEX II requirements, and should allow to the exchange specification the identification of the most used technologies and standards that might be used to address those features.

At this level DATEX II does not define any new specification. Instead, it identifies solutions based on the following principles:

  • Security should be delivered by the communication layer;

  • Identify the standards and technologies that fit to our requirements and features;

  • Describe in general the technology that can be used. However, each PSM Technical Specification should identify in detail how the technology must be implemented.

Protocol of communication

DATEX II is a protocol for traffic and travel data information exchange between systems typically over the Internet. The Internet protocol suite is the set of communications protocols used for the Internet.

The Internet protocol suite classifies its methods and protocols into four hierarchical abstraction layers:

  • The link layer that support the technology connected directly by hardware components;

  • The internet layer facilitates the interconnection of local networks, the support for the Internet Protocol (IP) communication;

  • The transport layer supports the Host-to-host communication, which provides a general application-agnostic framework to transmit data between hosts using protocols like the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP)

  • The application layer is the highest level, which contains all protocols such as HTTP, FTP, TLS/SSL, etc., that support the data communications services. This layer handles application-based interaction on a process-to-process level between communicating Internet hosts.

The data exchange protocol has a strong request to use current technologies like Web services to support the implementation of the exchange features. This Technical Specification identifies in each Internet protocol layer the existing standards and protocols that can be used to support each data exchange features and requirements. Each PSM standard should then describe how these protocols should be implemented.

The protocols used by this Technical specification are:

  • At the link, internet and transport layers, it uses the TCP/IP protocol and can implement some requirements like security over IPsec;

  • At the application layer it will base its implementation over the use of HTTP protocol. Some requirements can be implemented at this level, like support for services (Web Services), security (TLS/SSL or WS-Security) or compression.

The following diagram the most important protocols and standards that can be used to address each data exchange feature:

image4

Figure D.1 — Communication protocols and standards

Web Services definition and options

Web Services provide standard means of interoperating between different software applications, running on a variety of platforms and/or frameworks.

Definition (W3C - Web Service architecture - http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/): “A Web Service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web Service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialisation in conjunction with other Web-related standards.”

Web Services definitions offer several options. As an example the following table shows the options chosen by DATEX II.

Table D.1 — Web service options

Web Service Options

Decision

Discovery

Not dynamic: UDDI is not used, the Web Services are described in DATEX II Specification which is the reference for development

Security

The security set-up has to be decided by each PSM

Security

The data exchange protocol is designed to exchange data and should be able to implement different levels of security in order to support information security features. Security and their capabilities can be implemented at different layers of the Internet protocol using different solutions and technologies, all for the same capabilities:

  • At the link and transport layer IPSec can be used to implement security;

  • At the application layer TLS/SSL can be used over HTTP or WS-Security can be implemented over the Web Services.

Data exchange systems can implement the following features and capabilities:

  • Authentication is the capability of determining whether someone or something is, in fact, who or what it is declared to be. On a data exchange system both the supplier and the client can be authenticated.

  • Authorization is the capability of giving someone permission to do or have something. This concept is related to the subscription or profiles and will not be described at the security level.

  • Confidentiality is the capability that protects against the disclosure of information. In data exchange systems, it represents the assurance that only the supplier and the client are allowed to see the message.

  • Integrity is the capability that determines if the information or the message is correct and was not changed.

  • Nonrepudiation is the assurance that someone cannot deny something. Typically, nonrepudiation refers to the ability to ensure that a party to a contract or a communication cannot deny the authenticity of their signature on a document or the sending of a message that they originated. On the Internet, a digital signature is used not only to ensure that a message or document has been electronically signed by the person that purported to sign the Technical Specification, but also, since a digital signature can only be created by one person, to ensure that a person cannot later deny that they furnished the signature.

All of these features can be implemented using IPSec, TLS/SSL or WS Security.

IPsec

With IPsec security can be implemented at the network level without having impact on the application implementation or on the data exchange implementation. IPsec supports the implementation of all security capabilities Authentication, Authorization, Confidentiality, Integrity and Nonrepudiation, and normally is used on an end-to-end communication channel that can be used between a supplier and client network link.

IPsec is an end-to-end security scheme operating in the Internet Layer of the Internet Protocol Suite. It can be used protecting data flows between a pair of hosts (host-to-host), between a pair of security gateways (network-to-network), or between a security gateway and a host (network-to-host). IPsec protects any application traffic across an IP network. Applications do not need to be specifically designed to use IPsec.

Definition (IETF - IP Security (IPsec) and Internet Key Exchange (IKE) - http://tools.ietf.org/html/rfc6071): “IPsec (Internet Protocol Security) is a suite of protocols that provides security to Internet communications at the IP layer. The most common current use of IPsec is to provide a Virtual Private Network (VPN), either between two locations (gateway-to-gateway) or between a remote user and an enterprise network (host-to-gateway); it can also provide end-to-end, or host-to-host, security. IPsec is also used by other Internet protocols (e.g., Mobile IP version 6 (MIPv6)) to protect some or all of their traffic. IKE (Internet Key Exchange) is the key negotiation and management protocol that is most commonly used to provide dynamically negotiated and updated keying material for IPsec. IPsec and IKE can be used in conjunction with both IPv4 and IPv6.”

TLS/SSL

TLS/SSL supports all security capabilities: Authentication, Authorization, Confidentiality, Integrity and Nonrepudiation. The implementation of TLS/SSL is used over the HTTP protocol using the Web Server application features, is wide used on Internet and has a small impact on a DATA EXCHANGE implementation.

The Transport Layer Security (TLS) / Secure Sockets Layer (SSL) is implemented at the Transport Layer of the Internet Protocol Suite. The use of TLS/SSL must be designed into an application to protect the application protocols. The implementation of SSL over HTTP is commonly called HTTPS.

Definition (IETF - The Transport Layer Security (TLS) Protocol Version 1.2 - http://tools.ietf.org/html/rfc5246 ): “The primary goal of the TLS protocol is to provide privacy and data integrity between two communicating applications. The protocol is composed of two layers: the TLS Record Protocol and the TLS Handshake Protocol. At the lowest level, layered on top of some reliable transport protocol (e.g., TCP [TCP]), is the TLS Record Protocol. The TLS Record Protocol provides connection security that has two basic properties:

  • The connection is private. Symmetric cryptography is used for data encryption (e.g., AES [AES], RC4 [SCH], etc.). The keys for this symmetric encryption are generated uniquely for each connection and are based on a secret negotiated by another protocol (such as the TLS Handshake Protocol). The Record Protocol can also be used without encryption.

  • The connection is reliable. Message transport includes a message integrity check using a keyed MAC. Secure hash functions (e.g., SHA-1, etc.) are used for MAC computations. The Record Protocol can operate without a MAC, but is generally only used in this mode while another protocol is using the Record Protocol as a transport for negotiating security parameters.

The TLS Record Protocol is used for encapsulation of various higher-level protocols. One such encapsulated protocol, the TLS Handshake Protocol, allows the server and client to authenticate each other and to negotiate an encryption algorithm and cryptographic keys before the application protocol transmits or receives its first byte of data. The TLS Handshake Protocol provides connection security that has three basic properties:

  • The peer’s identity can be authenticated using asymmetric or public key, cryptography (e.g., RSA [RSA], DSA [DSS], etc.). This authentication can be made optional, but is generally required for at least one of the peers.

  • The negotiation of a shared secret is secure: the negotiated secret is unavailable to eavesdroppers, and for any authenticated connection the secret cannot be obtained, even by an attacker who can place himself in the middle of the connection.

  • The negotiation is reliable: no attacker can modify the negotiation communication without being detected by the parties to the communication.”

WS-Security

As with the other security protocols, WS-Security supports all security capabilities Authentication, Authorization, Confidentiality, Integrity and Nonrepudiation, although further implementations must be used along with WS-Security to achieve the functionality.

The WS-Security is implemented at the Application Layer of the Internet Protocol Suite. The implementation of WS-Security has a higher impact on the implementation because is made on the Web Services implementation, is easy to implement, but forces that both supplier and client to implement the protocol in their Web Services implementation.

Definition (Web Services Security v1.1 - http://www.oasis-open.org/standards#wssv1.1 ): “This specification proposes a standard set of SOAP [SOAP11, SOAP12] extensions that can be used when building secure Web services to implement message content integrity and confidentiality. This specification refers to this set of extensions and modules as the “Web Services Security: SOAP Message Security” or “WSS: SOAP Message Security”.

This specification is flexible and is designed to be used as the basis for securing Web services within a wide variety of security models including PKI, Kerberos, and SSL. Specifically, this specification provides support for multiple security token formats, multiple trust domains, multiple signature formats, and multiple encryption technologies. The token formats and semantics for using these are defined in the associated profile documents.

This specification provides three main mechanisms: ability to send security tokens as part of a message, message integrity, and message confidentiality. These mechanisms by themselves do not provide a complete security solution for Web services. Instead, this specification is a building block that can be used in conjunction with other Web service extensions and higher-level application-specific protocols to accommodate a wide variety of security models and security technologies.

These mechanisms can be used independently (e.g., to pass a security token) or in a tightly coupled manner (e.g., signing and encrypting a message or part of a message and providing a security token or token path associated with the keys used for signing and encryption).”

Compression

The DATEX II protocol deals with critical information about traffic and travel data, and the community that use the protocol expect that DATEX II should be a reliable, robust platform that guarantees the exchange of the information independent of the amount of data. The transmission of traffic and travel data (ex. Measures or Elaborated Data) over XML can be in some cases very large, therefore it will take a lot of time or will spend a lot of bandwidth to deliver the information between a supplier and a client.

Using the HTTP protocol compression can help reduce the size of data on the transport. GZip is a standard and can be very easy to implement at the Application Layer of the Internet Protocol Suite by the Web Server supporting the HTTP protocol.

Definition (IETF - GZIP file format specification version 4.3 - http://tools.ietf.org/html/rfc1952): “The purpose of this specification is to define a lossless compressed data format that:

  • Is independent of CPU type, operating system, file system, and character set, and hence can be used for interchange;

  • Can compress or decompress a data stream (as opposed to a randomly accessible file) to produce another data stream, using only an a priori bounded amount of intermediate storage, and hence can be used in data communications or similar structures such as Unix filters;

  • Compresses data with efficiency comparable to the best currently available general-purpose compression methods, and in particular considerably better than the “compress” program;

  • Can be implemented readily in a manner not covered by patents, and hence can be practiced freely;

  • Is compatible with the file format produced by the current widely used gzip utility, in that conforming decompressors will be able to read data produced by the existing gzip compressor.”

E - Major Functional Exchange Profile FEP+E for Information Delivery

(informative)

In the following table a list of features available ( Y / N / Optional ) for major specific combination FEP+EP for the Information Delivery Business Scenario are listed. These features and requirement are combined to implement specific exchange environments:

  • Pub Sub

  • S Pull: Snapshot Pull

  • S Push: Snapshot Push

  • SP Push: Simple Push

  • SF Push: Stateful Push

Features Area

Feature

PubSub support

S Pull

S Push

SP

Push

SF Push

Requirement Name related

Requirement Type

Subscription Contract

Contract

N

N

N

N

N

Subscription

Information

Client profiles

Filter handling

Catalogue

N

N

N

N

N

Catalogue exchange

Information

Session

Session life cycle

Y

N

N

N

Y

Error handling

Communication

Timeout management

Session

Link Monitoring

Y

N

N

Y

Y

Error handling

Communication

Timeout management

Full reliability

Link monitoring and control

Information management

Operating modes

Y

Y

Y

Y

Y

Reference datasets for different versions

Information

Update methods

Y

Y

Y

Y

Y

Full audit trail data delivery (all state changes)

Information

Lifecycle management

Y

N

N

Y

Y

Support for lifecycle management

Information

Data delivery

Data delivery

Y

Y

Y

Y

Y

Extensibility

Information

Delivery/response

Communication

Message sequence

Snapshot data delivery (last known state)

Exchange quality measures (ex. response timestamp)

On occurrence update

Periodic update

Client identification

Security

Supplier identification

Incremental data delivery

Information

Data request

Y

N

N

N

N

Extensibility

Information

Request/response

Communication

Message sequence

Snapshot data delivery (last known state)

Exchange quality measures (ex. response timestamp)

On occurrence update

Periodic update

Client identification

Security

Supplier identification

Large datasets handling

Y

N

N

N

N

Data delivered as soon as possible

Information

Delayed delivery

Multi-part data delivery

Synchronisation

Y

N

N

O

Y

Synchronisation

Information

With state supplier

Communication

Failed data recovery

Self Description

handshake

Y

N

N

N

N

self description

Communication

Security

Y

Y

Y

Y

Y

Security (data)

Security

Integrity

Confidentiality

State the intended recipient

Client authentication

Supplier authentication

Client authorization

Non-repudiation

Compression

Y

Y

Y

Y

Y

Compression

Communication

Communication

Y

Y

Y

Y

Timely responses

Communication

F - Data Delivery background: stateless and stateful information and information lifecycle management

(informative)

Data related to the state of traffic related information are typically of 2 categories:

  • Stateless information / data, i.e. they represent quantitative0 measurement of some physical evidence, sampled at certain point in time and consists in the last available value for a measure. In case of a situation it can be considered the snapshot of situation evolution that has been sampled at a certain time.

  • Stateful information / data, i.e. they represent some information that is considered describing a status of the road that is persistent for some time when observed and this situation can evolve in time and will be updated according to information gathering process.

When Information is observed and/or measured at certain timestamps, this is considered as Sampled Information. In this case Information is sampled and its validity is referred at the sampling time and next sampling time will be considered completely new information.

image5

image6

Figure F.1 – Sampled Information

In other cases Information updates observed can be considered as valid from the time it has been observed till a new observation which can update it. This is the case for instance of a message displayed on VMS observed at any message update time, or a road situation which is structured as a complex set of data combined in Classed and Attributes as in Situation publication.

The latter case can be defined as Stateful Information. Even from Sample Data some processing can be implemented on these data to obtain information which can be considered valid and persistent for the road for a further period as an estimate ( e.g. measured or elaborated information such as individual vehicle or average speed, vehicle flow, road ground temperature or visibility, which values are between specified threshold).

Information gathered at first can be updated and keeps its relevancy to road status for some time until it ends.

image7

image8

Figure F.2 – Stateful Information

G - Collaborative ITS Services background

(informative)

Service Oriented vs. Information Delivery Oriented Information Exchange

The aim of Traffic areal time information exchange among Traffic Information and Traffic Control Centres are:

  • to inform the Traffic Control Centre Operators of the situation that is being taken in the near area in order to help evaluate and prevent impact that may affect its competence.

  • to request for information processing and delivery of services based on such exchanged information by the Client Centre, in order to support operational decisions and consequent implementation of operations and/or to inform drivers about safety and security behavior for drivers who are approaching a specific reported situation location.

    • Via broadcast and personalized Information channels (Radio, Bulletins, Call Centers, RDS-TMC Channel, web, etc.)

    • Via Variable Message Signs

The first case is the plain Information Delivery Business Case, in which the only scope is Data Delivery itself and any further processing objective consideration is out of scope. Data are delivered with only request to be received and in most of implementations they are only syntactically checked.

This communication model applies when a center can ignore for its objectives the final usage and processing outcomes which are derived from the information which is exchanged. This communication pattern has been fully addressed and described in Data Delivery communication pattern for DATEX II data exchange specification.

Considering the whole process chain to transfer information gathered from a system to another system, the data delivery section is contained in the chain from the information supplier to the receiver node of a DATEX II System

image9

Figure G.1 - Boundary of DATEX system boundaries in Centres Information Delivery Business case

The only objective of Data delivery is to monitor that information delivered has been received correctly by the Client.

Introducing MMI as Man-Machine Interface i.e. the TCC Management Systems used by the Operator the chain of information among all the systems may be described as follows

image10

Figure G.2 - Boundary of DATEX system boundaries in Centres Information Delivery Business case

Considering this framework, as specified in the latter case mentioned before, we can consider that Information is not exchanged with the simple aim of deliverying it to other centres for their internal usage, but with the scope it will be used at the centre to implement processing and further services to be consumed by other applications and systems.

To activate a processing based on those data information need to be checked and not only Syntactical but also Semanthic errors are relevant to the processing. Furthermore, Check and Processing Results, i.e. a Feedback, is fundamental.

In some use cases distributed processing and services have to be activated as a consequence of the validity of a certain information such as a Traffic Status or a High Impact Condition which is running on the road (e.g. Traffic Element, Road or Weather or Environmental condition). Management of such conditions by the Centres may imply the need for one or more operation to be executed (i.e. services) by several Traffic Management or Service Provider Centres, for instance based on predefined Traffic Mangement Plan which had been elaborated for such conditions. This can happen also in case of extraordinary needs due to unpredictable events occurring in the road network which can affect the road operations (such as major Events and Activities).

In this case a more complex workflows is implemented by the several nodes involved. The outcomes of proposal acknowledging, and operation implementing is needed to all involved nodes to have evidence of ongoing operations.

image11

Figure G.3 - Example of Collaborative ITS Services business case framework

Collaborative ITS Services” ( CIS ) explores the user requirements and common techniques to address the needs and implement collaborative services by centres and is based on exchanging information to be processed by other nodes and receive this processing outcomes ( Feedback), giving a base to build more sophisticated workflows enabling to coordinate distributed operation among multiple centres.

A “Collaboration Workflow” may be seen as a composition of one or more sequences of

  • Service Request ( based on exchanged Payload )

  • Processing Results ( Feedback )

among a pair or more of interoperating nodes.

These “Request and Feedback” brick sequences enable to set up a Workflow, where Application Level rules can be added in very structured configuration management

image12

Figure G.4 - Example of ITS collaborative services Workflow

In this vision DATEX Exchange acts as an Operational tool enabling to take shared decisions and implement and monitor shared actions by the CIS Collaborative Services Pattern which is described in the following chapters.

CIS and TMPlan Design

For Traffic Management Plan (TMPlan) definitions as well as design and operating concepts we refer to Easyway TMS Deployment Guideline ( ref. http://dg.easyway-its.eu/DGs2012 )

TMPlan may be seen in a more general vision as Road Network Configuration implemented by means of resources because of a Scenario which conditions the road network status. The management of TMP aims to improve the poorer status of the network (Level of Service - LOS) and achieve better Global and/or Local specific performances, which are based in term of Traffic Flow Enhancement, Safety and Security performance and Pollution reduction.

image13

Figure G.5 – Network Status (LOS) during Incidents and Conditions and TMPlan operating on Road Network

The figure describes operating TMPlan during time having Incidents or Road Conditions which impact on Road Network Level of Service, seen as a global indicator. Operating TMPlan management improves LOS and achieve better performances.

Extending TMPlan approach description, we may see any option for resource usage across the road network, such as commanding a Variable Message Sign or controlling a whole section of a Lane Control System as well as Traffic Lights in Urban Area, as a Service offered by a Road Operator or TCC Operator to improve the road network performance as specified above.

Based on experience about road conditions and frequency of situation occurring, Traffic Engineers may design solutions to cope with problems which frequently arouse in road operation. We can depict a CIS Design generalizing TMPlan design expressed in Easyway TMS DG, as shown in the following figure.

It starts with a description of the Business Scenario i.e. the road Incidents or Conditions which have impact on the road network that are to be managed, then defining the problem to which it is related which has to be solved by the resources owned or managed by several organization. After a Feasibility Study and subsequent discussion Traffic Engineers defines a CIS (TMPlan) Design to cope up with the problem, which describes the resource configuration options to be used. Sometimes more than one configuration is possible to achieve same result and this general result is named as Strategy . All possible Measure to realize a strategy are inventoried. That CIS Design then define a CIS Activation Contract which states all details and rules to exchange and make decision to operate the CIS (TMPlan).

image14

Figure G.6 – CIS (TMPlan) Analysis, Design, Implementation and Operation phases

At real time, Service Request for CIS Implementation will be exchanged, as well as Feedbacks, to set up the predefined needed resources configuration, i.e. Strategy activation and single Actions referred as each resource disposal by an organization.

Extending the TMPlan by CIS Concept we can figure out any resource configuration (VMS, LCS, Cameras, Traffic Lights, etc) as a specific request for Service to be activated by another Centre.

Strategies and relative Actions are concepts defined in Deployment Guidelines, triggering conditions means the road situation or data which requires the need for operating a TMPlan or in a general way a CIS.

During Operation, Request for Services are usually to be validated by the involved centres operators, so Standard Operation to implement CIS is based on 2 phases: CIS Agreement and CIS Execution, each of them is implemented by a Specific Service Request and the Execution is achieved after Agreement has been done. In case Agreement is not achieved for a known reason, which can and should fed back, the requester should evaluate how to deal and eventually ask for a different alternative CIS (as shown in Fig) or should evaluate the condition at a higher decisional level.

image15

Figure G.7 – two phases CIS operation

In simpler Service Request, such as VMS management for information only purposes, the CIS request may still be valid, even if it will be implemented only by some of the centres involved, and it will itself be operating the same way if any of other centre won’t execute such request. In these cases, the Agreement phase can be avoided and one phase Execution CIS can be implemented: one of these cases is VMS setting for Traffic Condition Information, i.e when there is no need for coordinated management but only information needs, any VMS setting implemented will improve the global service to road user, and no other management is needed in case for instance a VMS cannot represent this information for a fault or for higher priority information displayed on the requested VMS.

image16

Figure G.8 ** – CIS implementation workflow among a requester Centre and one to many Implementer Centres**

And we can see this in application of this workflow management for Traffic Management Plan

image17

Figure G.9 ** – TMPlan implementation phase description **

image18

Figure G.10 ** – Single TMPlan Measure implementation via Agreement and Implementation Phase**

CIS Implementation Patterns

As seen in the previous paragraphs Collaborative ITS Services in our vision is the availability, usage and shared management of ITS Services implemented by Centres distributed along the Road Network.

The following figure depicts a set of connected Centres, each of which exposes several services.

These services can be combined to implement CIS (/TMPlan) after the request of a Specific Requester Centre (red).

image19

Figure G.11 – CIS as shared distributed services availability and usage among Centres

In real life each Service is realised by its own customized interface, using each one proprietary parameters, datatypes, syntactical rules and semantical definitions. Each TCC ITS System implement many services that could even be accessed from remote to enable other Centres to use them after agreement, for realtime services, using these proprietary legacy interfaces, and even when implemented via standard interfaces as WebServices needs adjustment and agreement among centres to set appropriate parameters defining parameters values and semantics.

In the domain of Centre to Centre exchange, DATEX technology is used to uniform data and give shared syntactical check rules and semantic understanding, as well as common handshaking and behaviour for data exchange patterns and communication errors or network failures management.

Having this framework in mind we can see DATEX CIS as the usage of DATEX nodes as a data exchange interface to convey information to enable and control services, adapting the legacy protocols of individual clients and server legacy systems, and wrapping individual node services: i.e. DATEX nodes acting as gateways which wrap the heterogeneity of the several multi language and national legacy systems enabling interoperability and common strategies achievement.

image20

Figure G.12 – CIS by DATEX: nodes act as gateways wrapping individual centre complexity and adapting semantics to a standardized language and interface.

A Service interface may be realised exposing a “common general” Collaborative ITS Service interface through which a Service may be invoked by the node on the actual TCC Server (ITS System) and Payload(s) can be conveyed which will be processed by the invoked Service.

image21

Figure G.13 – CIS by DATEX: implementation though “webservices” call

First option for a service method interface:

image24

That could be used with conventional shared names services like “TMPlanService” or “Feedback”

image25

Further Option use for Request CIService passing the requested Service name as data in the Request Payload and for Feedback CISFeedback.

image26

It’s evident now that requesting for a Service done via the DATEX node is not directly invoking a Service on that ITS System but abstracting the operation of invoking service and demanding it to the DATEX node, having information or data parameters required for the service adapted by the DATEX node client gateway to the specific service parameters to the specific ITS System.

In this vision invoking a Service through DATEX can also be equivalent as conveying one or more DATEX payloads and invoking specific Services through their “ServiceName” and this means in DATEX II Information Delivery pattern conveying information and data through DATEX nodes. This implies that Information Delivery of Service Request Publication could be used to actually request for services, so the same interface and WS Notification can fully be used to convey payloads among DATEX II nodes for new Service Request and Service Scenario DATEX payloads.

Examples:

  • Requesting one or more centres to implement VMS Message sending situation record and asking it to be processed to address VMS messages based on predefined rules.

  • Requesting one or more centres to implement on some specific VMS specific messages explicitly conveyed through VMS Publication.

  • Requesting one or more centres to implement a specific Predefined TMPlan, sending a TMPlan Publication (or a more general CIS through CIS Service request Publication).

On the other way round, there is also the need for the Node Requesting the Service to be informed about the success or failure of the service request, i.e. a Feedback which also is information which can be exchanged by DATEX wrapped in a Feedback Publication.

Again, the Feedback may be seen as a return information from the CIService invocation or simply as a payload itself exchanged back from the Node executing the service.

As seen in the first paragraph showing the sequence Diagrams and all actors which need to be considered when a Service is to be implemented on exchange data, to have the overall Feedback of the Service Request implies the whole process to implement the Service is to be completed before receiving such feedback. In this case service invocation can only be synchronous, and some IT resources allocated by the Service Request will be locked while waiting for such process to be completed, and further Agreement phase normally implies human operator to take some manual actions and decisions.

During the service implementing phase some intermediate processing results could be be notified to the Requester, before the overall result would be achieved, giving evidence of progressive processing phase. It could be preferable to feedback soon the request about only syntactical check and receive other intermediate and final feedbacks based on the progressive evolution in the processing phases.

The situation can be expressed by the following figure:

image22

Figure G.14 – intermediate and overall processing feedback in a multi-phase implementation service.

Concurrency Policies

We have to consider a further question prior to think about any implementation / PSM solution to manage Collaborative ITS Services, which is the Concurrency Policies which runs and regulate the business cases.

Whenever we think of a Service as a Resource usage to some objective which is active and shared or notified by a Service Requester to a Service Implementer, we have to think about which kind of resource is this and how can be managed if some other requests get in concomitancy with the current one which corresponded to the first known one.

Whenever we have the need to allocate the same resource to different usage and use cases we have to consider concurrency policies which are to be observed. There are two main cases we consider:

  • First Come - First Served FIFO Police

Request for Services may be considered as they come, and there is a implicit lock of Resources for Booking, the resource is granted to the first request received.

As an example, we consider Car or Truck Parks booking in specific Parking Area, such as the case of Secure Parking Area for HGV. It implies guaranties for booked resource and Payment of fee to book which is lost or partially refunded if resource will not be used. Also there may be policies to release resources after a timeout period in case they will be not used and resource release will be allowed with partial or total refund within a certain amount of time.

In the figure below the use case is depicted which may be granted by a Booking and Payment Service provider which manages communication to Parking Service Providers implementing locking and releasing of resources after payment guarantee.

image23

Figure G.15 – CIS schema fo booking parking resources

  • Conditional Priority

Either when we think of Services as VMS displaying information Messages about Road Situations or Traffic Management Plans the rule to manage priority is totally different as a new situation may arise which is much more relevant to be displayed on VMS, or to be managed by TCC with a different Network Operation set leading to a completely different Scenario and TMP Management.

We call this Conditional Priority Policy when more Service Request could be received subsequently but a more recent one may have higher urgency, so that a First Request could be Rejected or Cancellation/Termination Requested after first Approval and the higher Impact TMP request due a more impacting situation should be served.

Depending on Concurrency Policy

  • First Come First Served: distribute transactions protocols are needed to ensure consistency and avoid conflicts. The field of application is related to payment and booking of resources which will be allocated and could be released under precise conditions such as:

    1. Parking Facilities

    2. Tunnel Slot Booking

    3. Alternative Path allocation per vehicle, for Dynamic Rerouting

    4. Special Path prescription / Specific Itinerary for HVG or Exceptional Load

  • Conditional Priority: several decision level could be implied, as well as Operator Decision based on rules or Decision Support System could be needed to evaluate priority and solve conflicts. In some cases conflicts could be managed at higher decisional hierarchy level. As a requirement need for Exchange there is a need to Manage Workflows enabling decision making and resume

H - Collaborative ITS Services Exchange Pattern

(informative)

Based on Data Delivery model and Annex G and after the previously reported consideration we may consider that we have several choices for the Service Request and Feedback Implementation (no Atomic Transaction needed).

1 - Fully Based on Information Delivery

  • CIS Service Request Publication Notified to CIS involved partner by Requester node

  • CIS Feedback Publication Notified to Service Requester by CIS involved Partners

    This pattern implies 2 one-way communication that could be based on data delivery business Scenario PIM

    • Agreement, when needed, and Execution delivered from CIS Requester to implied nodes

    • Feedback, other way round, from implied nodes to CIS Requester

This implementation of CIS Exchange can be implemented in currently available Data Delivery FEP and Exchange Pattern Platform based on modelling Service Requests and Feedback information as payload content.