ANNEX¶

A - Methodology presentation¶

(informative)

1. Introduction

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

2. 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 PIM defining content (e.g. of DATEX II);

• The exchange interoperability domain as reflected by this document.

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

3. Use case driven

One of the principles followed in this document 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 document for each of those Business Scenarios.

This led to the identification of two main business scenarios:

• Information Delivery;

• Collaborative ITS Services.

The information delivery business scenario addresses the exchange of traffic and travel information between two data exchange nodes, whereas the Collaborative ITS Services 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 scenarios into particular, more detailed use cases, each of which address 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 Collaborative ITS Services 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.

4. Functional Exchange Profiles

When analysing the business scenarios and requirements for this document, 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.

5. 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 document.

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, e.g. ISO 14823-3 defines such a mapping. 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 need to follow the same mapping. 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)

1. 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 (CIS) business 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

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

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

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

C - Basic Exchange Data Model and Data Dictionary¶

(informative)

1. Overall presentation

The described data model is based on a UML methodology that is independent from any technical platform.

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. The basic exchange data model describes the more common data needed to implement the exchange features supported by the different exchange patterns.

As in specific contexts, more than one information payload need to be exchanged, this model further allows to exchange multiple payloads based on such extra exchange requirements.

This model is suggested to implement minumum exchange information and to enable interoperability among exchange interfaces which implement the same exchange pattern, but may not be needed for specific simplified platform specific models implicitely assuming the few mandatory data defined in the model (e.g. supplier identification, protocol type, protocol version, exchange status).

2. Basic Exchange Data Model

Overview

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

Figure C.1 — The MessageContainer class diagram

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 error management.

• Information management related information.

• Collaborative ITS Services information.

Information management and CIS Information linked classes are optional, while minimum Exchange Information is to be managed e.g. to convey information about the used protocol and version and supplier identification as exchange responsibility. Other constraints on implementation depending on different FEP+EP which implement the exchange and its features, e.g. exchange dynamic information attributes will be mandatory in a FEP+EP which wants to implement session management, such as Stateful Push FEP+EP.

The MessageContainer class also allows conveying multiple payloads within a single exchanged message.

The ExchangeInformation class diagram

Figure C.2 — ExchangeInformation class diagram

Exchange Information is used to convey information about exchange environment such as:

• Exchange Context, which is implied by supplier and client(s) identification represented as exchange agent which may be associated to an external international identifier, the type of protocol which is defined to be used in exchanging data, the implemented version of this protocol, the operating mode and update method used in the data delivery exchange.

• Subscription with its period validity information and delivery frequence. An external enhanced validity may support more information such as recurring periodic validity for specific time intervals within specific days.

• Dynamic Information: such as exchange status and return status (within a set of predefined exchanged status and return status enumeration lists and their reason) and SessionID for exchange patterns which manages sessions. Sequencing number for synchronisation purposes and a Boolean information about payload completion enable large dataset handling features available in some exchange pattern.

• Return Information is used in return messages to convey a first information about information delivery and cis request exchange and also to send back special request to manage such as snapshot synchronisation.

Exchange context is mostly implicit in subscription contract but it is instantiated to simplify or enable application level check for some communication features such as supplier and client identification, authentication, authorisation, which can only be implemented in a reliable way based on communication layers.

In Dynamic information the attribute exchangeStatus is the only mandatory information, but as this status may be not managed its value can be set to “undefined”. Other information will be de facto mandatory whenever needed to be managed in specific FEP+EP, e.g. in case of session management feature implementation SessionID attribute in class SessionInformation will be needed to be managed.

The InformationManagement class diagram

Figure C.3 — InformationManagement class diagram

InformationManagement class allows delivering information management data: as defined in Annex F for life cycle information only valid information is managed in the payload, whenever an element ends its life cycle, i.e. being closed or cancelled, it is no longer 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 ElementReference class which allows identification of the element by its reference or versioned reference, specifying its managementStatus, i.e. closed or cancelled.

5. The CISInformation class diagram

Figure C.4 — The CISInformation class 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 between 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 longer needed.

Service Request can be related to a Service Condition through the ServiceCondition class identifying the needs 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 involved Service Providers needed to implement such request and the corresponding 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.

