Real-time vehicle data acquisition and analysis

Abstract

An engine controller, system and method for collecting vehicle data. Drive torque data is determined using the engine controller in the vehicle and is stored in a memory in the vehicle. The drive torque data is stored in a non-time domain format, and may include a histogram of numbers of revolutions at predetermined intervals of drive torque values and/or a matrix of rainflow cycle counts. The drive torque data is temporarily stored in a buffer prior to being stored in the matrix of rainflow cycle counts using back-checking and binning. The drive torque data is downloaded from the vehicle and transmitted to a central data collection center.

Claims

1. A vehicle data collection system, the system comprising: a vehicle comprising a driveshaft and an engine controller, the engine controller comprising: a processor configured to: determine driveshaft torque data by utilizing a simulation model to calculate torque at the driveshaft based on a set of vehicle data including at least one of a vehicle throttle position, a vehicle axle ratio, and a vehicle axle weight, wherein the driveshaft torque data (i) represents torque at the driveshaft for each revolution of the driveshaft over a period in a time-domain and (ii) comprises a plurality of peaks and valleys corresponding to local driveshaft torque maximums and minimums, and using the driveshaft torque data, generate a revolutions-at-torque output comprising (i) a plurality of distinct ranges of driveshaft torque and (ii) counts for each driveshaft torque range, each count being indicative of a particular driveshaft torque of the driveshaft torque data falling within a particular driveshaft torque range, and a memory (i) having a limited capacity such that it is incapable of storing the driveshaft torque data and (ii) configured to store information comprising the revolutions-at-torque output; and a data collection device configured to download the information from the memory.

2. The system of claim 1, wherein the data collection device is configured to download the information when the vehicle is being serviced.

3. The system of claim 2, further comprising a central data collection center configured to receive the downloaded information upon transmission by the data collection device.

4. The system of claim 3, wherein the central data collection center is configured to utilize the information to predict a useful life of at least one of the driveshaft and a component related to the driveshaft.

5. The system of claim 4, wherein the central data collection center is configured to predict the useful life of at least one of the driveshaft and the driveshaft -related component by: converting the revolutions-at-torque output to a histogram plot; and utilizing the histogram plot to estimate a fatigue experienced by the at least one of the driveshaft and the driveshaft-related component at each of the plurality of distinct ranges of driveshaft torque.

6. The system of claim 3, wherein the central data collection center is configured to utilize the information to validate or revise designs of a future version of at least one of the driveshaft and a component related to the driveshaft.

7. The system of claim 1, wherein: the memory comprises a buffer configured for temporary storage; the processor is further configured to utilize the buffer perform rainflow processing on the driveshaft torque data by: applying a rainflow cycle counting rule to organize the driveshaft torque data into rainflow cycles, and generating a rainflow matrix comprising the rainflow cycles; and the memory is configured to store the rainflow matrix as part of the information.

8. The system of claim 7, wherein: the rainflow cycle counting rule is a four-point rainflow cycle counting rule; and applying the rainflow cycle counting rule comprises: initializing the buffer, temporarily storing, by the buffer, a plurality of driveshaft torques of the driveshaft torque data, identifying four consecutive peaks/valleys within the plurality of driveshaft torques, determining whether two intermediary peaks/valleys within the four consecutive peaks/valleys have magnitudes that are bounded by a remaining two peaks/valleys of the four consecutive peaks valleys, and when the two intermediary peaks/valleys have magnitudes that are bounded by the remaining two peaks/valleys, counting the intermediary peaks/valleys as a cycle.

9. A method for obtaining and storing driveshaft torque data for a vehicle comprising a driveshaft and an engine controller, the method comprising: determining, by a processor of the engine controller, driveshaft torque data by utilizing a simulation model to calculate the torque at the driveshaft based on a set of vehicle data including at least one of a vehicle throttle position, a vehicle axle ratio, and a vehicle axle weight, wherein the driveshaft torque data (i) represents torque at the driveshaft for each revolution of the driveshaft over a period in a time-domain and (ii) comprises a plurality of peaks and valleys corresponding to local driveshaft torque maximums and minimums, utilizing, by the processor, a buffer of a memory of the engine controller to perform rainflow processing on the driveshaft torque data by: applying a rainflow cycle counting rule to organize the driveshaft torque data into rainflow cycles, and generating a rainflow matrix comprising the rainflow cycles; storing, by the memory, information comprising the rainflow matrix, the memory having a limited capacity such that it is incapable of storing the driveshaft torque data; and downloading, from the engine controller by a data collection device, the information.

