Simulation Tool Use Cases

As detailed in Chapter 2, use cases are a mechanism for eliciting and structuring models of system functionality. Basic questions include: What will the simulation framework do? What are minimal levels of support for specification of scenarios, simulation, and post-simulation analysis? What types of decision making support will be provided? Table 3.1 contains a first-cut list of potential use cases for the simulation model.

Table 3.1: Potential use cases for the simulation model

Support for Scenarios. Part of the difficulty in framework development comes from a lack of specific constraints and, in this case, the need to simulate behavior in urban areas, the transportation overlay, and any potential interactions.

A well-designed framework will support assembly of simulation scenarios from multiple perspectives. In particular, we need to be able to build up scenarios in two ways: (1) through composition of collections of entities in a bottom-up manner, and (2) by breaking down aggregate data sources into a distribution of entities in a top-down manner. The latter would allow us to compare scenarios assembled from data gathered from a sampling of individual detailed sources, and from scenarios initialized using totals gathered at a higher level of detail. For example, we might know the number and type of cars registered in a city, their fuel efficiency, and the estimated distance they travel daily. From this we could assemble a simulation that gives us their average fuel consumption. Conversely, we might take a survey of all of the gas stations and know exactly how much fuel was pumped into a number of vehicles in the city, and from that deduce the distance each of them drive. By comparing similar scenarios constructed from different data sources, we might check our models for consistency as well as calibrate it under a variety of existing sources of data.

1. Bottom-up Scenario: Since the arcology is designed from the ground-up, starting at the individual level, the structure of our model would allows us to calculate the aggregate performance at higher levels of organization, such as a the city and national level.
   • Define number of simulation units, connectivity between units, schedule of transaction events, schedule of reaction events, initial conditions.

   • Output aggregate performance for groups of units.

2. Top-down Scenario: The present day scenario is built in a top-down fashion from various data sources. Statistics are only tracked from relatively high levels on the organizational hierarchy, so we must extrapolate some data to flow down to fill the detailed subcells of the structure.
   • Define high-level consumption rates for groups (using publicly tracked and available data), provide distribution histograms for each type of resource and transaction rates for each subunit.

   • Output unit-level quality of life, performance.

Support for Simulation/Analysis. One of the main types of problems this transportation network simulation needs to address is passenger demand generation. Different types of transportation infrastructures could be evaluated against each other to determine how well they meet that demand. Many existing transportation problems tackle ways to increase throughput or capacity. But the task of urban planning should also focus on arranging its physical layout to economize demand loads in addition to building out transit infrastructure for maximum capacity. For example, instituting staggered work hours or telecommuting programs can relieve peak rush hour traffic congestion without spending a fortune widening highways or building additional transit lines just to increase throughput for a few hours of peak usage a week. Local governments should know how much incentive they ought to offer to businesses to encourage them to implement flexible work hours. Similarly, they'd want to know how much to invest in telecommuting infrastructure (such as municipal broadband) in order to provide productivity benefits similar to simply adding highway lanes or additional thoroughfares.

By simulating demand, we can also create a transportation system that is more sensitive to the needs of individual travelers rather than the aggregate flow of passengers. This would allow us to create schedules around the traveler's itinerary rather than forcing the traveler to always plan around fixed train, bus, ferry, and aircraft timetables. By only tracking passenger flow through fixed schedules, we throw away some valuable data on when the passenger really wants to depart or arrive, which is a significant factor when comparing mass transit to personal vehicle use. For instance, if everyone starts work exactly at 8:30, but buses only run hourly on the hour to that particular stop, then the extra half hour everyone spends waiting per day essentially counts as extra commuting time in their books. The system operators might think they're doing quite well by only measuring the time passenger spend sitting on the bus and making connections, but the passengers would perceive much higher inconvenience and time costs.

