DE102015120991A1 - Method and device for wear estimation and maintenance planning for connected vehicle systems - Google Patents

Abstract

A system includes a processor configured to receive vehicle identifying data. The processor is also configured to receive system wear-related data from a vehicle system utilization event. The processor is further configured to aggregate system wear-related data. In addition, the processor is configured to compare system wear-related data with data collected from vehicles for which actual wear measurements have been made to determine a projected system wear condition. In addition, the processor is configured to determine if the projected wear condition exceeds an exchange threshold and to recommend a system maintenance based on the projected wear condition exceeding the replacement threshold.

Description

TECHNICAL AREA

The illustrative embodiments generally relate to a method and apparatus for wear estimation and maintenance planning for connected vehicle systems.

BACKGROUND

The Internet of Things, which for example includes a connected vehicle, creates trailblazing opportunities for vehicle service and maintenance. The ability to provide communication from the vehicle to the original manufacturer and to the dealer and to provide fast and flexible communication back to the driver provides a level of customer service that has not been achieved in the past. Vehicle connectivity enables better anticipation of customer needs and on-demand customer and vehicle communications, leading to ways to improve customer satisfaction and brand loyalty.

Various strategies for providing an estimate of brake pad thickness have been developed. One method employs a fusion of sensors, if used, and driver brake modeling to predict vehicle brake pad life. An algorithm is used that uses various inputs, such as brake pad friction materials, brake pad cooling rate, brake temperature, vehicle mass, road grade, weight distribution, brake pressure, braking energy, braking power, etc., to provide the estimate. The method calculates the brake work using the total work minus losses, such as drag, engine brake and / or brake power, as the brake torque multiplied by the speed divided by the rolling resistance to determine the brake disk and pad temperature. The method then uses the brake temperature to determine the brake pad wear, accumulating the wear for each brake event. A brake pad sensor may be incorporated to provide one or more pad thickness indications that may be used to rework the estimate.

In another strategy, a system and method for improving vehicle diagnostic and predictive algorithms and improving vehicle maintenance practices include collecting data from vehicle components, subsystems, and systems and storing the collected data in a database. The collected and stored data may be from multiple sources for similar vehicles or similar components and may include various types of error codes and work codes as well as other information such as operational data and failure mechanism data that are merged together. The method generates classes for different vehicle components, subsystems and systems and builds feature extractors for each class using data mining techniques of the data stored in the database. The method also generates classifiers that classify the characteristics for each class. The feature extractors and feature classifiers are used to determine when a fault condition has occurred for a vehicle component, vehicle subsystem, or vehicle system.

SUMMARY

In a first illustrative embodiment, a system includes a processor configured to receive vehicle identifying data. The processor is also configured to receive system wear-related data from a vehicle system utilization event. The processor is further configured to aggregate system wear-related data. In addition, the processor is configured to compare system wear-related data with data collected from vehicles for which actual wear measurements have been made to determine a projected system wear condition. In addition, the processor is configured to determine whether the projected wear condition exceeds an exchange threshold and system maintenance based on the projected wear condition the exchange limit has been exceeded, recommended.

In a second illustrative embodiment, a system includes a processor configured to receive vehicle identifying data. The processor is also configured to receive brake wear related data from a vehicle system usage event. Furthermore, the processor is configured to aggregate brake wear related data. The processor is further configured to compare brake wear related data to data acquired from vehicles for which actual wear measurements have been made to determine a projected brake wear condition. Further, the processor is configured to determine if the projected wear condition exceeds an exchange threshold and to recommend a system maintenance based on the projected wear condition exceeding the replacement threshold.

In a third illustrative embodiment, a non-transitory computer-readable storage medium stores instructions that, when executed, cause a processor to perform a method that includes receiving data identifying a vehicle. The method also includes receiving system wear-related data from a vehicle system utilization event. Further, the method includes aggregating system wear-related data and comparing system-wear-related data with data collected from vehicles for which actual wear measurements have been made to determine a projected system wear condition. In addition, the method includes determining whether the projected state of wear exceeds an exchange limit and recommending system maintenance based on the projected state of wear exceeding the replacement limit.

BRIEF DESCRIPTION OF THE DRAWINGS

1 shows an illustrative vehicle data processing system;

2A shows an illustrative system for reporting vehicle system wear related data and scheduling maintenance;

2 B shows some illustrative examples of actual data to be collected for a specific system;

3 shows an illustrative process for reporting brake wear data and scheduling a service;

4 shows an illustrative process for assessing brake wear and

5 shows an update process for modeling an estimate of brake wear.

DETAILED DESCRIPTION

