SYSTEMS AND METHODS FOR MONITORING AND VALIDATING STATUS OF SWITCH DEVICES

Abstract

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

Claims

1. A method of determining a status of switch devices in a classification yard, comprising: compiling a plurality of switch events associated with a switch in a classification yard, wherein each switch event represents a request to throw the switch device from a first position to a second position, and wherein each car event includes real-world metrics including one or more of: actual measurements associated with the switch device during each switch event of the plurality of switch events: utilization metrics including measurements associated with a usage of the switch device; and failure metrics including indications of failure events incurred during one or more switch events of the plurality of switch events; generating a set of deviation metrics associated with the switch device based on the plurality of switch events associated with the switch device; applying thresholding analysis to the set of deviation metrics associated with the switch device to determine a status of the switch device; and generating a corrective action signal including one or more of: an indication of the status of the switch device; and a corrective action to be taken on the switch device.

2. The method of claim 1, wherein generating the set of deviation metrics associated with the switch device includes generating one or more of: a set of throw time differences associated with the switch device; and a set of utilization metrics associated with the switch device.

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

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

5. The method of claim 2, wherein applying thresholding analysis to the set of deviation metrics associated with the switch device includes applying one or more of a set of utilization rules to the set of utilization metrics associated with the switch device, wherein the set of utilization rules includes one or more of: a first utilization rule specifying that the status of the switch device is based on whether a percentage of utilization metrics associated with the switch device that indicate that the switch incurred a kickback event exceeds a first threshold percentage; a second utilization rule specifying that the status of the switch device is based on whether a percentage of utilization metrics associated with the switch device that indicate that the switch incurred a no-movement event exceeds a second threshold percentage; a third utilization rule specifying that the status of the switch device is based on whether a number of utilization metrics associated with the switch device that indicate a lost position exceeds a threshold number; and a fourth utilization rule specifying that the status of the switch device is based on whether a total throw count associated with the switch device exceeds a threshold throw count.

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

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

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

9. A system for determining a status of retarder devices in a classification yard, comprising: at least one processor; and a memory operably coupled to the at least one processor and storing processor-readable code that, when executed by the at least one processor, is configured to perform operations including: compiling a plurality of switch events associated with a switch in a classification yard, wherein each switch event represents a request to throw the switch device from a first position to a second position, and wherein each car event includes real-world metrics including one or more of: actual measurements associated with the switch device during each switch event of the plurality of switch events: utilization metrics including measurements associated with a usage of the switch device; and failure metrics including indications of failure events incurred during one or more switch events of the plurality of switch events; generating a set of deviation metrics associated with the switch device based on the plurality of switch events associated with the switch device; applying thresholding analysis to the set of deviation metrics associated with the switch device to determine a status of the switch device; and generating a corrective action signal including one or more of: an indication of the status of the switch device; and a corrective action to be taken on the switch device.

10. The system of claim 9, wherein generating the set of deviation metrics associated with the switch device includes generating one or more of: a set of throw time differences associated with the switch device; and a set of utilization metrics associated with the switch device.

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

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

13. The system of claim 10, wherein applying thresholding analysis to the set of deviation metrics associated with the switch device includes applying one or more of a set of utilization rules to the set of utilization metrics associated with the switch device, wherein the set of utilization rules includes one or more of: a first utilization rule specifying that the status of the switch device is based on whether a percentage of utilization metrics associated with the switch device that indicate that the switch incurred a kickback event exceeds a first threshold percentage; a second utilization rule specifying that the status of the switch device is based on whether a percentage of utilization metrics associated with the switch device that indicate that the switch incurred a no-movement event exceeds a second threshold percentage; a third utilization rule specifying that the status of the switch device is based on whether a number of utilization metrics associated with the switch device that indicate a lost position exceeds a threshold number; and a fourth utilization rule specifying that the status of the switch device is based on whether a total throw count associated with the switch device exceeds a threshold throw count.

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

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

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

17. A computer-based tool for determining a status of retarder 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 switch events associated with a switch in a classification yard, wherein each switch event represents a request to throw the switch device from a first position to a second position, and wherein each car event includes real-world metrics including one or more of: actual measurements associated with the switch device during each switch event of the plurality of switch events: utilization metrics including measurements associated with a usage of the switch device; and failure metrics including indications of failure events incurred during one or more switch events of the plurality of switch events; generating a set of deviation metrics associated with the switch device based on the plurality of switch events associated with the switch device; applying thresholding analysis to the set of deviation metrics associated with the switch device to determine a status of the switch device; and generating a corrective action signal including one or more of: an indication of the status of the switch device; and a corrective action to be taken on the switch device.

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

19. The computer-based tool of claim 18, wherein applying thresholding analysis to the set of deviation metrics associated with the switch device includes applying one or more of a set of time differential rules to the set of throw time differences associated with the switch device, wherein the set of time differential rules includes one or more of: a first time differential rule specifying that the status of the switch device is based on whether a threshold percentage of the set of throw time differences associated with the switch device is outside a range defined by plus or minus a time threshold; a second time differential rule specifying that the status of the switch device is based on whether an average of the set of throw time differences associated with the switch device is within a range defined by plus or minus an average threshold; a third time differential rule specifying that the status of the switch device is based on whether a spread range of throw time values within a middle percentage of a set of throw time values associated with the switch device is less than a spread threshold, wherein the middle percentage of the set of throw time values is defined by a range of throw time values including a top percentile threshold of the set of throw time values and a bottom percentile threshold of the set of throw time values; and a combination time differential rule that includes a weighted combination of the results of one or more of the first time differential rule, the second time differential rule, and the third time differential rule.

20. The computer-based tool of claim 18, wherein applying thresholding analysis to the set of deviation metrics associated with the switch device includes applying one or more of a set of utilization rules to the set of utilization metrics associated with the switch device, wherein the set of utilization rules includes one or more of: a first utilization rule specifying that the status of the switch device is based on whether a percentage of utilization metrics associated with the switch device that indicate that the switch incurred a kickback event exceeds a first threshold percentage; a second utilization rule specifying that the status of the switch device is based on whether a percentage of utilization metrics associated with the switch device that indicate that the switch incurred a no-movement event exceeds a second threshold percentage; a third utilization rule specifying that the status of the switch device is based on whether a number of utilization metrics associated with the switch device that indicate a lost position exceeds a threshold number; and a fourth utilization rule specifying that the status of the switch device is based on whether a total throw count associated with the switch device exceeds a threshold throw count.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0027] FIG. 2 shows an example of a box-and-whisker chart generated for a set of switch throw times associated with a plurality of switches in accordance with embodiments of the present disclosure.

