Patent Description:
In current railroad infrastructure, wheel impact load detection systems are commonly installed to notify railroad personnel of potential defects in wheels of vehicles that travel on railroad tracks. Generally speaking, wheel impact load detection systems include strain gauges coupled to the rails that are operable to measure the strain or stress applied to the rail. As a train or other vehicle travels over the portion of the rail to which the strain gauges are attached, the strain gauges can measure the increase in strain caused by the vehicle. This increase in strain can correlate to a measurement of force exerted by the vehicle's wheel(s) on the rail. Strain gauges are often spread over a sufficient length of rail to allow for the gathering of force measurements corresponding to the entire circumference of a given wheel, as opposed to just a particular section.

Railroad vehicles are carefully loaded to ensure that the total weight of the vehicle and cargo combined does not exceed weight limits of track and vehicle infrastructure, and if there are no defects in vehicle wheels or the rails on which they travel, strain gauge measurements will generally reflect that trains traveling on the rails are exerting tolerable forces on the rails. However, if a wheel has a defect (e.g., a flat caused by sliding or mechanical shelling, etc.), this can cause increased force to be applied by the vehicle to the track via the defective wheel. These forces can be measured by strain gauges and ultimately detected by the overarching wheel impact load detection system, which can then alert railroad personnel to the potential defects.

Because of the need to keep trains moving to satisfy schedules and delivery timelines, railroad systems will often prioritize alerts that correspond to many potential issues, including detected wheel impact loads indicating wheel defects. Some alerts can indicate a serious problem and require a vehicle to be immediately stopped and inspected; some alerts can indicate that an inspection can wait until the train is next serviced. With respect to wheel impact load detection, such prioritization is generally dependent on the amount of force detected by the strain gauges-the higher the force, the more serious the alert, and the higher priority it is given. As an example of this prioritization, the American Association of Railroads (AAR) promulgates different levels of concern corresponding to different detected force values in wheel impact load detection, which are often measured in "kips," or thousands of pounds. The AAR considers a wheel to be "condemnable" (i.e., can be condemned by the railroad) if a wheel's kip value is greater than <NUM>. In addition to guidelines from the AAR, railroads will often maintain their own internal priority systems for condemnable wheels to assist them in managing the sheer volume of alerts that may be generated on any given day. However, the time constraints inherent in railroad operation mean that incorrect prioritization can be devastating to efficiency and productivity of railroad operation. Therefore, ensuring proper prioritization of alerts is key for successful and reliable implementation of a wheel impact load detection system. <CIT> describes a flat wheel detector. <CIT> discloses a device for evaluating the technical condition of the tread of moving railway vehicles. <NPL>, describes a wheel defect detection methodology.

The present disclosure achieves technical advantages as a system and method for wheel impact load detection (WILD) that can prioritize alerts by accounting for environmental conditions. The system can account for the variability in rail tension caused by environmental conditions (e.g., temperature, pressure, humidity, etc.) when assigning severity levels to alerts. The system can receive data that can be indicative of force exerted by a vehicle on a track, calibrate the received data to account for the environmental conditions, utilize the calibrated data in assigning a severity level that dictates prioritization in a railroad system, and then generate an alert with the assigned severity level.

The present disclosure solves the technological problem of providing a wheel impact load detection system configured to account for environmental conditions in prioritizing generated alerts. The present disclosure can calculate values from received data, calibrating relevant values using received data, deciding when to use original data or calibrated data, and comparing original or calibrated values (as appropriate) to predetermined thresholds to facilitate proper prioritization. Such specialized processing can also provide the benefit of increasing railroad system operational efficiency by mitigating incorrectly prioritized alerts that can be caused by, for example, increased rail tension due to linear shrinkage of rails in cold weather.

The present disclosure improves the performance and functionality of the system itself by implementing specialized algorithms adapted to data related to environmental conditions proximate a sensor (e.g., strain gauge, load cell, accelerometer, etc.). The system can assign severity levels related to received WILD sensor data in light of environmental conditions related to received environmental data. In contrast, traditional systems simply rely on often-incomplete data and assume uniform conditions without adjusting values based upon feedback values to account for, e.g., variable rail tension and/or linear shrinkage/expansion, resulting in improperly prioritized alerts that can diminish operational efficiency and often lead to the disastrous stoppage of generally healthy railroad vehicles. In certain embodiments, the disclosed WILD system not only determines when data needs to be calibrated but can also determine if the calibration should change the severity level of the alert.

The disclosed WILD system can include a server in operable communication with a database, clients, and a weather station. The WILD system can further be in operable connection with a plurality of sensors or gauges designed to measure a force or forces exerted by a vehicle on a track. The WILD system can generate records containing relevant data, including vehicle identity, time and date of detection, the direction the vehicle is travelling when detected, the determined weight of the vehicle, the determined maximum force applied by the vehicle to the track, the proportion of the maximum force that can be attributed to a wheel defect, and the environmental conditions at the time of detection.

It is an object of the disclosure to provide a system for wheel impact load detection and alert generation. It is a further object of the disclosure to provide a method for generating prioritized alerts related to wheel impact load detection. These and other objects are provided by at least the following embodiments.

In one embodiment, a system for generating railroad alerts related to wheel impact load detection sensor data can include: a memory having a first database with a plurality of sensor data, thresholds, and specifications related to a vehicle and at least a portion of a track; and a networked computer processor operably coupled to the memory and capable of executing machine-readable instructions to perform program steps, the program steps including:.

In another embodiment, a method of compensating for environmental conditions in wheel impact load detection can include the steps of: detecting a vehicle on a track; generating, via one or more processors, at least one record including a date, a time, a direction of the vehicle, and an Axle count of the vehicle; receiving environmental data related to an environmental condition; receiving sensor data from at least one strain gauge coupled to the track; determining an original max force value from the sensor data; comparing the original max force value with a first force threshold; if the environmental data satisfies an environmental threshold, wherein the environmental threshold is related to an environmental condition that can affect wheel impact load detection, generating, via the one or more processors, a calibrated max force value by calibrating the original max force value with an operational variable; if the original max force value exceeds the first force threshold, and if the calibrated max force value was not generated, utilizing the original max force value to assign a first severity level; if the original max force value exceeds the first force threshold, and if the calibrated max force value was generated, utilizing the calibrated max force value to assign a second severity level; generating an alert including either the first or second severity level; and updating the at least one record; wherein if the original max force value is below the first force threshold, the at least one record is updated without generating an alert. Wherein the environmental data includes temperature, and the environmental threshold is a temperature threshold. Further including the step of determining a confidence level in an accuracy of the sensor data. Wherein the confidence level is utilized with the original max force value to assign the first severity level. Wherein the confidence level is utilized with the calibrated max force value to assign the second severity level.

In another embodiment, a method of compensating for variable rail tension caused by environmental conditions in wheel impact load detection can include the steps of: detecting a vehicle on a track; receiving environmental data related to an environmental condition; receiving sensor data from at least one strain gauge coupled to the track; determining, via one or more processors, a max force value from the sensor data; if the max force value exceeds a first force threshold, determining if the environmental data satisfies an environmental threshold, wherein the environmental threshold is related to an environmental condition that can affect wheel impact load detection; if the max force value exceeds the first force threshold, and if the environmental data satisfies the environmental threshold, assigning a first severity level; and if the max force value exceeds the first force threshold, and if the environmental data does not satisfy the environmental threshold, assigning a second severity level; and generating an alert including the first or second severity level; wherein if the max force value is below the first force threshold, no alert is generated. Further including the step of utilizing a confidence level in assigning the first or second severity level. Wherein if the environmental threshold is satisfied, the confidence level is reduced. Wherein the environmental threshold is satisfied when a temperature is equal to or below <NUM>. Further including the step of updating a record to indicate that the alert includes the first or second severity level.

The present disclosure will be readily understood by the following detailed description, taken in conjunction with the accompanying drawings that illustrate, by way of example, the principles of the present disclosure. The drawings illustrate the design and utility of one or more exemplary embodiments of the present disclosure, in which like elements are referred to by like reference numbers or symbols. The objects and elements in the drawings are not necessarily drawn to scale, proportion, or precise positional relationship. Instead, emphasis is focused on illustrating the principles of the present disclosure.

The preferred version of 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, which follows. Descriptions of well-known components have been omitted so 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.

