0LAUK0 2015 01 Simulation

From Control Systems Technology Group
Revision as of 11:23, 15 October 2015 by S131047 (talk | contribs) (→‎Result)
Jump to navigation Jump to search
Quick Links
Home
Content Plan Report Simulation
Log Week1 Week2 Week3 Week4 Week5 Week6 Week7

The simulation test several different scheduling strategies and validate the outcome by evaluating the general happiness.

Simulator

Discrete Event Simulation based on React.NET framework.


Source code is available on GitHub under GPL V3 license.

Source Code


Compiled binary is available from dropbox

Executable


Hints: Use mouse wheel to switch between charts and click on bars will show detailed data.

Simulator Setup

The simulator consists of 2 parts, logic and GUI.

Logic

The logic is implemented upon Discrete Event Simulation Frame by using React.NET and compiled into a dll for later integration.

http://reactnet.sourceforge.net/index.html

The simulation logic has 3 process running.

Simulator
The simulator process is responsible for spawn all other processes and act as environment by adding passengers to bus stops.
Passenger
The passenger process is responsible for counting the on/off time.
Bus
The bus process is responsible to drive alone the destination list provided by the scheduler.

The scheduler is an interface which will be called by the Bus process each iteration for updating the destination list.

GUI

The GUI is written in C# using WPF for fast demonstration purpose. The data is displayed by using Modern UI Charts library.

http://modernuicharts.codeplex.com/

All the simulation result is saved in SimResult class. After the simulation done the GUI will process this result and put it into DataViewer class for visualization.

Assumption and Approximations

There are three factors we used to calculate the general satisfaction.

Waiting time
The weight is 8.05.
Crowdeness
The weight is 7.97.
Travel time
The weight is 7.29.

These weight are taken from the survey result of people who take bus often.

The crowdness of each passenger is normalized to 0.0 - 1.0 by evaluating PassengerNumber/MaxPassengerNumber.

The waiting time is also normalized to 0.0 - 1.0 by WaitingTime/MaxWaitingTime.

We assume the max waiting time is 15 min. After 15 min the passenger feels totally disappointed.

The Travel time is normalized to 0.0 - 1.0 like waiting time by setting Max Travel Time to one hour.

In this way we obtained a normalized general happiness from 0% to 100%.

Dynamic Scheduler

Due to the time limitation only a simple dynamic scheduler is implemented.

The algorithm make decisions like follow:

1. Check if there's shortcut available from current bus stop

2. iterate over all available shortcuts and check if people on the bus want to go to the skipped bus stops

3. iterate over all available shortcuts and check if people from skipped bus stops want to get on the bus

4. if all conditions are met, choose the shortcut that skip more bus stops.


Passenger flow generation

Currently only 2 configuration is implemented.

1. Passenger generate at bus stop uniformly and time independent, 1 passenger per bus stop per 60 seconds

2. Passenger generate at bus stop according to time (absolute of a sine wave which simulates the morning and afternoon busy hours). These passengers has higher probability want to go to a bus stop far away from the current bus stop, the higher the distance the higher the probability.

Result

//add detailed result later

The result shows that with this dynamic scheduling algorithm our system can't improve much under following conditions:

1. Passengers arrive all bus stop uniformly

2. The chance a passenger want to go to certain destination is equally distributed

The improvement is less than 5% under these situations and sometimes even give a worse result.


The result shows that with this dynamic scheduling algorithm our system can improve the situation under following conditions:

1. Passengers do no arrive uniformly, most of them arrive at starting bus stop(station eindhoven), ending bus stop(WC wonsel) and etc...

2. The chance a passenger want to go to certain destination is not equally distributed, most of them want to go to one or two bus stop(station Eindhoven or etc...)

The improvement is more than 10% under these situations but mainly depends on how the passenger flow is configured.(Due to time limitation we only implemented 2 simple algorithm to generate passenger flows)


This proves that during heavy load hours the system is not able to provide a better experience than a static scheduler. Since with large amount of passengers the chance a passenger want to go to certain destination can be seen as equally distributed and they also arrive uniformly.


More investigation is needed. (To test with more passenger flow configurations and probably different route configuration).