[0028] FIG. 3 illustrates an example of a user interface presented to an operator to provide a status report associated with one or more switches in accordance with aspects of the present disclosure.

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

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

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

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

[0033] Various embodiments of the present disclosure are directed to systems and techniques that provide functionality for determining a status of switch devices in a classification yard. In particular embodiments, a set of switch event data associated with a switch may be analyzed to determine the performance of the switch to actuate to route cuts from their current tracks to a target track. A status of the switch may be determined from analysis of the performance of the switch to actuate to route cuts from their current tracks to a target tracks. In embodiments, the status of the switch may be used to ensure corrective actions are taken on the switch (e.g., deploy maintenance personnel, report the status of the switch, send a control signal to the switch to deactivate, etc.).

[0034] FIG. 1 is a block diagram of an exemplary system 100 configured with capabilities and functionality for determining a status of detector devices in a classification yard in accordance with embodiments of the present disclosure. As shown in FIG. 1, system 100 may include server 110, detectors 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, switches 140 may operate to route cuts traveling along a route through the classification yard from current tracks to target cuts. A switch may be actuated via a switch throw signal that may throw the switch from a first position to a second position (e.g., from a right position in which a first track corresponding to the right position is selected to a left position in which a second track corresponding to the left position is selected, or from a left position in which the second track corresponding to the left position is selected to a right position in which the first track corresponding to the right position is selected). A switch event may include an event in which a switch is thrown from a first position (e.g., right or left) to a second position (e.g., right or left). In embodiments, data collector 150 may operate to collect real-world switch event data associated with a plurality of switch events associated with each of switches 140. For example, each switch event (e.g., each time a switch is requested to be thrown) may generate switch event data, including an actual throw time (e.g., the actual time taken to throw the switch from the first position to the second position), expected throw time (e.g., the time expected to take to throw the switch from the first position to the second position), switch throw failure data (e.g., including whether the switch event resulted in a switch throw failure, such as a kickback event, a no movement event, a lost position event, etc.), a switch throw count associated with the switch (e.g., the total number of switch throws of the switch), an identification of the switch for which the switch event was generated, and/or other conditions associated with the switch event (e.g., weather, type of train cars in the cut, type of bearings of the cut, identification of the cut, etc.).

[0035] In embodiments, functionality of server 110 may provide for determining, based on switch events associated with a switch, a status of the switch. In embodiments, server 110 may include functionality for determining, based on switch events associated with a switch, a status of the switch by compiling data related to switch events associated with the switch, 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 by the switch during the switch event, to determine a status of the switch based on the thresholding analysis, and to generate a corrective action signal in response to the determination of the status of the switch. In 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 associated with the switch event for determining the status of the switch. In some embodiments, the thresholding analysis may include determining, for each switch event associated with the switch, a throw time difference between an expected throw time and the actual throw time (e.g., actual throw time-expected throw time), and analyzing the relationship of the throw time differences against thresholds to determine the status of the switch. In embodiments, a negative throw time difference may indicate that the actual throw time is faster than the expected throw time, and a positive throw time difference may indicate that the actual throw time is slower than the expected throw time. In some embodiments, the thresholding analysis may include determining, for each switch event associated with a switch, utilization metrics, and analyzing the relationship of the utilization metrics against thresholds to determine the status of the retarder.

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

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

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

[0039] As noted above, in typical operations of a classification yard, 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. 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 of the classification yard. 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 the classification yard. For example, classification yard may implement switches, detectors, and retarders, among other components. In embodiments, the cooperative operation of the various components of the classification yard may enable the classification yard to ensure that various cuts traverse the marshalling tracks and arrive at the destination coupling point at the appropriate coupling speed.

[0040] Switches 140 may include one or more switches configured to route a cut to a target track. As switch may be actuated via a switch throw signal that may throw the switch from a first position to a second position (e.g., from a right position in which a first track corresponding to the right position is selected to a left position in which a second track corresponding to the left position is selected, or from a left position in which the second track corresponding to the left position is selected to a right position in which the first track corresponding to the right position is selected). For example, a cut may be traveling along a current track and may come upon the switch. The switch may be configured to route the cut from the current track to a target track according to the route of the cut, which in this case may be scheduled to travel through the second track. The switch may be currently positioned to the right (e.g., which may correspond to the first track). In this case, if the switch is not thrown to the left, the cut may be misrouted from the current track to the first track. In this case, however, a switch throw signal is used to throw the switch from the right position to the left position. After the switch is thrown to the left, the switch may route the cut to the second track. In this manner, the classification yard may control the route of the cut using switches 140 to ensure the cut moves through the appropriate route.

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

[0042] Data collector 150 may be configured to capture and store (e.g., in a database, such as database 124) switch event data related to switch events associated with switches 140. For example, during operations of the classification yard, switches 140 may be actuated (e.g., via switch throw signals) to throw the switches from a first position to a second position in order to route various cuts along respective routes. In embodiments, data collector 150 may operate to generate and collect switch events for each actuation of a switch. In embodiments, a switch event may include real-world switch event data associated with the switch event including an actual throw time (e.g., the actual time taken to throw the switch from the first position to the second position), expected throw time (e.g., the time expected to take to throw the switch from the first position to the second position), a time of the switch throw request, a direction of the switch throw requested (e.g., from left to right, from right to left), switch throw failure data (e.g., including whether the switch event resulted in a switch throw failure, such as a kickback event, a no movement event, a lost position event, etc.), switch throw failure (e.g., a kickback count, a no movement count, a lost position count, etc.), a switch throw count associated with the switch (e.g., the total number of switch throws of the switch), an identification of the switch for which the switch event was generated, and/or other conditions associated with the switch event (e.g., weather, type of train cars in the cut, type of bearings of the cut, identification of the cut, etc.). In embodiments, data collector 150 may store the switch events associated with each of switches 140 into a database (e.g., database 124) for subsequent analysis.

