WO2025219982A1

WO2025219982A1 - Systems and methods for analyzing track geometry data for track monitoring and defect detection

Info

Publication number: WO2025219982A1
Application number: PCT/IB2025/054167
Authority: WO
Inventors: Ranjan Dash; Darrell R. KRUEGER; Andrew WHITMAN; Joshua J. McBain; Corey D. Wills; Shivanand L. ATRE; Srilakshmi TAYI; Nicholaus FOSTER; Charity M. Duran
Original assignee: BNSF Railway Co
Current assignee: BNSF Railway Co
Priority date: 2024-04-18
Filing date: 2025-04-22
Publication date: 2025-10-23
Anticipated expiration: 2026-10-18

Abstract

Systems and techniques for analyzing track geometry data (TGD) for railroad track analysis. In embodiments, a system captures and processes rail profile data for detecting defects on a railroad track. An on-board rail profile capture system, mounted to a railroad vehicle, captures rail profile data at regular intervals as the vehicle traverses the track. A main computer receives the rail profile data and generates track geometry data. A backend rail profile processing system receives the TGD, validates the TGD, analyzes the validated TGD to determine rail defects, validates the rail defects to determine whether they are real defects or false positives, and generates notifications and alerts based on the validated defects. The system utilizes machine learning algorithms and models for defect detection and validation.

Description

SYSTEMS AND METHODS FOR ANALYZING TRACK GEOMETRY DATA FOR TRA CK MONITORING AND DEFECT DETECTION

CROSS-REFERENCE TO RELATED APPLICATION

[0001] The present application claims the benefit of United States Non-Provisional Patent Application Serial No. 19/183,365, filed April 18, 2025, which claims priority to United States Provisional Patent Application Serial No.63/636, 027, filed April 18, 2024, which is incorporated herein by refemece for all purposes.

TECHNICAL FIELD

[0002] The present disclosure relates generally to railway track monitoring technology, and more particularly to systems and methods for analyzing track geometry data for track monitoring and defect detection.

BACKGROUND

[0003] Railway tracks are a cornerstone of the global transportation infrastructure, enabling the efficient and reliable movement of goods and passengers over long distances. The structural integrity and operational reliability of these tracks are of paramount concern to railway operators, as the safety of millions of passengers and the timely delivery of cargo hinge upon their condition. Over time, tracks are susceptible to a multitude of defects arising from wear, environmental factors such as temperature fluctuations and corrosion, and the stress of bearing the weight and vibrations of passing trains.

[0004] Traditionally, railway track inspection has been a manual process, with track inspectors employing a variety of specialized tools to measure track parameters such as alignment, gauge, and elevation. This manual inspection process, while thorough, is inherently slow and labor-intensive, making it difficult to cover extensive track networks comprehensively. The precision of these inspections is also limited by human factors, including variability in measurement techniques and the potential for error.

[0005] The limitations of manual inspections have prompted the industry to explore automated solutions that can offer continuous, precise, and non-intrusive monitoring of track conditions. Such automated systems promise to revolutionize track maintenance by enabling early detection of potential issues, thereby allowing for timely interventions that can prevent accidents and reduce maintenance costs. However, the adoption ofthese advanced technologies has been a complex process, with technical, financial, and operational challenges to address.

[0006] While some automated systems for track inspection have been developed, they often fall short in terms of robustness and transparency. Many of these systems are proprietary, which poses a challenge for railway operators who are ultimately responsible for the condition of the tracks. Without a clear understanding of how these systems operate and the methodologies they employ for inspection, operators cannot fully assess the effectiveness or reliability of the inspections. This lack of transparency and control is a major concern, as operators are tasked with ensuring the safety and integrity of the railway infrastructure.

[0007] The proprietary nature of existing systems can also lead to vendor lock-in, where operators are dependent on a single supplier for updates, maintenance, and support, which can be both costly and limiting in terms of flexibility to adapt to new requirements or integrate with other systems. Despite these challenges, the pursuit of improved track inspection methods remains a high priority, driven by the imperative to enhance the safety and efficiency of rail transport in an increasingly fast-paced and interconnected world. SUMMARY

[0008] The present disclosure achieves technical advantages as systems, methods, and computer-readable storage media for analyzing track geometry data for track monitoring and defect detection. In embodiments, a system may be configured to enhance the safety and reliability of railway transportation by providing a comprehensive solution for railway track monitoring and defect detection. The system of embodiments is configured to capture the profile of the rails on a train track with high precision, utilize the captured profile information to calculate the geometry of the train track, and employ these geometry calculations to identify potential defects on the track. The system’s capabilities extend to generating detailed reports and alerts based on the identified defects, facilitating timely and informed maintenance decisions.

[0009] In embodiments, an on-board rail profile capture system may be mounted to a railroad vehicle. As the vehicle traverses the track, the system continuously captures the rail profile data at predetermined intervals. This rail profile data serves as the foundation for calculating various aspects of track geometry over several channels, which are indicative of the track’s condition. The system’s ability to operate at high speeds without compromising on data accuracy or resolution represents a substantial improvement over traditional manual inspection methods.

[0010] The calculated track geometry data is validated by the backend processing system to filter out invalid TGD. The validated TGD is then analyzed to detect any irregularities or deviations from predefined standards that may signal the presence of defects. This analysis is not a trivial task, as it involves the processing of large volumes of data to distinguish between normal variations in track geometry and actual defects that could compromise the safety of rail operations. To achieve this, the system employs sophisticated algorithms, including machine learning techniques, which are adept at identifying patterns and anomalies within complex datasets.

[0011] Once potential defects are identified, the system validates the defects to determine whether the defect is a false positive or a real defect. Based on validated defects, the system generates alerts and reports that provide detailed information about the nature and location of the defects. These reports are instrumental for railway maintenance crews, enabling them to prioritize and carry out repair work effectively. The system’s ability to generate realtime alerts ensures that any immediate risks to rail safety are communicated promptly, allowing for swift action to prevent accidents.

[0012] As such, the present disclosure provides for a system integrated into a practical application with meaningful limitations as that represent an improved system for railroad track monitoring, combining advanced data capture technology with powerful analytical tools to ensure the integrity of railway infrastructure. The advantageous result of the features of the system described herein provides several technical advantages that collectively enhance railroad track monitoring, offering increased safety, reduced maintenance costs, and a streamlined, non-intrusive inspection process in line with modem operational demands.

[0013] For example, the TGD validation functionality of embodiments represents a technical improvement as it enhances the accuracy and reliability of defect detection. The TGD validation functionality systematically filters out noise and false positives, ensuring that maintenance efforts are focused on genuine track irregularities. The precision of TGD validation minimizes unnecessary maintenance activities, which serve to optimize resource allocation and reducing operational costs. Furthermore, the ability to validate TGD in realtime contributes to the safety of rail transport by enabling prompt identification and rectification of track defects that could otherwise lead to derailments or other accidents. This proactive approach to track maintenance ensures the integrity of the railway infrastructure and the safety of passengers and cargo, while also extending the lifespan of the railway assets through timely and targeted interventions. Overall, the TGD validation functionality represents a technological advancement that transforms traditional track inspection methods into a more efficient, accurate, and data-driven process.

[0014] Furthermore, the defect validation functionality of embodiments represents a significant technical improvement. This advanced defect validation process ensures that maintenance efforts are concentrated on actual track irregularities, enhancing the efficiency of resource utilization and reducing unnecessary maintenance costs. The capability to validate defects in real-time is particularly advantageous, as it allows for the immediate identification and correction of track defects, substantially improving the safety of rail transport. By facilitating the early detection and confirmation of track defects, the defect validation functionality plays a pivotal role in maintaining the structural integrity of the railway infrastructure, ensuring the safety of passengers and cargo, and prolonging the service life of railway assets. This functionality represents a technological improvement, converting the conventional track inspection approach into a more streamlined, precise, and proactive maintenance strategy.

[0015] As such, the present disclosure provides for a system integrated into a practical application with meaningful limitations as that represent an improved system for railroad track monitoring, combining advanced data capture technology with powerful analytical tools to ensure the integrity of railway infrastructure. The advantageous result of the features of the system described herein provides several technical advantages that collectively enhance railroad track monitoring, offering increased safety, reduced maintenance costs, and a streamlined, non-intrusive inspection process in line with modem operational demands. [0016] Thus, it will be appreciated that the technological solutions provided herein, and missing from conventional systems, are more than a mere application of a manual process to a computerized environment, but rather include functionality to implement a technical process to replace or supplement current manual solutions or non-existing solutions for railroad track monitoring. In doing so, the present disclosure goes well beyond a mere application the manual process to a computer. Accordingly, the claims herein necessarily provide a technological solution that overcomes a technological problem.

[0017] In embodiments, the present disclosure includes techniques for training models (e.g., machine-learning models, artificial intelligence models, algorithmic constructs, etc.) for performing or executing a designated task or a series of tasks (e.g., one or more features for TGD generation, defect detection, and/or defect validation in accordance with embodiments of the present disclosure). The disclosed techniques provide a systematic approach for the training of such models to enhance performance, accuracy, and efficiency in their respective applications. In embodiments, the techniques for training the models may include collecting a set of data from a database, conditioning the set of data to generate a set of conditioned data, and/or generating a set of training data including the collected set of data and/or the conditioned set of data. In embodiments, that model may undergo a training phase wherein the model may be exposed to the set of training data, such as through an iterative processes of learning in which the model adjusts and optimizes its parameters and algorithms to improve its performance on the designated task or series of tasks. This training phase may configure the model to develop the capability to perform its intended function with a high degree of accuracy and efficiency. In embodiments, the conditioning of the set of data may include modification, transformation, and/or the application of targeted algorithms to prepare the data for training. The conditioning step may be configured to ensure that the set of data is in an optimal state for training the model, resulting in an enhancement of the effectiveness of the model’s learning process. These features and techniques not only qualify as patent-eligible features but also introduce substantial improvements to the field of computational modeling. These features are not merely theoretical but represent an integration of a concepts into a practical applications that significantly enhance the functionality, reliability, and efficiency of the models developed through these processes.

[0018] In embodiments, the present disclosure includes techniques for generating a notification of an event (e.g., a defect notification, a maintenance required notification, a false positive notification, etc.) includes generating an alert that includes information specifying the location of a source of data associated with the event, formatting the alert into data structured according to an information format; and transmitting the formatted alert over a network to a device associated with a receiver based upon a destination address and a transmission schedule. In embodiments, receiving the alert enables a connection from the device associated with the receiver to the data source over the network when the device is connected to the source to retrieve the data associated with the event and causes a viewer application (e.g., a graphical user interface (GUI)) to be activated to display the data associated with the event. These features represent patent eligible features, as these features amount to significantly more than an abstract idea. These features, when considered as an ordered combination, amount to significantly more than simply organizing and comparing data. The features address the Internet-centric challenge of alerting a receiver with time sensitive information. This is addressed by transmitting the alert over a network to activate the viewer application, which enables the connection of the device of the receiver to the source over the network to retrieve the data associated with the event. These are meaningful limitations that add more than generally linking the use of an abstract idea (e.g., the general concept of organizing and comparing data) to the Internet, because they solve an Internet-centric problem with a solution that is necessarily rooted in computer technology. These features, when taken as an ordered combination, provide unconventional steps that confine the abstract idea to a particular useful application. Therefore, these features represent patent eligible subject matter.

