Systems and methods for monitoring and validating status of hardware devices in a classification yard

Abstract

Methods and systems for determining a status of hardware devices in a classification yard. In particular embodiments, a set of device event data associated with a hardware device may be analyzed to determine the performance of the hardware device during operations of each device event. A status of the hardware device may be determined from the analysis of the performance of the hardware device during operations of each device event. In embodiments, the analysis may include thresholding analysis that may be configured to determine a relationship between real-world measurements and expected (e.g., predicted or desired) results for each device event associated with the hardware device. In embodiments, the status of the hardware device may be used to ensure corrective actions on the hardware device (e.g., deploy maintenance personnel, report the status of the hardware device, send a control signal to the hardware device to deactivate, etc.).

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] The present application is a Continuation-in-Part of U.S. patent application Ser. No. 18 / 658,386, filed on May 8, 2024, the entirety of which is herein incorporated by reference for all purposes.TECHNICAL FIELD

[0002] The present invention relates generally to maintenance monitoring systems, and more particularly to tools for monitoring and validating the status of hardware devices in railroad operations.BACKGROUND

[0003] Innovation in the railroad industry has allowed for widespread and efficient transportation of freight and passengers across distances using trains. A typical train may include one or more locomotive engines that may be configured to pull and / or push one or more train cars. The trains may be put together or assembled in a classification yard, which may include a hump yard. A hump yard may refer to an area configured to route the train cars along a network of marshalling tracks using gravity to respectively-assigned trains. In this manner, the hump yard may enable operators to assemble trains by routing the train cars to their assigned train. Typically, hump yards consist of an elevated area (e.g., a hump, which may be artificial or natural, such as a hill, mound, etc.) along which a track section is run. The track section may include an approach section, a top of the hump or crest, and a release area, which typically branches out into multiple marshalling tracks. Each of the marshalling tracks may eventually lead to a destination train to which the various train cars may be routed using the marshalling tracks.

[0004] In typical operations of a hump yard, a rolling stock train including the train cars to be marshalled to their assigned train may be pushed by a hump push engine at a set speed along the approach section to the crest of the hump. As the train cars roll past the apex (e.g., the crest) of the hump, gravity may begin pulling the railroad cars towards the bottom of the hump causing individual railroad cars, or groups of railroad cars, also referred to as a cut, to separate from the stock train and to coast to the release area at a release speed. The separated railroad cars, or cut, may coast (and may decelerate or accelerate depending on the layout of the marshalling tracks) through the marshalling tracks to reach the coupling point at their respectively assigned train. The operations continue with additional cuts being routed through the hump yard marshalling tracks as appropriate or necessary. Once the train is fully assembled, the train is pulled out of the marshalling tracks and eventually travels to its destination.

[0005] In a hump yard, controlling the movement of a cut as it travels through the marshalling tracks is exceedingly important. For example, controlling the route of each cut is important to ensure that each cut is routed to the respectively assigned destination train, to avoid potential collisions between the various cuts, and / or to load-balance the use of the marshalling tracks as the cuts are released onto the marshalling tracks.

[0006] Additionally, controlling the speed of each cut as it travels through the marshalling tracks is important in order to avoid accidental damage to equipment, train cars, and / or the freight itself. For example, an overly high coupling speed may cause the cut to couple with the destination train at a high speed and may cause damage to the existing train cars (e.g., the train cars already coupled to the destination train), to itself, or to the freight (e.g., the freight being carried by one or more of the train cars in the cut or the freight in the existing train cars of the destination train), whereas an overly low release speed may not be sufficient to ensure that the cut reaches the coupling point, as the only source of power to the cut during the marshalling process is gravity and as such, the cut is not able to accelerate beyond what gravity provides. In addition, controlling the speed of each cut as it travels through the marshalling tracks is important to ensure that the separation between the various cuts is sufficient to avoid collisions between cuts. Ensuring an appropriate separation between cuts may also ensure that any switches in the route of the cuts may be reset in time to marshal the next cut to the appropriate train. For example, if two consecutive cuts assigned to different marshalling tracks are released from the top of the hump too close together, there may not be sufficient time to reset the switch after the first cut is diverted to its respective marshalling track to ensure that the second cut is diverted to the appropriate marshalling track.

[0007] In typical implementations of a classification yard, various mechanisms and hardware devices are implemented to control the route and / or speed of the various cuts as these various cuts travel through the marshalling tracks of the classification yard. For example, current hump yard systems may include mechanisms to regulate the speed of the hump push engine as it pushes train cars up the hump. In this manner, the speed of the hump push engine may be controlled to control the release speed of a cut. For example, a fast-moving hump push engine may cause the cuts to be released with a high release speed, and a low-moving hump push engine may cause the cuts to be released with a low release speed. Moreover, a fast-moving hump push engine may cause the cuts to release close to each other, while a slower moving hump push engine may cause the cuts to release with more distance between each other.

[0008] Typical hardware devices used in a classification yard may include switches that may be configured to route a cut from a source track to a target track, detectors that may be configured to detect the speed and / or arrival time of a cut, retarders that may be configured to remove energy from a cut as passes through the retarders, radar devices that may be configured to detect the presence and / or speed of a cut, distance units that may be configured to detect how far a cut may be from other cuts and / or from other devices and / or points along the route from a current position), etc. A typical switch operates by routing a cut from a source track into one of a plurality of destination tracks. For example, a switch may be connected to a single source track and a plurality of destination tracks. A signal may be configured the throw the switch to a selected track of the plurality of destination tracks, in which case a cut traveling over the source track may be automatically routed to the selected destination track.

[0009] A typical detector may be configured to detect a speed and / or arrival time of a cut at the detector. For example, a detector may be configured to detect the presence of a wheel (e.g., a wheel of a cut) at the detector. The detector may generate a wheel detection with a time associated with the detection. In implementations, a detector may detect the speed of a cut by detecting the presence of a first wheel of the cut at a first time, detecting the presence of a second wheel of the cut at a second time, and determining a speed from the difference between the first and second times over the distance between the first wheel and the second wheel. In this manner, a detector may be used to measure the speed of a cut at the detector.

[0010] A typical retarder may be configured to remove energy from a cut traveling through the retarder. Removing energy from a cut may have the effect of slowing down the cut, which is why a retarder may be thought of as removing speed from a cut. A retarder may remove energy from a cut by applying a pressure against one or more wheels of the cut (e.g., using a braking element, such as a brake pad, etc.), which may cause the cut to slow down. Put another way, the retarder may remove energy (e.g., kinetic energy) of the train car as it moves through a marshalling track, which may cause the train car to slow down. The amount of energy, or speed, removed from a cut by a retarder may depend on the amount of pressure applied by the retarder. For example, a higher pressure may cause more energy, or speed, to be removed from a cut than a lower pressure. In this manner, retarders may be used to further control the speed of a cut as it travels through the marshalling tracks.

[0011] In typical retarder operations, an exit speed is requested of the retarder for a cut. In this manner, the retarder may operate to remove energy, as necessary, to ensure that the cut exits the retarder (e.g., at the exit point of the retarder) at the requested exit speed. The amount of energy to be removed by the retarder from the cut to meet the requested exit speed may depend on the speed of the cut at the entry point of the retarder.

[0012] However, hardware devices are subject to wear down and degradation over time and usage, in addition to exposure to environmental factors. As time passes by, the performance of the various hardware devices may deteriorate and the efficiency or effectiveness of the various devices may degrade. In addition, hardware devices may be subject to failures, such as due to mechanical, electrical, software failures, etc. As many of these hardware devices include mechanical operations, the hardware devices may bind, break, bend, or otherwise may experience failure events. This may cause operations of the classification yard that rely on the operations of the hardware devices to also fail, or to suffer degradation. For example, operations to control the speed or route of a cut may degrade, which may cause bottlenecks, slowdowns, and even collisions between the cuts. In some cases, predictions that rely upon hardware devices may become inaccurate, which may affect classification operations. In some cases, hardware devices may operate slower than expected, which may cause problems in the operations of the classification yard.

[0013] For example, retarders may wear down over time and as a result, may not be able to remove energy as efficiently as before. For example, as a retarder wears down, the same amount of pressure applied to a cut may not be able to remove the same amount of energy over time. In this case, even with the same pressure applied to a cut, the cut may not slow down as much as before. As a result, classification yard operations may not be as efficient because a retarder may not be able to remove an amount of energy requested.

[0014] In another example, switches may degrade or fail. For example, a switch operates by being “thrown” from one position to another position (e.g., from a first position to a second position). In this manner, a cut's route may be controlled by a switch by throwing the switch to the appropriate position, which may be connected to the target track. However, the switch throw may not be as fast as expected, in which case the cut may arrive at the switch before the switch has been repositioned to the target position, causing a misrouting of the cut, which may cause problems if the misroute is into an occupied track (e.g., may cause an undesired collision). A switch may also fail due to a kickback event (e.g., the switch is thrown from a first position (e.g., left or right) to a second position but is thrown back to the first position), a no movement event (e.g., the switch is signaled to throw from a first position to a second position but fails to move), a lost position event (e.g., the switch's current position is unknown). In some cases, the switch may have a shelf life of a certain number of throws.

[0015] In another example, detectors may also fail. For example, wheel detectors may fail due to degradation and may fail to detect an accurate speed of a cut. For example, the calculation of a speed of a cut based on the difference between a first detection time and a second detection time over the distance between the first wheel and the second wheel may not reflect the actual speed of the cut. In this case, the poor operations of a defective detector may cause problems with operations that rely on accurate speed measurements (e.g., speed and / or arrival time predictions).

[0016] Currently, determining a status of hardware devices may include manual inspections. However, this presents a great burden on operators, and may become very expensive due to the number of hardware devices used in classification yards. In some cases, software tools may be used to determine the status of hardware devices. However, current tools may not be able to effectively determine the status of hardware devices due to the complexity of the hardware devices operations. In particular, current tools may not be able to identify the degradation of a hardware device even when the hardware device may provide results within expected values, but may not be operating as efficiently or effectively as before. In this case, the degradation of the hardware device may indicate that the hardware device is close to failing, and currently, systems lack functionality to determine these situations.SUMMARY