Detailed embodiments of the present invention are disclosed herein if necessary; however, it should be understood that the disclosed embodiments are merely exemplary of the invention, which may be embodied in various and alternative forms. The figures are not necessarily to scale; some features may be exaggerated or minimized to show details of particular components. Thus, specific structural and functional details disclosed herein should not be considered as limiting, but merely as a representative basis for teaching one skilled in the art to variously employ the present invention.

1 FIG. 10 illustrates an exemplary block topology for a vehicle-based computing system 1 (vehicle-based computing system, VCS) for a vehicle 31 An example of such a vehicle-based data processing system 1 is the SYNC system manufactured by THE FORD MOTOR COMPANY. A vehicle equipped with a vehicle-based computing system may have a visual front-end surface 4 included in the vehicle. The user may also be able to interact with the interface if, for example, it is provided with a touch screen. In another illustrative embodiment, the interaction is through keystrokes, a natural language dialog system with automatic speech recognition and speech synthesis.

In the in 1 Illustrated illustrative embodiment 1 controls a processor 3 at least part of the operation of the vehicle-based data processing system. The processor provided in the vehicle enables onboard processing of commands and routines. Furthermore, the processor is both non-permanent memory 5 as well as a permanent memory 7 connected. In this illustrative embodiment, the non-permanent memory is a random access memory (RAM) and the persistent memory is a hard disk drive (HDD) or flash memory. In general, a permanent (non-volatile) memory may include all forms of memory that maintain data when a computer or other device is powered off. These include, but are not limited to, HDD, CD, DVD, magnetic tape, solid state drives, portable USB drives, and any other suitable form of permanent storage.

The processor is also provided with a number of different inputs that allow the user to connect to the processor. In this illustrative embodiment is a microphone 29 , an auxiliary entrance 25 (for input 33 ), a USB input 23 , a GPS input 24 , a screen 4 , which may be a touch screen display, and a BLUETOOTH input 15 all provided. An input selector 51 is also provided to allow a user to switch between different inputs. An input in both the Microphone as well as the auxiliary connector is through a transducer 27 converted from analog to digital before being routed to the processor. Although not shown, many of the vehicle components and auxiliary components in communication with the VCS may use a vehicle network (such as, but not limited to, a CAN BUS) to route data to and from the VCS (or components thereof).

Outputs to the system can be a visual indicator 4 and a speaker 13 or a stereo system output, but are not limited thereto. The speaker is with an amplifier 11 and receives its signal from the processor 3 through a digital-to-analog converter 9 , An output can also be sent to a remote BLUETOOTH device, such as a PND 54 , or a USB device, such as a car navigation device 60 , along the bidirectional data streams, at 19 respectively. 21 are shown done.

In an illustrative embodiment, the system uses 1 the BLUETOOTH transceiver 15 to come up with a nomadic device 53 the user (eg mobile phone, smartphone, PDA or any other device with wireless remote network connectivity) 17 , The nomadic device can then be used with a network 61 outside the vehicle 31 by, for example, a communication 55 with a mobile phone mast 57 to communicate 59 , In some embodiments, the mast 57 be a WiFi access point.

Exemplary communication between the nomadic device and the BLUETOOTH transceiver is through a signal 14 shown.

The connecting (pairing) of a nomadic device 53 and the BLUETOOTH transceiver 15 can by a button 52 or a similar input. Accordingly, the CPU is instructed to connect the on-board BLUETOOTH transceiver to a BLUETOOTH transceiver in a nomadic device.

Data can be between the CPU 3 and the network 61 using, for example, a data plan, data-over-voice or DTMF tones with the nomadic device 53 are associated. Alternatively, it may be desirable to have an onboard modem 63 with an antenna 18 integrate to data between the CPU 3 and the network 61 via the voice band 16 , The nomadic device 53 can then be used with a network 61 outside the vehicle 31 by, for example, a communication 55 with a mobile phone mast 57 to communicate 59 , In some embodiments, the modem 63 a communication 20 with the mast 57 to communicate with the network 61 produce. As a non-limiting example, the modem 63 be a USB cellular modem and communication 20 can be a mobile communication.

In an illustrative embodiment, the processor is provided with an operating system that includes an API to communicate with modem application software. The modem application software may access an embedded module or firmware on the BLUETOOTH transceiver to complete wireless communication with a remote BLUETOOTH transceiver (such as that found in a nomadic device). Bluetooth is a subset of IEEE 802 PAN protocols (PAN = personal area network, personal network). IEEE 802 LAN protocols (LAN = local area network, local area network) include Wi-Fi and have a considerable cross-functionality with IEEE 802 PAN , Both are suitable for wireless communication within a vehicle. Other means of communication that can be used in this field are free-space optical communication (such as IrDA) and non-standardized consumer IR protocols.

