Systems and methods for inspecting strategic orbits and maintenance plans.

Abstract

A system and method for Strategic Track and Maintenance Planning (STAMP) is presented that can provide a coordinated and adaptive infrastructure configured to facilitate railroad asset management and financial planning. The system can provide railroad asset inspectors with relevant data for assigned inspection segments. A location-based feature can obtain the exact location of the equipment and provide step-by-step input prompting based on the equipment location to provide only the data required for the inspection of a particular railroad asset. The system provides adaptive thresholding of asset-related criteria to determine if and when asset maintenance should occur. The system can obtain inspection data for one or more railroad assets, apply data optimization algorithms to the inspection data, analyze railroad asset related data (including historical data), and generate an optimized financial plan with schedules for railroad asset maintenance and replacement.

Description

Technical Field

[0001] The present disclosure relates generally to the management of railway assets, and more specifically, to systems and methods for strategic track and maintenance planning asset management for railway assets disposed throughout a railway system infrastructure.

Background Art

[0002] In general, maintenance of railway assets is a cumbersome task that requires documentation of manual inspections of railway assets. Inspections of railway assets are typically fraught with error-prone data capture, which results in wasted resources due to under-ordering of parts and materials that consequently leads to duplicate work to cover over-ordering or under-ordering of parts and materials.

[0003] Generation of inspections also requires experience to identify assets and understand the terminology associated with those assets. For example, railway tracks can be straight or curved, can have two curved rails, one of which is a high rail on the rail while the other is a low rail. Railway tracks also include many components with corresponding track characteristics. Proper inspection can require detailed inspection and documentation of many components and conditions. Safety can be an issue if one component or condition is missed or incorrectly characterized.

Summary of the Invention

Problem to be Solved by the Invention

[0004] While organizational methods and specialized equipment are useful in collecting and managing information on railway assets, inspection processes remain manual and outdated. Railway personnel are still required to inspect these assets and make final decisions on whether or not they need to be replaced. Such personnel may misplace notes, improperly document measurements, and may require regular training. Generating financial plans to allocate funds for the maintenance of railway assets can be nearly impossible if based on inaccurate information. And decisions on whether or not to replace assets can become subjective if they lack any consistency. [Means for solving the problem]

[0005] This disclosure realizes the technical merits of a system and method for Strategic Track and Maintenance Planning (STAMP) that can provide an organized and adaptive infrastructure configured to facilitate railway asset management and financial planning. The system enables the logging of adaptive inspections for assets being inspected (e.g., rails, sleepers, ballast, switches, forks, etc.). The system can guide the user step by step to conduct detailed inspections of various railway assets to capture a list of data points characterizing the assets, as well as to analyze the data points to assess whether the assets should be replaced and considered in financial planning. The system can utilize GPS coordinates from the client / device in the field to retrieve asset information from a GIS database, parts database, price database, or other appropriate database. The system also provides the acquisition and uploading of photographs of assets for specific inspections. The inspections can be used to directly generate financial plans and to provide a customizable user interface to virtually identify, characterize, and process information related to any railway asset.

[0006] This disclosure provides railway asset inspectors with a system configured to generate step-by-step prompts based on data received to provide appropriate guidance for assigned asset inspections, and not only solves the technical problem of generating financial plans using at least partially invalid or incomplete inspection data. This disclosure surpasses mere computerized paper and pencil implementations by providing step-by-step input prompt processing based on the location of equipment, by providing adaptive thresholding of criteria related to the equipment to determine whether and when asset maintenance should occur, by at least incorporating GPS functionality that can obtain the precise location of the equipment and provide only the data required for that particular inspection, and by providing users with only the relevant information required for that particular inspection, so that they can perform their inspections relatively quickly, relatively clearly, and relatively concisely without erroneous data collection.

[0007] This disclosure improves the performance and functionality of the system itself by analyzing data related to rail assets (including historical data) by acquiring inspection data for one or more rail assets, by providing step-by-step inspection prompts to request only relevant inspection data, by applying data optimization algorithms to prevent unnecessary storage of irrelevant data, and by collecting optimized financial plans and schedules for the repair, maintenance, and replacement of rail assets. In contrast, conventional systems simply rely on data that is often incomplete, resulting in erroneous, slow-generating, and haphazard financial plans that add to the burden on an already overused system. The STAMP system can not only determine when something needs to be replaced or maintained, but also determine the optimal schedule.

[0008] The STAMP system can include a client running an inspection application, a WebUI, and a backend (server-side) system. In summary, the process flow can be initiated on the inspection application, which can be displayed on a client (e.g., a mobile device) operable by the user inspecting a section of track or other railway assets. Using track inspection as an example, the user can generate track-side inspections with or without a connection. The user / client's precise location (e.g., latitude and longitude coordinates) can be determined using a GPS communication device installed in the client device or by manual input of latitude and longitude coordinates. The STAMP system can send the client a map with railway line segment mileposts to build the inspection workflow. Location data can be captured on the track side, along with defect data, as well as asset data for track types (e.g., main line, main line 1, main line 2, main line 3, turnouts, switches, bridges, crossovers, etc.). In one illustrative embodiment, a user can save inspections for one or more sections of a track on a client without a connection, and once a connection is obtained, all saved inspections can be uploaded from the inspection app and further processed by the backend system. The STAMP system can also provide adaptive content based on user input, historical data, or other relevant data.

[0009] The data acquired during the orbital inspection can be viewed via the backend, which may include a WebUI (User Interface System). The backend system can store and display all inspections received from the inspection application. If any errors or mistakes exist in the inspection, the inspection can be reviewed and corrected in the WebUI.

[0010] The backend can dynamically capture inspections entered by users into the inspection app. All plans, materials, and parts can be automatically generated by the backend via the WebUI with minimal user interaction. In the inspection app or WebUI, users can verify that default materials or parts are correct, make any necessary changes to materials or parts, generate a financial plan, and then submit the plan for approval. Once approved, the financial plan can be sent to a downstream estimation system and receive a detailed estimate, which will result in the generation of authorization for expenditures as part of the financial plan. Advantageously, this disclosure improves management processes by implementing algorithms that generate track analysis related to rail assets and maintenance, by capturing relatively detailed inspection records, and by generating relatively more data to analyze when to replace financial assets to streamline financial management and financial plan generation. Thus, this disclosure can provide benefits such as reduced asset inspection errors, optimized maintenance scheduling, and cost reduction due to maintenance planning using adaptive thresholds, reduction of unnecessary processing, and network utilization.

[0011] One object of the present invention is to provide a system for generating strategic track and maintenance plan inspection records for railway assets. A further object of the present invention is to provide a method for generating strategic track and maintenance plan inspection records for railway assets. These and other objects are provided by at least the following embodiments.

[0012] In one embodiment, a system for generating strategic track and maintenance plan inspection records for railway assets may include a memory having a first database having a plurality of inspection records, thresholds, and specifications relating to an asset, and a network-connected computer processor operably coupled to the memory and capable of executing machine-readable instructions to execute program steps, the program steps being: receiving an asset type and an asset description; initiating an asset inspection via the processor, at least in part, based on the asset type or asset description; receiving a client location; acquiring asset data via a server operably coupled to an encrypted network, having fields relating to one or more inspections relating to the location, asset type, or asset description; and performing steps via the processor based on the acquired asset data. The process may include steps of generating an inspection prompt for each step, displaying the first step-by-step inspection prompt on the client, determining whether any historical data for the fields related to each inspection is stored in the first database, displaying an automatically entered response in the response field on the client if historical data for the fields related to the inspection exists, receiving a response to an inspection prompt or a validation of an automatically entered response, analyzing the response or validation to generate and display one or more customized inspection prompts, receiving a customized response to a customized inspection prompt, and generating a strategic track and maintenance plan inspection record for a railway asset, including the response and the customized response, via a processor. In this case, the asset type is rail, ballast, panel, sleeper, switch, or facility. In this case, the customized inspection prompt is displayed only after the response has been received. In this case, the client's location determines the type of inspection prompt to send to the client. In this case, the client's asset type determines the type of inspection prompt to send to the client.In this case, the client's asset description determines the type of inspection prompt to send to the client. In this case, the response or customized response is stored in one or more fields, parameters, characteristics, or metadata in the database. In this case, memory can be operably coupled to the client or server. In this case, the client's location can be received via an input object or a GPS device operably coupled to the client. In this case, the automatically entered response may be a historical value obtained from the first database.

[0013] In another embodiment, a method for generating strategic track and maintenance plan inspection records for rail assets may include the steps of: receiving an asset type and asset description; initiating an asset inspection via a processor based at least in part on the asset type or asset description; receiving a client location; obtaining asset data via a server operably connected to an encrypted network, having fields relating to one or more inspections relating to the location, asset type, or asset description; generating step-by-step inspection prompts via a processor based on the obtained asset data; displaying a first step-by-step inspection prompt on the client; determining whether any historical data for each inspection-related field is stored in a first database; displaying an automatically entered response in the response field on the client if historical data exists for the inspection-related field; receiving a response to an inspection prompt or a validation of an automatically entered response; analyzing the response or validation to generate and display one or more customized inspection prompts; receiving a customized response to a customized inspection prompt; and generating a strategic track and maintenance plan inspection record for rail assets, including the responses and customized responses, via a processor. In this case, the asset type is rail, ballast, panel, sleeper, switch, or facility. In this case, the customized inspection prompt is displayed only after the response has been received. In this case, the client's location determines the type of inspection prompt to send to the client. In this case, the client's asset type determines the type of inspection prompt to send to the client. In this case, the client's asset description determines the type of inspection prompt to send to the client. In this case, the response or customized response is stored in one or more fields, parameters, characteristics, or metadata in the database. In this case, memory can be operably coupled to the client or server.In this case, the client's location can be received via an input object or a GPS device operably coupled to the client. In this case, the automatically entered response may be a historical value obtained from the first database.

[0014] This disclosure can be easily understood by the following detailed description, which is provided in conjunction with the accompanying drawings illustrating the principles of this disclosure. The drawings illustrate the design and utility of one or more exemplary embodiments of this disclosure, where identical elements are referenced by the same reference numeral or symbol. The objects and elements in the drawings are not necessarily drawn to exact scale, proportion, or exact positional relationships. Instead, the emphasis is on illustrating the principles of this disclosure. [Brief explanation of the drawing]

[0015] [Figure 1] A schematic diagram of a strategic trajectory and maintenance planning system according to one or more exemplary embodiments of the present disclosure is shown. [Figure 2] The following are block diagrams of strategic trajectory and maintenance planning systems according to one or more exemplary embodiments of the present disclosure. [Figure 3] A flowchart illustrating the strategic trajectory and maintenance planning process flow control logic according to one or more exemplary embodiments of the present disclosure is provided. [Figure 4] A flowchart illustrating the linear flow rail inspection generation control logic according to one or more exemplary embodiments of the present disclosure is shown. [Figure 5] A flowchart illustrating the curved flow rail inspection generation control logic according to one or more exemplary embodiments of the present disclosure is shown. [Figure 6] A flowchart illustrating rail inspection control logic according to one or more exemplary embodiments of the present disclosure is shown. [Figure 7] A flowchart illustrating the body flow rail inspection control logic according to one or more exemplary embodiments of the present disclosure is shown. [Figure 8] Fig. 1 is a flowchart illustrating rail inspection completion control logic according to one or more exemplary embodiments of the present disclosure. [Figure 9] Fig. 1 is a flowchart illustrating rail inspection completion control logic according to one or more exemplary embodiments of the present disclosure. [Figure 10] Fig. 1 illustrates an exemplary embodiment of a STAMP inspection system interface according to one or more exemplary embodiments of the present disclosure. [Figure 11A] Fig. 1 illustrates an exemplary embodiment of an inspection generation interface according to one or more exemplary embodiments of the present disclosure. [Figure 11B] Fig. 1 illustrates an exemplary embodiment of an inspection generation interface according to one or more exemplary embodiments of the present disclosure. [Figure 11C] Fig. 1 illustrates an exemplary embodiment of an inspection generation interface according to one or more exemplary embodiments of the present disclosure. [Figure 11D] Fig. 1 illustrates an exemplary embodiment of an inspection generation interface according to one or more exemplary embodiments of the present disclosure. [Figure 11E] Fig. 1 illustrates an exemplary embodiment of an inspection generation interface according to one or more exemplary embodiments of the present disclosure. [Figure 12A] Fig. 1 illustrates an exemplary embodiment of an inspection workflow interface according to one or more exemplary embodiments of the present disclosure. [Figure 12B] Fig. 1 illustrates an exemplary embodiment of an inspection workflow interface according to one or more exemplary embodiments of the present disclosure. [Figure 13A] Fig. 1 illustrates an exemplary embodiment of an annotated body interface according to one or more exemplary embodiments of the present disclosure. [Figure 13B] Fig. 1 illustrates an exemplary embodiment of an annotated body interface according to one or more exemplary embodiments of the present disclosure. [Figure 14A] Fig. 1 illustrates an exemplary embodiment of an inspection completion interface according to one or more exemplary embodiments of the present disclosure. [Figure 14B]An illustrative embodiment of an inspection termination interface according to one or more exemplary embodiments of the present disclosure is shown. [Figure 14C] An illustrative embodiment of an inspection termination interface according to one or more exemplary embodiments of the present disclosure is shown. [Figure 14D] An illustrative embodiment of an inspection termination interface according to one or more exemplary embodiments of the present disclosure is shown. [Figure 14E] An illustrative embodiment of an inspection termination interface according to one or more exemplary embodiments of the present disclosure is shown. [Figure 14F] An illustrative embodiment of an inspection termination interface according to one or more exemplary embodiments of the present disclosure is shown. [Figure 14G] An illustrative embodiment of an inspection termination interface according to one or more exemplary embodiments of the present disclosure is shown. [Modes for carrying out the invention]

[0016] The following description and preferred versions of the disclosure presented in its various features and advantageous details will be described in more detail, with reference to the non-limiting examples included in the accompanying drawings and detailed in the subsequent 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 the ways in which this disclosure may be implemented and carried out. Accordingly, these examples should not be construed as limiting the scope of the claims.

[0017] Figure 1 shows a schematic diagram of a Strategic Track and Maintenance Planning (STAMP) system 100 according to one or more exemplary embodiments of the present disclosure. The STAMP system 100 may include one or more STAMP servers 102 having one or more processors 104, memory 130, and other related modules, in addition to machine-readable instructions 106 including an inspection start module 108, a geolocation module 110, an asset identification module 112, an inspection generation module 114, a plan initialization module 116, an asset association module 118, a plan generation module 120, a status module 122, a selection module 124, and an authentication module 126. The servers 102 can be operably coupled to one or more clients via a network 140. Clients may be physical devices (e.g., a mobile phone 150, a laptop 152, a tablet 154, a desktop computer 156, a wearable device, or other suitable device), a program, or an application. In another exemplary embodiment, the client may include a mobile phone 150 having a mobile application configured to communicate with a server 102 over network 140.

