Web-Based Screening Tool for Shared-Use Rail Corridors (2014)

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

9 2.1 Background In seeking to relieve highway congestion, improve travel alternatives, and promote energy efficiency, the Passenger Rail Investment and Improvement Act of 2008 (PRIIA) seeks new partnerships between the freight and passenger railroad indus- tries including cost-sharing arrangements for state supported corridors under 750 miles in length (see PRIIA Section 209). These new partnerships will result in new publicly funded pas- senger rail services on privately owned freight railroad facilities. This shared-use concept is critical to the further development of all forms of passenger rail service. Public agencies require a screening tool that will identify rail passenger projects that warrant further study with more rigorous analytic tools. Web-based tools have proven to be an effective means of delivering analytic models and services. NCFRP sought a screening tool accessible over the Internet from a central server and operated on a local computer through a Web browser. An overarching theme of NCFRP is the development of practical and useful tools that can truly make a difference in transportation investment and planning. In this context, a balance must be struck among the requirements of the FRA Guidance Manual, the limitations of available data, and exist- ing methods and tools. This balance was crucial if the research was to yield a Web-based tool for screening shared-use projects, the practicality and usefulness of which would be measured by its acceptance and widespread use among the proponent agen- cies of new passenger rail service on existing freight corridors. The following general and task-oriented approaches were developed with the overarching NCFRP objective and this project’s objective in sharp focus. 2.2 Factors in Developing an Overall Approach This section covers several factors that were important in developing the overall approach to the research and to the development of the Shared-Use (SU) tool. Discussed are the use of a Web-based tool and screening processes, the role of public agency due diligence and freight railroad cooperation, the impact of passenger train reliability, freight train infrastruc- ture needs, data requirements, Web-based tool development, and Web browser-based applications. 2.2.1 Web-Based Tool and Screening Process The principal research product was a Web-based tool for screening projects. The starting point for developing such a tool was to understand the screening process and its application. The primary role for the screening process is a triage capability. As early as possible, the researchers sought to screen out those proposals that were non-feasible, while leaving for further consideration those proposals that seemed to have merit from a feasibility standpoint. The secondary role of the screening process was to provide preliminary estimates of the impacts of a proposal, which can be useful for the following: • Sensitivity analysis and design of a proposal, • Preliminary discussions among public agencies and railroads, and • Deciding what analyses to pursue with more rigorous analytic tools in partnership with the freight railroads. There are many approaches to screening projects for pre- liminary feasibility. These approaches include rules of thumb, simple analytical models, parametric models, and simulation models of varying complexity. Screening tools are intended to be easier, less costly, and quicker to use, but not as precise or accurate as detailed simulation or other models. Ideally, a robust tool would address both the primary and secondary roles of the screening process and be broadly applicable at the preliminary feasibility, concept phases of planning. As such, the tool would include an integrated set of models with a full range of capabilities. C H A P T E R 2 Research Approach