<FIG> illustrates a schematic view of a wheel impact load detection (WILD) system <NUM> in accordance with one or more embodiments of the present disclosure. The system <NUM> can include one or more servers <NUM> operably coupled to a database <NUM>. The server <NUM> can be operably coupled to one or more clients <NUM>, <NUM>, <NUM>, <NUM> via a network connection <NUM>. The clients can be a physical device (e.g., mobile phone <NUM>, computer <NUM>, <NUM>, tablet <NUM>, wearable device, or other suitable device), program, or an application. In another embodiment, the server <NUM> can be operable coupled to weather station <NUM> via the network <NUM>. For example, the weather station <NUM> can be a collection of weather-related sensors, such as thermometers, barometers, gauges, or any other suitable sensors for collection environmental data. In another example, the weather station <NUM> can be a networked computer <NUM> in operable connection with the server <NUM> that is capable of receiving and/or obtaining environmental data and transmitting the environmental data to the server <NUM>. The WILD system <NUM> can be integrated with a railroad system or railroad infrastructure to facilitate the detection of defects in railroad components. It will be understood by those having skill in the art that detections, captured data, measurements, determinations, alerts, etc. encompassed by the WILD system <NUM> can be promulgated and/or accessible to a railroad system at large via the network <NUM> or other operable connection. In one embodiment, the server <NUM> can include machine-readable instructions <NUM>; in another embodiment, the server <NUM> can access machine readable instructions <NUM>. In another embodiment, the machine-readable instructions can include instructions related to a vehicle detection module <NUM>, an environmental data capture module <NUM>, a geopositioning module <NUM>, a vehicle data capture module <NUM>, a force determination module <NUM>, a force calibration module <NUM>, an alert generation module <NUM>, and/or an alert delivery module <NUM>.

The aforementioned system components (e.g., server(s) <NUM>, weather station <NUM>, and client(s) <NUM>, <NUM>, <NUM>, <NUM>, etc.) can be communicably coupled to each other via the network <NUM>, such that data can be transmitted. The network <NUM> can be the Internet, intranet, or other suitable network. The data transmission can be encrypted, unencrypted, over a VPN tunnel, or other suitable communication means. The network <NUM> can be a WAN, LAN, PAN, or other suitable network type. The network communication between the clients, server <NUM>, or any other system component can be encrypted using PGP, Blowfish, Twofish, AES, 3DES, HTTPS, or other suitable encryption. The system <NUM> can be configured to provide communication via the various systems, components, and modules disclosed herein via an application programming interface (API), PCI, PCI-Express, ANSI-X12, Ethernet, Wi-Fi, Bluetooth, or other suitable communication protocol or medium. Additionally, third party systems and databases can be operably coupled to the system components via the network <NUM>.

The data transmitted to and from the components of system <NUM> (e.g., the server <NUM>, weather station <NUM>, and clients), can include any format, including JavaScript Object Notation (JSON), TCP/IP, XML, HTML, ASCII, SMS, CSV, representational state transfer (REST), or other suitable format. The data transmission can include a message, flag, header, header properties, metadata, and/or a body, or be encapsulated and packetized by any suitable format having same.

One or more server(s) <NUM> can be implemented in hardware, software, or a suitable combination of hardware and software therefor, and may comprise one or more software systems operating on one or more servers, having one or more processors <NUM>, with access to memory <NUM>. Server(s) <NUM> can include electronic storage, one or more processors, and/or other components. Server(s) <NUM> can include communication lines, connections, and/or ports to enable the exchange of information via a network <NUM> and/or other computing platforms. Server(s) <NUM> can also include a plurality of hardware, software, and/or firmware components operating together to provide the functionality attributed herein to server(s) <NUM>. For example, server(s) <NUM> can be implemented by a cloud of computing platforms operating together as server(s) <NUM>, including Software-as-a-Service (SaaS) and Platform-as-a-Service (PaaS) functionality. Additionally, the server(s) <NUM> can include memory <NUM> internally.

Memory <NUM> can comprise electronic storage that can include non-transitory storage media that electronically stores information. The electronic storage media of electronic storage can include one or both of system storage that can be provided integrally (e.g., substantially non-removable) with server(s) <NUM> and/or removable storage that can be removably connectable to server(s) <NUM> via, for example, a port (e.g., a USB port, a firewire port, etc.) or a drive (e.g., a drive, etc.). Electronic storage may include one or more of optically readable storage media (e.g., optical disks, etc.), magnetically readable storage media (e.g., magnetic tape, magnetic hard drive, floppy drive, etc.), electrical charge-based storage media (e.g., EEPROM, RAM, etc.), solid- state storage media (e.g., flash drive, etc.), and/or other electronically readable storage media. Electronic storage may include one or more virtual storage resources (e.g., cloud storage, a virtual private network, and/or other virtual storage resources). The electronic storage can include a database, or public or private distributed ledger (e.g., blockchain). Electronic storage can store machine-readable instructions <NUM>, software algorithms, control logic, data generated by processor(s), data received from server(s), data received from computing platform(s), and/or other data that can enable server(s) to function as described herein. The electronic storage can also include third-party databases accessible via the network <NUM>.

Processor(s) <NUM> can be configured to provide data processing capabilities in server(s) <NUM>. As such, processor(s) <NUM> can include one or more of a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and/or other mechanisms for electronically processing information, such as FPGAs or ASICs. The processor(s) <NUM> can be a single entity or include a plurality of processing units. These processing units can be physically located within the same device, or processor(s) <NUM> can represent processing functionality of a plurality of devices or software functionality operating alone, or in concert.

The processor(s) <NUM> can be configured to execute machine-readable instructions <NUM> or machine learning modules via software, hardware, firmware, some combination of software, hardware, and/or firmware, and/or other mechanisms for configuring processing capabilities on processor(s) <NUM>. As used herein, the term "machine-readable instructions" can refer to any component or set of components that perform the functionality attributed to the machine-readable instructions component <NUM>. This can include one or more physical processors <NUM> during execution of processor-readable instructions, the processor-readable instructions, circuitry, hardware, storage media, or any other components.

The server(s) <NUM> can be configured with machine-readable instructions <NUM> having one or more functional modules. The machine-readable instructions <NUM> can be implemented on one or more servers <NUM>, having one or more processors <NUM>, with access to memory <NUM>. The machine-readable instructions <NUM> can be a single networked node, or a machine cluster, which can include a distributed architecture of a plurality of networked nodes. The machine-readable instructions <NUM> can include control logic for implementing various functionality, as described in more detail below. The machine-readable instructions <NUM> can include certain functionality associated with the WILD system <NUM>. Additionally, the machine-readable instructions <NUM> can include a smart contract or multi-signature contract that can process, read, and write data to a database, distributed ledger, or blockchain.

<FIG> illustrates a schematic view of a wheel impact load detection system <NUM>, in accordance with one or more exemplary embodiments of the present disclosure. WILD system <NUM> can include a WILD data capture system <NUM>, a WILD calibration system <NUM>, and an alert management system <NUM>. In one exemplary embodiment, the WILD data capture system <NUM> can include a vehicle detection module <NUM>, an environmental data capture module <NUM>, a geopositioning module <NUM>, and a vehicle data capture module <NUM>. The vehicle detection module <NUM>, environmental data capture module <NUM>, geopositioning module <NUM>, and vehicle data capture module <NUM> can implement one or more algorithms to facilitate data capture related to wheel impact load detection, including recognition, location-retrieving, and detection algorithms. In one embodiment, the WILD data capture system <NUM> can be configured to initiate upon detection of a vehicle on a track and subsequently capture a myriad of data related to the vehicle, the track, and the environment.

In one embodiment, the vehicle detection module <NUM> can detect a vehicle (e.g., a train or other rail-traveling vehicle) on at least a portion of a track. For example, the WILD data capture system <NUM> can be in operable communication with strain gauges, cameras, LIDAR, radar, or any other device or mechanism suitable to detect movement (and/or position) on a track, and the vehicle detection module <NUM> can be configured to receive data from these components and determine if a vehicle is present. In another embodiment, the environmental data capture module <NUM> can be configured to receive and/or obtain environmental data (e.g., data related to environmental conditions). For example, the WILD data capture system <NUM> can be in operable connection with a weather station <NUM> that can collect, store, and make available data related to, weather conditions, such as temperature, precipitation, pressure, and humidity, among others. In one example, detection of a vehicle by the vehicle detection module <NUM> can initiate the environmental data capture module <NUM>, such that the environmental data capture module <NUM> can receive environmental data corresponding to a window of time in which the vehicle is detected. In another embodiment, the weather station <NUM> can periodically transmit (wired or wirelessly) captured environmental data to the server <NUM>. In another embodiment, the weather station <NUM> can asynchronously transmit (wired or wirelessly) environmental data to the server 102based upon one or more thresholds stored on the weather station <NUM>.

In another embodiment, the geopositioning module <NUM> can be configured to receive, obtain, generate, transmit, and/or store a location of the detected vehicle and/or the track. For example, the WILD data capture system <NUM> can be operably coupled with a global positioning system that can track a location of a vehicle, such that when the vehicle detection module <NUM> detects the vehicle, the geopositioning module <NUM> can receive a location of the vehicle from the global positioning system. In another embodiment, the WILD data capture system <NUM> can be operably coupled with sensors and other components that maintain a static location that can be transmitted amongst the system <NUM>. For example, the vehicle detection module <NUM> can detect a vehicle via a coupled sensor, and upon detection, the geopositioning module <NUM> can receive a location from the coupled sensor. In another embodiment, the geopositioning module <NUM> can retrieve a plurality of stored locations corresponding to a plurality vehicles, tracks, sensors, or other components that the geopositioning module <NUM> can associate with detections from the vehicle detection module <NUM>. In another embodiment, the geopositioning module <NUM> can transmit a location, such as a location of a detected vehicle and/or the portion of track the vehicle is traveling on, to another system (e.g., third party system).

