Remaining useful life estimation of vehicle component

A vehicle system includes a processor and a memory accessible to the processor and storing computer-executable instructions. The instructions include receiving data from a plurality of vehicles, generating at least one cluster from the received data, and determining a life cycle profile for a vehicle component based on the at least one cluster. The data includes state of health information associated with the vehicle component.

BACKGROUND

Automobiles include many components, some of which require regular maintenance. Automotive tires, brake pads, engine oil, etc., need to be periodically replaced. Sometimes, sensors can be used to measure wear on particular components and alert the vehicle operator when a particular component is due for maintenance.

DETAILED DESCRIPTION

Vehicle prognostics, in general, is difficult because state of health information is difficult to assess for many vehicle components. That is, providing sensors for all vehicle components that wear over time can be cost-prohibitive. Some information may not be directly observable or accessible even if a sensor could be used. Moreover, even with the appropriate sensor data, models for certain component degradation do not currently exist.

One solution includes an online evolving clustering method implemented by a prognostic system that tracks the wear of particular vehicle components and notifies vehicle owners when those components may need maintenance. The prognostic system may receive data about a particular vehicle component from multiple vehicles, generate one or more clusters from the received data, and determine a life cycle profile for the vehicle component based on the cluster. The data received from the vehicles includes state of health information associated with the vehicle component. The life cycle profile may estimate the state of health of the particular component based on, e.g., the age of the component, the way the component is used, the conditions under which the component is used, or any combination thereof. The prognostic system may notify the vehicle owner when a particular vehicle component needs maintenance based on the estimated life cycle given the data in the cluster. Alternatively or in addition, the prognostics information may be displayed at a level easily understandable to the vehicle owner while a more detailed, technical explanation is stored onboard and made available to technicians or maintenance personnel. The prognostic system may update the clusters with additional data as it is received. Updating the clusters could include creating new clusters, combining clusters, eliminating clusters, or the like.

By way of example, the prognostic system may receive data on how a particular brand of brake pads wear over time. From that data, the prognostic system may develop various phases, including a wearing phase, a stable phase, and a near end of life phase. Only three phases are discussed for purposes of simplicity. The prognostic system may develop any number of phases including, e.g., additional phases to better fit the non-linearity exhibited by a single degradation profile. In general, more phases may result in more precise prognostics. The wearing phase may refer to when the brake pads are relatively new. The stable phase may be the longest phase and may begin after the brake pads have been “broken in” and may end before the brake pads have deteriorated. The near end of life phase may refer to the period of time immediately before the brake pads deteriorate to a point where they should be replaced relatively soon. The phases may be a function of time, how often or aggressively the vehicle component is used, or both. When the prognostic system predicts that the brake pads in a particular vehicle have reached the near end of life phase, the prognostic system may output a notification to the owner to that vehicle.

The data may be received from many vehicles over time. For example, each time a vehicle with a particular brand of brakes is brought into a service center, the technician may note the age of the brakes, the state of the brakes (e.g., percentage of the pad remaining), how the vehicle is used (e.g., mostly highway, mostly surface streets, long trips, short trips, etc.), as well as any other information that contributes to developing a life cycle model for that particular brand of brakes. Similar data may be captured to model wear on other vehicle components including tire wear, oil degradation, etc. Further, the prognostic system may generate clusters based on various combinations of data (e.g., a particular brand of brakes and a particular brand of motor oil).

With the prognostic system, the technician and vehicle owner may have better access to the overall vehicle health. The data may be further used for inventory management (i.e., service centers can stock appropriate replacement parts based on the life cycle models so vehicle owners do not need to wait for parts to ship), better vehicle design that accounts for and tries to minimize degradation, and so on.

The elements shown may take many different forms and include multiple and/or alternate components and facilities. The example components illustrated are not intended to be limiting. Indeed, additional or alternative components and/or implementations may be used. Further, the elements shown are not necessarily drawn to scale unless explicitly stated as such.