10 The research team had broad experience with both the full range of tools that have or could be used to assess capacity issues and passenger/freight commingling in a given corridor. This experience included the development of simplified tools such as Ideal Day Analysis from the Midwest Regional Rail Initiative (MWRRI) study that provides a broad assessment of needs and impacts, other analytic tools like Miss-IT™, and simulation modeling tools like FRA’s General Train Movement Simulator (GTMS). The team also had broad experience applying data- and labor-intensive tools like RAILS, Rail Traffic Controller (RTC), RailSim, etc., that are used in detailed studies to provide very specific and rigorous assessments of train move- ments, priorities, locations, speeds, etc. 2.2.2 Public Agency Due Diligence and Freight Railroad Cooperation The public sector has a due diligence process involving con- cept and feasibility studies to identify options for more detailed analysis. However, the freight railroads have expressed concern that it is a significant resource requirement for them to pro- vide key personnel and other resources to the process. They would prefer a minimal role prior to the start of the Investment Grade/NEPA process, which in large, part duplicates in greater detail the initial feasibility and concept studies. The freight railroads, therefore, have asked that feasibility studies like those performed for the MWRRI, Ohio Hub, and Florida Vision Plan contain language such as unnegotiated, unfunded, and without freight railroad assistance to conserve its resources for the more critical second-level environmental impact studies (EIS)/investment grade studies. As a consequence, public agency planning departments often are left to develop and assess feasibility of corridors for passenger rail with relatively limited input from the freight railroads, whose staff generally will be committed to other legitimate business of the freight railroad. It is often the case that the public agency planning staff will face major data needs concerning track charts and commercial freight activity in the corridor and may request such data from the freight railroad. The request for track data is frequently granted while the request for commercial activity in the corridor is more difficult. The freight railroad often regards this data as commercially sensitive with the potential to expose its com- petitive position in the market vis-à-vis other railroads and competing freight modes. The freight railroads will typically only provide such data within a confidentiality agreement that can be provided once EIS/investment grade studies begin. In any case, the screening process and a Web-based tool should not depend on the freight railroad as a source of data; rather, they must rely on alternative sources. The Web-based screening tool can provide a feasibility- level analysis that should be practical and provide insight into both the difficulty of operating passenger services in a corridor and the level of slack time that they should include in their schedules. Moreover, the tool should provide an indication of the level of additional infrastructure needed to hold the freight railroad harmless. Major studies like the MWRRI, Ohio Hub, and Florida Vision Plan, all required that preliminary estimates of pas- senger train schedule reliability and additional infrastructure needs to hold the freight railroad industry harmless be used to quantify and present to the relevant railroad without involv- ing their technical staffs for more than a review of the results. A feasibility study like the Ohio Hub was able to obtain (with appropriate caveats) sign-off from the freight railroads for feasibility results without having to complete detailed engineering and operations studies. This allowed the Ohio Rail Development Commission to evaluate a wide range of route, technology, and market options to eliminate those that were not effective and to develop its strategy for detailed analysis of the best solutions. This experience suggests that the Web-based tool for screening corridors would need to allow for the estimation of the following two key outputs: • Passenger train reliability impacts; and • Freight train infrastructure needs. 2.2.3 Passenger Train Reliability Impacts The level of reliability of service is critical to passenger train operations, and timetables need to be adjusted to account for delays experienced along the route. Delays tend to be a func- tion of the volume of trains and the impact of local trains at yards and bottlenecks such as bridges along the route. For example, delays are experienced by Amtrak and the proposed Chicago-Twin Cities passenger trains at the Mississippi Bridge at La Crosse, Wisconsin, due to local train operations that at any hour of the day or night interfere with both passenger and freight operations. Whenever these local trains operate, they cause delay to the long-distance passenger and freight trains. Such delays create major problems for passenger rail operations and, as a result, a reliability factor is a critical ele- ment in finalizing the timetable. Therefore, at the feasibility stage, a tool supporting a public agency’s efforts needs some means for assessing current and future freight train levels using publicly available data. One source of contention in developing shared-use arrange- ments is the occasional tendency by public agencies and Amtrak to promote over-ambitious schedules (i.e., showing high speeds and frequent rush-hour trains). Railroads react negatively to what they perceive to be illogical or unrealistic plans that are difficult to realize consistently and will place the blame for failure on the railroad. Disruptions related to weather, peak traffic volumes, and scheduled or unscheduled maintenance are all routine