A more effective public transportation system should succeed in making the world ``smaller'' by making each district of a municipal area more readily accessible, allowing people to travel between places where they live, work, run errands, and seek entertainment. Under the trunk and feeder paradigm often used to organize mass transit in metropolitan areas today, travel through the system can take considerable time unless your source and destinations happen to be near major hubs or just down the street from each other on an established route. The worst case scenario for many trips off of a main trunk line would consist of catching a local feeder bus route to the nearest trunkline light rail station, making a transfer at a major hub or two, and finally catching another feeder route to your ultimate destination. Each transfer would typically consist of at least 5-20 minutes of waiting for the next connection. Compared to driving your independently owned vehicle, public transit would often take two to four times longer, even with traffic. Commuters would travel twice per day, so the time savings of taking a personally-owned vehicle could add up to an additional 1-2 hours of personal or family time at home each day. Public transportation systems could use much improvement to make mass transit preferable to driving, but often it becomes an alternative to escape congestion on the roadways rather than the primary mode of travel. Drivers typically support investment in public transportation only insofar as it gets other cars off the road.

An advanced busing system (such as the HCPPT system proposed by Cort$\acute{e}$s [13]) would dynamically generate routes and schedules based on individual source and destination requests from each passenger, and thereby achieve efficiencies and meet customer requirements far better than current fixed schedule transit fleets. This could make public transportation much more attractive to people who drive their own vehicles everywhere in order to maintain that degree of flexibility. During peak commuting hours, intelligent scheduling has the potential to reduce individual commute times, as most buses could be scheduled more like express routes, filling up at one location and proceeding directly to stops at a common destination with minimal stops or transfers or jaunts down back roads along the way. During off-peak hours, buses would not run nearly empty along the exact same routes at a drastically reduced frequency, but would run only on demand, cutting down unnecessary wait times and making them more convenient for midday or late night errands. All we'd need to implement an intelligent, dynamically reroutable transit system is a robust communications network with a simplified interface to provide route updates to vehicles and transfer instructions to passengers.

Performance Metrics

What defines a good inter-modal transit system? The conflicting goals might be characterized as: speed, latency, coverage, and efficiency.

• ``Speed'' refers to how fast the transit system can get a passenger or cargo item from point A to point B. Unfortunately, this does not depend entirely on the cruise speed of the vehicle alone, but also time spent making transfers and additional preparations (such as passenger check-in and luggage screening at airports)
• ``Latency'' refers to additional waiting time between when a passenger wants to go somewhere and when the transit system can actually take them. It is affected primarily by the frequency of service, particularly how well it matches demand. Extra time that people have to wait at their source or destination should be counted against the system -- though this is often overlooked in transit performance metrics today. The data just isn't available, or people have relegated themselves to adjust their schedules around the system's timetables. This ``latency'' metric will usually be at odds with efficiency due to economies of scale, since making passengers wait longer times between pickups can cluster them into larger groups.
• ``Coverage'' refers to how well the transit system covers the service area, which should include how far people have to walk from their doorstop to enter the system. Broad coverage is more difficult to achieve for a mass transit system, especially as population density decreases and residences and businesses become more spread apart.
• ``Efficiency'' might refer to two terms: monetary frugality on fixed infrastructure and operating costs, as well as in terms of conservation of fuel and resource utilization. Efficiency pretty much always counterbalances against each of the three other goals, so we often must express how much extra money or fuel we are willing to expend to achieve gains in speed, latency, or coverage.

Transit Schedule Optimization

To achieve reasonable improvements in these multiple competing performance goals, we must employ some manner of vehicle fleet optimization in order to investigate the full potential performance of a transit platform. An intelligent transit system would take advantage of existing and emerging ubiquitous computing and communications networks to make itself more responsive to customer requests and to deliver passengers in a more coordinated manner. While fixed route schedules might work well for normal demand based on projections, the true performance of a transit system should take into account all available emerging information. This could include advance knowledge of special events that create spikes in demand to certain stations, or even unforeseen events such as breakdowns that close transit lines and trigger a failure mode of operation with an altered schedule.