In another embodiment, the vehicle data capture module <NUM> can be configured to capture vehicle-specific data. For example, the vehicle data capture module <NUM> can be operably coupled with, e.g., an RFID reader that can facilitate the reception of data from an RFID chip on a vehicle. In one embodiment, the RFID chip can include a date, a time, an Axle count of the vehicle, an identification of the vehicle, a direction the vehicle is traveling, and/or a load that the vehicle bears. In another embodiment, the RFID chip can include a plurality of data related to where the vehicle has been, where it is located currently, and where it is going. In another example,
the vehicle data capture module <NUM> can be operably coupled to any other device or component suitable to capture data related to a vehicle, such as a strain gauge, camera, radar, etc. For example, the vehicle data capture module <NUM> can be coupled with a camera that can detect a serial number of a vehicle or other identifying information. The vehicle data capture module <NUM> can receive data from a sensor that can measure, for example, stress applied to a rail or a track. In another embodiment, the vehicle data capture module <NUM> can receive data from a strain gauge coupled to a rail of a track that can measure stress in the rail as it varies with the passing of a vehicle on the track. In another example, the vehicle data capture module <NUM> can receive data from any sensor or sensors that can measure a force applied to the rail, such as by a vehicle travelling over the rail. In another embodiment, the vehicle data capture module <NUM> can receive data related to a force applied to a rail and/or rails over a predetermined period of time.

In another embodiment, the WILD impact load detection system <NUM> can include a WILD calibration system <NUM>. The WILD calibration system <NUM> can include a force determination module <NUM> and a force calibration module <NUM>. In one embodiment, the force determination module <NUM> can be configured to receive data from the WILD data capture system <NUM> and use the data in determining a force and/or forces applied to a portion of a track and/or rail. For example, the force determination module <NUM> can receive data from the vehicle data capture module <NUM>; in another example, the force determination module <NUM> can receive data having particular units and convert the data to reflect units of force. In one embodiment, the force determination module <NUM> can receive a plurality of sensor data captured by the vehicle data capture module <NUM> and use the sensor data to determine a max force (max peak force) (original max force) (original max peak force) applied to the rail as detected by the sensor. In one embodiment, the force determination module <NUM> can determine a weight of a vehicle and an impact force from the determined max force. In another embodiment, the force determination module <NUM> can be configured to create a plot of the sensor data and identify trends in the plot that can correspond to a number of relevant force measurements. For example, and in one embodiment, the force determination module <NUM> can create a plot showing the static peak force trend and max force in a graph displaying the magnitude of the measured force over time.

In one embodiment, the force determination module <NUM> can review the sensor data and recognize a static peak force trend (an example of which is shown above). In one embodiment, a static peak force trend can refer to a measurement (within a margin of error) with the highest instance. In another embodiment, the force determination module <NUM> can use the static peak force trend and/or the sensor data to determine a weight of a vehicle on a rail, such as by averaging all of the plot points located within the trend to arrive at a determined weight of the vehicle. In another embodiment, the force determination module <NUM> can be configured to recognize trends (e.g., a static peak force trend) in the data without plotting the data.

In another embodiment, the force determination module <NUM> can distinguish between a weight of a vehicle and an impact force (dynamic force), such as can be caused by imperfections or defects in a wheel, a rail, a vehicle, or other component participating in the application of force to a rail. For example, a static peak force trend can correlate with a weight of a vehicle because the majority of the wheel of the vehicle can generally be free of defects-the force exerted by a vehicle on a track via the wheel can remain largely unchanged as the unmarred portions of the wheel support the vehicle's weight. In another example, as the wheel rotates on the track and disposes a defect of the wheel between the track and the vehicle, the force exerted by the vehicle on the rail can increase, and such increase (the apex of which can be considered a max force value) from the static peak force trend can correlate with a dynamic force. In another example, the force determination module can utilize a determined weight of a vehicle and the max force of the vehicle in calculating the dynamic force. For example, in one embodiment, subtracting the vehicle weight from the max force value can yield the dynamic force value.

In another embodiment, the WILD calibration system <NUM> can include a force calibration module <NUM>. The force calibration module <NUM> can be configured to utilize data from the force determination module <NUM> and WILD data capture system <NUM> to calibrate force values determined by the force determination module <NUM>, such as to account to environmental conditions. For example, the force calibration module <NUM> can receive a max force value from the force determination module <NUM> and weather data from the WILD data capture system <NUM>, and algorithmically adjust/calibrate the max force value to account for the received weather data. In one embodiment, the force calibration module <NUM> can calibrate a max force value to account for changes in temperature. For example, the force calibration module <NUM> can be configured to adjust max force values (e.g., for the purposes of alert severity level assignment, generation, and delivery) to account for increased rail tension, such as can be caused by linear shrinkage of a rail due to cold weather. In another example, the force calibration module <NUM> can be configured to adjust max force values to account for decreased rail tension, such as can be caused by linear expansion of a rail due to warm weather. In another embodiment, the force calibration module <NUM> can be configured adjust max force values determined by the force determination module <NUM> to compensate or account for any environmental conditions, including, but not limited to, temperature, pressure, humidity, wind speed, precipitation, UV index, and storm patterns.

In one embodiment, the force calibration module <NUM> can calibrate a max force value using an operational variable. For example, the force calibration module <NUM> can apply a mathematical equation that implements the operational variable, which can change depending on the condition being compensated for. In another embodiment, the operational variable can be a constant that can correspond to particular temperature thresholds. In another embodiment, the operational variable can be a constant corresponding to the material in the rail. In another embodiment, the operational variable can be a constant corresponding to typical linear expansion or shrinkage of a rail in certain temperatures. In one embodiment, the force calibration module <NUM> can utilize the following equation: <MAT>.