In another embodiment, the nomadic device includes 53 a modem for voice band or broadband data communication. In the data-over-voice embodiment, a technique known as frequency division multiplexing may be implemented whereby the owner of the nomadic device may talk over the device while data is being transmitted. At other times, if the owner does not use the device, the data transfer may use the entire bandwidth (300 Hz to 3.4 kHz in one example). Although frequency multiplexing for analog mobile communication between the vehicle and the Internet may and still is commonplace, it has largely been replaced by Code Domain Multiple Access (CDMA), Time Domain Multiple Access (TDMA), Replaces space domain multiple access (SDMA) for digital cellular communication. These are all ITU-IMT-2000 compliant (3G compliant) standards and offer data transfer speeds of up to 2 MB / s for inbound or outbound users and 385 KB / s for users in a moving vehicle. 3G standards are now being replaced with IMT-Advanced (4G), which offers 100 MB / s for users in a vehicle and 1 GB / s for stationary users. If the user has a data plan associated with the nomadic device, it is possible that the data plan will allow broadband transmission and the system could use a much wider bandwidth (speeding up the data transfer). In one more Another embodiment is the nomadic device 53 replaced by a mobile radio communication device (not shown) attached to the vehicle 31 is installed. In yet another embodiment, the NG 53 may be a wireless LAN (local area network) device used to communicate over, for example, and without limitation, an 802.11g network (ie, WiFi) or a WiMax network is capable.

In one embodiment, incoming data may be provided by the nomadic device via a data-over-voice connection or a data plan, through the on-board BLUETOOTH transceiver, and into the internal processor 3 of the vehicle. For example, in the case of certain temporary data, the data may reside on the HDD or other storage medium 7 stored until a point in time when the data is no longer needed.

Additional sources that can connect to the vehicle include a personal navigation device 54 with for example a USB connection 56 and / or an antenna 58 , a vehicle navigation device 60 with a USB connection 62 or another connection, an onboard GPS device 24 or a remote navigation system (not shown) with connectivity to the network 61 , USB is one of a class of serial networking protocols. IEEE 1394 (FireWireTM (Apple), i.LINKTM (Sony) and LynxTM (Texas Instruments)), serial protocols of the EIA (Electronics Industry Association), IEEE 1284 (Centronics Port), S / PDIF (Sony / Philips Digital Interconnect Format) and USB-IF (USB Implementers Forum) are the backbone of the serial device-to-device standards. Most of the protocols can be implemented for either electrical or optical communication.

Furthermore, the CPU could be in communication with a variety of other auxiliary devices 65 stand. These devices can be connected wirelessly 67 or a wired connection 69 get connected. The auxiliary device 65 may include, but is not limited to, personal media players, wireless health devices, portable computers, and the like.

Additionally or alternatively, the CPU could be with a vehicle-based wireless router 73 using, for example, a WiFi transceiver ( IEEE 803.11 transceiver ) 71 be connected. This could allow the CPU to deal with remote networks in the area of the local router 73 connect to.

In addition to exemplary operations performed by a vehicle computing system residing in a vehicle, in certain embodiments, the example operations may be performed by a computing system in communication with a vehicle computing system. Such a system may include, but is not limited to, a wireless device (eg, and without limitation, a mobile phone) or a remote data processing system (eg, and without limitation, a server) connected by the wireless device. In summary, such systems may be referred to as vehicle-associated computing systems (VACS). In certain embodiments, certain components of the VACS may perform certain portions of an operation depending on the particular implementation of the system. By way of example and not limitation, when a process includes a step of sending or receiving information with a connected (paired) wireless device, it is likely that the wireless device will not perform that portion of the process because the wireless device does not provide information to itself would "send and receive" from himself. One of ordinary skill in the art will understand when it is inappropriate to apply a particular data processing system for a given solution.

In each of the illustrative embodiments discussed herein, an exemplary, non-limiting example of an operation performed by a data processing system is shown. With respect to each operation, it is possible for the data processing system to perform the operation to be configured as a special purpose processor for the limited purpose of performing the operation to perform the operation. Not all processes must be performed in their entirety and are to be understood as examples of types of operations that may be performed to achieve elements of the invention. Additional steps may be added to or removed from the example operations.