11 circumstances that the railroads must deal with—and that must be considered in establishing plans for shared-use oper- ations. Capacity and service are limited by what can be done under poor conditions (and too often schedules and models assume optimal conditions). The Web-based tool needed to allow for realistic assessment of these reliability impacts in screening proposed plans. 2.2.4 Freight Train Infrastructure Needs To hold freight operations harmless (or, to allow some minimally tolerable level of disruption to freight operations) in a corridor is critical if passenger trains are to commingle with freight traffic on freight railways on infrastructure owned by the freight railroads. This becomes a more daunting task as passenger train speeds increase. At 79 mph, passenger trains are reasonably compatible with freight trains, but are frequently faster and instead of simply “going with the flow” need to overtake slower speed freight trains such as locals, bulks, and general cargo. As a result, extra sidings are needed to clear a path for the passenger train, which typically has priority. This requirement is further exacerbated as passenger train speeds increase to 90 mph, 110 mph, and—as in the Northeast Corridor—150 mph. To further complicate this problem, freight railroads frequently use mainline track as temporary storage and will leave trains “hanging out” while space is made in a yard. As such, consideration has to be given to yard operations along a track. Providing yard leads can often create more mainline capacity for an existing line than can other kinds of improvements. As a result, a screening tool must contain at least the functionality needed to deal with passenger train reliability and infrastructure needs for continued freight operations. Consequently, the development of the Web-based tool for screening needed to consider the following: • The current infrastructure of the route, • The level and type of freight operations, • The character of existing and proposed passenger rail operations, and • The degree of interaction between freight and passenger trains. 2.2.5 Data Requirements The above discussion indicates that the required data for assessing passenger service reliability impacts and infrastructure needs are as follows: • Infrastructure For this purpose, an electronic track database is needed. There is a clear need to be able to observe and identify infra- structure, both existing and needed at any location. The most data-intensive method in a screening toolkit would be simulation. A simulation tool that calculates train perfor- mance will require track layout, elevation points indicating grade change, heading points indicating curvature change, and speed zones. Other methods, like the “Ideal Day” method described in Exhibit 2-1, will require a subset of this data. Track charts can be obtained from public sources. One good source is the FRA GIS 1:100000 Rail Network database that is available from the U.S.DOT Bureau of Transportation Statistics (BTS). Another possible source of data is Google Earth, which can be used to extract coordinate and identi- fiable data for points that are distinguishable from satellite photographs. Railroad timetables, which may be publicly available or available on request from the railroads, include elevation data, track speed data, and special operating instructions (i.e., speed restrictions and special procedures at interlocking, wye junctions, and interchanges with other railroads). • Train Schedules To screen for any but the simplest, lowest-density cor- ridors, it is critical to obtain train movement data. This can be achieved either by specific train classification counts or time-of-day surveys. Train volume data are partially avail- able from FRA’s National Grade Crossing Inventory database and, in some cases, from state rail plans and related plan- ning efforts. The quality of the analysis will be impacted by the source and quality of surveys used to obtain this data, but it can be subject to further ratification and validation by empirical research. The different sources should be checked to assess differences in the results and potential error ranges. 2.2.6 Developing the Web-Based Tool As noted, some proposals may require very simple methods to screen them from further consideration. The research team’s review of tools and data was aimed at identifying those meth- ods for inclusion in the tool. Those proposals that were deemed worthy of more in-depth analysis focused on the following feasibility assessment criteria: • Passenger train reliability and • Freight infrastructure needs. The application of the screening tool to evaluate feasibility required the key data components of track database and train schedules. In Exhibits 2-1 and 2-2, the research team presents two alternative methods for conducting the analysis capable of addressing feasibility criteria. Exhibit 2-1 illustrates the Ideal Day Analysis method used by TEMS in the Midwest, Ohio, and Florida. Exhibit 2-2 illustrates analysis with FRA’s GTMS developed by DecisionTek. The two tools offer a choice of

12 Exhibit 2-1. Approach to corridor analysis by planning stage (using the tEms toolkit). In the 2001 report, “Methodology for Freight Capacity Analysis for the Midwest Regional Rail Initiative,” TEMS developed a framework to identify the type of capacity analysis needed for different stages of the planning and engineering process. Figure 2-1-1 shows the basic structure of the requirements for capacity analysis at each analysis level. For conceptual planning, TEMS proposed that the analysis consist of a review of potential conflicts and train “meets” (i.e., locations) where trains would ideally pass each other if adequate track capacity were available. At such locations at the conceptual level, preliminary recommendations would be made for additional infrastructure based on the type and class of train and their associated speeds, e.g., 2-mile siding for general freight train, 4-mile siding for an intermodal train, and 10-mile siding for another passenger train so trains could pass at speed. A capital cost can be assigned to the siding for track, switches, signaling, etc. These rules of thumb or benchmark estimates provide a very conceptual understanding of infrastructure needs and, within the typically large error range of such studies, provide a ballpark cost estimate for infrastructure needs. It should be noted that the error range of such analysis is correlated directly with train volumes and speed and may well produce large errors ±50 percent for 110 mph passenger trains on heavily used freight corridors (e.g., Chicago-Milwaukee-Twin Cities). However, for light or medium corridors, the results can be used to give a reasonable assessment of both passenger train delay and freight infrastructure needs. The second step in the TEMS framework is feasibility planning for which an Ideal Day Analysis is needed. This analysis considers the meets and conflicts of the corridor and assesses the likely delay by train meet based on train volume, level of infrastructure, types of freight train, and quality of signaling system. This type of analysis quantifies both the typical delay that will be experienced for the lower priority trains, as well as the infrastructure needed and costs (see Figure 2-1-2 and Table 2-1-1). The Ideal Day Analysis is a “static” process that assumes that the conditions under which trains operate are identical from day to day and produce identical travel times and delays each day. Because there is no variation in travel times or travel starts, these trains are assumed to operate under ideal—almost scheduled—conditions. As a feasibility tool, the Ideal Day Analysis has a significant error range ±30 percent; however, it is particularly effective as a screening tool and in developing the feasibility estimates of cost before detailed engineering can be performed. Conceptual Planning Feasibility Planning O pe ra tin g Pl an Working System Preliminary Engineering Final Engineering/ Construction Construction Impact Capacity Assessment Implementation Adjustments Capacity Assessment Typical Day Capacity Analysis Ideal Day Capacity Analysis Benchmark Capacity Analysis Figure 2-1-1. Levels of capacity analysis required in the planning process.

