System and method for railway sleeper management

Abstract

A railway sleeper management system is disclosed that can provide an efficient and organized way to inspect and audit sleepers in a rail system. [Solution] The sleeper mark file can be retrieved by the client from a database or server in communication with the client, and an inspection information table and sleeper grid can be generated upon instantiation of an inspection process managed by the system. The sleeper grid can be operated to receive instructions from a user, and the inspection information table can be operated to respond to changes in the sleeper grid and automatically increment and decrement fields contained therein. The sleeper grid can be configured to integrate data from sleeper scans and present the data to the client in an efficient, user-friendly manner.

Description

[Technical Field]

[0001] FIELD OF THE DISCLOSURE The present disclosure relates generally to managing railroad ties located throughout a railroad system infrastructure. [Background technology]

[0002] Rail transportation systems enable passenger and freight movement across every continent and around the world. A typical component of railroad infrastructure is railroad tracks laid across a myriad of geographies and terrains. Railroad tracks are designed to withstand the worst elements and facilitate the movement of locomotives throughout the railroad system. Due to the track's constant exposure to hazardous conditions, railroad companies must take care to maintain track integrity. If a section of track is damaged or an obstruction is not addressed quickly, the consequences can be fatal.

[0003] A given railway infrastructure facility may contain millions of sleepers, whose integrity must be maintained at all times to ensure the safe movement of freight cars along the tracks. To ensure the integrity of the sleepers, railway systems utilize specialized equipment to inspect the sleepers and determine their overall condition. For example, Aurora® scanning technology, located on a truck that can move along the rails, is used to collect data on the sleeper's exterior (i.e., surface conditions such as cracks, breaks, etc.) and interior (i.e., density changes due to decay, disintegration, etc.). For management purposes, railroad tracks are often divided into divisions, subdivisions, line segments, etc., and the location of the track is often referenced by milepost markers, similar to mile markers on highways. Railroad sleepers are also often labeled with individual numbers that correspond to the specific area in which the railroad ties are located. For example, a railroad tie may be number 5423 in a particular subdivision, and railroad personnel can search between mileposts where the tie is known to be located, narrowing the scope of the search for that particular railroad tie.

[0004] While these organizational methods and specialized equipment are effective for collecting and managing information about railroad ties, railroad personnel are still required to perform additional inspections of railroad ties and make the final decision on whether a railroad tie should be replaced. However, monitoring and inspecting millions of railroad ties in a railroad system is extremely difficult to manage and organize. Summary of the Invention [Means for solving the problem]

[0005] The present disclosure achieves technical advantages by providing a system and method for railway tie management that can provide an organized and adaptive infrastructure configured to facilitate railroad tie inspection. The system allows individual clients to have segmented and assigned access privileges to the entire sleeper mark file system, allowing access to the sleeper mark file only when necessary or assigned. The system can provide a user-definable user interface for identifying, characterizing, and processing information about the railway ties. The railway tie management system can also generate inspection information tables and tie grids to facilitate sleeper inspection management.

[0006] The present disclosure solves the technical problem of organizing and managing multiple sleepers at any given railway infrastructure facility. For example, a railway sleeper management system can document information about railway sleepers by milepost, track code, and line segment, identify and notify users of sleepers due for replacement, and algorithmically determine the sleeper grade of each sleeper from sleeper scans for processing according to a tie replacement schedule. The system can operate to receive instructions for sleeper inspection on a per-tie basis, and sleepers marked for replacement can be easily demarked. The system may include data generated by various scanning technologies and can provide inspectors with real-time (sub-millisecond) data that is direct and immediately actionable during the inspection process. This helps save inspectors time and ensures the accuracy of the information entered into the system.

[0007] Railroad ties are a core component of railroad infrastructure. Locomotive wheels travel along two parallel rails. Railroad ties may be slats placed between and beneath the rails of the track. Rails may be fixed substantially vertically at the ends of the ties. Railroad ties may maintain the three-dimensional coordinates of the track: "gauge," "line," and "surface." Track gauge refers to the distance between two railroad tracks that must be maintained for freight cars on the rails to operate satisfactorily. The track line indicates the horizontal position of the rails. For example, rails may be straight or curved around obstacles such as steep slopes. The "surface" of the track may be the vertical displacement of the rails, such as when the rails pass over hilly terrain. Railroad ties can be made of a variety of materials, including wood, concrete, metal, plastic, or other materials suitable for maintaining a predetermined gauge, line, and surface of the rails.

[0008] The railway sleeper management system may include a networked server in operative communication with the database, and the networked computing device may access the database via the server to retrieve railway sleeper mark files for inspection process instantiation. In another exemplary embodiment, the railway sleeper management system includes control logic operable to receive user instructions thereby to edit the sleeper mark files. In another embodiment, the railway sleeper management system includes multiple subsystems through which sleeper management and inspection can be accomplished, such as a dashboard subsystem, a tie mark retrieval subsystem, a tie audit subsystem, and a settings subsystem.

[0009] In an exemplary embodiment, the present disclosure includes a method for managing sleepers in a railway system, the method including generating and storing a plurality of tie mark files in a memory; receiving a request over an encrypted network for a first tie mark file having railway sleeper data; providing the first tie mark file to a client over the encrypted network; and instantiating, via a processor, an inspection process using the railway sleeper data to generate an inspection information table and a tie grid, the tie grid including metadata about the first sleeper. The method further includes categorizing the first tie mark file according to a predetermined category. The method further includes selecting the first tie mark file. The first tie mark file includes sleepers for a predetermined section of railway track. The method further includes receiving an entry selecting the first sleeper and generating, via a processor, a graphic highlighting the selection. The method further includes generating an indication if the first sleeper is marked for replacement. The method further includes modifying, via a processor, the first sleeper metadata if a flip command is received. The method further includes instantiating an image capture function on the client and storing the captured image in the first sleeper metadata. The method further includes instantiating, via the processor, a user input field and storing the input data in the first sleeper metadata. The method further includes determining railroad track characteristics and displaying the railroad track characteristics on the sleeper grid.

[0010] In another exemplary embodiment, the disclosure may include a railway sleeper management system including a data storage device including a first database including a plurality of sleeper mark files, and a networked computer processor operatively connected to the storage device via an encrypted network and capable of executing machine-readable instructions to perform program steps including retrieving the sleeper mark files from the database, instantiating an inspection process on the sleeper mark files to generate a sleeper grid and an inspection information table including metadata about the plurality of sleepers, editing the sleeper mark files, and storing the edited sleeper mark files in the database. The program steps include receiving an entry selecting a first sleeper in the sleeper grid and generating via the processor a graphic highlighting the selection.