As illustrated inFIG. 1, the prognostic system includes an estimation computer100in communication with multiple target vehicles105over a communication network110. The estimation computer100is programmed to aggregate component data, such as state of health information, from multiple target vehicles105. It processes the component data to estimate the remaining useful life for one or more vehicle components. For example, the estimation computer100may be programmed to create clusters from the component data, determine a life cycle profile for the component based on the cluster, and predict wear on the component from the life cycle profile. The life cycle profile may include various phases, including a wearing phase, a stable phase, and a near end of life phase. When a particular component installed in a real vehicle is estimated to be at or near the near end of life phase, the estimation computer100transmits a message to the vehicle owner recommending that the component be evaluated or replaced. The actual state of health of the component may be confirmed by a service technician, as described in greater detail below.

The three phases previously discussed are for purposes of simplicity. The life cycle profile may include additional phases to, e.g., provide more precision with respect to the prognostics. Further, different life cycle profiles may apply to the same components. For instance, different life cycle profiles may be used to account for varying combinations of effects certain impact factors may have on the overall shape on the life cycle profile. By way of example, given otherwise similar conditions, a driver that typically brakes lightly and gradually may wear out the brakes much more slowly than a driver that accelerates and brakes more aggressively and more frequently. Thus, two life cycle profiles may be developed to capture the effect of these different braking patterns, and specifically, how these different braking patterns affect the brake wear.

The target vehicles105transmitting data to the estimation computer100may include any passenger or commercial automobile such as a car, a truck, a sport utility vehicle, a crossover vehicle, a van, a minivan, a taxi, a bus, etc. In some possible approaches, the vehicle is an autonomous vehicle configured to operate in an autonomous (e.g., driverless) mode, a partially autonomous mode, and/or a non-autonomous mode. Examples of non-automotive target vehicles105that may provide component data to the estimation computer100include trains, airplanes, boats, etc.

In one possible approach, at least some of the component data may be transmitted to the estimation computer100from a computer or smartphone. In other words, the component data may not be transmitted to the estimation computer100directly from the target vehicle105. One example scenario includes when a target vehicle105is taken to a service station. A service technician may note the amount of wear on a particular vehicle component and transmit component data to the estimation computer100using a smartphone, laptop, tablet, or desktop computer.

Moreover, when a target vehicle105is brought in for service following, e.g., a message from the estimation computer100, the service technician may confirm the life cycle phase of the component at issue. That is, if the message was received by the owner of the target vehicle105because a particular component was predicted to be at the near end of life phase, the service technician may visually inspect the component to determine whether the estimation computer100accurate predicted the life cycle phase.

The communication network110may include various electronic components to facilitate wired or wireless communication between the estimation computer100, the target vehicles105, computers, smartphones, or the like. The communication network110may facilitate communication over any number of wired or wireless communication protocols. Examples of such protocols may include LTE, 3G, WiFi, Ethernet, etc.

FIG. 2illustrates example components of the estimation computer100. As shown, the estimation computer100includes a communication interface115, a memory120, and a processor125.

The communication interface115includes circuits and other electronic components that facilitate communication over the communication network110. The communication interface115, therefore, may receive signals representing component data transmitted from various target vehicles105. The communication interface115may transmit the component data to the processor125, the memory120, or both.

The memory120includes circuits and other electronic components that allow data storage. The memory120, therefore, may be programmed to receive and store component data. In one possible approach, the component data may be stored in a database that relates the component data in various clusters. Further, the memory120may store the life cycle profile for each component, a list (database) of target vehicles105with the particular component installed, owner contact information for each target vehicle105, etc. The memory120may also be programmed to store computer-executable instructions and make such instructions available to the processor125.

The processor125includes circuits and other electronic components that can access and execute the instructions stored in the memory120. The processor125may be programmed to receive the component data, generate clusters from the component data, and determine a life cycle profile for the vehicle component associated with the component data. The processor125may receive the component data directly from the communication interface115or from one or more databases stored in the memory120.

The processor125may be further programmed to identify various product phases based on the life cycle profile. The product phases may include a wearing phase, a stable phase, and a near end of life phase, and each phase may be associated with a particular amount of time. The wearing phase may be a relatively short phase that occurs immediately after the component has been installed in a target vehicle105. The wearing phase may be better understood as a “breaking in” phase. The stable phase may follow the wearing phase. The stable phase may be the longest among the phases and may represent most of the useful life of the component. The near end of life phase may follow the stable phase. That is, the near end of life phase may define the period of time at the tail end of the component's useful life. Thus, a component in or approaching the near end of life phase may need to be replaced relatively soon.