10. The method of claim 9, wherein: the rainflow cycle counting rule is a four-point rainflow cycle counting rule; and applying the rainflow cycle counting rule comprises: initializing the buffer, temporarily storing, by the buffer, a plurality of driveshaft torques of the driveshaft torque data, identifying four consecutive peaks/valleys within the plurality of driveshaft torques, determining whether two intermediary peaks/valleys within the four consecutive peaks/valleys have magnitudes that are bounded by a remaining two peaks/valleys of the four consecutive peaks valleys, and when the two intermediary peaks/valleys have magnitudes that are bounded by the remaining two peaks/valleys, counting the intermediary peaks/valleys as a cycle.

11. The method of claim 9, wherein the data collection device is configured to download the information when the vehicle is being serviced.

12. The method of claim 11, further comprising receiving, by a central data collection center via transmission from the data collection device, the information.

13. The method of claim 12, further comprising utilizing, by the central data collection center, the information to predict a useful life of at least one of the driveshaft and a component related to the driveshaft.

14. The method of claim 13, further comprising: using the driveshaft torque data, generating, by the processor, a revolutions-at-torque output comprising (i) a plurality of distinct ranges of driveshaft torque and (ii) counts for each driveshaft torque range, each count being indicative of a particular driveshaft torque of the driveshaft torque data falling within a particular driveshaft torque range; and storing, by the memory, the revolutions-at-torque output as part of the information.

15. The method of claim 14, further comprising predicting, by the central data collection center, the useful life of at least one of the driveshaft and the driveshaft-related component by: converting the revolutions-at-torque output to a histogram plot; and utilizing the histogram plot to estimate a fatigue experienced by the at least one of the driveshaft and the driveshaft-related component at each of the plurality of distinct ranges of driveshaft torque.

16. The method of claim 12, further comprising utilizing, by the central data collection center, the information to validate or revise designs of a future version of at least one of the driveshaft and a component related to the driveshaft.

17. A vehicle data collection system, the system comprising: a vehicle comprising a driveshaft and an engine controller, the engine controller comprising: a processor configured to: obtain driveshaft torque data that represents torque at the driveshaft for each revolution of the driveshaft over a period in a time-domain, the driveshaft torque data comprising a plurality of peaks and valleys corresponding to local driveshaft torque maximums and minimums, and using the driveshaft torque data, generate a revolutions-at-torque output comprising (i) a plurality of distinct ranges of driveshaft torque and (ii) counts for each driveshaft torque range, each count being indicative of a particular driveshaft torque of the driveshaft torque data falling within a particular driveshaft torque range, and a memory (i) having a limited capacity such that it is incapable of storing the driveshaft torque data and (ii) configured to store information comprising the revolutions-at-torque output; a data collection device configured to download the information from the memory when the vehicle is being serviced; and a central data collection center configured to: receive the downloaded information upon transmission by the data collection device; and utilize the information to predict a useful life of at least one of the driveshaft and a component related to the driveshaft by: converting the revolutions-at-torque output to a histogram plot; and utilizing the histogram plot to estimate a fatigue experienced by the at least one of the driveshaft and the driveshaft-related component at each of the plurality of distinct ranges of driveshaft torque.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) FIG. 1 illustrates a system for collecting drivetrain component data from customer vehicles according to the principles of the present disclosure;

(2) FIG. 2 illustrates a system for collecting drivetrain component data from customer vehicles according to the principles of the present disclosure;

(3) FIG. 3 illustrates a simulation model to be used in an engine controller according to the principles of the present disclosure;

(4) FIG. 4 illustrates an example revolutions-at-torque output according to the principles of the present disclosure;

(5) FIGS. 5A and 5B illustrate peaks and valleys of torque data for rainflow cycle determination according to the principles of the present disclosure;

(6) FIG. 6 illustrates a method of operating a buffer memory with respect to a four-point counting algorithm according to the principles of the present disclosure;

(7) FIG. 7 illustrates a maximum amount of torque data to be stored in a buffer in relation to a number of discrete data levels according to the principles of the present disclosure; and

(8) FIGS. 8A and 8B illustrate four-point cycle determination results with and without binning according to the principles of the present disclosure.