An optimization problem formulation should dynamically take in data about the arrangement of stations, passenger requests for transit between available stations, and properties describing the vehicle fleet and constraints pertaining to their movements between stations, and provide an optimized plan for delivering passengers to their destinations. This would allow us to identify and focus on the performance impacts of physical design parameters independently of the often arbitrary fixed scheduling methods. The optimized schedule could be calculated in near real time, incorporating updates from the evolving system state in a rolling-horizon fashion. It would incrementally compute the next series of interchanges and transfers in the future, at first working on projected demand data augmented with more solid data collected from vehicle and station sensors.

Once we identify transit scheduling paradigms that perform well, we might simplify the network somewhat by establishing some fixed strategies, patterns, or even routes. However, we see no reason why a fully dynamically-reoptimized transit system couldn't guide its passengers through a constantly updating and changing network or vehicles through the use of mobile phone text messages or a dedicated digital guide.

Coordination of Dynamic Optimal Schedules

The main way we'll be able to improve the efficiency of mass transit (aside from simply improving fuel economy) would be to use existing resources more effectively through extensive use of optimization. With enough planning and foresight, optimal scheduling is straightforward to perform. However, things never quite go as planned, due to a variety of unpredictable factors such as weather and accidents and just plain last-minute changes in schedules. In order for the optimal plan to be of much use, we ought to continually collect enough data in real-time to monitor and reevaluate schedules as able. This requires that we have a communications system in place that allows us to poll the status of our cargo, passengers, and transportation vehicles. Equipage for this type of system would have been cost prohibitive in the not-too-distant past, but now that geolocation devices, mobile computing, wireless networking, and cellular data network backbones have become nearly ubiquitous, we'd be silly not to put all this capability to good use.

So instead of having fixed timetables locked down and fixed weeks, months, or even years in advance, based only on projections from previous observation of seasonal flows in the past, we could perform schedule optimization on actual data. This data would factor in individual requests from each customer, including their destination and schedule constraints (or better yet, their schedule flexibility). Vehicles could report their current location and status, meaning they'll always be right on time - especially since they could report their arrival time themselves. Monitoring and reporting of deteriorating road or weather conditions could automatically update the schedules of every vehicle in the network to account for and mitigate the effects of new delays.

Comparison Framework for Multiple Urban System Models

Now that we have specified a model for urban-enabled demand on a transit network, a system simulation engine, and a schedule optimization algorithm to direct/control the action, we can set up an iterative optimization of system design that will analyze the design parameters for each particular simulation scenario. This framework will help us evaluate urban design and infrastructure in ways that should help drive progress towards efficient and sustainable societies that serve the people who live in them.

To see the usefulness of this framework, consider the following scenario. We could propose a new construction or infrastructure project, show its benefits in this kind of a simulated model, and later validate those benefits using data collected from the real system. Competing developers might even submit simulations of their designs to provide benchmarks using this analysis platform.

The ability to compare several optimization components, several system structures, different modeling methodologies, all using the same data interchange format to facilitate direct comparisons between both real and simulated evolution of the scenarios, allows us to take a systematic, objective approach to tackling urban improvement projects. Adapting such a simulated and real system performance comparison framework will allow us to have more complete impact assessments by making sure every study or proposal is analyzed consistently, using the same inputs, and doesn't sweep away or ignore unwanted side effects and consequences. Urban planners could use these studies to provide ammunition for driving changes toward the way they envision their communities. An intensified focus on operational efficiency and continuous improvement driven by pervasive measurement and analysis will lead towards a leaner, sustainable society where we could direct a higher ratio of resources towards forward progress instead of mere subsistence.

Transit Simulation Requirements

With that, we proceed to develop the outline for what our simulation must accomplish. See Table 3.2.

Table 3.2: Simulation Requirements