[0019] In embodiments, one or more operations and/or functionality of components described herein can be distributed across a plurality of computing systems (e.g., personal computers (PCs), user devices, servers, processors, etc.), such as by implementing the operations over a plurality of computing systems. This distribution can be configured to facilitate the optimal load balancing of requests, which can encompass a wide spectrum of network traffic or data transactions. By leveraging a distributed operational framework, a system implemented in accordance with embodiments of the present disclosure can effectively manage and mitigate potential bottlenecks, ensuring equitable processing distribution and preventing any single device from shouldering an excessive burden. This load balancing approach significantly enhances the overall responsiveness and efficiency of the network, markedly reducing the risk of system overload and ensuring continuous operational uptime. The technical advantages of this distributed load balancing can extend beyond mere efficiency improvements. It introduces a higher degree of fault tolerance within the network, where the failure of a single component does not precipitate a systemic collapse, markedly enhancing system reliability. Additionally, this distributed configuration promotes a dynamic scalability feature, enabling the system to adapt to varying levels of demand without necessitating substantial infrastructural modifications. The integration of advanced algorithmic strategies for traffic distribution and resource allocation can further refine the load balancing process, ensuring that computational resources are utilized with optimal efficiency and that data flow is maintained at an optimal pace, regardless of the volume or complexity of the requests being processed. Moreover, the practical application of these disclosed features represents a significant technical improvement over traditional centralized systems. Through the integration of the disclosed technology into existing networks, entities can achieve a superior level of service quality, with minimized latency, increased throughput, and enhanced data integrity. The distributed approach of embodiments can not only bolster the operational capacity of computing networks but can also offer a robust framework for the development of future technologies, underscoring its value as a foundational advancement in the field of network computing.

[0020] To aid in the load balancing, the computing system of embodiments of the present disclosure can spawn multiple processes and threads to process data concurrently. The speed and efficiency of the computing system can be greatly improved by instantiating more than one process or thread to implement the claimed functionality. However, one skilled in the art of programming will appreciate that use of a single process or thread can also be utilized and is within the scope of the present disclosure.

[0021] It is an object of the disclosure to provide a method of analyzing track geometry data for track monitoring and defect detection. It is a further object of the disclosure to provide a system for analyzing track geometry data for track monitoring and defect detection, and a computer-based tool for generating TGD for analyzing track geometry data for track monitoring and defect detection. These and other objects are provided by the present disclosure, including at least the following embodiments.

[0022] In one particular embodiment, a method of analyzing track geometry data for track monitoring and defect detection is provided. The method includes receiving, from one or more on-board rail profde capture systems mounted to a railroad vehicle, one or more TGD fdes. In embodiments, each TGD fde of the one or more TGD fdes includes a plurality of TGD records including TGD calculated over a measured distance of a track, and each TGD record of the TGD records is associated with a respective predetermined interval along the track. The method also includes applying one or more defect detection algorithms to the plurality of TGD records to detect one or more potential defects associated with the track, validating the one or more potential defects to determine whether each potential defect is a false positive, discarding potential defects of the one or more potential defects determined to be false positives, generating an alert based on each potential defect of the one or more potential defects determined to be a valid defect, and automatically sending a signal to initiate a corrective action in response to the alert generated for each potential defect of the one or more potential defects determined to be a valid defect.

[0023] In another embodiment, a system for analyzing track geometry data for track monitoring and defect detection is provided. The system comprises at least one processor and a memory operably coupled to the at least one processor and storing processor-readable code that, when executed by the at least one processor, is configured to perform operations. The operations include receiving, from one or more on-board rail profile capture systems mounted to a railroad vehicle, one or more TGD files. In embodiments, each TGD file of the one or more TGD files includes a plurality of TGD records including TGD calculated over a measured distance of a track, and each TGD record of the TGD records is associated with a respective predetermined interval along the track. The operations also include applying one or more defect detection algorithms to the plurality of TGD records to detect one or more potential defects associated with the track, validating the one or more potential defects to determine whether each potential defect is a false positive, discarding potential defects of the one or more potential defects determined to be false positives, generating an alert based on each potential defect of the one or more potential defects determined to be a valid defect, and automatically sending a signal to initiate a corrective action in response to the alert generated for each potential defect of the one or more potential defects determined to be a valid defect. [0024] In yet another embodiment, a computer-based tool for generating TGD for analyzing track geometry data for track monitoring and defect detection is provided. The computer-based tool including non-transitory computer readable media having stored thereon computer code which, when executed by a processor, causes a computing device to perform operations. The operations include receiving, from one or more on-board rail profile capture systems mounted to a railroad vehicle, one or more TGD files. In embodiments, each TGD file of the one or more TGD files includes a plurality of TGD records including TGD calculated over a measured distance of a track, and each TGD record of the TGD records is associated with a respective predetermined interval along the track. The operations also include applying one or more defect detection algorithms to the plurality of TGD records to detect one or more potential defects associated with the track, validating the one or more potential defects to determine whether each potential defect is a false positive, discarding potential defects of the one or more potential defects determined to be false positives, generating an alert based on each potential defect of the one or more potential defects determined to be a valid defect, and automatically sending a signal to initiate a corrective action in response to the alert generated for each potential defect of the one or more potential defects determined to be a valid defect.

[0025] The foregoing has outlined rather broadly the features and technical advantages of the present disclosure in order that the detailed description of the disclosure that follows may be better understood. Additional features and advantages of the disclosure will be described hereinafter which form the subject of the claims of the disclosure. It should be appreciated by those skilled in the art that the conception and specific embodiment disclosed may be readily utilized as a basis for modifying or designing other structures for carrying out the same purposes of the present disclosure. It should also be realized by those skilled in the art that such equivalent constructions do not depart from the spirit and scope of the disclosure as set forth in the appended claims. The novel features which are believed to be characteristic of the disclosure, both as to its organization and method of operation, together with further objects and advantages will be better understood from the following description when considered in connection with the accompanying figures. It is to be expressly understood, however, that each of the figures is provided for the purpose of illustration and description only and is not intended as a definition of the limits of the present disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

[0026] For a more complete understanding of the present disclosure, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:

[0027] FIG. 1 is a block diagram of an exemplary system configured with capabilities and functionality for railway track monitoring and defect detection in accordance with embodiments of the present disclosure.

[0028] FIG. 2 is a block diagram illustrating an example of operations of a backend processing system configured with capabilities and functionality for analyzing track geometry data (TGD) for track monitoring and defect detection in accordance with embodiments of the present disclosure.

[0029] FIG. 3 provides an example representation of the various channels of the TGD in accordance with embodiments of the present disclosure.

[0030] FIG. 4 illustrates an example of a data validation model configured for validating TGD in accordance with embodiments of the present disclosure.

[0031] FIG. 5 illustrates an example of a defect validation model configured for validating an unbalance defect in accordance with embodiments of the present disclosure.

[0032] FIG. 6 illustrates an example of a spike defect validation model configured for validating defects in accordance with embodiments of the present disclosure.

[0033] FIG. 7A illustrates an example of a data set for spike validation in accordance with embodiments of the present disclosure. [0034] FIG. 7B illustrates an example of a data set for spike validation in which no amplitude difference between the anomaly points is greater than the amplitude threshold in accordance with embodiments of the present disclosure.

[0035] FIG. 8 is a flowchart illustrating operations for analyzing track geometry data for track monitoring and defect detection in accordance with embodiments of the present disclosure.

[0036] It should be understood that the drawings are not necessarily to scale and that the disclosed embodiments are sometimes illustrated diagrammatically and in partial views. In certain instances, details which are not necessary for an understanding of the disclosed methods and apparatuses or which render other details difficult to perceive may have been omitted. It should be understood, of course, that this disclosure is not limited to the particular embodiments illustrated herein.

DETAILED DESCRIPTION

[0037] The disclosure presented in the following written description and the various features and advantageous details thereof, are explained more fully with reference to the nonlimiting examples included in the accompanying drawings and as detailed in the description. Descriptions of well-known components have been omitted to not unnecessarily obscure the principal features described herein. The examples used in the following description are intended to facilitate an understanding of the ways in which the disclosure can be implemented and practiced. A person of ordinary skill in the art would read this disclosure to mean that any suitable combination of the functionality or exemplary embodiments below could be combined to achieve the subject matter claimed. The disclosure includes either a representative number of species falling within the scope of the genus or structural features common to the members of the genus so that one of ordinary skill in the art can recognize the members of the genus. Accordingly, these examples should not be construed as limiting the scope of the claims.

[0038] A person of ordinary skill in the art would understand that any system claims presented herein encompass all of the elements and limitations disclosed therein, and as such, require that each system claim be viewed as a whole. Any reasonably foreseeable items functionally related to the claims are also relevant. The Examiner, after having obtained a thorough understanding of the disclosure and claims of the present application has searched the prior art as disclosed in patents and other published documents, i.e., nonpatent literature. Therefore, the issuance of this patent is evidence that: the elements and limitations presented in the claims are enabled by the specification and drawings, the issued claims are directed toward patent-eligible subject matter, and the prior art fails to disclose or teach the claims as a whole, such that the issued claims of this patent are patentable under the applicable laws and rules of this country. [0039] Various embodiments of the present disclosure are directed to systems and techniques that provide functionality for analyzing track geometry data for track monitoring and defect detection. In embodiments, the functionality for analyzing track geometry data for track monitoring and defect detection may include functionality to capture the profde of the rails on a train track with high precision, utilize the captured profde information to calculate the geometry of the train track, and employ these geometry calculations to identify potential defects on the track. The system’s capabilities extend to generating detailed reports and alerts based on the identified defects, facilitating timely and informed maintenance decisions.

[0040] The functionality of a system implemented in accordance with the present disclosure may enable a system to overcome the limitations of manual inspections and proprietary automated systems by providing a robust, non-proprietary solution that offers continuous, precise, and non-intrusive monitoring of track conditions. By utilizing advanced technologies such as machine learning algorithms and models for defect detection and validation, the system 100 ensures a high level of accuracy and transparency in the inspection process, enabling railway operators to maintain the integrity of their tracks with confidence.

[0041] FIG. 1 is a block diagram of an exemplary system 100 configured with capabilities and functionality for analyzing track geometry data for track monitoring and defect detection in accordance with embodiments of the present disclosure. As shown in FIG. 1, system 100 may include an on-board rail profile capture system 110, a backend processing system 150, user terminal 130, and network 145. These components, and their individual components, may cooperatively operate to provide functionality in accordance with the discussion herein. In particular, on-board rail profile capture system 110 may be configured to capture rail profile data at regular intervals as the railroad vehicle traverses a railroad track.

