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

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

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