Systems and methods for generating track geometry data for railway track analysis

Abstract

Systems and techniques for generating track geometry data (TGD) for railroad track analysis. In embodiments, rail profile data for each of the rails of a track may be obtained at regular intervals as a vehicle carrying the system traverses the track. The rail profile data may be validated, and reference points on the profiles of each of the rails corresponding to specific geometric features of the rails may be identified. The rail profile data may be filtered and processed to generate track geometry data. The track geometry data may include data for a plurality of data channels. The track geometry data may be transmitted to a backend system receives for further processing to determine rail defects, and to generate notifications and alerts based on the determined defects. The system utilizes machine learning algorithms and models for defect detection and validation.

Description

SYSTEMS AND METHODS FOR GENERATING TRACK GEOMETRY DATA FOR RAIL WA Y TRACK ANALYSISTECHNICAL FIELD

[0001] The present disclosure relates generally to railway track monitoring technology, and more particularly to systems and methods for generating track geometry data from rail profile data.BACKGROUND

[0002] Railway tracks are an integral part of the transportation infrastructure, enabling the movement of goods and passengers over long distances. The condition of these tracks is of paramount concern to railway operators, as defects can lead to derailments, delays, and other safety issues. 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. Left undetected or unaddressed, these defects can escalate into serious failures, including derailments, which not only endanger public safety but also inflict severe economic damage through service disruptions and infrastructure repair costs. Therefore, regular monitoring and maintenance of railway tracks are imperative to ensure safe and efficient operations.

[0003] One aspect of railway track monitoring involves the analysis of the track’s geometry. Track geometry refers to the three-dimensional layout of a track, including its horizontal and vertical alignment, curvature, and other parameters. These parameters are typically measured using manual approaches, with track inspectors employing a variety of specialized tools to measure these track parameters. This manual inspection process, while thorough, is fraught with challenges. It is inherently slow and labor-intensive, making it difficult to cover extensive track networks comprehensively. The precision of these inspectionsis also limited by human factors, including variability in measurement techniques and the potential for error. The vastness of railway networks exacerbates these issues, rendering it nearly impractical to manually inspect every segment of track with the frequency and detail that would be ideal for ensuring safety and preventing failures.

[0004] Inspectors face additional risks due to the nature of their work environment. Conducting inspections on or near active tracks exposes them to potential accidents, while the physical demands of the job and exposure to adverse weather conditions can affect their wellbeing and the accuracy of their assessments. As rail traffic increases and trains become faster and heavier, the pressure on the tracks — and the demand for more frequent and detailed inspections — grows. The railway industry is acutely aware of the pressing demand for more efficient, accurate, and safer track inspection methods.