3. Data Dictionary Overview

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

For each package the following are successively provided:

1. The class table,

2. The association 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. Column 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:

4. 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:

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

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.

For association ends, 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.

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.

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

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

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

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

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

6. 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 C.6.

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

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

4. Data dictionary for Basic Exchange Data Model

InformationManagement for "ExchangeDataModel"

Location of "Classes" package

The location of the classes package is MessageContainer/InformationManagement/Classes

Classes of the "Classes" package

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

Associations of "Classes" package

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

Attributes of the "Classes" package

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

ExchangeInformation "Classes" package

InformationManagement for "ExchangeDataModel"

Location of "Classes" package

The location of the classes package is MessageContainer/ExchangeInformation/Classes

Classes of the "Classes" package

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

Associations of "Classes" package

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

Attributes of the "Classes" package

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

CISInformation "Classes" package

Location of "Classes" package

The location of the classes package is MessageContainer/CISInformation/Classes

Classes of the "Classes" package

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

Associations of "Classes" package

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

"Classes" package attributes

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

"Common" package

Location of "Common" package

The location of the Common package is MessageContainer/Common

Classes of the "Common" package

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

"Common" package external classes

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

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.

"MessageContainer" package

MessageContainer

"MessageContainer" package classes

Table C.12 — Classes of the “MessageContainer” package

Associations of "MessageContainer" package

Table C.13 — Associations of the “MessageContainer” package

"MessageContainer" package attributes

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

Data Dictionary of Enumeration for "ExchangeDataModel"

Introduction

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

The enumeration "ExchangeReturnEnum"

Enumeration that identifies the return status

Table C.14 — Values contained in the enumeration “ExchangeReturnEnum”

The enumeration "ExchangeStatusEnum"

Enumeration that identifies the status of exchange session

Table C.15 — Values contained in the enumeration “ExchangeStatusEnum”

The enumeration "InvalidityReasonEnum"

A list of possible invalidity reason for messages

Table C.16 — Values contained in the enumeration “InvalidityReasonEnum”

The enumeration "MessageTypeEnum"

The list of message type which can be implemented to define specifice exchange pattern features

Table C.17 — Values contained in the enumeration “MessageTypeEnum”

The enumeration "ServiceActionEnum"

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

Table C.18— Values contained in the enumeration “ServiceActionEnum”

The enumeration "OperatingModeEnum"

The enumeration of the possible operating mode which can be adopted in the exchange

Table C.19 — Values contained in the enumeration “OperatingModeEnum”

The enumeration "PredefinedServiceEnum"

List of predefined service requests

Table C.20— Values contained in the enumeration “PredefinedServiceEnum”

The enumeration "ProtocolTypeEnum"

A list of protocol type as possible exchange specification available

Table C.21 — Values contained in the enumeration “ProtocolTypeEnum”

The enumeration "ServiceActionEnum"

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

Table C.22 — Values contained in the enumeration “ServiceActionEnum”

The enumeration "ServiceActionStatusEnum"

Defines values of service status

Table C.23 — Values contained in the enumeration “ServiceActionStatusEnum”

The enumeration "UpdateMethodEnum"

The list of the possible operating method which are managed for exchange

Table C.24 — Values contained in the enumeration “UpdateMethodEnum”

Data Dictionary of <> for "ExchangeDataModel"

Overview

There are no specific data types defined in the “ExchangeDataModel”. However, different attributes are used and are on generic data types which are in principle defined in the content packages. They often map to intrinsic datatypes of PSM.

The data type "DateTime"

A combination of integer-valued year, month, day, hour, minute properties, a decimal-valued second property and a time zone property from which it is possible to determine the local time, the equivalent UTC time and the time zone offset from UTC.

The data type "MultilingualString"

A multilingual string, whereby the same text may be expressed in more than one language. If the data type is not implemented as such in the targeted PSM it may mapped to a String.

The data type "Reference"

A reference to an identifiable managed object where the identifier is unique. It comprises an identifier (e.g. GUID) and a string identifying the class of the referenced object.

The data type "String"

A character string whose value space is the set of finite-length sequences of characters. Every character has a corresponding Universal Character Set code point (as defined in ISO/IEC 10646), which is an integer.