[0017] The present disclosure achieves technical advantages as systems, methods, and computer-readable storage media that provide functionality for determining a status of hardware devices in railroad operations (e.g., in a classification yard). In particular embodiments, a set of event data associated with a hardware device may be analyzed to determine the performance of the hardware device during operations of the classification yard. A status of the hardware device may be determined from analysis of the performance of the hardware device during operations of the classification yard. In embodiments, the status of the hardware device may be used to ensure corrective actions on the hardware (e.g., deploy maintenance personnel, report the status of the retarder, send a control signal to the retarder to deactivate, etc.).

[0018] The present disclosure provides for a system integrated into a practical application with meaningful limitations as a system with functionality for determining a status of hardware devices that are used for controlling operations of a classification yard. In embodiments, determining the status of hardware devices may be critical to operations in a classification yard, as hardware devices wear down and degrade over time. As hardware devices degrade, the performance of the hardware devices may not be the same. In some cases, predictions, control signals, activation signals, tracking signals, etc., associated with planning, controlling, tracking, reporting operations of a classification yard may not be based on accurate information or may not be executed correctly, which may cause operational problems. In addition, in some cases, the degradation of a hardware device may be masked by control software, which may control the hardware device to compensate when the control software detects that the desired results of the hardware device may not be obtained. In these cases, it may appear that the hardware device may be operating properly, since the desired results was obtained, but in reality, there may be issues with the hardware device that were compensated for by the control software. The present disclosure provides features that may be used by a system to monitor, track, and / or control the performance of a hardware device. In embodiments, features described herein may allow a system to generate alert and / or control signals that may be used by field personnel to perform corrective actions on the hardware device or may be used by the system to send automatic control signals to deactivate or adjust a defective or degraded hardware device.

[0019] The present disclosure solves the technological problem of a lack of functionality in current systems to dynamically monitor, track, and / or control the ability of a hardware device to operate efficiently and effectively to perform operations in a classification yard. For example, in current systems, a bad or degraded hardware device may not be identified until it is too late (e.g., after the hardware device has failed), which may result in catastrophic (e.g., may cause injury to persons, damage to equipment, and / or impact to services) and / or expensive consequences. In a particular case, as mentioned above, control software may compensate for a degraded hardware device, which may mask a hardware device that may be going bad. A system implemented in accordance with the present disclosure may be flexible and responsive to these situations may identify these bad / defective hardware devices, even when the problem may be masked by control software compensating. 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 determining the status of hardware devices. In doing so, the present disclosure goes well beyond a mere application of the manual process to a computer. Accordingly, the claims herein necessarily provide a technological solution that overcomes a technological problem.

[0020] It is further noted that the embodiments described herein focus and / or are described in the context of operations of a classification yard. However, this is not intended to be limiting, as the techniques disclosed herein are also applicable in other railroad operations that may not involve a classification yard. For example, the techniques disclosed herein may be used to determine a status of hardware devices that are used for controlling railroad operations that may not be part of a classification yard. In this case, the embodiments herein should be construed as exemplary, and not limiting in any way. Moreover, although specific and particular hardware devices may be described herein, this is also not intended to be limiting, and it should be understood that the techniques disclosed herein to determine a status of hardware devices may be used to determine that status of any hardware device that may be used in any operation related to hardware (and not limited to classification yard operations of specific devices mentioned herein).

[0021] In various embodiments, the system comprises one or more processors interconnected with a memory module, capable of executing machine-readable instructions. These instructions include, but are not limited to, the steps outlined in any flow diagram, system diagram, block diagram, and / or process diagram disclosed herein, as well as steps corresponding to any functionality detailed herein. In embodiments, the execution of these machine-readable instructions may involve initiating multiple concurrent computer processes. Each process of the concurrent computer process may be configured to handle or process a designated subset or portion of the of the machine-readable instructions. This division of tasks enables parallel processing, multi-processing, and / or multi-threading, enabling multiple operations to be conducted or executed concurrently rather than sequentially. This functionality for spawning a plurality of concurrent processes to manage separate portions of the machine-readable instructions markedly increases the overall speed of execution of the machine-readable instructions. By leveraging parallel or concurrent processing, the time required to complete a set or subset of program steps is substantially reduced (e.g., when compared to execution without concurrent or parallel processing). This efficiency gain not only accelerates the processing speed but also optimizes the use of processor resources, leading to an improved performance of the computing system. This enhancement in computational efficiency constitutes a significant technological improvement, as it enhances the functional capabilities of the processors and the system as a whole, representing a practical and tangible technological advancement. The result of this concurrent processing functionality results in an improvement in the functioning of the one or more processor and / or the computing system, and thus, represents a practical application.