[0018] The aforementioned system components (e.g., one or more servers 102 and one or more clients 150, 152, 154, 156, etc.) can be connected to each other via network 140 so that data can be transmitted. Network 140 may be the Internet, an intranet, or other suitable network. Data transmission may be encrypted or decrypted over a VPN tunnel or other suitable means of communication. Network 140 may be a WAN, LAN, PAN, or other suitable network type. Network communication between clients, servers 102, or any other system components may be encrypted using PGP®, Blowfish, Twofish, AES, 3DES, HTTPS, or other suitable encryption. System 100 may be configured to provide communication via various systems, components, and modules disclosed herein via application programming interfaces (APIs), PCI, PCI-Express®, ANSI-X12, Ethernet, Wi-Fi®, Bluetooth®, or other suitable communication protocols or media. In addition, third-party systems and databases can also be flexibly connected to the system components via the network 140.

[0019] Data transmitted between components of system 100 (e.g., server 102 and client) may include any format, including JSON (JavaScript® Object Notation), TCP / IP, XML, HTML, ASCII, SMS, CSV, REST (Representational State Transfer), or other appropriate formats. Data transmission may include, or may be encapsulated or packaged in any appropriate format having these elements.

[0020] One or more servers 102 can be implemented in hardware, software, or an appropriate combination of hardware and software, and may have one or more software systems running on one or more servers having one or more processors 104 having access to memory 130. One or more servers 102 may include electronic storage, one or more processors, and / or other components. One or more servers 102 may include communication lines, connections, and / or ports to enable the exchange of information over network 140 and / or other computing platforms. One or more servers 102 may also include multiple hardware, software, and / or firmware components that cooperate to provide the functions attributed to one or more servers 102 herein. For example, one or more servers 102 can be implemented by a cloud of computing platforms that cooperate as one or more servers 102, including SaaS (Software-as-a-Service) and PaaS (Platform-as-a-Service) functions. In addition, one or more servers 102 may also include memory 130.

[0021] Memory 130 may have electronic storage which may include non-temporary storage media for electronically storing information. The electronic storage media of the electronic storage may include one or both of the following: system storage (e.g., substantially non-removable) which may be provided integrally with one or more servers 102, and / or removable storage which may be removablely connected to one or more servers 102 via, for example, ports (e.g., USB ports, FireWire® ports, etc.) or drives (e.g., disk drives, etc.). The electronic storage may include one or more optically readable storage media (e.g., optical discs, etc.), magnetically readable storage media (e.g., magnetic tapes, magnetic hard drives, floppy disks, etc.), charge-based storage media (e.g., EEPROM, RAM, etc.), semiconductor storage media (e.g., flash drives, etc.), and / or other electronically readable storage media. The electronic storage may include one or more virtual storage resources (e.g., cloud storage, virtual private networks, and / or other virtual storage resources). The electronic storage may include a database or a public or private distributed ledger (e.g., a blockchain). The electronic storage may store machine-readable instructions 106, software algorithms, control logic, data generated by one or more processors, data received from one or more servers, data received from one or more computing platforms, and / or other data that may enable one or more servers to function as described herein. The electronic storage may also include a third-party database accessible via the network 140.

[0022] One or more processors 104 can be configured to provide data processing capabilities within one or more servers 102. Thus, one or more processors 104 may include one or more digital processors, analog processors, digital circuits designed to process information, analog circuits designed to process information, state machines, and / or other mechanisms for electronically processing information, such as FPGAs or ASICs. One or more processors 104 may be a single entity or may comprise multiple processing units. These processing units may be physically located within the same device, or one or more processors 104 may represent the processing capabilities of multiple devices or software functions operating independently or in coordination.

[0023] One or more processors 104 can be configured to execute machine-readable instructions 106 or machine learning modules via any combination of software, hardware, firmware, software, hardware, and / or firmware, and / or other mechanisms for constituting processing power on one or more processors 104. As used herein, the term “machine-readable instructions” may mean any component or set of components that perform the function attributed to the machine-readable instruction component 106. This may include one or more physical processors 104, processor-readable instructions, circuits, hardware, storage media, or any other components in the execution of processor-readable instructions.

[0024] One or more servers 102 can be configured to have machine-readable instructions having one or more functional modules. The machine-readable instructions 106 can be implemented on one or more servers 102 having one or more processors 104 having access to memory 130. The machine-readable instructions 106 can be a machine cluster that may include a single networked node or a distributed architecture of multiple networked nodes. The machine-readable instructions 106 may include control logic for implementing various functions, as will be described in more detail later. The machine-readable instructions 106 may include specific functions associated with the STAMP system 100. In addition, the machine-readable instructions 106 may also include smart contracts or multi-signature contracts that can process, read, and write data to a database, distributed ledger, or blockchain.

[0025] Figure 2 shows a schematic diagram of a strategic track and maintenance planning system 200 according to one or more exemplary embodiments of the present disclosure. The STAMP system 200 may include a STAMP inspection system 202, a STAMP dashboard system 204, and a STAMP planning system 206. While certain exemplary embodiments may target rail assets, the STAMP system 200 can be used to inspect and plan maintenance financing for any type of rail assets, including rails, ballast, panels, sleepers, switches, fixtures, or any suitable assets.

[0026] In one exemplary embodiment, the STAMP dashboard system 204 may include a status module 122, a selection module 124, and an authentication module 126. The status module 122, the selection module 124, and the authentication module 126 may implement one or more algorithms for facilitating inspection and maintenance planning of rail assets, including status, selection, and authentication algorithms. The algorithms and their associated thresholds and / or signatures may be programmable to suit specific rail assets, applications, functions, facilities, or other requirements. The STAMP dashboard system 204 may be configured to send and receive messages relating to inspection, financial planning, or other appropriate activities between a client or server. In another exemplary embodiment, the STAMP dashboard system 204 may generate one or more elements for display on a user device. The elements may provide further information to the user relating to the inspection or financial planning. For example, alerts may be generated by the STAMP dashboard system 204 and displayed on the client to notify of counts, completions, submissions, requests, or other appropriate information. In addition, system symbols can be displayed on the client to indicate the status of tasks, inspections, or plans.

[0027] The status module 122 can enumerate data stored on the client or server for a specific user. In another exemplary embodiment, the status module 122 can notify the status of one or more entries stored on the client or server for a specific user. For example, inspections stored on the client or server can be displayed on the client and labeled on the client's dashboard page by their status (e.g., "In Progress," "Completed," or "To Be Completed"). In another exemplary embodiment, the status module 122 can display notifications on the client about status changes or new requirements (e.g., new or repeated inspections, funding plan generation, approval requests, change requests, etc.).

[0028] The selection module 124 can initiate an action. For example, the action may include selecting an asset type, generating an inspection, downloading a plan, searching for an inspection, changing settings, or other appropriate actions. In another exemplary embodiment, the selection module 124 can upload or download an inspection to or from a server. In another exemplary embodiment, the selection module 124 can initiate an action by calling or instantiating one or more modules on a server, WebUI, or client. In another exemplary embodiment, one or more inspections can be transferred to or received between a client and the inspection initiation module 108 over an encrypted network 140.

[0029] The authentication module 126 can authenticate a user on a client such as a mobile phone 150, laptop 152, tablet 154, wearable device, or other appropriate device. In one exemplary embodiment, the authentication module 126 can authenticate a user or session using a username, password, authentication token, biometrics, or other appropriate attributes received from the client. In another exemplary embodiment, the authentication module 126 may generate an authentication token for a particular user, session, or request. In one exemplary embodiment, the authentication module 126 can generate an authentication token using user data stored within the client. For example, a user can access the client and / or STAMP system by providing valid credentials, including a username and password, biometrics, multi-factor authentication, or other appropriate credentials, via a login page or screen, and such credentials, along with user information such as name, username, employee number, etc., can be stored within the client or server. In another exemplary embodiment, the authentication module 126 can process at least a portion of the credentials and / or user information to generate an authentication token. For example, an authentication token can be generated as a JWT (JSON Web Token) by means of a dongle or key fob capable of periodically generating new authentication tokens according to a known algorithm, by using an authenticator app on the client or sent on demand via SMS, by hashing at least a portion of the login credentials, or by any other suitable methodology. In another exemplary embodiment, the authentication token may allow single sign-on authentication from the server and / or client to memory.

[0030] In one exemplary embodiment, the STAMP inspection system 202 may include an inspection initialization module 108, a geolocation module 110, an asset identification module 112, and an inspection generation module 114. The inspection initialization module 108, the geolocation module 110, the asset identification module 112, and the inspection generation module 114 may implement one or more algorithms to facilitate inspections of rail assets and to capture data related to inspections, including inspection generation, termination, and completion algorithms. The algorithms and their associated thresholds and / or signatures may be programmable to suit specific rail assets, uses, functions, facilities, or other requirements. The STAMP inspection system 202 may be configured to send and receive messages related to inspections or other appropriate activities between a client or server. In another exemplary embodiment, the STAMP inspection system 202 may generate one or more elements for display on a user device. The elements may provide further information to users involved in the inspection. For example, alerts can be generated by the STAMP inspection system 202 and displayed on the client to notify inspection count, inspection completion, inspection submission, inspection request, or other appropriate information. In addition, system symbols can be displayed on the client to notify the inspection status.

[0031] In one exemplary embodiment, the inspection initialization module 108 can generate a user interface that is displayable on a client for inputting, receiving, and / or selecting one or more attributes related to railway asset inspection. In another exemplary embodiment, a client can receive information from the inspection initialization module 108 over an encrypted network. In another exemplary embodiment, the inspection initialization module 108 can generate data, images, or graphics for display on any client. The inspection initialization module 108 can service web pages or data via one or more servers 102, including via HTTP, HTTPS, FTP, VPN, JavaScript, API, HTML, AJAX, SOAP, RESTful services, or other appropriate means. The inspection initialization module 108 can also provide a user interface for modifying the administrative parts of the STAMP inspection system 202, including algorithms and thresholds. The STAMP system 200 can utilize the inspection initialization module 108 to provide a user interface for generating user reports and observing analyses related to any element of the STAMP system 102.

[0032] In one exemplary embodiment, the geolocation module 110 can receive the client's location from the client. In another exemplary embodiment, the client may include a GPS communicator to receive GPS signals and determine the client's location from the received GPS signals. In another exemplary embodiment, the client may triangulate its location using two or more received signals via a communicator operably coupled or embedded within the mobile device. In another exemplary embodiment, the client may determine its location using a Wi-Fi positioning system that can utilize the characteristics of nearby Wi-Fi hotspots and other radio access points to find where the client is located. The client location may be transmitted to the geolocation module 110 over an encrypted network.

[0033] For example, during rail inspection, the user can begin inspecting a rail segment by starting at a starting point on the first end of the rail segment, and can capture a series of data points related to the segment. To begin logging data related to the inspection, the user's location must first be determined. In one exemplary embodiment, the user's location can be identified by receiving one or more characteristics of the user's location (e.g., line segment, milepost location, etc.) or by utilizing the client's GPS functionality. In another exemplary embodiment, once the GPS location (latitude and / or longitude coordinates) is determined, the geolocation information module 110 can determine one or more characteristics of the user's location (e.g., line segment, milepost location, curve-high rail or low rail, etc.). In another exemplary embodiment, the GPS coordinates can be used to determine line segments and mileposts by correlating the GPS coordinates with those stored in a geographic information system (GIS) database. For example, the GIS database may include one or more rail segment characteristics associated with specific latitude and longitude coordinates.

[0034] In one exemplary embodiment, the asset identification module 112 may utilize the user's location, asset type, or asset description to determine the type of prompt to send to the client. For example, the prompt may include one or more criteria. In another exemplary embodiment, once the location is determined, the asset identification module 112 may automatically determine the asset parts for inspection. In another exemplary embodiment, the criteria may be determined based on parts for a specific rail segment, room, floor, component, or other related element. For example, different rail sizes may be determined by the system based on the degree of curvature. The STAMP system 200 can retrieve parts and criteria stored in a database operably coupled to the server. Criteria may include rail size, rail material, sleeper type, connection type, room dimensions, power rating, or temperature, in addition to other related criteria.

[0035] In one exemplary embodiment, the inspection generation module 114 can generate, capture, and complete inspections. In one exemplary embodiment, the inspection may be based on one or more models relating to an asset type. The models may include asset characteristics, criteria, standards, and / or requirements for that asset. For example, a rail model may include criteria such as track shape, track number, main line, non-main line, and sidings, in addition to others. In another exemplary embodiment, the model may consist of various parts for that model. For example, the parts may include rails, transitions, fasteners, anchors, curve blocks, and other related parts.

[0036] In another exemplary embodiment, the inspection generation module 114 can generate a set of data fields and / or questions at a specific location (e.g., main track, curve, straight, both, etc.) to customize the actual inspection of the rail segment where the user is positioned based on the model and / or its associated parts. Advantageously, the data fields and / or questions at a specific location can be supplied to the user after entries / requests for the data fields / questions have been received from the user and analyzed by the inspection generation module 114. In another exemplary embodiment, the inspection generation module 114 can retrieve a model stored in a database having criteria for the associated parts and their models. Once the associated parts and criteria have been received, the inspection generation module 114 can display the criteria as part of an adaptive inspection process for the specific rail segment. The parts and criteria can also be linked to location and timeframe to potentially provide relatively large-scale inspection customization.

[0037] The inspection generation module 114 can generate the next input request based on a previous response. In another exemplary embodiment, the inspection generation module 114 can use criteria obtained by criteria for a specific part to generate the next inspection question. This offers the benefit of customizing the input request to ask only relevant questions while streamlining the user interface. For example, in the case of rail inspection, the types of rail information to be captured by the inspection generation module 114 may include, in addition to others, rail measurements, rail manufacturer, year of installation, and wear measurements (e.g., gauge, face, and vertical wear). In another exemplary embodiment, the inspection generation module 114 can generate adaptive inspection fields based on a specific rail segment or one or more rail characteristics being inspected. In another exemplary embodiment, different rail criteria may exist based on the characteristics of a specific rail segment being inspected. For example, in addition to other relevant criteria, the degree of curvature, the tonnage traveled on the segment, etc., may cause different input fields to be shown for a particular inspection. The inspection generation module 114 can display these fields on the client along with user input elements such as radio buttons, text fields, checkboxes, and other appropriate input elements. In another exemplary embodiment, the inspection generation module 114 may pre-populate one or more values ​​for rail segments in a user input element based on history or other relevant stored data.

[0038] The inspection generation module 114 does not merely enumerate general part inspection questions that may or may not fit most parts. Instead, the questions can be customized for the specific part being inspected. When an answer is entered into the inspection generation module 114 as either "yes" or "no," or "relatively high" or "relatively low," the inspection generation module 114 can generate the most appropriate next question based on the previous answer to generate the inspection flow. In another exemplary embodiment, the field may only accept specific types of data to help prevent user data entry errors. In another exemplary embodiment, the inspection flow of the inspection generation module 114 can guide the user to inspect assets according to standards or policies and can capture all necessary data to analyze the inspection while providing precise locations for inspection with minimal user background knowledge. In another exemplary embodiment, once the inspection workflow is complete for the inspection, the inspection generation module 114 can save the inspection record to the client and / or database. In another exemplary embodiment, the test generation module 114 may prompt the user to upload a test and facilitate the transfer of the test to STAMP's WebUI or database.