The captured rail profile data may be used to generate TGD 111, which may include a plurality of data channels and may be indicative of the condition of the railroad track 115. On-board rail profde capture system 110 may be in communication with backend processing system 150 (e.g., via a network 145) and may send the TGD 111 to backend processing system 150. Backend processing system 150 may process the TGD 111 to determine the presence of defects on the rail and to generate track defect reports and notifications 151. These track reports and notifications 151 may be used by railway operators to take appropriate maintenance actions to address any identified issues, and in this manner enhance the safety and efficiency of the railway infrastructure.

[0042] It is noted that the functional blocks, and components thereof, of system 100 of embodiments of the present disclosure may be implemented using processors, electronics devices, hardware devices, electronics components, logical circuits, memories, software codes, firmware codes, etc., or any combination thereof. For example, one or more functional blocks, or some portion thereof, may be implemented as discrete gate or transistor logic, discrete hardware components, or combinations thereof configured to provide logic for performing the functions described herein. Additionally, or alternatively, when implemented in software, one or more of the functional blocks, or some portion thereof, may comprise code segments operable upon a processor to provide logic for performing the functions described herein.

[0043] It is also noted that various components of system 100 are illustrated as single and separate components. However, it will be appreciated that each of the various illustrated components may be implemented as a single component (e.g., a single application, server module, etc.), may be functional components of a single component, or the functionality of these various components may be distributed over multiple devices/components. In such embodiments, the functionality of each respective component may be aggregated from the functionality of multiple modules residing in a single, or in multiple devices. [0044] It is further noted that functionalities described with reference to each of the different functional blocks of system 100 described herein is provided for purposes of illustration, rather than by way of limitation and that functionalities described as being provided by different functional blocks may be combined into a single component or may be provided via computing resources disposed in a cloud-based environment accessible over a network, such as one of network 145.

[0045] User terminal 130 may include a mobile device, a smartphone, a tablet computing device, a personal computing device, a laptop computing device, a desktop computing device, a computer system of a vehicle, a personal digital assistant (PDA), a smart watch, another type of wired and/or wireless computing device, or any part thereof. In embodiments, user terminal 130 may provide a user interface that may be configured to provide an interface (e.g., a graphical user interface (GUI)) structured to facilitate an operator interacting with system 100, e.g., via network 145, to execute and leverage the features provided by the cooperative operations of system 100. In embodiments, the operator may be enabled, e.g., through the functionality of user terminal 130, to provide functionality for managing railway track monitoring and defect detection in accordance with embodiments of the present disclosure. In embodiments, the operator may receive track condition reports, track defect reports, notifications, alerts, etc. via the GUI in accordance with embodiments of the present disclosure. In embodiments, user terminal 130 may be configured to communicate with other components of system 100.

[0046] In embodiments, network 145 may facilitate communications between the various components of system 100 (e.g., on-board rail profile capture system 110, backend processing system 150, and/or user terminal 130). Network 145 may include a wired network, a wireless communication network, a cellular network, a cable transmission system, a Uocal Area Network (LAN), a Wireless LAN (WLAN), a Metropolitan Area Network (MAN), a Wide Area Network (WAN), the Internet, the Public Switched Telephone Network (PSTN), etc.

[0047] System 100 is configured to ensure the integrity and safety of railway infrastructure through advanced monitoring and defect detection capabilities. In embodiments, and for the purposes of the present disclosure, the functionality of system 100 may be bifurcated into two main components, each serving a distinct yet interrelated function within the overall system. The first main component includes on-board rail profile capture system 110, which is primarily responsible for the direct acquisition of rail profile data associated with the rails of the railroad track as the railroad vehicle moves along the railroad track. On-board rail profile capture system 110 may be configured to be mounted on the railroad vehicle (e.g., to the underside of the railroad vehicle with line of sight to the rails of the railroad track) and includes the hardware and software elements that enable the capture, initial processing of the rail profile data to generate TGD 111, storage of the rail profile data and TGD 111, and transmission of TGD 111 to backend processing system 150.

[0048] The second main component of system 100 includes backend processing system 150, which may serve as the analytical and reporting hub for the data collected by the on-board rail profile capture system 110. Backend system 150 may be tasked with the more complex processing of TGD 111, including the application of machine learning algorithms and models to accurately identify and classify defects on the railroad track. Additionally, backend processing system 150 may generate the track defect reports and notifications 151 that are instrumental for railway operators in making informed decisions regarding track maintenance and safety measures, and may be used to automatically trigger the actuation of equipment to address the findings in the track defect reports and notifications 151. [0049] Together, the two main components of system 100 form a cohesive system that enhances the predictive maintenance capabilities of railway operators and contributes to the prevention of track-related incidents.

[0050] As noted above, on-board rail profde capture system 110 may be configured to capture precise rail profile data as a railroad vehicle traverses the tracks. This data forms the basis for the subsequent analysis and assessment of the condition of the railway track, enabling the identification of any potential defects that may be present. In embodiments, the configuration of on-board rail profile capture system 110 is optimized for high-speed operation, ensuring that rail profile data can be effectively captured even when the railroad vehicle is moving at high speeds. This is a particularly valuable feature, as it allows for the continuous monitoring of the tracks without disrupting regular railway operations or requiring the vehicle to slow down or stop for inspections.

[0051] In embodiments, on-board rail profile capture system 110 may be configured to capture detailed rail profile data as a railroad vehicle moves along the track. In embodiments, the captured rail profile data includes rail profile data for each rail — left and right — of the track. The rail profile data provides insights into the shape and profile of each rail of the track. As the railroad vehicle travels along the track, on-board rail profile capture system 110 employs its one or more profile capture sensors (e.g., one or more profilometers comprising laser modules in some embodiments), to project laser beams onto the rails (e.g., one laser module per rail). These beams are reflected back and captured by cameras within the one or more profile capture sensors, translating into a series of reflection points that collectively define the rail’s profile. Each reflection point is recorded as an x-y coordinate, relative to the sensor’s position, effectively mapping out the rail’s contour and dimensions at precise intervals. In embodiments, the rail profile data capture may be performed at periodic intervals (e.g., every foot of track traversed).

[0052] In embodiments, TGD 111 may include data related to various channels, each representing a specific aspect of the track’s geometry, such as gauge, crosslevel, alignment, surface, curvature, dips, unbalance, and cant. The data for the TGD channels may be compiled into a TGD file, and may organized according to predefined parameters, such as distance traveled or file size.

[0053] On-board rail profile capture system 110 may intelligently determine when to transmit the TGD file including TGD 111 to backend processing system 150. In this manner, on-board rail profile capture system 110 may not simply be a data collector, but rather an intelligent decision-maker. On-board rail profile capture system 110 determines the opportune moments to transmit the TGD file to the backend processing system 150. On-board rail profile capture system 110 assesses factors such as the file’s size, the distance covered by the vehicle, and the availability of a robust network signal to decide when to send the file. This ensures that backend processing system 150 receives the TGD file in a timely and efficient manner, allowing for the prompt identification of potential track defects and the initiation of maintenance actions. Backend processing system 150, equipped with its own suite of advanced algorithms, further scrutinizes TGD 111 to confirm the presence of defects and to generate the requisite notifications and alerts for railway operators.

[0054] Backend processing system 150 may be configured to provide functionality as the analytical and reporting hub for the data collected by the on-board rail profile capture system 110. Backend system 150 may be configured to process TGD 111 received from onboard rail profile capture system 110 by applying mathematical and machine learning algorithms and models to accurately identify and classify defects on the track. Additionally, backend processing system 150 generates the track defect reports and notifications 151 that are instrumental for railway operators in making informed decisions regarding track maintenance and safety measures.

[0055] For example, upon receiving the TGD file including TGD 111 from on-board rail profile capture system 110, backend processing system 150 may engage in a thorough analysis of TGD 111 across the various TGD channels. Backend processing system 150 may utilize sophisticated machine learning algorithms and models that have been trained to recognize patterns indicative of various types of track anomalies. These could range from minor irregularities that may require monitoring over time, to urgent defects that necessitate immediate intervention. Backend processing system 150’s ability to differentiate between normal variations in track geometry and genuine defects reflects the advanced nature of the algorithms provided by system 100.

[0056] By employing advanced machine learning algorithms and models, backend system 150 can detect a wide array of defect types, with the capability to pinpoint defects associated with each TGD channel of TGD 111. For example, the gauge channel of TGD 111 may provide insights into the lateral distance between the right and left rails. Analysis of this channel may reveal anomalies in the gauge measurements that may indicate a defect. A specific example could be a section of the track where the gauge measurement deviates from the standard track width, suggesting a potential narrowing or widening of the track at that particular location. Such a defect could compromise the stability of the trains running over it and requires immediate attention.

[0057] Similarly, the surface channel of TGD 111 may focus on the vertical alignment between the rails. Analysis of this channel may uncover irregularities in the surface profile, such as unevenness or dips along a particular section of the track. These surface defects could lead to a rough ride, potential wheel damage, or even derailment risks. By identifying these issues, backend processing system 150 may alert maintenance crews to areas that require resurfacing or other corrective measures to restore the track to its proper condition.

[0058] In embodiments, backend processing system 150 may not just identify defects but may also categorize the defects them based on severity and location, enabling targeted maintenance efforts. Backend processing system 150 may also be configured to validate the detected defects to filter out false positives, ensuring that the maintenance resources are directed towards genuine concerns. For example, backend processing system 150 may be equipped with validation mechanisms to ensure the reliability of the defect detection process. Backend processing system 150 may be configured to apply mathematical and machine learning algorithms to the detected defects and TGD 111 to determine false positives — instances where the system might initially identify a defect that does not actually represent a threat to track integrity. By filtering out these false alarms, backend processing system 150 enhances the accuracy of its diagnostics, and optimizes maintenance operations and resource allocation.

[0059] In embodiments, once detected defects are confirmed and/or validated, backend processing system 150 may generate detailed track defect reports and notifications 151, which may include the type, location, and recommended actions for each defect. These reports and alerts may be communicated to railway operators, who can prioritize maintenance tasks and address the defects to maintain the safety and integrity of the railway infrastructure. In some embodiments, backend processing system 150 generate automatic signals to actuate equipment in response to the detection of defects. This proactive approach to track maintenance enhances the efficiency and responsiveness of railway operations. [0060] For example, in response to identifying a defect within TGD 111, backend processing system 150 may categorize the defect based on type, severity, and location. If the defect is of a nature that can be addressed by automated maintenance equipment, backend processing system 150 may generate a signal that is transmitted to a controller of the appropriate equipment. For example, if the gauge channel analysis reveals a narrowing of the track width that can be corrected by track adjustment machinery, backend processing system 150 may send a signal to initiate the adjustment process automatically. Similarly, if the surface channel analysis detects an uneven section of track that requires grinding or leveling, backend processing system 150 may automatically dispatch a signal to a track grinding machine to commence operations at the specified location. This automation of defect correction not just streamlines the maintenance process but also reduces the time lag between defect detection and remediation, minimizing the risk of accidents and service disruptions.

