Patent Description:
The present disclosure generally relates to a system, method and apparatus for fleet management in vehicular telemetry environments. More specifically, the present disclosure relates to monitoring and predicting component maintenance before an actual component failure to maximize maintainability and operational status of a fleet of vehicles thereby avoiding a vehicle breakdown.

Maintainability and identification of component failure is an important aspect of fleet management. One past approach is to consider the Mean Time Between Failure engineering data to predict the elapsed time between inherent failures during normal operation of the vehicle. Another past approach is to apply the manufacturer's recommended vehicle maintenance schedule. These past approaches are based upon a running total of mileage or running total of operational time. Simple comparisons of numbers are limited and inconclusive. Comparing a current value with some previous value cannot accurately predict component failure.

One past application of telematics is <CIT>(<CIT> for a method and system for condition monitoring of vehicles.

Another past application of telematics is <CIT> (<CIT> for a method and system for monitoring a mobile equipment fleet. Another past application of telematics is <CIT> (<CIT> for a vehicle customization and personalization activities. Another past application of telematics is <CIT> (<CIT> for a vehicle customization and personalization activities. Patent publication <CIT> discusses further information that is useful for understanding the background of the invention.

The present disclosure is directed to methods and systems for identifying real-time component remaining effective life status parameters of an electrical system of a vehicle according to the appended claims.

According to a non-claimed example there is provided a system for identifying real time component remaining effective life status parameters of a vehicle component, the vehicle component having a service life span associated therewith when new. The system comprises a telematics hardware device comprising a processor, memory, firmware and communications capability; a remote device comprising a processor, memory, software and communications capability; the telematics hardware device monitoring at least one vehicle component from at least one vehicle and logging operational component data of the at least one vehicle component, the telematics hardware device communicating a log of operational component data to the remote device; the remote device accessing at least one record of operational component data, the operational component data comprising operational values from at least one vehicle component from at least one vehicle, the operational values representative of operational life cycle use of the at least one vehicle component, the operational values further based upon a measured component event; the remote device storing a minimum operational threshold value representative of a failing health condition of the vehicle component based upon the measured component event and a maximum operational threshold value representative of an optimal health condition of the vehicle component based upon the measured component event; the remote device normalizing each of the operational values (X) of the operational component data with the minimum and maximum threshold values to identify normalized real time component health status parameters of the vehicle component; and, the remote device associating the normalized real-time component health status parameters with the service life span of the vehicle component to identify the real time component remaining effective life status parameters of the vehicle component.

According to a second broad aspect there is provided a method to identify real time component remaining effective life status parameters of a vehicle component according to claim <NUM>.

According to a third broad aspect there is provided a system for identifying real time component remaining effective life status parameters of an electrical system of a vehicle according to claim <NUM>.

Additional aspects are provided in the dependent claims.

Exemplary non-limiting embodiments are described with reference to the accompanying drawings in which:.

The drawings are not necessarily to scale and are diagrammatic representations of the exemplary non-limiting embodiments of the present invention.

Described herein are techniques for monitoring operational components of vehicle, comprising electrical components and other components of a vehicle, to generate information on a state of an operational component over time and to generate a prediction of whether and/or when an operational component is likely to fail. In some embodiments, for each operational component that is monitored in this manner, one or more signals, generated by the operational component during an event that corresponds to a particular operation of the operational component, are monitored and characteristic values of the operational parameter(s) generated by the component during the event are determined (e.g., through statistical analysis of the signals to identify inflection points of the signals indicative of failing operation health of the component) and used in generating a real time component health indicator or parameter of the component as well as the prediction of whether and/or when the operational component is likely to fail. The prediction generated in this manner may be reliably used to determine whether and when to perform maintenance on a vehicle, to repair or replace the operational component before failure and to forecast demand for upcoming maintenance on the vehicle.

Such techniques for generating real time component health parameters and predictions of whether and/or when an operational component is likely to fail may be advantageous in some environments. Conventionally, there was no reliable way to predict when an operational component would fail. Manufacturers often publish information on their products, comprising "mean time between failure" (MTBF) information, that may indicate when the manufacturer expects a failure might occur. Unfortunately, this product information is wholly unreliable. Manufacturers tend to be very cautious in setting these product life estimates. This not only mitigates the risk of a product unexpectedly failing earlier than predicted, which may lead to a product owner suffering inconvenience from a product failure, but also encourages purchase of replacement products early, which may benefit the manufacturer as over time more products are purchased than otherwise would be. However, while early replacement benefits the manufacturer, early replacement is an unnecessary expense to a product owner. When a product owner owns hundreds or thousands of vehicles, over time, early and unnecessary replacement of parts can add up to a substantial cost, potentially millions of dollars, as compared to timely or just in time replacement.

Additionally, past approaches generated such product lifespan estimates using assumptions related to normal operation of a vehicle based upon a pre-established set of operating conditions, which may include operational criteria for a vehicle. In reality, vehicles are typically operated outside of such pre-established operating conditions such as, for example, a range of altitudes from sea-level to several thousand feet above sea-level, extreme cold temperatures, extreme hot temperatures, on highly rough roads causing significant vibration, and in mountainous terrains or flat terrains as well as other operational criteria. Vehicles may also be operated through four seasons that create four distinct operational environments. Operating a vehicle outside of normal operating conditions impacts the frequency and time between failures. Of course, few vehicles may have been operated perfectly within the assumptions that underlay the product lifespan estimates, undermining the reliability of the estimates for (or even making the estimates useless for, in some cases) real-world purposes.

Given the unreliability of manufacturer estimates, owners of such fleets of vehicles have therefore, conventionally, attempted to generate their own approximate predictions of failures of operational components, based primarily on time since an operational component was installed. Fleet owners are well aware, however, that this is also notoriously unreliable. Particularly when a fleet is used over a wide geographic area (e.g., a whole country), different vehicles in a fleet may encounter vastly different operating conditions, such as different environmental factors, road conditions, different operating styles that may yield different characteristics of vehicle operation (e.g., greater acceleration, greater speed, harder braking, more frequent engine turn offs and start-ups, etc.), different distances traveled, different loads carried, or other factors that influence operation of the vehicle. When there is significant variation in operating conditions, there may be significant variation in life span of operational components of a vehicle, comprising the operating conditions discussed in the preceding paragraph. Accordingly, while fleet owners may create a maintenance schedule for their vehicles to repair or replace operational components, such a schedule may not reliably predict failures in individual vehicles. Vehicles may therefore experience failures prior to a planned maintenance, which can significantly increase costs for fleet owners that may need to tow a vehicle to be repaired, repair the vehicle, make arrangements for transporting people and/or cargo that had been being transported by the failed vehicle, and accommodate schedule delays from the change in transportation of the people/cargo. These may be significant costs. As a result, as with manufacturer estimates, some fleet owners may replace operational components earlier than may be needed, which has its own substantial costs, as discussed above.

This lack of reliable real time component health status parameters of a vehicle being available to fleet owners and the lack of reliable prediction systems for failure or deterioration of vehicle operational components has presented difficulties to vehicle fleet operators for decades, and costs such fleet owners millions of dollars. The inventor has recognized and appreciated that there would be significant advantages for fleet owners if a reliable form of prediction could be offered.

The inventor recognized and appreciated the advantages that would be offered by a reliable prediction system that would monitor a vehicle and operational components of a vehicle in real time, during use of the vehicle, to generate a real time component health status parameter and a prediction specific to that vehicle and specific to that time. Such a system that generates a health status parameter and a prediction unique to each vehicle would have advantages over systems that generate information on average lifespans of products, given the significant inter-vehicle variation mentioned above, resulting from differences in operating conditions, comprising differences in operating environments. Moreover the inventor has recognized and appreciated that standardizing and or normalizing real time component health status parameters relative to vehicles in a vehicle class may make available to fleet owners standardized and or normalized fleet health data that is not vehicle class dependent. The inventor has further recognized and appreciated that normalization of fleet health data may be associated with component known lifespan to predict real time component remaining effective life.

The inventor has further recognized and appreciated that such an analysis may be conducted using data generated by vehicular telemetry systems of vehicles. Vehicular telemetry systems may include a hardware device to monitor and log a range of vehicle parameters, component parameters, system parameters and sub-system parameters in real time. An example of such a device is a Geotab® GO™ device available from Geotab, Inc. of Oakville, Ontario Canada (www. The Geotab® GO™ device interfaces to the vehicle through an on-board diagnostics (OBD) port to gain access to the vehicle network and engine control unit. Once interfaced and operational, the Geotab® GO™ device monitors the vehicle bus and creates of log of raw vehicle data. The Geotab® GO™ device may be further enhanced through an I/O expander (also available from Geotab, Inc. ) to access and monitor other variables, sensors, devices, components, systems and subsystems resulting in a more complex and larger log of raw data. Additionally, the Geotab® GO™ device may further include a GPS capability for tracking and logging raw GPS data. The Geotab® GO™ device may also include an accelerometer for monitoring and logging raw accelerometer data. The Geotab® GO™ device may also include a capability to monitor atmospheric conductions such as temperature and altitude. The inventor thus recognized and appreciated that vehicle telemetry systems may collect types of data that, if combined with analysis techniques that analyze the data in a particular manner, could be used to generate a reliable prediction of whether and/or when an operational component will fail.

However, the inventor additionally recognized and appreciated that, when monitoring an operational component of a vehicle, that operational component may demonstrate significant variability in the signals generated by the operational component and that be monitored. Such variability presents an impediment to establishing clear analyses that could be used to determine whether a component is deteriorating or failing. For example, while an operational component under ideal operating conditions may, while failing, generate an operational parameter having a particular value, under non-ideal operating conditions that same component might produce an operational parameter that appears similar to that value associated with a failure, even when the operational component is not failing. Even for operational components that do not typically experience such a wide swing in values between conditions, the impact of variation in operating conditions introduces noise into a signal that substantially complicates analysis and prediction.

Generation of reliable real-time prediction and health status parameters is further complicated by effects of other operational components of the vehicle on a monitored operational component. In some events in which an operational component may be used, the operational component may interact with one or more other operational components of the vehicle. The failure or deterioration of these other operational components may affect operational parameters generated by the operational component being monitored. This impact could cause signals to be generated by the monitored operational component that appear as if the operational component is deteriorating or failing, even in the case that the operational component is not deteriorating or failing. Similarly, deterioration or failure of an operational component could be masked by its interaction with other operational components, or it may be difficult to determine which operational component is deteriorating or failing.

The inventor has thus recognized and appreciated that, in some embodiments, monitoring operating conditions of an operational component may aid in generating a reliable prediction of whether and/or when an operational component will fail, or aid in increasing reliability of such a prediction. Such operating conditions may include environmental conditions, such as conditions in which a vehicle is being operated, including climate or weather conditions (temperature, humidity, altitude, etc.), characteristics of vehicle operation (e.g., characteristics of acceleration, speed, braking, etc.), distance traveled, loads carried, road conditions, or other factors that influence operation of the vehicle. Operating conditions of an operational component may additionally or alternatively include information on other operational components of the vehicle, or of maintenance performed on operational components. Signals generated by an operational component may be contextualized by that operating condition information. The contextualization may aid in generating reliable predictions of deterioration or failure, such as by eliminating potential noise or environment-triggered variation in operational parameters.

Variation in operation signals may additionally be accounted for, or mitigated, in some embodiments by monitoring operational components through generation of statistical values that characterize operational parameters generated by an operational component over time. Such statistical values may characterize an operational parameter in various ways, including describing a maximum value of a signal over a time period, a minimum value of a signal over a time period, an average value of a signal over a time period, a change in a signal over a time period, a variance of a signal over a time period, one or more operational thresholds of a signal over a time period or other value that may be calculated or identified from a statistical analysis of an operational parameter over time. Different time periods may be used for calculating different statistical values. For example, some statistical values may be calculated from an analysis of values of an operational parameter generated during a time period corresponding to one or more events in which the operational component performed an action, or interacted with other operational components of the vehicle to collectively perform an action.

The inventor has further recognized and appreciated that additional complexity may be introduced into monitoring of an operation component by the number of different operational parameters that may be generated by an operational component, and the number of statistical analyses that can be performed on these different operational parameters over time. As mentioned in the preceding paragraph, in some embodiments, operational parameters generated by an operational component specific to an event may be monitored and used to generate statistical values. Such an event may correspond to an action performed by one or more operational components of the vehicle. Over time, some operational components may perform multiple different actions, and thus there may be a large number of events that could be monitored. An operational component may engage in each action in a different way, or each action may have a different impact on an operational component. As a result, different operational parameters may be generated. Moreover, when different operational parameters are generated, there may be different characteristics of the operational parameter that would be associated with proper operation, deterioration, or failure of the operational component. These different characteristics may be reflected in different statistical analyses. Accordingly, identifying, even for one operational component, a manner in which to analyze operational parameters to predict whether and/or when the operational component may fail is complex.

The inventor has recognized and appreciated that by monitoring a large group of vehicles, with the same or similar operation components, over time, in different operating conditions, and collecting different operation signals over time, may enable selection of one or more particular events to monitor for an operational component, and particular statistical analyses to perform of operational parameters generated during the event(s). Operational parameters collected for operation components of the large group of vehicles may be analyzed, together with information on events that occurred at times the operation signals were generated, to determine events and changes in operational parameters that are correlated with deterioration or failure of an operational component. For example, events and changes in operational parameters that are correlated to the health status of an operational component during its operational life may be determined from the analysis. Based on identified correlations, one or more events to monitor and one or more statistical analysis to perform on operational parameters generated during the event(s) may be determined. By identifying the event(s) and statistical analysis(es), a prediction process may be created based on the event(s) and the statistical analysis(es) that leverages the correlation and can generate a prediction of a health condition of an operation component when operational parameters from such an event are detected. More particularly, for example, when a statistical analysis of operational parameters from an event satisfy one or more conditions that, based on the analysis of the operational parameters for the large group of vehicles, is correlated with a deterioration of an operational component, the prediction process may determine that the operational component is deteriorating. As another example, when a statistical analysis of operational parameters from an event satisfy one or more conditions that, based on the analysis of the operational parameters for the large group of vehicles, is correlated with a failure of an operational component at the event and/or is correlated with optimal performance of the operational component at the event, the prediction process may determine the health of operational component.

Accordingly, described herein are techniques for collecting and analyzing one or more operational parameters generated by one or more operational components during an event, and based on an analysis of the one or more operational parameters, generating a prediction of the real time health of a particular operational component and/or a prediction of whether and/or when a particular operational component will deteriorate or fail. Some techniques described herein may be used to determine, from an analysis of the operational parameters, a current health status of an operational component, which may characterize how current operation of the operational component compares to operation of the operational component when failing (e.g., whether the operational component has reached or is about to reach a failing health condition at which the component fails to provide reliable operation).

In some such embodiments, operational parameters generated by a first operational component for which a prediction is generated may be contextualized in the analysis with other information. Such other information may include operational parameters generated by one or more other operational components at a time (e.g., during an event) that the operational parameters of the first operational component were generated. Such other information may additionally or alternatively include information on operating conditions of the vehicle. Such other information may additionally or alternatively include information on a maintenance schedule of a vehicle and/or an operational component, such as past completed maintenance (including repair or replacement) and planned future maintenance.

In some embodiments, the vehicle may be a truck and the operational component may be a battery. Clearly, a battery is used over a long period of time and in connection with a large number of events. Operational parameters may be generated by the battery throughout this time, and corresponding to any one of the large number of events. Additionally, a large number of different statistical analyses could be performed on these operational parameters. The inventor recognized and appreciated, however, that operational parameters generated during a particular type of event may be useful in generating a prediction of whether the battery is deteriorating, failing or when the battery will fail. The inventor further recognized and appreciated that a prediction of whether a battery is deteriorating, failing or about to fail may be symptomatic of other electrical system deterioration or failures related to, as example, battery cables, the starter motor and/or the alternator. Moreover, the inventor recognized and appreciated that analyzing such operational parameters in the context of particular statistical analyses to ascertain one or more event threshold operational values for the battery together with an analysis of the real time operational event parameters would yield reliable health status information on the battery that may be useful in predicting whether and/or when the battery will deteriorate or fail. The inventor further recognized and appreciated that standardization and/or normalization of such operational event parameters in the context of one or more threshold operational values provides a health status rating for specific vehicles that fleet owners may apply uniformly across vehicles of the same vehicle class or different vehicle classes. Moreover, the inventor recognized and appreciated that normalization of such operational event parameters with new and failing threshold values when associated with component life span data provides a remaining effective life valuation upon which fleet owners may predict time lines for component replacement and may allow fleet owners to budget both time and costs associated with component replacement.

In particular, the inventor recognized and appreciated that a starter motor event generates operational parameters that may be advantageously used in determining a status of a battery, and that evaluating minimum voltages during starter motor events over time, may be advantageous in generating a reliable prediction of whether and/or when the battery will fail. The inventor also recognized and appreciated that other components and parameters in association with the starter motor event may be beneficial to determining the status of a battery such as air temperature, oil temperature, coolant temperature, road conditions (vibrations detected by an accelerometer) and altitudes.

During a starter motor event, the starter motor will draw energy from the battery. An operational parameter may be generated by the battery, or by a sensor that operates with the battery, that indicates a voltage of the battery over a time corresponding to the event. The event may last from a time that energy starts being drawn from the battery for the starter motor through a time that the engine of the vehicle has been successfully started and an alternator is supplying electrical energy to the battery. Over this time, the voltage of the battery may drop before rising again once the battery is being charged by the alternator. The operational parameters for this event may indicate a voltage of the battery over time, demonstrating the drop and then rise in voltage. A statistical analysis may be performed for a starter motor event to identify a maximum and minimum value of the voltage during the starter motor event. Alternatively, a statistical analysis may be performed for multiple starter motor events to calculate, over a period of time (e.g., a number of starter motor events), minimum voltages from individual starter motor events.

From this statistical analysis, the inventor recognized and appreciated that focusing on the minimum value of battery voltages during respective cranking events are key health predictive parameters for the batteries when under load. A statistical analysis may be performed of these key health predictive parameters on a real time basis to determine a distribution curve of battery voltages for the same class of vehicles in a fleet during and under load of the cranking events. From the distribution curve or histogram of minimum value of battery voltages during load cranking events, the inventor recognized and appreciated that minimum and maximum operational threshold voltage values of battery voltage may be identified respectively representing a failing health condition (for example, a battery no longer reliable to provide sufficient voltage to enable start-up of the vehicle) and an optimal health condition (for example a new battery) for batteries in the same class of vehicles in the fleet. Moreover, an analysis of the minimum value of battery voltages during cranking events for each battery when associated with one or more of the minimum and maximum operational threshold voltage values may be used to identify a the real time battery health condition independent of battery and/or vehicle class. The health condition of the battery may be useful in generating a prediction of whether and/or when the battery may fail and result in a maintenance work order being sent to the fleet owner, and may also identify remaining lifespans of batteries from which the owner may forecast battery replacement costs and vehicle maintenance. The inventor recognized and appreciated that standardizing real time health status battery parameters relative to the minimum operational threshold voltage value to have a mean of zero provides an inflection point common to all vehicles in the owner's fleet regardless of the class of the vehicle providing a standardized battery parameter corresponding to a failing or about to fail battery operating condition. The inventor further recognized and appreciated that normalizing real time health status battery parameters relative to the minimum operational threshold voltage value and the maximum operation health value provides a health status rating for each battery of vehicles in the fleet that fleet owners can apply uniformly across vehicles of the same vehicle class or different vehicle classes. The inventor recognized and realized that this normalization of the health status rating may be represented and communicated to a fleet owner as a probability or a numerical representation of that probability such as, for example, one or more of scaling, rounding, and as a percentage. The inventor recognized and appreciated that statistical normalization of the real time health of battery parameters of batteries in a fleet of vehicles provides a health probability that can be associated with an expected life span of the battery thereby providing real time remaining life span information for each battery in the fleet of vehicles.

It should be appreciated that embodiments described herein may be used in connection with any of a variety of vehicles and operational components of a vehicle. Embodiments are not limited to operating in connection with any particular operational component, any particular type of operational component, or any particular type of vehicle. Accordingly, while an example was given above of how the system may be used in connection with an operational component that is a battery of a truck, and that example is used occasionally below to illustrate how a particular technique may be implemented in some embodiments, it should be appreciated that the example is merely illustrative and that other embodiments may operate with other operational components or other vehicles. Accordingly, while specific examples of embodiments are described below in connection with <FIG>, it should be appreciated that embodiments are not limited to operating in accordance with the examples and that other embodiments are possible.

Referring to <FIG> of the drawings, there is illustrated one embodiment of a high level overview of a vehicular telemetry environment and infrastructure. There is at least one mobile device or vehicle generally indicated at <NUM>. The vehicle <NUM> includes a vehicular telemetry hardware system <NUM> and a resident vehicular portion <NUM>. Optionally connected to the telemetry hardware system <NUM> is at least one intelligent I/O expander <NUM> (not shown in <FIG> - see <FIG>). In addition, there may be at least one wireless communication module such as Bluetooth® wireless communication module <NUM> (not shown in <FIG> - See <FIG>) for communication with at least one of the vehicular telemetry hardware system <NUM> or the intelligent I/O expander <NUM>.

The vehicular telemetry hardware system <NUM> monitors and logs a first category of raw telematics data known as vehicle data. The vehicular telemetry hardware system <NUM> may also log a second category of raw telematics data known as GPS coordinate data and may also log a third category of raw telematics data known as accelerometer data.

The intelligent I/O expander <NUM> may also monitor a fourth category of raw expander data. A fourth category of raw data may also be provided to the vehicular telemetry hardware system <NUM> for logging as raw telematics data.

The Bluetooth® wireless communication module <NUM> may also be in periodic communication with at least one beacon such as Bluetooth® wireless communication beacon <NUM> (not shown in <FIG> - see <FIG>). The at least one Bluetooth® wireless communication beacon may be attached or affixed or associated with at least one object associated with the vehicle <NUM> to provide a range of indications concerning the objects. These objects include, but are not limited to packages, equipment, drivers and support personnel. The Bluetooth® wireless communication module <NUM> provides this fifth category of raw object data to the vehicular telemetry hardware system <NUM> either directly or indirectly through an intelligent I/O expander <NUM> for subsequent logging as raw telematics data.

Persons skilled in the art appreciate the five categories of data are illustrative and only one or a suitable combination of categories of data or additional categories of data may be provided. In this context, a category of raw telematics data is a grouping or classification of a type of similar data. A category may be a complete set of raw telematics data or a subset of the raw telematics data. For example, GPS coordinate data is a group or type of similar data. Accelerometer data is another group or type of similar data. A log may include both GPS coordinate data and accelerometer data or a log may be separate data. Persons skilled in the art also appreciate the makeup, format and variety of each log of raw telematics data in each of the categories is complex and significantly different. The amount of data in each of the categories is also significantly different and the frequency and timing for communicating the data may vary greatly. Persons skilled in the art further appreciate the monitoring, logging and the communication of multiple logs or raw telematics data results in the creation of raw telematics big data.

The vehicular telemetry environment and infrastructure also provides communication and exchange of raw telematics data, information, commands, and messages between the at least one server <NUM>, at least one computing device <NUM> (remote devices such as desktop computers, hand held device computers, smart phone computers, tablet computers, notebook computers, wearable devices and other computing devices), and vehicles <NUM>. In one example, the communication <NUM> is to/from a satellite <NUM>. The satellite <NUM> in turn communicates with a ground-based system <NUM> connected to a computer network <NUM>. In another example, the communication <NUM> is to/from a cellular network <NUM> connected to the computer network <NUM>. Further examples of communication devices include Wi-Fi® wireless communication devices and Bluetooth® wireless communication devices connected to the computer network <NUM>.

Computing device <NUM> and server <NUM> with corresponding application software communicate over the computer network <NUM> may be provided. In an embodiment, the myGeotab™ fleet management application software <NUM> runs on a server <NUM>. The application software may also be based upon Cloud computing. Clients operating a computing device <NUM> communicate with the myGeotab™ fleet management application software running on the server <NUM>. Data, information, messages and commands may be sent and received over the communication environment and infrastructure between the vehicular telemetry hardware system <NUM> and the server <NUM>.

Data and information may be sent from the vehicular telemetry hardware system <NUM> to the cellular network <NUM>, to the computer network <NUM>, and to the at least one server <NUM>. Computing devices <NUM> may access the data and information on the servers <NUM>. Alternatively, data, information, and commands may be sent from the at least one server <NUM>, to the network <NUM>, to the cellular network <NUM>, and to the vehicular telemetry hardware system <NUM>.

Data and information may also be sent from vehicular telemetry hardware system to an intelligent I/O expander <NUM>, to a satellite communication device such as an Iridium® satellite communication device available from Iridium Communications Inc. of McLean, Virginia, USA, the satellite <NUM>, the ground based station <NUM>, the computer network <NUM>, and to the at least one server <NUM>. Computing devices <NUM> may access data and information on the servers <NUM>. Data, information, and commands may also be sent from the at least one server <NUM>, to the computer network <NUM>, the ground based station <NUM>, the satellite <NUM>, the satellite communication device, to an intelligent I/O expander <NUM>, and to a vehicular telemetry hardware system.

The methods or processes described herein may be executed by the vehicular telemetry hardware system <NUM>, the server <NUM> or any of the computing devices <NUM>. The methods or processes may also be executed in part by different combinations of the vehicular telemetry hardware system <NUM>, the server <NUM> or any of the computing devices <NUM>.

Referring now to <FIG> of the drawings, there is illustrated a vehicular telemetry hardware system generally indicated at <NUM>. The on-board portion generally includes: a DTE (data terminal equipment) telemetry microprocessor <NUM>; a DCE (data communications equipment) wireless telemetry communications microprocessor <NUM>; a GPS (global positioning system) module <NUM>; an accelerometer <NUM>; a non-volatile memory <NUM>; and provision for an OBD (on board diagnostics) interface <NUM> for communication <NUM> with a vehicle network communications bus <NUM>.

The resident vehicular portion <NUM> generally includes: the vehicle network communications bus <NUM>; the ECM (electronic control module) <NUM>; the PCM (power train control module) <NUM>; the ECUs (electronic control units) <NUM>; and other engine control/monitor computers and microcontrollers <NUM>.

While the system is described as having an on-board portion <NUM> and a resident vehicular portion <NUM>, it is also understood that this could be either a complete resident vehicular system or a complete on-board system.

The DTE telemetry microprocessor <NUM> is interconnected with the OBD interface <NUM> for communication with the vehicle network communications bus <NUM>. The vehicle network communications bus <NUM> in turn connects for communication with the ECM <NUM>, the engine control/monitor computers and microcontrollers <NUM>, the PCM <NUM>, and the ECU <NUM>.

The DTE telemetry microprocessor <NUM> has the ability through the OBD interface <NUM> when connected to the vehicle network communications bus <NUM> to monitor and receive vehicle data and information from the resident vehicular system components for further processing.

As a brief non-limiting example of a first category of raw telematics vehicle data and information, the list may include one or more of but is not limited to: a VIN (vehicle identification number), current odometer reading, current speed, engine RPM, battery voltage, cranking event data, engine coolant temperature, engine coolant level, accelerator pedal position, brake pedal position, various manufacturer specific vehicle DTCs (diagnostic trouble codes), tire pressure, oil level, airbag status, seatbelt indication, emission control data, engine temperature, intake manifold pressure, transmission data, braking information, mass air flow indications and fuel level. It is further understood that the amount and type of raw vehicle data and information will change from manufacturer to manufacturer and evolve with the introduction of additional vehicular technology.

Continuing now with the DTE telemetry microprocessor <NUM>, it is further interconnected for communication with the DCE wireless telemetry communications microprocessor <NUM>. In an embodiment, an example of the DCE wireless telemetry communications microprocessor <NUM> is a Leon <NUM>™, which is commercially available from u-blox Corporation of Thalwil, Switzerland (www. The Leon <NUM>™ wireless telemetry communications microprocessor provides mobile communications capability and functionality to the vehicular telemetry hardware system <NUM> for sending and receiving data to/from a remote site <NUM>. A remote site <NUM> could be another vehicle or a ground based station. The ground-based station may include one or more servers <NUM> connected through a computer network <NUM> (see <FIG>). In addition, the ground-based station may include computer application software for data acquisition, analysis, and sending/receiving commands to/from the vehicular telemetry hardware system <NUM>.

The DTE telemetry microprocessor <NUM> is also interconnected for communication to the GPS module <NUM>. In an embodiment, an example of the GPS module <NUM> is a Neo-<NUM>™ also commercially available from u-blox Corporation. The Neo-<NUM>™ provides GPS receiver capability and functionality to the vehicular telemetry hardware system <NUM>. The GPS module <NUM> provides the latitude and longitude coordinates as a second category of raw telematics data and information.

The DTE telemetry microprocessor <NUM> is further interconnected with an external non-volatile memory <NUM>. In an embodiment, an example of the memory <NUM> is a <NUM> MB non-volatile memory store commercially available from Atmel Corporation of San Jose, California, USA. The memory <NUM> is used for logging raw data.

The DTE telemetry microprocessor <NUM> is further interconnected for communication with an accelerometer <NUM>. An accelerometer (<NUM>) is a device that measures the physical acceleration experienced by an object. Single and multi-axis models of accelerometers are available to detect the magnitude and direction of the acceleration, or g-force, and the device may also be used to sense orientation, coordinate acceleration, vibration, shock, and falling. The accelerometer <NUM> provides this data and information as a third category of raw telematics data.

In an embodiment, an example of a multi-axis accelerometer (<NUM>) is the LIS302DL™ MEMS Motion Sensor commercially available from STMicroelectronics of Geneva, Switzerland. The LIS302DL™ integrated circuit is an ultra compact low-power three axes linear accelerometer that includes a sensing element and an IC interface able to take the information from the sensing element and to provide the measured acceleration data to other devices, such as a DTE Telemetry Microprocessor (<NUM>), through an I2C/SPI (Inter-Integrated Circuit) (Serial Peripheral Interface) serial interface. The LIS302DL™ integrated circuit has a user-selectable full-scale range of +-<NUM> and +-<NUM>, programmable thresholds, and is capable of measuring accelerations with an output data rate of <NUM> or <NUM>.

In an embodiment, the DTE telemetry microprocessor <NUM> also includes an amount of internal memory for storing firmware that executes in part, methods to operate and control the overall vehicular telemetry hardware system <NUM>. In addition, the microprocessor <NUM> and firmware log data, format messages, receive messages, and convert or reformat messages. In an embodiment, an example of a DTE telemetry microprocessor <NUM> is a PIC24H™ microcontroller commercially available from Microchip Technology Inc. of Westborough, Massachusetts, USA.

Referring now to <FIG> of the drawings, there is illustrated a vehicular telemetry hardware system generally indicated at <NUM> further communicating with at least one intelligent I/O expander <NUM>. In this embodiment, the vehicular telemetry hardware system <NUM> includes a messaging interface <NUM>. The messaging interface <NUM> is connected to the DTE telemetry microprocessor <NUM>. In addition, a messaging interface <NUM> in an intelligent I/O expander <NUM> may be connected by the private bus <NUM>. The private bus <NUM> permits messages to be sent and received between the vehicular telemetry hardware system <NUM> and the intelligent I/O expander, or a plurality of I/O expanders (not shown). The intelligent I/O expander hardware system <NUM> also includes a microprocessor <NUM> and memory <NUM>. Alternatively, the intelligent I/O expander hardware system <NUM> includes a microcontroller <NUM>. A microcontroller includes a CPU, RAM, ROM and peripherals. Persons skilled in the art appreciate the term processor contemplates either a microprocessor and memory or a microcontroller in all embodiments of the disclosed hardware (vehicle telemetry hardware system <NUM>, intelligent I/O expander hardware system <NUM>, wireless communication module <NUM> (<FIG>) and wireless communication beacon <NUM> (<FIG>)). The microprocessor <NUM> is also connected to the messaging interface <NUM> and the configurable multi-device interface <NUM>. In an embodiment, a microcontroller <NUM> is an LPC1756™ <NUM> bit ARM Cortec-M3 device with up to <NUM> KB of program memory and <NUM> KB SRAM, available from NXP Semiconductors Netherlands B. , Eindhoven, The Netherlands. The LPC1756™ also includes four UARTs, two CAN <NUM>. 0B channels, a <NUM>-bit analog to digital converter, and a <NUM> bit digital to analog converter. In an alternative embodiment, the intelligent I/O expander hardware system <NUM> may include text to speech hardware and associated firmware (not illustrated) for audio output of a message to an operator of a vehicle <NUM>.

The microprocessor <NUM> and memory <NUM> cooperate to monitor at least one device <NUM> (a device <NUM> and interface <NUM>) communicating with the intelligent I/O expander <NUM> over the configurable multi device interface <NUM> through bus <NUM>. Data and information from the device <NUM> may be provided over the messaging interface <NUM> to the vehicular telemetry hardware system <NUM> where the data and information is retained in the log of raw telematics data. Data and information from a device <NUM> associated with an intelligent I/O expander provides the <NUM>th category of raw expander data and may include, but not limited to, traffic data, hours of service data, near field communication data such as driver identification, vehicle sensor data (distance, time), amount and/or type of material (solid, liquid), truck scale weight data, driver distraction data, remote worker data, school bus warning lights, and doors open/closed.

Referring now to <FIG>, <FIG> and <FIG>, there are three alternative embodiments relating to the Bluetooth® wireless communication module <NUM> and Bluetooth® wireless communication beacon <NUM> for monitoring and receiving the 5th category of raw beacon data. The module <NUM> includes a microprocessor <NUM>, memory <NUM> and radio module <NUM>. The microprocessor <NUM>, memory <NUM> and associated firmware provide monitoring of beacon data and information and subsequent communication of the beacon data, either directly or indirectly through an intelligent I/O expander <NUM>, to a vehicular telemetry hardware system <NUM>.

In an embodiment, the module <NUM> is integral with the vehicular telemetry hardware system <NUM>. Data and information is communicated <NUM> directly from the beacon <NUM> to the vehicular telemetry hardware system <NUM>. In an alternate embodiment, the module <NUM> is integral with the intelligent I/O expander. Data and information is communicated <NUM> directly to the intelligent I/O expander <NUM> and then through the messaging interface <NUM> to the vehicular telemetry hardware system <NUM>. In another alternate embodiment, the module <NUM> includes an interface <NUM> for communication <NUM> to the configurable multi-device interface <NUM> of the intelligent I/O expander <NUM>. Data and information is communicated <NUM> directly to the module <NUM>, then communicated <NUM> to the intelligent I/O expander and finally communicated <NUM> to the vehicular telemetry hardware system <NUM>.

Data and information from a beacon <NUM>, such as the Bluetooth® wireless communication beacon provides the 5th category of raw telematics data and may include data and information concerning an object associated with the beacon <NUM>. In one embodiment, the beacon <NUM> is attached to the object. This data and information includes, but is not limited to, object acceleration data, object temperature data, battery level data, object pressure data, object luminance data and user defined object sensor data. This 5th category of data may be used to indicate, among others, damage to an article or a hazardous condition to an article.

Aspects disclosed herein relate to monitoring and optimally predicting health, replacement or maintenance of a vehicle component before failure of the component. Aspects disclosed herein relate to monitoring and optimally predicting health, replacement or maintenance of a vehicle component before failure of the component and providing standardized health status parameters and/or normalized health status rating parameters which may be understood across vehicles of differing characteristics. Aspects disclosed herein also relate to monitoring and predicting replacement of an electrical or electronic vehicle component before failure of the electrical component, or providing a real time electrical system health rating parameter. By way of an example only, the vehicle component may be a vehicle battery.

<FIG> illustrates a historical sample of raw big telematics data <NUM> over about a <NUM> month period of time for one vehicle. The sample is based upon a collection of multiple logs of data from the vehicular telemetry hardware system <NUM>. The sample pertains to the use of a vehicle component over the useful life, or life span, of the vehicle component from a new installation, normal use, failure and replacement. The raw big telematics data <NUM> reveals operational parameters around the process of vehicle component use and failure over several months of useful life. The raw big telematics data, or historical records of data, is obtained from at least one telematics hardware system in the form of a log of data that is communicated to a remote site. The operational values are further based upon a measured component event.

The y-axis is values of operational parameters for a vehicle component based upon a type of vehicle component event <NUM>. For example, the y-axis may be operational parameters for a vehicle battery during a starter motor cranking event where electrical energy is supplied by the vehicle battery to start an engine and then electrical energy is provided back to the vehicle battery to replenish the energy used by the starter motor cranking event (see <FIG>). The x-axis is values relating to time over the life cycle of the vehicle component, for example days, months and years. In an embodiment, the raw big telematics data <NUM> illustrates the maximum and minimum values for vehicle component battery voltages for numerous starter motor cranking events. The raw big telematics data <NUM> has two distinct patterns or trends on either side of a vehicle component event <NUM> where this event may be either one of a failure event <NUM> or a maintenance event <NUM> with respect to the vehicle component. The pattern post a vehicle component event <NUM> is a smaller or narrower variation of values on the y-axis and the magnitude of the values is greater.

The operational parameters evolve over time from a new vehicle component state to a failed vehicle component state wherein the magnitude of the operational parameters decreases over time and the variance increases over time until failure and installation of a new vehicle component. However, this embodiment concerns changes in magnitude of the operational parameters at the measurable component event. A few representative examples of operational components are vehicle batteries, starter motors, O2 sensors, temperature sensors and fluid sensors. Over continued use of the vehicle component, the operational parameters will change or evolve where the raw big telematics data <NUM> will decrease in magnitude. For an embodiment, the magnitude is a minimum battery voltage level based upon a vehicle component starter motor cranking event and the average minimal battery cranking voltage decreases over time and operational useful life. The vehicle component cranking event is an example of a measurable component event and an example of a maximum or significant operational load on the vehicle component in contrast to a minimal or lighter operational load on the vehicle component.

Referring now to <FIG>, the voltage versus time is illustrated for a good battery and a poor battery. <FIG> illustrates a good battery cranking event voltage curve. When the vehicle ignition key is activated, the voltage starts to decrease slightly followed by a very steep drop in the voltage. Then, after the cranking event has been completed, the voltage rises on a recharge slope within a dwell time where the voltage reaches a steady state for recharging the battery. <FIG> illustrates a poor battery cranking event voltage curve. The initial voltage is lower for the poor battery. When the vehicle ignition key is activated, the voltage starts to decrease slightly followed by a very steep drop in the in the voltage. Then, after the cranking event has been completed, the voltage rises on a more shallow recharge slope within a longer dwell time where again the voltage reaches a steady state for recharging the battery. In this embodiment, <NUM> voltage readings are recorded for each cranking event. The number of voltage readings could be lower, for example <NUM> or higher, for example <NUM>. From this collection of data readings either the minimum voltage of all these readings may be used or alternatively, an average of more than one of the readings may be used to arrive at the minimum voltage level based upon a vehicle component cranking event.

The raw big telematics data <NUM> representative of the vehicle component operational life cycle of <FIG> may be filtered to smooth out short-term fluctuations and highlight longer-term trends in the life cycle data. This is illustrated in <FIG>. The raw big telematics data <NUM> is filtered to provide a moving average <NUM> derived from the raw big telematics data <NUM>. Alternatively the moving average could be ranges of the data, averages of the data or the result of a low pass or impulse filter. In addition to the raw big telematics data <NUM> that is monitored, log and stored, additional vehicle component event <NUM> data is also provided. Vehicle component event <NUM> data is typically sourced differently and separately from the raw big telematics data <NUM> but may also be sourced with the raw big telematics data <NUM>. When sourced differently and separately, the vehicle component event <NUM> data is obtained from maintenance records or a vehicle maintenance database. The vehicle component event <NUM> data may include the type of event, the date of the event and time of the event. Vehicle component event <NUM> data includes at least one of either a failure event <NUM> or a maintenance event <NUM> concerning the vehicle component. The vehicle component event <NUM> data defines a known event with respect to the vehicle component and is associated with the moving average <NUM> representative of the raw big telematics data <NUM>. Individual values or data points of the moving average <NUM> data are steadily decreasing over time up to the point of the vehicle component event <NUM>. Immediately after the vehicle component event <NUM>, the individual values or data points of the moving average <NUM> data sharply increase over a shorter period of time and then maintain a relatively consistent moving average <NUM> going forward in time. The different patterns of the moving average <NUM> data are indications of a process change between a vehicle component good state, a poor state, a failed state, a new state and/or a refurbished state.

In an embodiment, <FIG> illustrates a voltage distribution of the moving average of operational values of vehicle components for all vehicles of like category, class or classification in a fleet of just over <NUM> vehicles for current or real time snap shot. The like category, class or classification of vehicles in a fleet may refer to vehicles in a fleet sharing common characteristics such as, for example, gas engine type, diesel engine type, and/or the number of batteries in the vehicle. In the embodiment, the vehicles in the fleet are of like engine and fuel type. The X axis represents the component operational value and the Y axis represents the vehicle count. In an embodiment, the operational values of voltage are a moving average of the minimum battery voltage for a cranking event. The inventor recognized and appreciated similar voltage distributions may be calculated for predetermined times from historical raw big telematics data for differing classes of vehicles and these distributions while similar in pattern may extend across different minimum voltage values for the batteries during a cranking event. Of the vehicles included in these types of voltage distributions for each class of vehicles, the inventor recognized and appreciated from statistical analysis that typically <NUM>% of the values from the data set may lie between -<NUM> and +<NUM> standard deviations. The inventor recognized and appreciated that these voltage distributions may have different voltage ranges for differing classes of vehicles and regardless of class each of the battery voltages yields <NUM> percent of the values from the data set lying within -<NUM> and +<NUM> standard deviations of the distribution curve for the class of vehicle to which it belongs. Thus from each distribution of operational component values for the same class of vehicles and from the histogram of operational component values over time as shown in <FIG>, the inventor recognized and appreciated that minimum and maximum threshold operational values based upon the measured component event may be identified for each distribution curve that are representative of the health of the vehicle component. In the battery embodiment of <FIG>, the identified minimum operational threshold voltage value based upon or related to the cranking event is indicated at <NUM> and the identified maximum operational threshold voltage value at cranking is indicated at <NUM>. The lower or minimum operational threshold voltage value <NUM> may be identified as <NUM> V for this class of vehicle. This minimum or lower threshold voltage value during cranking may be representative of the battery vehicle component having deteriorated to no longer reliably function to start the vehicle during a cranking event. It is appreciated that the minimum operational threshold voltage value may differ from <NUM> V for different classes of vehicle or battery. For the battery of the embodiment of <FIG>, an upper or maximum operational threshold voltage value during starter motor cranking <NUM> may be identified as <NUM> V for this class of vehicle where the maximum operational threshold voltage value during a cranking event may be voltage representative a new battery. It is appreciated that the maximum operational threshold voltage value may differ from <NUM> V for a different class of vehicle or battery. It should be appreciated that the terms minimum and maximum as used herein may not represent a true minimum or maximum voltage reading during a vehicle cranking event experienced by all batteries of like vehicles in the fleet and that some batteries may operate beyond these ranges for limited times. It should be appreciated that the minimum and maximum operational threshold voltage may vary based upon environmental conditions experienced during the cranking event such as for example, ambient temperature conditions, and operating voltages during colder conditions may be used when determining the minimum and maximum operational threshold voltage values. Thus these minimum and maximum operational threshold values are predictive indicators of the health of the vehicle component.

In addition to these minimum and maximum operational threshold values being predictive indicators the health of the vehicle component, the inventor recognized and appreciated that identification of an intermediate threshold value relative to and greater than the minimum threshold value, and also based upon the measured component event, such as a starter motor cranking event for a battery component, in an embodiment may provide for triggering of a component health pre-failure signal that may be communicate to the fleet owner to initiate service on the vehicle component. This communication may be in the form of a notification such as an email or other electronic message or may be a flag brought to the attention of the fleet owner when monitoring the status of the fleet through an internet portal.

In the embodiment of <FIG>, the intermediate threshold value is shown at <NUM> to be <NUM> V for this class of vehicle and battery. In the embodiment where the vehicle component is a battery, the intermediate threshold voltage value based upon or related to a cranking event for the starter motor triggers a component health pre-failure signal that can be communicated to the fleet owner. The fleet operator may then perform an electrical service inspection on the vehicle to determine the health status of the battery and/or other components in the vehicles electrical system such as for example, the battery cables, the alternator and/or the starter motor. Triggering an early or pre-failure signal allows for preventative maintenance of the vehicle component. In an embodiment, the intermediate threshold voltage value during the cranking event may provide real time electrical system health status parameters representative of at least one of a battery status, battery cable status, starter motor status and alternator status. It is understood that the intermediate threshold voltage value may differ for different classes of vehicle and battery.

Referring to <FIG> there is shown a plot of minimum battery voltages during cranking events and in <FIG> there is shown a plot of moving average minimum voltage values measured at cranking events as measured over months starting in May and ending in December. <FIG> is for one vehicle in a fleet of vehicles. The Y axis represents battery voltage and the X access is the event date and time of the starter motor cranking event as logged over about seven months. The recorded minimum voltage values <NUM> measured or determined at cranking are relatively noisy. The minimum voltage values in <FIG> prior to vehicle component event <NUM> are shown between about <NUM> volts and slightly over <NUM> volts where the median voltage decreases in value over time. The vehicle component event <NUM> in this embodiment may be a battery replacement, refurbishment or a change to the alternator or battery cables. After the vehicle component event <NUM>, the minimum voltage values during cranking events increases rapidly. Due to the noisiness of the data, this decrease in the battery health status parameters is difficult to predict.

Referring to <FIG>, the X and Y axis are the same as in <FIG>, and the curve displayed is a moving average of the minimum voltage values at cranking events shown in <FIG>. In this embodiment, the moving average comprises a sample set of the last <NUM> minimum voltage values measured at cranking events over time including the current or real time minimum voltage reading and <NUM> previous readings. As can be seen in <FIG>, the resultant plot of moving average minimum voltage values measured at cranking events is much smoother when compared to the noisy unfiltered minimum voltage events in <FIG>. The smoothing effect of the filtering moving average shows the minimum voltage values at cranking gradually decreasing over time from about <NUM> volts at <NUM> down to close to <NUM> volts at the vehicle component event <NUM>. Thereafter, the moving average of the minimum voltage values at cranking increases at <NUM> to about <NUM> volts. The slope of the increase in voltage is not as steep in <FIG> as in <FIG> due to the smoothing effect of the filtering by the moving average.

From the embodiment of <FIG>, the intermediate threshold voltage value for the moving average is shown at <NUM> to be <NUM> V. When the moving average of the minimum voltage values <NUM> in <FIG> decreases to <NUM> V, a triggering event is generated. The triggering event is indicated at vertical line <NUM> in each of <FIG>. The triggering event <NUM> triggers generation of a work order in an embodiment which is sent to and/or from the fleet owner to perform maintenance on the vehicle electrical system. This maintenance may be performed later in time as shown at the vehicle component event <NUM>. In the exemplary embodiment, the work order may be generated late in September at <NUM> and the maintenance may be performed about one month later before the moving average minimum voltage value at cranking falls below the minimum threshold voltage of <NUM> V. This permits the fleet owners to schedule timely or just in time maintenance. After the maintenance event <NUM> has been performed the average minimum voltage rises to just over <NUM> V in <FIG>. While the intermediate threshold voltage value is <NUM> V, this value may be different for different classes of vehicles or batteries and has been chosen based on the historical big raw data of battery performance to provide sufficient lead time for the maintenance event to occur. If more or less time is required by a fleet operator to service its vehicles once the work order is triggered, then the intermediate threshold voltage value may be adjusted accordingly.

As mentioned above in the embodiment shown in <FIG>, the moving average comprises the most recent <NUM> samples of battery minimum voltages measured at cranking events. While the <NUM> samples provide a smooth curve, it should be understood that the number of events may be lower or higher than this number of samples in other embodiments. However, the minimum voltage of the most recent measured voltage at the cranking event forms part of the moving average and this overall average is a good representation of the battery health. The inventor recognized and appreciated that for different types of fleets of vehicles there may be different number of samples measured for the minimum voltage at the cranking events. For example, in a courier business, the trucks in the vehicle may be started anywhere from <NUM> to <NUM> times a day. Accordingly, the moving average of <FIG> would be a real time average that falls within the last working day of the vehicle. For other types of trucks of vehicle fleet, for example, a truck delivering food or beverage items to stores having about <NUM> to <NUM> stop and starting events in a day, then this <NUM> sample minimum voltage moving average may be obtained over the last five to seven days of the operation of the vehicle. The inventor realized and appreciated that the <NUM> samples effectively covers both these described vehicle embodiments. It is appreciated that for vehicles in a fleet having different stop and start considerations, the number of samples making up the moving average may have to be altered to provide a real-time or near real time predictive indication of the battery health status.

The inventor recognized and appreciated that the minimum operational threshold value represented to of a failing health condition of the vehicle components and or the maximum operational threshold value representative of an optimal health condition of the vehicle component may be used to determine a predictive health status rating parameters in real time, including real-time component health status parameters which could be contextualized across all batteries in the class of vehicle as well as batteries across different classes of vehicles. Such a contextualized battery or electrical system health rating parameter simplifies for fleet owners health status parameters in fleets of like vehicle classes and across fleets of differing vehicle classes.

In an embodiment, operational component data and at least one threshold operational value are associated to identify the real-time component health status parameters of the vehicle component. In an embodiment, this associating may involve standardizing the operational component data with at least one threshold operational value to identify standardized real-time component health status parameters of the vehicle component. In an embodiment, the vehicle component includes a battery and the real-time electrical system health parameters are based at least in part on scaling each of the minimum voltage signals at cranking with the minimum operational threshold value determined for a cranking event. An example of this scaling is shown in <FIG>.

<FIG> is a plot of the minimum voltage events of <FIG>, as compared to the minimum operational threshold value identified for the battery. The X axis of <FIG> corresponds to the X axis of <FIG> and the Y axis represents individual electrical system rating (ESR) readings. In this instance, the minimum threshold voltage value was identified as <NUM> V. The minimum voltage events of <FIG> are standardize to transform the data to have a mean of zero for <NUM> V. This standardization permits for all vehicles of like class to have their vehicle component compared relative to each other. Moreover it allows for vehicles of different classes to be compared relative to each other as the voltage values revert to the mean of zero. It should also be understood that the graph of <FIG> has not been filtered or smoothed and that in another embodiment, the results may be filtered providing a smoother graph approaching the mean of zero which would be more readily identifiable as the battery component approached its minimum operational threshold value and mean of zero. The standardized real-time component health status parameters can be communicated to the fleet owner so that the fleet owner may then schedule preventative battery or vehicle component maintenance for vehicles in its fleet in both near future (next month) and the more distant future of <NUM> months or more. After the vehicle component event <NUM>, such as battery replacement, refurbishment or alternator replacement or battery cable replacement, the mean value of the battery minimum voltage signals during a cranking event rises to about <NUM>.

<FIG> represents an embodiment illustrating normalized real time electrical system health status rating parameters normalized relative to the minimum operational threshold voltage value (Vmin) representative of a failing health condition of the electrical system based upon a cranking event of the starter motor and a maximum operational threshold voltage value (Vmax) representative of an optimal health condition of the electrical system based upon a cranking event of the starter motor. The X axis corresponds to the x axis of <FIG> and <FIG>. The Y axis is a normalized value between <NUM> and <NUM> scaled by a factor of <NUM>. In one embodiment, for <FIG>, the results of <FIG> have been normalized and filtered by a moving average of <NUM> samples. In an alternative embodiment, the results of <FIG> may represent the normalization of the smoothed curve in <FIG>. The inventor recognized and appreciated that normalization could be achieved by unity-based normalization which is a feature scaling approach to bring all values into a range between <NUM> and <NUM>. Feature scaling is performed wherein each moving average minimum voltage value during cranking events (V) of <FIG> is scaled to derive the normalized real time electrical system health status rating parameters (H) of the vehicle as follows: <MAT>.

The unity-based normalization values are then scaled again by a factor of <NUM> to show the curve of <FIG>. In an embodiment Vmin has a value of <NUM> V and Vmax has a value of <NUM> V. From equation (<NUM>), for a new battery, the minimum voltage at cranking is <NUM> V and the battery rating would then be H X100 = <NUM>. For a battery having minimum voltage at cranking of <NUM>, the battery rating would by <NUM> X <NUM> = <NUM>. Hence the curve of <FIG> shows a battery health status rating starting at about <NUM> for a battery that has been in use and over <NUM> months. This rating generally gradually decreases to about a rating of <NUM> wherein the maintenance work order event <NUM> is triggered resulting in a vehicle component event or in this embodiment an electrical maintenance event <NUM>. After the maintenance is performed, the battery rating rises up to a rating of about <NUM>. For a battery rating of <NUM>, which is less than <NUM> for replacement with a fully functional new battery, the maintenance event may have been the replacement of the battery with a refurbished battery, and/or a change of the alternator or battery cable. As discussed above, the curve of <FIG> may be employed to trigger the vehicle component event <NUM> at a health rating (H) of about <NUM>. The rating of <NUM> corresponds to an intermediate threshold voltage value of <NUM> V, in this embodiment, normalized to a health status rating parameter H and scaled by a factor of <NUM>. The advantage associated with this predictive analysis is that it allows for normalized health status rating parameters for vehicle components such as, for example, batteries, to be compared relative to each other regardless of vehicle classification since the normalizing factors in each classification of vehicle are related to or dependent upon that class of vehicle. Further, real-time battery status rating indicators representative of the health of the battery status may be generated for all vehicles in the same class vehicles or different classes of vehicles owned by fleet owner. These ratings can then be communicated to the fleet owner so that the fleet owner may then schedule preventative battery or vehicle component maintenance for vehicles in its fleet in both near future (next month) and the more distant future of <NUM> months or more.

<FIG> correspond to <FIG> with the difference being that the battery represented is a new battery in <FIG>. The minimum voltage events in <FIG> are fluctuating close to or just above the <NUM> V level. The moving average is shown to be slightly above <NUM> V in <FIG>. The minimum voltage events with the applied standardized electrical system rating are shown in <FIG> with valuations of about or close to the <NUM> scale plus or minus <NUM>, well above the mean of <NUM>. In <FIG> the normalized real time electrical system health status rating parameters H are consistently at <NUM>.

Referring to <FIG>, there is shown Figures similar to <FIG>. However, in this embodiment, the battery is not a new battery and is nearing midlife. In <FIG> the minimum voltage signals at cranking events are between <NUM> V and <NUM><NUM>/<NUM> V. In <FIG>, the smoothing average of the battery minimum voltage values for the cranking events is about <NUM> V. The minimum voltage values at cranking events when standardized are shown in <FIG> having a mean around <NUM> with deviation between <NUM> and slightly above <NUM>. The normalized rating in <FIG> of real time electrical system health status rating parameters shows a battery health rating is just over <NUM>.

Accordingly, it should be understood that a real time battery health rating may be ascertained for each vehicle in the fleet or across differing fleets. For the normalized rating this scaled rating will be a between <NUM> and <NUM> with <NUM> representing a battery that is going to fail and <NUM> representing a new battery. The generation of normalized real time electrical system health status rating parameters based at least in part on normalization of the plurality of minimum voltage signals with the minimum and maximum operational threshold voltage values allows for prediction in real time of the health status of the electrical system components in and across it fleets to effect timely or just in time maintenance servicing of the electrical systems of its vehicles.

Referring to <FIG> there is shown snapshot of minimum voltage readings measured during cranking events for an embodiment of all gas vehicles for a fleet of <NUM> vehicles having common vehicles and battery types. The X axis is voltage with each bar in the graph shown by its voltage range, and the Y axis is vehicle count. The results of <FIG> follow a standard distribution curve. <FIG> identifies real time normalized health status rating parameters of an electrical system of the vehicles shown for the vehicle data of <FIG>. The X axis is the normalized real time electrical system health status rating parameters based at least in part on normalization of the plurality of minimum voltage signals with the minimum and maximum operational threshold voltage values and scaled by a factor of <NUM>. Each bar in the graph is identified in the X axis by its normalized rating range. The Y axis is the vehicle count. <FIG> also follows a standard distribution curve similar to that of <FIG>. The inventor recognized and appreciated that the standard distribution curve of <FIG> is more easily readable and allows fleet operators to determine how many battery vehicle components may need to be scheduled for maintenance in real time. In the embodiment of <FIG> there are about <NUM> vehicles with an electrical system rating of less than <NUM>. The inventor recognized and appreciated the value of this information being made available to fleet operators allows for the timely and/or just in time maintenance of the electrical system of the <NUM> vehicles with a rating of <NUM> or less. Further, the fleet operator can compare normalized real time electrical system health status rating parameters for different classes of vehicles and electrical systems due to the normalization of the information whereby distribution curves similar to that of <FIG> for different classes of vehicles may be cumulatively superimposed on one another to provide an overall representation of the health status rating for all batteries in the fleet.

The inventor recognized and appreciated identification of real time component remaining effective life status parameters of a vehicle component allow the owner sufficient lead time to manage the upcoming costs associated with purchasing and replacement of the vehicle component. It permits the fleet owner to purchase replacement components in bulk or on a scheduled basis permitting improved budgeting of costs for the fleet owners managing the vehicles in the fleet. However, determining when a vehicle component's useful life will end and associating an effective life status parameter therewith is no simple task.

The inventor recognized and appreciated from the normalized battery performance curve scaled by a factor of <NUM> as shown in <FIG>, when not so scaled, would provide a battery rating curve over the operational life of the battery having normalized values between <NUM> and <NUM> where <NUM> represents an end of serviceable life where the vehicle component, battery, no longer functions as required to start the vehicle. While the battery component may still have a voltage level, this voltage level under a starter motor cranking load condition is insufficient to perform the required function of starting the vehicle.

The inventor further recognized and appreciated that life span of the vehicle component in its operating environment in an embodiment can be determined from an analysis of historical raw big data of the vehicle component when compared with maintenance logs of fleet owners. This historical information when associated the normalized real-time component health status parameters of the vehicle component identifies real time component effective life status parameters for the vehicle component.

In other embodiments, the span of the vehicle component value may be determined from the vehicle component manufacturer's life expectancy specifications or a combination of vehicle component manufacturer's life expectancy specifications and the historical information of telematics big raw data.

In an embodiment, real time component remaining effective life status parameters of an electrical system of a vehicle may be identified wherein for each battery in the fleet in real time a normalized electrical system health rating parameter (H) may be determined in accordance with formula (<NUM>). This normalized rating, as discussed before, is determined from a moving average and may have a value between <NUM> and <NUM>, inclusive. When this normalized rating value is factored against the expected life of the battery, a remaining life in days, weeks, months or years can be determined. For example, when expected life of a battery is <NUM> months and the battery rating parameter is <NUM>, then the expected remaining life of the battery is <NUM> months. The inventor recognized and appreciated that the performance curve of the like batteries in the fleet may be non-linear and may more rapidly decline near the end of life and may be subject to variations due to ambient operating conditions. However, the inventor recognized and appreciated that for a large portion of the battery life cycle the variation in the moving average of the minimum voltage readings during a cranking event is relatively linear over time and that at any given real time, remaining effective life of the vehicle component when made available to fleet operators provides useful information for predicting future costs and scheduling of vehicle component preventative maintenance.

Referring now to <FIG>, the different types of raw telematics data useful alone or in combination for predictive component failure and maintenance validation are described. The vehicular telemetry hardware system <NUM> has the capability to monitor and log many different types of telematics data to include GPS data, accelerometer data, vehicle component data (data specific to the component being assessed for predictive failure or maintenance validation), vehicle data and vehicle event data. In addition, event data may be supplemented to the log of raw telematics data provided by the vehicular telemetry hardware system <NUM>. The predictive component failure analysis process uses the raw telematics data and event data to provide a predictive component failure indication, a recommendation for maintenance and validation or indication of a maintenance activity.

The GPS module <NUM> provides GPS data in the form of latitude and longitude data, time data and speed data that may be applied to indicate motion of a vehicle. The accelerometer <NUM> provides accelerometer data that may be applied to indicate forward motion or reverse motion of the vehicle.

Vehicle data includes the first category of raw telematics vehicle data and information such as a vehicle component type or identification, vehicle speed, engine RPM and two subsets of data. The first subset of data is the vehicle component data. Vehicle component data is specific parameters monitored over the life cycle and logged for a particular vehicle component being assessed for predictive component failure. For example, if the vehicle component is a vehicle battery, then raw battery voltages and minimum cranking voltages are monitored and logged. The second subset of data is vehicle event data. This may be a combination of vehicle data applied or associated with a vehicle event or a vehicle component event. For example, if the vehicle component is a vehicle battery and the event is a cranking event, then the vehicle data event may include one or more of ignition on data, engine RPM data, decrease in battery voltage data, speed data and/or accelerometer data.

Event data typically includes a record of a vehicle event. This may include one or more of a maintenance event, a repair event or a failure event. For example, with a vehicle battery the maintenance event would be a record of charging or boosting a battery. A repair event would be a record of replacing the battery. A failure event would be a record of a dead battery. Event data typically includes a date and time associated with each event.

Referring now to <FIG>, the predictive component pre-failure analysis process is described. The predictive component pre-failure analysis process is generally indicated at <NUM>. This process and logic may be implemented in a server <NUM> or in a computing device <NUM> or in a vehicular telematics hardware system <NUM> or a combination of a server, computing device and vehicular telematics hardware system. This process may also be implemented as a system including a vehicular telematics hardware system <NUM> and a remote device <NUM>. Finally, this process may also be implemented as an apparatus that includes a vehicular telematics hardware system <NUM>. The process begins by receiving historical data. The historical data includes vehicle event data and raw telematics data <NUM>. The raw telematics data <NUM> includes vehicle component data. The vehicle component data includes vehicle component data before one or more vehicle events and after one or more vehicle events. Vehicle component data is the historical operational data obtained over time from a vehicular telemetry hardware system <NUM> (see <FIG>). Vehicle component data includes operational data for at least one vehicle component. Vehicle component data is also the life cycle data for a component from a new installation to failure situation.

Vehicle component data includes operational component data from at least one type of vehicle based upon fuel based vehicles, hybrid based vehicles or electric based vehicles. The broad categories include: fuel and air metering, emission control, ignition system control, vehicle idle speed control, transmission control and hybrid propulsion. These broad categories are based upon industry OBDII fault or trouble codes either generic or vehicle manufacturer specific. The vehicle component data may include one or more data generated by thermostat or temperature sensors (oil, fuel, coolant, transmission fluid, electric motor coolant, battery, hydraulic system), pressure sensors (oil, fuel, crankcase, hydraulic system), or other vehicle components, sensors or solenoids (fuel volume, fuel shut off, camshaft position, crankshaft position, O2, turbocharger, waste gates, air injections, mass air flow, throttle body, fuel and air metering, emissions, throttle position, fuel delivery, fuel timing, system lean, system rich, injectors, cylinder timing, engine speed conditions, charge air cooler bypass, fuel pump relay, intake air flow control, misfire (plugs, leads, injectors, ignition coils, compression), rough road, crankshaft position, camshaft position, engine speed, knock, glow plug, exhaust gas recirculation, air injection, catalytic convertor, evaporative emission, vehicle speed, brake switch, idle speed control, throttle position, idle air control, crankcase ventilation, air conditioning, power steering, system voltage, engine control module, throttle position, starter motor, alternator, fuel pump, throttle accelerator, transmission control, torque converter, transmission fluid level, transmission speed, output shaft speed, gear positions, transfer box, converter status, interlock, torque, powertrain, generator, current, voltage, hybrid battery pack, cooling fan, inverter and battery).

An example of vehicle component data is battery voltages during operational use of a vehicle battery or battery voltages based upon a cranking event. The cranking event produces a minimum battery voltage followed by a maximum battery voltage as the battery is recharging to replace the energy used by a vehicle starter motor.

The vehicle event data typically includes a date, or date and time, and the type of vehicle event. The type of vehicle event may be failure, maintenance or service. For example, a failure of a vehicle battery is when the vehicle would not start. Maintenance of a vehicle battery could be replacement of the vehicle battery. Service of a vehicle battery could be a boost.

For each vehicle component under analysis, the moving average <NUM> from the vehicle component data may be determined. Alternatively, an average moving range or median moving range may be determined. For each vehicle component under analysis, the minimum operational threshold value may be determined at failure <NUM> and the maximum operational threshold value <NUM> may be determined when the vehicle component is replaced by a new component.

The next sequence in the process is component approaching failure analysis. Component approaching failure analysis uses the component event data and one or more of the predictive threshold values. In embodiments, the analysis compares the determined data values from the component data before the component event, or after the component event, or before and after the component event. The analysis determines a component approaching failure. For the vehicle component data preceding the vehicle event data point, if the data value decreases over time from the maximum component threshold value to the minimum component threshold value, then when the moving average decreases to the intermediate threshold value a component approaching failure or pre-failure signal is indicated.

The next sequence in the process is to communicate and/or schedule with the owner of the vehicle a maintenance call for the vehicle due to the pre-failure signal being triggered. This communication may comprise for example internet portal access by the owner to the remote device <NUM> to see vehicles having triggered pre-failure signals, or it may comprise the remote device sending and electronic messages to the owner of the pre-failure signals and notification that vehicle maintenance servicing is imminently due.

Referring now to <FIG> and <FIG> determining and identifying standardized and normalized predictive indicators of vehicle component status are described respectively at <NUM> for <FIG> and <NUM> for <FIG>. This process and logic may be implemented in a server <NUM> or in a computing device <NUM> or in a vehicular telematics hardware system <NUM> or a combination of a server, computing device and vehicular telematics hardware system. This process may also be implemented as a system including a vehicular telematics hardware system <NUM> and a remote device <NUM>. Finally, this process may also be implemented as an apparatus that includes a vehicular telematics hardware system <NUM>. The determining standardizing process is illustrated at <NUM> in <FIG> and determining normalization process is illustrated at <NUM> in <FIG>. Both processes may be implemented as a method or as a system. In the case of a system, the system includes a telematics hardware device <NUM> and a remote device <NUM>. The telematics hardware device <NUM> monitors and logs operational component data. This data includes operational values from various vehicle components. The operational component data also includes vehicle component data based upon measured component events such as a cranking event. The operational component data is communicated from the telematics hardware device <NUM> to remote device <NUM>. Over time, the logs of operational data provide an operational life cycle view of vehicles components from new to failure.

In addition, management event data is also captured over time. Management data provides vehicle component records in the form of component or vehicle events. Vehicle component events may be a failure event, a repair event or a replace event depending upon the corrective action of a management event.

The processes each begin by accessing or obtaining management event data. Then, operational vehicle component data is accessed or obtained prior to a management event data point and following a management event data point (prior and post). In <FIG>, the operational vehicle component data is filtered. Filtering provides a moving average or a running average of the operational vehicle component data. In addition, signals are derived from the operational vehicle component data. The derived signals may be identified between a lower control limit and an upper control limit or between a mean and upper control limit. The derived signals are representative of a measured component event, for example a cranking event. A cranking event is an example of an operational event that places a high operational load on a vehicle component within the limits of the component. The cranking event provides a series of battery voltages starting with the ignition on voltage, a voltage representative of an active starter motor, a voltage after cranking where the battery is charging followed by a recovery voltage as energy is replaced into the battery following the cranking event. A lower cranking event voltage produces more signals. The operational component data is associated with the management event data typically by database records.

A check for real time predictive indicators occurs to identify potential real time predictive indicators of operational vehicle component status. In embodiment of <FIG>, the check involves standardizing the derived signal with a minimum operational threshold value that is based on the measured component event. The results of the standardization identify vehicle component heath status and associated predictive indicators of component status that are real time indications relative to a mean of zero associated with the failing condition of the battery that can be compared across vehicle components of different classes. In an embodiment of <FIG> the check involves normalizing the filtered derived signal with minimum and maximum operational threshold values that are based upon the measured component event. The results of the normalization identify vehicle component heath status and associated predictive indicators of component status that are real time indications of the rating of the component that in an embodiment are scaled to be between a range of <NUM> and <NUM> of the battery and that can be compared across vehicle components of different classes. A monitoring indicator framework may also be associated with the operational component data and the management event data. The monitoring indicator framework may include different normalized values between <NUM> and <NUM> that represent the component heath status rating from a new condition progressing to a failure condition. With the normalization or standardization of the vehicle component health status, a real time indication of the actual health of the vehicle component is realized independent of states of health.

The next step in these processes is to communicate with the owner respectively the standardized and normalized real predictive indicators. This communication may comprise internet portal access by the owner to the standardized and normalized real predictive indicators in the remote device <NUM>, or it may comprise the remote device sending and electronic message to the owner of the standardized and normalized real predictive indicators.

Referring now to <FIG> a process of determining remaining effective life of a vehicle component is illustrated at <NUM>. This process and logic may be implemented in a server <NUM> or in a computing device <NUM> or in a vehicular telematics hardware system <NUM> or a combination of a server, computing device and vehicular telematics hardware system. This process may also be implemented as a system including a vehicular telematics hardware system <NUM> and a remote device <NUM>. Finally, this process may also be implemented as an apparatus that includes a vehicular telematics hardware system <NUM>. The process may be implemented as a method or as a system. In the case of a system, the system includes a telematics hardware device <NUM> and a remote device <NUM>. The telematics hardware device <NUM> monitors and logs operational component data. This data includes operational values from various vehicle components. The operational component data also includes vehicle component data based upon measured component events such as a cranking event. The operational component data is communicated from the telematics hardware device <NUM> to remote device <NUM>. Over time, the logs of operational data provide an operational life cycle view of vehicles components from new to failure.

The process <NUM> begins by access or obtaining management event data. Then, operational vehicle component data is accessed or obtained prior to a management event data point and following a management event data point (prior and post). The operational vehicle component data may be filtered. Filtering provides a moving average or a running average of the operational vehicle component data. In addition, signals are derived from the operational vehicle component data. The derived signals may be identified between a lower control limit and an upper control limit or between a mean and upper control limit. The derived signals are representative of a measured component event, for example a cranking event. A cranking event is an example of an operational event that places a high operational load on a vehicle component within the limits of the component. The cranking event provides a series of battery voltages starting with the ignition on voltage, a voltage representative of an active starter motor, a voltage after cranking where the battery is charging followed by a recovery voltage as energy is replaced into the battery following the cranking event. A lower cranking event voltage produces more signals. The operational component data is associated with the management event data typically by database records. The operational vehicle component datat and derived signal is filtered by a moving average as discussed prior.

A check for real time predictive indicators occurs to identify potential real time predictive indicators of operational vehicle component status. In an embodiment the check involves normalizing the derived signal with minimum and maximum operational threshold values that are based upon the measured component event. The results of the normalization identify vehicle component heath status and associated predictive indicators of component status that are real time indications of the rating of the component in an embodiment to be between a range of <NUM> and <NUM>. The normalized derived signal is then associated with service life span parameters of the vehicle component to identify the vehicle component remaining effective life parameters.

The next sequence in the process is to communicate with the owner of the identified vehicle component remaining effective life parameters. This communication may comprise internet portal access by the owner to the remote device <NUM> to see vehicles having triggered pre-failure signals, or it may comprise the remote device sending and electronic message to the owner of the pre-failure signals and notification that vehicle maintenance servicing is imminently due.

Claim 1:
A computer implemented method for identifying real-time component remaining effective life status parameters of an electrical system of a vehicle (<NUM>), the method comprising:
receiving a plurality of voltage signals indicating a change in voltage of a vehicle battery at times associated with a plurality of crankings of a starter motor of the vehicle (<NUM>);
determining for each of the plurality of voltage signals a minimum voltage (V) of the voltage signal, and generating a plurality of minimum voltage signals (<NUM>) for a time period;
characterized in that the method comprises
determining a minimum operational threshold voltage value (Vmin) representative of a failing health condition of the electrical system during cranking of the starter motor and a maximum operational threshold voltage value (Vmax) representative of an optimal health condition of the electrical system during cranking of the starter motor, wherein the minimum and maximum operational threshold voltage values (Vmin, Vmax) are determined from historical vehicle battery data having a distribution curve associated with a life cycle of the vehicle battery from an optimal health condition to a failing health condition;
generating for each of the plurality of minimum voltage signals (<NUM>) normalized real-time electrical system health status rating parameters (H) based on normalization of the plurality of minimum voltage signals with the minimum and maximum operational threshold voltage values, wherein each of the normalized real-time electrical system health status rating parameters (H) of the vehicle is derived from:<MAT>
where V represents one of a filtered and a non-filtered minimum voltage of the voltage <NUM> signal (V), and when V is non-filtered said each of the normalized real-time electrical system health status rating parameters (H) is subsequently filtered; and,
associating the normalized real-time electrical system health status rating parameters (H) with the service life span of the vehicle battery to identify the real-time component remaining effective life status parameters of the electrical system of the vehicle (<NUM>).