[0011] The program steps further include generating an indication if a sleeper in the sleeper grid is marked for replacement. The program steps further include modifying the first sleeper metadata via the processor if a flip command is received. The program steps further include instantiating an image capture function in the client and storing a captured image in the first sleeper metadata via the processor. The program steps further include instantiating a user input field and storing the input data in the first sleeper metadata via the processor. The program steps further include determining railroad track characteristics and displaying the railroad track characteristics on the sleeper grid.

[0012] In another exemplary embodiment, the present disclosure may include a rail tie status processing system, the rail tie status processing system including a data storage device including a plurality of sleeper mark files, and a networked computer processor operatively connected to the storage device via an encrypted network and capable of executing machine-readable instructions to perform program steps, the program steps including receiving a location of a client device, indicating a starting point and direction of travel at the client device, generating a rail tie status indicator for each of the plurality of railway sleepers in the rail tie file, and receiving input to confirm or change the status of the rail tie. The rail tie status processing system further includes displaying a graphic illustrating one or more rail sleepers for a section track associated with the rail tie file. The graphic indicates a sleeper type, a sleeper number, and attributes or characteristics associated with the railway track. [Brief explanation of the drawings]

[0013] [Figure 1] 1 illustrates an example railway sleeper management system in accordance with one or more exemplary embodiments of the present disclosure. [Figure 2] 1 illustrates an example diagram of a railway sleeper management system in accordance with one or more exemplary embodiments of the present disclosure. [Figure 3] 1 illustrates a railway sleeper management system control logic according to one or more exemplary embodiments of the present disclosure. [Figure 4] 1 illustrates rail sleeper status processing control logic according to one or more exemplary embodiments of the present disclosure. [Figure 5] 1 illustrates a railway sleeper management and processing system control logic according to one or more exemplary embodiments of the present disclosure. [Figure 6A] 1 illustrates railway sleeper inspection control logic according to one or more exemplary embodiments of the present disclosure. [Figure 6B] 1 illustrates railway sleeper inspection control logic according to one or more exemplary embodiments of the present disclosure. [Figure 7A]1 illustrates an exemplary embodiment of a railway sleeper management system component, in accordance with one or more exemplary embodiments of the present disclosure. [Figure 7B] 1 illustrates an exemplary embodiment of a railway sleeper management system component, in accordance with one or more exemplary embodiments of the present disclosure. [Figure 8A] 1 illustrates an exemplary embodiment of a railway sleeper management system component, in accordance with one or more exemplary embodiments of the present disclosure. [Figure 8B] 1 illustrates an exemplary embodiment of a railway sleeper management system component, in accordance with one or more exemplary embodiments of the present disclosure. [Figure 8C] 1 illustrates an exemplary embodiment of a railway sleeper management system component, in accordance with one or more exemplary embodiments of the present disclosure. [Figure 9A] 1 illustrates a railway sleeper management system interface for providing railway sleeper mark files to a client device for download, according to one or more exemplary embodiments of the present disclosure. [Figure 9B] 1 illustrates a railway sleeper management system interface for providing railway sleeper mark files to a client device for download, according to one or more exemplary embodiments of the present disclosure. [Figure 9C] 1 illustrates a railway sleeper management system interface for providing railway sleeper mark files to a client device for download, according to one or more exemplary embodiments of the present disclosure. [Figure 9D] 1 illustrates a railway sleeper management system interface for providing railway sleeper mark files to a client device for download, according to one or more exemplary embodiments of the present disclosure. [Figure 10A] 1 illustrates an exemplary embodiment of a railway sleeper management system component, in accordance with one or more exemplary embodiments of the present disclosure. [Figure 10B] 1 illustrates an exemplary embodiment of a railway sleeper management system component, in accordance with one or more exemplary embodiments of the present disclosure. [Figure 10C] 1 illustrates an exemplary embodiment of a railway sleeper management system component, in accordance with one or more exemplary embodiments of the present disclosure. [Figure 10D] 1 illustrates an exemplary embodiment of a railway sleeper management system component, in accordance with one or more exemplary embodiments of the present disclosure. [Figure 10E] 1 illustrates an exemplary embodiment of a railway sleeper management system component, in accordance with one or more exemplary embodiments of the present disclosure. [Figure 10F] 1 illustrates an exemplary embodiment of a railway sleeper management system component, in accordance with one or more exemplary embodiments of the present disclosure. [Figure 11A] 1 illustrates an exemplary embodiment of a railway sleeper management system component, in accordance with one or more exemplary embodiments of the present disclosure. [Figure 11B] 1 illustrates an exemplary embodiment of a railway sleeper management system component, in accordance with one or more exemplary embodiments of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0014] As set forth below, preferred versions of the disclosure presented in the description and its various features and advantageous details will be more fully described with reference to non-limiting examples included in the accompanying drawings, as detailed in the following description. Descriptions of well-known components have been omitted so as not to unnecessarily obscure the main features described herein. The examples used in the following description are intended to facilitate understanding of how the present disclosure can be embodied and implemented. Therefore, the examples should not be construed as limiting the scope of the claims.

[0015] FIG. 1 shows a schematic diagram of a railway sleeper management system 100 according to one or more embodiments of the present disclosure. The railway sleeper management system 100 includes a railway sleeper management system server 102 operably connected to a database 104. The server 102 can be operably coupled to one or more clients 108 via a network connection 106. The clients 108 can be physical devices (e.g., mobile phones, computers, or other suitable devices), programs, or applications. In other exemplary embodiments, the clients 108 can include mobile devices having a mobile application configured to communicate with the server 102.

[0016] A server may be implemented using hardware, software, or a suitable combination of hardware and software, and may include one or more software systems operating on one or more servers having one or more processors with access to memory. A server may also include electronic storage devices, one or more processors, and / or other components. A server may also include communication lines or ports that allow information exchange with a network and / or other computing platforms. A server, as used herein, may also include multiple hardware, software, and / or firmware components that work together to provide the functionality attributed to a server. For example, a server may be implemented by a cloud of computing platforms that together operate as a server. A server may also include memory.