[0022] In embodiments, the present disclosure includes techniques for training models (e.g., machine-learning models, artificial intelligence models, algorithmic constructs, etc.) for performing or executing a designated task or a series of tasks (e.g., one or more features of steps or tasks of processes, systems, and / or methods disclosed in 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 application that significantly enhance the functionality, reliability, and efficiency of the models developed through these processes.

[0023] In embodiments, the present disclosure includes techniques for generating a notification of an event that includes generating an alert that includes information specifying the location of a source of data associated with the event, formatting the alert into data structured according to an information format, and / or 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.

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

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

[0026] It is an object of the disclosure to provide a system for determining a status of hardware devices in a classification yard. It is a further object of the disclosure to provide a method of determining a status of hardware devices in a classification yard, and a computer-based tool for determining a status of hardware devices in a classification yard. These and other objects are provided by the present disclosure, including at least the following embodiments.

[0027] In one particular embodiment, a method of determining a status of hardware devices in a classification yard is provided. The method includes compiling a plurality of device events associated with a hardware device in a classification yard. In embodiments, each device event of the plurality of device events may be associated with an expected measurement and may include real-world measurements of an actual measurement at the hardware device during each device event of the plurality of device events and / or an indication of a utilization of the hardware device during each device event of the plurality of device events to obtain the expected measurement for each device event. The method also includes generating a set of deviation metrics associated with the hardware device based on the plurality of device events associated with the hardware device, applying thresholding analysis to the set of deviation metrics associated with the hardware device to determine a status of the hardware device, and generating a corrective action signal including an indication of the status of the hardware device and / or a corrective action to be taken on the hardware device.

[0028] In another embodiment, a system for determining a status of hardware devices in a classification yard is provided. The system comprises at least one processor and a memory operably coupled to the at least one processor and storing processor-readable code that, when executed by the at least one processor, is configured to perform operations. The operations include compiling a plurality of device events associated with a hardware device in a classification yard. In embodiments, each device event of the plurality of device events may be associated with an expected measurement and may include real-world measurements of an actual measurement at the hardware device during each device event of the plurality of device events and / or an indication of a utilization of the hardware device during each device event of the plurality of device events to obtain the expected measurement for each device event. The operations also include generating a set of deviation metrics associated with the hardware device based on the plurality of device events associated with the hardware device, applying thresholding analysis to the set of deviation metrics associated with the hardware device to determine a status of the hardware device, and generating a corrective action signal including an indication of the status of the hardware device and / or a corrective action to be taken on the hardware device.

[0029] In yet another embodiment, a computer-based tool for determining a status of hardware devices in a classification yard 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 compiling a plurality of device events associated with a hardware device in a classification yard. In embodiments, each device event of the plurality of device events may be associated with an expected measurement and may include real-world measurements of an actual measurement at the hardware device during each device event of the plurality of device events and / or an indication of a utilization of the hardware device during each device event of the plurality of device events to obtain the expected measurement for each device event. The operations also include generating a set of deviation metrics associated with the hardware device based on the plurality of device events associated with the hardware device, applying thresholding analysis to the set of deviation metrics associated with the hardware device to determine a status of the hardware device, and generating a corrective action signal including an indication of the status of the hardware device and / or a corrective action to be taken on the hardware device.

[0030] The foregoing has outlined rather broadly the features and technical advantages of the present invention in order that the detailed description of the invention that follows may be better understood. Additional features and advantages of the invention will be described hereinafter which form the subject of the claims of the invention. 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 invention. 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 invention as set forth in the appended claims. The novel features which are believed to be characteristic of the invention, 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 invention.BRIEF DESCRIPTION OF THE DRAWINGS

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

[0032] FIG. 1 is a block diagram of an exemplary system configured with capabilities and functionality for determining a status of hardware devices in a classification yard in accordance with embodiments of the present disclosure.

[0033] FIG. 2 shows a high-level flow diagram of operation of a system for determining a status of hardware devices in a classification yard in accordance with embodiments of the present disclosure.

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

[0035] The disclosure presented in the following written description and the various features and advantageous details thereof, are explained more fully with reference to the non-limiting 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.

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

[0037] Various embodiments of the present disclosure are directed to systems and techniques that provide functionality for determining a status of hardware devices in a classification yard. In particular embodiments, a set of event data associated with a hardware device may be analyzed to determine the performance of the hardware device during operations of the classification yard. A status of the hardware device may be determined from analysis of the performance of the hardware device during operations of the classification yard. In embodiments, the status of the hardware device may be used to ensure corrective actions on the hardware device (e.g., deploy maintenance personnel, report the status of the hardware device, send a control signal to the hardware device to deactivate, etc.).

[0038] FIG. 1 is a block diagram of an exemplary system 100 configured with capabilities and functionality for determining a status of hardware devices in a classification yard in accordance with embodiments of the present disclosure. As shown in FIG. 1, system 100 may include server 110, classification yard 140, data collector 150, user terminal 130, and network 145. These components, and their individual components, may cooperatively operate to provide functionality in accordance with the discussion herein. For example, in operation according to embodiments, hardware devices of classification yard 40 may perform operations associated with the operations of classification yard 140 (e.g., switching operations, speed detection operations, energy removal operations). Each hardware device operation may generate a device event. For example, an event may include a detector detecting the speed and / or arrival time of a cut passing through the detector, and this may generate a device event (e.g., a detector event). In another example, an event may include a cut passing through a retarder and the retarder operating to reduce the speed of the cut as the cut passes through the retarder, and this may generate a device event (e.g., a retarder event). In still another example, an event may include a switch being thrown from a first position (e.g., left or right) to a second position (e.g., left or right), and this may generate a device event (e.g., a switch event). In embodiments, data collector 150 may operate to collect real-world device event data associated with the hardware devices. In this manner, a device event may represent an operational event of a hardware device. In embodiments, a device event may include real-world measurements associated with the device event and may include a measured speed (e.g., the actual speed of a cut at the hardware device), a predicted speed (e.g., the predicted or expected speed of the cut at the hardware device), an exit speed (e.g., the actual exit speed of the cut at the exit point of the hardware device), an entry speed (e.g., the actual speed of the cut at the entry point of the hardware device), a requested exit speed (e.g., the exit speed requested for the cut associated with the device event), an amount of pressure applied by a retarder device against the wheels of the cut to remove an amount of energy necessary to reach the requested exit speed, a distribution of the amount of pressure applied by the retarder device at each section of the retarder, a speed of the cut at each of the sections of the retarder device, an actual switch throw time (e.g., the actual throw time of a switch event), an expected switch throw time (e.g., the expected throw time of a switch event), a throw count for a switch device (e.g., the total number of times the switch device has been thrown), a failure count for a switch device (e.g., the total number of failures of the switch device, such as kickbacks, no movements, lost position, etc.), an identification of the cut associated with the device event, an identification of the hardware device for which the device event was generated, and / or other conditions associated with the device event (e.g., weather, type of train cars in the cut, type of bearings of the cut, identification of the cut, etc.).

[0039] In embodiments, functionality of server 110 may provide for determining, based on device events associated with a hardware device, a status of the hardware device. In embodiments, server 110 may include functionality for determining, based on device events associated with a hardware device, a status of the hardware device by compiling data related to device events associated with the hardware device, applying threshold analysis to the compiled data to determine a relationship between real-world measurements and expected (e.g., predicted or desired) results with respect to operation of the hardware device, to determine a status of the hardware device based on the thresholding analysis, and to generate a corrective action signal in response to the determination of the status of the hardware device. In embodiments, the thresholding analysis may include analysis that focuses on the relationship between real-world measurements and expected (e.g., predicted or desired) results for each device event associated with a hardware device. In some embodiments, the thresholding analysis may include applying one or more rules that may determine the amount and / or spread of deviations between the real-world measurements for determining the status of a hardware device. In some embodiments, the thresholding analysis may include determining, for each device event associated with a hardware device, a measurement difference between an expected measurement and the actual measurement (e.g., actual measurement−expected measurement), and analyzing the relationship of the measurement differences against thresholds to determine the status of the hardware device. In some embodiments, the thresholding analysis may include determining, for each device event associated with a hardware device, a utilization per energy change metric, and analyzing the relationship of the utilization per energy change (e.g., based on the utilization per energy change metric) against thresholds to determine the status of the hardware device.

[0040] It is noted that the functional blocks, and components thereof, of system 100 of embodiments of the present invention 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.

[0041] It is also noted that various components of system 100 are illustrated as single and separate components. However, it will be appreciated that each of the various illustrated components may be implemented as a single component (e.g., a single application, server module, etc.), may be functional components of a single component, or the functionality of these various components may be distributed over multiple devices / components. In such embodiments, the functionality of each respective component may be aggregated from the functionality of multiple modules residing in a single, or in multiple devices.

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

[0043] Classification yard 140 may represent a train yard, such as a hump yard, in which train cars are routed or marshalled to a destination track to be coupled to a destination train. In embodiments, classification yard 140 may include functionality to plan, track, control, and report the movement of the train cars through the marshalling tracks, including the hump approach section, the hump crest, the hump release area, and multiple marshalling tracks.

[0044] In a typical operation of classification yard 140, such as a hump yard, a stock train that includes train cars to be marshalled to their assigned train may be pushed by a hump push engine at a set speed along the approach section of the hump to the crest of the hump. As the train cars roll past the hump crest, gravity may begin pulling the train cars towards the bottom of the hump. In embodiments, the train cars are “cut” from the stock train and the cut is allowed to roll down the hump and is marshalled to the destination train.

[0045] As noted above, ensuring that the cut reaches the assigned destination train at the appropriate coupling speed is very important. As such, in embodiments, a cut may be tracked and controlled as the cut moves along the marshalling tracks in classification yard 140. In particular, the route and the speed of the cut from the hump to its destination track or train may be controlled using various components of classification yard 140. For example, classification yard 140 may include various components enabling classification yard 140 to track and / or control the movement of a cut through the marshalling tracks. In embodiments, the various components enabling classification yard 140 to track and / or control the movement and / or speed of a cut through the marshalling tracks may include switches 142, detectors 144, and retarders 146, among other components. In embodiments, the cooperative operation of the various components of classification yard 140 may enable classification yard 140 to ensure that various cuts traverse the marshalling tracks and arrive at the destination coupling point at the appropriate coupling speed

[0046] In embodiments, switches 142 may include one or more switches configured to route a cut to a designated track section. For example, a cut may be traveling along a first track and may come upon a switch. The switch may be configured to route the cut from the first track to a target track according to the route of the cut. In some cases, the target track may be one of a plurality of selectable tracks. For example, one side of the switch may be coupled on one side to the first track, and on the second side to the second and a third track. In this example, the switch may be configured to selectively route the train car from the first track to either the second or the third track. Whether the switch routes the train car from the first track to the second or the third track may depend on the throw position of the switch. For example, the throw position of the switch may currently be the left position, which may route to the second track. In this example, the right throw position of the switch may route to the third track. In this case, when a cut is destined to a destination track via a route that may travel through the third track, classification yard 140 may control the route of the cut by throwing the switch to change the switch's position from the left to the right, to route the cut to the third track. In this manner, classification yard 140 may control the route of the cut using switches 142 to ensure the cut moves through the appropriate route.

[0047] In embodiments, switches 142 may be laid out at different points along the tracks of classification yard 140. In particular, each of switches 142 may be laid out at points at which a single track may branch out into multiple tracks.

[0048] In embodiments, retarders 146 may include one or more retarders configured with functionality to remove energy from a cut traveling through retarders 146. For example, each of retarders 146 may be laid out at different points along the tracks of classification yard 140. In some embodiments, each of the marshalling tracks of classification yard 140 may include one or more retarders of retarders 146. In some embodiments, a main master retarder may be positioned along the main marshalling track (e.g., along the release section) of the hump track. In some embodiments, each segment of a route along the marshalling tracks of classification yard 140 may be configured with at least one retarder. In some embodiments, each segment of a route along the marshalling tracks of classification yard 140 may be configured with a master retarder and one or more slave retarders. In these embodiments, the retarders along a segment of a route may cooperatively operate to remove energy from a cut traveling through the segment.

[0049] In embodiments, retarders 146 may be configured to remove energy from a cut traveling through retarders 146 by causing the cut to slow down as it travels through or over retarders 146. In some embodiments, retarders 146 may cause a cut to slow down by applying a pressure against one or more wheels of one or more train cars included in the cut, which may cause the cut to slow down. For example, retarders 146 may press a braking element (e.g., a brake pad, etc.) against one or more wheels of one or more train cars included in the cut causing the cut to slow down. In embodiments, the amount of energy, or speed, removed from a cut by a retarder (e.g., one or more retarders of retarders 146) may depend on the amount of pressure applied by the retarder against one or more wheels of one or more train cars included in the cut. For example, a higher pressure may cause more energy, or speed, to be removed from a cut than a lower pressure. In this manner, as the energy of a cut is related to the speed of the cut, retarders 146 may operate to remove energy from a cut. In this manner, classification yard 140 may control the speed of a cut as it travels through the marshalling tracks using retarders 146 to remove energy from the cut as necessary.

[0050] In embodiments, detectors 144 may include one or more detectors configured to detect a speed of a cut. In embodiments, detectors 144 may be laid out at different points along the tracks of classification yard 140. In this manner, detectors 144 may be configured to detect the speed of a cut at various points along the route of the cut through the marshalling tracks of classification yard 140.

[0051] In embodiments, detectors 144 may be configured to detect the presence of a cut at various points along the route of the cut through the marshalling tracks of classification yard 140. For example, as a cut passes through a detector a particular time, the detector may detect the presence of the cut at the particular time, and may generate a detection, including an identification of the cut, a timestamp indicating date / time of the detection, the location of the detection (e.g., an identification of the detector), etc.

[0052] In some embodiments, detectors 144 may include one or more detectors configured to detect one or more wheels, or wheel axles (e.g., one or more wheels, or wheel axles, of a train car, or of a cut, passing through the one or more detectors). In embodiments, detectors 144 may detect more than one wheel (or wheel axle) of the train car, or cut, passing through detectors 144. For example, a train car passing through a detector may include multiple wheel axles. In this case, the detector may be configured to detect one or more of the multiple wheel axles, and in some embodiments may identify the wheel axle detected. For example, for a train car including four wheels, the detector may identify that a detection includes detection of wheel three of four, when the detector detects the third wheel in the train car. In another example, for a cut traveling through the detector that includes two train cars each including four wheels, the detector may identify that a detection includes detection of wheel five of eight, when the detector detects the fifth wheel in the cut. In some embodiments, the wheel detector may detect more than one wheel.

[0053] In some embodiments, detectors 144 may detect a speed of a cut by detecting multiple wheels of the cut, measuring the time between the detections, and calculating a speed based, at least in part, on the characteristics of the cut. For example, a cut may travel through a detector of detectors 144. The detector may detect a first wheel of the cut at a first time. A first detection of a first wheel of the cut may be generated with a timestamp equal to the first time. The detector may detect a second wheel of the cut at a second time. A second detection of the second wheel of the cut may be generated with a timestamp equal to the second time. In embodiments, the speed of the cut may be calculated by comparing the first and the second time, and determining a speed based on the distance between the first and the second wheel, which may be a known characteristic of the cut. For example, the distance between the first and second wheel traveled by cut over the difference between the first and second detection times may provide the speed of the cut over the detector.

[0054] In some embodiments, detectors 144 may detect a speed of a cut by detecting a cut at multiple detectors and measuring the time between the detections. For example, a cut may travel through a route along classification yard 140 and may pass a first detector of detectors 144 at a first time. The first detector may detect the cut (e.g., a wheel of the cut) at the first time. A first detection of the cut may be generated with a timestamp equal to the first time. The cut may continue travelling through the route and may pass a second detector of detectors 144 at a second time. The second detector may detect the cut (e.g., a wheel of the cut) at the second time. A second detection of the cut may be generated with a timestamp equal to the second time. In embodiments, the speed of the cut may be calculated by comparing the first and the second time, and determining a speed based on the distance between the first and the second detector, which may be a known characteristic of detectors 144. For example, the distance between the first and second detector traveled by cut over the difference between the first and second detection times may provide the speed of the cut between the first and second detectors.

[0055] In embodiments, the components of classification yard 140 may include occupancy devices that may include track circuits, light detectors, presence detectors, etc., and may be configured to detect occupancy of a track and / or track segment, such as to detect a presence of a vehicle within the track and / or track segment. In some embodiments, occupancy devices may be configured to detect when a track or track segment has been filled to a safe capacity, which may enable a system to prevent overfilling of the track or track segment. In embodiments, occupancy devices may be used in long sections of track that may not include a wheel detector, a retarder, etc. In embodiments, an occupancy device may be configured with predicted on and off times. If the on and off times are exceeded, a segment protected by the occupancy device may be temporarily protected and if the condition persists, the protection may remain. In embodiments, protecting a track or track segment may include routing away from the protected track or track segment, such as in response to a determination that sufficient time exists to route the vehicle away from the protected track or track segment. However, the railroad vehicle may be routed into the protected track segment (e.g., to prevent a side-swipe) in response to a determination that there is not sufficient time to route the vehicle away from the protected track or track segment.

[0056] Data collector 150 may be configured to capture and store (e.g., in a database, such as database 124) device event data related to device events associated with hardware devices (e.g., the various hardware devices of classification yard 140). In embodiments, during operations, predictions of the speed and / or arrival times of a cut at a hardware device (e.g., a retarder device, detector device, a switch device, etc.) may be made during classification operations of a classification yards. For example, a production prediction manager may generate production predictions (e.g., using control parameters including tuning coefficients, characteristics of the cut, characteristics of the track or device, etc.) of a speed and / or arrival times of a cut at a particular hardware device. In embodiments, the production predictions may include production predictions for a plurality of cuts scheduled to be classified through the classification yard and for many devices (e.g., switches, detectors) and / or segments of the classification yard. In some embodiments, expected results of hardware device operations (e.g., device events) may include an expected measurement related to the device event, such as a throw switch time for a switch event, an expected exit speed at a retarder, a predicted speed at a detector, etc. Example operations and techniques of a system for generating production predictions are described in related U.S. Patent Application Docket No. [BNSF-00163], the entire contents of which are herein incorporated by reference for all purposes.

[0057] In embodiments, as a device event occurs, real-world measurements related to the device event at a hardware device may be generated and may be captured by data collector 150. The captured real-world measurements related to the device event at the hardware device may be included into the device event associated with the hardware device. In embodiments, a device event associated with a hardware device may also include expected (e.g., predicted or expected) measurements related to the device event at the hardware device. In embodiments, data collector 150 may store the device events associated with a hardware device into a database (e.g., database 124) for subsequent analysis.

[0058] 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 server 110. In embodiments, the operator may be enabled, e.g., through the functionality of user terminal 130, to provide configuration parameters that may be used by system 100 to provide functionality for determining the status of hardware devices, as well as to interact with results (e.g., selection, confirmation, verification of results, etc.). In embodiments, user terminal 130 may be configured to communicate with other components of system 100. In embodiments, the functionality of user terminal 130 may include presenting results of hardware device status determination operations to an operator. In embodiments, the results of hardware device status determination operations may be presented to an operator via the GIU of user terminal 130.

[0059] In embodiments, server 110, classification yard 140 (and its various components), and user terminal 130 may be communicatively coupled via network 145. 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.

[0060] Server 110 may be configured to facilitate operations for determining a status of hardware devices in a classification yard in accordance with embodiments of the present disclosure. In embodiments, functionality of server 110 to facilitate determination of a status of hardware devices in a classification yard may be provided by the cooperative operation of the various components of server 110, as will be described in more detail below.

[0061] Although FIG. 1 shows a single server 110, it will be appreciated that server 110 and its individual functional blocks may be implemented as a single device 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. 1 illustrates components of server 110 as single and separate blocks, each of the various components of server 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 server 110 may actually be part of a different component of server 110, and as such, the description of the particular functionality described for the particular component of server 110 is for illustrative purposes and not limiting in any way.

[0062] As shown in FIG. 1, server 110 includes processor 111, memory 112, database 124, data compiler 121, thresholding analysis manager 122, and results manager 123. 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.

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

[0064] Memory 112 may also be configured to facilitate storage operations. For example, memory 112 may comprise database 124 for storing various information related to operations of system 100. For example, database 124 may store analysis models, threshold data, configuration information, etc., to be used for configuring system 100, etc. In embodiments, database 124 may store characteristics of various and different train cars, such as rolling resistance characteristics, weights, aerodynamic characteristics (e.g., drag coefficient, coupler overhang status, articulation status of the etc. In embodiments, database 124 may store device event data related to speed, energy, and / or arrival times measurements of various cuts at various points (e.g., devices and / or segments) of the classification yard.

[0065] Database 124 is illustrated as integrated into memory 112, but in some embodiments, database 124 may be provided as a separate storage module or may be provided as a cloud-based storage module. Additionally, or alternatively, database 124 may be a single database, or may be a distributed database implemented over a plurality of database modules.

[0066] Data compiler 121 may be configured to retrieve data related to device events associated with hardware devices, and to filter the data according to various configuration parameters for subsequent thresholding analysis (e.g., by threshold analysis manager 122). In some embodiments, data compiler 121 may include functionality to format and / or present device event data to an operator.

[0067] In embodiments, data compiler 121 may provide a robust mechanism for configuring, controlling, and executing data retrieval and compilation functionality in order to obtain a most appropriate set of device events and leverage the device event data to determine a status of a hardware device or hardware devices. For example, in embodiments, data compiler 121 may be configured to retrieve and compile the device event data by configuring and scheduling one or more analysis jobs that include configuration associated with the analysis job itself as well as the device event data against which thresholding analysis is to be performed.

[0068] In embodiments, configuring an analysis job may include specifying values for various parameters defining characteristics of the job as well as characteristics of the device events to be included in the thresholding analysis. In a sense, the configuration of an analysis job may serve to filter device events in the database so that data compiler 121 may compile those device events that meet the configuration (e.g., pass the filters). The resulting set of device events may be used in the thresholding analysis (e.g., performed by thresholding analysis manager 122) to determine a status of one or more hardware devices. For example, in embodiments, the various parameters defining characteristics of the job may include parameters for specifying attributes of the job, such as a schedule name, a starting time of the job, a minimum time period that the job should run, how often the job is to be scheduled (e.g., daily, weekly, monthly, etc.), how often the job is to recur (e.g., re-perform analysis of particular device events), etc. In embodiments, the various parameters defining characteristics of the device events to be included in the analysis may include parameters for specifying a hardware device for which device events are to be compiled (e.g., an identification of the hardware device), a minimum device event count, a type of precipitation associated with the device events, such as the precipitation status when the device event was recorded (e.g., dry, wet, rain, snow, rust, all, etc.), a maximum temperature at the time of the device event, a minimum temperature at the time of the device event, an indication of a time period that each task performing the analysis job may be available after completion, etc.

[0069] In some embodiments, data compiler 121 may be configured to provide a user interface (UI) via which an operator may specify values for the various configuration parameters of an analysis job. For example, data compiler 121 may present the UI (e.g., via user terminal 130) to the operator and may include various fields via which the operator may specify values for respective configuration parameters. In some embodiments, the values for the various configuration parameters of an analysis job may be automatically selected by data compiler 121, such as by retrieving values stored in database 124, which may be previously specified by an operator or may be default values.

[0070] In embodiments, scheduling an analysis job may include defining a period over which the analysis job may be executed, as well as the recursive configuration of the analysis job. In embodiments, an analysis job may be scheduled, which may make the analysis job available to be executed. The execution of the analysis job may be performed using tasks, in which case the job may be executed against a set of device events currently available via a task execution. In this manner, a task for an analysis job may execute the analysis job based on the analysis job configuration on device event data current available. In some embodiments, a second task may be started for the same analysis job, in which case the second task may execute the analysis job (e.g., in accordance with the analysis job configuration) against a set of device events as available with respect to the second task. In this manner, as device event data in the database changes (e.g., more data is collected), a task may permit the analysis job to be executed for the data as it changes. For example, an analysis job may be scheduled to be run weekly, in which case, every week, data compiler 121 may compile device events (e.g., from database 124) that meet the analysis job configuration into a task which is executed to perform the determination of the status of one or more hardware devices in the classification yard. This functionality may allow data retriever and compiler 121 to ensure that the analysis job for hardware device status determination may be performed recursively, and in this manner the results of a first iteration of the analysis job may be leveraged in a subsequent execution (e.g., via a second task). In addition, the use of tasks may also enable the analysis to be performed over different sets of device event data, which may facilitate a diverse thresholding analysis of the data.

[0071] In embodiments, the functionality of data compiler 121 to enable the configuration of analysis jobs may provide a mechanism to configure different analysis jobs with different sets of configuration parameter values, which may combine for a full deployment of configurations that may cover a large set of situations, conditions, and / or configurations. In some embodiments, data compiler 121 may include functionality to combine jobs, such as by defining a field for specifying that an analysis job is combinable. In embodiments, combining analysis jobs may include combining the results (e.g., hardware device status determination results) of the analysis jobs, such as for presentation to an operator for verification, confirmation, and / or corrective actions to address hardware device status results.

[0072] In embodiments, analysis jobs may include configuration that may enable device event data to be classified based on various factors. For example, a particular device event may be classified into a particular classification (e.g., a particular data bucket) based on environmental conditions (e.g., weather, etc.), train car type, bearing type of the train car, etc. In embodiments, the various classifications, or buckets, may include a cold bucket (e.g., that may be used to classify device events that occur during cold weather), a warm bucket (e.g., that may be used to classify device events that occur during warm weather), a hot bucket (e.g., that may be used to classify device events that occur during hot weather), a wet bucket (e.g., that may be used to classify device events that occur during wet weather), a snow bucket (e.g., that may be used to classify device events that occur during snowy weather), a rain bucket (e.g., that may be used to classify device events that occur during rainy weather), a dry bucket (e.g., that may be used to classify device events that occur during dry weather), a resilience type bucket (e.g., that may be used to classify device events based on whether the cut includes train cars with a resilience type bearing), etc. It will be appreciated that the description of the above data buckets that may be used to classify device events are provided for illustrative purposes and not by way of limitation. As such, additional and / or different data buckets may be used to classify device events.

[0073] In embodiments, an analysis job may be configured as corresponding to a particular data bucket (e.g., an analysis job may be configured to be used for determining status of hardware devices using device event data associated with a data bucket). In these embodiments, the results of the analysis jobs may be specifically tailored to the conditions associated with the particular data bucket with which the analysis job is configured. In this manner, this functionality to configure a job with a data bucket may enable system 100 to perform operations for determining a status of hardware devices in a classification yard in which the status determination is tailored for particular conditions (e.g., environmental conditions, train car type, bearing type of the train car, etc.). In embodiments, this functionality may allow system 100 to ensure that device status determinations are made based on prevailing conditions. For example, in some cases, some hardware devices may be known to operate inefficiently in cold weather, as compared with the efficiency of the hardware devices in warm weather. In this case, by tailoring the thresholding analysis to a particular prevailing condition, the results may take into account the currently prevailing conditions, which may prevent misidentification of hardware device status (e.g., a good hardware device may be labeled as bad during cold weather if the thresholding analysis does not take into account the cold weather conditions).

[0074] In embodiments, the configuration of the analysis job may specify the data bucket applicable to the analysis job. For example, an analysis job may be configured as applicable to the cold bucket. In this example, data compiler121 may operate to compile a set of device events for thresholding analysis that includes device events that occur during cold weather. In this manner, the results of the thresholding analysis using the results of this analysis job may be specifically tailored to cold weather conditions. In another example, an analysis job may be configured as applicable to the dry bucket. In this example, data compiler 121 may operate to compile a set of device events for thresholding analysis that includes device events that occur during dry weather, such as device events occurring while no rain or snow was present. In this manner, the results of the thresholding analysis using the results of this analysis job may be specifically tailored to dry weather conditions. In yet another example, an analysis job may be configured as applicable to the dry and cold bucket. In this example, data compiler 121 may operate to compile a set of device events for thresholding analysis that includes device events that occur during dry and cold weather, such as device events occurring during cold weather while no rain or snow was present. In this manner, the results of the thresholding analysis using the results of this analysis job may be specifically tailored to dry and cold weather conditions. In still another example, an analysis job may be configured as applicable to a “resilience bearing true” bucket. In this example, data compiler 121 may operate to compile a set of device events for thresholding analysis that includes device events in which each cut generating each of the device events including one or more train cars having resilient bearing. In this manner, the results of the thresholding analysis using the results of this analysis job may be specifically tailored to reliance bearing conditions.

[0075] In some embodiments, current or recent device event data may include device event data associated with a particular data bucket representing currently prevailing conditions. For example, currently prevailing conditions may include cold weather (e.g., currently may be winter in the location of classification yard 140). In this case, the current and / or recent device event data in the database may include mostly, if not exclusively, cold weather device events (e.g., device events belonging to the cold data bucket) due to the currently prevailing weather conditions. In embodiments, analysis jobs that may executed to be used for thresholding analysis may include these mostly, if not exclusively, cold weather device events, which may result in hardware device status determination results (e.g., based on thresholding analysis) that may be biased and / or tailored to the prevailing weather conditions (e.g., cold weather conditions in this example).

[0076] Following the example above, if and when the weather changes to warmer conditions, a next device event (or a series of next device events) may be warm device events. In this case, it may be desirable to ensure that the thresholding analysis for determining a status of hardware devices may be tailored to the new warmer prevailing condition. However, as most of the previous device events may include cold weather device events, due the previously prevailing cold weather conditions, tuning the thresholding analysis for determining a status of hardware devices to the current warm weather conditions may be challenging, as the current data is biased to cold weather (e.g., previously prevailing condition). To address this, data compiler 121 may provide functionality to specify alternate data buckets into which device events may be classified. In embodiments, an analysis job may be configured with parameters that may specify a main data bucket and one or more alternate data buckets. In these embodiments, the analysis job may be executed against a set of device events that includes device events associated with the main data bucket. However, if no device events associated with the main data bucket exist in the database, or if less than a threshold number of device events associated with the main data bucket exist in the database, data retriever and compiler 121 may operate to include device events associated with the one or more alternate data buckets. For example, configuration of an analysis job may specify a warm bucket, with a cold bucket as alternative. However, the weather conditions recently change from cold to warm. As a result, there may be no or limited warm weather device events. In this case, the warm bucket analysis job still may be executed, but against a set of device events that may include cold weather device events. The results of the analysis job may be used to automatically tune the thresholding analysis for determining a status of hardware devices. This functionality to specify alternative data buckets for an analysis job may enable system 100 to provide a mechanism to leverage the benefits of the thresholding analysis for determining a status of hardware devices functionality of embodiments, even when the device event data may not be perfectly fit to the current prevailing conditions.

[0077] In embodiments, data compiler 121 may be configured to provide the compiled set of device events for a particular analysis job to thresholding analysis manager 122. In embodiments, each device event may be associated with a hardware device, and may include information related to real-world measurements (e.g., activation time, switch throw time, speed, energy, arrival time, etc.) associated with a respective device event.

[0078] In embodiments, a flag may be provided in configuration for a hardware device that may be used to specify the status of the hardware device. For example, the flag may be used to indicate a “good status” for the hardware device indicating that the status of the hardware device is good, which may indicate that the hardware device is able to perform operations related to the device event with an acceptable level of performance, a “bad status” for the hardware device indicating that the status of the hardware device is bad, which may indicate that the hardware device is not able to perform operations related to the device event with an acceptable level of performance and may be fully or close to fully degraded, and / or a “warning status” indicating that the status of the hardware device is cautionary, and may indicate that although the hardware device is able to perform operations related to the device event with an acceptable level of performance, the performance of the hardware device has degraded significantly and may be close to failing.

[0079] In embodiments, data compiler 121 may be configured to filter device events to be compiled based on the status flag of a hardware device. For example, data compiler 121 may determine whether the status flag of a hardware device has been reset from a “bad status” or “warning status” to a “good status.” In response to a determination that the status flag of a hardware device has been reset from a “bad status” or “warning status” to a “good status,” data compiler 121 may filter out any device events that occurred (e.g., with a timestamp) before the status flag of the hardware device was reset from the compiled set of device events to be provided to thresholding analysis manager 122. In this manner, the compiled set of device events to be provided to thresholding analysis manager 122 may include device events for hardware devices occurring from the time the status flag of the hardware device was reset to a current time. This functionality may allow system 100 to ensure that the thresholding analysis is iterative with respect to corrective actions. For example, system 100 may cause a corrective action to be applied to a hardware device determined to have a “bad status” or “warning status.” After the corrective action, however, further thresholding analysis may be performed against the hardware device. In the case where the further thresholding analysis is performed on device events including the previous device events, the analysis may be biased toward a bad status finding. By resetting the set of device events that are considered in the determination of the status of a hardware device to include only device events after corrective action was taken on the hardware device, status results may be more reliable. In addition, resetting the set of device events that are considered in the determination of the status of a hardware device to include only device events after corrective action was taken on the hardware device may allow system 100 to determine whether a finding of a bad status hardware device may be actually caused by the prediction scheme (e.g., the prediction as to the expected measurements for a device event), rather than an actual bad status of the hardware device. In this case, if a hardware device is found to have a bad status numerous times after corrective action, system 100 may make a determination that the problem may be not that the hardware device is bad, but that the prediction scheme may be out of tune and not as accurate as should be.

[0080] In embodiments, data compiler 121 may be configured to calculate, based on the compiled set of device events, a measurement difference for each device event in the compiled set of device events. In embodiments, data compiler 121 may calculate, for each device event in the compiled set of device events, a measurement difference by calculating a difference between expected measurements and actual measurements. For example, for a device event associated with a hardware device, data compiler 121 may subtract the expected measurement indicated in the device event from the actual measurement measured in real-world during the device event. The result of the subtraction may be the measurement difference associated with the device event. Data compiler 121 may perform the same calculations for each device event in the compiled set of device events to obtain a measurement difference for each device event in the compiled set of device events. The result may be a set of measurement differences associated with the set of compiled set of device events, where each measurement difference in the set of measurement differences represents a difference between an expected measurement for the device event and an actual measurement for the device event. In embodiments, the set of measurement differences may be stored in database 124 and / or may be provided to thresholding analysis manager 122.

[0081] In embodiments, data compiler 121 may be configured to determine, based on the compiled set of device events, a utilization metric for each device event in the compiled set of device events. For example, data compiler may determine, for a device event, the amount of utilization of the associated hardware device during the device event. In some embodiments, the amount of utilization of the associated hardware device during the device event may include how much the hardware was used during the device event to obtain the results of the device events. For example, for a switch event, the utilization metric may include a switch throw count indicating at total number of times a switch device has been thrown. In another example, for a retarder event, the utilization metric may indicate the amount of utilization of the retarder during the retarder event to reach the exit speed. The result may be a set of utilization metrics associated with the set of compiled set of device events. In embodiments, the set of utilization metrics may be stored in database 124 and / or may be provided to thresholding analysis manager 122.

[0082] In some embodiments, data compiler 121 may be configured to generate a visual representation of the set of measurement differences and / or the set of utilization metrics, and to present the generated visual representation to an operator. For example, in some embodiments, data compiler 121 may generate a box-and-whisker graph from the set of measurement differences against the deviation represented by a measurement difference from zero. In this case, a non-zero value for a measurement difference may represent a deviation from zero, with zero indicating that there is no measurement difference (e.g., the actual measurement and the expected measurement for the device event are the same). In this example, a large deviation from zero may represent a device event in which the hardware device was not very accurate (e.g., the actual results of the device event were far off from the expected results). On the other hand, a small deviation from zero, or a zero deviation, may represent a device event in which the hardware device was very accurate (e.g., the actual results of the device event were very close to the expected results). In embodiments, the box-and-whisker graph may then be presented to the operator using a UI (e.g., via user terminal device 130). In some embodiments, an operator presented with the box-and-whisker graph may gain insight into the operational performance of the hardware devices represented in the box-and-whisker chart, and may even make maintenance decisions to ensure that corrective action is taken on hardware devices that may not be operating efficiently.

[0083] Thresholding analysis manager 122 may be configured to apply thresholding analysis to the compiled set of device event data to determine a status of each hardware device represented in the compiled set of device event data. In particular, thresholding analysis manager 122 may perform thresholding analysis using the set of exit speed differences and / or the set of utilization metrics generated by data compiler 121, as described above. In embodiments, the thresholding analysis applied by manager 122 may include application of one or more rules to the data in set of exit speed differences and / or the set of utilization metrics and to determine the status of the hardware device indicated by the result of the application of the one or more rules.

[0084] In embodiments, a first set of rules that may be applied in the thresholding analysis may include differential rules that may be applied to measurement differences associated with a hardware device. The differential rules may be applied to the set of measurement differences generated by data compiler 121 and may be configured to determine the status of a hardware device based on the rule application.

[0085] In embodiments, a first differential rule may include a rule that determines that the status of a hardware device is good when no more than a threshold percentage of actual device event measurements associated with the hardware device are outside of a plus or minus measurement from an expected measurement. Put another way, the first differential rule determines that the status of a hardware device is good when no more than a threshold percentage of measurement differences are outside the range defined between [+expected measurement and expected measurement]. In embodiments, thresholding analysis manager 122 may apply this first differential rule against the set of measurement differences to determine, for each hardware device, the percentage of measurement differences associated with each hardware device that are outside the range defined between [+expected measurement and −expected measurement]. Thresholding analysis manager 122 may then compare the percentage of measurement differences associated with each hardware device that are outside the range defined between [+expected measurement and −expected measurement] with the threshold percentage. If, for a particular hardware device, the percentage of measurement differences associated with each hardware device that are outside the range defined between [+expected measurement and −expected measurement] is less than the threshold percentage, thresholding analysis manager 122 may determine that the particular hardware device has passed the first differential rule. On the other hand, if, for the particular hardware device, the percentage of measurement differences associated with each hardware device that are outside the range defined between [+expected measurement and −expected measurement] is not less than the threshold percentage, thresholding analysis manager 122 may determine that the particular hardware device has failed the first differential rule.

[0086] For example, a threshold percentage of 75% and a plus or minus measurement threshold of 1 MPH may be specified for an application of the first differential rule. In this example, thresholding analysis manager 122 may determine, based on the set of measurement differences, for a first hardware device, the percentage of measurement differences associated with the first hardware device that are outside of plus or minus 1 MPH (e.g., outside of [−1 MPH to 1 MPH]). Thresholding analysis manager 122 may then compare the percentage of measurement differences associated with the first hardware device that are outside of plus or minus 1 MPH with the threshold percentage of 75%. In this example, if the percentage of measurement differences associated with the first hardware device that are outside of plus or minus 1 MPH is less than 75%, thresholding analysis manager 122 may determine that the first hardware device passed the first differential rule. However, if the percentage of measurement differences associated with the first hardware device that are outside of plus or minus 1 MPH is not less than 75%, thresholding analysis manager 122 may determine that the first hardware device failed the first differential rule. Thresholding analysis manager 122 may continue applying the first differential rule to all hardware devices represented in the set of measurement differences to determine the status of each hardware device represented in the set of measurement differences.

[0087] In embodiments, thresholding analysis manager 122 may apply the first differential rule to a hardware device with a parameter that ensures that the result of the application will be a percentage ratio between the percentage of measurement differences associated with the hardware device that are outside the range defined between [+expected measurement and −expected measurement] and the parameter, such that the hardware device may be considered as a bad hardware device by thresholding analysis manager 122 when the percentage ratio is at least 100%. In these embodiments, the parameter may include a value by which the percentage of measurement differences associated with the hardware device that are outside the range defined between [+expected measurement and −expected measurement] is divided. For example, thresholding analysis manager 122 may calculate the percentage of measurement differences associated with the hardware device that are outside the range defined between [+expected measurement and −expected measurement] and may then divide the percentage by the parameter. The result may be a value configured to be 1 (or 100%) when the percentage of measurement differences associated with the hardware device that are outside the range defined between [+expected measurement and −expected measurement] is above the threshold percentage. In embodiments, a hardware device may be determined to not fail the first differential rule, but the percentage ratio may be close to 100%, in which case, even though the hardware device may not be flagged as a bad hardware device, the hardware device may be flagged as needing attention (e.g., using a “section warning” indication or a “warning” indication), as it may be close to becoming a bad hardware device. In this manner, thresholding analysis manager 122 may be configured to determine “how close” a hardware device may be to failing. In some embodiments a percentage ratio threshold may be used to determine to flag a hardware device as needing attention (e.g., a warning) even though the hardware device may not be flagged as a bad hardware device. In some embodiments, the percentage ratio threshold may be a value above 50% but less than 100%.

[0088] In embodiments, a second differential rule may include a rule that determines that the status of a hardware device is good when a median and / or average of the measurement differences associated with the hardware device is not outside of a range defined by plus or minus an average threshold. In embodiments, thresholding analysis manager 122 may apply this second differential rule against the set of measurement differences to determine, for each hardware device, the median and / or average of the measurement differences associated with each hardware device. Thresholding analysis manager 122 may then compare the median and / or average of the measurement differences associated with each hardware device with the range defined by plus or minus an average threshold. If, for a particular hardware device, the median and / or average of the measurement differences associated with the particular hardware device is within the range defined by plus or minus an average threshold, thresholding analysis manager 122 may determine that the particular hardware device has passed the second differential rule. On the other hand, if, for the particular hardware device, the median and / or average of the measurement differences associated with the particular hardware device is outside of the range defined by plus or minus an average threshold, thresholding analysis manager 122 may determine that the particular hardware device has failed the second differential rule.

[0089] For example, an average threshold of 2 MPH may be specified for an application of the second differential rule. In this example, thresholding analysis manager 122 may determine, based on the set of measurement differences, for a first hardware device, the median and / or average of the measurement differences associated with the first hardware device. Thresholding analysis manager 122 may then compare the median and / or average of the measurement differences associated with the first hardware device with range defined by plus or minus the average threshold of 2 MPH (e.g., the range of [−2 MPH to 2 MPH]). In this example, if the median and / or average of the measurement differences associated with the first hardware device is between −2 MPH and 2 MPH, thresholding analysis manager 122 may determine that the first hardware device passed the second differential rule. However, if the median and / or average of the measurement differences associated with the first hardware device is outside of −2 MPH to 2 MPH, thresholding analysis manager 122 may determine that the first hardware device failed the second differential rule. Thresholding analysis manager 122 may continue applying the second differential rule to all hardware devices represented in the set of measurement differences.

[0090] In embodiments, thresholding analysis manager 122 may apply the second differential rule to a hardware device with a parameter that ensures that the result of the application of the second differential rule will be a percentage ratio, such that the hardware device may be considered as a bad hardware device by thresholding analysis manager 122 when the percentage ratio is at least 100%. In embodiments, a hardware device may be determined to not fail the second differential rule, but the percentage ratio may be close to 100%, in which case, even though the hardware device may not be flagged as a bad hardware device, the hardware device may be flagged as needing attention (e.g., using a “section warning” indication or a “warning” indication), as it may be close to becoming a bad hardware device. In this manner, thresholding analysis manager 122 may be configured to determine “how close” a hardware device may be to failing. In some embodiments a percentage ratio threshold may be used to determine to flag a hardware device as needing attention (e.g., a warning) even though the hardware device may not be flagged as a bad hardware device. In some embodiments, the percentage ratio threshold may be a value above 50% but less than 100%.

[0091] In embodiments, a third differential rule may include a rule that determines that the status of a hardware device is good when a defined middle percentage of the measurement differences associated with the hardware device are not spread over a spread range greater than a spread threshold. In embodiments, the defined middle percentage may be defined as a threshold and may include a range of measurement differences values defined by a top percentile threshold and a bottom percentile threshold. For example, a defined middle percentage may include a range of 50% of the measurement differences associated with the hardware device, and may be defined as the range between the bottom 25 percentile and the top 75 percentile of data points (e.g., the range that excludes the bottom 25th percentile and excludes the top 25% of the data points). In embodiments, thresholding analysis manager 122 may apply this third differential rule against the set of measurement differences to determine, for each hardware device, the spread range of the defined middle percentage of measurement differences associated with each hardware device. For example, thresholding analysis manager 122 may determine, for each hardware device, the difference between the lowest measurement difference value in the measurement differences within the defined middle percentage and the highest measurement difference value in the measurement differences within the defined middle percentage to determine the spread range of the defined middle percentage of measurement differences associated with each hardware device. Thresholding analysis manager 122 may then compare the spread range of the defined middle percentage of measurement differences associated with each hardware device with the spread threshold. If, for a particular hardware device, the spread range of the defined middle percentage of measurement differences associated with each hardware device is less than the spread threshold, thresholding analysis manager 122 may determine that the particular hardware device has passed the third differential rule. On the other hand, if, for the particular hardware device, the spread range of the defined middle percentage of measurement differences associated with each hardware device is not less than the spread threshold, thresholding analysis manager 122 may determine that the particular hardware device has failed the third differential rule.

[0092] For example, a spread threshold of 3 MPH may be specified for an application of the third differential rule. In addition, a middle percentage that includes the range between the bottom 25 percentile and the top 75 percentile of data points may be defined for the third differential rule. In embodiments, thresholding analysis manager 122 may apply this third differential rule against the set of measurement differences and may identify measurement differences associated with a hardware device falling within the middle percentage of all the measurement differences associated with the hardware device. Analysis manager 122 may then determine a spread range of the measurement differences within the middle percentage. For example, thresholding analysis manager 122 may determine, the difference between the lowest measurement difference value within the middle percentage and the highest measurement difference value within the defined middle percentage. Analysis manager 122 may determine the spread range of the middle percentage as the difference between the highest measurement difference value and the lowest measurement difference value. In this example, thresholding analysis manager 122 may compare the spread range of the middle percentage to the spread threshold of 3 MPH. In this example, if the spread range of the middle percentage is less than the spread threshold of 3 MPH, thresholding analysis manager 122 may determine that the first hardware device passed the third differential rule. However, if the spread range of the middle percentage is not less than the spread threshold of 3 MPH, thresholding analysis manager 122 may determine that the first hardware device failed the third differential rule. Thresholding analysis manager 122 may continue applying the third speed differential rule to all hardware devices represented in the set of measurement differences.

[0093] In embodiments, thresholding analysis manager 122 may apply the third differential rule to a hardware device with a parameter that ensures that the result of the application of the third differential rule will be a percentage ratio, such that the hardware device may be considered as a bad hardware device by thresholding analysis manager 122 when the percentage ratio is at least 100%. In embodiments, a hardware device may be determined to not fail the third differential rule, but the percentage ratio may be close to 100%, in which case, even though the hardware device may not be flagged as a bad hardware device, the hardware device may be flagged as needing attention (e.g., using a “section warning” indication or a “warning” indication), as it may be close to becoming a bad hardware device. In this manner, thresholding analysis manager 122 may be configured to determine “how close” a hardware device may be to failing. In some embodiments a percentage ratio threshold may be used to determine to flag a hardware device as needing attention (e.g., a warning) even though the hardware device may not be flagged as a bad hardware device. In some embodiments, the percentage ratio threshold may be a value above 50% but less than 100%.

[0094] In embodiments, a fourth differential rule may include a weighted combination of the first, second, and third differential rules. In embodiments, thresholding analysis manager 122 may apply the fourth differential rule by combining the results of the first, second, and third differential rules in a weighted combination. The weighted combination may include applying a respective multiplier to the results of each of the first, second, and third differential rules. For example, in a particular example, weighted factors of 3, 2, and 2.25 may be configured for the results of the first, second, and third differential rules, respectively. In this example, thresholding analysis manager 122 may apply the respective weighted factor to each of the first, second, and third differential rules and may then sum the results to obtain a single result for the combination rule. In embodiments, applying the respective weighted factor to each of the first, second, and third differential rules may include raising each of the of the first, second, and third differential rules results by a power equal to the respective weighted factors. For example, in this example, the results of the first rule may be raised to a power of 3, the results of the second rule may be raised to a power of 2, and the results of the third rule may be raised to a power of 2.5. In this example, the results of each exponential operation may be summed to obtain an overall result for the fourth rule. In some embodiments, as the results of the first, second, and third differential rules may include a percentage value, the result of the combination rule (e.g., fourth differential rule) may also be a percentage value. It is noted that the particular weighted factors of 3, 2, and 2.25 are described by way of example and not intended to be limiting in any way. Indeed, in some embodiments, other weighted factors may be used. For example, in another particular example, weighted factors of 2, 3, and 1.1 may be configured for the results of the first, second, and third differential rules, respectively.

[0095] In embodiments, thresholding analysis manager 122 may determine a status of a hardware device based on whether the hardware device failed or passed each of differential rules. For example, if a hardware device failed any of the differential rules, the status of the hardware device may be set as bad. On the other hand, if the hardware device passed all applied differential rules, the status of the hardware device may be set as good. In particular embodiments, a hardware device may fail the fourth differential rule (e.g., the combination rule) even if the hardware device has not failed any one of the individual rules (e.g., where the weighed factors may be greater than one), such as when the hardware device may pass the individual rules but may fail the fourth differential rule.

[0096] In embodiments, other sets of rules may be applied in the thresholding analysis. For example, utilization rules that may apply thresholding rules to the set of utilization metrics may be applied to determine the status of a hardware device. These rules may determine how close the utilization metrics are to expected values, whether the utilization metrics are below expected values, and / or the spread of the utilization metric values, in order to determine whether the utilization metric data indicates that a hardware device is degraded.

[0097] Results manager 123 may be configured to report the results of the thresholding analysis by thresholding analysis manager 122 and to generate, track, and / or control corrective actions performed in response to the determination of the status of hardware devices. For example, in some embodiments, results manager 123 may be configured to automatically generate a corrective action without operator intervention. In embodiments, results manager 123 may issue a notification to operators of the status of a hardware device, in which case the operators may take corrective action. In some embodiments, results manager 123 may, in response to a determination that the status of a hardware device is bad, send a control signal to the deactivate the hardware device in order to avoid potential damage. In some embodiments, the control signal to the deactivate the hardware device may include a signal to deactivate a specific section of the hardware device (e.g., a section determined to be bad), a control signal to adjust parameters of the specific section, etc.

[0098] In embodiments, results manager 123 may be configured to generate and provide one or more status reports indicating the determined status of one or more hardware devices based on the thresholding analysis by thresholding analysis manager 122. In embodiments, the status report may be interactive and may allow an operator to modify entries on the report. Modified entries in the report may be detected by results manager 123, which may cause results manager 123 to store the modified entries in the respective configurations of the corresponding hardware device. For example, in some embodiments, an operator may reset a status indicator flag of a hardware device (e.g., after corrective action has been taken on the hardware device) from a bad hardware device or a section warning status indicator to a good hardware device status indicator. In these cases, the configuration of the corresponding hardware device may include an indication that the status flag for the hardware device has been reset. In embodiments, device events associated with the hardware device having a timestamp with a value before the time the status flag was reset may be scrubbed or removed from the database. In this manner, subsequent thresholding analysis performed for the hardware device may only include device events after the status flag reset. The same process of removing device events associated with a hardware device occurring prior to a status flag reset for the hardware device may be performed every time the status flag for the hardware device is reset. However, in embodiments, results manager 123 may determine that the status flag of a hardware device found in a current thresholding analysis iteration to be a bad hardware device or having a section warning has been reset a number of times before, and that the number of times exceeds a threshold number of times. In this case, results manager 123 may determine to include an indication indicating that there is a likelihood that the hardware device is not actually bad, even though it has been found to be bad in the current thresholding analysis iteration, and there may be a possibility that the problem (e.g., the cause of the hardware device being found to be a bad hardware device) may be another device (e.g., a detector used to collect speed information associated with the hardware device) or the prediction scheme used to determine the expected speeds at the hardware device.

[0099] FIG. 2 shows a high-level flow diagram 200 of operation of a system configured in accordance with embodiments of the present disclosure for determining a status of hardware devices in a classification yard. For example, the functions illustrated in the example blocks shown in FIG. 2 may be performed by system 100 of FIG. 1 according to embodiments herein. In embodiments, the operations of the method 200 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 200.

[0100] At block 202, a plurality of device events associated with a hardware device in a classification yard may be compiled. In embodiments, each device event of the plurality of device events may be associated with an expected measurement and may include real-world measurements of an actual measurement at the hardware device during each device event of the plurality of device events and / or an indication of a utilization of the hardware device during each device event of the plurality of device events to obtain the expected measurement for each device event. In embodiment, functionality of a data compiler (e.g., data compiler 121 in FIG. 1) may be used to compile the plurality of device events associated with the hardware device in the classification yard. In embodiments, the data compiler may perform operations to compile the plurality of device events associated with the hardware device in the classification yard according to operations and functionality as described above with reference to data compiler 121 and as illustrated in FIG. 1.

[0101] At block 204, a set of deviation metrics associated with the hardware device is generated based on the plurality of device events associated with the hardware device. In embodiment, functionality of a data compiler (e.g., data compiler 121 in FIG. 1) may be used to generate the set of deviation metrics associated with the hardware device based on the plurality of device events associated with the hardware device. In embodiments, the data compiler may perform operations to generate the set of deviation metrics associated with the hardware device based on the plurality of device events associated with the hardware device according to operations and functionality as described above with reference to data compiler 121 and as illustrated in FIG. 1.

[0102] At block 206, thresholding analysis is applied to the set of deviation metrics associated with the hardware device to determine a status of the hardware device. In embodiment, functionality of a threshold analysis manager (e.g., threshold analysis manager 122 in FIG. 1) may be used to apply thresholding analysis to the set of deviation metrics associated with the hardware device to determine a status of the hardware device. In embodiments, the threshold analysis manager may perform operations to apply thresholding analysis to the set of deviation metrics associated with the hardware device to determine a status of the hardware device according to operations and functionality as described above with reference to threshold analysis manager 122 and as illustrated in FIG. 1.

[0103] At block 208, a corrective action signal including an indication of the status of the hardware device and / or a corrective action to be taken for the hardware device is generated. In embodiment, functionality of a results manager (e.g., results manager 123 in FIG. 1) may be used to generate a corrective action signal including an indication of the status of the hardware device and / or a corrective action to be taken for the hardware device. In embodiments, the results manager may perform operations to generate a corrective action signal including an indication of the status of the hardware device and / or a corrective action to be taken for the hardware device according to operations and functionality as described above with reference to results manager 123 and as illustrated in FIG. 1.

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

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

[0106] 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 inventions can be established by the appended claims rather than by the foregoing description. 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

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

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

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

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

[0111] Although the present invention 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 invention 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 invention, 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 invention. Accordingly, the appended claims are intended to include within their scope such processes, machines, manufacture, compositions of matter, means, methods, or steps.

Claims

1. A method of determining a status of hardware devices in a classification yard, comprising:compiling a plurality of device events associated with a hardware device in a classification yard, wherein each device event of the plurality of device events is associated with an expected measurement and includes one or more of:real-world measurements of an actual measurement at the hardware device during each device event of the plurality of device events; andan indication of a utilization of the hardware device during each device event of the plurality of device events to obtain the expected measurement for each device event;generating a set of deviation metrics associated with the hardware device based on the plurality of device events associated with the hardware device;applying thresholding analysis to the set of deviation metrics associated with the hardware device to determine a status of the hardware device; andgenerating a corrective action signal including one or more of:an indication of the status of the hardware device; anda corrective action to be taken on the hardware device.

2. The method of claim 1, wherein generating the set of deviation metrics associated with the hardware device includes generating one or more of:a set of measurement differences associated with the hardware device; anda set of utilization metrics associated with the hardware device.

3. The method of claim 2, wherein generating the set of measurement differences associated with the hardware device includes:calculating, for each device event in the plurality of device events associated with a hardware device, a measurement difference by calculating a difference between the expected measurement associated with a respective device event and the actual measurement measured at the hardware device during the respective device event; andaggregating each calculated measurement difference for each device event into the set of measurement differences associated with the hardware device.

4. The method of claim 3, wherein applying thresholding analysis to the set of deviation metrics associated with the hardware device includes applying one or more of a set of differential rules to the set of measurement differences associated with the hardware device, wherein the set of differential rules includes one or more of:a first differential rule specifying that the status of the hardware device is based on whether a threshold percentage of the set of measurement differences associated with the hardware device are range defined by plus or minus a measurement threshold;a second differential rule specifying that the status of the hardware device is based on whether a median or average of the set of measurement differences associated with the hardware device is within a range defined by plus or minus an average threshold;a third differential rule specifying that the status of the hardware device is based on whether a spread range of measurement differences values within a middle percentage of the set of measurement differences associated with the hardware device is less than a spread threshold, wherein the middle percentage of the set of measurement differences is defined by a range of measurement differences values including a top percentile threshold of the measurement differences values in the set of measurement differences and a bottom percentile threshold of the measurement differences values in the set of measurement differences; anda combination differential rule that includes a weighted combination of the results of one or more of the first differential rule, the second differential rule, and the third differential rule.

5. The method of claim 1, wherein applying the thresholding analysis to the set of deviation metrics associated with the hardware device to determine the status of the hardware device includes:obtaining a percentage result for the hardware device, the percentage result indicating a percentage status of the hardware device.

6. The method of claim 5, wherein determining the status of the hardware device includes flagging a status flag of the hardware device with one or more of:a bad status indication when the percentage status of the hardware device is at least 100%;a warning status indication when the percentage status of the hardware device is greater than a threshold percentage and less than 100%;a good status indication when the percentage status of the hardware device is less than the threshold percentage.

7. The method of claim 6, wherein the warning status indication includes a section warning indication identifying a section of the hardware device determined to have failed the thresholding analysis.

8. The method of claim 1, further comprising:identifying that the indication of the status of the hardware device found to be bad has previously been reset a number of times;determining that the number of times exceeds a threshold amount; andflagging the hardware device as a potential misidentification of a bad hardware device.

9. A system for determining a status of hardware devices in a classification yard, comprising:at least one processor; anda 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:compiling a plurality of device events associated with a hardware device in a classification yard, wherein each device event of the plurality of device events is associated with an expected measurement and includes one or more of:real-world measurements of an actual measurement at the hardware device during each device event of the plurality of device events; andan indication of a utilization of the hardware device during each device event of the plurality of device events to obtain the expected measurement for each device event;generating a set of deviation metrics associated with the hardware device based on the plurality of device events associated with the hardware device;applying thresholding analysis to the set of deviation metrics associated with the hardware device to determine a status of the hardware device; andgenerating a corrective action signal including one or more of:an indication of the status of the hardware device; anda corrective action to be taken on the hardware device.

10. The system of claim 9, wherein generating the set of deviation metrics associated with the hardware device includes generating one or more of:a set of measurement differences associated with the hardware device; anda set of utilization metrics associated with the hardware device.

11. The system of claim 10, wherein generating the set of measurement differences associated with the hardware device includes:calculating, for each device event in the plurality of device events associated with a hardware device, a measurement difference by calculating a difference between the expected measurement associated with a respective device event and the actual measurement measured at the hardware device during the respective device event; andaggregating each calculated measurement difference for each device event into the set of measurement differences associated with the hardware device.

12. The system of claim 11, wherein applying thresholding analysis to the set of deviation metrics associated with the hardware device includes applying one or more of a set of differential rules to the set of measurement differences associated with the hardware device, wherein the set of differential rules includes one or more of:a first differential rule specifying that the status of the hardware device is based on whether a threshold percentage of the set of measurement differences associated with the hardware device are range defined by plus or minus a measurement threshold;a second differential rule specifying that the status of the hardware device is based on whether a median or average of the set of measurement differences associated with the hardware device is within a range defined by plus or minus an average threshold;a third differential rule specifying that the status of the hardware device is based on whether a spread range of measurement differences values within a middle percentage of the set of measurement differences associated with the hardware device is less than a spread threshold, wherein the middle percentage of the set of measurement differences is defined by a range of measurement differences values including a top percentile threshold of the measurement differences values in the set of measurement differences and a bottom percentile threshold of the measurement differences values in the set of measurement differences; anda combination differential rule that includes a weighted combination of the results of one or more of the first differential rule, the second differential rule, and the third differential rule.

13. The system of claim 9, wherein applying the thresholding analysis to the set of deviation metrics associated with the hardware device to determine the status of the hardware device includes:obtaining a percentage result for the hardware device, the percentage result indicating a percentage status of the hardware device.

14. The system of claim 13, wherein determining the status of the hardware device includes flagging a status flag of the hardware device with one or more of:a bad status indication when the percentage status of the hardware device is at least 100%;a warning status indication when the percentage status of the hardware device is greater than a threshold percentage and less than 100%;a good status indication when the percentage status of the hardware device is less than the threshold percentage.

15. The system of claim 14, wherein the warning status indication includes a section warning indication identifying a section of the hardware device determined to have failed the thresholding analysis.

16. The system of claim 9, further comprising:identifying that the indication of the status of the hardware device found to be bad has previously been reset a number of times;determining that the number of times exceeds a threshold amount; andflagging the hardware device as a potential misidentification of a bad hardware device.

17. A computer-based tool for determining a status of hardware devices in a classification yard, 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:compiling a plurality of device events associated with a hardware device in a classification yard, wherein each device event of the plurality of device events is associated with an expected measurement and includes one or more of:real-world measurements of an actual measurement at the hardware device during each device event of the plurality of device events; andan indication of a utilization of the hardware device during each device event of the plurality of device events to obtain the expected measurement for each device event;generating a set of deviation metrics associated with the hardware device based on the plurality of device events associated with the hardware device;applying thresholding analysis to the set of deviation metrics associated with the hardware device to determine a status of the hardware device; andgenerating a corrective action signal including one or more of:an indication of the status of the hardware device; anda corrective action to be taken on the hardware device.

18. The computer-based tool of claim 17, wherein generating the set of deviation metrics associated with the hardware device includes generating one or more of:a set of measurement differences associated with the hardware device; anda set of utilization metrics associated with the hardware device.

19. The computer-based tool of claim 18, wherein generating the set of measurement differences associated with the hardware device includes:calculating, for each device event in the plurality of device events associated with a hardware device, a measurement difference by calculating a difference between the expected measurement associated with a respective device event and the actual measurement measured at the hardware device during the respective device event; andaggregating each calculated measurement difference for each device event into the set of measurement differences associated with the hardware device.

20. The method of claim 19, wherein applying thresholding analysis to the set of deviation metrics associated with the hardware device includes applying one or more of a set of differential rules to the set of measurement differences associated with the hardware device, wherein the set of differential rules includes one or more of:a first differential rule specifying that the status of the hardware device is based on whether a threshold percentage of the set of measurement differences associated with the hardware device are range defined by plus or minus a measurement threshold;a second differential rule specifying that the status of the hardware device is based on whether a median or average of the set of measurement differences associated with the hardware device is within a range defined by plus or minus an average threshold;a third differential rule specifying that the status of the hardware device is based on whether a spread range of measurement differences values within a middle percentage of the set of measurement differences associated with the hardware device is less than a spread threshold, wherein the middle percentage of the set of measurement differences is defined by a range of measurement differences values including a top percentile threshold of the measurement differences values in the set of measurement differences and a bottom percentile threshold of the measurement differences values in the set of measurement differences; anda combination differential rule that includes a weighted combination of the results of one or more of the first differential rule, the second differential rule, and the third differential rule.

Images