0LAUK0 2015 01 Simulation
The simulation test several different scheduling strategies and validate the outcome by evaluating the general happiness.
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.
The simulator consists of 2 parts, logic and GUI.
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.
- The simulator process is responsible for spawn all other processes and act as environment by adding passengers to bus stops.
- The passenger process is responsible for counting the on/off time.
- 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.
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.
- 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%.
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.
//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 out 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).