[0043] 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 status of switches, 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 switch status determination operations to an operator. In embodiments, the results of switch status determination operations may be presented to an operator via the GIU of user terminal 130.

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

[0045] Server 110 may be configured to facilitate operations for determining a status of switch 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 switch 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.

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

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

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

[0049] 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 switch 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.

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

[0051] Data compiler 121 may be configured to retrieve data related to switch events associated with a switch, 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 switch event data to an operator.

[0052] 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 switch events and leverage the switch event data to determine a status of a switch or switches. For example, in embodiments, data compiler 121 may be configured to retrieve and compile the switch event data by configuring and scheduling one or more analysis jobs that include configuration associated with the analysis job itself as well as the switch event data against which thresholding analysis is to be performed.

[0053] In embodiments, configuring an analysis job may include specifying values for various parameters defining characteristics of the job as well as characteristics of the switch events to be included in the thresholding analysis. In a sense, the configuration of an analysis job may serve to filter switch events in the database so that data compiler 121 may compile those switch events that meet the configuration (e.g., pass the filters). The resulting set of switch events may be used in the thresholding analysis (e.g., performed by thresholding analysis manager 122) to determine a status of one or more switches. 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 switch events), etc. In embodiments, the various parameters defining characteristics of the switch events to be included in the analysis may include parameters for specifying a switch which switch events are to be compiled (e.g., an identification of the switch), a minimum switch event count (e.g., a minimum number of switch throws, etc.), a type of precipitation associated with the switch events, such as the precipitation status when the switch event was recorded (e.g., dry, wet, rain, snow, rust, all), a maximum temperature at the time of the switch event, a minimum temperature at the time of the switch event, an indication of a time period that each task performing the analysis job may be available after completion, etc.

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

[0055] 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 switch 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 switch 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 switch events as available with respect to the second task. In this manner, as switch 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 switch 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 switches in the classification yard. This functionality may allow data retriever and compiler 121 to ensure that the analysis job for switch 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 switch event data, which may facilitate a diverse thresholding analysis of the data.

[0056] 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., switch status determination results) of the analysis jobs, such as for presentation to an operator for verification, confirmation, and/or corrective actions to address switch status results.

