Technical Specification Public Transit Demand

1 References
[1] “Movement and dwell time of buses in DynaMIT 2.0 and SimMobility: Technical Specifications”, version 0.4 [2] Antoniou C. (2004), “On-line Calibration for Dynamic Traffic Assignment”, PhD thesis at Massachusetts Institute of Technology
[3] Balakrishna R. (2006), “Off-line Calibration of DynaMIT Traffic Assignment Models”, PhD thesis at Massachusetts Institute of Technology
[4] Ben-Akiva M, Bierlaire M (2003) Discrete choice methods and their applications to short term travel decisions. In: Hall R (ed) Handbook of transportation science, 2nd edn, Kluwer Academic, Boston
[5] Ben-Akiva M., Koutsopoulos H., Antoniou C., Balakrishna R., (2010) "Traffic Simulation with DynaMIT". In: Barceló J (Ed) "Fundamentals of Traffic Simulation", ISBN 978-1-4419-6141-9
[6] Bekhor, S., Ben-Akiva, M. E., & Ramming, M. S. (2006). Evaluation of choice set generation algorithms for route choice models. Annals of Operations Research, 144(1), 235-247.
[7] Yen, J. Y. (1971). Finding the k shortest loopless paths in a network. management Science, 17(11), 712-716.
[8] Cats, O. (2011). Dynamic modelling of transit operations and passenger decisions. KTH.
[9] Hoogendoorn-Lanser, S., Bovy, P., & van Nes, R. (2007). Application of constrained enumeration approach to multimodal choice set generation. Transportation Research Record: Journal of the Transportation Research Board, 2014(1), 50-57.
[10] Rieser, M. (2010). Adding transit to an agent-based transportation simulation: concepts and implementation. Universitätsbibliothek.
[11] “Requirements for DynaMIT 2.0”, Requirements_DynaMIT_20130731.xlsx