[0039] In one exemplary embodiment, the STAMP planning system 206 may include a planning initialization module 116, an asset association module 118, and a planning generation module 120. The planning initialization module 116, the asset association module 118, and the planning generation module 120 may implement one or more algorithms to facilitate maintenance planning for rail assets and to capture data related to planning, including maintenance plan generation, completion, and status algorithms. The algorithms and their associated thresholds and / or signatures may be programmable to suit specific rail assets, uses, functions, facilities, or other requirements. The STAMP planning system 206 may be configured to send and receive messages related to financial planning or other appropriate activities between a client or server. In another exemplary embodiment, the STAMP planning system 206 may generate one or more elements for display on a user device. The elements may provide further information to users involved in financial planning. For example, alerts may be generated by the STAMP inspection system 202 and displayed on the client to notify of planning counts, planning completion, planning submissions, planning requests, or other appropriate information. In addition, system symbols can be displayed on the client to notify users of the planning status.

[0040] In one exemplary embodiment, the plan initialization module 116 may prompt the user to choose whether a financial plan should be generated and / or whether an inspection record should be generated. In another exemplary embodiment, the plan initialization module 116 may process criteria as the user performs an inspection. For example, if the rail wear measurement is only 1 / 4'' and 5 / 8'' of wear is required to generate a financial plan for the inspection, it is clear that the measured wear will not satisfy the financial plan requirement, and therefore, instead of generating a financial plan, the inspection can be marked as complete and uploaded to the server without selecting to generate a plan. In one exemplary embodiment, if a plan is not generated for the inspection, the inspection record is stored in the database. In another exemplary embodiment, if a plan is generated, the inspection record may be stored in the database, but the plan initialization module 116 may generate a specific plan number and enter that inspection record in a separate section, in which case the inspection may be stored on the client or server. In another exemplary embodiment, when only inspections are generated, the relevant inspection data can be stored in the inspection log. In another exemplary embodiment, specific information based on all the input data can be obtained by the plan initialization module 116 and entered into the financial plan. For example, all logic can be processed in the background to generate a baseline for the relevant financial plan. The user can then review the financial plan to ensure accuracy and verify that the plan is correct, and can input any missing data and review the data.

[0041] In another exemplary embodiment, the planning initialization module 116 can retrieve relevant stored thresholds and associate them with rail assets. In another exemplary embodiment, the planning initialization module 116 can utilize predictive modeling when one or more rail criteria are provided to determine whether a financial plan should be generated. For example, when determining whether to generate a financial plan, the planning initialization module 116 may consider the tonnage on the track segment and the duration that the track has been in place. In one exemplary embodiment, the planning initialization module 116 can guide the user to inspect a particular rail segment and determine a scheduling program. As a result, the STAMP system can provide predictive modeling to determine which rail assets need to be replaced and when.

[0042] In one illustrative embodiment, the asset association module 118 can adaptively correlate criteria to select materials for a particular part or model. For example, the asset association module 118 can automatically determine rail size based on the degree of the curve. Criteria for a particular model stored in the database may include one or more thresholds that can determine the materials to be used and whether further components should be included. This adaptive thresholding can modify one or more characteristics of the financial plan. In addition, the thresholds are adaptive because the thresholding can change based on historical data, inspection data, season, temperature, cost, budget, or other relevant data. For example, if the asset association module 118 identifies a high-grade curve exceeding a specific threshold of millions of gross tons (MGT) of traffic, the module 118 can select rail size 41136 to suit that scenario, given that specific thresholds and associated material assignments are provided in the database. One or more thresholds can be established for one or more materials so that a first rail material can be selected for curves of first to second curvature, and a second rail material can be selected for curves of second to third curvature. The materials can also be modified based on a second selection criterion, such as tonnage traveled on the track or other indicators of rail wear. The asset association module 118 can set the rail size to 41136 so that a financial plan is directed and constructed with 141 pounds of rail. In another exemplary embodiment, the asset association module 118 can provide adaptive thresholding of asset-related criteria based on changes in use, wear, weather, or other relevant information. In another exemplary embodiment, the asset association module 118 can store the adapted thresholds in a database for a specific model.

[0043] The asset association module 118 can correlate actual measurement data from inspections with calculated prediction data generated by the STAMP system to determine whether one or more thresholds should be met. Adaptive thresholding can result in cost savings by reducing the use of relatively expensive materials that are required for specific applications but no longer required for certain line segments. The asset association module 118 can automatically refer to the MGT table to understand the condition of rail segments based on different scenarios for criteria related to stored assets, such as rail size and whether insulating joints are required. In another exemplary embodiment, data captured by the user during inspection can be used as training data for a machine learning algorithm for rail segments. The machine learning algorithm can analyze the captured data along with any historical data and determine whether a financial plan should be generated. In another exemplary embodiment, the system can generate a financial plan or override the user's plan generation decision.

[0044] In one exemplary embodiment, the plan generation module 120 can generate a plan from current or stored inspection records. In another exemplary embodiment, the plan generation module 120 can generate a unique plan ID, plan version, and plan status, and can place the plan in draft. In another exemplary embodiment, the plan generation module 120 can import a budget year identified by the user and can associate department codes and project types based on the input information. In another exemplary embodiment, the plan generation module 120 can associate project subtypes (e.g., rail relays on timber or concrete with relatively high or relatively low rates). In yet another exemplary embodiment, the plan generation module 120 can import certain information so that the information can be used to generate a funding code. In another exemplary embodiment, the user can select a funding code based on the provided information. In another exemplary embodiment, the plan generation module 120 can import at least a portion of location information. Such imported location information may include milepost locations, track numbers, and latitude and longitude coordinates.

[0045] In another exemplary embodiment, the plan generation module 120 can import parts and may prompt the user to verify a series of data points. In one exemplary embodiment, plan generation may occur on the client or server (via the WebUI). For example, if the part is a curved high rail, the module can import the curve for that degree, identify the rail number, and verify that a plate is not required, as well as the fastener type. In another exemplary embodiment, parts can be automatically entered. In another exemplary embodiment, the plan generation module 120 can automatically enter parts and may prompt the user to verify that the parts are correct. In another exemplary embodiment, once the parts in the rail segment have been verified, the plan generation module 120 may prompt the user to proceed based on the imported inspection record and any attributes entered in the WebUI and to automatically enter the materials. In another exemplary embodiment, the plan generation module 120 may allow the user to customize the plan by adding or removing materials based on planning requirements. In another exemplary embodiment, the plan generation module 120 may provide a text field for capturing user notes. In another illustrative embodiment, the plan generation module 120 is capable of saving parts, any added comments, and then adding the parts to the financial plan. For example, in the case of a curve, one plan with one part can be generated. In other words, in the case of a large curve, one part can be generated within one plan. In the case of a large curve, separate parts can be generated within separate plans. In the case of an inclined rail, it may have two parts for each rail.

[0046] As a result, a financial plan can be generated using multiple different parts. In another exemplary embodiment, only parts that require replacement based on inspections may be included in the financial plan. In another exemplary embodiment, the plan generation module 120 can automatically calculate costs based on the quantity and unit price of the material that has been imported, and the unit price of that material. Advantageously, the plan generation module 120 can estimate the amount of the project's cost. Part and material costs can be imported from a pricing database that maintains contract prices, which is operably coupled to the STAMP system. The STAMP system allows users to perform inspections and generate plans for any assets currently in use. In another exemplary embodiment, the STAMP system 200 can approve the plan within the client. In another exemplary embodiment, the model may include scheduling parameters to indicate when and where inspections should occur. In addition, the STAMP system 200 can assign inspections to specific users or groups of users and can provide notifications of new inspection requests within the client.

[0047] Figure 3 shows a flowchart illustrating the strategic trajectory and maintenance planning process flow control logic 300 according to one or more exemplary embodiments of the present disclosure. The STAMP process flow control logic 300 can be implemented as an algorithm on a server 304, a machine learning module, a client 302, a database 306, or other suitable system. The STAMP process flow control logic 300 can be implemented by software, hardware, an application programming interface (API), network connectivity, network transport protocols, HTML, DHTML, JavaScript, Dojo, Ruby, Rails, or other suitable applications, or a suitable combination thereof.

[0048] The STAMP process flow control logic 300 can leverage the capabilities of a computer platform to generate multiple processes and threads by processing data simultaneously. The speed and efficiency of the STAMP process flow control logic 300 can be significantly improved by instantiating multiple processes to implement STAMP inspection. However, those skilled in the art in the field of programming will understand that the use of a single processing thread can also be utilized and is within the scope of this disclosure.

[0049] The STAMP process flow control logic 300 of this embodiment is initiated in step 310, where the control logic 300 can generate or receive an inspection request. In one exemplary embodiment, the inspection request may be from a client in the field (e.g., near a railway track). In another exemplary embodiment, the inspection request may include inspection data having one or more fields, parameters, characteristics, or metadata related to the inspection. In another exemplary embodiment, the request may include commands such as upload, download, save, retrieve, or other appropriate commands. The control logic 300 then proceeds to step 312.

[0050] In step 312, the control logic 300 can generate a request using the inspection data and upload the inspection. In one exemplary embodiment, the inspection may be a data file containing one or more characteristics of a rail asset. The control logic 300 then proceeds to step 314.

[0051] In step 314, the control logic 300 can format the inspection data as a data file or message. In one exemplary embodiment, the data file, message, string, or pipe may be a JSON message, SOAP message, XML file, RESTful string, or other appropriate format. The control logic 300 then proceeds to step 316.

[0052] In step 316, the control logic 300 can generate an authentication token for a particular request. In one exemplary embodiment, the control logic 300 can receive an authentication token from a client over an encrypted network. For example, client 302 can access the STAMP system by providing valid credentials, including a username and password, biometrics, multi-factor authentication, or other appropriate credentials, via login. In another exemplary embodiment, the credentials can be processed to generate an authentication token. For example, the authentication token can be generated as a JWT (JSON Web Token) by hashing at least a portion of the login credentials, by using an authentication app sent on-demand on the client or via SMS, via a dongle or key fob that periodically generates new authentication tokens according to a known algorithm, or by other appropriate methodologies. In another exemplary embodiment, the authentication token can allow single sign-on authentication from client 302 to server 304 and / or database 306. The control logic 300 then proceeds to step 318.

[0053] In step 318, an authentication token is sent to the gateway. In one exemplary embodiment, the gateway may be a router, a switch, or other suitable device. In another exemplary embodiment, the gateway may be operably coupled to an encrypted network. The control logic 300 then proceeds to step 320.

[0054] In step 320, the control logic 300 can validate the token. In one exemplary embodiment, the authentication token can be parsed by the server 304 to validate access for client 302. In another exemplary embodiment, authentication may succeed if the user can prove to the server that they are a valid user by transmitting a security token. The control logic 300 then proceeds to step 322.

[0055] In step 322, the control logic may authenticate the request. In one exemplary embodiment, after the authentication token has been validated by the server 304, the control token can be used to establish a security context for the client 302 so that the server 304 can successfully make an authentication decision on the user request or inspect the activity. In another exemplary embodiment, the server 304 will attempt to validate the token, and if successful, will continue processing the request. If the server is unable to validate the token, the server 302 may generate a message stating that it could not process the request because it could not validate authorization. In another exemplary embodiment, the request may be to upload, download, review, or complete inspection data or files, in addition to any other relevant requests. The control logic 300 then proceeds to step 324.

[0056] In step 324, the control logic 300 can generate a web service endpoint. In one exemplary embodiment, the web service endpoint may be an entity, processor, or resource on server 304 that can be referenced and to which web service messages can be addressed. An endpoint reference can convey the information necessary to address the web service endpoint. In another exemplary embodiment, the web service endpoint may be a web address (e.g., a URL) to which a client 302 can obtain access to a resource on server 304. In another exemplary embodiment, by referencing the URL, the client 302 can access the operations provided by server 304. The control logic 300 then proceeds to step 326.

[0057] In step 326, the control logic 300 can convert the request into a rail inspection model object. In one exemplary embodiment, the model can be associated with a particular type of inspection. For example, the model may have rails, ballast, panels, sleepers, switches, or other appropriate model types. In another exemplary embodiment, the model may have one or more objects associated with it. Each object may have one or more characteristics or parameters related to a particular model. In another exemplary embodiment, the request can be parsed to deselect one or more fields of the request for conversion to a model object. The control logic 300 then proceeds to step 330.

[0058] In step 330, the control logic 300 can add the model to the GIS database. In one exemplary embodiment, the model may include a header. In another exemplary embodiment, the model may include an attribute table. The model can be customized to accommodate any relevant data relating to a model type, including rails, ballast, panels, sleepers, switches, or other appropriate model types. The control logic 300 then proceeds to step 332.

[0059] In step 332, the control logic 300 can generate a funding plan. The funding plan may include rail inspection data and rail standards, as will be described in more detail later. The control logic 300 then proceeds to step 334.

[0060] In step 334, the control logic 300 can render the inspection screen via the WebUI. The control logic 300 can then terminate or wait for a new request and repeat the steps described above.

[0061] Figure 4 shows a flowchart illustrating the linear flow rail inspection control logic 400 according to one or more exemplary embodiments of the present disclosure. The linear flow rail inspection control logic 400 can be implemented as an algorithm on a server 304, a machine learning module, a client 302, a database 306, or other suitable system. In addition, the linear flow rail inspection control logic 400 can implement or incorporate one or more features of the STAMP inspection system 202, including an inspection initialization module 108, a geolocation module 110, an asset identification module 112, and an inspection generation module 114. The linear flow rail inspection control logic 400 can be implemented by software, hardware, an application programming interface (API), network connectivity, a network transport protocol, HTML, DHTML, JavaScript, Dojo, Ruby, Rails, or other suitable applications, or a suitable combination thereof. One or more exemplary embodiments of the linear flow rail inspection control logic 400 may be shown in Figures 11A to 11C.

[0062] The linear flow rail inspection control logic 400 can leverage the capabilities of a computer platform to generate multiple processes and threads by processing data simultaneously. The speed and efficiency of the linear flow rail inspection control logic 400 can be significantly improved by instantiating multiple processes to implement linear flow rail inspection. However, those skilled in programming will understand that the use of a single processing thread may also be utilized and is within the scope of this disclosure.

[0063] In this embodiment, the linear flow rail inspection control logic 400 is started in step 402, where the control logic 400 can receive an inspection generation command. In one exemplary embodiment, an inspection command can be generated by selecting an inspection generation command. For example, the inspection generation command may be an image or symbol selectable on the client's screen. In another exemplary embodiment, the control logic 400 can receive an asset type and an asset description. In another exemplary embodiment, the control logic 400 can initiate an asset inspection based at least partially on the asset type or asset description. In another exemplary embodiment, the control logic 400 can retrieve asset data from a database via an encrypted network, having one or more inspection-related fields relating to location, asset type, or asset description. In another exemplary embodiment, a command or data can be received via user input generated on the client or server, such as a screen tap, swipe, mouse click, key press, voice command, or other appropriate mechanism. In another exemplary embodiment, an inspection command or data may include inspection data having one or more fields, parameters, characteristics, or metadata relating to the inspection. In another exemplary embodiment, the command may initiate an upload, download, save, retrieve, or other appropriate action. The control logic 400 then proceeds to step 404.