[0057] In embodiments, analysis jobs may include configuration that may enable switch event data to be classified based on various factors. For example, a particular switch 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 switch events that occur during cold weather), a warm bucket (e.g., that may be used to classify switch events that occur during warm weather), a hot bucket (e.g., that may be used to classify switch events that occur during hot weather), a wet bucket (e.g., that may be used to classify switch events that occur during wet weather), a snow bucket (e.g., that may be used to classify switch events that occur during snowy weather), a rain bucket (e.g., that may be used to classify switch events that occur during rainy weather), a dry bucket (e.g., that may be used to classify switch events that occur during dry weather), a resilience type bucket (e.g., that may be used to classify switch 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 switch 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 switch events.

[0058] 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 switches using switch 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 switches 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 switches may be known to operate inefficiently in cold weather, as compared with the efficiency of the switches 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 switch status (e.g., a good switch may be labeled as bad during cold weather if the thresholding analysis does not take into account the cold weather conditions).

[0059] 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 compiler 121 may operate to compile a set of switch events for thresholding analysis that includes switch 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 switch events for thresholding analysis that includes switch events that occur during dry weather, such as switch 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 switch events for thresholding analysis that includes switch events that occur during dry and cold weather, such as switch 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 switch events for thresholding analysis that includes switch events in which each cut generating each of the switch 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.

[0060] In some embodiments, current or recent switch event data may include switch 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 switch event data in the database may include mostly, if not exclusively, cold weather switch events (e.g., switch 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 switch events, which may result in switch 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).

[0061] Following the example above, if and when the weather changes to warmer conditions, a next switch event (or a series of next switch events) may be warm switch events. In this case, it may be desirable to ensure that the thresholding analysis for determining a status of switches may be tailored to the new warmer prevailing condition. However, as most of the previous switch events may include cold weather switch events, due the previously prevailing cold weather conditions, tuning the thresholding analysis for determining a status of switches 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 switch 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 switch events that includes switch events associated with the main data bucket. However, if no switch events associated with the main data bucket exist in the database, or if less than a threshold number of switch events associated with the main data bucket exist in the database, data retriever and compiler 121 may operate to include switch 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 switch events. In this case, the warm bucket analysis job still may be executed, but against a set of switch events that may include cold weather switch events. The results of the analysis job may be used to automatically tune the thresholding analysis for determining a status of switches. 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 switches functionality of embodiments, even when the switch event data may not be perfectly fit to the current prevailing conditions.

[0062] In embodiments, data compiler 121 may be configured to provide the compiled set of switch events for a particular analysis job to thresholding analysis manager 122. In embodiments, each switch event may be associated with a switch, and may represent an event in which a switch is thrown, or signaled to be thrown, from a first position (e.g., right or left) to a second position (e.g., right or left).

[0063] In embodiments, a flag may be provided in configuration for a switch that may be used to specify the status of the switch. For example, the flag may be used to indicate a good status for the switch indicating that the status of the switch is good, which may indicate that the switch is able to perform operations for routing a cut to a target track with an acceptable level of performance, a bad status for the switch indicating that the status of the switch is bad, which may indicate that the switch is not able to perform operations for routing a cut to a target track with an acceptable level of performance and may be fully or close to fully degraded, and/or a warning status or section warning status indicating that the status of the switch is cautionary, and may indicate that although the switch is able to perform operations for routing a cut to a target track with an acceptable level of performance, the performance of the switch has degraded significantly and may be close to failing.

[0064] In embodiments, data compiler 121 may be configured to filter switch events to be compiled based on the status flag of a switch. For example, data compiler 121 may determine whether the status flag of a switch has been reset from a bad switch or section warning status to a good switch status. In response to a determination that the status flag of a switch has been reset from a bad switch or section warning status to a good switch status, data compiler 121 may filter out any switch events that occurred (e.g., with a timestamp) before the status flag of the switch was reset from the compiled set of switch events to be provided to thresholding analysis manager 122. In this manner, the compiled set of switch events to be provided to thresholding analysis manager 122 may include switch events for switches occurring from the time the status flag of the switch 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 switch determined to have a bad switch or section warning. After the corrective action, however, further thresholding analysis may be performed against the switch. In the case where the further thresholding analysis is performed on switch events including the previous switch events, the analysis may be biased toward a bad status finding. By resetting the set of switch events that are considered in the determination of the status of a switch to include only switch events after corrective action was taken on the switch, status results may be more reliable. In addition, resetting the set of switch events that are considered in the determination of the status of a switch to include only switch events after corrective action was taken on the switch may allow system 100 to determine whether a finding of a bad status switch may be actually caused by the prediction scheme (e.g., the expected throw times), rather than an actual bad status of the switch. In this case, if a switch 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 switch is bad, but that the prediction scheme may be out of tune and not as accurate as should be.

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

[0066] In embodiments, data compiler 121 may be configured to calculate, based on the compiled set of switch events, utilization metrics for each switch event in the compiled set of switch events. In embodiments, the utilization metrics for a switch event may include data related to the usage of the switch with respect to the switch event. For example, utilization metrics may include metrics associated with switch throw counts, switch throw failures, etc. In embodiments, data compiler 121 may calculate utilization metrics for each switch event in the compiled set of switch events generating a set of utilization metrics. In embodiments, the set of utilization metrics may be stored in database 124 and/or may be provided to thresholding analysis manager 122.

[0067] In embodiments, data compiler 121 may be configured to generate a visual representation of the throw time and/or the set of utilization metrics associated with the compiled set of switch events, 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 throw times associated with the set of car events. In alternative or additional embodiments, data compiler 121 may be configured to generate a visual representation of the set of throw time 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 throw time differences against the deviation (e.g., between expected throw time and measured throw time) represented by a time difference from zero. In this case, a non-zero value for a throw time difference may represent a deviation from zero, with zero indicating that there is no throw time difference (e.g., the actual throw time and the expected throw time in the switch event are the same). In this example, a large deviation from zero may represent a switch event in which the switch was slow to switch to the requested position. On the other hand, a small deviation from zero, or a zero deviation, may represent a switch event in which the switch was fast to switch to the requested position.

[0068] In embodiments, the box-and-whisker graph may then be presented to the operator using a UI (e.g., via user terminal device 130). FIG. 2 shows an example of a box-and-whisker chart 200 generated for a set of switch throw times associated with a plurality of switches in accordance with embodiments of the present disclosure.

[0069] As seen in FIG. 2, data compiler 121 may generate a box-and-whisker entry for each switch represented in the compiled set of switch events. In this manner, data compiler 121 may aggregate the throw times in box-and-whisker chart 300 by switches. For example, box-and-whisker entry 220 may correspond to switch 212, while box-and-whisker entry 230 may correspond to switch 14. In box-and-whisker chart 200, a density of each group of data points may be represented with lines, while higher density groups of data points may be represented marked with boxes within those lines. In this example, each throw time value (e.g., each measured throw switch time for each switch event) is entered as a point in the appropriate box-and-whisker entry for the corresponding switch. For example, all throw times measured for all events associated with switch 212 may be entered as points in box-and-whisker entry 220. In this example, the throw times may range from approximately 775 milliseconds to approximately 900 milliseconds. In this same example, all throw times measured for all events associated with switch 214 may be entered as points in box-and-whisker entry 230, and may range from approximately 700 milliseconds to approximately 875 milliseconds. In this example, the spread of the throw times for switch 212 (e.g., approximately 125 millisecond spread) seems to be tighter than the spread of the exit speed differences for switch 212 (e.g., approximately 175 spread).

[0070] In embodiments, each box-and-whisker entry of box-and-whisker chart 200 may include an indication of the median value of the spread of each box-and-whisker entry. For example, for switch 212, the median value 222 of box-and-whisker entry 220 is approximately 875 milliseconds and, for switch 14, the median value 232 of box-and-whisker 30 3230 is approximately 800 milliseconds.

[0071] In some embodiments, an operator presented with box-and-whisker chart 200 may gain insight into the operational performance of the switches represented in box-and-whisker chart 200, and may even make maintenance decisions to ensure that corrective action is taken on switches that may not be operating efficiently.

[0072] With reference back to FIG. 1, thresholding analysis manager 122 may be configured to apply thresholding analysis to the compiled set of switch event data to determine a status of each switch represented in the compiled set of switch event data. In particular, thresholding analysis manager 122 may perform thresholding analysis using the set of throw time 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 the set of throw time differences and/or the set of utilization metrics and to determine the status of the switch indicated by the result of the application of the one or more rules. In some embodiments, the thresholding analysis may be performed based on the direction of the switch throw, such that a first thresholding analysis may focus on right to left switch throw events and a second thresholding analysis may focus on left to right switch throw events. In this manner, the status of a switch may be determined with respect to the direction of the throw.

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

[0074] In embodiments, a first time differential rule may include a rule that determines that the status of a switch is good when no more than a threshold percentage of measured throw times associated with the switch are outside of a plus or minus a time threshold difference from a predicted time. Put another way, the first time differential rule determines that the status of a switch is good when no more than a threshold percentage of throw time differences fall outside the range defined between + time threshold and time threshold. In embodiments, thresholding analysis manager 122 may apply this first time differential rule against the set of throw time differences to determine, for each switch, the percentage of throw time differences associated with each switch that are outside of the plus or minus time threshold. Thresholding analysis manager 122 may then compare the percentage of throw time differences associated with each switch that are outside the range defined between [+ time threshold and time threshold] with the threshold percentage. If, for a particular switch, the percentage of throw time differences associated with each switch that are outside the range defined between [+ time threshold and time threshold] is less than the threshold percentage, thresholding analysis manager 122 may determine that the particular switch has passed the first time differential rule. On the other hand, if, for the particular switch, the percentage of throw time differences associated with each switch that are outside the range defined between [+ time threshold and time threshold] is not less than the threshold percentage, thresholding analysis manager 122 may determine that the particular switch has failed the first time differential rule.

[0075] For example, a threshold percentage of 75%, a time threshold of 50 milliseconds, and an expected throw time of 800 milliseconds may be specified for an application of the first time differential rule. In this example, thresholding analysis manager 122 may determine, based on the set of throw time differences, for a first switch, the percentage of throw time differences associated with the first switch that are outside plus or minus 50 milliseconds. Thresholding analysis manager 122 may then compare the percentage of throw time differences associated with the first detector that are outside of outside plus or minus 50 milliseconds with the threshold percentage of 75%. In this example, if the percentage of throw time differences associated with the first detector that are outside plus or minus 50 milliseconds is less than 75%, thresholding analysis manager 122 may determine that the first detector passed the first time differential rule. However, if the percentage of throw time differences associated with the first detector that are outside plus or minus 50 milliseconds is not less than 75%, thresholding analysis manager 122 may determine that the first detector failed the first time differential rule. Thresholding analysis manager 122 may continue applying the first time differential rule to all detectors represented in the set of throw time differences.

[0076] In embodiments, thresholding analysis manager 122 may apply the first time differential rule to a switch with a parameter that ensures that the result of the application will be a percentage ratio between the percentage of throw time differences associated with the switch that are outside the range defined between [+ time threshold and time threshold] and the parameter, such that the switch may be considered as a bad switch 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 throw time differences associated with the switch that are outside the range defined between [+ time threshold and time threshold] is divided. For example, thresholding analysis manager 122 may calculate the percentage of throw time differences associated with the switch that are outside the range defined between [+ time threshold and time threshold] 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 throw time differences associated with the switch that are outside the range defined between [+ time threshold and time threshold] is above the threshold percentage. In embodiments, a switch 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 switch may not be flagged as a bad switch, the switch 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 switch. In this manner, thresholding analysis manager 122 may be configured to determine how close a switch may be to failing. In some embodiments a percentage ratio threshold may be used to determine to flag a switch as needing attention (e.g., a warning) even though the switch may not be flagged as a bad switch. In some embodiments, the percentage ratio threshold may be a value above 50% but less than 100%.

[0077] In embodiments, the second time differential rule may include a rule that determines that the status of a switch is good when an average of the throw times for the switch is not outside of a range defined by plus or minus an average threshold from an expected throw time. Put another way, the second time differential rule determines that the status of a switch is good when an average of the throw time differences associated with the switch is not outside of a range defined by plus or minus an average threshold. In embodiments, thresholding analysis manager 122 may apply this second time differential rule against the set of throw time differences to determine, for each switch, the average of the throw time differences associated with each switch. Thresholding analysis manager 122 may then compare the average of the throw time differences associated with each switch with the range defined by plus or minus the average threshold. If, for a particular switch, the average of the throw time differences associated with the particular switch is within the range defined by plus or minus the average threshold, thresholding analysis manager 122 may determine that the particular switch has passed the first time differential rule. On the other hand, if, for the particular switch, the average of the throw time differences associated with the particular switch is outside the range defined by plus or minus the average threshold, thresholding analysis manager 122 may determine that the particular switch has failed the second time differential rule.

[0078] For example, an average threshold of 50 milliseconds and an expected throw time of 800 milliseconds may be specified for an application of the second time differential rule. In this example, thresholding analysis manager 122 may determine the set of throw time differences for the set of compiled switch events associated with a switch by subtracting 800 milliseconds from each actual throw time measured for each switch event and including the throw time difference to the set of throw time differences. Thresholding analysis manager 122 may then determine, based on the set of throw time differences, for a first switch, the average of the throw time differences associated with the first switch. Thresholding analysis manager 122 may then compare the average of the throw time differences associated with each switch with the range defined by plus or minus the average threshold of 50 milliseconds (e.g., [50 milliseconds to 50 milliseconds]). In this example, if the average of the throw time differences associated with the first switch is between-50 milliseconds and 50 milliseconds, thresholding analysis manager 122 may determine that the first switch passed the second time differential rule. However, if the average of the throw time differences associated with the first switch is outside of 50 milliseconds to 50 milliseconds, thresholding analysis manager 122 may determine that the first switch failed the second time differential rule. Thresholding analysis manager 122 may continue applying the second time differential rule to all switches represented in the set of throw time differences.

[0079] In embodiments, thresholding analysis manager 122 may apply the second time differential rule to a switch with a parameter that ensures that the result of the application of the second time differential rule will be a percentage ratio, such that the switch may be considered as a bad switch by thresholding analysis manager 122 when the percentage ratio is at least 100%. In embodiments, a switch 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 switch may not be flagged as a bad switch, the switch may be flag as needing attention, as it may be close to becoming a bad switch. In this manner, thresholding analysis manager 122 may be configured to determine how close a switch may be to failing. In some embodiments a percentage ratio threshold may be used to deter-mine to flag a switch as needing attention (e.g., a warning) even though the switch may not be flagged as a bad switch. In some embodiments, the percentage ratio threshold may be a value above 70% but less than 100%.

[0080] In embodiments, a third time differential rule may include a rule that determines that the status of a switch is good when a defined middle percentage of the throw time values associated with the switch is 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 throw times 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 throw times associated with the switch, and may be defined as the range between the bottom 25% percentile and the top 75%. In embodiments, thresholding analysis manager 122 may apply this third time differential rule against the throw time values (e.g., the throw times of each of the compiled set of switch events) to determine, for each switch, the spread range of the defined middle percentage of throw times associated with each switch. For example, thresholding analysis manager 122 may determine, for each switch, the difference between the lowest throw time value in the throw time values within the defined middle percentage and the highest throw time value in the throw time values within the defined middle percentage to determine the spread range of the defined middle percentage of throw times associated with each switch. Thresholding analysis manager 122 may then compare the spread range of the defined middle percentage of throw times associated with each switch with the spread threshold. If, for a particular switch, the spread range of the defined middle percentage of throw times associated with each switch is less than the spread threshold, thresholding analysis manager 122 may determine that the particular switch has passed the third time differential rule. On the other hand, if, for the particular switch, the spread range of the defined middle percentage of throw times associated with each switch is not less than the spread threshold, thresholding analysis manager 122 may determine that the particular switch has failed the third time differential rule.

[0081] For example, a spread threshold of 150 milliseconds may be specified for the third time differential rule. In addition, a middle percentage that includes the bottom 25% percentile and the top 75% may be defined for the third time differential rule. In embodiments, thresholding analysis manager 122 may apply this third time differential rule against the throw times associated with each switch event associated with a first switch, and may identify throw times associated with the switch falling within the middle percentage of all the times associated with the switch. Analysis manager 122 may then determine a spread range of the throw times within the middle percentage. For example, thresholding analysis manager 122 may determine the difference between the lowest throw time value within the middle percentage and the highest throw time value within the defined middle percentage. Analysis manager 122 may determine the spread range of the middle percentage as the difference between the highest throw time value and the lowest throw time value. In this example, thresholding analysis manager 122 may compare the spread range of the middle percentage to the spread threshold of 150 milliseconds. In this example, if the spread range of the middle percentage is less than the spread threshold of 150 milliseconds, thresholding analysis manager 122 may determine that the first switch passed the third time differential rule. However, if the spread range of the middle percentage is not less than the spread threshold of 150 milliseconds, thresholding analysis manager 122 may determine that the first switch failed the third time differential rule. Thresholding analysis manager 122 may continue applying the third time differential rule to all switches represented in the compiled set of switch events.

[0082] In embodiments, thresholding analysis manager 122 may apply the third time differential rule to a switch with a parameter that ensures that the result of the application of the third time differential rule will be a percentage ratio, such that the switch may be considered as a bad switch by thresholding analysis manager 122 when the percentage ratio is at least 100%. In embodiments, a switch 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 switch may not be flagged as a bad switch, the switch may be flag as needing attention, as it may be close to becoming a bad switch. In this manner, thresholding analysis manager 122 may be configured to determine how close a switch may be to failing. In some embodiments a percentage ratio threshold may be used to determine to flag a switch as needing attention (e.g., a warning) even though the switch may not be flagged as a bad switch. In some embodiments, the percentage ratio threshold may be a value above 70% but less than 100%.

[0083] In embodiments, a fourth time differential rule may include a weighted combination of the first, second, and third time differential rules. In embodiments, thresholding analysis manager 122 may apply the fourth rule by combining the results of the first, second, and third time 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 time differential rules. For ex-ample, weighted factors of 3, 2, and 2.25 may be configured for the results of the first, second, and third time differential rules, respectively. In this example, thresholding analysis manager 122 may apply the respective weighted factor to each of the first, second, and third time 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 time differential rules may include raising each of the of the first, second, and third time 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 time differential rules may include a percentage value, the result of the combination rule (e.g., fourth time differential rule) may also be a percentage value.

[0084] In embodiments, thresholding analysis manager 122 may determine a status of a switch based on whether the switch failed or passed each of time differential rules. For example, if a switch failed any of the time differential rules, the status of the switch may be set as bad. On the other hand, if the switch passed all applied time differential rules, the status of the switch may be set as good. In particular embodiments, a switch may fail the fourth time differential rule (e.g., the combination rule) if the switch has failed any one of the individual rules in the combination.

[0085] In embodiments, a second set of rules that may be applied in the thresholding analysis may include utilization rules that may be applied to utilization metrics associated with a switch. The utilization rules may be applied to the set of utilization metrics generated by data compiler 121 and may be configured to determine the status of a switch based on the rule application.

[0086] In embodiments, a first utilization rule may include a kickback failure count rule that determines that the status of a switch is good when no more than a threshold percentage of throws associated with the switch indicate that the throw incurred a kickback event. In embodiments, thresholding analysis manager 122 may apply this first rule against the set of utilization metrics to determine, for each switch, the percentage of throws associated with each switch that incur a kickback event. Thresholding analysis manager 122 may then compare the percentage of throws associated with each switch that incurred kickback event with the threshold percentage. If, for a particular switch, the percentage of throws that incurred a kickback event is less than the threshold percentage, thresholding analysis manager 122 may determine that the particular switch has passed the kickback failure count rule. On the other hand, if, for the particular switch, the percentage of throws that incurred a kickback event is not less than the threshold percentage, thresholding analysis manager 122 may determine that the particular switch has failed the kickback failure count rule.

[0087] For example, a threshold percentage of 2.5% may be specified for an application of the kickback failure count rule. In this example, thresholding analysis manager 122 may determine, based on the set of throw event metrics, for a first switch, the percentage of throw event metrics associated with the first switch that indicate that a throw incurred a kickback event. Thresholding analysis manager 122 may then compare the percentage of throws that incurred kickback event with the threshold percentage of 2.5%. In this example, if the percentage of throws that incurred kickback event is less than 2.5%, thresholding analysis manager 122 may determine that the first switch passed the kickback failure count rule. However, if the percentage of throws that incurred kickback event is not less than 2.5%, thresholding analysis manager 122 may determine that the first switch failed the kickback failure count rule. Thresholding analysis manager 122 may continue applying the kickback failure count rule to all switches represented in the set of utilization metrics to determine whether each switch passes or fails the kickback failure count rule.

[0088] In embodiments, a second utilization rule may include a no-movement failure count rule that determines that the status of a switch is good when no more than a threshold percentage of throws associated with the switch indicate that the throw incurred a no movement event. In embodiments, thresholding analysis manager 122 may apply this second rule against the set of utilization metrics to determine, for each switch, the percentage of throws associated with each switch that incur a no-movement event. Thresholding analysis manager 122 may then compare the percentage of utilization metrics associated with each switch that indicate that a no-movement event was incurred with the threshold percentage. If, for a particular switch, the percentage of utilization metrics associated with the particular switch that indicate that the switch incurred a no-movement event is less than the threshold percentage, thresholding analysis manager 122 may determine that the particular switch has passed the no-movement failure count rule. On the other hand, if, for the particular switch, the percentage of utilization metrics associated with the particular switch that indicate that the switch incurred a no-movement event is not less than the threshold percentage, thresholding analysis manager 122 may determine that the particular switch has failed the no-movement failure count rule. Thresholding analysis manager 122 may continue applying the no-movement failure count rule to all switches represented in the set of utilization metrics to determine whether each switch passes or fails the no-movement failure count rule.

[0089] For example, a threshold percentage of 1.5% may be specified for an application of the no-movement failure count rule. In this example, thresholding analysis manager 122 may determine, based on the set of throw event metrics, for a first switch, the percentage of utilization metrics associated with the first switch that indicate that the first switch incurred a no-movement event. Thresholding analysis manager 122 may then compare the percentage of utilization metrics associated with the first switch that indicate that the first switch incurred a no-movement event with the threshold percentage of 1.5%. In this example, if the percentage of utilization metrics associated with the first switch that indicate that the first switch incurred a no-movement event is less than 1.5%, thresholding analysis manager 122 may determine that the first switch passed the no-movement failure count rule. However, if the percentage of utilization metrics associated with the first switch that indicate that the first switch incurred a no-movement event is not less than 1.5%, thresholding analysis manager 122 may determine that the first switch failed the no-movement failure count rule. Thresholding analysis manager 122 may continue applying the no-movement failure count rule to all switches represented in the set of utilization metrics to determine whether each switch passes or fails the no-movement failure count rule.

[0090] In embodiments, a third utilization rule may include a lost position failure count rule that determines that the status of a switch is good when no more than a threshold number of switch events in the utilization metrics indicate a lost position event. In embodiments, thresholding analysis manager 122 may apply this third utilization rule against the set of utilization metrics to determine, for each switch, the number of throw events in the utilization metrics that indicate a lost position event. Thresholding analysis manager 122 may then compare the number of throw events in the utilization metrics that indicate a lost position event with the threshold number. If, for a particular switch, the number of throw events in the utilization metrics that indicate a lost position event is less than the threshold number, thresholding analysis manager 122 may determine that the particular switch has passed the lost position failure count rule. On the other hand, if, for the particular switch, the number of throw events in the utilization metrics that indicate a lost position event is not less than the threshold number, thresholding analysis manager 122 may determine that the particular switch has failed the lost position failure count rule.

[0091] For example, a threshold number of 50 may be specified for an application of the lost position failure count rule. In this example, thresholding analysis manager 122 may determine, based on the set of throw event metrics, for a first switch, the number of throw events in the utilization metrics associated with the first switch that indicate a lost position event. Thresholding analysis manager 122 may then compare the number of throw events in the utilization metrics associated with the first switch that indicate a lost position event with the threshold number of 50. In this example, if the number of throw events in the utilization metrics associated with the first switch that indicate a lost position event is less than 50, thresholding analysis manager 122 may determine that the first switch passed the lost position failure count rule. However, if the number of throw events in the utilization metrics associated with the first switch that indicate a lost position event is not less than 50, thresholding analysis manager 122 may determine that the first switch failed the lost position failure count rule. Thresholding analysis manager 122 may continue applying the lost position failure count rule to all switches represented in the set of utilization metrics to determine whether each switch passes or fails the lost position failure count rule.

[0092] In embodiments, a fourth utilization rule may include a throw count rule that determines that the status of a switch is good when a throw count associated with the switch indicates that the switch has not exceeded more than a threshold number of switch throws. In embodiments, this throw count rule may be applied against left throw counts (e.g., switch throws to change position from right to left), right throw counts (e.g., switch throws to change position from left to right), or a combination of right and left throw counts. In this manner, thresholding analysis manager 122 may be configured to determine the status of a switch using the throw count rule based on the number of right throws performed by the switch, the number of left throws performed by the switch, and/or the number of right and left throws combined performed by the switch. In embodiments, thresholding analysis manager 122 may apply this throw count rule against the set of utilization metrics to determine, for each switch, at total throw count indicating the number of throws that have been performed by each switch. Thresholding analysis manager 122 may then compare the total throw count for each switch with the threshold number. If, for a particular switch, the total throw count is less than the threshold number, thresholding analysis manager 122 may determine that the particular switch has passed the throw count rule. On the other hand, if, for the particular switch, the total throw count is not less than the threshold number, thresholding analysis manager 122 may determine that the particular switch has failed the throw count rule.

[0093] For example, a threshold number of 5000 (left and right throws) may be specified for an application of the throw count rule. In this example, thresholding analysis manager 122 may determine, based on the set of throw event metrics, for a first switch, a total throw count associated with the first switch, which may indicate the number of throws (e.g., left and right throws in combination) that have been performed by the first switch. Thresholding analysis manager 122 may then compare the total throw count associated with the first switch with the threshold number of 50. In this example, if the total throw count associated with the first switch is less than 5000, thresholding analysis manager 122 may determine that the first switch passed the throw count rule. However, if the total throw count associated with the first switch is not less than 5000, thresholding analysis manager 122 may determine that the first switch failed the throw count rule. Thresholding analysis manager 122 may continue applying the throw count rule to all switches represented in the set of utilization metrics to determine whether each switch passes or fails the throw count rule.

[0094] In embodiments, thresholding analysis manager 122 may determine a status of a switch based on whether the switch failed or passed each of the utilization rules. For example, if a switch failed any of the utilization rules, the status of the switch may be set as bad. On the other hand, if the switch passed all applied utilization rules, the status of the switch may be set as good.

[0095] In some embodiments, the status of the switch may include one of a plurality of status indicators. The status indicators in the plurality of status indicators may include status indicators of varying severity. In embodiments, a first status indicator may include an indication that a switch is operating as expected and may include a good switch indication. A second status indicator may include an indication that a switch is not able to meet an expected throw time and may include a bad switch indication. This bad switch indication may be used to cause a corrective action on the switch. A third status indicator may include a warning status indication indicating that, although a switch may be able to meet an expected throw time, the switch is degraded (e.g., due to the switch having been thrown in excess of a number threshold, due to presence of failure switch events, etc.). In these cases, even if the switch may perform a requested operation, the performance of the switch is not efficient and/or it may be determined that the switch may be in danger of failing soon. In embodiments, other status indications may be used, and as such, the present description of three status indicators should not be construed as limiting in any way.

[0096] 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 switches. 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 switch, 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 switch is bad, send a control signal to the deactivate the switch in order to avoid potential damage.

[0097] 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 switches 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 switch. For example, in some embodiments, an operator may reset a status indicator flag of a switch (e.g., after corrective action has been taken on the switch) from a bad switch or a section warning status indicator to a good switch status indicator. In these cases, the configuration of the corresponding switch may include an indication that the status flag for the switch has been reset. In embodiments, switch events associated with the switch 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 switch may only include switch events after the status flag reset. The same process of removing switch events associated with a switch occurring prior to a status flag reset for the switch may be performed every time the status flag for the switch is reset. However, in embodiments, results manager 123 may determine that the status flag of a switch found in a current thresholding analysis iteration to be a bad switch 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 switch 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 switch being found to be a bad switch) may be another device (e.g., a detector used to collect speed information associated with a switch event) or the prediction scheme used to determine the expected throw times at the switch.