[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 of these 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 orreliability 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 generating track geometry data for railroad track analysis. In embodiments, an innovative system is configured to enhance the safety and reliability of railway transportation by providing a comprehensive solution for railway track monitoring and defect detection through the generation of track geometry data for railroad track analysis. The system of embodiments is configured to capture the profile of the rails on a train track with high precision, validate the captured profile information, identify reference points of the rails, and then use the information to calculate data associated with different aspects of the geometry of the train track to generate track geometry data. The track geometry data generated is used to identify potential defects on the track and to reports and alerts based on the identified defects.

[0009] As such, the present disclosure provides for a system integrated into a practical application with meaningful limitations as that represent an improved system for railway 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 railway track monitoring, offering increased safety, reduced maintenance costs, and a streamlined, non-intrusive inspection process in line with modem operational demands.

[0010] For example, a system implemented in accordance with the present disclosure may provide automated high-speed data capture through an on-board rail profile capture system. Configured for efficiency, this component captures rail profile data at high velocities, enabling continuous track monitoring without impeding rail traffic. This capability facilitates more frequent and thorough inspections, which aids in the early detection of potential track defects.

[0011] Another significant technical improvement is the system’s precise interval data collection. Leveraging one or more wheel encoders, the system is designed to capture rail profile data at exact, predetermined intervals, such as every foot of track traversed. This technical approach yields a detailed, continuous profile of the railway track, affording a granular view of its condition and contributing to enhanced maintenance strategies.

[0012] Further augmenting the system’s improved performance is the inclusion of an inertial measurement unit (IMU), which captures the orientation of the railroad vehicle. This orientation data is crucial for refining rail profile information, adjusting for the vehicle’s movement and alignment to ensure that the TGD accurately represents the track’s actual condition.

[0013] In terms of data processing and analysis, a main computer plays a pivotal role, processing captured rail profile data to generate comprehensive TGD. This data spans multiple channels, including gauge, crosslevel, alignment, surface, and curvature, derived from both static and chordal measurements. This extensive analysis provides a thorough examination of the track’s geometry, enhancing the monitoring process.

[0014] 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 railway 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.

[0015] In embodiments, the present disclosure includes techniques for training models (e.g., machine-learning models, artificial intelligence models, algorithmic constructs, etc.) forperforming or executing a designated task or a series of tasks (e.g., one or more features forTGD 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.

[0016] 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 structuredaccording 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.

[0017] 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 effectivelymanage 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.

[0018] 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 theart 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.

[0019] It is an object of the disclosure to provide a method of generating TGD for railroad track analysis. It is a further object of the disclosure to provide a system generating TGD for railroad track analysis, and a computer-based tool for generating TGD for railroad track analysis. These and other objects are provided by the present disclosure, including at least the following embodiments.

[0020] In one particular embodiment, a method of generating TGD for railroad track analysis is provided. The method includes obtaining, from one or more profile capture sensors mounted on a railroad vehicle, rail profile data associated with one or more rails of a track at a predetermined interval. In embodiments, the rail profile data includes a set of data points for each of the one or more rails defining a profile of a respective rail. The method also includes obtaining inertial measurement unit (IMU) data including rates and angles of an orientation of the railroad vehicle, identifying, based on the rail profile data, one or more reference points on the profiles of each of the rails corresponding to specific geometric features of the rails, calculating, based on the rail profile data and the IMU data, a plurality of data channels related to the geometry of the railroad track, generating TGD for the predetermined interval based on the data calculated for the plurality of data channels, and integrating the TGD for the predetermined interval into a TGD file to be transmitted to a backend rail profile processing system via a network. In embodiments, the TGD file is processed at the backend rail profile processing system to determine defects on the railroad track and to generate track defect reports and notifications based on the determined defects.

[0021] In another embodiment, a system for generating TGD for railroad track analysis is provided. The system comprises at least one processor and a memory operably coupled tothe 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 obtaining, from one or more profile capture sensors mounted on a railroad vehicle, rail profile data associated with one or more rails of a track at a predetermined interval. In embodiments, the rail profile data includes a set of data points for each of the one or more rails defining a profile of a respective rail. The operations also include obtaining IMU data including rates and angles of an orientation of the railroad vehicle, identifying, based on the rail profile data, one or more reference points on the profiles of each of the rails corresponding to specific geometric features of the rails, calculating, based on the rail profile data and the IMU data, a plurality of data channels related to the geometry of the railroad track, generating TGD for the predetermined interval based on the data calculated for the plurality of data channels, and integrating the TGD for the predetermined interval into a TGD file to be transmitted to a backend rail profile processing system via a network. In embodiments, the TGD file is processed at the backend rail profile processing system to determine defects on the railroad track and to generate track defect reports and notifications based on the determined defects.

[0022] In yet another embodiment, a computer-based tool for generating TGD for railroad track analysis 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 obtaining, from one or more profile capture sensors mounted on a railroad vehicle, rail profile data associated with one or more rails of a track at a predetermined interval. In embodiments, the rail profile data includes a set of data points for each of the one or more rails defining a profile of a respective rail. The operations also include obtaining IMU data including rates and angles of an orientation of the railroad vehicle, identifying, based on the rail profile data, one or more reference points on the profiles of each of the rails corresponding to specific geometric featuresof the rails, calculating, based on the rail profile data and the IMU data, a plurality of data channels related to the geometry of the railroad track, generating TGD for the predetermined interval based on the data calculated for the plurality of data channels, and integrating the TGD for the predetermined interval into a TGD file to be transmitted to a backend rail profile processing system via a network. In embodiments, the TGD file is processed at the backend rail profile processing system to determine defects on the railroad track and to generate track defect reports and notifications based on the determined defects.

[0023] 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

[0024] 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:

[0025] 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.

[0026] FIG. 2 is a block diagram illustrating an example of operations of an on-board rail profile capture system configured with capabilities and functionality for capturing rail profile data and generating track geometry data in accordance with embodiments of the present disclosure.

[0027] FIG. 3 is a block diagram illustrating an example of operations of a track geometry data (TGD) calculations manager configured with capabilities and functionality for generating track geometry data based on rail profile data in accordance with embodiments of the present disclosure.

[0028] FIG. 4 shows a high-level flow diagram of operation of a system configured for providing functionality for generating track geometry data in accordance with embodiments of the present disclosure.

[0029] FIG. 5 shows a high-level flow diagram of operation of a system configured for providing functionality for detecting the top and gauge face point of a rail in accordance with embodiments of the present disclosure.

[0030] FIGS. 6A-6D show diagram illustrating operations to detect the head and gauge face point of a rail in accordance with embodiments of the present disclosure.

[0031] FIG. 7 is a flowchart illustrating operations for generating TGD for railroad track analysis in accordance with embodiments of the present disclosure.

[0032] 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

[0033] 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.

[0034] 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.

[0035] Various embodiments of the present disclosure are directed to systems and techniques that provide functionality for railway track monitoring and defect detection. In embodiments, the functionality for railway track monitoring and defect detection may include functionality to capture (e.g., using an on-board rail profile capture system mounted to a railroad vehicle) rail profile data at regular intervals as the railroad vehicle traverses a railroad track. The captured rail profile data may be used to generate track geometry data (TGD), which may include a plurality of data channels that may be indicative of the condition of the railroad track. The TGD may be sent to a backend rail profile processing system, which may be configured to process the TGD and to determine the presence of defects on the railroad track and to generate track defect reports and notifications. These track defect reports and notifications 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.

[0036] 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.

[0037] FIG. 1 is a block diagram of an exemplary system 100 configured with capabilities and functionality for railway 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 rail profile processing system 150, userterminal 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 profile capture system 110 may be in communication with backend rail profile processing system 150 (e.g., via a network 145) and may send the TGD 111 to backend rail profile processing system 150. Backend rail profile 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.

[0038] 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.

[0039] 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 illustratedcomponents 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.

[0040] 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.

[0041] 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 thepresent disclosure. In embodiments, user terminal 130 may be configured to communicate with other components of system 100.

[0042] In embodiments, network 145 may facilitate communications between the various components of system 100 (e.g., on-board rail profile capture system 110, backend rail profile 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 Local 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.

[0043] System 100 is meticulously architected and / or 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 1 10, 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 1 10 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 11 1 to backend rail profile processing system 150.

[0044] The second main component of system 100 includes backend rail profile processing system 150, which may serve as the analytical and reporting hub for the datacollected by the on-board rail profile capture system 110. Backend system 150 may be tasked with the more complex processing of TGD 1 11, including the application of machine learning algorithms and models to accurately identify and classify defects on the railroad track. Additionally, backend rail profile 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.

[0045] 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.

[0046] As noted above, on-board rail profile 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.

[0047] In embodiments, on-board rail profile capture system 110 may be configured to withstand a wide range of environmental conditions. Whether it’s operating under the scorching sun, in heavy rain, or in freezing temperatures, on-board rail profile capture system 110 may be configured to function reliably and deliver accurate data. This robustness ensures that on-board rail profile capture system 110 can be used for track monitoring in variousgeographical locations and climates, making it a versatile solution for railway operators worldwide. On-board rail profile capture system 110 represents a sophisticated piece of technology that plays a pivotal role in the railway track monitoring process. On-board rail profile capture system 110’s ability to capture precise rail profile data at high speeds and under various environmental conditions ensures that railway operators have access to reliable and timely information about the condition of their tracks, enabling them to detect and address potential defects promptly and effectively.

[0048] In embodiments, on-board rail profile capture system 110 is 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).

[0049] 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, and curvature. 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.

[0050] On-board rail profile capture system 110 may intelligently determine when to transmit the TGD file including TGD 111 to backend rail profile 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 rail profile 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 rail profile 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 rail profile 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.

[0051] Backend rail profile 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 on-board 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 rail profile 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.

[0052] For example, upon receiving the TGD file including TGD 111 from on-board rail profile capture system 110, backend rail profile processing system 150 may engage in a thorough analysis of TGD 111 across the various TGD channels. Backend rail profileprocessing 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 rail profile 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.

[0053] 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.

[0054] 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 rail profile processing system 150 may alert maintenance crews to areas that require resurfacing or other corrective measures to restore the track to its proper condition.

[0055] In embodiments, backend rail profile 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 rail profile processing system 150 may alsobe configured to validate the detected defects to filter out false positives, ensuring that the maintenance resources are directed towards genuine concerns. For example, backend rail profile processing system 150 may be equipped with validation mechanisms to ensure the reliability of the defect detection process. Backend rail profile 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 rail profile processing system 150 enhances the accuracy of its diagnostics, and optimizes maintenance operations and resource allocation.

[0056] In embodiments, once detected defects are confirmed and / or validated, backend rail profile 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 rail profile 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.

[0057] For example, in response to identifying a defect within TGD 111, backend rail profile 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 rail profile 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 rail profile processing system 150 may send a signal to initiate the adjustment process automatically.

[0058] Similarly, if the surface channel analysis detects an uneven section of track that requires grinding or leveling, backend rail profile 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.

[0059] Backend rail profile 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.

[0060] Operations of on-board rail profile capture system 110 will now be discussed with respect to FIG. 2. FIG. 2 is a block diagram illustrating an example of operations of an on-board rail profile capture system 110 configured with capabilities and functionality for capturing rail profile data and generating track geometry data in accordance with embodiments of the present disclosure. In embodiments, functionality of on-board rail profile capture system 110 for capturing rail profile data associated with the rails of track 115 and generating TGD may be provided by the cooperative operation of the various components of on-board rail profile capture system 110, as will be described in more detail below.

[0061] It is noted that although FIG. 2 shows on-board rail profile capture system 110 as a single component, it will be appreciated that on-board rail profile capture system 110 (and the individual functional blocks of on-board rail profile capture system 110) may beimplemented 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 on-board rail profile capture system 110 as single and separate blocks, each of the various components of on-board rail profile capture system 110 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 on-board rail profile capture system 1 10 may actually be part of a different component of on-board rail profile capture system 110, and as such, the description of the particular functionality described for the particular component of on-board rail profile capture system 110 is for illustrative purposes and not limiting in any way.

[0062] As shown in FIG. 2, on-board rail profile capture system 110 includes processor 111, memory 112, data processor 120, TGD calculations manager 121, TGD file generator 122, TGD file transmission manager 123, one or more profile capture sensors 125, inertial measurement unit (IMU) 126, one or more wheel encoders 127, one or more sun shields 128, and database 114.

[0063] 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.

[0064] 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.

[0065] 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 on-board rail profile capture system 110. In embodiments, database 114 may store information related to various models used during operations of on-board rail profile capture system 110, such as a mathematical and / or machine learning algorithms used to generate TGD data from rail profile data. 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.

[0066] In embodiments, one or more wheel encoders 127 may be mounted directly to the wheels of the railroad vehicle and may be configured to generate a series of pulses as the wheels of the railroad vehicle rotate. Each pulse corresponds to a specific increment of distance traveled, allowing the system to calculate the total distance covered by the vehicle with a high degree of accuracy. This information may be used by the on-board rail profile capture system 110 to synchronize the capture of rail profile data with the physical location along the track, ensuring that the data collected is spatially accurate and can be correlated with specific sections of the railway track.

[0067] One or more sun shields 128 may be configured and positioned to mitigate the impact of direct sunlight on the rail, which can interfere with the accuracy and reliability of the one or more profile capture sensors 125. For example, one or more sun shields 128 may be strategically designed components of the on-board rail profile capture system 110, serving a specific purpose in ensuring the accuracy and reliability of the rail profile data capture process. One or more sun shields 128 may be positioned to protect the one or more profile capture sensors 125 from the direct interference of sunlight, which can introduce noise and errors into the data collection by causing glare or reflections on the rails of track 115. By effectively blocking these unwanted light sources, one or more sun shields 128 ensure that the profile capture sensors can operate with maximum precision under a wide range of environmental lighting conditions.

[0068] One or more profile capture sensors 125 represent a central component of onboard rail profile capture system 110, and may play a pivotal role in the acquisition of rail profile data as the railroad vehicle moves along track 115. One or more profile capture sensors125 may include one or more profilometers configured to capture detailed rail profile data, which may provide insights into the shape and profile of each rail — left and right — of the track.As the railroad vehicle on which on-board rail profile capture system 110 may be mounted travels or moves along track 115, one or more profile capture sensors 125 may capture the rail profile data of each of the left and right rails of track 115.

[0069] In embodiments, one or more profile capture sensors 125 may include one or more laser modules. For example, one or more profile capture sensors 125 may include a right laser module configured to capture rail profile data associated with the right rail of track 115 and a left laser module configured to capture rail profile data associated with the left rail of track 115. Right and left orientations may be with respect to the travel direction of the railroad vehicle. In embodiments, each laser module may include a laser beam projector configured to project a laser beam onto a corresponding rail and a camera configured to detect the reflections of the laser beam. For example, the right laser module may include a laser beam projector configured to project a laser beam onto the right rail of track 115 and a camera configured to detect the reflections of the laser beam, and the left laser module may include a laser beam projector configured to project a laser beam onto the left rail of track 115 and a camera configured to detect the reflections of the laser beam.

[0070] In embodiments, the laser module may translate the reflections of the laser beam captured by the camera into a series of reflection points that collectively define the rail’s profile. Each reflection point may be recorded as an x-y coordinate, relative to the laser module’s position. In this manner, each of the one or more profile capture sensors 125 effectively maps out the corresponding rail’s profile, contour, and dimensions at precise intervals along the length of track 115 (e.g., at each foot of track traversed).

[0071] IMU 126 may be configured to capture the dynamic orientation and movement of the railroad vehicle om which on-board rail profile capture system 110 may be mounted as the railroad vehicle travels along track 115. IMU 126 may be configured to measure and recordthe vehicle’s angular rates and orientation angles — specifically roll, pitch, and yaw — which are pivotal in understanding the vehicle’s positioning in three-dimensional space. This orientation information is particularly valuable when the railroad vehicle is navigating through varying terrains, such as inclines, declines, and curves along the railway track.

[0072] In embodiment, the data captured by IMU 126 may be utilized by on-board rail profile capture system 110 to enhance the accuracy of the rail profile data collected by the one or more profile capture sensors 125. By factoring in the railroad vehicle’s orientation, on-board rail profile capture system 110 may adjust the rail profile data to account for the vehicle’s movement, ensuring that the TGD reflects the true condition of the track rather than artifacts introduced by the railroad vehicle’s motion. For example, if the vehicle is on an incline, IMU 126 data can be used to differentiate between actual track elevation changes and those perceived due to the angle of the vehicle.

[0073] In some embodiments, IMU 126 may facilitate filtering the rail profile data based on the frequency of the IMU data. High-frequency data may indicate transient vibrations or bumps that are not indicative of the track’s structural integrity, while low-frequency data may reveal long-term track deformations or curvatures. By analyzing the IMU data in conjunction with the rail profile data, on-board rail profile capture system 110 may more accurately identify areas of concern that may require further inspection or immediate maintenance.

[0074] In embodiments, IMU 126 may also contribute to on-board rail profile capture system 110’s ability to map the track’s geometry with precision. For example, the inclusion of global positioning system (GPS) data (e.g., within the IMU 126’s functionality or external to IMU 126) allows for the precise geolocation of any detected track defects, facilitating targeted maintenance efforts. This geospatial awareness is particularly beneficial for railway operatorsmanaging extensive track networks, enabling them to pinpoint the exact location of potential issues quickly and efficiently. In some embodiments, the GPS data may be provided by a component external and separate from IMU 126, even though the description herein may describe the GPS data as provided by IMU 126. As such, it should be appreciated that the description herein of GPS data as provided by IMU 126 is for illustrative purposes and should not be construed as limiting in any way.

[0075] As mentioned above, on-board rail profile capture system 110 may be configured with capabilities and functionality for not only capturing rail profile data, but also processing the captured rail profile data to calculate and generate TGD. This functionality of on-board rail profile capture system 110 may be provided by the cooperative functionality and operations of data processor 120, TGD calculations manager 121, TGD file generator 122, TGD file transmission manager 123.

[0076] As also mentioned above, the rail profile data associated with a rail of track 115 encompasses a collection of data points, each captured by a respective one of the one or more profile capture sensors 125. These data points are defined as x-y coordinates, with each coordinate representing a specific location along the rail’s profile relative to the vantage point of the profile capture sensor. This capture of coordinates results in a detailed set of data points that collectively outline the contour and dimensions of the rail as perceived by the sensor. In this manner, the rail profile data associated with a rail represents a comprehensive representation of the rail’s profile.

[0077] Data processor 120 may be configured to serves as the initial processing unit for the rail profile data captured by the one or more profile capture sensors 125. As the railroad vehicle traverses the track 115, the left and right sensors collect rail profile data for their respective rails. This data, consisting of a series of x-y coordinates that map the rail’s profile,is then relayed to data processor 120. Data processor 120 may be tasked with the preliminary analysis and refinement of this raw data, preparing it for further processing and the generation of TGD.

[0078] In embodiments, data processor 120 may be configured to detect specific features of the rail, such as the top of the rail head — the uppermost portion of the rail’s head — and the gauge face, which is the interface surface of the rail head that comes into contact with train wheels. In other embodiments, the functionality of data processor 120 to detect specific features of the rail, such as the top of the rail head and the gauge face may be combined with the functionality ofTGD calculations manager 121.

[0079] TGD calculations manager 121 may be configured to transform the rail profile data captured by the one or more profile capture sensors into TGD 1 11. TGD calculations manager 121 may leverage mathematical and machine learning algorithms to analyze the intricacies of the rail profile data, enabling the calculation of various geometric parameters that define the track’s condition. In this manner, TGD 111 is not merely a singular data point but represents a comprehensive set of data channels, each representing a different geometric aspect of the track 115. Details of the functionality and operations of TGD calculations manager 121 will be discuss in more detail below, with respect to FIGS. 3-6D.

[0080] TGD file generator 122 may be configured to compile and organize the data in the various channels of TGD 111 into a coherent and manageable format. In embodiments, after TGD calculations manager 121 has processed the rail profile data to calculate the data for the various channels of the TGD, TGD file generator 122 generates a structured TGD file that encapsulates this valuable information. In embodiments, the functionality of TGD file generator 122 to compile and organize the data in the various channels of TGD 111 into acoherent and manageable format may be combined with the functionality of TGD calculations manager 121.

[0081] In embodiments, TGD file generator 122 operates based on a set of configurable parameters that dictate how TGD 111 is to be packaged in the TGD file. These parameters may be tailored to meet specific operational requirements or preferences. For example, one such parameter may specify that the TGD file is to encompass data for a particular distance of travel. This could range from 1 to 50 miles, allowing for flexibility in data segmentation. If the parameter is set for 30 miles, for example, TGD file generator 122 may compile all the data for the different channels of TGD 111 corresponding to that 30-mile stretch of track into a single TGD file. This segmentation facilitates easier handling and analysis of the data by breaking it down into manageable sections that correspond to distinct segments of the railway.

[0082] In addition, or in the alternative to distance-based segmentation, TGD file generator 122 may be configured to create TGD files based on size. This may be particularly useful for ensuring compatibility with data transmission and storage systems that may have limitations on file size. By setting a parameter for the file size, such as a maximum of 1MB to 50MB, TGD file generator 122 may accumulate channel data of TGD 111 until the file reaches the specified size threshold before finalizing the TGD file. This approach ensures that the TGD files are neither too large to handle efficiently nor too small to be meaningful, striking a balance that suits the system’s operational context.

[0083] TGD file transmission manager 123 may be configured to send the TGD file to the backend rail profile processing system for processing, such as to determine defects or maintenance requirements, and / or generate notification and alerts based on the track geometry data.

[0084] Operations and functionality of TGD calculations manager 121 will now be discussed with respect to FIG. 3. FIG. 3 is a block diagram illustrating an example of operations of a TGD calculations manager 121 configured with capabilities and functionality for generating track geometry data based on rail profile data in accordance with embodiments of the present disclosure. In particular, TGD calculations manager 121 may be configured with capabilities for generating TGG (e.g., TGD 111) based, at least in part, on rail profile data 325, IMU data 326, and encoder pulses 327. In embodiments, functionality of TGD calculations manager 121 for generating TGD in accordance with embodiments of the present disclosure may be provided by the cooperative operation of the various components of TGD calculations manager 121, as will be described in more detail below.

[0085] As shown, TGD calculations manager 121 may include gauge and crosslevel calculator 310, geometry calculations prefilter 312, geometry point data calculator 314, geometry chordal data calculator 316, and TGD data generator 318.

[0086] Encoder pulses 327 represent data signals (e.g., one or more encoder pulses) received from one or more wheel encoders (e.g., one or more wheel encoders 127 of FIG. 2). As noted above one or more wheel encoders may be mounted on one or more wheels of the railroad vehicle and may be configured to generate pulses corresponding to the rotation of the wheels. Each pulse may signify a specific increment of distance traveled by the railroad vehicle, providing a precise and continuous measurement of the distance covered as the vehicle traverses the railway track. Encoder pulses 327 may operate as an input for the TGD calculations manager 121, enabling the synchronization of rail profile data capture with the physical location along the track, ensuring spatial accuracy in the representation of the track’s geometry.

[0087] IMU data 326 may include measurements obtained from an IMU (e.g., IMU 126 of FIG. 2). In embodiments, IMU data 326 may include data related to the dynamic orientation and movement of the railway vehicle as it navigates the railway track as captured by IMU 126. This IMU data 326 may include angular rates and orientation angles such as roll, pitch, and yaw, which may be used to determine the railroad vehicle’s positioning and movement in three-dimensional space. IMU data 326 may be particularly valuable when the railway vehicle encounters varying terrains, such as inclines, declines, and curves along the track, as it provides context to the rail profile data by accounting for the railroad vehicle’s orientation.

[0088] In embodiments, IMU data 326 may be utilized by TGD calculations manager 121 to refine the rail profile data captured by the one or more profile capture sensors. By incorporating the orientation data from the IMU 126, TGD calculations manager 121 may adjust the rail profile data to accurately reflect the track’s geometry, independent of the vehicle's motion or orientation. This ensures that the calculated TGD is a true representation of the track’s condition, rather than an artifact of the vehicle’s dynamics. In additional or alternative embodiments, IMU data 326 may be used to filter out high-frequency vibrations or movements that may not be indicative of the track’s structural integrity, allowing for a more focused analysis of the track’s geometry and the identification of potential defect.

[0089] Rail profile data 325 may include the detailed information captured by one or more profile capture sensors (e.g., one or more profile capture sensors 125 of FIG. 2) mounted on the railway vehicle. In embodiments, rail profile data 325 may forms the basis for analyzing the physical characteristics of the railway track. Rail profile data 325 may encompass a set of precise measurements that define the shape or profile of the rails. In particular, rail profile data325 may include rail profile data associated with each rail (e.g., right rail and left rail) of therailroad track being inspected (e.g., the railroad track over which the railroad vehicle to which on-board rail profile capture system 110 may be mounted may be traveling). For example, rail profile data 325 may include a set of data points for each rail (e.g., a set of data points associated with the right rail and a set of data points associated with the left rail), each data set captured by a respective one of the one or more profile capture sensors 125 (e.g., the set of data points associated with the right rail captured by a right profile capture sensor and the set of data points associated with the left rail captured by a left profile capture sensor). The data points in a set of data points associated with a rail may be defined as x-y coordinates, with each coordinate representing a specific location along the rail’s profile relative to the vantage point of the profile capture sensor that captured the data points. This capture of coordinates results in a detailed set of data points that collectively outline the contour and dimensions of the rail as perceived by the sensor. In this manner, the rail profile data associated with a rail represents a comprehensive representation of the rail’s profile.

[0090] In embodiments, rail profile data 325 may be captured at regular or predetermined intervals to provide a continuous and detailed representation of the track’s geometry over the distance covered by the railroad vehicle. For example, the predetermined interval may include an interval of anywhere between half a foot to five feet. In these embodiments, rail profile data 325 may be captured every time the railroad vehicle is determined to have traveled the predetermined interval. For example, rail profile data 325 may be captured at a first point, then rail profile data 325 may be captured may be captured again when the railroad vehicle is determined to have moved the predetermined interval from the first point. In a specific example, the predetermined interval may be one foot. In this example rail profile data 325 may be captured every foot of track traveled by the railroad vehicle. In these embodiments, encoder pulses 327 may be configured to be generated each time the railroadvehicle has traveled the predetermined interval. As such, on-board railroad system 110 may operate to capture rail profile data 325 in response to an encoder pulse being detected.

[0091] In embodiments, TGD calculations manager 121 may be configured to transform rail profile data 325 into TGD (e.g., TGD 111). TGD calculations manager 121 may leverage the functionality of gauge and crosslevel calculator 310, geometry calculations prefilter 312, geometry point data calculator 314, geometry chordal data calculator 316, and TGD data generator 318. In particular embodiments, the TGD generated by TGD calculations manager 121 represents a comprehensive set of data channels, each representing a different geometric aspect of the railroad track. In embodiments, these channels include a gauge channel, a crosslevel channel, an alignment channel, a surface channel, and a curvature channel.

[0092] The gauge channel may include calculations related to the lateral distance between the right and left rails of the track. The gauge channel’s calculations may be performed at each predetermined interval of the track, using the rail profile data captured for that specific location of the track. The data in the gauge channel may be a static measurement, meaning it is independent of the measurements taken at other track feet, providing a snapshot of the track width at each measured point.

[0093] The crosslevel channel may include calculations related to the vertical distance between the top of the right rail and the top of the left rail of the track, offering a precise vertical profile of the track at each measured point. The data in the crosslevel channel may be particularly useful for identifying any tilting or unevenness that could affect train stability. The crosslevel channel’s calculations may be performed at each predetermined interval of the track, using the rail profile data captured for that specific location of the track. For example, for a predetermined interval of a foot, crosslevel measurements may be included in the crosslevel channel for every foot of track traveled, or each track foot. The data in the crosslevel channelmay be a static measurement, meaning it is independent of the measurements taken at other track feet, providing a snapshot of the vertical profile of the track at each measured point.

[0094] In contrast to the static measurements (e.g., the gauge and crosslevel channels), some channels may include chordal measurements that require rail profile data over a series of track feet. For example, the alignment channel may include calculations related to the lateral deviation of the rails of the track over a specified distance, providing an indication of the track’s straightness. The surface channel may include calculations related to the vertical deviation between the tops of the rails over a distance, identifying any long-term undulations or dips in the track. The curvature channel may include calculations related to the degree of curvature of the track over a distance, incorporating aggregated rail profile data and potentially GPS data to determine the track’s overall bend. The curvature channel may be particularly relevant for assessing the track’s geometry in curves and ensuring that the curvature falls within safe operational limits.

[0095] Gauge and crosslevel calculator 310 may be configured to calculate the gauge level data for the gauge channel of the TGD and the crosslevel data for the crosslevel data of the crosslevel channel of the TGD. The gauge channel involves calculations pertaining to the lateral distance between the right and left rails of the railway track, while the crosslevel channel concerns the vertical distance between the tops of the right and left rails. These measurements are foundational for assessing the track’s geometry and are performed at each predetermined interval along the track, such as every foot of track traveled.

[0096] For the gauge channel, gauge and crosslevel calculator 310 determines the lateral distance between the rails by analyzing the rail profile data 325 captured for each rail to determine the lateral (GF_Xdifference) and vertical (GF_Ydifference) distances between the laser projector and the gauge face of each rail, based on the rail profile data 325. Utilizingthese distances, gauge and crosslevel calculator 310 applies the Pythagorean theorem to compute the gauge deviation between the two rails, given that the fixed distance between the laser projectors is a known value. An example of a gauge calculation by gauge and crosslevel calculator 310 to determine the lateral distance between the left and right rail of the track may be performed using equation 1 as follows:Gauge = square_root((GF_Xdifference * GF_Xdifference) + (GF _Ydifference * GF_Ydifference)) - 1435 - GaugeOffset (Equation 1), where 1435 refers to the standard gauge distance of 1435mm, equivalent to 56.5 inches, GaugeOffset is a calibration value for system adjustments, GF_Xdifference is the lateral distance between the laser projector and the gauge face of the rail, and GF_Ydifference is the vertical distance between the laser projector and the gauge face of the rail.

[0097] For the crosslevel channel, gauge and crosslevel calculator 310 calculates the vertical distance between the tops of the rails, taking into account the roll data from the IMU 126 to adjust for the vehicle’s orientation. The crosslevel calculation is a combination of the crosslevel beam value derived from the rail profile data 325 and the roll data from the IMU 126, and the crosslevel laser value based on the vertical difference between the right and left lasers. An example equation for crosslevel calculation is illustrated in Equation 2 as follows:Xlevel = Xlevel_Beam - Xlevel_Laser (Equation 2), where Xlevel_Beam is calculated using the sine of the roll angle and the lateral offsets of the lasers from the center of the main enclosure (e.g., using sine(Roll) * (LeftLaserXoffset + RightLaserXoffset + (-1.0 * LaserlTORx) + Laser2TORx, where Roll is the roll data from IMU 326, LeftLaserXoffset is the distance from the center of the main enclosure to the (0,0) coordinate of the left laser, RightLaserXoffset is the distance from the center of the mainenclosure to the (0,0) coordinate of the right laser, Laser ITORx is the lateral distance between the left laser and the top of the left rail, Laser2TORx is the lateral distance between the right laser and the top of the left rail), and Xlevel_Laser is the vertical difference between the right and left lasers’ measurements from the tops of the rails.

[0098] Geometry calculations prefilter 312 may be configured to enhance the accuracy of the track geometry data by filtering out anomalies that may not be indicative of the track’s structural integrity. This prefiltering process is particularly valuable when the railway vehicle encounters varying terrains and track conditions that could introduce noise into the rail profile data.

[0099] For example, geometry calculations prefilter 312 may be configured to apply filtering techniques to the raw rail profile data 325 to remove high-frequency vibrations or movements that may result from terrain undulations or other transient conditions. These high- frequency components are typically characterized by short wavelengths and do not reflect the true geometry of the railway track. By applying a high-pass filter, geometry calculations prefilter 312 can isolate and remove these transient effects, allowing for a more focused analysis of the track’s geometry.

[0100] In some embodiment, geometry calculations prefilter 312 may be configured identify and preserve low-frequency data that may be indicative of long-term track deformations, such as gradual curves or gradual elevation changes. This low-frequency data is characterized by longer wavelengths and is more likely to represent actual changes in the track’s geometry. By applying a low-pass filter, the prefilter can retain this valuable information while excluding the high-frequency noise. In some embodiments, the low-pass filter information may be used to filter out these low frequency waves, which may also skew the geometry analysis.

[0101] In embodiments, the filtering functionality provided by geometry calculations prefilter 312 may be configurable and may be adjusted based on specific operational requirements. For example, geometry calculations prefilter 312 can be set to apply a 100-foot high-pass filter, which would be suitable for filtering out data over a 1 OO-foot section of the track. This level of configurability ensures that the filtering process is tailored to the characteristics of the railway track being monitored and the specific objectives of the track geometry analysis.

[0102] Geometry point data calculator 314 may be configured to generate the data for the point data channels of the TGD, such as the gauge and crosslevel channels, which involve measurements that are performed at each predetermined interval along the track and are not dependent on measurements over distance. In embodiments, geometry point data calculator 314 may update the current TGD record (e.g., the current TGD file including the TGD generated over various predetermined interval as the railroad vehicle travels over the track) with the point data values calculated for a current interval for the point data channels by gauge and crosslevel calculator 310. For example, after gauge and crosslevel calculator 310 calculates the gauge and crosslevel data for a predetermined interval, geometry point data calculator 314 may integrate these values into their respective channels within the TGD.

[0103] In some embodiments, the process of integrating the calculated gauge and crosslevel values into the respective channels within the TGD may involve organizing the calculated data into a structured format that is consistent with the TGD's overall data schema, ensuring that the information is accurately represented and readily accessible for analysis. By updating the TGD file with the latest point data channel values, geometry point data calculator 314 ensures that the TGD remains current and reflects the true state of the railroad track’s geometry at each measured interval. This updated TGD file serves as a comprehensive datasetthat can be eventually transmitted to the backend rail profile processing system for further processing and defect analysis.

[0104] Geometry chordal data calculator 316 may be configured to generate the data for the chordal channels of the TGD, such as the alignment, surface, and curvature channels. These chordal channels may represent measurements that are dependent on data captured over multiple predetermined intervals, as opposed to the static point data channels like gauge and crosslevel. In embodiments, the distance over which the chordal data may be calculated may be configurable, and may include distances between 1 foot to 500 feet. For example, with a distance set to 100 feet, geometry chordal data calculator 316 may be configured to calculate chordal data over 100 feet (e.g., alignment, surface, and / or curvature over 100 feet). In some embodiments, the distances over which the chordal data is calculated may be different for different channels. For example, alignment and surface may be calculated over 62 feet distances and curvature may be calculated over 100 feet distances.

[0105] In some embodiments, chordal measurements may be performed based on threshold distances traveled. For example, 31 -foot chordal data may be obtained in response to a determination that the railroad vehicle (e.g., the railroad vehicle on which on-board rail profile capture system 110 is mounted) has traveled at least 31 feet. Similarly, 62-foot chordal data may be obtained in response to a determination that the railroad vehicle has traveled at least 62 feet. In another example, curvature chordal data may be obtained in response to a determination that the railroad vehicle has traveled at least 100 feet. In yet another example, chordal data may be filtered (e.g., with a FIR filter) in response to a determination that the railroad vehicle has traveled at least 300 feet.

[0106] For the alignment channel, geometry chordal data calculator 316 calculates the lateral deviation between the right and left rails over a specified distance. In embodiments,calculating the lateral deviation between the right and left rails over a specified distance may involve aggregating rail profile data captured at each track foot along the distance of track to determine any lateral misalignments. An example of an alignment calculation by geometry chordal data calculator 316 may be performed using equations 3 and 4 as follows:Right_X_Comp = Right_X + LatPosition + Right_X_Roll_Effect (Equation 3)Left_X_Comp = Left_X + LatPosition - Left_X_Roll_Effect (Equation 4), where 'Right_X' is the lateral distance between the right laser and the top of the right rail, 'Left_X' is the lateral distance between the left laser and the top of the left rail, 'LatPosition' is the lateral position of the enclosure, 'Right_X_Roll_Effect' is the effect of the roll, as provided by the IMU data 326, on the 'Right_X' measurement, and 'Left_X_Roll_Effect' is the effect of the roll, as provided by the IMU data 326, on the 'Left_X' measurement.

[0107] In embodiments, geometry chordal data calculator 316 may be configured to push 'Right X Comp' and 'Left X Comp' to respective buffers (e.g., Right X Comp Buffer and Left_X_Comp_Buffer, respectively) and apply a high-pass filter (e.g., a 100-foot high pass finite impulse response (FIR) filter) to isolate the alignment data over the desired distance, such as 62 feet, using equations 5 and 6 as follows:Align62_L = ((Left_X_Comp_Buffer[CurrentIndex] + Left_X_Comp_Buffer[CurrentIndex - 62]) / 2.0) - Left_X_Comp_Buffer [Currentindex - 31] (Equation 5)Align62_R = ((Right_X_Comp_Buffer[CurrentIndex] + Right_X_Comp_Buffer[CurrentIndex - 62]) / 2.0) - Right_X_Comp_Buffer[CurrentIndex - 31] (Equation 6)

[0108] For the surface channel, geometry chordal data calculator 316 calculates the vertical deviation between the right and left rails over a distance. This calculation is similar tothe alignment calculation but focuses on the vertical component. An example of a surface calculation by geometry chordal data calculator 316 may be performed using equations 7 and8 as follows:Right Y Comp = Right Y - VertPosition - BeamRollVerticalEffect_Riglit (Equation 7)Left_Y_Comp = Left_Y - VertPosition - BeamRollVerticalEffect_Left (Equation 8), where 'Right_Y' is the vertical distance between the right laser and the top of the right rail, 'Left_Y' is the vertical distance between the left laser and the top of the left rail, 'VertPosition' is the vertical position of the enclosure, 'BeamRollVerticalEffect_Right' is the effect of the roll on the 'Right_Y' measurement, and 'BeamRollVerticalEffect_Left' is the effect of the roll on the 'Left_Y' measurement.

[0109] In embodiments, geometry chordal data calculator 316 may be configured to push Right Y Comp and Left Y Comp to respective buffers (e.g., Right Y Comp Buffer and Left_Y_Comp_Buffer, respectively), and may apply a high-pass filter (e.g., a 1 OO-foot high FIR filter) to isolate the surface data over the desired distance, such as 62 feet, using equations9 and 10 as follows:Surf62_L = ((Left_Y_Comp_Buffer[CurrentIndex] + Left_Y_Comp_Buffer[CurrentIndex - 62]) / 2.0) - Left_Y_Comp_Buffer[CurrentIndex - 31] (Equation 9)Surf62_R = ((Right_Y_Comp_Buffer[CurrentIndex] + Right_Y_Comp_Buffer[CurrentIndex- 62]) / 2.0) - Right_Y_Comp_Buffer[CurrentIndex - 31] (Equation 10)

[0110] For the curvature channel, geometry chordal data calculator 316 calculates the degree of curvature of the track over a distance, which may include GPS data to determine thetrack’s overall bend. An example of a curvature calculation by geometry chordal data calculator 316 may be performed using procedure 11 as follows:Curvature = Geo_Record_Wall[CurrentIndex].GPSheading -Geo_Record_Wall[CurrentIndex - 100].GPSheading (Procedure 11), where 'GPSheading' is derived from the average yaw over a 60-foot interval, converted to degrees.

[0111] The functionality of geometry chordal data calculator 316 to calculate the data for the chordal channels contributes to the comprehensive analysis of the track’s geometry, enabling the detection of defects that could impact the safety and efficiency of railway operations.

[0112] In embodiments, geometry chordal data calculator 316 may be configured to update the current TGD record (e.g., the current TGD file including the TGD generated over various predetermined interval as the railroad vehicle travels over the track) with the data values calculated for a current interval for the chordal channels. For example, after the alignment, surface, and curvature data has been calculated at the predetermined interval for the predetermined distance, geometry chordal data calculator 316 may integrate these values into their respective channels within the TGD.

[0113] FIG. 4 shows a high-level flow diagram 400 of operation of a system configured for providing functionality for generating track geometry data in accordance with embodiments of the present disclosure. In embodiments, the process illustrated in FIG. 4 may be executed at each predetermined interval, such as every foot of track traveled by the railway vehicle, ensuring that the TGD reflects a continuous and precise representation of the track’s geometry. The high-level flow diagram 400 delineates the sequence of steps undertaken by the on-boardrail profile capture system to process the rail profile data to generate the TGD. In embodiments, each step in the flowchart may correspond to a specific operation that contributes to the detailed analysis of the railway track, facilitating the identification of potential defects and informing maintenance decisions. The interval-based approach ensures that the TGD is updated with high-resolution data that accurately captures the condition of the railway track at each measured point along its length.

[0114] At block 402, the process begins with the reception of an encoder pulse from one or more wheel encoders (e.g., one or more wheel encoders 125 as illustrated in FIG. 2) mounted on the railway vehicle. This encoder pulse signifies that the railway vehicle has reached the next predetermined interval, such as a foot of track traveled, and triggers the onboard rail profile capture system to initiate the generation of TGD for this specific interval. The encoder pulse serves as a precise and reliable indicator that the vehicle has traversed a consistent unit of distance, ensuring that the TGD reflects the track’s geometry with high spatial accuracy at each measured point. This marks the starting point for a series of operations that will process the captured rail profile data and calculate the TGD for the current interval.

[0115] In response to receiving the encoder pulse at block 402, operations proceed to blocks 404, 406, and 408. At block 404, IMU data (e.g., IMU data 326 as illustrated in FIG. 3), which may include orientation and movement information of the railway vehicle, may be obtained, such as from an IMU (e.g., IMU 126 as illustrate in FIG. 2). The IMU data may be instrumental in adjusting the rail profile data to account for the vehicle’s dynamics as described herein and may be used later during operations of block 416 to calculate track geometry.

[0116] At block 406, right rail profile data for the right rail of the track may be obtained. The right rail profile data may include a set of data points defining the precise physical characteristics of the right rail as seen from the right sensor’s perspective. Similarly, at block408, left rail profile data for the left rail of the track may be obtained. The left rail profile data may include a set of data points defining the precise physical characteristics of the left rail as seen from the left sensor’s perspective. In embodiments, the rail profile data (e.g., the right rail profile data and the left rail profile data), in conjunction with the IMU data, forms the basis for generating the TGD, ensuring that the track’s geometry is accurately represented for and at the current interval.

[0117] At block 410, a verification process is performed to ensure that the rail profile data collected for both the right and left rails, as described in blocks 406 and 408, respectively, is sufficient for a comprehensive analysis of the track’s geometry. This verification process may include determining whether each set of rail profile data (e.g., the set of data points for the right rail profile and the set of data points for the left rail profile) includes at least a predetermined threshold number of data points. In embodiments, the threshold number of data points may be configurable and may include any number between 10 and 500 data points, but in any case, the threshold number of data points includes a minimum number of data points required to ensure a detailed and accurate representation of the rail’s profile. This threshold is strategically set to guarantee that the collected data points for a rail is robust enough to facilitate a thorough and reliable analysis of the track’s geometry.

[0118] In response to a determination that the rail profile data for either the right or left rail does not include at least the predetermined threshold number of data points, a corrective action may be taken at block 412. Specifically, the rail profile data for the right and / or left rails may be discarded along with the corresponding IMU data. This step may ensure that the subsequent analysis and calculations are based on complete and reliable data sets, enhancing the accuracy and reliability of the track geometry data. Operations may then return to block402 to receive the next encoder pulse. This next encoder pulse may signify the next intervalfor data capture, prompting the system to repeat the data collection process for the new interval.This iterative process ensures that the system continuously captures and verifies rail profile data at regular intervals as the railroad vehicle traverses the track.

[0119] However, in response to a determination that both sets of rail profile data meet or exceed the threshold number of data points, operations proceed to block 414 for further processing. At block 414, the top of the rail for each of the right and left rails of the track may be identified based on the rail profile data previously obtained. The operations at block 414 may be pivotal as the top of the rail is a reference point for many of the subsequent calculations that contribute to the generation of the TGD. The process of identifying the top of the rail involves analyzing the rail profile data to locate the point that represents the uppermost part of the rail’s profile, which is in direct contact with the train wheels.

[0120] While FIG. 5 provides a detailed algorithm for detecting or identifying the top of a rail from rail profile data, the essence of block 414 is to ensure that the system accurately determines this point for both rails. This accurate identification is used in the calculation of various geometric parameters, such as gauge and crosslevel, which are integral to the assessment of the track's condition. The precise location of the top of the rail is also used in the detection of potential defects and irregularities in the track’s structure. The specific algorithm and methodology used to detect the top of the rail, as detailed in FIG. 5, will be discussed later in the context of that figure.

[0121] At block 416, the gauge and crosslevel data for the TGD may be calculated. The operations at block 416 may involve determining the lateral distance between the rails for the gauge channel and the vertical distance between the tops of the rails for the crosslevel channel. The gauge and crosslevel calculations are performed using the rail profile data. These operations may be executed in accordance with the functionality of a gauge and crosslevelcalculator (e.g., gauge and crosslevel calculator 310 as detailed in FIG. 3). The accurate calculation of gauge and crosslevel is pivotal for assessing the track’s geometry and identifying any potential maintenance or safety concerns.

[0122] At block 418, a prefiltering process may be initiated to enhance the accuracy of the track geometry data by filtering out anomalies that may not be indicative of the track’s structural integrity. The prefiltering operations at block 418 may be performed by a geometry calculations prefilter (e.g., geometry calculations prefilter 312 as detailed in FIG. 3), and may involve applying filtering techniques to the raw rail profile data to remove high-frequency vibrations or movements that may result from terrain undulations or other transient conditions, while preserving low-frequency data that may be indicative of long-term track deformation.

[0123] At block 420, the point data for the TGD’s static or point data channels, such as gauge and crosslevel, may be calculated. The operations at block 420 may be based on the refined rail profile data and may be performed in accordance with the functionality of a geometry point data calculator (e.g., geometry point data calculator 314 as detailed in FIG. 3). The calculated point data is then integrated into the TGD, ensuring that the TGD reflects the true state of the railway track's geometry at each measured interval.

[0124] At block 422, the chordal data for the TGD’s chordal channels, which include alignment, surface, and curvature, may be calculated. The operations at block 422 may be dependent on data captured over multiple predetermined intervals and may be performed in accordance with the functionality of a chordal data calculator (e.g., chordal data calculator 316 as detailed in FIG. 3). The resulting chordal data is then incorporated into the TGD to provide a detailed representation of the track’s geometry over distance.

[0125] At block 424, operations may include an update operation on the TGD file, incorporating the newly generated TGD for the current interval. This operation may leveragefunctionality of a TGD file generator (e.g., TGD file generator 122 as detailed in FIG. 2). The TGD file, at this point, may already contain TGD from previous intervals. The process at this block 424 ensures that the TGD file is updated with the latest TGD, reflecting the track’s geometry data up to the current measured interval. This results in an updated TGD file that now contains a comprehensive dataset of the track’s geometry over the distance traversed by the railway vehicle.

[0126] This comprehensive dataset in the TGD file includes detailed information about the track’s geometry, such as the gauge, crosslevel, alignment, surface, and curvature data. Each of these data points provides valuable insights into the condition of the track, enabling the detection of potential defects and irregularities. The TGD file, therefore, serves as a comprehensive record of the track’s condition, providing a detailed snapshot of the track’s geometry at each measured interval.

[0127] Once the TGD file has been updated with the latest TGD, a determination may be made as to whether the TGD file is ready for transmission to the backend rail profile processing system (e.g., whether the TGD file size has reached a predetermined threshold size and / or whether the railroad vehicle has traveled a predetermined threshold distance). Transmitting the TGD file to the backend rail profile processing system may include sending the TGD file over a network to the backend rail profile processing system, where it will be further analyzed for defect detection. The backend rail profile processing system may use sophisticated machine learning algorithms and models to analyze the TGD and identify potential defects on the track. This analysis can lead to the generation of notifications and alerts, informing railway operators of any potential issues that may require attention.Therefore, the operations illustrated in FIG. 4 not just update the TGD file but also sets thestage for further analysis and defect detection, contributing to the overall goal of maintaining the safety and integrity of the railway track.

[0128] FIG. 5 shows a high-level flow diagram 500 of operation of a system configured for providing functionality for detecting the top and gauge face point of a rail in accordance with embodiments of the present disclosure. In embodiments, the detected top and gauge face point of a rail may represent integral components of the rail profile data used for track geometry analysis in accordance with embodiments of the present disclosure. The operations depicted in the high-level flow diagram 500 outline the systematic steps taken by an on-board rail profile capture system to accurately identify these specific features of the rail’s profile. The operations illustrated in FIG. 5 will be described with further reference to FIGS. 6A-6D. FIGS. 6A-6D show diagram illustrating operations to detect the head and gauge face point of a rail in accordance with embodiments of the present disclosure.

[0129] Operations may begin at block 502, where a graphical representation of the rail profile data and proceeds through a series of checks and calculations to pinpoint the precise location of the rail head and gauge face point. The detailed steps of operations 500 will be further elucidated with reference to FIGS. 6A-6D, which provide visual illustrations of the rail profile and the corresponding detection process.

[0130] At block 502, a graphical representation of the rail profile data associated with a rail is rendered. This graphical representation is a visual depiction of the rail profile data, which includes a set of data points that collectively define the profile or contour of the rail. FIG. 6A illustrates an example of this graphical representation, showcasing the rail profile data 610 as a series of data points that map out the shape and dimensions of the rail’s surface as seen from the sensor’s perspective. This visual representation is a foundational step in theprocess of identifying the precise features of the rail’s profile, such as the rail head and gauge face point.

[0131] At block 504, a determination is made as to whether the railroad vehicle has traveled at least a threshold initial distance since the initiation of the rail profile data capture process. In embodiments, the threshold initial distance is configurable and may include values between 5 feet and 500 feet, and / or other values based on specific operational requirements or preferences. In embodiments, determining whether a threshold initial distance has been traveled may ensure that the on-board rail profile capture system has been given sufficient time to start up and stabilize, which is particularly relevant when the system is first activated or after any interruption in data capture.

[0132] In response to the determination at block 504 that the railroad vehicle has not traveled at least the threshold initial distance, operations may proceed to block 506 where a wide-view of the image rendered at block 502 is utilized. The wide-view image is employed to ensure that the subsequent detection of the rail head (and of the rail top) encompasses all the data points captured in the rail profile data. This wide-view approach is taken to provide a comprehensive perspective of the rail’s profile, allowing for the full contour and shape of the rail to be visible and available for analysis.

[0133] FIG. 6A illustrates an example of such a wide-view image, where the rail profile data 610 is displayed in its full context, without any zoom or focus on a specific area. This wide-view is in contrast with the image illustrated in FIG. 6B, which shows a focused-view image. The focused-view image is zoomed into a particular portion of the rail profile, typically centered around a previously identified feature such as the rail head, to closely examine that specific area for detailed analysis. The wide-view image is particularly useful when the system has not yet established a reference point for the rail head, ensuring that no data points areexcluded from the initial detection process. After utilizing the wide-view image at block 506, the system then advances to block 514 for further processing steps.

[0134] However, if it is determined that the railroad vehicle has traveled at least the threshold initial distance, then it is likely that a previous rail top detection has occurred, as a prior detection process may have been executed. In this case, at block 506, a focused-view of the image rendered at block 502 is used, which is centered on the point where the rail head was previously detected. This focused approach is adopted because the detection of the top of the rail begins with identifying the rail head. However, due to the movement of the vehicle, there is considerable movement within the system, which can result in the rail head’s position shifting relative to the profilometer.

[0135] By using a focused-view image for rail head detection, the system can leverage the previous top of rail determination as a reference point for the center of the current focused image. This strategy allows the system to track the movement of the rail head as it shifts due to the vehicle’s motion, ensuring that the rail head detection remains accurate despite any positional changes.

[0136] As noted above, FIG. 6B provides an example of a focused-view image that is zoomed into a specific portion of the rail profile. This image is centered on the previously detected top of rail point 615, allowing for a detailed examination of the area around the rail head. The use of this focused-view image is instrumental in maintaining the continuity and accuracy of the rail profile detection process as the railroad vehicle continues to traverse the track.

[0137] At block 514, a template matching technique is applied to the image, which may be either a focused-view or wide-view, to detect the likely location of the rail head. This process involves using predefined templates that represent the standard shapes and features ofknown rail heads. These templates are compared against the image to determine if there is a match, which would indicate the presence and location of the rail head within the image.

[0138] Once a potential match is found, a detection box is drawn around the area of the image where the rail head is determined to be located. This detection box, shown as detection box 620 in FIG. 6A, visually delineates the target area for further analysis, specifically focusing on the rail head, which is depicted as rail head 612 in FIG. 6A. The template matching and subsequent drawing of the detection box are integral steps in accurately identifying the rail head, which is a precursor to determining the top of the rail and other relevant geometric features for track analysis.

[0139] At block 516, operations detect the data point in the rail profile data that represents the apex or the uppermost point of the rail profile within the detection box previously established. This specific data point corresponds to the top of the rail, which is a reference point for many of the subsequent calculations that contribute to the generation of the TGD.

[0140] The process of identifying the top of the rail involves analyzing the rail profile data within the confines of the detection box to locate the point that represents the peak of the rail's profile. This is the point that is in direct contact with the train wheels and is therefore a pivotal reference for assessing the condition of the rail. Once the data point that corresponds to the top of the rail is identified, the identified point is set as the top of the rail for further processing. In FIG. 6A, this is illustrated as top of rail point 615. Accurately determining the top of the rail is a foundational step in the rail profile analysis process, as it ensures that the measurements and calculations that follow are based on a precise and consistent reference point.

[0141] At block 518, the gauge face point of the rail is identified. The gauge face point is a specific location on the rail profile that is of particular interest for track geometry analysis.The gauge face point is typically the part of the rail that comes into contact with the wheel flange and is a major factor in the overall health of the track. To locate the gauge face point, operations iterate through the data points in the rail profile data starting from the top of rail point, which define the rail’s profile as captured by the profile capture sensors. These operations search for a data point that matches the predefined criteria for a gauge face point.

[0142] In particular embodiments, the criteria for identifying the gauge face point may include finding a data point that is 5 / 8 of an inch below the top of the rail point on the gauge side of the rail. This specific measurement may be used to ensure that the identified point accurately represents the gauge face location. The iterative operations may continue through the rail profile data until a data point meeting this criterion is found. Once the appropriate data point is identified, it is marked as the gauge face point. This gauge face point is then used in subsequent calculations related to the TGD. An example of a gauge face point is shown as gauge face point 617 in FIG. 6C, which illustrates how the system marks the identified point on the rail profile.

[0143] At block 520, a determination is made as to whether a valid gauge face point has been found based on the criteria established for identifying such a gauge face point. This determination may be made after the system has iterated through the rail profile data and has attempted to locate a data point that matches the predefined criteria for a gauge face point, such as being 5 / 8 of an inch below the top of the rail on the gauge side in some examples. If the system identifies a data point within the rail profile data that meets the criteria and is an actual point in the set of data points defining the rail profile, this point is deemed a valid gauge face point. This means that the data point not only exists within the captured rail profile data but also accurately represents the location on the rail that comes into contact with the wheel flange.

[0144] Upon confirming that a valid gauge face point has been found, the system then sets this data point as the gauge face point for the rail at block 522. This gauge face point becomes a reference for subsequent calculations and analyses related to the TGD. For example, gauge face point 617 is set as a valid gauge face point in FIG. 6C, which is a point within rail profile data 610.

[0145] In the event that the system is unable to locate a data point within the rail profile data that satisfies the established criteria for a gauge face point, the process proceeds to block 524. At block 524, the system adopts an alternative approach to identify the gauge face point by selecting the data point that is closest to the expected location of the gauge face point.

[0146] This scenario may arise if the set of data points defining the rail profile is incomplete or lacks sufficient detail in the area of the gauge face due to obstructions, shadows, or other factors that prevent the capture of a data point meeting the gauge face criteria. For example, if an obstruction or shadow has obscured the gauge portion of the rail during data capture, the resulting rail profile data may not include a data point at the precise location that would typically define the gauge face point. In such cases, the system looks for the data point on the top of the rail head that is closest to the expected gauge face point location. This nearest data point is then used as a substitute for the gauge face point. This approach ensures that the system can continue with the track geometry data calculations using the closest available reference point to the actual gauge face location.

[0147] For example, as illustrated in FIG. 6D, the absence of data points on the gauge side of the rail profile due to the presence of a rail guard 618 may mean that a valid gauge face point may not be identified. In this example, the last available data point on the rail head top in the direction of the gauge face, marked as data point 617, may be designated as the gauge face point. This method allows the system to approximate the gauge face point as accuratelyas possible with the data at hand, thus maintaining the accuracy of the track geometry data analysis.

[0148] The operations illustrated in FIG. 5 conclude at block 526.

[0149] FIG. 7 shows a high-level flow diagram 700 of operation of a system configured for providing functionality for generating TGD based on rail profile data for railroad track analysis in accordance with embodiments of the present disclosure. For example, the functions illustrated in the example blocks shown in FIG. 7 may be performed by system 700 of FIG. 1 according to embodiments herein. In embodiments, the operations of the method 700 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 700.

[0150] At block 702, rail profile data associated with one or more rails of a track is obtained from one or more profile capture sensors mounted on a railroad vehicle at a predetermined interval. In embodiments, the rail profile data includes a set of data points for each of the one or more rails defining a profile of a respective rail. In embodiments, functionality of one or more profile capture sensors (e.g., one or more profile capture sensors 125 as illustrated in FIG. 2) may be used to obtain, from one or more profile capture sensors mounted on a railroad vehicle, rail profile data associated with one or more rails of a track at a predetermined interval. In embodiments, the one or more profile capture sensors may perform operations to obtain, from one or more profile capture sensors mounted on a railroad vehicle, rail profile data associated with one or more rails of a track at a predetermined interval according to operations and functionality as described above with reference to one or more profile capture sensors 125 and as illustrated in FIGS. 1-6D.

[0151] At block 704, IMU data including rates and angles of an orientation of the railroad vehicle is obtained. In embodiments, functionality of an IMU (e.g., IMU 126 asillustrated in FIG. 2) may be used to obtain IMU data including rates and angles of an orientation of the railroad vehicle. In embodiments, the IMU may perform operations to obtainIMU data including rates and angles of an orientation of the railroad vehicle according to operations and functionality as described above with reference to IMU 126 and as illustrated in FIGS. 1-6D.

[0152] At block 706, one or more reference points on the profiles of each of the rails corresponding to specific geometric features of the rails are identified based on the rail profile data. In embodiments, functionality of a TGD calculations manager (e.g., TGD calculations manager 121 as illustrated in FIG. 2) may be used to identify, based on the rail profile data, one or more reference points on the profiles of each of the rails corresponding to specific geometric features of the rails. In embodiments, the TGD calculations manager may perform operations to identify, based on the rail profile data, one or more reference points on the profiles of each of the rails corresponding to specific geometric features of the rails according to operations and functionality as described above with reference to TGD calculations manager 121 and as illustrated in FIGS. 1-6D.

[0153] At block 708, a plurality of data channels related to the geometry of the railroad track is calculated based on the rail profile data and the IMU data. In embodiments, functionality of a gauge and crosslevel calculator and a geometry chordal data calculator (e.g., gauge and crosslevel calculator 310 and geometry chordal data calculator 316 as illustrated in FIG. 3) may be used to calculate, based on the rail profile data and the IMU data, a plurality of data channels related to the geometry of the railroad track. In embodiments, the gauge and crosslevel calculator and the geometry chordal data calculator may perform operations to calculate, based on the rail profile data and the IMU data, a plurality of data channels related to the geometry of the railroad track according to operations and functionality as describedabove with reference to gauge and crosslevel calculator 310 and geometry chordal data calculator 316 and as illustrated in FIGS. 1-6D.

[0154] At block 710, TGD is generated for the predetermined interval based on the data calculated for the plurality of data channels. In embodiments, functionality of a geometry point data calculator and a geometry chordal data calculator (e.g., geometry point data calculator 314 and geometry chordal data calculator 316 as illustrated in FIG. 3) may be used to generate TGD for the predetermined interval based on the data calculated for the plurality of data channels. In embodiments, the geometry point data calculator and the geometry chordal data calculator may perform operations to generate TGD for the predetermined interval based on the data calculated for the plurality of data channels according to operations and functionality as described above with reference to geometry point data calculator 314 and geometry chordal data calculator 316 and as illustrated in FIGS. 1-6D.

[0155] At block 712, the TGD for the predetermined interval is integrated into a TGD file to be transmitted to a backend rail profile processing system via a network. In embodiments, the TGD file is processed at the backend rail profile processing system to determine defects on the railroad track and to generate track defect reports and notifications based on the determined defects. In embodiments, functionality of a TGD data generator (e.g., TGD data generator 318 as illustrated in FIG. 3) may be used to integrate the TGD for the predetermined interval into a TGD file to be transmitted to a backend rail profile processing system via a network. In embodiments, the TGD data generator may perform operations to integrate the TGD for the predetermined interval into a TGD file to be transmitted to a backend rail profile processing system via a network according to operations and functionality as described above with reference to TGD data generator 318 and as illustrated in FIGS. 1-6D.

[0156] 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.

[0157] 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.

[0158] 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.

[0159] 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.

[0160] Functional blocks and modules in FIGS. 1-7 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.

[0161] 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.

[0162] 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.

[0163] 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

CLAIMSWhat is claimed is:

1. A method of generating track geometry data (TGD) for railroad track analysis, comprising: obtaining, from one or more profde capture sensors mounted on a railroad vehicle, rail profde data associated with one or more rails of a track at a predetermined interval, wherein the rail profde data includes a set of data points for each of the one or more rails defining a profde of a respective rail; obtaining inertial measurement unit (IMU) data including rates and angles of an orientation of the railroad vehicle; identifying, based on the rail profde data, one or more reference points on the profiles of each of the rails corresponding to specific geometric features of the rails; calculating, based on the rail profde data and the IMU data, a plurality of data channels related to the geometry of the railroad track; generating track geometry data (TGD) for the predetermined interval based on the data calculated for the plurality of data channels; and integrating the TGD for the predetermined interval into a TGD file to be transmitted to a backend rail profde processing system via a network, wherein the TGD file is processed at the backend rail profde processing system to determine defects on the railroad track and to generate track defect reports and notifications based on the determined defects.

2. The method of claim 1, wherein the predetermined interval is determined based on an encoder pulse received from one or more wheel encoders mounted on therailroad vehicle, each encoder pulse corresponding to a specific increment of distance traveled by the railroad vehicle to facilitate synchronization of rail profile data capture with a physical location of the railroad vehicle along the track.

3. The method of claim 1, wherein the TGD file includes TGD aggregated from multiple previous predetermined intervals, facilitating analysis of track geometry over extended distances and identification of long-term geometric trends and patterns on the railroad track.

4. The method of claim 1, wherein the rail profile data associated with the one or more rails of the track is validated by determining whether the rail profile data associated with the one or more rails includes at least a predetermined threshold number of data points for each of the one or more rails.

5. The method of claim 4, wherein the rail profile data is discarded in response to a determination that the rail profile data associated with the one or more rails does not include at least the predetermined threshold number of data points for each of the one or more rails.

6. The method of claim 1, wherein identifying the one or more reference points on the profiles of each of the rails includes identifying the top of the rail for each of the rails based on the rail profile data, the top of the rail being a reference point for calculating the plurality of data channels related to the geometry of the railroad track.

7. The method of claim, 6, further comprising: iterating through the set of data points in the rail profile data, starting from the identified top of the rail point of a respective rail, to locate a data point that matches predefined criteria for a gauge face point; and marking the data point that matches the predefined criteria for a gauge face point as the gauge face point of the respective rail.

8. The method of claim 7, wherein, in response to a failure to identify a valid gauge face point for the respective rail based on the predefined criteria, a data point in the set of data points that is nearest to the expected location of the gauge face point is selected as the gauge face point for the respective rail.

9. The method of claim 1, wherein identifying the one or more reference points on the profiles of each of the rails includes utilizing a template matching technique to detect the likely location of specific geometric features on the rail profiles, wherein the specific geometric features include at least the top of the rail and the gauge face point of the rail.

10. The method of claim 1, 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; and a curvature channel representing a degree of curvature of the railroad track over the traveled distance.

11. 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: obtaining, from one or more profile capture sensors mounted on a railroad vehicle, rail profile data associated with one or more rails of a track at a predetermined interval, wherein the rail profile data includes a set of data points for each of the one or more rails defining a profile of a respective rail; obtaining inertial measurement unit (IMU) data including rates and angles of an orientation of the railroad vehicle; identifying, based on the rail profile data, one or more reference points on the profiles of each of the rails corresponding to specific geometric features of the rails; calculating, based on the rail profile data and the IMU data, a plurality of data channels related to the geometry of the railroad track;generating track geometry data (TGD) for the predetermined interval based on the data calculated for the plurality of data channels; and integrating the TGD for the predetermined interval into a TGD fde to be transmitted to a backend rail profde processing system via a network, wherein the TGD fde is processed at the backend rail profde processing system to determine defects on the railroad track and to generate track defect reports and notifications based on the determined defects.

12. The system of claim 11, wherein the predetermined interval is determined based on an encoder pulse received from one or more wheel encoders mounted on the railroad vehicle, each encoder pulse corresponding to a specific increment of distance traveled by the railroad vehicle to facilitate synchronization of rail profde data capture with a physical location of the railroad vehicle along the track.

13. The system of claim 1, wherein the TGD fde includes TGD aggregated from multiple previous predetermined intervals, facilitating analysis of track geometry over extended distances and identification of long-term geometric trends and patterns on the railroad track.

14. The system of claim 11, wherein the rail profde data associated with the one or more rails of the track is validated by determining whether the rail profde data associated with the one or more rails includes at least a predetermined threshold number of data points for each of the one or more rails.

15. The system of claim 14, wherein the rail profile data is discarded in response to a determination that the rail profile data associated with the one or more rails does not include at least the predetermined threshold number of data points for each of the one or more rails.

16. The system of claim 11, wherein identifying the one or more reference points on the profiles of each of the rails includes identifying the top of the rail for each of the rails based on the rail profile data, the top of the rail being a reference point for calculating the plurality of data channels related to the geometry of the railroad track.

17. The system of claim, 16, wherein the operations further comprise: iterating through the set of data points in the rail profile data, starting from the identified top of the rail point of a respective rail, to locate a data point that matches predefined criteria for a gauge face point; and marking the data point that matches the predefined criteria for a gauge face point as the gauge face point of the respective rail.

18. The system of claim 17, wherein, in response to a failure to identify a valid gauge face point for the respective rail based on the predefined criteria, a data point in the set of data points that is nearest to the expected location of the gauge face point is selected as the gauge face point for the respective rail.

19. The system of claim 11, wherein identifying the one or more reference points on the profiles of each of the rails includes utilizing a template matching technique to detectthe likely location of specific geometric features on the rail profiles, wherein the specific geometric features include at least the top of the rail and the gauge face point of the rail.

20. 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: obtaining, from one or more profile capture sensors mounted on a railroad vehicle, rail profile data associated with one or more rails of a track at a predetermined interval, wherein the rail profile data includes a set of data points for each of the one or more rails defining a profile of a respective rail; obtaining inertial measurement unit (IMU) data including rates and angles of an orientation of the railroad vehicle; identifying, based on the rail profile data, one or more reference points on the profiles of each of the rails corresponding to specific geometric features of the rails; calculating, based on the rail profile data and the IMU data, a plurality of data channels related to the geometry of the railroad track; generating track geometry data (TGD) for the predetermined interval based on the data calculated for the plurality of data channels; and integrating the TGD for the predetermined interval into a TGD file to be transmitted to a backend rail profile processing system via a network, wherein the TGD file is processed at the backend rail profile processing system to determine defects on the railroad track and to generate track defect reports and notifications based on the determined defects.

Images