Fall 2010, Weeks 6-10
11:00-13:00 on Wednesdays in QB 1.59
Instructor: John Lees-Miller
| Item | Weight |
|---|---|
| deliverable in week 7 | 5% |
| deliverable in week 8 | 5% |
| final presentation | 30% |
| final report: group component | 40% |
| final report: individual component | 20% |
Please use this installer (20MB). You can use the zip file above on your home machine, but this installer sets up shortcuts and file associations. Note that the simulator only runs on Windows, at present.
This tutorial is a good reference on how to use the simulator.
You will need a map of the area, and you will have to know the scale of the map image, in meters per pixel. (Hint: A screenshot from Google Earth or Google Maps is good, and Google Earth has a tool for measuring distances.)
You will need to identify the major demand generators in the area. (Hint: Google Earth and Google Maps label most major facilities and land marks.)
Your site can be anywhere, but keep in mind that you have to estimate what the potential passenger demand will be. For ideas, you can go to http://www.ultraprt.com/applications but please do not use a site that has already been studied by someone else.
Alternatively, you can work from a greenfield (undeveloped) site, and develop your site around your PRT system, rather than trying to fit the system into an existing site. Keep in mind, however, that designing both the site and the PRT system will require more work. If your group wants to do this, please discuss with me before the end of week 6.
Also note that your service area must not exceed 5km by 5km, due to limitations of the simulator.
Now you are ready to place stations near your site's demand generators. Exactly how many stations you place and where you place them depends on your estimates for the demand between pairs of stations. For this project, you will have to make several (educated) guesses at what the demand will be.
When deciding where to place stations, you should be thinking about the following guidelines.
To represent the passenger demand, you will create one demand scenario per group member. Each scenario describes the passenger demand at a particular time. For example, a large urban system might have an AM peak during morning rush hour, in which most of the demand is from the outskirts to the center. The evening rush hour is the PM peak demand. Outside of peak times, the passenger flows are typically smaller and more balanced; that is, the average flow into each region tends to equal the average flow out. Other scenarios might come from special events, for example at a stadium or convention centre. Each scenario will suggest different system optimisations.
The data required to define a scenario are the in flow and out flow of vehicles at every station. As mentioned above, the total flow (in plus out) for each station must be less than 300 vehicles per hour. Also, the sum of all the in flows must equal the sum of all the out flows for each scenario; these sums are written Ti in the table below. Your scenarios must include one balanced flow scenario, in which the flow in and out of each station is (roughly) equal. The others should represent peaks with different spatial distribution and intensity. The total flow (Ti) for the whole system must be at least 700 vehicle trips per hour for the balanced scenario and at least 1300 trips per hour for the peak scenarios.
Note that the simulator needs to know the demand in vehicles per hour; the average vehicle occupancy relates this to passengers per hour. To help calibrate your numbers, a reasonable guess at vehicle occupancy is 1.2 passengers per vehicle, but it will be higher for some sites, for example if there are many couples or families using the system. Different scenarios may also have different vehicle occupancies.
Finally, for each scenario you will have to estimate how many hours per day (or per week) each scenario will occur. We will assume here that the actual demand will always be like one of the scenarios. This allows us to estimate the system's annual patronage, which will be important in subsequent sections.
You may want to organize these data in a table like the following (it would be a good idea to use a spreadsheet).
| Vehicle Flows (vehicles/hour) | ||||||
|---|---|---|---|---|---|---|
| Scenario: | Balanced | AM Peak | PM Peak | |||
| Station | In | Out | In | Out | In | Out |
| Park Plaza East | 80 | 80 | 50 | 250 | 200 | 80 |
| Park Plaza West | 80 | 80 | 50 | 150 | 200 | 30 |
| ... | ... | ... | ... | ... | ... | ... |
| Total In/Out | T1 | T1 | T2 | T2 | T3 | T3 |
| Total Hourly Flow | T1 | T2 | T3 | |||
| Hours / Day | ... | ... | ... | |||
| Total Daily Vehicle Flow | ... | |||||
| Vehicle Occupancy | 1.2 passengers / vehicle | |||||
| Total Passengers / Day | ... | |||||
| Total Passengers / Year | ... | |||||
The next step is to run a gravity model to turn each scenario into an origin-destination demand matrix (OD matrix) that you can use with the simulator. The OD matrix specifies the average number of vehicle trips per hour between each pair of stations. The simulator uses this matrix to to generate passengers randomly according to a Poisson process.
The equations for the gravity model and an algorithm for running it will be described in class. Use the straight-line distances between stations as "costs." (Note: the version of the sim that you downloaded in the first week did not report straight-line distances in the output; the latest version does.) The suggested dispersion factor is 0.5. You are free to tweak this factor, or to edit the resulting OD matrix directly, if you wish, provided that the resulting matrix still satisfies the constraints on total flow at stations and for the system as a whole. You can implement the algorithm however you like; it's possible to do it in MATLAB or in Excel (hint: use the solver add-in).
Now you are ready to connect the stations with guideways. We'll do this in three stages.
For (a), you will have to show me the simulation in class in week 8. For (b), each group member must write an appendix to the final report that documents the optimisation process for his/her scenario.
Your objective is to minimize the sum of system costs and user costs, according to the following cost estimates.
| Capital Costs | £ |
|---|---|
| 1 vehicle | 50k |
| 1 station | 0.5M |
| 1 depot | 0.4M |
| 1 km at-grade guideway | 1M |
| 1 km elevated guideway | 2.5M |
| other | +50% |
| Operating Costs | £ |
| 1 passenger km | 0.15 |
| User Costs | £ |
| 1 minute passenger travel time | 0.1 |
| 1 minute passenger waiting time | 0.2 |
Some of the costing inputs you can read directly from the network, but the number of vehicles and the mean passenger waiting time must be estimated by simulation. You should run 5 simulations and average the results, in order to get reliable numbers.
The simulator output includes the total track length, but the simulator does not know anything about grades. For costing, you should estimate roughly what percentage of your track is at-grade. Do not worry about getting this exactly right, because all of the costs are rough; just try to estimate to within 10% or so.
Once you have computed the base capital costs (vehicles, stations, depots and guideway), add 50% to cover related expenses, such as central control software and hardware, and a contingency.
The system operating costs are given as a rough total cost per passenger kilometer. The simulator output includes the 'mean demand-weighted passenger trip distance,' which you can use to compute the operating cost per passenger trip. To scale this up to an annual operating cost, you will use the passenger trips / year figure from task 2. (Note that when you are optimising for a single scenario, multiplication by the total passengers per year effectively assumes that the demand is always like this scenario; this is not really true, but it is good enough for our purposes here.)
You can approach the user costs similarly; here the relevant simulator outputs are the 'mean demand-weighted passenger trip time' and the mean passenger waiting time. The user costs are based on a standard value of time calculation.
These costs are rough estimates. The main point is that there are trade-offs between capital costs, operating costs and user costs. For example, you can build more guideway to reduce travel times, which increases your capital cost but decreases your operating and user costs.
Operating and user costs occur over time, so you should use present values to weigh them against capital costs. Assume the standard public works discount rate of 6% per year, and discount over 30 years.
These costs give you a way of evaluating networks objectively. However, you should be mindful of externalities. For example, this does not include a cost for visual intrusion in culturally sensitive areas. It also does not account for changes in pedestrian flows; areas that were once quiet could become busy, and vice versa. You may reject a design that is "optimal" by cost but undesirable for other reasons.
I strongly recommend that you create a spreadsheet to keep track of the cost calculations.
Once each member of your group has optimised your initial network for one scenario, you will apply what you've learned to design a network that works for all of them.
To evaluate your final network, use a composite cost that describes its combined performance on all of the demand scenarios. The capital costs apply to all scenarios equally, but the operating and user costs depend on the demand. So, you should evaluate your final network on each scenario and record the trip distance, trip time and passenger waiting time for each one. Then you should weight these by how frequently each scenario occurs (as estimated in task 2) and apply the cost model. (Also note that the number of vehicles you need is the largest number needed in any single scenario.)
You should do several iterations to improve the composite cost. Again, be mindful of externalities.
Note: The simulator will only let you enter one OD matrix at a time, but you can copy and paste OD matrices to/from the sim. The best way to do this is to copy the matrix from one simulation into Excel, delete the last row and the last column (the totals), and then paste it into another simulation.
To measure the user benefits that could come from building a PRT system, one must compare user costs with PRT to user costs with existing modes. Here we will compare PRT with a very simplistic model of a bus system. Assume that users wait an average of 5 minutes for the bus, and that the average travel time by bus is the time taken to travel the straight-line distance from origin to destination at 12km/h. (Note: the version of the sim that you downloaded in the first week did not report straight-line distances in the output; the latest version does.) Use the travel and waiting time savings (or not) with the cost table to compute user benefits and system costs.
See section 2 in the final report.
Pick two stations that are interesting or challenging, for example due to large size or passenger volumes, culturally sensitive surroundings or an architecturally interesting setting (e.g. integrated into a building), and produce a conceptual design for each one.
You should produce a plan view of the station, keeping the following questions in mind.
The "vehicle side" of the station should be consistent with these design guidelines; see also this overview. The 3D design template (in SketchUp) is particularly helpful. You should consider where the main line and the on- and off-ramps will go.
Note: hand-drawn sketches are fine.
Bonus: Construct an architectural rendering (e.g. in SketchUp) of the station. You can use the 3D design template in the guidelines to get started.
See section 3 in the final report.
Each group's presentation will last around 10 minutes with a few minutes for questions. Your presentation should cover essentially the same content as the main body of the final report (sections 1-3), with a focus on the visual and qualitative aspects of your design. Every group member must participate in the presentation.
Each group should submit a report as described below. The main body of the report (sections 1-3) is limited to 5000 words on 20 pages. In addition, each group member should submit an appendix (see below) of up to 600 words on 6 pages. Note that these are word and page maxima: you should aim to be concise (and use lots of pictures!).
In addition to the written report, please submit the following ATS/CityMobil (.atscm) simulation files.
To submit: either upload the document and supporting sim files to fluff and send me the link, or drop them in the appropriate box in the Queen's School Office.
The report will be marked according to the following five equally weighted criteria.
For each of the two stations:
Your appendix should describe the process that you (individually) went through to optimise the system for your scenario. In particular, you should provide a record of three iterations; for each one, you should include