[0061] Backend processing system 150 may be integrated with a centralized control system that manages a fleet of maintenance machinery. Upon receiving the automatic signals, this control system can schedule and deploy the machinery to the exact locations where the defects have been identified. The integration of TGD analysis with automated maintenance operations represents a sophisticated approach to railway infrastructure management, ensuring that the tracks are kept in optimum condition with minimum human intervention and maximum precision.

[0062] Operations of backend processing system 150 will now be discussed with respect to FIG. 2. FIG. 2 is a block diagram illustrating an example of operations of a backend processing system 150 configured with capabilities and functionality for analyzing track geometry data for track monitoring and defect analysis in accordance with embodiments of the present disclosure. As shown in FIG. 2, backend processing system 150 may be implemented in a server (e.g., server 210). In embodiments, functionality of server 210 to facilitate operations of backend processing system 150 may be provided by the cooperative operation of the various components of server 210, as will be described in more detail below.

[0063] It is noted that although FIG. 2 shows server 210 as a single server, it will be appreciated that server 210 (and the individual functional blocks of server 210) may be implemented as separate devices and/or may be distributed over multiple devices having their own processing resources, whose aggregate functionality may be configured to perform operations in accordance with the present disclosure. Furthermore, those of skill in the art would recognize that although FIG. 2 illustrates components of server 210 as single and separate blocks, each ofthe various components of server 210 may be a single component (e.g., a single application, server module, etc.), may be functional components of a same component, or the functionality may be distributed over multiple devices/components. In such embodiments, the functionality of each respective component may be aggregated from the functionality of multiple modules residing in a single, or in multiple devices. In addition, particular functionality described for a particular component of server 210 may actually be part of a different component of server 210, and as such, the description of the particular functionality described for the particular component of server 210 is for illustrative purposes and not limiting in any way.

[0064] As shown in FIG. 2, server 210 includes processor 111, memory 112, preprocessor 220, parallelization manager 222, data validation manager 224, defect detection engine 226, defect validation manager 228, reports and alerts manager 230, and database 114.

[0065] Processor 111 may comprise a processor, a microprocessor, a controller, a microcontroller, a plurality of microprocessors, an application-specific integrated circuit (ASIC), an application-specific standard product (ASSP), or any combination thereof, and may be configured to execute instructions to perform operations in accordance with the disclosure herein. In some embodiments, implementations of processor 111 may comprise code segments

(e.g., software, firmware, and/or hardware logic) executable in hardware, such as a processor, to perform the tasks and functions described herein. In yet other embodiments, processor 111 may be implemented as a combination of hardware and software. Processor 111 may be communicatively coupled to memory 112.

[0066] Memory 112 may comprise one or more semiconductor memory devices, read only memory (ROM) devices, random access memory (RAM) devices, one or more hard disk drives (HDDs), flash memory devices, solid state drives (SSDs), erasable ROM (EROM), compact disk ROM (CD-ROM), optical disks, other devices configured to store data in a persistent or non-persistent state, network memory, cloud memory, local memory, or a combination of different memory devices. Memory 112 may comprise a processor readable medium configured to store one or more instruction sets (e.g., software, firmware, etc.) which, when executed by a processor (e.g., one or more processors of processor 111), perform tasks and functions as described herein.

[0067] Memory 112 may also be configured to facilitate storage operations. For example, memory 112 may comprise database 114 for storing various information related to operations of system 100. For example, database 114 may store configuration information related to operations of server 210. In embodiments, database 114 may store information related to various models used during operations of on server 210, such as a mathematical and/or machine learning algorithms or models used to validate and analyze TGD for defect detection and algorithms or models used to validate detected defects. Database 114 is illustrated as integrated into memory 112, but in some embodiments, database 114 may be provided as a separate storage module or may be provided as a cloud-based storage module. Additionally, or alternatively, database 114 may be a single database, or may be a distributed database implemented over a plurality of database modules.

[0068] TGD fdes 211 may include one or more TGD fdes received by backend processing system 150 from one or more on-board rail profile capture systems. For example, each of the one or more on-board rail profile capture systems may operate over a railroad track to capture rail profile data and process the captured rail profile data to generate TGD at multiple predetermined intervals traveled over their respective tracks. Each of the one or more on-board rail profile capture systems may compile and integrate the respectively generated TGD into respective TGD files, which each of the one or more on-board rail profile capture systems may send to backend processing system 150. In this manner, backend processing system 150 may receive the one or more TGD files from the one or more on-board rail profile capture systems.

[0069] In embodiments, each TGD file of TGD files 211 may include TGD collected over a specific measured distance (e.g., any distance between 5 and 100 miles, or predetermined based on operational requirements), or may be defined by a predetermined size (e.g., any size between 5MBs and 500MBs, or predetermined based on operational requirements). This structuring allows for the segmentation of track geometry data into manageable and analyzable units, corresponding to substantial yet distinct sections of the railroad track. The measured distance or file size parameters ensure that the TGD files are of a consistent and practical scale for processing, facilitating efficient data handling and analysis by backend processing system 150. Consequently, this organization aids in maintaining a systematic approach to monitoring and assessing the condition of the railway infrastructure over time and across various geographic spans.

[0070] In embodiments, a TGD file may be composed of TGD calculated at every predetermined interval (e.g., at every foot, or at any interval having a value ofbetween 6 inches and 20 feet) as traveled along the track. Consequently, a TGD file may contain a plurality of TGD records, with each individual TGD record representing the TGD for a specific predetermined interval. This granular approach ensures that the TGD captures a detailed and continuous profile of the track’s geometry, allowing for precise monitoring and potential defect detection at each segment of the railway. The aggregation of these TGD records within a single TGD file provides a comprehensive dataset that backend processing system 150 can analyze to assess the track’s overall condition and identify areas requiring maintenance or further inspection.

[0071] In embodiments, the TGD file for a measured distance of a track (e.g., a track segment) may represent an assembly of TGD that has been collected and/or calculated at each predetermined interval over the measured distance of the track. For example, in scenarios where the predetermined interval is set to one foot, each TGD record within the TGD file corresponds to the TGD calculated for a specific foot of track. This means that for every foot the railroad vehicle travels, a new TGD record may be generated and included in the TGD file, encapsulating the data for each channel of the TGD. This methodical collection of data at uniform intervals ensures a high-resolution dataset, enabling precise analysis of the track’s geometry and facilitating the early detection of structural concerns or deviations from expected conditions.

[0072] In embodiments, a TGD record in a TGD file for a predetermined interval includes not just the TGD calculated for that interval but also the latitude/longitude data that specifies the exact location of the railroad vehicle at the time the TGD was collected. This geospatial information is integral to each TGD record, providing a precise geographic context to the track geometry data. For example, if the TGD is collected or calculated when the railroad vehicle has traveled a predetermined interval, such as one foot, the corresponding latitude/longitude data is captured — typically via a GPS module — and is then associated with the TGD for that specific track foot.

[0073] By associating each TGD record with the latitude/longitude data of the railroad vehicle at the moment of data collection, TGD files 211 become a powerful tool for maintenance and inspection operations. This association ensures that each TGD record is not merely a numerical representation of track geometry but also a geographically anchored data point. Such a comprehensive approach to data collection ensures that every foot of the railway track is monitored with geographic precision, facilitating targeted maintenance actions and strategic management of the railway infrastructure.

[0074] In embodiments, each TGD file of TGD files 211 may include TGD for a plurality of channels, each channel representing a different aspect of a track’s geometry. In a particular TGD file, the values for each of the channels may be calculated for every predetermined interval along the track, and as such, each TGD record in a TGD file may include values for each of the plurality of channels. In embodiments, the plurality of channels may include, but is not limited to, a gauge channel including values representing the lateral distance between rails, a crosslevel channel including values representing the vertical distance between the tops of the rails, an alignment channel that includes values representing the lateral deviation of the track over a distance, a surface channel that includes values representing the vertical deviations of each rail surface over a distance, a curvature channel that includes values representing the track’s degree of curvature over a distance, a dip channel that includes values representing localized depressions along the longitudinal profile of the track over a distance, an unbalance channel that includes values representing deviations from the desired superelevation (or values representing the cant deficiency) of the track over a distance, and a cant channel that includes values representing the inclination angle of each rail relative to the horizontal plane of the respective rail. These channels collectively provide a comprehensive multi-dimensional analysis of the track’s geometry. FIG. 3 provides an example representation of the various channels of the TGD in accordance with embodiments of the present disclosure.

[0075] In embodiments, TGD 300 may represent the track geometry data for a specific section of a railroad track collected over a measured distance (e.g., measured distance 325). In this example, TGD 300 may be structured to include a comprehensive array of channels, each channel capturing a distinct geometric characteristic of the track. These channels may include a right rail surface channel and a left rail surface channel, which record the vertical profiles of the respective rails at each predetermined interval. Additionally, a dip channel is included to identify any localized depressions along the track’s longitudinal profile, while an alignment channel measures the lateral deviation of the track over a given distance. The gauge channel captures the lateral distance between the rails, and the crosslevel channel assesses the relative vertical distance between the rails at each predetermined interval.

[0076] The curvature channel within TGD 300 provides represents the degree of curvature along the track, providing insights into the track’s bending at each predetermined interval. An unbalance channel is also present, which proves insight into deviations from the desired superelevation or cant deficiency at each predetermined interval. Furthermore, TGD 300 includes a right cant channel and a left cant channel, each showing the inclination angle of the corresponding rail relative to the horizontal plane at each predetermined interval. The data for these various channels is visually represented in channels representations 320, offering a graphical depiction of the values obtained at each predetermined interval along measured distance 325. In some embodiments, channels representations 320 may be provided (e.g., via user terminal 130) as a notification report, such as by reports and alerts manager 230. [0077] In the specific example illustrated in FIG. 3, the predetermined interval for data collection may be set to one foot, meaning that TGD 300 includes values for each channel calculated at every foot of the measured distance 325. For example, at interval 327, the graph within channels representations 320 would display a value for each data channel corresponding to that specific foot of track. Similarly, at interval 328, which is four feet subsequent to interval 327, the graph would again show a value for each data channel, reflecting the continuous and detailed monitoring of the track’s geometry. This level of granularity in data collection ensures that TGD 300 provides a high-resolution dataset, enabling precise analysis and the early detection of potential track defects or deviations from expected conditions.