2 Introduction
As part of the SimMobility project, Public Transport was modeled. The following are the two key aspects of modelling Public Transport.
Demand: Modelling all the trips that take place on public transport
Supply: Modelling the movement of Public Transport vehicles on the network
This section provides the technical specification for modelling the demand of public transport. There is a similar document for modelling the [supply of public transport] (https://github.com/smart-fm/simmobility-prod/wiki/Technical-Specification---Public-Transit-Supply). This also contains a section indicating the interaction between the supply and demand simulations.
The purpose of the technical specification is to explain the key concepts and models in modelling transport demand to a sufficient level that:

• A software programmer is able to code without having to ask too many additional questions.
• The modeller is able to verify that what is being coded is what is required.

3 Existing literature in modelling demand on public transport networks:
3.1 Other traffic simulation software
3.1.1 BusMezzo
BusMezzo is a mesoscopic traffic simulation model for bus services. This section will briefly describe how demand is modelled in BusMezzo. The origin and destination matrix is assumed as given in BusMezzo. The demand model takes the origin and destination and simulates passengers’ path choice in the bus network. The demand model in BusMezzo has two parts. The first part generates choice sets using a branch and bound algorithm, while the second part interacts with the supply model and dynamically selects paths within the context of previous generated choice sets.
The path set generation in BusMezzo is conducted on a normal network with each service link representing a unique service line serving between two consecutive stops along the service line. Walking links are added based on distance between stops. A branch and bound algorithm with predefined logical constraints, behaviour constraints, and feasibility constraints is used to generate the path set. The generated path set is then processed to get a master path set by merging common lines and common stops. The final master path set is then represented as a decision tree data structure from origin to destination by traversing each candidate stops in the master choice set.
Dynamic path generation is achieved by simulating three types of passenger decisions when passengers start their journey, namely connection decision, boarding decision, and alighting decision.

• Connection decision takes place when passengers are selecting a stop to board via non-transit links. It can be either deciding the initial boarding stop on egress walks, or choosing a transfer stops after alighting.
• Boarding decision has only two states: to Board, or to Wait. It will be initiated when a passenger has arrived at his boarding station and a transit vehicle is arriving at this stop. For all the candidate transit vehicles within predefined choice set, the passenger will choose to board the vehicle with least expected remaining travel time.
• Alight decision is similar to boarding decision as it has two states: to alight or to stay. It takes place when a passenger is on-board and the on-board vehicle is arriving at a stop which is available in predefined choice set. Passengers will choose the stop to alight which will result in least expected remaining travel time to reach the destination.

The current implementation of path choice model in BusMezzo is based on a Multinomial Logit (MNL) model. At each decision point, the passenger calculates the expected utility for taking each action and makes a decision using a MNL model. The expected utility for taking each action is given by the logsum of joint utility of subsequent path alternatives after taking the action. The utility of the path alternative is defined to be the linear combination of path attributes such as: expected travel time based on scheduled timetable, expected waiting time based on frequencies of attractive service lines, expected walking time based on distance and pre-defined speed, number of transfers, and monetary cost. The chosen path is then the simulation result of passengers’ successive decisions. An overview of how BusMezzo models demand is given in the following figure.

3.1.2 MatSIM
The demand model of transit simulation in MatSIM is reviewed in this section. Unlike BusMezzo which assumes OD demand as given, MatSIM has an activity type choice model, an activity location choice model, an activity chain choice model, an activity starting time choice model, and an activity duration choice model to estimate the activity chain with location, duration and starting time. The figure below depicts the overall framework with building blocks in MatSIM. The initial demand is the initial set of day plans for the simulated population. The Execution block simulates agents’ performing activities following the day plan. It includes mode choice and route choice in the demand simulator. Given a selected route, the agent’s movement is simulated in a supply simulator. A scoring block evaluates the performance of day plans such that an agent can replan their activity plan to optimize their day plan. Simulation results are output to the analysis block for various analyzing purposes.

n MatSIM, trips are derived as the outcome of conducting activities in different locations. A mode choice model and route choice model is then used to select paths in the transit network. The transit network used in MatSIM is a line-based network with nodes representing stops which are duplicated from physical stops such that each service line has its own unique set of stops and transit link representing a unique service line serving between two consecutive stops along the service line, as well as transfer links representing transfers between different service lines. A conceptual network formulation is shown in the following figure.

Route Choice in MatSIM is based on choosing the least cost path. It is worth mentioning that they have implemented an external LinkTravelTimeCalculator to calculate the travel time for each link. Although it is not mentioned in their documents, it is believed that this LinkTravelTimeCalculator is able to calculate the time-dependent link travel time for both transfer links and transit links.

3.2 How demand is currently modelled in SimMobility
The following section reviews how demand for road transport is currently modeled in SimMobility. This is because a similar approach may be relevant for the modeling of public transport. SimMobility models each individual traveler on the network using the demand simulator. The demand simulator used by SimMobility consists of five key steps which are shown in the figure below.

• Step 1: In the first step the historical OD matrix is disaggregated into a population of travellers. Each traveller is assigned socio-economic characteristics based on the distribution of such characteristics within the actual population. These characteristics include: value of time, purpose of trip, and access to information whilst travelling. Other characteristics assigned are habitual travel behaviour.
• Step 2: In the second step, each traveller’s decisions is updated. For example the departure time, mode, and route path of a traveller can be updated depending on guidance information received. Travellers in the middle of a trip can also change their path. The decision of each traveller is dependent on the characteristics of the traveller defined in step 1 – thus two different travellers undertaking the same OD at the same time might choose different paths since only one traveller might be receiving real time information. A path size logit model is used to provide probabilities for route selection (Ben-Akiva and Bierlaire, 2003). This allows SimMobility to model the heterogeneity of path selection observed in the real world.
• Step 3: In the third step all the individual travellers from step 2 are aggregated into OD table cells in preparation for step 4.
• Step 4: In the fourth step on-line calibration is used to improve the estimates of the OD flows as well as improve the short term predictions of OD flows.
• Step 5: In the fifth step the OD matrices are disaggregated into a list of travellers that will be sent to the Supply Simulation.

3.3 Glossary of Terminology
-- to be added --

4 Requirements for modelling demand in public transport
4.1 Use case of modelling a passenger trip
As a validation stage in eliciting requirements it is useful to produce a flow diagram indicating the key processes in the movement of a passenger over one or many trips in a single day. This flow diagram should indicate all possible processes that might occur and should therefore be incorporated into the design. Such a diagram was produced and is shown in the following figure. There are three main “actors”:

• Person Agent: This represents the passenger
• Vehicle: This is the vehicle which moves the passenger. Typically this will be a bus or MRT train

The use case is summarised in the following table

Name	Description
Primary Flow
P01: Agent performs tour planning	At the start of the day the person agent determines all the activities and trips that they will make during the day. This will include the approximate start time of each trip
P.02: Agent perform pre trip planning	When a trip is about to begin the agent determines the mode and route they are going to take as well as the exact departure time.
P.03: Agent walks to initial PT stop / access node	The agent walks to a stopping point on the transport network.
P.04.Agent wait for PT vehicle	The agent then waits for a suitable public transport vehicle that will take them along their route
P.05: Agent boards PT vehicle	When a suitable PT vehicle arrives the agent boards
P.06: Agent rides vehicle	The agent then rides the PT vehicle
P.07: Agent alights PT vehicle	When the PT vehicle arrives at the desired stop the agent alights the vehicle
P.08: Agent walks to next stop point in trip plan	If there are more rides to take then the agent walks to the next stop point. Of course if the next ride begins at the same stop point then the travel time of this transfer walk will be 0 seconds.
P.09: Agent walks to destination	If there are no more rides to take to complete the trip, then the agent walks to the destination.
Alternative Flows
P.10: Agent re-evaluates trip	At any point in the trip the agent may re-evaluate the path they are taking
P.11: Agent checks real time information	The agent may check real time information to help them make better informed travel decisions.
V.01: PT vehicle arrives at stop and allows passenger to board and alight	When the PT vehicle arrives at the stop agents are allowed to alight and board the vehicle
V.02: PT vehicle drives along the network	The PT vehicle then drives along the network as described

5 Overview of modelling demand in Public Transport
A small design team in SMART have identified a potential solution to modelling demand in public transport that takes into account the requirements. This section provides an overview of this solution. It describes how a single trip is modeled. It then describes how a sequence of trips is modeled. Later sections will describe each part of the solution in more detail.

5.1 Modelling a single trip

A single trip can be summarized by the following figure.

This diagram shows in order from top to bottom:

• The key data flows into and out of the system
• The key processes
• The models that are needed
• The stages of the trip

The diagram is explained in detail below.

5.1.1 Stages of a trip

There are 4 key stages in a trip:

• Pre-Day: This refers to the period at the start of the day when the person determines all the activities and trips that they will have to take during the day. In this stage an approximate time for each trip is determined. Of course in most cases the trip start time is dependent on the time that the preceding activity is completed. The person will also make an initial choice of the mode of transport they will take (i.e. private or public transport).
• Pre-Trip: This refers to the period just before a trip should start. In this stage the person determines the mode and route that they will take. They also determine the exact departure time.
• En-Route: This refers to the period during which the trip is happening.
• Day-to-Day learning: This refers to the period after the trip. The person will evaluate the whole trip and potentially make changes to how such a trip is performed again in future.

5.1.2 Models that must be implemented
Analysis of the process has identified 5 models which must be designed and implemented. These are listed below and described in detail in the rest of this document:

• Model 1 - Path Set Generation Model: This model identifies potential paths that a traveller might take from any given origin to any given destination.
• Model 2 – Route Choice Model: This model identifies the cost of each feasible path at a specific moment in time. It then identifies a suitable path that the traveller will take.
• Model 3 – Departure Time Choice Model: This model calculates the exact time that a user will start a trip to within one minute.
• Model 4 – Reschedule Activity: This model allows users to change the list of activities that they will undertake during the day. It should be noted that since only SimMobility uses activity modelling, this model is run only in SimMobility.
• Model 5 - Day-to-Day learning model: THIS IS YET TO BE COMPLETED

5.2 Modelling all the trips of a single person in a single day in SimMobility
Travel demand is created by people's need to perform various activities (like work, shopping, education etc.) in different geographical locations. A person makes trips to reach his activity locations. In SimMobility, all trips made by a single person along with the activities for which the trips are made are represented as a trip chain for that person. Each Person in the simulation has a trip chain, which specifies the sequence of trips and activities for that person.
As the name suggests, trips have a chaining effect for a person. It means if one trip or activity gets modified (delayed or dropped) then it has a ripple effect on the subsequent trips and activities in the Trip chain. In SimMobility Trips are multimodal. So in the trip chain private car trips or walking trips may co-exist with the public transit trip. SimMobility allows mode changes by assigning a different role to the same person during the trip. For example when a person agent is performing some activity his role will be “activity performer” and after the activity finishes, if he has to start a trip by public transport or private transport he will be assigned a “passenger” or “driver” role respectively.
Figure represents the life cycle of the trip chain in SimMobility.

6 Model 1: Path Set Generation Model
6.1 Overview
The first model that must be built is a path set generation model (PSG). The aim of the PSG model is to identify the set of possible paths that a passenger might take when travelling from a given origin to a given destination. It is important that ALL possible routes that could in some circumstances be used are included. This is because the actual path chosen by the passenger will be a sub-set of those in the path set. Therefore when constructing this path set possible scenarios such as road closures must be considered. Depending on the distance between the origin and destination and the network, there could be hundreds of feasible paths in the path set.
The set of feasible paths is calculated off-line for all possible ODs in the network. These path sets will then be used during the simulation run-time. When a person agent is travelling between origin O and destination D, the set of feasible paths obtained by the PSG will be obtained. The exact cost at the current simulation time of each of these paths will then be calculated to identify the best paths.
The purpose of the Path Set is to speed up real time computation of the simulator. This is because the process of path set generation can be very computationally expensive. In a network there might be thousands of theoretically possible paths that need to be considered. Therefore having whittled these down to only a few hundred will save very large amounts of time.
The PSG model is used for all fixed line scheduled PT services such as buses and MRT.

6.2 PSG process
There are 5 steps in the PSG model:

• Step 1: Define network for path choice generation
• Step 2: Define walking transfers
• Step 3: Estimate waiting times to embark on each route segment
• Step 4: Estimate travel times for each route segment and walk leg
• Step 5: For each OD determine set of possible paths

6.2.1 Step 1: Define network for path choice generation
The first step in the PSG model is to redefine the network into a series of “Route Segments”. A route segment represents a direct connection between two stops served by at least one line. All vehicle journeys that serve the route segment must run along the same sequence of roads.

As an example consider the diagram above. The left hand diagram shows the conventional representation. There are 5 bus lines which serve from stop S1 to S2. There are also 5 bus lines which serve from S2 and S3. However only one bus line serves all three stops. This is line L1. This simple three stop example can be converted to three route segments. There is one route segment defined between stops S1 and S2 which is served by 5 bus lines. There is also one route segment defined between stops S2 and S3 which is served by 5 bus lines. There is also an additional route segment defined from S1 to S3. This path segment is served by only one bus line, L1. The attributes of a Route Segment are given in table below.

Name	Description
Start Stop	This is the stopping point which defines the start of the route section
End Stop	This is the stopping point which defines the end of the route section
Distance	This is the distance of the route section as experienced by the bus
Mode	This is the mode of transport, typically bus or MRT
List of Frequency-Based Service Lines	This is the list of lines which serve this route segment along with the frequencies of these buses.
List of Schedule-Based Service Lines	This is the list of lines which serve this route segment along with the schedules of these buses at the start stop
Travel Time	This is the expected travel time on the route segment.,This will be time-of-day dependent.
Waiting Time	This is defined is defined as the expected waiting time at the starting stop to board on any service lines on route segment. This will be time-of-day dependent.

It should be noted that it is possible to define more than one route segment between a given start stop and end stop. This is because there can be more than one unique path between the two. In this case it is necessary to create a route segment for each possible path between the two stops.

6.2.2 Step 2: Define walking transfers
In the second step walking transfers are defined between stop points where it is feasible that walking transfers could occur. It should be noted that if a walking transfer is NOT defined in this stage then it will NOT be possible to undertake that walking transfer in future. Therefore the following rules will be used to define the walking transfers:

• Rule 1: A walking transfer is defined between all stopping points that are within X meters. (default value of X is currently 300m but research is being undertaken to determine this) - Rule 2: A walking transfer must be defined between a stopping point and at least one other stopping point which serves a different line subject to this distance being less than Y meters.
• Rule 3: A walking transfer is defined between all stopping points where transfers are observed in the cleaned EZ link data set. (NB. It is possible to do research on how the set of stops produced by rules 1 and 2 compare to that of rule 3).

6.2.3 Step 3: Estimate waiting times to embark on each route segment The third step is to estimate the waiting times to embark on each route segment. This is given by a black box model as illustrated in the following figure.

Waiting time to embark on each route segment is defined as the expected waiting time at the starting stop and is a function of both frequency-based service lines and schedule-based service lines on this route segment. The input will be based on the frequency of services and scheduled times at this stop. Two equations that could be used are given below: - Model 1: For static path set generation without specifying departure time - Compute effective frequency of schedule-based service lines - Expected waiting time is based on all “frequency” of service lines on the route segment to embark on.

Where Rx denotes the route segment, Li is service lines traversing on the route segment, and fi is the frequency of line Li. Model 2: For time-dependent path set generation with departure time specified:

Where Dj is the departure time of line Lj and is the passenger arrival time at node.

6.2.4 Step 4: Estimate travel times for each route segment and walk leg
The fourth step is to provide an approximate indication of the travel time for each route segment and walk leg. The purpose of doing this is explained in step 5. There are three approaches to estimating the travel time of each route segment:

• Approach 1 - schedule data: schedule data can be used. This should be an accurate source since operators will attempt to run their services to schedule.
• Approach 2 – observed data: Observed travel times of a route segment can be used.
• Approach 3 – regression model: If neither schedule data nor observed data is available then an equation given by route segment attributes such as distance, number of stops in between and time of day information and day of week information can be used to estimate the travel time

6.2.4.1 Travel time regression model
The regression model can be written as

Where α is the estimated constant coefficient, β is an estimated vector of coefficients on route segment attributes, γ is an estimated vector of coefficients on time information, θ is the estimated coefficient on service type, while ε represents unobserved error term. This unobserved error term is assumed to follow identical and independent normal distribution with zero mean and an estimated variance σ2 on all route segments. The explanatory variables are: Ride_distance, Number of stops in between, Time of day Dummy Variables, Day of Week Dummy Variables, and Service Type dummy variables.

EZLink card data provides travel distance and recorded travel time for all public transit services in Singapore. The following data will be extracted from EZLink card data:

Name	Description
Boarding_Stop_STN	This is the boarding stop/station name as recorded in EZLink Card
Alighting_Stop_STN	This is the alighting stop/station name as recorded in EZLink Card
Ride_Start_Time	This is the ride start time as recorded in EZLink Card
Ride_Distance	This is the ride distance as recorded in EZLink Card
No_of_Stops	This is the number of stops traversed on this record trip. It is extracted based on service line stop sequence.
Hx	X ϵ {0,1,2,….,21,22,23} This is dummy variables for time of day. It is extracted based on the boarding time of day.
Dx	X ϵ {1,2,3,4,5,6,7} This is dummy variables for day of week. It is extracted based on the boarding day.
Mode	This is dummy variable denoting the travel mode. 0 for Bus, 1 for RTS including MRT and LRT.

Note that for time of day, we map it into discrete time intervals, , so is day of week. In future weather condition such as rainfall could also be added as explanatory variables.

6.2.5 Step 5: For each OD determine set of possible paths
Figure depicts the overview of path choice set generation method proposed for SimMobility. In summary, it contains the following steps:

• Generation of Stop-to-Stop Path Choice set on PT network
• Generation of access walk alternatives
• Generation of egress walk alternatives
• Concatenation of stop-to-stop path alternatives, access walk alternatives, egress walk alternatives to final Point-to-Point Path Alternatives

6.2.5.1 Stop-to-Stop Choice Set Generation We propose to use a combined k-shortest path and link elimination approach to generate the stop-to-stop path choice set for all stop-to-stop pairs in the network. We can refer to Yen’s work for the k-shortest path algorithm (Yen, 1971). The k-shortest path algorithm can be applied to the transformed network directly. Figure below depicts the design framework of generating the choice set using a combined k-shortest path and link elimination method for public transit network. Note that stop-link refers to the actual road segment between adjacent public transit stops that is traversed by public transit service lines.

The main purpose of link elimination is to demonstrate how a passenger will react when there is a certain blockage in the network. Link elimination is analogous to simulating a blockage at certain road segments, while re-searching for the shortest paths is assuming that people will always chose the current shortest path in the network. As specified in section 6.2.1, we have transformed the actual service routes and links into route segments. If we simply eliminate one route segment in the PT network, it does not reveal the affecting network by introducing road blockage. Therefore, a “transit link to route segment” incidence matrix is needed to build up the connection between blocked road and affected route segments. The elimination method is then eliminating all the route segments that are associated with one link on the actual transit network one by one.

The desired stop-to-stop paths choice set Pss st for stop-to-stop pair {Ss,St} contains set of paths specified in the following format:

Where is the ith path in _Pss st_, is the starting stop , _S1i,S2i,S3i,......SQki_ are the transfer nodes in sequence where _Qk_ denotes the number of the last transfer node before reaching ending stop _St_.

6.2.5.2 Generation of access and egress walk alternatives
Generation of access and egress walk alternatives is accomplished by selecting feasible boarding and alighting stops given the location of origin, destination and all stops in the PT network. We propose to select all surrounding stops which are within a configurable radius (default = 300m) with respect to origin and destination respectively. The generated access walk alternatives Am, and egress alternative Em for OD pair {om,dm} will have the following format:

Where _ai_ is the ith access walk alternative in _Am_ , _SiAm_ is the boarding stop selected in the ith access walk alternative in _Am_, while _ei_ is the ith egress walk alternative in _Em_ , _SiEm_ is the alighting stop selected in ith egress walk alternative in _Em_.

6.2.5.3 Concatenation of point-to-point path alternatives
For each OD pair {om,dm}, we will obtain its access walk and egress walk alternative Am and from section 6.2.5.2, and stop-to-stop path choice set will be obtained for each stop-to-stop pair {} from section 6.2.5.1, For each selected boarding stop in access walk alternative set , and each selected alighting stop in the egress walk alternative set , point-to-point path alternatives can be constructed by concatenating , stop-to-stop path alternative and . The final point-to-point path alternatives for OD pair , will have the following format:

6.3 Coverage Test
Once a list of suitable paths that a passenger is likely to take when travelling from a given origin to a given destination has been estimated, it is important to verify how accurate this list is. This is achieved by checking that the Path Set Generation Model correctly identifies all paths that have been used in reality. The steps to doing this are as follows:

• Step 1: Identify the sequence of rides performed in an EZ link trip from origin O to destination D.
• Step 2: For each EZ link trip, check whether the path observed is included in the list of possible paths for the given OD.
• Step 3: Aggregate results over all EZ link trips in the validation set.

7 Model 2: Route Choice Model A path-size route choice model is proposed based on the overlapped route segment for the base model. We refer to Bekhor, Ben-Akiva, & Ramming (2006) for the path-size formulation. The utility attributes are listed in section 7.1. Route choice is performed dynamically when the departure time is given, therefore, a dynamic travel time calculation process, as described in section 7.2 is need to update the estimated in-vehicle travel time and waiting time depending on departure time.
7.1 Utility Attributes
The following attributes are proposed to constitute the utility function for the base model:

• Travel Time
  - waiting time twait
  - In-vehicle time ti vehicle
  - Walking time twalk
• No of Transfers, ntransfer
• Monetary Cost ci
• Logarithm of Path Size ln P Si
  Mathematically, the utility for path i can be written as:

Where _βx,p_ are parameter coefficients to estimate and _εi_ is the error term which is assumed to be Gumble distribution with mean = 0, and variation left to be estimated. The path size for path i is given as:

where route segment _Cn_ is the choice set which path i belongs to, _lr_ is the length for route segment r, _Li_ is the total length for path i, _γ_ is the accounting factor for the different in route length and _δrj_ is the indicator whether route segment r is inside path j.

7.2 Dynamic travel time calculation process
Given a departure time t, for every path denoted as pi = {oi,di,r1,r2,....rN} where ri is the ith route segment along the path, from path choice set Pod, we can identify its stop sequence s={oi,stop(r1),stop(r2),....di}. Perform the following steps to find out its waiting time and travel time:

• Step 1 - initialization: walking time twalk=0, waiting time twait=0 and in-vehicle travel time ti vehicle=0, index current=0, index next=1, current time tcurrent=t
• Step 2 - stop criteria: If Scurrent=di, then STOP. Else, Go to Step 3.
• Step 3 - updating: At station Scurrent, check the type of associated route segment for reaching next station along path pi, denote at rcurrent
• If _rcurrent _ is walking link,
  • update twalk = twalk+trcurrent ; tcurrent=tcurrent+twalk
• If is transit link (route segment),
  • search for the earliest available arrival time at Scurrent for all available service lines on rcurrent, and denote it as tlScurrent with service line l as the expected boarding service line, then
  • update twait = twait + tlScurrent-tcurrent;
  • update tivehicle = tivehicle+tlSnext-tlScurrent
• update current = next, next = next+1

7.3 Incorporation of real time information in route choice model Real time information is incorporated into route choice model in two ways: Each passenger is associated with a flag indicating whether they have access to real time information. This is designed mainly to capture the passengers with information access via smart phones. Each stop is associated with a flag indicating whether it has real-time bus arrival information displays. When either the passenger has access to real time information or the passenger is at a stop with real time information display, the dynamic waiting time will be calculated based on difference between passenger arrival time and predicated arrival time of attractive service lines.

8 Model 3: Departure Time Choice Model
Few departure time choice models are proposed as a base model for public transport demand modeling.

• Model1: Constrained Uniform or Poisson Distribution w.r.t late penalty and etc
• Method 2: MNL model based on expected shortest travel time (historical data)
• Method 3: Mixed Logit Integrating Nested path size model with departure time selection as 1st layer choice.
  (To be filled up when the model is finalized)

9 Model 4: Reschedule Activity
The rescheduling activity has been discussed briefly in section 5.2. It is implemented in SimMobility.

10 Model 5: Day-to-Day Learning Model
The day-to-day learning model has been discussed briefly in section 5.2.

11 Summary of differences with Short Term SimMobility
SimMobility short-term is a microscopic simulator where the movement of each vehicle is simulated in great details. Differences in public transit implementation from mid-term are listed here.

11.1 Demand generation & Route Choice:
In Mid-term demands are generated in the pre-day level as described in section 4.2. For short term demand will be received from Mid-Term so the trip chain will contain all the sub-trips by all different mode and waiting activities as well.
Short-term will also receive the route generated for the agent in the mid-term as guidance for the pre-trip only. En-route route choice will be generated in short-term simulator in case there is any need to change the planned trip.

11.2 Movement of the Bus
Movement of the buses in the short-term model will follow the microscopic movement which includes lane-changing model, gap-acceptance model etc. similar to the car driver. The movement of the buses in the microscopic level is further classified in two different sections as follows:

11.2.1 Movement near the bus stop:
In short-term when a bus is approaching to a bus stop it must change the lane to the lane next to the bus and also gradually slow down to finally stop at the bus stop. Buses must follow the following steps to implement this behaviour.

• Step 1: At bus-to-stop distance (currently set to 50m) the driver must consider a lane changing (discretionary lane-change regime) to come to the lane next to bus stop.
• Step 2: Buses enter a mandatory lane-changing regime when a bus stop is within its bus-to-stop visibility distance. If buses cannot get sufficient gap to do a mandatory lane change then they will do a forced merging in order to change the lane.
• Step 3: At a safe braking distance buses will have a corresponding deceleration in order to stop at the appropriate location at the bus stop.
• Step 4: Once the bus is ready to leave the bus stop it will gradually accelerate. NB. The must be have to wait for an appropriate gap to get merged in the traffic if the bus stop is on a bus-bay.
• Step 5: Buses will have a very high preference to choose the bus lane if there is a dedicated bus lane on the road.
  Exception: Bus driver may choose to skip a bus stop if there is no demand at the bus stop & no passenger need to alight at that bus stop. This behaviour depends on bus driver’s characteristics & also in case buses are running behind the schedule.

11.2.2 Movement away from the bus stop:
Bus drivers will receive the bus route from the controller and they will follow the scheduled route. When they are away from the bus stop they will behave similarly to car drivers, with the only exception that they will have high preference for the bus lane if it exists on the road.
Exception: In case of the express bus route (with less number of bus stop) bus driver will have the privilege to choose the shortest path between the bus stops.

11.3 Dwell Time:
Passenger boarding & alighting in short-term is depicted in the figure below. When a pedestrian reaches the bus stop they will start their waiting activity at the bus stop as described in section 4.2. During their waiting some of the informed pedestrian may query for the next bus arrival time and based on the information they may consider an activity reschedule decision (described in section 4.2).
Once the bus reaches at the bus stop agents at the bus stop who were waiting for that bus will start boarding activity according to their order of reaching at the bus stop. Each agent will take a different time to board based on their age factor and disability/ability factor. Passenger in the bus whose destination of the sub-trip is this bus stop will also start alighting activity & this is also as per their individual characteristic. If the bus reaches its maximum occupancy or if there are no more agent to board or alight bus, it will leave the bus stop & merge to the traffic. Short-term will also allow “late-arrival”.

12 Scalability of solution

TO BE COMPLETED SimMobility is a real time simulation software. It is therefore imperative that SimMobility runs quickly enough to allow this to happen. This section estimates the peak volume of work that may be expected.
SimMobility will need to model all public transport demand. Some analysis was done on the EZ link records of a typical day, Tuesday 12th April 2011, to determine the number of trips which started each hour. The results are given in the figure below.

*** GRAPH OF NO OF TRIPS IN PROGRESS PER HOUR *** *** GRAPH OF NO OF RIDES PER HOUR ***