Patent Application
20150330317
The technology herein relates generally to the design, analysis and testing of transmission and driveline systems. More particularly, the technology herein relates to real-time vehicle drive torque data acquisition from customer vehicles to improve testing of transmission and driveline systems.
Traditionally, a durability validation process for powertrain system and components has three different levels. These levels include vehicle level testing, system level testing, and component level testing. In vehicle level testing, vehicles are commonly tested at a proving ground based on specific powertrain endurance schedules. For system level testing, offline system data such as torque-at-speed and gears are utilized to create transmission and differential dynamometer testing schedules. For component level testing, offline component data such as rainflow cycle results are utilized to develop component bench test criteria.
In practice, a vehicle durability design and validation target is based on a proving ground powertrain endurance schedule. The proving ground powertrain endurance schedule is derived based on percentile customer usage information. For example, a proving ground powertrain endurance schedule can be based on information reflecting the 95th percentile of customer usage. Specifically, the proving ground powertrain schedule is derived by studying the poll data from a pool of vehicle owners who volunteer to participate in answering survey questionnaires. The answers are then translated into engineering requirements as part of the proving ground schedule. However, the resultant engineering requirements tend to be highly subjective due to the subjective nature of customer interpretation and responses to the survey questionnaires.
Additional variableness occurs at the powertrain system and component level testing. Traditionally, for powertrain system and component level testing, the design and validation test target have included historical data collected from various sources and data acquired from a test vehicle running on a proving ground based on the above-mentioned proving ground schedules. However, historical data often lacks context and may not be able to be correlated with actual use patterns. Further, the acquired proving ground data tends to be subjective and prone to error. As a result, the use of the data is limited due to a lack of confidence in the data accuracy. When the data is used, design targets tend to be set artificially high in order to compensate for the low confidence rating.
Thus, there is a need to acquire real-time customer usage data to substantiate and define a more accurate representative of 95th percentile customer usage in an objective manner. There is also a need to improve the quality of data used to construct vehicle simulations and models for prototype durability testing. Additionally, there is a need to improve the efficiency of obtaining and processing component data so as to improve the design and testing stages of powertrain development.
In one form, the present disclosure provides an engine controller in a vehicle. The engine controller includes a processor configured to determine drive torque data for the vehicle, and a memory configured to store the drive torque data in a non-time domain format. The engine controller may be configured to store the drive torque data in a histogram of numbers of revolutions at predetermined intervals of drive torque values. Alternatively, or additionally, the engine controller may be configured to store the drive torque data in a matrix of rainflow cycle counts. The drive torque data may be temporarily stored in a buffer before being stored in the matrix of rainflow cycle counts. The engine controller may include a communication port to allow download of the stored drive torque data.
In another form, the present disclosure provides a vehicle data collection system. The system includes a vehicle equipped with an engine controller configured to determine drive torque data for the vehicle. The system also includes a data collection device, configured to download the drive torque data from the vehicle. Download of the data may occur when the vehicle is being serviced and may occur at any one of a plurality of remote data collection devices. After download, the drive torque data may be transmitted to a central data collection center. The engine controller may include both a processor configured to determine the drive torque data for the vehicle, and a memory configured to store the drive torque data in a non-time domain format. The engine controller may be configured to store the drive torque data in a histogram of numbers of revolutions at predetermined intervals of drive torque values. Alternatively, or additionally, the engine controller may be configured to store the drive torque data in a matrix of rainflow cycle counts. The drive torque data may be temporarily stored in a buffer before being stored in the matrix of rainflow cycle counts. The engine controller may include a communication port to allow download of the stored drive torque data.
In yet another form, the present disclosure provides a method of collecting vehicle data. The method includes downloading drive torque data from a vehicle, the drive torque data determined using an engine controller in the vehicle and stored in a memory in the vehicle. The method also includes transmitting the downloaded drive torque data to a central data collection center. The drive torque data may be stored in a non-time domain format. The non-time domain format may include a histogram of numbers of revolutions at predetermined intervals of drive torque values. The non-time domain format may alternatively (or additionally) include a matrix of rainflow cycle counts. The drive torque data may be temporarily stored in a buffer prior to being stored in the matrix of rainflow cycle counts. The temporary storage of the drive torque data in the buffer may include the steps of back-checking the drive torque data to identify cycles in compliance with a four-point rainflow cycle rule and binning the drive torque data.
Further areas of applicability of the present disclosure will become apparent from the detailed description provided hereinafter. It should be understood that the detailed description, including disclosed embodiments and drawings, are merely exemplary in nature intended for purposes of illustration only and are not intended to limit the scope of the invention, its application or use. Thus, variations that do not depart from the gist of the invention are intended to be within the scope of the invention.
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.
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.
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.
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.
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.
The simulation model 114 in the engine controller 112 is illustrated in greater detail in
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.
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.
An example revolutions-at-torque output is illustrated in
The revolutions-at-torque output of
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.
Torque measurements can be organized into cycles. To do this, the peaks and valleys of the torque measurements are considered. For example, in
If |P2−P1|>=|P3−P2| and |P4−P3|>=|P3−P2|,
then FROM=P2 and TO=P3,
end.
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
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.
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.
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.
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
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.
Binning can result, however, in some inaccuracies. For example, in
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.
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.