[0078] With reference back to FIG. 2, preprocessor 220 may be configured to prepare TGD files 211 for detailed analysis. In embodiments, preprocessor 220 may include functionality configured to streamline the subsequent processing stages, ensuring that the TGD is in the appropriate format and context for advanced defect detection and analysis. Among its core functions, preprocessor 220 includes functionality for converting the raw TGD into a standardized format conducive to processing. Additionally, preprocessor 220 incorporates geo-location functionality, which is instrumental in associating each TGD record within the TGD files with a precise geographic information systems (GIS) coordinate of the track, anchoring the data to specific physical locations along the railway. This preparatory work by preprocessor 220 is integral to the system’s ability to deliver accurate and geographically relevant insights into the track’s condition.

[0079] In embodiments, preprocessor 220 may include functionality to transform the TGD files received into a compatible format for processing (e.g., a comma-separated values

(CSV) format). In embodiments, this conversion may be facilitate standardizing the raw TGD files into a format that is compatible with subsequent analytical tools and systems. By converting the TGD into a compatible format, such as a CSV format, preprocessor 220 ensures that the data is organized into a tabular form, with each TGD record delineated by commas, facilitating efficient parsing, processing, and analysis in the later stages of defect detection and validation within backend processing system 150. The CSV format’s compatibility with a broad range of software applications and systems further enhances the interoperability and accessibility of the TGD for various maintenance and monitoring purposes.

[0080] In embodiments, preprocessor 220 may be configured with advanced geolocation functionality, which plays a pivotal role in enhancing the utility and precision of the TGD analysis. The geo-location functionality of preprocessor 220 enables preprocessor 220 to assign a specific GIS coordinate to each TGD record contained within the TGD files. The geo-location process may include converting the latitude and longitude data associated with each TGD record into a GIS coordinate that accurately reflects the physical location on the railway track.

[0081] For example, a TGD record corresponding to a location of track located 200 feet beyond milepost 50 would include not just the TGD for that track location but also the latitude and longitude of the railroad vehicle at that precise location. Preprocessor 220 may be configured to translate this positional data into a GIS coordinate, such as "50.200," which succinctly indicates that the TGD was collected 200 feet past milepost 50. This conversion leverages a GIS database that correlates specific track mileposts with their respective geographic coordinates, ensuring that each TGD record is augmented with a meaningful and accurate location reference. This geo-location enhancement provided by preprocessor 220 is instrumental in anchoring the TGD to identifiable locations along the track, facilitating targeted maintenance actions and enabling a more strategic approach to railway infrastructure management. [0082] Parallelization manager 222 may be configured to optimize the geo-location operations of preprocessor 220. To manage the substantial volume of TGD files generated by deployed on-board rail profile capture systems, backend processing system 150 leverages the functionality of parallelization manager 222 to parallelize the geo-location operations performed by preprocessor 220. Parallelization manager 222 may include functionality for distributing the workload across multiple processes, and in this manner, accelerating the geolocation functionality to keep pace with the influx of incoming TGD files. This parallel processing is particularly advantageous given the direct correlation between the number of deployed on-board rail profile capture systems, the velocity of data collection, and the resulting quantity of TGD files.

[0083] For example, consider a scenario where a single on-board rail profile capture system mounted on a railroad vehicle traveling at 90MPH generates three TGD files, each 30MB in size, within an hour. When scaled to 20 such systems operating concurrently and at similar speeds, backend processing system 150 could potentially receive 60 TGD files, each 30MB, in the same timeframe. The challenge lies not just in the volume of data but also in the expectation for backend processing system 150 to process the data more rapidly than it is produced. To illustrate, if a system produces three 30MB TGD files in an hour, the backend processing system 150 is engineered to process these files in under an hour, ensuring that data analysis keeps ahead of data generation.

[0084] Parallelization manager 222 is configured to parallelize the geo-location operations by initiating multiple processing threads or processes, each designed to handle a specific subset of TGD records. These subsets could range from individual TGD files to portions of TGD files, depending on the processing requirements. In embodiments, parallelization manager 222 may dynamically adjust the number of processes based on the rate at which TGD files are received and their respective sizes. This dynamic scaling is a proactive approach to resource allocation, ensuring that processing power is neither underutilized in times of low data flow nor overwhelmed during peak data reception. Through this parallelization functionality, backend processing system 150 maintains a consistent and efficient processing rate, enabling timely geo-location and subsequent analysis of the track geometry data.

[0085] Data validation manager 224 may be configured to enhance the integrity of the TGD analysis by processing the TGD for each channel, identifying and filtering out any data that may be characterized as noise rather than valid TGD. Noise within the TGD can arise from various sources, such as environmental interference, equipment anomalies, or signal fluctuations, and can obscure or distort the true state of the railway track’s geometry. To achieve this data validation, data validation manager 224 may leverage advanced machine learning models that have been trained to distinguish between noise and legitimate TGD. These models may be configured to recognize the intricate patterns that differentiate valid data from spurious signals. By applying these models to the TGD, data validation manager 224 systematically evaluates the data within each channel, isolating and removing those TGD records that are likely to represent noise. This process of validation is pivotal, as it ensures that the subsequent stages of defect detection and analysis are based on the cleanest and most accurate data possible, enhancing the reliability of the defect detection process and the overall safety assessments made by the system.

[0086] A particular example of the advanced machine learning models used by data validation manager 224 to validate TGD is illustrated in FIG. 4. FIG. 4 illustrates an example of a data validation model configured for validating TGD in accordance with embodiments of the present disclosure. As shown in FIG. 4, data validation model 400 may be trained using an input multivariate time series 414. Patterns of valid data 410 and patterns of noise 412 may be fed to the input multivariate time series 414. In embodiments, patterns of valid data 410 may be derived from historical TGD that are known to accurately represent the track’s geometry. These patterns may vary across the different channels of TGD, and as such, data validation model 400 may be trained with multiple valid patterns for each channel to ensure comprehensive coverage.

[0087] Conversely, patterns of noise 412 may represent data anomalies that do not correspond to the actual state of the railway track but are instead attributed to external interferences or sensor inaccuracies. Similar to the valid data patterns, noise patterns may be channel-specific, and data validation model 400 may be equipped with several noise patterns for each TGD channel to effectively identify and filter out noise.

[0088] In embodiments, input multivariate time series 414, which encapsulates both patterns of valid data 410 and patterns of noise 412, undergoes a non-linear transformation 416. This non-linear transformation may include an operation that adjusts the data to reveal complex, non-linear relationships within the TGD records that might not be apparent in their original form.

[0089] The transformed data may then be subjected to a probability distribution 418, which may assign probabilities over K classes, effectively categorizing the data into distinct groups based on the likelihood of being valid TGD or noise. The application of probability distribution 418 is a powerful step that allows for the nuanced classification of TGD records. By assigning probabilities to each record, data validation model 400 may determine the likelihood of a record being representative of actual track geometry or merely noise. This probabilistic approach provides a more granular analysis than binary classification, accommodating the inherent uncertainty and variability within the TGD. [0090] In embodiments, data validation manager 224 may leverage the outcomes of this probabilistic classification of data validation model 400 to filter the TGD channels. For example, data validation manager 224 may apply data validation model 400 to TGD records 420 to isolate and discard those portions of the TGD that are likely to be noise, as indicated by their alignment with the patterns of noise 412 and their corresponding probability scores. Conversely, TGD records that align with patterns of valid data 410 and have high probability scores indicative of valid TGD may be retained for further analysis as fdtered TGD records 422.

[0091] This fdtration process represents an enhanced approach to the overall integrity of the TGD analysis, as it ensures that the data fed into subsequent stages of defect detection is of the utmost quality. By effectively distinguishing between noise and valid TGD, data validation manager 224 upholds the accuracy and reliability of the defect detection process, contributing to the safety and maintenance of the railway infrastructure.

[0092] With reference back to FIG. 2, defect detection engine 226 may be configured to process the validated TGD to detect, identify, and/or classify a variety of defect types that may affect the structural integrity of railway tracks. For example, once data validation manager 224 has filtered the TGD to remove any noise, the resulting clean and validated TGD is fed into defect detection engine 226 for detailed analysis. Defect detection engine 226 may leverage sophisticated machine learning algorithms that are capable of detecting subtle and complex patterns within the TGD that may indicate the presence of geometric defects.

[0093] The machine learning algorithms employed by defect detection engine 226 may be trained on historical data and known defect patterns, enabling the engine to recognize a wide range of defect types. These defect types may include, but are not limited to, issues with rail alignment, gauge irregularities, surface deviations, curvature anomalies, cant problems, dip irregularities, crosslevel problems, unbalance defects, etc. By analyzing the TGD across the multiple channels and over various distances, defect detection engine 226 can pinpoint areas of concern that may not be immediately apparent to manual inspections or simpler automated systems.

[0094] In embodiments, defect detection engine 226 may operate by examining the TGD associated with specific sections of the railway track. Defect detection engine 226 may analyze TGD over the full measured distance covered by the on-board rail profile capture systems, or it may focus on smaller subsets of that distance to identify localized defects. Additionally, defect detection engine 226 may have the capability to aggregate TGD from multiple measured distances, providing a comprehensive view of the track’s condition over extended stretches of railway. This holistic approach to defect detection ensures that no potential issue goes unnoticed, regardless of its size or location along the track.

[0095] The versatility of defect detection engine 226 lies in its ability to adapt its analysis based on the nature of the TGD and the specific requirements of the railway operator. Whether the focus is on high-traffic areas, sections of track with a history of issues, or newly laid tracks, defect detection engine 226 may be configured to prioritize and scrutinize the TGD accordingly. This targeted analysis is instrumental in the proactive maintenance of the railway infrastructure, allowing operators to address defects before they escalate into more serious problems.

[0096] Defect validation manager 226 may be configured to validate potential defects identified by the defect detection engine 226. Defect validation manager 226 may include functionality to determine whether a detected defect is indeed a true defect or a false positive. This distinction is of utmost relevance, as it prevents the unnecessary allocation of maintenance resources to non-issues and ensures that attention is focused on genuine concerns. [0097] The functionality of defect validation manager 226 to validate potential defects may include leveraging advanced machine learning models that have been specifically trained to recognize the signature patterns of true defects as opposed to anomalies that mimic defect characteristics but are not indicative of an actual track issue. These advanced models may be informed by a comprehensive dataset of historical TGD that includes examples of both confirmed defects and false positives.

[0098] When defect detection engine 226 flags a potential defect within the TGD, defect validation manager 228 may apply the machine learning models to the data associated with the flagged defect. The models analyze the TGD, considering factors such as the defect’s shape, size, and location, as well as the context within which it was detected. For instance, a defect identified in a high-stress area of the track, such as a curve or junction, may be subjected to a different validation criterion than one found on a straight and level section.

[0099] If the machine learning models determine that the characteristics of the flagged defect align with the known patterns of a true defect, the defect is validated and passed on for inclusion in the track defect reports and notifications. Conversely, if the models assess the flagged defect as aligning more closely with patterns associated with false positives, defect validation manager 228 filters out the defect, streamlining the subsequent maintenance planning process.