[0017] Memory may include non-transitory storage media that electronically store information and may include electronic storage devices. The electronic storage media of the electronic storage devices may include one or all of system storage provided integrally with the server (i.e., substantially non-removable) and / or removable storage that can be removably coupled to the server via, for example, a port (e.g., a USB port, a Firewire port, etc.) or a drive (e.g., a disk drive, etc.). The electronic storage devices may include one or more of optically readable storage media (e.g., optical disks, etc.), magnetically readable storage media (e.g., magnetic tape, magnetic hard drives, floppy drives, etc.), charge-based storage media (e.g., EEPROM, RAM, etc.), solid-state storage media (e.g., flash drives, etc.), and / or other electronically readable storage media. The electronic storage devices may include one or more virtual storage resources (e.g., cloud storage, virtual private networks, and / or other virtual storage resources). The electronic storage device may store machine-readable instructions, software algorithms, information determined by a processor, information received from a server, information received from a computing platform, and / or other information that enables the server to operate, as described herein. The electronic storage device may be accessed via a network connection.

[0018] The processor may be configured to provide information processing functionality at the server.

[0019] As such, a processor may include one or more of a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and / or other mechanisms for electronically processing information, such as an FPGA or ASIC. A processor may include a single entity or multiple processing units. Such processing units may be physically located within the same device, or a processor may represent the processing functions of multiple devices operating in coordination or software functionality.

[0020] A processor may be configured to execute machine-readable instructions or learning modules through software, hardware, firmware, a combination of portions of software, hardware, and / or firmware, and / or other mechanisms for configuring the processing functionality of the processor. As used herein, the term "machine-readable instructions" refers to any component or set of components that perform the functions attributed to the machine-readable instruction components. This may include one or more physical processors during execution of processor-readable instructions, processor-readable instructions, circuitry, hardware, storage media, or any other component.

[0021] The server may be configured with machine-readable instructions having one or more functional modules. The machine-readable instructions may be implemented on one or more servers having one or more processors with access to memory. The machine-readable instructions may be a single networked node or a machine cluster including multiple networked nodes in a distributed architecture. The machine-readable instructions may include control logic for implementing various functions, as described in more detail below. The machine-readable instructions may include specific functions related to the railway sleeper management system 100.

[0022] For example, in the case of the railway sleeper management system 100, the format of messages sent to and received from the server 102 and the client 108 may include any suitable format, including JavaScript Object Notation (JSON), TCP / IP, XML, HTML, ASCII, SMS, CSV, API, or other suitable formats. Each message may consist of a message header, header properties, and a message body, or may be encapsulated and packetized in any suitable format that includes a web representational state transfer (REST) ​​format. The components of the system (e.g., the server and clients) described above may be communicatively connected via the Internet, an intranet, or other suitable network. Message transmissions may be encrypted or unencrypted, using VPN tunnels or other suitable communication means. The components of the system 100 may be connected via a WAN, LAN, PAN, or other suitable network 106. Network communications between client 108 and server 100 may be encrypted using PGP, Blowfish, Twofish, AES, 3DES, HTTPS, or other suitable encryption. System 100 can be configured to communicate with various other systems and modules disclosed herein using Wi-Fi, Bluetooth, Ethernet, or other suitable communications protocols. Network communications may occur via application programming interface (API), PCI, PCI-Express, ANSI-X12, Ethernet, Wi-Fi, Bluetooth, or other suitable communications protocols. Third-party databases may also be operably connected to the system components via network 106.

[0023] FIG. 2 , in accordance with one or more exemplary embodiments of the present disclosure, illustrates a diagram of a railway sleeper management system 200 having multiple subsystems, including, for example, a dashboard system 202, a sleeper inspection system 204, a sleeper mark search system 206, and a configuration system 208. In an embodiment, the sleeper inspection system 204, the sleeper mark search system 206, and the configuration system 208 may be subsystems of the dashboard system 202. In an exemplary embodiment, the railway sleeper management system 200 is embodied in part via a mobile application on a smart device, where aspects of the system respond to user commands and inputs to achieve various results. For example, the railway sleeper management system 200 may include a smartphone that executes machine-readable instructions, including an installed mobile application that includes the dashboard system 202. Through the dashboard 202, a user can communicate with the railway sleeper management system server 102 and database 104 via the Internet 106, as shown in FIG. 1 . In other exemplary embodiments, the railway sleeper management system 200 may be implemented as an application on a smart device and is in operative communication with the server 102 and the database 104, and the dashboard system 202, sleeper audit system 204, sleeper mark search system 206, and configuration system 208 may operate as subsystems to the implemented application.

[0024] 3 shows a flowchart 300 illustrating control logic implementing features of a method for railway sleeper dashboard generation and management, according to one or more exemplary embodiments of the present disclosure. The railway sleeper dashboard control logic 300 may be implemented as an algorithm on a server, a machine learning module, or other suitable system. The railway sleeper dashboard control logic 300 may be achieved through software, hardware, an application programming interface (API), a network connection, a network transmission protocol, HTML, DHTML, JavaScript, Dojo, Ruby, Rails, other suitable applications, or any suitable combination thereof.

[0025] The railway sleeper dashboard control logic 300 may take advantage of the computer platform's ability to spawn multiple processes and threads by processing data simultaneously. The speed and efficiency of the railway sleeper dashboard control logic 300 may be greatly improved by instantiating more than one process to generate and manage the railway sleeper dashboard. However, those skilled in the art of programming will understand that the use of a single processing thread may also be utilized and is within the scope of the present disclosure.

[0026] The process flow of the railroad tie dashboard control logic 300 of this embodiment begins at step 302, where the control logic 300 receives an access request from a client. In an exemplary embodiment, the client may be a mobile application running on a mobile smart device according to the present disclosure. The control logic 300 then proceeds to step 304.

[0027] At step 304, control logic 300 generates and renders a login screen to allow the user to access the system. In an exemplary embodiment, the client may prompt the user to enter a username and password, a fingerprint, a facial image, or other appropriate data. Control logic 300 then proceeds to step 306.

[0028] In step 306, control logic 300 determines whether user authentication was successful. In an exemplary embodiment, control logic 300 may initiate authentication of user credentials via authentication key matching or other suitable authentication methods. If authentication 306 fails, the client may re-display login screen 304 until authentication is successful or a maximum number of attempts is reached. If authentication 306 is successful, the client may display a dashboard with links to one or more systems and subsystems, such as dashboard system 202, sleeper audit system 204, sleeper mark retrieval system 206, and configuration system 208. In other exemplary embodiments, dashboard system 202 may render and retrieve railway sleeper files locally. In other exemplary embodiments, dashboard system 202 may retrieve a remote database or other suitable stored railway sleeper files. Dashboard system 202 may also render an indication of the number of sleepers audited and the number of sleepers marked. Rendering may be on the client device. In other exemplary embodiments, dashboard system 202 may also identify the status of the available railroad tie files. For example, the status may include an indication that the file is "in progress" or "completed," among other suitable states. In other exemplary embodiments, railroad tie files may be categorized according to status. Control logic 300 may then terminate or wait for new authentication information and repeat the steps described above.

