d2.3 movesmart technical specificationsmovesmartfp7.iti.gr/movesmartfp7/wp-content/... · in this...

FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART

D2.3: of 73

Renewable Mobility Services in Smart Cities

FP7 ‐ Information and Communication Technologies

Grant Agreement No: 609026 Collaborative Project

Project start: 1 November 2013, Duration: 36 months

D2.3 MOVESMART Technical Specifications

Work package: WP2 – User Requirements and System Architecture Due date of deliverable: 31 August 2014Actual submission date: 10 September 2014Responsible Partner: CTI Contributing Partners: CERTH, FLEX, KIT, MLS, UD

Nature: Report Prototype Demonstrator Other Dissemination Level: PU : Public PP : Restricted to other programme participants (including the Commission Services) RE : Restricted to a group specified by the consortium (including the Commission Services) CO : Confidential, only for members of the consortium (including the Commission Services) Keyword List: Technical Specifications, Software and Hardware requirements, Service Communication

The MOVESMART project (http://www.movesmartfp7.eu) is funded by the

European Commission, Information and Communication Technologies, Snart Cities and Communities (FP7‐SMARTCITIES‐2013), under the FP7 Programme.


D2.3: of 73

The MOVESMART Consortium

Ayuntamiento de Vitoria‐Gasteiz (coordinator), Spain

Asociacion para la Promocion de la Innovacion Denokinn, Spain

Centre for Research and Technology Hellas / Information Technologies Institute, Greece

Computer Technology Institute & Press “Diophantus”, Greece

Karlsruher Institut für Technologie / Institute of Theoretical Informatics

Universidad de la Iglesia De Deusto, Energy Unit, Spain

South West College, UK

Grad Pula ‐ Pola, Croatia

Going Green SL, Spain

MLS Multimedia SA, Greece

Flexiant Limited, UK


D2.3: of 73

Document history

Version Date Status Modifications made by

0.1 05.07.2014 First Draft with ToC, initial content and assigned responsibilities

S. Kontogiannis (CTI)

0.2 31.07.2014 Second Draft with partial contributions

C. Zaroliagis, D. Gavalas, A. Paraskevopoulos, S. Kontogiannis, G. Papastavrou (CTI), A. Gemsa, M. Baum (KIT), K. Genikomsakis (UD).

0.3 14.08.2014 First version with input consolidated by all contributing partners

D. Kehagias (CERTH), A. Stavridis (MLS),K. Hughes, C. Sheridan, T. Sharif (FLEX)

0.4 09.09.2014 Final version sent to coordinator and reviewers

S. Busturia (AVG), D. Kehagias (CERTH)

0.5 10.09.2014 Reviewed by evaluators D. Kehagias (CERTH)

0.6 10.09.2014 Reviewer Comments incorporated ‐ Final approval after quality check performed by the Quality Board

D. Kehagias (CERTH)

1.0 10.09.2014 Final version submitted to EC S. Busturia (AVG)

2.0 20.01.2015 Y1 review comments incorporated

S. Kontogiannis (CTI)

2.1 29.01.2015 Peer‐Review comments on revised version incorporated and submitted to PQB for final review

S. Kontogiannis (CTI) Peer Reviewers: Dionisis Kehagias (CERTH) and Sandra Busturia (AVG)

2.2 30.01.2015 Comments of PQB incorporated, submitted to project coordinator

Spyros Kontogiannis (CTI) PQB Reviewers: Andreas Gemsa (KIT) and Darren Whigham (FLEX)

Deliverable manager Spyros Kontogiannis (CTI)

List of Contributors Christos Zaroliagis (CTI) Damianos Gavalas (CTI) Andreas Paraskevopoulos (CTI) Spyros Kontogiannis (CTI) Georgia Papastavrou (CTI) Andreas Gemsa (KIT) Moritz Baum (KIT) Dionisis Kehagias (CERTH) Adamantios Stavridis (MLS) Katrina Hughes (FLEX) Craig Sheridan (FLEX) Tabassum Sharif (FLEX) Konstantinos Genikomsakis (UD)

List of Evaluators


D2.3: of 73

Sandra Busturia (AVG) Dionisis Kehagias (CERTH)

Executive Summary The present deliverable is the outcome of T2.3, and classifies various system requirements from a technical and implementation perspective. It provides a high‐level sketch of dependencies among different service modules of the framework (e.g. local device data, crowd‐sourcing mechanisms, urban traffic knowledge base, individual components interfaces, etc.) and describes in detail the constraints of the system elements in terms of hardware and/or software resources, compatibility with standards, etc. Hence, a set of appropriate technologies is proposed for the realisation of both software and hardware MOVESMART infrastructure aspects.

This service‐oriented representation of the MOVESMART concept will be the basis of the forthcoming detailed architectural design of the entire MOVESMART system.


D2.3: of 73

Table of Contents

1 Introduction ............................................................................................................... 6

2 Modular Representation of MOVESMART System ...................................................... 7

3 Classification of Service Features within Modules ...................................................... 8 3.1 Cloud Management Module ............................................................................................... 8

3.1.1 Profiles Management ............................................................................................. 8 3.1.2 Entity Monitoring ................................................................................................. 10 3.1.3 Traveller Incentivising & Rewarding .................................................................... 12

3.2 Core‐Traffic Services ......................................................................................................... 13 3.2.1 Traffic Prediction .................................................................................................. 13 3.2.2 UTKB Management .............................................................................................. 15 3.2.3 Crowd‐sourcing .................................................................................................... 17 3.2.4 Traffic Management ............................................................................................ 22

3.3 Integrated Personal Mobility Applications Module .......................................................... 33 3.3.1 MOVESMART Connect / Disconnect Client .......................................................... 33 3.3.2 Renewable MOD Services .................................................................................... 33 3.3.3 Park & Ride Client ................................................................................................ 47 3.3.4 Messenger ............................................................................................................ 56 3.3.5 Mobile Device API ................................................................................................ 58

4 Infrastructural & Data Format Specifications ............................................................ 66 4.1 Hardware Requirements ................................................................................................... 66 4.2 Software Requirements .................................................................................................... 68 4.3 Supported Data Formats ................................................................................................... 69

4.3.1 Raw Data Formats ................................................................................................ 69 4.3.2 Traffic Metadata Formats .................................................................................... 72

5 Dependencies among Services ................................................................................. 73

6 Conclusions .............................................................................................................. 73


D2.3: of 73

1 Introduction

The main objectives of WP2 are:

To precisely define the MOVESMART target user groups and involved stakeholders.

To specify the user functional requirements and extract the MOVESMART use cases.

To draw necessary technical specifications for the design of the envisaged technical solutions.

To conceptually design the system architecture.

The present deliverable is the outcome of task T2.3 which, starting from the conceptual and functional design done in task T2.1, produced detailed technical specifications for the development of the envisaged route planning applications, as well as for their harmonisation and integration in the MOVESMART urban traffic knowledge base, to validate the final performance of all sub‐systems. Task T2.3 was based upon User Requirements Specification (T2.1) and Use Cases Analysis (T2.2), mostly focusing on the identification and specification of those MOVESMART architecture’s technical aspects that are necessary for the realisation of the extracted use cases in accordance with the functional requirements. In this task the specifications of the key components and their functionalities are derived. Specifically, the Technical Specifications of the MOVESMART subsystems and modules are defined.

The present deliverable is the outcome of T2.3, and classifies various system requirements from a technical and implementation perspective. It provides a high‐level sketch of dependencies among different parts of the framework (e.g. local device data, crowd‐sourcing mechanisms, urban traffic knowledge base, individual components interfaces, etc.) and describes in detail the constraints of the system elements in terms of hardware and/or software resources, compatibility with standards, etc. Hence, a set of appropriate technologies is proposed for the implementation of both software and hardware MOVESMART infrastructure aspects.


D2.3: of 73

2 Modular Representation of MOVESMART System

This section describes a detailed breakdown of the MOVESMART system into modules, sub‐modules and services. In the diagram shown in Figure 1, the identified modules of the MOVESMART system are drawn as boxes, containing smaller dashed‐line boxes representing sub‐modules, and shapes representing services. Some services are not contained in sub‐modules, and may themselves be considered as sub‐modules as well (containing a single service). The modules that comprise the MOVESMART system are the following:

1. Cloud Management Module. This module is responsible for: (i) maintenance of entity profiles within the MOVESMART system, be it travellers, vehicles or services; (ii) monitoring of entity mobility and availability and current status, upon their connection to the system; (iii) management of transactions of bonus‐points among entities (e.g., transfer of bonus points from the Vehicle Relocation service to a traveller willing adopt the “good practice” of leaving the electric vehicle (EV) to a high‐demand‐low‐availability parking, on behalf of the service); (iv) security and anonymisation service, to protect the privacy of the connected travellers when requesting specialised services which require personal information such as current location, destination, MOVESMART ID, etc.

2. Data Communication Interface Module. This module is responsible for: (i) Digestion of data from external resources, and their propagation to any requesting module in particular data formats. (ii) Maintenance in the UT‐Cloud, and periodic synchronisation with the local snapshots kept in the travellers’ devices, of traffic metadata that are created by the corresponding UTKB management service.

3. Core Traffic Services Module. This module is responsible for the following traffic‐related functionalities, meant to be supported by the MOVESMART system: (i) Crowd‐sourcing, which will gather periodic or instantaneous traffic‐related reports, and after assessing their importance, will propagate them accordingly to the appropriate services for further actions; (ii) Traffic prediction, which will exploit the periodic traffic reports in order to perform prediction of the traffic status for a short or medium term period and for a given urban area of interest. (iii) UTKB management, which will be responsible for updating the traffic metadata kept in the UT‐Cloud by the Data Communication Module, based again on the periodic traffic reports. (iv) Traffic management, which is responsible for providing TD routes for a single or multiple modes of transportation, based on varying route optimisation criteria; assessment of the energy‐efficiency of the provided routes; Relocation of fleets of EVs and/or bicycles among parking places, in order to assure continuous availability.

4. Integrated Personal Mobility Applications Module. This module contains all the client‐side applications, residing in the travellers’ devices, such as personal navigation devices (PND) and/or smartphones, which are responsible for: (i) connecting to the MOVESMART system and accessing / modifying the personalised user profiles; (ii) providing advanced MOD services, based on specialised optimisation criteria based on the traveller’s profile; and (iii) providing Park & Ride services to the travellers. It also supports the periodic synchronisation with the Data Communication Interface Module, of locally held traffic‐metadata snapshots, so that a minimal level of operation can be guaranteed, despite a temporal loss of connection to the MOVESMART system.

Modules 1‐3 comprise the subsystem of MOVESMART, which will reside on the UT‐Cloud. Module 4 is the end‐user integrated platform of MOVESMART, which will reside on the portable devices (PNDs and/or smartphones).


D2.3: of 73

Figure 1: Breakdown of MOVESMART system into Modules, Sub‐modules and Services.

3 Classification of Service Features within Modules

3.1 Cloud Management Module

3.1.1 Profiles Management

Entity (user / vehicle / service) Profile Creation and Management

This service implements the management of profiles for all possible entities, be it travellers, vehicles, or services, involved in the MOVESMART system. Name: Entity (user/vehicle/service) Profile Creation & Management.

Type: Service

Container: Profiles Management

Functionality: Creates and manages profiles for all entities, including users and vehicles

Connections: Entity Monitoring, Traveller Reporting, Security & Anonymity Gateway

Relevant Use Cases: UC1.1, UC1.7, UC1.8, UC1.10, UC1.11, UC1.12, UC1.14, UC2.6, UC2.7, UC3.2, UC3.3, UC3.4, UC3.6, UC3.7, UC3.8, UC3.9

INPUT PARAMETERS

Name Data Type Cardinality Source Description

UUID String 1 Security & Anonymity Gateway

Unique identifier for each user of the

platform to identify and verify them.

Password String 1 Security & An encrypted


D2.3: of 73

Name: Entity (user/vehicle/service) Profile Creation & Management.

Anonymity Gateway

password to allow users to be

authenticated.

OUTPUT PARAMETERS

Name Data Type Cardinality Destination Description

Entity Type String 1 User Profile Management

Identification of the type of profile, user/vehicle

User details Complex 1 User Profile Management

Contact information on the user such as name, address, phone number

Billing Data Complex 1 Service Profile Management

Billing details to allow charges to be made

to the user

Bonus Complex 1 User Profile Management

Information on any bonus achieved by

the user

Rank String 1 User Profile The positioning within a ranking system for a user

Location Complex 1 User/Vehicle Profile

Management

Information on the current location of a

user or vehicle

Vehicle Status String 1 Vehicle Profile Management

Information on whether the vehicle is

ready for booking/reserved/out

of service

Vehicle Condition Complex 1 Vehicle Profile Management

Information on any maintenance

required for the vehicle

Security And Anonymity Gateway

The purpose of this service is to guarantee the anonymity of the travellers when requesting personalised information by other services, and the privacy of their own profiles and their activities (e.g., their actual mobility) within the MOVESMART system. Name: Security and Anonymity Gateway

Type: Service

Container: Profiles Management

Functionality: It provides an authentication barrier between the public Internet and the private SQL databases which will hold the data for the resources.

Connections: Data Communication Interface Module, Infrastructure Reporting, Traveller Reporting, Profiles Management, Crowd‐sourcing

Relevant Use Cases: UC3.3, UC3.4, UC3.5, UC3.6, UC3.9,

INPUT PARAMETERS



D2.3: of 73

Name: Security and Anonymity Gateway

UUID String 1 Data Communication

Interface Module,

Infrastructure Reporting, Traveller Reporting, Profiles

Management, Crowd‐sourcing,

The unique anonymous user id of the user who sends data.

Password String 1 As above An encrypted password that the users use in order to authenticate themselves.

Location Complex 1 As above An object containing

information about the user current

location.

OUTPUT PARAMETERS


Access Details Complex 1 Profiles Management,

Detailing if the access has been authorised.

3.1.2 Entity Monitoring

Traveller Monitoring

This service will support the monitoring of various events on behalf of the traveller, so that other services can provide personalised information (e.g., alternative routes on demand, broadcasting of real‐time traffic incidents relevant to the traveller’s route, etc) without having direct access to the traveller’s profile. For example, the traveller may allow other services to access his own current GPS location upon request, via an appropriate attribute in his profile and a periodic tracking of his location, not by this service but by the Traveller Monitoring service. Name: Traveller Monitoring

Type: Service

Container: Entity Monitoring

Functionality: Monitors events on behalf of the traveller to provide information for other services to allow determination of routes.

Connections: Profile Management, Traveller Reporting, Core Traffic Services Module, Renewable Mobility on Demand

Relevant Use Cases: UC1.1, UC1.4, UC1.5, UC1.8, UC1.9, UC1.10, UC1.11, UC1.12, UC3.2, UC3.6, UC3.7, UC3.8,

INPUT PARAMETERS


UUID String 1 Profile Unique identifier


D2.3: of 73

Name: Traveller Monitoring

Management for a user

OUTPUT PARAMETERS


Location Complex 1 Traveller Reporting, Core Traffic Services

Module, Renewable Mobility on Demand

Information on the travellers current

location

Traveller Data Speed Complex 1 As above Information on the travellers current speed at location

Vehicle Availability

This service will support the location of available EVs or bicycles in the vicinity of a particular GPS location. Therefore, access rights to the profiles of the corresponding vehicles’ profiles will be provided to this service, which in turn will respond to requests of other, traffic‐related services, for available vehicles, in real‐time. Name: Vehicle Availability

Type: Service


Functionality: Provide information on the location and availability of vehicles

Connections: Profiles Management, Core Traffic Services Module, Park & Ride, Security & Anonymity Gateway, Traffic Management.

Relevant Use Cases: UC1.10, UC1.13, UC2.1, UC2.4

INPUT PARAMETERS


UUID String 1 Profile Management, Security & Anonymity Gateway

Unique identifier of an entity to verify

access right

Password String 1 As above Encrypted password to verify

entity is valid

OUTPUT PARAMETERS


Vehicle Status String 1 Vehicle Reservation &

Billing, EV/Bicycle Availability

Shows availability status of any given

vehicle

Vehicle Location Complex 1 Traffic Management

Information on the GPS location of a

vehicle


D2.3: of 73

Vehicle Reservation & Billing

This service will support the reservation & billing functionalities of particular vehicles, as requested by the owning traffic‐related services. This implies that the status of the corresponding vehicle will be changed to RESERVED for a particular time‐interval, and the corresponding bonus‐transaction from the requesting traveller to the owing traffic‐service will be implemented, in a way that is transparent to both. Name: Vehicle Reservation & Billing

Type: Service


Functionality: Allows reservation of vehicles and addition of bonuses to users

Connections: Profiles Management, Traffic Management, Traveller Incentivising & Rewarding, Security & Anonymity Gateway

Relevant Use Cases: UC1.10, UC1.12, UC1.14, UC2.1, UC2.2, UC2.3

INPUT PARAMETERS



Unique identifier of an entity to verify

access right

Password String 1 As above Encrypted password to verify

entity is valid

Reservation Request String 1 Vehicle Reservation &

Billing

Request to hold a specified vehicle for

use.

OUTPUT PARAMETERS


Vehicle Status String 1 Profiles Management

Changing of vehicle status if reservation

is approved.

Billing Cost Complex 1 Profiles Management,

Vehicle Reservation &

Billing

Cost associated with the

reservation period for users journey.

Bonus Entitlement Complex 1 Profiles Management,

Traveller Incentivising & Rewarding

Any bonuses which the user has

accrued from this journey.

3.1.3 Traveller Incentivising & Rewarding

This service will support the mere bonus‐transaction among entity profiles, upon request of the debtor. The transaction will be implemented from the debtor (e.g., the rewarding traffic‐related service) to the creditor, in a way that is transparent to both entities, by the cloud‐management service itself. The actual policy for providing incentives is an endogenous process of the debtor, and is transparent to the Traveller Incentivising & Rewarding service. Name: Traveller Incentivising & Rewarding

Type: Service



D2.3: of 73

Name: Traveller Incentivising & Rewarding

Functionality: This service relates to the addition of bonus transactions to user profiles.

Connections: Profiles Management, Entity Monitoring, Security & Anonymity Gateway, Vehicle Reservation & Billing

Relevant Use Cases: UC1.14, UC1.15, UC2.3

INPUT PARAMETERS



Unique identifier for a resource in this instance the user profile.

Bonus Type String 1 Vehicle Reservation &

Billing

Bonus type credit or debit for accounts

Bonus Amount Complex 1 Vehicle Reservation &

Billing

Size of bonus

OUTPUT PARAMETERS


Bonus Account Status Complex 1 Entity Monitoring, User Profile Management

Updated status of bonus account after bonus transaction.

3.2 Core‐Traffic Services

3.2.1 Traffic Prediction

This service performs prediction of the traffic status for a short term period (5 minutes to 1 hour) and for a given urban area. Alternatively, it reports on the current traffic status, when no prediction is requested. Name: Traffic Prediction Type: Service Container: Core Traffic Services Module Functionality: Performs a short‐term (5 minutes to 1 hour ahead) prediction of

traffic status. Connections: Data Communication Interface Module, Infrastructure

Reporting, Crowd‐sourcing (Periodic Reports Push), Traffic Management, UTKB Management.

Relevant Use Cases: UC1.2, UC1.4, UC1.5, UC1.6, UC1.7, UC1.8, UC1.9, UC1.10, UC1.11, UC1.12, UC3.1, UC3.2, UC3.3, UC3.5, UC3.6, UC3.10, UC3.11.

INPUT PARAMETERS

Name Data Type Cardinality Source Description GetTrafficPredictionRequest Complex 1 Renewable

Mobility on demand, Traffic Management,

Data Communication

A complex object for predicted traffic

information. It provides values for parameters such as

the user’s GPS


D2.3: of 73

Name: Traffic Prediction

Interface Module

coordinates and bounding box.

GetTrafficPredictionRequest.road Complex 1 As above An object that represents the road to which the traffic forecasting refers.

GetTrafficPredictionRequest.city String 1 As above The name of the city in which the user is travelling.

GetTrafficPredictionRequest.country String 1 As above The name of the country to which the city belongs.

GetTrafficPredictionRequest. timeInMinutes

int 1 As above The prediction time in minutes (from the current time

ahead).

GetTrafficPredictionRequest.time int 1 As above The current time in milliseconds.

GetCurrentTrafficRequest Complex 1 As above A complex object that describes current traffic information. It

provides values for parameters such as

the user’s GPS coordinates and bounding box.

GetCurrentTrafficRequest.road Complex 1 As above An object that

represents the road to which the traffic forecasting refers.

GetCurrentTrafficRequest.city String 1 As above The name of the city in which the user is travelling.

GetCurrentTrafficRequest.country String 1 As above The name of the country to which the city belongs.

OUTPUT PARAMETERS

Name Data Type Cardinality Destination Description TrafficReport Complex 1 As above A complex object

including all information about predicted/current traffic, encoded

within subsequent complex objects.

TrafficReport.trafficStatus Complex 1..n As above A complex object that describes

predicted/current traffic.

TrafficReport.trafficStatus.trendType enumeration 1..n As above The type of traffic


D2.3: of 73

Name: Traffic Prediction

trend (e.g. traffic Building Up, slowing down, being stable).

TrafficReport.trafficStatus.value Enumeration 1..n As above Gets one of: “impossible”, “heavy”,

“congested”, “freeFlow”, “unknown”.

TrafficReport.trafficSpeedRecord Enumeration 1 As above A complex object including traffic prediction related

information.

TrafficReport.trafficSpeedRecord. timeStamp

int 1 As above The time stamp in msec of the

predicted/real traffic.

TrafficReport.trafficSpeedRecord. velocity

double 1 As above The value of predicted/real velocity in kmph

that corresponds to this traffic report.

TrafficReport.trafficSpeedRecord. roadID

int 1 As above The road id, to which this traffic report refers.

TrafficReport.hasRoadWorks Complex 1..n As above An object that describes possible

road works occurring on the reference road.

3.2.2 UTKB Management

This service performs the creation and maintenance of traffic‐related metadata, to be exploited by specialised route planning and mobility‐on‐demand services supported by the MOVESMART system. It also creates and maintains periodically snapshots of the current traffic status, to be used for synchronisation with the local snapshots held by the travellers’ devices so as to assure a minimum level of service even without connection to the MOVESMART system. Name: UTKB Management Type: Service Container: Core Traffic Services Module Functionality: Traffic data management Connections: Crowd‐sourcing Sub‐module (Periodic Reports, Post Route

Reports, Emergency Push Services), Traffic Prediction Service, Infrastructural Reporting Sub‐module (Weather Forecasting Service), Historic TD Traffic Data Repository Sub‐module, PND Cached Replica of Historic TD Traffic Data Sub‐module

Relevant Use Cases: UC3.3, UC3.5, UC3.6, UC3.7 INPUT PARAMETERS

Name Data Type Cardinality Source Description RouteResponse complex 1 Periodic A complex route


D2.3: of 73

Name: UTKB Management

ReportsPush

response object to time dependent

route queries listing one (or several)

routes

RouteResponse. routeInfo

complex 1 PeriodicReports Push

A complex route response object that

holds key information about

the computed routes (total distance, estimated travel time and fuel

consumption, eco‐friendliness etc.)

RouteResponse. recordedInfo

complex Post‐Route Reports Push

A complex route response object that holds the real‐time evaluation of the computed routes

(actually travel time, fuel consumption

etc.)

RouteRating complex 1 Post‐Route Reports Push

A complex rate response object that indicates the user review for the provided routes

RouteRating.like Boolean

1 Post‐Route Reports Push

A like/dislike answer from user for the provided routes

RouteRating.feedback string 1 Post‐Route Reports Push

A detailed review from user for the provided routes

TrafficUpdateRequest complex 1 Traffic Prediction

Periodic Reports Push

A complex update request on traffic

history data and the current traffic status (e.g. redefining the underestimated delays during a traffic congestion due to accidents or

road works)

PublicTransportUpdateRequest complex 1 Traffic Prediction


A complex update request on timetable fleet transportation information (such as vehicle delays, route changes, station closures, etc.,

together with the associated time horizon of the


D2.3: of 73

Name: UTKB Management

change)

WeatherInfoUpdateRequest complex 1 Weather Forecasting

A complex update request on weather info for a specific location and time‐

date

RoadWorkInfoUpdateRequest complex 1 Emergency Push

A complex update request for road works at a given location and time

AccidentInfoUpdateRequest complex 1 Emergency Push

A complex update request for accidents at a given location

and time

OUTPUT PARAMETERS

Name Data Type Cardinality Destination Description SetRoutePenalty complex 1 Historic TD

Traffic Data A complex update on TD routing data

about user‐undesired routes

SetTrafficUpdate complex 1 Historic TD Traffic Data

A complex update that describes the travel time weight changes on the road segments for one or

several time horizons

SetPublicTransportUpdate complex 1 Historic TD Traffic Data

A complex update that describes the

changes in timetable fleet transportation

information

SaveRouteTrafficSnapshot complex 1 PND Cached Replica of Historic TD Traffic Data

A complex storing of valuable up‐to‐date traffic snapshots in a

database (to be synchronised

with the local copies kept in the user

navigation devices, in order to assure a min level of

operation even upon connectivity‐loss).

3.2.3 Crowd‐sourcing

Report Tracking & Significance Assessment

This service performs a twofold role: (a) on the one hand it supports dynamic user reports that the users are posting as they move, e.g., real‐time reports on sudden traffic events and incidents, sudden weather changes and any additional information that users pushes into the system regarding traffic, transport and carpooling; (b) on the other hand this service support assessment of the incoming information, which is an essential operation of any crowd‐sourcing system, in order to make sure


D2.3: of 73

that any crowd sourced information is not fake, i.e. it is validated before being further processed. Thus, the user serves the MOVESMART crowd‐sourcing mechanism being both information publisher and information evaluator (referring to information published by other users). Name: Report Tracking & Significance Assessment

Type: Service Container: Crowd‐sourcing Functionality: Gather real time data as the user is moving and request the

user to assess any incoming information by nearby users. Connections: Data Communication Interface Module, Infrastructure

Reporting, UTKB Management. Relevant Use Cases: UC3.5, UC3.7, UC3.8.

INPUT PARAMETERS

Name Data Type Cardinality Source Description FeedbackRequest Complex 1 UTKB

Management, Data

Communication Interface Module,

Infrastructure Reporting, Traveller Reporting.

Complex object representing a request for feedback.

FeedbackRequest.hasIncidentType Enum 1..n As above The type of incident to which the original report refers. The user is requested to give their feedback on the validity of that incident. Possible values: “Road blocked”,

“accident”, “heavy showers”, “icy road”, etc.

FeedbackRequest.road Complex 1..n As above An object that represents the

road to which the user report refers.

FeedbackRequest.city String 1 As above The name of the city in which the user is travelling.

FeedbackRequest.country String 1 As above The name of the country to which the city belongs.

FeedbackRequest.onUserId int 1 As above The anonymous id of the user who

posted the report.

OUTPUT PARAMETERS

Name Data Type Cardinality Destination Description SendReport Complex 1 As above Complex object

that includes


D2.3: of 73

Name: Report Tracking & Significance Assessment

information about user reporting.

SendReport.user_id int 1 As above The anonymous id of the reporting

user.

SendReport.road Complex 1 As above The road to which the report refers.

SendReport.city String 1 As above The name of the city in which the user is travelling.

SendReport.country String 1 As above The name of the country to which the city belongs.

SendReport.hasIncidentType Enum 1..n As above Gets ones of: “Road blocked”, “accident”, “heavy showers”, “icy road”, etc.

SendReport.time Int 1 As above The current time in msec of the user generated report

UserSubmittedFeedback Complex 1 As above Complex object that includes

information about the submitted user feedback.

UserSubmittedFeedback.value double 1 As above The value of user rating in the 0.0…5.0 scale.

UserSubmittedFeedback. hasIncidentType

Enum 1..n As above Gets ones of: “Road blocked”, “accident”, “heavy showers”, “icy road”, etc.

UserSubmittedFeedback.isLikeDislike Boolean 1 As above If feedback is given in a like/dislike

fashion, like is represented by

‘true’.

UserSubmittedFeedback.onUser int 1 As above The anonymous id of the user who originated the

report.


It provides periodic updates regarding the speed of the user, the transportation means they use, the location of a shared vehicle and other crowd sourced retrieved data that are necessary for providing to the user and the system the information needed to make informed decisions regarding route planning.


D2.3: of 73

Name: Periodic Reports Push Type: Service Container: Crowd‐sourcing Functionality: Sends periodic reports from the users in passive mode. Connections: Data Communication Interface Module, Infrastructure

Reporting, UTKB Management. Relevant Use Cases: UC3.3, UC3.6.

INPUT PARAMETERS


No input parameters are associated to this service.

OUTPUT PARAMETERS

Name Data Type Cardinality Destination Description UserPeriodicReport Complex 1 UTKB

Management, Data



A complex object including all periodic

information reported by the user in passive

mode.

UserPeriodicReport.trafficSpeedRecord Enumeration 1 As above A complex object represented the current speed of

the user.

UserPeriodicReport.trafficSpeedRecord. timeStamp

int 1 As above The time stamp in msec of this

report.

UserPeriodicReport.trafficSpeedRecord. velocity

double 1 As above The value of current velocity in

kmph that corresponds to the

current user.

UserPeriodicReport. trafficSpeedRecord.roadID

int 1 As above The road id, to which the velocity

refers.

UserPeriodicReport.mode Enum 1 As above Represents one of the possible means of

transport that the user is currently

using, e.g. “private car”, “pedestrian”,

“bus”, etc.

UserPeriodicReport.userid int 1 As above The unique anonymous id of the user who

sends the report.

UserPeriodicReport.nextReportingTime int 1 As above The submission period of this report in msec.


D2.3: of 73

Post‐Reports Push

The user submits feedback in order to evaluate the quality of the provided services. Name: Post‐Reports Push

Type: Service Container: Crowd‐sourcing Functionality: The user sends feedback on the provided services. Connections: Data Communication Interface Module, Infrastructure

Reporting, UTKB Management. Relevant Use Cases: UC3.7.

INPUT PARAMETERS

Name Data Type Cardinality Source Description FeedbackRequest Complex 1 UTKB

Management, Data



Complex object representing a request for feedback.

FeedbackRequest.serviceType Enum 1..n As above The type of service for which the user

is asked for providing her/his feedback. Possible

values: “Car pooling”, “eco‐friendly route”,

“safest route”, etc.

FeedbackRequest.city String 1 As above The name of the city in which the user is travelling.

FeedbackRequest.country String 1 As above The name of the country to which the city belongs.

OUTPUT PARAMETERS

Name Data Type Cardinality Destination Description UserSubmittedFeedback Complex 1 As above Complex object

that includes information about the submitted user feedback.

UserSubmittedFeedback.value double 1 As above The value of user rating in the 0.0…5.0 scale.

UserSubmittedFeedback. ServiceType

Enum 1..n As above Gets ones of: “Car pooling”, “eco‐friendly route”,


UserSubmittedFeedback.isLikeDislike Boolean 1 As above If feedback is given in a


D2.3: of 73

Name: Post‐Reports Push

like/dislike fashion, like is represented by

‘true’.

UserSubmittedFeedback.userId int 1 As above The anonymous id of the user who submits feedback.

Emergency Reports Push

When connection is established to the cloud the user starts to push whenever required system wide alerts and notifications. Other users may be notified as well. Name: Emergency Reports Push

Type: Service Container: Crowd‐sourcing Functionality: Provides alerts and notifications to the user navigation

device from the system or other users. Connections: Data Communication Interface Module, Infrastructure

Reporting, UTKB Management. Relevant Use Cases: UC3.4.

INPUT PARAMETERS


No input parameters are associated to this service.

OUTPUT PARAMETERS

Name Data Type Cardinality Destination Description EmergencyAlert Complex 1..n Traveller

Reporting, Mobile Device

API.

Complex object that describes the

alert.

EmergencyAlert.type Enum 1 As above The type of the alert (e.g. “weather”,

“traffic”, “road blockage”).

EmergencyAlert.severity Enum 1 As above The degree of severity of the

alert.

EmergencyAlert.text String 1 As above The message of the alert.

3.2.4 Traffic Management

EV / Bicycle Fleet Relocation & Pricing Policy

The EV / Bicycle Fleet Relocation & Pricing Policy service runs on the MOVESMART system's server. It has two purposes: a) to optimise the EV and bicycle displacement and allocation, preserving the performance of the provided fleet service in a good level and b) to provide the rewarding & pricing policy during the reservation time of the vehicles. The goal of the service is to balance the vehicle


D2.3: of 73

demand by area, to satisfy the most of the users on finding easily a vehicle, and to provide ecological and economical incentive rewards for the good practices by the user side (especially at rush hours). Name: EV / Bicycle Fleet Relocation & Pricing Policy

Type: Service Container: Traffic Management Sub‐module / Core Traffic Services

Module Functionality: Relocation & Pricing Policy management

Connections: Entity Monitoring Sub‐module (Traveller Monitoring, EV / Bicycle Availability, Vehicle Reservation & Billing Service), Park & Ride Sub‐module [EV state of charge (SoC) Checking / Recharging Service], Profiles Management Sub‐module (User, Service, Vehicle Profile Management Service), Traveller Incentivising / Rewarding Service

Relevant Use Cases: UC1.10, UC1.13, UC1.14, UC1.15, UC2.1, UC2.2, UC2.3, UC2.4, UC2.5, UC2.6, UC2.7

INPUT PARAMETERS

Name Data Type

Cardinality Source Description

UsersWithReservedVehicle

list 1

User Profile

Management

Vehicle Profile

Management

The list of the users who are travelling with a

vehicle

AreaVehicleAvailability list 1

EV / Bicycle Availability

The list of the available vehicles

AreaVehicleDemand complex 1


The vehicle demand by area

AreaVehicleDemand.EV list 1


The areas where EVs are needed by

customers

AreaVehicleDemand.Bicycle

list 1 EV / Bicycle Availability

The areas where bicycles are needed by customers

EVChargingPoints list 1

EV SoC Checking / Recharging

The points where an EV can be charged

UserVehicleType int 1

Vehicle Profile

Management

The user selection on vehicle type : EV or bicycle

EnergyConsumption

double 1 Traveller

Monitoring

The energy consumption of the EV vehicle during user

reservation time ReservationTime

double 1 Traveller

Monitoring

The reservation time of vehicle by

user

getVehicleDisplacementRate complex 1

Traveller Monitoring

The vehicle displacement area


D2.3: of 73

Name: EV / Bicycle Fleet Relocation & Pricing Policy

rate

getVehicleDisplacementRank.Demanding

double 1 Traveller

Monitoring

The customer demand degree at

the vehicle displacement area

getVehicleDisplacementRank.EnergyCharging

Boolean 1 Traveller

Monitoring

If user left EV in energy charging

station.

userCardinality

Int 1 Service Profile

Management

The number of users are

travelling in the same vehicle

AdvertisingDisplay

Boolean

User Profile

Management

Service Profile

Management

An option for an EV user for the advertisement displaying during the travelling

OUTPUT PARAMETERS

Name Data Type

Cardinality Destination Description

VehicleDisplacementBonus

complex 1 EV / Bicycle Availability

The areas where vehicle

displacements offer bonus

setEnergyCostLevel double 1 Vehicle Reservation & Billing

The cost based on energy

consumption

setReservationTimeLevelCost double 1 Vehicle Reservation & Billing

The cost based on travelling duration

setBonus complex 1 Traveller Incentivising / Rewarding

Service

A complex object for providing

bonus to a user based on his/her “good practices”

setBonus.VehicleDisplacementRank double 1 Traveller Incentivising / Rewarding

Service

A bonus rate concerning the

vehicle displacement.

setBonus.UserCardinality double 1 Traveller Incentivising / Rewarding

Service

A bonus rate concerning the shared use of a

vehicle by different users.

setBonus.ecoFootprint double 1 Traveller Incentivising / Rewarding

Service

A bonus rate concerning the

minimum energy consumption and CO2 emissions

setBonus.AdvertisingDisplay double 1 Traveller Incentivising

A bonus rate from the advertisments


D2.3: of 73

Name: EV / Bicycle Fleet Relocation & Pricing Policy

/ Rewarding Service

Energy‐Efficiency Assessment

This service supports the single‐ or multi‐modal route planning of individuals by performing the assessment of the route suggestions (provided to the user) from an energy‐efficiency perspective. Upon the receipt of such a request from the TD Routing Service, it returns information about the energy consumption and emissions for the provided route, based on the characteristics of the latter, the transport mode chosen for each leg of it, as well as the characteristics and predicted traffic conditions of the road network. Name: Energy‐Efficiency Assessment Type: Service Container: Traffic Management Sub‐module / Core Traffic Services Module Functionality: Energy‐efficiency Assessment Computations Connections: TD Routing Service, UTKB Management Service, Vehicle Profile

Management Service

Relevant Use Cases: UC1.2, UC1.3, UC1.4, UC1.5, UC1.6, UC1.7, UC1.8, UC1.9, UC1.16, UC3.1

INPUT PARAMETERS

Name Data Type Cardinality Source Description EnergyEfficiencyAssessmentRequest complex 1 TD Routing /

Traffic Management Sub‐module

A complex request object for querying energy efficiency assessment of the provided route

EnergyEfficiencyAssessmentRequest. TransportModeParameters

complex 1 TD Routing / Traffic

Management Sub‐module

Vehicle Profile

Management / Profiles


Parameters of the transport mode for each leg of the route, such as category (e.g.

walking / cycling / driving / PT), vehicle pooling option and

occupancy (if applicable), vehicle characteristics (e.g.

type, internal combustion engine / electric, engine / motor class, fuel

type, emission class)

EnergyEfficiencyAssessmentRequest.

RouteParameters complex 1 TD Routing /


UTKB

Management / Core Traffic Services Module

Parameters for each in‐between road segment of the

route, such as travel distance, traffic

conditions (e.g. free flow, heavy traffic, saturated, stop & go), average speed,

area type (e.g.


D2.3: of 73

Name: Energy‐Efficiency Assessment

rural/urban), speed limits, road

type and gradient

OUTPUT PARAMETERS

Name Data Type Cardinality Destination Description EnergyEfficiencyAssessmentResponse complex 1 TD Routing /


A complex response object representing the energy efficiency assessment of the provided route

EnergyEfficiencyAssessmentResponse. RouteInfo

complex 1 TD Routing / Traffic


A complex response object that holds information about the energy consumption and the emissions for the provided route

TD Routing

The TD Routing service runs on the MOVESMART system's server. This service is responsible for executing several types of queries made by users. Based on the user requirements or/and preferences, it computes one or several routes which satisfy at least one optimisation criteria (such as distance, travel time, fuel consumption, eco‐friendliness) and use at least one transportation mode (bus, train, EV, bicycle), at specific departure times or time windows. Name: TD Routing Type: Service Container: Traffic Management Sub‐module / Core Traffic Services Module Functionality: TD‐Route Planning Computation Connections: Renewable MOD Sub‐module, Traffic Prediction Service,

Proprietary Traffic Data Adapter, EV‐Fleet Management Module Relevant Use Cases: UC1.4, UC1.5, UC1.6, UC1.7, UC1.8, UC1.9, UC3.1, UC3.2, UC3.9,

UC3.10, UC3.11

INPUT PARAMETERS

Name Data Type Cardinality Source Description SimpleRouteRequest complex 1 Renewable

MOD Sub‐module

EV‐Fleet

Management Service

A complex request object for querying time dependent

routes

SimpleRouteRequest. fromCoord

WGS84 latitude, longitude

1 Renewable MOD Sub‐module

EV‐Fleet

Management Service

Origin coordinate of the requested route

SimpleRouteRequest. toCoord

WGS84 latitude,

1 Renewable MOD Sub‐

Destination coordinate of the


D2.3: of 73

Name: TD Routing

longitude module

EV‐Fleet Management

Service

requested route

SimpleRouteRequest. timeLeaving

time 1 Renewable MOD Sub‐module

EV‐Fleet

Management Service

Departure time (if not immediate)

SimpleRouteRequest. Preferences

complex 1 Renewable MOD Sub‐module

EV‐Fleet

Management Service

The user preferences, such as avoid freeways, or the optimisation

criterion, e.g. fastest, eco, robust

TimeDependentRouteRequest complex 1 Renewable MOD Sub‐module

EV‐Fleet

Management Service

A complex request object for querying time dependent

routes

TimeDependentRouteRequest. fromCoord



EV‐Fleet

Management Service


TimeDependentRouteRequest. toCoord



EV‐Fleet

Management Service

Destination coordinate of the requested route

TimeDependentRouteRequest. earliestTimeLeaving


EV‐Fleet

Management Service

Earliest departure time

(if not immediate)

TimeDependentRouteRequest. latestTimeLeaving


EV‐Fleet

Management Service

Latest departure time


D2.3: of 73

Name: TD Routing TimeDependentRouteRequest. Preferences


EV‐Fleet

Management Service

The user preferences, such as avoid freeways, or the optimisation


AltRouteRequest complex 1 Renewable MOD Sub‐module

EV‐Fleet

Management Service

A complex request object for querying alternative routes

AltRouteRequest. fromCoord



EV‐Fleet

Management Service


AltRouteRequest. toCoord



EV‐Fleet

Management Service


AltRouteRequest. timeLeaving


EV‐Fleet

Management Service


AltRouteRequest. Preferences


EV‐Fleet

Management Service

The user preferences, such as

number of alternatives (or

density of alternative graph), avoid freeways, or the optimisation


MultiCriteriaRouteRequest complex 1 Renewable MOD Sub‐module

EV‐Fleet

Management Service

A complex request object for querying multi‐criteria routes

MultiCriteriaRouteRequest. fromCoord

WGS84 latitude,

1 Renewable MOD Sub‐



D2.3: of 73

Name: TD Routing

longitude module


Service MultiCriteriaRouteRequest. toCoord



EV‐Fleet

Management Service


MultiCriteriaRouteRequest. timeLeaving


EV‐Fleet

Management Service

Departure time(if not immediate)

MultimodalRouteRequest.activeCriteria

bitfield 1 Multi‐Modal Transport Application

(UI), Itinerary‐planning module

Cost criteria to take into consideration ‐ Combination of

FASTEST, TRANSFERS,

CHEAPEST, ROBUST, ECO

MultimodalRouteRequest.preferences

complex 0..1 Multi‐Modal Transport Application


User preferences (e.g. preference in modes of transport,

ownership of monthly passes,

transfer configuration,

walking speed, and similar)

RobustRouteRequest complex 1 Renewable MOD Sub‐module

EV‐Fleet

Management Service

A complex request object for querying

robust routes

RobustRouteRequest.fromCoord WGS84 latitude, longitude


EV‐Fleet

Management Service

Origin coordinate of the requested robust

route

RobustRouteRequest.toCoord WGS84 latitude, longitude


EV‐Fleet

Destination coordinate of the requested robust

route


D2.3: of 73

Name: TD Routing

Management Service

RobustRouteRequest.timeLeaving time 0..1 Renewable MOD Sub‐module

EV‐Fleet

Management Service


OUTPUT PARAMETERS

Name Data Type Cardinality Destination Description SimpleRouteResponse list 1 Renewable

MOD Sub‐module

EV‐Fleet

Management Service

A complex response object to time

dependent route queries listing one (or several) routes

SimpleRouteResponse. routeInfo


EV‐Fleet

Management Service


holds key information about the calculated route

(total distance, travel time, eco‐friendliness etc.)

SimpleRouteResponse. route


EV‐Fleet

Management Service

Detailed description of the calculated

route such as the list of in‐between road segments on fthe computed route

TimeDependentRouteResponse list 1 Renewable MOD Sub‐module

EV‐Fleet

Management Service

A complex response object to time

dependent route queries listing one (or several) routes

TimeDependentRouteResponse[i]. routeInfo


EV‐Fleet

Management Service


holds key information about the ith calculated

route such as several route criteria ( best departure time, total distance, travel time, eco‐friendliness etc.)

TimeDependentRouteResponse[i]. complex 1 Renewable Detailed description


D2.3: of 73

Name: TD Routing path MOD Sub‐

module


Service

of the ith calculated route such as the list of in‐between road segments on the computed route

TimeDependentRouteResponse. bestDepartureTime


EV‐Fleet

Management Service

Best departure time in the given time

window

AltRouteResponse

list 1 Renewable MOD Sub‐module

EV‐Fleet

Management Service

A complex response object to alternative route queries listing the computed routes

(if any)

AltRouteResponse[i]. routeInfo


EV‐Fleet

Management Service


holds key information about the ith calculated route such as the route metrics total distance, travel time, eco‐friendliness, reliability etc.

AltRouteResponse[i]. path


EV‐Fleet

Management Service

Detailed description of the ith calculated route such as the list of in‐between road segments on the computed route

MultiCriteriaRouteResponse

list 1 Renewable MOD Sub‐module

EV‐Fleet

Management Service

A complex response object to multi‐

criteria route queries listing the Pareto Optimal Routes

MultiCriteriaRouteResponse[i]. routeInfo


EV‐Fleet

Management Service


holds key information about the ith calculated

route such as several route criteria (total distance, travel time, eco‐friendliness etc.)

MultiCriteriaRouteResponse[i]. complex 1 Renewable Detailed description


D2.3: of 73

Name: TD Routing path MOD Sub‐

module


Service

of the ith calculated route such as the list of in‐between road segments on the computed route

MultimodalRouteResponse

list 1 Multi‐Modal Transport Application


A complex response object to multi‐modal route queries listing the compute routes (if any)

MultimodalRouteResponse[i]. routeInfo

complex 1 Multi‐Modal Transport Application


A complex route response object that holds key information about the ith calculated route such as departure time (and date), travel time, number of trips, reliability, eco‐friendliness, and fare

MultimodalRouteResponse[i]. path

complex 0..1 Multi‐Modal Transport Application


Detailed description of the ith calculated route such as (mode of transportation, vehicle id if any, stop names, list of coordinates)

RobustRouteResponse complex 1 Renewable MOD Sub‐module

EV‐Fleet

Management Service

A complex object representing a

robust response to the query under uncertainty

RobustRouteResponse.routeInfo complex 1 Renewable MOD Sub‐module

EV‐Fleet

Management Service


holds key information about the calculated route such as several route

criteria (total distance, travel time, eco‐friendliness,

confidence of travel time etc.)

RobustRouteResponse.path complex 1 Renewable MOD Sub‐module

EV‐Fleet

Management

Detailed description of the calculated

route such as the list of in‐between road segments on the computed route


D2.3: of 73

Name: TD Routing

Service

3.3 Integrated Personal Mobility Applications Module

3.3.1 MOVESMART Connect / Disconnect Client

This service will allow connection to the MOVESMART system, so as to have access / modification rights to the entity (traveller / vehicle / service) profile, and be able to exchange entity‐related information (e.g., rewards, vehicle availability, etc) via the Security And Anonymity Gateway. Name: MOVESMART Connect / Disconnect Client

Type: Service

Container: Integrated Personal Mobility Applications Module.

Functionality: Via the Security & Anonymity Gateway the MOVESMART system has access to modify entity profiles and exchange related information

Connections: Cloud Management Module, Traveller Reporting, Security & Anonymity Gateway

Relevant Use Cases:

INPUT PARAMETERS



Unique identifier of resource that is required to be

edited.

Access Group Complex 1 Security & Anonymity Gateway

Rights associated to the service to

modify a profile.

OUTPUT PARAMETERS


Access Allowed Complex 1 Connection / Disconnection to UT‐Cloud

Status of access granted/denied based on their security group.

3.3.2 Renewable MOD Services

EV Routes

The EV Routes service runs on the user's own PND and provides an interface for the user to compute routes for EVs. It does so in one of two ways. If the device is able to connect to the cloud, it will gather all necessary data for the TD‐ROUTING service, such that the TD‐ROUTING service can compute an optimised EV‐route. Should the PND not be able to connect to the cloud, it will, if possible, gather all necessary input data and compute an optimised EV‐route based on a locally stored snapshot of the historic traffic data. Name: EV ROUTES Type: Service Container: Renewable Mobility on Demand / Integrated Personal Mobility

Applications Module Functionality: Interface for Computing EV‐Routes through TD Routing service,


D2.3: of 73

Name: EV ROUTES

or, as fallback, computing EV Routes locally on the device. Connections: TD Routing Service, Connection / Disconnection to UT‐cloud

Service, Traveller Monitoring Service, Mobile Device API service, EV/Bicycle on Demand Service, Vehicle Reservation & Billing Service, Messenger Service, Security & Anonymity Gateway, EV Sharing, EV SoC Checking/Recharging, Vehicle Pooling, Vehicle Profile Management

Relevant Use Cases: UC 1.4, UC 1.5, UC1.6 INPUT PARAMETERS


UserCredentials Complex 1 Mobile Device API

The user’s credentials to obtain a temporal

alias

TemporalAlias Complex 1 Connection / Disconnection to UT‐cloud

A anonymous temporal alias for the user

EVRouteRequest Complex 1 Mobile Device API

A complex request object for querying EV

routes EVRouteRequest. fromCoord


1 Traveller Monitoring

or Mobile Device

API


EVRouteRequest. toCoord

WGS84latitude, longitude

1 Mobile Device API


EVRouteRequest. timeLeaving

Time 1 Mobile Device API

(earliest possible)departure time

EVRouteRequest. latestTimeLeaving

Time 0..1 Mobile Device API

Latest possible depature time (only

relevant when TimeDependentRouteR

equest is issued)

EVRouteRequest. batteryCharge

Int 1 Mobile Device API or

Vehicle Profile Management

Current state of charge of the vehicle (in %)

EVRouteRequest. Preferences

complex 1 Security & Anonymity Gateway

The user preferences stored in the user’s

profile. Particularly the optimisation criterion, e.g. fastest, eco friendly

GetTrafficResponse complex 1 Messenger A complex object that includes a current traffic report.

SimpleRouteResponse list 1 TD Routing A complex response object to EV route

queries listing one (or several) routes

TimeDependentRouteResponse list 1 TD Routing A complex response object to EV route

queries listing one (or


D2.3: of 73

Name: EV ROUTES

several) routes

OUTPUT PARAMETERS

Name Data Type Cardinality Destination Description SimpleRouteRequest complex 1 TD Routing A complex request

object for querying EV routes



1 TD Routing Origin coordinate of the requested route



1 TD Routing Destination coordinate of the requested route


Time 1 TD Routing departure time

SimpleRouteRequest. batteryCharge

Int 1 TD Routing Current state of charge of the vehicle (in %)


complex 1 TD Routing The user preferences stored in the user’s profile. Particularly the optimisation criterion, e.g. fastest, eco friendly

SimpleRouteRequest. modeOfTransport

“EV”String

1 TD Routing The chosen mode of transport. In this case it is fixed to “EV”

TimeDependentRouteRequest complex 1 TD Routing A complex request object for querying EV routes










Time 1 TD Routing

TimeDependentRouteRequest. batteryCharge


TimeDependentRouteRequest. Preferences


TimeDependentRouteRequest. modeOfTransport

“EV”String

1 TD Routing The chosen mode of transport. In this case it is fixed to “EV”

StationToStationRoutes list 1…* EV Sharing A complex response object to an EV route query between two EV Sharing stations. The object may list one or several routes


D2.3: of 73

Name: EV ROUTES StationToStationRoutes[i]. routeInfo

complex 1 EV Sharing A complex route response object that holds key information about the ith calculated route such as several route criteria (best departure time, total distance, travel time, eco‐friendliness etc.)

StationToStationRoutes[i]. path

complex 1 EV Sharing Detailed description of the ith calculated route such as the list of in‐between road segments on the computed route

CalculateRoutes list 1…* Vehicle Pooling

or EV SoC

Checking/Recharging

A complex response object to an EV route query. The object may list one or several routes

CalculateRoutes[i]. routeInfo

complex 1 Vehicle Pooling

or EV SoC

Checking/Recharging

A complex route response object that holds key information about the ith calculated route such as several route criteria (best departure time, total distance, travel time, eco‐friendliness etc.)

CalculateRoutes[i]. path


or EV SoC

Checking/Recharging


RouteEnergyConsumption Int 1 EV SoC Checking/Rec

harging

Estimated energy consumption for an EV, on a given route.

ActiveRoute complex 1 Route on Demand

The currently selected route from the currently active Route service

ActiveRoute. routeInfo

complex 1 Route on Demand

A complex route response object that holds key information about the currently active route (total distance, travel time, energy efficiency assessment, predicted traffic situation information, etc.)

ActiveRoute. path


Detailed description of the currently route such


D2.3: of 73

Name: EV ROUTES

as the list of in‐between road segments on the computed route

IsActiveServiceIndicator

Boolean

1 Mobile Device API

Response to determine if EV Routes service is active and provides routing for the traveller

Bicycle Routes

The Bicycle Routes service runs on the user's own PND and provides an interface for the user to compute routes for Bicycles or e‐bikes. It does so in one of two ways. If the device is able to connect to the cloud, it will gather all necessary data for the TD‐ROUTING service, such that the TD‐ROUTING service can compute an optimised bicycle/e‐bike‐route. Should the PND not be able to connect to the cloud, it will, if possible, gather all necessary data and compute an optimised bicycle/e‐bike ‐route locally by using a snapshot of the locally stored historic traffic data. Name: BICYCLE ROUTES Type: Service Container: Renewable Mobility on Demand / Integrated Personal Mobility

Applications Module Functionality: Interface for Computing bicycle/e‐bike‐routes through TD

Routing service, or, as fallback, computing bicycle/e‐bike‐routes locally on the device.

Connections: TD Routing Service, Connection / Disconnection to UT‐cloud Service, Traveller Monitoring Service, Mobile Device API service, EV/Bicycle on Demand Service, Vehicle Reservation & Billing Service, Messenger Service, Security & Anonymity Gateway,

Relevant Use Cases: UC 1.4, UC 1.5 INPUT PARAMETERS




alias



BikeRouteRequest complex 1 Mobile Device API


bicycle routes BikeRouteRequest. fromCoord



or Mobile Device

API


BikeRouteRequest. toCoord


1 Mobile Device API


BikeRouteRequest. timeLeaving


departure time

BikeRouteRequest. complex 1 Security & The user preferences


D2.3: of 73

Name: BICYCLE ROUTES Preferences Anonymity

Gateway stored in the user’s


BikeRouteRequest. batteryCharge

Int 0..1 Mobile Device API or

Vehicle Profile Management

Current state of charge of the e‐bike (in %)

(only applicable for e‐bikes)


SimpleRouteResponse list 1 TD Routing A complex response object to bike route queries listing one (or

several) routes

OUTPUT PARAMETERS

Name Data Type Cardinality Destination Description BikeRouteResponse list 1 TD Routing A complex response

object to bike route queries listing one (or several) routes (the response object is the same for BikeRouteRequest and BikeRouteRequest Offline)

BikeRouteResponse[i]. routeInfo

complex 1 TD Routing A complex route response object that holds key information about the ith calculated route (total distance, travel time, energy efficiency assessment, predicted traffic situation information, etc.)

BikeRouteResponse[i]. path

complex 1 TD Routing Detailed description of the ith calculated route such as the list of in‐between road segments on the computed route

SimpleRouteRequest complex 1 TD Routing A complex request object for querying bicycle routes









SimpleRouteRequest. Int 1 TD Routing Current state of charge


D2.3: of 73

Name: BICYCLE ROUTES batteryCharge of the vehicle (in %)




String

(“e‐bike” or ”bike”)

1 TD Routing The chosen mode of transport. In this case it is fixed to either “e‐bike” or “bike”






ActiveRoute. path


Detailed description of the currently route such as the list of in‐between road segments on the computed route

IsActiveServiceIndicator Boolean 1 Mobile Device API

Response to determine if Bicycle Routes service is active and provides routing for the traveller

Car Routes

The CAR ROUTES service runs on the user's own PND and provides an interface for the user to compute routes for conventional cars. It does so in one of two ways. If the device is able to connect to the cloud, it will gather all necessary data for the TD‐ROUTING service, such that the TD‐ROUTING service can compute an optimised route. Should the PND not be able to connect to the cloud, it will, if possible, gather all necessary data and compute an optimised route locally by using a snapshot of the locally stored historic traffic data. Name: CAR ROUTES Type: Service Container: Renewable Mobility on Demand / Integrated Personal Mobility

Applications Module Functionality: Interface for Computing routes for conventional cars through

TD Routing service, or, as fallback, computing routes locally on the device.

Connections: TD Routing Service, Connection / Disconnection to UT‐cloud Service, Traveller Monitoring Service, Mobile Device API


D2.3: of 73

Name: CAR ROUTES

service, Messenger Service, Security & Anonymity Gateway

Relevant Use Cases: UC 1.4, UC 1.5, UC1.6 INPUT PARAMETERS




alias



CarRouteRequest Complex 1 Mobile Device API


routes for conventional cars

CarRouteRequest. fromCoord



or Mobile Device

API


CarRouteRequest. toCoord

WGS84latitude, longitude

1 Mobile Device API


CarRouteRequest. timeLeaving


(earliest possible) departure time

CarRouteRequest. latestTimeLeaving

Time 0..1 Mobile Device API

Latest possible depature time (only

relevant when TimeDependentRouteR

equest is issued)

CarRouteRequest. Preferences





SimpleRouteResponse list 1 TD Routing A complex response object to EV route


TimeDependentRouteResponse list 1 TD Routing A complex response object to EV route


OUTPUT PARAMETERS

Name Data Type Cardinality Destination Description SimpleRouteRequest complex 1 TD Routing A complex request

object for querying routes for conventional cars


WGS84 latitude,



D2.3: of 73

Name: CAR ROUTES

longitude









“Car”String

1 TD Routing The chosen mode of transport. In this case it is fixed to “Car”

TimeDependentRouteRequest complex 1 TD Routing A complex request object for querying EV routes










Time 1 TD Routing Latest depature time

TimeDependentRouteRequest. Preferences


TimeDependentRouteRequest. modeOfTransport

“Car”String

1 TD Routing The chosen mode of transport. In this case it is fixed to “Car”

CalculateRoutes list 1…* Vehicle Pooling

A complex response object to a car route query. The object may list one or several routes

CalculateRoutes[i]. routeInfo


A complex route response object that holds key information about the ith calculated route such as several route criteria (best departure time, total distance, travel time, eco‐friendliness etc.)

CalculateRoutes[i]. path




D2.3: of 73

Name: CAR ROUTES ActiveRoute complex 1 Route on

Demand The currently selected route from the currently active Route service




ActiveRoute. path




Boolean

1 Mobile Device API

Response to determine if EV Routes service is active and provides routing for the traveller

Routes On Demand

The ROUTES ON DEMAND service resides on the traveller's PND and provides a background service complementary to the current active (CAR/EV/BICYCLE/MULTIMODAL) ROUTES service. It has two main purposes. One is to act on changes in the road or public transportation network and to provide alternative routes to the current selected route at certain points during the trip. The second one allows the user to request a new route on demand while being on the trip. Name: ROUTES ON DEMAND Type: Service Container: Renewable Mobility on Demand / Integrated Personal Mobility

Applications Module Functionality: Complementary service to the active route service

(EV/Car/Bicycle/Multimodal – Routes). Provides alternative routes to the user at certain point. The service takes changes in the traffic and disturbances in the public transporation network into account.

Connections: TD Routing Service, Connection / Disconnection to UT‐cloud Service, Traveller Monitoring Service, Mobile Device API service, Messenger Service, Security & Anonymity Gateway, EV Routes, Car Routes, Bicycle Routes, Multimodal Routes, Vehicle Reservation & Billing

Relevant Use Cases: UC 1.5, UC 1.9 INPUT PARAMETERS


ActiveRouteService Text 1 Mobile Device API The currently active Routes Service (EV/Car/e‐

bike/bike/multimodal) if there is one

ActiveRoute complex 1 EV Routes/Car Routes/Bicycle

The currently selected route from the currently active Route


D2.3: of 73

Name: ROUTES ON DEMAND

Routes/Multimodal Routes/Vehicle

Pooling/EV Sharing

service

GetTrafficResponse complex 1 Messenger A complex object that includes acurrent traffic report.

AltRouteRequest complex 1 Mobile Device API A complex request object for querying EV routes

AltRouteRequest.fromCoord WGS84 latitude, longitude

1 Mobile Device API Current position of the user

AltRouteRequest.time Time 1 Mobile Device API Current time AltRouteRequest.batteryCharge Int 0..1 Mobile Device API Current state of charge of the

vehicle (in %) (only applicable if EV/e‐bike)

AltRouteRequest.Preferences complex 1 Security & Anonymity Gateway

The user preferences stored in the user’s profile. Particularly the optimisation criterion, e.g.

fastest, eco friendly OUTPUT PARAMETERS

Name Data Type Cardinality Destination Description AltRouteResponse list 1 Mobile Device API A complex response object to

multimodal route queries listing one route

AltRouteResponse.routeInfo complex 1 Mobile Device API A complex route response object that holds key information about the calculated route (total distance, travel time, energy efficiency assessment, predicted traffic situation information, etc.)

AltRouteResponse.path complex 1 Mobile Device API Detailed description of the calculated route such as the list of in‐between road segments on the computed route

AltRouteResponse.sharedEV shared EV identifier

1 Mobile Device API and

Vehicle Reservation &

Billing

The shared EV that the user will use for the route. This EV must be reserved for the user through the Vehicle Reservation & Billing service

AltRouteRequest complex 1 TD Routing A complex request object for querying EV routes

AltRouteRequest. transportMode

String 1 TD Routing Transportation Mode (EV/Car/Bicycle/Multimodal)

AltRouteRequest. fromCoord


1 TD Routing Current position of the user

AltRouteRequest. toCoord



AltRouteRequest. timeLeaving

Time 1 TD Routing Current time

AltRouteRequest. batteryCharge



D2.3: of 73

Name: ROUTES ON DEMAND AltRouteRequest. Preferences


AltRouteRequest. activeCriteria

bitfield 1 TD Routing Cost criteria to take into consideration ‐ Combination of FASTEST, TRANSFERS, CHEAPEST, ROBUST, ECO (only applicable for multimodal routing)

AltRouteRequest. modesOfTransportation

list 1 TD Routing The allowed modes of transportation (e.g., train, tram, taxi, walking) (only applicable for multimodal routing)

AltRouteRequest. modeConstraints

complex 0..1 TD Routing Constraints on the types of modes (e.g., limit walking duration) (only applicable for multimodal routing)

Multimodal Routes

The MULTIMODAL ROUTES service runs on the user's own PND and provides an interface for the user to compute routes for routes that combine several different modes of transportation. More specifically, it is possible to compute routes that combine, e.g., the use of EVs, the public train network and the public bus network. It must be flexible enough to accommodate for the user’s own preferences (e.g., maximum walking duration of 5 minutes, no taxi, at most 4 changes between public transportation networks). It should also be able to provide a If the service is able to connect to the cloud, it will gather all necessary data for the TD‐ROUTING service, such that the TD‐ROUTING service can compute an optimised multimodal route that accommodates for the user’s preferences (and limitations). Should the PND not be able to connect to the cloud, it will, if possible, gather all necessary data and compute an optimised route locally by using a snapshot of the locally stored historic traffic data and the underlying public transportation network. Name: MULTIMODAL ROUTES Type: Service Container: Renewable Mobility on Demand / Integrated Personal Mobility

Applications Module Functionality: Interface for computing multimodal routes through TD Routing

service, or, as fallback, computing multimodal Routes locally on the device.

Connections: TD Routing Service, Connection / Disconnection to UT‐cloud Service, Traveller Monitoring Service, Mobile Device API service, EV/Bicycle on Demand Service, Vehicle Reservation & Billing Service, Messenger Service, Security & Anonymity Gateway, EV Sharing

Relevant Use Cases: UC1.2, UC1.3, UC 1.4, UC 1.5, UC1.6, UC 1.7, UC 1.8, UC 1.9, UC 3.1, UC 3.2

INPUT PARAMETERS


UserCredentials Complex 1 Mobile The user’s credentials to


D2.3: of 73

Name: MULTIMODAL ROUTES

Device API obtain a temporal alias



MultimodalRouteRequest complex 1 Mobile Device API

A complex request object for querying multimodal

routes MultimodalRouteRequest.fromCoord



or Mobile

Device API


MultimodalRouteRequest.toCoord


1 Mobile Device API


MultimodalRouteRequest.timeEarliest

Date 1 Mobile Device API

Earliest departure (or arrival, see below) time

and date MultimodalRouteRequest.timeLatest

Date 1 Mobile Device API

Latest departure (or arrival, see below) time

and date

MultimodalRouteRequest.depOrArr

Boolean

1 Mobile Device API

Meaning of timeEarliest and timeLatest False: departure True: Arrival

MultimodalRouteRequest.Preferences



profile. Particularly the optimisation criterion

(e.g. fastest, eco friendly) and preferences in mode of transportation (e.g., user has own car, the user’s walking speed)


bitfield 1 Mobile Device API

Cost criteria to take into consideration ‐

Combination of FASTEST, TRANSFERS, CHEAPEST,

ROBUST, ECO

MultimodalRouteRequest.modesOfTransportation

list 1 Mobile Device API

The allowed modes of transportation (e.g.,

train, tram, taxi, walking)

MultimodalRouteRequest.modeConstraints

complex 0..1 Mobile Device API

Constraints on the types of modes (e.g., limit walking duration)

MultimodalRouteResponse list 1 TD Routing A complex response object to multimodal

route queries listing one (or several) routes

GetTrafficResponse complex 1 Messenger A complex object that includes a current traffic

report.

GetPublicTransitResponse complex 1 Messenger A complex object that includes delays for the public transportation


D2.3: of 73


network

OUTPUT PARAMETERS

Name Data Type Cardinality Destination Description MultimodalRouteRequest complex 1 TD Routing A complex request object

for querying multimodal routes

MultimodalRouteRequest.fromCoord



MultimodalRouteRequest.toCoord



MultimodalRouteRequest.timeEarliest

Date 1 TD Routing Earliest departure (or arrival, see below) time and date

MultimodalRouteRequest.timeLatest

Date 1 TD Routing Latest departure (or arrival, see below) time and date

MultimodalRouteRequest.depOrArr

Boolean

1 TD Routing Meaning of timeEarliest and timeLatest

False: departureTrue: Arrival

MultimodalRouteRequest.Preferences



bitfield 1 TD Routing Cost criteria to take into consideration ‐

Combination of FASTEST, TRANSFERS, CHEAPEST, ROBUST, ECO

MultimodalRouteRequest.modesOfTransportation

list 1 TD Routing The allowed modes of transportation (e.g., train, tram, taxi, walking)

MultimodalRouteRequest.modeConstraints

complex 0..1 TD Routing Constraints on the types of modes (e.g., limit walking duration)

MultimodalRouteResponse list 1 Mobile Device API

A complex response object to multimodal route queries listing one (or several) routes

MultimodalRouteResponse[i]. routeInfo

complex 1 Mobile Device API

A complex route response object that holds key information about the calculated route (total distance, travel time, energy efficiency assessment, predicted traffic situation information, etc.)

MultimodalRouteResponse[i]. path


Detailed description of the calculated route such as the list of in‐between road segments on the


D2.3: of 73


computed route MultimodalRoutesToStation list 1 EV Sharing A complex response

object to multimodal route queries listing one

(or several) routes

MultimodalRoutesToStation [i]. routeInfo

complex 1 EV Sharing A complex route response object that holds key information about the calculated route (total distance, travel time, energy efficiency assessment, predicted traffic situation information, etc.)

MultimodalRoutesToStation [i]. path


Detailed description of the calculated route such as the list of in‐between road segments on the computed route






ActiveRoute. path




Boolean

1 Mobile Device API

Response to determine if Multimodal Routes service is active and provides routing for the traveller

3.3.3 Park & Ride Client

EV Sharing

EV sharing refers to a model of car rental where people rent cars for short periods of time, often in hourly basis. The service’s client runs on the user’s smartphone and provides an interface for the user to search for feasible EV sharing options. In a typical scenario, the user enters a start location and departure time (alternatively, the destination location, the rental duration or the latest arrival time) for his/her trip. The service recommends the user the best possible feasible travel plan (satisfying user restrictions and ensuring that the EV’s battery has adequate SoC); the travel plan involves the user moving to a nearby vehicle sharing station, picking up an EV and dropping it off to


D2.3: of 73

another station located nearby his/her destination location. The user may then accept the recommended travel plan and reserve the vehicle. In the case that the user has indicated interest in participating in an incentivised EV sharing scheme s/he might receive additional travel plans (e.g. picking up/dropping off a vehicle from farther located stations, using the transit system for a part of his/her trip or joining a ride reserved by another user) each associated with a bonus (award). Name: EV Sharing Type: Service Container: Park And Ride Module Functionality: EV Sharing Planning Connections: Connection/disconnection to UT‐cloud, security &

anonymity gateway, traveller monitoring, mobile device API, user profile management, EV / bicycle availability, vehicle profile management, vehicle reservation & billing, traveller incentivising & rewarding, EV routes, multimodal routes, vehicle pooling

Relevant Use Cases: UC1.13, UC1.15

INPUT PARAMETERS

Name Data Type Cardinality Source Description UserCredentials Complex 1 Connection /

Disconnection To UT‐Cloud

User credentials, so that a temporary alias can be obtained, through the security and anonymity

gateway.

StartingLocation WGS84 latitude, longitude


or Mobile Device

API

The starting GPS location as acquired from the traveller

monitoring system, in case the user wants to depart immediately, or from the mobile device of the user, if it is not supplied by the Travel Monitoring service or if the user decides to travel at a later time.

EndingLocation WGS84 latitude, longitude

1 Mobile Device API

The GPS location of the trip destination.

UserPreferences Complex 1 User Profile Management

or Mobile Device

API

User preferences, such as departure time, expected rental

duration, opt‐in to the incentivised vehicle sharing scheme,

intention to use public transport or carpooling. If the user does not have a profile, and/or cloud information is

unavailable, the Mobile Device API is employed.

VehicleStatus Complex 1..* EV / Bicycle Availability

Information about vehicle availability on


D2.3: of 73

Name: EV Sharing

vehicle stations.

BatteryStatus Int 1..* Vehicle Profile Management

Information about the State of Charge of each

vehicle.

RouteTravelCost Double 1 Vehicle Reservation and Billing

Travel cost estimation for specific travel plans

RouteReward Double 1 Traveller Incentivizing and Rewarding

Award estimation for specific travel plans.

StationToStationRoutes Complex 1..* EV Routes Alternative routes between the pickup and the drop‐off station depending on the

optimisation criteria and traffic information

MultimodalRoutesToStation Complex 1..* Multimodal Routes

Multimodal routes between the starting location and the pickup

station, as well as between the drop‐off

station and the destination.

VehiclePoolingOptions Complex 1..* Vehicle Pooling

Vehicle pooling options, for the user to offer or join an EV ride, in the case that the user has indicated intention to participate in the incentivised vehicle pooling scheme.

ReservationRegistrationResponse Complex 1 Vehicle Reservation &

Billing

Indication of whether the EV sharing option

selected by the user has been successfully

registered; updated user account.

AccountCreditResponse int 1 Traveller Incentivising and Rewarding

Indication of whether the user’s account has been successfully

credited with his/her awarded bonus.

OUTPUT PARAMETERS


EVSharingResponse Complex 0..* Any requesting

party

The service delivers several EV sharing options for each

request.

EVSharingResponse.Distance Double 1 As above Total distance for the current EV sharing

option.

EVSharingResponse.ArrivalTime Time 1 As above Arrival time for the current EV sharing

option.


D2.3: of 73

Name: EV Sharing EVSharingResponse.RegistrationNo String 1 As above Registration number of

the EV to be used.

EVSharingResponse.Duration Time 1 As above Total time for the current EV sharing

option.

EVSharingResponse.Cost Double 1 As above Total cost for the current EV sharing option, taking

multimodal cost into account, when applicable.

EVSharingResponse.StartingStation Complex 1 As above Starting station id (for each EV sharing option, so that other services can be queried for

further information), name, address and GPS

coordinates.

EVSharingResponse.EndingStation Complex 1 As above Ending station id (for each EV sharing option, so that other services can be queried for

further information), name, address and GPS

coordinates.

EVSharingResponse.IncentivisedData Complex 1 As above Incentivised travel plan data, such as award

credited, time/distance deviation from the optimal path, cost benefit, multimodal

route planning (to reach the pickup/drop‐off station), or vehicle

pooling plan.

EVSharingResponse.RecommendedSoC Int 1 As above Battery SoC for recommended vehicle

EVSharingResponse.EcoStatistics Complex 1 As above Returns statistics such as CO2 emission savings, energy consumption

etc.

ActiveServiceIndicator Boolean 1 As above Indication that EV Sharing is an active

service.

Vehicle Pooling

Vehicle pooling is about the shared use of vehicles (either conventional cars or EVs) by individuals with similar travel needs. The VEHICLE POOLING service allows vehicle owners to offer a ride and other users to join a ride. The service’s client runs on the user's own PND or smartphone and provides an interface for the user to search for offering or joining a vehicle ride, respectively. The service accepts user requests by individuals interested in offering and joining rides; each request denotes the intended start/end location and departure time along with the request type (‘offer’ or ‘join’ request). The service provides offer/join requests matching and notifies the users with


D2.3: of 73

compatible travel plans (i.e. those with nearby start/end locations or largely overlapping routes, departing at approximately the same time) provided that passenger capacity restrictions and user preferences are satisfied; it then notifies to all users involved presenting the cost or rewards/bonuses that may apply. Should both parties agree, the vehicle pooling plan is presented on their PND/smartphone devices. Upon completion of the pooling plan, the service updates the bonus account of the individual offering the ride and charges the account of the user joining the ride. Name: Vehicle Pooling Type: Service Container: Park And Ride Module Functionality: Vehicle Pooling Planning Connections: Connection/disconnection to UT‐cloud, security &

anonymity gateway, traveller monitoring, mobile device API, user profile management, car routes, EV routes, vehicle reservation & billing, traveller incentivising and rewarding

Relevant Use Cases: UC2.6, UC2.7

INPUT PARAMETERS


Disconnection To UT‐Cloud


gateway.



or Mobile Device

API

The starting GPS location as acquired from the traveller monitoring system, in case the user wants to depart immediately, or from the

mobile device of the user, if it is not supplied by the Travel Monitoring service or if the user decides to travel at a

later time.


1 Mobile Device API



or Mobile Device

API

User preferences, such as departure time, pooling request type (“offer” or

“join”), capacity restrictions for ‘offer’ requests (i.e. seats

available) and capacity requirements for ‘join’ requests (i.e. seats

requested), fellow passenger restrictions (e.g. age, gender). If the user does not have a

profile, and/or cloud information is unavailable, the MOBILE DEVICE API is

employed.

CalculateRoutes Complex 1..* Car Routesor

Calculate routes, depending on whether the vehicle owner


D2.3: of 73

Name: Vehicle Pooling

EV Routes offering the ride owns a conventional or EV vehicle.

The routes will depend on the requesting user’s selected optimisation criteria and

traffic information.

UserChargeResponse int 1 Vehicle Reservation &

Billing

Indication of whether the ‘joining’ user’s account has been successfully charged

with the travel cost.

AccountPoolingCreditResponse int 1 Traveller Incentivising and Rewarding

Indication of whether the ‘offering’ user’s account has been successfully credited with his/her awarded bonus upon the completion of the vehicle pooling schedule.

OUTPUT PARAMETERS


PoolingResponse Complex 0..* Any requesting

party

The service delivers several vehicle pooling options for

each ‘offer’ and ‘join’ request depending on the selected optimisation criteria and restrictions (e.g. profile of fellow passenger, bearable deviation from the optimal trip in time/distance, etc).

PoolingResponse.Cost Double 1 As above Returns the bonus reward for the user that offers the ride, or the cost for the user that

joins the ride.

PoolingResponse.DepartureTime Time 1 As above Returns the estimated departure time.

PoolingResponse.ArrivalTime Time 1 As above Returns the estimated arrival time.

PoolingResponse.StartingLocation WGS84 latitude, longitude

1 As above Returns the starting GPS location of the “joining”

passenger.

PoolingResponse.EndingLocation WGS84 latitude, longitude

1 As above Returns the ending GPS location of the “joining”

passenger.

PoolingResponse.OptimalTripDeviation

Time 1 As above Returns the delay between the optimal trip and the

proposed trip.

PoolingResponse.CarDetails Complex 1 As above Returns the details of the car, to be used by the user that joins a ride, to recognise his ride. Such details include color, registration number, manufacturer and model.

PoolingResponse.EcoStatistics Complex 1 As above Returns statistics such as CO2 emission savings, energy

consumption etc.

ActiveServiceIndicator Boolean 1 As above Indication that Vehicle


D2.3: of 73

Name: Vehicle Pooling

Pooling is an active service.

EV / Bicycle on Demand

The main purpose of this service is to offer a traveller alternative travel options (analogous to the alternative routes offered by the routing services), while s/he is traveling towards a defined destination. For instance, (a) to check the availability of shared EVs/Bicycles which could offer a preferable travel option to the current travel plan, assuming that those shared EVs/Bicycles have not been available at the travel start time, (b) participate in vehicle pooling services currently active, being compatible with the current travel plan. Name: EV / Bicycle On Demand

Type: Service Container: Park And Ride Module Functionality: Real‐time EV/Bicycle Sharing or Vehicle Pooling Planning Connections: Connection/Disconnection To UT‐Cloud, Security &

Anonymity Gateway, Traveller Monitoring, Mobile Device API, User Profile Management, EV Sharing, Vehicle Pooling

Relevant Use Cases: ‐

INPUT PARAMETERS


Disconnection to UT‐Cloud


gateway.



or Mobile Device

API

The current GPS location as acquired from the traveller monitoring system or from the mobile device of the

user.


1 Mobile Device API



or Mobile Device

API

User preferences, such as expected rental

duration (for EV sharing options), opt‐in to the incentivised vehicle sharing scheme,

intention to use public transport or carpooling. If the user does not have a profile, and/or cloud information is


EVSharingResponse Complex 0..* EV Sharing EV sharing options currently available, based on the user’s

current travel plan and


D2.3: of 73

Name: EV / Bicycle On Demand

preferences/restrictions.

PoolingResponse Complex 0..* Vehicle Pooling Vehicle pooling options currently available, based on the user’s

current travel plan and preferences/restrictions.

OUTPUT PARAMETERS


EV_BicycleOnDemandResponse Complex 0..* Any requesting party

The service delivers several EV/Bicycle sharing and vehicle

pooling options; that is, many

EVSharingResponse and PoolingResponse

objects

EV_BicycleOnDemandResponse[i].Deviation

Complex 1 As above An object describing how the selected

EV/bicycle on demand option considered deviates from the

current travel plan (wrt travel cost, travel time, eco footprint, etc)

ActiveServiceIndicator Boolean 1 As above Indication that EV / Bicycle On Demand is an

active service.

EV SoC Check / Recharging

This service provides pre‐trip information on the availability of shared‐use EVs with sufficient battery SoC to complete a given trip. It also provides on‐trip information with regards to the feasibility of a trip. In case of an unfeasible trip underway, the service may assist the user in planning a park & ride route, i.e. to route the driver towards a nearby parking/charging station and plan a multimodal trip towards his/her final destination. The service’s client runs on the user’s on‐board PND device; pre‐trip services may also be offered though the user’s smartphone. Name: EV SoC Check / Recharging Type: Service Container: Park And Ride Module Functionality: Check EV State of Charge Connections: Connection/Disconnection To UT‐Cloud, Security &

Anonymity Gateway, Traveller Monitoring, Mobile Device API, User Profile Management, Vehicle Profile Management, Car Routes, EV Routes, Multimodal Routes, Vehicle Reservation & Billing

Relevant Use Cases: UC1.10, UC1.11, UC1.12

INPUT PARAMETERS


Disconnection to UT‐Cloud

User credentials, so that a temporary alias can be obtained,

through the security and anonymity gateway.


D2.3: of 73

Name: EV SoC Check / Recharging



or Mobile Device

API


monitoring system, in case the user wants to depart immediately, or

from the mobile device of the user, if it is not supplied by the Travel Monitoring service or if the user decides to travel at a later time.


or Mobile Device

API

User preferences, containing optimisation criteria. If the user does not have a profile, and/or cloud information is unavailable,

the MOBILE DEVICE API is employed.

ScheduledTripInformation Complex 1 Mobile Device API

Route description for a trip that is scheduled or underway.

RouteEnergyConsumption Int 1 EV Routes Estimated energy consumption for an EV, on a given route.

BatteryCharge Int 1 Vehicle Profile Management

Battery charge percentage of a specific vehicle.

MultimodalRoutes Complex 1..* Multimodal Routes

Multimodal routes from a specified station to the final destination of

the user.

ParkingReservationResponse

Complex 1 Vehicle Reservation &

Billing

Indication of whether the parking space or a charging spot has been successfully reserved; updated user

account.

CalculateRoutes Complex 1..* EV Routes Calculate possible alternative feasible routes from the vehicle’s current location towards the

destination location. The routes will depend on the requesting user’s selected optimisation criteria and

traffic information.

OUTPUT PARAMETERS


BatteryStatus Complex 1 EV Routes Battery charge percentage and residual mileage for a specific

vehicle

IsChargeEnoughForRoute Boolean 1 EV Routes Provided a trip and a vehicle, the service informs the user whether the battery state of charge is

enough for this trip.

FeasibleTrips Complex 1..* Car Routes, EV Routes

Provides alternative feasible routes towards the user’s destination (possibly violating the user's

preferences).

ChargingStationInformation Complex 1..* EV Routes Displays information about charging stations, such as location, directions to them, availability of parking places / charging spots, (estimated) time until a parking space / charging spot becomes

available.


D2.3: of 73

Name: EV SoC Check / Recharging

RouteToDestination Complex 1..* As above Displays route plans from the vehicle's current location towards a parking/charging station, followed by multimodal trip plans until the actual destination of the user.

ActiveServiceIndicator Boolean 1 As above Indication that Vehicle EV SoC Check / Recharging is an active

service.

3.3.4 Messenger

This service will implement a bidirectional channel of communication among travellers and/or vehicles and the MOVESMART system, for traveller‐reporting and system announcements and traffic‐related updates. Name: Messenger

Type: Service Container: Messenger Functionality: Handles communication between travellers, vehicles and the

MOVESMART system.

Connections: Data Communication Interface Module, Infrastructure Reporting, UTKB Management.

Relevant Use Cases: UC3.1, UC3.2, UC3.3, UC3.4, UC3.5, UC3.6, UC3.7, UC3.8, UC3.9, UC3.10, UC3.11.

INPUT PARAMETERS

Name Data Type Cardinality Source Description PushTravellerEmegencyReport Complex 1 Crowd‐

sourcing, Mobile Device

API.

Object wrapping the emergency report posted by

the user.

PushTravellerEmegencyReport. EmergencyAlert

Complex 1..n As above Complex object that describes the

alert.

PushTravellerEmegencyReport. EmergencyAlert.type

Enum 1 As above The type of the alert (e.g. “weather”,

“traffic”, “road blockage”).

PushTravellerEmegencyReport. EmergencyAlert.severity

Enum 1 As above The degree of severity of the

alert.

PushTravellerEmegencyReport. EmergencyAlert.text

String 1 As above The message of the alert.

PushEnRouteReport Complex 1 As above Object wrapping the en‐route

reported posted by the user

PushEnRouteReport. SendReport

Complex 1..n As above Complex object that includes

information about user reporting.

PushEnRouteReport. SendReport.user_id

int 1 As above The anonymous id of the reporting


D2.3: of 73

Name: Messenger

user.

PushEnRouteReport. SendReport.road

Complex 1 As above The road to which the report refers.

PushEnRouteReport. SendReport.city

String 1 As above The name of the city in which the user is travelling.

PushEnRouteReport. SendReport.country

String 1 As above The name of the country to which the city belongs.

PushEnRouteReport. SendReport.hasIncidentType

Enum 1..n As above Gets ones of: “Road blocked”,

“accident”, “heavy showers”, “icy road”, etc.

PushFeedback Complex 1 As above Object wrapping user feedback

PushFeedback. UserSubmittedFeedback

Complex 1..n As above Complex object that includes

information about the submitted user

feedback.

PushFeedback. UserSubmittedFeedback.value

double 1 As above The value of user rating in the 0.0…5.0 scale.

PushFeedback. UserSubmittedFeedback. ServiceType

Enum 1 As above Gets ones of: “Car pooling”, “eco‐friendly route”,


PushFeedback. UserSubmittedFeedback.isLikeDislike

Boolean 1 As above If feedback is given in a like/dislike fashion, like is represented by

‘true’.

PushFeedback. UserSubmittedFeedback.userId

int 1 As above The anonymous id of the user who submits feedback.

OUTPUT PARAMETERS

Name Data Type Cardinality Destination Description SendEmergencyReport Complex 1 Data

Communication Interface

Module, UTKB Management.

Wrapper object that represents a new emergency

report

SendEmergencyReport.isValid Boolean 1 As above True if the report has been validated

by the users.

SendEmergencyReport. EmergencyAlert

Complex 1..n As above The emergency alert object. See above (Input

Parameters) for details.

SendEnRouteReport Complex 1 As above Wrapper object


D2.3: of 73

Name: Messenger

that represents a new en‐route

report.

SendEnRouteReport.isValid Boolean 1 As above True if the report has been validated

by the users.

SendEnRouteReport. PushEnRouteReport

Complex 1 As above Object representing the en‐route report posted by the user. See above (Input Parameters) for

details.

SendFeedback Complex 1 As above Wrapper object that represents user submitted

feedback.

SendFeedback.isValid Boolean 1 As above True if the report has been validated

by the users.

SendFeedback.PushFeedback Complex 1 As above Object representing the user feedback. See above (Input Parameters) for

details.

3.3.5 Mobile Device API

This service will be the API for accessing the resources of the traveller’s or the vehicle’s device. Using available routes, either with public transport or with Evs/shared EVs and available traffic prediction modules (or real time traffic information through crowd‐sourcing) the API will provide the user with directions from his starting point to his destination. This can be either developed in PND device or in a mobile device running Android. Name: Mobile Device API

Type: GUI Service Container: Functionality: Handles communication between travellers, vehicles, the

MOVESMART system and the mobile or PND device users.

Connections: Data Communication Interface Module, Infrastructure Reporting, UTKB Management, Park and Ride, Renewable MOD.

Relevant Use Cases: All

INPUT PARAMETERS

Name Data Type Cardinality Source Description EVRouteResponse[i].routeInfo complex 1 EV routes A complex route response object

that holds key information about the i‐th calculated route (total distance, travel time, energy efficiency assessment, predicted traffic situation information, etc.)

EVRouteResponse[i].route complex 1 EV routes Detailed description of the i‐th calculated route such as the list of in‐between road segments on


D2.3: of 73

Name: Mobile Device API

the computed route SharedEVRouteResponse complex 1 EV routes A complex response object to

shared EV route queries listing one (or several) routes

SharedEVRouteResponse[i].routeInfo complex 1 EV routes A complex route response object that holds key information about the i‐th calculated route (total distance, travel time, energy efficiency assessment, predicted traffic situation information, price, etc.)

SharedEVRouteResponse[i].route complex 1 EV routes Detailed description of the i‐th calculated route such as the list of in‐between road segments on the computed route

SharedEVRouteResponse[i].sharedEV shared EV identifier

1 EV routes The shared EV that the user will use for the i‐th route. This EV must be reserved for the user through the Vehicle Reservation & Billing service

IsActiveServiceResponse Boolean

1 EV routes Response to determine if EV Routes service is active and provides routing for the traveller

IsActiveServiceResponse True/False 1 Bicycle routes

Response to determine if Bicycle Routes service is active and provides routing for the traveller

CarRouteResponse list 1 Car routes A complex response object to car route queries listing one (or several) routes (the response object is the same for CarRouteRequest and CarRouteRequestOffline)

CarRouteResponse[i]..routeInfo complex 1 Car routes A complex route response object that holds key information about the i‐th calculated route (total distance, travel time, energy efficiency assessment, predicted traffic situation information, etc.)

CarRouteResponse[i]..route complex 1 Car routes Detailed description of the i‐th calculated route such as the list of in‐between road segments on the computed route

IsActiveServiceResponse Boolean

1 Car routes Response to determine if Car Routes service is active and provides routing for the traveller

AltRouteResponse list 1 Routes On Demand (ROD)

A complex response object to multimodal route queries listing one route

AltRouteResponse.routeInfo complex 1 ROD A complex route response object that holds key information about the calculated route (total distance, travel time, energy efficiency assessment, predicted


D2.3: of 73


traffic situation information, etc.)

AltRouteResponse.route complex 1 ROD Detailed description of the calculated route such as the list of in‐between road segments on the computed route

AltRouteResponse.sharedEV shared EV identifier

1 ROD The shared EV that the user will use for the route. This EV must be reserved for the user through the Vehicle Reservation & Billing service

MMRouteResponse list 1 Multimodal Routes

A complex response object to multimodal route queries listing one (or several) routes (the response object is the same for MMRouteRequest and MMRouteRequestOffline)

MMRouteResponse[i].routeInfo complex 1 Multimodal Routes

A complex route response object that holds key information about the calculated route (total distance, travel time, energy efficiency assessment, predicted traffic situation information, etc.)

MMRouteResponse[i].route complex 1 Multimodal Routes

Detailed description of the calculated route such as the list of in‐between road segments on the computed route

MMRouteResponse[i].sharedEV shared EV identifier

1 Multimodal Routes

The shared EV that the user will use for the route. This EV must be reserved for the user through the Vehicle Reservation & Billing service

IsActiveServiceResponse True/False 1 Multimodal Routes

Response to determine if Multimodal Routes service is active and provides routing for the traveller

OUTPUT PARAMETERS

Name Data Type Cardinality Destination Description EVRouteRequest complex 1 EV Routes A complex request object for

querying EV routes

EVRouteRequest.fromCoord WGS84 latitude, longitude

1 EV routes Origin coordinate of the requested route

EVRouteRequest.toCoord WGS84 latitude, longitude

1 EV routes Destination coordinate of the requested route

EVRouteRequest.timeLeaving Time 1 EV routes departure time

EVRouteRequest.soc Floating point

number (%)

1 EV routes Current state of charge of the vehicle (in %)

EVRouteRequestOffline complex 1 EV routes A complex request object for


D2.3: of 73


querying EV routes offline (when there is no connection to the

cloud)

EVRouteRequestOffline.fromCoord WGS84 latitude, longitude


EVRouteRequestOffline.toCoord WGS84 latitude, longitude


EVRouteRequestOffline.timeLeaving Time 1 EV routes departure time

EVRouteRequestOffline.soc Floating point

number(%)

1 EV routes Current state of charge of the vehicle (in %)

EVRouteRequestOffline.Preferences complex 1 EV routes The user preferences which includes the optimisation criterion, e.g. fastest, eco

friendly

SharedEVRouteRequest complex 1 EV routes A complex request object for querying EV routes

SharedEVRouteRequest.fromCoord WGS84 latitude, longitude


SharedEVRouteRequest.toCoord WGS84 latitude, longitude


SharedEVRouteRequest.timeLeaving Time 1 EV routes departure time

BikeRouteRequest complex 1 Bicycle routes

A complex request object for querying bicycle routes

BikeRouteRequest.fromCoord WGS84 latitude, longitude

1 Bicycle routes


BikeRouteRequest.toCoord WGS84 latitude, longitude

1 Bicycle routes


BikeRouteRequest.timeLeaving Time 1 Bicycle routes

departure time

BikeRouteRequestOffline complex 1 Bicycle routes

A complex request object for querying bicycle routes

BikeRouteRequestOffline.fromCoord WGS84 latitude, longitude

1 Bicycle routes


BikeRouteRequestOffline.toCoord WGS84 latitude, longitude

1 Bicycle routes


BikeRouteRequestOffline.timeLeaving Time 1 Bicycle routes

departure time

EBikeRouteRequest complex 1 Bicycle routes

A complex request object for querying e‐bike routes

EBikeRouteRequest.fromCoord WGS84 latitude, longitude

1 Bicycle routes


EBikeRouteRequest.toCoord WGS84 latitude,

1 Bicycle routes



D2.3: of 73


longitude EBikeRouteRequest.timeLeaving Time 1 Bicycle

routes departure time

EBikeRouteRequest.soc Floating point

number (%)

1 Bicycle routes


EBikeRouteRequestOffline complex 1 Bicycle routes

A complex request object for querying e‐bike routes

EBikeRouteRequestOffline.fromCoord WGS84 latitude, longitude

1 Bicycle routes


EBikeRouteRequestOffline.toCoord WGS84 latitude, longitude

1 Bicycle routes


EBikeRouteRequestOffline.timeLeaving Time 1 Bicycle routes

departure time

EBikeRouteRequestOffline.soc Floating point

number (%)

1 Bicycle routes


EBikeRouteRequestOffline.Preferences complex 1 Bicycle routes

The user preferences which includes the optimisation criterion, e.g. fastest, eco

friendly

ShareEBikeRouteRequest complex 1 Bicycle routes

A complex request object for querying shared bicycle/e‐bike

routes

ShareEBikeRouteRequest.fromCoord WGS84 latitude, longitude

1 Bicycle routes


ShareEBikeRouteRequest.toCoord WGS84 latitude, longitude

1 Bicycle routes


ShareEBikeRouteRequest.timeLeaving Time 1 Bicycle routes

departure time

IsActiveServiceRequest ‐ 1 Bicycle routes

Request to determine if Bicycle Routes service is active and

provides routing for the traveller

CarRouteRequest complex 1 Car routes A complex request object for querying routes

CarRouteRequest.fromCoord WGS84 latitude, longitude

1 Car routes Origin coordinate of the requested route

CarRouteRequest.toCoord WGS84 latitude, longitude

1 Car routes Destination coordinate of the requested route

CarRouteRequest.timeLeaving Time 1 Car routes departure time CarRouteRequestOffline complex 1 Car routes A complex request object for

querying car routes offline (when there is no connection to

the cloud) CarRouteRequestOffline.fromCoord WGS84 1 Car routes Origin coordinate of the


D2.3: of 73


latitude, longitude

requested route

CarRouteRequestOffline.toCoord WGS84 latitude, longitude

1 Car routes Destination coordinate of the requested route

CarRouteRequestOffline.timeLeaving Time 1 Car routes departure time CarRouteRequestOffline.Preferences complex 1 Car routes The user preferences which

includes the optimisation criterion, e.g. fastest, eco

friendly IsActiveServiceRequest Complex 1 Car routes Request to determine if Car

Routes service is active and provides routing for the traveller

ActiveRouteService Text 1 ROD The currently active Routes Service

(EV/CAR/BICYCLE/MULTIMODAL) if there is one

AltRouteRequest complex 1 ROD A complex request object for querying EV routes

AltRouteRequest.fromCoord WGS84 latitude, longitude

1 ROD Current position of the user

AltRouteRequest.time Time 1 ROD Current time AltRouteRequest.soc Floating

point number (%)

1 ROD Current state of charge of the vehicle (in %)

MMRouteRequest.fromCoord WGS84 latitude, longitude

1 Multimodal Routes


MMRouteRequest.toCoord WGS84 latitude, longitude

1 Multimodal Routes


MMRouteRequest.timeEarliest Date 1 Multimodal Routes

Earliest departure (or arrival, see below) time and date

MMRouteRequest.timeLatest Date 1 Multimodal Routes

Latest departure (or arrival, see below) time and date

MMRouteRequest.depOrArr

Boolean

1 Multimodal Routes

Meaning of timeEarliest and timeLatest

False: departure True: Arrival

MMRouteRequestOffline complex 1 Multimodal Routes

A complex request object for querying multimodal routes

MMRouteRequestOffline.fromCoord WGS84 latitude, longitude

1 Multimodal Routes


MMRouteRequestOffline.toCoord WGS84 latitude, longitude

1 Multimodal Routes


MMRouteRequestOffline.timeEarliest Date 1 Multimodal Routes

Earliest departure (or arrival, see below) time and date

MMRouteRequestOffline.timeLatest Date 1 Multimodal Routes

Latest departure (or arrival, see below) time and date

MMRouteRequestOffline.depOrArr Boolean 1 Multimodal Meaning of timeEarliest and


D2.3: of 73


Routes timeLatestFalse: departure True: Arrival


1 EV sharing The starting GPS location as acquired from the traveller

monitoring system, in case the user wants to depart

immediately, or from the mobile device of the user, if it is not

supplied by the Travel Monitoring service or if the user decides to travel at a later time.


1 EV sharing The GPS location of the trip destination.

UserPreferences Complex 1 EV sharing User preferences, such as departure time, expected rental

duration, opt‐in to the incentivised vehicle sharing

scheme, intention to use public transport or carpooling. If the user does not have a profile, and/or cloud information is



1 Vehicle pooling






1 Vehicle pooling


UserPreferences Complex 1 Vehicle pooling

User preferences, such as departure time, pooling request type (“offer” or “join”), capacity restrictions for ‘offer’ requests (i.e. seats available) and capacity requirements for ‘join’ requests (i.e. seats requested), fellow

passenger restrictions (e.g. age, gender). If the user does not have a profile, and/or cloud

information is unavailable, the MOBILE DEVICE API is employed.


1 EV/Bicycle on demand

The current GPS location as acquired from the traveller

monitoring system or from the mobile device of the user.

EndingLocation WGS84 1 EV/Bicycle The GPS location of the trip


D2.3: of 73


latitude, longitude

on demand destination.

UserPreferences Complex 1 EV/Bicycle on demand

User preferences, such as expected rental duration (for EV sharing options), opt‐in to the incentivised vehicle sharing

scheme, intention to use public transport or carpooling. If the user does not have a profile, and/or cloud information is



1 EV SoC Check /

Recharging





UserPreferences Complex 1 EV SoC Check /

Recharging

User preferences, containing optimisation criteria. If the user does not have a profile, and/or cloud information is unavailable,

the MOBILE DEVICE API is employed.

ScheduledTripInformation Complex 1 EV SoC Check /

Recharging

Route description for a trip that is scheduled or underway.

PushTravellerEmegencyReport Complex 1 Messenger Object wrapping the emergency report posted by the user.

PushTravellerEmegencyReport. EmergencyAlert

Complex 1..n Messenger Complex object that describes the alert.

PushTravellerEmegencyReport. EmergencyAlert.type

Enum 1 Messenger The type of the alert (e.g. “weather”, “traffic”, “road

blockage”).

PushTravellerEmegencyReport. EmergencyAlert.severity

Enum 1 Messenger The degree of severity of the alert.

PushTravellerEmegencyReport. EmergencyAlert.text

String 1 Messenger The message of the alert.

PushEnRouteReport Complex 1 Messenger Object wrapping the en‐route reported posted by the user

PushEnRouteReport. SendReport

Complex 1..n Messenger Complex object that includes information about user

reporting.

PushEnRouteReport. SendReport.user_id

int 1 Messenger The anonymous id of the reporting user.

PushEnRouteReport. SendReport.road

Complex 1 Messenger The road to which the report refers.

PushEnRouteReport. SendReport.city

String 1 Messenger The name of the city in which the user is travelling.

PushEnRouteReport. SendReport.country

String 1 Messenger The name of the country to which the city belongs.


D2.3: of 73


PushEnRouteReport. SendReport.hasIncidentType

Enum 1..n Messenger Gets ones of: “Road blocked”, “accident”, “heavy showers”,

“icy road”, etc.

PushFeedback Complex 1 Messenger Object wrapping user feedback

PushFeedback. UserSubmittedFeedback

Complex 1..n Messenger Complex object that includes information about the submitted

user feedback.

PushFeedback. UserSubmittedFeedback.value

double 1 Messenger The value of user rating in the 0.0…5.0 scale.

PushFeedback. UserSubmittedFeedback. ServiceType

Enum 1 Messenger Gets ones of: “Car pooling”, “eco‐friendly route”, “safest

route”, etc.

PushFeedback. UserSubmittedFeedback.isLikeDislike

Boolean 1 Messenger If feedback is given in a like/dislike fashion, like is represented by ‘true’.

PushFeedback. UserSubmittedFeedback.userId

int 1 Messenger The anonymous id of the user who submits feedback.

4 Infrastructural & Data Format Specifications

4.1 Hardware Requirements

Cloud Requirements

The hardware cloud requirements for implementing the envisaged services are depicted in the Following figures. The required cloud infrastructure that will be dedicated to the needs of the project comprise two clusters, namely one KVM/NFS cluster (Figure 2) and one KVM/CEPH Cluster (Figure 3). The required key for reading those diagrams is shown in Figure 4.

Figure 2: KVM/NFS Cluster 1


D2.3: of 73

Figure 3: KVM/CEPH Cluster 2

Figure 4: The KEY for KVM/NFS Cluster 1 and KVM/CEPH Cluster 2 diagrams

Above are network diagrams of the 2 proposed FCO research platform clusters which the MOVESMART cloud will be hosted upon. This has the following hardware: KVM / NFS Cluster Compute Node 64GB RAM

2 X 6 Core CPUs 2 x 1GB/s NICs with PXE capability No Local Storage

16TB NFS Storage

KVM / CEPH Cluster CEPH Compute Nodes 32GB RAM, 16 Core CPU, 12 x 2TB Disk, 2 x 1GB NIC with PXE capability, 2 x 10GB NIC with PXE capability.

Storage is local

This currently allows for the creation of servers up to a spec of 4GB RAM & 4 CPUs with a max disk size of 500GB. These maximums can be extended on a per case basis as to not consume all platform resources where not required.

Portable Device Requirements

The portable device requirements, in the hardware level, in order to implement MOVESMART’s designed multi modal mobility algorithms for several types of users, scenarios and Use Cases are the following:

WI‐FI

GPS

Data access contract for user with a Mobile Provider or access to the internet and MOVESMART database through WI‐FI Hot Spots


D2.3: of 73

4.2 Software Requirements

Cloud Requirements

The MOVESMART platform will come with the following OS images installed as standard from which each server can be created:

CentOS 6.4

Ubuntu 12.04

Windows 2008

Windows 2012 Further images can be created upon request where a requirement is needed. An SQL database will also be provisioned for database use for the profile management. A server will be created in a MOVESMART account on the platform and the database will be set up ready for use by the other partners to populate. FCO also has a feature of built in software firewalls which may be configured to prevent unauthorised access to the private network holding all of the personal data. There is also a capability of the FCO platform to allow role based group access accounts to provide a further layer of software security to the platform to allow only authorised users to access the servers and services therein that will hold all of the key data on the MOVESMART system.

Portable Device Requirements

The Operating System (OS) that is used by almost 80% of the mobile phones sold internationally is Android, and MLS has adapted to this global trend, although there is also a small possibility to develop in i‐phone if urgently needed. There are several versions of Android mobile Operating System, with the last one being 5.0 (Lollipop). The level of the several APIs (Application Programming Interface) and their compatibility depends, in general, on the version, but it’s expected that for the API of MOVESMART, there won’t be any compatibility issues, since it will use basic activities and services that run usually in all versions. In addition, typically MLS has available Mobile Devices and can provide flashed ones running all versions of Android after 4.0. However, it will be better to build and run the API using one of the latest versions available, but this will be decided and finalised during the course of the project. MLS’s team of developers and programmers are capable of developing, testing and running the API.

Core‐Traffic Services Requirements

Computation of time‐dependent and multimodal routes, especially when integrating changes in the road or public transportation network on the fly, is a computationally demanding problem thus extensive processing and storage capacity is required. This becomes even more obvious when considering that the core TD‐routing services must be able to handle multiple requests at the same time (i.e., in parallel), and also be able to digest live‐traffic reporting by the crowd‐sourcing and the traffic prediction modules of MOVESMART. Previous experience1 2 of our consortium on providing speedup techniques and distance oracles for TD‐routing of private cars in urban areas that are efficient and fast in practice, in particular achieving response times to queries within a few milliseconds, has shown that it is a very challenging task, both in theory and in practice. For example, it is well known that even storing an exact shortest travel‐

1 Spyros Kontogiannis, Christos Zaroliagis: Distance oracles for time-dependent networks. In J. Esparza et al. (eds.), ICALP 2014, Part I, volume 8572 of LNCS, pages 713-725. Springer-Verlag Berlin Heidelberg, 2014. 2 Spyros Kontogiannis, George Michalopoulos, Georgia Papastavrou, Andreas Paraskevopoulos, Dorothea Wagner, Christos Zaroliagis: Analysis and Experimental Evaluation of Time-Dependent Distance Oracles. In ALENEX 2015.


D2.3: of 73

time function for a given origin‐destination pair of nodes, would require space which superpolynomial in the size of the network3. On the other hand, if we accept only (slightly) approximate distance functions, then each of them would require much smaller space which allows for it being used as preprocessed traffic metadata requiring only sublinear space (in theory), which then amounts to a few decades of Gigabytes for large‐scale urban‐traffic environments (cf. footnotes 1 2). Therefore, the following computational and storage specifications are deemed sufficient to handle the workload of the algorithms, when considering a stand‐alone dedicated routing server and urban areas with hundreds of thousands of vertices and millions of arcs: The precomputed traffic metadata is expected to require at most a few decades of Gigabytes. To be able to have all data structures, important metadata, as well as the routing data and precomputed information available in the main memory of the server in order to efficiently respond to real‐time queries, an amount of RAM of 64 GiB would thus be an appropriate requirement. For storing all the information that is necessary for routing (e.g., graph data structure, street names, traffic‐metadata for private cars, EVs, and public transport time tables), for all modes of transport to be considered, 500 GiB of hard disk memory, preferably fast solid‐state disk, would also be sufficient. In order to achieve response times within a few milliseconds per routing request, the processor must be a relatively modern CPU (preferably a quad core CPU such as Intel’s i5‐2500 with a clock speed of 3.3 GHz). Finally, the operating system of the dedicated routing server we have used in all our experimental works, was a relatively modern Linux system (e.g., Ubuntu 12.04). The above mentioned requirements correspond to a cloud‐free solution, i.e. they correspond to the recommended specifications of a standalone server that we used for laboratory experiments. Since MOVESMART is a cloud‐based system, the preprocessing techniques for the maintenance of the traffic metadata and the core traffic services will be hosted mainly by a collection of virtual machines with analogous computational capabilities that will cumulatively cover these hardware requirements, exploiting the inherent parallelism of the traffic‐metadata maintenance operations, particularly for the demanding updating phase which has to be done essentially in real‐time. In case of a necessity for faster or more frequent maintenance operations within the UTKB (e.g., for updating in real‐time the traffic metadata, or due to increased streams of traveller traffic reports via the Crowdsourcing Mechanism), this can be dealt with by exploiting the inherent scalability of the UT‐Cloud architecture. The aforementioned hardware needs are specified in order to facilitate the selection of the virtual machine(s) that will be used (minimum requirements) for the initial installation of the proposed solutions within MOVESMART for providing in real‐time core TD routing and personalized mobility services to the travelers. In certain exceptional cases where the scalability of the UT‐Cloud platform will not fulfil the technical requirements of certain real‐time core traffic services that need to be executed on a single machine, the alternative of a dedicated routing server will also be considered as a way‐out.

4.3 Supported Data Formats

4.3.1 Raw Data Formats

User Generated Reports

Regarding the reports that are generated by the users, these will be sent via the underpinning communication infrastructure (e.g. 3G) to the MOVESMART cloud for further processing, i.e. validation and publishing. One critical point regarding the communication between the user’s device and the cloud infrastructure for user generated reports is the response time. Given the bandwidth limitations of the communication network, it is necessary to keep the response times as low as possible in order to ensure close to real time communication. For this reason, we propose to use a

3 Luca Foschini, John Hershberger, and Subhash Suri: On the complexity of time-dependent shortest paths. Algorithmica, 68(4):1075{1097, 2014. Preliminary version in ACM-SIAM SODA 2011.


D2.3: of 73

data model that is resource efficient, being also expressive enough in order to sufficiently encapsulate all necessary information coming from the user.

One such data representation schema that fulfils these requirements, and is also very popular in the mobile application programming world is JSON4 (JavaScript Object Notation), a lightweight data‐interchange format. JSON is a text format that is completely language independent, but also human readable. Due to its small size it is an ideal option when transfer of data is concerned in a limited bandwidth mobile communication network.

When user‐generated reports need to be sent, these will be encoded according to the JSON format and will contain the following fields: The fields of user‐generated data to be modeled at this level are shown in the following table.

Table 1: User‐generated (en‐route) report structure

Field Type Description

UUID String The anonymous id of the reporting user.

Road_id Int The road to which the report refers.

City String The name of the city in which the user is travelling.

Country String The name of the country to which the city belongs.

incidentType Enum Gets ones of: “Road blocked”, “accident”, “heavy showers”, “icy road”, etc.

Time Integer The current time in msec of the user generated report

Hence, the JSON representation of an example message would like the one illustrated in the Figure below.

{"report": { "uuid": "eh7d8kj", "road_id": "3421",

"city": "London", "enum": { "incidentType": [ {"value": "Accident", "selected": "n"}, {"value": "Road Blocked", "selected": "y"}, {"value": "Icy Road", "selected": "n"} ] }

"country": "UK" }}

Figure 5. JSON representation of a user‐generated report example

Emergency Reports

In the case of an emergency report, the data structure of the message to be sent by the user is going to be in JSON format. The required fields and its types are explained in the following table below.

Table 2: Emergency report fields

4 http://json.org/


D2.3: of 73

Field Type Description

UUID String The anonymous id of the reporting user.

Type String The type of the alert (e.g. “weather”, “traffic”, “road blockage”).

Severity String The degree of severity of the alert.

Text String The message of the alert.

Hence, an emergency report in JSON format looks like the example below. {"emergency-report": { "uuid": "eh7d8kj", "type": "road-accident",

"severity": "high", "text": "A new accident on Elm Street 28. Please avoid." }

} Figure 6. JSON representation of a user‐generated report example

Weather Data

For weather data representation, simple XML‐based structures can be used based on well known approaches. One recommended data structure about weather data that works well in practice is the one adopted in the eCOMPASS project, which takes into account some fields defined in the DATEX II format. This is depicted in the following figure in the form of UML classes5. This data format can form the basis of the MOVESMART data model where fields that are not necessary can be omitted in the future.

Points of Interest

Based on our previous experience, the de facto data format to be used for Points of Interest (POIs) will be Google Transit Data Feed Specification (GTFS)6. For further details the interested reader may refer to the official GTFS documentation page (see footnote 3 at the bottom of this page).

5 eCOMPASS Deliverable D4.1.2: Communication Interfaces supporting the most prominent standards, September 2012, © eCOMPASS Consortium. 6 https://developers.google.com/transit/gtfs/reference


D2.3: of 73

Figure 7. Graphical UML representation of the eCOMPASS Weather data XML schema.

Suggested Route Plans

Since the MOVESMART routing services (e.g., TD Routing) provide paths as a result (if a route can be found) to different kinds of routing requests, we require a flexible data format for exchanging this information. A file format for doing this is the Keyhole Markup Language (KML) which shares many similarities with the eXtensible Markup Language (XML) that is used for many real‐world applications. However, there are some limitations to the KML format which may make using KML for MOVESMART unsuitable. Therefore, we might consider using Javascript Object Notation (JSON) which is commonly used format to exchange information between online applications especially, when Javascript is used. The advantage of JSON is that it can easily be extended and it is possible to attach more information to the path itself (e.g., specific information about the legs of a multimodal route). The road network as well as all pre‐computed data will be stored as a proprietary binary format on the MOVESMART UT‐cloud’s storage.

4.3.2 Traffic Metadata Formats

For maintaining traffic‐metadata, the UTKB module will use proprietary data formats that are dependent on the particular traffic services exploiting them. Nevertheless, the utmost effort will be made to make the employed formats resemble as much as possible the data formats of the corresponding raw traffic data, so that scalability and uniformity is assured for the methods exploiting both raw data and traffic‐metadata. The consortium’s great expertise on maintaining such kind of metadata will be exploited, particularly for private cars and public‐transport media, from the project eCOMPASS.

class WeatherDataTypes

«XSDcomplexType»WeatherItem

+ title: string [0..1]+ description: string [0..1]+ location: PointCoordinates+ publicationDate: DateTime+ city: string [0..1]+ country: string [0..1]

«XSDcomplexType»WeatherCondition

+ description: string+ temperature: float+ units: string+ timeDate: DateTime

«XSDcomplexType»WeatherForecast

+ description: string+ date: date+ dayOfTheWeek: string+ low: float+ high: float+ units: string

«XSDcomplexType»WeatherRelatedRoadConditions

+ conditionType: WeatherRelatedRoadConditionTypeEnum+ location: PointCoordinates+ date: DateTime

«enumeration»DATEX II::

WeatherRelatedRoadConditionTypeEnum

blackIce deepSnow dry freezingOfWetRoads freezingPavements freezingRain freshSnow ice iceBuildUp iceWithWheelBarTracks icyPatches looseSnow normalWinterConditionsForPedestrians packedSnow roadSurfaceMelting slipperyRoad slushOnRoad slushStrings snowDrifts snowOnPavement snowOnTheRoad surfaceWater wet wetAndIcyRoad wetIcyPavement other

«XSDcomplexType»WeatherElementWind

+ chill : int+ direction: int+ speed: int+ speedUnit: string

«XSDcomplexType»WeatherElementAtmoshpere

+ humidity: int+ visibi li ty: int+ pressure: float+ pressureUnit: string+ rising: PressureRisingEnum [0..1]

string

«enumeration»PressureRisingEnum

fall ing rising steady

1+hasWeatherItem

0..1

+rising

0..1

+hasWindInfo

0..1

+hasWindInfo

0..1

+hasAtmosphereInfo


D2.3: of 73

5 Dependencies among Services

Figure 8 shows the interdependencies among the distinct services of the MOVESMART system, with incoming and outgoing arrows that represent the information that flows between modules.

DATA COMMUNICATION INTERFACE MODULE

INTEGRATED PERSONAL MOBILITY APPLICATIONS MODULE

CLOUD MANAGEMENT MODULE

CORE TRAFFIC SERVICES MODULE

WeatherEmergencies

Fixed-Point Traffic Monitoring Reports

TravelerEmergencies

UTKB MANAGEMENT

Historic(Time Dependent)

Traffic Data Repository

TRAFFIC PREDICTION

EV / BICYCLE AVAILABILITY

TRAVELER INCENTIVISING &

REWARDING

ENERGY EFFICIENCY

ASSESSMENT

EV ROUTESVEHICLE POOLING

TRAVELER MONITORING

PND Cached Replica of Historic (TD) Traffic Data

Like / Dislike Reports

EV / BICYCLE ON DEMAND

En-Route Reports

EMERGENCY PUSH

PoliceEmergencies

TD ROUTING

MOBILE DEVICE API

MULTIMODAL ROUTES

Weather Forecasting

USER PROFILE MANAGEMENT

VEHICLE PROFILE

MANAGEMENT

SERVICE PROFILE

MANAGEMENT

CONNECTION /DISCONNECTION

TO UT-CLOUD

PROFILES MANAGEMENT

RENEWABLE MOBILITY ON DEMAND

ENTITY MONITORING

PARK & RIDE

EV SoC CHECKING /

RECHARGING

ROUTE ON DEMAND

VEHICLE RESERVATION &

BILLING

EV / BIKE FLEET RELOCATION &

PRICING POLICY

SECURITY & ANONYMITY GATEWAY

BICYCLE ROUTES

CAR ROUTES

TRAVELER REPORTING

INFRASTRUCTURE REPORTING

CROWDSOURCING TRAFFIC MANAGEMENT

REPORT TRACKING &

SIGNIFICANCE ASSESSMENT

PERIODIC REPORTS

PUSH

POST-ROUTE REPORTS

PUSH

MESSENGER

EV SHARING

LEGEND

request data

provides input

maintains

access device

Figure 8: Interdependencies between the various MOVESMART services

These interdependencies will form the basis for the intercommunication data flow between the various modules to be defined in the next deliverable D2.4 “MOVESMART System Architecture”.

6 Conclusions

The present document provides a comprehensive service‐oriented view of the MOVESMART system focusing on its major software modules, namely: the Profile‐Management, the Entity‐Monitoring, the Data Communication, the Traffic‐Management, the Crowd‐sourcing, the Traffic‐Prediction, the UTKB‐Management, the Park‐And‐Ride, and the Renewable‐Mobility‐On‐Demand modules. It provides critical abstractions with which it is possible to reason about and describe the structure and behaviour of a system. This will provide critical information to several stakeholders, e.g. the users, module developers and integrators to discuss about architectural issues in the ongoing development processes in a more efficient and effective way.

In the forthcoming architectural diagram of the MOVESMART system (deliverable D2.4), the system will be further analysed into a number of components following a more hierarchical structure. Based on the adopted design methodology for the technical specifications, and the forthcoming architectural design of the MOVESMART system, it is expected that in the near future no major interventions will be required. However, minor refinements are still possible that might be necessary in case of a new unforeseen limitation that comes up during the implementation phase.

d2.3 movesmart technical specificationsmovesmartfp7.iti.gr/movesmartfp7/wp-content/... · in this...

Documents