Uppsala Student Project 2015
MObile Network Assisted Driving (MO.N.A.D.)
Project specification (PA3 – Work in progress)
Industry representatives:
Konstantinos Vandikas, Gábor Stikkel
Ericsson Research
Table of Contents
Table of Contents .......................................................................................................................2
1. Introduction ...........................................................................................................................3
2. Architectural components .....................................................................................................3
2.1 Client-app .....................................................................................................................3
2.2. Simulated (or virtual) client-app .................................................................................4
2.3 Vehicle-app ..................................................................................................................4
2.4 Simulated vehicle-app..................................................................................................4
2.5 Data component (or database) ....................................................................................4
2.8 Notification system ......................................................................................................5
3. Code considerations...............................................................................................................6
3.1 Tractability .......................................................................................................................6
3.2 Expected Performance .....................................................................................................7
3.3 Revision system................................................................................................................7
4 Development phases ..............................................................................................................7
5 References ..............................................................................................................................8
1. Introduction
Main goal of this project is to setup an open platform for timetable-free traveling. The
advent of self-driving vehicles introduces an interesting prospect that will irrevocably
change public transport. Be that as it may, self-driving vehicles are not self-aware therefore
there is still a need for a platform that allows for efficient planning and scheduling for
vehicles. In this premise, ad-hoc timetables can be generated based on real-time on demand
traveling requests.
2. Features
This section explains the different features/functions of the system to be implemented.
2.1 Client-app
The system contains a Client-App running either on a mobile phone or in a web page. The
implementation choice here can vary. It would be more preferable if the app runs on a
mobile device (i.e. Android) since the haptic user interface provided by Android devices,
along with the mechanism for receiving notifications fits very nicely to the nature of the
proposed system. The Client-App allows for the user to register himself or to use the system
anonymously. In the case of registering to the system, an AuthenticationModule would be
used in order to verify the user’s credentials. The Client-App has a very simple user interface
that allows for the user to type where he wants to go. The Client-App sends this request to
the RequestHandler module and receives a response from that system which contains the
travelling plan. Moreover, the Client-App can receive notifications (from the
NotificationSystem) about different trips that the user needs to make, either based on past
information, or by information from the user's agenda. Last but not least, we are interested
in the user’s location therefore with the user’s approval the Client-App would be recording
the user’s location on regular intervals.
2.2. Simulated (or virtual) client-app
The virtual client-app bears similar traits to the Client-App with the exception that its
behavior can be programmatically controlled. This means, that for testing and large-scale
simulation purposes, using this module, you are allowed to create an arbitrary amount of
clients that push a scripted set of traveling requests. The simulator module, described later
on would be responsible for orchestrating the set of simulated client-apps.
2.3 Vehicle-app
The vehicle-app is pretty much the same module as the Client-App. The main purpose of its
existence is that of identifying vehicles as special first class citizens in this system. Moreover,
it can be used in order to associate client’s (user’s of the system) to vehicles. Within this
project it will be decided whether or not such an app deserves an implementation, or if it is
sufficient to model this association otherwise without the need of a dedicated app. Finally,
yet importantly the main function of this app is to tell the driver where he/she needs to go
in order to pick up passengers, so similarly to the client-app, this app can process and
receive notifications from the notification system.
2.4 Simulated vehicle-app
The simulated vehicle-app is a simulated version of the vehicle-app, used for testing and
simulation purposes. Using this app it should be possible to generate an arbitrary amount of
vehicles moving in various trajectories over time. Similarly, to the simulated client-app, this
app is also control by the simulator module.
2.5 Data component (or database)
The data component (or database) is the central (from a logical perspective) component
which stores all the information needed for the proposed system to operate with the
exception for the user profiles and user credentials which are stored separately in a
different database for security purposes. The basic information that is recorded here are the
location of a user and the different travelling requests the user has made. Since this is an
open system, every user is allowed to download all the information that this system has
recorded such as location information and travel requests. Even though the database
appears as a central logical component, it’s underlying implementation is that of a
distributed database. Implementations such as MongoDB[1] and Apache Cassandra[2]
should be taken into consideration here when it comes to deciding how to implement this
component.
2.6 RequestHandler
The RequestHandler component is responsible for receiving traveling requests which will
later on be pushed to the Data component to be recorded also to the Travel planner
component which will generate the corresponding travelling plan.
2.7 Travel Planner
Takes as input a travelling request and generates the travelling plan expressed as a
trajectory of points. For the purposes of this assignment there is no need for creating a
brand new and novel travel planner system, already available APIs that take into
consideration transit information (such as Google’s Direction API) if the licensing agreement
permits so. Perhaps the creation of a bespoke version of this function would make sense in
the course of this project when creating ad-hoc routes that are different from the predefined ones but that remains to be seen.
2.8 Notification system
The purpose of this component is to proactively send different kinds of notification to the
client-app and the vehicle-app such as:
o upcoming traveling requests
o proximity to bus stop information etc.
o suggest virtual (ad-hoc) stops for collecting people
o proactively push more efficient alternative routes
2.9 Authentication module
A simple authentication module that uses the User Database in order to authorize,
authenticate and account a user’s access into this system.
2.10 User Database
The User Database contains user credentials as hash-codes and one-time tokens for
accessing the system.
2.11 Travel Recommendation
Purpose of this module is to start learning the user’s preferred (or potential) upcoming
travels and to proactively generate recommendations which will be later on served and
delivered to the user with the Notification system. Another input of information for travel
recommendations can be the user’s calendar.
2.12 LookAhead function
Generates a new timetable out of traveling requests that have been made in the past. The
LookAhead function should take into consideration the city of Uppsala. Information from
OpenStreetMaps can be used. As far as connections are concerned when generating future
timetables, one connection point should be taken into consideration which is that of the
Central Station.
2.13 Feedback function
The feedback function is another important component of this system where the user gets
to evaluate how good a recommendation made by the Travel recommendation component
was, or how beneficiary (or not) was an an ad-hoc timetable that has been generated for
that user in particular. This information should be taken into consideration when generating
a travel recommendation or when generating a new timetable.
2.14 Simulator function
The role of the Simulator function is to govern the simulated apps such as vehicles and
clients.
KTH-ITRL has created a simulator that could be used for this purpose [3]. Another simulator
is GAMA [4]. Performance and scalability but also ease of use are the main criteria for
choosing a simulator.
3. Code considerations
3.1 Stream processing / Batch processing
These techniques should be taken into consideration when dealing with the LookAhead
function. Stream processing is about doing small computation on a series of infinite data,
while batch processing is about making a more involved computation to a large set of data.
Tools such as Apache Storm [5] or Apache Flink [6] should be used for Stream processing
purposes, i.e. for figuring out the amount of people that want to go from point A to point B
since this information is going to be constantly flowing into the system Batch processing
should be considered for the Travel Recommendation mechanism. A hybrid approach which
combines the two is also an option. Apache Flink in particular is capable of dealing both with
streams and batches.
3.2 Tractability
The tasks to be solved by the Travel Planner, Travel Recommendation and Lookahead
function are known to be NP-Complete therefore it is interesting to utilize genetic
algorithms in order to circumvent inherent intractability by sacrificing absolute optimal
solution with approximations of good enough solutions. A useful library for genetic
algorithms in Python is DEAP [7].
3.3 Expected Performance
At the moment of writing this text it is fairly premature to setup any particular performance
threshold therefore a particular point in time, during the development of this activity should
be set in order to construct a proper benchmark for this system.
3.4 Evaluation
Aside from performance it is important to evaluate the LookAhead function which
generates ad-hoc timetables as opposed to rigid timetables already used by UL. It is
interesting to show if the new function can bring lower costs for UL and better user
experience (i.e. smaller waiting time).
3.5 Revision system
The following github repository will be used for storing the source code that is going to be
developed within this project:
https://github.com/EricssonResearch/monad
Each student will be given access to this repository based on their personal github accounts.
The source code will be made publicly available under the Apache 2.0 software license.
Moreover, for the purposes of recording SPRINT progress (backlog, ongoing, completed
tasks) we will be using a private account on Trello. [link to be added here]
3.6 Deployment
The complete deployment of the system should be clearly documented (input/output of
each component). Furthermore, (and in order to simplify development) puppet scripts
should be used for automating the development/testing process of all different
components, including the setup of the cluster for processing stream data.
4 Development phases
The development process can be split in (at least) two phases. The first phase should be
about designing the simulation and the algorithms for generating recommendations, but
also the LookAhead function that generates the ad-hoc timetable and ad-hoc routes. A set
of criteria for evaluating the quality, accuracy of these solutions should be also defined at
this stage. The next phase should focus on engineering the previous phase to a larger scale
setup. Techniques such as stream processing/batch processing should be taken into
consideration here. Tools such as puppet should be used for generating the deployment of
the large scale version in a cloud based infrastructure (based on openstack).
5 References
[1] MongoDB - https://www.mongodb.org
[2] Apache Cassandra - http://cassandra.apache.org
[3] KTH-ITRL - https://bitbucket.org/kthSMLteam/kth-smart-mobility-lab/src
[4] GAMA - https://github.com/gama-platform/gama
[5] Apache Storm – https://storm.apache.org
[6] Apache Flink - https://flink.apache.org
[7] DEAP - https://github.com/deap/deap