13 Exhibit 2-1. (Continued). Figure 2-1-2. Conflict points subsequent to analysis. In the preliminary engineering phase of a project development process, a Typical Day Analysis produces a more detailed analysis than does the Ideal Day Analysis. It considers all of the variation in train performance, particularly actual starting times, route delays, and location issues such as lift bridges, local trains, and yards. This dynamic element provides more typical travel time estimates for trains passing through a corridor and, therefore, a more accurate measure of delay and conflict. It is at this stage that the freight railroads are willing to participate and frequently want to carry out the capacity analysis. Error range in these studies is ±20 percent. In the final phase of development, final operating plans are produced to show how construction phasing and implementation process will impact train movements. At this stage, detailed analysis of train patterns, movements, Meet Point Summary by Milepost Train1 Number Train2 Number No Milepost Time Direction Category 1 0.05 13:00 HIA_335 Metra_2134 Opposite Clear 2 0.05 8:15 LAKE_CO_WB Metra_2118 Opposite Clear 3 0.09 7:40 Metra_2107 Metra_2112 Opposite Clear 4 0.2 8:35 Metra_2109 Metra_2122 Opposite Clear 5 0.25 19:35 Metra_2149 Metra_2152 Opposite Clear 6 0.3 20:35 Metra_2151 Metra_2154 Opposite Clear 7 0.3 17:30 Metra_2139 Metra_2144 Opposite Clear 8 0.39 9:07 LAKE_CO_EB Metra_2126 Same Conflict 9 0.45 7:41 HIA_330 Metra_2107 Opposite Clear Table 2-1-1. Meet point analysis report sorted by milepost. (continued on next page)

14 Exhibit 2-1. (Continued). Figure 2-1-3. Appropriate tools for different levels of analysis. and inter lockings is needed. This level of detail requires full simulation of the train operations to ensure the integrity of the infrastructure, signaling, and train movements at all locations along the track. The impact of these requirements is that different tools are needed for different levels of planning. Figure 2-1-3 shows how the planning level and train volume relate to the typical tool needed for capacity analysis. It is clear that at low levels of freight rail operation relatively simple tools can be adopted, whereas when the need for accuracy increases because of more detailed planning needs, and train volumes increase because of train volume, the level of detail provided by the tool must increase. The assessment of data needs at different planning levels suggests that for most feasibility planning a tool can be developed that will provide reasonable solutions for corridors with less than 40 to 50 trains per day. Over 40 to 50 trains per day, a more detailed Typical Day Analysis is likely to be needed due to the complexity of the activity in the corridor. Only by adopting very broad error ranges can cost estimates be reasonably prepared for concept and feasibility studies when the train volume reaches 40 to 50 freight trains per day. Although the TEMS assessment frameworks provide a first cut at the development of a taxonomy for feasibility analysis tools in different levels of planning, they point to both the character of the tools needed for capacity analysis and their data requirements. approach, each with its own advantages and disadvantages. Ideal Day was originally developed for low-density routes; the simulation-based approach originally embodied in GTMS can better inform regarding delay-mitigating infrastructure improvements in corridors with higher traffic density. Com- bining the approaches builds on the strengths of both tools. The researchers studied the pros and cons of each option, and how inefficiencies might be overcome by improving the technical capability of Ideal Day type models versus improv- ing the openness and clarity of the simulation option. For this purpose, the research team evaluated a range of examples that they had already assessed in completing passenger cor- ridor feasibility and EIS across the country. These include the Midwest, Ohio, the Northeast, Florida, Texas, and Colorado. The aim was to test both heavily used corridors such as Chicago-Cleveland, as well as medium or lightly used cor- ridors like Chicago-Detroit. Using the results of these assessments, the performance of planning models versus simulation models was assessed and recommendations made as to how a Web-based system would be developed. Given the research team’s access and knowledge of planning and simulation tools, the research team was able

