Quick check vehicle diagnostics

[0002] The present invention relates to data collection from a vehicle, and more particularly to a data collection system which provides an overview of vehicle subsystems to quickly extract on-board data and identify the severity of any vehicle subsystem faults.

[0003] Commonly, on-board data recorders gather vehicle information from a plurality of vehicle subsystems such as the engine, the transmission and the braking system among others. Such data recorders are specifically applicable to heavy duty vehicles for analysis by a fleet operations facility. The data is stored on-board the vehicle for later examination and tracking should a problem with the particular subsystem develop.

[0004] Each particular subsystem typically requires a separate extraction and analysis software package to review the stored data. A technician must therefore be familiar with the software package and data presentation format of each particular subsystem. The data from each particular subsystem is commonly provided in a spreadsheet like format which may be time consuming and difficult to analyze. The technician may therefore avoid performing a full diagnostic on each individual subsystem until a subsystem problem is identified by a vehicle operator. Such identification typically may not occur until the underlying subsystem problem has become acute. Such identification is less than ideal.

[0005] Accordingly, it is desirable to provide an overview of vehicle subsystems to identify the severity of any faults of all vehicle subsystems in a timely manner.

[0006] A vehicle data storage system in communication with a diagnostic unit according to the present invention provides a “quick fault” screen which summarizes data stored within a storage device of the vehicle data storage system. The “quick fault” screen displays a plurality of keys organized in matrix format to display an overview of vehicle subsystem faults conditions through animation and/or coloring of each key in response to event data stored within the storage device.

[0007] Should no problematic vehicle operating conditions be recorded, all of the keys in the “quick fault” screen will be colored green to indicate all subsystems are operating satisfactory. A technician is thereby rapidly apprised of the vehicle subsytems status upon connection of a data interface between the diagnostic unit and vehicle data storage system. No laborious spreadsheet-like analysis is required to determine that all subsystems are operating satisfactory.

[0008] Should one or more of the subsystem control modules recognize a problematic vehicle operating condition, the event data therefrom will be stored in the storage device. The associated key on the “quick fault” screen will then be animated/colored as appropriate to the fault condition. For example only, a yellow key will represent a single occurrence of a triggering event while a red key will represent multiple triggering events for that fault condition.

[0009] By selecting any animated/colored key, a more detailed representation of the event data stored in the storage device for the particular subsystem is represented. The detailed subsystem screen presents the event data recorded within the storage device in a graphical and/or tabulation format showing associated subsystem parameters over time.

[0010] The present invention presents an overview of all the subsystems and, if desired, a detailed report of the faulted subsystems by selecting the animated/colored key. By then reviewing the more detailed information for the faulted subsystem, the technician can quickly reach an initial determination of whether further investigation is warranted.

[0011] The various features and advantages of this invention will become apparent to those skilled in the art from the following detailed description of the currently preferred embodiment. The drawings that accompany the detailed description can be briefly described as follows:

[0012] FIG. 1 is a schematic view of one embodiment of the present invention vehicle diagnostic unit;

[0013] FIG. 2 is a screen display of a “quick fault” screen of the vehicle diagnostic unit in FIG. 1; and

[0014] FIG. 3 is a screen display of one subsystem selected from the “quick fault” screen of FIG. 2.

[0015] FIG. 1 illustrates a general schematic view of a vehicle data storage system 10 in communication with a diagnostic unit 12. The diagnostic unit 12 is preferably a personal computer, however, other dedicated units will also benefit from the present invention. The diagnostic unit 12 includes a display screen 14, preferably a touch screen and a character input screen portion 16 for inputting alphanumeric characters onto the screens 14 and 16. Additionally, an input 18 such as a keyboard, mouse, trackball, remote or the like may also be used to communicate with the diagnostic unit 12. The diagnostic unit 12 includes a data interface 20 for connection to a vehicle databus such as a type J1708 or J1939 databus.

[0016] The vehicle data storage system 10 includes a plurality of subsystem control modules such as an ABS brake control module 22a, a transmission control module 22b, a collision avoidance control module 22c, an engine control module 22d, or any other type of control module 22e. A plurality of sensors 24a, 24b, 24c, 24d, and 24ecorrespondingly communicate with the subsystem control modules 22a, 22b, 22c, 22dand 22eto provide information about the particular vehicle subsystem. Traditionally, the subsystem control modules were able to be accessed through vehicle databus in only a very limited manner. With the present invention, subsystem control modules are more accessible to make information more available for analysis.

[0017] The sensors 24 sense vehicle operating conditions such as temperatures, pressures, valve positions or any other condition. The subsystem control modules translate the vehicle operating conditions into corresponding vehicle information. Vehicle information may include but is not limited to vehicle speed, engine speed, gear position, fluid levels, brake temperatures, bearing temperatures, vehicle load, battery voltage, and brake status in addition to other vehicle information. The combined vehicle information from all of the subsystem control module systems 22 is sent to a memory buffer 26. As the memory buffer 26 becomes full, the new vehicle information from the subsystem control modules 22 will overwrite the information already contained on the memory buffer 26.

[0018] The subsystem control modules 22 are programmed to recognize fault conditions or problematic vehicle operating conditions. For example, if an engine temperature is high or out of a predetermined range, the engine control module 22dwill recognize the high engine temperature as a triggering event. When a triggering event has been recognized by a subsystem control module 22, the subsystem control module 22 will direct or command the buffer 26 to transmit the event data surrounding the triggering event to a secondary storage device 28.

[0019] The event data is defined by a first predetermined time before the triggering event to a second predetermined time after the triggering event. That is, the event data includes vehicle information previous to the triggering event which has been stored within buffer 26, for example, from two minutes before the triggering event to two minutes after the triggering event. However, it is to be understood that the event data may be defined in any number of ways. In addition to the particular subsystem event data, other vehicle information data such as vehicle speed, odometer reading, gear selection, environmental conditions such as temperature and the like, may also be recorded.