[0098] FIG. 3 illustrates an example of a UI presented to an operator to provide a status report associated with one or more switches in accordance with aspects of the present disclosure. As can be seen in FIG. 3, UI 300 may be presented to an operator (e.g., via user terminal 130). In embodiments, UI 300 may include various graphical elements providing input/output functionality so that the operator may be presented with the results of the switch status determination.

[0099] In embodiments, UI 300 may include a section 312 for including an indication of the number of switch failures (e.g., the number of switches whose status was determined as bad by thresholding analysis 122, such a due to a failure of one or more rules applied against switch events associated with the switch) included in the report. In this example, 5 switches were found to be bad. UI 300 may also include a section 310 for including an indication of the number of switches that were found to be degraded and were flagged with a warning indication (e.g., e.g., the number of switches whose status was determined as degraded by thresholding analysis 122, such a due to results of one or more rules applied against switch events associated with the switch) included in the report.

[0100] As illustrated in FIG. 3, the switch status report may identify several switches as bad. In this case, an indication (e.g., a bad status indicator represented in this example as a first color highlighting) may be included to identify bad switches. For example, switch 316 was found as bad. As can be seen, the result of a combination throw time differential rule for switch 316 was found to be over 100%. In this case, switch 316 was determined to be bad and flagged as bad switch in the status report. On the other hand, switch 315 was found to have passed all rules and in this case, switch 315 was flagged as a good switch.

