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.

60 4.1 Introduction This research has produced a software tool called Shared- Use (SU) and a users manual whose underlying methods and effectiveness for corridor planning have been demonstrated in three case studies. The tool meets the research objective and should prove a useful and effective tool in support of screening proposed new rail services in shared-use corridors. This chapter has three subsequent sections. The first sec- tion includes the recommended approach for the design of the Web-based tool given the findings from the review of meth- odologies. The second section describes the implementation of the Web-based tool. The final section includes suggested research and next steps. 4.2 Recom mended Approach for a Web-Based Tool • Description of the Web-based tool, • System goals and constraints, • SU system features, and • SU use cases. 4.2.1 Description of the Web-Based Tool This section describes the recommended approach for the Web-based tool, beginning with a general description of its system architecture. The Web-based tool will be a three-tiered (presentation, business logic, database) application with standard multi-user, account-based data support and security features. The capabili- ties of the Web-based tool for shared-use rail corridor feasibility screening can be divided into the following three groups: • Data development, • Analysis modalities, and • Results exposition. An overview of the approach for SU is provided in Figure 4-1. 4.2.2 System Goals and Constraints The system goals and constraints that guided the develop- ment of the recommended approach are as follows: • Overarching Goal—SU will be an effective tool for pre- feasibility screening of shared-use rail corridor projects. • Web-Based—SU will be deployed on a central server that users will access via the Internet with a minimally configured computer and Web browser equipped with the Microsoft Silverlight add-on, available as a free download (71). • Configurability—SU is intended for corridor-specific analy- ses and will be generally applicable to a broad range of rail corridors and traffic control systems. System users must be able to provide input data and parameters as required to accurately simulate a specific rail system. • Usability—The system will be accessible and, with minimal training, usable by government personnel, other rail project proponents, and their consultants. • Standards Based—SU will be developed from widely used technologies without reliance on specialized tools or skill sets (minimizing vendor and consultant lock-in). • Flexibility—SU will enable users to manage and organize related datasets (e.g., track plans, operational plans, train sets, randomization parameters, and analysis results) to support various analysis scenarios and rail systems and to sup- port easy modification of scenarios as project plans evolve over time. • Performance and Scalability—SU will be able to perform realistically complex analyses of sufficient duration that provide robust results for specific corridor feasibility assess- ments, while achieving an optimal balance of run time and system resource utilization. 4.2.3 SU System Features SU conducts preliminary feasibility analyses of proposed shared-use rail corridors. The main purpose of SU is to screen C H A P T E R 4 Recommended Approach, Implementation, and Suggested Research

61 WEB-BASED TOOL CORE ANALYTIC ENGINE Train Performance Calculator Traffic Control Model MODES OF USE CONFLICT IDENTIFIER SIMULATION DATA DEVELOPMENT Train Builder and Scheduler Other Data Developer Scenario Builder INTERNET Track Infrastructure Data Entry and Visualization RESULTS String Charts Speed/Performance Charts Feasibility Metrics Average train speed by type of train Average wait by type of train Percentage of trains meeting reliability criteria by type Other summary metrics Figure 4-1. Recommended approach.