[0029] 4 shows a flowchart 400 illustrating control logic implementing features of a method for rail sleeper condition processing in accordance with one or more exemplary embodiments of the present disclosure. The rail sleeper condition processing control logic 300 may be implemented as an algorithm on a server, a machine learning module, or other suitable system. The rail sleeper condition processing control logic 400 may be achieved through software, hardware, an application programming interface (API), a network connection, a network transmission protocol, HTML, DHTML, JavaScript, Dojo, Ruby, Rails, other suitable applications, or any suitable combination thereof.

[0030] The rail sleeper status processing control logic 400 may take advantage of the computer platform's ability to spawn multiple processes and threads by processing data simultaneously. The speed and efficiency of the rail sleeper status processing control logic 300 may be greatly improved by instantiating more than one process to generate and manage the railway sleeper dashboard. However, those skilled in the art of programming will understand that the use of a single processing thread may also be utilized and is within the scope of the present disclosure.

[0031] The rail sleeper status processing control logic 400 process flow of this embodiment begins at step 402, where the control logic 400 can access one or more rail sleeper files. In an exemplary embodiment, the sleeper files may include a file identifier. The file identifier may be a file name or other unique identifier. In other exemplary embodiments, the file identifier relates to a railroad track segment, location, or other related information. In other exemplary embodiments, the rail sleeper files may be accessed on a client device, such as a mobile application running on a mobile smart device, laptop, smartwatch, or other suitable device. The control logic 400 then proceeds to step 404.

[0032] In step 404, control logic 400 determines a railroad tie file status for each railroad tie file. In an exemplary embodiment, the file status indicates if, how, when, where, and by whom the file has been used by control logic 400. In other exemplary embodiments, the file status may include "not started," "in progress," and "completed," among other related states. Control logic 400 then proceeds to step 406.

[0033] In step 406, control logic 400 classifies the railroad tie files according to file status. In an exemplary embodiment, file status may be classified according to whether, how, when, where, and by whom the file has been used. In an exemplary embodiment, the railroad tie mark files may be classified by control logic 400 according to a sequential search, bubble search, or quick search algorithm, among others. Control logic 400 then proceeds to step 408.

[0034] In step 408, the control logic 400 displays the file identifiers of the categorized sleeper files on the client device. The control logic 400 then proceeds to step 410.

[0035] At step 410, control logic 400 generates a file action indicator for selectively processing the sleeper file. In an exemplary embodiment, the file action indicator may be a symbol or letter displayed in proximity to the file identifier on the client device. In other exemplary embodiments, the file action indicator may instantiate a process that can complete the type file upload, open the sleeper file, or download the sleeper file, among other associated actions. Control logic 400 then proceeds to step 412.

[0036] At step 412, control logic 400 receives the location of the client device. In an exemplary embodiment, a GPS receiver may be located within or operably connected to the client device. Control logic 400 receives the GPS coordinates of the client device to identify the location of the client device. In another exemplary embodiment, the location of the client device may be identified via a symbol on a map displayed on the client device. Control logic 400 then proceeds to step 414.

[0037] At step 414, control logic 400 indicates a starting point and direction of travel on the client device. In an exemplary embodiment, control logic 400 may generate a notification or indication of the direction of travel to the starting point. The starting point and direction of travel may be indicated by a map symbol, an audible instruction played through a speaker on the client device, a textual direction (e.g., latitude and longitude), or any other suitable means. Control logic 400 then proceeds to step 416.

[0038] In step 416, control logic 400 displays a graphic showing one or more rail ties for the section of track associated with the tie file. In an exemplary embodiment, the graphic shows the tie type, tie number, attributes or characteristics, or other relevant information for the rail track. Control logic 400 then proceeds to step 418.

[0039] In step 418, control logic 400 generates a rail sleeper status using the sleeper file. In an exemplary embodiment, the rail sleeper status indicates the nature or condition of the rail sleeper. For example, the rail sleeper status indicates whether the sleeper is worn, in need of replacement, or acceptable. In other exemplary embodiments, control logic 400 can retrieve the status from the sleeper file and populate the rail sleeper status through automatic scanning for confirmation. In other exemplary embodiments, the sleeper file may be an XML file with multiple fields describing various characteristics of the rail sleeper, section, or railway or other related subject matter. Control logic 400 then proceeds to step 420.

[0040] In step 420, control logic 400 generates a sleeper status indicator for each rail sleeper. In an exemplary embodiment, symbols or letters can be generated by the control logic to correlate the sleeper status with a library of status indicators and display the associated indicator at or near each rail sleeper on the client device display. Control logic 400 then proceeds to step 422.

[0041] In step 422, control logic 400 receives input to confirm or change the status of each rail sleeper in the sleeper file. In an exemplary embodiment, control logic may generate and display one or more statuses for the rail sleeper so that the user can select the appropriate status. In another exemplary embodiment, control logic 400 may generate controls to increment or decrement through each rail sleeper. Once the desired rail sleeper is selected, control logic 400 receives input from the user regarding the status of the rail sleeper to confirm or "flipping" the status of the selected rail sleeper. Control logic 400 then exits or waits for input to repeat the steps described above.

[0042] 5 shows a flowchart 500 illustrating control logic implementing features of a method for railway sleeper file management and processing, according to one or more exemplary embodiments of the present disclosure. The railway sleeper file control logic 500 may be implemented as an algorithm on a server, a machine learning module, or other suitable system. The railway sleeper file control logic 500 may be achieved in software, hardware, an application programming interface, a network connection, a network transmission protocol, HTML, DHTML, JavaScript, Dojo, Ruby, Rails, other suitable applications, or any suitable combination thereof.

[0043] The process flow of the railroad tie file control logic 500 of this embodiment begins at step 502 where the control logic 500 instantiates a dashboard system 502. In an exemplary embodiment, the client may be a mobile application running on a mobile smart device according to the present disclosure. The control logic 500 then proceeds to step 504.

[0044] At step 504, control logic 500 determines whether the sleeper mark file is locally available (e.g., stored on the client device). In other exemplary embodiments, control logic 500 may determine whether the sleeper mark file can be accessed remotely (e.g., at network-attached storage, a server, a database, or other suitable remote location). If the target sleeper mark file is locally available, control logic 500 proceeds to step 514. If the target sleeper mark file is not locally available, control logic 500 proceeds to step 506.