DETAILED DESCRIPTION

(9) Because regenerating data through conducting additional proving ground tests is expensive and time-consuming, and because historical data or consumer-provided data may be unreliable, systems and methods are disclosed herein for generating, collecting and processing drivetrain component data from customer vehicles during the lifespan of the vehicles.

(10) In the disclosed embodiments, a drive shaft torque of a vehicle is determined in the engine controller of the vehicle. The present disclosure describes an process for decomposing the drive shaft torque loading cycles into rainflow cycle counts in real-time. In addition, an additional process measures the vehicle's prop shaft revolutions-at-torque distribution data in real-time. The resultant rainflow cycle count matrix and revolutions-at-torque histogram are stored in an engine controller memory and can be downloaded at a later time.

(11) Further, the present disclosure describes a data acquisition process. The rainflow cycle count matrix and the revolutions at torque histogram data that is stored with an engine controller is downloaded from the vehicle using the data collection device when the vehicle is being serviced at the dealership or a maintenance shop. After download, the data is sent to a data collection center or a testing center where it is further processed and analyzed.

(12) FIG. 1 illustrates a system 100 for collecting drivetrain component data from customer vehicles. In system 100, customer vehicles 110 each include an engine controller 112 that is enabled to collect and process data relating to the use of the vehicle. When a customer takes the vehicle 110 to a dealership or maintenance shop 120 for vehicle maintenance, for example, the technician at the dealership or maintenance shop 120 is authorized to download the collected data from the engine controller 112 in the vehicle 110 and then transmit the downloaded data to a testing center 130 such as a central data collection center. At the testing center 130, the data is received and further processed and analyzed in order to populate the simulations and computational models used at the testing center 130. For example, the collected data could be used to predict the useful life of not only the components actually being used in the customer's vehicle 110, but could also be used as data supporting ongoing design work at the testing center 130.

(13) FIG. 2 illustrates additional details relating to system 100. The engine controller 112 is a programmable controller that is installed in customer vehicles 110. The engine controller 112 acquires real-time engineering data from various vehicle systems. For example, the engine controller 112, which may be a programmed processor, includes a simulation model 114 to calculate a real-time driveshaft torque time history. The driveshaft torque time history is calculated based on acquired data from, for example, the vehicle's throttle position, axle ratio and weight, as well as from calibrated powertrain performance curves.

(14) The calculated driveshaft torque time history data is stored in a memory 116 of the engine controller 112. Because the memory 116 in the engine controller 112 is limited (for example, only 80 bytes may be available), the driveshaft torque time history data cannot be stored in the time domain. Instead, the time domain data is converted into other forms that are able to be stored in the limited-capacity memory 116 for later analysis at a testing center. For example, the time domain engineering data is converted into a two-dimensional revolutions-at-torque histogram and into a three-dimensional rainflow cycle counting matrix, as explained below.

(15) Once the data has been processed and stored in the memory 116 of the engine controller 112, it can be periodically downloaded from the engine controller 112. This can be done, for example, at a dealership or maintenance shop 120. The engine controller 112 must include a wired or wireless port 118 for facilitating the data download. Once downloaded, the data is transmitted to the testing center 130. Transmission can be in the form of an email, a data stream or other transmission. At the testing center 130, the data Is extrapolated so as to be usable in predicting the lifespan of the vehicle components and to provide accurate data for correlation with proving grounds and other prototypal testing.

(16) The simulation model 114 in the engine controller 112 is illustrated in greater detail in FIG. 3. The simulation model 114 may be implemented in software running on the engine controller 112, which may be a programmable processor. Alternatively, the simulation model 114 and its component modules may be implemented in hardware or as a combination of software and hardware. The simulation model 114 uses input vehicle parameters to determine the vehicle's drive torque. The simulation model 114 includes a throttle module 305, an engine module 310, a torque converter module 315, a transmission module 320, an axle ratio module 325 and a vehicle module 330. The throttle module 305 simulates a throttle control signal 355 that is based on desired vehicle performance. The throttle control signal 355 is input to the engine module 310. The engine module 310 calculates engine torque 360 that is used by the torque converter module 315. The output of the torque converter module 315 (torque signal 365) is fed to the transmission module 320. The transmission module 320 multiplies the input torque signal 365 with a gear ratio based on the vehicle's transmission's current state to produce a transmission output prop torque signal 375. The axle module 325 uses the prop torque signal 375 and a final drive ratio signal 380 to determine an axle torque signal 385. The vehicle module 330 uses the axle torque signal 385 and one or more inputs 390 representing variables such as aerodynamic drag and tire rolling resistance to determine an overall drive torque 395. Thus, the engine controller 112 uses the simulation model 114 to determine the vehicle's drive torque under various conditions and at various times.

