Behavior of individuals travelling on the mass transit system is defined by the sequence of activities shown in Figure 4.5. The four parties (or actors) that participate in transit behavior are: passenger, station manager, vehicle, and scheduler. Swim lanes show their roles and responsibilities in enabling behavior.
The simulation is based on a discrete event simulation engine. This means that state changes in the system structure are triggered by the firing of events which occur along the global time line queue. The simulation engine runs a model by populating the global time queue with scheduled events and executing instructions triggered by events in order. The system global time advances to the time of the last event, and any state transitions triggered by that event are executed so they can perform their operations, sometimes scheduling additional events in the future event queue. Thus, the simulation perpetuates events and continues in time until the program reaches a time limit or there are no more events left on the simulation queue.
This transit simulation consists of a conglomeration of relatively simple entities working together. We'll introduce them roughly in order of increasing complexity.
The simulated people entities exist purely to create demand on the transit system. In the current simple commuting scenario, they simply live in a residence at one node and work at an employer at a possibly different node. They will enter the transit system based on their work schedule. Some configurable time in advance of their travel, they will submit a TransitRequest to the global transit scheduler system. By having advance knowledge of when the passenger needs to travel, the fleet schedule optimizer can ostensibly do a better job reducing passenger waiting time.
They enter the transit system by traveling to their local Station and procuring a TransitToken programmed with their final destination. From there on, they are shuffled around by the other entities of the transit system until they reach their destination station. Once they arrive at their final stop, they are placed into the appropriate employer cell in that neighborhood.
Vehicles of the same type are considered completely interchangeable, so the only state information of any importance for them is their capacity and their next immediate destination node (either a station or a waypoint). Vehicles simply wait to receive a transitEvent and then pick up as many people as they can from the station's PassengerPools before leaving for their next destination.
When vehicles arrive at a station, they will dock in an available berth and immediately empty out all of their passengers into the station for sorting back into PassengerPools.
Each station has a StationMaster process that reads the global fleet schedule distributed with each transferEvent and organizes all passengers and vehicles. It first sorts all passengers into PassengerPool queues and all vehicles into rosters grouped by their final and next destinations, respectively. After a brief period of time allowing passengers to make their connections onto the next vehicle, the firing of the transitEvent signals that all transfers have completed and the vehicles disembark to their next destination.
The global scheduler receives incoming passenger requests, occasionally triggering the generation of a new optimized schedule. Then it gradually advances the global clock until the time comes to serve the first passengers arriving at the station. The global scheduler begins firing a succession of transferEvents and transitEvents at regular intervals to synchronously push the Vehicles and StationMasters through their state actions.
The schedule generation MIP is formulated using the following sets of variables to track the inventory and movement of passengers and vehicles:
All variables are integers, but only the vehicle movement variables must explicitly be declared as integer.
Rowin Andruscavage 2007-05-22