[0045] In step 506, control logic 500 instantiates sleeper mark retrieval system 506. In an exemplary embodiment, control logic 500 is instantiated to facilitate providing sleeper mark files from a railway sleeper management system server or database to a client. Control logic 500 then proceeds to step 508.

[0046] In step 508, control logic 500 determines whether authentication was successful. Authentication may be for a user, a device, or other suitable entity. In an exemplary embodiment, control logic 500 may initiate authentication of user credentials through authentication key matching or other suitable authentication methods. If authentication 508 fails, control logic 500 proceeds to step 502. If authentication 508 is successful, control logic 500 proceeds to step 510.

[0047] At step 510, control logic 500 generates a user prompt to confirm the user's consent to the permissions requested by server 510. In an exemplary embodiment, the requested permissions may include access to client resources such as the microphone, network, and other suitable resources, as well as client location and data. Control logic 500 then proceeds to step 512.

[0048] At step 512, control logic 500 provides the requested sleeper mark file to client 512. In an exemplary embodiment, the sleeper mark file may be transmitted over an encrypted network. Network communications between the client and server may be encrypted using PGP, Blowfish, Twofish, AES, 3DES, HTTPS, or other suitable encryption. Control logic 500 then proceeds to step 514.

[0049] At step 514, the control logic 500 classifies the sleeper mark files into predetermined categories. In an exemplary embodiment, the sleeper mark files include metadata regarding various characteristics of the files, including timestamp, status, inspector, location, and other appropriate metadata. The metadata may then be grouped into similar categories, either predetermined or generated by the device. In other exemplary embodiments, the predetermined categories may include "NOT STARTED," which refers to sleeper mark files that have been downloaded from the server but not yet interacted with on the client device; "IN PROGRESS," which refers to sleeper mark files that have been interacted with on the client device but not yet marked as completed; "COMPLETED," which refers to sleeper mark files that have been marked as completed; or "RECENTLY WORKED," which refers to files that have been recently downloaded, accessed, queried, or interacted with. It will be appreciated that numerous other categories may be used, such as geographic location, number of sleepers to be inspected, priority, etc. The control logic 500 then proceeds to step 516.

[0050] In step 516, control logic 500 estimates various data related to the railroad tie file. In an exemplary embodiment, a selection of a particular railroad tie mark file is received (e.g., file name, timestamp, location, etc.), and the system generates a display of the railroad tie mark file details in step 518. In an exemplary embodiment, control logic 500 may generate and display a graphic depicting one or more railroad ties. In other exemplary embodiments, the graphic may be processed by control logic 500 to generate one or more indicators characterizing each railroad tie using railroad tie information from the railroad tie file. Thereafter, in step 520, a milepost designation entry is received (in one embodiment, a user communicates with a system with mileposts at which to inspect the sleepers), and then a direction entry is received in step 522 to indicate the direction of inspection. In another exemplary embodiment, the direction entry may be "increase" or "decrease," corresponding to west and east, respectively. The control logic 500 then waits for user input and proceeds to step 524 if a "check" command is received, step 540 if a "set" command is received, or step 542 if an "audit" command is received.

[0051] At step 524, control logic 500 receives an "inspect" command. In an exemplary embodiment, the inspect command may generate a graphic showing one or more rail sleepers for the section of track associated with the sleeper file. In another exemplary embodiment, the inspect command may display a rail sleeper status indicating the nature or condition of each rail sleeper in the sleeper file. In another exemplary embodiment, a sleeper status indicator may be generated for each rail sleeper. In another exemplary embodiment, a symbol or letter may be generated by the control logic to correlate the sleeper status with a library of status indicators and display an indicator associated with or near each rail sleeper on the client device display. Control logic 500 then proceeds to step 526.

[0052] At step 526, an inspection process is instantiated to inspect the data in the sleeper mark file. In an exemplary embodiment, the graphic indicates the sleeper type, sleeper number, attributes or characteristics, or other relevant information for the railroad track. In another exemplary embodiment, the rail sleeper status indicates the nature or condition of the rail sleeper. In another exemplary embodiment, the control logic may generate and display one or more statuses for the rail sleeper so that the user can select the appropriate status. In another exemplary embodiment, the control logic 500 may generate controls to increment or decrement through each rail sleeper. Once the target rail sleeper is selected, the control logic 400 may receive input from the user indicating the status of the rail sleeper. The control logic 500 then proceeds to step 528.

[0053] In step 528, if the test is complete, control logic 500 receives and confirms a storage command. In an exemplary embodiment, the test progress may be stored locally on the client device. Control logic 500 then proceeds to step 530.

[0054] In step 528, control logic 500 receives and acknowledges a "mark complete" command that ends the inspection process and records all metadata about the rail sleeper inspection captured by control logic 500 in a sleeper mark file. In an exemplary embodiment, the sleeper file is marked as complete, ultimately allowing the sleeper mark file to be classified, categorized, and displayed in the dashboard system. Control logic 500 then terminates or waits for input to repeat the steps described above.

[0055] At step 532, control logic 500 receives an "upload" command to upload the completed sleeper file to a remote location. In an exemplary embodiment, once the locally available sleeper mark file is marked as completed, an upload command may be received by control logic 500 to initiate transmission of the completed file to a server, network storage device, or other associated location. Control logic 500 then proceeds to step 534.

[0056] In step 534, control logic 500 authenticates the user or communicates with other systems that can authenticate the user. In an exemplary embodiment, control logic 500 may initiate authentication of user credentials via authentication key matching or other suitable authentication methods. In other embodiments, the user must be authenticated in order for the user to upload sleeper files. Control logic then proceeds to step 536.

[0057] In step 536, control logic 500 determines whether user authentication was successful. If authentication 534 fails, control logic 500 re-displays the login screen on the client device display until authentication is successful or the maximum number of tries is reached. If authentication is confirmed, control logic 500 proceeds to step 538.

[0058] In step 538, control logic 500 uploads one or more updated sleeper mark files from the client device to a remote location over an encrypted or unencrypted network connection. Control logic 500 can then terminate or wait for new input and repeat the steps described above.

[0059] 6A-6B depict a flowchart 600 (starting in FIG. 6A and continuing in FIG. 6B) illustrating control logic implementing features of a method for railway sleeper inspection, according to one or more exemplary embodiments of the present disclosure. The railway sleeper inspection control logic 600 may be implemented as an algorithm on a server, a machine learning module, or other suitable system. The railway sleeper inspection control logic 600 may be achieved in software, hardware, an application programming interface, a network connection, a network transmission protocol, HTML, DHTML, JavaScript, Dojo, Ruby, Rails, other suitable applications, or any suitable combination thereof.