[00100] In embodiments, defect validation manager 228 may apply specialized machine learning algorithms tailored to validate specific types of defects. This targeted approach allows for a more nuanced and accurate validation process, as each defect type may exhibit distinct characteristics that are better identified and analyzed by algorithms designed for that specific purpose. For example, an unbalance defect, which pertains to deviations from the desired superelevation or cant deficiency, may be validated using an unbalance validation model. This model is trained to recognize the particular patterns and signatures that are characteristic of genuine unbalance defects. In the context of railroad tracks, unbalance defects are particularly concerning as they can affect the dynamic stability of trains, especially at higher speeds or on curves. The unbalance validation model ensures that such defects are accurately identified and distinguished from false positives that may occur due to the complex interplay of forces at these locations.

[00101] Similarly, a cant defect, which involves the improper inclination angle of the rail relative to the horizontal plane, may be validated using a cant defect validation model. Cant defects can lead to uneven wear on the rail and wheels, potentially causing derailments. The cant defect validation model is trained to discern the subtle differences between normal variations in cant and actual defects that compromise the track’s safety.

[00102] In addition to these specific models, defect validation manager 228 may also employ more general validation models that are capable of validating a broad range of defect types. These models may be particularly useful for initial screenings and for identifying defects that do not fall into more common categories. By utilizing a combination of specialized and general validation models, defect validation manager 228 ensures a comprehensive and reliable validation process, covering the full spectrum of potential track defects.

[00103] Several examples of defect validation models that may be leveraged by defect validation manager 228 to validate potential defects in accordance with embodiments of the present disclosure will now be discussed with reference to FIGS. 5-7B. It is noted, however, that these examples are provided as illustrative of the functionalities described herein, and should not be construed as limiting in any way. Indeed, in some embodiments, other defect validation models may be leveraged by defect validation manager 228. [00104] FIG. 5 illustrates an example of a defect validation model configured for validating an unbalance defect in accordance with embodiments of the present disclosure. In embodiments, unbalance defects are a type of geometric anomaly that can occur in railroad tracks, typically manifesting as deviations from the desired superelevation for a track, which is also known as a cant deficiency. However, not all unbalance defects detected by defect detection engine 226 are indicative of a genuine issue with the track, as some detections, particularly those in the vicinity of railroad switches, may be false positives.

[00105] In embodiments, unbalance defect validation model 500 may be configured to distinguish between true unbalance defects and those that are falsely identified due to the complex track geometry (e.g., track geometry around switches). Unbalance defect validation model 500 may leverage the fact that the pattern of curvature TGD data from the curvature channel, when collected near a switch and associated with an unbalance defect, typically exhibits a sinusoidal shape. This characteristic shape in the curvature channel is a result of the normal geometry of the switch area and does not necessarily indicate a true unbalance defect.

[00106] Similarly, unbalance defect validation model 500 may leverage the fact that the pattern of unbalance TGD data from the unbalance channel, when collected near a switch and associated with an unbalance defect, typically exhibits an M-like shape. This characteristic M- like shape in the unbalance channel is a result of the normal geometry of the switch area and does not necessarily indicate a true unbalance defect.

[00107] In embodiments, unbalance defect validation model 500 may include obtaining defect patterns 520, which may include segments of TGD data from the curvature channel where an unbalance defect has been detected. Defect patterns 520 may include data that is specifically selected from instances where the TGD was collected in the vicinity of a railroad switch, and may typically exhibit a sinusoidal shape. [00108] Unbalance defect validation model 500 may include obtaining defect patterns 522, which are segments of TGD data from the unbalance channel where an unbalance defect has been detected. Defect patterns 522 may include data that is specifically selected from instances where the TGD was collected in the vicinity of a railroad switch, and may typically exhibit an M-like shape.

[00109] Defect patterns 520 and 522 may be input, as curvature patterns 510 and unbalance patterns, respectively, into a neural network 514 as combination pattern 524. In embodiments, neural network 514 may be trained to recognize TGD having a pattern corresponding to the combination pattern 524, which may be leveraged to recognize instances of a false positive unbalance defect. For example, when defect detection engine 226 identifies a potential unbalance defect, the corresponding curvature and unbalance TGD data are input into the trained neural network 514. The neural network then processes this data and determines whether the combined pattern matches the trained model of a false positive (e.g., the sinusoidal and M-like shapes typically found near switches) or a true unbalance defect.

[00110] In embodiments, to validate an unbalance defect that has been detected by the defect detection engine 226 within the unbalance channel of the track geometry data (TGD), unbalance defect validation model 500 is applied to the specific segment of TGD associated with the unbalance channel (e.g., TGD unbalance channel 516). This segment of TGD corresponds to the location along the measured distance of the railway track where the potential unbalance defect has been identified.

[00111] The validation process involves analyzing TGD unbalance channel 516 at the particular predetermined interval, or data point, where the unbalance defect was flagged. The segment of TGD is examined to determine if the pattern of data at this location matches the known patern for an invalid unbalance defect, which is typically characterized by the sinusoidal and M-like shapes associated with the vicinity of a switch.

[00112] The neural network 514 within the unbalance defect validation model 500 processes the TGD data from the unbalance channel and compares it against trained combination pattern 524. If the data patern at the detected location matches the trained patern of a false positive, neural network 514 will identify the defect as invalid. This means that the detected unbalance defect is likely not a true defect but rather an artifact of the complex geometry around a switch, and therefore, it does not warrant maintenance action.

[00113] Conversely, if the data patern does not match the false positive patern, neural network 514 will classify the defect as valid. This indicates that the detected unbalance defect is likely a genuine concern that may require further investigation or immediate maintenance to ensure the safety and integrity of the railway track.

[00114] The result of this validation process is provided at step 518, where a definitive determination is made regarding the validity of the detected unbalance defect. This determination is based on the neural network’s analysis and is used to inform the subsequent actions of the railway track monitoring system, such as generating maintenance alerts or scheduling inspections to address the defect. The ability to accurately validate or dismiss detected defects is a testament to the advanced analytical capabilities of the unbalance defect validation model 500 within the railway track monitoring system.

[00115] FIG. 6 illustrates an example of a spike defect validation model configured for validating defects in accordance with embodiments of the present disclosure. In embodiments, spike defect validation model 600 may be configured to determine whether the anomaly points, which are the data points that led to the defect detection, actually represent a spike in the TGD. If the anomaly points are determined to be spikes, the corresponding defect may be classified as a false positive, indicating that the detected defect does not represent a true track geometry issue.

[00116] FIG. 6 will be described with further reference to FIGS. 7A and 7B. FIG. 7A illustrates an example of a data set 700 for spike validation in accordance with embodiments of the present disclosure. FIG. 7B illustrates an example of a data set 750 for spike validation in which no amplitude difference between the anomaly points is greater than the amplitude threshold in accordance with embodiments of the present disclosure.

[00117] Spike validation model 600 is versatile and may be applied to validate several types of defects, including but not limited to crosslevel and gauge defects. Crosslevel defects pertain to the vertical alignment between the rails, while gauge defects relate to the lateral distance between the rails. Spikes in the TGD for these channels may be indicative of measurement errors or transient events that do not reflect persistent track geometry issues.

[00118] By employing spike validation model 600, defect validation manager 228 may enhance the accuracy of the defect validation process by distinguishing between genuine track defects and anomalies that are not indicative of a track issue. This differentiation is pivotal in ensuring that maintenance efforts are directed towards addressing true defects, optimizing the use of maintenance resources and enhancing the safety and reliability of the railway infrastructure.

[00119] At block 610, a data window is set for the purpose of defect validation. In embodiments, the data window may be defined to include a predetermined number of data points that are collected before and after the location where a defect has been detected. These data points may correspond to predetermined intervals along the railway track, such as every foot of track traversed by the railroad vehicle. [00120] For example, as illustrated in FIG. 7A, a defect may be detected at a specific data point, designated as data point 0, which represents a particular track foot or predetermined interval. In this example, data window 700 may encompass the TGD measurements for fifty feet prior to the defect location and fifty feet subsequent to the defect location. This data window 700 provides a comprehensive view of the track’s geometry around the defect location, detailing the amplitude at each data point within the window and the slope between these points. Data window 700 may be used in the spike validation process as it captures the immediate context of the track geometry surrounding the defect. This context is used to analyze the amplitude and slope of the TGD at each data point, which are pivotal in determining whether an anomaly point represents a spike — a transient or erroneous measurement that could lead to a false positive defect detection.

[00121] Included within data window 700 are anomaly points 720 and 722, which have been identified within the data set as contributing to the detected defect. The data window’s configuration allows for a focused analysis of these anomaly points in relation to the surrounding track geometry, enabling spike validation model 600 to accurately assess the validity of the detected defect. By examining the amplitude and slope information within this window, the model can discern whether the anomaly points are indicative of a genuine track defect or if they are merely artifacts of measurement noise or transient events.

[00122] At block 612, a valid anomaly point range may be set. The valid anomaly point range may define the specific area within the data window set at block 610 that may be considered when determining if an anomaly point is indicative of a spike, and consequently, whether the detected defect is a false positive. The anomaly point range is a subset of the data window and is centered around the defect location, which may include the point at which the defect was initially detected. The valid anomaly point range may be predetermined and may include a specific number of data points before and after the defect location. For example, as illustrated in FIG. 7A, if the defect was detected at data point 0, representing a specific track foot or predetermined interval, the valid anomaly point range might be set to include data points within a range of -15 feet to +15 feet from the defect location.

[00123] By setting the valid anomaly point range, spike validation model 600 focuses on the immediate vicinity of the detected defect, where the presence of a spike is more likely to be relevant to the defect’s validity. Anomaly points that fall within this range are considered for further analysis to determine if they represent a spike. Conversely, anomaly points that fall outside of this valid anomaly point range are excluded from the spike detection analysis, as they are less likely to be related to the defect in question.

[00124] The establishment of a valid anomaly point range is a strategic step in the validation process. It narrows the focus of the analysis to the area of the data set that is of greatest interest for defect validation, which may enhance the efficiency and accuracy of the spike detection process. This targeted approach helps to ensure that spike validation model 600 can effectively differentiate between true track defects and transient anomalies that do not pose a risk to the track’s structural integrity.

[00125] At block 614, a validation based on the anomaly point range may be performed. In particular, each anomaly point that falls within the previously established anomaly point range may be considered for further spike detection analysis (e.g., at block 616 and/or 618), which could indicate a false positive defect detection. Conversely, anomaly points located outside of this range are not considered for spike detection, as they are deemed less likely to impact the validity of the detected defect.

[00126] In embodiments, if no anomaly points are found within the anomaly point range, the data set is concluded to be free of spikes, and the detected defect is considered valid. This outcome suggests that the anomaly leading to the defect detection is not due to a transient or erroneous measurement but is likely indicative of a true track geometry issue.