Since some vehicle components can be used in different ways, the processor125may further develop the life cycle profile based on how a particular component is used. For instance, a component used often or more aggressively may reach the near end of life phase faster than a component used seldom or less aggressively. The processor125may cluster component data according to usage, develop different life cycle profiles for each cluster, and relate the appropriate life cycle profile to the appropriate target vehicle105based on component usage in the database.

By way of example, the processor125may develop different clusters, and thus different life cycle profiles, for different uses of a particular brand of brake pads. That is, component data concerning aggressively used brake pads may be incorporated into one cluster that is used to generate one life cycle profile while component data concerning less aggressively used brake pads may be incorporated into a different cluster used to generate a different life cycle profile. Moreover, component data for a target vehicle105that is driven daily may show faster brake wear than component data for a target vehicle105that is only driven once or twice a week. Thus, that difference in usage may form the basis for two distinct clusters. Likewise, component data for brake pads on a target vehicle105that is mostly highway driven may show slower wear than component data for brake pads on a target vehicle105that is mostly driven in urban areas. Those different types of usages, therefore, may serve as the basis for distinct clusters.

The processor125may use the life cycle profile for a particular component to notify the owner of a target vehicle105with the particular component installed that the component is at the near end of life phase. For instance, the processor125may be programmed to determine, from the database stored in the memory120, that a target vehicle105has the particular component installed, the amount of time the component has been in use, and the amount of remaining useful life according to the life cycle profile for the component. When the remaining useful life indicates that the component is in or approaching the near end of life phase, the processor125may be programmed to retrieve the contact information for the owner of the target vehicle105and command the communication interface115to transmit a notification to the owner of the target vehicle105indicating that the component should be evaluated or replaced.

In one possible approach, the processor125may set various thresholds associated with the state of health of the component that can be used to determine where a particular component falls on the life cycle profile. For example, the processor125may define a low or high threshold for a measurable or otherwise observable indicator that strongly correlates to state of health. Whether the threshold is low or high may depend on the circumstances or the component. For instance, an example of a low threshold may be where brake pad thickness is measured. A thinner brake pad suggests more wear, so a “low” threshold may be more appropriate than a “high” threshold. An example of a high threshold may include monitoring for braking energy consumed per unit distance since a higher value may suggest that the brakes are closer to the near end of life phase.

Different thresholds may apply to each phase of the life cycle profile. The processor125may compare the value to the various thresholds to determine where the component falls on the life cycle profile. The notification to the vehicle owner may be generated and sent when the most recent estimation indicates that the component is at or approaching the near end of life phase.

The processor125may be programmed to periodically update the clusters with updated component data received. Updating the clusters may include creating a new cluster, adding the updated component data to an existing cluster, separating an existing cluster into two clusters, combining the component data from multiple clusters into a single cluster, eliminating a previously existing cluster and redistributing the component data from the eliminated cluster into new or different clusters, etc. The updated component data may be received by the processor125in response to signals associated with one or more target vehicles105being transmitted to the estimation computer100over the communication network110.

FIG. 3is a graphical representation300of clusters130that may be formed from the vehicle component data and associated to particular vehicles. The clusters130may be formed in accordance with any cluster analysis technique such as the Mahalanobis distance technique or a squared distance (such as a Euclidean distance) technique. In general, each cluster130represents major groups of data in a data stream. Each cluster130is characterized by a mean and a covariance metric. The center (mean) and orientation of the data are considered in generating each cluster130. Data is incorporated into the clusters130on a sample by sample basis. That is, new data is used to update the clusters130without having to process historical data each time. As a result, clusters130can move, be created, be combined, be removed, etc., over time. For instance, new data collected may indicate a new pattern that ultimately is used to form a new cluster130.

Data provided by particular vehicles may be grouped into one or more clusters130. The clusters may be updated in accordance with the rate at which signals describing the usage of a component are received. Further, the remaining useful life model of each cluster may be updated in accordance with the availability of the state of health information. As a result, the clusters and life cycle profile may be updated at the same time, at different times, at the same rate, or at different rates. For instance, state of health information may be received less often than other types of information associated with developing the clusters. Moreover, as the remaining useful life information is generated, the remaining useful life information may be transmitted to the owners of the target vehicles105. For example, as discussed above, the remaining useful life information may be transmitted when the remaining useful life information for a particular target vehicle105is at or approaching the near end of life phase.

