|Surface Transportation Efficiency Analysis Model (STEAM)||User Manual|
The Surface Transportation Efficiency Analysis Module (STEAM 2.0) is the most recent version of the transportation/economic impact analysis tool developed by the Federal Highway Administration (FHWA). In 1995, the FHWA developed a corridor sketch planning tool called the Sketch Planning Analysis Spreadsheet Model (SPASM) to assist planners in developing economic efficiency and other evaluative information needed for comparing cross-modal and demand management strategies (DeCorla-Souza, Cohen & Bhatt, 1996). In 1997, FHWA introduced the Surface Transportation Efficiency Analysis Module (STEAM) for detailed, system-wide analysis of alternative transportation investments. STEAM was the first FHWA impact analysis product to use input directly from the four-step travel demand modeling process.
STEAM 2.0 retains all of STEAM's functionality and adds two new features: the ability to report mobility and safety benefits by user-defined districts and a new accessibility measure. The district-level reporting feature allows users to compare the impacts of transportation investments to resident trip-makers across aggregations of zones, which may represent neighborhoods, policy areas or political jurisdictions. The accessibility feature produces estimates of employment opportunities within a user-defined travel-time threshold of a district across a base and improvement scenario. Both an index and the percentage change are provided. The district reporting and accessibility features are useful new tools for gauging the social impacts of transportation investments.
STEAM 2.0 post-processes the traffic assignment volumes generated from conventional four-step planning models in order to get more accurate highway travel speeds, especially under congested conditions. It also performs risk analysis to clearly describe the level of uncertainty in the results of the analysis, so that the debate over transportation investments can shift from unproductive technical controversy to compromise and action.
Like STEAM, STEAM 2.0 is based on the principles of economic analysis, and allows development of monetized impact estimates for a wide range of transportation investments and policies, including major capital projects, pricing and travel demand management (TDM). Impact measures are monetized to the extent feasible, but quantitative estimates of natural resource usage (i.e., energy consumption) and environmental impacts (i.e., emissions) are also provided. Net monetary benefits (or costs) of alternatives can then be used to evaluate trade-offs against non-monetizable benefits, including sustainability and community livability.
STEAM 2.0 is highly flexible in terms of transportation modes, trip purposes, and time periods analyzed. It provides default analysis parameters for seven modes (auto, truck, carpool, local bus, express bus, light rail, and heavy rail) and allows the user to deal with special circumstances or new modes by modifying these parameters. Users are allowed to specify different values of time for separate travel markets. The user also provides Base Case and Improvement Case trip tables for different trip purposes, which will be analyzed separately by the model. Regarding time periods, STEAM 2.0 can be applied to average weekday traffic or to peak and off-peak traffic with different definitions of the peak periods.
The primary objectives of STEAM 2.0 are to provide a framework for estimating impacts of multimodal transportation alternatives and assessing their overall merits.
The STEAM 2.0 analysis provides estimates of the following measures of effectiveness for proposed actions:
As shown in Exhibit 2.1, STEAM 2.0 consists of four modules:
This section describes the procedures used by STEAM 2.0 for:
The analysis of user benefits in STEAM 2.0 focuses on how proposed improvements affect travel conditions for a set of "market sectors" defined by the model user. Market sectors can be defined to represent different modes, trip purposes, and time periods, e.g., peak period auto work trips.
For each market sector to be analyzed, the STEAM 2.0 user provides a Base Case and an Improvement Case trip table, specifying the number of trips from each analysis zone to other zones. User benefits will be calculated for each zone pair and then summed over all zone pairs. Zone-to-zone travel times for the Base Case and Improvement Case for highway modes are estimated by STEAM 2.0's network analysis module, using the speed-volume relationships described below (under Congestion Analysis). Motor vehicle operating costs are calculated as the sum of fuel and non-fuel costs by applying unit (per vehicle mile) fuel consumption rates (as a function of speed) and costs to zone-to-zone distances. As discussed later, user-perceived accident costs are also used in the estimation of user benefits. The STEAM 2.0 user can also specify other changes in zone-to-zone travel times (in-vehicle and walk/wait) and out-of-pocket costs for each zone pair. The difference in the total cost of travel for each zone pair is calculated as the sum of changes in out-of-pocket cost, operating cost, user-perceived accident costs, and the dollar value of changes in travel time. Zone pairs for which a travel time cannot be determined by STEAM are excluded entirely from the analysis. Users may specify different values of travel time for different market sectors. Motor vehicle operating costs and other out-of-pocket costs are assumed to be specified on a per vehicle basis, and are converted to a per person basis by dividing by vehicle occupancy.
STEAM 2.0 uses the concept of "consumer surplus" to measure user benefits (see Exhibit 2.2). User benefits(B) are calculated using consumer surplus as follows:
B = (Pb - Pi)(Tb + Ti) / 2
where Pb and Pi are price per trip and Tb and Ti are the number of trips in the Base and Improvement Cases. User benefits equals one half the product of the base case price per trip minus improvement case price per trip, and the sum of base case trips and improvement case trips. This calculation applies to each origin-destination pair. The results for each origin-destination pair are summed together to obtain a regional total. In Exhibit 1, the rectangular area represents benefits to current users and the triangular area represents benefits to new users.
STEAM 2.0 calculates benefits for a specific analysis year by comparing Base Case and Improvement Case conditions for that year. Capital costs are annualized so that they can be related to analysis year benefits in a benefit-cost ratio. If conditions are expected to vary greatly over the life of the proposed improvements (due to, for example, growth in traffic over time), it may be appropriate to perform several STEAM 2.0 analyses (representing different analysis years) and average the results.
Cambridge Systematics has developed new speed models for use in STEAM 2.0 (see Exhibit 2.3). The models are designed to be used as part of a post-processor of average weekday traffic assignments. They produce peak, off-peak, and average weekday speeds for freeways and arterials as a function of: 1) free-flow speed; 2) average weekday traffic; and 3) capacity (in vehicles per hour).
The new models were developed by conducting hour-by-hour simulations of traffic volumes and queuing for facilities with different levels of congestion. The simulation program kept track of the growth and dissipation of queues over the course of the day. Queuing was assumed to occur if the volume attempting to use the facility exceeded its capacity, or if there was a standing queue at the end of the preceding hour. The hour-by-hour results were then combined to produce average speeds for a six-hour peak period (7-10 a.m. and 4-7 p.m.), an 18-hour off-peak period, and an average weekday. Finally, sets of curves were fit to simulation outputs, producing the results shown in Exhibit 2.3.
As discussed in the following paragraphs, the new speed models have a number of features that make them especially useful in the evaluation of transportation system improvements.
The models account for delays due to incidents, using data on the frequency, severity, and duration of incidents compiled by Ball Systems Engineering1. Incidents account for a large share of total travel delays due to congestion, especially on freeways. For example, Lindley2 estimates that over 60 percent of the congestion delay experienced on urban freeways is due to incidents rather than recurring congestion. Hence, ignoring incidents could grossly understate actual congestion delays.
The models account for peak spreading that occurs when facilities become more congested. The traffic temporal distributions used in developing the models were based on data from 579 urban automatic traffic recorders (ATRs) across the nation3. Separate temporal distributions were developed for freeways and arterials with low, moderate, and high ratios of average daily traffic to capacity.
The models account for day-to-day variations in traffic. The relationship between delays due to congestion and traffic volumes are highly non-linear in nature, especially when the ratio of demand volume to capacity is close to 1.0. Hence, using average volumes, rather than explicitly accounting for day-to-day variations in traffic volumes, can result in a significant overestimate of average speeds. To address this problem, the new speed models were developed using Monte Carlo simulation of traffic volumes, based on estimates of day-to-day variations in traffic compiled from urban ATR counts by SAIC.
|4 Free-flow speed is that which occurs when traffic volumes are very low. On interrupted flow facilities, they include delays due to traffic control devices but exclude any congestion-related delays.|
The models account for the decrease in highway capacity that occurs after demand volumes exceed capacity. The 1994 Highway Capacity Manual notes that observations of freeway queue departure rates range from 1,500 to 2,000 passenger cars per hour per lane. In contrast, freeway capacities for 12-foot lanes with no lateral obstructions are 2,200 to 2,300 passenger cars per hour per lane. Not accounting for the fact that queue departure rates are generally lower than freeway capacities can result in a large understatement of the delays due to queuing.
STEAM 2.0's accessibility measure allows users to estimate changes in spatial proximity between workers and jobs resulting from transportation investments. For each user-defined district, STEAM 2.0 reports: 1) the number of jobs within one of up to eight travel time thresholds; and 2) an accessibility index, which provides a single indicator of spatial proximity. Both these measures are reported by district, as well as for the entire region.
The threshold measure uses information on travel times, employment and population. STEAM 2.0 first calculates the total travel time, consisting of in-vehicle, out-of-vehicle and time from the "other changes" file for each origin/destination pair. From each origin zone, STEAM 2.0 identifies all destination zones and the number of jobs within the travel time thresholds specified. STEAM 2.0 aggregates these results by district, weighting by zonal population:
Ai is the
Accessibility measure for district;
Pi is the population in zone i in the district;
Ei is the total employment within access of threshold m; and
N is the nth zone in each district.
This measure is intended to be used with a production/attraction home-based trip table, so that user benefits can be properly attributed to resident trip-makers. However, users are not prohibited from using any trip table they choose.
To calculate regional job accessibility by travel time threshold, population and employment are summed over all zones in the region, rather than by all zones in the district.
The accessibility index is calculated as a summation of the quantity:
AIi is the accessibility index for origin zone I;
Ej is the total employment at destination zone j;
is a "dispersion" parameter indicating the attractiveness of nearby zones; and
Tij is the total travel time between origin i and destination j.
The district-level accessibility index is a weighted sum of the zonal accessibility values.
To calculate the regional job accessibility index, population and employment are summed over all zones in the region, rather than by all zones in the district.
STEAM 2.0 applies per vehicle mile rates and unit costs for fatal, injury, and property damage only crashes. It includes default rates for limited-access and non-limited-access highways. Alternatively, STEAM 2.0 users can specify crash rates for up to six user-defined highway classes.
STEAM 2.0 allows the specification of "internal" and "external" unit costs for fatal, injury, and property damage only crashes. "Internal" costs are viewed as incident upon and perceived by highway users and are treated in the same way as travel time, operating, and out-of-pocket costs to highway users in the benefit-cost analysis. "External" costs are viewed as incident upon other elements of society and are treated the same way as emissions, noise, and global warming costs in the benefit-cost analysis (i.e., it is assumed that these costs are not taken into account in traveler decisions).
STEAM 2.0 produces estimates of user benefits by mode and summarizes travel demand output for each user-defined district. Districts are aggregations of traffic analysis zones. These aggregations may represent neighborhoods, policy areas or political jurisdictions.
With this feature, users can compare user benefits to resident trip-makers across districts that they have defined. The dollar value of in-vehicle travel time, out-of-vehicle travel time, fuel costs, non-fuel operating costs, out-of-pocket costs, and internal accident costs are reported separately, as a total, by mode and by district. Revenue transfers are reported separately as well. Travel demand measures reported by district and mode include vehicle miles of travel (VMT), person trips, vehicle trips, in-vehicle time, out-of vehicle and total travel time.
The aggregation feature can report user benefits to resident trip-makers. For this reason, STEAM 2.0 accepts matrices in Production-Attraction format. Trips at the origin end of a daily trip table may contain work to home trips, non-home to non-home trips, shop-to-home trips, and other trips not attributable to residents of a district. However, when trips are provided in production-attraction format, it is possible to determine the district of residence for the trip-maker.
STEAM 2.0 performs an internal conversion of trips from P/A to O/D format. The number of person trips in the production-attraction zone interchange is factored by a user-defined percentage. That percentage is applied to the P/A interchange to create a O/D interchange. The balance (1-the percentage) is assumed to originate at the attraction end and to end at the origin end. This fraction of the trip table is transposed. User benefits for both sets of trips are assigned to districts based on the district code of the production zone.
For example, suppose that 100 home-based work trips are produced in zone 1 and are attracted to zone 2. Home-based work P/A tables typically contain two daily trips for each trip-maker, both of which originate at the production zone. These trips represent the trip from home to work and the trip from work to home. To convert these to O/D format, the user specifies a P/A factor of 50 percent. STEAM 2.0 will assign 50 of the trips to the production/attraction zone interchange, and remaining 50 trips to the attraction/ production zone interchange. User benefits of all 100 trips will be attributed to the user's district of origin.
Users have the option of aggregating results by district of destination. This may be useful if the focus of the analysis is on a group of trip-makers bound for a particular destination, such as a CBD, employment district, or non-work destination.
In STEAM 2.0, emissions for autos, trucks, and carpools are calculated as the sum of: 1) mileage-based emissions on the highway system (calculated under the assumption that vehicles are already warmed up); and 2) added emissions due to cold starts.
Mileage-based emissions are calculated using emission rates as a function of speed. Specifically, emission rates are input for speeds of 5, 10, 15, ..., 60, and 65 miles per hour, and the spreadsheet interpolates to get emission rates at intermediate speeds. The average speeds are trip-based (i.e., calculated as origin to destination distance divided by origin to destination mileage). The added emissions due to cold starts are calculated on a per vehicle trip basis and combined with mileage-based emissions.
Transit emissions are calculated by applying emission rates to changes in transit vehicle miles specified in the inputs to STEAM 2.0.
STEAM 2.0 applies per vehicle mile unit costs for noise, global warming, and other external costs. STEAM 2.0 inputs also include an estimate of external costs incurred during the construction period. These costs are annualized in the same way as capital costs (discussed below).
STEAM 2.0 calculates revenue transfers occurring as a result of changes in fares, tolls, and other out-of-pocket costs paid by transportation system users Increases in fares and tolls implemented as part of a package of transportation system improvements reduce the benefits of the improvements to system users. If the fare and toll increases are very large, the net effect of the package on transportation system users may be negative. However, fare and toll increases do not, in themselves, necessarily result in a loss to society as a whole, since they cause revenues to be transferred from system users to the agencies that collect tolls and fares.
Conversely, decreases in fares and tolls increase benefits to users because revenues are being transferred to them from the collecting agencies. Hence, in calculating the net benefits of a package of actions, revenue transfers to or from collecting agencies must be added to user benefits to capture the full effect of the package of actions on society.
STEAM 2.0 calculates revenue transfers at the zonal interchange level for each market sector. The equation used to calculate revenue transfer (RT) is as follows:
RT = (OPTCi) (Ti) - (OPTCb) (Tb)
where Ti and Tb are the number of trips in the Improvement and Base Cases and OPTCi and OPTCb are the out-of-pocket costs in the Base and Improvement Cases. Revenue transfers are calculated as the difference between out-of-pocket costs multiplied by the number of trips in the improvement case and out-of-pocket costs multiplied by the number of trips in the base case.
In addition to the revenue transfers which occur as a result of fares and tolls and other out-of-pocket costs paid by users, revenue transfers occur as a result of changes in motor fuel taxes collected. If additional motor fuel is consumed in an improvement case versus a base case, transportation users are paying additional costs for the motor fuel. However, some of the additional cost for fuel is State and Federal tax which is simply a revenue transfer from transportation users to government agencies. The STEAM 2.0 model calculates the amount of revenue transfer resulting from changes in motor fuel consumption based on an average State and Federal motor fuel tax rate. The combined State and Federal tax rates for gasoline is 37.48 c/gal and 42.6 for diesel.
STEAM 2.0 estimates benefits and costs for an analysis year. To determine capital costs for the analysis year, total capital costs are converted into a stream of annual costs starting in the year of opening and extending over the useful life of the project. For simplicity in this conversion, all capital costs are viewed as incurred in the year entered by the spreadsheet user as the midpoint of the construction period. The equation used to annualize capital costs is:
C is capital cost;
yo is the year of opening;
ym is the midpoint of the construction period;
L is the useful life of the investment in years;
d is the discount rate expressed as a fraction (e.g., 0.07); and
a is capital cost annualized over the useful life of the investment.
Uncertainty is a key attribute of both the physical and economic components of transportation user costs. Risk analysis is useful to reflect both what is known and what is uncertain in the effect of transportation conditions and performance on user costs. Risk analysis allows the planner to evaluate alternative investment options under a variety of scenarios. The result of the risk analysis is a forecast of future outcomes and the probability, or odds, of their occurrence. Risk analysis provides the STEAM 2.0 user with a sense of perspective on the likelihood of future outcomes and a process which is easily understandable and technically robust. This allows planners and decision-makers to select the level of risk within which they are willing to plan and make commitments.
The risk analysis process helps avoid the lack of perspective in "high" and "low" cases used in sensitivity analysis by measuring the probability or "odds" that an outcome will actually materialize. This is accomplished by attaching ranges (probability distributions) to the forecasts of each input variable. The approach allows all inputs to be varied simultaneously within their distributions, thus avoiding the problems inherent in conventional sensitivity analysis. The approach also recognizes interrelationships between variables and their associated probability distributions.
Probability distributions for the variables in-question are established on the basis of both statistical analysis and subjective probability. In the current version of STEAM 2.0, the variables subject to risk analysis are assumed to follow a log-normal probability distribution. Future versions of STEAM 2.0 will provide more flexibility in selecting probability distributions. Ranges need not be normal or symmetrical - that is, there is no need to assume the bell shaped normal probability curve. The bell curve assumes an equal likelihood of being too low and being too high in forecasting a particular value. It might well be, for example, that if projected inflation rates deviate from expectations, they are more likely to be higher rather than lower. The software places no restrictions on the degree of "skew" in the specified ranges and thus maximizes the extent to which the risk analysis reflects reality.
Although the computer program will transform all ranges into formal "probability density functions", they do not have to be determined or presented in either mathematical or graphical form. All that is required is the entry of upper and lower limits of an 80 percent confidence interval. The software will then use numerical analysis to translate these entries into a uniquely defined statistical probability distribution automatically. This liberates the non-statistician from the need to appreciate the abstract statistical depiction of probability and thus enables administrators, stakeholders and decision-makers to understand and participate in the process whether or not they possess statistical training.
The model uses a monte carlo simulation process to generate the distributions. During the simulation process, the unique probability density function for each variable is sampled, and the resulting numbers populate the mathematical equations making up the model. Values for each result metric are calculated at the end of each simulation. After repeated samplings the model generates a probability distribution for each result metric. For each result there is both a forecast and a quantification of the probability that the forecast will be achieved.