[0064] In step 404, the control logic 400 can receive a project description. In one illustrative embodiment, the project description can be received via user input from a client. For example, the project description may be a text string received from a client. The text string can be received from user input. The control logic 400 then proceeds to step 406.

[0065] In step 406, the control logic 400 can determine the trajectory shape. In one exemplary embodiment, the control logic 400 can display one or more options for the trajectory shape on the client. For example, the trajectory shape may be a curved trajectory, a straight trajectory, or other appropriate trajectory shape. In another exemplary embodiment, the trajectory shape can be determined via user input from the client. If the trajectory shape is straight, the control logic 400 proceeds to step 410. If the trajectory shape is curved, the control logic 400 proceeds to step 408.

[0066] In step 408, the control logic 400 can start the curved rail inspection algorithm, as described in more detail in Figure 5.

[0067] In step 410, the control logic 400 can determine the track type. In one exemplary embodiment, the control logic 400 can display one or more options for the track type on the client. For example, the track type may be main line, non-main line, siding or branch line, or other appropriate track type. In another exemplary embodiment, the track type can be determined via user input from the client. If the track type is main line, the control logic 400 proceeds to step 412. If the track type is non-main line, the control logic 400 proceeds to step 416. If the track type is siding or branch line, the control logic 400 proceeds to step 418.

[0068] In step 412, the control logic 400 can receive a track number. In one exemplary embodiment, the control logic 400 can display one or more options for a track number on the client. For example, the track number could be single track, main line 1, main line 2, main line N, or other appropriate track number. In another exemplary embodiment, the track number could be for backtrack, industrial, or yard. In another exemplary embodiment, the track number can be received via user input from the client. If the track number is single track or main line 1 through main line 8, the control logic 400 proceeds to step 420. If the track number is a different (other) number, the control logic 400 proceeds to step 414.

[0069] In step 414, the control logic 400 may receive other track numbers. In one exemplary embodiment, the control logic 400 may display an input object (e.g., a text field) and a keyboard on the client to receive user input defining other track numbers. The control logic 400 then proceeds to step 420.

[0070] In step 416, the control logic 400 can receive a track number. In one exemplary embodiment, the control logic 400 can display one or more options for the track number on the client. For example, the track number could be single track, main line 1, main line 2, main line N, or other appropriate track number. In another exemplary embodiment, the track number can be received from the client via user input. The control logic 400 then proceeds to step 418.

[0071] In step 418, the control logic 400 can receive a CLIC (Car Location Inventory Control) number. In one exemplary embodiment, the CLIC number may consist of six digits. For example, the first two digits represent the zone, the second two digits indicate the track number within the zone, and the last two digits represent the location on the track. In another exemplary embodiment, the CLIC number can be received from the client via user input. The control logic 400 then proceeds to step 420.

[0072] In step 420, the control logic 400 can receive the rail position for a straight rail. In one exemplary embodiment, the straight rail position may be left, right, both, or any other suitable position. The control logic 400 then proceeds to step 420.

[0073] In step 422, the control logic 400 can generate a new inspection. In one exemplary embodiment, the control logic 400 can prompt the user to start the inspection once the project description, trajectory shape, and trajectory type have been determined. In another exemplary embodiment, the control logic 400 can generate a new inspection record. The inspection record can be stored on the client or server. The control logic 400 can prompt the user by displaying a button, graphic, or other appropriate widget on the client. In another exemplary embodiment, the control logic 400 can save or update the inspection details in a client or server database. In another exemplary embodiment, the control logic 400 can display an inspection start screen or other appropriate display screen on the client. The control logic 400 can then terminate or wait for a new inspection generation request and repeat the steps described above.

[0074] Figure 5 shows a flowchart illustrating the curved flow rail inspection control logic 500 according to one or more exemplary embodiments of the present disclosure. The curved flow rail inspection control logic 500 can be implemented as an algorithm on a server 304, a machine learning module, a client 302, a database 306, or other suitable system. In addition, the curved flow rail inspection control logic 500 can implement or incorporate one or more features of the STAMP inspection system 202, including an inspection initialization module 108, a geolocation module 110, an asset identification module 112, and an inspection generation module 114. The curved flow rail inspection control logic 500 can be implemented by software, hardware, an application programming interface (API), network connectivity, a network transport protocol, HTML, DHTML, JavaScript, Dojo, Ruby, Rails, or other suitable applications, or a suitable combination thereof. One or more exemplary embodiments of the curved flow rail inspection control logic 500 may be shown in Figures 11D to 11E.

[0075] The curved flow rail inspection control logic 500 can leverage the capabilities of a computer platform to generate multiple processes and threads by processing data simultaneously. The speed and efficiency of the curved flow rail inspection control logic 500 can be significantly improved by instantiating multiple processes to implement the curved flow rail inspection. However, those skilled in programming will understand that the use of a single processing thread may also be utilized and is within the scope of this disclosure.

[0076] The curved flow rail inspection control logic 500 of this embodiment is initiated in step 408, where the control logic 500 can receive a curved track inspection instance generation according to step 408 in Figure 4. In one exemplary embodiment, a command or data may be received via user input generated on a client or server, such as a screen tap, swipe, mouse click, key press, voice command, or other appropriate mechanism. In another exemplary embodiment, the inspection command or data may include inspection data having one or more fields, parameters, characteristics, or metadata related to the inspection. The control logic 500 then proceeds to step 502.

[0077] In step 502, the control logic 500 can receive a track type. In one exemplary embodiment, the control logic 500 can display one or more options for the track type on the client. For example, the track type may be main line, non-main line, siding or branch line, or other appropriate track type. In another exemplary embodiment, the track type can be determined via user input from the client. If the track type is main line, the control logic 500 proceeds to step 504. If the track type is non-main line, the control logic 500 proceeds to step 508. If the track type is siding or branch line, the control logic 500 proceeds to step 510.

[0078] In step 504, the control logic 500 can receive a track number. In one exemplary embodiment, the control logic 500 can display one or more options for the track number on the client. For example, the track number could be single track, main line 1, main line 2, main line N, or any other appropriate track number. In another exemplary embodiment, the track number can be received via user input from the client. If the track number is single track or main line 1 through main line 8, the control logic 500 proceeds to step 512. If the track number is a different (other) number, the control logic 500 proceeds to step 506.

[0079] In step 506, the control logic 500 can receive other trajectory numbers. In one exemplary embodiment, the control logic 500 may display a text field and a keyboard on the client to receive user input defining other trajectory numbers. The control logic 500 then proceeds to step 512.

[0080] In step 508, the control logic 500 can receive a track number. In one exemplary embodiment, the control logic 500 can display one or more options for the track number on the client. For example, the track number could be single track, main line 1, main line 2, main line N, or other appropriate track number. In another exemplary embodiment, the track number can be received via user input from the client. The control logic 500 then proceeds to step 510.

[0081] In step 510, the control logic 500 can receive a CLIC (Car Location Inventory Control) number. In one exemplary embodiment, the CLIC number may consist of six digits. For example, the first two digits represent the zone, the second two digits indicate the track number within the zone, and the last two digits represent the location on the track. In another exemplary embodiment, the CLIC number can be received via user input from a client. The control logic 500 then proceeds to step 512.

[0082] In step 512, the control logic 500 can receive a curve number. In one exemplary embodiment, the control logic 500 may display a text field and a keyboard on the client to receive user input defining the curve number. The control logic 500 then proceeds to step 514.

[0083] In step 514, the control logic 500 can receive a curved rail. In one exemplary embodiment, the control logic 400 can display one or more options for the curved rail on the client. For example, the curved rail could be high, low, or other appropriate rail. In another exemplary embodiment, the curved rail can be received via user input from the client. The control logic 500 then proceeds to step 516.

[0084] In step 516, the control logic 500 can receive a rail position for a straight rail. In one exemplary embodiment, the straight rail position may be left, right, both, or any other suitable position. The control logic 500 then proceeds to step 518.

[0085] In step 518, the control logic 500 can generate a new inspection. In one exemplary embodiment, the control logic 500 can prompt the user to start an inspection. In another exemplary embodiment, the control logic 500 can generate a new inspection record. The inspection record can be stored on the client or server. The control logic 500 can prompt the user by displaying a button, graphic, or other appropriate widget on the client. In another exemplary embodiment, the control logic 500 can save or update the inspection details in the client or server database. In another exemplary embodiment, the control logic 500 can display an inspection start screen or other appropriate display screen on the client. The control logic 500 can then terminate or wait for a new inspection generation request and repeat the steps described above.

[0086] Figure 6 shows a flowchart illustrating rail inspection control logic 600 according to one or more exemplary embodiments of the present disclosure. Rail inspection control logic 600 can be implemented as an algorithm on a server 304, a machine learning module, a client 302, a database 306, or other suitable system. In addition, rail inspection control logic 600 can implement or incorporate one or more features of the STAMP inspection system 202, including an inspection initialization module 108, a geolocation module 110, an asset identification module 112, and an inspection generation module 114. Rail inspection control logic 600 can be implemented by software, hardware, an application programming interface (API), network connectivity, a network transport protocol, HTML, DHTML, JavaScript, Dojo, Ruby, Rails, or other suitable applications, or a suitable combination thereof. One or more exemplary embodiments of rail inspection control logic 600 may be shown in Figures 12A and 12B.

[0087] The rail inspection control logic 600 can leverage the capabilities of a computer platform to generate multiple processes and threads by processing data simultaneously. The speed and efficiency of the rail inspection control logic 600 can be significantly improved by instantiating multiple processes to implement linear flow rail inspection. However, those skilled in programming will understand that the use of a single processing thread may also be utilized and is within the scope of this disclosure.

[0088] The rail inspection control logic 600 of this embodiment is initiated in step 602, where the control logic 600 can display one or more prompts related to the inspection. In one exemplary embodiment, a prompt can be retrieved for a specific asset at a specific location from inspection-related data stored in a database. In another exemplary embodiment, prompts can be presented in a step-by-step manner such that subsequent prompts cannot be displayed until a first prompt is responded to. In another exemplary embodiment, prompts can be presented in a step-by-step manner such that subsequent prompts cannot be displayed until a first group of prompts is responded to. In another exemplary embodiment, step-by-step inspection prompts can be generated by the control logic 600 based on the retrieved asset data. In another exemplary embodiment, the control logic 600 can display a first step-by-step inspection prompt on the client. In another exemplary embodiment, the control logic 600 can identify whether any historical data for each inspection-related field is stored in the first database. For example, the control logic 600 can compare the inspection-related field associated with the inspection prompt with the inspection-related field stored in the database for a specific location. If values ​​are stored in the database for the fields related to the inspection, those values ​​can be automatically entered in the inspection prompt and associated input objects. Historical data may include values ​​such as measurements, specifications, thresholds, ranges, costs, or other appropriate data. In another exemplary embodiment, if historical data exists for the fields related to the inspection, the control logic 600 can display the automatically entered response in the response field on the client. For example, the automatically entered response may be a historical value retrieved from the database or a value determined by the STAMP system.In another exemplary embodiment, the prompt may include a corresponding input object, such as a text box, radio button, checkbox, or other appropriate input object. In another exemplary embodiment, the input object may be configured to receive user input, such as a screen tap, swipe, mouse click, key press, voice command, or other appropriate mechanism. In another exemplary embodiment, the input object may include one or more fields, parameters, characteristics, or metadata related to inspection. The control logic 600 can then proceed to step 604.

[0089] In step 604, the control logic 600 may receive the client's starting rail location. In one exemplary embodiment, the control logic 600 may receive, if present, a response to one or more check prompts or validation of an auto-entered response. In another exemplary embodiment, the control logic 600 may display an input object to receive a response to an input prompt (e.g., the starting rail location). For example, an input object such as a text box, radio button, checkbox, or other appropriate input object may be displayed by the control logic 600 on the client or server. In another exemplary embodiment, the input object may be configured to receive user input such as a screen tap, swipe, mouse click, key press, voice command, or other appropriate mechanism. In another exemplary embodiment, the control logic 600 may store the starting rail location in one or more fields, parameters, characteristics, or metadata in memory on the client or server. In another exemplary embodiment, the control logic 600 may instantiate the client's GPS function to determine the client's location. For example, the control logic 600 can receive the client's latitude and longitude coordinates from a geolocation module or GPS device coupled to the client. The control logic 600 then proceeds to step 606.

[0090] In step 606, the control logic 600 can receive line segment values. In another exemplary embodiment, the control logic 600 can display a text field and keyboard on the client to receive user input defining line segments near the client. In another exemplary embodiment, the control logic 600 can override the received GPS latitude and longitude coordinates when line segments are notified. The control logic 600 then proceeds to step 608.

[0091] In step 608, the control logic 600 can receive a milepost value. In one exemplary embodiment, the control logic 600 can display a text field and keyboard on the client to receive user input defining a milepost near the client. In another exemplary embodiment, the control logic 600 can override the received GPS latitude and longitude coordinates when a milepost is notified. The control logic 600 then proceeds to step 610.

[0092] In step 610, the control logic 600 can determine the trajectory shape. In one exemplary embodiment, the control logic 400 can display one or more options for the trajectory shape on the client. For example, the trajectory shape may be a curved trajectory, a straight trajectory, or other appropriate trajectory shape. In another exemplary embodiment, the trajectory shape can be determined via user input from the client. If the trajectory shape is straight, the control logic 600 proceeds to step 612. If the trajectory shape is curved, the control logic 600 proceeds to step 618.

[0093] In step 612, the control logic 600 can determine the rail position to be inspected for a straight rail. In one exemplary embodiment, the straight rail position may be left, right, both, or any other suitable position. If the rail position is left or right, the control logic 600 proceeds to step 618. If the rail position is both, the control logic 600 proceeds to step 614.

[0094] In step 618, the control logic 600 may receive notification of whether a transition rail is required. In one exemplary embodiment, the control logic 600 may display an input object to receive the transition rail notification. For example, an input object such as a text box, radio button, checkbox, or other input object may be displayed by the control logic 600 on the client or server. In another exemplary embodiment, the input object may be configured to receive user input such as a screen tap, swipe, mouse click, key press, voice command, or other appropriate mechanism. In another exemplary embodiment, the control logic 600 may store the transition rail notification in one or more fields, parameters, characteristics, or metadata in memory on the client or server. A transition rail is a track component that can connect two different rail sections. If a transition rail is required, the control logic 600 proceeds to step 624. If a left transition rail is not required, the control logic 600 proceeds to step 620.

[0095] In step 620, the control logic 600 can receive the parent rail weight. In one exemplary embodiment, the control logic 600 can display an input object to receive the parent rail weight. For example, the input object, such as a text box, radio button, checkbox, or other appropriate input object, can be displayed by the control logic 600 on the client or server. In another exemplary embodiment, the input object can be configured to receive user input such as a screen tap, swipe, mouse click, key press, voice command, or other appropriate mechanism. In another exemplary embodiment, the control logic 600 can store the parent rail weight in one or more fields, parameters, characteristics, or metadata in memory on the client or server. For example, the rail weight may range from 100 pounds to 150 pounds. The control logic 600 then proceeds to step 650.