[0060] Referring to FIG. 6A, the process flow of the railway sleeper inspection control logic 600 of this embodiment begins at step 602, where the control logic 500 instantiates an inspection process. When instantiating the inspection process 602, an inspection information table is generated at step 608. As discussed in connection with FIG. 5, a user may select an increasing or decreasing direction before instantiating the inspection process when selecting a sleeper mark file for inspection. In step 604, in the exemplary embodiment, if an increasing direction is selected, the control logic 600 generates a sleeper grid with the sleepers sorted in ascending order by sleeper number. In step 606, if a decreasing direction is selected, the control logic 600 generates a sleeper grid with the sleepers sorted in descending order by sleeper number.

[0061] In step 610, the generated sleeper grid is responsive to multiple user inputs. For example, a search sleeper command may be received prompting the user to enter a target sleeper number. If a search sleeper command is received, control logic continues to step 612. If a search sleeper command is not received, control logic continues to step 618.

[0062] At step 612, a sleeper number entry is received by control logic 600. At step 614, a find distance command is received by control logic 600. At step 616, control logic 600 calculates and displays the physical distance between the specified sleeper and the client device. In an exemplary embodiment, such distance calculation may utilize a GPS receiver operably connected to a client device, such as a mobile smart device (e.g., authorization granted if requested, e.g., 510 of FIG. 5). At step 620, a "go to tie" command is received, which at step 622 navigates the user to the specified sleeper in the sleeper grid.

[0063] In step 618, the control logic receives a navigation entry to navigate to a particular sleeper in the sleeper grid. In other exemplary embodiments, instead of using the generated commands of the control logic 600, a user may use manual entry (e.g., scrolling, arrow keys, or any other suitable user input interface) to manually navigate to a particular sleeper in the sleeper grid.

[0064] Once the target sleeper is navigated to, a selection entry of the particular sleeper is received and highlighted in step 624. In an exemplary embodiment, the control logic 600 can display the selected sleeper on the client device, which may highlight, paint, bald, or otherwise distinguish the selected sleeper from the unselected sleepers in the sleeper grid.

[0065] In step 626, the sleeper is marked for replacement. In an exemplary embodiment, such designation is already programmed into the sleeper mark file. The control logic 600 may parse attributes for the particular sleeper from the sleeper file and render the sleeper on the client device according to such attributes.

[0066] In step 628, the control logic generates an indication to inform the user of the attribute for the sleeper to be marked. In an exemplary embodiment, the indication may be visual (color), tactile (vibration), audible (sound, etc.), or other relevant user indication.

[0067] If the sleeper is not marked for replacement at step 626, control logic 600 determines to take no action at step 644. In an exemplary embodiment, the user may tag the sleeper with metadata indicating to take no action via control logic 600. At step 630, a flip command is also received by control logic 600. The flip command may be selected by the user via a client device.

[0068] In step 632, the designation (state) of the sleeper is switched between "action" and "no action," and the control logic may display such change to the user. In other exemplary embodiments, sleepers marked for replacement will no longer be marked for replacement, and sleepers not so marked will be so marked.

[0069] In step 634, a comment command is received by control logic 600. In an exemplary embodiment, the sleeper grid can be navigated via user-input commands such as PREVIOUS and NEXT, which navigate the grid to select the sleeper immediately adjacent to the currently selected sleeper in the indicated direction. In another exemplary embodiment, this functionality is connected to a controller such as a Bluetooth wireless controller.

[0070] In step 636, the control logic generates user input fields that allow the user to enter data for a particular sleeper. In an exemplary embodiment, the control logic 600 can tag the sleepers in the file with metadata that indicates user-generated or selected sleeper data.

[0071] In step 638, it is determined whether the control logic 600 has received a camera command.

[0072] In an exemplary embodiment, the client device may include a camera. If a camera command has not been received, control logic passes to step 644. If a camera command has been received, control logic passes to step 640.

[0073] At step 640, control logic instantiates client device camera functionality (e.g., permissions obtainable at step 510 of FIG. 5). In an exemplary embodiment, control logic 600 may capture one or more images via the client device camera. At step 642, control logic 600 associates the captured image with the selected rail tie. In an exemplary embodiment, control logic 600 may store the image in the tie file or as metadata about the particular rail tie attached to the tie file.

[0074] 6B after instantiation of the inspection process at step 602. As described above, at step 608, an inspection information table is generated, including multiple displays and fields. At step 648, control logic 600 displays the currently selected sleeper in the Sleeper field using the data contained in the information table. At step 648, control logic 600 displays the replaced sleeper in the Replacement field 650. Control logic 600 also displays the number of sleepers previously marked for replacement that were removed from that category in the "Removed" field, an "Added" field indicates the number of sleepers added to the total count of sleepers marked for replacement, a "Bunker" field displays the difference between the "Removed" and "Added" fields as an indication of the tie allotment for the category, and a Total Marks field may indicate the number of sleepers marked for replacement in the selected sleeper mark file.

[0075] The control logic 600 can automatically update the fields in response to user interaction with the sleeper grid. The control logic may include registers that can store increment and decrement counter values. If a sleeper previously marked for replacement is "flipped" in step 652, a "removed" field counter is incremented in step 654. In an exemplary embodiment, flipping the field indicates that the marked sleeper has been removed. This increment may cause or occur simultaneously with an increment of a "bunker" field counter in step 656 (indicating that the user has an "extra" sleeper because the previously marked sleeper is no longer marked for replacement, i.e., no new sleeper is needed and the new sleeper is available for use as a "bank").

[0076] In step 660, if a tie not previously marked for replacement is "flipped" so that it is marked for replacement, the "added" field is thereby incremented by control logic 600. Such an increment causes the "banker" field to be decremented by control logic in step 664, indicating that a new tie is being "withdrawn" from the "bank" to replace the tie currently marked for replacement. Increments and decrements in the inspection information table similarly affect the "total marking" field counter, causing a decrement in step 658 and an appropriate increment in step 666. In step 668, control logic takes no action. Control logic 600 then terminates or waits for new input and repeats the steps described above.

