0LAUK0 2015 01 Simulation

(Difference between revisions)
 Revision as of 20:45, 11 October 2015 (view source)S131047 (Talk | contribs) (→Assumption and Approximations)← Older edit Current revision as of 09:47, 22 October 2015 (view source)S131047 (Talk | contribs) (→Result) (15 intermediate revisions not shown) Line 48: Line 48: Hints: Use mouse wheel to switch between charts and click on bars will show detailed data. Hints: Use mouse wheel to switch between charts and click on bars will show detailed data. + + == Simulation Concept == + + The concept of the simulation is to implement different schedulers and different passenger flows. By inputting them into the simulator, it should be able to give out result containing a list of passenger records including waiting time, travelling time and crowdedness on bus. + + + Configurable Parameters + + ; 1. Bus : Bus number and interval between each bus + + + ; 2. Scheduler : Different scheduling algorithm ( one static and various dynamic scheduling algorithm) + + + ; 3. Passenger Flow : Passengers arrival rate and their destinations. + + + Output Results + + ; 1. Waiting Time : The time a passenger spent on waiting for bus. + + + ; 2. Travelling Time : The time a passenger spent on bus to reach the destination. + + + ; 3. Crowdedness on bus : Number of passengers on bus. == Simulator Setup == == Simulator Setup == Line 74: Line 100: http://modernuicharts.codeplex.com/ 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 ==== ==== Assumption and Approximations ==== Line 96: Line 124: In this way we obtained a normalized general happiness from 0% to 100%. 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 according to 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 == == Result == + + 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). + + == Possible improvements and To do == + + 1. Implement more passenger flow types + + 2. Implement more dynamic scheduling algorithm + + 3. Test more passenger flow and scheduling algorithm pairs

Current revision as of 09:47, 22 October 2015

 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.

Compiled binary is available from dropbox

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

Simulation Concept

The concept of the simulation is to implement different schedulers and different passenger flows. By inputting them into the simulator, it should be able to give out result containing a list of passenger records including waiting time, travelling time and crowdedness on bus.

Configurable Parameters

1. Bus
Bus number and interval between each bus

2. Scheduler
Different scheduling algorithm ( one static and various dynamic scheduling algorithm)

3. Passenger Flow
Passengers arrival rate and their destinations.

Output Results

1. Waiting Time
The time a passenger spent on waiting for bus.

2. Travelling Time
The time a passenger spent on bus to reach the destination.

3. Crowdedness on bus
Number of passengers on bus.

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.

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.

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 according to 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

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

Possible improvements and To do

1. Implement more passenger flow types

2. Implement more dynamic scheduling algorithm

3. Test more passenger flow and scheduling algorithm pairs