[0096] In step 624, the control logic 600 can receive the parent rail weight. In one exemplary embodiment, the control logic 600 can display an input object to receive the parent rail weight. For example, the input object, such as a text box, radio button, checkbox, or other appropriate input object, can be displayed by the control logic 600 on the client or server. In another exemplary embodiment, the input object can be configured to receive user input such as a screen tap, swipe, mouse click, key press, voice command, or other appropriate mechanism. In another exemplary embodiment, the control logic 600 can store the parent rail weight in one or more fields, parameters, characteristics, or metadata in memory on the client or server. For example, the rail weight may range from 100 pounds to 150 pounds. The control logic 600 then proceeds to step 626.

[0097] In step 626, the control logic 600 receives notification that the end transition rail is shipped in an unfixed state or welded at the plant. In one exemplary embodiment, the control logic 600 may display an input object to receive the end transition rail shipment notification. For example, the control logic 600 may display an input object on the client or server, such as a text box, radio buttons, checkboxes, or other appropriate input objects. In another exemplary embodiment, the input object may be configured to receive user input such as screen taps, swipes, mouse clicks, key presses, voice commands, or other appropriate mechanisms. In another exemplary embodiment, the control logic 600 may store the end transition rail shipment notification in one or more fields, parameters, characteristics, or metadata in memory on the client or server. If the end transition rail shipment is shipped in an unfixed state, the control logic 600 proceeds to step 628. If the end transition rail shipment is welded at the plant, the control logic 600 proceeds to step 628.

[0098] In step 628, the control logic 600 can receive a vertical head loss value. For example, vertical head loss is the shortening of the railhead due to the movement of the locomotive on the rails. In one exemplary embodiment, the control logic 600 may display a text field and a keyboard on the client to receive user input defining the vertical head loss value. The control logic then proceeds to step 630.

[0099] In step 630, the control logic 600 can receive a gauge surface loss value. For example, gauge surface loss is the erosion of the railhead surface facing the gauge side of the railway track. As the wheels rotate through a curve, the wheels on both the high and low rails can generate lateral gauge extension forces. In particular, wear on the gauge surface of the rail can be caused by the contact load applied to the side of the railhead by the wheel flange. In one exemplary embodiment, the control logic 600 can display a text field and keyboard on the client to receive user input defining the gauge surface loss value. The control logic 600 then proceeds to step 650.

[0100] In step 614, the control logic 600 determines whether a left transition rail is required. A transition rail is a track component that can connect two different rail sections. If a left transition rail is required, the control logic proceeds to step 622. If a left transition rail is not required, the control logic 600 proceeds to step 616.

[0101] In step 616, the control logic 600 can receive the parent rail weight. In one exemplary embodiment, the control logic 600 may display a text field and keyboard on the client to receive user input specifying the rail weight for the left rail. For example, the rail weight may range from 100 pounds to 150 pounds. The control logic 600 then proceeds to step 638.

[0102] In step 622, the control logic 600 can receive the left parent rail weight. In one exemplary embodiment, the control logic 600 may display a text field and keyboard on the client to receive user input specifying the rail weight for the left rail. For example, the rail weight may range from 100 pounds to 150 pounds. The control logic 600 then proceeds to step 632.

[0103] In step 632, the control logic 600 determines whether the left transition rail is shipped in an unfixed state or welded at the plant. If the rail for the left transition rail is shipped in an unfixed state, the control logic proceeds to step 634. If the rail for the left transition rail is shipped in a state where it will be welded at the plant, the control logic proceeds to step 634.

[0104] In step 634, the control logic 600 can receive a left vertical head loss value. For example, vertical head loss is the shortening of the railhead due to the locomotive's movement on the rails. In one exemplary embodiment, the control logic 600 may display a text field and a keyboard on the client to receive user input defining the left vertical head loss value. The control logic then proceeds to step 636.

[0105] In step 636, the control logic 600 can receive a left gauge face loss value. For example, gauge face loss is the erosion of the railhead surface facing the gauge side of the railway track. As the wheels rotate through a curve, the wheels on both the high and low rails can generate lateral gauge extension forces. In particular, wear on the gauge surface of the rail can be caused by contact loads applied to the sides of the railhead by the wheel flanges. In one exemplary embodiment, the control logic 600 can display a text field and a keyboard on the client to receive user input defining the left gauge face loss value. The control logic 600 then proceeds to step 638.

[0106] In step 638, the control logic 600 determines whether a right transition rail is required. A transition rail is a track component that can connect two different rail sections. If a right transition rail is required, the control logic proceeds to step 640. If a right transition rail is not required, the control logic 600 proceeds to step 648.

[0107] In step 640, the control logic 600 can receive the right parent rail weight. In one exemplary embodiment, the control logic 600 may display a text field and keyboard on the client to receive user input specifying the rail weight for the right rail. For example, the rail weight may range from 100 pounds to 150 pounds. The control logic 600 then proceeds to step 642.

[0108] In step 648, the control logic 600 can receive the left parent rail weight. In one exemplary embodiment, the control logic 600 may display a text field and keyboard on the client to receive user input specifying the rail weight for the left rail. For example, the rail weight may range from 100 pounds to 150 pounds. The control logic 600 then proceeds to step 650.

[0109] In step 642, the control logic 600 determines whether the right transition rail is shipped in an unfixed state or welded at the plant. If the rail for the right transition rail is shipped in an unfixed state, the control logic proceeds to step 644. If the rail for the right transition rail is shipped in a state where it will be welded at the plant, the control logic proceeds to step 644.

[0110] In step 644, the control logic 600 can receive a left vertical head loss value. For example, vertical head loss is the shortening of the rails due to the movement of the locomotive on the rails. In one exemplary embodiment, the control logic 600 may display a text field and a keyboard on the client to receive user input specifying the left vertical head loss value. The control logic then proceeds to step 646.

[0111] In step 646, the control logic 600 can receive a left gauge face loss value. For example, gauge face loss is the erosion of the railhead surface facing the gauge side of the railway track. As the wheels rotate through a curve, the wheels on both the high and low rails can generate lateral gauge extension forces. In particular, wear on the gauge surface of the rail can be caused by contact loads applied to the sides of the railhead by the wheel flanges. In one exemplary embodiment, the control logic 600 may display a text field and a keyboard on the client to receive user input defining the left gauge face loss value. The control logic 600 then proceeds to step 650.

[0112] In step 650, the control logic 600 can instantiate the body inspection algorithm, which is further detailed in Figure 7.

[0113] Figure 7 shows a flowchart illustrating the body flow rail inspection control logic 700 according to one or more exemplary embodiments of the present disclosure. The body flow rail inspection control logic 700 can be implemented as an algorithm on a server 304, a machine learning module, a client 302, a database 306, or other suitable system. In addition, the body flow rail inspection control logic 700 can implement or incorporate one or more features of the STAMP inspection system 202, including an inspection initialization module 108, a geolocation module 110, an asset identification module 112, and an inspection generation module 114. The body flow rail inspection control logic 700 can be implemented by software, hardware, an application programming interface (API), network connectivity, a network transport protocol, HTML, DHTML, JavaScript, Dojo, Ruby, Rails, or other suitable applications, or a suitable combination thereof. One or more exemplary embodiments of the body flow rail inspection control logic 700 may be shown in Figures 13A and 13B.

[0114] The body flow rail inspection control logic 700 can leverage the capabilities of a computer platform to generate multiple processes and threads by processing data simultaneously. The speed and efficiency of the body flow rail inspection control logic 700 can be significantly improved by instantiating multiple processes to implement body flow rail inspection. However, those skilled in programming will understand that the use of a single processing thread may also be utilized and is included within the scope of this disclosure.

[0115] The body flow rail inspection control logic 700 of this embodiment is initiated in step 650, where the control logic 700 can receive a body inspection instance generation according to step 650 in Figure 6. In one exemplary embodiment, the control logic 700 can display one or more questions related to the inspection. In another exemplary embodiment, the control logic 700 can display a body inspection screen. In another exemplary embodiment, commands or data can be received via user input generated on the client or server, such as screen taps, swipes, mouse clicks, key presses, voice commands, or other appropriate mechanisms. In another exemplary embodiment, inspection commands or data may include inspection data having one or more fields, parameters, characteristics, or metadata related to the inspection. The inspection data can be stored in memory on the client or server. The control logic 700 then proceeds to step 702.

[0116] In step 702, the control logic 700 can determine the trajectory shape. In one exemplary embodiment, the control logic 700 can display one or more options for the trajectory shape on the client. For example, the trajectory shape may be a curved trajectory, a straight trajectory, or other appropriate trajectory shape. In another exemplary embodiment, the control logic 700 can display an input object to receive the trajectory shape. For example, an input object such as a text box, radio button, checkbox, or other appropriate input object can be displayed by the control logic 700 on the client or server. In another exemplary embodiment, the input object may be configured to receive user input such as a screen tap, swipe, mouse click, key press, voice command, or other appropriate mechanism. In another exemplary embodiment, the control logic 700 can store the trajectory shape in one or more fields, parameters, characteristics, or metadata in memory on the client or server. If the trajectory shape is straight, the control logic 700 proceeds to step 704. If the trajectory shape is curved, the control logic 700 proceeds to step 708.

[0117] In step 704, the control logic 700 can determine the rail position of the rail to be inspected for a straight rail. In one exemplary embodiment, the straight rail position may be left, right, both, or any other appropriate position. In another exemplary embodiment, the control logic 700 may display an input object to receive the straight rail position. For example, an input object such as a text box, radio button, checkbox, or any other appropriate input object may be displayed by the control logic 700 on the client or server. In another exemplary embodiment, the input object may be configured to receive user input such as a screen tap, swipe, mouse click, key press, voice command, or any other appropriate mechanism. In another exemplary embodiment, the control logic 700 may store the straight rail position in one or more fields, parameters, characteristics, or metadata in memory on the client or server. If the rail position is left or right, the control logic 700 proceeds to step 708. If the rail position is both, the control logic 700 proceeds to step 706.

[0118] In step 706, the control logic 700 can instantiate the double-check algorithm, which is further detailed in step 614 of Figure 6. Once the double-check algorithm is complete, the control logic 700 can proceed to step 708.

[0119] In step 708, the control logic 700 can receive the year in which the body rail was put into use (laid). In another exemplary embodiment, the control logic 700 can display an input object to receive the year of use. For example, an input object such as a text box, radio button, checkbox, or other appropriate input object can be displayed by the control logic 700 on the client or server. In another exemplary embodiment, the input object can be configured to receive user input such as a screen tap, swipe, mouse click, key press, voice command, or other appropriate mechanism. In another exemplary embodiment, the control logic 700 can store the year of use in one or more fields, parameters, characteristics, or metadata in memory on the client or server. The control logic then proceeds to step 710.

[0120] In step 710, the control logic 700 can receive the manufacturer name of the body rail. In another exemplary embodiment, the control logic 700 can display an input object for receiving the manufacturer name. For example, the control logic 700 can display an input object on the client or server, such as a text box, radio button, checkbox, or other appropriate input object. In another exemplary embodiment, the input object can be configured to receive user input such as a screen tap, swipe, mouse click, key press, voice command, or other appropriate mechanism. In another exemplary embodiment, the control logic 700 can store the manufacturer name in one or more fields, parameters, characteristics, or metadata in memory on the client or server. The control logic then proceeds to step 712.

[0121] In step 712, the control logic 700 can receive the weight of the rail body. In another exemplary embodiment, the control logic 700 can display an input object to receive the rail weight. For example, the control logic 700 can display an input job object on the client or server, such as a text box, radio buttons, checkboxes, or other appropriate input objects. In another exemplary embodiment, the input object can be configured to receive user input such as screen taps, swipes, mouse clicks, key presses, voice commands, or other appropriate mechanisms. In another exemplary embodiment, the control logic 700 can store the rail weight in one or more fields, parameters, characteristics, or metadata in memory on the client or server. The control logic then proceeds to step 714.

[0122] In step 714, the control logic 700 can receive a vertical head loss value for the rail body. In another exemplary embodiment, the control logic 700 can display an input object for receiving the vertical head loss value. For example, the control logic 700 can display an input object on the client or server, such as a text box, radio button, checkbox, or other appropriate input object. In another exemplary embodiment, the input object can be configured to receive user input such as a screen tap, swipe, mouse click, key press, voice command, or other appropriate mechanism. In another exemplary embodiment, the control logic 700 can store the vertical head loss value in one or more fields, parameters, characteristics, or metadata in memory on the client or server. The control logic then proceeds to step 716.

[0123] In step 716, the control logic 700 can receive the gauge face loss value of the rail body. In another exemplary embodiment, the control logic 700 can display an input object to receive the gauge face loss value. For example, the input object, such as a text box, radio button, checkbox, or other appropriate input object, can be displayed by the control logic 700 on the client or server. In another exemplary embodiment, the input object can be configured to receive user input such as a screen tap, swipe, mouse click, key press, voice command, or other appropriate mechanism. In another exemplary embodiment, the control logic 700 can store the gauge face loss value in one or more fields, parameters, characteristics, or metadata in memory on the client or server. The control logic then proceeds to step 718.

[0124] In step 718, the control logic 700 can determine the sleeper type. In another exemplary embodiment, the control logic 700 can display an input object to receive the sleeper type. For example, the control logic 700 can display an input object on the client or server, such as a text box, radio button, checkbox, or other appropriate input object. In another exemplary embodiment, the input object can be configured to receive user input such as a screen tap, swipe, mouse click, key press, voice command, or other appropriate mechanism. In another exemplary embodiment, the control logic 700 can store the sleeper type in one or more fields, parameters, characteristics, or metadata in memory on the client or server. If the sleeper type is concrete, the control logic 700 proceeds to step 732. If the sleeper type is wood, the control logic 700 proceeds to step 720.

[0125] In step 732, the control logic 700 may receive a concrete fastener selection for the rail sleepers. In another exemplary embodiment, the control logic 700 may display an input object to receive the concrete fastener selection. For example, an input object such as a text box, radio buttons, checkboxes, or other appropriate input object may be displayed by the control logic 700 on the client or server. In another exemplary embodiment, the input object may be configured to receive user input such as a screen tap, swipe, mouse click, key press, voice command, or other appropriate mechanism. In another exemplary embodiment, the control logic 700 may store the concrete fastener selection in one or more fields, parameters, characteristics, or metadata in memory on the client or server. The control logic then proceeds to step 734.

[0126] In step 734, the control logic 700 may receive notification of whether shoulder repair is required. In another exemplary embodiment, the control logic 700 may display an input object to receive shoulder repair notifications. For example, an input object such as a text box, radio buttons, checkboxes, or other appropriate input objects may be displayed by the control logic 700 on the client or server. In another exemplary embodiment, the input object may be configured to receive user input such as screen taps, swipes, mouse clicks, key presses, voice commands, or other appropriate mechanisms. In another exemplary embodiment, the control logic 700 may store the shoulder repair notification in one or more fields, parameters, characteristics, or metadata in memory on the client or server. The control logic then proceeds to step 736.