(17) While the engine controller 112 could store all determined drive torque values with corresponding time values, the memory 116 of the engine controller 112 would quickly be exhausted. So, in order to conserve memory resources, the drive torque/time data is further refined into a format for more direct application at the testing center.

(18) One method of further refining the determined data is to store the number of driveshaft revolutions at various torque levels. In other words, the range of possible torque levels can be divided into specific levels, and then a corresponding count of driveshaft revolutions that occur at each torque level is tallied. The number of torque levels can be adjusted based on memory constraints and desired resolution.

(19) An example revolutions-at-torque output is illustrated in FIG. 4. In the example, the range of torque output is divided into twenty levels ranging from −350 ft-lbs to 1550 ft-lbs. Both the range and the number of sublevels can be modified. For each torque level, the number of driveshaft revolutions that occurred at a torque falling within the corresponding torque level is tallied. Thus, in the example of FIG. 4, only three driveshaft revolutions occurred with drive torques ranging from 850 ft-lbs to 950 ft-lbs, while 901 driveshaft revolutions occurred with drive torques ranging from 350 ft-lbs to 450 ft-lbs.

(20) The revolutions-at-torque output of FIG. 4 can be converted into a histogram plot when the data is received at the testing center. The plot can be used to estimate the fatigue experienced at each torque level. For example, “damage” is defined as the ratio between the actual revolutions to the revolutions-to-failure at a given torque level. Therefore, a higher ratio at a given torque level means that the component is closer to failure.

(21) Another method of further refining the determined data is to store the number of prop shaft torque cycles consistent with a four-point rainflow cycle counting rule. Rainflow cycle counting is generally used to convert a load data stream into a compact matrix format that retains essential fatigue loading information.

(22) Torque measurements can be organized into cycles. To do this, the peaks and valleys of the torque measurements are considered. For example, in FIG. 5A, the illustrated torque data includes four consecutive peaks and valleys (points P1, P2, P3 and P4). To organize the torque data into cycles, the intervening peak and valley points (points P2 and P3) are considered. If points P2 and P3 are bounded by the values of points P1 and P4, then points P2 and P3 (and additional point P2′) are counted as a cycle. If points P2 and P3 are not bounded by the values of points P1 and P4, then no cycle is counted. Thus, in FIG. 5A, two cycles are illustrated. In FIG. 5B, no cycles are illustrated, since none of the illustrated examples show intermediary points P2 and P3 being bounded by the values of points P1 and P4. This four-point rule is summarized by the statement: If |P2−P1|>=|P3−P2| and |P4−P3|>=|P3−P2|, then FROM=P2 and TO=P3, end.

(23) To implement the four-point counting algorithm, the memory 116 in the engine controller 112 must include a buffer. Operation of the buffer with respect to the four-point counting algorithm is illustrated in FIG. 6. The operation of the buffer may be implemented in software running on the engine controller 112, which may be a programmable processor. Alternatively, the operation of the buffer may be implemented in hardware or as a combination of software and hardware. At step 610, the buffer is initialized. At step 615, an incoming point, x, is read. At step 620, the point x is checked to determine if it is either a peak or a valley point. If point x is not a peak or a valley point, the next incoming point is read, replacing the previously read point x (step 615). If point x is either a peak or a valley point, then the buffer count k is incremented (step 625) and point x is stored in the buffer as point y_k (step 630), where y denotes a point value stored in the buffer, and k is the buffer point index. If the buffer has less than four points (step 635), then the next peak or valley point is read into the buffer (step 615). If the buffer already has four points (step 635), then the four-point rule is applied to the four most recent buffer points (y_k−3, y_k−2, y_k−1, y_k) (step 640). If application of the four-point rule results in a cycle being found (step 645), then points y_k−2 and y_k−1 are removed from the buffer and stored in a matrix (representing the From-To values for the rainflow cycle) (step 650). The buffer count is then updated (k=k−2) (step 655), and the buffer is re-evaluated to determine if it has four or more points (step 635). Once again, if the buffer has less than four points, the next point is read into the buffer (step 615). If the buffer has four or more points, the four-point rule is applied again (step 640). If, after application of the four point rule, no cycle is found, the next point is read into the buffer (step 615).