In one embodiment, Koriginal can refer to a max force value determined by the force determination module <NUM>. In another embodiment, Koriginal can include a value in "kips," or a measurement indicating thousands of pounds (e.g., <NUM> kip = <NUM> lbs. In another embodiment, Kadjusted can refer to calibrated and/or adjusted max force value. In another embodiment, V can be an operational variable. In one embodiment, V can be in the range of <NUM> to <NUM>. In another embodiment, V can be in the range of -<NUM> to -<NUM>. In another embodiment, V can be equal to -<NUM>; in another embodiment, V can be equal to <NUM>. In another embodiment, the operational variable can be derived by setting a relationship, such as a <NUM> kip value at <NUM>°F can be adjusted down to <NUM> kips. In one embodiment, the value of V can change depending on the temperature being compensated for (e.g., hot or cold). In another embodiment, V can also change depending on a temperature threshold. In another embodiment, a temperature threshold can vary depending on if cold or hot weather is being compensated for. For example, a temperature threshold can be designed to account for decreased rail tension due to warmer weather, and °Fdeviation from temperature threshold can refer to a number of degrees above a temperature threshold (as an example, <NUM> °F). For example, if the temperature is <NUM> °F, and the temperature threshold is <NUM>°F the integer "<NUM>" can be inserted for °Fdeviation from temperature threshold. In another embodiment, the above equation can be modified as follows to calibrate a max force value to account for temperatures below freezing (e.g., below the freezing point of water): <MAT>.

In another embodiment, the force calibration module <NUM> can account for an amount of time an environmental condition has been present. For example, if a temperature has been above or below a temperature threshold (or otherwise satisfied a temperature threshold) for a set amount of time (e.g., two hours), the force calibration module <NUM> can further calibrate the max force value to account for this duration and temperature. In one embodiment, the force calibration module <NUM> can provide an increased calibrated max force value to account for hotter temperatures present over longer periods of time and provide a decreased calibrate max force value to account for colder temperatures present over long periods of time, as compared to the original max force value. In one embodiment, the force calibration module <NUM> can calibrate max force values only if a temperature falls below freezing, or if a temperature rises above <NUM> °F.

In another embodiment, the wheel impact load detection system <NUM> can include an alert management system <NUM>. The alert management system <NUM> can include an alert generation module <NUM> and an alert delivery module <NUM>. In another embodiment, the alert generation module <NUM> can receive data from the WILD data capture system <NUM> and/or the WILD calibration system <NUM>. For example, the alert generation module <NUM> can receive that a vehicle has been detected, a location of the vehicle, environmental conditions, and/or an identity of the vehicle. In another example, the alert generation module <NUM> can receive a max force value (and/or a calibrated max force value) and determine if the (calibrated) max force value exceeds one or more force thresholds. In another embodiment, the alert generation module <NUM> (and/or the force determination module <NUM>) can determine a confidence level in the data received from one or more systems and/or sensors. In another embodiment, the alert generation module <NUM> can utilize received data to generate an alert with an assigned severity level. For example, an alert can be assigned a severity level (e.g., Levels <NUM>-<NUM>) based on the (calibrated) max force value and the confidence level, a tabulated example of which is shown below:.

In one embodiment, severity levels can indicate to a railroad system what action is recommended to address the alert. For example, a Level <NUM> alert can indicate that the vehicle should be stopped immediately and inspected. In another example, a Level <NUM> alert can indicate that an inspection (e.g., of the wheels and/or Axles of the vehicle) can wait until the next scheduled inspection. In another example, a Level <NUM> alert can indicate that an inspection can wait until the vehicle has been fully emptied of cargo and/or until its last visit to a mechanical facility prior to going offline. In another embodiment, multiple other severity levels of alerts are possible. For example, an Opportunistic alert can indicate that the vehicle (or particular parts of the vehicle, e.g., wheels) needs to be inspected only when the vehicle is receiving repairs for a different issue. In another example, a Level <NUM> alert can indicate that the alert generation module <NUM> utilized a calibrated max force (e.g., instead of an original max force) in generating the alert, such that a Level <NUM> alert can indicate to the railroad system that the alert severity was adjusted as a result of calibration for environmental conditions. In another embodiment, a Level <NUM> alert can indicate that an original max force value exceeded a force threshold, while a calibrated max force value fell below the force threshold. In another embodiment, a Level <NUM> alert can indicate the same recommended action as the Opportunistic alert, but can further inform a railroad system that the alert was generated by accounting for environmental conditions.

In another embodiment, the severity levels of alerts generated by the alert generation module <NUM> can be based at least in part on (calibrated) max force values. In one example, and with reference to the above table, a kip value of <NUM> or more (e.g., <NUM>,<NUM> lbs. ) can be categorized as "Most Severe;" a kip value between <NUM> and <NUM> can be "Severe," and a kip value between <NUM> and <NUM> can be "Least Severe. " In another embodiment, a kip value between <NUM> and <NUM> can generate an Opportunistic alert. Other kip values or (calibrated) max force values can be utilized in these categories instead of those discussed above. In another embodiment, the alert generation module <NUM> can utilize a number of force thresholds and confidence thresholds in assigning a severity level. For example, if a max force value falls below a first force threshold (e.g., <NUM> kips), the alert generation module <NUM> can determine, without considering a confidence level, to not generate an alert. In another example, if a confidence level falls below a first confidence threshold (e.g., <NUM>%), the alert generation module <NUM> can determine, without considering a max force value, to not generate an alert. In another embodiment, the alert generation module <NUM> can utilize any number of force and/or confidence thresholds to assign a severity level for a generated alert.

In another embodiment, the alert delivery module <NUM> of the alert management system <NUM> can transmit alerts throughout a railroad system. For example, the alert delivery module <NUM> can receive an alert with an assigned severity level from the alert generation module <NUM> and communicate the alert to personnel, networked servers, or any other components in operable connection with the network or alert delivery module <NUM>. In one embodiment, the alert delivery module <NUM> can transmit alerts via messages, records, or any other suitable form of communication. In another embodiment, the alert delivery module <NUM> can update a record with a generated alert.

<FIG> illustrates a flow chart diagram <NUM> exemplifying control logic embodying features of a method of wheel impact load detection (WILD), in accordance with an exemplary embodiment of the present disclosure. The WILD control logic <NUM> can be implemented as an algorithm on a server (e.g., server <NUM>), a machine learning module, or other suitable system. Additionally, the WILD control logic <NUM> can implement or incorporate one or more features of the WILD system <NUM>, including the wild capture system <NUM> (with corresponding modules <NUM>, <NUM>, <NUM>, and <NUM>), wild calibration system <NUM> (with corresponding modules <NUM> and <NUM>), and alert management system <NUM> (with corresponding modules <NUM> and <NUM>). The WILD control logic <NUM> can be achieved with software, hardware, an application programming interface (API), a network connection, a network transfer protocol, HTML, DHTML, JavaScript, Dojo, Ruby, Rails, other suitable applications, or a suitable combination thereof.

The WILD control logic <NUM> can leverage the ability of a computer platform to spawn multiple processes and threads by processing data simultaneously. The speed and efficiency of the WILD control logic <NUM> is greatly improved by instantiating more than one process to facilitate wheel impact load detection. However, one skilled in the art of programming will appreciate that use of a single processing thread may also be utilized and is within the scope of the present disclosure.

The WILD control logic <NUM> process flow of the present embodiment begins at step <NUM>, wherein the control logic <NUM> instantiates. In one embodiment, the control logic <NUM> can be configured to receive data from sensors or other data-gatherers on and/or by a railroad track and instantiating the control logic <NUM> at step <NUM> can prepare the control logic <NUM> to receive and process the anticipated data. The control logic <NUM> then proceeds to step <NUM>.

At step <NUM>, the control logic <NUM> can detect a train passing along a particular portion of track. For example, the control logic <NUM> can receive data from a motion sensor indicating that a train is passing; in another embodiment, the control logic <NUM> can receive data from a strain gauge indicating that a train is exerting force on a portion of a track. In one embodiment, step <NUM> can be related to and/or considered to be performed by the vehicle detection module <NUM>. The control logic <NUM> then proceeds to steps <NUM> and <NUM>.

At step <NUM>, the control logic <NUM> can capture environmental data, such as weather data. In one embodiment, step <NUM> can be related to and/or considered to be performed by the environmental data capture module <NUM>. In another embodiment, step <NUM> can include receiving weather data from a weather station (e.g., weather station <NUM>). In another embodiment, step <NUM> can include receiving one or more temperature measurements, such as ambient temperature measurements. The control logic <NUM> then proceeds to step <NUM>.

At step <NUM>, the control logic <NUM> can determine if a temperature threshold is satisfied. In one embodiment, a temperature threshold can be satisfied if a temperature (e.g., a temperature received at step <NUM>) is below, above, and/or equal to a predetermined temperature or temperatures. In an exemplary embodiment, a temperature threshold is satisfied if the temperature (e.g., ambient temperature) at step <NUM> is below <NUM> °F. If the temperature threshold is satisfied, the control logic <NUM> then proceeds to step <NUM>. If the temperature threshold is not satisfied, the control logic <NUM> then proceeds to step <NUM>.

At step <NUM>, the control logic <NUM> can capture wheel impact load detection (WILD) data. In one embodiment, step <NUM> can be related to and/or considered to be performed by the vehicle data capture module <NUM> and/or the geopositioning module <NUM>. In another embodiment, the control logic <NUM> can receive the identity of the train, measurements (e.g., measurement of strain and/or stress on the track), the location of the train, and other relevant data. The control logic <NUM> then proceeds to steps <NUM> and <NUM>.

At step <NUM>, the data captured at step <NUM> can be transferred and/or transmitted to an alert system (e.g., alert management system <NUM>). For example, and in one embodiment, the control logic <NUM> can create a record that includes the data and transmit the record to an alert system, such as to facilitate the generation of an alert by the alert system. In another embodiment, the control logic <NUM> can send a message to the alert system that communicates the data. The control logic <NUM> then proceeds to step <NUM>.

At step <NUM>, the data transferred to the alert system at <NUM> can be stored in an alert system database, or any other database in operable connection with the control logic <NUM>. The control logic <NUM> then proceeds to step <NUM>.

At step <NUM>, the control logic <NUM> can create and publish alerts using the data stored in the database at step <NUM>. In one embodiment, step <NUM> can be related to and/or considered to be performed by the force determination module <NUM>, the alert generation module <NUM>, and/or the alert delivery module <NUM>. For example, the control logic <NUM> can determine a max peak (e.g., max force, such as the max peak determined at step <NUM>), compare the max force with predetermined force thresholds, and determine if an alert should be created and published. The control logic <NUM> can also assign a severity level to the alert at step <NUM> based at least in part on the max peak and predetermined force thresholds. In one embodiment, the alert can be published to the railroad system to notify personnel of a recommended action.

At step <NUM>, the control logic <NUM> can determine an original max peak (original max peak force). In one embodiment, step <NUM> can be related to and/or considered to be performed by the force determination module <NUM>. In another embodiment, the original max peak can refer to the original max force that can be determined from the data captured at step <NUM>. For example, at step <NUM>, the control logic <NUM> can determine an original kip value that can be used in assigning a severity level to an alert. The control logic <NUM> then proceeds to step <NUM>.

At step <NUM>, if the temperature threshold was satisfied in step <NUM>, the control logic <NUM> can utilize the original max peak and the temperature delta (e.g., amount of deviation of the measured temperature from the temperature threshold) to calculate an adjusted max peak (calibrated max peak force). In one embodiment, step <NUM> can be related to and/or considered to be performed by the force calibration module <NUM>. If the temperature threshold is not satisfied in step <NUM>, the temperature delta can be zero, meaning that the adjusted max peak can be equal to the original max peak. The control logic <NUM> then proceeds to step <NUM>.

At step <NUM>, the control logic <NUM> appends the WILD data captured at step <NUM> with the adjusted max peak value determined at step <NUM>. In one embodiment, step <NUM> can be related to and/or considered to be performed by the force calibration module <NUM> and/or the alert delivery module <NUM>. The control logic <NUM> then proceeds to step <NUM>.

At step <NUM>, the control logic <NUM> assigns a severity level to an alert based at least in part on the adjusted max peak value. In one embodiment, step <NUM> can be related to and/or considered to be performed by the alert generation module <NUM>. In one embodiment, the severity level assigned at step <NUM> can differ from the severity level of the alert created in step <NUM>. For example, when WILD data is captured at step <NUM>, the control logic <NUM> can assign an initial severity level that does not account for environmental conditions (e.g., the weather data captured at step <NUM>). After consideration of the temperature threshold at step <NUM>, the control logic can then amend the severity level at step <NUM>. In one embodiment, the severity level assigned at step <NUM> can act as an "internal" alert, informing need-to-know railroad personnel of recommended actions, while the alert created and published at step <NUM> can remain outstanding until it is closed in accordance with the control logic <NUM> process flow. In another embodiment, the severity level assigned at step <NUM> can override the severity level assigned at step <NUM>, such that the alert created and published at step <NUM> can be amended to reflect the new severity level assigned at step <NUM>. The control logic <NUM> then proceeds to step <NUM>.

At step <NUM>, the control logic <NUM> can then receive input as to whether a defect (e.g., a billable defect) was discovered after the alert was acted upon. For example, once an inspection is performed in accordance with the assigned severity level, the control logic <NUM> can receive a command indicating that defect was found or not. If a defect is found, the control logic <NUM> then proceeds to step <NUM>. If a defect is not found, the control logic then proceeds to step <NUM>.

At step <NUM>, the control logic <NUM> can receive input indicating that an inspection was performed. In one embodiment, the inspection input can be an e-mail, text, flag, message, or other suitable notification. The control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can receive input indicating that a repair was performed to address the defect. In one embodiment, the repair input can be an e-mail, text, flag, message, or other suitable notification. The control logic <NUM> then proceeds to step <NUM>.

At step <NUM>, the alert with the assigned severity level can be closed. For example, if it is indicated to the control logic in step <NUM> that a defect was repaired, the control logic <NUM> can moot the alert, such that the control logic <NUM> can close the alert. Similarly, if it is indicated to the control logic <NUM> at step <NUM> that an inspection was performed, the control logic <NUM> can close the alert. The control logic <NUM> then proceeds to step <NUM> and <NUM>. At step <NUM>, the control logic <NUM> publishes that the alert has been closed. At step <NUM>, the control logic <NUM> can terminate or await a new train detection and can repeat the aforementioned steps.

In one embodiment, steps <NUM>, <NUM>, and <NUM> of the control logic <NUM> can correspond with the WILD data capture system <NUM>. In another embodiment, steps <NUM>, <NUM>, <NUM>, and <NUM> can correspond with the WILD calibration system <NUM>. In another embodiment, steps <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> can correspond with the alert management system <NUM>.

<FIG> illustrates a flow chart diagram <NUM> exemplifying control logic embodying features of a method of wheel impact load detection (WILD) and calibration, in accordance with an exemplary embodiment of the present disclosure. The detection and calibration control logic <NUM> can be implemented as an algorithm on a server (e.g., server <NUM>), a machine learning module, or other suitable system. Additionally, the detection and calibration control logic <NUM> can implement or incorporate one or more features of the WILD system <NUM>, including the wild capture system <NUM> (with corresponding modules <NUM>, <NUM>, <NUM>, and <NUM>), wild calibration system <NUM> (with corresponding modules <NUM> and <NUM>), and alert management system <NUM> (with corresponding modules <NUM> and <NUM>). The control logic <NUM> can be achieved with software, hardware, an application programming interface (API), a network connection, a network transfer protocol, HTML, DHTML, JavaScript, Dojo, Ruby, Rails, other suitable applications, or a suitable combination thereof.

The control logic <NUM> can leverage the ability of a computer platform to spawn multiple processes and threads by processing data simultaneously. The speed and efficiency of the control logic <NUM> is greatly improved by instantiating more than one process to facilitate wheel impact load detection. However, one skilled in the art of programming will appreciate that use of a single processing thread may also be utilized and is within the scope of the present invention.

The control logic <NUM> process flow of the present embodiment begins at step <NUM>, where the control logic <NUM> detects a vehicle, e.g., a vehicle traveling on a track. In one embodiment, step <NUM> can be related to and/or considered to be performed by the vehicle detection module <NUM>. The control logic <NUM> then proceeds to step <NUM>.

At step <NUM>, the control logic <NUM> can generate a record. In one embodiment, step <NUM> can be related to and/or considered to be performed by the vehicle data capture module <NUM>. In one embodiment, the record can include data related to the vehicle, such as a time and date of , an identify of the vehicle, an Axle count of the vehicle, and/or a direction the vehicle is traveling. The record can be stored on a client, a server, or a database. The control logic <NUM> then proceeds to step <NUM>.

At step <NUM>, the control logic <NUM> can receive a location, such as a location of the vehicle, a location of the track, etc. In one embodiment, step <NUM> can be related to and/or considered to be performed by the geopositioning module <NUM>. For example, the control logic <NUM> can receive location data from a sensor on the vehicle or on the track; in another example, the control logic <NUM> can receive a location from a railroad system. The control logic <NUM> then proceeds to step <NUM>.

At step <NUM>, the control logic can receive environmental data. In one embodiment, step <NUM> can be related to and/or considered to be performed by the environmental data capture module <NUM>. The environmental data can include humidity, pressure, temperature, or any other type of environmental data. The control logic then proceeds to step <NUM>.

At step <NUM>, the control logic <NUM> can receive data from a sensor, such as a sensor on the track or the vehicle. In one embodiment, step <NUM> can be related to and/or considered to be performed by the vehicle data capture module <NUM>. Preferably, the control logic <NUM> receives data from a sensor that can indicate a strain/stress corresponding to a weight or mass of the vehicle. In one example, the sensor can be a strain gauge coupled to the track. The control logic <NUM> then proceeds to step <NUM>.

At step <NUM>, the control logic <NUM> can determine an original max force value from the sensor data. In one embodiment, step <NUM> can be related to and/or considered to be performed by the force determination module <NUM>. The control logic <NUM> then proceeds to step <NUM>.

At step <NUM>, the control logic <NUM> can determine a confidence level. In one embodiment, step <NUM> can be related to and/or considered to be performed by the force determination module <NUM>, and/or the alert generation module <NUM>. In another embodiment, the confidence level can be a measure of confidence in an accuracy of the sensor data received at step <NUM>. For example, and in one embodiment, data received at step <NUM> can be received from one or more sensors. If multiple sensors yield similar measurements, the control logic <NUM> can determine at step <NUM> that a confidence level should be higher. If, on the other hand, only one sensor yields useable measurements, the control logic <NUM> at step <NUM> can determine that a confidence level should be lower. In another embodiment, if the measurements from the sensors are not uniform, but instead more erratic, the control logic <NUM> can determine that the confidence level should be lower. In another embodiment, if the received data provides multiple data points that seem appropriately uniform, the control logic <NUM> can determine that the confidence level should be higher. In one embodiment, the control logic <NUM> can give a determined confidence level a percentage value (e.g., like the table discussed above with respect to the alert generation module <NUM>). The control logic <NUM> can then proceed to step <NUM>.

At step <NUM>, the control logic <NUM> can determine whether an environmental threshold is satisfied. In one embodiment, step <NUM> can be related to and/or considered to be performed by the force calibration module <NUM>. In one embodiment, the environmental threshold can be a pressure threshold, such that if the environmental data received at step <NUM> indicates a pressure that is below, equal to, or above the pressure threshold, the pressure threshold can be satisfied or not. In another embodiment, the environmental threshold can be a temperature threshold, such as the temperature threshold discussed with respect to the force calibration module <NUM> and the alert generation module <NUM> above. If the environmental threshold is satisfied, the control logic <NUM> proceeds to step <NUM>. If the environmental threshold is not satisfied, the control logic <NUM> proceeds to step <NUM>.

At step <NUM>, the control logic <NUM> can generate a calibrated max force value. In one embodiment, step <NUM> can be related to and/or considered to be performed by the force calibration module <NUM>. In another embodiment, the control logic <NUM> can generate a calibrated max force value by referencing the original max force value determined in step <NUM> and the environmental data received in step <NUM>. In another embodiment, the calibrated max force value can be generated by adjusting the original max force value with an operational variable. The control logic <NUM> then proceeds to step <NUM>.

At step <NUM>, the control logic <NUM> can determine if the original max force value exceeds a force threshold. In one embodiment, step <NUM> can be related to and/or considered to be performed by the alert generation module <NUM>. In another embodiment, the control logic <NUM> can reference a force threshold contained in memory that can act as a kill switch-for example, if the original max force value does not exceed the force threshold, the control logic <NUM> can determine that no alert will be generated, regardless of the remaining process flow steps. If the original max force value does not exceed the force threshold, the control logic <NUM> then proceeds to step <NUM>. If the original max force value exceeds the force threshold, the control logic <NUM> proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can determine that no alert will be generated. In one embodiment, step <NUM> can be related to and/or considered to be performed by the alert generation module <NUM>. The control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can update a record, such as the record generated at step <NUM>. In one embodiment, step <NUM> can be related to and/or considered to be performed by the alert delivery module <NUM>.

At step <NUM>, the control logic <NUM> can determine whether a calibrated max force value was generated (e.g., whether step <NUM> was performed). In one embodiment, step <NUM> can be related to and/or considered to be performed by the alert generation module <NUM>. If the control logic <NUM> generates a calibrated max force value, the control logic <NUM> then proceeds to step <NUM>. If the control logic <NUM> does not generate a calibrated max force value, the control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can utilize the calibrated max force value generated at step <NUM> and the confidence level determined at step <NUM> to assign a severity level to an alert. In one embodiment, step <NUM> can be related to and/or considered to be performed by the alert generation module <NUM>. In another embodiment, the severity levels can be assigned in accordance with the table discussed above with the respect to the alert generation module <NUM>. In one example, the severity level of the alert can vary with both the calibrated max force value and the confidence level. The control logic <NUM> then proceeds to step <NUM>.

At step <NUM>, the control logic <NUM> can utilize the original max force value determined at step <NUM> and the confidence level determined at step <NUM> to assign a severity level to an alert. In one embodiment, step <NUM> can be related to and/or considered to be performed by the alert generation module <NUM>. In another embodiment, the severity levels can be assigned in accordance with the table discussed above with the respect to the alert generation module <NUM>. In one example, the severity level of the alert can vary with both the original max force value and the confidence level. The control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can generate an alert with the severity level assigned in either step <NUM> or step <NUM>. The control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can update the record generated at step <NUM> to reflect that an alert was generated with the severity level assigned at step <NUM> or step <NUM>, or that no alert was generated. The control logic <NUM> then terminates or awaits a new vehicle detection and can repeat the aforementioned steps.

In one embodiment, steps <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> of the control logic <NUM> can correlate with the WILD data capture system <NUM>. In another embodiment, steps <NUM>, <NUM>, <NUM>, and <NUM> can correlate with the WILD calibration system <NUM>. In another embodiment, steps <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> can correlate with the alert management system <NUM>.

<FIG> illustrate a flow chart diagram <NUM> exemplifying control logic embodying features and program steps of a wheel impact load detection and calibration system, in accordance with an exemplary embodiment of the present disclosure. The wheel impact load detection and calibration system control logic <NUM> can be implemented as an algorithm on a server (e.g., server <NUM>), a machine learning module, or other suitable system. Additionally, the wheel impact detection and calibration system control logic <NUM> can implement or incorporate one or more features of the WILD system <NUM>, including the wild capture system <NUM> (with corresponding modules <NUM>, <NUM>, <NUM>, and <NUM>), wild calibration system <NUM> (with corresponding modules <NUM> and <NUM>), and alert management system <NUM> (with corresponding modules <NUM> and <NUM>). The control logic <NUM> can be achieved with software, hardware, an application programming interface (API), a network connection, a network transfer protocol, HTML, DHTML, JavaScript, Dojo, Ruby, Rails, other suitable applications, or a suitable combination thereof.

The control logic <NUM> process flow of the present embodiment begins at step <NUM>, where the control logic <NUM> can detect a vehicle, e.g., a vehicle traveling on a track. The control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can generate a record. The control logic <NUM> can then proceed to step <NUM>. At step <NUM>, the control logic <NUM> can receive a location of the vehicle and/or the track. The control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can receive environmental data <NUM>. The control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can receive data from one or more sensors; preferably, the data received relates to a force exerted by the vehicle on the track. The control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can determine an original max peak force from the received sensor data. In one embodiment the max peak force can correspond to the maximum force exerted by the vehicle on the track. The control logic <NUM> then proceeds to steps <NUM> and <NUM>.

At step <NUM>, the control logic <NUM> can determine a confidence level in the received sensor data in accordance with the principles of the present disclosure. The control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can determine if the original max peak force determined in step <NUM> exceeds a first force threshold. If the original max peak force does not exceed the first force threshold, the control logic <NUM> then proceeds to step <NUM>. If the original max peak force exceeds the first force threshold, the control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can determine that no alert will be generated. At step <NUM>, the control logic <NUM> can determine whether an environmental threshold is satisfied, in accordance with the principles of the present disclosure. If the environmental threshold is not satisfied, the control logic <NUM> then proceeds to step <NUM>. If the environmental threshold is satisfied, the control logic <NUM> then proceeds to step <NUM>.

At step <NUM>, the control logic <NUM> can generate a calibrated max peak force in accordance with the principles of the present disclosure. The control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can determine whether the calibrated max peak force generated in step <NUM> exceeds the first force threshold. If the calibrated max peak force does not exceed the first force threshold, the control logic <NUM> then proceeds to step <NUM>. If the calibrated max peak force exceeds the first force threshold, the control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can generate an alert with an assigned severity level. In one embodiment, the severity level of the alert can be a Level <NUM> severity level. In one embodiment, the severity level (e.g., Level <NUM>) can signify that the original max peak force exceeded the first force threshold, and that the calibrated max peak force did not exceed the first force threshold. In another embodiment, a Level <NUM> alert can be of a lower severity level (and priority) than a Level <NUM>, Level <NUM>, and Level <NUM> alert. The control logic <NUM> then terminates or awaits a new vehicle detection and can repeat the aforementioned steps.

At step <NUM>, the control logic <NUM> can determine whether a max peak force (e.g., the original max peak force or the calibrated max peak force) exceeds a third force threshold. In one embodiment, the control logic <NUM> can determine whether the original max peak force or the calibrated max peak force should be used at step <NUM> and onward. For example, the control logic <NUM> can determine that the calibrated max peak force should be used beginning at step <NUM> if a calibrated max peak force was generated at step <NUM>. In another example, the control logic <NUM> can determine that the original max peak should be used beginning at step <NUM> if no calibrated max peak force was generated at step <NUM>. Preferably, the third force threshold can be higher than the first force threshold. For example, the first force threshold can correspond to a lower force (e.g., a lower kip value) than the third threshold, such that if a max peak force exceeds the third force threshold, a severity level of a resulting alert can generally be higher as compared to a max peak force that does not exceed the third force threshold but does exceed the first force threshold. If the max peak force used (e.g., original or calibrated) exceeds the third force threshold, the control logic <NUM> then proceeds to step <NUM>. If the max peak force used does not exceed the third force threshold, the control logic <NUM> then proceeds to step <NUM>.

At step <NUM>, the control logic <NUM> can determine whether the confidence level determined in step <NUM> exceeds a first confidence threshold. For example, a confidence threshold can take the form of a statistical probability that the received sensor data (and resulting max peak force values) are accurate. In another embodiment, a confidence threshold can be similar to that depicted in the table above, e.g., corresponding to general likelihood that the received data and determined max peak force are accurate. Preferably, the first confidence threshold can be <NUM>% - in other words, if the confidence level determined in step <NUM> is less than <NUM>%, the first confidence threshold would be considered to not be exceeded by the determined confidence level. If the confidence level exceeds the first confidence threshold, the control logic <NUM> then proceeds to step <NUM>. If the confidence level does not exceed the first confidence threshold, the control logic <NUM> can proceed to step <NUM>. At step <NUM>, the control logic <NUM> can generate an alert with an assigned severity level. In one embodiment, the severity level can be Level <NUM>. In another embodiment, the severity level of the alert generated at step <NUM> can be higher (e.g., more severe) than the severity level of the alert generated in step <NUM>. The control logic <NUM> then terminates or awaits a new vehicle detection and can repeat the aforementioned steps. At step <NUM>, the control logic <NUM> can generate an alert with an assigned severity level. In one embodiment, the severity level can be Level <NUM>. In one embodiment, the severity level assigned to the alert generated in step <NUM> can be higher than the severity level of the alert generated in steps <NUM> and <NUM>. The control logic <NUM> then terminates or awaits a new vehicle detection and can repeat the aforementioned steps.

At step <NUM>, the control logic <NUM> can determine whether a max peak force (e.g., an original max peak force or a calibrated max peak force) exceeds a second force threshold. Preferably, the second force threshold can be between the first force threshold and the third force threshold. For example, the second force threshold can be higher than the first force threshold, and lower than the third force threshold. If a max peak force exceeds the second force threshold, the control logic <NUM> then proceeds to step <NUM>. If a max peak force does not exceed the second force threshold, the control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can generate an alert with an assigned severity level. In one embodiment, the severity level can be Level <NUM>. In one embodiment, the severity level of the alert generated at step <NUM> can be lower than the severity levels of the alerts generated at steps <NUM> and <NUM>, but higher than the severity level of the alert generated in step <NUM>. The control logic <NUM> then terminates or awaits a new vehicle detection and can repeat the aforementioned steps.

At step <NUM>, the control logic <NUM> can determine if the confidence level determined at step <NUM> exceeds a first confidence threshold. In one embodiment, the first confidence threshold of step <NUM> can be the same as the first confidence threshold of step <NUM>. If the first confidence threshold is exceeded, the control logic <NUM> then proceeds to step <NUM>. If the first confidence level is not exceeded, the control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can determine if the confidence level determined at step <NUM> exceeds a second confidence threshold. The second confidence threshold can be similar to the first confidence threshold; preferably, the second confidence threshold can indicate a higher degree of confidence as compared to the first confidence threshold. In one embodiment, the second confidence threshold can be <NUM>%. For example, if the confidence level determined in step <NUM> does not exceed <NUM>%, the confidence level would not exceed the second confidence threshold. In another embodiment, a second confidence threshold of <NUM>% can indicate that the control logic <NUM> is <NUM>% certain that the data received from the sensors in step <NUM> (and resulting max peak force value) are accurate. If the confidence level exceeds the second confidence threshold, the control logic <NUM> then proceeds to step <NUM>. If the confidence level does not exceed the second force threshold, the control logic <NUM> then proceeds to step <NUM>.

At step <NUM>, the control logic <NUM> can determine if the confidence level determined at step <NUM> exceeds a third confidence threshold. The third confidence threshold can be similar to the first confidence threshold and/or the second confidence threshold. Preferably, the third confidence threshold can indicate a higher degree of confidence as compared to the first confidence threshold and the second confidence threshold. In one embodiment, the third confidence threshold can be <NUM>%. For example, if the confidence level determined in step <NUM> does not exceed <NUM>%, the confidence level would not exceed the third confidence threshold. If the confidence level exceeds the third confidence threshold, the control logic <NUM> then proceeds to step <NUM>. If the confidence level does not exceed the third confidence threshold, the control logic <NUM> then proceeds to step <NUM>.

At step <NUM>, the control logic <NUM> can plot the data from the sensor received in step <NUM>. For example, the control logic <NUM> can create a plot like the one discussed above with respect to the force determination module <NUM>. Preferably, the plot can include a force axis and a time axis, such that points on the plot can be coordinated by magnitude of force and the time at which the force was exerted. In another embodiment, the data received in step <NUM> can be data from one or more strain gauges, and the control logic <NUM> can convert the units of measurement provided by the strain gauge (e.g., µε, in. , mm/mm, etc.) into a force measurement and/or a mass measurement, such as Newtons, pounds, kilograms, etc., and subsequently plot the force measurements according to the time at which the data was received. The control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can compare the points from the plot. Preferably, the control logic <NUM> can search for similarities in the points and trends in the data. In one example, the control logic <NUM> can determine a force value (within a margin of error) having the highest instance on the plot. In one embodiment, the control logic <NUM> can recognize that a particular force measurement (e.g., <NUM> kips ± <NUM> kips) occurred most often. In another embodiment, the control logic <NUM> can recognize spikes in the plotted data, as well determine a maximum force measurement received by the sensor in step <NUM>. The control logic <NUM> then proceeds to step <NUM>.

At step <NUM>, the control logic <NUM> can recognize a static peak force trend in the data. In one embodiment, the static peak force trend can refer to a number of measurements that can correlate with one another, such as by being close in value with one another; in another embodiment, the static peak force trend can refer to a force value range having the highest instance. In another embodiment, the static peak force trend can refer to the force measurements that are within a predetermined deviation from one another. As an example, the control logic <NUM> can receive ten different force measurements, occurring at ten different times, in step <NUM>. In this example, seven of those measurements can be between <NUM> and <NUM> kips; the other three measurements can be <NUM> kips, <NUM> kips, and <NUM> kips, respectively. In this example, the control logic <NUM> can recognize that seven of the measurements correlate to one another by nature of the fact that they all fall within a range spanning only three kips-in this manner, the control logic <NUM> can recognize a static peak force trend in the data. In this example, the control logic <NUM> can further recognize that the maximum force value measure was <NUM> kips. The control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can determine a weight value of the vehicle by using the static peak force trend. In one embodiment, the control logic <NUM> can average all of the force values within the static peak for trend to determine a weight of a vehicle. The control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can calculate a dynamic force value using the original max peak force determined in step <NUM> and the weight value determined in step <NUM>. In one embodiment, the control logic <NUM> can thereby determine the proportion of the max peak force that was due to the defect as opposed to the weight of the vehicle.

In operation, in one exemplary embodiment, the control logic <NUM> can begin at step <NUM>, where a train can be detected on a track. For example, the train can be detected via at least one strain gauge coupled to the track that the train travels over; in another example, the train can be detected by LIDAR, such that the control logic <NUM> can prepare to receive data. The train can include identifying information that can be received by the control logic <NUM>. For example, the train can have an RFID tag that can be read by an RFID reader in operable connection with the control logic <NUM>. In another embodiment, the RFID tag can include the date and time that the RFID tag is read by the reader, the Axle count of the train, and the direction the train is traveling on the vehicle. In another embodiment, the date and time that the RFID tag is read can be generated by the control logic <NUM>. The control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can generate a record <NUM> that can include the data gleaned from reading the train's RFID tag. The control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can receive a location of the vehicle, track, and/or spot of detection, such as from coordinates that are programmed into the sensors (RFID reader, strain gauge, etc.), from a GPS beacon on the train, or from the RFID tag. The control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can receive environmental data, such as a temperature (e.g., an ambient temperature) at that portion of the track where the train has been detected. In this example, the temperature received at step <NUM> can be <NUM> °F. The control logic <NUM> then proceeds to step <NUM>.

At step <NUM>, in this example, the control logic <NUM> can receive data from a plurality of strain gauges coupled to the track. The control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can use the strain gauge data to determine an original max peak force - in this embodiment, the control logic <NUM> can determine that the original max peak force can be <NUM> kips. The control logic then proceeds to steps <NUM> and <NUM>.

At step <NUM>, the control logic <NUM> can determine a confidence level. The control logic <NUM> can incorporate a number of factors in determining the confidence level, such as the number of data points received in step <NUM> (which can, in one embodiment, signify the number of wheel revolutions that occurred in the given time and distance), the range of the measurements, the environmental data, etc. In this embodiment, the control logic <NUM> can determine the confidence level to be <NUM>%. The control logic <NUM> then proceeds to step <NUM>.

At step <NUM>, the control logic <NUM> determines if the original max peak force exceeds the first force threshold. In this example, the first force threshold can be <NUM> kips, meaning that in this example, the control logic <NUM> then proceeds to step <NUM> instead of step <NUM> (e.g., because <NUM> kips exceeds <NUM> kips). At step <NUM>, the control logic <NUM> can determine if an environmental threshold is satisfied. In this example, the environmental threshold can be a temperature threshold of <NUM> °F, and the temperature threshold can be satisfied if a temperature received at step <NUM> is below <NUM> °F. In this example, the control logic <NUM> can determine that the temperature received at step <NUM> (<NUM> °F) satisfies the environmental threshold at step <NUM>, and the control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can generate a calibrated max peak force-in this example, the control logic <NUM> can generate the calibrated max peak force with the following equation: <MAT> wherein V = <NUM> and Koriginal = <NUM> kips. The control logic <NUM> can determine, in this example, that the Kadjusted value (which can be the calibrated max peak force) can be equal to <NUM> kips. The control logic <NUM> then proceeds to step <NUM>.

At step <NUM>, the control logic <NUM> can determine if the calibrated max peak force (<NUM> kips) exceeds the first force threshold (<NUM> kips). Because this is true, the control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can determine if the calibrated max peak force exceeds a third force threshold, which, in this example, can be <NUM> kips. In this example, the control logic <NUM> can determine that the calibrated max peak value should be used as opposed to the original max peak value. Because <NUM> kips is less than <NUM> kips, the control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can determine if the calibrated max peak force exceeds the second force threshold, which in this example, can be <NUM> kips. Because <NUM> kips exceeds <NUM> kips, the control logic <NUM> then proceeds to step <NUM>.

At step <NUM>, the control logic <NUM> can determine if the first confidence threshold is exceeded; in this example, the first confidence threshold can be <NUM>%. Because the confidence level determined at step <NUM> in this example was <NUM>%, the control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can determine if the second confidence threshold is exceeded; in this example, the second confidence threshold can be <NUM>%. Because the control logic <NUM> determined the confidence level to be <NUM>% in this example, the control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can generate an alert with an assigned Level <NUM> severity level. The control logic <NUM> then terminates or awaits a new vehicle detection and can repeat the aforementioned steps.

Advantageously, the force thresholds and confidence thresholds discussed herein can be of any suitable value, depending on the desired alert severity level assignments. For example, lowering the force thresholds can, in one embodiment, cause alerts with higher severity levels to be generated for vehicles applying less force to a track. In another example, decreasing confidence thresholds can also cause alerts with higher severity levels to be generated from received data with determinedly lower fidelity. In contrast, raising force thresholds and/or confidence thresholds can cause the control logic <NUM> to assign lower severity levels for higher impact forces determined from less accurate data.

<FIG> illustrates a flow chart diagram <NUM> exemplifying control logic embodying features and program steps of a wheel impact load detection (WILD) system, in accordance with an exemplary embodiment of the present disclosure. The WILD system control logic <NUM> can be implemented as an algorithm on a server (e.g., server <NUM>), a machine learning module, or other suitable system. Additionally, the WILD system control logic <NUM> can implement or incorporate one or more features of the WILD system <NUM>, including the wild capture system <NUM> (with corresponding modules <NUM>, <NUM>, <NUM>, and <NUM>), wild calibration system <NUM> (with corresponding modules <NUM> and <NUM>), and alert management system <NUM> (with corresponding modules <NUM> and <NUM>). The control logic <NUM> can be achieved with software, hardware, an application programming interface (API), a network connection, a network transfer protocol, HTML, DHTML, JavaScript, Dojo, Ruby, Rails, other suitable applications, or a suitable combination thereof.

The control logic <NUM> process flow of the present embodiment begins at step <NUM>, where the control logic <NUM> can detect a vehicle, e.g., a vehicle traveling on a track. In one embodiment, a vehicle can be detected by measuring values that exceed a rest state or threshold from one or more strain gauges operably coupled to a train track. The control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can receive environmental data in accordance with the principles of the present disclosure. The control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can receive sensor data in accordance with the principles of the present disclosure. The control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can determine a max force value from the sensor data receive at step <NUM>, in accordance with the principles of the present disclosure. The control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can determine an original confidence level in accordance with the principles of the present disclosure. The control log then proceeds to step <NUM>.

At step <NUM>, the control logic <NUM> can determine if the max force value determined at step <NUM> exceeds a first force threshold. If the max force value exceeds the first force threshold, the control logic <NUM> then proceeds to step <NUM>. If the max force value does not exceed the first force threshold, the control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can determine that no alert will be generated. At step <NUM>, the control logic <NUM> can determine if the environmental data received at step <NUM> satisfies an environmental threshold. If the environmental data satisfies the environmental threshold, the control logic <NUM> then proceeds to step <NUM>. If the environmental data does not satisfy the environmental threshold, the control logic <NUM> then proceeds to step <NUM>.

At step <NUM>, the control logic <NUM> can reduce the original confidence level. In one embodiment, the confidence level can be reduced commensurate with the deviation of the environmental data from the environmental threshold. For example, if the environmental threshold is a temperature threshold of <NUM> °F, and the received environmental data indicates a temperature of <NUM> °F, the confidence level can be reduced further than if the receive environmental data indicated a temperature of, e.g., <NUM> °F. In another embodiment, the control logic <NUM> can utilize a similar equation as discussed above with respect to the force determination module <NUM> to adjust the confidence level as opposed to the max force value. In another embodiment, the control logic <NUM> can reduce the confidence level such that the confidence level falls below a confidence threshold. For example, if a first confidence threshold is <NUM>%, a second confidence threshold is <NUM>%, and the original confidence level is determined at step <NUM> to be <NUM>%, the control logic <NUM> can reduce the confidence level to <NUM>%, such that the first confidence threshold is not exceeded. The control logic <NUM> then proceeds to step <NUM>.

At step <NUM>, the control logic <NUM> can utilize the reduced confidence level determined at step <NUM> and the max force value determined at step <NUM> to assign a severity level in accordance with the principles of the present disclosure. The control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can generate an alert with the severity level assigned at step <NUM>, in accordance with the principles of the present disclosure. At step <NUM>, the control logic <NUM> can utilize the original confidence value determined at step <NUM> and the max force value determined at step <NUM> to assign a severity level in accordance with the principles of the present disclosure. The control logic <NUM> then proceeds to step <NUM>.

<FIG> illustrates a flow chart diagram <NUM> exemplifying control logic embodying features and program steps of a wheel impact load detection (WILD) method, in accordance with an exemplary embodiment of the present disclosure. The WILD method control logic <NUM> can be implemented as an algorithm on a server (e.g., server <NUM>), a machine learning module, or other suitable system. Additionally, the WILD method control logic <NUM> can implement or incorporate one or more features of the WILD system <NUM>, including the wild capture system <NUM> (with corresponding modules <NUM>, <NUM>, <NUM>, and <NUM>), wild calibration system <NUM> (with corresponding modules <NUM> and <NUM>), and alert management system <NUM> (with corresponding modules <NUM> and <NUM>). The control logic <NUM> can be achieved with software, hardware, an application programming interface (API), a network connection, a network transfer protocol, HTML, DHTML, JavaScript, Dojo, Ruby, Rails, other suitable applications, or a suitable combination thereof.

The control logic <NUM> process flow of the present embodiment begins at step <NUM>, where the control logic <NUM> can detect a vehicle, e.g., a vehicle traveling on a track. The control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can receive environmental data in accordance with the principles of the present disclosure. The control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can receive sensor data in accordance with the principles of the present disclosure. The control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can determine a max force value from the sensor data receive at step <NUM>, in accordance with the principles of the present disclosure. The control logic <NUM> then proceeds to step <NUM>.

At step <NUM>, the control logic <NUM> can determine if the max force value determined at step <NUM> exceeds a force threshold, in accordance with the principles of the present disclosure. If the max force value exceeds the force threshold, the control logic <NUM> then proceeds to step <NUM>. If the max force value does not exceed the force threshold, the control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can determine that no alert will be generated.

At step <NUM>, the control can determine if the environmental data received at step <NUM> satisfies an environmental threshold. If the environmental data satisfies the environmental threshold, the control logic <NUM> then proceeds to step <NUM>. If the environmental data does not satisfy the environmental threshold, the control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> can assign a severity level. In one embodiment, the control logic <NUM> can assign a severity level without reference to a max force value. In another embodiment, the control logic <NUM> can assign a severity level that indicates that the environmental threshold was satisfied. For example, if the environment threshold is satisfied at step <NUM>, the control logic <NUM> can assign the same severity level to all potential alerts, regardless of the max force value. At step <NUM>, the control logic <NUM> can utilize the max force value determined at step <NUM> in assigning a severity level, in accordance with the principles of the present disclosure. The control logic <NUM> then proceeds to step <NUM>. At step <NUM>, the control logic <NUM> generates an alert with the severity level assigned instep <NUM> or step <NUM>, in accordance with the principles of the present disclosure.

It will be understood by those having skill in the art that the systems and methods disclosed herein can implement numerous force thresholds, confidence thresholds, and environmental thresholds within the same process flow to tailor the alert generation and severity level assignments to fit specific needs. In one embodiment, environmental thresholds of different types can be used in the same flow-for example, a process flow can include a temperature threshold, a pressure threshold, a humidity threshold, and/or any other type of environmental threshold related to environmental conditions that can affect wheel impact load detection. In another embodiment, a factor of time can be included the environmental thresholds, or instead be thresholds themselves. For example, an environmental threshold can require that a specific temperature be exceeded for a specific period of time before the threshold can be satisfied; in another example, an environmental threshold can require a temperature to be constantly below a specific temperature for a specific period of time before the threshold can be satisfied. In another embodiment, the systems and methods disclosed herein can incorporate time thresholds that can affect the assignment of severity levels. For example, if an environmental threshold is satisfied for a duration of time, an assigned severity level can be lower than if the environmental threshold was satisfied for a comparatively longer duration. In another embodiment, environmental data and an environmental threshold can refer to the environment of a rail. For example, environmental data can include the temperature of a rail, and an environmental threshold can include a temperature threshold related to the temperature of the rail.

The present disclosure achieves at least the following advantages:.

Persons skilled in the art will readily understand that these advantages (as well as the advantages indicated in the summary) and objectives of this system 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. It will be further understood that a variety of programming tools, known to persons skilled in the art, are available for implementing the control of the features and operations described in the foregoing material. Moreover, the particular choice of programming tool(s) may be governed by the specific objectives and constraints placed on the implementation plan selected for realizing the concepts set forth herein and in the appended claims.

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.

Claim 1:
A system for generating railroad alerts related to wheel impact load detection sensor data, comprising:
a memory (<NUM>) having a first database with a plurality of sensor data, thresholds, and specifications related to a vehicle and at least a portion of a track; and
a networked computer processor (<NUM>) operably coupled to the memory (<NUM>) and capable of executing machine-readable instructions (<NUM>) to perform program steps, the program steps including:
detecting the vehicle on the track;
receiving environmental data related to an environmental condition;
receiving sensor data corresponding to a force or forces exerted by the vehicle on the track;
determining an original max peak force from the sensor data;
comparing the original max peak force with a first force threshold;
if the original max peak force exceeds the first force threshold:
determining if the environmental data satisfies an environmental threshold, wherein the environmental threshold is related to an environmental condition that can affect wheel impact load detection; and
if the environmental data satisfies the environmental threshold, generating, via the processor, a calibrated max peak force;
utilizing either the original max peak force or the calibrated max peak force in assigning a severity level;
generating an alert including the severity level; and
if the original max peak force is below the first force threshold, no alert is generated.