[0127] In step 720, the control logic 700 can receive a selection of timber fasteners for rail sleepers. In another exemplary embodiment, the control logic 700 can display an input object to receive the timber fastener selection. For example, the input object, such as a text box, radio buttons, checkboxes, or other appropriate input object, can be displayed by the control logic 700 on the client or server. In another exemplary embodiment, the input object can be configured to receive user input such as a screen tap, swipe, mouse click, key press, voice command, or other appropriate mechanism. In another exemplary embodiment, the control logic 700 can store the timber fastener selection in one or more fields, parameters, characteristics, or metadata in memory on the client or server. The control logic then proceeds to step 722.

[0128] In step 722, the control logic 700 can receive notification of whether a pull plate change is required. In another exemplary embodiment, the control logic 700 can display an input object to receive pull plate change notifications. For example, an input object such as a text box, radio button, checkbox, or other appropriate input object can be displayed by the control logic 700 on the client or server. In another exemplary embodiment, the input object can be configured to receive user input such as a screen tap, swipe, mouse click, key press, voice command, or other appropriate mechanism. In another exemplary embodiment, the control logic 700 can store the pull plate change notification in one or more fields, parameters, characteristics, or metadata in memory on the client or server. The control logic then proceeds to step 724.

[0129] In step 724, the control logic 700 verifies the track shape for selecting the type of wooden sleeper. In one exemplary embodiment, the control logic 700 may retrieve this test track shape stored in memory on the client or server. If the track shape is straight, the control logic 700 proceeds to step 728. If the track shape is curved, the control logic 700 proceeds to step 726.

[0130] In step 726, the control logic 700 can receive notification of whether a curve block is required. In another exemplary embodiment, the control logic 700 can display an input object to receive the curve block notification. For example, an input object such as a text box, radio button, checkbox, or other appropriate input object can be displayed by the control logic 700 on the client or server. In another exemplary embodiment, the input object can be configured to receive user input such as a screen tap, swipe, mouse click, key press, voice command, or other appropriate mechanism. In another exemplary embodiment, the control logic 700 can store the curve block notification in one or more fields, parameters, characteristics, or metadata in memory on the client or server. The control logic then proceeds to step 728.

[0131] In step 728, the control logic 700 can determine the type of wood fastener. In another exemplary embodiment, the control logic 700 can display an input object to receive the wood fastener type. For example, the control logic 700 can display an input object on the client or server, such as a text box, radio button, checkbox, or other appropriate input object. In another exemplary embodiment, the input object can be configured to receive user input such as a screen tap, swipe, mouse click, key press, voice command, or other appropriate mechanism. In another exemplary embodiment, the control logic 700 can store the wood fastener type in one or more fields, parameters, characteristics, or metadata in memory on the client or server. If the wood fastener type is cut spike, the control logic 700 proceeds to step 730. If the wood fastener type is Pandrol®, the control logic 700 proceeds to step 736.

[0132] In step 730, the control logic 700 can receive notification of whether a legacy anchor pattern should be used. In another exemplary embodiment, the control logic 700 can display an input object to receive legacy anchor pattern notification. For example, an input object such as a text box, radio button, checkbox, or other appropriate input object can be displayed by the control logic 700 on the client or server. In another exemplary embodiment, the input object can be configured to receive user input such as a screen tap, swipe, mouse click, key press, voice command, or other appropriate mechanism. In another exemplary embodiment, the control logic 700 can store the legacy anchor pattern notification in one or more fields, parameters, characteristics, or metadata in memory on the client or server. The control logic then proceeds to step 736.

[0133] In step 736, the control logic 700 can instantiate the inspection termination algorithm, which is further detailed in Figure 8.

[0134] Figure 8 shows a flowchart illustrating the rail inspection termination control logic 800 according to one or more exemplary embodiments of the present disclosure. The inspection termination control logic 800 can be implemented as an algorithm on a server 304, a machine learning module, a client 302, a database 306, or other suitable system. In addition, the rail inspection termination control logic 800 can implement or incorporate one or more features of the STAMP inspection system 202, including an inspection initialization module 108, a geolocation module 110, an asset identification module 112, and an inspection generation module 114. The inspection termination control logic 800 can be implemented by software, hardware, an application programming interface (API), a network connection, a network transport protocol, HTML, DHTML, JavaScript, Dojo, Ruby, Rails, or other suitable applications, or a suitable combination thereof. One or more exemplary embodiments of the inspection termination control logic 800 may be shown in Figure 14A.

[0135] The inspection termination control logic 800 can leverage the capabilities of the computer platform to generate multiple processes and threads by processing data simultaneously. The speed and efficiency of the inspection termination control logic 800 can be significantly improved by instantiating multiple processes to implement linear flow rail inspection. However, those skilled in programming will understand that the use of a single processing thread may also be utilized and is within the scope of this disclosure.

[0136] The inspection termination control logic 800 of this embodiment is initiated in step 736, where the control logic 800 can receive inspection termination instance generation according to step 736 in Figure 7. In one exemplary embodiment, the control logic 800 may display one or more questions relating to the termination of the inspection. In another exemplary embodiment, the control logic 800 may display an inspection termination screen. In another exemplary embodiment, commands or data may be received via user input generated on the client or server, such as screen taps, swipes, mouse clicks, key presses, voice commands, or other appropriate mechanisms. In another exemplary embodiment, inspection commands or data may include inspection data having one or more fields, parameters, characteristics, or metadata relating to the inspection. The inspection data may be stored in memory on the client or server. The control logic 800 then proceeds to step 804.

[0137] In step 804, the control logic 800 can determine the client's end rail location. In one exemplary embodiment, the control logic 800 can display an input object to receive the end rail location. For example, the control logic 800 on the client or server can display an input object such as a text box, radio button, checkbox, or other appropriate input object. In another exemplary embodiment, the input object can be configured to receive user input such as a screen tap, swipe, mouse click, key press, voice command, or other appropriate mechanism. In another exemplary embodiment, the control logic 800 can store the end rail location in one or more fields, parameters, characteristics, or metadata in memory on the client or server. In another exemplary embodiment, the control logic 800 can instantiate the client's GPS function to determine the client's location. For example, the control logic 800 can receive the client's latitude and longitude coordinates from a geolocation module or GPS device. The control logic 800 then proceeds to step 806.

[0138] In step 806, the control logic 800 can receive the end milepost value. In one exemplary embodiment, the control logic 800 can display an input object to receive the end milepost value. For example, the control logic 800 can display an input object on the client or server, such as a text box, radio button, checkbox, or other appropriate input object. In another exemplary embodiment, the input object can be configured to receive user input such as a screen tap, swipe, mouse click, key press, voice command, or other appropriate mechanism. In another exemplary embodiment, the control logic 800 can store the end milepost value in one or more fields, parameters, characteristics, or metadata in memory on the client or server. In another exemplary embodiment, the control logic 800 can override the received GPS latitude and longitude coordinates when the milepost is notified. The control logic 800 then proceeds to step 808.

[0139] In step 808, the control logic 800 can receive the measured number of feet. In one exemplary embodiment, the control logic 800 can display an input object to receive the measured number of feet. For example, the control logic 800 can display an input object on the client or server, such as a text box, radio button, checkbox, or other appropriate input object. In another exemplary embodiment, the input object can be configured to receive user input such as a screen tap, swipe, mouse click, key press, voice command, or other appropriate mechanism. In another exemplary embodiment, the control logic 800 can store the measured number of feet in one or more fields, parameters, characteristics, or metadata in memory on the client or server. In another exemplary embodiment, the measured number of feet can have any input unit (e.g., feet, meters, or miles). In another exemplary embodiment, the control logic 800 can convert the received unit to feet. The control logic 800 then proceeds to step 810.

[0140] In step 810, the control logic 800 can receive the amount of insulating joints. In one exemplary embodiment, the control logic 800 can display an input object to receive the amount of insulating joints. For example, the input object, such as a text box, radio buttons, checkboxes, or other appropriate input objects, can be displayed by the control logic 800 on the client or server. In another exemplary embodiment, the input object can be configured to receive user input such as screen taps, swipes, mouse clicks, key presses, voice commands, or other appropriate mechanisms. In another exemplary embodiment, the control logic 800 can store the amount of insulating joints in one or more fields, parameters, characteristics, or metadata in memory on the client or server. In another exemplary embodiment, the measured number of feet can have any input unit (e.g., feet, meters, or miles). The control logic 800 then proceeds to step 812.

[0141] In step 812, the control logic 800 can verify the trajectory shape. In one exemplary embodiment, the control logic 800 can retrieve this test trajectory shape stored in memory on the client or server. In another exemplary embodiment, the trajectory shape can be determined via user input from the client. If the trajectory shape is straight, the control logic 800 proceeds to step 814. If the trajectory shape is curved, the control logic 800 proceeds to step 818.

[0142] In step 814, the control logic 800 can determine the rail position to be inspected for a straight rail. In one exemplary embodiment, the straight rail position may be left, right, both, or any other suitable position. If the rail position is left or right, the control logic 800 proceeds to step 818. If the rail position is both, the control logic 800 proceeds to step 816.

[0143] In step 818, the control logic 800 may receive notification of whether an end transition rail is required. A transition rail is a track component that can connect two different rail sections. In one exemplary embodiment, the control logic 800 may display an input object to receive an end transition rail notification. For example, an input object such as a text box, radio button, checkbox, or other appropriate input object may be displayed by the control logic 800 on the client or server. In another exemplary embodiment, the input object may be configured to receive user input such as a screen tap, swipe, mouse click, key press, voice command, or other appropriate mechanism. In another exemplary embodiment, the control logic 800 may store the end transition rail notification in one or more fields, parameters, characteristics, or metadata in memory on the client or server. If an end transition rail is required, the control logic proceeds to step 820. If an end transition rail is not required, the control logic 800 proceeds to step 846.

[0144] In step 820, the control logic 800 receives notification that the end transition rail is shipped in an unfixed state or welded at the plant. In one exemplary embodiment, the control logic 800 may display an input object to receive the end transition rail shipment notification. For example, an input object such as a text box, radio buttons, checkboxes, or other input objects may be displayed by the control logic 800 on the client or server. In another exemplary embodiment, the input object may be configured to receive user input such as a screen tap, swipe, mouse click, key press, voice command, or other appropriate mechanism. In another exemplary embodiment, the control logic 800 may store the end transition rail shipment notification in one or more fields, parameters, characteristics, or metadata in memory on the client or server. If the end transition rail shipment is shipped in an unfixed state, the control logic 800 proceeds to step 822. If the end transition rail shipment is welded at the plant, the control logic 800 proceeds to step 822.

[0145] In step 822, the control logic 800 can receive the end parent rail weight. In one exemplary embodiment, the control logic 800 can display an input object to receive the end parent rail weight. For example, the input object, such as a text box, radio button, checkbox, or other appropriate input object, can be displayed by the control logic 800 on the client or server. In another exemplary embodiment, the input object can be configured to receive user input such as a screen tap, swipe, mouse click, key press, voice command, or other appropriate mechanism. In another exemplary embodiment, the control logic 800 can store the end parent rail weight in one or more fields, parameters, characteristics, or metadata in memory on the client or server. For example, the rail weight may range from 100 pounds to 150 pounds. The control logic 800 then proceeds to step 824.

[0146] In step 824, the control logic 800 can receive a vertical head loss value. For example, vertical head loss is the shortening of the railhead due to the movement of the locomotive on the rails. In one exemplary embodiment, the control logic 800 can display an input object to receive the vertical head loss value. For example, an input object such as a text box, radio button, checkbox, or other input object can be displayed by the control logic 800 on the client or server. In another exemplary embodiment, the input object can be configured to receive user input such as a screen tap, swipe, mouse click, key press, voice command, or other appropriate mechanism. In another exemplary embodiment, the control logic 800 can store the vertical head loss value in one or more fields, parameters, characteristics, or metadata in memory on the client or server. The control logic then proceeds to step 826.

[0147] In step 826, the control logic 800 can receive a gauge face loss value. For example, gauge face loss is the erosion of the railhead surface facing the gauge side of the railway track. As the wheels rotate through a curve, the wheels on both the high and low rails can generate lateral gauge extension forces. In particular, wear on the gauge surface of the rail can be caused by contact loads applied to the sides of the railhead by the wheel flanges. In one exemplary embodiment, the control logic 800 can display an input object to receive the gauge face loss value. For example, an input object such as a text box, radio buttons, checkboxes, or other appropriate input object can be displayed by the control logic 800 on the client or server. In another exemplary embodiment, the input object can be configured to receive user input such as a screen tap, swipe, mouse click, key press, voice command, or other appropriate mechanism. In another exemplary embodiment, the control logic 800 can store the gauge face loss value in one or more fields, parameters, characteristics, or metadata in memory on the client or server. Next, the control logic 800 proceeds to step 846.

[0148] In step 816, the control logic 800 may receive notification of whether an end-left transition rail is required. A transition rail is a track component that can connect two different rail sections. In one exemplary embodiment, the control logic 800 may display an input object to receive an end-left transition rail notification. For example, an input object such as a text box, radio button, checkbox, or other appropriate input object may be displayed by the control logic 800 on the client or server. In another exemplary embodiment, the input object may be configured to receive user input such as a screen tap, swipe, mouse click, key press, voice command, or other appropriate mechanism. In another exemplary embodiment, the control logic 800 may store the end-left transition rail notification in one or more fields, parameters, characteristics, or metadata in memory on the client or server. If an end-left transition rail is required, the control logic 800 proceeds to step 828. If an end-left transition rail is not required, the control logic 800 proceeds to step 836.

[0149] In step 828, the control logic 800 receives notification that the end left transition rail is shipped in an unfixed state or is welded at the plant. In one exemplary embodiment, the control logic 800 may display an input object to receive the end left transition rail shipment notification. For example, the input object, such as a text box, radio buttons, checkboxes, or other appropriate input objects, may be displayed by the control logic 800 on the client or server. In another exemplary embodiment, the input object may be configured to receive user input such as screen taps, swipes, mouse clicks, key presses, voice commands, or other appropriate mechanisms. In another exemplary embodiment, the control logic 800 may store the end left transition rail shipment notification in one or more fields, parameters, characteristics, or metadata in memory on the client or server. If the end left transition rail shipment is shipped in an unfixed state, the control logic 800 proceeds to step 830. If the end left transition rail shipment is welded at the plant, the control logic 800 proceeds to step 830.

[0150] In step 830, the control logic 800 can receive the end parent rail weight for the left rail. In one exemplary embodiment, the control logic 800 can display an input object to receive the end left rail parent rail weight. For example, the input object, such as a text box, radio button, checkbox, or other appropriate input object, can be displayed by the control logic 800 on the client or server. In another exemplary embodiment, the input object can be configured to receive user input such as a screen tap, swipe, mouse click, key press, voice command, or other appropriate mechanism. In another exemplary embodiment, the control logic 800 can store the end left rail parent rail weight in one or more fields, parameters, characteristics, or metadata in memory on the client or server. For example, the rail weight may range from 100 pounds to 150 pounds. The control logic 800 then proceeds to step 832.