[00127] However, if one or more anomaly points are determined to be included within the anomaly point range, the validation process proceeds to the next step for further analysis (e.g., at block 616). For example, referring to FIG. 7A, any anomaly point within a range of - 15 feet to +15 feet from data point 0 — the location where the defect was detected — is considered for further spike detection analysis. Anomaly point 720, which lies within this range, would be considered for further spike detection analysis. In contrast, anomaly points 722, which fall outside the -15 feet to +15 feet range from data point 0, may not be considered for further spike detection analysis as their position relative to the defect location renders them irrelevant to the current analysis of the defect's validity.

[00128] At block 616, validation based on a slope change may be performed. Validation based on a slope change may involve analyzing the slope of the TGD at each anomaly point that falls within the valid anomaly point range established in block 614. The slope at an anomaly point is indicative of the rate of change in the vertical profde of the track at that specific location. To determine if an anomaly point represents a spike, the slope at that point is calculated and compared against a predefined slope threshold. If the calculated slope is greater than the slope threshold, it suggests a sharp change in the track’s profile, which may be characteristic of a spike . In such cases, the validation process advances to block 618 for further analysis based on amplitude checks.

[00129] Conversely, if the slope at the anomaly point is not greater than the slope threshold, the anomaly is likely not a spike but rather anormal variation in the track’s geometry. As a result, the data set is determined to be free of spikes, and the detected defect is considered to be a valid indication of a track geometry issue that may require attention. [00130] The slope threshold used in the validation based on a slope change step may be configurable parameter that can be set based on empirical data and the specific requirements of the railway track monitoring system. In some embodiments, the slope threshold may be any value within a range of 0.5 to 5. This range allows for flexibility in the validation process, accommodating different track conditions and ensuring that the spike detection is neither overly sensitive, leading to false positives, nor too insensitive, potentially missing genuine spikes. The careful setting of the slope threshold is thus a pivotal factor in the accuracy and reliability of the spike validation process.

[00131] At block 618, a validation based on an amplitude check of the anomaly point may be performed. The validation based on an amplitude check may include setting a range of data values on both sides of the anomaly point and measuring the amplitude difference across this range. For example, a set of five data points on either side of the anomaly point may be selected to establish the range for analysis.

[00132] The amplitude difference may then be calculated over this range of data points, on both sides of the anomaly point. If the amplitude difference is found to be greater than an amplitude threshold, the anomaly point is identified as a spike. This determination suggests that the anomaly point represents a transient or erroneous measurement, leading to a false positive in defect detection. Conversely, if the amplitude difference is not greater than the amplitude threshold, the anomaly point is not considered a spike. Consequently, the data set is deemed free of spikes, and the detected defect is validated as a true indication of a track geometry issue that may necessitate further attention or maintenance.

[00133] In embodiments, the amplitude threshold may be a configurable parameter that may be adjusted based on the type of defect being analyzed. For example, in the case of crosslevel and cant defects, the amplitude threshold may be set to any value within a range of 0.1 to 2. This flexibility in setting the amplitude threshold allows for tailored validation processes that are sensitive to the specific characteristics of different types of track defects, which may enhance the precision and reliability of the spike detection and validation process.

[00134] The validation based on the amplitude check of the anomaly point may enable a system to accurately discern between true spikes and normal variations in the TGD. This validation based on the amplitude check may be configured to prevent the incorrect classification of a defect as a false positive due to misidentified spikes. For example, as illustrated in FIG. 7B, without the amplitude check validation, anomaly points 752, 754, 756, and 758 within data set 750 might erroneously be identified as spikes. This misidentification could occur if the slope at these points and their location within the valid anomaly point range meet the criteria for spike detection. Consequently, a defect detected at these points could be incorrectly flagged as invalid or as a false positive, potentially leading to unnecessary maintenance actions or overlooking a genuine defect.

[00135] However, by implementing the amplitude check, the defect validation manager can measure the amplitude difference across a range of data points surrounding each anomaly point. If this amplitude difference exceeds a predefined threshold, the point is classified as a spike. Conversely, if the amplitude difference does not exceed the threshold, the anomaly point is not considered a spike. In the example illustrated in FIG. 7B, the amplitude check reveals that the anomaly points 752, 754, 756, and 758 do not exhibit amplitude differences that surpass the threshold. Therefore, these points may not be considered spikes, and the data set is determined to be free of spikes. As a result, the defect initially detected within data set 750 (e.g., at point 0) is validated as a true defect, affirming the integrity of the defect detection process and ensuring that maintenance efforts are appropriately directed towards actual track defects. This validation step is integral to maintaining the accuracy and reliability of the railway track monitoring system.

[00136] Referring back to FIG. 2, reports and alerts manager 230 may be configured to synthesize and communicate the findings from the defect detection and validation processes. In embodiments, reports and alerts manager 230 may be configured to generate and transmit alerts in response to defects in a railroad being detected and validated by the defect detection engine 226 and defect validation manager 228. For example, upon validation of a defect, reports and alerts manager 230 may generate an alert that includes detailed information about the defect, including its precise location, the nature of the defect, its size, and potential remediation strategies.

[00137] In embodiments, the alerts generated by reports and alerts manager 230 may be designed to be actionable, providing clear and concise information that enables maintenance personnel to understand the severity and urgency of the situation. The alerts may include specific recommendations for corrective actions, which could range from immediate repairs to closer monitoring of the affected track section. By doing so, reports and alerts manager 230 ensures that maintenance teams can prioritize their tasks effectively and respond to issues with the appropriate level of urgency.

[00138] In addition to notifying maintenance crews, reports and alerts manager 230 may be configured to interface with automated systems. Reports and alerts manager 230 may be configured to send automatic signals to trigger the deployment of maintenance equipment directly to the location of the defect. This automation streamlines the maintenance process, reducing response times and potentially preventing minor issues from escalating into more serious problems. [00139] The communication of alerts by reports and alerts manager 230 is not limited to manual dissemination. In some embodiments, reports and alerts manager 230 may be configured to integrate with existing railway communication networks. This enables the rapid distribution of alerts to the appropriate personnel, ensuring that all stakeholders are informed and can take coordinated action.

[00140] In embodiments, reports and alerts manager 230 may be configured to issue safety alerts. These safety alerts are of particular import as they can trigger immediate responses to prevent accidents or disruptions. For example, if the system detects a defect that compromises the safety of a section of the track, reports and alerts manager 230 may automatically send a signal to a controller that causes a vehicle to stop. By automatically stopping the vehicle, the vehicle may be prevented from entering the affected area until the issue is resolved.

[00141] In embodiments, reports and alerts manager 230 may be configured to compile the validated TGD into comprehensive reports that detail the condition of the railway track, highlighting any validated defects that have been identified. The reports generated by reports and alerts manager 230 can take various forms, depending on the intended audience and purpose. Maintenance alerts may be issued to signal the immediate attention and action of maintenance crews, while pre-maintenance alerts might indicate areas that require monitoring for potential future intervention. The reports may also provide a detailed breakdown of the validated data for each channel of the TGD, offering insights into specific aspects of the track’s geometry and condition.

[00142] FIG. 8 shows a high-level flow diagram 800 of operation of a system configured for providing functionality for analyzing track geometry data for track monitoring and defect detection in accordance with embodiments of the present disclosure. For example, the functions illustrated in the example blocks shown in FIG. 8 may be performed by system 800 of FIG. 1 according to embodiments herein. In embodiments, the operations of the method 800 may be stored as instructions that, when executed by one or more processors, cause the one or more processors to perform the operations of the method 800.

[00143] At block 802, one or more TGD files are received from one or more on-board rail profile capture systems mounted to a railroad vehicle. In embodiments, each TGD file of the one or more TGD files includes a plurality of TGD records including TGD calculated over a measured distance of a track, and each TGD record of the TGD records is associated with a respective predetermined interval along the track. In embodiments, functionality of a preprocessor (e.g., preprocessor 220 as illustrated in FIG. 2) may be used to receive, from one or more on-board rail profile capture systems mounted to a railroad vehicle, one or more TGD files. In embodiments, the preprocessor may perform operations to receive, from one or more on-board rail profile capture systems mounted to a railroad vehicle, one or more TGD files according to operations and functionality as described above with reference to preprocessor 220 and as illustrated in FIGS. 1-7B.

[00144] At block 804, one or more defect detection algorithms are applied to the plurality of TGD records to detect one or more potential defects associated with the track. In embodiments, functionality of a defect detection manager (e.g., defect detection manager 226 as illustrated in FIG. 2) may be used to apply one or more defect detection algorithms to the plurality of TGD records to detect one or more potential defects associated with the track. In embodiments, the defect detection manager may perform operations to apply one or more defect detection algorithms to the plurality of TGD records to detect one or more potential defects associated with the track according to operations and functionality as described above with reference to defect detection manager 226 and as illustrated in FIGS. 1-7B. [00145] At block 806, the one or more potential defects are validated to determine whether each potential defect is a false positive. In embodiments, functionality of a defect validation manager (e.g., defect validation manager 228 as illustrated in FIG. 2) may be used to validate the one or more potential defects to determine whether each potential defect is a false positive. In embodiments, the defect validation manager may perform operations to validate the one or more potential defects to determine whether each potential defect is a false positive according to operations and functionality as described above with reference to defect validation manager 228 and as illustrated in FIGS. 1-7B.

[00146] At block 808, potential defects of the one or more potential defects determined to be false positives are discarded. In embodiments, functionality of a defect validation manager (e.g., defect validation manager 228 as illustrated in FIG. 2) may be used to discard potential defects of the one or more potential defects determined to be false positives. In embodiments, the defect validation manager may perform operations to discard potential defects of the one or more potential defects determined to be false positives according to operations and functionality as described above with reference to defect validation manager 228 and as illustrated in FIGS. 1-7B.

[00147] At block 810, an alert is generated based on each potential defect of the one or more potential defects determined to be a valid defect. In embodiments, functionality of a reports and alerts manager (e.g., reports and alerts manager 230 as illustrated in FIG. 2) may be used to generate an alert based on each potential defect of the one or more potential defects determined to be a valid defect. In embodiments, the reports and alerts manager may perform operations to generate an alert based on each potential defect of the one or more potential defects determined to be a valid defect according to operations and functionality as described above with reference to reports and alerts manager 230 and as illustrated in FIGS. 1-7B. [00148] At block 812, a signal to initiate a corrective action in response to the alert generated for each potential defect of the one or more potential defects determined to be a valid defect is automatically sent. In embodiments, functionality of a reports and alerts manager (e.g., reports and alerts manager 230 as illustrated in FIG. 2) may be used to automatically send a signal to initiate a corrective action in response to the alert generated for each potential defect of the one or more potential defects determined to be a valid defect. In embodiments, the reports and alerts manager may perform operations to automatically send a signal to initiate a corrective action in response to the alert generated for each potential defect of the one or more potential defects determined to be a valid defect according to operations and functionality as described above with reference to reports and alerts manager 230 and as illustrated in FIGS. 1- 7B.