[0077] 7A and 7B illustrate railway sleeper management system components according to one or more exemplary embodiments. In an exemplary embodiment, a mobile application on a client device can request a connection with a railway sleeper management system server and display a dashboard. Referring to FIG. 7A, authentication is requested via a login screen 700 where a user can enter a user ID 702 and password 704. If authentication is successful, the mobile application can instantiate a dashboard system 706. For example, sections of track may be organized from files, with files listing sleeper conditions and corresponding metadata. Such track sections may vary in length based on the number of problems identified on a particular section of track, available equipment, location accessibility, and other relevant parameters. In an exemplary embodiment, the client device has locally available sleeper mark files and enables the dashboard system 706 to sort the sleeper mark files for increased accessibility. The sleeper mark files may be sorted using a linear search, bubble search, or fast search algorithm.

[0078] In an exemplary embodiment, the metadata in the sleeper mark file indicates the inspection status of a particular section of track. In other exemplary embodiments, the status can be identified as IN PROGRESS 708, COMPLETED 710, NEW, or other related indications. In other embodiments, the dashboard system 706 may receive instructions to instantiate subsystems via navigation links. Such links may include, among other links, dashboard 712, sleeper audit 714, sleeper mark 716, and settings 718. In other exemplary embodiments, sleepers that have been marked or audited can be marked by the dashboard system 706 on a client device.

[0079] 8A, 8B, and 8C illustrate railway sleeper management system components according to one or more exemplary embodiments. Sleeper mark navigation link 716 (shown in FIGS. 7A and 7B), for example, instantiates sleeper mark search system 800. In this exemplary embodiment, sleeper mark search system 800 may execute as a subsystem of dashboard system 706, with available local files (e.g., 810) remaining categorized into multiple categories 804, 806, and 808. Such sleeper mark search system subsystem 800 may generate file search requests that may be sent to a railway sleeper management system server (e.g., via a "+" user-input link in the upper right-hand corner). The server may request authentication, for example, through a login screen 812, and then request authorization from user 814 to allow the server (and / or a mobile application in operable communication with the server) to control certain aspects of the client device. Once authentication is complete and the necessary authorizations are granted, the server may provide sleeper mark files to the client device for download, as shown in FIGS. 9A-9D.

[0080] In an exemplary embodiment, a sleeper mark file may first be organized by subdivision (i.e., HASTINGS or ST CROIX), as seen at 900. The client is provided with a range of sleeper mark files organized, for example, by milepost range, as seen at 902 (e.g., a sleeper mark file titled -MP-173.0-202.0 would indicate that the sleeper mark file includes sleepers from milepost 173 to milepost 202 in a particular subdivision). Several other fields, such as plan number, track code, and line segment, are associated with a sleeper mark file range. Upon receiving a "download" or "download all" command, the client may retrieve a copy of the selected sleeper mark file from the server. Sleeper mark files, if locally available, are sorted, as seen at 904. A given sleeper mark file is then selected, prompting the generation of sleeper mark file details, as seen at 906. Such details may include division, subdivision, line segment, track type, milepost range, last inspection date, sleeper mark file status, and milepost direction. In an exemplary embodiment, the milepost direction field may be toggled by the user to select an increasing or decreasing direction 908. Once this is completed, the inspection process may be instantiated, for example, via an inspection command (e.g., top right corner of FIG. 9D).

[0081] 10A-10F illustrate railway sleeper management system components according to one or more exemplary embodiments. In an exemplary embodiment, when an inspection process is instantiated with a sleeper mark file, an inspection information table 1000 and a sleeper grid 1018 are generated. The inspection information table includes multiple fields, such as sleeper 1002, replacement 1004, addition 1006, removal 1008, milepost 1010, overall mark 1012, bunker 1014, and AURORA# 1016 (e.g., data previously included in the sleeper mark file in embodiments corresponding to inspections previously performed by Aurora® scanning technology). The inspection information table responds to interactions with the sleeper grid in accordance with the principles of the present disclosure. The sleeper grid 1018 can include multiple fields, such as: corresponds to the sleeper type (e.g., wood, concrete, metal, composite, etc.) (TIE TYPE 1020); refers to the sleeper's internal density score, e.g., as determined by an Aurora® scanner (INT 1022); corresponds to the sleeper identification number (TIE NO 1024); refers to the sleeper's curve category (CRVCAT 1026); corresponds to a combination of the INT and EXT scores (CMB 1028); and corresponds to the sleeper's external score (i.e., the score determined by inspecting the surface of the sleeper) (EXT 1030). In an exemplary embodiment, the sleeper type may display WT (for wood sleepers), CT (concrete sleepers), X (crossing ties), or T (turnout ties). In other exemplary embodiments, the CRVCAT may display T (tangent curve), L (weak curve), M (medium curve), or S (severe curve). In other exemplary embodiments, the INT, EXT, and CMB scores are displayed as decimal numbers from 1.0-4.0.

[0082] In an exemplary embodiment, the sleeper scores (ie, INT, EXT, and CMB) range from 1.0-4.0 as determined, for example, via an Aurora® scanner, according to the following chart: [Table 1]

[0083] In an exemplary embodiment, the tie grid 1018 is color-coded according to the chart above (i.e., ties with a CMB of 3.5-4.0 are highlighted in black, 2.7-3.4 are highlighted in red, 1.5-2.6 are highlighted in yellow, and 1.0-1.4 are highlighted in green). Additionally, ungraded ties (e.g., ties not scanned by the Aurora® scanner, i.e., ballast cover ties, ties covered with thick vegetation or mud, ties at turnouts and road crossings, ties at interior guardrail locations, etc.) are highlighted in blue to indicate that the INT, EXT, and CMB are not graded to -1.0. In another exemplary embodiment, a user command may be received to enter manual INT, EXT, and / or CMB for ungraded ties.

[0084] In an exemplary embodiment, the sleeper grid 1018 is manually navigated; for example, a user can "scroll" through the grid to locate a target sleeper. In another exemplary embodiment, a find sleeper command 1032 is received, which then prompts the user to enter a sleeper number 1034 to which the user wishes to navigate. After entering the sleeper number 1034, a find distance command is received, which can calculate and display the latitude and longitude of the specified sleeper based on the physical distance between the client device and the specified sleeper. After the sleeper number entry 1034 is received, a move to sleeper command 1038 is received, which automatically navigates the user to the specified sleeper in the sleeper grid. A particular sleeper may be selected while navigating the sleeper grid, and such selection may be emphasized, for example, via highlighting, as shown in FIG. 10D . In an embodiment, a sleeper marked for replacement may have a visual indicator 1042 located in the sleeper type column (e.g., here, square 1042). If a flip command 1040 is received for a sleeper that has been marked for replacement, the sleeper is accordingly marked. For example, a red X is shown in black box 1042 indicating that the sleeper is no longer marked for replacement. In another exemplary embodiment, if a flip command 1040 is received for a selected sleeper that is not marked for replacement, a visual indicator 1044 may be placed in the sleeper type column (e.g., here, circle 1044).