2A shows an illustrative system for reporting vehicle system wear related data and scheduling maintenance. In the in 2 Illustrative example shown may be a modem equipped vehicle 201 use a telematics controller or an OBD2-connected modem to continuously monitor, for example, vehicle factors that affect vehicle system wear. Specific examples relating to brake wear are given in the illustrative examples, but it should be understood that the techniques and processes presented herein are applicable to a variety of mechanical and mechanical applications electrical systems could be applied. In essence, any system that shows a clear correlation between vehicle measurable data and actual part wear or actual part wear is a candidate for inclusion in the illustrative embodiments.

With respect to the brakes, vehicle measurable data includes, but is not limited to, vehicle deceleration, vehicle speed, ambient temperature, ambient humidity, vehicle location, abrupt stops, yaw rate, lateral acceleration, application of the brakes, and so forth. This information can be retrieved from vehicle sensors and provided to a vehicle network, such as the CAN network. The telematics controller or other modem / communication providing device may download messages containing this data from the CAN or other vehicle network and transport the data to a remote server. In other mechanical systems, measurable mechanical data can be measured with a clear correlation with the wear of the mechanical system (various forces exerted during use and overall usage, which is generically referred to as a duty cycle) and discussed with respect to the brake system be used to estimate the wear on the mechanical system. Similarly, in electrical systems where usage and electrical measurements correlate with wear in the electrical system, these factors may be used as a representative of "wear" on the system according to the illustrative embodiments.

The remote server 203 can aggregate the received data based on the vehicle identification number (FIN) and the time, so that a model for the daily vehicle system use for individual vehicles can be obtained. These aggregated data for a variety of vehicles may be used to form a continuously learning system wear model (in this case a brake pad wear model). A correlation between energy derived by braking (eg, the integral of vehicle deceleration multiplied by mass over time or the difference between vehicle motive energy before and after a braking event) may be made with a brake pad replacement frequency. This can vary with location and environmental conditions. The accuracy of the results can be refined over time by checking actual log wear when servicing the brakes of a vehicle.

By providing this calculation for a large number of vehicles, a statistical model of maintenance events can be obtained depending on the vehicle operating cycle and the vehicle location / environment. A surveillance system 205 For example, using this model, it can predict when a pad replacement will be required by extrapolating the duty cycle for each vehicle and comparing that duty cycle with the statistical maintenance limit (eg, the point at which the brakes have worn out to a replacement condition). When the limit overshoot is observed / predicted, a service recommendation for the vehicle may be generated.

For all vehicles in a given monitoring set (the "fleet"), duty cycle data can be continuously monitored at a relatively low cost. This typically involves existing sensors and computations that can be made on the basis of data observable using currently installed vehicle systems. In the brake model, for example, derived energy is measured as the integral of vehicle deceleration multiplied by mass over time, resulting in the delta between vehicle motive energy before and after a brake event. Since the vehicle mass is generally known and the deceleration can be easily measured, no additional sensors in a vehicle are required to obtain this data.

The data itself is aggregated with other previously measured and observed data to provide an aggregated "work cycle" (ie, usage and observed applicable forces during use) for the vehicle up to the current time (or, for example, from a recent system repair to the current time). to develop. This duty cycle may be compared to known thresholds for similar vehicles obtained by taking actual wear values from a selected subset of vehicles and recording the actual work cycles associated with those wear values. These actual wear values do not have to be measured for all vehicles; it is sufficient to measure the values for a certain subset of similarly equipped vehicles and to extrapolate the likely wear values on similar vehicles with similar duty cycle values. If the measured data for a given vehicle is based on a probability (based on the measured duty cycle of the vehicle compared to the duty cycle of a vehicle that is explicitly known to exhibit system wear with the measurement) of system wear that is a Requires repair, point out, a service recommendation can be generated.

Once the service recommendation has been generated, it can be sent to a garage system management broker 209 for scheduling a service to the particular vehicle identified with respect to the request 207 become. This system may manage one or more garages / dealerships and may be responsible for scheduling maintenance for the managed sites. After finding an available time slot to service the brakes, the process may become a service offer 221 to the vehicle for delivery to the driver. This may include any number of recommended times and / or locations, and may be presented to the driver in a selectable format (eg, via touch response, voice response, etc.).

Once the customer accepts an available time slot, the process may respond 213 Send to the specific workshop, so that the workshop expects the customer at the agreed time. The customer then meets at the workshop 215 one and the service is carried out.

In the illustrative examples, the service is performed based on an estimated requirement of brake repair based on the estimated wear. Accordingly, it may be useful to check the actual wear on the pads to determine how accurate the wear estimate actually was. Once the pads have been replaced, this data can be used 219 (by the management system broker, or directly) to the monitoring system for updating the model of brake pads so that future modeling more accurately reflects the actual condition of blocks in service.