15 Exhibit 2-2. Operations analysis with simulation (using FRA’s Gtms). A simulation approach offers a number of advantages when conducting operations analysis for preliminary feasibility. The non-simulation approaches may be adequate in some situations, while in others they may include large margins of error and run the risk of over or under screening alternatives. A simulation approach will, however, typically be more data-intensive and require an analyst with more experience. With simulation of train movements, the analysis accounts for the resistive forces on the trains whose fluctuations may be very significant in undulating terrain, especially for large freight trains. Together with explicit modeling of power requirements and braking, simulation replicates train movements to arrive at realistic estimates of point-to-point run times by type of train. Just as important, simulation captures the impacts of traffic control in the realization of train schedules and the effects of increased traffic density with and without improvements to the infrastructure In the example shown here, the simulation outputs show a territory that is mostly single track with sidings. The purpose of this illustrative analysis is to demonstrate how simulation can show the effects of added traffic, identify bottlenecks and see whether infrastructure modifications are possible that would pass preliminary feasibility screening (i.e., permit reliable passenger service while leaving freight operations harmless). As shown in Table 2-2-1, in the base case there are 11 scheduled daily freight trains. The freight trains have a maximum track (normal) speed of 50 mph. The analysis assumes that both main track and sidings can handle the heaviest trains, which are 134-car, 19,000-ton coal trains. In the alternate case, the analysis adds passenger service of six trains (three in the A.M. period and three in the P.M. period) whose maximum speeds are 79 mph. The analysis assumes that there are no infrastructure improvements (except whatever track upgrades may have been necessary to accommodate the higher speed passenger trains). The Figure 2-2-1 string chart shows the time and position of trains in the simulated system for the base case (time is on the X-axis and distance in miles from the milepost designating the northern system boundary is on the Y-axis). Where lines cross on the chart the train meets are executed. One can observe that there is very little delay (i.e., holding of trains) at this level of traffic density. In the alternate case string chart shown in Figure 2-2-2, six passenger trains have been added to the schedule (these are labeled P_01, P_02, etc.) The added traffic is seen to result in some delay in both the A.M. and P.M. periods. The simulation outputs also provide a clear view of the functioning of traffic control. The authorities chart shows each traffic control block (shown on the Y-axis) and the time that movement authority has been granted to a particular train. Authority is revoked after the train has exited the block. Traffic control blocks for the main track (1 through 122) are shown on the bottom of the chart and sidings are at the top of the chart. For each meet it is possible to see which train was directed to a siding, the time authority was granted, and when the train exited the block. Base Case Alternate Case Infrastructure 150 miles (north south), single track with sidings Same as base case Traffic 11 daily freight trains 11 daily freight trains 6 daily passenger trains Speed Limit 50 mph maximum for freight 50 mph maximum for freight 79 mph maximum for passenger table 2-2-1. simulation scenarios. (continued on next page)

16 Exhibit 2-2. (Continued). Figure 2-2-1. String chart (base case—freight trains only). Figure 2-2-2. String chart (alternate case—including passenger trains).

17 Exhibit 2-2. (Continued). Figure 2-2-3. Chart of authorities (base case—freight trains only). Below is the same chart for the alternate case. One can observe the more extensive use of sidings when compared with the base case. Figure 2-2-4. Chart of authorities (including passenger trains). (continued on next page)

18 Exhibit 2-2. (Continued). The following chart shows the speed profile for one of the coal trains, and this chart can be generated for all of the trains. The chart includes the speed profile, elevation, position of controls (throttle and dynamic braking) and the application of air brakes. A review of these results will lead an analyst to conclude that the added passenger rail traffic without modifi- cations to either the freight schedule or changes to the facility (i.e., additional sidings) would be likely to result in delays to freight movements while not meeting passenger service reliability requirements. The analyst could then propose modifications that could result in acceptable operational outcomes, which could be demonstrated with additional simulations. Figure 2-2-5. Speed profile, elevation, train controls (selected freight train). Figure 2-2-6. Simulation summary of operational metrics. Average Speed by Train Type (MPH) PASSENGER (6 trains) COAL (7 trains) GENERAL (2 trains) UNIT (2 trains) Percentage of Trains by Type with Delay in Excess of Tolerance Aggregate Net Aggregate Net PASSENGER (delay in excess of 10minutes) N/A N/A 83.3 20.0 COAL (in excess of 30minutes) 28.6 14.3 42.9 14.3 GENERAL (delay in excess of 30minutes) 0.0 0.0 50.0 0.0 UNIT (delay in excess of 30minutes) 0.0 0.0 50.0 50.0 Mean Delay (in mins) Aggregate Net Aggregate Net PASSENGER (delay in excess of 10minutes) N/A N/A 17.8 12.0 COAL (in excess of 30minutes) 9.0 15.0 63.7 105.0 GENERAL (delay in excess of 30minutes) 0.0 0.0 91.0 0.0 UNIT (delay in excess of 30minutes) 0.0 0.0 33.0 33.0 Maximum Delay (in mins) Aggregate Net Aggregate Net PASSENGER (delay in excess of 10minutes) N/A N/A 27.0 12.0 COAL (in excess of 30minutes) 15.0 15.0 110.0 105.0 GENERAL (delay in excess of 30minutes) 0.0 0.0 91.0 0.0 UNIT (delay in excess of 30minutes) 0.0 0.0 33.0 33.0 Alternate CaseBase Case * Aggregate delay is the total minute difference between scheduled and actual arrival ”me, less tolerance. ** Net delay is the total minute difference between scheduled and actual run ”me, less tolerance. With Passenger TrainsFreight Trains Only 35.1 60.4 31.9 34.2 37.0 N/A 34.5 32.1