(24) So, in general, the buffer acts as a temporary storage for data points that have not been counted as cycles by the four-point rule. Only peak and valley points are stored in the buffer. This helps to minimize the size of the buffer. Almost all buffer points should eventually be counted as cycles and removed from the buffer. The buffer is initialized by storing the first incoming point and the next peak or valley point. This establishes the initial search direction for peak or valley points. After this, the search direction will always alternate between up or down. After initialization, the buffer will never have less than two points.

(25) When a peak or valley point is detected, it is stored, so the buffer grows by one point. Next, the last four points in the buffer are checked by the four-point rule. If the four-point rule passes, two points will be removed from the buffer. Therefore, there is a net loss of one point in the buffer. However, there may be instances when the four-point rule does not pass for a long period of time, meaning that the buffer could grow without bounds unless additional points can be removed. “Back-checking” involves re-checking the last four points in the buffer every time the four-point rule passes and two-points are removed, since it is possible that more points can be removed because the sequence of the last four points has changed. There is no need to back-check if the four-point rule fails as the preceding points in the buffer have already failed the four-point rule with the same sequence of points. Thus, in practice, back-checking is an efficient way of controlling the buffer size.

(26) After a round of back-checking, the points stored in the buffer must have a pattern given by one of three cases. In a first case, the peak points are all strictly increasing while the valley points are all strictly decreasing. In a second case, the peak points are all strictly decreasing while the valley points are all strictly increasing. A third case is a combination of the first case followed by the second case. Points that do not follow the stable patterns given by any of the three cases are counted as cycles by the four-point rule and are removed from the buffer.

(27) When points stored in the buffer fall into the third case, the buffer can approach its maximum length. The maximum possible buffer length is two times the number of discrete data levels. For example, if the data has n=8 discrete levels, the maximum buffer length is 2n=16 points, as shown in FIG. 7.

(28) If the data values are represented in single-precision format (2^32 discrete levels), then the maximum buffer length will be 2×2^32, which is around 8.6 billion points. However, if the data values are represented by a 1-byte number (2^8 discrete levels), then the maximum buffer length will be 2×2^8, which is 512 points long, meaning that the maximum buffer size will be about 0.5 kB. If the data values are represented by two-byte numbers (2^16 discrete levels), the maximum buffer length will be 2×2^16=131,072 points long, or approximately 262 kB.

(29) Binning can result, however, in some inaccuracies. For example, in FIG. 8A, the peak points all lie in the same bin interval, even though they each are progressively lower than the previous peak. When binning is used, each peak would be considered to have an equal value. Similarly, in FIG. 8B, the valley points all lie in a same bin interval as well, even though they also each are progressively lower than the previous valley. When binning is used, each valley would be considered to have an equal value. Thus, when binning is used, application of the four-point rule will result in cycles being counted from peak to valley. However, when binning is not used, application of the four-point rule will result in cycles being counted from valley to peak. Thus, errors can occur. However, as long as bin intervals are small enough, the errors are able to fall within an acceptable range.

(30) Therefore, a combination of back-checking and binning ensures that a small buffer size may be used in order to collect four-point rule rainflow cycle data. Accordingly, both four-point rule rainflow cycle data and revolutions-at-torque output data is able to be stored in the limited memory 116 of the engine controller 112.

(31) By using the engine controller 112 with the memory 116 configured to use measured vehicle parameters in order to simulate or determine other vehicle parameters (such as drive torque, for example) and to store the revolutions-at-torque data and rainflow cycle data in a sparse format conducive to limited-capacity memory, timely and accurate reporting of vehicle drivetrain component data can be reported to a vehicle manufacturer for population of data simulations and computational models. The data stored in the memory 116 of the engine controller 112 is able to be downloaded when the vehicle 110 is taken to a dealership or maintenance shop 120 for vehicle maintenance. The downloaded data is transmitted to a testing center 130. At the testing center 130, the revolutions-at-torque data and rainflow cycle data is received, processed and analyzed in order to predict the useful life of not only the components actually being used in the customers vehicle 110, but also in order to support ongoing design work at the testing center 130.