[0020] Unlike some prior art devices, the present invention commands the transfer from event data from the memory buffer in response to a request signal from the subsystem control module having the triggering event. For example, if a temperature sensor 24ddetects an engine over temperature condition, the engine controller 22dwill send a request signal to the memory buffer 26 to send the event data to the secondary storage device 28. In this manner, each subsystem control module need not be polled for vehicle information.

[0021] Preferably, the secondary storage device 28 is of a large enough capacity to store a rather large quantity of data equivalent to months of vehicle operation. Event data is thus available from a single source. The event data stored within the secondary storage device 28 has heretofore been available in a spreadsheet like format which requires detailed and time intensive analysis.

[0022] Referring to FIG. 2, the display screen 14 of the diagnostic unit 12 is illustrated. The diagnostic unit 12 preferably displays a “quick fault” screen 30 which summarizes the data stored within the secondary storage device 28. The quick fault screen 30 includes a vehicle ID tag 32 and the date of extraction 34. Other status like information such as maintenance facility location, technician name, and the like may alternatively or additionally be included.

[0023] The “quick fault” screen 30 displays a plurality of keys 36 preferably organized in matrix format. The term “key” should be construed broadly to include touch screen buttons, physical buttons, and other selectable devices. The keys 36 are preferably separated into clusters related to particular vehicle subsystems such as a brake cluster 38a, a transmission cluster 38b, a collision avoidance cluster 38can engine cluster 38d, or any other type of cluster 38e. It should be understood that other arrangements and organizations will also benefit from the present invention.

[0024] Each key 36 preferably represents a fault condition of a vehicle subsystem control module. That is, each control module 22 may have a multiple of fault conditions associated with it. Each fault condition represents a compilation of event data which has been recorded to the secondary storage 26 due to one or more triggering event occurrences. That is, the event data from a multiple of problematic vehicle operating conditions identified by, for example, the engine subsystem control module 22d(FIG. 1) would be compiled into one or more fault conditions, each represented by a key 36. Compilations of the event data from multiple triggering events is readily accomplished through known software packages.

[0025] The “quick fault” screen 30 preferably displays an overview of the fault conditions through animation and/or coloring of each key 36 in response to the data stored within the secondary storage device 28. Known software packages running under a standard operating system can be used to extract information from the data as stored in the secondary storage device 28 and provide the associated animation/coloring in the inventive manner according to the present invention.

[0026] Should no problematic vehicle operating conditions be recorded within the secondary storage device 28, none of vehicle subsystems experienced a triggering event. Each of the keys 36 on the “quick fault” screen 30 will preferably be colored green to indicate all subsystems are operating satisfactory. The technician is thereby rapidly apprised of the vehicle subsytems status upon connection of the data interface 20 between the diagnostic unit 12 and vehicle data storage system 10. No laborious analysis is required to determine that all subsystems are operating satisfactory. The present invention thereby promotes preemptive subsystem diagnostic checks by providing for a quick subsystem overview when the vehicle undergoes routing maintenance such as an oil change or the like.

[0027] Should one or more of the subsystem control modules 22 recognize a problematic vehicle operating condition, the event data therefrom will be stored in the secondary storage device 28. The event data, which has been compiled as described above, will then be associated to one or more fault conditions. The key 36 on the “quick fault” screen 30 associated with that fault condition will then be animated/colored, i.e., will not be colored green. Preferably, the animation/coloring will be appropriate to the subsystem data stored in the secondary storage device 28. That is, the animation/coloration represents the severity of the fault condition for each subsystem. For example only, a key 36 representative of a particular fault condition for a particular subsystem will be colored yellow if the event data comprises a single triggering event. The same key 36 will be colored red if the event data comprises a multiple of triggering events. The same key may be blinking if the multiple triggering events occurred within a predetermined time period, etc. It should be understood that other animation/coloration representations for problem hierarchies will also benefit from the present invention.

[0028] In FIG. 2, key 36′ represents the ABS sensor subsystem. Due to the ABS sensor subsytem event data stored in the secondary storage device 28, diagonal lines are superimposed over the ABS sensor subsystem key 36′. The ABS sensor key 36′ may alternatively or additionally be colored in a certain manner to provide an extremely informative problem hierarchy.

[0029] Preferably, by selecting any animated/colored key 36, a more detailed representation of the event data stored in the secondary storage device 28 for the particular subsystem is represented by a detailed subsystem screen 40 (FIG. 3). The detailed subsystem screen preferably presents the subsystem data recorded within the secondary storage device 28 in a graphical and/or tabulation format showing associated subsystem parameters over time. It should be understood that other information related to the triggering event may alternatively or additionally provided for printing, storing, and transferring to other diagnostic devices or programs

[0030] The present invention presents an overview of all the subsystems and, if desired, a detailed subsystem report of the faulted subsystem simply by selecting the animated/colored key. By then reviewing the more detailed information for the faulted subsystem, the technician can reach an initial determination of whether further investigation is warranted.

[0031] Furthermore, it is understood that the present invention is not limited to a microprocessor based control system. The system may be implemented in a non-microprocessor based electronic system (either digital or analog).

[0032] The foregoing description is exemplary rather than defined by the limitations within. Many modifications and variations of the present invention are possible in light of the above teachings. The preferred embodiments of this invention have been disclosed, however, one of ordinary skill in the art would recognize that certain modifications would come within the scope of this invention. It is, therefore, to be understood that within the scope of the appended claims, the invention may be practiced otherwise than as specifically described. For that reason the following claims should be studied to determine the true scope and content of this invention.