The data type "VersionedReference"

A reference to an identifiable version managed object where the combination of the identifier and version is unique. It comprises an identifier (e.g. GUID), a version (NonNegativeInteger) and a string identifying the class of the referenced object.

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 data exchange 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 the data exchange protocol 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

Overall presentation

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:

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

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 dataexchange 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 denysomething. 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

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

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.

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

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

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.

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

** “Collaborative ITS Services” ** (CIS) explore user requirements and common techniques to address the needs and implement collaborative services by centres and they are based on exchanging information to be processed by other nodes and receiving the processing outcomes (feedback), giving a base to build more sophisticated workflows enabling to coordinate distributed operations 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

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 (TMP) definitions as well as design and operating concepts it is referred to the TMS Deployment Guideline (ref. http://dg.its-platform.eu/DGs2012 )

TMP may be seen in a more general vision as a road network configuration implemented by means of resources because of a scenario which conditions the road network status. The management of a TMP aims to improve the worsened 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.

Figure G.5 describes operating TMP during time having Incidents or Road Conditions which impact on road network level of service, seen as a global indicator. Operating TMP management improves LOS and achieve better performances.

Key

Figure G.5 — Network status (LOS) during incidents and conditions with TMP operating on road network

When extending TMP approach description, any option for resource usage across the road network can be seen, such as commanding a Variable Message Sign or controlling a whole section of a Lane Control System as well as traffic signals in urban areas, 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 occurring situation frequency, traffic engineers may design solutions to cope with problems that frequently arise in road operation. A CIS design can be depicted as generalizing the TMP design expressed in EasyWay TMS DG, as shown in Figure G.6.

It starts with the description of the business scenario, i.e. the road incidents or conditions which impact the road network to be managed, then by defining the problem to which it is related and which has to be solved by the resources owned or managed by several organisations. After a feasibility study and subsequent discussion traffic engineers define a CIS (TMP) design to tackle the problem, with the resource configuration options to be used. Sometimes more than one configuration is possible to achieve the same result and this general result is named as strategy. All the possible measures to realise a strategy are inventoried. That CIS design then defines a CIS Activation Contract which states all the details and rules to exchange and make decision to operate CIS (TMP).

Figure G.6 — CIS (TMP) analysis, design, implementation and operation phases

At real-time, a service request for CIS implementation will be exchanged, as well as feedbacks, to set up the predefined configuration of needed resources, i.e. strategy activation and single actions referred as well as the resource disposal by an organisation.

Extending TMP by the CIS concept any resource configuration (VMS, LCS, CCTV, traffic signals, etc) can be meant as a specific request for service to be activated by another centre.

Strategies and relative actions are concepts defined in Deployment Guidelines, triggering conditions mean the road situation or data which requires the need for operating a TMP or in a more general way CIS.

During operation, requests for services are usually to be validated by the involved centre operators, so a 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 the agreement is not achieved for a known reason, which can and should be fed back, the requester should evaluate how to deal with and possibly ask for a different alternative CIS (as shown in Figure G.6) or should evaluate the condition at a higher decisional level.

Figure G.7 — Two-phase CIS operation

In a simpler service request, such as VMS management for only information 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 another centre does not execute such a request. In this case 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 for information needs, any VMS setting implemented will improve the global service to road users, and no other management is needed in case, for instance, a VMS cannot represent this information due to a fault or because higher priority information is displayed on the requested VMS.

Figure G.8 — CIS implementation workflow with a requester centre and implementer centres

This can be seen in application of this workflow management for Traffic Management Plan.

Figure G.9 — TMP implementation phase description

Figure G.10 — Single TMP measure implementation via agreement and implementation phases

CIS Implementation Patterns

As seen in the previous paragraphs Collaborative ITS Services in this presentation is the availability, usage and shared management of ITS services implemented by centres distributed along the road network.

Figure G.11 depicts a set of connected centres, each of which exposes several services.

These services can be combined to implement CIS (through TMP) after the request of a specific requester centre (in red).

Figure G.11 — CIS as shared distributed services availability and usage among centres

In real life each service is realised by its own customised interface, using each one proprietary parameters, datatypes, syntactical rules and semantic definitions. Each TCC ITS system implements many services that could even be accessed remotely to enable other centres to use them after agreement, for real-time services. Using these proprietary legacy interfaces, and even when implemented via standard interfaces as web services adjustment and agreement are needed among centres to set appropriate parameters for defining parameters values and semantics.

In the domain of Centre-to-Centre exchange, data exchange technology is used to standardise 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.

In this framework CIS data exchange can be seen as the usage of exchange 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. nodes acting as gateways which wrap the heterogeneity of several languages, and national legacy systems enabling interoperability and common strategies achievement.

Figure G.12 — CIS by data exchange: nodes act as gateways wrapping individual centre complexity and adapting semantics to a standardised 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 of the actual TCC server (ITS system) and payload(s) can be conveyed which will be processed by the invoked service.

Figure G.13 — CIS by data exchange: implementation through “web services” call

First option for a service method interface:

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

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

Obviously requesting for a service via the exchange node is not directly invoking the service on that ITS system but abstracting the operation of invoking service and demanding it through the exchange node, having information or data parameters required for the service, adapted by the exchange node client gateway to the specific service parameters of the specific ITS system.

Thus invoking a service through exchange can also be equivalent as conveying one or more exchange payloads and invoking specific services through their “ServiceName” and this means in this case information delivery pattern conveying information and data through exchange 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 exchange nodes for new service requests and service scenario exchanged 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).