62 projects—removing unworthy candidates from further con- sideration while flagging those having merit for additional, more rigorous analysis. Key features of system include the following: • General – Ability to manage, share, and manipulate data represent- ing a railroad’s physical plant; train schedules, traffic volumes, and train consists; railroad operating schedules; traffic control; alternative analysis scenarios. – Ability to store and retrieve input data and results. – Ability to conduct meaningful pre-feasibility analyses in support of project screening. • Data entry and visualization – Ability to define and develop datasets in support of screening analyses. – Ability to enter and visualize track and related railroad physical plant data, including adequate detail to account for grade, curvature, and track needed to manage over- the-road (outside yard and terminal limit) operations of freight and passenger trains. – Ability to enter train, train consist, and schedule data, including built-in libraries of rolling stock to cover a wide range of operational scenarios. – Ability to enter data to support a minimal set of unit costs and other assumptions. • Conflict identification – Ability to identify points of potential conflicts (meets of opposing trains and overtakes by fast trains). The basis for conflict identification will be simulated move- ments in which conflicts are ignored (i.e., movements are unimpeded as if there were infinite capacity), but are identified in reports and graphical representation. – Ability to indicate location and type of infrastructure modification that mitigates unacceptable levels of conflict. • Simulation – Ability to model detailed train movement including time, position, speed, and the forces acting on a train. Train movements account for changes in terrain and track curvature as a train moves through a defined territory while observing speed limits and directives for routing and movement authorizations. – A central dispatcher that prioritizes train movements, makes routing decisions, prevents train deadlock, and effects the safe separation of trains. – Ability to specify the random distribution of departure delays affecting each scheduled train. • Results exposition – SU will contain a set of tables and charts for reporting results and enabling the screening of candidate passenger rail projects. – System outputs will include raw outputs (time-speed- position data of trains, dispatcher authorizations to trains by time, added infrastructure cost estimates, numbers of conflicts, numbers of meets/passes) and processed outputs (string chart, speed chart, authorities chart, total delay, and by components). 4.2.4 Use Cases Use cases describe how an “actor” interacts with the system. The primary actor for the system description is the SU user. An additional role and its functions will be defined in the system documentation for the SU administrator. Registration The user will browse to a URL, encounter an introductory page and, if not already registered, he or she will be prompted to register. Registration will establish a user ID and password, set up an account, and seed the account with necessary start-up data and files. Login The user logs in with his or her credentials (user ID or password). Login will include a forgotten password recovery feature. Folder Maintenance Folders will contain user data. This use case provides the ability for the user to archive and download a folder to the local computer, upload and restore an archived folder, set a folder to be used as default, reload the default folder, add a new folder, and delete a folder. Maintain Rail Infrastructure This use case provides the ability for the user to add or delete tables representing rail infrastructure data for the corridor of study. Set Up Trains This use case represents the ability of the user to view and update train information including train consists and schedules. Edit cars. The user specifies physical car attributes including car type, weight, length, load limits, number of axles, and reference documentation.

63 Edit locomotives. The user specifies physical locomotive attributes including length, transmission factor, weight, rated power (HP), type, axles, driven axles, and air resistance. Edit trains. The user develops train consists, selecting from user-defined or system-provided cars and locomotives, and provides a name for the train. Edit schedules. The user specifies a schedule for each train, providing scheduled station arrival and departure times and days of operation. Set Up Analysis This use case describes how the user sets up analysis and traffic control parameters and runs the analysis. Set Up Traffic Control The user provides various traffic control parameters that influence the dispatcher algorithm. Set Up Speed Restrictions (GCOR Forms A and B) The user may apply temporary speed restrictions con- forming to standard rail operations in the General Code of Operating Rules–Forms A and B (72). Select Trains The user selects from among the defined trains and also may set up a distribution (mean and standard deviation) for generating a random schedule delay for each train. View Track Schema The user may view a previously provided schematic diagram of the track schema. Run Analysis The user provides (or overwrites the default value of) a results file name, analysis start date-time, and end date-time. Optionally, the user may modify the random seed value, choose to ignore weight restrictions, and enable or disable real-time reporting. The user also may save the current settings as a job to be run at a later time. Once the parameters are set, the user invokes the analysis. View Results This use case describes how the user views analysis results. The user selects from a list of results files to view. The user may also delete, rename, or share/unshare selected results. View table. The user may view raw analysis data in table form for a selected train. View speed chart. The user may view a chart showing allowed and actual speed over the distance traveled for a selected train along with the corresponding terrain elevation profile. View string chart. The user may view a chart showing time and distance of train meets. View block authorizations chart. The user may view a chart showing locations and time spans of authorizations granted to all trains. View block authorizations table. The user may view a chart showing authorizations in tabular form for a selected train. Node Network Diagram The user may view a previously provided schematic diagram of the node network. 4.2.5 Data Development Capabilities Data development capabilities refer to the features that allow users to populate the tool, or that facilitate the pro- cess of doing so. The data development elements are the following: • Track infrastructure data entry and visualization, • Train builder and scheduler, • Other data developer, and • Scenario builder. These elements are described in the following subsections. Track Infrastructure Data Entry and Visualization Infrastructure data permits users to fully characterize the rail system and support analyses with the screening tool. The process of entering data into the tool can be facilitated with the introduction of a data visualization tool, which permits users to build, visualize, and validate rail system data. With the integrated data visualization tool, the user will develop rail infrastructure datasets within the SU software and store them in the database. The following items are part of the visualization tool use case. Set up or modify rail infrastructure dataset identifiers. The user specifies a rail infrastructure dataset including the name of the system whose rail infrastructure is being developed, the length of the corridor, and other characteristic data.