[00149] Persons skilled in the art will readily understand that advantages and objectives described above would not be possible without the particular combination of computer hardware and other structural components and mechanisms assembled in this inventive system and described herein. Additionally, the algorithms, methods, and processes disclosed herein improve and transform any general-purpose computer or processor disclosed in this specification and drawings into a special purpose computer programmed to perform the disclosed algorithms, methods, and processes to achieve the aforementioned functionality, advantages, and objectives. It will be further understood that a variety of programming tools, known to persons skilled in the art, are available for generating and implementing the features and operations described in the foregoing. Moreover, the particular choice of programming tool(s) may be governed by the specific objectives and constraints placed on the implementation selected for realizing the concepts set forth herein and in the appended claims. [00150] The description in this patent document should not be read as implying that any particular element, step, or function can be an essential or critical element that must be included in the claim scope. Also, none of the claims can be intended to invoke 35 U.S.C. § 112(f) with respect to any of the appended claims or claim elements unless the exact words “means for” or “step for” are explicitly used in the particular claim, followed by a participle phrase identifying a function. Use of terms such as (but not limited to) “mechanism,” “module,” “device,” “unit,” “component,” “element,” “member,” “apparatus,” “machine,” “system,” “processor,” “processing device,” or “controller” within a claim can be understood and intended to refer to structures known to those skilled in the relevant art, as further modified or enhanced by the features of the claims themselves, and can be not intended to invoke 35 U.S.C. § 112(f). Even under the broadest reasonable interpretation, in light of this paragraph of this specification, the claims are not intended to invoke 35 U.S.C. § 112(f) absent the specific language described above.

[00151] The disclosure may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. For example, each of the new structures described herein, may be modified to suit particular local variations or requirements while retaining their basic configurations or structural relationships with each other or while performing the same or similar functions described herein. The present embodiments are therefore to be considered in all respects as illustrative and not restrictive. Accordingly, the scope of the disclosure can be established by the appended claims. All changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein. Further, the individual elements of the claims are not well-understood, routine, or conventional. Instead, the claims are directed to the unconventional inventive concept described in the specification. [00152] Those of skill in the art would further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the disclosure herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure. Skilled artisans will also readily recognize that the order or combination of components, methods, or interactions that are described herein are merely examples and that the components, methods, or interactions of the various embodiments of the present disclosure may be combined or performed in ways other than those illustrated and described herein.

[00153] Functional blocks and modules in FIGS. 1-8 may comprise processors, electronics devices, hardware devices, electronics components, logical circuits, memories, software codes, firmware codes, etc., or any combination thereof. Consistent with the foregoing, various illustrative logical blocks, modules, and circuits described in connection with the disclosure herein may be implemented or performed with a general -purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

[00154] The steps of a method or algorithm described in connection with the disclosure herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user terminal, base station, a sensor, or any other communication device. In the alternative, the processor and the storage medium may reside as discrete components in a user terminal.

[00155] In one or more exemplary designs, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. Computer-readable storage media may be any available media that can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code means in the form of instructions or data structures and that can be accessed by a general- purpose or special-purpose computer, or a general -purpose or special-purpose processor. Also, a connection may be properly termed a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, or digital subscriber line (DSL), then the coaxial cable, fiber optic cable, twisted pair, or DSL, are included in the definition of medium. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

[00156] Although the present disclosure and its advantages have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein without departing from the spirit and scope of the disclosure as defined by the appended claims. Moreover, the scope of the present application is not intended to be limited to the particular embodiments of the process, machine, manufacture, composition of matter, means, methods, and steps described in the specification. As one of ordinary skill in the art will readily appreciate from the disclosure of the present disclosure, processes, machines, manufacture, compositions of matter, means, methods, or steps, presently existing or later to be developed that perform substantially the same function or achieve substantially the same result as the corresponding embodiments described herein may be utilized according to the present disclosure. Accordingly, the appended claims are intended to include within their scope such processes, machines, manufacture, compositions of matter, means, methods, or steps.

Claims

CLAIMS What is claimed is:

1. A method of detecting railroad track defects, comprising: receiving, from one or more on-board rail profile capture systems mounted to a railroad vehicle, one or more track geometry data (TGD) files, wherein each TGD file of the one or more TGD files includes a plurality of TGD records including TGD calculated over a measured distance of a track, and wherein each TGD record of the TGD records is associated with a respective predetermined interval along the track; applying one or more defect detection algorithms to the plurality of TGD records to detect one or more potential defects associated with the track; validating the one or more potential defects to determine whether each potential defect is a false positive; discarding potential defects of the one or more potential defects determined to be false positives; generating an alert based on each potential defect of the one or more potential defects determined to be a valid defect; and automatically sending a signal to initiate a corrective action in response to the alert generated for each potential defect of the one or more potential defects determined to be a valid defect.

2. The method of claim 1, further comprising: analyzing the plurality of TGD records using a data validation manager configured with one or more machine learning models to distinguish between valid TGD and noise within the plurality of TGD records; filtering out TGD records identified as noise by the data validation manager; and retaining TGD records classified as valid TGD by the data validation manager for subsequent defect detection and validation processing.

3. The method of claim 1, further comprising preparing the one or more TGD files for detailed analysis.

4. The method of claim 3, wherein preparing the one or more TGD files for detailed analysis includes converting the one or more TGD files into a standardized format compatible for to processing by the one or more defect detection algorithms.

5. The method of claim 3, wherein preparing the one or more TGD files for detailed analysis includes associating each TGD record within the one or more TGD files with corresponding location information obtained from a global positioning system (GPS) module.

6. The method of claim 5, wherein the location information associated with each TGD record is converted into a geographic information systems (GIS) coordinate that represents a physical location along the track that is referenced from the center of the track.

7. The method of claim 1, wherein the plurality of TGD records in a TGD file of the one or more TGD files is configured across a plurality of data channels related to the geometry of the railroad track.

8. The method of claim 7, wherein the one or more defect detection algorithms are applied separately to each channel of the plurality of data channels to detect potential defects specific to each channel.

9. The method of claim 7, wherein the plurality of data channels includes one or more of: a gauge channel representing a lateral distance between the one or more rails of the railroad track; a crosslevel channel representing vertical distance between a top of a first rail of the one or more rails of the railroad track and a top of a second rail of the one or more rails of the railroad track; an alignment channel representing lateral deviation between the one or more rails of the railroad track over a traveled distance; a surface channel representing vertical deviation over between the top of the first rail of the one or more rails of the railroad track and the top of the second rail of the one or more rails of the railroad track over the traveled distance; a curvature channel representing a degree of curvature of the railroad track over the traveled distance; a dip channel representing localized depressions along a longitudinal profile of the track over a distance; a cant channel representing an inclination angle of each rail of the track relative to a horizontal plane of a respective rail; and an unbalance channel representing deviations from a configured superelevation of the track over a distance.

10. A system configured for capturing and processing rail profile data, comprising: at least one processor; and a memory operably coupled to the at least one processor and storing processor- readable code that, when executed by the at least one processor, is configured to perform operations including: receiving, from one or more on-board rail profile capture systems mounted to a railroad vehicle, one or more track geometry data (TGD) files, wherein each TGD file of the one or more TGD files includes a plurality of TGD records including TGD calculated over a measured distance of a track, and wherein each TGD record of the TGD records is associated with a respective predetermined interval along the track; applying one or more defect detection algorithms to the plurality of TGD records to detect one or more potential defects associated with the track; validating the one or more potential defects to determine whether each potential defect is a false positive; discarding potential defects of the one or more potential defects determined to be false positives; generating an alert based on each potential defect of the one or more potential defects determined to be a valid defect; and automatically sending a signal to initiate a corrective action in response to the alert generated for each potential defect of the one or more potential defects determined to be a valid defect.

11. The system of claim 10, wherein the operations further comprise: analyzing the plurality of TGD records using a data validation manager configured with one or more machine learning models to distinguish between valid TGD and noise within the plurality of TGD records; filtering out TGD records identified as noise by the data validation manager; and retaining TGD records classified as valid TGD by the data validation manager for subsequent defect detection and validation processing.

12. The system of claim 10, wherein the operations further comprise preparing the one or more TGD files for detailed analysis.

13. The system of claim 12, wherein preparing the one or more TGD files for detailed analysis includes converting the one or more TGD files into a standardized format compatible for to processing by the one or more defect detection algorithms.

14. The system of claim 12, wherein preparing the one or more TGD files for detailed analysis includes associating each TGD record within the one or more TGD files with corresponding location information obtained from a global positioning system (GPS) module.

15. The system of claim 14, wherein the location information associated with each TGD record is converted into a geographic information systems (GIS) coordinate that represents a physical location along the track that is referenced from the center of the track.

16. The system of claim 10, wherein the plurality of TGD records in a TGD file of the one or more TGD files is configured across a plurality of data channels related to the geometry of the railroad track.

17. The system of claim 16, wherein the one or more defect detection algorithms are applied separately to each channel of the plurality of data channels to detect potential defects specific to each channel.

18. The system of claim 16, wherein the plurality of data channels includes one or more of: a gauge channel representing a lateral distance between the one or more rails of the railroad track; a crosslevel channel representing vertical distance between a top of a first rail of the one or more rails of the railroad track and a top of a second rail of the one or more rails of the railroad track; an alignment channel representing lateral deviation between the one or more rails of the railroad track over a traveled distance; a surface channel representing vertical deviation over between the top of the first rail of the one or more rails of the railroad track and the top of the second rail of the one or more rails of the railroad track over the traveled distance; a curvature channel representing a degree of curvature of the railroad track over the traveled distance; a dip channel representing localized depressions along a longitudinal profile of the track over a distance; a cant channel representing an inclination angle of each rail of the track relative to a horizontal plane of a respective rail; and an unbalance channel representing deviations from a configured superelevation of the track over a distance.

19. A computer-based tool for capturing and processing rail profile data, the computer-based tool including non-transitory computer readable media having stored thereon computer code which, when executed by a processor, causes a computing device to perform operations comprising: receiving, from one or more on-board rail profile capture systems mounted to a railroad vehicle, one or more track geometry data (TGD) files, wherein each TGD file of the one or more TGD files includes a plurality of TGD records including TGD calculated over a measured distance of a track, and wherein each TGD record of the TGD records is associated with a respective predetermined interval along the track; applying one or more defect detection algorithms to the plurality of TGD records to detect one or more potential defects associated with the track; validating the one or more potential defects to determine whether each potential defect is a false positive; discarding potential defects of the one or more potential defects determined to be false positives; generating an alert based on each potential defect of the one or more potential defects determined to be a valid defect; and automatically sending a signal to initiate a corrective action in response to the alert generated for each potential defect of the one or more potential defects determined to be a valid defect.

20. The computer-based tool of claim 19, wherein the operations further comprise: analyzing the plurality of TGD records using a data validation manager configured with one or more machine learning models to distinguish between valid TGD and noise within the plurality of TGD records; filtering out TGD records identified as noise by the data validation manager; and retaining TGD records classified as valid TGD by the data validation manager for subsequent defect detection and validation processing.