[0101] The switch status report in FIG. 3 may also show that the results of the kickback failure count rule applied against switch 322 may indicate that a percentage of the right throw events for switch 322 exceeding a threshold percentage incurred a kickback event. As a result, the status of switch 322 was flagged as a bad switch. In this case, the bad switch indication included an indication that the failure was due to right throw events.

[0102] The switch status report identifies several switches as degraded, but not bad. In this case, an indication (e.g., a warning indicator represented in this example as a second color highlighting) to identify degraded but not bad switches. For example, the result of a combination throw time differential rule for switch 318 were found to be over a threshold percentage (e.g., a value above 50%) but less than 1005. As such, switch 318 was identified as a degraded switch and flagged with a warning status indicator. In this example, the results of the throw count rule against switch 320 may indicate that, although the total throw count associated with switch 320 has not exceed a total throw count threshold, the total throw count associated with switch 320 is within a threshold percentage or a threshold number of the total throw count threshold. In this case, switch 320 may be flagged with a warning status indication.

[0103] switch 318 was found as bad. As can be seen, the result of a combination throw time differential rule for switch 316 was found to be over 100%. In this case, switch 316 was determined to be bad and flagged as bad switch in the status report. On the other hand

[0104] In this example, the combination rule was applied against switch 416, and the result was 86%, not greater than 100%, indicating that although switch 414 is not bad, it is degraded and may be close to becoming a bad switch. In this example, the combination rule was applied against switch 418, and the result of the switch was 80%, indicating that the detector is good. However, the results of the utilization per energy change analysis on switch 418 also indicate that at least one section of switch 418 (e.g., the second section) may be closed to being outside acceptable parameters. In this example, even though the second section of switch may not have failed, it may be closed to failing.

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