2 B FIG. 11 shows an illustrative example of a large (but not exhaustive) number of wear-affecting variables that may be measured with respect to an exemplary brake system. This is not intended to be in any way limiting, but merely illustrative of the data that may be acquired with respect to a system for comparison with approximate wear on the system and variables that may be affected by that data.

For example, in this illustrative embodiment, an instantaneous ambient temperature may be used 202 a factor for the brake operating temperature 262 be. The target vehicle 204 may have associated data related to the brake system design 226 , the payload mass 228 (which can be appreciated or measurable), the design geometry 246 , the vehicle mass 248 , the initial block thickness 256 , the permissible block thickness 258 and the heat dissipation capability 262 point out (as can be seen from this model, some data are not measured, but are only data related to a vehicle make / model / vehicle series, etc.).

The current elevation 206 and the instantaneous speed 208 can be used to the instantaneous potential energy 254 or the momentary kinetic energy 244 to determine. The timestamp 230 . 232 indicate instantaneous on / off states 210 the brake system, which in turn can be used to the brake event energy 260 and the brake hardness 250 to determine. Similarly, the ignition timestamps demonstrate 234 . 236 on on / off states of ignition 214 which may be factors at brake operating temperatures. Other instant measurable quantities, such as acceleration 212 , Humidity 216 , Vehicle inclination 218 , Vehicle location 220 and date 222 , affect different brake calculations. The GPS position can be used when determining the terrain type 238 and the work cycle 252 be used. Many of the data can be used to calculate the accumulated instantaneous wear 266 and the instant block thickness 268 to "guess", which in turn can be used to the remaining club life 270 to extrapolate. A certain number of days before being projected by a log he has an acceptable thickness limit 272 exceeds, the process may generate a maintenance notification.

At the same time lead inspection events 224 for a selected group of vehicles to actual log thickness data based on some or all of the above factors. This actual data may be stored relative to some or all of the above factors and this data may be compared to data for vehicles on the road for which no inspection events have occurred. For vehicles having brakes (in this example) with similar mechanical properties and having similar measurable magnitudes, it is believed that the brake wear in these vehicles approximates the observed brake wear in the vehicle for which the inspection event occurred. The actual block thickness 240 and a date stamp 242 are also recorded so that later measurement will reveal attrition based on the factors measured since the last date stamp (which adds further extrapolation to vehicles allows for which no actual measurements are taken).

3 shows an illustrative process for reporting brake wear data and scheduling a service. With respect to the illustrative embodiment described in this figure, it is noted that a general purpose processor may be temporarily activated as a special purpose processor for the purpose of performing some or all of the example methods shown herein. When executing code that provides instructions for performing some or all steps of the method, the processor may be temporarily converted as a special processor until the time the method is completed. In another example, firmware acting in accordance with a preconfigured processor may cause, to a reasonable extent, the processor to act as a special purpose processor provided for the purpose of performing the method or some reasonable variation thereof.

This in 3 Illustrative example shown illustrates a process running on the vehicle system, although some or all of the operation (with reasonable modifications) could be made on the surveillance system or on other systems other than vehicle systems. In this illustrative example, the process captures the appropriate system wear-related data (in this example, brake wear related data). Since data impacting the outcome may vary with location and refinement of the modeling, it may be useful to specify which data should be captured. Since the vehicle is capable of communicating with the remote monitoring system in which modeling may be performed and refined, instructions may be provided for acquiring new data at given times for the vehicle.

For example, in the brake example, the process may periodically command the vehicle to measure a braking distance with respect to the braking force. Based on the recorded observed data for similar vehicles, these measured data can be used to determine a reduction in brake pads. This can be achieved, for example, by comparing the measured data with data measured in vehicles for which wear has actually been measured. These and similar comparisons can give at least a rough estimate of the accuracy of models of wear. Other variables and their respective benefits may change over time, and by dynamically modifying the collected data, the system may retain data collection relevant and useful.

Any collected data may, if desired, be exported to the monitoring system along with relevant vehicle identification and timestamps for assessment 303 , The monitoring system may, upon assessment, notify the driver when any maintenance is likely to be required 305 , If maintenance is not likely to be required, the process may continue to collect the appropriate vehicle data and provide updated data to the monitoring system.

If and when maintenance is required, the process may communicate with a dealer / workshop management system to receive a service offer 307 , This offer may include incentives to use certain dealerships or time slots, or incentives to service before the brake pads are dangerously worn out. The process may present the received service options to a customer in a selectable manner (or via a secondary device such as a telephone) and receive a customer selection of a service option 309 ,

