0LAUK0 2015 01 Simulation: Difference between revisions
No edit summary |
(→Result) |
||
(19 intermediate revisions by the same user 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 == | |||
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 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 |
Latest revision as of 10: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.
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 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