In the other direction, 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 that can be exchanged using exchange nodes wrapped in a feedback publication.

Again, the feedback can be seen as a return information from a CIS invocation or simply as a payload itself exchanged back from the node executing the service.

As seen in G.1 showing the sequence diagrams and all actors 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 needs 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 notified to the requester, before the overall result is achieved, giving evidence of progressive processing phase. It is better to quickly feed the request back about only syntactical check and send other intermediate and final feedbacks based on the progressive evolution in the processing phases.

The situation can be expressed by the following Figure G.14:

Figure G.14 — Intermediate and overall processing feedback in a multiphase implementation service

Competition policies

A further question to consider prior to thinking about any implementation/PSM solution for managing Collaborative ITS Services, is competition policies which run and regulate the business cases.

Whenever a service is designed as a resource usage to some objective which is active and shared or notified by a service requester to a service implementer, it is necessary to think about this kind of resource and how it can be managed if some other requests get concomitantly with the current one which is first known.

Whenever there is a need to allocate the same resource to different usages and use cases consider competition policies to observe are to consider. There are two main policies:

• First Come - First Served (FIFO) policy

Request for services may be considered as they come, and there is an implicit lock of resources for booking, the resource is granted to the first request received.

An example of such is about car or lorry parks booking in a specific parking area, like secure parking areas for HGV. It implies guaranties for the booked resource and the payment of a fee to book, lost or partially refunded if the resource is not used. There may also be policies to release resources after a timeout period in case they are not used and the resource release is allowed with a partial or total refund within a certain amount of time.

In Figure G.15 the use case is depicted in which a request can be granted by a booking and payment service provider which manages communication to parking service providers implementing the locking and releasing of resources after payment guarantees.

Figure G.15 — CIS schema for booking parking resources

• Conditional priority

Either when considering services as VMS displaying information messages about road situations or Traffic Management Plans the rule to manage priority is different as a new situation may arise that 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.

This conditional priority policy is considered when several service requests are received subsequently and a more recent one may have higher urgency, so that the first request is rejected or its cancellation/termination requested after a first approval and the higher-ranked TMP request due to a more impacting situation needs to be served.

Depending on the competition policy

• First Come First Served: distributed 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 HGV or abnormal indivisible goods.

• Conditional priority: several decision levels can be implied, as well as an operator decision based on rules or Decision Aiding System may be needed to evaluate priority and solve conflicts. In some cases, conflicts are managed at a higher decisional level. As a requirement need for exchange there is a need to manage workflows enabling decision making and resuming.

H - Collaborative ITS Services Exchange Pattern¶

(informative)

Based on data delivery model and Annex G and after the previously reported consideration one may consider that several choices exist for the service request and feedback implementation (no atomic transaction needed).

It is 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 communications 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.