Successfully reported this slideshow.
Upcoming SlideShare
×

of

Upcoming SlideShare
Computer Simulation Final Project
Next

1

Share

Simulation Modelling final_project_ganganer

Simulated a complicated model of a real pick-and-drop cab service provided by UC to it's students using Arena Simulation Software.

See all

Simulation Modelling final_project_ganganer

1. 1. Simulation Modelling Final Project UC Night Ride Simulation Professor: David Kelton Created by: Rutuja Gangane UC MS-BANA (M08655415) Index  Introduction  Model Logic 1. Challenges Faced 2. Logic Used 3. Limitations and Assumptions  Data 4. Collection 5. Cleaning 6. Model Distribution Fitting  Scenarios Tested 7. Process Analyzer  Conclusions/Suggestions
2. 2. Introduction This Project is based on the night-time pick-and-drop shuttle service called Night Ride provided by the University of Cincinnati Public Safety to its students. Typically, students can use the Night Ride anywhere within 1 mile of campus as an on-call, free, pick-and-drop cab service. The idea is to simulate the number of shuttles that operate and observe waiting time for students and how to best optimize the model so that average waiting times are reduced. ModelLogic 1. Challenges Faced a. To use Transporter, Resource or Route: As the process/transfer times were already given, transporter, which works on distance and velocity inputs looked like an unlikely choice. Using a resource or a route with delay would not create a request-based model, and will not be very useful when simulating and analysing alternatives. b. How to make the transporter “wait” till one of the entities is dropped off and use the same transporter to move ahead with the rest of the passengers. Since entities are picked up and dropped off altogether as a single entity or a batch. c. How to batch entities? d. How to assign the transporter (logic)? 2. Logic Used Create and Assign Logic: The model starts from a Create module where entities are created (when night ride receives the calls). The entities are assigned Pickup and drop-off locations, and routed to their stations from where they are to be picked up. Description of one station of the Model: The next decide module decides if the entity has been using the transporter, then to Free and Halt the transporter (block the transporter so that rest of the passengers can be dropped off to further locations instead of releasing the transporter and then requesting for another one). We need to release the transporter because entities might be travelling in batches from the same locations but might have different drop-off points. We will use separate module to unbatch and release the entity whose drop-off point is current station. If it is a new entity with pickup as current station, then this step will be skipped. Next step is the decide module which checks if current station is a drop off point for any entity. Such entities are disposed. Next condition of the decide module is to check if it is an entity being picked up from the current location. If it is, then we count the passengers (this helps in deciding the batch size of the transporter about to leave from station 2). We then record current time and hold such entities for some time in order for them
3. 3. to possibly form a batch, with other new passengers to be picked up from same station or passengers passing through this station in a night ride. The third condition of the Decide Module will have passengers passing through this station in the Night ride (while dropping off some other passenger), we will count these and send them to be batched again along with any new passengers from same pickup location. The Queue logic for this batch module will be entity that is created the first (already travelling passengers) will be at the start of the queue. Maximum size of the batch is Old Passengers+ New passengers, but not more than 6. If any new passengers are remaining, they will be in the next batch, which then goes on to request another transporter. Meanwhile, the batch having old passengers and might be having new passengers goes ahead, the transporter is activated (engine started) again and is requested by the batch. It takes some delay for the passengers to get down/climb in, take a turn and the Night ride moves ahead to its Next station. This is the station of the entity first created among all the passengers in the NightRide. A screenshot of the complete model:
4. 4. 3. Limitations and Assumptions Assumption 1: Every Transporter/ Night ride has a limited capacity of 6(by use of batch size no more than 6). Specific transporters were not assigned specific capacities. Assumption 2: Only Six Stations, which are also clubbed from various different actual pickup and drop-offs. Data 4. Collection The data was requested from UC NightRide Program. The data received was Date, Van Number/Driver Names.,Number of People, Pickup Location, and Drop-off location, Time of Call, Time of Pickup and Time of Drop. 5. Data Cleaning This was a very complex model to simulate. To make it easier, I have chosen six “Areas”,in which many of the locations were clubbed (which was not an easy task at all!). Total data used from the 49,000 odd rows given in the dataset,was about 30,000. Most of the locations (although same) were spelled incorrectly multiple times. It took a lot of time to get the data cleaned and grouped in six areas. Location Grouping:
5. 5. 6. Model Distribution Fitting: The distributions were fitted on inter-arrival times as per given data. The service times (and hence distance, velocities) were found by fitting the data in Input Analyzer. The distribution of drop-off and pickups were also found from the data. Six distribution An example of the service time data fitting:
6. 6. 30 such distributions were made to check the inter-arrival times from one area to another. Similarly distributions were fitted to inter-arrival times. Probability of choosing the station was a discrete probability found from the data. 7. Process Analyzer: Process Analyzer was used to check the three different scenarios. One was the Base case with 8 Night rides. Second was the Model with 10 Night Rides. The final scenario was when assignment of the Night ride/transporter was not cyclical but based on smallest distance. The best scenario was when Night Ride was assigned on the logic of smallest distance, i.e. when new batches request for a night ride, the transporter that is closest to request station should be dispatched. This decreases the Totalentity time in system, however the times are not very significant, but the best scenario is with third model.
7. 7. Although the smallest distance scenario might increase the maximum waiting time, but it reduces the avg. time in system significantly. Conclusions: The logic for assigning the Night Ride should be based on smallest distance from Requesting location and not Cyclical/Random. (Here, Cyclical means that starting from 1, each transporter will be used one after the other from all the free available transporters i.e. we will try to use all ofthe shuttles equal number of times.)
• mohitkulkarni9081

May. 3, 2021

Simulated a complicated model of a real pick-and-drop cab service provided by UC to it's students using Arena Simulation Software.

Total views

1,437

On Slideshare

0

From embeds

0

Number of embeds

146

1

Shares

0