If no service option is selected at this time, the process may continue at periodic intervals to offer a service until the offers are ignored / deactivated or a service elsewhere (outside the automatic scheduling options, although service could be performed at a merchant) is identified by the automatic scheduling options, and could be scheduled by a different way) is performed 311 , On the other hand, if the customer chooses to participate in the service offering, the process may receive scheduling options for the customer 313 , These options may be drawn from available service slots that are large enough to complete brake replacement / repair work, and may be identified by one or more local service providers, for example, by the monitoring system. The driver may have a preferred service provider and times may be provided to that provider, but times may also be provided based on service providers who are near the vehicle location, offering promotional rates, etc.

The options for planning can be presented to the customer in a selectable way. For example, without limitation, the customer may select a language-selectable set of options, a touch-selectable set of options, a scroll-and-select list, and so forth. to get presented. The options can also be presented visually or acoustically. In this example, the customer selects one of the presented options 315 and as a result an appointment is made 317 , The process will monitor wear using the current model until the appointment is completed 319 , Once the appointment is completed, the actual wear on the blocks and any other required brake repair data may be sent to the modeling process for comparison with the estimated wear and repair needs and for use in enhancing the modeling process.

For example, a model may project, without limitation, that a set of blocks are 70% worn and that the calipers need to be repaired based on data observed about the life of the brakes when processed through modeling. which was developed from the same or similar vehicles and / or in similar environments. During the actual repair it can be observed that the saddles are functional and usable and the blocks are only 55% worn. These data can be used to refine the model, either general and / or for the specific vehicle, the specific vehicle make / model, etc. The specific vehicle model can be more drastically influenced by the observed data than a generalized model that collects data from may require a number of vehicles before making a drastic adjustment to avoid outlier corruption. By using generalized models of various types (environmental wear, brand / model wear, vehicle class wear) and / or vehicle specific models based on the observed impact of vehicle-specific factors, the process can be refined over time and various braking impairments can be modeled for a specific set of brake pads.

4 shows an illustrative process for estimating system wear (in the example of brake wear). With respect to the illustrative embodiment described in this figure, it is noted that a general purpose processor may be temporarily activated as a special purpose processor for the purpose of performing some or all of the example methods shown herein. When executing code that provides instructions for performing some or all steps of the method, the processor may be temporarily converted as a special processor until the time the method is completed. In another example, firmware acting in accordance with a preconfigured processor may cause, to a reasonable extent, the processor to act as a special purpose processor provided for the purpose of performing the method or some reasonable variation thereof.

In this illustrative example, vehicle data relating to a decelerating vehicle is detected. The data is received at a processing point at which modeling is performed. In this illustrative example, this is a monitoring system and the vehicle data has been transmitted to the monitoring system via a wireless connection. In other examples, the modeling process could be performed directly on a portable device or in a vehicle computer if the processing capacity is sufficient. Updates to a remotely stored model could be propagated to the locally running modeling process, if appropriate.

The process receives vehicle data 401 that include, but are not limited to, vehicle identification, any required vehicle characteristics, environmental data, road data, etc. With respect to the equipment provided to a given vehicle, it may be stored at a starting point and updated as necessary when the vehicle configuration is modified (eg, without limitation, spare parts, other tires, etc.). Environmental and road data may be of a more dynamic nature and may either be captured directly by the vehicle or, for example, crowdsored for a given location or location.

In addition to the vehicle data, the process can brake data 403 Among other things, indicate the braking force, a reduction in speed over a distance, the braking time, etc. Any braking data useful for modeling the wear on the brakes can be received here. The modeling process may then use the received data in conjunction with one or more models or algorithms to calculate the projected wear on the pads and other brake parts. In this example, the vehicle data included a vehicle identification number (FIN) or other vehicle identifying characteristic usable for identifying a specific vehicle. This allows the braking data to be stored for the specific vehicle and, for example, the use of any models designed for the specific vehicle when models are implemented at such a refined level.

The brake data wear calculations may be for the vehicle 407 aggregated to model a current state of the vehicle brake system. For example, this data may be subject to a duty cycle limit 409 for the vehicle to determine if the brakes have reached a state where repair / replacement is recommended. When the brake condition has exceeded the replacement / repair limit 411 , the process may recommend a brake service / brake maintenance 413 , Otherwise, the process may be aborted until more data is available.

Since the actual wear on a subset (as opposed to the total) of a vehicle population can be measured, wear modeling can be achieved by applying a variation of the Kaplan-Meier product limit estimator. In Kaplan-Meier, S (t) is the probability that an element from a given population will have a lifetime wear that exceeds t. From a pattern population of size N, the observed number of N pattern members can be represented as follows: t ₁ ≦ t ₂ ≦ t ₃ ≦ ... ≦ t _N.

