System and method for vehicle diagnostics and health monitoring

Description Submit all comments and votes

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention generally relates to a vehicle monitoring system and method, and more particularly to a method and system for vehicle diagnostics and health monitoring.

2. Description of the Related Art

Motor vehicles contain complex mechanical systems that are monitored and regulated by computer systems such as electronic control units (ECUs) and the like.

Such ECUs monitor various components of the vehicle including engine performance, carburation, speed/acceleration control, transmission, exhaust gas recirculation (EGR), braking systems, etc.

However, vehicles perform such monitoring typically only for the vehicle driver and without communication of any impending results, problems and/or vehicle malfunction to a remote site for trouble-shooting, diagnosis or tracking for data mining.

Systems that provide for remote monitoring do not have a means for automated analysis and communication of problems or potential problems and recommendations to the driver.

As a result, the vehicle driver or user is often left stranded, or irreparable damage occurs to the vehicle as a result of neglect or driving the vehicle without the user knowing the vehicle is malfunctioning until it is too late.

SUMMARY OF THE INVENTION

In view of the foregoing and other problems of the conventional methods and structures, an object of the present invention is to provide a method and structure to extract information provided by the vehicle's internal monitoring systems, to transfer that information to a remote service center, to provide a means and method for comparison and analysis of the information, and to provide timely information to the driver of the vehicle.