64 Set up or modify rail infrastructure system boundaries and timetable routes. The user specifies the boundaries of the system including its entry and exit points, stations, and timetable routes. Set up or modify complex items. The user specifies com- plex rail facility data such as crossovers, track inter connections, diamonds, double-ended sidings, slips, and multiple tracks. Set up or modify ancillary items. The user specifies ancillary data such as bridges and tunnels, highway-grade crossings, junctions and single-ended sidings, and yards. Generate or modify node network. The node network is a logical construct that is developed from the track data and is a required component for effecting deadlock-free traffic control. The user will be able to generate a basic node network or modify it. Train Builder and Scheduler When rail infrastructure data is imported into the tool, the user must define the trains that will operate over the simulated corridor. The tool will provide forms for building train consist data, with the ability to select from an inventory of car and locomotive data. A scheduling feature will also permit users to select schedules for each train, which include the days of operation, departure and arrival times, and station stops along the timetable route. Other Data Developer In addition to rail infrastructure and traffic mix data, users must define infrastructure unit costs. The unit cost component is intended to estimate infrastructure costs for added capacity required to integrate passenger and freight trains. Scenario Builder The Web-based tool will have a scenario builder, capable of conducting analyses for each mode of use. A scenario consists of a list of trains (developed with the train builder), a simu- lation start and end date, a set of a traffic control parameters, and optional features such as GCOR Forms A and B, temporary track outages, or train crew work schedule settings. The tool will allow users to save built scenarios and load them for future analyses. 4.2.6 Data Development Functionality Grade and Elevation Data The user enters data for track grade by section, which is the change in elevation divided by the length of the section (expressed as a percentage). Elevations at the section endpoints are derived from the grade information. Curve and Heading Data The user enters data for track curvature of a section, which is given by the section length and an angle of curvature. Head- ings at the section endpoints are derived from the curvature information. Speed Zone Data The user specifies the speed zone data for each track seg- ment, defined as the maximum allowable (“normal” or “track”) speed, by train class, on all portions of track within the segment (expressed in miles per hour). Traffic Control Data Signals. The user specifies the signals associated to specific tracks, specifying their type (e.g., automatic block signaling or ABS, centralized train control or CTC, positive train control or PTC), the side of the track they are on, and the direction(s) they face. Control points and towers. The user specifies the con- trol points and towers associated with interlock complexes, specifying a control point symbol, which indicates a location where switches or signals are remotely controlled by a dis- patcher, and providing a milepost to specify their location. Interlockings. The user specifies each interlocking by selecting a set of switches and signals that allow trains to safely switch or cross tracks where there may be some potential for a train collision. Ancillary Data Bridges and tunnels. The user specifies bridges by select- ing type (drawbridge, over, tunnel, under, or viaduct), the beginning milepost, and bridge or tunnel length in feet. Crossings. The user specifies highway crossings at grade, specifying milepost number, crossing name, description, and level of crossing protection (e.g., flashing lights, flashing lights and gates, private crossings, and signal-only cross-bucks). Crossovers and track interconnections. The user speci- fies crossovers and track interconnections, specifying the turn- outs, their milepost location, and a speed restriction based on the sharpness of the turnouts used. Diamonds. The user specifies diamonds, specifying the number of tracks involved (single or double) and the direction (left, right, and perpendicular).