[0151] In step 832, the control logic 800 may receive a vertical head loss value for the left rail. For example, vertical head loss is the shortening of the railhead due to locomotive movement on the rail. In one exemplary embodiment, the control logic 800 may display an input object to receive the left rail vertical head loss value. For example, an input object such as a text box, radio button, checkbox, or other appropriate input object may be displayed by the control logic 800 on the client or server. In another exemplary embodiment, the input object may be configured to receive user input such as a screen tap, swipe, mouse click, key press, voice command, or other appropriate mechanism. In another exemplary embodiment, the control logic 800 may store the left rail vertical head loss value in one or more fields, parameters, characteristics, or metadata in memory on the client or server. The control logic then proceeds to step 834.

[0152] In step 834, the control logic 800 may receive an end gauge face loss value for the left rail. For example, gauge face loss is the erosion of the railhead surface facing the gauge side of the railway track. As the wheels rotate through a curve, the wheels on both the high and low rails can generate lateral gauge extension forces. In particular, wear on the gauge surface of the rail can be caused by contact loads applied to the sides of the railhead by the wheel flanges. In one exemplary embodiment, the control logic 800 may display an input object to receive the end left rail gauge face loss value. For example, an input object such as a text box, radio buttons, checkboxes, or other appropriate input objects may be displayed by the control logic 800 on the client or server. In another exemplary embodiment, the input object may be configured to receive user input such as a screen tap, swipe, mouse click, key press, voice command, or other appropriate mechanism. In another exemplary embodiment, the control logic 800 may store the end left rail gauge face loss value in one or more fields, parameters, characteristics, or metadata in memory on the client or server. Next, the control logic 800 proceeds to step 836.

[0153] In step 816, the control logic 800 may receive notification of whether an end transition rail is required for the right rail. A transition rail is a track component that can connect two different rail sections. In one exemplary embodiment, the control logic 800 may display an input object to receive an end right transition rail notification. For example, an input object such as a text box, radio button, checkbox, or other appropriate input object may be displayed by the control logic 800 on the client or server. In another exemplary embodiment, the input object may be configured to receive user input such as a screen tap, swipe, mouse click, key press, voice command, or other appropriate mechanism. In another exemplary embodiment, the control logic 800 may store the end right transition rail notification in one or more fields, parameters, characteristics, or metadata in memory on the client or server. If an end right transition rail is required, the control logic 800 proceeds to step 838. If an end right transition rail is not required, the control logic 800 proceeds to step 846.

[0154] In step 828, the control logic 800 may receive notification of whether the end right transition rail is shipped in an unfixed state or welded at the plant. In one exemplary embodiment, the control logic 800 may display an input object to receive the end right transition rail shipment notification. For example, the control logic 800 may display an input object on the client or server, such as a text box, radio buttons, checkboxes, or other appropriate input objects. In another exemplary embodiment, the input object may be configured to receive user input such as screen taps, swipes, mouse clicks, key presses, voice commands, or other appropriate mechanisms. In another exemplary embodiment, the control logic 800 may store the end right transition rail shipment notification in one or more fields, parameters, characteristics, or metadata in memory on the client or server. If the end right transition rail shipment is shipped in an unfixed state, the control logic 800 proceeds to step 840. If the end right transition rail shipment is welded at the plant, the control logic 800 proceeds to step 840.

[0155] In step 840, the control logic 800 can receive the end parent rail weight for the right rail. In one exemplary embodiment, the control logic 800 can display an input object to receive the end right rail parent rail weight. For example, the input object, such as a text box, radio button, checkbox, or other appropriate input object, can be displayed by the control logic 800 on the client or server. In another exemplary embodiment, the input object can be configured to receive user input such as a screen tap, swipe, mouse click, key press, voice command, or other appropriate mechanism. In another exemplary embodiment, the control logic 800 can store the end right rail parent rail weight in one or more fields, parameters, characteristics, or metadata in memory on the client or server. For example, the rail weight may range from 100 pounds to 150 pounds. The control logic 800 then proceeds to step 842.

[0156] In step 842, the control logic 800 may receive a vertical head loss value for the right rail. For example, vertical head loss is the shortening of the railhead due to locomotive movement on the rail. In one exemplary embodiment, the control logic 800 may display an input object to receive the right rail vertical head loss value. For example, an input object such as a text box, radio button, checkbox, or other appropriate input object may be displayed by the control logic 800 on the client or server. In another exemplary embodiment, the input object may be configured to receive user input such as a screen tap, swipe, mouse click, key press, voice command, or other appropriate mechanism. In another exemplary embodiment, the control logic 800 may store the right rail vertical head loss value in one or more fields, parameters, characteristics, or metadata in memory on the client or server. The control logic then proceeds to step 844.

[0157] In step 844, the control logic 800 can receive an end gauge face loss value for the right rail. For example, gauge face loss is the erosion of the railhead surface facing the gauge side of the railway track. As the wheels rotate through a curve, the wheels on both the high and low rails can generate lateral gauge extension forces. In particular, wear on the gauge surface of the rail can be caused by the contact load applied to the side of the railhead by the wheel flange. In one exemplary embodiment, the control logic 800 can display an input object to receive the end right rail gauge face loss value. For example, an input object such as a text box, radio button, checkbox, or other appropriate input object can be displayed by the control logic 800 on the client or server. In another exemplary embodiment, the input object can be configured to receive user input such as a screen tap, swipe, mouse click, key press, voice command, or other appropriate mechanism. In another exemplary embodiment, the control logic 800 can store the end right rail gauge face loss value in one or more fields, parameters, characteristics, or metadata in memory on the client or server. Next, the control logic 800 proceeds to step 846.

[0158] In step 846, the control logic 800 can instantiate the inspection completion algorithm, which is further detailed in Figure 9.

[0159] Figure 9 shows a flowchart illustrating the rail inspection completion control logic 900 according to one or more exemplary embodiments of the present disclosure. The rail inspection completion control logic 900 can be implemented as an algorithm on a server 304, a machine learning module, a client 302, a database 306, or other suitable system. In addition, the rail inspection completion control logic 900 can implement or incorporate one or more features of the STAMP planning system 206, including a plan initialization module 116, an asset association module 118, and a plan generation module 120. The rail inspection completion control logic 900 can be implemented by software, hardware, an application programming interface (API), a network connection, a network transport protocol, HTML, DHTML, JavaScript, Dojo, Ruby, Rails, or other suitable applications, or a suitable combination thereof. One or more exemplary embodiments of the inspection completion control logic 900 may be shown in Figures 14B to 14D.

[0160] The rail inspection completion control logic 900 can leverage the capabilities of a computer platform to generate multiple processes and threads by processing data simultaneously. The speed and efficiency of the rail inspection completion control logic 900 can be significantly improved by instantiating multiple processes to implement inspection completion. However, those skilled in programming will understand that the use of a single processing thread may also be utilized and is within the scope of this disclosure.

[0161] The rail inspection completion control logic 900 of this embodiment is initiated in step 846, where the control logic 900 can receive inspection completion instance generation according to step 846 in Figure 8. In one exemplary embodiment, the control logic 900 can display one or more questions relating to the completion of the inspection. In another exemplary embodiment, the control logic 900 can display an inspection completion screen. In another exemplary embodiment, any inspection completion command or data can be received via user input generated on the client or server, such as screen taps, swipes, mouse clicks, key presses, voice commands, or other appropriate mechanisms. In another exemplary embodiment, the inspection completion command or data may include inspection data having one or more fields, parameters, characteristics, or metadata relating to the inspection. All inspection completion data can be stored in memory on the client or server. The control logic 900 then proceeds to step 902.

[0162] In step 902, the control logic 900 may receive notification of whether a STAMP funding plan should be generated. In another exemplary embodiment, the control logic 900 may automatically input notification of whether a STAMP funding plan should be generated, as determined by the inspection data, historical data, or the STAMP system. If a STAMP plan should be generated, the control logic 900 proceeds to step 904. If a STAMP plan should not be generated, the control logic 900 proceeds to step 912.

[0163] In step 904, the control logic 900 can receive maintenance activities. For example, maintenance activities may include relay wood, gauge, or other appropriate maintenance activities. In another exemplary embodiment, the control logic 900 can automatically input maintenance activities from inspection data, historical data, or as determined by the STAMP system. The control logic 900 then proceeds to step 906.

[0164] In step 906, the control logic 900 can receive relay reason codes. For example, maintenance activities may include combined rail wear, gauge face loss, vertical head loss, internal defects, surface defects, rail exceptions, bolt condition, or other appropriate reason codes. In another exemplary embodiment, the control logic 900 may automatically input relay reason codes from inspection data, historical data, or as determined by the STAMP system. The control logic 900 then proceeds to step 908.

[0165] In step 908, the control logic 900 can receive the budget year for planning. In one exemplary embodiment, the control logic 900 may automatically input the budget year from inspection data, historical data, or as determined by the STAMP system. The control logic 900 then proceeds to step 910.

[0166] In step 910, the control logic 900 may receive a funding code. For example, the funding code may include a code relating to a domain, technology, model, or other appropriate code. In another exemplary embodiment, the control logic 900 may automatically input the funding code from inspection data, historical data, or as determined by the STAMP system. The control logic 900 then proceeds to step 912.

[0167] In step 912, the control logic 900 can receive comments related to the plan. For example, the funding code may include codes related to the domain, technology, model, or other appropriate codes. In another exemplary embodiment, the control logic 900 may automatically input comments from inspection data, historical data, or as determined by the STAMP system. The control logic 900 then proceeds to step 914.

[0168] In step 914, the control logic 900 may receive notification that the STAMP funding plan should be uploaded or marked for upload. For example, the plan may be uploaded directly from the client to the STAMP system, or it may be marked for upload at a later date. In another exemplary embodiment, if the client lacks network connectivity, the plan may be marked for upload when the client regains network connectivity. If the STAMP plan should be uploaded, the control logic 900 proceeds to step 916. If the STAMP plan should be marked for upload, the control logic 900 proceeds to step 920.

[0169] In step 914, the control logic 900 may save the plan to the database. In one exemplary embodiment, the control logic 900 may call an authentication module to generate an authentication token for access to the STAMP system. The control logic may transfer the plan to the STAMP system for storage in the database in memory. The control logic 900 then proceeds to step 918.

[0170] In step 918, the control logic 900 may make API calls to access or process planning data. In one exemplary embodiment, the API may reside on the STAMP system. In another exemplary embodiment, the API may be operably coupled to a WebUI. The control logic 900 then proceeds to step 922.

[0171] In step 922, the control logic 900 can receive a home inspection command to instantiate the STAMP dashboard system 204. In one exemplary embodiment, the control logic 900 can display a home screen. In another exemplary embodiment, any command or data can be received via user input generated on the client or server, such as screen taps, swipes, mouse clicks, key presses, voice commands, or other appropriate mechanisms. In another exemplary embodiment, the command or data may include inspection data having one or more fields, parameters, characteristics, or metadata related to the inspection. All inspection data can be stored in memory on the client or server.

[0172] Figure 10 shows an exemplary embodiment of the interface of a STAMP inspection system according to one or more exemplary embodiments of the present disclosure. In one exemplary embodiment, an asset selection screen 1000 may be displayed on the client. In another exemplary embodiment, the client may display one or more icons for selecting rail assets. For example, the client processor may display icons on the client for rails 1002, ballast 1004, panels 1006, sleepers 1008, turnouts 1010, other items 1012, and management 1014, in addition to other related assets. The icons can be assigned asset types and can instantiate one or more algorithms related to asset types. For example, selecting an asset type icon may result in the display of another screen or the presentation of a prompt related to rail asset types.

[0173] Figures 11A to 11E illustrate illustrative embodiments of the inspection generation interface according to one or more exemplary embodiments of the present disclosure. In relation to Figure 11A, a home (dashboard) screen 1100 is shown. In one exemplary embodiment, the home screen 1100 may include one or more icons that can instantiate one or more processes or algorithms. Icons may include text, images, and / or software objects. For example, the home screen 1100 may include a home icon 1102, an inspection generation icon 1104, a plan download icon 1106, an inspection search icon 1108, and further item icons 1110, in addition to other relevant icons. In another exemplary embodiment, the home screen 1100 may include labels 1112 for categorizing various inspections and / or financial plans. For example, labels 1112 may include lists of recently worked tasks, future tasks, and current tasks, in addition to other relevant categories. For recently worked tasks (e.g., inspection, planning, etc.), the home screen 1100 may display the status 1114, project description 1116, timestamp 1118, task ID, location, or other information related to the task under the recent work label 1112. In another exemplary embodiment, the home screen 1100 may include all upload icons 1119 that can facilitate the transfer of one or more tasks to the database. All upload icons 1119 can instantiate an authentication module 126 to facilitate data transfer.

[0174] In relation to Figure 11B, the inspection generation screen 1120 is shown. In one exemplary embodiment, the inspection generation screen 1120 may be displayed when an inspection generation icon 1104 is selected. In another exemplary embodiment, the inspection generation screen 1120 may display a project description prompt having a corresponding project description input object 1122. In another exemplary embodiment, a network-connected processor may display an input object on the client to receive user input. The network-connected processor may prompt the user by displaying a button, graphic, or other appropriate widget on the client. For example, an input object such as a text box, radio button, checkbox, or other appropriate input object may be displayed by the network-connected processor on the client or server. In another exemplary embodiment, the input object may be configured to receive user input such as a screen tap, swipe, mouse click, key press, voice command, or other appropriate mechanism. For example, the network-connected processor may display a text box and keyboard on the client to receive a project description. In another exemplary embodiment, the network-connected processor may save or update the project description in a database on the client or server.

[0175] In relation to Figure 11C, the inspection generation screen 1120 is shown. In another exemplary embodiment, once a project description is received, the network-connected processor may display prompts to receive asset descriptions relevant to the asset inspection. For example, the network-connected processor may display a trajectory shape selection prompt 1132 with a corresponding input object, a trajectory type definition prompt 1134 with a corresponding input object, or other appropriate prompts with corresponding input objects. Once data is entered or selected using input objects, the data can be stored in a database field related to the prompt. In another exemplary embodiment, once all requested asset description data has been received, an inspection start icon 1136 may be displayed on the inspection generation screen 1120 to display an inspection start screen or other appropriate display screen on the client.

[0176] In Figures 11D to 11E, after the inspection has started, the networked processor may display prompts related to the asset type. In another illustrative embodiment, when the track number specification prompt 1142 is displayed, the input object may be a selection list 1143 related to the track number specification prompt 1142, displayed in a window overlaid on at least a portion of the client display. For a particular asset type for asset description, the networked processor may display one or more relevant prompts. For example, the networked processor may display a specified curve member prompt 1152, a curved rail specification feasibility prompt 1154, a rail position specification prompt 1156, or other appropriate prompts related to the asset type for asset description. Each prompt may have its corresponding input object. Upon receiving a response to a prompt, the networked prompt may retrieve one or more criteria for description from the database. The criteria may be displayed as prompts on the client. Once all relevant asset description responses have been received, the processor can start the inspection.