19 to build the option that proved most effective and include a graphics interface, database, model, and output system. The development system was based on a detailed concept design, which identified inputs/outputs, models, and interface require- ments for the system. Once the Web-based system was developed, it was tested on three case studies. The research team had data for a large number of corridors around the country and provided test analyses on a range of different corridors. This included a range of train densities and geographic conditions to test the performance of the model in different environments. 2.2.7 About Web Browser-Based Applications Software Architecture Applications that run in browsers over the Internet pre- sent special challenges that developers need to consider. The basic Web model is one of request-response, that is, the client (local computer and browser) is de-coupled from the server, and sends requests that are processed by the server which, in turn, sends responses back to the client as updated browser pages, after which, the server is free to handle requests from other users. In earlier implementations of Web applications “response-request” usually meant click and wait—the user experience was generally considered much worse than that of a comparable desktop application. Newer applications use technologies that offer a rich client experience in which the application responds almost like a desktop application. A Web application has components that run in the browser (like events that trigger when a mouse hovers on a location) and other processes that are handled on the server (like database queries and complex procedures). Pages from non-trivial applications such as non-static HTML (HTML stands for hyper text markup language and is used to create structured documents that are viewable in a Web browser) show con- tent that is customized for the user’s session and may also rely on stored user data. There is a considerable amount of design that goes into developing a Web application so it can maintain communications between its components and manage the states of the application and its active sessions—all of which are subject to the constraints of the basic request- response model. A best practice design or software architecture for a Web- based application is one that isolates domain or business logic (i.e., technical calculations) from the presentation layer or “front end,” which is the pages and forms that the user sees on screen. One such software architecture is called Model-View- Controller (MVC) and is shown in Figure 2-1. The model represents the business logic, the view is the presentation layer, and the controller represents the elements through which the user interacts with the application (i.e., buttons, text boxes, menus, etc.). The application’s data model is contained within the model component. Even if the application does not store user data, there will still be system data required by the application so the Web-based tool will require a database (i.e., a back end). If the application does not store user data, then the application receives all of its user input in the user session like an online calculator. However, if the application is to have any significant complexity it will store user data and require users to register and set up a user account on the server. (Alternately, user data accounts could be avoided if user data are downloaded to the local computer at the end of a session and then uploaded back to the server when the user starts a new session. However, this is problematic because users will lose a session’s data if there is an Internet outage, the local computer hangs, or the user accidentally closes his or her browser.) The research team’s solutions implemented the best practice methods for developing Web applications that are described here and, where applicable, included processes for registration and secure login to access user data. Implementing Technologies of the Web-Based Tool The team implemented the solution in ASP.NET using the Microsoft® Visual Studio integrated development environment. The application database used SQL Server 2008. The server ran the MS Windows 2008 Server operating system, which uses the Internet Information Server (IIS) 7.0 Web server. These technologies are industry standards approved by the Office of Management and Budget. The research team had used these technologies extensively and applied them in other Web-based applications. Note: This figure uses the Unified Modeling Language (UML) conventions. Solid lines represent a direct association; dashed lines represent an indirect association via an observer. Figure 2-1. UML diagram of the MVC software architecture.