According to the teaching, t _i n _i , the number of "vulnerable" just before time t _i , and d _i the number of deaths at time t _i (death = wear requiring wear). The Kaplan-Meier estimator is the nonparametric estimate of the maximum probability of S (t). He is a product of the form:

This equation can be used to estimate the probability that a system of the group of vehicles will experience wear that exceeds t.

Also used is a modified survival regression model. This is typically used in clinical settings to show the likelihood that a patient will survive cancer after treatment x, and the basic formula is: S (T | x) = exp [-∫ T / 0h (t | x) dt], where S (T | x) is the survival probability (ie, the "reliability") of a patient caused by the vector of explanatory variables or covariates x. h (t | x) is the danger function.

Established covariates are represented by the following: h (t | x) = h ₀ (t) exp {β ^T _x }, where t is the time to failure (death), h (t | x) is the hazard function, h ₀ (t) is the base hazard function, β ^{T is} the transposed vector of coefficients.

Time-dependent covariates are represented by the following:

wobei w der Bremsklotzverschleiß ist, Φ[] die normale Standard-KVF für Normal und Log-Normalverteilungen und den kleinsten Extremwert-KVF für die Weibull-Verteilung ist; µ, σ der Positions- bzw. Maßstabparameter der Verschleißverteilung ist, x der Vektor erklärender Werte ist (z. B., ohne Einschränkung, verbrauchte Energie, Temperatur, Luftfeuchtigkeit usw.).This formula can be modified to a wear context formula:

where w is the pad wear, Φ [] is the normal standard KVF for normal and log normal distributions and the minimum extreme KVF for the Weibull distribution; μ, σ is the position or scale parameter of the distribution of wear, x is the vector of explanatory values (eg, without limitation, consumed energy, temperature, humidity, etc.).

In this modified formula, the specified covariates are represented by the following: μ _w (x) = β ₀ + β _i x, where β _i model parameters are estimated from data.

Using these formulas, it is possible to model the probability of wear on a vehicle exceeding a predetermined limit (recorded for each vehicle identification number (FIN)). These formulas can also be used for each vehicle (which includes a large number of vehicles for which actual wear data has never been measured, merely extrapolated) the projected incremental mileage (based on a recorded mileage accumulation path) to a critical wear point to determine. This prediction may be communicated to a driver and a manufacturer or dealer so that an appropriate action can be taken long before the system exceeds a critical wear point. Furthermore With knowledge of the brake energy accumulation for each vehicle, it is then possible to predict the number of days remaining up to a critical wear point - thereby allowing to schedule (via the FIN) individualized service appointments in a calendar time.

5 shows an update process for modeling an estimate of brake wear. With respect to the illustrative embodiment described in this figure, it is noted that a general purpose processor may be temporarily activated as a special purpose processor for the purpose of performing some or all of the example methods shown herein. When executing code that provides instructions for performing some or all steps of the method, the processor may be temporarily converted as a special processor until the time the method is completed. In another example, firmware acting in accordance with a preconfigured processor may cause, to a reasonable extent, the processor to act as a special purpose processor provided for the purpose of performing the method or some reasonable variation thereof.

In this illustrative example, the process again collects the vehicle and system wear related data for any appropriate system usage cases (in this example, deceleration). This data may be aggregated locally on the vehicle and delivered on demand at specified intervals to avoid transmission of data and bandwidth usage each time the brakes are applied. The process also uses modeling algorithms to determine the estimated wear on the vehicle system 503 , and stores the system state data 505 in relation to the single vehicle.

If a service is performed on the vehicle 507 , the model may be updated based on the actual, observed condition of the brakes. Participating dealers and service garages are encouraged to report the data to enhance the modeling process so that brake exchange can be more accurately modeled and customers can be adequately informed when the brakes need to be replaced.

When the brakes are actually serviced, the service location may check the brake components and report actual wear and damage data received from the modeler 509 , These can be used to revise the wear estimates 511 so that the incoming data more accurately models the actual wear observed on the brake system components. Once the appropriate modifications to the estimates have been made, any changes to the model itself may be made as appropriate.

For example, assuming sufficient data is received for a given climate, it can be observed that braking in winter in conditions below 10 degrees Fahrenheit will result in a greater increase in brake wear than expected. Accordingly, estimates based on braking in such conditions may be suitably modified. Additionally or alternatively, the model itself may be revised to incorporate the observed change for received data including a temperature condition below 10 degrees Fahrenheit.