In a first aspect of the present invention, an information system for a vehicle includes an electronic data collector (e.g., preferably for obtaining electronic data from the vehicle's internal monitoring systems), a client computer device within the vehicle (e.g., preferably for data management, remote session management and user interaction), a communication unit (e.g., preferably coupled to the client computer device, for providing remote communication for the client computer device), a remote service center (e.g., including a vehicle data store, a server computer, and a call center for communicating with the client computer device via the communication unit).

With the unique and unobvious structure and method of the invention, information can be reliably extracted from a vehicle's internal monitoring systems, and the information can be transferred to a remote service center. Further, the information can be compared and analyzed, to provide timely information for the driver of the vehicle to avoid the vehicle driver being stranded or the vehicle being irreparably damaged. Additionally, the ability of a driver to initiate health checkups brings the driver assurance of the proper functioning of his vehicle as well as reminders for preventive maintenance which will prevent the development of problems.

This system and method benefits the vehicle manufacturer and service provider by enhancing customer loyalty and providing timely feedback to solve engineering and manufacturing problems.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other purposes, aspects and advantages will be better understood from the following detailed description of a preferred embodiment of the invention with reference to the drawings, in which:

FIG. 1 illustrates an upper level environment in which the present invention is utilized;

FIG. 2 illustrates exemplary in-vehicle hardware components for the system shown in FIG. 3;

FIG. 3 illustrates an exemplary architecture of a fault monitoring and diagnosis system according to the present invention;

FIG. 4 illustrates a fault monitoring and diagnosis event operation flow; and

FIG. 5 illustrates a health checkup event operation flow according to the invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS OF THE INVENTION

Referring now to the drawings, and more particularly to FIGS. 1-5, there are shown preferred embodiments of the method and structures according to the present invention.

FIG. 1 illustrates an upper level environment of a system according to the present invention.

As shown in FIG. 1, the system 1000 includes a vehicle 10 with a vehicle driver or user 140, having an in-vehicle computing system 100, a client computer device 101 installed to enable vehicle health checkup and remote diagnostics, a communication link 150 (e.g., via wireless base stations 150B, or the like) for communicating vehicle information (e.g., vehicle identification number, (VIN), diagnostic data, and the like). Such a link may be interfaced with an intranet 150C, the Internet 150D, or a public (or private) switch telephone network (PSTN) 150E. Further shown, the vehicle location is established, for example by a device 317 (e.g., antenna or the like) for receiving positioning information from orbiting Global Positioning System (GPS) satellites 150A.

Further shown is a roadside assistance unit 175 for assisting the vehicle based on a signal received over the communication link 150.

A remote service center 200 is also provided having a diagnostic server 201, a help desk 202 and a data repository 203. The help desk 202 schedules services, orders parts, and dispatches assistance through the roadside assistance unit 175.

Further, a dealer 250 is shown communicating with the remote service center 200 and optionally with the vehicle 10.

FIG. 2 is a block diagram providing an exemplary component overview for the in-vehicle hardware. The in-vehicle hardware provides a platform for the client computer device 101 and for the system functions shown in the architectural design in FIG. 3. As shown in FIG. 2, the in-vehicle hardware includes a processor 300 coupled with memory 350, a user interface 310, a network interface 320, a vehicle interface 330, at least one persistent storage device 340, and optional external devices 360.

The processor 300 may be of a conventional type or it may be an embedded system depending upon the designer's requirements. Examples include an Intel Pentium.RTM., or the Hitachi SH-4 for an embedded system.

The user interface includes one or more input means such as an audio input 318 capability for speech recognition, speaker identification, or voice recording. For this a microphone such as those manufactured by AKG or Sony can be used. Other input means 319 may include a touch screen for, as an example, entering menu selections by pressing a particular area of the screen, and actuator buttons 301A such as a push-to-talk (PTT) button to initiate audio input to the processor or a "911" button for triggering a call for emergency help. The user interface also includes a plurality of output means such as an audio output capability 315 for generating auditory signals, text-to-speech, and prerecorded voice playback. The audio output may be coupled to the vehicle's speakers. The output means 316 may also include a display screen and indicator lights.

The processor is integrated with a network interface 320 to provide communication capability with the remote service center 200. Preferably, the network interface comprises a removable wireless telephone such as the Motorola i1000+ and a docking facility for the wireless phone integrated with the client computer device. Both voice and data connections can be supported by interfacing the processor 300 and the wireless phone. The telephone integration provides basic communication functions. It establishes a data (e.g. TCP/IP) connection with a remote service center (e.g., remote service center 200). Wireless technologies such as GSM (Global System for Mobile Communications), CDMA (Code Division Multiple Access), TDMA (Time Division Multiple Access), iDEN.TM. (a TDMA-based Motorola technology), and AMPS (Advanced Mobile Phone System) can all be supported. The phone may also be used for wireless voice communications.

The processor 300 is coupled to a vehicle bus 335 through a vehicle bus interface 330. The coupling between the client computer device and the vehicle bus interface 106 of FIG. 3, may be one of RS-232, USB (Universal Serial Bus), IDB (ITS Data Bus), Ethernet, and the like. The vehicle bus interface may support one of vehicle bus standards such as CAN (Controller Area Network) and the Society of Automotive Engineers' SAE J1850 - Class B Data Communication Network Interface. Alternatively, the processor supports some or all of the functions of the vehicle bus interface and connects directly to the vehicle bus 335. The vehicle bus shown in FIG. 2 is an inherent part of all new automobiles. The dotted line is used as an indication that the vehicle bus is built into the vehicle.

The in-vehicle hardware includes at least one persistent storage device 340 such a hard disk, CD-ROM, flash memory, and the like coupled to the processor. The processor may also be coupled by additional interface means 365 such as infrared, RF, serial and parallel ports and the like, to communicate with external devices 360 such as printer, fax, personal digital assistant (PDA), notebook computer, etc. Optionally, the processor 300 may be coupled to a location sensing device such as a GPS receiver 317 (FIG. 1) to provide vehicle location information. The system may or may not assume the availability of the automatic vehicle position information. Location-related scenarios, such as emergency help dispatch may use automatic vehicle positioning or may depend on the driver to provide position information.

In an exemplary system, such capabilities have been provided. Further, other computing devices such as a laptop computer or personal data assistant (PDA) may be used to perform the function of the processor 300 and some or all of the additional hardware components and to provide the hardware platform for the client computer device 101.

In-Vehicle Computing System

FIG. 3 depicts a more detailed system architectural view of a preferred embodiment of the system 1000 according to the present invention for fault monitoring and diagnosis. The system includes the in-vehicle system 100 (including client computer device 101) and the remote service center 200.

The application software that makes up the in-vehicle computing system 100 includes an in-vehicle client computer device 101 and a vehicle bus interface 120. The vehicle bus interface may run on a hardware component separate from that of the client computer device 101, such as those manufactured by Vetronix Inc. or DigiTech Inc., or may have some or all of its functions contained within the client computer device 101.

The vehicle bus interface 120 is responsible for replying to requests for parametric data. It is also responsible for continuously monitoring the vehicle bus 104 for any fault reported by the ECUs 103, in terms of diagnostic trouble codes (DTCs).

The vehicle bus interface 120 includes the following modules: vehicle bus adapter 120C, fault detector 120B, and diagnostic data service 120A. The fault detector 120B polls the vehicle bus 104 through the vehicle bus adapter 120C checking for fault codes reported by the vehicle ECUs 103. The vehicle bus adapter 120C translates the messages received from the vehicle bus into the language of the fault detector. It also translates messages from the fault detector into the language of the vehicle bus. The fault code specifications and protocols of the vehicle may be Original Equipment Manufacturer (OEM) and model dependent. The term "vehicle fault codes" is meant to be synonymous with the term "trouble code" or "diagnostic trouble code". A listing of such codes may be found in the publication of the Society of Automotive Engineers, "SAE On-Board Diagnostics for Light and Medium Duty Vehicles Standards Manual". The diagnostic data service 120A accepts request for vehicle parametric data and retrieves the data using the vehicle bus adapter.

The client computer device 101 performs several functions including communicating to the remote service center 200 by means of the network interface 107 using the cell phone 102. It sends requests for diagnostic services such as health checkup and fault diagnosis to the service center.

In support of this function, it sends diagnostic trouble codes (DTCs) and vehicle information to the service center. It handles incoming requests for data from the service center. It communicates through the user interface 105 to the driver using a combination of audio, indicator lights, and text. The severity, and optionally the description, of the reported trouble codes may be so communicated. Proper recommended actions such as "stop now", "go to a service station immediately", or "contact the service center for further help by . . . " are spoken to the driver using text-to-speech (ITS).

The client computer device 101 handles DTCs by listening for vehicle faults through the fault monitor 420, classifies the severity of the faults (e.g. alarm or warning), provides a description of the DTCs and a recommended course of action. The client computer device also manages the state of active requests, vehicle status, and other relevant information handling functions, e.g. including bootup and stored information or data.

Further, the client computer device may initiate a remote health checkup upon a user request. The driver or user may request a comprehensive, remote health checkup if the driver or user feels that the vehicle is behaving abnormally, is alerted by the application of potential trouble, or simply wants to get a checkup before a long trip.

The in-vehicle system establishes a data connection, using a cellular phone 102, with a diagnostic server 201 at the service center 200, collects diagnostic data using the diagnostic data service 120A, and uploads a snapshot of the vehicle data (e.g. VIN, test data with time-stamp) to the diagnostic server 201. The in-vehicle system may need to interact with the server 201 throughout a diagnosis or health checkup session, collecting and providing additional vehicle information as requested by the server 201. The result from the server 201 indicates either that the vehicle is in good health with n