[0106] At block 402, a plurality of switch events associated with a switch in a classification yard is compiled. In embodiments, each switch event may represent a request to throw the switch device from a first position to a second position, and each car event may include real-world metrics including actual measurements associated with the switch device during each switch event of the plurality of switch events, utilization metrics including measurements associated with a usage of the switch device, and/or failure metrics including indications of failure events incurred during one or more switch events of the plurality of switch events. In embodiment, functionality of a data compiler (e.g., data compiler 121 in FIG. 1) may be used to compile a plurality of switch events associated with a switch in a classification yard. In embodiments, the data compiler may perform operations to compile a plurality of switch events associated with a switch in a classification yard according to operations and functionality as described above with reference to data compiler 121 and as illustrated in FIGS. 1-3.

[0107] At block 404, a set of deviation metrics associated with the switch device is generated based on the plurality of switch events associated with the switch 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 switch device based on the plurality of switch events associated with the switch device. In embodiments, the data compiler may perform operations to generate the set of deviation metrics associated with the switch device based on the plurality of switch events associated with the switch device according to operations and functionality as described above with reference to data compiler 121 and as illustrated in FIGS. 1-3.

[0108] At block 406, thresholding analysis is applied to the set of deviation metrics associated with the switch device to determine a status of the switch 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 switch device to determine a status of the switch device. In embodiments, the threshold analysis manager may perform operations to apply thresholding analysis to the set of deviation metrics associated with the switch device to determine a status of the switch device according to operations and functionality as described above with reference to threshold analysis manager 122 and as illustrated in FIGS. 1-3.

[0109] At block 508, a corrective action signal including an indication of the status of the switch device and/or a corrective action to be taken for the switch 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 switch device and/or a corrective action to be taken for the switch device. In embodiments, the results manager may perform operations to generate a corrective action signal including an indication of the status of the switch device and/or a corrective action to be taken for the switch device according to operations and functionality as described above with reference to results manager 123 and as illustrated in FIGS. 1-3.

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

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

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

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

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

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

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

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