65 FRA track class. The user specifies the FRA track class, specifying the maximum speed limit for each train type (passenger or freight) and track class (Class I through VII). Track weight limit. The user specifies the maximum car- load weight limit (e.g., 286K lbs.) for the track. Junctions and single-ended sidings. The user specifies junctions, noting the single-ended siding or series of sidings that create a connection to another route, railway, or significant yard complex. Multiple tracks. The user specifies multiple tracks, including double, triple, and quadruple track types. The user specifies maximum speed by train class and a normal operating direction. Double-ended sidings. The user specifies the double- ended siding, specifying the points on the track that it connects to, and its position relative to the main track (above or below). Slips. The user specifies each slip, or slip-switch— a complex switch-point work incorporated in yards and stations where the properties of a diamond and turnout are combined—specifying their milepost and designation (double or single). Yards. The user specifies each yard, specifying its name, position relative to the main line (above or below), and the range of mileposts over which it extends. Other Data The user specifies basic unit cost information that will enable a rough order of magnitude calculation of improvement costs. The system will include aggregate level high- and low- value guidance for several cost metrics. 4.3 Web-Based Tool Implementation The Web-based tool, whose design was described in the previous section, was implemented on a Web CMS called DotNetNuke™ (DNN) (73). A Web CMS is a bundled or stand- alone application to create, manage, store, and deploy content on Web pages. Web content includes text and embedded graphics, photos, video, audio, and code (e.g., for applications) that displays content or interacts with the user. A Web CMS Figure 4-2. SU home page.

66 may catalog and index content, select or assemble content at runtime, or deliver content to specific visitors in a requested way, such as other languages. Web CMSs usually allow client control over HTML-based content, files, documents, and Web hosting plans based on the system depth and the niche it serves. DNN is built on the Microsoft ASP.NET Web development platform, and the DNN community edition that was used is both royalty free and open source. Many of the commonly used features of a Web-based system (e.g., registration, login) are built in to DNN. DNN permits the integration of custom- coded components, which is where all the SU programmed elements are contained. 4.3.1 User Interface The user interface is a standard Web page, accessible on the FRA datacenter). From the home page, access to the system is limited to users who are registered and authorized by the system administrator. After login, users can access all of the system’s features through the main menu. The menu structure of SU is shown in Figure 4-3. SU includes an RIA called the Track Charting App that enables users to visualize and modify rail infrastructure data directly on a graphical user inter- face. Figure 4-4 shows a sample screen shot from the Track Charting App. All of the features of the Web-based tool and their use are explained in the users manual available on the FRA website. 4.3.2 Database The data for SU analyses, inputs, and outputs, are stored on the system database, which is implemented on an instance of SQL Server. Users may choose to archive their data to a local computer and restore them to the system database for use with a future session with SU. 4.3.3 Runtime Console Application After users have prepared their data for running an analysis on SU, they submit an analysis job to the SU job queue. A separate console application runs on the server that polls the database and job queue for submitted jobs and executes jobs based on submittal time (first submitted, first executed). The actual runtime logic for SU analyses is implemented in the console application. 4.3.4 Hosting Environment The system has several components that require hosting for Internet-based use as follows: • Web server, • Database, and • Runtime console application. All of these components could be hosted on a single physi- cal or virtual server. However, the requirements for the Web application are relatively light while the database and run- time console application require significant CPU and memory resources. For this reason, it is recommended that SU be hosted on a local area network with two servers: 1. Shared or virtualized Web server, 2. A database server and runtime console application. The specifications for the two servers shown in Table 4-1 should deliver good user experiences. The Web experience will not degrade with even 100 simul- taneous user sessions—well beyond the anticipated maximum use of the system. Submitted jobs, however, could take up to 5 minutes each to run. Many users submitting multi ple jobs simultaneously could result in long wait times. A future improvement could allow for multiple instances of the con- sole application running simultaneously to reduce wait times. 4.4 Suggested Research and Next Steps The SU Web-based tool is a complete and tested product that should prove its usefulness with practitioners. Experience shows that the adoption of tools can be accelerated through appropriate improvements so that the return on the research investment is maximized. The proposed improvements to the Web-based tool have been divided into the following three categories: • Refined capabilities, • Integration with corridor planning process, and • Walkthrough examples. 4.4.1 Refined Capabilities The following are proposed refinements to the Web-based tool that will enhance its performance and make it applicable to more operationally complex situation than in its current form. Dispatcher Algorithm Refinements The central dispatcher (CD) algorithm in SU is a deadlock- preventing algorithm. However, it makes decisions to grant authorities that may cause high-priority trains to be blocked for extended periods resulting in unacceptable outcomes. The existing rule-based algorithm can be extended with user-specified strategies, combinatoric methods, and heuristic

