d2.3 movesmart technical specificationsmovesmartfp7.iti.gr/movesmartfp7/wp-content/... · in this...
Post on 28-Jun-2020
2 Views
Preview:
TRANSCRIPT
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 1 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.
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 2 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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 4 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.
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 5 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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 6 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.
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 7 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).
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 8 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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 9 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
Name Data Type Cardinality Source Description
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 10 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
Name Data Type Cardinality Destination Description
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
Name Data Type Cardinality Source Description
UUID String 1 Profile Unique identifier
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 11 of 73
Name: Traveller Monitoring
Management for a user
OUTPUT PARAMETERS
Name Data Type Cardinality Destination Description
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
Container: Entity Monitoring
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
Name Data Type Cardinality Source Description
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
Name Data Type Cardinality Destination Description
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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 12 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
Container: Entity Monitoring
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
Name Data Type Cardinality Source Description
UUID String 1 Security & Anonymity Gateway
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
Name Data Type Cardinality Destination Description
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
Container: Entity Monitoring
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 13 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
Name Data Type Cardinality Source Description
UUID String 1 Security & Anonymity Gateway
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
Name Data Type Cardinality Destination Description
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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 14 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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 15 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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 16 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
Periodic Reports Push
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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 17 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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 18 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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 19 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.
Periodic Reports Push
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.
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 20 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
Name Data Type Cardinality Source Description
No input parameters are associated to this service.
OUTPUT PARAMETERS
Name Data Type Cardinality Destination Description UserPeriodicReport Complex 1 UTKB
Management, Data
Communication Interface Module,
Infrastructure Reporting, Traveller Reporting.
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.
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 21 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
Communication Interface Module,
Infrastructure Reporting, Traveller Reporting.
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”,
“safest route”, etc.
UserSubmittedFeedback.isLikeDislike Boolean 1 As above If feedback is given in a
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 22 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
Name Data Type Cardinality Source Description
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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 23 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
EV / Bicycle Availability
The vehicle demand by area
AreaVehicleDemand.EV list 1
EV / Bicycle Availability
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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 24 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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 25 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
Management Sub‐module
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 /
Traffic Management Sub‐module
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.
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 26 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 /
Traffic Management Sub‐module
A complex response object representing the energy efficiency assessment of the provided route
EnergyEfficiencyAssessmentResponse. RouteInfo
complex 1 TD Routing / Traffic
Management Sub‐module
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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 27 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
WGS84 latitude, longitude
1 Renewable MOD Sub‐module
EV‐Fleet
Management Service
Origin coordinate of the requested route
TimeDependentRouteRequest. toCoord
WGS84 latitude, longitude
1 Renewable MOD Sub‐module
EV‐Fleet
Management Service
Destination coordinate of the requested route
TimeDependentRouteRequest. earliestTimeLeaving
time 1 Renewable MOD Sub‐module
EV‐Fleet
Management Service
Earliest departure time
(if not immediate)
TimeDependentRouteRequest. latestTimeLeaving
time 1 Renewable MOD Sub‐module
EV‐Fleet
Management Service
Latest departure time
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 28 of 73
Name: TD Routing TimeDependentRouteRequest. 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
AltRouteRequest complex 1 Renewable MOD Sub‐module
EV‐Fleet
Management Service
A complex request object for querying alternative routes
AltRouteRequest. fromCoord
WGS84 latitude, longitude
1 Renewable MOD Sub‐module
EV‐Fleet
Management Service
Origin coordinate of the requested route
AltRouteRequest. toCoord
WGS84 latitude, longitude
1 Renewable MOD Sub‐module
EV‐Fleet
Management Service
Destination coordinate of the requested route
AltRouteRequest. timeLeaving
time 1 Renewable MOD Sub‐module
EV‐Fleet
Management Service
Departure time (if not immediate)
AltRouteRequest. Preferences
complex 1 Renewable MOD Sub‐module
EV‐Fleet
Management Service
The user preferences, such as
number of alternatives (or
density of alternative graph), avoid freeways, or the optimisation
criterion, e.g. fastest, eco, robust
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‐
Origin coordinate of the requested route
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 29 of 73
Name: TD Routing
longitude module
EV‐Fleet Management
Service MultiCriteriaRouteRequest. toCoord
WGS84 latitude, longitude
1 Renewable MOD Sub‐module
EV‐Fleet
Management Service
Destination coordinate of the requested route
MultiCriteriaRouteRequest. timeLeaving
time 1 Renewable MOD Sub‐module
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
(UI), Itinerary‐planning module
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
1 Renewable MOD Sub‐module
EV‐Fleet
Management Service
Origin coordinate of the requested robust
route
RobustRouteRequest.toCoord WGS84 latitude, longitude
1 Renewable MOD Sub‐module
EV‐Fleet
Destination coordinate of the requested robust
route
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 30 of 73
Name: TD Routing
Management Service
RobustRouteRequest.timeLeaving time 0..1 Renewable MOD Sub‐module
EV‐Fleet
Management Service
Departure time (if not immediate)
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
complex 1 Renewable MOD Sub‐module
EV‐Fleet
Management Service
A complex route response object that
holds key information about the calculated route
(total distance, travel time, eco‐friendliness etc.)
SimpleRouteResponse. route
complex 1 Renewable MOD Sub‐module
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
complex 1 Renewable MOD Sub‐module
EV‐Fleet
Management Service
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.)
TimeDependentRouteResponse[i]. complex 1 Renewable Detailed description
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 31 of 73
Name: TD Routing path MOD Sub‐
module
EV‐Fleet Management
Service
of the ith calculated route such as the list of in‐between road segments on the computed route
TimeDependentRouteResponse. bestDepartureTime
time 1 Renewable MOD Sub‐module
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
complex 1 Renewable MOD Sub‐module
EV‐Fleet
Management Service
A complex route response object that
holds key information about the ith calculated route such as the route metrics total distance, travel time, eco‐friendliness, reliability etc.
AltRouteResponse[i]. path
complex 1 Renewable MOD Sub‐module
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
complex 1 Renewable MOD Sub‐module
EV‐Fleet
Management Service
A complex route response object that
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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 32 of 73
Name: TD Routing path MOD Sub‐
module
EV‐Fleet Management
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
(UI), Itinerary‐planning module
A complex response object to multi‐modal route queries listing the compute routes (if any)
MultimodalRouteResponse[i]. routeInfo
complex 1 Multi‐Modal Transport Application
(UI), Itinerary‐planning module
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
(UI), Itinerary‐planning module
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
A complex route response object that
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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 33 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
Name Data Type Cardinality Source Description
UUID String 1 Security & Anonymity Gateway
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
Name Data Type Cardinality Destination Description
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,
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 34 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
Name Data Type Cardinality Source Description
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
WGS84 latitude, longitude
1 Traveller Monitoring
or Mobile Device
API
Origin coordinate of the requested route
EVRouteRequest. toCoord
WGS84latitude, longitude
1 Mobile Device API
Destination coordinate of the requested route
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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 35 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
SimpleRouteRequest. fromCoord
WGS84 latitude, longitude
1 TD Routing Origin coordinate of the requested route
SimpleRouteRequest. toCoord
WGS84 latitude, longitude
1 TD Routing Destination coordinate of the requested route
SimpleRouteRequest. timeLeaving
Time 1 TD Routing departure time
SimpleRouteRequest. batteryCharge
Int 1 TD Routing Current state of charge of the vehicle (in %)
SimpleRouteRequest. Preferences
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
TimeDependentRouteRequest. fromCoord
WGS84 latitude, longitude
1 TD Routing Origin coordinate of the requested route
TimeDependentRouteRequest. toCoord
WGS84 latitude, longitude
1 TD Routing Destination coordinate of the requested route
TimeDependentRouteRequest. earliestTimeLeaving
Time 1 TD Routing departure time
TimeDependentRouteRequest. latestTimeLeaving
Time 1 TD Routing
TimeDependentRouteRequest. batteryCharge
Int 1 TD Routing Current state of charge of the vehicle (in %)
TimeDependentRouteRequest. Preferences
complex 1 TD Routing The user preferences stored in the user’s profile. Particularly the optimisation criterion, e.g. fastest, eco friendly
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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 36 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
complex 1 Vehicle Pooling
or EV SoC
Checking/Recharging
Detailed description of the ith calculated route such as the list of in‐between road segments on the computed route
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
complex 1 Route on Demand
Detailed description of the currently route such
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 37 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
Name Data Type Cardinality Source Description
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
BikeRouteRequest complex 1 Mobile Device API
A complex request object for querying
bicycle routes BikeRouteRequest. fromCoord
WGS84 latitude, longitude
1 Traveller Monitoring
or Mobile Device
API
Origin coordinate of the requested route
BikeRouteRequest. toCoord
WGS84 latitude, longitude
1 Mobile Device API
Destination coordinate of the requested route
BikeRouteRequest. timeLeaving
Time 1 Mobile Device API
departure time
BikeRouteRequest. complex 1 Security & The user preferences
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 38 of 73
Name: BICYCLE ROUTES Preferences Anonymity
Gateway stored in the user’s
profile. Particularly the optimisation criterion, e.g. fastest, eco friendly
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)
GetTrafficResponse complex 1 Messenger A complex object that includes a current traffic report.
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. fromCoord
WGS84 latitude, longitude
1 TD Routing Origin coordinate of the requested route
SimpleRouteRequest. toCoord
WGS84 latitude, longitude
1 TD Routing Destination coordinate of the requested route
SimpleRouteRequest. timeLeaving
Time 1 TD Routing departure time
SimpleRouteRequest. Int 1 TD Routing Current state of charge
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 39 of 73
Name: BICYCLE ROUTES batteryCharge of the vehicle (in %)
SimpleRouteRequest. Preferences
complex 1 TD Routing The user preferences stored in the user’s profile. Particularly the optimisation criterion, e.g. fastest, eco friendly
SimpleRouteRequest. modeOfTransport
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 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
complex 1 Route on Demand
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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 40 of 73
Name: CAR ROUTES
service, Messenger Service, Security & Anonymity Gateway
Relevant Use Cases: UC 1.4, UC 1.5, UC1.6 INPUT PARAMETERS
Name Data Type Cardinality Source Description
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
CarRouteRequest Complex 1 Mobile Device API
A complex request object for querying
routes for conventional cars
CarRouteRequest. fromCoord
WGS84 latitude, longitude
1 Traveller Monitoring
or Mobile Device
API
Origin coordinate of the requested route
CarRouteRequest. toCoord
WGS84latitude, longitude
1 Mobile Device API
Destination coordinate of the requested route
CarRouteRequest. timeLeaving
Time 1 Mobile Device API
(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
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 several) routes
OUTPUT PARAMETERS
Name Data Type Cardinality Destination Description SimpleRouteRequest complex 1 TD Routing A complex request
object for querying routes for conventional cars
SimpleRouteRequest. fromCoord
WGS84 latitude,
1 TD Routing Origin coordinate of the requested route
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 41 of 73
Name: CAR ROUTES
longitude
SimpleRouteRequest. toCoord
WGS84 latitude, longitude
1 TD Routing Destination coordinate of the requested route
SimpleRouteRequest. timeLeaving
Time 1 TD Routing departure time
SimpleRouteRequest. Preferences
complex 1 TD Routing The user preferences stored in the user’s profile. Particularly the optimisation criterion, e.g. fastest, eco friendly
SimpleRouteRequest. modeOfTransport
“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
TimeDependentRouteRequest. fromCoord
WGS84 latitude, longitude
1 TD Routing Origin coordinate of the requested route
TimeDependentRouteRequest. toCoord
WGS84 latitude, longitude
1 TD Routing Destination coordinate of the requested route
TimeDependentRouteRequest. earliestTimeLeaving
Time 1 TD Routing departure time
TimeDependentRouteRequest. latestTimeLeaving
Time 1 TD Routing Latest depature time
TimeDependentRouteRequest. Preferences
complex 1 TD Routing The user preferences stored in the user’s profile. Particularly the optimisation criterion, e.g. fastest, eco friendly
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
complex 1 Vehicle Pooling
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
complex 1 Vehicle Pooling
Detailed description of the ith calculated route such as the list of in‐between road segments on the computed route
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 42 of 73
Name: CAR ROUTES 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
complex 1 Route on Demand
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 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
Name Data Type Cardinality Source Description
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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 43 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
WGS84 latitude, longitude
1 TD Routing Current position of the user
AltRouteRequest. toCoord
WGS84 latitude, longitude
1 TD Routing Destination coordinate of the requested route
AltRouteRequest. timeLeaving
Time 1 TD Routing Current time
AltRouteRequest. batteryCharge
Int 1 TD Routing Current state of charge of the vehicle (in %)
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 44 of 73
Name: ROUTES ON DEMAND AltRouteRequest. Preferences
complex 1 TD Routing The user preferences stored in the user’s profile. Particularly the optimisation criterion, e.g. fastest, eco friendly
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
Name Data Type Cardinality Source Description
UserCredentials Complex 1 Mobile The user’s credentials to
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 45 of 73
Name: MULTIMODAL ROUTES
Device API obtain a temporal alias
TemporalAlias Complex 1 Connection / Disconnection to UT‐cloud
A anonymous temporal alias for the user
MultimodalRouteRequest complex 1 Mobile Device API
A complex request object for querying multimodal
routes MultimodalRouteRequest.fromCoord
WGS84 latitude, longitude
1 Traveller Monitoring
or Mobile
Device API
Origin coordinate of the requested route
MultimodalRouteRequest.toCoord
WGS84 latitude, longitude
1 Mobile Device API
Destination coordinate of the requested route
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
complex 1 Security & Anonymity Gateway
The user preferences stored in the user’s
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)
MultimodalRouteRequest.activeCriteria
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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 46 of 73
Name: MULTIMODAL ROUTES
network
OUTPUT PARAMETERS
Name Data Type Cardinality Destination Description MultimodalRouteRequest complex 1 TD Routing A complex request object
for querying multimodal routes
MultimodalRouteRequest.fromCoord
WGS84 latitude, longitude
1 TD Routing Origin coordinate of the requested route
MultimodalRouteRequest.toCoord
WGS84 latitude, longitude
1 TD Routing Destination coordinate of the requested route
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
complex 1 TD Routing The user preferences stored in the user’s profile. Particularly the optimisation criterion, e.g. fastest, eco friendly
MultimodalRouteRequest.activeCriteria
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
complex 1 Mobile Device API
Detailed description of the calculated route such as the list of in‐between road segments on the
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 47 of 73
Name: MULTIMODAL ROUTES
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
complex 1 Mobile Device API
Detailed description of the calculated route such as the list of in‐between road segments on the computed 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
complex 1 Route on Demand
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 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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 48 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
1 Traveller Monitoring
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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 49 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
Name Data Type Cardinality Destination Description
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.
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 50 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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 51 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
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
1 Traveller Monitoring
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, 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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 52 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
Name Data Type Cardinality Destination Description
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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 53 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
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
1 Traveller Monitoring
or Mobile Device
API
The current GPS location as acquired from the traveller monitoring system or from the mobile device of the
user.
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 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
unavailable, the Mobile Device API is employed.
EVSharingResponse Complex 0..* EV Sharing EV sharing options currently available, based on the user’s
current travel plan and
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 54 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
Name Data Type Cardinality Destination Description
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
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.
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 55 of 73
Name: EV SoC Check / Recharging
StartingLocation WGS84 latitude, longitude
1 Traveller Monitoring
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.
UserPreferences Complex 1 User Profile Management
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
Name Data Type Cardinality Destination Description
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.
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 56 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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 57 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”,
“safest route”, etc.
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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 58 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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 59 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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 60 of 73
Name: Mobile Device API
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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 61 of 73
Name: Mobile Device API
querying EV routes offline (when there is no connection to the
cloud)
EVRouteRequestOffline.fromCoord WGS84 latitude, longitude
1 EV routes Origin coordinate of the requested route
EVRouteRequestOffline.toCoord WGS84 latitude, longitude
1 EV routes Destination coordinate of the requested route
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
1 EV routes Origin coordinate of the requested route
SharedEVRouteRequest.toCoord WGS84 latitude, longitude
1 EV routes Destination coordinate of the requested route
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
Origin coordinate of the requested route
BikeRouteRequest.toCoord WGS84 latitude, longitude
1 Bicycle routes
Destination coordinate of the requested route
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
Origin coordinate of the requested route
BikeRouteRequestOffline.toCoord WGS84 latitude, longitude
1 Bicycle routes
Destination coordinate of the requested route
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
Origin coordinate of the requested route
EBikeRouteRequest.toCoord WGS84 latitude,
1 Bicycle routes
Destination coordinate of the requested route
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 62 of 73
Name: Mobile Device API
longitude EBikeRouteRequest.timeLeaving Time 1 Bicycle
routes departure time
EBikeRouteRequest.soc Floating point
number (%)
1 Bicycle routes
Current state of charge of the vehicle (in %)
EBikeRouteRequestOffline complex 1 Bicycle routes
A complex request object for querying e‐bike routes
EBikeRouteRequestOffline.fromCoord WGS84 latitude, longitude
1 Bicycle routes
Origin coordinate of the requested route
EBikeRouteRequestOffline.toCoord WGS84 latitude, longitude
1 Bicycle routes
Destination coordinate of the requested route
EBikeRouteRequestOffline.timeLeaving Time 1 Bicycle routes
departure time
EBikeRouteRequestOffline.soc Floating point
number (%)
1 Bicycle routes
Current state of charge of the vehicle (in %)
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
Origin coordinate of the requested route
ShareEBikeRouteRequest.toCoord WGS84 latitude, longitude
1 Bicycle routes
Destination coordinate of the requested route
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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 63 of 73
Name: Mobile Device API
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
Origin coordinate of the requested route
MMRouteRequest.toCoord WGS84 latitude, longitude
1 Multimodal Routes
Destination coordinate of the requested route
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
Origin coordinate of the requested route
MMRouteRequestOffline.toCoord WGS84 latitude, longitude
1 Multimodal Routes
Destination coordinate of the requested route
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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 64 of 73
Name: Mobile Device API
Routes timeLatestFalse: departure True: Arrival
StartingLocation WGS84 latitude, longitude
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.
EndingLocation WGS84 latitude, longitude
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
unavailable, the Mobile Device API is employed.
StartingLocation WGS84 latitude, longitude
1 Vehicle pooling
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 Vehicle pooling
The GPS location of the trip destination.
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.
StartingLocation WGS84 latitude, longitude
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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 65 of 73
Name: Mobile Device API
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
unavailable, the Mobile Device API is employed.
StartingLocation WGS84 latitude, longitude
1 EV SoC Check /
Recharging
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.
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.
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 66 of 73
Name: Mobile Device API
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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 67 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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 68 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.
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 69 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.
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 70 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/
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 71 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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 72 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
FP7‐SMARTICITIES‐2013 609026 ‐ MOVESMART
D2.3: Page 73 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.
top related