By using the modeling process, a need for brake replacement can be more accurately predicted and communicated to a customer. At the same time, participating dealers and service locations can report actual data to enhance the modeling process. These sites may also provide available service slots for use by customers whose brakes have been projected to require repair.

Although exemplary embodiments are described above, it is not intended that these embodiments describe all possible forms of the invention. Rather, the words used in the specification are words of description rather than limitation, and it is understood that various changes may be made without departing from the spirit and scope of the invention. Moreover, the features of various implementation embodiments may be combined to form further embodiments of the invention.

QUOTES INCLUDE IN THE DESCRIPTION

This list of the documents listed by the applicant has been generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Cited non-patent literature

• IEEE 802 PAN protocols [0023]
• IEEE 802 LAN protocols [0023]
• IEEE 802 PAN [0023]
• IEEE 1394 [0026]
• IEEE 1284 [0026]
• IEEE 803.11 Transceivers [0028]

Claims (20)

 A system comprising: a processor configured to: Receiving data identifying a vehicle; Receiving system wear-related data from a vehicle system utilization event; Aggregate system wear-related data; Comparing system wear-related data with data collected from vehicles for which actual wear measurements have been made to determine a projected system wear condition; Determining whether the projected wear condition exceeds an exchange limit; and Recommending a system service based on the projected wear condition exceeding the replacement threshold.  The system of claim 1, wherein the processor is further configured to provide an estimated time to an exchange based on an observed usage representing a projected usage as compared to a known wear for vehicles exhibiting a usage similar to the projected usage for which actual wear data were measured.  The system of claim 2, wherein the processor is configured to report the estimated time to replacement to a driver.  The system of claim 1, wherein the processor is configured to store an aggregated estimated wear on a vehicle record identifiable based on the received vehicle identifying data.  The system of claim 1, wherein the processor is configured to request transmission of one or more available service time slots in response to recommending a system service.  The system of claim 5, wherein the processor is configured to receive actual system wear data from a service location associated with the selected service slot after a system repair, and wherein the processor is configured to implement a system wear model based on the received system wear data and the system wear pattern aggregated, system-related data update.  The system of claim 1, wherein the processor is configured to generate a generalized system wear model based on a duty cycle that expresses system wear as a function of vehicle usage and indicative of the comparison for data detected by vehicles for the actual one Wear measurements were made, usable.  A system comprising: a processor configured to: Receiving data identifying a vehicle; Receiving brake wear related data from a vehicle system utilization event; Aggregating brake wear related data; Comparing brake wear related data to data collected from vehicles for which actual wear measurements have been made to determine a projected brake wear condition; Determining whether the projected wear condition exceeds an exchange limit; and Recommending a system service based on the projected wear condition exceeding the replacement threshold.  The system of claim 8, wherein the processor is further configured to provide an estimated time to an exchange based on an observed usage representing a projected usage as compared to a known wear for vehicles exhibiting a usage similar to the projected usage for which actual wear data were measured.  The system of claim 9, wherein the processor is configured to report the estimated time to replacement to a driver.  The system of claim 8, wherein the processor is configured to store an aggregated estimated wear on a vehicle record identifiable based on the received vehicle identifying data.  The system of claim 8, wherein the processor is configured to request transmission of one or more available service time slots in response to recommending a brake service.  The system of claim 12, wherein the processor is further configured to receive a customer selection of a service timeslot. The system of claim 13, wherein the processor is configured to receive actual brake wear data from a service location associated with the selected service slot after brake repair, and wherein the processor is configured to apply a brake wear model based on the received brake wear data and aggregated data related to brake wear.  A non-transitory computer readable storage medium storing instructions that, when executed, cause a processor to perform a method comprising: Receiving data identifying a vehicle; Receiving system wear-related data from a vehicle system utilization event; Aggregate system wear-related data; Comparing system wear-related data with data collected from vehicles for which actual wear measurements have been made to determine a projected system wear condition; Determining whether the projected wear condition exceeds an exchange limit; and Recommending a system service based on the projected wear condition exceeding the replacement threshold.  The storage medium of claim 15, wherein the method further comprises determining an estimated time to an exchange based on an observed usage representing a projected usage as compared to a known wear for vehicles exhibiting a usage similar to the projected usage the actual wear data has been measured.  The storage medium of claim 16, wherein the method includes reporting the estimated time to replacement to a driver.  The storage medium of claim 15, wherein the method includes storing an aggregated estimated wear on a vehicle record identifiable based on the received vehicle identifying data.  The storage medium of claim 15, wherein the method includes requesting transmission of one or more available service time slots in response to recommending a system service.  The storage medium of claim 19, wherein the method further comprises receiving a customer selection of a service timeslot.

Images