20 Federal Requirements for Web-Based Systems The proposed Web-based tool will run on a FRA server and, as such, will need to meet all the requirements mandated for federal systems and by the agency. The research team was committed to providing the Web-based tool as a fully com- pliant system meeting all federal and agency requirements including • Security, • Privacy, and • Compliance with Section 508 of the Rehabilitation Act (for disabled accessibility). In addition, the Web-based tool was designed to be “browser neutral” and fully compatible with post-2005 ver- sions of major browsers (Internet Explorer, Firefox, Safari, and Chrome). 2.3 Approach to Tasks The research applied the general approach outlined above to perform the following tasks. 2.3.1 Task 1: Identification of Tools This task was conducted in three principal components, as follows: • Develop an inventory of tools, • Assess functionality, and • Assess potential relevance. Tools to consider included RAILS RailSim, RTC, GTMS, TRACKMAN, LOCOMOTION, COMPASS, GOODS, and RENTS. In developing the inventory of tools the research team relied on its extensive experience and its knowledge of indus- try tools, as well as a new search performed to find existing tools that have been used in recent rail plan feasibility studies. This search for tools included Internet searches and phone interviews with study authors to determine whether there are additional tools in the public domain or commercially available that can support rail feasibility analysis. After developing an inventory of the tools, the research team assessed the functionality of each tool by • Specifying the issues the tool addresses (i.e., capacity analysis, scheduling, etc.); • Specifying the data that are required to use the tool—and whether these data are likely to be publicly available; • Specifying the output metrics and reporting formats that are provided by the tool; • Assessing the usefulness of the tool in addressing feasibility analysis concerns; and • Assessing the extent to which the methods embodied in the tool are replicable in the Web-based tool (i.e., based on publicly available methods or otherwise accessible to the research team and implementable in a Web-based tool given schedule and budget restrictions). This information was organized in a tabular format with an assessment of the relevance of each tool to the Web-based tool, along with a list of pros and cons associated with it. 2.3.2 Task 2: Description of Data Needed for Identified Tools In this task the researchers provided a full description of the data needed to populate each of the tools that was identified as relevant to the Web-based tool. The description of the data included a full specification of the data and all of the data attributes at a level that is adequate to gather the data (by interview, survey, request, or other means) and implement a functional database. One important data need of the Web-based tool was infra- structure unit costs, which can be used to estimate infrastructure costs for added capacity required to integrate passenger and freight trains. The data descriptions include a mapping to the tools that require them. 2.3.3 Task 3: Gap Analysis of Identified Data For the data described in Task 2 the researchers determined the following: • Whether or not the data are publicly available; • When data are not publicly available, publicly available proxy data or methods for inferring data from other data or independently gathered data was specified; • Where inferred or proxy data were used in place of source data, the research team analyzed the likely impacts of using the inferred data on the analysis. As described in the general approach, principal interest areas of the feasibility analysis were passenger train reliability and freight train infrastructure needs. The broad data catego- ries for conducting the analyses were track data and current and projected train volumes.

21 Preliminary sources that could substitute for railroad- provided track data included the FRA GIS 1:100000 database that is available from BTS. Current railroad timetables contain a wealth of useful information (including general facility infor- mation, point-to-point distances, elevations, and speed limits), but are not publicly available. (One reason that railroads may not make these available is that overzealous rail enthusiasts or unfriendly persons could possibly disrupt operations given the dispatcher frequencies and other information contained in the timetables.) However, timetables could, perhaps, be provided on request. For train volume data, the FRA National Grade Crossing Inventory Database is publicly available and could be a start- ing point gathering train volume data. Actual surveyed train counts could be a useful means of gathering train volume data. The research team’s gap analysis was designed to deter- mine which tools and methods together with the culled data required to populate them would contribute to an effective Web-based screening tool. 2.3.4 Task 4: Summary of Phase 1 Research and Recommended Approach for Phase 2 This task had the following component parts aimed at developing: • A summary set of functions and outputs that best meets the FRA Guidance Manual using publicly available or inferred data, • A detailed work plan for the development of the Web-based screening tool, and • A software development plan. The results of this task and the preceding tasks were pre- sented in an interim report. The research team included its recommendations for proceeding with the Web-based tool and addressed all the relevant elements of the FRA Guidance Manual as were practical. Functions and Outputs The researchers developed a proposed list of Web-based tool functions and outputs. The functions describe the procedures that the Web-based tool will implement and the outputs include the metrics, results, and description of the principal result tables and charts that the tool generates. These functions and outputs form the basis for the software requirements described in Task 5. Work Plan The Phase 2 work plan covered all of the Phase 2 activities, including tool development, documentation, and preparation of case studies. The work plan included interim milestones that enabled the project panel to track the research team’s progress. Software Development Plan The software development plan included the tasks required to design, implement, and test and deploy a Web-based tool based on a software architecture for a multi-tiered application with strong separation between the data, logic, and presenta- tion layers. The software development included a breakout of tasks, an estimate of hours for each task, and the intermediate deliverables leading to the beta and final versions of the Web- based tool. Figure 2-2 shows the process workflows for software development, phases of development, and the intensity of the workflow in each development phase. Process Workflows Inception Elaboration Construction Transition Modeling Requirements Analysis & Design Implementation Test Deployment Supporting Workflows Config Management Management Phases of Development Figure 2-2. Work flow intensity relative to development phase.