FIG. 4is a graph400illustrating a component life cycle generated from data collected from multiple vehicles over time and incorporated into a cluster. The X-axis represents time in days and the Y-axis represents the remaining life as a percentage. The solid line405may be a function of the collected data (shown as stars). For instance, the line405may be generated, at least in part, from a cumulative distribution function and shaped at least partially via a least squares method. The different phases are separated by vertical lines410A and410B. The line410A may separate the wearing phase135from the stable phase140, and the line410B may separate the stable phase140from the near end of life phase145.

As shown, the wearing phase135ends, and the stable phase140begins, when the remaining life is approximately 95%. The stable phase140ends, and the near end of life phase145begins, when the remaining life is approximately 10%. These numbers are merely examples for purposes of simplicity. Different percentages may be applied based on the type of component, the expected rate of degradation, etc.

FIG. 5is a flowchart of an example process500that may be executed by the estimation computer100to aggregate the component data. The process500may be executed by the estimation computer100periodically so that new data may be continually sampled. Computer-executable instructions for the process500may be stored in the memory120and made accessible to components of the estimation computer100, such as the processor125.

At block505, the estimation computer100receives component data. The component data can be received from multiple vehicles over a period of time. The component data may be received via the communication interface115and stored in the memory120where it can be accessed by the processor125.

At block510, the estimation computer100generates clusters. The clusters can be generated by, e.g., the processor125according to various statistical techniques including a Mahalanobis distance technique. The processor125may cluster the component data according to the type of component, the make of the component, the model of the component, the way the component is used, whether the component is part of a group of at least one other component, or the like.

At block515, the estimation computer100develops the life cycle profile for each cluster. The life cycle profile may estimate the state of health of the particular component based on, e.g., the age of the component, the way the component is used, or both. The processor125may develop the life cycle profile by, e.g., identifying various product phases based on the life cycle profile. As discussed above, the product phases may include a wearing phase, a stable phase, and a near end of life phase, and each phase may be associated with a particular amount of time. The wearing phase may be a relatively short phase that occurs immediately after the component has been installed in a target vehicle105. The wearing phase may be better understood as a “breaking in” phase. The stable phase may follow the wearing phase. The stable phase may be the longest among the phases and may represent most of the useful life of the component. The near end of life phase may follow the stable phase. That is, the near end of life phase may define the period of time at the tail end of the component's useful life. Thus, a component in or approaching the near end of life phase may need to be replaced relatively soon.

At block520, the estimation computer100may receive updated component data. The updated component data may be received via the communication interface115and stored in the memory120. The processor125may access the updated component data from the memory120for processing, including the processing that occurs at block525,535, and545.

At decision block525, the estimation computer100determines whether to update an existing cluster with the component data received at block520. For instance, the processor125may use, e.g., the Mahalanobis distance technique to determine whether the component data received at block520should be applied to an existing cluster. The processor125may make such a decision if the component data received at block520is based on the same type of component, use of the component, etc., as the previously received component data in an existing cluster. If an existing cluster is to be updated, the process500proceeds to block530. If not, the process500proceeds to block535.

At block530, the estimation computer100adds the component data received at block520to an existing cluster. Adding the component data may include the processor125applying various statistical techniques, discussed above, to the updated component data and updating the life cycle profile for the cluster, if necessary, based on the updated component data. The process500may proceed to block545.

At decision block535, the estimation computer100determines whether to create a new cluster with the component data received at block520. For instance, the processor125may use, e.g., the Mahalanobis distance technique to determine whether the component data received at block520is different enough from the previously received component data in the existing clusters that it should be incorporated into a new cluster, either alone or with previously received component data.

For instance, if the component data received at block520is from a different type of component, a different type of use, etc., the processor125may determine that the component data received at block520should be incorporated into a new cluster. In this instance, the process500proceeds to block540. If not (e.g., the processor125determines that no new cluster is needed), the process500proceeds to block545.

At block540, the estimation computer100creates a new cluster with the updated component data. Creating the new cluster may include moving previously received component data from an already existing cluster into a new cluster. Moreover, the new cluster may be formed to include component data that previously appeared to be an outlier relative to the previously existing clusters. Thus, creating a new cluster may include reducing the size of a previously existing cluster. Further, creating the new cluster may include the processor125applying various statistical techniques, discussed above, to the updated component data and generating the life cycle profile for the cluster based on the updated component data as well as any other component data incorporated into the new cluster. The process500may proceed to block545.