[0177] Figures 12A–12B illustrate illustrative embodiments of an inspection workflow interface according to one or more exemplary embodiments of the present disclosure. Figures 12A–12B show a start rail screen 1200. In one exemplary embodiment, the start rail screen 1200 may include one or more icons that can instantiate one or more processes or algorithms. Icons may include text, images, and / or software objects. For example, the start rail screen 1200 may include a start icon 1212, a body icon 1214, an end icon 1216, a complete icon 1218, and a photo icon 1220, in addition to other related icons. In another exemplary embodiment, each of icons 1212, 1214, 1216, 1218, and 1218 may correspond to different aspects of an asset inspection workflow. In another exemplary embodiment, each of icons 1212, 1214, 1216, 1218, and 1218 may be displayed based on an inspection workflow for an received asset type. In another exemplary embodiment, the start rail screen 1200 may include one or more icons that can instantiate one or more processes or algorithms.

[0178] In one exemplary embodiment, a start rail location prompt 1202 can be displayed on the client via a network-connected processor. In another exemplary embodiment, the rail location can be determined via GPS coordinates received by the selection of a location acquisition input object 1204. For example, the GPS coordinates may include latitude and longitude values. In another exemplary embodiment, the start rail location can be determined from user input into a prompt and associated text box input object, and a line segment input prompt 1206 can be displayed on the client along with a milepost input prompt 1208. In one exemplary embodiment, data input into the input object for line segment input 1206 or milepost input 1208 may result in overriding the latitude and longitude coordinates received from the GPS device. The network processor can display a start transition rail request prompt 1210 to determine whether a prompt related to a transition rail should be displayed. If the processor receives "no" as input, the network-connected processor can skip the prompt for transition rail inspection. If the processor receives "yes" as input, a network-connected processor may display prompts for transition rail checks. For example, the processor may display at least one prompt 1222 for the start parent rail weight and a prompt 1224 for the start transition rail shipment, which relates to the "yes" transition rail prompt.

[0179] Figures 13A–13B illustrate an exemplary embodiment of a body annotation interface according to one or more exemplary embodiments of the present disclosure. The processor can display a body screen 1300 having one or more prompts relating to asset type, asset description, location, or other appropriate data. For example, the body screen 1300 may include inspection prompts for body rail in use year 1302, body rail manufacturer 1304, body rail weight 1308, body vertical head loss 1310, body gauge face loss 1312, sleeper type 1314, timber fastener 1316, and full plate change need 1318. As before, each prompt may include a corresponding input object. In another exemplary embodiment, the input object may be stored in a field in a database. In another exemplary embodiment, the field name for the input object may be the prompt name or a unique identifier associated with the prompt.

[0180] Figures 14A to 14G illustrate one exemplary embodiment of an inspection termination interface according to one or more embodiments of the present disclosure. In relation to Figure 14A, a termination rail screen 1400 is shown. In one exemplary embodiment, the termination rail screen 1400 may include one or more icons that can instantiate one or more processes or algorithms. The icons may include text, images, and / or software objects. In another exemplary embodiment, a termination rail location prompt 1402 may be displayed on the client via a networked processor. In another exemplary embodiment, the rail location may be determined via GPS coordinates received by selection of a location acquisition input object 1404. For example, the GPS coordinates may include latitude and longitude values. In another exemplary embodiment, the termination rail location may be determined from user input into a prompt and associated text box input object, and a milepost input prompt 1406 may be displayed on the client. In another exemplary embodiment, data input into the input object for milepost input 1208 may result in overriding latitude and longitude coordinates received from a GPS device. In another exemplary embodiment, the network processor may display a measured feet input 1408, an insulation joint amount input prompt 1410, or other appropriate prompts. The network processor may display an end transition rail need prompt 1412 to determine whether a prompt related to the end of a transition rail should be displayed. If the processor receives "no" as input, the networked processor may skip the prompt for end transition rail inspection. If the processor receives "yes" as input, the networked processor may display a prompt for transition rail inspection. For example, the processor may display a prompt related to the end transition rail status. The end transition rail need prompt may only be displayed if the transition rail need is determined to be "yes".In another exemplary embodiment, a pause icon can be displayed on any screen to pause the inspection capture and save the received response.

[0181] In relation to Figures 14B to 14D, a completion screen 1420 is shown. In one exemplary embodiment, the completion screen 1420 may include one or more icons that can instantiate one or more processes or algorithms. The icons may include text, images, and / or software objects. In another exemplary embodiment, the STAMP system 200 may display a STAMP plan generation 1422 from the inspection prompt to determine whether it should transition from inspection capture to a financial plan. If "yes" is selected, in one exemplary embodiment, the inspection response and prompt can be stored in the inspection record and transmitted to the financial plan that can be instantiated. The inspection record may include a header or metadata indicating the date of record generation and the name of the generator, in addition to other relevant data. In another exemplary embodiment, the inspection record can be uploaded to a database if "yes" is selected. If "no" is selected, in another exemplary embodiment, the inspection response and prompt can be stored in the inspection record without the instantiated financial plan. A comment prompt 1424 can be displayed on the client to capture any relevant notes related to the inspection. For example, any received comments can be saved in the inspection record. In one exemplary embodiment, if a STAMP plan should be generated from the inspection, the processor may display a prompt 1426 for determining the maintenance activity. For example, the maintenance activity may be a relay-wood or gauge, in addition to other relevant activities. In another exemplary embodiment, if a relay-wood maintenance activity is received, the networked processor may display further prompts related to that maintenance activity, such as a relay reason code selection 1428, a budget year input 1430, a funding code 1432, and comments 1434, in addition to other relevant prompts.

[0182] In relation to Figure 14E, a photographic screen 1440 is shown. In one exemplary embodiment, the photographic screen 1440 may include one or more icons that can instantiate one or more processes or algorithms. The icons may include text, images, and / or software objects. In another exemplary embodiment, a network-connected processor may display one or more photographic prompts 1442 for uploading one or more images related to the inspection. In relation to Figure 14F, once all the inspection data has been received, the network-connected processor may display an alert 1436 related to the inspection. In one exemplary embodiment, the alert 1436 may display a save prompt to the user to determine whether the processor should save the inspection to an inspection record in the database. In another exemplary embodiment, the alert 1436 may be displayed in a window overlaid on at least a portion of the client display. The display below the window may be grayed out to highlight the importance of the alert.

[0183] In relation to Figure 14G, once the inspection is complete, the workflow can return to the home (dashboard) screen 1100. In one illustrative embodiment, the home screen 1100 may include labels 1412 for classifying various inspections and / or financial plans. For example, labels 1412 may include lists of recently worked tasks, future tasks, and current tasks, in addition to other relevant categories. For recently worked tasks (e.g., inspections, plans, etc.), under the Recent Works label 1112, the home screen 1100 may display the status 1114, project description 1116, timestamp 1118, task ID, location, or other relevant information related to the task. In another illustrative embodiment, further tasks may be displayed within the home screen 1100. For example, for a second recently worked task, under the Recent Works label 1112, the home screen 1100 may display the status 1438, project criteria 1440, timestamp 1442, task ID, location, or other relevant information related to the task. In another exemplary embodiment, the home screen 1100 may include all upload icons 1119 that can facilitate the transfer of one or more tasks to the database. All upload icons 1119 can instantiate an authentication module 126 to facilitate data transfer.

[0184] This disclosure provides at least the following advantages: 1. In addition to other technical improvements, the organization and accessibility of asset inspection and maintenance have been improved. 2. Asset inspection and inspector efficiency are increased through an improved system that allows for the addition and modification of prompts based on responses. 3. It provides a unified platform to facilitate railway asset inspections. 4. Provide a centralized and accessible data model and standards for assets throughout the entire railway infrastructure, thereby enabling relatively fast and relatively well-informed decision-making.

[0185] Those skilled in the art will readily understand that these advantages (and not only those advantages outlined) and objectives of this system would not be possible without the specific combination of computer hardware and other structural components and mechanisms assembled in this invention and described herein. It should be further understood that various programming tools known to those skilled in the art are available to implement the control of the features and operations described above. Furthermore, the specific choice of one or more programming tools may be governed by the specific objectives and constraints imposed on the implementation plan chosen to realize the concepts described herein and in the appended claims.

[0186] The descriptions in this patent document should not be construed to mean that any particular element, step, or function may be an essential or important element that must be included within the scope of the claims. Furthermore, no claim can be construed as invoking Section 112(f) of the U.S. Patent Act in relation to any of the appended claims or claim elements unless the exact terms “means for” or “step for” are explicitly used within a particular claim followed by a participial phrase identifying a function. The use of terms such as (but not limited to) “mechanism,” “module,” “apparatus,” “unit,” “component,” “element,” “member,” “apparatus,” “machine,” “system,” “processor,” “processing device,” or “controller” in a claim can be understood and interpreted as meaning a structure known to those skilled in the art, which is further modified or improved by the features of the claim itself, and cannot be construed as invoking Section 112(f) of the U.S. Patent Act.

[0187] This disclosure can be implemented in other specific forms without departing from its spirit or fundamental characteristics. For example, each of the novel structures described herein can be modified to suit specific local variations or requirements, while retaining its basic configuration and structural relationships with one another, or while performing the same or similar functions described herein. Accordingly, these embodiments should be considered in all respects as illustrative rather than restrictive. Accordingly, the scope of the invention can be established by the appended claims rather than by the foregoing description. Accordingly, all changes included in the meaning and scope of the equivalents of the claims should be interpreted as being encompassed therein. Furthermore, the individual elements of the claims are not well understood, commonplace, or conventional. Instead, the claims concern non-conventional inventive concepts described herein.

Claims

1. A system for generating track and maintenance plan inspection records for railway assets, A memory having a first database having multiple inspection records, thresholds, and specifications related to assets, A network-connected computer processor operably coupled to the memory and capable of executing machine-readable instructions to execute program steps, It has, The aforementioned program step is: Steps to receive asset type and asset description, The steps include: initiating an asset inspection via the network-connected computer processor based at least partially on the asset type or asset description; Steps to receive the client's location, The steps include obtaining asset data having fields relating to one or more inspections relating to the location, the asset type, or the asset description, via a server operably connected to an encrypted network, The steps include generating step-by-step inspection prompts based on the acquired asset data via the network-connected computer processor, The steps include displaying a first step-by-step inspection prompt on the client, The step of receiving a response to the inspection prompt or a validation of an automatically entered response, wherein the automatically entered response includes a historical value for a field related to the inspection, which has been automatically entered into an input object related to the inspection prompt. Steps include analyzing the response or validation to generate and display one or more customized test prompts, The steps include receiving a customized response to the customized test prompt, The steps include providing adaptive thresholding of criteria related to infrastructure assets in order to determine when infrastructure asset maintenance should occur, The steps include generating track and maintenance plan inspection records for railway assets, including the response, maintenance timing and the customized response, via the network-connected computer processor, A system that has

2. The system according to claim 1, wherein the asset type is rail, ballast, panel, sleeper, switch, or facility.

3. The system according to claim 1, wherein the customized inspection prompt is displayed only after the receipt of the response.

4. The system according to claim 1, wherein the location of the client determines the type of inspection prompt to be sent to the client.

5. The system according to claim 1, wherein the asset type of the client determines the type of inspection prompt to be sent to the client.

6. The system according to claim 1, wherein the client's asset description determines the type of inspection prompt to be sent to the client.

7. The system according to claim 1, wherein the response or customized response is stored in one or more fields, parameters, characteristics, or metadata in the first database.

8. The system according to claim 1, wherein the thresholding process changes based on at least one of historical data, inspection data, season, temperature, cost, or budget.

9. The system according to claim 1, wherein the location of the client can be received via the input object or GPS device operably coupled to the client.

10. The system according to claim 1, wherein the historical values ​​are obtained from the first database.

11. A method for generating track and maintenance plan inspection records for railway assets, The process involves receiving the asset type and asset description via the processor, The steps include: initiating an asset check via the processor based at least partially on the asset type or asset description; The steps include receiving the client's location via the aforementioned processor, The steps include obtaining asset data having fields relating to one or more inspections relating to the location, the asset type, or the asset description, via a server operably connected to an encrypted network, The process involves generating step-by-step inspection prompts based on the acquired asset data via the aforementioned processor, The steps include displaying a first step-by-step inspection prompt on the client, The processor receives verification of a response to the inspection prompt or an automatically entered response, the automatically entered response includes a step of including historical values ​​for fields related to the inspection, which are automatically entered into an input object related to the inspection prompt, The steps include analyzing the response or verification via the processor to generate and display one or more customized inspection prompts, The steps include receiving a customized response to the customized test prompt via the processor, The process involves providing adaptive thresholding of criteria related to infrastructure assets via the aforementioned processor in order to determine when infrastructure asset maintenance should occur. The steps include generating track and maintenance plan inspection records for railway assets, including the response, maintenance timing and the customized response, via the processor; A method of having.

12. The method according to claim 11, wherein the asset type is rail, ballast, panel, sleeper, switch, or facility.

13. The method according to claim 11, wherein the customized inspection prompt is displayed only after the receipt of the response.

14. The method according to claim 11, wherein the location of the client determines the type of inspection prompt to be sent to the client.

15. The method according to claim 11, wherein the asset type of the client determines the type of inspection prompt to be sent to the client.

16. The method according to claim 11, wherein the client's asset description determines the type of inspection prompt to be sent to the client.

17. The method according to claim 11, wherein the response or customized response is stored in one or more fields, parameters, characteristics, or metadata in the database.

18. The method according to claim 11, wherein the thresholding process changes based on at least one of historical data, inspection data, temperature, or budget.

19. The method according to claim 11, wherein the client's location can be received via the input object or a GPS device operably coupled to the client.

20. The method according to claim 11, wherein the historical value is obtained from a first database.

21. A track and maintenance planning inspection system for managing railway infrastructure inspection records, Having one or more computer processors, The aforementioned computer processor To generate a user interface that can be displayed on the client for inputting, receiving, and selecting one or more attributes related to railway infrastructure asset inspection, To receive the location of the aforementioned client, To automatically determine one or more asset components for the railway infrastructure asset inspection based at least partially on the client location, Based on the asset data for one or more asset components, generate step-by-step inspection prompts. To initiate the inspection of the railway infrastructure assets, send the step-by-step inspection prompts to the client. To determine when infrastructure asset maintenance should occur, and to provide adaptive thresholding of criteria related to infrastructure assets, To generate, capture, or complete the aforementioned railway infrastructure asset inspection, A system that is composed of.

22. A method for managing railway infrastructure inspection records, The steps include generating a user interface that can be displayed on a client for inputting, receiving, and selecting one or more attributes related to railway infrastructure asset inspection via a processor, The steps include receiving the client's location via the geolocation module through the processor, The steps include: via the processor, automatically determining one or more asset components for the railway infrastructure asset inspection based at least partially on the client location; The process involves generating a plurality of step-by-step inspection prompts based on asset data for one or more asset components via the processor, The steps include sending the plurality of step-by-step inspection prompts to the client via the processor to initiate the railway infrastructure asset inspection, The steps include providing adaptive thresholding of criteria related to infrastructure assets in order to determine when infrastructure asset maintenance should occur, The steps include capturing the railway infrastructure asset inspection via the aforementioned processor, A method of having.

Images