[0085] In another exemplary embodiment, a camera instruction 1048 is received that instantiates an image capture function on the client device in accordance with the principles of the present disclosure. In another exemplary embodiment, a comment instruction 1046 is received that causes the generation of a user input field 1050 in accordance with the principles of the present disclosure. In another exemplary embodiment, a mark complete instruction 1052 is received that updates the metadata of the sleeper mark file to indicate that the file is classified in the completed category in the dashboard system.

[0086] 11A and 11B, 1100 displays a dashboard system implementing the sleeper mark subsystem, where a sleeper mark file is categorized as completed. The system can determine that the file is completed and therefore can be retrieved by the server. To instantiate this process, after receiving an upload command 1102, a confirmation 1104 is performed. The uploaded railway sleeper mark file can then be accessed by other components of the railway sleeper management system, such as other clients.

[0087] The present disclosure achieves at least the following advantages:

[0088] Improve the organization and accessibility of sleeper inspections and sleeper changes through sleeper grids and other technological improvements.

[0089] Increase the efficiency of sleeper inspection and sleeper inspectors through an improved system for adding and modifying metadata tags on sleeper files.

[0090] Providing a platform to facilitate sleeper inspection and sleeper marking; and

[0091] It provides an accessible, centralized dataset for sleepers across rail infrastructure assets, enabling faster and more informed decision-making.

[0092] Those skilled in the art will readily appreciate that these advantages (and those indicated in the Abstract) and the objectives of the present system would not be possible without the particular combination of computer hardware and other structural components and mechanisms assembled into the inventive system and described herein. It will be further appreciated that a variety of programming tools known to those skilled in the art can be used to implement the functions and control operations described in the foregoing materials. Moreover, the particular choice of programming tools will be governed by the particular objectives and constraints placed on the implementation strategy chosen to realize the concepts described in this specification and the appended claims.

[0093] Nothing in this patent document should be construed as implying that any particular element, step, or function is essential or critical to inclusion in the scope of the claim. Furthermore, 35 U.S.C. §112(f) cannot be relied upon in connection with any appended claim or claim element unless the precise words "means for" or "step for" are clearly used in any particular claim following a participial division that identifies the function. Any reference to a "mechanism," "module," "apparatus," "unit," "component," "element," "member," "device," "machine," "system," "processor," "processing device," or "controller" in a claim is intended to be understood as referring to structures known to those skilled in the relevant art, as further modified or enhanced by the function of the claim itself, and is not intended to recite 35 U.S.C. §112(f).

[0094] The present disclosure may be embodied in other specific forms without departing from its spirit or essential characteristics. For example, each novel structure described herein may retain the basic configuration or structural relationships between each other, or may be modified to suit particular local variations or requirements while performing the same or similar functions described herein. Accordingly, the present embodiments are to be considered in all respects as illustrative and not restrictive. The scope of the present invention is therefore defined by the appended claims, not the foregoing description. Accordingly, all changes that come within the meaning and range of equivalency of the claims are intended to be embraced therein. Furthermore, individual elements of the claims may be non-intelligible or non-ordinary and conventional. Instead, the claims are directed to the non-traditional inventive concepts described in the specification.

Claims

1. 1. A method for managing ties in a railway system, comprising: generating and storing a plurality of sleeper mark files in a memory via a processor configured to execute machine-readable instructions; receiving, via said processor, an encrypted request over a network from a client device for a first sleeper mark file having railway sleeper data; providing the first sleeper mark file via the processor to the client device over the encrypted network; instantiating, via the processor, an inspection process using the railway sleeper data to generate an inspection information table and a sleeper grid, the inspection information table automatically updating in response to user interaction with the sleeper grid; Including, The method, wherein the sleeper grid includes metadata about a first sleeper.

2. The method of claim 1 further comprising the step of classifying the first sleeper mark file according to predetermined categories.

3. The method of claim 1 further comprising the step of selecting a first sleeper mark file.

4. 4. The method of claim 3, wherein the first sleeper mark file contains the sleepers for a predetermined section of railroad track.

5. 2. The method of claim 1, further comprising receiving an entry selecting the first sleeper and generating, via the processor, a graphic highlighting the selection.

6. The method of claim 1 further comprising the step of generating an indication when the first tie is marked for replacement.

7. The method of claim 1 , further comprising the step of modifying first sleeper metadata via the processor if a flip command is received.

8. The method of claim 1 , further comprising instantiating an image capture function of the client device and storing the captured image in first sleeper metadata.

9. The method of claim 1 , further comprising the steps of instantiating, via the processor, a user input field and storing the input data in first sleeper metadata.

10. The method of claim 1 further comprising determining railroad track characteristics and displaying the railroad track characteristics on the sleeper grid.

11. 1. A railway sleeper management system, comprising: a data storage device including a first database containing a plurality of sleeper mark files; a networked computer processor operatively connected to said data storage device over an encrypted network and capable of executing machine-readable instructions to perform program steps; Including, The program steps include: retrieving a sleeper mark file from said first database via said networked computer processor; instantiating, via the networked computer processor, an inspection process on the sleeper mark file to generate a sleeper grid and an inspection information table containing metadata about a plurality of sleepers, the inspection information table automatically updating in response to user interaction with the sleeper grid; editing said sleeper mark file via said networked computer processor; storing the edited sleeper mark file in the first database via the networked computer processor; Railway sleeper management system, including:

12. 12. The railway sleeper management system of claim 11, wherein said programming steps further include receiving an entry selecting a first sleeper in said sleeper grid and generating a graphic highlighting said selection via said networked computer processor.

13. 12. The railway sleeper management system of claim 11, wherein said programming steps further include the step of generating an indication if a sleeper in said sleeper grid is marked for replacement.

14. 12. The railway sleeper management system of claim 11, wherein said programming steps further include the step of modifying first sleeper metadata via said networked computer processor if a flip command is received.

15. 12. The railway sleeper management system of claim 11, wherein said programming steps further include the steps of instantiating an image capture function on a client and storing a captured image in first sleeper metadata.

16. 12. The railway sleeper management system of claim 11, wherein said programming steps further include the steps of instantiating user input fields via said networked computer processor and storing input data in first sleeper metadata.

17. 12. The railway sleeper management system of claim 11, wherein said programming steps further include determining railroad track characteristics and displaying said railroad track characteristics on said sleeper grid.

Images