At decision block545, the estimation computer100determines whether to delete an existing cluster or merge one existing cluster with another. For instance, the processor125may determine that an existing cluster should be deleted if the updated component data renders one or more previously existing clusters meaningless. For instance, if the component data received at block520serves as a link between the component data in two clusters, the clusters may be combined (i.e., merged), effectively deleting one of the clusters. Or, if the updated component data shows that the data in one cluster is actually outlier data relative to another cluster, the cluster with the outlier data may be deleted and the outlier data redistributed or excluded from all clusters. To determine if two clusters should be merged, the processor125may identify two clusters with overlapping coverage and evaluate distance between the centroids of both clusters involved. If the overlap is significant and the distance between the centroids is statistically significant, the processor125may decide to merge the clusters. If the overlap is insignificant or if the distance between the centroids is insignificant, the processor125may decide to keep the clusters separate. If the processor125determines that a cluster should be deleted, the process500proceeds to block550. Otherwise, the process500proceeds to block520so that additional component data can be received and considered.

At block550, the estimation computer100deletes the old cluster selected at block545(or merges two or more clusters, as the case may be). To delete the old cluster, the processor125may redistribute all component data previously incorporated into the deleted cluster or treat certain component data from the deleted cluster as outlier data, which may be ignored. The processor125may distribute the component data in the deleted cluster to an existing cluster as discussed above with regard to block530, create a new cluster with the component data from the deleted as discussed above with respect to block540, or a combination of both. To merge a cluster, the processor125may combine the data from the merging clusters and define the merged cluster in a way that maintains the centroids and original coverage of the original clusters. Further, the processor125may redevelop the life cycle profile for each cluster that was updated or created as a result of deleting one of the clusters or merging two clusters. The process500may proceed to block520so that additional component data may be considered, and the clusters and life cycle profiles updated.

FIG. 6is a flowchart of an example process600that may be executed by the estimation computer100to notify vehicle owners of significant times associated with the life cycle of a particular vehicle component. The process600may be executed periodically (on the order of every few hours, every few days, every few weeks, etc.) for each target vehicle105. Computer-executable instructions for the process600may be stored in the memory120and made accessible to components of the estimation computer100, such as the processor125.

At block605, the estimation computer100identifies a target vehicle105. The target vehicle105may be identified by the processor125according to a database stored in the memory120. The target vehicle105may be one that has contributed component data to the prognostic system, has a particular component installed, uses a particular component in a particular way, or the like.

At block610, the estimation computer100determines the product phase associated with one or more components of the target vehicle105. For instance, the processor125may identify one or more relevant clusters, identify one or more components associated with the identified clusters, and determine how long the one or more components have been installed in the target vehicle105identified at block605. The processor125may compare the amount of time the component has been installed to the life cycle profiles associated with the identified clusters. If multiple clusters are involved, the processor125may determine the product phase according to a weighted average (based on similarity) of the life cycle profiles associated with each of the individual identified clusters. Thus, the life cycle profile that most closely resembles the actual wear on the component may be given more weight by the processor125when determining the product phase. The processor125may determine whether the component is in the wearing phase, the stable phase, the near end of life phase, or any other phase defined in the life cycle profile. If in the stable phase, the processor125may further determine how much time before the component is likely to reach the near end of life phase.

At decision block615, the estimation computer100determines whether the component is at or quickly approaching the near end of life phase. The processor125may determine whether the component is at or approaching the near end of life phase based on the life cycle profile, the amount of time remaining until the component is estimated to reach the near end of life phase, or the like. If the component is already at the near end of life phase, or if the component is estimated to reach the near end of life phase before the process600is subsequently executed, the process600may proceed to block620. If the component is not at the near end of life phase, the process600may return to block605.

At block620, the estimation computer100may transmit a notification to the owner of the target vehicle105. The notification may indicate that the subject component should be evaluated or replaced. The processor125may generate the notification and command the communication interface115to transmit the notification to the owner of the target vehicle105. The notification may be transmitted via any wireless communication protocol. Moreover, the notification may be transmitted via, e.g., email, text message, an in-vehicle alert, or the like.