67 Shared Use Menu Tab or Page Features Figure 4-3. SU menu structure.

68 Figure 4-4. SU Track Charting App. Operating System CPU Random Access Memory Disk Requirement Other Specifications Web server (if virtualized, resources available to the virtual machine) Windows Server 2008 R2 or 2012 Single, multi-core processor 4GB 50GB Installation of .Net framework and DotNetNuke Database server and runtime console application Windows Server 2008 R2 or 2012 Dual, multi- core processor 32GB or more 200GB (preferably inline SAS drives) SQL Server 2008 R2 or 2012 Table 4-1. Specification of servers hosting SU.

69 methods so that it will generate acceptable outcomes in a wider range of operational situations than currently available. The three proposed improvements that would make SU more applicable to many challenging operational situations where it currently has limited usefulness are as follows: • Automated repeated simulations; • Find best dispatching from multiple sketch runs, then apply to full simulation; and • Apply a priori heuristics. The following sections describe these improvements. Improvement 1: Automated Repeated Simulations. The proposed improvement is to halt a simulation when it encounters a “fail” condition (e.g., passenger train delayed more than 20 minutes), then re-run the simulation with a new random seed or alternate set of inputs. Continue run- ning simulations until one finally completes without hitting a fail condition. One advantage of this approach is not waiting until a simu- lation completes once it fails. For instance, a simulation with a 5-minute run time may hit a fail condition after just 1 minute. Improvement 2: Find Best Dispatching from Multiple Sketch Runs, then Apply to Full Simulation. About 70 per- cent of simulation time is spent on the train movement algo- rithm. A “sketch” run would approximate train movement. In a short time, multiple sketch simulations could be run while tracking the CD decisions. Then, a set of CD decisions would be selected based on the sketch run with the least estima- ted delay. Finally, the selected set of CD decisions would be applied to a full simulation. Improvement 3: Apply a Priori Heuristics. Although there is no way to ensure a particular outcome, simulation results can be improved by selectively applying some strate- gies and combinations of strategies. For example: • Let trains of a particular type (e.g., freight) only advance along buffers and not by single nodes, • Set conditions for holding trains that will permit higher priority trains to advance, and • Designate certain track elements as freight only or passenger only. Train Movement Algorithm Refinements The train movement algorithm was adopted from the Train Performance Calculator developed at the Volpe National Transportation Systems Center. The algorithm is general, but more closely tailored to freight trains. There are multiple passenger train technologies that warrant dedicated refine- ments to the train movement algorithm in order to better reflect the train movement of passenger trains (i.e., acceleration, deceleration, braking, performance on different terrains, and refined fuel consumption calculation). This refinement would enable SU to report more reliably on the advantages and dis- advantages of alternative passenger train technologies and their comingling with freight traffic. Data Conversion The effort of data entry is a significant impediment to adoption, and this could be reduced if there were more features that enabled the conversion of data from other widely used simulation programs. Additional data interchange methods would speed adoption of SU. Additional Operational Strategies SU includes a number of features to capture special operat- ing conditions (e.g., slow orders, work zones, temporary track closures). A number of additional features that would sup- port real-world operating conditions and operating strategies that railroads employ could be added to SU to better replicate actual operations. Additional Planning Features and User Interfaces With a series of user workshops, feedback could be solicited that could guide additional development that would facilitate ease of use and potential adoption of SU. 4.4.2 Integration with Corridor Planning Process Additional guidance could be developed along with soft- ware modifications that could support the integration of SU with the corridor planning process to reduce the difficulty and cost of complying with the process. 4.4.3 Walkthrough Examples A number of additional step-by-step walkthrough exam- ples of new services and corridor enhancements would help users adopt and make the best use of SU.