At Decisiontek, we developed a train movement simulator to help rail operators determine the safety of their territories. In order to produce precise and dependable results, the software relied on a large set of inputs — the most important of which were the territory’s railroad infrastructure data.
Railroad infrastructure data describe all infrastructure and equipment within a rail system or subdivision. These include properties of the physical track such as their length, connectivity, grades, and curvatures, as well as equipment and devices including railroad switches, grade crossings, and signals. To conduct a study using our simulator, users had to define these data across 12 spreadsheets, which was an onerous process for territories that spanned hundreds of miles and included complex track configurations. We decided to re-design the experience of entering and managing railroad infrastructure data to accelerate this process and make it more accessible to non-technical users.
Our goal was to create new software that would present a visual representation of the track data that users could interact with. By abstracting the information into simple shapes and symbols, we could provide an intuitive interface for building, editing, and viewing railroad data. I developed this software over the course of 4 months using Microsoft Silverlight and the .NET Framework.
Designing the Interface
Our first task was to create a wireframe for the software. The major graphical elements of a territory’s visualization are the physical track along with its grades, curvatures, and speed limits. We organized these four elements and assigned them graphical representations using standards set forth in track diagrams – charts created by private railroads to depict their infrastructure. By preserving most of the design conventions used in track charts, our target users were a priori familiar with the user interface, giving them a sense of comfort when interacting with it.
Understanding the Data Model
Track segments and railroad switches form the basis of every railroad system. Track segments are the minimum unit of physical track that connect either to other segments or to switches. Railroad switches allow for one track to diverge into two tracks or for two tracks to converge back to one track. Together, track segments and switches form a ‘track network’ – a collection of inter-connected infrastructure elements that make up a rail system. This graph structure was reflected in the data model design using database columns that store both the preceding and succeeding infrastructure elements of each track or switch.
Executing the Track Visualization
One of the most common mistakes users made when preparing infrastructure data was specifying incorrect connectivity data (e.g. stating that segment 56 connects to both segments 55 and 73, when in fact it connects to segments 55 and 57). To validate against connectivity errors, I constructed the data visualization using a graph traversal algorithm. This method ensured that the territory depictions were only as accurate as their specified underlying data, and that only sections of the territory with connecting infrastructure elements would become displayed.
Most importantly, the traversal algorithm was used to discover and position the infrastructure elements on the canvas. Because territories often had multiple entry and exit points, the algorithm searched through every combination of system entry point, exit point, and direction in between. After all paths were searched, the algorithm knew exactly where elements were positioned relative to each other and could safely assign them x-positions on the canvas. An element’s x-position was determined using the cumulative length of all segments preceding it. An element’s y-position was available in the data and assumed to be set by the user at the time the element was created (users would eventually be able to create territories from scratch using the software, not only visualize existing ones).
In some cases, adjustments to track length or position were required to account for topological differences between actual track positions and the simplified track visualization. A common example is a siding, which track charts display as a section of track parallel to and with the same length as the main track. In reality, the main and siding tracks can have diverging paths with differing lengths. As a result, the algorithm had to trim or extend segments to ensure that diverging sidings connected back to the mainline at exact switch locations. I faced similar complications when visualizing track crossovers and wyes.
Displaying Track Grades, Curvatures, and Speed Zones
Specifying segment grades, curvatures, and speed zones allows the simulator to replicate the real-life operating conditions of a railroad. After users input these data, visualizing them can highlight errors such as excessive grades, drop-offs in elevation, or exceedingly sharp turns. Because of limitations in canvas space, these three track characteristics can only be displayed for one user-selected path through the system. However, users can still click on any segment to view its characteristic data.
Grades derive from elevation points, which are points along segments that hold measures of elevation in feet. Curvatures derive from heading points, which are points along segments that hold angle measures between the lines tangent to each point and the North-South line. Elevation and heading data are often obtained by the private railroads using satellite data, whereas grade and curvature data can be found on track charts and originate from on-site measurements. Grades are displayed like any other elevation profile, and curvatures are represented by semi-ellipses that face up or down when track curves to the left or right, respectively. Speed zones are shown as gray lines with maximum speed displayed above for each train type.
Editing Infrastructure Data
After territories could be visualized, I added menu items, forms, and data grids for editing the underlying data. Users could click on any track segment to edit it, delete it, or append a new one to it. If new segments were added, re-running the graph traversal algorithm refreshed the visualization.
To edit track characteristic data, users could summon an editable data grid by right-clicking a grade/curvature/speed zone shape or track segment. Modifications were asynchronously pushed to the database and the visualization was refreshed immediately afterwards. Users could also make modifications in a local spreadsheet and upload their changes.
Creating New Rail Systems
The final task was the ability to build new systems from scratch. I allowed users to start with a blank canvas and a single entry point from which they could build a rail line through a series of clicks. They could also add new entry points and interconnect parallel lines through crossovers. The process could take as little as three days to model a 100-mile double-track territory, as opposed to the three weeks of spreadsheet preparation, error trapping, and validation required by the previous data entry method.
Our final product received overwhelming positive feedback from our users. They saved an estimated 10 hours per week using the software, and our monthly number of troubleshooting requests declined substantially. Best of all, the railroads complimented us for our accurate depictions, and for the now-seamless process of running a full-fledged simulation analysis.