22 2.3.5 Task 5: Web-Based Screening Tool Design Task 5 was intended to “develop” the Web-based screening tool, and the research team took this to mean “design” the tool, which would logically precede Task 6. (In software devel- opment parlance “development” embraces all related activi- ties that are in the process workflows in Figure 2-2.) Tasks to complete in the tool design phase included mod- eling, requirements, and analysis/design. Modeling refers to the development and testing of concepts for the software. Requirements refers to the preparation of a software speci- fication and requirements (SSR) document that lists all the requirements of the Web-based tool (inputs, outputs, pro- cesses, and performance characteristics). Each requirement is a firm and testable statement about the capability of the new software. Analysis/design refers to the preparation of a design document, which is essentially a series of diagrams and supporting documentation that serves as a blueprint for the implementation of the tool. The design (or system archi- tecture) document includes diagrams representing multiple views of the system: logical (functionality), implementation (software management), process (performance, scalability, throughput), deployment (system topology, delivery, instal- lation, communication), and use case (understandability and usability). All of the system’s components including the data model, user interface, error handling, and communications between components are covered in the design document. The design document also includes mockups of pages that will give reviewers an idea of the intended “look and feel” of the Web-based tool. The team delivered requirements and design of the system in a recommended approach document. 2.3.6 Task 6: FRA-Hosted Beta Version Software and Supporting Documentation In Task 6, the researchers implemented the requirements and design that were developed in Task 5. The tool was developed on the research team’s development platform, and the beta version was to be installed on the FRA server and accessible for review and testing when complete. The researchers developed a users manual that offers thor- ough guidance to users and includes several walkthrough examples of how to develop an analysis using the screening tool. The users manual describes the database for the user and specific page formats and controls that will be provided to allow the user to enter the data and to ensure that data are properly assembled. Database design and data requirements were in the design documents of Task 5. This task delivered the operational beta version of the Web-based tool installed on the FRA server and the supporting documentation (users manual and annotated source code). 2.3.7 Task 7: Identification of Five Shared-Use Corridors for Case Studies The researchers selected five shared-use corridors for case studies. The case studies were selected with the intent of illus- trating the use of the tool’s features and its robustness for a range of operating scenarios. The case studies provided a source of valuable lessons learned for refining the Web-based tool into its release version. The research team considered the mixes of freight and pas- senger traffic attributes as shown in Figure 2-3. The researchers considered stages of planning or execution in selecting the case studies, that is, a mix of corridors that are in concept planning, implementation, or service were considered. A report to the project panel showed the research team’s pro- cess, the selection of candidate corridors for case studies, and the rationale behind these recommendations. 2.3.8 Task 8: Preparation of Three Case Studies Using the Beta-Version Tool Following the project panel’s selection of the shared-use corridors for study, the research team conducted three case studies. The case studies included analyses using the Web- based tool to establish feasibility for proposed alternatives. The case studies also contained the following: • Calibration of the Web-based tool—Where possible, the research team compared estimated metrics using the tool with actual measured metrics and fine-tuned the related models so that minimum differences between the actual and estimated results were achieved. • Validation of the Web-based tool—The research team validated the result outputs by comparing results to actual Moderate to High Volume C om m uter Low Volume Inter -City Freight Traffic Passenger Service Figure 2-3. Mix of freight and passenger traffic attributes for case studies.

23 measured outcomes, where possible. When not possible, the research team reviewed and validated case study results with individuals closely involved with the shared- use corridor. • Performance of sensitivity analysis—The case studies were subject to sensitivity analysis of key variables (those factors that are most responsible for the determination of acceptable levels of passenger service reliability and uninter rupted freight operations in the corridor). The research team delivered three case study reports. 2.3.9 Task 9: Draft Final Report, Draft Final Software with Supporting Documentation A draft final report was prepared to summarize work com- pleted and for project panel review at the completion of the research. This report reflects the project panel’s advice and com- ments submitted following review and addressing comments. These reports bring together all Web-based tool documenta- tion, the users manual, case studies, and information included in the interim report. The final version of the software and its supporting documentation is available on the FRA server.